7月17日、O'Reillyが「The Right Amount of Spec for Agentic Development」と題した記事を公開した。AIエージェントで「仕様書はもう要らない」という空気が広がるなか、「ゼロ仕様は安くない」という逆説から出発し、ボトルネックの移動・マルチエージェント間の「契約」概念・仕様の賞味期限まで、実装コストが激減した時代に仕様を書く意味を根本から整理した内容だ。特に「あいまいなアイデアが機械の速さで"もっともらしいシステム"に化ける」という洞察は、エージェント開発に携わる全エンジニアにとって一読の価値がある。
AIエージェントで「仕様書はもう要らない」という空気が広がっている。大まかな目標を与えて実装を任せ、出力を修正して進める——確かに素早く動けるように見える。だが、その「安さ」は幻想だとこの記事は指摘する。
「ゼロ仕様」は安くない
仕様なしでエージェントに実装させると、何が起きるか。レビューして、意図を補足して、変更を依頼して、テストを再実行して、次のギャップを見つけてまた繰り返す。結果が本当のゴールに合っているかを判断するのは、結局のところ人間だ。その人間が「オラクル（正解判定者）」になる。
逆に、**BDD（振る舞い駆動開発）**シナリオや受け入れテストまで書き込む「フル仕様」は初期コストが高い。しかし、テストは同じ条件を何度でも、疲れることなくチェックできる。「オラクルの一部が実行可能になる」というのが本質的な利点だ。
ゼロ仕様はインテリジェントでもリーンでもない。コストの高い「vibe-coding」に過ぎない。
vibe-codingとは、明確な仕様や設計なしに「なんとなくの雰囲気」でAIに実装を任せ続けるスタイルを指す造語だ。短期的には高速に見えるが、意図との乖離が検証されないまま蓄積する。
最小コストの落としどころは中間地点にある。作業を制約するだけの構造、意図を具体化するための例示、そしてレビューが「推測ゲーム」にならないための実行可能なチェック——この3つが揃えば十分だ。
ボトルネックは消えたのではなく、移動した
エージェントが実装を劇的に安くした。問題は、あいまいなアイデアが「もっともらしいシステム」に化けるスピードも上がったことだ。
旧来の開発では、仕様のあいまいさは人間の遅さにぶつかって自然に露呈した。レビュアーがエッジケースに気づき、QAが誰も書かなかったパスを踏む——あれこれ非効率でも、あいまいさを表面化させる機能があった。
エージェント開発では、あいまいな要件が機械の速さにぶつかる。仕様が重要なのは昔も今も変わらない。ただ、実装コストが高かった時代は、そのコスト自体が「強制的な仕様の明確化」として機能していた。
実装が安くなるにつれ、「正しい」の定義とその検証に困難が集中する
仕様を書いただけでは足りない
見落とされがちなステップがある。「仕様自体のレビュー」だ。
丁寧に書いた仕様でも、内部矛盾する、ハッピーパスしか書かれていない、リトライやレートリミットの記述がない、「正確だが意図と違うことを言っている」——こうした問題は珍しくない。欠陥のある仕様を忠実に実行されると、失敗の診断が難しくなる。実装は一見まともに見え、提供したチェックすら通過するかもしれない。問題は仕様の上流にある。
記事では、エージェントを使った仕様検証の具体的なプロンプトが提示されている。
まず仕様草案を生成させる際はこう指示する：
「別のエージェントが安全に実装できる最小の仕様を作れ。前提条件、非ゴール、受け入れ基準、エッジケース、観測可能なアウトカム、未解決の問いを含めること。自動テストにできる項目と人間のレビューが必要な項目を明示すること。」
次に、別のエージェントに攻撃させる：
「矛盾、あいまいな用語、隠れた依存、テスト不能な主張、欠落した失敗モード、書かれた基準を満たしながら意図を違反できる実装の余地を見つけよ。」
このツーステップだけでも、人間の判断を投入する価値のある仕様に到達するコストを下げられる。
マルチエージェントでは「契約」が必要になる
単一エージェントなら、ルーズな指示からの逸脱は人間がすぐ気づいて修正できる。マルチエージェントパイプラインでは話が違う。
エージェントAの出力がエージェントBの入力になると、解釈のズレが連鎖的に増幅する。BはAが要件を10%誤解していたことを知らない。出力を正しい情報として扱い処理を続ける。人間が結果を見た時点では、最初のミスが複数層の「一見まともな作業」の下に埋もれている。
この状況では、仕様は「ガイダンス」ではなく「契約」だ。スキーマ、不変条件、許容されるあいまいさの範囲、バリデーションルール、明示的な失敗時の動作——これらが必要になる。エージェント間のハンドオフは、れっきとしたインターフェースとして設計・検証される対象だ。
エージェント間のハンドオフは、実インターフェースと同様に仕様化・検証が必要だ
仕様には「賞味期限」がある
仕様を増やし続けるのも危険だ。Chromaのcontext rot研究が示すように、コンテキストが長くなるほどモデルの性能は単純なタスクでも不安定になる。
さらに、設計ドキュメント、古い受け入れ基準、3セッション前のプラン、すでに存在しないクラスを説明するSDD——こうしたものがコンテキストに混在すると、モデルはどれが「現在の指示」でどれが「過去の記録」かを判断できなくなる。セキュリティ的な意味のプロンプトインジェクションではなく、「自己誘発的な指示のドリフト」だ。
設計ドキュメントはコードが存在しない初期に有用だ。インターフェース、テスト、不変条件が実装に落とされた後は、詳細なビルドプランは削っていくべきだ。コードがすでに表現していることを散文で繰り返すのは、2つの「仕様」を作るだけで、エージェントは両方に従おうとする。
タスク種別ごとの最適解
記事は、仕様量の最適値はタスクの種類で変わると整理している。
- 小さく境界が明確なタスク：ゴール、数例の例示、非ゴール、受け入れ基準で十分
- 決定論的な作業（CRUD、API連携、データ変換）：仕様を厚くするほど効果が高い。BDD、契約テスト、実行可能な受け入れ基準が最も効く
- 探索的な作業（アーキテクチャ検討、調査）：仕様を厚くすると柔軟性が死ぬ。アウトカムではなく「境界条件」を仕様化する
- マルチエージェントパイプライン：エージェント間の境界すべてに契約が必要
どのケースにも共通するルールは1つ：「実装をスケールさせる前に仕様を検証せよ」だ。
詳細はThe Right Amount of Spec for Agentic Developmentを参照していただきたい。
