Claude CodeのためのSpec Kit仕様駆動開発ガイド

Claude Codeをうまく使えているチームと、そうでないチームの違いは、プロンプトのうまさよりもプロセスにあります。GitHub Spec Kitベースの仕様駆動開発は、まさにその差を生むための運用方式です。

このガイドの目的はシンプルです。AIに一度にコードを書かせるのではなく、仕様 -> 技術計画 -> タスク分解 -> 実装 -> 検証 の流れを強制し、成果物の予測可能性と再現性を高めることです。GitHubもこの方式について、仕様が実装、チェックリスト、タスク分解の中心になるように設計されていると説明しています。

まず要点を先にまとめると、次の通りです。

• Spec Kitの本質は、AIをより賢くすることではなく、AIが推測する余地を減らすことです。
• 良い実装は、良いプロンプトよりも良い仕様から生まれます。
• Claude Codeは強力ですが、spec、plan、tasks なしで使うと、過剰設計と要件漏れが同時に大きくなりやすいです。

なぜClaude Codeに仕様駆動開発が必要なのか

一般的なプロンプトベース開発は、素早いプロトタイピングには向いています。問題は、要件が増え始めたときです。たとえば「写真共有機能を追加して」という依頼は一見十分に見えますが、実際には多くの暗黙要件を含んでいます。

権限はどう分かれるのか。アップロード制限はあるのか。削除ポリシーは何か。モバイルでも同じUXを保証する必要があるのか。こうした条件が抜けていると、AIはその空白を推測で埋めます。その結果、見た目にはもっともらしくても、実際の要求から微妙にずれた実装が生まれます。

GitHubがSpec Kitで解こうとしている問題も、まさにここです。何を作るかを spec に、どう作るかを plan に、どの順序で作るかを tasks に分けることで、AIが勝手な前提を足し込む余地を減らせます。

要するに、仕様駆動開発はClaude Codeの能力を魔法のように高める手法ではありません。AIの推測コストを下げるための運用体系です。

Spec Kitの核心は6つの段階で理解するとわかりやすい

Constitution: まずプロジェクト原則を固定する

最初に作るのは機能仕様ではなく、原則文書です。Spec Kitは /speckit.constitution コマンドで、コード品質、テスト基準、UXの一貫性、性能要件など、プロジェクトの憲法を定義することを推奨しています。

この結果は .specify/memory/constitution.md に保存され、その後の spec、plan、implement 全体の基準点になります。この文書が弱いと、後続の工程もすべて不安定になります。

実務では、次のように書くと使いやすいです。

Specify: 何を、なぜ作るのかを明確にする

/speckit.specify は機能仕様を作る段階です。ここで重要なのは技術スタックよりも意図です。GitHubもこの段階では、要件やユーザーシナリオをできるだけ具体的に書きつつ、技術選定に早く入りすぎないよう案内しています。

つまり、この段階で問うべきなのは「どのフレームワークを使うか」ではなく、「誰がどんな状況で何をできる必要があるか」です。

たとえば、次のように始められます。

Clarify: 初稿仕様の空白を質問で埋める

仕様の初稿には、ほぼ必ず抜けがあります。だからこそ /speckit.clarify が重要です。READMEも plan の前に clarify を行うことを推奨しており、その回答は仕様内の Clarifications セクションに蓄積されます。

この段階の目的は、早く実装を始めることではありません。誤った前提のまま速く進んでしまうことを防ぐことです。

たとえば、次のように質問を引き出せます。

Plan: 技術実装の計画を文書化する

/speckit.plan は実装計画を作る段階です。ここからデータモデル、契約文書、リサーチ文書、クイックスタートガイドなどの成果物が生成されることがあります。

例示ディレクトリには plan.md、data-model.md、research.md、quickstart.md、contracts/ などが含まれます。ここからは「何を作るか」よりも、「どんな制約と構造で作るか」が重要になります。

Tasks: 実装可能な単位まで分解する

/speckit.tasks は、AIが実際に動ける作業単位を作る段階です。READMEによれば、生成される tasks.md には、ユーザーストーリーごとの作業区分、依存順序、並列処理の印 [P]、実装ファイルパス、TDD順序、各段階の検証チェックポイントが含まれます。

この段階の核心は、AIに「大きく一気に」実装させないことです。代わりに、小さく、検証可能で、レビュー可能な単位で進ませます。

Analyze / Checklist / Implement: 実装前後に品質ゲートを置く

現在のSpec Kitは、任意コマンドとして /speckit.analyze と /speckit.checklist も提供しています。analyze は成果物同士の整合性とカバレッジを点検し、checklist は要件の完成度、明確さ、一貫性を検証するカスタムチェックリストを生成します。

最後の /speckit.implement は、constitution、spec、plan、tasks をすべて確認したうえで、作業順序と依存関係に従って実装を進めます。

Spec Kit READMEによると、implement 段階では prerequisite を検証し、tasks.md を読み、依存関係と並列印に従って作業を実行します。TDD構造があればその順序に従い、npm や dotnet などのローカルCLIツールを実際に呼び出すこともできるため、開発環境の準備が先に必要です。

Claude Codeと組み合わせるときは初期設定の確認から始める

GitHub README基準では、プロジェクト初期化は specify init から始まります。Claude Code向けには、代表的に次の2つの形が示されています。

インストールせずにすぐ使いたいなら、uvx --from git+https://github.com/github/spec-kit.git specify init ... 方式が便利です。

現在のREADMEでは、Claude、Gemini、Copilot以外にも複数のエージェントをサポートすると案内されています。ただしClaude Code環境では、/speckit.constitution、/speckit.specify、/speckit.plan、/speckit.tasks、/speckit.implement コマンドが見えれば設定済みと考えてよいです。

初期化後には、featureブランチと仕様ディレクトリが生成されます。READMEの例では 001-create-taskify のようなブランチやフォルダ構造が使われ、.specify/ 以下には scripts、templates、memory、specs が作られ、featureディレクトリ内にまず spec.md が作られます。

実務ではこの順序で運用すると安定しやすい

1段階: プロジェクト原則を先に固める

品質、性能、テスト、セキュリティ基準を最初にClaude Codeへ明示しておく必要があります。この段階が曖昧だと、その後の plan と implement がぶれやすくなります。

良い憲法文書は、チームの好みではなく、譲れない原則を定義します。たとえばテスト優先、API契約優先、小さなPR単位、性能予算の明記といった項目は、後続のAI判断を安定させます。

2段階: 機能仕様は技術ではなく意図で書く

この段階では「何を作りたいか」と「なぜ必要か」を書くべきです。特にユーザー役割、主要フロー、対応環境、権限差などが抜けると、後の計画文書が精密に見えても実際の要求から離れていくことがあります。

3段階: 仕様が出た直後に必ず補正する

仕様を作った直後に実装へ進むのは危険です。その時点では、まだ欠けたポリシーが残っています。clarify を回して、権限ルール、例外フロー、データ保持ポリシー、削除ポリシー、監査ログ要件などを表に出す必要があります。

4段階: 技術計画には制約と運用基準まで含める

ここでスタック、制約、運用環境をClaude Codeに渡します。重要なのは最新技術を並べることではなく、どのトレードオフを優先するかを明確にすることです。たとえば「大規模トラフィックより運用の単純さを優先する」という一文だけでも、設計方向は大きく変わります。

5段階: タスクは独立検証できる大きさまで細かくする

タスク単位が大きいと、AIは再び大きな塊で実装しようとします。だから、ファイルパス、テスト順序、依存順序が見えるところまで分解する必要があります。並列処理できるものには [P] を付け、人とエージェントが同じ順序を見られるようにするのが有効です。

6段階: 実装前に最後の品質ゲートを置く

analyze と checklist は任意コマンドですが、実務ではほぼ必須に近いです。仕様、計画、作業の間に抜けや衝突がないかを実装前に点検しておくことで、Claude Codeが誤った前提のまま高速に進む状況を減らせます。

7段階: 実装は文書を読んで動かす

最後の実装段階では、AIに場当たり的な判断をさせないことが重要です。constitution、spec、plan、tasks を前提に実行させれば、実装順序と検証基準はその場の勘ではなく文書で統制できます。

実務で特に重要な運用原則は3つある

仕様は保管文書ではなく実行契約であるべきだ

Spec Kitの核心は、美しい spec を書くことではありません。仕様は plan と tasks を生み、その成果物が再び implement を支配する必要があります。

つまり仕様は説明文ではなく契約文です。誰が、いつ、どんな条件で、何をできるのかが明確でなければなりません。

Claude Codeの過剰設計を継続的に警戒する

GitHub READMEは、Claude Codeが過度に eager に動き、ユーザーが要求していないコンポーネントを追加してしまう可能性があると警告しています。だから plan 段階では、「なぜこの構成要素が必要なのか」「根拠は何か」「本当に要件に含まれているのか」を問い返す手順が必要です。

この原則は単純ですが効果があります。AIが熱心であることと、AIが正確であることは同義ではないからです。

調査は広くではなく、問題単位で狭く依頼する

READMEは、変化の速いスタックでは research.md を補強することを推奨しています。しかし「このフレームワークを調べて」のように曖昧に投げると、AIは関係の薄い方向に時間を使いやすくなります。

その代わり、「このバージョンで認証ミドルウェアは互換性があるか」「このデプロイ方式の制約は何か」のように、問題単位で分解して調査させるべきです。調査の品質も、仕様と同じく狭く具体的であるほど上がります。

推奨される成果物構造はこの程度で十分

実務では、次の構造を基準に管理すれば十分です。

この構造は、公式READMEのディレクトリ例をもとに整理したものです。plan の後には contracts/、data-model.md、research.md、quickstart.md などが含まれることがあり、tasks の後には tasks.md が追加されます。

大事なのはファイル数ではなく流れです。文書を増やすことが目的ではありません。実装が文書に従う状態を作ることが目的です。

こうしたチームには特によく合う

Spec Kitベースの仕様駆動開発は、次のような状況で特に強みを発揮します。

• 要件変更が多いが、変更履歴を仕様中心で管理したいとき
• AIに大きな機能を任せつつ、過剰設計と要件漏れを減らしたいとき
• フロントエンド、バックエンド、インフラが密接に絡み、作業順序と境界を明確にする必要があるとき
• 一度に巨大なコードダンプを受け取るより、小さな検証単位でレビューしたいとき

GitHubブログも、曖昧なプロンプトよりこの方式が強い理由を、AIが心を読むのではなく、仕様に基づいてより正確に実行できるからだと説明しています。

限界と注意点も明確にある

Spec Kitがあるからといって、要件整理が自動で良くなるわけではありません。仕様の品質が低ければ、その後の成果物もそのまま揺らぎます。

またClaude Codeは、誤った前提の上でも非常にそれらしい plan を作れてしまいます。変化の速いスタックでは、research.md の検証なしに計画文書を信頼するのは危険です。

実装後も終わりではありません。ブラウザコンソールエラー、ランタイム問題、実際のUX欠陥は別途確認が必要です。READMEも、CLIログに出ないランタイムエラーは別のテストで拾うべきだと案内しています。

定義的にまとめるなら、こう言えます。Spec Kitは実装品質を自動保証する道具ではなく、実装品質を検証可能な手続きの中に置くための道具です。

結論: うまくコードを書くAIより先に、うまく統制されたプロセスを作る

Claude Codeを 제대로活用するには、「うまくコードを書くAI」より先に「うまく操縦される開発プロセス」を作る必要があります。Spec Kitはまさにそのプロセスを提供します。

実務的には、次の一文で十分です。

良い結果を望むなら、実装を細かく指示する前に、まず仕様を統制せよ。

Claude Codeをもっと上手に使う方法を探しているなら、プロンプトを長くするよりも、constitution、spec、clarify、plan、tasks、analyze、checklist、implement の順序をチームの基本運用にするほうが、はるかに効果的です。