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

正の源としての仕様、それとも遅い儀式か？

目次

スペック駆動開発（Spec-Driven Development）は、2026年において、ビブコーディング（Vibe Coding）による方向性のブレに対する、真面目な開発者としての回答として登場しました。

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

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

双方に一定の道理があります。

スペック駆動開発とビブコーディング

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

ビブコーディング – 曖昧なプロンプトを書き、AIエージェントが生成した結果を反復して改善していく手法 – は、小規模な、探索的な、使い捨ての作業に対して驚くほどよく機能します。2025年の上半期は、これがAIコーディングの支配的なパターンでした。開発者は、これまで以上に迅速にスクリプト、プロトタイプ、シンプルなツールをリリースしました。

しかし、プロジェクトは成長しました。複数ファイルにまたがる機能は、徐々に本来の意図から外れ始めました。1セッション目で確立された制約は、3セッション目には忘れ去られていました。セキュリティに関する前提が脱落することもありました。エージェントに意図の永続的なメモリがないため、機能の途中でアーキテクチャの判断が変更されることもありました。

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

GitHub Spec Kit、Kiro、Claude CodeのSDDワークフロー、およびBMAD、さらにSuperpowersなどのコミュニティによるスキャフォールドは、すべてこの考えの実装です。ツールは実在し、関心は実在します。そして、反発もまた実在します。

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

ビブコーディングを退ける前に、それが何を得意としているのかを正確に見極める価値があります。

探索的なプロトタイプ。 何を構築したいか確信が持てない場合、最速の道はラフな何かを構築し、それに対して反応することです。SDDは、何を実装すべきかを特定できることが前提です。まだそれが分かっていない場合、仕様書を作成することは時期尚早です。

UIの実験。 視覚的なレイアウトやインタラクションの感覚は、事前に仕様として定義するのが困難です。ビブコーディングにより、選択肢を素早く確認し、その大部分を捨て、実際に適切に感じられるものに収束させることができます。ここでは要件定義書は役立ちません。

使い捨ての自動化。 ワンスクリプト、データ抽出ジョブ、マイグレーションヘルパー – これらはほとんどが設計書 unnecessary です。少し誤った場合のコストは低く、遅く儀式的なプロセスのコストの方が現実的です。

迅速なフィードバック。 何かを素早く学習したい場合 – この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行のスクリプトには、要件定義書は unnecessary です。プロンプトを書き、出力を確認し、リリースします。

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

UIスケッチ。 インタラクション設計は、指定するのではなく見ることで恩恵を受けます。いくつかのラフなバリエーションを素早く構築し、見たものに対して反応し、実際にリリースするものだけを指定します。

使い捨ての自動化。 ワンスクリプト、データインポート、マイグレーションヘルパー – 少し誤った結果のコストは通常低く、成果物は使用後に削除されるでしょう。

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

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

実用的な問いは「SDDかビブコーディングか？」ではなく、「この特定のタスクにはどの程度の仕様が必要か？」です。

ビブコーディングを使用する場合：

  • タスクが1日未満で完了する
  • 探索または学習中である
  • 成果物が使い捨てまたは低リスクである
  • これに触れるのは自分だけである
  • 正確性よりもフィードバックの速度が重要である

軽量なSDDを使用する場合：

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

フルSDDを使用する場合：

  • 機能が公開インターフェースまたはデータ契約に関わる
  • 複数のエージェントまたはチームメンバーが関わる
  • 組織が実装前の設計レビューを要求している
  • コンプライアンスまたは監査証跡が要求されている

最も一般的な誤りは、軽量なSDDで十分なタスクにフルSDDを適用することと、少なくとも軽量な仕様が必要なタスクに仕様を一切適用しないことです。どのレベルを選んでも、コードと常に照合され続ける何かがなければ、仕様書は有用さを保ちません。AI開発における仕様、テスト、コードの同期維持 は、仕様書が静かに陳腐化することを検出するトレーサビリティチェックを扱っています。

悪いSDDは、マークダウンを使ったウォーターフォールです。優れたSDDは、永続的な成果物を持つ制御されたイテレーションです。 ビブコーディングは、適切なタスクには適切なツールであり – 不適切なタスクには不適切なツールです。 その違いを知ることが、スキルです。

有用なリンク

購読する

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