背景

Copilot で業務アプリを作るために、自分でワークフローのフレームワーク（HVE。以降、この記事では HVE v1 と書きます）と、DAG のオーケストレータまで作りました。

結果は、正直、期待どおりではありませんでした。
業務アプリは完成せず、HVE v1 本体の開発・保守に 181,055 AI クレジットを使いました。

その反省から、いま個人で作り直しているのが、**HVE v2 にあたる Enterprise App Build Kit（EABK）**です。
公開はしていますが、おそらく、ほとんどの方は知らないと思います。そのため、比較の前に、EABK を独立した節で説明します。

一方で、その仕組み（HVE v1）を使わず、Coding Agent に短い Prompt を入れて作ったアプリは、どれも実行や受入の記録があるところまで進んでいました。
別の比較実験でも、単一の Prompt は、オーケストレータを足した場合より 1.7〜2.25 倍速く、2.49〜3.50 倍安く、品質は同じでした。

そこで、最初はこう考えました。
「何もない素の Coding Agent が、一番よいのではないか」

ただ、これを人がアプリ全体に回し続けると、次の 4 つの問題が起きていました。

問題	実際に起きたこと
ずれ	元のビジネスの目的から外れていく
矛盾	機能を足すたびに、ビジネスの論理に矛盾が生まれる
繰り返し	同じ Prompt を何度も入れている
停止	そのたびにジョブが止まり、人が再開している

この記事の問いは、次の 1 つです。

Enterprise で Vibe Coding をするとき、標準にすべき方式はどれか。

結論から書くと、私の立場は「Enterprise App Build Kit（EABK）を標準にする。ただし、すべてを重い工程で作るのではなく、小さな変更は EABK が素の Coding Agent に振り分ける」です。
この記事では、その立場に至った根拠を、同じ要求定義書を使った実測で確かめます。振り分け機能そのものは、今回は実測していません。その点は、後ろで分けて書きます。

注意点 / 前提

これは私個人の環境・条件での記録です。製品の評価や、一般的な結論ではありません。

実験は 2026-10-08 に、同じ PC（14 コア・64GB、Windows、常時稼働）で行いました。Copilot CLI 1.0.93 を使っています。
各条件の試行は 1〜6 回です。統計的な有意差は示していません。
比べた方式のうち、1 つ（EABK）は私が開発したツールキットです。利害関係があります。
実験の設計・実行・集計と、元のレポートの執筆は AI（GitHub Copilot のエージェント）が行いました。採点役にも、同じ系統のモデル（Claude Sonnet 5.5）を使っています。同じ系統のモデルの成果物を好む偏りは、否定できません。
本記事は私個人の記録であり、所属組織の公式見解ではありません。
実験の入力ファイル、成果物、採点結果の公開先はありません【要確認：公開の予定】。

EABK（HVE v2）とは

比較の前に、EABK を説明します。私が個人で開発している、GitHub Copilot 用のマルチエージェント開発 toolkit で、HVE v1 の失敗を踏まえた作り直し（HVE v2）にあたります。
GitHub で公開しています: dahatake/HypervelocityEngineering（Business Engineering x Software Engineering include Agentic DevOps）。

この節は、公開されている README（確認日 2026-10-13）を、私が読み直してまとめたものです。実験に使ったバージョンが、この README の版と同じかどうかは確認していません【要確認：実験時の版】。README の最新版では、エージェントは 6 種、skills は 7 種、CI は ebak-verify.yml です。

1. 何を解決するものか

要求定義書・カタログ・System Test の整合性を保ったまま、アプリケーションを最高品質・最短時間・最小 Token で実装することを目指します。（README より）

複数の AI エージェントに、要求定義・実装・テストを繰り返させると、次の問題が起きがちです。これは、この記事の「ずれ」「矛盾」にそのまま重なります。

実装の途中で要求が書き換わり、承認していない内容が「承認済み」になる。
離れた要求どうしの矛盾に、書いた本人のセルフレビューでは気づけない。
テストを実装に合わせて書き換えてしまい、要求の意味が変わる（実装のバグが「正解」になる）。
並行作業で ID が重複したり、要求の意味が衝突したりする。
監査結果やログがチャット履歴にしか残らず、失われる。

2. 4 つの手段

手段	内容
役割の分離	要求を書く役・監査する役・テストを作る役・実装する役を、別のエージェントに分ける。どのエージェントも、自分が作った成果物を自分で「正解」と判定できない
強制ゲート	エージェントごとの書き込み範囲と、作業を終える前の検証を、hook と verify で強制する
決定的スクリプト	検査・ID の採番・台帳の更新・ログの要約は、LLM ではなくスクリプトで行う。同じ入力なら常に同じ結果になる
データの永続管理	要求定義書、カタログ、ID 台帳、System Test の台帳、run の状態・ログ・監査結果を、決まったパスのファイルに残す。チャット履歴に依存せず、中断しても途中から再開できる

利用者がやることは、オーケストレーターのエージェント conductor に、/build で Prompt を 1 回送るだけです。
conductor は、要求定義 → 独立監査 → System Test の先行設計 → 並行実装 → 直列の統合 → 最終監査 → 報告までを、最大 24〜48 時間、人の介入なしで実行します。

3. 6 つのエージェント

エージェント	責務	書き込める範囲（hook で強制）
`conductor`	計画、作業の割り当て、統合、ゲートの判定、報告。小さな作業は自分で行う	`work/` と `docs/run-history.md` だけ
`rd-author`	要求定義書・カタログの作成と更新、質問票、決定記録。要求を書けるのは、このエージェントだけ	`docs/`（run-history を除く）
`rd-auditor`	意味の監査（矛盾・目的との整合・記述の質）。`rd-author` とは別系統のモデルを使う設計	`work/` だけ（読み取り専用）
`test-designer`	受入基準から System Test と台帳のケースを、実装より前に作る	`tests/system/`
`implementer`	1 つの作業項目（要求 1〜5 個）を、worktree で実装し、単体テスト・結合テストを書く	自分の worktree（要求定義書と System Test は変更不可）
`reviewer`	差分と受入基準の照合。共通部品・契約・セキュリティ・個人情報・画面の変更にだけ使う	なし（読み取り専用）

4. 7 つの工程

工程 1〜2（品質の土台）: 実装を始める前に、要求定義書の直接矛盾を 0 件にします。利用者の判断が必要なものは質問票に挙げ、関係する受入基準を BLOCKED にして、残りの作業を先に進めます。
工程 4（テストファースト）: test-designer は、要求定義書だけを根拠に期待値を決めます。実装を正解として扱わないためです。
工程 5（並行実装）: 並行するのは、依存関係がなく、同じ共通部品・テーブルに触れない項目だけです。統合は 1 本ずつ直列に行い、そのたびに verify と canary テストを実行します。
工程 6（最終）: System Test の全量実行と、rd-auditor による全量監査（3 回の多数決）を行い、残すべき情報を docs/ と台帳に転記してから報告します。

5. 規則を、LLM の判断に任せない仕組み

層	実装	発火するタイミング	例
hook	`.github/hooks/quality-gates.json` → `scripts/hooks/gate.py`	ツール実行の前と、作業役・conductor が終了する前	`rd-author` 以外が要求定義書を編集しようとしたら拒否する。`implementer` の終了前に verify を実行し、失敗なら差し戻す
verify	`scripts/verify.py`（CHK-01〜27）	作業役のゲート、統合のたび、CI	台帳のケースが理由なく削除された。受入基準の本文が変わったのに台帳が古いまま

README は、VS Code の hook がプレビュー機能で、harness によって動作が異なることがあると注意しています。そのため、同じ規則を verify でも検査し、hook が効かない環境でも、統合の時点で止まるようにしています。

README によると、品質の規則の多くは、/build で run を開始したときだけ働きます。/build 以外の Prompt で変更を依頼すると、規則が効かないリスクがあります。

この点は、後ろの「振り分け」の議論に直結します。振り分け後に ⓪ 素の Coding Agent が動く場合、その変更も PR の CI を通す、といった外側の守りが要ると考えています。

6. 中断しても再開できる理由

会話の要約には依存せず、状態を次のファイルと git に置きます。

置き場所	内容	git	保持期間
`docs/`	要求定義書、カタログ、ID 台帳、実行履歴	管理する	永続
`tests/system/ledger.json`	System Test のケースと最新の状態	管理する	永続
`work/`	キュー（`queue.json`）、進捗（`progress.md`）、報告、結果、証跡、ログ、worktree	管理しない	14 日

止まったときは、同じセッションで「続けて」と送るか、新しいセッションで同じ Prompt を送れば再開します。この記事の完走の再計測で、1 文の依頼で続きから進めたのは、この仕組みによるものです。

7. Token を節約する工夫

長い手順書は skills に置き、担当の作業役が必要なときだけ読む。
検査・採番・台帳更新・要約は、スクリプトで行い、LLM には要約だけを渡す。
テストは影響範囲だけを実行し、全量は節目と最終工程だけにする。
多数決の監査は、最終工程だけにする。
作業役のモデルを、難易度で振り分ける設計（scripts/ebak.config.json の models）。ただし、この記事の実験では、この指定が 15 回中 10 回守られませんでした（後述）。

8. 入手と導入

前提は、git リポジトリ、Python 3.9 以上（標準ライブラリだけで動く）、GitHub Copilot（VS Code の Agents ウィンドウ、Copilot CLI、GitHub Copilot app）です。
対象リポジトリのルートで、次の 1 行を実行します。

Windows（PowerShell）

irm https://raw.githubusercontent.com/dahatake/HypervelocityEngineering/main/tools/install.ps1 | iex

macOS / Linux / WSL / Git Bash

curl -fsSL https://raw.githubusercontent.com/dahatake/HypervelocityEngineering/main/tools/install.sh | bash

環境変数 EBAK_REF で、タグ・ブランチ・commit を固定できます。
--dry-run で、書き込まずに操作だけを確認できます。--check で、更新が必要かを CI で検出できます。
既存のアプリ（brownfield）には、python scripts/adopt.py scan で棚卸しし、逆生成した要求の仮説（承認待ち）と、現状の挙動の固定から始められます。
GitHub Spec Kit の仕様を、/build の依頼文に変換して取り込めます。

README は、最初の run は短い時間（max_hours: 4〜8）で試すことを勧めています。まず --dry-run で、何が書き込まれるかを確認してください。

整理・考え方

比べる 4 つの方式を分けておく

以降、番号と名前をセットで書きます。順序も、この順で固定します。

項目	⓪ 素の Coding Agent（基準）	① 対話型 Vibe Coding	② Prompt 駆動	③ Enterprise App Build Kit（EABK）
開発の形	Coding Agent に、その都度、短い Prompt だけを入れる。仕様の正本も、手順書も、独自の仕組みも持たない	人が細かく指示を重ねる対話型。実態は「⓪ 素の Coding Agent を、仕様の正本なしに、254 回積み重ねたもの」に近い	仕様駆動の自律実行。要求定義の Prompt（約 47KB）→ 承認 → 実装の Prompt（約 42KB）	進行役、作業役、skills、hooks、決定的スクリプト。`/build` を 1 回入力すると、要求定義 → 独立監査 → 計画 → System Test の先行設計 → 並行実装 → 統合 → 最終監査までを、人の介入なしで進める
依頼の文面	1 文〜数文	254 回の短い指示	約 47KB と約 42KB の Prompt	`/build` ＋依頼。手順書（約 100KB）は skills にあり、必要なときだけ読む
モデル	Opus 5.5 / Sonnet 5.5	15 通り以上	Opus 5.5（effort high）＋ gpt-5.6-luna	Opus 5.5（進行役）＋ Sonnet 5.5（作業役 119 体）
要求の管理	なし（依頼文と、リポジトリの中身だけ）	要求定義書を 29 回改訂。要求 ID なし	FR・NFR・AC に ID を付ける	要求定義書＋カタログ＋ ID 台帳＋ System Test 台帳。ID はスクリプトで採番
合否の判定	エージェントの申告	人の確認と CI	verify の終了コード、CI	verify、canary、System Test。hook で強制

⓪ 素の Coding Agent と ① 対話型 Vibe Coding の違いは、Prompt の数ではなく単位です。
⓪ 素の Coding Agent は「1 つのタスクを 1〜数回の Prompt で終える」方式、① 対話型 Vibe Coding は「プロジェクト全体を、仕様を固めないまま Prompt の積み重ねで進める」方式です。

なお、① 対話型 Vibe Coding は、私が当時「HVE」と呼んでいた期間のものですが、HVE v1 のフレームワークも DAG のオーケストレータも、実際には呼び出していません。

4 つの問題と、5 つの観点を対応づけておく

「何が一番よいか」を 1 つの軸で決めると、答えが偏ります。そこで、評価の観点を次の 5 つに分け、背景の 4 つの問題と対応づけました。以降の節は、この対応に沿って並べます。

観点	何を見るか	対応する問題	見る実験
(A) 短い実行時間	依頼から完了までの時間	停止	E-0、E-4、完走の再計測
(B) コードの品質	受入基準の充足、テスト、静的解析	—	E-2
(C) 最小の Token	AI クレジット、充足点あたりの費用	—	E-1、E-4、正規化
(D) Enterprise で使える運用	人の Prompt の回数、再開、衝突の検出、追跡	繰り返し、停止	Prompt の分類、E-1、E-4、E-5、完走の再計測
(E) ビジネスとの整合	範囲、矛盾、目的との対応	ずれ、矛盾	E-1、E-3

(E) は、最初の採点にはありませんでした。私自身の問題意識を評価に入れるために、あとから加えました。

時間と費用の指標を分けておく

資料によって、時間の定義が違います。

総待ち時間: 人の Prompt の入力から、最後の処理の終了までの合計。
稼働時間: エージェントのターンの開始から終了までを重ねずに合算した時間。人の待ちを含まない。
壁時計: Prompt の投入から CLI の終了まで。

定義の違う値どうしの比は取りません。比を示すときは、定義を併記します。
費用は AI クレジット（ログの totalNanoAiu ÷ 10⁹。1 AI クレジット＝ 0.01 USD とみなした目安）で示します。

さらに、方式どうしを比べるために、受入基準の充足点を使いました。
ドラフトの受入基準 AC-001〜AC-050 を 1 件あたり 0〜1 点で採点し、合計を 0〜50 点とします。これは「実装が存在し、テストで確かめられているか」を測るもので、UI の使いやすさや、実際の AI 呼び出しの正しさは含みません。

検証

1. 繰り返しと停止: ① 対話型 Vibe Coding の Prompt を数える

まず、利用者としての実感（同じ Prompt を何度も入れる、そのたびに止まる）が、数字で裏付けられるのかを確かめました。

① 対話型 Vibe Coding（32 日間）の Prompt を、VS Code Chat と Copilot CLI の履歴から 285 件抽出しました。
このうち 66 件はターミナルの完了通知の自動注入なので除き、人が入力した 219 件を、評価者 2 体が互いの結果を見ずに 1 件ずつ分類しました。

分類	件数	割合	代表例
止まった作業の再開・続行の指示	93	42.5%	「@agent Try Again」22 回、「残作業をリストアップしてください」12 回、「全てのタスクを実行をしてください…」11 回
エラーで止まったジョブへの対処	18	8.2%	「Autopilotで発生しているエラーの根本原因を調査してください…」9 回
要求・範囲の変更	26	11.9%	「[設問別得点]は、削除してください」
ビジネスの意図からのずれ・不整合の指摘	8	3.7%	「要求定義に誤りがあると思います」
レビュー・検証の依頼	22	10.0%	敵対的レビュアーとしての振る舞いの依頼 9 回
ビルド・リリース・運用	26	11.9%	—
質問・説明・文書	21	9.6%	—
不具合の修正・その他	5	2.3%	—

表の件数は 1 人目の評価者のものです。9 分類の一致率は 90.0%（Cohen の κ=0.87）でした。

観測したことです。

人の入力の **50.7%（111 件）が「止まったジョブの再開」と「エラーで止まったジョブへの対処」**でした（2 人目の評価者では 47.5%）。
人の入力の 43.8%（96 件）は、以前とほぼ同じ文面の打ち直しでした（2 人目の評価者では 44.7%）。
「@agent Try Again」22 件は UI の再実行に近い操作です。これを除くと、再開・エラー対処は 45.2%、打ち直しは 38.1% です。
要求定義書は 29 回改訂され、文字数は 5.3 万 → 2.4 万 → 14.1 万と大きく揺れました。

そこから考えたことです。
人の入力の約半分は、「開発を前に進める判断」ではなく、「止まったものを動かす作業」でした。
⓪ 素の Coding Agent を、仕様の正本なしにアプリ全体へ積み重ねると、こうなると考えています。
なお、評価者は 2 体とも同じ系統のモデルなので、人が分類した場合と一致するかは確認していません。

2. 追加実験の設計

同じドラフト要求定義書（177KB、受入基準 50 件）を使い、6 つの実験を計画しました。実際には、計画より縮小したものがあります。

実験	目的	計画との差
E-0	⓪ 素の Coding Agent を同じアプリで測る	空のリポジトリと既存コード、Opus 5.5 と Sonnet 5.5 の 4 条件（各 n=1）
E-1	同じ出発点で ② Prompt 駆動と ③ EABK を走らせる	各 1 回。② の effort を変える条件は未実施。リモートと CI は作らず未適用
E-2	成果物の品質を結果で比べる	E2E の隠しテストは、技術も API も成果物ごとに違うため作れなかった。受入基準の盲検採点、ビルド・全テスト、CodeQL、.NET アナライザーで代えた
E-3	要求定義書に入れた 10 件の矛盾の検出	⓪ 素の Coding Agent、② Prompt 駆動（要求定義だけ）、③ EABK（要求定義と監査だけ）。監査役 2 通り
E-4	小さな変更を ⓪ 素の Coding Agent と ③ EABK で行う	計画の 20 件を 6 件に減らした
E-5	③ EABK の部品を 1 つずつ外す	reviewer と、独立監査・最終監査の除去だけ。canary の除去は未実施

3. 使用した依頼文（原文）

実験で使った依頼文は、すべて原文のままです。長いので折りたたんでいます。ファイルパスだけ省略しました。

E-0 と E-3 の ⓪ 素の Coding Agent の依頼文

要求定義書のドラフト 【ファイルパス省略】 のアプリケーションを実装してください。私は途中で応答しません。最後まで完成させてください。1 回のツール呼び出しで書き込む内容は 300 行以内にしてください。

E-1 の ③ EABK の依頼文

/build
<request>
ドラフト要求定義書 【ファイルパス省略】 を toolkit 書式に合わせ、アプリを実装する。作業役は sonnet-5.5/medium
</request>
<run_options>
max_hours: 4
approval_policy: 安全範囲は推奨どおり
parallel_workers: 3
scope: 承認済みすべて
git_push: しない
deploy: しない
external_write: しない
paid_services: 使わない
external_exposure: 公開しない
</run_options>

E-1 の ② Prompt 駆動の人の Prompt（大きな Prompt 2 本を除く）

E-1 の ② Prompt 駆動は、元の実行と同じ人の Prompt の並びです（言語の指定と説明の依頼は除く）。
大きな Prompt 2 本（要求定義用の約 47KB と、実装用の約 42KB）は、ここには載せていません【要確認：公開してよい範囲】。その間に入れた人の Prompt は次のとおりです。

未回答の質問票は、最良と考える選択肢を採用してください。要求定義書を更新してください。

承認待ちは全て承認します。

残る項目は全て: 除外します。やりません。

E-3 の ③ EABK の依頼文

上の /build の <request> を次のようにし、max_hours を 1、scope を「なし」にしたものです。

ドラフト要求定義書 【ファイルパス省略】 を toolkit 書式に合わせる。今回は要求定義と監査だけを行い、実装はしない。

4. E-0: ⓪ 素の Coding Agent を同じアプリで測る（時間・費用）

条件	時間	AI クレジット	成果物	自動テスト	受入基準の充足（盲検）	エージェントの申告
⓪ 素の Coding Agent（Sonnet 5.5・空）	7.5 分	36.5	C#・WinForms、3 ファイル・394 行	なし	16.5%	一部だけ実装、と正直に申告して終了
⓪ 素の Coding Agent（Opus 5.5・空）	28.9 分	395.9	C#・WPF、19 ファイル・2,195 行	16/16 合格	51.0%	実装した。実際の Copilot 呼び出しとログインは未確認
⓪ 素の Coding Agent（Opus 5.5・既存コード）	27.9 分	98.3	8 行の変更	2,107/2,111	99.0%（ほぼ既存コードの値）	全テスト実行中に待機上限（600 秒）で終了。完了の申告なし
⓪ 素の Coding Agent（Sonnet 5.5・既存コード）	35.4 分	49.4	変更なし	2,108/2,111	99.0%（既存コードと同一）	既に実装済みのため変更していない。全体の照合はしていない

観測したことです。

数分〜30 分、数十〜約 400 AI クレジットで終わりました。時間と費用では、4 方式で最小です。
ただし、空のリポジトリからは、1 回でアプリを完成させませんでした。
Sonnet は早々に打ち切り、そのことを正直に申告しました。
Opus は受入基準の約半分（51%）の時点で、「完了」と申告しました。
既存コードがあると、ドラフトとの差分をほとんど見つけませんでした。

そこから考えたことです。177KB の要求定義書は、⓪ 素の Coding Agent の 1 回の実行で扱える範囲を超えていたのだと考えています。
外部の採点がないと、⓪ 素の Coding Agent の完成度は見誤りやすい、というのが私の受け取り方です。

5. E-1: 同じ出発点で ② Prompt 駆動と ③ EABK を走らせる（範囲と繰り返し）

指標	② Prompt 駆動	③ EABK
人の Prompt	5 回	1 回（`/build`）
時間（壁時計）	42.1 分	71.4 分
AI クレジット	2,225.7	1,321.6
終わり方	「依頼は完了していません」。verify は失敗。テストを弱めずに終了	「全件完了」。verify --strict 合格、System Test 4/4
受入基準の充足（盲検）	10.0%	48.0%

観測したことです。

② Prompt 駆動は、承認済みの 156 件の要求のうち、7 件（と一部 4 件）しか実装せず、未完了を正直に報告しました。
③ EABK は、人の Prompt 1 回で止まらずに進み、自分の範囲では「全件完了」と報告しました。
ただし、③ EABK は 1,297 行のドラフトを承認済み 26 件の要求にまとめ、残りを計画に入れていませんでした。受入基準で見ると、充足は 48% です。
同じツールキットでも、元の実行（90 項目）とは範囲の決め方が大きく違いました。

③ EABK の「全件完了」は、「ドラフトを全部作った」ではなく「自分で縮めた範囲を作った」という意味でした。 これは、実験をやってみて初めて気づいたことです。③ EABK の弱点として、後ろの考察で扱います。

6. E-2: 成果物の品質を結果で比べる

10 の成果物を匿名化し、ツールキットの痕跡を消して、3 体の採点役が静的に採点しました。あわせて、ビルド、全テスト、CodeQL 2.27.2 を実行しています。

成果物	全テストの結果	受入基準の充足
⓪ 素の Coding Agent（Sonnet・空）	テストなし	16.5%
⓪ 素の Coding Agent（Opus・空）	16/16	51.0%
② Prompt 駆動（空）	33/33	10.0%
③ EABK（空）	91/91（1 件スキップ）	48.0%
③ EABK 元の実行（51/90 項目で打ち切り）	636/636	75.0%（採点役により 61.5〜75%）
③ EABK 完走した成果物（106/106 項目）	1,096/1,096	98.0%

観測したことです。

CodeQL の指摘は、10 の成果物すべてで 0 件でした。
空のリポジトリからの 1 回の実行では、⓪ 素の Coding Agent（Opus）の 51% と、③ EABK の 48% に差はありませんでした。
③ EABK が上回ったのは、テストの量（テスト行／本体行が、③ EABK は 0.51、⓪ 素の Coding Agent（Opus）は 0.08）と、申告と実態の一致でした。
採点役の違いによるずれは、同じ成果物で最大 13.5 ポイントありました。

そこから考えたことです。
「③ EABK のコードは ⓪ 素の Coding Agent より品質が高い」は、結果の品質では確かめられませんでした。CodeQL が全件 0 件だったのも、このアプリ（ローカルのデスクトップアプリ）の攻撃面が小さいことの反映かもしれず、方式の安全性の差とは言えません。

7. E-3: 要求定義書の矛盾の検出（矛盾とずれ）

要求定義書に 10 件の矛盾を入れ、答えを採点まで非公開にして比べました。

矛盾	⓪ 素の Coding Agent（Sonnet）	② Prompt 駆動（要求定義の Prompt）	③ EABK（監査役 Opus）	③ EABK（監査役 gpt-5.5）
検出し、成果物に記録した	0	8	2	2
指摘せず、どちらかに決めた	3	0	4	4
見逃した	7	2	4	4

観測したことです。

⓪ 素の Coding Agent は矛盾を 1 件も指摘せず、誤った値のうち 4 件をそのまま実装しました。
② Prompt 駆動は、8 件を矛盾の表と質問票として要求定義書に記録しました。
③ EABK は 2 件だけの検出でした。細かい値をドラフトへの参照のままにする書き方をしたため、ドラフトの中の矛盾が監査の対象になりませんでした。
監査役のモデルを変えても、検出は同じでした。

「別の文脈の監査役」を置くだけでは、矛盾の検出は保証されませんでした。 何を監査の対象にするかが、監査役のモデルより効いていたと考えています。ただし n=1 です。
なお、「監査役 sonnet-5.5」の条件は、モデル指定が守られず、実際には Opus 5.5 で動いていました。

8. E-4: 小さな変更（1 文で言える変更 6 件）

次の 6 件の変更を、⓪ 素の Coding Agent（Sonnet 5.5）と ③ EABK（/build、max_hours: 1）で行いました。
⓪ 素の Coding Agent の依頼文は「（変更の依頼）私は途中で応答しません。最後まで完成させてください。」の形です。③ EABK は、上の /build の <request> を変更の依頼に置き換えたものです。

ID	変更の依頼（原文）
S01	LogPolicy の MaxValueLength を 120 から 200 文字に変更してください。
S02	--input に .xlsx 以外のファイルが指定されたときは LaunchException を投げるようにしてください。
S03	LogPolicy の許可フィールドに "definitionId" を追加してください。
S04	NormalScoring.Normalize で raw が NaN の場合は 0 を返すようにして、EvaluatorValue が有限値のままになるようにしてください。
S05	OutputPathPlanner.EffectiveDirectory で出力先の上書き指定の前後の空白を取り除き、空白だけの場合は null と同じく入力ファイル隣の "result" を使うようにしてください。
S06	StudentAnswerText で、補助列が主回答列または他の補助列と（大文字小文字を区別せず）同じ場合は重複して表示しないようにしてください。

変更ごとに、実装役に見せない隠しテストを用意しました。基のコードで失敗し、参照の実装で成功することは、事前に確かめています。

指標	⓪ 素の Coding Agent（Sonnet 5.5）	③ EABK	③ EABK / ⓪ 素の Coding Agent
隠しテストの合格	6/6	6/6	—
既存の単体テストの退行	0	0	—
平均の時間	3.1 分（1.3〜4.8）	47.6 分（36.6〜62.4）	約 15 倍
平均の AI クレジット	8.1	252.0	約 31 倍
更新した管理文書（平均）	0	5.3	—
依頼の問題点の指摘	0/6	S03 で 1 件	—

観測したことです。

結果の正しさは、⓪ 素の Coding Agent も ③ EABK も同じでした。
S03 は、既存のセキュリティ要求（設定の実内容をログに入れない）と衝突し得る依頼です。⓪ 素の Coding Agent は 77 秒で黙って実装しました。③ EABK は、E-4 と E-5 の 3 回とも、衝突を質問票か監査の指摘として記録し、1 回は実装を止めて利用者の判断を求めました。

そこから考えたことです。
小さな変更では、③ EABK の追加費用（約 30 倍）は、結果の正しさを買っていません。買っているのは、記録の更新と、既存の要求（特にセキュリティ）との衝突の検出です。
逆に言えば、衝突しない小さな変更まで ③ EABK の全工程で処理するのは、過剰です。この点が、後ろの「振り分け」の議論の出発点です。

9. E-5: ③ EABK の部品を外してみる

E-4 の S01〜S03 で、③ EABK の部品を外しました。

条件	隠しテストの合格	平均の時間	平均の AI クレジット
③ EABK そのまま	3/3	42.3 分	277.7
③ EABK（reviewer なし）	3/3	37.1 分	206.1（−26%）
③ EABK（独立監査・最終監査なし）	2/3	35.1 分	140.1（−50%）

監査を外した条件の 1 件は、既存のセキュリティ要求との衝突を理由に BLOCKED になったものです。隠しテストとしては不合格ですが、判断としては妥当だったと考えています。
n=3 で、同じ条件でも 29〜43 分とばらつきました。差より、ばらつきの方が大きい可能性があります。

10. 期待と違った結果: ③ EABK のモデル指定が守られなかった

③ EABK の 15 回の実行のうち、作業役と監査役のモデルを設定どおりに使えたのは 5 回だけでした。残りの 10 回は、どちらも進行役と同じ Opus 5.5 で動いていました。
モデルの指定を設定ファイルに書いただけでは、費用の設計も、監査役を別系統にする設計も、保証されません。 これは、私が作ったツールキット側の欠陥です。

11. 打ち切られていた ③ EABK を完走させる（停止）

元の実行は、③ EABK 自身が止まったのではなく、私が途中で打ち切ったものでした（51/90 項目）。
そこで、同じ run を、打ち切りの時点から続けました。依頼は毎回 1 文です。

タスクを再開してください。作業役は sonnet-5.5/medium

区間	壁時計	AI クレジット	終わり方
元の実行	553 分	11,193	私の打ち切り（51/90 項目）
再計測 1	85.7 分	837.1	進行役が、設定した AI クレジットの上限（20,000）を見て「残りが少ない」と判断し、32 項目を blocked にした（実際の使用は上限の 4%）
再計測 2	165.2 分	2,936.3	CLI の自動継続の上限（60 回）
再計測 3	151.9 分	1,792.2	CLI のバックグラウンド待機の上限（600 秒）
再計測 4	約 84 分	約 1,240（推定）	PC の停止
再計測 5	1.3 分	0	Opus 5.5 が CLI で使えなくなり、起動に失敗
再計測 6	118.5 分	257.0	全件完了
合計	1,158 分（19.3 時間）	約 18,300	—

PC の停止の約 26 時間は、稼働時間に含めていません。

指標	打ち切り時点	完走
作業項目	51/90	106/106（進行役が 16 項目を追加）
全テスト	636/636	1,096/1,096
CodeQL の指摘	0	0
受入基準の充足（盲検）	75.0%	98.0%（2 人の採点役が同じ値）

観測したことです。

止まった 5 回の原因は、環境の上限 3 回、PC の停止 1 回、モデルの利用不可 1 回でした。ツールキットの設計や品質の問題ではありませんでした。
毎回、記録から 1 文の依頼で続きから進みました。
受入基準で 1 点未満だったのは、配布と文書の 3 件だけでした。
最後の約 2 時間は、Opus 5.5 が使えなくなったため、進行役が Sonnet 5.5 でした。元の実行と、完全に同じ構成ではありません。
再計測は 1 回です。

そこから考えたことです。
空のリポジトリから受入基準 98% に達したのは、今回の範囲では、完走した ③ EABK だけでした。同じツールキットでも、run によって到達点が 48%（71 分）と 98%（19.3 時間）に分かれています。範囲の決め方が違うためです。
また、③ EABK は、実行の上限を実際より厳しく解釈して、早めに止まることがありました。

12. 充足点 1 点あたりで正規化する（費用）

成果物	時間	AI クレジット	充足点（50 点満点）	AI クレジット / 点	分 / 点
⓪ 素の Coding Agent（Sonnet・空）	7.5 分	36.5	8.25	4.4	0.9
⓪ 素の Coding Agent（Opus・空）	28.9 分	395.9	25.5	15.5	1.1
② Prompt 駆動（空）	42.1 分	2,225.7	5.0	445.1	8.4
③ EABK（空）	71.4 分	1,321.6	24.0	55.1	3.0
参考: ③ EABK 完走	19.3 時間	約 18,300	49.0	約 373	23.6
参考: ① 対話型 Vibe Coding	143 時間 47 分（総待ち時間）	33,999 以上	49.5	687 以上	174

上の 4 行は、空のリポジトリからの 1 回の実行で、直接比べられます。参考の 2 行は、時間の定義と出発点が違います。

1 点あたりの AI クレジットは、⓪ Sonnet 4.4 ＜ ⓪ Opus 15.5 ＜ ③ EABK 55 ＜ ② Prompt 駆動 445 でした。
③ EABK は ② Prompt 駆動の約 1/8 ですが、⓪ Opus の約 3.5 倍です。
完走した ③ EABK は、① 対話型 Vibe Coding の約 1/7 の時間、約 0.5 倍の費用でした。ただし、① は 32 日間の人の待ちを含み、費用は下限です。

考察

1. 実測結果を、4 つの問題と 5 つの観点に並べ直す

ここまでの観測を、背景の問いに沿って 1 つの表にまとめます。

記号の凡例です。◎ は実測で確認、○ はおおむね良い、△ は一部だけ、✕ は問題が残った、を表します。

問題・観点	⓪ 素の Coding Agent	① 対話型 Vibe Coding	② Prompt 駆動	③ EABK
繰り返し（人の Prompt の回数）	小さな変更は ◎（1 回）。アプリ全体は ✕（1 回で終わらない）	✕ 人の入力の 43.8% が打ち直し	○ 5〜7 回	◎ 1 回（E-1）
停止	小さな変更は ◎（数分）。アプリ全体は ✕（途中で終了）	✕ 人の入力の 50.7% が再開・エラー対処	○ 判断の区切りで止まる	◎ 5 回止まっても 1 文の再開で続行
ずれ（範囲・目的）	✕ 51% で「完了」と申告	✕ 要求定義書を 29 回改訂	○ 未完了を正直に報告	△ 範囲を黙って縮め「全件完了」と報告
矛盾	✕ 検出 0/10	△ 人が気づいた分だけ	◎ 検出 8/10	△ 既存の要求との衝突は 3/3 回検出。ドラフト内の矛盾は 2/10
(A) 時間	◎ 最短	✕ 143 時間 47 分（総待ち時間）	○ 42.1 分（E-1）	△ 71.4 分（E-1）、完走は 19.3 時間
(B) 品質（結果）	△ 空から 16.5〜51%	○ 99%（実利用あり）	✕ 空から 10%	◎ 完走で 98%（1,096 テスト合格）
(C) 費用	◎ 充足点あたり 4.4〜15.5	✕ 687 以上	✕ 445	△ 55（E-1）〜約 373（完走）
(D) 運用（追跡・衝突の検出・再開）	✕ 追跡なし。衝突を黙って実装	✕ 要求 ID なし	○ ID と verify	◎ ID、hook、System Test、再開

表を縦に読むと、⓪ 素の Coding Agent は「速い・安い」を、③ EABK は「止まらない・衝突を見つける・追跡できる」を持っています。両者は、同じ軸の上位互換ではなく、補い合う関係です。

2. なぜ ⓪ 素の Coding Agent だけでは、Enterprise に足りないのか

アプリ規模でも小さな変更でも、⓪ 素の Coding Agent に共通して欠けていたのは、自分の結果を外から確かめる仕組みでした。

51% で「完了」と申告した（E-0）。
矛盾を 1 件も指摘しなかった（E-3）。
既存のセキュリティ要求と衝突する依頼を、77 秒で黙って実装した（E-4 の S03）。

そして、これを人がアプリ全体に繰り返すと、① 対話型 Vibe Coding の姿になります。人の入力の約半分が再開で、要求定義書は 29 回改訂されました。
速さは、⓪ 素の Coding Agent の長所です。しかし Enterprise では、速さだけでなく、衝突の検出、追跡、再開が要ると考えています。

3. なぜ ③ EABK を標準にするのか。そして、なぜ「振り分け」なのか

では、③ EABK を全部の依頼に使えばよいのでしょうか。実測は、そうではないことを示しました。

小さな変更では、結果の正しさは ⓪ 素の Coding Agent と同じで、③ EABK は約 15 倍の時間と約 31 倍の AI クレジットでした（E-4）。
③ EABK の部品を外すと、AI クレジットは 26〜50% 減りました（E-5）。

つまり、依頼の大きさによって、最適な方式が違うのです。ここで私の設計の立場は、次のとおりです。

Enterprise の Vibe Coding の入口は、1 つにしたい。その入口が ③ EABK であり、③ EABK が、依頼の大きさと影響範囲を見て、小さな変更は ⓪ 素の Coding Agent へ自動的に振り分ける。

人が「これは ⓪ 素の Coding Agent で足りるか、③ EABK を使うか」を毎回判断すると、その判断が新しい負担とミスの原因になります。
これは、① 対話型 Vibe Coding で人が担っていた「止まったものを動かす」作業を、仕組みに移す考え方と同じ方向だと考えています。

この振り分けは、今回の実験では測っていません。

事実として確かめたこと: ⓪ 素の Coding Agent と ③ EABK を、それぞれ単独で動かした結果（E-4、E-5）。
私の設計の立場: ③ EABK が ⓪ 素の Coding Agent へ自動的に振り分けること。README には、conductor が「小さな作業は自分で行う」という記載がありますが、これが ⓪ 素の Coding Agent への振り分けと同じ動きかは、確認していません。
確認していないこと: 振り分けの判断の精度、振り分け後の合計の費用と時間、衝突する変更（S03 のような依頼）を、振り分けの時点で見逃さないか【要確認：振り分け機能の実装状況と実測】。

振り分けの基準の案は、次のとおりです（実測から導いた案で、基準自体の精度は未検証です）。

基準	⓪ 素の Coding Agent へ振り分ける	③ EABK の全工程で扱う
差分の説明	1 文で説明できる	要求定義書の節で説明するもの
影響する要求	0〜1 件で、既存の要求の範囲内	数十件以上、または未確定を含む
既存のセキュリティ・プライバシーの要求	触れない	触れる（衝突の検出を任せる）
共通部品・契約（API、スキーマ）の変更	なし	あり
想定の実行時間	〜1 時間	8 時間超、無人の長時間実行
規制・監査の要件	なし	あり

特に、「既存のセキュリティ・プライバシーの要求に触れない」を、振り分けの条件の最優先にしたいと考えています。E-4 の S03 で、⓪ 素の Coding Agent だけが、この衝突を黙って通したからです。

4. ② Prompt 駆動は、独立した選択肢ではなく、③ EABK に取り込むものと考える

当初は、「要求が確定した中規模の変更は ② Prompt 駆動」という 3 つの使い分けを考えていました。しかし、実測を並べ直すと、次の理由で、独立した選択肢にしない方がよいと考えるようになりました。

E-1 で、空のリポジトリから ② Prompt 駆動は受入基準の 10% でした。
② Prompt 駆動が優れていたのは、矛盾の検出（8/10）と、未完了の正直な報告です。これは、方式全体ではなく、要求定義の Prompt に含まれる監査の観点の強さです。

そのため、入口を増やすのではなく、② Prompt 駆動の監査の観点を ③ EABK の要求定義と監査に取り込みたいと考えています。

5. ③ EABK の弱点と、標準にする前に直すこと

③ EABK を標準にするのは、弱点がないからではありません。実験から、直すべき点が見えました。

弱点	根拠	直し方の案
モデルの指定が守られない	15 回中 10 回で、設定どおりに動かなかった（E-1、E-3、E-4、E-5）	設定ファイルの表ではなく、各 agent の定義か呼び出しの引数で強制する。実際のモデル別の件数を報告に出す
範囲を黙って縮める	受入基準の約半分しか要求にせず「全件完了」と報告した（E-1）	報告の 1 行目に「依頼の受入基準のうち、要求にした割合」と、要求にしなかったものの一覧を出す
ドラフトの矛盾を監査しない	検出 2/10（E-3）	監査役に、書き起こした要求だけでなく、参照しているドラフトの本文も監査させる
事業目的との対応が弱い	ずれと矛盾は、② Prompt 駆動の方が強かった	要求定義書の先頭に「事業の目的・利用者・成功指標」を置き、各要求との対応を毎回確かめる
実行の上限を厳しく解釈して止まる	上限の 4% の使用で「残りが少ない」と判断した（完走の再計測）	開始時に上限を明示し、「上限の 85% までは続ける」ことを指示する
中心の機能を実環境で確かめていない	すべての自動実行で、Copilot による答案の評価は偽の AI（スタブ）で試しただけ	最後に実環境で 1 回通す。認証が要るなら、BLOCKED として人に返す

「止まらずに完了した」ことと、「ビジネスの目的を果たすアプリができた」ことは、別です。 この実環境での確認は、どの方式でも残っています。

6. 加重スコアは、重みで首位が変わる

採点の対象は、アプリ規模の開発です。重みは、(E) を最も重くしました。私の問題意識の中心だからです。

重みの置き方	⓪ 素の Coding Agent	① 対話型 Vibe Coding	② Prompt 駆動	③ EABK	首位
本書の重み（A20・B20・C15・D20・E25）	2.95	1.70	3.38	3.68	③ EABK
5 観点を均等	3.10	1.65	3.30	3.70	③ EABK
時間だけ	5.00	1.00	4.00	3.50	⓪ 素の Coding Agent
ビジネスとの整合を最重視（E 50%）	2.50	1.78	3.56	3.44	② Prompt 駆動

点数は私が付けたもので、客観的な測定値ではありません。重みを変えると首位が変わる、という見方で読むのが適切だと考えています。
この表が示しているのは、「時間だけ見れば ⓪ 素の Coding Agent、整合を最重視すれば ② Prompt 駆動」です。どの軸でも一貫して上位なのは ③ EABK で、それが標準の入口に ③ EABK を置く理由の 1 つです。

今回の結果から言えないこと

統計的な有意差。各条件の試行は 1〜6 回です。
③ EABK が ⓪ 素の Coding Agent へ自動的に振り分けること、その精度、振り分け後の合計の費用と時間。 これは私の設計の立場で、今回は実測していません【要確認：振り分け機能の実測】。
⓪ 素の Coding Agent に「続けて」を繰り返して完成させた場合の総費用と、ドリフトの大きさ。① 対話型 Vibe Coding は実際の利用ログで、条件の揃った実験ではありません。
実際の Copilot による答案の評価が、どの方式の成果物で正しく動くか。
出発点のコードの効果と、方式の効果の完全な切り分け。既存コードを引き継いだ成果物の受入基準 99% は、ほぼそのコードの値です。
受入基準の採点は静的な確認です。UI の操作と、実際の AI 呼び出しは試していません。
他のアプリ、他の規模、他のモデルへの一般化。今回のアプリは、ローカルのデスクトップアプリです。
採点役が同じ系統のモデルであることによる偏りの大きさ。成果物の匿名化と、決定的な検査（ビルド、テスト、CodeQL、隠しテスト）で、影響を小さくしようとしました。
完走の再計測の再現性。1 回だけで、再計測 4 の AI クレジットは推定です。
モデルの進歩の影響。⓪ 素の Coding Agent の守備範囲は広がり続けています。③ EABK の部品の一部は、不要になる可能性があります。

ここまでの整理

良かった点

小さな変更で、⓪ 素の Coding Agent と ③ EABK の結果が同じだと、隠しテストで確かめられた。
③ EABK は、人の Prompt 1 回で止まらずに進み、止まっても 1 文で続きから進んだ。
完走した ③ EABK は、空のリポジトリから、受入基準 98%・1,096 テスト合格に達した。
既存のセキュリティ要求との衝突を、③ EABK だけが毎回検出した。

注意したい点

⓪ 素の Coding Agent は、アプリ規模では 1 回で完成せず、完成度を過大に申告することがある。
③ EABK は、範囲を黙って縮めて「全件完了」と報告することがある。
③ EABK のモデル指定は、設定ファイルだけでは守られなかった。
矛盾の検出は、② Prompt 駆動の大きな Prompt の方が強かった。

今回の限界

各条件が 1〜6 回で、ばらつきが差より大きい可能性がある。
私が開発したツールキットを、AI が実験し、同じ系統の AI が採点した。
振り分け機能と、中心の機能の実環境での動作を、試していない。
完走までに、約 26 時間の PC 停止と、モデルの利用不可を挟んでいる。

まとめ

私の立場は、「Enterprise の Vibe Coding では、EABK を標準の入口にする。小さな変更は EABK が素の Coding Agent へ自動的に振り分けるので、速さを捨てずに、衝突の検出・追跡・再開を得られる」です。

この立場の根拠は、次のとおりです。

問い	実測で言えたこと	方式
速く安く済ませたい小さな変更は	結果は同じで、約 1/15 の時間・約 1/31 の費用	⓪ 素の Coding Agent
衝突、範囲、追跡、再開は	衝突を 3/3 回検出、人の Prompt 1 回、1 文で再開、完走で 98%	③ EABK
矛盾の検出は	8/10 で最も強い	② Prompt 駆動（観点を ③ EABK に取り込む）
積み重ねるとどうなるか	人の入力の約半分が再開、要求定義書を 29 回改訂	① 対話型 Vibe Coding（避けたい形）

これは標準でもランキングでもなく、次に試す順番です。条件が違えば、結論は変わりうると考えています。

次にやることは、次の 3 つです。

範囲の報告、ドラフトの監査、事業目的の監査、中心機能の実環境での確認、モデル指定の強制を入れた ③ EABK で、同じ実験をやり直す。
小さな変更と大きな変更が混ざった依頼を ③ EABK に投げ、⓪ 素の Coding Agent への振り分けの精度と、合計の費用・時間を測る。
⓪ 素の Coding Agent に「続けて」を繰り返す実験で、① 対話型 Vibe Coding の形の総費用とドリフトを、同じアプリで測る。

速さは ⓪ 素の Coding Agent が持ち、守りは ③ EABK が持つ。その切り替えを人ではなく仕組みに任せられるかが、Enterprise の Vibe Coding の鍵だと考えています。

参考資料

ID	資料名	確認した範囲
R1	4 方式の比較レポート（社内の作業記録。非公開）	本記事の数値は、すべてこのレポートの記載による【要確認：公開の可否】
R2	追加実験 E-0〜E-5 の入力・成果物・採点結果（実行した PC 内。公開先なし）	本記事の公開時点では、第三者が再現できる状態にはない
R3	dahatake/HypervelocityEngineering（EABK の README）	確認日 2026-10-13。概要、エージェント、工程、hook と verify、データの置き場所、導入方法の節。実験時の版との差は未確認