機能を学ぶ · COURSE
Plan Mode 完全ガイド
大きな変更を安全に進める。読み取りフェーズで計画を固めてから実装に入る。
audience
中級者以上
duration
50分
lessons
5 章
reviewed
2026.05
2 分でコース概要を見る
先に読むとよい
このコースで作るもの
- 01Plan Mode 適用 5 シナリオの判定フローチャート
- 02Plan プロンプト雛形（読み取り → 計画 → 承認）
達成目安
全 5 レッスンを読み、コース完了マークを付ける
未完了
クイズ 5 問に挑戦し、正答率 80% 以上
未挑戦
成果物 2 個を実際に手元に作る
自己チェック
コース構成
このコースで学ぶこと
- 01
Plan Mode とは何か
Claude が編集せず『読む・調べる・提案する』だけに専念する権限モード。承認を経て初めて編集に入る。
`Shift+Tab` または `/plan` で切替。Plan Mode 中は Read / Glob / Grep / WebFetch などの read-only ツールしか使えません。Edit / Write / Bash（書込系）はブロックされます。
大規模な改修・初見のコードベース・本番リポジトリでの作業では、まず Plan Mode で『何をするか』を明確にしてから、承認して実装フェーズに入るのが鉄則。
理解度チェック
Q1.Plan Mode 中に使える tool の組合せとして正しいのは？
- 02
Plan Mode を使うべき 5 つのシナリオ
全部 Plan Mode で始める必要はない。価値が出る場面を覚えておく。
- 🟠 **初見のコードベース** — 「触る前にまず地図を作って」
- 🟠 **大規模リファクタ** — 影響範囲が読めない時
- 🟠 **本番リポジトリ** — 一文字も間違えたくない作業
- 🟠 **アーキテクチャ判断** — トレードオフの提示を求める時
- 🟠 **他人のコード** — レビュー・引き継ぎ前の読み込み
理解度チェック
Q1.次のうち、Plan Mode を挟むメリットが最も“少ない”シナリオは？
- 03
効果的な Plan プロンプトの書き方
「Plan Mode で X してください」と頼むだけではダメ。具体的な観点・出力形式を指定すると質が跳ね上がる。
text# 良い例：観点と出力を指定 /plan > src/api/users.ts が肥大化しています（450 行）。3 つの分割案を出してください。 各案について以下を比較表にしてください: - (1) 分割後のファイル構成 - (2) 影響範囲（変更が必要な他ファイル） - (3) テストの追加・修正コスト - (4) リスク（高/中/低） - (5) 推奨度（◎ ○ △） 最後に「私のおすすめ案」を理由付きで。 # 悪い例：丸投げ > Plan Mode で users.ts を綺麗にして理解度チェック
Q1.Plan Mode に渡すプロンプトとして“質が高い”のはどれ？
- 04
承認 → 実装への移行
Plan の出力を見て『この方針で OK』と思ったら、Shift+Tab で plan モードを解除して実装フェーズへ。
実装フェーズでも、最初のターンで「承認した Plan を実装してください。Phase 1 だけ。各ステップ終了で確認して」と伝えると安全です。Plan の中で TodoWrite を使わせておけば、進捗が見える化されたまま実装が進みます。
手を動かす
0 / 4
理解度チェック
Q1.Plan Mode を解除する操作は？
- 05
失敗パターンと対策
Plan Mode あるある。事前に知っていれば回避できる。
- ❌ Plan 後に実装を任せたら全然違うことを始めた → 「承認した Plan の通りに」と明示する
- ❌ Plan が抽象的すぎて使えない → プロンプトで観点・出力形式を具体的に
- ❌ Plan を見ずに『はい』と承認 → ちゃんと読む。読めない量なら Plan が長すぎる
- ❌ Plan Mode 中に試行錯誤で時間が溶ける → 30 分タイマーを切る、ダメなら一度休む
- ❌ Plan を 1 案だけ出させる → 必ず 2-3 案を比較させる
理解度チェック
Q1.Plan Mode を承認したあと、実装に移るときに最も効くひと言は？
