背景
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 行を実行します。
irm https://raw.githubusercontent.com/dahatake/HypervelocityEngineering/main/tools/install.ps1 | iex
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 を実行しています。
| 成果物 | 全テストの結果 | CodeQL の指摘 | 受入基準の充足 |
|---|---|---|---|
| ⓪ 素の Coding Agent（Sonnet・空） | テストなし | 0 | 16.5% |
| ⓪ 素の Coding Agent（Opus・空） | 16/16 | 0 | 51.0% |
| ② Prompt 駆動（空） | 33/33 | 0 | 10.0% |
| ③ EABK（空） | 91/91（1 件スキップ） | 0 | 48.0% |
| ③ EABK 元の実行（51/90 項目で打ち切り） | 636/636 | 0 | 75.0%（採点役により 61.5〜75%） |
| ③ EABK 完走した成果物（106/106 項目） | 1,096/1,096 | 0 | 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、データの置き場所、導入方法の節。実験時の版との差は未確認 |