8月21日、Stack Overflowが「Dispatches from O'Reilly: The right amount of spec for agentic development」と題した記事を公開した。AIエージェントを活用した開発において「どれだけ仕様を書くべきか」という問いと、その最適解について詳しく論じた内容だ。
「仕様はいらない」は幻想だ
AIエージェントによるコード生成が当たり前になりつつある今、「大まかなゴールを渡してあとはモデルに任せればいい」という考え方が広まっている。実装が安くなったのだから、仕様書に時間をかけるのは旧時代の無駄だ、という論法だ。
記事はこの考え方を真っ向から否定する。
「仕様ゼロはインテリジェントでもリーンでもない。コストの高いバイブコーディングだ」
バイブコーディング（vibe coding）とは、ゴールだけを曖昧に伝えてAIに丸投げするコーディングスタイルのことだ。曖昧なプロンプトを渡しても実装は始まる。問題はそのあとだ。出力をレビューし、意図を補足し、修正を依頼し、テストを再実行し、また次のギャップを見つけて……という補正ループが延々と続く。そして誰かが「これは本当に目的に合っているか」を判断しなければならない。その人間が「オラクル（正解の判定者）」になる。
オラクルとはソフトウェアテスト用語「テストオラクル」に由来する概念で、ある出力が正しいかどうかを判定する主体や基準を指す。エージェント開発では、その役割が自動化されず人間に残り続ける。
人間がオラクルになるコストは、詳細な仕様を最初に書くコストより安いとは限らない。
コードが安くなると、何が難しくなるか
記事が提示するフレームワークはシンプルだ。実装の自動化が進むほど、「正しい」とはどういう意味かを決めることとそれを確認することが、エンジニアリングの主な難しさになる。
旧来の世界では、曖昧な要件は「人間の遅さ」という壁にぶつかっていた。レビュアーがエッジケースに気づき、QAが誰も説明しなかったパスを見つけ、シニアエンジニアが暗黙の要件を会議のたびに翻訳していた。非効率だったが、それが曖昧さを強制的に表面化させていた。
エージェントはそのブレーキを取り除く。「曖昧な要件が、誰も合意していないうちにもっともらしいシステムになってしまう」のがエージェント時代の構造的なリスクだ。
仕様そのものをレビューする
記事が特に強調するのが「仕様のバリデーション」という工程だ。多くのチームが見落としているステップだという。
仕様書のよくある失敗パターンは以下の通りだ：
- ハッピーパスだけ記述し、リトライ・レート制限・部分失敗について何も言わない
- 一見精密に見えるが実際には検証不能な動作を記述している
- 書いた内容は正確だが、意図とズレている
エージェントが欠陥のある仕様を忠実に実行すると、失敗の診断が難しくなる。実装は一貫して見え、提供したテストすら通過するかもしれない。しかし問題の根は仕様の上流にある。
そこで記事が提案するのは、エージェントを使った仕様のレビューワークフローだ：
まず最小仕様を書かせるプロンプト：
別のエージェントがこれを安全に実装できる最小の仕様を作成してください。前提、非ゴール、受け入れ基準、エッジケース、観測可能な成果、未解決の問いを含めてください。どのクレームが自動テストになれるか、どれが人間のレビューを必要とするかを明示してください。
次に、別のエージェントに攻撃させる：
矛盾、曖昧な用語、隠れた依存関係、テスト不能なクレーム、欠落した失敗モード、文字通りに実装しても意図を違反できる箇所を見つけてください。
この2ステップだけで、人間が判断する価値のある仕様に到達するコストを大きく下げられる。
仕様量の最適解は「作業の種類」で変わる
記事は「適切な仕様量は一つではない」と結論づけ、作業の種類ごとに最適点を整理している。
- 単一の小規模タスク：ゴール・例・非ゴール・受け入れ基準の「構造化された意図」で十分
- CRUD・API統合・データ変換などの決定論的な作業：BDDやコントラクトテスト、実行可能な受け入れ基準が効く。仕様に投資するほどレビューと手戻りが減る
- アーキテクチャ検討・調査合成などの探索的な作業：過剰仕様は柔軟性を殺す。成果よりも「何が真でなければならないか」「何が起きてはいけないか」という境界を仕様化すべきだ
- マルチエージェントパイプライン：エージェント間のすべての境界にコントラクトが必要。スキーマ、不変条件、バリデーションルール、明示的な失敗動作が求められる
マルチエージェントの場合が特に厄介だ。エージェントAが要件を10%誤解していても、エージェントBはその出力を事実として扱って処理を続ける。人間が結果を見る頃には、最初のミスが「有能に見える作業」の複数レイヤーの下に埋もれている。
過剰仕様もまた問題だ
記事は「仕様が多ければ多いほど安全」という誤解も指摘する。
ChromaのContext Rotに関する研究が示すように、コンテキスト長が増すほど中間に位置する情報の想起精度が低下し、モデルのパフォーマンスは不安定になる。さらにコーディングプロジェクトでは、設計のプロズ・サンプル・チケット・古い受け入れ基準が蓄積すると、何が「指示」で何が「アーティファクト」なのかが不明確になる。セキュリティ的な意味でのプロンプトインジェクションではなく、「自己誘発的な指示のドリフト」だ。
設計ドキュメントはコードが存在しない初期に価値があるが、インターフェース・テスト・不変条件が実装された後は縮小すべきだ。クラスやメソッドがすでに表現していることを繰り返すだけのプロズは削除する。そうしないと「2つの仕様」が生まれ、エージェントは両方に従おうとする。
共通ルール：実装をスケールする前に仕様を検証する
4つの作業タイプすべてに通じる原則は一つだ。
「実装をスケールする前に、仕様をバリデートせよ」
記事によれば、エージェントは従来の開発プロセスを無意味にするわけではない。ただし「人間の作業を時間単位で調整するためだけに存在していた儀式」は意味を失う。デイリーステータス会議、膨らんだバックログの儀式、根拠の薄い見積もりは、エージェントがコードを書いたからといって強化されない。
一方で生き残るのはフィードバックの論理だ。短いサイクル、薄い垂直スライス、顧客レビュー、テストファースト、継続的インテグレーション——これらはエージェント時代においてむしろ重要性が増す。エージェントは「確信に満ちた間違い」を大量に高速で生成できるからだ。
詳細はDispatches from O'Reilly: The right amount of spec for agentic developmentを参照していただきたい。
