数日前に エージェント的コーディング について書き、重要なスキルの変化は「うまく委任することを学ぶ」だと述べました。あの記事は「何をするか」についてでした。こちらは「どうやって」かという話です。なぜなら、コミュニティはAIコーディングエージェントと実際にどう作業すべきかを巡って、二つの全く異なる派閥に分かれているからです。
第一陣はこう言います：単に反復的にプロンプトを出すだけ。自分が望むものを説明し、エージェントにそれを作らせ、出力を確認し、必要に応じて修正する。会話的なやり取りを保つ。これを「雰囲気系コーディング（vibe coding）」と呼ぶ人もいますが、現時点ではその用語は有用性を超えて拡大されてしまったと私は思います。
二つ目の陣はこう言います：最初に詳細な仕様を書きましょう。作業を構造化された文書に分解します。要件、制約、アーキテクチャ、受け入れ基準を、エージェントがコードを一行も書く前に定義します。次に仕様をエージェントに渡して実行させます。
その第二のアプローチには今、名称があります。スペック駆動開発（spec-driven development）と呼ばれ、至る所に広がっています。GitHub は Spec Kit と呼ばれるオープンソースのツールキットをリリースし、72,000以上の星を獲得しています。AWS はこの概念を軸に Kiro という IDE 全体を作りました。Martin Fowler は自身のブログでこれについて書きました。Thoughtworks は深い分析を公開しました。この話題は過去1か月で Hacker News で3回もトレンド入りしており、昨日だけで1つの投稿が332点を記録しました。
誰もが一致しているようには見えない問い: これが実際により良いものなのか、それとも Waterfall（ウォーターフォール）開発手法が流行の新しい帽子をかぶっているだけなのか？
私はこの1週間、実際のプロジェクトでそれを試してみました。以下が私の所見です。
スペック駆動開発とは実際には何か
「スペック駆動開発」という用語はすでに意味があいまいに使われているため、定義を正確に説明します。
従来のソフトウェア開発では、何を作るかを考え、それを作ります。コードが真実の源泉です。文書化が存在する場合でも、それは二次的な成果物であり、通常は数週間で時代遅れになります。
スペック駆動開発はこれを反転させます。仕様が真実の源泉です。コードは仕様を実装する生成物です。コードと仕様が矛盾する場合は、仕様を直すのではなくコードを修正します。
実際の作業の流れは次のようになります:
仕様を定義する: 何を作るのか、なぜそれが必要なのかを明確に説明します。ユーザーストーリー、受け入れ基準、エッジケース、全体像。AIエージェントはこれを生成・洗練するのを手伝います。
計画を立てる: 技術的な制約を定義します。どのスタックを使うか、どのパターンに従うか、どのアーキテクチャ上の意思決定が重要か。エージェントは仕様と制約に基づいて実装計画を作成します。
タスク: 計画を具体的で検証可能な作業項目に分解します。各タスクには明確な入力、期待される出力、検証基準があります。
実装: コーディングエージェントは計画と仕様を文脈として、各決定を体系的に進めながらタスクをこなしていきます。
核心的な洞察は単純です。言語モデルはパターン完成には優れていますが、心を読むことは苦手です。与える文脈と構造が多いほど、出力は良くなります。詳細な仕様は非常に良い文脈に他なりません。
ウォーターフォール比較
経験豊富な開発者の多くがこれを聞くと最初に思うことはこうです。「待って。コードを書く前に網羅的な要件ドキュメントを作る？それをすでに試してみなかったか？それは見事に失敗しなかったか？」
その反応は完全にもっともです。ウォーターフォールモデルは何十年にもわたりソフトウェア開発を支配し、完全に前もってシステムを仕様できるという根本的に誤った仮定のもとで放棄されました。実際には、要件は変化します。ユーザーは何を望むかを、何かが動作して初めて知るのです。仕様と実装の間のフィードバックループこそが、真の理解が生まれる地点です。
スペック駆動開発は常にウォーターフォールと比較されます。Hacker News のスレッドには文字通りタイトルに「The Waterfall Strikes Back」がありました。比較自体が完全に間違いというわけではありません。
しかし、ここから意味のある形で分岐します。
ウォーターフォールでは、仕様と実装の間のフィードバックループは数か月に及びました。200ページにも及ぶ要件文書を作成し、それを開発チームに渡して、納品物を待つこと3〜6か月。実際に動くソフトウェアを見た頃には、要件はすでに間違っていました。
AIエージェントを用いたスペック駆動開発では、フィードバックループは数分です。仕様を書けば、エージェントが5〜15分で実装を生成します。レビューします。仕様が誤っているか不完全であれば、仕様を更新して再生成します。ウォーターフォールで数か月かかっていた全サイクルが、午後の間に完了します。
これは小さな差ではありません。カテゴリの差です。ウォーターフォールが失敗した理由は、仕様自体が悪いからではありませんでした。仕様を見つけ出すコストが壊滅的に高かったからです。更新された仕様からコードを再生成するコストがほぼゼロに近づくと、経済学が完全に変わります。
実際に試してみたこと
私には通知システムが必要なサイドプロジェクトがあります。特定のイベントについてアプリ内通知を受け取り、既読/未読の状態、通知設定ページ、重要なアラートのメール代替を備えるべきです。単純ではありませんが、非常に複雑というほどでもありません。実世界でのしっかりとしたテストです。
それを二つの方法で構築してみました。
アプローチ1: 反復的プロンプト
これは通常 Claude Code での私の作業方法です。通知システムを自然言語で説明し、既存のコードベースについての文脈を与え、作業させました。誤った仮定をしたときには、それを修正しました。自分が望まない方向に進んだときは、別の方法を試すように伝えました。
約45分程度のやり取りの後、結果は機能しました。コードはかなり良好でした。いくつかの点は手動での整備が必要でした。エージェントが私のデータベーススキーマについていくつか誤った仮定をしたため、通知設定UIについて二度の軌道修正を余儀なくされました。
総じて：問題なし。実際のものを出荷しました。プロセスは自然に感じられました。
アプローチ2: スペック駆動
Spec Kit のワークフローを簡略化したバージョンを使いました。最初に仕様書を作成しました：どの通知が存在するか、いつトリガーするか、データモデルはどうなるか、設定はどう機能するか、メールのフォールバックのロジック。各機能に対して受け入れ基準を含めました。技術的制約を明記しました：既存のデータベース ORM を使用、既存の API パターンに従う、現在の UI コンポーネントライブラリに合わせる、です。
次に、全仕様を Claude Code に渡して実装させました。
初期実装は約12分かかりました。最初の段階で明らかに優れていました。データベーススキーマは私が望んだものと一致しました。APIエンドポイントは私が軌道修正をすることなく、既存のパターンに従いました。通知設定UI は適切なコンポーネントを使用しました。
まだ清掃作業が必要でした。メールテンプレートのレンダリングにバグがありました。バッチ通知のマーク付けに関するエッジケースが一つ未処理でした。しかし、やり取りの量は劇的に少なくなりました。
ただし、仕様を書くのに約30分かかったことです。したがって総時間はほぼ同じでした。
スペック駆動開発が勝る点
両方の手法を試し、コミュニティの議論を多く読んだ後、私が考えるにSDD（スペック駆動開発）は本当にその価値を発揮する点は次の通りです。
複数の貢献者がいるチームプロジェクト。 ソロで作業している場合、コンテキストが頭の中にあるため、反復的プロンプティングは問題なく機能します。3人の開発者が同じコードベースでAIエージェントを使う場合、「完了」がどのように見えるかを定義した共有の仕様があることが有用です。これはエンジニアリングチームが設計文書を書くのと同じ理由で、AI 向けに整形されたものです。
多くの連動部品を持つ複雑な機能。 通知システムは中程度に複雑でした。相互に結びついた10個のコンポーネントのようなものでは、相互の関係を定義する仕様があると、エージェントがシステムの異なる部分で一貫性のない判断を下すのを防ぎます。仕様は一貫性のアンカーになります。
レガシーコードベースとブラウンフィールドプロジェクト。 既存のパターンと規約が確立されているシステムに機能を追加する場合、"Xファイルのパターンに従う"、"既存のYサービスを使用する" などを明示的に示す仕様は、エージェントが自分自身のアプローチを発明する傾向を劇的に減らします。これは私が最も大きな利点と感じた点です。仕様駆動アプローチは、既存のコードベースにふさわしく見えるコードを生み出しました。反復的アプローチは動作するコードを生み出しましたが、やや違和感がありました。
引き継ぎと非同期作業。 日中に仕様を書き、夜間にエージェントを走らせる場合（これは エージェント的コーディングの記事 でも触れたことです）、十分に定義された仕様を持つことで夜間実行ははるかに信頼性が高くなります。エージェントは、明確化の質問をする能力なしに、必要なすべてを手にしています。
どこで崩れるか
SDD の欠点についても正直にお伝えしたいです。SDD の話題性が少し過熱しているからです。
仕様の保守は実質的なオーバーヘッドです。 仕様と実装の両方を持つと、それらを同期させる必要がある二つの要素が生じます。要件が変更されると（必ず変更されます）、コードを更新する前に仕様を更新することが摩擦を生みます。自動的に仕様とコードを同期させようとするツールもありますが、それもまだ完璧なプロセスではありません。
小さなタスクには忙しい作業のように感じられることがあります。 バグ修正や小さな機能の詳しい仕様を作成するのは過剰すぎます。すべてのタスクに正式な仕様が必要というわけではありません。オーバーヘッドと価値の比率は、特定の複雑さの閾値を超える機能に対してのみ意味を成します。
エージェントは仕様に必ずしも従うとは限らない。 これは私の実験で最も苛立たしい点でした。詳しい仕様があっても、エージェントは時折制約を無視したり、私が明示的に指定した事柄について自分で判断を下すことがありました。仕様は成功率を改善しましたが、遵守を保証するものではありませんでした。それでもすべてを確認する必要があります。レビュープロセスはなくなりません。
仕様を過剰に決めてしまうことはある。 仕様を完璧にするのにあまりにも時間を費やして、結局全体の時間を無駄にしてしまうリスクがあります。私自身、これをやってしまうところでした。現実的には、反復的なプロンプトを使えばその場で対処できただろうエッジケースの受け入れ条件を作成していました。仕様は準備として偽装した先送りツールになってしまいました。
それはドメイン知識を置き換えるものではありません。 SDDを非開発者が仕様を書くだけでソフトウェアを構築できるようにするものだと主張する人もいます。それは誤解を招くものです。良いデータベーススキーマがどういうものかを知っている必要があります。APIパターンを理解している必要があります。エージェントの出力に微妙なバグがあるかを見抜く必要があります。仕様はコミュニケーションツールであり、専門知識の代替ではありません。
ツールの動向
仕様主導型開発に関するツールは急速に進化しています。現在利用できるものは次のとおりです：
GitHub Spec Kit は最も人気のあるオープンソースのオプションです。specify、plan、tasks、implement の各サイクルのテンプレートとワークフローを提供します。 Claude Code、GitHub Copilot、Amazon Q、Gemini CLI などを含む22以上のAIエージェントプラットフォームをサポートしています。72,000件以上のスターを獲得しており、コミュニティの勢いが本格的です。
AWS Kiro は、仕様主導のワークフローを中心に構築されたIDEです。Constitution（構成）、Specify、Plan、Tasks、Implement、PR のようなステップで完全な仕様ライフサイクルをエンコードします。すでに AWS エコシステムにいる場合は、検討する価値があります。
Tessl は、フレームワークとレジストリのアプローチでそれをさらに進めます。仕様のための npm のようなものと考えてください。チーム間で仕様テンプレートを公開・共有できます。
CLAUDE.md と AGENTS.md ファイル は、現在多くの開発者がSDDを仕様駆動開発と呼ぶことなく使っている、SDDの低技術版です。毎回のセッションでエージェントが読むマークダウンファイルに、詳細なプロジェクトコンテキスト、規約、制約を記述することは、構造的には同じアイデアです。ただし正式度が低いだけです。
CLAUDE.md ファイルをすでに効果的に使用している場合は、すでに仕様駆動開発の軽量な形を実践しています。公式ツールは、本質的には同じ原則の上に構造とワークフローを付加します。すなわち、エージェントにより良い文脈を提供すれば、より良いコードを得られるということです。
コンテキストエンジニアリング: 大局像
仕様駆動開発は、注目を集めているより広い分野、コンテキストエンジニアリングの一部です。
コンテキストエンジニアリングは、AIエージェントが動作する情報環境全体を編成する実践です。 それには、エージェントが読むファイル、従うルール、保持する履歴、到達できるツール、そしてナビゲートするプロジェクトの構造が含まれます。Martin Fowler は、コーディングエージェントの文脈でこれについて書きました。2025年半ばまでには、AIコーディングエージェントが信頼性の高いコードを出荷するか、費用のかかる技術的負債を生むかを決定する規律として呼ばれるようになっていました。
この点が重要なのは、仕様は文脈の一種に過ぎないということです。出力品質に影響する他の文脈には、以下が含まれます：
- プロジェクトの規約（ファイルの命名方法、インポートの構造、使用するパターン）
- アーキテクチャ上の意思決定（なぜこのデータベースを選んだのか、なぜAPIがこのように構成されているのか）
- チームの知識（以前試してうまくいかなかったこと、ビジネス要件から生じる制約）
- コードベースの記憶（以前のセッションからエージェントが学んだこと）
仕様駆動開発は、文脈の「要件」部分を形式化します。しかし最高の結果は、仕様だけでなく、すべての形式の文脈を正しく整えることから生まれます。
この点から、SDDの議論は有用ですが不完全だと私は考えています。プロジェクトの規約、アーキテクチャ的文脈、コードベースの記憶を無視し、完璧な仕様に没頭することは、キッチンの在庫をそろえる代わりに詳細なレシピを書き残すようなものです。仕様は重要ですが、それだけが重要なわけではありません。
私の正直な見解: ケースバイケース（ただし、以下の場合に限る）
試してみて読んだ上で、私の実践的な推奨は次のとおりです：
仕様駆動開発を使うときには:
- その機能が、いずれ設計文書を作成するほど複雑である場合
- 複数の人やエージェントが同じ機能に取り組む予定がある場合
- 既に大規模な既存コードベースで、確立されたパターンがある場合
- 作業を非同期で実行するために委任している場合（例: 夜間のエージェント実行）
- 実装決定の“理由”をとらえた、レビュー可能な成果物がほしい場合
仕様を省略して反復する場合:
- タスクが小さく、よく理解されており、何を望んでいるかが分かっている場合
- プロトタイピングや探索をしており、まだ適切なアプローチが分かっていない場合
- 深く理解しているプロジェクトを一人で取り組んでいる場合
- 初回の誤りのコストが低い場合（安価に再生成できる）
Never do:
- 方法論に従うためだけに仕様を書くのは避けてください。仕様がエージェントにとって真に有用な文脈でない場合、それは無駄な労力になります。
- 仕様を保証として扱わないでください。仕様がなくても出力を厳密にレビューしてください。
- SDDを自分のコードベースを理解する代替手段として使わないでください。エージェントの出力が正しいかどうかを評価できない場合、どんな仕様もあなたを救えません。
誰も尋ねていない本当の質問
ここに、方法論の議論の下で、SDD 議論が実際には何についてのものであると私は考えるかがあります。
私が考えるに、SDD 議論は、方法論の議論の下にある、実際には何についてのものであるかです。
私たちは、AIコーディングエージェントと協働する方法を見つけ出している移行期にあります。ツールは強力ですが、新しい種の対話パターンを必要とします。構造を重視する人もいれば、構造を抑える人もいます（仕様、計画、正式なワークフロー）。一方、反復的プロンプティング、対話的開発、雰囲気コードのような構造を減らす方向を好む人もいます。
Neither is universally right. The optimal approach depends on the task, the team, and the codebase. The developers who will be most effective are those who can fluidly move between structured and unstructured approaches based on what the situation calls for.
That is not a satisfying answer for people who want a methodology to follow. But it is the honest one.
Spec-driven development is a useful tool in the toolbox. It is not the only tool. And calling it Waterfall 2.0 misses the point as badly as calling it the future of all software development.
The future is probably messier and more pragmatic than either camp wants to admit. And I am fine with that.
Getting Started If You Want to Try It
If you want to experiment with spec-driven development, here is a low-friction way to start without adopting a full framework:
Pick a feature you are about to build. Something with at least three or four moving parts.
Before prompting your AI agent, write a markdown document that covers: what you are building, why, what the user experience should be, what technical constraints exist, and what "done" looks like.
Hand that document to your agent along with the implementation request. Compare the output quality to what you normally get with iterative prompting.
If the output is meaningfully better, gradually formalize the process. If it is not, your iterative approach is probably working well enough for your use case.
You do not need Spec Kit or Kiro or any specific tool to try this. A markdown file and your existing agent are enough. The value is in the thinking you do while writing the spec, not in the tooling around it.
Start small. See if it helps. Adjust from there. That is how every useful methodology actually gets adopted, regardless of what the thought leaders say.
