目次

AIにコードを書かせる時代、価値が高いのは「コードを書く力」より「仕様を書く力」になりつつある。その流れを象徴するのが仕様駆動開発（Spec-Driven Development、SDD）だ。2026年にはClaude Code・GitHub・AWSなど主要ツールがこぞって対応し、バイブコーディングの"次"として注目を集めている。

本記事では、仕様駆動開発とは何か、なぜ今必要なのか、基本の4ステップ、主要ツール、そしてバイブコーディングとの使い分けまでを初心者向けに整理する。

SPEC-DRIVEN DEVELOPMENT · 仕様が主役

「仕様 → 計画 → タスク → 実装」

— 各ステップが文書を残し、AIに迷わせない

STEP 1

Specify（仕様）

何を作るかを言葉で明確化する。

STEP 2

Plan（計画）

設計・使う技術・制約を加える。

STEP 3

Tasks（タスク）

レビュー可能な小単位に分解する。

STEP 4

Implement（実装）

仕様に沿ってAIが実装する。

1. 仕様駆動開発（SDD）とは

仕様駆動開発とは、「仕様（spec）」を開発の主役（中心ドキュメント）に据え、そこからAIに実装を導き出させる進め方だ。いきなりコードを書かせるのではなく、まず「何を・どう作るか」を構造化した文書にまとめ、その仕様をAIエージェントが読んで設計・分解・実装する。

イメージは「家を建てる前の設計図」だ。設計図なしに大工へ「いい感じに建てて」と頼めば、出来上がりはバラつき、作り直しが増える。AIエージェントも同じで、曖昧な指示は"推測"を生む。仕様という設計図を先に固めれば、AIが迷って勝手な実装に走る余地を減らせる。

💡 ひとことで：SDD＝「コードの前に仕様を書く」開発。仕様が"正"で、コードはそこから生成される派生物。直近で学んだコンテキストエンジニアリングの視点では、仕様はAIに渡す最良の"文脈"でもある。

2. なぜ今？バイブコーディングの「3ヶ月の壁」

バイブコーディング（思いつきで会話しながら作る進め方）は、試作を爆速で生み出せる一方、規模が大きくなると破綻しやすい。報道や実務では、勢いで作ったコードが3ヶ月ほどで「技術的負債の壁」にぶつかり、保守コストが膨らむ例がよく語られる。AIが生成したまま放置されたコードが本番に大量に残り、後から直せなくなるのだ。

仕様駆動開発は、この「要件のズレ（drift）」を設計段階で潰す。最初に仕様を固めるぶん前準備の手間は増えるが、後工程の「作り直し」が激減する。GitHubは自社ツールの利用で、"ゼロから作り直す"回数がおおむね桁違いに減ったと報告している（※ベンダー報告値）。

バイブコーディング

速い・探索向き

  • 試作・検証が爆速
  • 会話しながら方向を探れる
  • ただし規模が増えると破綻しやすい
  • 要件のズレ・負債が溜まる
仕様駆動開発

保守しやすい・出荷向き

  • 仕様が"正"で迷いが減る
  • 要件のズレを設計で防ぐ
  • 前準備の手間は増える
  • 作り直しが激減し保守が楽

「2026年はコードを書く力よりも、仕様を書く力が技術者の差になる」とも言われる。AIに任せる範囲が広がるほど、人間の仕事は"何を作るかを正確に定義すること"へ移っていく。

3. 基本の流れ——4ステップ

ツールによって名前は少し違うが、仕様駆動開発はおおむね同じ4ステップを踏む。重要なのは、各ステップが文書（多くはMarkdownファイル）を残し、次のステップがそれを読むこと。AIの"頭の中"だけに情報を置かないのがコツだ。

① Specify（仕様）

何を作るかを記述。機能・目的・利用者・受け入れ条件などを言葉で固める。

② Plan（計画・設計）

どう作るかを追加。アーキテクチャ・使うライブラリ・制約を決める。

③ Tasks（タスク分解）

計画をレビュー可能な小単位へ分解。1つずつ確認しながら進められる。

④ Implement（実装）

タスクを仕様に照らしてAIが実装。人間はレビューと承認に集中する。

⚠️ 人間のレビューは必須：仕様駆動でも、AI生成コードの確認を省いてはいけない。SDDは"丸投げ"の道具ではなく、人が舵を取りやすくする仕組みだ。

4. 主要ツール（Spec Kit・Kiro ほか）

2026年時点で、主要なコーディングエージェントの多くがSDDに対応する。代表例を挙げる。

GitHub Spec Kit

オープンソースのCLI（GitHub上で9万超のスター）。Specify→Plan→Tasks→Implementを支援し、Claude CodeやGitHub Copilotなど30以上のエージェントに対応。

AWS Kiro

Requirements→Design→Tasksの3段階を踏んでからコード生成。タスクごとに最適なモデルを選ぶAutoルーターを備え、CLIとWebの両方で使える。

その他

BMAD、OpenSpec、Tessl、Google Antigravity、Cursor なども独自のSDDフローを提供。主要ツールはほぼ何らかの形で対応している。

ツールを使わなくても、「仕様をMarkdownで先に書き、それをAIに読ませてから実装させる」だけで考え方は実践できる。AIがルールを無視してしまう問題も、仕様を明確な文書として渡すことで起きにくくなる。

5. バイブコーディングとの使い分け

大事なのは「どちらが正しいか」ではなく「いつどちらを使うか」だ。2026年の実践的な答えはハイブリッド——探索はバイブ、出荷は仕様駆動。

  • バイブコーディングが向く場面：アイデア検証、使い捨ての試作、一人で小さく試すとき。とにかく速く形にしたい段階。
  • 仕様駆動が向く場面：長く保守する本番システム、チーム開発、仕様が重要なプロダクト。開発ライフサイクル全体を見据えるとき。

つまり、最初はバイブで素早く方向を探り、これでいくと決めたら仕様に落として作り込む。両者は対立ではなく、フェーズの違いとして使い分けるのが賢い。

6. 今日から試すには

いきなり専用ツールを入れなくても、小さく始められる。

  • まず仕様を1枚書く：作りたい機能について「目的・入出力・受け入れ条件」を箇条書きでMarkdownにまとめる。
  • AIに仕様を読ませてから実装を頼む：「この仕様に厳密に従って実装して。曖昧な点は質問して」と伝える。いきなり「作って」と言わない。
  • タスクを小さく刻む：一度に全部ではなく、1機能ずつ実装→レビュー→次へ。Claude Skillsに手順をまとめておくと再現性が上がる。
  • 仕様を更新し続ける：変更が出たらコードより先に仕様を直す。仕様を"正"に保つのがSDDの肝。

💡 初心者にも効く：AIでアプリを作るとき、最初に仕様を書くだけで完成度が大きく上がる。プログラミングが得意でなくても使えるコツだ。

まとめ

仕様駆動開発を3点に整理する。

  • 正体：コードの前に「仕様」を書き、それを"正"としてAIに実装させる開発。仕様が中心ドキュメント。
  • 理由：バイブコーディングの「要件ズレ・技術的負債」を設計段階で防ぎ、作り直しを減らせるから。
  • 使い分け：探索はバイブ、出荷は仕様駆動のハイブリッド。人間のレビューは必須。

まずは「作る前に仕様を1枚書く」から始めてみよう。AI時代に伸びるのは、速くコードを書く人より、何を作るかを正確に定義できる人だ。あわせてバイブコーディングやコンテキストエンジニアリングも読むと、AI開発の全体像がつかめる。

FAQ

Q. プログラミング初心者でも仕様駆動開発はできる？

A. できます。むしろ初心者ほど効果的です。コードを書く前に「何を作るか」を言葉で整理するだけで、AIの出力が安定し完成度が上がります。専用ツールがなくてもMarkdownのメモから始められます。

Q. バイブコーディングはもう古い？

A. いいえ。探索や試作ではバイブコーディングが今も最速です。古い・新しいではなく、フェーズで使い分けるのが2026年の主流です。探索はバイブ、本番に向けては仕様駆動、という組み合わせが効きます。

Q. 仕様はどれくらい細かく書けばいい？

A. 「目的・入出力・受け入れ条件」が伝わる粒度が目安です。細かすぎると硬直し、曖昧すぎるとAIが推測します。プロンプトの6要素と同じく、具体的かつ柔軟な中間を狙いましょう。

Q. SDDを使えばコードレビューは不要になる？

A. いいえ。仕様駆動でも人間のレビューは必須です。SDDはAIを正しい方向に導く仕組みであって、確認を省くための道具ではありません。仕様・実装の両方を人がチェックして初めて安全に出荷できます。