仕様先行型エージェント開発：AI駆動エンジニアリングのための新しいワークフロー

仕様先行型開発の基本原則

仕様先行型エージェント開発は、AIコーディングのパラダイムを、反復的なプロンプト入力から構造化されたゲートチェック方式のプロセスへと転換します。エージェントに対し、実装前にYAMLベースの仕様書を作成させることで、このワークフローは目標、制約、および「完了」の定義が既存のコードベースに対して明示的にレビューされることを保証します。このアプローチは、エージェントに提案する変更の根拠として特定のファイルやコード行を引用させることを強制することで、いわゆる「バイブ・コーディング（vibe coding）」によく見られる曖昧さを排除することを目的としています。

4段階のライフサイクル

すべての作業は、システムの整合性を維持するために設計された厳格な4段階のプロセスに従います：

create-spec: エージェントは、アプリケーションコードを一切書かずに、目標、必要な手順、および事実（ファイル/行の引用を含む）を定義します。
review-spec: 前回の会話履歴を持たない新しいエージェントインスタンスが、現在のコードベースに対して仕様書を評価し、潜在的な競合や不足している要件を特定します。
apply-spec: エージェントは、レビュー済みの仕様書に厳密に基づいて、コード、配線、およびテストを実装します。
deliver-spec: 変更はコミットゲートを通過し、プルリクエストが開かれる前にすべてのテストとビルド段階がパスすることを確認します。

並列実行と状態管理

開発をスケールさせるために、システムは仕様書ごとに個別のブランチとワークツリーを利用します。IDはシステムクロックから生成されるため、並行して動作するエージェントが衝突することなく異なる機能に取り組むことができます。状態は context.yaml ファイルに永続化されるため、中断後もエージェントは作業を再開できます。より大きな機能については、deliver-series コマンドを使用することで、開発者は複数の仕様書をグループ化し、依存関係が許す限り並列に構築して、単一のプルリクエストにマージすることができます。

副産物としてのドキュメント化

この手法の主な利点の一つは、プロジェクト履歴の自動生成です。エージェントは構築の過程で、自明ではないすべての決定をYAMLファイルに記録し、アーキテクチャ上の選択の根拠（例：なぜ特定のライブラリが他よりも選ばれたのか）をキャプチャします。これにより、コードと並行して存在するプロジェクトの進化の生きた記録が作成され、古くなったWikiドキュメントを別途維持する必要がなくなります。

コミュニティの視点と批判

このアプローチはエージェント主導のワークフローを管理する構造化された方法を提供しますが、コミュニティの議論では、現実の環境における仕様駆動型開発の有効性に関して、いくつかの一般的な懸念が指摘されています：

「コードこそが仕様である」という主張: 一部の開発者は、真に正確な仕様書は実質的にコードそのものであり、複雑なシステムを別のドキュメントで定義しようとすることは不必要なオーバーヘッドを生むと主張しています。
発見と反復: 批判的な意見として、多くの製品環境では要件が事前に完全には把握されていないことが挙げられます。あるユーザーは次のようにコメントしました： > 「問題は、ほとんどの製品ベースの決定において、事前に何を知らないのかさえ分からないことが多いということです。問題を修正するために仕様書を行ったり来たりするのは大きな間違いです。」
代替アプローチ: 「バイブ・コーディング」の支持者は、まず手早くプロトタイプを作成する方が要件を発見するのに効果的であり、それを最終的で洗練された実装の基礎として使用できると示唆しています。
ツールの比較: ユーザーは、このアプローチを既存のフレームワークである Spec Kit や BMAD と比較し、確立された代替手段と比較した際のこの実装の具体的な利点について疑問を呈しています。メンテナーは、このシステムの独自の価値は、ビルド前のレビューゲートとコミット段階のチェックの自動強制にあると強調しています。