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