Claude Code × cc-sddで始めるAI駆動開発フロー｜要件定義からデプロイまで完全解説
「Claude Codeに指示を出したのに、思っていたものと違うものができた」「AIが勝手に実装を進めて収拾がつかなくなった」——こんな経験はありませんか？
AI駆動開発の最大の落とし穴は、AIとの認識ズレです。この問題を根本から解決するのが、仕様駆動開発ツール「cc-sdd」を使ったワークフローです。
この記事では以下のことが分かります：
- AI駆動開発における人間とAIの正しい役割分担
- cc-sddで要件定義（requirements.md）→ 設計（design.md）→ タスク（tasks.md）を作る手順
- 複数LLMクロスレビューで品質を95点超えまで引き上げる戦略
- 実装・デプロイ（GitHub Actions + GCP）まで含めた全体ワークフロー
対象読者：Claude CodeやCursorを使い始めたエンジニア・非エンジニアで、AI開発の品質をもっと高めたい方
結論：cc-sddで仕様を固めてからAIに実装させると、手戻りが激減します。
目次
AI駆動開発（AI Driven Development）とは
コードを書く主体は「人間」から「AI」へ
AI駆動開発とは、コードを書く主体をAIに任せ、人間は要件定義・承認・テストに集中する開発スタイルです。
具体的な役割分担はこうなります：
| 人間の役割 | AIの役割 |
|---|---|
| システムの使用目的を決定する | Next.js等のコードを記述する |
| 必要な画面・項目を考案する | DB設計を行う |
| 動作確認と合否判定をする | エラー原因を特定・修正する |
| 業務視点でフィードバックする | 技術的な実装詳細を決定する |
「丸投げ」ではなく「協働」です。人間が目的・制約を決め、AIがそれを実現するコードを書きます。
AI駆動開発の3フェーズ
フェーズは大きく3段階に分かれます：
- フェーズ1（企画・製造）：要件定義 → AIがコード作成
- フェーズ2（テスト・修正）：動作確認 → NGならAIへ修正指示 → OK
- フェーズ3（自動化・公開）：CI/CDパイプライン → デプロイ
この流れの中で最も重要なのがフェーズ1の「要件定義」です。ここが曖昧だと、後工程で膨大な手戻りが発生します。その問題を解決するのが cc-sdd です。
cc-sddとは何か
仕様駆動開発（Spec-Driven Development）を実現するツール
cc-sddは、Claude CodeやCursorで「仕様駆動開発（SDD）」を実現するnpxツールです。日本語完全対応・AWS Kiroスタイル互換で、以下の3つのドキュメントをAIと対話しながら作成できます：
- requirements.md：何を作るか（思想・合格ラインの明確化）
- design.md：どう作るか（技術設計図）
- tasks.md：何から作るか（実装単位への分解）
これらのドキュメントを先に作り、AIに渡すことで「意図と違うものが作られる」問題を根本から防ぎます。詳しい cc-sdd 自体の使い方はcc-sddで始める仕様駆動開発（SDD）完全ガイドもご参照ください。
cc-sddを使ったAI駆動開発フロー【全ステップ解説】
Step 0：cc-sddをインストールする
Cursor または Claude Code CLI のターミナルで以下を実行します：
# Cursor IDE の場合
npx cc-sdd@latest --cursor --lang ja
# Claude Code CLI の場合
npx cc-sdd@latest --claude --lang jaインストールが完了すると、/kiro/ スラッシュコマンドが使えるようになります。また、PROJECT.md や CLAUDE.md（AIへの指示書）も自動生成されます。
Step 1：/kiro/spec-init でシステム概要を定義する
まず作りたいシステムの概要を一言で伝えます：
/kiro/spec-init 社内の案件進捗を一元管理するWebシステムAIがシステム名（スラッグ）を提案してくれます。次のステップでこのシステム名を使います。
Step 2：/kiro/spec-requirements で要件定義書を作成する
ここが最も重要なステップです。技術スタックと詳細要件を一緒に渡します：
/kiro/spec-requirements project-tracker
技術要件はNext.js 15（App Router）、Prisma（ORM）、Tailwind CSS、PostgreSQL（DB）で本番環境はVercelを想定
案件一覧・担当者・ステータス・期日を管理し、期日3日前にSlackへ自動リマインド
管理者は全案件を閲覧・編集でき、一般ユーザーは自分の担当案件のみ操作可能ポイント： 要件は改行OKで、できるだけ詳細に記述します。権限設計（管理者／一般ユーザー）もこの段階で詰めておきましょう。
Step 3：レビュアーサブエージェントを準備する
サブエージェントを使う前に、「レビュアー専用のエージェント定義ファイル」をプロジェクトに用意します。このファイル作成自体も Claude に依頼します。
Claude Code のチャットに以下のように入力してください：
.claude/agents/spec-reviewer.md を作成して。
仕様書（requirements.md / design.md / tasks.md）をレビューする専用エージェントとして、
以下の観点でレビューし、JSON形式（score / issues / suggestions）で返すよう定義して。
レビュー観点：
- 要件の抜け・漏れ（未定義のユーザーストーリーがないか）
- 曖昧な記述（実装者が判断に迷う箇所）
- 矛盾・整合性の問題
- 非機能要件（パフォーマンス・セキュリティ・エラー処理）の不足Claude が .claude/agents/spec-reviewer.md を自動生成します。一度作成すればプロジェクト全体で使い回せます。内容を確認・調整したい場合はそのままチャットで「〇〇の観点も追加して」と追加依頼できます。
Step 4：サブエージェントで要件定義の品質を自動レビューする
準備ができたら Claude Code の Agent ツールでサブエージェントを起動し、要件定義を自動レビューさせます。別のチャットウィンドウに切り替える必要はありません。
/kiro/spec-requirementsでrequirements.mdを生成する- Claude Code のチャットで Agent ツールを呼び出し、
spec-reviewerを起動する - サブエージェントへの指示例：
requirements.md をレビューして。
問題点を JSON 形式（issues 配列）で返して。- サブエージェントが返した
issuesをもとに、Claude がrequirements.mdを直接修正する - 重要な指摘がなくなるまで繰り返す（通常 1〜2 ラウンドで完了）
ポイント： サブエージェントは「作った本人（Claude）とは独立した視点」でレビューします。同一セッション内で動くため、ファイルを手動コピーする必要がなく、ラウンドトリップを Claude Code が自動で管理します。
異なるLLMの視点でクロスチェックすることで、同じモデルだと見落としがちな矛盾や抜け漏れを炙り出せます。
Step 4：/kiro/spec-design で設計図を生成する
/kiro/spec-design project-trackerdesign.md（アーキテクチャ・モジュール設計・データモデル）が自動生成されます。Step 3 と同様に別LLMでレビューし、重要な指摘がなくなるまで改善します：
@design.md この設計図をレビューして。
requirements.mdの全要件が設計に反映されているか、技術選定の根拠が明確かを確認してStep 5：/kiro/spec-tasks で作業手順書を作成する
/kiro/spec-tasks project-tracker設計書を実装可能な単位に分解した tasks.md が生成されます。同様に別LLMでレビューして内容を確定します。
Step 6：/kiro/validate-impl で実装を開始する
3つのドキュメントが揃ったら実装フェーズへ：
# Mac の場合
/kiro/validate-impl
環境構築で必要なものはHomebrewでインストールしてこれでAIが tasks.md に従って自律的に実装を進めます。
実装時のAI活用コツ
精度の高いコードを引き出す4ステップ
実装中に個別機能を依頼するときは、以下の4ステップを意識するとAIの出力精度が上がります：
- 目的を先に伝える：「案件一覧画面でタイトル・担当者・期日を表示したい」
- プランニングさせる：「コード実装の前に提案だけして」
- ファイルを明示する：「
@app/projects/page.tsxを編集して」 - 確認方法も聞く：「変更後の動作確認手順も教えて」
よく使う実装プロンプト
# 要件定義書に沿って自動実装
「要件定義書に従って実装を進めて」
# モックではなく本番APIで実装させる
「モックデータではなく実際に利用できるAPIで実装して」
# 進捗をチェックリスト形式で管理
「実装が完了したら要件定義書の項目にチェックをつけて」ブラウザーテストとエラー対処
実装後は必ず開発サーバーを起動して動作確認します：
npm run dev # 開発サーバー起動
npm run build # ビルド確認
npx prisma studio # DB確認エラーが出た場合は、ブラウザーのコンソールやサーバーサイドログのエラー文をそのままAIにコピペして修正依頼します。AIはエラー文から原因を特定し、ファイルを直接修正してくれます。
CLAUDE.md（AIへの指示書）を最大限活用する
cc-sdd を使うと以下のファイルが自動生成されます：
- PROJECT.md：プロジェクトの目的・概要・技術スタック。AIが常に参照する基本情報
- CLAUDE.md（AGENT.md）：「このプロジェクトのAIアシスタントへの指示書」。日本語で応答することや構造ルールを規定
- .cursor/rules：Cursorエディタ固有のルール。ファイル構成やコンポーネント分割基準など
これらのファイルをプロジェクトに含めておくだけで、新しいチャットを開くたびにAIが文脈を理解した状態から始められます。Claude Codeカスタムスキルの作り方と組み合わせると、繰り返し作業を一段と自動化できます。
大規模プロジェクトや並列開発にはClaude Code Agent Teamsも活用できます。複数エージェントが分担して実装を進めることで、開発速度がさらに向上します。
よくある質問（FAQ）
Q1. cc-sddはClaude Code以外でも使えますか？
はい。インストール時のオプションで切り替えられます。--cursor（Cursor IDE）、--gemini-cli（Gemini CLI）に対応しています。技術スタックにも依存しないため、React・Vue・Go・Python など任意のプロジェクトで使用可能です。
Q2. requirements.md はどのくらい詳細に書けばよいですか？
「別のLLMで採点して95点を超える」を目安にしてください。権限設計（管理者できること・一般ユーザーできること）、エラー時の挙動、外部API連携の仕様など、実装時に判断が必要になる点は全て記述しておくと手戻りが減ります。
Q3. AIに任せた部分と人間が判断すべき部分はどう分ければよいですか？
コード実装・DB設計・エラー修正はAIに任せ、「何を作るか」「どんな体験を提供するか」「合否の判断」は人間が担当します。業務の知識が必要なフィードバック（「この項目は現場では使わない」など）も人間の仕事です。
Q4. 要件定義書がうまく作れないときはどうすれば良いですか？
「不明点を私に質問して」というプロンプトが有効です。AIが曖昧な点を逆質問してくれるので、それに答えながら要件を深掘りできます。また「〇〇を実現するのにおすすめの方法を提案して」と聞くと、技術選択の相談にも乗ってもらえます。
Q5. cc-sddを使っても実装がうまくいかないことはありますか？
あります。AIが生成したコードはそのままでは動かないことがあります。開発サーバーを起動してブラウザーで動作確認し、エラーが出たらコンソールのエラー文をAIにコピペして修正依頼するサイクルを繰り返してください。Cursorのブラウザー機能を使うと、AIが自動でブラウザーテストまで行ってくれます。
まとめ
Claude Code × cc-sdd の AI駆動開発フローをまとめます：
npx cc-sdd@latest --cursor --lang jaでインストール/kiro/spec-initでシステム概要を定義/kiro/spec-requirementsで要件定義書を作成 → 別LLMでクロスレビュー（95点超えまで）/kiro/spec-designで設計図を生成 → 同様にクロスレビュー/kiro/spec-tasksでタスク分解 → 同様にクロスレビュー/kiro/validate-implで実装開始- ブラウザーテスト → エラー修正ループ
- GitHub Actions → GCP へデプロイ
最大のポイントは「要件定義にかける時間を惜しまない」ことです。AIとの認識ズレは上流で潰すほど修正コストが下がります。複数LLMのクロスレビューを活用して、高品質な仕様書を起点にした開発を始めてみてください。