仕様駆動型開発 vs バイブコーディング：ウォーターフォール？

仕様を唯一の正解とするのか、それとも遅い儀式とするのか

目次

仕様駆動型開発（SDD）は、2026年において「バイブコーディング（Vibe Coding）の逸脱」に対する真面目な開発者の回答として登場しました。

その論理はシンプルです。AIエージェントは、アドホックなプロンプトではなく、レビュー済みの仕様書に対して実装を行うことで、より良質で一貫性のある出力を生成します。理論的にはこれに反論するのは難しいでしょう。

しかし現実には、Hacker Newsではこれを「ウォーターフォールが再び襲来した」と評しました。

両陣営とも、それぞれの立場には一理あります。

Spec-Driven Development versus Vibe Coding

バイブコーディングの世界におけるSDDの意義

バイブコーディング――すなわち、緩やかなプロンプトを入力し、AIエージェントが生成する結果を繰り返して手直ししていく実践――は、小規模で探索的、あるいは使い捨ての作業において驚くほど効果的です。2025年の最初の6ヶ月間、これがAIコーディングの主流パターンでした。開発者たちは、かつてない速さでスクリプト、プロトタイプ、シンプルなツールをリリースしました。

しかし、プロジェクトは成長しました。複数ファイルにまたがる機能は次第に本来の意図から逸脱し始めました。セッション1で確立された制約は、セッション3には忘れ去られていました。セキュリティ上の前提条件が軽視され、アーキテクチャ上の決定は機能の中途半端な段階で変更されました。それはエージェントに意図に関する永続的な記憶がなかったためです。

仕様駆動型開発（SDD）は、この状況に対する規律ある対応策として現れました。その核心的な主張は、プロンプトではなく「仕様書」を中央のアーティファクト（成果物）とすることです。まず要件、設計、タスク計画を記述します。エージェントに、それらのアーティファクトを基準に1スライスずつ実装させます。仕様書のバージョン管理と更新を維持します。

AIコーディングツール――GitHub Spec Kit、Kiro、BMAD、そして拡大を続けるClaude Codeのカスタムワークフロー群――はすべて、このアイデアの実装です。ツールは実在します。関心は実在します。しかし反発もまた実在します。

バイブコーディングが得意とする領域

バイブコーディングを否定する前に、それが本当に効果を発揮する領域を正確に理解しておく価値があります。

探索的なプロトタイピング。 何を構築すべきか確信がない場合、最も早い方法はラフなものを作り、その結果に反応することです。SDDには何を指定すべきかを知る必要があります。まだわからない段階では、仕様書は早計すぎます。

UI実験。 視覚的なレイアウトやインタラクションの感覚は、事前に仕様として定義するのが難しいものです。バイブコーディングなら、選択肢を迅速に見て、大半を破棄し、実際に正しいと感じるものへ収束させることができます。ここで要件定義書は役に立ちません。

使い捨ての自動化。 使い切りスクリプト、データ抽出ジョブ、移行ヘルパー――これらは設計文書が必要になることは稀です。少し間違えたコストは低く、ゆっくりとした儀式的なプロセスのコストは現実的です。

迅速なフィードバック。 何かを素早く学びたいとき――例えば、このAPIは自分が想像している通りに動くか？――バイブコーディングは学習ループを分単位に短縮します。SDDはそのような場合、何の利益もなくスピードを落とします。

間違いは、これらの文脈での成功パターンを、実際の制約、実際のユーザー、そして誤りの重大な結果が存在する本番機能に適用してしまうことです。

バイブコーディングが破綻する場所

バイブコーディングは、スコープと賭けられるものが大きくなるにつれて、予測可能な形で劣化します。

複数ファイルの変更。 機能が5つ以上のファイルをまたぐようになると、エージェントのコンテキストウィンドウは不変条件を追跡できなくなります。設計文書がない場合、各プロンプトは過去のセッションで確立され忘れてしまったコンテキストを再構築する必要があります。

アーキテクチャの逸脱。 明確な非目標（non-goals）がない場合、エージェントはとにかく実装を進めます。エージェントは理にかなっているように思ってキャッシュレイヤーを追加します。3セッション後、そのキャッシュの前提はデータモデルに焼き付けられ、それを撤去するのは高コストになります。

忘れられた制約。 「認証済みユーザーのみがこのトリガーを実行できる」というのは、要件定義書の一節です。バイブコーディングのセッションでは、それはセッション1で一度言及されただけで、セッション4で新しいエンドポイントを書く際にエージェントが覚えていません。

隠れたセキュリティ前提。 認可ルール、入力検証の境界、シークレットの扱い――これらは、エージェントが「正しくて制約されたコード」ではなく「あり得る動作するコード」を最適化している際に、見落とされがちな暗黙の要件の典型です。

チームへの引継ぎ。 イテレーティブなプロンプティングで構築した場合、何が決まり、なぜそう決めたかを記録するアーティファクトは……gitログです。それでは難しいでしょう。

仕様駆動型開発（SDD）が変えるもの

SDDはイテレーション（反復）を排除すると主張していません。良いSDDは明らかにイテレーティブです。変えるのは、イテレーションが行われる場所です。完全な定義――TDD、BDD、形式手法との違いを含む――については What Is Spec-Driven Development? をご覧ください。

コードをイテレーションして差分から意図を推測するのではなく、仕様書をイテレーションしてから実装します。仕様書は、何が決まり、なぜそうし、何はスコープ外かを記録するアーティファクトとなり、 Architecture Decision Records と似た機能を果たしますが、システムレベルの選択ではなく機能の意図を中心に据えています。コードはその意図を実装します。

典型的なSDDワークフローは5つのフェーズを通ります：

仕様書作成（Specify）。 問題定義、ユーザー、目標、非目標、受け入れ基準、未解決の質問。

計画（Plan）。 アーキテクチャ決定、影響を受けるモジュール、データモデル、API契約、セキュリティ懸念事項、テスト戦略。

タスク分解（Task breakdown）。 明確な検証基準と人間のレビューチェックポイントを持つ、小さな実装スライス。

実装（Implement）。 1つのタスクずつ、タスク間のコンテキストリセットを行い、仕様からの制約を適用し、現実が設計と異なる場合は計画を更新する。

検証（Validate）。 テスト、lint、型チェック、受け入れ基準、仕様書からコードへの差分。

エージェントは大部分のフェーズ（仕様書のドラフト作成、設計の生成、タスクの提案など）に関与しますが、実装開始前に人間がアーティファクトをレビューします。このレビューステップが、SDDとバイブコーディングの中心的な違いです。

開発者がそれをウォーターフォールと呼ぶ理由

ウォーターフォールへの批判は間違っていません。ただし、それはSDD自体ではなく、悪いSDDを標的にしています。

特定の失敗モードは、長すぎる事前計画です。ウォーターフォールの定義的な特徴は、フィードバックループが数週または数ヶ月にわたることです：要件フェーズ、設計フェーズ、構築フェーズ、テストフェーズ、出荷。フィードバックは遅く届きます。設計の前提が間違っていたことに気づいた時には、すでに数週間その上で構築していました。

開発者がSpec Kitを使って1行のコードも書く前に200行のタスクリストを生成し、エージェントが何かに触れる前に2日間も要件定義書を磨き上げている場合、それはウォーターフォールです。UMLではなくマークダウンを使っていますが、失敗モードは同一です。

あるHN（Hacker News）のコメント投稿者は、小さなCLIツールにSpec Kitを使い、「コードを見る前に調整が多すぎ、遅すぎる」と感じたことを述べています。それが悪いバージョンです。そのユーザーは、そのタスクに対してそれを拒否する権利がありました。

有用な批判は「仕様書が悪い」ことではありません。「フィードバックを得るための事前計画が長すぎることは悪い」ことです。これらは異なる主張です。

有用な中間地帯

良いSDDは、仕様書を小さく保ち、実装を早期に開始することでウォーターフォールの罠を回避します。

小さな仕様書。 単一機能の要件定義書は、画面1枚に収まるべきです。仕様書が10ページもあるなら、それはプラットフォーム設計か、小さな機能に分割する必要があります。大きすぎる仕様書はレビューに時間がかかり、すぐに陳腐化します。

短いタスクスライス。 各タスクは、単一のエージェントセッションで実装可能で、小さな差分としてレビュー可能、かつ孤立してテスト可能であるべきです。タスクが大きすぎる場合、実装ループが伸び、仕様書からコードへのマッピングが検証しにくくなります。

早期実装。 最初のタスクの仕様を作成し、実装し、検証し、次に進みます。何も実装する前にすべてを仕様定義しないでください。最初の実装は、仕様書で間違っていたものを明らかにします。続行する前に仕様書を更新します。

生きた仕様書（Living spec）。 現実が設計と異なる場合――それは必ず起こります――コードだけでなく仕様書も更新します。仕様書は実際に構築されたものを反映している場合にのみ有用です。

テストとしての実行可能なフィードバック。 各受け入れ基準は少なくとも1つのテストに対応すべきです。テストスイートは仕様書の機械可読版です。仕様書に「認証済みユーザーのみがこのトリガーを実行できる」とあるなら、認証されていないリクエストが拒否されることを検証するテストが存在すべきです。

このハイブリッド――小さな仕様書、短いタスク、早期実装、生きたドキュメント――が実際に機能するものです。それはバイブコーディングでもなく、ウォーターフォールでもありません。それは持続可能なアーティファクトを持つ制御されたイテレーションです。

SDDがバイブコーディングを凌駕する場面

誤りのコストが現実的な場合、SDD――たとえ軽量なSDDでも――を使用します。

リスクの高いビジネスロジック。 課金、権限、データ移行、冪等性――誤った動作が高コストまたは逆転困難なあらゆるロジック。バイブコーディングはこれらの要件を暗黙のものとします。SDDはそれらを明示的かつ実装前にレビュー可能にします。

本番APIの変更。 パブリックまたは内部のAPI契約に対する変更には、設計文書が必要です。設計文書は、呼び出し側を破壊するコードをエージェントが書く前にレビューするものです。

マルチエージェントワークフロー。 複数のエージェントが機能の異なる部分を実装する場合、仕様書は真の共有ソースです。それがないと、各エージェントは局所的に最適化し、部品がフィットしない可能性があります。

チームへの引継ぎ。 別の開発者または別のエージェントがこの作業を継続する場合、仕様書は引継ぎアーティファクトです。gitログとREADMEだけでは不十分です。

大規模なリファクタリング。 コア抽象化に触れるリファクタリングには、何が同じでなければならないか（挙動）、何が変更されてもよいか（構造）という明確な記述が必要です。それがないと、エージェントは保持すべきだと思っていた契約を壊す可能性があります。

バイブコーディングが依然として優れる場面

SDDはオーバーヘッドです。時として、オーバーヘッドは価値がありません。

クイックスクリプト。 ファイルのリネームやJSONの変換を行う50行のスクリプトに要件定義書は必要ありません。プロンプトを書いて、出力を確認し、リリースします。

実験。 アプローチの可行性を学んでいる場合――APIの探索、ライブラリのテスト、仮説の検証――必要なのは構造ではなく速度です。まず実験し、実験が成功したら仕様定義します。

UIスケッチ。 インタラクションデザインは、指定するよりも見ることで恩恵を受けます。いくつかのラフなバリエーションを素早く構築し、目にしたものに対応し、実際に出荷するものだけを仕様定義します。

使い捨ての自動化。 1回限りのスクリプト、データインポート、移行ヘルパー――少し間違えた結果のコストは通常低く、アーティファクトは使用後に削除されるものです。

ソロプロトタイピング。 このコードを見るのは自分一人だけで、目標が本番環境ではなく学習である場合、バイブコーディングは速く、デメリットは限定されます。

シンプルな意思決定フレームワーク

実践的な問いは「SDDかバイブコーディングか？」ではありません。「この特定のタスクに必要な仕様書の量は？」です。

バイブコーディングを使用するべきとき：

  • タスクが1日以内で完了する
  • 探索中または学習中である
  • アーティファクトが使い捨てまたは低リスクである
  • これを触るのは自分だけである
  • 正しさよりもフィードバックの速度が重要である

軽量SDDを使用するべきとき：

  • タスクが2日以上かかる
  • 複数のファイルに影響が出る
  • 明確なセキュリティまたは正確性の要件がある
  • 別の人物またはエージェントが作業を継続する
  • 要件に対応するテストを書く必要がある

完全なSDDを使用するべきとき：

  • 機能がパブリックインターフェースまたはデータ契約に触れる
  • 複数のエージェントまたはチームメンバーが関与する
  • 組織が実装前に設計レビューを要求する
  • コンプライアンスまたは監査証跡が必要である

最も一般的な間違いは、軽量SDDのみが必要なタスクに完全なSDDを適用し、少なくとも軽量な仕様が必要なタスクに仕様を一切適用しないことです。

悪いSDDはマークダウンによるウォーターフォールです。良いSDDは、持続可能なアーティファクトを持つ制御されたイテレーションです。バイブコーディングは、適切なタスクには正しいツールであり、不適切なタスクには誤ったツールです。その違いを知るものが技能です。

有用なリンク

購読する

システム、インフラ、AIエンジニアリングの新記事をお届けします。