takemi-ohama · Nov 4, 2026 · Nov 4, 2026
@@ -98,6 +98,73 @@
         }
       ],
       "body": "# ai-plugins のプロジェクト MVV\n\nこのリポジトリ（ai-plugins。主要プラグインは NDF。NDF を Web から使うサービス Factory も置く）の Mission（何のためにやるか）・Vision（目指す姿）・Value（判断の基準）。AI と人がこのプロジェクトで判断するときの基準にする。判断の記録から候補を抽出した根拠は `issues/mvv-candidates-ai-plugins.md` にある。`.ndf/` へ置く形は #1366 の設計が決める。\n\n## NDF の共通原則との関係\n\nこの MVV は、NDF の共通原則（`issues/ndf-common-principles.md`。上位の原則「人を守り、人の発展を支える」、優先順位、AI が自分で取れる行動は「進める / 止めて人へ戻す」の 2 つだけ、人と AI の対話、必ず承認が要る操作 C1〜C8）の範囲で定める。ai-plugins は NDF を作るプロジェクトであると同時に、NDF を使うプロジェクトの 1 つでもある。**共通原則の優先順位と「必ず承認が要る操作」C1〜C8 は、この MVV のどの項目よりも先に効く。** 以下の Vision と Value は、その範囲でだけ読む。\n\n## Mission（何のためにやるか）\n\nClaude Code / Codex を使うチームに、プラグインとして、また Web から操作するサービス（Factory）として、要求から本番の配布までの開発工程を「人の判断が要る所だけで止まる」形で届け、開発者が価値を利用者へ届けるまでの時間と費用を減らす。Kiro と agy へは配らず、レビューと提案の相手役として起動するだけにする。\n\n## Vision（目指す姿）\n\n開発者が課題を 1 つ指せば、設計・実装・レビュー・検査・配布までを NDF が回し、人が手を止めるのは、設計の承認と本番への配布の承認の 2 回（と、共通原則が必ず承認を要するとする操作）に寄る。その 2 回には、決めたこと・未検証のまま残ること・MVV に照らした判定がそろって届き、人は問い直さずに 1 回で決められる。2 回の承認を MVV 判定に任せるかは、利用者が進め方ごとに事前に選ぶ（`.ndf/pace.json` の許可と MVV の承認。利用者の承認による委任であり、MVV が利用者の承認に代わるのではない）。共通原則の C1〜C8 と固有の P1 に当たる操作は任せず、配布が他のリポジトリへの公開（C5）に当たるときも任せない。任せた判定の記録と、人が判定を覆した回数は版ごとに見える。言語・テスト・ブランチ運用・配布の手段が違うどのリポジトリでも、プロジェクトごとの設定（`.ndf/`）を 1 つ置けば同じ工程がそのまま通る。効果は版ごとの実測（費用・秒・件数）で示され、チームの内外の誰もがその数値を見て版を選べる。Factory では、GitHub のリポジトリを登録すれば同じスプリントが並列に動き、進捗が Web の一覧と詳細で見え、承認ゲートで知らせが届く。マーケットプレイスの他のプラグイン（playwright-kit・mcp-*）と Factory も同じ基準で判断する。\n\n## Value（判断の基準）\n\n1. **まず届ける**: 完璧なものより「たぶん動く」ものを早く出す。開発版のチャネル・導入の確認・自動テストで守り、見つけた不具合は 4 条件（原因が分かっている・既存の約束事を壊さない・既存の方針の範囲・1 回の revert で戻せる）を満たせばその場で直す。処理の改善・削減・高速化に寄与しない指摘は直さない。ただし、人を害する・秘密・利用者のデータ・戻せない操作に関わる指摘（共通原則の範囲）は、効率に寄与しなくても直す。\n2. **利用者の手を止めない**: 人の承認は「設計」と「本番への配布」の 2 回に寄せ、再起動・告知・確認で操作を求めない。承認を求めるときは、判断の材料（決めたこと・未検証のまま残ること・残る危険）を資料に集めてから求め、材料が無いときはどれが無いかを示す。共通原則の C1〜C8 と固有の P1 に当たる操作の承認は、この 2 回とは別に必ず残す。それ以外の操作を実行前に確認するかどうかは「取り消せるか・他者が読む内容を外へ出すか・判断を問うか」の 3 つの問いで決める。\n3. **測って決める**: 効果は実測（費用・秒・件数）で示し、測らずに良くなったとは言わない。手順やコードに書くコマンドは書く前に実行して確かめる。\n4. **決まった手順はスクリプトに、判断と中身は AI に**: 待ち・集計・検査・記録・整形・起動の組み立てのように判断の要らない手順はスクリプトが進め、AI（LLM）は判断と中身（コード・設計文書）だけを担う。conductor がプランの外で手当てをしたら、その形と回数を記録に残す。同じ手当てが 2 度目になった時点で、雛形へ入れる課題を起こす。守れているかは、振り返りで手当ての件数として数える。\n5. **どのプロジェクトでも使える形を保つ**: スクリプトにするのは手順の骨組みだけにし、プロジェクトごとに違うもの（テストのコマンド・起点のブランチ・配布の手段・言語・ランタイム・課題の置き場）は設定か引数で受ける。ai-plugins の形を既定に埋め込まない。\n6. **根本原因の場所で直す**: 現象ごとに直さず、直す場所が現象の場所と違うときは共通の層へ寄せてから設計する。同じ役割の定数・関数を Skill ごとに分けない。\n7. **判断の理由を残す**: 変更点の列挙とは別に「何を決め、なぜそう決めたか」を版・設計文書・振り返りに残し、同じ判断を繰り返さない。正本は 1 か所に置き、写さずに指す。\n8. **語は 1 語 1 意味**: 業界に流通している語を用語集で 1 語 1 意味に揃える。使う言語は `AGENTS.md` のポリシーが決める。\n9. **試すものと本体を分ける**: 呼んだときだけ働く仕組みは実験版として、課題を起こさずその場で試し、台帳に使った結果と行き先を残す。効いたと実測で示せたものだけを、設計・レビュー・版の経路で本体へ移す（`AGENTS.md` の「安定版と実験版」）。\n10. **費用 > 速さ > 品質の順で決める**: 品質を上げる工程（レビューのラウンド・検査・やり直し）は、変更や周回ごとに決めた費用と時間の上限の中でだけ行う。上限は実測（費用・秒）で決めて見直す。上限を超えてまで行いたい品質の向上は、その場で続けずに別の Issue へ起こし、後の作業へ回す。ただし品質を置き去りにしない。後へ回した品質の Issue は、棚卸しで決めた基準（利用者へ届いた不具合か・同じ手当てや失敗の繰り返しの回数・後へ回してからの期間など。閾値は棚卸しの手順が持つ）で順位を調整する。この順位は効率の範囲の中での順位であり、人を害する・秘密・利用者のデータ・戻せない操作に関わる品質（共通原則の範囲）と、承認資料に載せる材料の正しさには当てない。\n\n## 必ず人の承認が要る操作（ai-plugins に固有のもの）\n\nNDF の共通原則の C1〜C8 に加えて、このプロジェクトでは次の操作も人の承認を省かない。\n\n| # | 操作 | 理由 |\n| --- | --- | --- |\n| P1 | 配布物の取得元・版の規則を変える（マーケットプレイスの登録の置き換え、既定ブランチ・版の規則の変更） | 利用者全員に効き、戻すには利用者側の操作が要る（`AGENTS.md` の版と配布の方針） |\n\n## 改訂\n\nMVV は進化する。改訂は利用者の承認で成立し、版・理由・前の版との差分を記録に残す。方向の誤りは、人が AI の判断を覆した回数・AI が決められなかった回数・検査をすり抜けて利用者へ届いた不具合の件数で検出し、閾値を超えたら改訂を提案する。手順の正本は `development-workflow` の `references/project-mvv.md` の「改訂」にある。\n"
+    },
+    {
+      "version": 5,
+      "sha256": "e74e0d3b32838c6803902e783bca260e75d6f3c7b7a512fa4a05ed59bcd51ee9",
+      "approved_at": "2026-11-04T04:41:46+00:00",
+      "approved_by": "user",
+      "reason": "無駄な作業の根本原因の対策（#2436 の振り返りで覆し 4 件が閾値 3 を超えた。量の上限・設計の承認の先頭で要否・やめる既定・外の利用で確かめる）",
+      "vet": {
+        "verdict": "follow",
+        "at": "2026-11-04T04:38:52+00:00",
+        "accepted_unknown": false
+      },
+      "changes": [
+        {
+          "item": "Mission",
+          "kind": "changed"
+        },
+        {
+          "item": "Vision",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 1",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 2",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 3",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 4",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 5",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 6",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 7",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 8",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 9",
+          "kind": "changed"
+        },
+        {
+          "item": "P1",
+          "kind": "changed"
+        },
+        {
+          "item": "Value 10",
+          "kind": "removed"
+        }
+      ],
+      "body": "# ai-plugins のプロジェクト MVV\n\nこのリポジトリ（ai-plugins。主要プラグインは NDF。NDF を Web から使うサービス Factory も置く）の Mission（何のためにやるか）・Vision（目指す姿）・Value（判断の基準）。AI と人がこのプロジェクトで判断するときの基準にする。判断の記録から候補を抽出した根拠は `issues/mvv-candidates-ai-plugins.md` にある。`.ndf/` へ置く形は #1366 の設計が決める。\n\n## NDF の共通原則との関係\n\nこの MVV は、NDF の共通原則（`issues/ndf-common-principles.md`。上位の原則「人を守り、人の発展を支える」、優先順位、AI が自分で取れる行動は「進める / 止めて人へ戻す」の 2 つだけ、人と AI の対話、必ず承認が要る操作 C1〜C8）の範囲で定める。ai-plugins は NDF を作るプロジェクトであると同時に、NDF を使うプロジェクトの 1 つでもある。**共通原則の優先順位と「必ず承認が要る操作」C1〜C8 は、この MVV のどの項目よりも先に効く。** 以下の Vision と Value は、その範囲でだけ読む。\n\n## Mission\n\nClaude Code / Codex を使うチームに、プラグインとして、また Web から操作するサービス（Factory）として、要求から本番の配布までの開発工程を「人の判断が要る所だけで止まる」形で届け、開発者が価値を利用者へ届けるまでの時間と費用を減らす。良くなったかは、NDF の外のプロジェクトで実際に使われた結果で確かめる。Kiro と agy へは配らず、レビューと提案の相手役として起動するだけにする。\n\n## Vision\n\n開発者が課題を 1 つ指せば、設計・実装・レビュー・検査・配布までを NDF が回す。人が手を止めるのは、設計の承認と本番への配布の承認の 2 回と、必ず承認が要る操作に限られる。設計の承認では、設計の中身より先に、それを作る要否を数行で決める。1 回のスプリントで作る量（課題の数と承認資料の分量）は、人が 1 回の承認で読み切れる量に収まる。2 回の承認を MVV 判定に任せるかは、利用者が進め方ごとに事前に選ぶ（`.ndf/pace.json` の許可と MVV の承認。利用者の承認による委任であり、MVV が利用者の承認に代わるのではない）。共通原則の C1〜C8 と固有の P1 に当たる操作は任せず、配布が他のリポジトリへの公開（C5）に当たるときも任せない。承認には、決めたこと・未検証のまま残ること・MVV に照らした判定が、番号でなく中身の分かる語でそろって届く。出した版は実際に使って確かめ、確かめた結果が次に何を作り何をやめるかを決める。ai-plugins の中より、NDF の外のリポジトリでの利用の手がかりを先に拾う。言語・テスト・ブランチ運用・配布の手段が違うどのリポジトリでも、プロジェクトの設定（`.ndf/`）を 1 つ置けば同じ工程が通る。Factory でも同じ基準で判断する。\n\n## Value\n\n1. **小さく出して使って確かめる**: 完璧なものより、小さく「たぶん動く」ものを早く出す。開発版のチャネル・導入の確認・自動テストで守る。出した後は実際に使って受け入れ条件を確かめ、確かめていないものを済んだと記録しない。見つけた不具合は 4 条件を満たせばその場で直す。人を害する・秘密・利用者のデータ・戻せない操作に関わる指摘は、効率に寄与しなくても直す。\n2. **人が判断できる量に収める**: 一度に作る量は、スプリントの課題の数と承認資料の分量で測り、その上限を人が 1 回の承認で読み切れる量で決める（数値は実測から決めて見直す）。上限に収まらないものは、始める前に分けるか縮める。承認は「設計」と「本番への配布」の 2 回に寄せ、設計の承認の先頭で作る要否を数行で問う。再起動・告知・確認で操作を求めない。AI が決められないときは、理由と根拠を添えて人へ戻す。共通原則の C1〜C8 と固有の P1 に当たる操作の承認は、この 2 回とは別に必ず残す。承認を求めるときは判断の材料を先に集め、番号と内部の呼び名だけで書かない。\n3. **やめる・縮めるを既定にする**: 上限（費用・秒・ラウンド・量）に当たったら、続けずにやめるか縮める。それを既定にし、残りを新しい Issue へ送ることを既定にしない。起票するのは、利用者へ届いた不具合か、人の安全・秘密・利用者のデータ・戻せない操作・承認資料の正しさに関わるものに限る。役に立たない繰り返し（同じ指摘の出直し、指摘 0 件でのラウンドの追加）は始めない。\n4. **外の利用で測って決める**: 効果は実測（費用・秒・件数）で示し、測らずに良くなったとは言わない。何を作るかの順位は、NDF の外のプロジェクトでの利用と、そこで見つかった不具合を先に置く。手順やコードに書くコマンドは、書く前に実行して確かめる。\n5. **決まった手順はスクリプトに、判断と中身は AI に**: 判断の要らない手順（待ち・集計・検査・記録・整形・起動の組み立て）はスクリプトが進め、AI は判断と中身だけを担う。同じ手当てが 2 度目になったら、まずその手順自体を消せないかを問う。消せないときだけ雛形へ入れる。決まりを足すより、要らない決まりを減らす方を選ぶ。\n6. **どのプロジェクトでも使える形を保つ**: スクリプトにするのは手順の骨組みだけにする。プロジェクトごとに違うもの（テストのコマンド・起点のブランチ・配布の手段・言語・ランタイム・課題の置き場）は、設定か引数で受ける。ai-plugins の形を既定に埋め込まない。\n7. **根本原因の場所で直す**: 現象ごとに直さない。直す場所が現象の場所と違うときは、共通の層へ寄せてから設計する。同じ役割の定数・関数を Skill ごとに分けない。\n8. **判断の理由を残し、語をそろえる**: 変更点の列挙とは別に、「何を決め、なぜそう決めたか」を、版・設計文書・振り返りに残す。正本は 1 か所に置き、写さずに指す。語は業界に流通している語を用語集で 1 語 1 意味にそろえ、番号には題か中身を添える。\n9. **試すものと本体を分ける**: 呼んだときだけ働く仕組みは実験版として、課題を起こさずその場で試し、台帳に使った結果と行き先を残す。実際に使って効いたと示せたものだけを、本体へ移す。\n\n## 必ず人の承認が要る操作\n\n| # | 操作 | 理由 |\n| --- | --- | --- |\n| P1 | 配布物の取得元・版の規則を変える（マーケットプレイスの登録の置き換え、既定ブランチ・版の規則の変更） | 利用者全員に効き、戻すには利用者側の操作が要る |\n\n## 改訂\n\nMVV は進化する。改訂は利用者の承認で成立し、版・理由・前の版との差分を記録に残す。方向の誤りは、人が AI の判断を覆した回数・AI が決められなかった回数・検査をすり抜けて利用者へ届いた不具合の件数で検出し、閾値を超えたら改訂を提案する。手順の正本は `development-workflow` の `references/project-mvv.md` の「改訂」にある。\n"
     }
   ]
 }