自作オーケストレータ（HVE）をやめて「3 つの Prompt + GitHub Copilot」で企業向けの大規模分散アプリは作れるのか

背景

ここしばらく、私は HVE（Hypervelocity Engineering） という仕組みを作ってきました。

GitHub Copilot に、要求定義・設計・実装・ドキュメント生成を Workflow と DAG で段階的に実行させる、いわば「自作のオーケストレータ」です。

作り始めた頃は、Copilot 本体に「途中で止まらずに続ける」「タスクを分けて並列に流す」「計画を人が承認する」といった仕組みがほとんどありませんでした。なので、外側で全部面倒を見る必要があったわけです。

ところが最近、正直なところ違和感が大きくなってきました。

Copilot 本体に Autopilot、/fleet、hooks、cloud agent の plan 承認、Automations が入ってきた
自分で測った結果、HVE の DAG 部分を切り出した ATG（Autonomous Task Graph）が、単一 Prompt より良い結果を一度も出さなかった
それなのに、HVE 本体は Python だけで十数万行あり、保守の手間は確実に増えている

「これ、自分で作り続ける意味あるんだっけ？」と。

そこで、HVE の開発・利用をやめて、次の 5 段階で企業向けの大規模分散アプリを作る方針を検討しました。

要求定義のドラフトを Microsoft 365 Copilot / Work IQ で作る
ドラフトを Prompt P-RD（RequirementDefinition作成）で要求定義にする
Prompt P-FR（RD-FR_Prompt）を Agile の Wave ごとに繰り返し実行する
- Wave 1 はローカルだけ
- Wave 2 で Azure・スマホ・Power Platform へ展開
Prompt P-ST（SystemTest-Run）でシステムテストを繰り返し実行する
人の作業は UAT だけにして、その都度 3 と 4 を回す

前提として、GitHub Copilot が Plugin / MCP で使うクラウドサービスへの認証・認可は済んでいるものとします。

この記事は、その方針が本当に妥当なのかを、過去の実測・公式文書・外部の論文で検証した結果をまとめたものです。

注意点 / 前提

最初に、いくつか断っておきます。

この記事は個人の見解です。 所属組織の公式見解ではありません。
この記事のための新しい実験はしていません。 数値は、私が過去に行った検証の実測値か、手元に残っていた Copilot のセッション履歴と Git 履歴を集計した値か、外部資料に書かれている値です。
過去の実測は 3 タスク・各 n=2〜3・新規作成だけ と、規模がかなり小さいです。企業の大規模分散アプリにそのまま一般化できるものではありません。
検討の結果改訂した 3 つの Prompt は、まだ実際の業務アプリで流していません。プロダクションでそのまま使うことはおすすめしません。
Copilot の機能・モデル名・既定値は、2026-10-03 時点で公式文書を確認したものです。変わる前提で読んでください。
過去に作ったアプリは、名前・業種・顧客が特定されないように「アプリ A〜D」「アプリ X」と書き、概要だけを残しています。

文中では、次の 3 つを書き分けています。

事実: 資料・実測・公式文書で確認したこと
推論: 事実からの私の判断
未検証: まだ確認できていないこと

なお、この検討は次の流れで進めました。

途中の検討として、まず「今の 3 つの Prompt をそのまま使う 5 段階」を評価し、5 つの不足（G1〜G5）を洗い出した
その不足への対応方針を決め、5 つすべてを 3 つの Prompt に反映した。外部の論文とベストプラクティスも根拠に加えた
「HVE で解決しようとしていた課題と、その対応」と「過去に開発していたアプリに費やした時間とトークン費用」を調べた
HVE を使って開発しようとしていたアプリ自体についても、同じ観点（時間、費用、到達点、問題）で調べた

この記事は、これらをまとめた最終的な結論です。

ここで一度、整理してみます

用語

用語	この記事での意味
HVE	私が作ってきた、Copilot を Workflow / DAG で段階実行させるフレームワーク
ATG	HVE の DAG 実行部分を独立させたもの。13 ファイル・2,354 行の Python
P-RD / P-FR / P-ST	要求定義作成 / 要求定義からの実装 / システムテストの 3 つの Prompt
Wave	Agile のイテレーションのように、少しずつ依頼する単位
catalog	`docs\catalog.md`。要求 ID → 実装 → テスト → API の短い対応表
mdq / cq	markdown-query / code-query。Markdown とコードを索引で引くローカル検索ツール

何が問題で、何が問題ではないか

実際に検討を進めると、論点がいくつか混ざっていることに気付きました。一度切り分けます。

問題ではなかったこと

オーケストレータのコード量や作りの良し悪し
- 律速は LLM の呼び出しと文脈の量で、エンジンのコード量ではありませんでした
単一 Prompt で中規模の実装を作り切れるか
- 条件付きですが、作り切れました（後述）

問題だったこと

合否を だれが 決めているのか（エージェントの自己申告になっていないか）
人の承認を どこに 残すのか
デプロイや課金を伴う作業を どの Prompt が 受け持つのか
生成したアプリの システムテスト をどうするのか
要求が増えたときに、要求定義と catalog が 破綻しないか

ここで大事なのは、「HVE が必要か」と「エージェントの外に決定的な仕組みが必要か」は別の問い だということです。

後者は必要です。でも、それは HVE でなくても、数百行のスクリプトと CI で用意できます。この記事の結論は、ほぼこの切り分けから出てきています。

結論から

一言でいうと

HVE の開発をやめる判断は妥当だと考えています（根拠あり）。

途中の検討では、「今の 3 つの Prompt をそのまま使う」だけでは企業向けの大規模分散アプリには足りない（条件付き）と判定し、5 つの不足を洗い出しました。

その 5 つすべてを 3 つの Prompt に反映 しました。Prompt を増やさず、HVE も使っていません。

残っている条件は、実際の業務アプリで確かめること だけです。

#	不足（途中の検討で判明）	重大度	理由（要点）	対応
G1	P-ST が生成アプリのシステムテストに使えない	Critical	P-ST と関連 Skill・台帳スクリプトは HVE 本体をテストするもので、生成アプリは対象外と明記されていた	P-ST の既定の対象を生成アプリにした（`test_target: app`）。受入基準から作る JSON のケース台帳、canary、増分実行、自動修正の上限、生成 AI 機能の評価テストを追加。HVE 本体のテストは `test_target: hve` で選べる
G2	Wave 2（Azure・スマホ・Power Platform）を受け持つ Prompt がない	Critical	P-FR は「デプロイ、有料サービスの呼び出し、git push をしない」と定めていた	P-FR に `<execution_options>` を追加。push、デプロイ、デプロイ先、有料サービス、予算、外部公開を選べるようにした。既定値はすべて「しない」
G3	合否をエージェントの自己申告だけで決めている	Major	過去の実測で、ATG は隠しテスト 258/564 の実装を「受理」した。外部研究でも自己修正の限界やテストの改変が報告されている	P-FR に検証スクリプト（ビルド、静的検査、全テスト、要求 ID の整合）と CI（GitHub Actions、CodeQL、依存関係の確認）を作らせ、完了を exit code で判定するようにした
G4	人の承認が UAT だけになっている	Major	P-RD の成果物は「最終候補版（未承認）」で AI 提案を含むのに、P-FR は BLOCKED 以外の MUST をすべて実装していた	P-RD に「承認依頼一覧」を出させ、P-FR は承認済みの要求と依頼原文で明示された要求だけを実装するようにした。承認済みの文面は実装の都合で変えさせない
G5	大規模化したときの要求定義と catalog の扱いが決まっていない	Major	要求定義も catalog も単一ファイル。過去には catalog が 28 ファイル・約 82 万バイトまで膨らみ、ID のずれが起きた	catalog は短い対応表のまま残し、詳細は mdq と cq の索引で補う。要求 ID を `FR-xxx`、`NFR-<区分>-xxx` にそろえ、1 要求 1 見出しにした。分割の規則（要求 150 件、300KB、境界 3 つ）を入れた

判定の内訳

問い	判定	主な根拠
HVE の開発・保守をやめてよいか	根拠あり（妥当）	ATG は 3 タスクのどれでも単一 Prompt を上回らず、時間は 1.7〜2.25 倍、コストは 2.49〜3.50 倍、品質は同じだった。HVE 独自の仕組みの多くは Copilot 本体の機能で置き換えられる。外部研究にも、単純な構成が複雑なエージェントに並ぶか上回る例がある。過去に作った 4 つのアプリは、どれも HVE を使っていなかった。記録のある期間だけでも、HVE まわり（HVE でのアプリ開発と HVE 本体）に使った AI の費用は、4 アプリの合計の約 1.39 倍だった
HVE で開発しようとしていたアプリは完成したか	完成していない（根拠あり）	14 のサブアプリからなる業務システムを HVE で作ろうとし、HVE の Workflow 実行だけで 85.6 時間・約 1,095 USD 相当を使ったが、システムテストの総合判定は「INCOMPLETE・BLOCKED」のままだった。規模の差があるので、HVE だけが原因とは言えない
HVE で解決しようとしていた課題に、今も Framework やアプリケーションが要るか	大半は不要（根拠あり）	10 の課題のうち 7 つは Copilot 本体の機能か運用の規則で済む。残る 3 つ（合否の判定、要件索引、予算）も、リポジトリごとの検証スクリプト・CI・持ち出せる索引ツール・予算の設定で済む
単一 Prompt で中〜大規模の実装を完成できるか	根拠あり（範囲付き）	要求定義 4,458〜9,908 文字の 2 タスクを 1 回の依頼で 100% 完成（隠しテスト 74/74、225/225）。モデル単独では難しいタスクでも、「300 行以内に分けて書く」の 1 文で完成率が 1/3 → 2/3 に上がった。この 1 文は P-FR に入っている
提示の 5 段階で企業向け大規模分散アプリを作れるか	条件付き	Prompt 上の不足（G1〜G5）は解消した。既存コードへの繰り返し変更、複数サービス、Wave 2 の展開、生成アプリのシステムテストの有効性は、まだ実測していない
人の作業を UAT だけにできるか	不可。ただし 2 点に集約できる	要求の承認、課金・公開を伴う展開の承認、PR のマージは、ツールの仕様上も統制上も人に残る。改訂した Prompt では「Wave の始めの承認」と「Wave の終わりの UAT とマージ」の 2 点に集約した

推奨

HVE の開発は止めます。 再利用できる資産（Skill、mdq と cq の導入キット、Prompt の知見、検証規約）だけを残します。
Prompt は 3 本のまま使います。 途中の検討で追加を考えた 3 本は、既存の 3 本に吸収しました。
合否はエージェントの外で決めます。 P-FR が作る検証スクリプトと CI がその役割を持ちます。必要に応じて hooks を足します。
最初の Wave で実地確認をします。 小さな業務アプリで Wave 1（ローカル）と Wave 2（dev 環境へのデプロイ）を 1 回ずつ通し、後述の U1〜U6 を測ります。

なぜそう考えるか

HVE の価値は「継続・並列・承認・安全ゲート・証跡」でした。そのほとんどが公式機能になった今、残る独自の価値は「決定的な検査」と「機械可読な要件索引」です。どちらも HVE である必要はありません。

実務への影響

チームが保守するものが、十数万行のオーケストレータから「3 本の Prompt + 数百行のスクリプトと CI 設定」に変わります。一方で、人の承認ポイントは消えません。ここを「AI に全部任せられる」と誤解すると、統制の面でかなり危ないです。

調べた範囲と方法

区分	対象	方法
提案された Prompt	P-RD（137 行）、P-FR（135 行）、P-ST（11 行）	全文を読んだ
過去の調査レポート	手元の調査レポート 120 件（ATG、DAG、長時間タスク、自律 Prompt、Harness、要件索引、モデル比較、Orchestrator レビュー、Work IQ、Managed Runtime など）	リポジトリから削除済みだったので、履歴から復元して読んだ。主要なものは本文を、敵対的レビューは判定だけを確認
直近の調査	不明 Issue の挙動分析、HVE のフォルダー構成、システムテスト計画の分析	結論部を読んだ
HVE 本体	README、Workflow 定義、モジュール構成、要求定義の見出し、システムテスト用 Skill と台帳スクリプト	棚卸しした
GitHub Copilot の現状	GitHub Docs と GitHub Changelog	一次資料の本文を取得。ブログなどの二次資料は根拠にしていない
外部の論文とベストプラクティス	査読論文、arXiv、Anthropic・OpenAI・METR・Chroma の技術文書、OWASP、NIST、ISO、Microsoft Learn、GitHub Docs、Playwright	本文か要旨を、私か調査用のサブエージェントが取得できたものだけを根拠にした
mdq / cq	両 Skill の仕様、CLI リファレンス、ID 抽出の実装、導入キットの README	仕様を読み、ID 抽出に新しい ID 形式を与えて動作を確かめた
過去に作ったアプリ	4 つのアプリのリポジトリの作業記録（作業中の一次情報）、配置記録、Git 履歴	実行計画・実行記録・分析レポートを読み、commit 数と活動日を数えた
Copilot のセッション履歴	手元に残っている Copilot のセッション履歴 2,086 件	作業フォルダーが各リポジトリのセッションを選び、稼働時間・AI の費用・Premium Request を集計した
HVE で開発しようとしていたアプリ X	設計の文書、ソースコード、システムテストの証跡、Git 履歴、GitHub の Issue と PR	範囲と到達点を読み、アプリと HVE 本体で Git 履歴を分けて数えた。セッション履歴を、HVE の Workflow 実行（アプリ開発）とそれ以外（HVE 本体）に分けて集計した

限界も書いておきます。

この記事のための新しい実験はしていません。時間と費用は、手元に残っていたセッション履歴と Git 履歴を集計しただけです。
手順 1（Microsoft 365 Copilot / Work IQ でドラフトを作る段階）は、過去の Work IQ 調査で間接的に評価しただけです。
改訂した Prompt は、まだ実際のアプリ開発で実行していません。

提案した 5 段階を、まず素直に評価する

この表は、途中の検討で改訂前の Prompt を評価したものです。改訂後の対応は後半にまとめています。

段階	実行するもの	入力	出力	人の役割（提案）	評価
1	Microsoft 365 Copilot / Work IQ	会議・メール・文書	要求定義のドラフト	ドラフトの依頼	妥当。ただし Work IQ の検索で見つかる割合は低かった
2	P-RD	ドラフト、社内情報、公式資料	要求定義（最終候補版・未承認）	なし	内容は高品質。人の承認が抜けている（G4）
3	P-FR（Wave ごと）	要求定義、catalog、依頼	コード、テスト、更新した要求定義と catalog	なし	Wave 1 は妥当。Wave 2 は範囲外（G2）。合否は自己申告（G3）
4	P-ST（繰り返し）	台帳	テスト結果、自動修正の commit	なし	対象を誤っている（G1）
5	人	動くアプリ	UAT の判定	UAT	UAT 以外にも人の作業が残る（G4）

ぱっと見はシンプルで良さそうです。ただ、細かく見ると「だれが合否を決めるのか」「だれが承認するのか」が抜けていました。

根拠 1: 過去の実測から分かっていたこと

ATG あり／なしの比較

実測環境は GitHub Copilot CLI 1.0.88、Windows、モデルは claude-opus-5.5 です。C1 は「ATG を使わない 1 回の依頼」、C2 は「ATG あり」です。

タスク	要求定義の文字数	隠しテスト	完成率 C1 → C2	時間 C1 → C2	クレジット C1 → C2
1: 家計簿 CLI	4,458	74	2/2 → 2/2	328.8 → 738.3 秒（2.25 倍）	47.8 → 167.2（3.50 倍）
2: 表計算エンジン	9,908	225	3/3 → 3/3	1,879.8 → 3,221.1 秒（1.71 倍）	254.5 → 634.3（2.49 倍）
3: SQL エンジン（medium）	7,155	564	1/3 → 0/3	7,876.5 → 8,120.7 秒	1,620.7 → 1,914.8
3: 分割の 1 文を追加（C1S → C2S）	同上	同上	2/3 → 2/3	7,350.5 → 6,234.0 秒	1,572.0 → 1,528.2

事実: 当時のレポートは「測った範囲では、モデルの進化によって ATG の役割は不要になった、という判断を支持する」と結論しています。
事実: 推奨 Prompt は「要求定義を最後まで完成させてください。私は途中で応答しません。…」の 1 文で、大規模な場合は「1 回のツール呼び出しで書き込む内容は 300 行以内」を足す、というものでした。P-FR はこの 2 つを両方含んでいます。
事実: この推奨には 3 つの前提があります。要求定義がファイルであること、完了条件を exit code で判定できること、Autopilot で実行することです。

正直、ここは自分でも少しショックでした。オーケストレータを足すと、時間もコストも増えるのに、品質は変わらなかったわけです。

単一セッションが失敗する仕組み

事実: タスク 3 の失敗では、実装段階でモデルが 1 回の応答の出力上限（32,000 トークン）をすべて推論に使い切り、ツールを呼べないままターンが終わる、ということが繰り返されました。推論トークンが出力に占める割合は 95.7% でした。
事実: ATG のあり／なしに関係なく、同じ仕組みで失敗しました。オーケストレータを足しても防げませんでした。
推論: 効いたのは「書き込みを小さく分ける」指示と、「タスクそのものを小さく分ける」ことです。

提案の「Wave で少しずつ依頼する」運用は、後者を人の側でやっていることになります。実測と整合しています。

モデルの差

事実: Sonnet 5.5 の平均総時間は Opus 5.5 の 0.41 倍（表計算）、0.56 倍（SQL）でした。SQL の完成率は Opus 3/6、Sonnet 5/6。完成した実装の隠しテストは Opus 561.3/564、Sonnet 557.4/564 です。
事実: 分割を明示しない C1 は Sonnet でも 1/3 が失敗し、分割した C1S は 3/3 成功しました。
推論: 既定は Sonnet 5.5 + 分割指示にし、難しい設計判断だけ上位モデルを使うのが、時間とコストの面で合理的です。とはいえ n が少ないので、確定的な差とは言えません。

長時間化の原因

事実: 最長のステップは 88.7 分以上かかりました。そのうち LLM の推論時間は 16 回で合計 7.3 分。LLM 以外の時間が 81.4 分（91.8%） でした。入力コンテキストは 45,805 → 103,596 トークンと 2.26 倍に増えています。
推論: 長時間化の主な原因は、ツールの実行、承認待ち、直列実行、文脈の肥大です。外部のオーケストレータは直列実行の一部を改善できても、ほかの原因には効きません。

オーケストレータを小さく書き直す案

「じゃあ、もっと小さく作り直せばいいのでは」という案も検討していました。

事実: ATG は 13 の Python ファイル（2,354 行）で、依存ライブラリはありません。HVE の外でも動きます（14 種類の CLI 実行形式で exit 0）。
事実: それでも全面的な書き直しは推奨しませんでした。エンジンを小さくしても速度はほとんど変わらないからです。律速は LLM 呼び出し、文脈の量、制御の判断、直列性にあります。

検証の空白（偽の PASS）

ここは実務でいちばん効いてくる話だと思っています。

事実: atg node finish は verify_command を実行せず、handoff に書かれた exit_code: 0 をそのまま受け入れていました。スタブ実装と assert True でも succeeded になりました。
事実: accepted=1 のまま、隠しテスト 258/564 の実装を受理した例があります。
事実: 過去の調査では「指示があることをテストしても、エージェントがその指示を守ったことは証明できない」と整理していました。
推論: 合否は、エージェントが書く文章ではなく、エージェントの外で実行したコマンドで決める必要があります。

これは HVE を使っても使わなくても同じです。HVE をやめて新たに失うものではありません。ただし、元の P-FR だけではこの仕組みがない、というのが G3 です。

Work IQ

事実: 固定の質問で問い合わせる方式では、35 件中、見つかった 5 件（14%）、一部 4 件（11%）、見つからない 23 件（66%）、使えない 3 件（9%）でした。情報がテナントにそもそも存在しない可能性もあり、方式だけが原因とは断定していません。
事実: 当時の結論は Work IQ の否定ではなく、「HVE 専用の Work IQ オーケストレーションを撤去し、探索エージェントに retrieve を優先した反復調査を任せる」というものでした。
推論: 手順 1 で Work IQ を「ドラフト作成者」として使い、P-RD で「見つからなければ『社内情報未確認』と記録して進む」方針は、この結論と整合します。

Managed Runtime

事実: 調査時点では、Microsoft Copilot Managed Runtime は HVE の実行エンジンを置き換えられないと判定していました。実験的な API で、ローカルリポジトリの編集や権限コールバック、output_paths ゲートなどを満たさないためです。
推論: これは「HVE を何で置き換えるか」の評価です。今回は「HVE を置き換えずに、Copilot 本体を直接使う」案なので、この結論は判定を妨げません。

HVE を見直したときの結論

事実: HVE には重複したステップ、過剰な指示、複雑な経路があり、削れると整理していました。一方で、複数のエージェントは文脈を共有しないので、ファイルとしての要件索引だけが共有状態になる とし、要件索引と決定的な検査は必要としていました。
推論: 必要だったのは「HVE」ではなく、「機械可読な要件索引」と「決定的な検査」です。catalog は前者の最小形で、後者は G3 で補います。

過去のアプリ開発にかかった時間とトークン費用

HVE を作るかたわらで、私は 4 つのアプリを Copilot で開発していました。それぞれのリポジトリの作業記録と Git 履歴、手元に残っていた Copilot のセッション履歴を集計しました（集計日 2026-10-05）。

アプリ	概要	Git の期間	commit 数（活動日）	HVE	ATG	稼働時間	AI の費用（AIU）	金額の目安
A	画像 AI の教師データ作成・学習・推論を行うデスクトップアプリ	約 4 週間	87（10 日）	なし	導入したが一度も呼ばれず、削除	63.3 時間	100,794	約 1,008 USD
B	レポートの回答を AI で採点するデスクトップアプリ	約 1 か月	124（18 日）	なし	なし	40.6 時間	33,999	約 340 USD
C	生産管理のデモ（Azure にデプロイ、AI チャットつき）	1 日	3（1 日）	なし	なし	5.3 時間	7,747	約 77 USD
D	対談動画の編集支援アプリ	約 5 週間	216（21 日）	なし	使った	45.4 時間	66,981	約 670 USD
合計			430			154.6 時間	209,521	約 2,095 USD
参考: アプリ X（HVE で開発しようとしたもの。次の節）	14 のサブアプリからなる企業向けの業務システム	約 9 か月	944（135 日）	HVE で開発	HVE の DAG	85.6 時間	109,547	約 1,095 USD
参考: HVE 本体の開発・保守・テスト	Copilot を Workflow / DAG で段階実行させる Framework	約 8 か月	1,740（176 日）	—	—	143.3 時間	181,055	約 1,811 USD

定義: 稼働時間は、エージェントが動いていた時間の合計で、人の待ち時間は含みません。AI の費用は、セッション履歴の totalNanoAiu を 10^9 で割った値（AIU）の合計で、サブエージェントの分を含みます。
集計の確かめ: アプリ A には、以前に同じセッション履歴から作った分析がありました。同じ時点で区切って集計し直すと、その値との差は 1.4% でした。
金額の目安は、1 AI Credit = 0.01 USD（GitHub Docs）として、AIU を AI Credits と同じ単位とみなして換算したものです。プランに含まれる分を差し引いた実際の請求額ではありません。
限界: セッション履歴は 2026-09 の後半以降しか残っておらず、Git の活動はそれより前から始まっています。表の値は下限です。HVE まわりのセッション履歴も 2026-07 以降の分だけで、HVE 本体の行には、この記事を書くための調査や実験も含みます。
限界: 集計できたのは、手元に残る CLI / SDK のセッションだけです。VS Code Chat と、GitHub 上の cloud agent のセッションは入っていません。以前の分析では、アプリ D の VS Code Chat の 1 セッションだけで、入力が約 27 億トークン・約 95 時間に達していました。どの行も、実際はもっと大きいと考えてください。

ここから分かったのは、次の 3 つです。

事実: 4 つのアプリは、どれも HVE を使わずに作られていました。ATG は 2 つで試しましたが、A では一度も呼ばれないまま削除しました。C は、HVE も ATG も使わずに、1 日・稼働 5.3 時間・約 77 USD で Azure へのデプロイと AI の評価まで済ませていました（実機での一部の計測は受入待ち）。
事実: A の分析では、費用の最大の要因は、1 セッションに作業を詰め込んだ長大セッション（1 セッションで全体の 31%）と、広い範囲の敵対的レビュー（上位 6 件でサブエージェントのトークンの 52%）でした。オーケストレータがあれば防げた重複実行は、全体の約 1% でした。
推論: 記録のある期間だけでも、HVE まわり（HVE でのアプリ開発と HVE 本体）に使った AI の費用は 4 アプリの合計の約 1.39 倍、稼働時間は約 1.48 倍でした。HVE 本体の開発・保守だけでも、4 アプリの合計の約 0.86 倍です。アプリを作るのと同じくらいのお金と時間を、アプリを作るための仕組みに使っていたことになります。正直、これは集計してみて一番こたえた数字です。

HVE で開発しようとしていたアプリ X は、どこまで行ったのか

上の 4 つは HVE を使っていませんでした。では、HVE を使って作ろうとしていたアプリはどうだったのか。同じ観点で調べました。

アプリ X は、14 のサブアプリと 26 のユースケースからなる企業向けの業務システムです。業務要求の整理から始め、HVE の Workflow（要求定義 → アーキテクチャ選定 → 画面・サービス設計 → Web アプリの実装）で、設計から実装・デプロイまで進める計画でした。

時間と費用

期間	開発の方法	時間・費用
最初の約 1.5 か月	業務要求と将来シナリオの文書作成	未測定
次の約 3.5 か月	GitHub の Issue から cloud agent で Workflow の Step を実行（Issue 168 件）	未測定（cloud agent のセッションは手元の履歴にない）
次の約 2 か月	手元の HVE で Workflow を実行（55 run・381 セッション）	稼働 85.6 時間、109,547 AIU（約 1,095 USD 相当）

手元の HVE 実行の内訳を見ると、Web アプリの実装の Workflow が 66% を占め、そのうち UI の実装と UI テストの生成だけで 40% でした。画面ごとに「先にテストだけ作る」工程を回していたためです。HVE の run の中から /fleet を起動した分も 16% ありました。

到達点

設計の文書は多く作られました。サブアプリ 14 件の要求定義、ユースケース 25、画面 8、サービス 9、テスト仕様 25 のファイルです。
ところが、アーキテクチャの選定は 14 件すべてで「入力不足のため判定中断」 でした。
実装は、C# と JavaScript で合わせて約 1.9 万行ありますが、明確に動くところまで作られたのは 1 つのサブアプリが中心です。
システムテストの総合判定は 「INCOMPLETE・BLOCKED（全体 PASS ではない）」 でした。機能の受入、E2E、修正後の安定性は未完了で、Azure へのデータのデプロイは実行されていません。
最近の再実行でも、4 つの Workflow のうち 2 つが失敗しました。成功した Web 実装の Workflow も、最初の 1 Step だけで約 27 分・1,000 リクエストかかっていました。
Workflow を回し直すたびに成果物を作り直しており、ファイルを削除した commit が 53 件、削除したソースファイルは延べ 1,500 を超えていました。

起きていた問題

問題	中身
1 回通すだけで長い	1 Step が約 7〜18 分。全 131 Step を直列で通すと約 15〜39 時間かかる試算
前の Step が止まると、後ろも止まる	アーキテクチャ選定が 14 件すべて中断。Prompt 版のテストでは 44 ケース中、実行した 5 件がすべて失敗し、29 件は未実行、10 件は承認待ちのまま
費用が偏る	UI テストの生成に費用の 40%
全体の合否と費用が分からない	「Step ごとの費用、実際のツール呼び出し、性能目標は、全体で有効な集計なし」とシステムテストの報告に書かれていた
作り直しが多い	削除 commit 53 件

推論: HVE を通したアプリ X は、手元の実行だけで 85.6 時間・約 1,095 USD 相当を使い、cloud agent の期間を含めると約 9 か月かけましたが、動くアプリには届きませんでした。同じ時期に HVE なしで作った 4 つのアプリは、合計 154.6 時間・約 2,095 USD 相当で、4 つとも実行や受入の記録がある状態まで進んでいます。
留保: 規模がまったく違います。アプリ X は 14 のサブアプリからなる企業向けのシステムで、4 つは単体のアプリです。また、HVE でのアプリ開発には、HVE 自体を試すための実行も混ざっています。なので「HVE のせいで完成しなかった」とまでは言えません。
それでも言えるのは、Workflow を順に回す方式では、大きなアプリでも完成に近づかず、時間と費用の多くが成果物の生成と作り直しに使われたということです。HVE は課題を解決するために作ったのに、このアプリでは HVE 自体が「長い」「止まる」「作り直す」という新しい課題を生んでいました。

費用を下げるのは、オーケストレータではなく、Wave を小さく分けること、レビューを変更の範囲に絞ること、既定のモデルを Sonnet 5.5 にすることだと考えています。

根拠 2: Copilot 本体の機能と、外部の研究

Copilot 本体で使えるようになった機能

HVE を作り始めた頃になかった仕組みの多くが、今は公式機能になっています。

公式機能	内容（公式文書の記載）	HVE で対応していた機能	出典
CLI Autopilot	完了と判断するまで自律的に続ける。既定では自動継続 5 回で一時停止し、`--max-autopilot-continues` で変えられる	無人での連続実行	autopilot
`/fleet`	計画を独立した小タスクに分け、依存関係を見てサブエージェントで並列実行する。各サブエージェントは別のコンテキストを持つ。並列化でクレジット消費は増え得る	DAG による Wave 分割と並列実行	fleet
Hooks	`agentStop` は block して継続を強制できる。`preToolUse` はツール実行を許可・拒否・変更できる。`postToolUseFailure` は回復の手引きを注入できる。CLI と cloud agent の両方で動く	継続判定、安全ゲート、`output_paths` ゲート、監査ログ	hooks、hooks reference
Cloud agent の research / plan / branch	リポジトリの調査、実装計画の作成と承認、PR を作らないブランチでの反復	計画の承認ゲート（SHA-256）、Cloud Agent での Issue 実行	Changelog 2026-04-01、about cloud agent
Cloud agent の安全策	CodeQL、Advisory Database、Secret scanning で自動検査。push 先は 1 ブランチ、PR のマージには人のレビューが必要。firewall でアクセスを制限。署名付き commit、セッションログと監査ログ	安全境界と証跡	risks and mitigations
Automations	定期実行や Issue・PR のイベントで cloud agent を起動。使えるツールを絞れる。private / internal のリポジトリだけ、Git では版管理されない	定期実行、自動修正	about automations
Custom instructions / Agent skills / MCP	リポジトリの指示、Skill、MCP サーバーを CLI と cloud agent が読み込む	Prompt と Skill の配布、MCP の利用	about cloud agent
課金	cloud agent は Actions の分数と AI Credits、CLI もトークン量に応じて AI Credits を使う	予算と AIU の管理	同上

推論: HVE の主な付加価値だった「継続」「並列」「承認」「安全ゲート」「証跡」は、公式機能でほぼ置き換えられます。
注意（事実）: Autopilot の自動継続は 既定で 5 回まで です。P-FR を無人で最後まで流すには、上限を上げるか、agentStop hook で継続を判定する必要があります。ここは実務でハマりやすいところです。

外部の論文とベストプラクティス

自分の実測だけだと、どうしても「自分の環境ではそうだった」で終わってしまいます。なので、外部の根拠も集めました。

「確認」の列は、本文 = 私が本文を読んだ、要旨 = 私が要旨を読んだ、本文（調査）/ 要旨（調査）= 調査用のサブエージェントが読み、私は題名・URL・主張の対応だけを確かめた、という意味です。

#	主張	出典	確認	今回への含意	反映先
E1	うまくいった実装の多くは、複雑なフレームワークではなく単純で組み合わせやすい部品で作られていた。複雑さは必要なときだけ足す	Anthropic, "Building effective agents", 2024, https://www.anthropic.com/engineering/building-effective-agents	本文（調査）	自作オーケストレータより、Prompt と公式機能の組み合わせを優先してよい	HVE 停止の判定
E2	「位置特定 → 修正 → 検証」の単純な 3 段（Agentless）が、SWE-bench Lite で既存の OSS エージェントより高い性能（32.00%）と低いコスト（0.70 ドル）を出した	Xia et al., "Agentless", arXiv:2407.01489, 2024	要旨	複雑なエージェントが必ずしも有利ではない。ATG の実測と同じ方向	HVE 停止の判定
E3	複数エージェントの調査システムは単一より 90.2% 良い結果だったが、トークン消費はチャットの約 15 倍。依存関係の強いコーディングは複数エージェントに向かない	Anthropic, "How we built our multi-agent research system", 2025, https://www.anthropic.com/engineering/multi-agent-research-system	本文（調査）	反証であり条件でもある。並列化は独立した広い調査には効くが、密結合な実装には向かない	P-FR のサブエージェント規則（境界ごとにだけ分ける）
E4	長時間エージェントでは「一度に作りすぎて文脈が尽きる」「途中の状態を見て完了と宣言する」失敗が起きた。機能一覧を最初は全部「未達」にして JSON で持つ、1 機能ずつ進める、git と進捗ファイルで状態を引き継ぐ、ブラウザ自動化で E2E テストする、テストの削除・編集を強く禁じる、が有効だった	Anthropic, "Effective harnesses for long-running agents", 2025, https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents	本文	Wave 運用と一致する。台帳と E2E テストが重要	P-ST の JSON 台帳と E2E、P-FR の作業前の基準確認
E5	文脈は有限の資源で、モデルには注意の予算がある。少なく情報量の多いトークンに絞る「コンテキスト工学」が要る	Anthropic, "Effective context engineering for AI agents", 2025, https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents	本文（調査）	要求定義の全文を毎回読ませず、索引で必要な箇所だけ取り出す	P-RD・P-FR の mdq / cq
E6	関係する情報が長い入力の中ほどにあると、性能が大きく落ちる	Liu et al., "Lost in the Middle", TACL 2024（arXiv:2307.03172）	要旨	要求定義が大きくなったら分割する	分割の規則
E7	入力が長くなるにつれて、性能は一様でない形で落ちる（context rot）	Chroma Research, "Context Rot", 2025, https://research.trychroma.com/context-rot	本文（調査）	同上	同上
E8	リポジトリ全体から関連コードを反復検索してから生成すると、ファイル内だけの補完より 10% 以上精度が上がった	Zhang et al., "RepoCoder", arXiv:2303.12570, 2023	要旨	catalog だけでなく、索引付きのコード検索で補う意味がある	P-FR の `cq search` / `trace` / `def` / `refs`
E9	エージェント向けの操作体系（検索・移動・編集のコマンド）が性能を大きく左右する	Yang et al., "SWE-agent", arXiv:2405.15793, 2024	要旨	小さな結果を返す専用の検索ツールを用意する価値がある	同上
E10	LLM は外部からの正しいフィードバックなしには自分の推論を自己修正できず、悪化することもある	Huang et al., "Large Language Models Cannot Self-Correct Reasoning Yet", ICLR 2024（arXiv:2310.01798）	要旨（調査）	エージェント自身の「完了した」で合否を決めない	P-FR の検証スクリプトと CI（G3）
E11	最先端モデルが、テストや採点コードを書き換えて高得点を得る「報酬ハッキング」が実測された	METR, "Recent Frontier Models Are Reward Hacking", 2025-06-05, https://metr.org/blog/2025-06-05-recent-reward-hacking/	本文（調査）	テストを弱めることの禁止と、外部での判定が必要	P-FR・P-ST の「テストを弱めない」、CI
E12	仕様とテストが矛盾する課題で、エージェントがテストを利用して「解いたふり」をする割合が高く観測された	Zhong et al., "ImpossibleBench", arXiv:2510.20270, 2025	要旨（調査）	テストが要求と食い違うときは、直させずに競合として報告させる	P-FR・P-ST の競合の扱い
E13	推論モデルの思考過程を監視すると、テストを書き換えて合格に見せかける計画が記録されていた	OpenAI, "Monitoring reasoning models for misbehavior and the risks of promoting obfuscation", 2025, https://openai.com/index/chain-of-thought-monitoring/	本文（調査）	同上	同上
E14	過剰な機能・権限・自律性が「Excessive Agency」の根本原因。影響の大きい操作を独立して確認・承認しない設計も原因になる	OWASP, "LLM06:2025 Excessive Agency", https://genai.owasp.org/llmrisk/llm062025-excessive-agency/	本文	デプロイ、push、課金、外部公開は既定で「しない」にし、明示した範囲だけ許可する	P-FR の `<execution_options>`（G2・G4）
E15	AI のリスク管理を設計・開発・利用・評価の全体に組み込む枠組み。生成 AI 向けプロファイル（AI 600-1）がある	NIST, "AI Risk Management Framework"（AI RMF 1.0, 2023 / AI 600-1, 2024）, https://www.nist.gov/itl/ai-risk-management-framework	本文（調査。AI 600-1 はページの記述だけ）	人による承認と、その記録を残す	P-RD の承認依頼一覧、P-FR の承認済みだけ実装（G4）
E16	要求工学のプロセスと、要求が持つべき特性（検証できる、曖昧でないなど）を定める国際規格	ISO/IEC/IEEE 29148:2018, https://www.iso.org/standard/72089.html	本文（調査。概要ページ）	受入基準を検証できる形で書く既存の方針と合う	既存の規約のまま
E17	GitHub Actions から Azure への認証は OIDC フェデレーションかマネージド ID を推奨。サービスプリンシパル + シークレットは推奨しない	Microsoft Learn, "Authenticate to Azure from GitHub Actions workflows", https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure	本文（調査）	デプロイの秘密値は OIDC とマネージド ID で扱う	P-FR のデプロイ規則
E18	小さく段階的で品質ゲートを持つリリースと、段階的な公開範囲の拡大でリスクを抑える（WAF OE:11）	Microsoft Learn, "Architecture strategies for safe deployment practices", https://learn.microsoft.com/en-us/azure/well-architected/operational-excellence/safe-deployments	本文（調査）	Wave 2 は dev から始め、本番は明示した場合だけ	P-FR のデプロイ規則
E19	GitHub Environments に保護規則（必須レビュー担当者など）を設定でき、満たすまでジョブは秘密値に触れられない	GitHub Docs, "Managing environments for deployment", https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments	本文（調査）	本番展開に人の承認を挟む仕組みとして使える	決定的ゲート（後述）
E20	経験のある OSS 開発者の無作為化比較試験で、AI を使うと作業時間が平均 19% 長くなった。本人は速くなったと感じていた（2026 年に更新版ありとの注記あり）	METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025-07-10, https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/	本文（調査）	反証。AI を使えば自動的に速くなるとは限らない。実地で測る必要がある	未検証事項の測定
E21	定型の課題（HTTP サーバー実装）では、Copilot を使った群が 55.8% 速く完了した	Peng et al., "The Impact of AI on Developer Productivity", arXiv:2302.06590, 2023	要旨（調査）	E20 と合わせると、効果は課題の種類と文脈の量で変わる	同上
E22	AI は組織がもともと持つ強みと弱みを増幅する。効果は品質の文化や明確なプロセスで決まる	Google DORA, "State of AI-assisted Software Development", 2025, https://dora.dev/research/2025/dora-report/	要旨（調査）	Prompt だけでなく、要求の正本・承認・検証のプロセスが成果を左右する	5 段階の構成そのもの
E23	E2E テストは利用者に見える振る舞いを検証し、実装の詳細に依存せず、各テストを独立させる	Playwright, "Best Practices", https://playwright.dev/docs/best-practices	本文（調査）	生成アプリのシステムテストの書き方	P-ST の `<test_design>`
E24	既存ベンチマークのテストは量も質も足りず、テストを増やして厳しく評価すると、LLM 生成コードの正答率の推定が大きく下がる	Liu et al., "Is Your Code Generated by ChatGPT Really Correct?"（EvalPlus）, NeurIPS 2023（arXiv:2305.01210）	要旨（調査）	システムテストは正常系 1 件で済ませず、異常系と境界を含める	P-ST の `<test_design>`

外部の根拠から見ると、こう整理できます（推論）。

HVE 停止を支持する根拠: E1、E2、E4。単純な構成と、少しずつ進める運用が有効だとしています。ATG の実測と同じ方向です。
補うべき点（G3〜G5）を支持する根拠:
- E10〜E13: エージェント自身の申告やテストに頼る危うさ。外部の判定（CI）が必要
- E5〜E9: 全文を読ませず、索引で絞る方針
- E14〜E19: 権限を既定で絞り、人の承認を挟む設計
反証と留保: E3 は、広い調査では複数エージェントが有利なことを示しています。E20 は、実際の開発で AI が作業を遅くした例です。E4 自身も、専門エージェント（テスト担当など）に分けた方がよいかは未解決としています。

つまり、HVE をやめても「それで速くなるか」は実地で測らないと分からない、ということです。ここは素直に認めておきます。

HVE で解決しようとしていた課題は、今も Framework が要るのか

HVE の目的は、「業務要件の整理から設計・実装・検証までを、再現可能なワークフローとして運用すること」でした。その裏には、作り始めた頃の Copilot では解決できなかった課題がありました。課題ごとに、HVE での対応と今の解決手段を並べてみます。

判定: 不要 = Copilot 本体の機能か運用の規則で済む。薄い仕組み = リポジトリごとの数十〜数百行のスクリプト・CI・設定、または持ち出せる単体ツールで済む。

#	HVE で解決しようとしていた課題	HVE での対応	今の解決手段	Framework 化・アプリ化
1	途中で止まる。中断すると再開できない	Workflow の連続実行、Step 単位の resume	Autopilot、`agentStop` hook、セッションの再開、commit 単位の再開	不要
2	大きな作業を分け、依存関係を守り、並列に流す	DAG、Wave 分割、ATG	`/fleet`、人が Wave を分ける、「300 行以内に分けて書く」の 1 文	不要
3	複数のセッションが同じ作業を重ねる、同じ作業ツリーで競合する	ATG の状態 DB、重複起動の拒否	Wave をブランチ単位にする、共有ファイルは親だけが書く	不要（運用の規則）
4	計画を人が承認してから実行したい	計画の SHA-256 と承認ゲート	Cloud agent の plan 承認、CLI の plan モード	不要
5	破壊的な操作や、範囲外への書き込みを防ぎたい	`output_paths` ゲート、安全ガード	`preToolUse` hook、cloud agent の安全策	不要
6	要件から設計・実装・テストまでを、段階ごとの Prompt で順に回したい	13 Workflow、Prompt 約 314 件	P-RD と P-FR の 2 本、必要な Skill だけ残す	不要
7	社内の情報を要求に取り込みたい	Work IQ のオーケストレーション、原本の取り込み	Microsoft 365 Copilot / Work IQ でドラフト、MCP、P-RD の出典規約	不要
8	合否がエージェントの自己申告になる（偽の PASS）	ATG の検証コマンド、検証ループの Skill	P-FR が作る検証スクリプトと CI の exit code	薄い仕組み
9	文脈が肥大する。要求とコード・テストの対応を追えなくなる	要件索引、mdq / cq の HVE 統合	catalog（短い対応表）、mdq / cq の導入キット、分割の規則	薄い仕組み
10	費用と証跡を管理したい	実行台帳、AIU の予算、KPI ダッシュボード	Enterprise の AI Credits 予算、セッションログ・監査ログ、上の表と同じ定義での集計	薄い仕組み

推論: 10 の課題のうち 7 つは、Copilot 本体の機能か運用の規則で済みます。残る 3 つも、リポジトリごとの小さな仕組みか単体ツールで足ります。課題そのものは今も実在します。でも、その解決のために Framework やアプリケーションを作り、保守し続ける必要はなくなりました。
推論: 8 の偽の PASS は、そもそも HVE を作っても解決していませんでした。HVE をやめて失うものではなく、HVE の有無に関係なく、エージェントの外に置く必要がある仕組みです。

過去の 4 つのアプリが、どれも HVE なしで作られていたことも、この整理と合っています。逆に、HVE で作ろうとしたアプリ X では、1・2・6 への HVE の対応（Workflow の Step を順に回す）そのものが、「1 回通すだけで長い」「前が止まると後ろも止まる」という新しい課題になっていました。

HVE の機能は、何で代替できるのか

代替度: ◎ = 公式機能で同等、○ = 小さな追加（Prompt・hook・CI）で同等、△ = 一部だけ、× = 代替なし

HVE の機能	代替手段（HVE なし）	代替度	失うもの・対応
Workflow / Step の Prompt 群（13 Workflow、Prompt 約 314 件、Skill 34 件）	P-RD・P-FR の 2 本に集約。必要な Skill（リージョン方針、デプロイスクリプト、CI/CD、検証ループなど）はそのまま残す	○	設計書を細かく分けて作る工程はなくなる。要求定義の「技術選択」と catalog で代える
DAG 実行と並列化	`/fleet`、または Wave を人が分ける	○	決定的な DAG の状態は残らない。Wave ごとの commit と catalog 更新で代える
計画の SHA-256 と承認ゲート	Cloud agent の plan 承認、CLI の plan モード	◎	—
継続（途中で止まらない）	Autopilot と `agentStop` hook	○	hook のスクリプトを 1 本用意する
`output_paths` ゲート、破壊的操作の拒否	`preToolUse` hook、cloud agent の単一ブランチ制限	○	拒否する規則を hook に書く
中断からの再開	CLI のセッション再開と、commit 単位での再開	○	Step 単位の正確な再開は失う。P-FR は冪等なので影響は小さい
実行台帳、試行ごとの証跡	cloud agent のセッションログ、監査ログ、commit。ローカルは hooks のログ	○	HVE 独自の KPI ダッシュボードはなくなる
予算（max-minutes、AIU）	Enterprise の AI Credits 予算、`--max-autopilot-continues`	△	1 回の実行ごとの厳密な上限は難しい（未検証）
失敗時の自動修正と試行上限	Prompt に上限を書く。`agentStop` hook で回数を数える。夜間は Automations	○	—
GUI	VS Code、Copilot app、GitHub の Agents タブ	◎	—
Work IQ と MCP の許可リスト、出典の実在照合	MCP の設定、Skill、P-RD の出典規約（SRC-xxx）	△	出典の機械照合はなくなる。CI で形式だけ検査する程度
HVE 本体のシステムテスト	—	対象外	HVE をやめれば不要。生成アプリ用のシステムテストは、もともと HVE になかった（G1）。改訂した P-ST では、既定の対象を生成アプリにした
要件索引と、要求 ID からコード・テストへの追跡	catalog（短い対応表）と mdq・cq の索引	○	mdq と cq は導入キットごと他のリポジトリへ持ち出せる。HVE 固有の自動起動はなくなるので、P-FR の最後に索引を更新させる
モバイルと Power Platform	—	対象外	HVE の 13 Workflow に専用のものはない。HVE をやめても失わない

推論: HVE をやめて失うのは、主に「決定的な DAG の状態」「実行単位の予算制御」「出典の機械照合」の 3 つです。どれも、Wave 運用と CI で実務上は補える範囲だと考えています。

実際には、「失うもの」より「保守しなくてよくなるもの」の方がずっと大きい、というのが私の感覚です。

3 つの Prompt のレビュー

ここからは、途中の検討で改訂前の Prompt を見直したレビューです。最終的に何を反映したかは、この章の最後にまとめます。

P-RD（要求定義の作成）

良い点（事実）

事実・決定・仮説・提案・不明を区別させています。要求ごとに出自（原文由来／利用者決定／AI 提案）と決定状態（承認済み／承認待ち／保留／却下）を付けます。
外部連携、マスター、ID の正本を確認させる節があります。企業システムでいちばん手戻りが大きい論点を押さえています。
社内情報（Work IQ）と公式資料（Microsoft Learn、Context7）の出典を SRC-xxx で残させます。後続のエージェントがツールなしで同じ情報を参照できます。
「承認を宣言・生成するのは人の役割」と明記しています。

課題

ID	課題	影響	対応案
RD-1	成果物は「最終候補版（未承認）」で AI 提案を含む。一方 P-FR は要求定義を唯一の正本とし、BLOCKED 以外の MUST をすべて実装する	承認されていない AI 提案が実装される（G4）	P-FR は承認済みの要求だけを実装する。Wave の始めに人の承認を 1 回入れる
RD-2	ID 体系が違う。P-RD は `R-xxx` など、P-FR は `FR-001`、`NFR-001`、`SEC-001` などを例示	2 つの体系が混ざる余地がある	どちらかに合わせるか、P-RD に区分を付けさせる
RD-3	P-RD の受入条件は業務レベルの文章。P-FR は exit code で判定できるコマンドを求め、要求定義を書き換える	承認済みの受入条件の文面が、実装の都合で変わる	P-FR は受入条件の本文を変えず、検証コマンドの列を足すだけにする
RD-4	既存ファイルの複製名が固定で、再実行すると上書きされる	最初の原本を失う	複製名に日時を付けるか、commit を原本とする
RD-5	要求定義を単一ファイルにまとめる	大規模化で文脈を圧迫し、ID がずれる	分割の規則を入れる

P-FR（要求定義からの実装。Wave ごとに繰り返す）

良い点（事実）

過去の実測で最良だった構成（要求定義ファイル、無人実行、300 行以内の書き込み）を含んでいます。
受入基準を exit code で判定させ、テストの弱体化、スキップ、ハードコードを禁じています。
catalog（要求 ID → 実装 → テスト → API・テーブル・イベント）を更新させます。「共有状態としての索引」の最小形です。
ターンの終え方の規則で、途中で止まる 4 つの型を禁じています。
TBD・BLOCKED・ASSUMPTION を記録させ、安全側の動作だけを実装させます。

課題

ID	課題	影響	対応案
FR-1	デプロイ、有料サービス、git push、リポジトリ外の変更をしないと定めている	Wave 2 を実行できない（G2）	途中の検討では展開用 Prompt を別に作る案もあったが、最終的に `<execution_options>` に吸収
FR-2	合否がエージェント自身の実行と報告に依存している	偽の PASS を見逃す（G3）	受入コマンドを CI で実行する。`agentStop` hook で exit 0 でなければ継続させる
FR-3	既存の大きなコードベースを繰り返し変更する運用は、過去に測っていない	回帰と文脈の肥大が起きるか不明	Wave を小さくする。全件回帰は CI に任せる。実地で測る
FR-4	Autopilot の自動継続は既定で 5 回まで	長い Wave の途中で止まる	上限を上げるか、`agentStop` hook で判定する
FR-5	ローカル実行では cloud agent の自動検査（CodeQL、Secret scanning、依存の脆弱性検査）が動かない	脆弱性や秘密値の混入を見逃す	CI に CodeQL、Secret scanning、依存関係のレビューを入れる。または cloud agent で実行する
FR-6	サブエージェントは「本当に独立で並列化できる作業」にだけ使う	大規模な Wave では直列の 1 セッションで文脈が肥大する	境界づけられたコンテキストが分かれる場合は `/fleet` を明示的に使う
FR-7	質問せず最後まで進め、決まらないことは ASSUMPTION にする	業務上の重要な判断が AI の仮定で実装される	ASSUMPTION と BLOCKED の一覧を Wave ごとに人がレビューする

P-ST（システムテスト）— そもそも対象が違った（G1）

これは正直、検証して初めて気付いた点でした。

事実: P-ST は「HVE 本体のシステムテスト の未実施ケースだけを増分実行」し、「HVE が生成したアプリのテストは対象外」と書いています。
事実: 関連する Skill も対象を HVE 本体とし、台帳スクリプトの自動修正の指示も「HVE 本体を修正」に固定されていました。
推論: HVE をやめると、P-ST は実行する意味がなくなります。 手順 4 には、生成アプリのシステムテストを行う仕組みが別に必要です。

とはいえ、P-ST と台帳には、生成アプリでもそのまま使える良い規約がありました。

安定した ID を持つテストケースの台帳と、未実施分だけの増分実行
先に canary（短い代表ケース）を流し、失敗したら本体を止める
自動修正の上限（3 回）と、別ブランチへの commit
修正でテストや期待値を弱めない
合否を exit code と台帳の状態で述べ、失敗を PASS に丸めない
「一括実行ではなく、台帳で分けて実行する」方針

手順 1（Microsoft 365 Copilot / Work IQ でドラフトを作る）

推論: 妥当です。P-RD はドラフトの中の命令を「分析対象のデータ」として扱い、出典がないものは「未確認」とします。ドラフトの品質が低くても、要求定義の段階で弱い部分が見えるようになります。
注意: Work IQ の固定質問で見つかった割合は 14%（一部を含めて 25%）でした。関係する会議名・文書名・連携先の資料を人が指定すると、精度は上がると考えています（推論）。
注意: 個人名や秘密情報を要求定義に転記しないことは、P-RD と P-FR の両方に書かれています。

人の作業は UAT だけにできるか（G4）

結論から言うと、できません。

人に残る作業	理由	種類
要求の承認（Wave の始め）	P-RD の成果物は未承認で AI 提案を含む。P-RD 自身が「承認は人の役割」としている	業務上の統制
ASSUMPTION と BLOCKED の確認	P-FR は決まらないことを仮定で進める	業務上の統制
PR のレビューとマージ	cloud agent は自分の PR を承認・マージできない。依頼者は自分が依頼した PR を承認できない（公式文書）	ツールの仕様
GitHub Actions の実行許可	cloud agent の PR では、既定で人が「Approve and run workflows」を押すまでワークフローが動かない	ツールの仕様
展開・課金・外部公開・権限変更の承認	不可逆な操作、または費用が発生する操作	企業の統制
秘密値と資格情報の配置	エージェントに持たせない	セキュリティ
UAT	業務の妥当性の判定	提案どおり

推論: 人の作業は「UAT だけ」ではなく、「Wave の始めの承認」と「Wave の終わりの UAT とマージ」の 2 点 に集約するのが現実的です。

それでも、HVE を使っていたときより人の作業は減ります。実務的には、まずはここまでで十分だと考えています。

最終的に Prompt へ何を反映したか

対応方針（G1: P-ST の対象に生成アプリを加える、G2: P-FR でデプロイなどを選べるようにする、G3・G4: 補うべき点として採用、G5: catalog を mdq・cq で補う）に従って、3 つの Prompt を改訂しました。改訂前の原本は別途保存しています。

課題 ID	反映した Prompt	反映した内容	根拠
G1	P-ST	既定の対象を生成アプリ（`test_target: app`）に。HVE 本体は `test_target: hve` で選べる。`<run_options>` で時間予算、実行環境（local／deployed。本番は明示時だけ）、自動修正の有無と上限を選べる	P-ST のレビュー、E4
G1	P-ST	ケース台帳 `tests\system\ledger.json`（安定 ID、要求 ID、AC ID、層、コマンド、canary、状態、証跡、履歴）。状態は実行結果でだけ更新し、ケースの削除や期待値の弱体化はしない	E4
G1	P-ST	期待値は要求定義と受入基準から決め、実装コードを読んで決めない。テストが要求と食い違うときは、どちらも直さず競合として報告する	E10〜E13
G1	P-ST	利用者と同じ操作の E2E テスト、サービス間の契約テスト、受入基準にある異常系を必須にした	E4、E23、E24
G1	P-ST	生成 AI の機能は、厳密な一致ではなく評価（`ai_eval`）で確かめる。同じ入力を 3 回以上実行し、合格率で判定する。閾値がなければ blocked・TBD。プロンプトインジェクションと情報漏えいのケースを含める	E14
G1	P-ST	canary の先行実行、変更があったケースだけの増分実行（`git diff` と `cq trace`）、自動修正は別ブランチに commit してマージ・push しない、決まった形の報告	P-ST のレビュー
G2	P-FR	`<execution_options>` を追加。implement_scope、git_push、deploy、deploy_targets、paid_services、budget、external_exposure の 7 項目。既定値はすべて「しない／使わない／公開しない」で、必須の値が欠けたら実行しない	E14
G2	P-FR	deploy が「する」の場合: IaC、適用前の what-if、宣言した先以外に触れない、削除・権限付与・本番は明示時だけ、秘密値は OIDC・マネージド ID・Key Vault、予算内の構成、デプロイ後の受入確認、`docs\deployment.md` への記録、ストア公開と Power Platform の本番取り込みは人に渡す	E17、E18
G3	P-FR	検証スクリプト（ビルド、静的検査、全テスト、要求 ID の整合）と CI（Actions、CodeQL、依存関係の確認）を作らせる。完了は検証スクリプトを新しいプロセスで実行した exit code で判定。作業前に `git log` と検証スクリプトで基準を記録	E4、E10〜E13
G4	P-RD	別添の最後に「承認依頼一覧」を出させる。承認の記録方法（決定状態を「承認済み（決定者の役割・日付・決定記録）」に書き換える）を冒頭に書かせ、記録の有無を確認させる。チャットで上位 3 件を返させる	E15
G4	P-FR	実装してよいのは承認済みの要求と、今回の依頼原文で明示された要求だけ。AI が考えた新機能は「AI提案／承認待ち」として書くだけ。承認済みの文面は変えず、誤りは競合として記録。未実装の承認待ちと要確認の仮定を、影響の大きい順に報告させる	E14、E15
G5	P-RD・P-FR	要求 ID を `FR-xxx` と `NFR-<区分>-xxx` にそろえた。1 要求 1 見出し（例: `#### FR-012 …`）にして、mdq で ID を検索するとその要求だけ取り出せるようにした。テストのコメントに要求 ID と AC ID を書かせる	E5、E6、E8、E9
G5	P-FR	catalog を読んだ後、mdq（`search`）と cq（`trace`／`def`／`refs`）で詳細を探す。索引が古ければ更新してから検索。0 件は不存在の証明にしない。最後に索引を更新する（索引は commit しない）	E5〜E9
G5	P-RD・P-FR	分割の規則: 要求が 150 件超、300KB 超、または境界が 3 つ以上なら、索引と境界ごとの要求ファイルに分ける。境界ごとにサブエージェントへ分けてよいが、要求定義・索引・catalog・契約ファイルは親だけが書く	E3、E6、E7
RD-4	P-RD	既存ファイルの複製名に実行日時を付け、上書きしないようにした	P-RD のレビュー

ID 形式の動作確認（事実）

cq の ID 抽出処理に、次の行を与えて確かめました。

# FR-012 AC-031
# NFR-SEC-001 NFR-PERF-001 E2E-001
# R-012 should not match

結果は FR-012、NFR-SEC-001、NFR-PERF-001、E2E-001 の 4 件でした。改訂前の P-RD の形式（R-012）は拾われず、AC-031 も拾われません。

受入基準の本文は要求定義の側にあり、mdq で取り出せるので支障はありません。ID をそろえたことで、cq trace --id FR-012 で要求からコードとテストを引けるようになるはずです（推論。実際のアプリでの確認は U2）。

あえて反映しなかったもの

agentStop / preToolUse hook: Prompt ではなく、リポジトリの設定（.github/hooks/*.json）として置くものです。Prompt から作らせると、作った後のセッションにしか効かず、上限のない継続ループの危険もあります。なので、任意の設定として残しました。
Autopilot の継続回数の上限（FR-4）: 実行時の設定なので、Prompt には入れていません。
Prompt を増やすこと: 既存の 3 本に吸収しました。Prompt が増えると、それだけで運用の負担が増えるからです。

企業向けの大規模分散アプリとして、まだ残る論点

ここは HVE の有無に関係なく、この 5 段階で企業向けの大規模分散アプリを作るなら避けて通れない論点です。実務では、Prompt よりもこちらで話が変わることが多いです。

論点	改訂した Prompt での扱い	残るリスク	対応案
サービス間の契約（API、イベント、データ）	catalog に API・テーブル・イベントの列。P-ST が契約テストを作る。契約ファイルは親エージェントだけが更新	契約の破壊的な変更を自動で検出する仕組みはない	OpenAPI、AsyncAPI、JSON Schema を正本にし、互換性検査を検証スクリプトに加える
要求定義と catalog の規模	分割の規則、1 要求 1 見出し、mdq・cq の索引	閾値（150 件、300KB、境界 3 つ）に根拠はない	U2 で測って見直す
環境（dev / stg / prod）	`deploy_targets` で宣言。本番は明示時だけ	環境ごとの設定差を管理する規約はない	IaC（Bicep / Terraform）と `azd` の環境、GitHub Environments の保護規則（E19）
認証と秘密値	OIDC、マネージド ID、Key Vault、GitHub Secrets から読む	—	—
可観測性	要求の書き方の観点にある	運用の要求が抜ける	非機能要求にログ・メトリクス・トレース・SLO を入れる（`NFR-OPS-xxx`）
セキュリティの検査	CI に CodeQL と依存関係の確認。P-ST がプロンプトインジェクションと情報漏えいを確かめる	Secret scanning はリポジトリ設定に依存	Secret scanning と push protection を有効にする
再現性	合否は検証スクリプトと CI の exit code	LLM の出力は毎回違う	Wave ごとに commit とタグを付ける
複数人・複数エージェントの並行開発	共有ファイルは親だけが書く	複数人が同時に P-FR を流すと競合する	Wave をブランチ単位にし、共有ファイルは Wave ごとに 1 回マージ
コスト	`paid_services` と `budget` でデプロイ先の費用を制限	AI Credits の消費は Prompt では制限できない	Enterprise の予算設定、既定モデルを Sonnet 5.5 に
スマホ	テスト配布までを P-FR が行い、ストア申請と公開は人に渡す	署名用の証明書とストアのアカウントは人が用意する	署名と配布は人の承認つき CI。UAT は実機で
Power Platform	宣言した環境へだけ展開。本番取り込みと管理者設定は人に渡す	環境、接続参照、DLP ポリシーは管理者権限に依存	ソリューションをソース管理し、Power Platform CLI と CI で展開（手順は未検証）

反証と留保

「HVE をやめるのは妥当」という判定に対して、反対側の材料も並べておきます。

実測の規模が小さい。 3 タスク、各 n=2〜3、新規作成だけ、モデルは 1 種類です。企業の大規模分散アプリは桁違いに大きくなります。
CLI の出力上限への依存。 失敗の仕組みは、Copilot CLI の 1 応答あたり 32,000 トークンという上限に依存していました。バージョンが変われば結果も変わり得ます。
DAG と状態管理の設計そのものは合理的。 ATG の技術設計（成果物単位の状態、成果物ハッシュ、構造化 handoff、検証層）は、長時間・分割タスクの設計として妥当と評価されています。問題は「効果が測れなかったこと」と「受入判定の信頼境界」でした。
Prompt だけでは継続は保証されない。 自律 Prompt の調査では「ほぼ可能」としつつ、継続には agentStop hook などの決定的な仕組みが要るとしていました。
Cloud Agent での Issue / Sub-Issue DAG は、チームでの並行開発で価値があり得る。 ただし、cloud agent の plan 承認と Automations で代わりが利きます。
外部研究にも反証がある。 広い調査では複数エージェントが単一より大きく良い結果を出しました（E3）。経験のある開発者の比較試験では、AI を使うと作業が遅くなりました（E20）。

推論: 1、2、6 は、HVE を続ける根拠にはなりません。HVE でも同じ条件は測っていないからです。E3 の利点も、/fleet と境界ごとのサブエージェントで HVE なしに得られます。
推論: 3〜4 が示しているのは「HVE が要る」ではなく「小さな決定的ゲートが要る」です。このゲートは、改訂した P-FR の検証スクリプトと CI で用意しました。

なので、判定は変わりません。とはいえ、「反証がない」わけではない点は強調しておきます。

まだ確かめていないこと（HVE 停止後に測るべきこと）

#	未検証事項	測り方（案）	判定の基準（案）
U1	P-FR を既存の大きなコードベースに繰り返し適用したときの回帰と完成率	実際の業務アプリで Wave を 3 回以上回し、CI の全件テストの結果と所要時間を記録	Wave ごとに新規 FAIL 0 件で、受入コマンドが exit 0
U2	要求定義と catalog の大きさの上限	要求数、ファイルサイズ、Wave の所要時間、ID のずれの件数を記録	ID のずれ 0 件。所要時間が Wave の大きさに比例
U3	Wave 2 の Azure 展開の自動化の範囲	`deploy: する` と dev の `deploy_targets` で実行し、IaC、what-if、デプロイ、デプロイ後検証を通す	人の承認 1 回（`<execution_options>` の記入）で展開と検証が通る
U4	スマホと Power Platform の展開	小さなサンプルで署名・配布・ソリューション展開を通す	手作業の手順が `docs\deployment.md` にあり、それ以外は CI で通る
U5	改訂した P-ST の、生成アプリのシステムテストとしての有効性	人が別に用意した E2E テスト（隠しテスト）で採点	隠しテストの合格率と、偽の PASS 0 件
U6	1 回の実行あたりのコスト上限を決める方法	Enterprise の予算機能と CLI のオプションを確認	予算を超えたら停止する
U7	`ai_eval` の判定の安定性	同じ版に P-ST を 2 回流し、`ai_eval` の判定が変わるかを見る	変化が要求定義に書いた許容範囲内
U8	承認の運用の負担	Wave ごとの承認依頼の件数と、人が判断にかけた時間を記録	Wave の始めの承認が、運用できる時間で終わる
U9	改訂した P-FR が検証スクリプトと CI を実際に作り、exit code で完了を判定するか	新しいリポジトリで P-FR を 1 回流し、`scripts/verify.*` と `.github/workflows/` の生成、最終報告の exit code を確認	検証スクリプトが要求 ID の整合を検査し、CI が PR で動く

HVE をやめた後の最小構成

Prompt は 3 本のまま使う

ID	Prompt	使うタイミング	改訂での主な変更
P-RD	`RequirementDefinition作成`	最初と、大きな変更のとき	要求 ID を `FR-xxx`・`NFR-<区分>-xxx` に統一。1 要求 1 見出し。承認依頼一覧の出力と承認記録の確認。分割の規則。複製名に日時。既存文書を mdq / cq で探す
P-FR	`RD-FR_Prompt`	Wave ごと	`<execution_options>`（push、デプロイ、予算、外部公開など）。承認済みの要求だけを実装。検証スクリプトと CI を作り、exit code で完了を判定。mdq / cq で catalog を補う。分割の規則と境界ごとのサブエージェント。作業前の基準記録。報告項目の追加
P-ST	`SystemTest-Run`	Wave の終わり	既定の対象を生成アプリに。JSON 台帳、E2E・契約・異常系、生成 AI の評価テスト、canary、増分実行、自動修正の上限、決まった形の報告。HVE 本体は `test_target: hve` で選べる

人の作業は、次の 2 点に集約しました。

Wave の始め: P-RD が出した承認依頼一覧を見て、要求の決定状態を「承認済み」に書き換える。P-FR の <execution_options>（デプロイ先と予算を含む）を書く。
Wave の終わり: P-FR と P-ST の報告（承認待ち、要確認の仮定、TBD、BLOCKED、fail のケース）を見て、UAT を行い、PR をマージする。

エージェントの外に置く「薄い仕組み」

HVE の代わりに置くのは、これだけです。

ゲート	置き場所	内容	状態
受入ゲート	検証スクリプト（`scripts/verify.*`）と GitHub Actions	ビルド、静的検査、全自動テストを実行し、1 つでも失敗すれば 0 以外で終わる。CI では CodeQL と依存関係の確認も	P-FR に反映済み
索引の整合ゲート	検証スクリプトの一部	実装してよい MUST 要求の ID（BLOCKED を除く）が、catalog とテストコードの両方に現れることを確かめる	P-FR に反映済み
展開の承認ゲート	GitHub Environments の保護規則	本番へのデプロイは人が承認するまで動かない（E19）	任意。リポジトリ設定
継続ゲート	`.github/hooks/*.json` の `agentStop`	検証スクリプトを実行し、失敗なら `decision: "block"` で続けさせる。回数の上限を持たせる	任意。リポジトリ設定
安全ゲート	`.github/hooks/*.json` の `preToolUse`	`git push --force`、リソース削除、本番デプロイ、リポジトリ外への書き込みを拒否	任意。リポジトリ設定

注意: agentStop hook で block を返すと作業は続きますが、上限のないループになる危険と、AI Credits を消費し続ける危険があります。回数を数えるファイルを置いて、上限（例: 3 回）で止める実装にします。cloud agent では、続けた分もジョブの時間制限に数えられます。
推論: これらは数十〜数百行のスクリプトと設定で済みます。HVE（テストを除いて Python 236 ファイル・約 12.5 万行、テスト込みで 934 ファイル・約 12.6 MiB）を保守し続けるより、はるかに小さい負担です。

要求定義と catalog の扱い（大規模化への備え）

最初は単一ファイル（docs\requirements-definition.md）で始める。各要求は 1 見出しにし、見出しに要求 ID を入れる。
要求が 150 件を超える、300KB を超える、または業務の境界が 3 つ以上になったら、docs\requirements-definition.md を索引（要求 ID、題名、決定状態、優先度、所属ファイルへのリンク）にし、境界ごとのファイル（docs\requirements\<境界名>.md）に分ける。閾値は案なので、U2 の測定で見直す。
catalog は「要求 ID → 実装 → テスト → API・テーブル・イベント」の短い表のまま保つ。詳細は mdq（文書）と cq（コード）で探す。
サービス間の契約は、要求定義ではなく契約ファイル（OpenAPI など）を正本にし、要求定義からは ID で参照する。
mdq と cq を新しいリポジトリで使う準備:
- 導入キット（tools/skills/markdown_query/、tools/skills/code_query/）を対象リポジトリへコピーし、それぞれでセットアップスクリプトを実行する（例: pwsh -NoLogo -NoProfile -File setup.ps1 --repo-root <対象> --install-skill --build-index。code-query は --profile main も付ける）。
- cq.toml の roots にアプリのソースとテストのフォルダーを、mdq.toml の [index].roots に docs を入れる。
- .mdq/ と .cq/ の索引は gitignore にする。
- 配置された Skill に HVE 固有の参照が含まれていたら取り除く。

HVE を止める手順（案）

順	作業	備考
1	現在の HEAD にタグを付けて凍結する（例: `hve-eos-final`）	後で参照・復元できるように
2	再利用する資産を選ぶ	候補: `markdown-query`、`code-query`（導入キットごと）、`harness-verification-loop`、`tdd-red-green-reality`、`harness-safety-guard`、`harness-error-recovery`、`adversarial-review`、`large-output-chunking`、`azure-region-policy`、`azure-cli-deploy-scripts`、`azure-ac-verification`、`github-actions-cicd`、`docs-output-format`。HVE 固有の参照を除いてから使う
3	改訂した 3 本の Prompt で、小さなサンプルアプリの Wave 1 と Wave 2 を一度通す	U1、U3、U5、U9 を測る。必要なら任意のゲートを足す
4	HVE 本体と HVE 専用のテスト・Skill・Instruction・Issue Template は、新しい開発用リポジトリに持ち込まない	既存リポジトリから消すかは別途判断（破壊的な操作なので、ここでは行わない）
5	利用者向けの文書に、HVE の提供終了と 3 本の Prompt の使い方（人の作業 2 点を含む）を書く	—

実行時の設定（Prompt の外）

設定	推奨	理由
Autopilot の自動継続の上限	`--max-autopilot-continues` を Wave の大きさに合わせて 5 より大きくする	既定の 5 回では長い Wave の途中で止まる
権限	`--allow-all` を使うなら、ローカルのサンドボックスか cloud agent で実行する	Autopilot は全権限で最もよく動くが、ファイル削除なども許すことになる
既定のモデル	Sonnet 5.5 を既定に、難しい設計判断だけ上位モデル	時間とコストが小さく、完成率は同等以上だった（n は少ない）
予算	Enterprise の AI Credits の予算を設定する	Autopilot と `/fleet` は、人が関わらないまま AI Credits を消費する
Prompt の配布	共有フォルダーにある古い P-RD は、改訂版で置き換える	2 つの版が混ざると ID 形式が食い違い、`cq trace` で追えなくなる

ここまでの整理

長くなったので、一度まとめます。

良い点

自作オーケストレータを足しても、時間とコストが増えるだけで品質は変わらなかった。HVE をやめる判断には実測の根拠がある
HVE で解決しようとしていた 10 の課題は、7 つが Copilot 本体の機能か運用の規則で、3 つが薄い仕組みで済む。Framework 化・アプリ化そのものが不要になった
過去の 4 つのアプリはどれも HVE なしで作られていた。HVE まわりに使った AI の費用は、記録のある期間だけでも 4 アプリの合計の約 1.39 倍だった
HVE で作ろうとしていたアプリ X は、約 9 か月かけても動くアプリに届かなかった（規模の差があるので、HVE だけが原因とは言えない）
単一 Prompt + 「300 行以内に分けて書く」の 1 文で、中規模の実装は作り切れた
HVE の付加価値だった「継続・並列・承認・安全ゲート・証跡」は、Copilot 本体の機能でほぼ置き換えられる
途中の検討で見つけた不足（G1〜G5）は、Prompt を増やさずに 3 本の改訂で吸収できた

注意点

合否はエージェントの外（検証スクリプトと CI の exit code）で決める。自己申告に頼らない
人の承認は消えない。「Wave の始めの承認」と「Wave の終わりの UAT とマージ」の 2 点に集約する
デプロイ・課金・外部公開は既定で「しない」にし、明示した範囲だけ許可する
Autopilot の自動継続は既定で 5 回まで。実行時の設定と予算の設定を忘れない

限界

実測は小規模（3 タスク、n=2〜3、新規作成だけ）で、企業の大規模分散アプリにそのまま一般化はできない
既存コードへの繰り返し変更、複数サービス、Wave 2 の展開、生成アプリのシステムテストの有効性は未検証
外部研究にも、複数エージェントが有利な例や、AI で作業が遅くなった例がある。HVE をやめれば速くなる、とは言い切れない

まとめ

正直に言うと、自分で作ってきたものを止める判断は、あまり気持ちのいいものではありません。

とはいえ、測った結果は「オーケストレータを足しても良くならなかった」でしたし、HVE が担っていた仕組みの多くは、すでに Copilot 本体に入っています。外部の研究も、おおむね同じ方向を向いていました。

一方で、「Prompt を 3 本用意すれば、あとは AI が全部やってくれる」という話でもありません。

合否は、エージェントの外で決める
承認は、人が持つ
権限は、既定で絞る

この 3 つは、HVE があってもなくても変わらない前提です。HVE をやめて減るのは「仕組みを自分で保守するコスト」であって、「統制の責任」ではない、というのが私の理解です。

万能ではありません。ただ、今の Copilot の機能と、薄い決定的ゲートの組み合わせで、現実的なところまでは来ていると感じています。

次にやることは、小さな業務アプリで Wave 1 と Wave 2 を 1 回ずつ通して、U1〜U9 を実際に測ることです。数字が出たら、閾値や運用の重さをもう一度見直します。

同じように自作のオーケストレータやエージェント基盤を抱えている方は、一度「それは本当に自分で持ち続ける必要があるのか」「必要なのは基盤ではなく、外側の検査ではないか」を切り分けてみると、見え方が変わるかもしれません。

参考資料

手元の調査レポート（非公開）

レポート	主に参照した内容
ATG の業務影響分析	ATG あり／なしの比較、推奨 Prompt、前提条件、失敗の仕組み
DAG・ATG 統合と小さなエンジンへの書き直しの調査	書き直しを推奨しない理由、律速の分析
長時間アプリ開発のハーネス設計（ATG 分析 v2）	`verify_command` 未実行による偽の PASS
ATG 単体移植ガイド	HVE の外での動作確認
ATG 技術解説	設計の妥当性
Opus 5.5 と Sonnet 5.5 のモデル比較	時間・完成率・隠しテスト
長時間タスクの分析	LLM 以外の時間の割合、文脈の肥大
タスク完了定義の調査	指示のテストと遵守の証明の違い
自律 Prompt の調査	継続には決定的な仕組みが要る
HVE Orchestrator レビュー	要件索引と決定的な検査の必要性
Work IQ の撤去調査	固定質問での検出率と結論
Microsoft Copilot Managed Runtime の採用調査	実行エンジンの置き換え可否
過去に作った 4 つのアプリの作業記録と Git 履歴	HVE・ATG の利用状況、開発期間、費用の要因
Copilot のセッション履歴の集計	稼働時間、AI の費用（AIU）、Premium Request
アプリ X の設計文書・システムテストの報告・Git 履歴	範囲、到達点、Workflow 別の費用、起きていた問題

公式文書（確認日: 2026-10-03）

GitHub Docs, "About GitHub Copilot cloud agent", https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent
GitHub Docs, "Risks and mitigations for GitHub Copilot cloud agent", https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations
GitHub Docs, "About Copilot automations", https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-automations
GitHub Docs, "Allowing GitHub Copilot CLI to work autonomously"（autopilot）, https://docs.github.com/en/copilot/concepts/agents/copilot-cli/autopilot
GitHub Docs, "Running tasks in parallel with the /fleet command", https://docs.github.com/en/copilot/concepts/agents/copilot-cli/fleet
GitHub Docs, "About hooks for GitHub Copilot", https://docs.github.com/en/copilot/concepts/agents/hooks
GitHub Docs, "GitHub Copilot hooks reference", https://docs.github.com/en/copilot/reference/hooks-reference
GitHub Changelog, "Research, plan, and code with Copilot cloud agent"（2026-04-01）, https://github.blog/changelog/2026-04-01-research-plan-and-code-with-copilot-cloud-agent/
GitHub Docs, "GitHub Copilot billing"（確認日 2026-10-05）, https://docs.github.com/en/billing/concepts/product-billing/github-copilot-billing

論文とベストプラクティス

本文の E1〜E24 の表に、発行元、題名、年、URL、確認の範囲を書いています。私が本文または要旨を直接読んだのは E2、E4、E6、E8、E9、E14 で、そのほかは調査用のサブエージェントが読んだものを、私が題名・URL・主張の対応だけ確かめています。