「証拠で縛る」か「軽さで走る」か。AI Coding の 2 つの手法を、20 機能の EC サイト開発で検証した ～musubix3 vs musubix6: 時間、AI Credits、品質を実測した比較レポート～

はじめに

AI Coding は、個人の試作から、組織の業務システム開発へと広がっている。しかし、エンタープライズ開発では、動くコードができるだけでは足りない。仕様に沿っていること、テストで確認されていること、誰が何を承認したかが残ることが求められる。

AI Coding の手法には、この規律の扱いが大きく異なるものがある。証拠を重ねて完了を検証する手法と、規律を保ちながら軽さを優先する手法である。どちらが適するかは、開発の目的によって変わる。

本レポートは、この 2 つの手法を代表する musubix3 と musubix6 を、同じ仕様の EC サイトの開発で比べた記録である。新規開発と機能追加の 2 段階で、実現される仕組み、品質、時間、AI Credits を実測した。

主な読者は、エンタープライズ開発に AI Coding を導入しようとする、開発責任者、アーキテクト、開発者である。1 章で必要な機能を整理し、2 章に結論、4 章以降に実測の結果を示す。次の要約には、主な数値をまとめた。

要約

• 背景: エンタープライズ開発で AI Coding をするために必要な機能（SDD、TDD、証拠、承認）を、2 つのツールがどう実現するかを調べた。約 20 機能の EC サイトを、musubix3 と musubix6 で開発した。新規開発と機能追加の 2 段階で、時間、トークン、AI Credits を比べた。
• 問い: 役割ごとの AI エージェントを置くだけでは、エンタープライズ開発には足りない。SDD、TDD、証拠、承認という仕組みが要る（1 章）。その仕組みを、2 つのツールがどう実現するかを見た（4.4 節）。
• 結論: この実行構成では、機能の品質は同等だった（171 項目のブラックボックス検査が両者とも全 pass）。差は、証拠をどこまで作るかという開発プロセスのコストに表れ、musubix3 は両工程で、時間も AI Credits も多かった。ただし、新規開発は並列条件が揃っておらず、参考値である（9.1 節）。
• 新規開発（14 機能、参考値）: musubix6 は 17分04秒、114.32 AI Credits で、musubix3（26分50秒、231.66）より、時間が約 36%、AI Credits が約 51% 少ない。
• 機能追加（6 機能）: musubix6 は 19分43秒、185.98 AI Credits で、musubix3（22分55秒、247.31）より、時間が約 14%、AI Credits が約 25% 少ない。新規開発より、差は小さい。
• 合計: musubix6 は 36分47秒、300.30 AI Credits で、musubix3（49分45秒、478.97）より、時間が約 26%、AI Credits が約 37% 少ない。
• 差の主因: レビュー用サブエージェントの消費と、メインエージェントの往復の多さである。ただし、機能追加では、musubix6 もレビューを 6 回行い（musubix3 は 7 回）、差が小さかった。
• 承認: musubix3 は release 承認に到達できなかった（承認 2/3）。要件と設計の承認は、Copilot が代行して記録した。

1. エンタープライズ開発で AI Coding をするために、何が必要か

本レポートの主題は、エンタープライズアプリケーションの開発で AI Coding を使うとき、どのような機能が必要かである。AI との対話で動くものを素早く作る Vibe Coding の手法を、論じるものではない。エンタープライズ開発は、顧客や組織に納める成果物を、長期にわたって保守し続ける開発である。この条件では、AI Coding に追加の機能が要る。

1.1 エンタープライズ開発で、AI Coding に求められること

AI Coding（コーディングエージェントに実装を任せる開発）をエンタープライズ開発に使うと、次の課題が出る。

• 「テストは通りました」という AI の報告を、どこまで信用してよいか。
• AI が書いたコードを、半年後に別の担当者が「なぜこうなっているか」まで説明できるか。
• 品質と責任の所在を、第三者に説明できるか。
• 統制や検証を強めるほど、開発は遅く、高くなる。どこまで強めるべきか。
• 承認やレビューを人間が行うと、AI の速度が人間の待ち時間に引きずられる。

個人で使うアプリや試作なら、動けばよく、壊れても自分で直せる。納品物では、この前提が成り立たない。完成の合意、第三者による再確認、保守、説明責任が必要になる。そのためには、AI の作業の土台を、先に決めておく必要がある。その土台が、SDD と TDD である。

1.2 SDD（仕様駆動）と TDD（テスト駆動）が重要である

課題の多くは、AI に「何を作るか」と「正しく動くか」を、先に与えていないことから生じる。前者を固定するのが SDD、後者を固定するのが TDD である。AI Coding では、人間が実装を逐一見ないぶん、この 2 つの重要性が増す。

SDD（Specification-Driven Development、仕様駆動開発）

実装より先に、要件と設計を仕様として書き、実装を仕様から導く開発手法である。重要な理由は、次のとおりである。

• 曖昧な指示を、勝手に解釈させない。AI は、曖昧な指示をもっともらしく解釈して実装する。「速い」「安全」のような要件では、完了を判定できない。測定できる形で仕様を書けば、何を満たせば完了かが決まる。
• 意図が残る。仕様がないと、コードだけが唯一の記録になる。AI が生成したコードは意図が残りにくく、担当者が替わると「なぜこうなっているか」が失われる。
• 変更の影響を追える。要件、設計、コード、テストが ID で結びついていれば、変更の影響範囲を特定できる。

TDD（Test-Driven Development、テスト駆動開発）

実装より先にテストを書く開発手法である。SDD が「何を作るか」を決めるのに対し、TDD は「正しく動くか」を決める。次の 3 ステップを、小さく繰り返す。

1. Red: 期待する挙動を表すテストを、先に書く。実装が無い、または不足しているので、実行すると失敗する。この失敗を確認する。
2. Green: そのテストを通す、最小限の実装を書く。
3. Refactor: テストが通ったまま、コードを整理する。

重要な理由は、次のとおりである。

• テストが仕様の表現になる。AI は、実装に合わせてテストを書きがちである。先にテストを書けば、テストが「何を満たすべきか」を固定し、実装の後追いにならない。
• Red の失敗が、テストの有効性の証拠になる。最初から通るテストは、何も検査していない可能性がある。Red で実際に失敗したことが分かれば、そのテストは意味のある検査だと言える。
• 「テストは通りました」という報告を、検証しやすくなる。Red から Green への遷移が記録されていれば、通ったことだけでなく、通る前に失敗していたことも確認できる。
• 回帰を防ぐ。機能追加を重ねても、過去の挙動をテストが守る。

1.3 役割ごとの AI エージェントだけでは足りない

AI Coding では、PM（要件の整理）、PE（設計）、PG（実装）、テスターといった役割を、それぞれ別の AI エージェントに担わせればよいと考えがちである。役割を分けると、1 つのエージェントが書いて自分で確認する偏りを減らせる。実際に、今回の 2 つのツールも、実装とは別のレビュー用サブエージェントを使った（5.3 節）。

しかし、役割を分けるだけでは、エンタープライズ開発の課題は解決しない。次の点が残るためである。

残る課題	役割分担だけでは足りない理由
共通の土台がない	各エージェントが、別々の解釈で動く。仕様とテストという共通の基準（SDD、TDD）がなければ、分担した成果物が整合する保証がない
検証が自己申告のままになる	どのエージェントも、報告は会話の中にある。「テスターが確認しました」は、確認の内容と結果が記録に残らなければ、第三者には検証できない
同じ偏りを共有する	同じモデルの別エージェントは、同じ誤解や見落としを共有しうる。役割を分けても、独立した検証になるとは限らない
手順が守られた保証がない	「先にテストを書く」「承認を得る」といった手順を、各エージェントが守ったかを確認する仕組みがない。指示を書くだけでは、強制にならない
責任の所在がない	誰が何を根拠に承認したかが残らない。エージェントは責任を負えず、最終的な責任は人間にある
状態が消える	会話が終わると、決定の経緯が失われる。長期の保守に必要な、変更の理由と履歴が残らない

つまり、必要なのは、役割の分担に加えて、手順を強制し、結果を記録し、後から検証できる仕組みである。役割分担は、その仕組みの上で働く構成要素の 1 つにすぎない。この観点は、本レポートの判断軸になる。なお、この整理は、エンタープライズ開発の要件から導いた見解であり、役割分担のみの構成を実測して比べたものではない。

1.4 GitHub Copilot の機能だけでは足りない

本レポートの 2 つのツールは、どちらも GitHub Copilot CLI の上で動く。では、Copilot 自体の機能で、1.1 節の要件は満たせるだろうか。Copilot は、次の機能を提供している（GitHub Docs の公開情報に基づく）。

Copilot の機能	内容
カスタム指示、プロンプトファイル	リポジトリ全体やパスごとの指針を、常時または手動で適用する
カスタムエージェント、サブエージェント	役割や権限を分けた専門エージェントを定義する。サブエージェントは、独立した文脈で作業する
エージェントスキル	手順や資材をまとめたフォルダを、必要なときに読み込む
フック	エージェントの実行過程の決まった時点（ツール実行の前後など）で、コマンドを確実に実行する。ツール実行の許可と拒否、監査ログの記録もできる
MCP サーバー	外部システムや API に接続する
クラウドエージェント、コードレビュー	Issue から実装し、PR を作る。PR を AI がレビューする
セッションログ	エージェントの作業内容と使ったツールを確認できる

これらは、エンタープライズ開発に有用な部品である。特にフックは、手順の強制や監査ログの土台になる。しかし、これらは部品であって、開発の進め方そのものではない。次の点が、利用者の設計に委ねられる。

残る課題	Copilot の機能だけでは足りない理由
開発手順が定義されていない	「要件、設計、テスト、実装、承認」という順序と、各段階の完了条件は、Copilot の標準機能にはない。指示やスキルに書くのは利用者である
指示は強制にならない	カスタム指示とスキルは、AI への依頼である。AI が従ったかは、別に確認しなければならない。強制するには、フックや検査（gate）を自作する必要がある
証拠の形式が決まっていない	トレーサビリティ（要件、設計、テスト、コードの対応）や、Red から Green への遷移といった記録の形式は、利用者が決める。セッションログは作業の記録であり、検証済みの完了の証拠ではない
完了と承認の基準がない	何をもって完了とし、誰がいつ承認するかを判定する仕組みは、標準では提供されない
変更の履歴と理由が残らない	変更の理由、影響範囲、承認の記録を、仕様と結びつけて残す形式は、標準にはない
構成の設計と保守が必要になる	指示、エージェント、スキル、フックを組み合わせた構成は、利用者が設計し、保守する。設計が悪ければ、効果も出ない

つまり、Copilot は AI Coding の実行基盤と拡張点を提供するが、エンタープライズ開発に必要な手順、証拠、承認の規律は、その上に利用者が構築する必要がある。musubix3 と musubix6 は、この規律を、スキルと検査（gate）として構築した例と位置づけられる。今回の 2 つのアプリには、フックの設定はなかった。なお、この整理は、公開されている機能の説明と今回の構成から導いた見解である。Copilot 単体で同じ開発を行って比べたものではない。また、Copilot の機能は更新が続くため、将来は一部が標準で提供される可能性がある。

1.5 SDD と TDD の先: どこまで証拠を残すか

SDD と TDD を前提にしたうえで、エンタープライズ開発では、もう 1 つの判断が残る。守られたことを、どこまで検証できる記録として残すかである。記録を厚くすれば、説明責任と保守性は高まるが、時間とコストが増え、承認が人間の待ち時間になる。

この判断に対して、考え方が正反対の 2 つのツールがある。どちらも SDD と TDD を前提にしている。

• musubix3: AI を信用せず、リポジトリに残る証拠で完了を検証する。SDD、TDD、Evidence-Driven Development を組み合わせる。
• musubix6: 規律は保ったまま、証拠の量と人間の関与を最小にする。

1.6 この比較の問い

同じ EC サイトを 2 つのツールで開発し、次の 3 つを調べた。

1. エンタープライズ開発に必要な機能（SDD、TDD、証拠、承認）を、各ツールはどう実現し、品質に差は出るか。
2. 時間、トークン、AI Credits は、どれだけ違うか。
3. 新規開発と機能追加で、差の出方は違うか。

読み方

• 結論だけ知りたい場合は、2 章を読む。
• 実測値は、4 章にある。
• 差の理由は、5 章にある。
• 2 つのツールのコンセプトは、6 章と 7 章にある。
• 用語は、末尾の用語集（11 章）にまとめた。

2. 先に結論: あなたの開発は、どちらに近いか

1 章で整理した仕組みのうち、どちらのツールも SDD と TDD は備えている（4.4 節）。選択の分かれ目は、証拠と承認をどこまで厚くするかである。以下は、今回の構成（承認必須の musubix3、単発の copilot -p 実行、ツールごとのプロンプト）での実測に基づく暫定の目安である。一般的な適性の結論ではない。

あなたの状況	目安	根拠
PoC、社内ツール、機能追加を頻繁に繰り返す	musubix6	合計で、時間が約 26%、AI Credits が約 37% 少なかった（4 章）。機能追加でも、時間が約 14%、AI Credits が約 25% 少なかった（4.2 節）
コストやトークンを強く絞りたい	musubix6	新規開発の入力トークンが約 71%、機能追加が約 38% 少なかった（4 章）
最初の新規開発を、速く安く立ち上げたい	musubix6	新規開発で、差が最も大きかった。時間 −36%、AI Credits −51%（4.1 節。並列条件が揃わない参考値）
非対話で自動実行する（copilot -p など）	musubix6	承認必須の設定では、musubix3 は workflow 照合に失敗し、release 承認に到達できなかった（4.3 節）。事前承認や承認不要の設定では比べていない
監査や規制で、第三者に説明できる証跡が必須	musubix3	設計上の適性であり、今回の実験で完了を実証したものではない。承認を完了できる運用であれば、承認が成果物のハッシュに紐づき、要件からテストまでのトレースと変更履歴が残る設計である（7 章）。今回の成果物は、この水準に達していない（4.3 節）
「誰がいつ何を承認したか」を全工程で残す	musubix3	requirements、design、release の各段階で承認を記録する設計である（7 章）
迷っている	musubix6 から始める	統制が必要になった時点で musubix3 へ移る進め方もあり得る（未検証）

• 今回テストした機能の範囲では、機能の品質に差はなかった（4.3 節）。選ぶ基準は、品質の高低ではなく、証拠をどこまで作るかというコストと統制のバランスである。
• 新規開発に比べて、機能追加の差は小さかった。差の大きさは、変更の内容（金額、状態、セキュリティを含むか）に左右される可能性がある（5.5 節）。
• この結論は、1 つの実行構成に基づく。一般化できる範囲は 9 章に示す。

3. 目的と条件

エンタープライズ開発で AI Coding に必要な仕組み（1 章）を、2 つのツールがどう実現するかを調べた。そのために、大きく複雑なオンラインショッピングサイト（REST API）を、musubix3 と musubix6 でそれぞれ開発した。新規開発と機能追加の両方で、実現状況、品質、時間、トークンを比較した。仕様には、エンタープライズ開発の模擬として、認証、決済、並行性、状態機械、監査ログを含めた。

項目	内容
スタック	TypeScript, Express, better-sqlite3, vitest
仕様	large/APP_SPEC.md（F1〜F14: 会員登録とログイン、住所、カテゴリ、商品の検索と並べ替え、カート、送料、クーポン、チェックアウト、在庫引当の期限切れ、モック決済と冪等性、注文の状態機械、注文一覧、管理者レポート）
追加要件	large/CHANGE_SPEC.md（F15〜F20: レビュー、お気に入り、返品と返金の計算、監査ログ、ログインのロックアウト、クーポンのユーザーごとの利用上限）
実行方法	各ディレクトリで copilot -p（別セッション）、--model gpt-6.1-sol、--allow-all --no-ask-user
計測	時間は実行前後の実時間。トークンと AI Credits は --usage-output-file と終了時の統計
musubix3	npm install musubix3 + musubix3 init（9 個のスキル）
musubix6	~/GitHub/musubix6 をインストール + musubix6 init（8 個のスキル）
musubix3 の承認	要件、設計、release の承認を、Copilot が Copilot (delegated by nahisaho) 名義で記録するよう指示。waiver は使わない
実行回数	各条件 1 回

この仕様は、認証、決済、並行性、状態機械を含む。実験の制約は 9 章に示す。

4. 結果

4.1 新規開発（F1〜F14）

musubix3 は単独で再実行し、musubix6 の時間は自己申告値から換算した。実行条件が揃っていないため、この表は参考値である（9.1 節）。

指標	musubix3	musubix6	差
所要時間	26分50秒	17分04秒	−36%
AI Credits	231.66	114.32	−51%
入力 / 出力トークン（キャッシュを含む）	6.6M / 86.5k	1.9M / 45.7k	入力 −71%
変更行	+1732 / −62	+1521 / −23
自前テスト	22	14
最終 gate	fail（承認 2/3、change-history が fail）	全 pass

4.2 機能追加（F15〜F20）

指標	musubix3	musubix6	差
所要時間	22分55秒	19分43秒	−14%
AI Credits	247.31	185.98	−25%
入力 / 出力トークン（キャッシュを含む）	6.6M / 86.3k	4.1M / 68.2k	入力 −38%
変更行	+864 / −24	+1060 / −43
自前テスト（累計）	28	23
最終 gate（実行終了時）	fail（ready=false。承認 2/3、workflow と change-history が fail）	全 pass

4.3 成果物の品質

独立したブラックボックス検査（blackbox2.mjs）を、両アプリで実行した。F1〜F14 の 123 項目と、F15〜F20 を加えた 171 項目で、結果は両者とも全項目 pass だった。検査には、並行リクエストでの在庫の超過販売と、クーポン利用回数の超過も含む。npm audit（本番依存）は、両者とも脆弱性 0 件だった。機能のブラックボックス検査の範囲では、品質に差はない。性能と、詳細なセキュリティ検査は、対象外である。

検査スイートは、最初の実行で、両アプリに同じ失敗が出た。原因を調べると、いずれもスイート側の不具合だった（カートに残った在庫不足の明細、仕様の上限 100 を超える limit=500 の指定）。修正後に再実行した結果が上記である。失敗が両者で同一だったため、アプリ間の比較には影響しない。

ただし、ここで比べたのは機能の品質である。musubix3 の成果物は、リリース可能な証拠としては完成していない。

• 要件と設計の承認は記録されたが、release 承認に到達していない（承認 2/3）。
• workflow 照合は、12 件の宣言が Copilot の実行イベントと完全には一致せず、fail だった。非対話（copilot -p）の実行で、この照合が通らなかった。
• change-history は、2 件の変更について、成果物と TDD 証拠の順序が正しくないとして fail だった。エージェント自身も、補足テストを Red/Green の途中に追加し、workflow 宣言を実行順に記録しなかったことが原因と報告している。
• 一方で、trace のエラーは 0 件、TDD の Red→Green は 22 サイクル、テスト ID は 22/22 が pass だった。

musubix6 の最終 gate は、全項目が pass だった。なお、tdd evidence には、弱い Red（Red を再記録した 2 件。TEST-CAT-002、TEST-ORD-005）という注記が付いた。

「機能が正しい」ことと「リリース可能と証明できる」ことは別である。

4.4 エンタープライズ開発に必要な仕組みの実現状況

1 章で整理した仕組みについて、今回の成果物とログから確認できた事実を並べる。評価ではなく観測であり、長期運用での有効性は確認していない。

必要な仕組み（1 章）	musubix3	musubix6
SDD: 仕様の永続化	要件と設計を、feature ごとに .musubix/features/（shop、shop-r2）へ保存	機能ごとの spec 10 個を .sdd/specs/ へ保存。trace は 22 REQ でエラー 0
TDD: テスト先行と Red→Green の記録	22 サイクルを記録し、tdd の検査は pass	23/23 テストが Red→Green。弱い Red が 2 件ある旨を注記
検証可能な記録（証拠）	gate が複数の決定論的検査を実行。trace は pass。workflow と change-history は fail	gate が trace、TDD 台帳（ハッシュ連鎖が正常）、テストを実行し、全 pass
手順を強制する仕組み	gate が、欠けた証拠や順序違反を fail として検出した（今回は自身の手順違反を検出）	gate が trace と TDD 証跡を強制。スキップは PASS にならない設計
独立した検証（役割分担）	段階ごとに、別のレビュー用サブエージェントが確認（要件、設計、release）。新規 6 回、機能追加 7 回	リスクの観点（spec、方針、状態、契約）ごとに、別のサブエージェントが確認。新規 3 回、機能追加 6 回
承認と責任の所在	要件と設計の承認を記録（Copilot が代行）。release は未到達	既定は AI のレビューを経て spec をロック。人間の承認は approval: human の spec に限る
変更履歴と追跡	CHANGE を 2 件記録。変更の順序の検査は fail	spec の差分更新と、Red/Green の再記録
非対話での完了	承認必須の設定では、release 承認に到達できなかった	gate まで完了した

• 役割分担（1.3 節）は、両ツールとも取り入れていた。ただし、役割分担だけで検証が成立したわけではない。どちらも、gate という機械的な検査が最終判定を担った。
• musubix3 は、手順の違反を gate が検出して止めた。強制の仕組みが働いた例である。ただし、止まった結果、release に到達できなかった。強制の強さと、完了までの速度は、トレードオフだった。

5. 差が出た理由

時間と AI Credits の差を、メインエージェントとレビュー用サブエージェントに分けて分解した（出典は results/*/usage.json と results_change/*/usage.json）。

5.1 時間の内訳

項目	新規 musubix3	新規 musubix6	追加 musubix3	追加 musubix6
実時間	1610 秒	1024 秒	1375 秒	1183 秒
API 呼び出しの合計時間	1384 秒	874 秒	1177 秒	1050 秒
うちメインエージェント	949 秒	735 秒	465 秒	597 秒
うちレビュー用サブエージェント	435 秒	139 秒	712 秒	453 秒

• 新規開発では、API 合計時間の差（510 秒）の約 58% がサブエージェント、約 42% がメインエージェントによる。
• 機能追加では、メインエージェントの時間は musubix3 のほうが短く（465 秒対 597 秒）、差はサブエージェント（712 秒対 453 秒）で生じた。
• usage.json は API 時間の合計だけを記録しており、レビューが他の作業と並列だったかは確定できない。

5.2 AI Credits の内訳

項目	新規 musubix3	新規 musubix6	追加 musubix3	追加 musubix6
メインエージェント	143.67	69.01	85.26	75.85
レビュー用サブエージェント	87.99	45.31	162.05	110.13
合計	231.66	114.32	247.31	185.98
レビューの占有率	38%	40%	66%	59%

• 新規開発では、差（117.34）の約 64% がメインエージェントの消費による。musubix3 のメインエージェントは、musubix6 の約 2.1 倍のクレジットを使った。
• 機能追加では、差（61.33）の約 85% がレビューによる。musubix3 のレビューは、総クレジットの 66% を占めた。
• 差の主因は、工程で異なった。新規開発ではメインエージェントの往復の多さが、機能追加ではレビューが、より大きな要因だった。

5.3 レビュー用サブエージェントの比較

新規開発

	名前	リクエスト数	API 時間	クレジット
musubix3	requirements-review	5	91 秒	19.10
	requirements-diff-review	2	5 秒	1.83
	design-review	6	154 秒	20.00
	design-diff-review	8	33 秒	8.26
	quality-review	17	130 秒	33.68
	quality-diff-review	5	22 秒	5.12
musubix6	spec-review	2	52 秒	13.02
	boundary-review	7	47 秒	13.86
	state-review	4	40 秒	18.43

機能追加

	名前	リクエスト数	API 時間	クレジット
musubix3	requirements-review	7	134 秒	28.01
	requirements-diff-review	7	51 秒	10.51
	design-review	20	240 秒	42.91
	design-diff-review	6	37 秒	8.05
	release-review	17	159 秒	45.48
	release-diff-review	5	23 秒	6.86
	release-rejection-diff	16	69 秒	20.22
musubix6	spec-review	9	124 秒	23.82
	policy-test-review	15	131 秒	31.37
	state-contract-review	8	38 秒	14.26
	delta-spec-review	17	80 秒	21.81
	final-contract-review	6	22 秒	3.39
	final-policy-review	10	59 秒	15.47

• 新規開発のレビューは、musubix3 が 6 回、musubix6 が 3 回だった。musubix3 は段階（要件、設計、品質）ごとに、差分の再レビューを挟んだ。musubix6 は、spec と境界、状態を観点ごとに見た。
• 機能追加では、musubix6 のレビューが 3 回から 6 回に増え、musubix3（7 回）との回数の差が縮まった。musubix6 は、金額と状態遷移、セキュリティ（返金、ロックアウト、監査）を含む変更を、リスクの高い変更として扱い、方針とテストのレビューを加えた可能性がある。これは、レビューの名称と、リスク階層の仕様（7 章）からの推測であり、ログでは確認していない。
• musubix3 の機能追加で最大だったのは、design-review（20 リクエスト）と release-review（17 リクエスト）である。release の却下後の再確認（release-rejection-diff）にも、20.22 クレジットを使った。

5.4 メインエージェントの作業量

指標	新規 musubix3	新規 musubix6	追加 musubix3	追加 musubix6
モデルへのリクエスト数	72	32	54	31
入力トークン（キャッシュ含む）	5.32M	1.55M	3.66M	1.99M
生成（出力）トークン	48.0k	36.1k	25.8k	35.9k

• 新規開発では、リクエスト数が約 2.3 倍、入力トークンが約 3.4 倍になった。ツールの呼び出しごとに履歴が入力として再送されるため、手順が増えるほど入力が増える。
• 機能追加では、リクエスト数が 1.7 倍、入力が 1.8 倍だった。生成トークンは、musubix6 のほうが多かった。
• musubix3 の workflow-record は、新規開発の transcript で 20 回、機能追加で 11 回あった。

5.5 要因のまとめ

要因	新規開発への寄与	機能追加への寄与
① 成果物と検証の手順が多く、メインの往復が増える	大きい（メインの差が約 75 クレジット）	小さい（約 9 クレジット）
② 段階ごとの広いレビュー	中程度（差が約 43 クレジット）	大きい（差が約 52 クレジット）

• ①は、立ち上げ時に、要件、設計、トレース、記録をまとめて作る場面で大きい。2 回目以降は、既存の成果物に差分を足す形になり、固定費が下がったように見える。
• ②は、musubix3 が機能追加でも段階ごとにレビューを置き続けたことと、release の却下後の再確認が加わったことによる。
• 機能追加の差が新規開発より小さかった理由は、①の縮小と、musubix6 のレビュー増加の組み合わせである。6 機能をまとめて追加したことと、変更内容が金額やセキュリティを含んだことが影響した可能性があるが、1 回の測定からは分離できない。

6. musubix3 のコンセプトと、musubix6 を開発した動機（要点）

• TDD の扱い: どちらも Red→Green を手順に含む。違いは、その記録の扱いである。musubix3 は、Red/Green の証拠を、gate の検査対象にする（今回は 22 サイクルを記録し、tdd の検査は pass）。musubix6 は、tdd red と tdd green のコマンドで、ハッシュ連鎖の台帳に記録する（今回は 23/23 テストが Red→Green で、弱い Red が 2 件の注記付き）。TDD の記録は、今回の実行では、どちらも機能した。
• musubix3 は、SDD、TDD、Evidence-Driven Development を組み合わせ、AI の「完了」を、リポジトリに残る証拠で機械的に検証する。標準では強制しにくい完了の定義、仕様の永続化、手順の強制、独立した検証、追跡可能性、責任の所在を、仕組みで補う。代償は、成果物と承認の増加である。
• musubix6 は、開発者の説明によれば、musubix3 の運用で見えた課題（時間とコスト、人間の承認、非対話実行）を解決するために作られた。要件と設計を 1 つの spec にまとめ、リスク階層で手順の重さを変え、人間の承認を例外に限る。
• 今回の結果は、この設計の違いと整合する。ただし、整合することは、設計の意図が原因であることの証明ではない。

7. コンセプトの違い（要点）

観点	musubix3	musubix6
信頼の置き方	AI を信用せず、外形的な証拠で検証する	AI を信頼して自走させ、最小限のルールで規律を保つ
形態	npm パッケージの CLI + 9 個のスキル	1 個の依存なしスクリプト + 8 個のスキル
成果物の置き場	.musubix/（features、changes、evidence、constitution）	.sdd/（specs、tdd 台帳、review、gate 報告）
手順の重さ	常に一定	リスク階層（T0〜T2）で変わる
人間の関与	requirements、design、release の承認が標準	既定は不要。approval: human を明記した spec のみ
役割分担（レビュー用エージェント）	段階（要件、設計、品質、release）ごとに置き、差分の再レビューを挟む	リスクの観点（spec、方針、状態、契約）ごとに置く
優先する価値	監査性、統制、再現性	速度、トークン効率、少ない成果物

今回の成果物の構成にも、違いが表れた。musubix3 は、feature を 2 つ（shop、shop-r2）に分け、変更記録を 2 件（CHANGE-0001、CHANGE-0002）残した。musubix6 は、機能ごとに spec を分け、10 個の spec を残した。内訳は、accounts、catalog、checkout、orders の 4 つと、追加分の reviews、wishlist、returns、audit、lockout、coupon-limits の 6 つである。

8. 向いている開発と向かない開発: 2 章の補足

2 章の判断表を、今回の結果から補う。

• 規模が大きい新規開発: 立ち上げ時に、差が最も大きかった。要件、設計、トレースを一度に作る場面で、musubix6 の軽さが効いた。
• 多数の機能を続けて追加する開発: 新規開発より差が小さかった。musubix3 の固定費は、2 回目以降に下がる傾向があった。
• 金額、状態、セキュリティを含む変更: musubix6 でも、複数観点のレビューを重ねた。リスクの高い変更では、どちらのツールも、手順が重くなる。

判断の軸は、「後で説明できること」が成果物の一部かどうかである。一部なら musubix3、そうでなければ musubix6 から始める。

9. 限界と次の確認事項

9.1 この比較の限界

• 計測は各条件 1 回で、複数回の逐次実行はしていない。
• エンタープライズ開発の要件のうち、長期保守、複数人での引き継ぎ、監査対応は、今回の実験では検証していない。4.4 節は、成果物とログから確認できた事実の整理であり、これらの有効性の評価ではない。
• 機能追加は、2 つの実行を並列に動かした。API の同時利用による誤差を含む。
• 新規開発では、musubix3 の最初の実行が、実行環境側の中断で途中停止した。musubix6 は最初の実行が完了したので、その結果を採用した。musubix3 は、作業ディレクトリをベースラインに戻し、最初からやり直した。このため、再実行の musubix3 は、musubix6 と並列ではなく、単独で動いた。新規開発の時間とクレジットは、同じ並列条件ではない。中断した実行のデータは、large/results_interrupted/ に残した（比較には使っていない）。
• musubix6 の新規開発の所要時間は、中断により time.txt が欠けたため、Copilot が報告した所要時間（17分04秒）を秒に換算した（1024 秒）。他の値は、実行前後の実時間である。
• 各実行では、メインエージェントが gpt-6.1-sol、レビュー用サブエージェントが主に claude-sonnet-5 と、モデルが混在した（musubix6 の boundary-review などは gpt-6.1-sol）。モデル別の単価の違いは、分離していない。
• どのレビューを何回行うかは、各ツールの指示に従って、エージェントが決めた。ツールの仕様で固定された回数ではない。
• プロンプトは、各ツールの標準的な手順に沿って書き分けた。完全に同条件ではない。
• 仕様とブラックボックス検査は、私（Copilot）が書いた。検査は、最初の実行で 2 つの不具合が見つかり、修正している。検査の対象は、API の機能の範囲である。
• 差が小さかった理由（5.5 節）は、測定からの解釈であり、要因の分離はしていない。

9.2 未解決の事項

• musubix3 の release 承認は未完了である（workflow、change-history が fail、承認 2/3）。waiver を使うかどうかは、別途判断が必要である。
• workflow 照合が、対話的な実行では通るのか、copilot -p に固有の問題なのかは、今回のデータからは確定できない。
• 3 回目以降の機能追加で、差がさらに縮むのかは、確認していない。

10. 成果物

• large/APP_SPEC.md, large/CHANGE_SPEC.md: 共通仕様
• large/musubix3_test/, large/musubix6/: 各アプリ
• large/results/, large/results_change/: 時間、使用量、transcript
• large/results_interrupted/: 中断した musubix3 の新規開発の記録（比較には不使用）
• large/blackbox2.mjs, large/run_bench.sh, large/run_change.sh: 検査と実行スクリプト

11. 用語集

用語	意味
SDD	Specification-Driven Development（仕様駆動開発）。実装の前に仕様を書き、仕様から実装を導く
TDD	Test-Driven Development（テスト駆動開発）。失敗するテストを先に書き、通す実装を書く
Evidence-Driven Development	証拠駆動開発。完了の判断を、会話の報告ではなくリポジトリに残る検証可能な記録で行う
Red / Green	TDD で、テストが失敗している状態（Red）と、通った状態（Green）
EARS	Easy Approach to Requirements Syntax。要件を決まった文型で書き、曖昧さを減らす記法
gate	完了条件を機械で検査し、満たさなければ失敗させる関門
trace	要件、設計、コード、テストの対応づけ
workflow 照合	エージェントの自己申告と、実際のスキル実行イベントを突き合わせる musubix3 の検査
spec	musubix6 で、要件、設計、承認の単位を 1 ファイルにまとめた仕様書
T0 / T1 / T2	musubix6 のリスク階層。数字が大きいほど、手順が重くなる
delta review	前回の未解決分と、修正した差分だけを再レビューする方式
冪等性（idempotency）	同じ操作を繰り返しても、結果が 1 回分と同じになる性質
AI Credits	GitHub Copilot の利用量の単位。本レポートでは usage.json の totalNanoAiu を 10 億で割った値
waiver	検査を免除する記録。ゲートを回避できるため、今回は使っていない