🚀 Claude Code の Plan Mode 完全ガイド：安全にコードを調査して計画を立てる方法 🔍

はじめに

「Claude にコードを書いてもらったら、予想外の変更をされて困った…」😰
「大規模なリファクタリングの前に、まず計画を立てたい…」🤔
「チームで実装方針を議論したいけど、どうやって整理すればいい？」💭

こんな悩みを解決するのが、Claude Code の Plan Mode（プランモード） です。✨

Plan Mode は、Claude がコードを読み取り専用で調査し、実装計画を作成する特別なモードです。ファイルを編集せずに安全にコードベースを分析できるため、大きな変更の前に計画を立てたり、チームで方針を議論したりするのに最適です。

ステップ	作業内容
1️⃣	要件を整理する 📝
2️⃣	Plan Mode で計画を立てる 🔍
3️⃣	計画をレビュー・承認する ✅
4️⃣	自動承認モードで実装する ⚡
5️⃣	テストして検証する 🧪
🎉	完成！

この記事では、Plan Mode の基本的な使い方から実践的な活用方法まで、初心者向けに分かりやすく解説します。

Plan Mode とは

Plan Mode の特徴

Plan Mode は、Claude Code の3つの実行モードの1つです。

3つの実行モード:

通常モード	自動承認モード	Plan Mode
コードを読み書きして実装する 📝	編集を自動承認して高速化 ⚡	読み取り専用で調査・計画を立てる 🔍 ← 今回の主役

3ステップで始める Plan Mode（クイックスタート）🚀

Plan Mode を今すぐ試したい方のために、最短3ステップで体験できる方法を紹介します。

ステップ1: Plan Mode を起動 💻

# Plan Mode に切り替え
/plan

ステップ2: やりたいことを伝える 💬

既存のログイン機能を調査して、改善案を提案してほしい

ステップ3: 計画を確認して承認 ✅

Claude が調査して計画を提示するので、内容を確認して承認するだけ！
これだけで Plan Mode を体験できます！ 🎉

Plan Mode 起動 → やりたいことを伝える → 計画を確認・承認 → 完了！

もっと詳しく知りたい方は、この後の「Plan Mode で何ができるか」から読み進めてください。 ⬇️

Plan Mode で何ができるか

主な機能:

✅ 読み取り専用の調査: ファイルを編集せずにコードベースを調査
✅ 安全な分析: 誤った変更を防ぐ 🛡️
✅ 計画の作成: 実装前に詳細な計画を立てる 📋
✅ 成果物の保存: plan.md ファイルとして計画を保存 💾

なぜ Plan Mode が必要なのか

通常モードの問題点:

ユーザー: 「認証システムを改善して」
    ↓
Claude: すぐにコードを書き始める 💨
    ↓
結果: 予想外の変更、設計の問題、手戻りが発生 😱

Plan Mode の利点:

ユーザー: 「認証システムを改善する計画を立てたい」
    ↓
Claude: コードを調査（読み取り専用）🔍
    ↓
Claude: 計画を作成して提示 📋
    ↓
ユーザー: 計画を確認・承認 ✅
    ↓
実装開始（自動承認モードで）⚡

いつ Plan Mode を使うべきか

以下のような場面で Plan Mode が特に有効です：

1. 大規模な変更の前 🏗️

複数ファイルにまたがるリファクタリング
アーキテクチャの変更
ライブラリの移行（例: JWT → OAuth2）

2. コードベースの理解 📚

既存コードの調査
依存関係の把握
影響範囲の特定

3. 設計の検討 🎨

複数のアプローチを比較
トレードオフの評価
リスクの洗い出し

4. チーム開発 👥

実装方針の共有
レビュー前の計画作成
ドキュメントの自動生成

Plan Mode の使い方

起動方法

Plan Mode の起動方法は3つあります。

方法1: コマンドラインから起動 💻

新しいセッションを Plan Mode で開始：

claude --permission-mode plan

プロンプトで質問するだけ：

ログイン機能を OAuth2 に移行したい

方法2: /plan コマンド（おすすめ）⭐

Claude Code 実行中に、プロンプトで /plan と入力：

# まず通常モードで起動
claude

# プロンプトで
/plan

# → Plan Mode に切り替わる ✨

この方法なら、通常モードから簡単に Plan Mode に切り替えられます。

方法3: Shift+Tab ショートカット（最速）⚡

実行中に Shift+Tab を押すと、モードが循環します：

通常モード 📝
    ↓ Shift+Tab
自動承認モード ⏵⏵ (accept edits on)
    ↓ Shift+Tab
Plan Mode ⏸ (plan mode on) 🔍 ← ここ
    ↓ Shift+Tab
通常モード（戻る）📝

Shift+Tab を2回押す と Plan Mode になります。

Plan Mode での実行の流れ

Plan Mode で計画を立てる流れを見ていきましょう。

Plan Mode の流れ:

ステップ	内容	説明
1️⃣	コードベースの調査 🔍	Claude が自動的に関連ファイルを検索し、既存実装を確認
2️⃣	ユーザーへの質問 💬	不明点を質問（必要時のみ）
3️⃣	計画の作成 📋	調査結果をもとに実装計画を作成
4️⃣	計画の保存 💾	plan.md ファイルとして保存
5️⃣	ユーザー承認 ✅	計画を確認して承認

ステップ1: コードベースの調査 🔍

Claude が自動的にコードベースを調査します。

調査内容:

関連ファイルの検索
既存実装の確認
依存関係の把握
テストの有無確認

例:

プロンプト: 「ログイン機能を OAuth2 に移行したい」

Claude の調査:
→ 既存の認証コード（src/auth/session.ts）を発見
→ JWT ベースの実装を確認
→ OAuth2 ライブラリの有無をチェック
→ テストファイル（tests/auth/）を確認

ステップ2: ユーザーへの質問（必要に応じて）💬

Claude が不明点を質問します。

質問の例:

「OAuth2 プロバイダーは Google を使いますか？」
「既存ユーザーは再ログインが必要で問題ないですか？」
「段階的移行と一括移行、どちらが良いですか？」

複数選択式の質問が表示されるので、選ぶだけです。

ステップ3: 計画の作成 📋

調査と質問の結果をもとに、Claude が計画を作成します。

計画に含まれる内容:

項目	内容
実装の概要 📝	何をするのか、なぜそのアプローチを選んだか
実装ステップ 📊	ステップバイステップの手順、各ステップの詳細
修正が必要なファイル 📂	ファイルパスと行番号、変更内容の概要
注意点とリスク ⚠️	破壊的変更、データ移行の必要性、互換性の問題
検証方法 ✅	テストの実行方法、動作確認手順

ステップ4: 計画の保存 💾

計画が plan.md ファイルとして保存されます。

デフォルトの保存場所:

~/.claude/plans/計画ファイル名.md

プロジェクト内に保存（plansDirectory 設定時）:

.claude/plans/計画ファイル名.md

保存場所の詳細は、後述の「計画ファイルの保存場所（plansDirectory）」セクションをご覧ください。

ステップ5: ユーザー承認 ✅

Claude が計画を提示し、承認を求めます。

計画を作成しました。確認してください。

[計画の内容が表示される]

この計画で実装を進めて良いですか？

承認後の選択肢:

実装開始: Plan Mode を終了し、自動承認モードで実装 ⚡
計画修正: Plan Mode のまま計画を修正 ✏️
キャンセル: 計画を破棄 ❌

Plan Mode の実践例

実際の使用例を見ていきましょう。

例1: 既存コードのリファクタリング 🔧

シナリオ

既存の認証コードが複雑になってきたので、整理したい。

Plan Mode での操作

# Plan Mode に切り替え
/plan

プロンプト:

src/auth/ ディレクトリのコードをリファクタリングしたい。
特に以下を改善したい：
- 関数が長すぎる（200行以上）
- 責務が混在している
- テストが書きにくい

Claude の調査 🔍

→ src/auth/session.ts を確認（350行）
→ 認証、セッション管理、トークン更新が混在
→ テストカバレッジ 45%（低い）
→ 依存関係: express-session, jsonwebtoken

Claude の計画 📋

# 認証コードリファクタリング計画

## 概要
src/auth/session.ts を3つのモジュールに分割し、責務を明確化する。

## 実装ステップ

### ステップ1: モジュール分割
- src/auth/authentication.ts: 認証ロジック
- src/auth/session-manager.ts: セッション管理
- src/auth/token-handler.ts: トークン処理

### ステップ2: インターフェース定義
- 各モジュールの公開APIを定義
- 依存関係を整理

### ステップ3: テスト追加
- 各モジュールの単体テスト
- カバレッジ 80% 以上を目標

### ステップ4: 既存コードの移行
- session.ts から新モジュールへ移行
- 後方互換性を維持

## 影響範囲
- src/auth/session.ts: 削除
- src/routes/auth.ts: import文のみ変更
- tests/auth/: テストファイル追加

## 検証方法
- npm test で全テスト実行
- カバレッジレポート確認

メリット

✅ リファクタリングの全体像が分かる
✅ ステップが明確で実装しやすい
✅ リスクを事前に把握できる

例2: 新機能の実装計画 🆕

シナリオ

ユーザープロフィール編集機能を追加したい。

Plan Mode での操作

# Plan Mode に切り替え
/plan

プロンプト:

ユーザープロフィール編集機能を追加したい。
要件:
- ユーザー名、メールアドレス、プロフィール画像を編集可能
- バリデーションあり
- 既存の認証システムと統合

Claude の質問 💬

質問1: プロフィール画像のアップロード方式
[ ] ローカルストレージ
[ ] AWS S3
[✓] Cloudinary（推奨）

質問2: バリデーション方式
[✓] サーバー側のみ（推奨）
[ ] クライアント側とサーバー側の両方

Claude の計画 📋

# ユーザープロフィール編集機能 実装計画

## アーキテクチャ

### フロントエンド
- src/components/ProfileEdit.tsx: 編集フォーム
- src/hooks/useProfileUpdate.ts: 更新ロジック

### バックエンド
- src/routes/profile.ts: API エンドポイント
- src/services/profile-service.ts: ビジネスロジック
- src/validators/profile-validator.ts: バリデーション

### データベース
- users テーブルに以下カラム追加:
  - display_name: VARCHAR(100)
  - profile_image_url: VARCHAR(500)

## 実装ステップ

### フェーズ1: バックエンド
1. データベースマイグレーション
2. バリデーター実装
3. サービス層実装
4. API エンドポイント実装

### フェーズ2: フロントエンド
1. 編集フォームコンポーネント
2. 画像アップロード機能
3. API 連携

### フェーズ3: テスト
1. API 統合テスト
2. コンポーネントテスト

## 検証方法
- Postman でAPI テスト
- ブラウザでE2Eテスト

例3: バグ調査と修正計画 🐛

シナリオ

「ログアウト後も一部のデータが残る」というバグを修正したい。

Plan Mode での操作

# Plan Mode に切り替え
/plan

プロンプト:

ログアウト後にユーザーデータが残るバグを調査して、修正計画を立てたい。

Claude の調査 🔍

→ src/auth/logout.ts を確認
→ セッションのクリアは実装済み
→ ローカルストレージのクリアが漏れている
→ Service Worker のキャッシュも残っている

Claude の計画 📋

# ログアウトバグ修正計画

## 原因
ログアウト時に以下がクリアされていない:
1. localStorage の user データ
2. Service Worker キャッシュ
3. IndexedDB の一部データ

## 修正箇所

### src/auth/logout.ts:45
現在:
```typescript
// セッションのみクリア
await sessionManager.clear();

修正後:

// セッション、ストレージ、キャッシュをクリア
await sessionManager.clear();
localStorage.removeItem('user');
localStorage.removeItem('preferences');
await clearServiceWorkerCache();
await clearIndexedDB();

plansDirectory 設定について

この計画ファイルは、デフォルトでは ~/.claude/plans/ に保存されます。

プロジェクト内で管理したい場合は、.claude/settings.json で plansDirectory を設定できます。

設定のメリット:

✅ 計画ファイルをプロジェクトと一緒に Git で管理
✅ チームメンバーと計画を共有
✅ プロジェクトごとに計画を整理

plansDirectory のメリット

✅ Git で管理: 計画の履歴を追跡できる
✅ チームで共有: チームメンバーと計画を共有できる
✅ プロジェクトと一緒: 関連ファイルがまとまる

保存先の比較

設定	保存先	メリット	デメリット
デフォルト	`~/.claude/plans/`	設定不要	プロジェクトと分離
plansDirectory設定	`.claude/plans/`	Git管理可能、チーム共有可能	設定が必要

実際の使い分け

個人プロジェクトの場合 🧑‍💻:

// デフォルトのまま（~/.claude/plans/）でOK

チーム開発の場合 👥:

{
  "plansDirectory": ".claude/plans"
}
// → Git で計画を共有

plansDirectory の設定例

プロジェクトルートに .claude/settings.json を作成すると、Plan Mode で作成した計画がプロジェクト内に保存されます。

# プロジェクト構成例
my-project/
├── .claude/
│   ├── settings.json       # plansDirectory を設定
│   └── plans/              # 計画ファイルが保存される
│       ├── auth-refactor.md
│       └── profile-feature.md
├── src/
└── package.json

チーム開発では、この設定ファイルと計画ファイルを Git で管理することで、チーム全体で実装方針を共有できます。

Plan Mode を最大限活用するコツ

コツ1: 具体的な質問をする 🎯

悪い例 ❌:

コードを改善して

良い例 ✅:

src/auth/ のコードをリファクタリングしたい。
特に以下を改善したい：
- 長すぎる関数を分割
- テストカバレッジを80%以上に
- 依存関係を整理

コツ2: 要件を明確にする 📝

悪い例 ❌:

ログイン機能を追加

良い例 ✅:

ソーシャルログイン機能を追加したい。
要件:
- Google、GitHub でログイン可能
- 既存のメールログインと併用
- ユーザーデータは既存DBに統合

コツ3: 制約条件を伝える ⚠️

プロフィール編集機能を実装したい。

制約:
- 既存APIとの互換性を保つ
- データベーススキーマ変更は最小限に
- リリースは段階的に（まずベータユーザーのみ）

コツ4: 計画を段階的に立てる 📊

大きな機能は、段階的に計画を立てると良いです。

# フェーズ1: 要件整理
/plan
「OAuth2移行の要件を整理したい」

# フェーズ2: 技術設計
/plan
「要件に基づいて技術設計を作成したい」

# フェーズ3: 実装計画
/plan
「設計に基づいて実装計画を作成したい」

# フェーズ4: 実装
Shift+Tab（通常モードに戻る）
「計画に従って実装を始めたい」

まとめ

Plan Mode を使うべき理由 🌟

安全性: ファイルを編集せずに調査できる 🛡️
効率性: 手戻りを防げる ⚡
品質: 事前に設計を検討できる 💎
チーム開発: 計画を共有・議論できる 👥

Plan Mode の起動方法（3つ）

方法	コマンド	使いどころ
コマンドライン	`claude --permission-mode plan`	🐢 セッション開始時
/plan	`/plan`	🐇 セッション途中
Shift+Tab	`Shift+Tab` 2回	🚀 最速切り替え

次のステップ 🚀

Plan Mode を試す
```
/plan
```
小さな機能で練習 💪
- 既存コードの調査
- シンプルな機能の計画作成

plansDirectory を設定（任意）📁

{
  "plansDirectory": ".claude/plans"
}

チームで活用 👥
- 計画を Git で共有
- レビュー前に計画を作成

おすすめの使い方 💡

大規模な変更の前には、必ず Plan Mode を使う

# ❌ いきなり実装
claude
「認証システムを OAuth2 に移行して」

# ✅ まず計画
/plan
「認証システムを OAuth2 に移行したい」
→ 計画を確認・承認 ✅
→ 実装開始 🚀

ワークフロー図 📊

Plan Mode ベストプラクティス:

ステップ	作業内容
1️⃣	要件を整理する 📝
2️⃣	Plan Mode で計画を立てる 🔍
3️⃣	計画をレビュー・承認する ✅
4️⃣	自動承認モードで実装する ⚡
5️⃣	テストして検証する 🧪
🎉	完成！

参考リンク 🔗

Plan Mode を使いこなして、より安全で効率的な開発を実現しましょう！🚀✨