Claude Code: Coding Plan
最終更新:2026-08-31
Coding Plan により、Claude Code は「思いつきで実行」から「先に明確に考える」へと移行します — 複雑なタスクの実行前に計画を出力し、確認してから進めます。
💡 ヒント: Coding Plan は本質的に Claude Code に実行前に計画を出力させます。ステップ、影響範囲、リスク評価を含みます。実行前に確認することで、「途中で方向を間違える」無駄を回避します。
📋 前提条件: 第24章 - Agent SDK
1. 学ぶ内容
- Coding Plan メカニズム
- トリガーと使用方法
- 計画のレビューと修正
- 計画の実行と検証
- ベストプラクティス
2. Coding Plan メカニズム
(1) いつ使うか
| シナリオ | 計画が必要? | 理由 |
|---|---|---|
| マルチファイルリファクタリング | ✅ はい | 影響範囲が大きい |
| アーキテクチャ変更 | ✅ はい | 方向転換が不可逆的 |
| データ移行 | ✅ はい | データリスクが高い |
| シンプルなバグ修正 | ❌ いいえ | 影響が小さい |
| 単一ファイル追加 | ❌ いいえ | リスクが低い |
▶ 例1:Coding Plan のトリガー
TEXT
📖 参照専用
# 方法1:/plan コマンド
> /plan Migrate auth from Session to JWT
# 方法2:指示に「plan first」を含める
> Migrate auth from Session to JWT, plan first then execute
# 方法3:自動トリガー(大規模タスク)
> Refactor entire project's error handling
3. 計画の生成
(1) 計画の構造
TEXT
📖 参照専用
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Coding Plan: Session → JWT Auth Migration
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## Goal
認証を Session から JWT に移行
## Impact Scope
- Modified files: 12
- New files: 3
- Deleted files: 2
- DB changes: None
## Execution Steps
### Step 1: Create JWT utility module
- New src/auth/jwt.ts
- Implement token generation, verification, refresh
- Write unit tests
### Step 2: Modify auth middleware
- Modify src/middleware/auth.ts
- Change from Session to JWT verification
- Keep interface unchanged
### Step 3: Modify login/register routes
- Modify src/routes/auth.ts
- Return JWT token instead of setting Session
### Step 4: Modify protected routes
- Modify 8 route files
- Adjust auth check method
### Step 5: Clean up Session code
- Delete session config
- Remove express-session dependency
## Risk Assessment
- 🔴 High: ミドルウェアの移行はすべてのログインユーザーに影響する可能性
- 🟡 Medium: Token リフレッシュロジックは慎重な設計が必要
- 🟢 Low: ユーティリティモジュールは独立しており、既存コードに影響なし
## Estimate
- Tokens: ~80K
- Time: ~15 min
- Cost: ~$1.60
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Confirm execution? [y/n/modify]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▶ 例2:計画のレビューと修正
TEXT
📖 参照専用
> Step 5 doesn't need Session deletion, keep compatibility for 2 weeks
Claude Code:
Updated plan:
Step 5: Keep Session compatibility
- express-session を削除しない
- 双認証サポート(Session + JWT)を追加
- 2週間後に Session コードをクリーンアップ
Confirm? [y/n/modify] y
Starting execution...
4. 計画の実行と検証
(1) ステップごとの実行
TEXT
📖 参照専用
[Step 1/5] Create JWT utility module
→ src/auth/jwt.ts を作成中
→ 実行中: npm test -- jwt.test.ts
✅ Step 1 complete
/checkpoint "jwt-module-complete"
[Step 2/5] Modify auth middleware
→ src/middleware/auth.ts を修正中
→ 実行中: npm test -- auth.test.ts
✅ Step 2 complete
[Step 3/5] Modify login/register routes
✅ Step 3 complete
(2) 問題の処理
TEXT
📖 参照専用
[Step 4/5] Modify protected routes
→ 実行中: npm test
❌ 3テスト失敗
→ 根本原因:一部ルートが req.session に依存
→ 修正:ミドルウェアで JWT payload を req.user にマッピング
→ 再実行: npm test ✅
5. ベストプラクティス
(1) 計画レビューチェックリスト
| 確認項目 | 説明 |
|---|---|
| 影響範囲 | どのファイルが修正/追加/削除されるか? |
| リスク評価 | 高/中/低のリスクポイントは何か? |
| ロールバック計画 | 各ステップはロールバック可能か? |
| 依存関係 | ステップは順次か並列か? |
| テスト戦略 | 各ステップをどう検証するか? |
| Token 見積もり | 総消費は予算内か? |
(2) 実行の規律
| ルール | 説明 |
|---|---|
| ステップごとに確認 | 各ステップを確認してから続行 |
| チェックポイント | 主要ステップ後にチェックポイントを作成 |
| テスト優先 | 各ステップをテストで検証 |
| 適時調整 | 問題発生時に計画を修正 |
| コスト監視 | 各ステップで /cost を確認 |
6. 総合例:Plan を使った大規模マイグレーション
TEXT
📖 参照専用
> /plan Migrate entire microservice project from JavaScript to TypeScript
Claude Code が詳細な計画を生成:
## Phase 1: Infrastructure (1-2 hours)
Step 1: TypeScript と型定義をインストール
Step 2: tsconfig.json を作成(最初は loose mode)
Step 3: ビルドスクリプトを設定
## Phase 2: Shared Modules (2-3 hours)
Step 4: shared/types/ を移行(5ファイル)
Step 5: shared/utils/ を移行(8ファイル)
## Phase 3: Service Modules (3-4 hours, parallelizable)
Step 6: user-service/ を移行(12ファイル)
Step 7: order-service/ を移行(15ファイル)
Step 8: payment-service/ を移行(10ファイル)
## Phase 4: Strict Mode (1-2 hours)
Step 9: strict モードを有効化
Step 10: すべての型エラーを修正
Step 11: フルテスト検証
Total: 53ファイル修正、8ファイル新規
Estimate: ~200K tokens、~$4.00
> Phase ごとに実行、各 Phase 後に /checkpoint
[Phase 1 complete] /checkpoint "ts-infra"
[Phase 2 complete] /checkpoint "shared-modules"
[Phase 3 complete] /checkpoint "services"
[Phase 4 complete] /checkpoint "strict-mode"
✅ すべてのテスト合格、マイグレーション完了!
❓ よくある質問
Q Coding Plan は追加でどのくらい Token を消費しますか?
A 計画ステップで約10-20%多く消費します。しかし方向違いの無駄を回避できるため、トータルでは節約になります。
Q 計画は保存できますか?
A はい。計画は Markdown で出力されるため、ファイルにコピーして参照できます。
Q 小さなタスクにも Plan は必要ですか?
A いいえ。シンプルなバグ修正や単一ファイル追加は Plan なしの方が効率的です。Plan は影響の大きいタスク向けです。
Q 計画に厳密に従う必要がありますか?
A いいえ。修正、スキップ、ステップの順序変更が可能です。計画はガイドであり制約ではありません。
Q 複数の計画を生成して比較できますか?
A はい。Claude Code に「2-3つのアプローチを生成して比較」と依頼し、最善を選択してください。
Q Plan と Skill の違いは?
A Plan はタスク固有の一時的な計画です。Skill は再利用可能な標準ワークフローです。一回限りの大きなタスクには Plan を、反復的なワークフローには Skill を使用してください。
📖 まとめ
- Coding Plan は実行前に計画し、方向違いを回避
- トリガー:
/plan、指示での計画要求、大規模タスクの自動トリガー - 計画には:ステップ、影響範囲、リスク評価、Token 見積もりを含む
- 実行の規律:ステップごとに確認、チェックポイント、テスト検証、適時調整
- マルチステップのタスクには Plan + Checkpoint の組み合わせを推奨
📝 練習問題
- 基本 (⭐):
/planを使って3ステップの修正タスクを実行し、Plan なしの実行と比較してください。 - 応用 (⭐⭐): Coding Plan で5ステップ以上のリファクタリングを行い、各ステップでチェックポイントを作成してください。
- 高度 (⭐⭐⭐): 10ステップ以上の大規模マイグレーションの Plan を生成し、段階的に実行し、各 Phase の Token と時間を記録してください。