LLMを活用した開発ツールの普及により、自然言語の指示から即座にコードを生成する「Vibeコーディング」が一般的になりました。個人の実装速度を劇的に高める一方で、チーム開発やプロジェクトが一定の規模を超えたあたりで、このスタイル特有の難しさに直面することがあります。
本記事では、Vibeコーディングで突き当たりやすい課題を整理した上で、一つの解決策として「仕様駆動開発（SDD）」を今の開発フローに合わせて取り入れる流れについて考えてみます。
1. Vibeコーディングの課題
設計をあえて作り込まずに進めるVibeコーディングには、中長期的な運用においていくつか懸念されるポイントがあります。
・インターフェースの不整合
明確なデータ定義がないまま進めると、フロントエンドとバックエンドの接続部分で認識のズレが発生しやすくなります。型や命名の些細な食い違いが、開発終盤での手戻りに繋がることも少なくありません。
・ハルシネーションの制御
制約となる具体的なルールがない場合、生成AIは前後のコードから推測して存在しないデータ構造などを勝手に作り出してしまうことがあります。一見きれいに書かれている分、原因の特定に時間がかかる場合があります。
・ドキュメントの不足による属人化
その場のプロンプトで生成されたコードは、設計意図が残りにくい側面があります。後から参加したメンバーにとって、コードそのものから仕様を読み解くのは負担が大きく、結果として特定の人にしか全貌がわからない状態を招きがちです。
2. 仕様駆動開発（SDD）とは
仕様駆動開発（Specification-Driven Development: SDD）とは、実装に入る前に、システムの振る舞いやデータの構造を共通の形式（OpenAPIなど）で定義し、それを実装の中心に据える手法です。
この仕様ファイルは「チームとツールがいつでも立ち返ることができる共通の判断基準」として機能します。指示を丸投げするのではなく、作成した仕様をベースに実装を進めることで、意図しないコードの生成を抑え込み、一貫性のある出力を得やすくなります。
3. 仕様駆動開発の具体的な流れ
設計を行う際は、人間が手作業ですべてを書くのではなく、チャット形式のツールを設計のパートナーとして活用しながら進めるのが現実的だと考えています。
ステップ1：対話を通じて仕様を固める
まずはツールに対し、「どんな機能を作りたいか」を自然言語で伝えます。この際、「なぜその機能が必要か（Why）」まで伝えると、より文脈に沿ったエンドポイントやデータ項目が提案されやすくなります。
ステップ2：仕様書の出力とチームによる確認
対話で固まった内容をもとに、OpenAPI形式などで仕様書を出力させます。ここで欠かせないのが、人間によるレビューと合意です。
提示された内容がビジネス要件に合っているか、チーム全員で確認します。このプロセスを通すことで、仕様がチームの総意となり、後の実装のブレを防ぐことができます。
ステップ3：仕様を基にした技術設計
仕様が決まれば、それをコンテキストとして読み込ませ、具体的なDB構成やシーケンス図などを作成させます。ベースとなる仕様が固まっているため、出力される設計情報の精度も高まります。
ステップ4：仕様に基づいた実装をさせる
確定した仕様ファイルをツールに読み込ませ、具体的なコードを実装させます。ここでのメリットは、単にコードが早く書けることだけではありません。
共通の仕様ファイルをツールに読み込ませておくことで、フロントエンド側ではAPIから返ってくるデータ構造を正しく理解した状態でUIの実装が進み、バックエンド側では実装すべきエンドポイントの正解を把握した状態でロジックが生成されます。
このように、共通の仕様が実装のガイドラインとなるため、フロントとバックを個別に実装させても、最後に双方を組み合わせた際に「型が合わない」「データが足りない」といった事故を減らすことができます。
4. AIツールと連携して仕様の精度を高めるコツ
仕様書をベースに実装を進めていく中で学んだ、いくつかのコツがあります。
・要求と制約をセットで伝える
ツールへの指示では「何を実現したいか（要求）」だけでなく、「どのように実現してほしいか（制約）」をセットで伝えることが重要です。
例えば「ユーザー投稿機能を作って」という要求に加えて、「バリデーションはこのライブラリを使い、レスポンスはこの形式に従って」といった具体的なルールを明示します。
これにより、ツールの自由すぎる提案を抑え、プロジェクトの規律に沿った仕様に導くことができます。
・やらないことも定義する
仕様を固める段階で「今回は検索機能は含めない」といった制約も共有しておくと、余計なデータ構造が混じり込むリスクを減らせます。
・徐々に詳細化する
最初から完璧な定義ファイルを出力させようとせず、まずは自然言語の箇条書きで合意し、その後にコード形式へ変換させるという段階的なステップを踏むのがスムーズです。
5. 運用上の課題
メリットの多い仕様駆動開発ですが、実務で導入する際にはいくつか気をつけるべき点もあります。
・仕様と実装の乖離
実装フェーズにて、実装スピードを優先して、仕様ファイルを更新せずにコードだけ直してしまうと、仕様書が形骸化してしまいます。CIなどで不整合を検知する仕組みを導入し、機械的にチェックできるようにするのが理想的です。
・複雑化した既存プロジェクトへの適用
既存プロジェクトのすべてを一気に変えるのは現実的ではないように思います。まずは新しく追加する機能や修正頻度の高いAPIから限定して導入してみるのがおすすめです。
また、既存のコードから現在の挙動をベースにした仕様書を逆引きで生成させて現状を可視化するなど、小さな範囲から少しずつ広げていくとスムーズに作業が進むと考えています。
・初期設計への抵抗感
最初に仕様を固める時間が、スピード感を削いでいるように感じられるかもしれません。まずは主要な機能だけに絞って定義し、少しずつ仕様を定めていくスモールスタートにするのも一つの手です。
6. 最後に
最初に正解を定義しておくことは、決して開発を停滞させるものではありません。むしろ、後半に発生しがちな混乱や手戻りを未然に防ぎ、プロジェクトをスムーズに完走させるための大切な先行準備といえます。
ツールを用いて実装スピードを向上させつつ、仕様書というガイドラインでうまく導いてあげる。このバランスを意識することが、実装の勢いを止めることなく、チーム全員が安心して使い続けられるプロダクトを作るための、実用的な選択肢になると考えています。