Vibe Codingから仕様駆動開発へ｜AI時代のエンジニアが押さえるべき開発スタイル

この記事で分かること / 対象読者

• 「Vibe Coding」と「仕様駆動開発（Spec-Driven Development, SDD）」がそれぞれ何を指すか
• Vibe Codingがなぜ流行り、どこで壁にぶつかるのか
• SDDの基本ワークフローと、代表的なツール（GitHub Spec Kit、Kiro など）の使い方
• 自分のチームで今日から取り入れられる実践のコツ

対象は、ChatGPTやClaude Code、Cursorなどのコーディングエージェントを日常的に使っている初級〜中級エンジニアです。個人開発でAIにコードを書かせた経験がある方を想定しています。

「Vibe Coding」は2025年に広まった言葉で、仕様書もほとんど書かず、AIとの対話でコードを生成させながら開発を進めるスタイルを指します。

動作を見ながらプロンプトを重ね、動けばOK、というアプローチです。Vibe Codingは、プロトタイピングや短命なツールの開発で特に力を発揮します。一方、チーム開発や長期運用では、仕様や判断過程が残りにくい点が課題になります。

Vibe Codingは次のような場面では活用できます。

• 個人のプロトタイピングやアイデア検証

• 使い捨てのスクリプトや社内ツール

• 「とにかく早く動くものを見たい」というフェーズ

• 自分が詳しくない技術領域の「感触」を短時間で掴みたいとき

これらに共通するのは、成果物の寿命が短く、自分ひとりが理解していれば十分という条件です。この条件下では、仕様書を詳細に作る費用対効果が合わない場合があります。

たとえば、ハッカソンで24時間後に捨てるかもしれないアプリに要件定義書を書く人はいませんし、Slack通知を飛ばすだけの10行のスクリプトに設計レビューは不要です。

また、見落とされがちですが、Vibe Codingには「作ってみないと分からないことを最速で学ぶ」という探索的な価値があります。頭の中で仕様を練るより、雑に動くものを触ったほうが「本当に欲しかったもの」に早くたどり着けるケースは多く、この学習速度こそがVibe Codingの武器です。

仕様駆動開発は、この反省から生まれた開発スタイルです。考え方はシンプルで、コードを最初に生成する対象にするのではなく、仕様書を開発の中心（First-Class Artifact）に置き、コードはその仕様から生成される派生物として扱うというものです。

ポイントは、SDDにおける「仕様」が単なる読み物ではないことです。AI時代の仕様書は、人間が後から読むための固定ドキュメントというより、AIの出力が正しいかどうかを機械的に検証するための「評価関数」として機能します。

仕様が明確であるほど、AIエージェントは迷わず、レビュアーも「仕様通りか」を基準に判断できます。

両者は対立概念というより、開発フェーズごとの使い分けに近いものです。

アイデア段階でVibe Codingを使って「何を作りたいか」を発見し、方向性が固まった時点で仕様に落とし込んでSDDに移行する。この往復こそが、AI時代の現実的な開発スタイルです。

ここでは、SDDの効果を測るための現実的な指標を整理します。

• 定量指標｜手戻りとレビューのコストを見る
• 定性指標｜チームの会話とオンボーディングの変化

最も分かりやすいのは手戻りの減少です。具体的には次のような指標を、導入前後で比較します。

• PRあたりの修正コミット数（レビュー指摘による追加コミットの回数）
• 「仕様の認識違い」を理由とするPRの差し戻し・作り直しの件数
• レビュー着手からマージまでのリードタイム
• マージ後に発覚した仕様バグ（実装は正しいが要求と違う）の件数

SDDが機能していれば、仕様の認識違いは実装前のClarifyや仕様レビューの段階で潰れるため、これらの数値は下がっていくはずです。注意点として、導入直後は仕様を書くコストが上乗せされるため、リードタイム全体は一時的に伸びることがあります。

最初の1〜2ヶ月は「仕様起因の手戻り件数」に絞って見るのが現実的です。また、指標を個人評価に結びつけると数字合わせが始まるため、あくまでチームのプロセス改善の材料として扱うことを強くおすすめします。

数値に表れにくいものの確実に現れる変化が、チーム内の会話の質です。

SDD導入前のレビューコメントは「この変数名は〜」「ここはnullチェックが〜」といった実装の指摘が中心になりがちですが、導入後は

• この要件のエッジケースはどうする？
• スコープ外に入れたこの機能、本当に次フェーズでいい？

といった要求レベルの議論が仕様レビューの段階で行われるようになります。議論が上流に移動すること自体が、SDDが機能しているサインです。

もう1つの分かりやすい変化は新メンバーのオンボーディングです。仕様・設計・タスクの履歴がリポジトリに残っているため、新しく入ったメンバーが「なぜこの機能はこうなっているのか」を人に聞かずに追えるようになります。

代表的なツールであるGitHub Spec Kitは、次の4段階のワークフローを提供しています。

1. Specify — 「何を」「誰のために」作るかを自然言語で記述する。実装方法には触れない。
2. Plan — 使用する技術スタック、アーキテクチャ、制約条件を明文化する。
3. Tasks — 実装可能な単位までタスクを分解する。
4. Implement — AIコーディングエージェント（Claude Code、GitHub Copilot、Cursorなど）がタスクを実行する。

Spec Kitは29種類のAIコーディングツール（Claude Code、GitHub Copilot、Gemini CLI、Cursorなど）と統合できるオープンソースのCLIツールです。

ここでは実際にCLI内でタスクを投げられるコードの実例を紹介します。

初期化すると、/specify /plan /tasks /implement といったスラッシュコマンドがAIエージェント側に追加され、対話の中で仕様→設計→タスク→実装の順に進められるようになります。

この流れにより、AIエージェントは仕様と計画という「拠り所」を持った状態でコードを書くため、実装が仕様からずれにくくなります。

GitHubやAWSの早期採用事例では、非自明なタスクにおいてAIエージェントの一発成功率が3〜10倍向上したという報告もあります。

AWSが提供するKiroは、SDDを前提としたIDEです。CLIツールを組み合わせるのが好みでない場合、仕様→設計→タスク→実装の流れをIDEのUIとして体験できる選択肢になります。

Spec Kitの主な特徴は次のとおりです。

1. Specs機能

2. タスクの逐次実行

3. Steering

4. Agent Hooks

5. MCP

6. モデル選択

• Specs機能 — チャットで要件を伝えると、Kiroがそれをrequirements.md、design.md、tasks.mdの3つのファイルに自動で落とし込みます。ユーザーはこの3ファイルをレビュー・修正してから実装フェーズに進めます。
• タスクの逐次実行 — tasks.mdに分解されたタスクを1つずつAIに実行させ、都度差分を確認しながら進められます。Vibe Codingのように一気に大きな変更を投げるのではなく、レビュー可能な粒度に区切られるのが特徴です。
• Steering — .kiro/steering/配下にMarkdownファイルを置くことで、プロジェクト固有のルールをAIに常時参照させられます。always（毎回読み込む）、fileMatch（特定ファイル編集時のみ）、manual（#ファイル名で明示的に呼び出す）という3種類の読み込みモードがあり、コンテキストを圧迫しないよう3〜5ファイル程度をタスクに応じて使い分けるのが推奨されています。個人設定は~/.kiro/steeringにグローバルに置くこともできます。
• Agent Hooks — ファイル保存やコミットといったイベントをトリガーに、コードスキャンやドキュメント更新などのアクションを自動実行できます。仕様や設計の更新漏れを防ぐ仕組みとしても使えます。
• MCP統合 — 外部ツールやデータソースをMCP経由で接続でき、社内システムとの連携を仕様駆動のワークフローに組み込めます。
• モデル選択 — Claude Opus・Sonnetなど複数のフロンティアモデルから、タスクの性質に応じて切り替えて利用できます。

Spec KitがCLIベースで既存のエディタ・エージェントに「後付け」する形なのに対し、Kiroは仕様・設計・タスクの管理そのものがIDEに統合されている点が最大の違いです。チームで統一したワークフローを強制したい場合はKiro、既存のClaude CodeやCursorの使用感を保ちたい場合はSpec Kit、という選び方が現実的です。

ワークフローを回し始めると、次に直面するのが「仕様に何をどう書けばいいのか」という問題です。SDDの成否は仕様の質でほぼ決まるため、ここでは実践的な3つの原則を紹介します。

• 実装ではなく「意図」を書く
• 曖昧語を検証可能な条件に置き換える
• 書かないこと（スコープ外）を明示する

初心者がやりがちな失敗は、仕様に実装手順を書いてしまうことです。例えば、

• 「usersテーブルにis_verifiedカラムを追加し、フラグがtrueのときだけログインを許可する」

は仕様ではなく実装指示です。この書き方をすると、AIはより良い設計の選択肢を検討する余地を失いますし、後から実装を変えるたびに仕様も書き直す羽目になります。

代わりに書くべきは意図です。「メールアドレスの所有確認が完了していないユーザーは、サービスの主要機能にアクセスできないこと。確認完了前でも、確認メールの再送だけは可能であること」。このように「何が満たされるべきか」だけを書き、「どうやって満たすか」はPlan以降に委ねるのが原則です。

SDDの仕様は「評価関数」です。評価関数として機能するためには、仕様の各文が「満たされたかどうかを第三者が判定できる」形になっている必要があります。

チェックすべきは曖昧語で、

• 高速に表示する

• 使いやすいUI

• 大量のデータに対応

などこれらはすべて、AIがどんな実装を返しても「満たした」と言い張れる表現です。それぞれ「一覧画面の初回表示は1秒以内」「主要操作は3クリック以内で完了」「10万行のCSVを30秒以内に処理」のように、数値・条件・境界を伴う形に置き換えます。

すべてを数値化できるわけではありませんが、書いた仕様を読み返して「この文が満たされたかどうか、私とAIで判定が食い違う余地はあるか？」と自問する習慣をつけるだけで、仕様の質は変わります。

意外と効果が大きいのが、やらないことを仕様に書くことです。AIエージェントは気を利かせて機能を足す傾向があります。一見親切ですが、頼んでいない機能は、テストされていない仕様・レビューされていない設計判断がコードベースに混入することを意味します。仕様に

• スコープ外：ソーシャルログイン、パスワードリセット

と一行書くだけで、この種のスコープの膨張を防げます。

さらにスコープ外リストには、チーム内の認識合わせという効果もあります。「この機能はやらない」が明文化されていれば、実装後の手戻りが省略できるのです。

実際にAI開発を進めるうえで重要なステップやスキルについては、こちらの記事でまとめています。

実際にSDDのワークフローを個人プロジェクトやチーム内で回してみると、ドキュメントには書かれていない細かなつまずきに出会います。

ここでは特に頻度が高かった3点をQ&A形式で挙げます。

Vibe Codingは探索・プロトタイピングの武器として、仕様駆動開発は本実装・チーム開発・本番運用の武器として、それぞれ得意分野が異なります。「AIに書かせるか、人間が書くか」ではなく「仕様を誰が・いつ固めるか」がAI時代のエンジニアが押さえるべき軸になります。

まずは個人の小さなタスクで、GitHub Spec Kitの /specify から /implement までを一度通してみることをおすすめします。仕様が形になった状態でAIにコードを書かせる感覚を掴むことが、次のステップへの近道です。

コーディング事情はアップデートが頻繁なため、最新の仕様は下記の公式ドキュメントをあわせてご確認ください。

• GitHub Spec Kit ドキュメント
• GitHub Blog: Spec-driven development with AI
• Martin Fowler: Understanding Spec-Driven-Development