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

仕様書を真実の基準とするか、それとも遅い儀式とするか

目次

2026年、仕様駆動型開発（Spec-Driven Development）は、バイブコーディング（Vibe Coding）の漂流に対抗する真面目な開発者の解決策として登場しました。

その論理は単純です。AIエージェントは、即興のプロンプトではなく、レビュー済みの仕様に対して実装を行った場合により良く、かつ一貫性のある出力を生成します。理論的には論破できません。

しかし実際には、Hacker Newsでは「ウォーターフォールの復活」と呼ばれていました。

両陣営にもそれぞれの理があります。

仕様駆動型開発 versus バイブコーディング

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

バイブコーディング – つまり、緩いプロンプトを書き、AIエージェントが生成したものを反復して改善していく手法 – は、小規模な探索的作業や、使い捨ての作業には驚くほど効果的です。2025年の最初の6ヶ月間、これは主要なAIコーディングのパターンでした。開発者は、過去に比べてかつてない速さでスクリプト、プロトタイプ、シンプルなツールをリリースしました。

しかし、プロジェクトは成長しました。複数ファイルにまたがる機能は徐々にズレが生じるようになりました。1回目のセッションで確立された制約は、3回目のセッションには忘れ去られていました。セキュリティの前提条件は軽視されました。アーキテクチャの決定は機能の途中で変更されました。それはエージェントが意図に関する耐久性のあるメモリを持っていなかったためです。

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

GitHub Spec Kit、Kiro、Claude CodeのSDDワークフロー、およびBMAD、その他コミュニティによるスキャフォールド（足場）は、すべてこのアイデアの実装です。ツールは本物です。関心は本物です。反発もまた本物です。

バイブコーディングが得意なこと

バイブコーディングを軽視する前に、それがどのように優れているかを正確に把握しておく価値があります。

探索的なプロトタイプ。 何を構築すべきか確信がない場合、最速の道は粗い何かを構築し、それに対応することです。SDDでは、何を指定すべきかを知る必要があります。まだわからない場合、仕様は時期尚早です。

UIの実験。 視覚的なレイアウトやインタラクションの感覚は、事前に指定するのは困難です。バイブコーディングであれば、選択肢を素早く確認し、大部分を破棄し、実際に正しく感じられるものへと収束させることができます。ここでは要件文書は役に立ちません。

使い捨ての自動化。 ワンオフのスクリプト、データ抽出ジョブ、移行ヘルパー – これらはほとんど設計文書を必要としません。少し間違えた場合のコストは低いです。しかし、遅く儀式的なプロセスのコストは現実的なものです。

高速なフィードバック。 何かを素早く学びたい場合 – このAPIは私が思うように機能しているか？ – バイブコーディングは学習ループを数分に短縮します。SDDではそれなしに遅くなってしまうでしょう。

間違いは、これらの文脈での成功パターンを取り、実際の制約、実際のユーザー、そして間違えた場合に現実的な結果を伴う本番用の機能に適用してしまうことです。

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

バイブコーディングは、範囲と利害関係が増加するにつれて、予測どおりに劣化します。

複数ファイルの変更。 機能が5つ以上のファイルに触れると、エージェントのコンテキストウィンドウは不変条件を見失い始めます。設計文書がない場合、各プロンプトは、以前のセッションで確立され忘れ去られたコンテキストを再確立する必要があります。

アーキテクチャの漂流。 明示的な非目標（non-goals）がない場合、エージェントはあれこれ実装します。エージェントは理にかなっているためキャッシュ層を追加します。3セッション後、そのキャッシュの前提はデータモデルに組み込まれ、それを削除するのは高コストになります。

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

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

チームへの引き継ぎ。 反復的なプロンプティングで構築した場合、何が決まり、なぜそう決まったかを記録するアーティファクトは… gitログです。それを使って幸運を祈ってください。

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

SDDは反復を排除するとは主張していません。良いSDDのバージョンは、明確に反復的です。それらが変えるのは、反復が行われる場所です。完全な定義 – SDDがTDD、BDD、形式手法とどのように異なるかを含みます – については 仕様駆動型開発とは？ を参照してください。

コードを反復し、差分から意図を推測するのではなく、仕様を反復し、その後実装します。仕様は、何が決まり、なぜ、そして何が範囲外かを記録するアーティファクトとなり、 アーキテクチャ意思決定記録 と同様の機能を提供しますが、システムレベルの選択ではなく、機能の意図を中心に据えています。コードはその意図を実装します。

SDDは5つのフェーズ – 指定、計画、タスク、実装、検証 – を通じて実行され、各ステップに人間のレビューゲートがあります。完全なプロセス、テンプレート、チェックポイントについては 仕様駆動型開発ワークフロー：要件からコードへ を参照してください。エージェントはほとんどのフェーズに参加しますが、人間は実装開始前にアーティファクトをレビューします。このレビューステップが、SDDとバイブコーディングの核心的な違いです。

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

ウォーターフォールへの批判は間違えていません。それは単に、SDD自体ではなく、悪いSDDを対象としているだけです。

具体的な失敗モードは、前倒しの長期計画です。ウォーターフォールの特徴は、フィードバックループが数週間に及ぶ、あるいは数ヶ月に及ぶことです：要件フェーズ、設計フェーズ、ビルドフェーズ、テストフェーズ、出荷。フィードバックは遅く届きます。設計の前提が間違っていたことに気づいた時には、すでに数週間それを土台に構築していました。

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

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

有用な批判は「仕様は悪い」のではなく、「フィードバックを得るための前倒しの長期計画は悪い」です。それらは異なる主張です。

有用な中間地点

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

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

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

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

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

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

このハイブリッド – 小さな仕様、短いタスク、早期実装、生きたドキュメント – が実際に機能するものです。それはバイブコーディングでもなく、ウォーターフォールでもありません。それは、耐久性のあるアーティファクトによる制御された反復です。

SDDがバイブコーディングに勝つとき

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

リスクの高いビジネスロジック。 請求、権限、データ移行、冪等性 – 間違った動作が高価な、または元に戻しにくいロジック。バイブコーディングはこれらの要件を暗黙にしておきます。SDDはそれらを明示し、実装前にレビュー可能にします。

本番APIの変更。 公開または内部のAPI契約へのあらゆる変更には、設計文書が必要です。設計文書は、呼び出し方を壊すコードを書く前に、エージェントがレビューするものです。

マルチエージェントワークフロー。 複数のエージェントが機能の異なる部分を実装する場合、仕様は共有された真実の源です。それなしに、各エージェントはローカルに最適化し、部品が合わない可能性があります。

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

大規模なリファクタリング。 コア抽象に触れるリファクタリングには、何が変わらないべきか（振る舞い）、そして何が変更されてもよいか（構造）の明示的な宣言が必要です。それなしに、エージェントはあなたが保存したものと思っていた契約を壊す可能性があります。

バイブコーディングがまだ優れているとき

SDDはオーバーヘッドです。時々、オーバーヘッドはそれだけの価値がないことがあります。

クイックスクリプト。 ファイルをリネームしたりJSONを変換するための50行のスクリプトには、要件文書は必要ありません。プロンプトを書き、出力を確認し、出荷します。

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

UIスケッチ。 インタラクションデザインは、指定するのではなく見て得る利点があります。いくつかの粗いバリエーションを素早く構築し、見たものに対応し、実際に出荷するものだけを指定します。

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

ソロプロトタイプ。 あなたがそのコードを見る唯一の人物であり、目標が本番環境ではなく学習である場合、バイブコーディングは速く、欠点は制限されます。

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

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

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

  • タスクが1日未満で完了する場合
  • 探索中または学習中である場合
  • アーティファクトが使い捨てまたは低リスクである場合
  • あなたがこのコードに触れる唯一の人物である場合
  • 正確性よりもフィードバックの速度が重要である場合

軽量SDDを使用するとき：

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

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

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

最も一般的な間違いは、完全なSDDを軽量SDDのみが必要なタスクに適用し、少なくとも軽量な仕様が必要なタスクに仕様を全く適用しないことです。どのレベルを選んでも、仕様がコードに対して何かをチェックし続ける場合にのみ、仕様が有用さを保ちます；AI開発における仕様、テスト、コードの同期維持 は、静かに陳腐化する仕様を捕捉する追跡性チェックについて解説しています。

悪いSDDはマークダウン付きのウォーターフォールです。良いSDDは、耐久性のあるアーティファクトによる制御された反復です。 バイブコーディングは、適切なタスクには正しいツール – そして不適切なタスクには間違いのツールです。 その違いを知ることは、技術そのものです。

有用なリンク

購読する

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