一行でいうと
ファイルを一切変更せず、調べて計画を出すだけのモードです。Shift+Tab で切り替えるか、依頼の頭に /plan を付けます。
設計図を読んで計画する場所と、実際に手を動かす場所をゲートで分けます。
なぜこれが効くのか
作者のBoris Chernyは、複雑なタスクでPlan modeに切り替えるだけで、成功率が2倍にも3倍にもなると語っています。単純な機能なのに、効果が大きい。
“You can double or triple your chances of success on complex tasks by switching to 'plan mode'”
筆者訳「プランモード」に切り替えるだけで、複雑なタスクの成功確率を2倍にも3倍にもできる。
理由は、AIの失敗の多くが実装の失敗ではなく、理解の失敗だからです。
- こちらの意図と違うものを作り始める
- 触ってほしくない場所まで書き換える
- 前提を取り違えたまま、最後まで走り切る
これらは全部、手を動かす前なら1行で直せます。動いたあとだと、直すのに時間がかかる。
計画の質は、そのまま実装の速さにも直結します。
“once there is a good plan, it will one-shot the implementation almost every time.”
筆者訳良い計画さえあれば、ほとんど毎回一発で実装をやり切る。
会議で言えば、指示を出す前に「私はこう理解しました」と復唱してもらうのに近い。復唱の20秒が、あとの30分を救います。
使い方
使い方はシンプルです。Shift+Tabで切り替えて、依頼を書くだけです。
$Shift+Tab（プランモードに切り替え）$この記事全体を、初学者向けにトーンを整えたい。どこをどう直すか計画を出して
計画が出てきたら、承認の仕方を選べます。
Ctrl+G で計画を自分の手で編集することもできます。計画の段階で直すのが、いちばんコストが低い。
公式ドキュメントは、この一連の流れを4段階のワークフローとして定義しています。Plan modeは、そのうち2番目の工程です。
Explore → Plan → Implement → Commit
Explore
Plan modeに入り、ファイルを読んで質問に答えさせる。まだ何も変更しない
Plan
詳細な実装計画を作らせる。Ctrl+Gでテキストエディタに開き直接編集できる
Implement
プランモードを解除し、計画と照らし合わせながら実装させる
Commit
説明的なメッセージでコミットさせ、プルリクエストを作らせる
スキップしていい基準も、公式ドキュメントは明示しています。
If you could describe the diff in one sentence, skip the plan. （差分を1文で言い表せるなら、計画は飛ばしていい）
typo修正やちょっとした追記に計画が要らないのは、この基準のとおりです。
よくある誤解と罠
罠1: 「読み取り専用＝安全モード」だと思う
これは誤解です。読み取り専用なのはあなたのファイルに対してであって、外部への副作用が完全にゼロという意味ではありません。Web検索のような外向きの操作は起こりえます。
罠2: 小さな作業にも使う
typo修正やちょっとした追記に計画は要りません。効くのは、複数ファイルにまたがる変更、方向を間違えると手戻りが大きい作業です。
罠3: 計画を読まずに承認する
これをやると、Plan modeを使っていないのと同じです。むしろ「確認したつもり」になる分、危ない。
ここは公式ドキュメントの、承認疲れについての一文が刺さります。
After the tenth approval you're not really reviewing anymore, you're just clicking through. （10回目の承認では、もうレビューしていない。ただクリックしているだけだ）
承認を作業にしない。計画は読むために出させています。
使いどころ
効くのは、手戻りが大きい作業です。
- 原稿全体の構成を変える前に、変更方針を出させる
- スライド一式のトーンを揃える前に、どこをどう触るか示させる
- 大きな整理（フォルダの再編、命名の統一）の前に必ず
判断の目安はこうです。「間違った方向に進まれたら、やり直しが面倒か」。面倒ならPlan modeを挟む。
2026年6月の変化：作者自身はもうPlan modeを主に使っていない
結論から言うと、ここまでの説明は今も有効です。ただし判断の基準そのものが動いていることは知っておいてください。
Claude Code一般提供から1年を振り返るやり取りの中で、Boris Cherny本人がこう投稿しています。
“When we first demoed Claude Code internally, it got two reactions on Slack. A year after GA, @_catwu and I sat down to talk about what's changed: why I use auto mode instead of plan mode, how routines fix bugs before I see them, why I do most of my coding from my phone now, and...”
筆者訳Claude Codeを社内で初めてデモしたとき、Slackでは2つの反応があった。一般提供から1年、@_catwuと座って何が変わったかを話した。なぜプランモードの代わりにオートモードを使うようになったか、ルーティンがどうやって私が見る前にバグを直しているか、なぜ今はコーディングの大半をスマホからやっているか、など。
このやり取りの中でBorisは、以前はPlan modeを使っていたが今は使わなくなったこと、新しいモデル（Opus 4.6以降）が計画のステップを必要としなくなったことを述べたとされています。この部分は原典の文字起こしまでは確認できておらず、複数の要約記事を経由した内容です。
だからといって、この講座がPlan modeを教える方針を変える理由にはなりません。複雑なタスクの前に理解を揃えるという考え方そのものは、モデルが変わっても有効です。ただ、Plan modeを毎回挟むのが唯一の正解だという思い込みだけは持たないでください。モデルが賢くなるほど、この判断基準自体も動いていきます。
今日のまとめ
- Plan modeは、ファイルを変更せず計画だけ出すモード。成功率が2〜3倍になる
- 一番安く直せるのは計画の段階。承認前に必ず読む
- 「読み取り専用」であって「安全」ではない。手戻りが大きい作業で使う
Plan modeの詳細、承認時の選択肢、既定モードの設定方法。
ここまでで9語。最後は付録として、これらをいつ使うかの地図になる「AI導入の5段階」を読みます。