AI駆動開発のプロジェクト計画術

TL;DR

• 計画フェーズこそ AI の活用余地が大きい。実装の自動化は進んだが、要件定義・タスク分解・スプリント計画は「まだ人が全部やっている」チームが多い。
• AI が得意なのは「構造化・列挙・パターン照合」、苦手なのは「ステークホルダー利害の読み取り・優先順位の最終決定」。この分担を明確にするだけで計画効率は数段上がる（経験則）。
• 人間の判断が必要な箇所には レビューゲート を置く。PlanGate の C-3 ゲート（計画承認）はその自動強制機構の一例。
• AIエージェントの三層成熟度モデルでいう Level 2（タスク実行） から Level 3（自律計画） への移行期に読む記事。

このシリーズについて

AI駆動開発の計画から実践・運用まで体系的に解説します。

1. AI駆動開発のプロジェクト計画術（本記事）— 要件定義〜スプリント設計
2. AIとペアプロする実践パターン — コンテキスト設計と引き継ぎ
3. AI駆動開発チームのオンボーディング設計 — 学習曲線の設計
4. マルチエージェント開発の実装パターン2026 — エージェント間通信
5. AI駆動開発における技術的負債の管理 — 生成コードの品質維持

はじめに

こんにちは、みねです。

「Claude Code を使い始めたら実装速度が2倍になった」——そういう声は増えています。しかし「計画フェーズ（要件定義・タスク分解・スプリント計画）も同じように加速できているか」と聞かれると、多くのエンジニアリングマネージャーは首を横に振ります。

実装フェーズの AI 活用と計画フェーズの AI 活用は、求められるスキルセットが違います。実装は「コードを書く」という単一のアウトプットに集約されますが、計画は「何を・なぜ・いつまでに・誰が」を整合させる 意思決定の連鎖 です。AI に丸投げすると、表面上はそれらしい計画書ができあがりますが、ステークホルダーの利害が抜け落ちていたり、リソース制約が無視されていたりします。

この記事では、要件定義・タスク分解・スプリント計画 の3フェーズで AI をどう使うか、そして 人間がどこで判断するか を具体的なプロンプト例とともに整理します。

AI が得意・苦手な計画作業の整理

AI が得意なこと（委ねてよい）

AI が苦手なこと（人間が判断する）

この分類を念頭に置いて、各フェーズの具体的な活用方法を見ていきます。

フェーズ1：AI を活用した要件定義

ステップ概要

自然言語の要件 → AI による構造化 → 人間レビュー → 確定

プロンプト例：要件の構造化

Claude Code（または Claude CLI）に次のプロンプトを渡すと、自然言語の要件を GIVEN/WHEN/THEN 形式に変換できます。

以下の要件テキストを Given/When/Then 形式のユーザーストーリーに変換してください。
各ストーリーには受入基準を3〜5項目列挙してください。
曖昧な箇所は "[要確認: ○○]" と明記してください。

---
要件テキスト:
{{paste your requirements here}}
---

ポイント: [要確認: ○○] を AI に自動挿入させることで、曖昧な要件が可視化されます。このフラグがある箇所こそ、人間が確認すべき優先事項です。

Gate-1: 要件確定レビュー（人間が必ず行う）

AI が生成した要件ドラフトを以下の観点でチェックします。

• ビジネスゴールとの整合（AIには届かない文脈）
• ステークホルダーの合意（会議・メール等で確認）
• スコープ境界の明確化（何をやらないかも書く）
• [要確認] フラグの解消

PlanGate の C-3 ゲートは、このレビューを「承認記録なしには次フェーズへ進めない」仕組みで強制します。

フェーズ2：AI によるタスク分解

要件が確定したら、次は 開発タスクへの分解 です。ここが AI の活躍機会が最も大きいフェーズです。

プロンプト例：エピックからタスクへの分解

以下のユーザーストーリー（エピック）を、エンジニア1人が1〜3日で完了できる粒度のタスクに分解してください。

各タスクには以下を含めてください:
- タスク名（動詞+名詞の形式）
- 完了条件（1〜2文）
- 依存タスク（あれば）
- 見積もり（SP: 1/2/3/5）

---
エピック:
{{paste your epic here}}
---

AI による見積もりの精度を上げるコツ

1. 過去チケットを文脈として渡す: 類似タスクの実績工数を CONTEXT として添付すると、見積もり精度が上がります（経験則）。
2. ストーリーポイントは相対見積もりに留める: AI が出した SP はあくまで初稿。チームのベロシティで補正します。
3. 依存関係の確認は必須: AI は並列実行可能性を過大評価する傾向があります。依存関係は人間が確認します。

Gate-2: タスク分解レビュー

• 1タスクの粒度が1〜3日に収まっているか
• 依存関係が正しく反映されているか
• 完了条件が測定可能か（テスタブルか）
• 見積もりがチームのベロシティと整合するか

フェーズ3：AI によるスプリント計画

タスクが揃ったら、スプリントに割り当てる計画を立てます。

プロンプト例：スプリントバックログの優先順位付け

以下のバックログアイテムを、次のスプリントに入れる優先順位でソートしてください。
優先順位は (ビジネス価値 × 緊急度) / 工数 で計算してください。

各アイテムには「なぜこの順位なのか」の理由を1行で添えてください。

---
バックログ:
{{paste your backlog here}}

チームのベロシティ: {{X}} SP/スプリント
スプリント期間: 2週間
---

スプリントゴールのドラフト生成

以下のスプリントバックログから、スプリントゴールを1文で表現してください。
ゴールは「誰が」「何を」「なぜ」の形式で書いてください。

---
スプリントバックログ:
{{paste your sprint backlog here}}
---

Gate-3: スプリント計画の人間判断

ワークフロー全体像

┌─────────────────────────────────────────────────────────┐
│  フェーズ1: 要件定義                                      │
│  自然言語 → [AI: 構造化・曖昧フラグ] → Gate-1 → 確定    │
└─────────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────────┐
│  フェーズ2: タスク分解                                    │
│  エピック → [AI: タスク分解・見積もり] → Gate-2 → 確定  │
└─────────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────────┐
│  フェーズ3: スプリント計画                                │
│  タスク群 → [AI: 優先順位・ゴール案] → Gate-3 → 確定    │
└─────────────────────────────────────────────────────────┘
                         ↓
┌─────────────────────────────────────────────────────────┐
│  実装フェーズ（Claude Code / Codex による開発）           │
└─────────────────────────────────────────────────────────┘

ツール別の使い分け

AI 計画ツールには複数の選択肢があります。2026年版 AI ツール比較も参考にしてください。

Claude Code を計画フェーズで使う場合、セッション継続性の管理が重要です。詳細はClaude Code のセッション管理パターンを参照してください。

セキュリティ面では、要件定義フェーズで扱う情報には機密仕様が含まれることがあります。AI ツールへの情報提供範囲はAI コーディングのセキュリティ設計に基づき事前に決めておきましょう。

実践チェックリスト：翌スプリントから使える

要件定義フェーズ

• 自然言語の要件をプロンプト経由で GIVEN/WHEN/THEN 形式に変換する
• [要確認] フラグが付いた箇所をステークホルダーに確認する
• Gate-1（要件確定レビュー）の承認記録を残す

タスク分解フェーズ

• エピックをプロンプト経由で1〜3日粒度のタスクに分解する
• 依存関係を人間が目視確認する
• 完了条件がテスタブルか確認する
• Gate-2（タスク分解レビュー）を実施する

スプリント計画フェーズ

• AI 生成のバックログ優先順位をチームで議論する
• スプリントゴールを PO と合意する
• Gate-3（スプリント計画承認）を実施する

まとめ

AI 駆動開発の計画フェーズを一言で表すなら「AI が構造を作り、人間が文脈を足す」です。

AI は要件を GIVEN/WHEN/THEN に変換し、エピックをタスクに分解し、バックログの優先順位案を出せます。しかし「このビジネスで今最も重要なことは何か」「このチームのキャパシティはどの程度か」という判断は、依然として人間にしかできません。

ゲート設計 がこの分業を制度化します。Gate-1〜3 を置くことで、AI の出力が「人間の目を通らずに次フェーズに進む」事故を防げます。PlanGate のような自動強制機構を使うか、チームルールとして運用するかは状況によりますが、「ゲートを置く」という設計思想は共通です。

AIエージェントの三層成熟度モデルでいう Level 3（自律計画）に到達するまでの道のりは、このようなゲート設計を積み重ねることで初めて安全に歩めます。

本番運用のための包括的なチェックリストはLLM本番運用チェックリストも参考にしてください。

FAQ

Q1. AIに計画を丸投げしても問題ないですか？

問題があります。AI は構造化・列挙・パターン照合は得意ですが、ステークホルダーの利害・優先順位の最終判断・スコープカットのトレードオフは人間の文脈情報が必要です。AI 生成の計画は「ドラフト」として扱い、必ず人間のレビューゲートを通してください。

Q2. Claude CodeとCodexはどちらが計画フェーズに向いていますか？

長文の要件定義書や設計ドキュメント作成には Claude Code が向いています（長いコンテキスト保持が得意）。タスクを実装チケットに変換する用途では Codex のコード生成精度が活きます。用途によって使い分けるのが実践的です（経験則）。

Q3. レビューゲートをどのくらいの頻度で置けばよいですか？

最低でも「要件確定・タスク分解完了・スプリント計画確定」の3回は置いてください。チームの成熟度が上がるにつれてゲートの粒度を減らす方向に調整します。最初は多めに設定して「飛ばしてよいゲート」を見つける運用が安全です（経験則）。

Q4. AIの見積もりはどの程度信用できますか？

単体での信用度は低いです（経験則）。過去の類似チケット実績をコンテキストとして渡すと改善しますが、チームのベロシティ・外部依存・技術的不確実性の考慮が弱い傾向があります。SP の初稿生成に使い、プランニングポーカーで補正するのが現実的です。

Q5. セキュリティ上の懸念はありますか？

あります。要件定義フェーズでは機密仕様や個人情報が含まれることがあります。クラウド型の AI サービスに送信する情報の範囲を、AI コーディングのセキュリティ設計の原則に従って事前に決めてください。

References

• アジャイルソフトウェア開発宣言 — アジャイルの原則（公式サイト）
• Scrum Guide（日本語版） — スプリント計画の公式定義（公式ドキュメント）
• Claude Code 公式ドキュメント — Claude Code の概要（公式ドキュメント）
• OpenAI Codex ドキュメント — Codex の公式ガイド（公式ドキュメント）
• PlanGate 公式リポジトリ — ゲート型ワークフローハーネス（公式リポジトリ）