メインコンテンツまでスキップ
中級

Spec Kit によるスペック駆動開発

バイブコーディング — 「ダッシュボードを作って」と頼み、返ってきたものをそのまま受け入れる — は、機能が大きくなるまではうまく機能します。ところが機能が大きくなるとエージェントは脱線します。以前の決定を忘れたり、関数を作り直したり、技術的には動くけれど意図したものではないものを出してきたりします。スペック駆動開発（SDD: Spec-Driven Development） は、2026年にエージェント型コーディング界隈で広く支持されるようになった、その解決策です。プロンプトを使い捨てとして扱う代わりに、書かれてレビュー可能な仕様を信頼できる唯一の情報源にし、エージェントにそこからコードを生成させるのです。

GitHub のオープンソース Spec Kit は、その考え方を、今日 Claude Code の中で実行できる具体的なワークフローに落とし込みます。

What you'll learn
  • スペック駆動開発とは何か、そしてそれが解決する問題を理解する
  • Spec Kit のフェーズを辿る: constitution → specify → plan → tasks → implement
  • Specify CLI をインストールし、Claude Code に組み込む
  • 任意のクオリティゲート（clarify、analyze、checklist）を知る
  • SDD がそのオーバーヘッドに見合うときと、省くべきときを判断する

なぜ単なるプロンプトではなくスペックなのか​

プロンプトはターンが終わった瞬間に消えてしまいます。スペックはアーティファクトです。読むことができ、PR でレビューでき、修正でき、再実行できます。このたった一つの転換が、大きなエージェント型ビルドが失敗する三つの原因を解消します。

  • ドリフト — 何も書き留められていないため、エージェントが以前の決定と矛盾すること。スペックがその記憶になります。
  • 曖昧さ — 「いい感じにして」は十通りに解釈できます。要件を散文に落とし込むことを強制すると、コードが存在する前に — つまり修正が安価なうちに — ギャップが表面化します。
  • レビュー不能な差分 — 2,000行の生成された PR は判断が困難です。レビュー済みのスペック＋プランは、その差分を意外なものではなく想定されたものにします。

メンタルモデルはこうです。意図こそが価値が高く、長続きするものであり、コードはその下流にある、再生成可能なアーティファクトである。 SDD は、Claude Code 自身の Plan Mode の規律ある親戚です — まず計画し、次に構築する — それを機能全体にスケールアップし、リポジトリ内のファイルとして永続化したものです。

Spec Kit のワークフロー​

Spec Kit は、機能をスラッシュコマンドの短いパイプラインとして構造化します。各コマンドは Markdown のアーティファクトをリポジトリ（.specify/ 配下）に書き込むので、すべてのフェーズが検査可能でバージョン管理されます。

Guided walkthrough1 of 5
  1. プロジェクトごとに一度 /speckit.constitution を実行します。これは統治となる原則 — コードスタイル、テストの基準、譲れないアーキテクチャ上の決まり — を .specify/memory/constitution.md に書き込みます。以降のすべてのフェーズはこれと照合されるので、これがあなたの長続きするガードレールになります（原則に特化した CLAUDE.md だと考えてください）。

任意のクオリティゲート​

機能が重要度の高いものであるときは、さらに三つのコマンドがループを引き締めます。

  • /speckit.clarify — スペックを精査して仕様が不十分な箇所を見つけ、計画の前に的を絞った質問をします。specify の直後に実行するのが最適です。
  • /speckit.analyze — スペック、プラン、タスクを相互チェックし、一貫性とカバレッジのギャップを確認します。
  • /speckit.checklist — 検証用のチェックリストを生成し、「完了」が定義され、テスト可能になるようにします。
Pro tip
  • /speckit.plan の前に /speckit.clarify を実行する — 曖昧さを直すのは、アーキテクチャが確定する前が最も安価です。
  • 生成された各アーティファクトを PR のように扱う: 読み、修正し、そうしてから次のフェーズに進む。
  • .specify/ のアーティファクトをコミットする — それらはコードの背後にある意図のレビュー可能な記録です。

Claude Code で動かす​

Spec Kit は Specify という CLI を提供しており、これがスラッシュコマンドをプロジェクトに足場として組み込みます。30以上のコーディングエージェントをサポートしており、Claude Code もその一つです。

Guided walkthrough1 of 3
  1. uv を使ってリポジトリからインストールします。（Python + uv が必要です。）

Install the Specify CLI (uv)

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Scaffold spec-driven workflow into a project

# new project
specify init my-feature

# or in the current repo
specify init --here

Then, inside Claude Code, run the pipeline

/speckit.constitution Establish principles: TypeScript strict, tests for every public function, no secrets in code.
/speckit.specify Build a CSV export for the reports page: users pick a date range and download a CSV of matching rows.
/speckit.clarify
/speckit.plan Next.js App Router, server action for the query, stream the CSV; no new dependencies.
/speckit.tasks
/speckit.implement
Watch out
  • specify init の正確なエージェント選択フラグはリリースごとに変わります — フラグを盲目的にコピーするのではなく、README のクイックスタートを確認してください。
  • SDD は検証の必要をなくしません: 生成されたコードを読み、実行してください。スペックは差分をレビュー可能にするのであって、自動的に正しくするわけではありません。
  • シークレットや認証情報をスペック、プラン、constitution に決して入れないでください — それらは他のファイルと同様にコミットされてしまいます。

いつ使うべきか（そしていつ使わないか）​

SDD は前もっての手間と引き換えにコントロールを得ます。その取引は、作業が大きい、曖昧、あるいは他の人にレビューされなければならないときには価値がありますが — そうでないときには純粋なオーバーヘッドです。

What you'll learn
  • SDD を使うべきとき: グリーンフィールドの機能、複数ファイルにまたがるビルド、チームメイトがレビューしなければならないもの、あるいはサブエージェント群に渡す作業。
  • SDD を省くべきとき: 使い捨てのスクリプト、ごく小さな修正、探索的な使い捨てコード — 素のプロンプトや Plan Mode の方が速いです。
  • ブラウンフィールドでも機能します: /speckit.specify を新規プロジェクトだけでなく、既存コードベースへの機能拡張に向けてください。
SDD at a glance
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 5

理解度チェック​

Check yourself

0/3
  1. スペック駆動開発の中核となる考え方は何か?
  2. Spec Kit のどのフェーズが技術スタックとアーキテクチャを捉えるべきか?
  3. スペック駆動開発がそのオーバーヘッドに見合わないのはいつか?
Key takeaways
  • スペック駆動開発は、プロンプトではなくレビュー可能なスペックを信頼できる唯一の情報源にし、ドリフト、曖昧さ、レビュー不能な差分を消し去ります。
  • GitHub の Spec Kit（Specify CLI）は、SDD を /speckit.* スラッシュコマンドとして Claude Code に持ち込みます。
  • パイプラインは constitution → specify → (clarify) → plan → (analyze) → tasks → (checklist) → implement で、それぞれが検査可能なアーティファクトを書き込みます。
  • 「何を」「なぜ」はスペックに、「どうやって」はプランに留める; 進む前にすべてのアーティファクトを PR のようにレビューする。
  • 大きく、曖昧で、レビューされる機能に使う; 使い捨ての作業には省く — そして常に、生成されたコードを必ず検証する。

次へ​

  • Plan Mode — 組み込みの、より軽量な「構築する前に計画する」ループ
  • Slash Commands — /speckit.* コマンドが Claude Code のコマンドシステムにどう収まるか
  • CLAUDE.md & Memory Files — constitution の背後にある「原則を記憶として」の考え方
  • Subagents — レビュー済みのタスクリストをエージェント群に渡す
  • Coding & Software Development — SDD が依拠する、すべてを検証するという心構え

出典 & 参考資料​