Agentic Agile-V は、エージェント型のソフトウェア・ファームウェア・ハードウェア開発のためのプロセスフレームワークであり、Koch が Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ で提案した。これは 2 つの層からなる。マクロ層は Agile-V であり、各インクリメントが要求・設計・実装・検証・承認・監査証拠を通じて追跡可能な状態に保たれる反復的なライフサイクルである。ミクロ層は SCOPE-V であり、個々のエージェント型タスクごとに実行される 6 段階のループである。著者はこの分担を、Agile-V がライフサイクルを統制し、SCOPE-V がエージェント型タスクを統制するものとして述べ、この組み合わせをアジリティと検証のどちらかを選ばずに済ませる方法として提示している。すなわち、アジャイルの反復が速度をもたらし、V モデルの考え方が追跡可能性をもたらし、エージェントによる実行が実装能力をもたらし、検証ゲートが受け入れを決める。
用法
SCOPE-V ループの 6 つの段階は、Specify（仕様化）、Constrain（制約）、Orchestrate（統率）、Prove（立証）、Evolve（進化）、Verify（検証）である。Specify は意図を、目的・スコープ・非目標・影響を受けるモジュール・依存関係・受け入れ基準・必要な証拠を記したタスクブリーフに変換する。Constrain は境界を設定する — 承認なしに公開 API を変更しない、無関係なファイルに触れない、正当な理由なしに新しい依存関係を加えない、バグ修正中に広範なリファクタリングを行わない、セキュリティ上重要なコードには明示的なレビューを行う、ハードウェアのタイミングと安全上の制約を保持する。Orchestrate はエージェントがどう作業すべきかを定める。すなわち、まず調べ、現在の設計を要約し、計画を提案し、小さな単位で実装し、ローカルのチェックを実行し、残存リスクを添えた差分の要約を作成する。Prove は、単体テストや静的解析から、シミュレーション、形式的検査、ハードウェア・イン・ザ・ループの結果に至るまで、リスクに見合った証拠を求める。Evolve は、検証済みの学びをリポジトリの指示・テンプレート・テスト・ベースラインにフィードバックし、同時に古くなった指示や有害な指示を取り除く。Verify は最後の一回ではなく繰り返し行われるものとして扱われる — 実装の前、パッチ作成中、マージの前、デプロイの後、そして現場からのフィードバックの後である。
ループの前段には、著者が「会話から契約へのゲート」と呼ぶものが置かれている。会話は初期の不確実性に対しては適切だとされる — 要求の明確化、アーキテクチャのブレインストーミング、欠けている制約の特定、テスト戦略の比較、代替案の検討などであり、そこではエージェントは思考のパートナーとして振る舞い、望まれる出力はコードではなくより良い問題記述である。タスクが公開 API、安全性、セキュリティ、性能、ハードウェアの振る舞い、規制対象のワークフロー、顧客向けの振る舞い、共有ライブラリ、永続データに影響を及ぼすようになった時点で、構造化が必須となる。著者が述べる原則は、エージェントに長いチャットから実装させるのではなく、レビュー済みのブリーフから実装させよ、というものである。
受け入れは、要求事項が段階的に厳しくなる 4 つのリスクレベルによって統制される。スモークテストと任意のレビューだけでよい探索的な作業から、ルーチン層と本番層を経て、追跡可能な要求、独立したテスト、該当する場合にはシミュレーション・形式的検査・ハードウェア・イン・ザ・ループの証拠、そして明示的な承認を必要とする高保証の作業に至る。上位 2 つの層については、フレームワークが最低限の証拠バンドルを定めている。すなわち、タスクブリーフと要求識別子、エージェントの計画と影響を受けるファイル、実行したコマンドとテスト結果、残存リスクを添えた差分の要約、受け入れ基準からテストへのトレース、レビュアーの判断、そしてロールバックの手段である。
適用される場面
このフレームワークは、リポジトリを調べ、計画し、ファイルを編集し、テストを実行し、差分を生成できるエージェントと、会話的なプロンプトではなく構造化された入力を提供する意思のあるチームを前提としている — 著者は、意図とスコープ、受け入れ基準、アーキテクチャの文脈、制約、実行の文脈、証拠の要件、リスク区分をカバーする最低限の入力成果物パッケージを示しており、それと並行して、ボードのリビジョン、メモリマップ、クロック、ピン配置、ツールチェーンといったハードウェア上の対応物の列も設けている。このフレームワークは、著者が 検証負債 と呼ぶ失敗モードを真正面から狙っており、そのリスク層は、オーバーヘッドが一律に課されないようにするために存在する。探索的な作業は軽いままであることが意図されている。
その明示された限界は、著者が自らの証拠について引いているのと同じ線である。このフレームワークは検証済みの介入ではなく、統合的な整理とプロセスの提案である。著者は、複数のチーム、リポジトリ、ツール、ハードウェア領域にわたって実証的に評価されることを求めており、未解決の問いとして、構造化された実行ブリーフが会話的なプロンプトに比べて実際にエージェントの成功率を高めるのか、どのタスク区分がオーバーヘッドによって遅くなるのではなく恩恵を受けるのか、証拠バンドルが生産性の向上を失わせることなく検証負債を減らせるのか、を挙げている。リポジトリの指示について同フレームワークが採用する最小コンテキストの原則 — 短く、最新で、矛盾がなく、実行可能なフィードバックに結びついていること — も同様に、フレームワークそのものの測定からではなく、互いに矛盾する研究から導き出されたものである。
関連用語
Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ, 検証負債, バイブコーディング, 仕様駆動開発, AGENTS.md