この記事は、筆者が音声入力で話した内容を Claude Code で読みやすく整理したものです。
書いてある主張も検証結果も筆者自身のもので、公開前にすべて目を通しています。
Claude Code の Plan モードは、依頼を投げても実装が始まらず、先に計画だけが返ってくるモードです。
確認の一手間が増えるぶん後回しにしていたのですが、承認したあとに残る計画ファイルのほうが気になって、中身まで見てみました。
この記事は、Plan モードの入り方と、実際に生成された計画ファイルを確かめた記録です。
忙しい人のための要約
Plan モードを使うかどうかを決めるだけなら、この3点で足ります。
-
Shift+Tabでフッターがplan mode onになれば、あとは普段どおり頼むだけで計画が返ってくる - 承認の前に計画を読むと、実装が1行も走らないうちに方針のズレを見つけられる
- 実装が終わったあとも計画は
~/.claude/plans/にファイルとして残るので、別のモデルや別のエージェントに渡せる
Plan モードとは（承認モードの1つ）
Claude Code に指示を送ると、ファイルを書き換える前やコマンドを走らせる前に「本当に実行していいですか」と聞かれることがあります。
この確認をどこまで挟むかを決めているのが承認モードという仕組みです。
Plan モードは、その承認モードの選択肢のひとつです。
調査と計画づくりだけに徹し、コードもコマンドも一切触らない状態を指します。
承認モードは4つある
ターミナル画面のいちばん下の行（フッター）に、いまどのモードかが表示されます。
| フッターの表記 | どう動くか |
|---|---|
⏸ manual mode on |
変更のたびに確認を求める |
⏵⏵ accept edits on |
ファイル編集を自動で承認する |
⏸ plan mode on |
調査と計画だけを行う |
⏵⏵ auto mode on |
安全性を自動で判定し、承認とブロックを振り分ける |
切り替えは Shift+Tab です。
押すたびに次のモードへ移り、画面下のフッターの表記が変わります。
循環の順番はこうなっています。
押す回数は覚えなくて構いません。
起動時にどのモードから始まるかは設定で変えられるので、フッターが plan mode on になるまで押すのが確実です。
Plan モードで何が起きないか
大きめの実装をいきなり任せると、方向がずれたまま最後まで走り切ってしまうことがあります。
そこから戻すには、書かれたコードを読んで、どこで曲がったのかを探すところから始めることになります。
方針が文章で読める状態を先に作っておけば、走り出す前にそこで止められます。
指示を適切に与えていれば思いどおりに進むこともありますが、Plan モードはその手前でズレを塞ぐ安全策です。
これができるのは、Plan モードでは承認するまでファイルが1行も書き換わらず、コマンドも走らないからです。
既存のコードを読んで、これからどう変えるつもりかを文章にするところまでしかしません。
Plan モードで実装を頼んでみる
フッターが plan mode on になったら、あとは普段どおりに頼むだけです。
Plan モード用の特別な書き方はありません。
題材にしたのは、機材貸出台帳の小さな Python CLI です。
貸出や登録といった出来事を1行ずつログに追記していき、現在の一覧はそのログを最初から再生して組み立てる、という作りにしてあります。
この作りを壊さずに機能を足せるかが、題材としてのポイントです。
そこへ投げた依頼文は一言だけです。
> 機材の更新と削除ができるようにしてください。
通常のモードなら、ここからファイルの書き換えが始まります。
しかし Plan モードでは、既存のコードをひととおり読んだあとに計画テキストが返ってきました。
末尾はこうなっています。
対象ファイル
- kizai/registry.py — build_items に2分岐追加
- kizai/cli.py — import追加、cmd_update/cmd_delete 追加、サブコマンド登録
- tests/test_registry.py — テスト4件追加
- kizai/store.py — 変更なし（append_event は既に汎用）
- data/events.jsonl — 変更なし（実行時に追記されるのみ）
どのファイルをどう触るつもりなのかが、実装前に全部並んでいます。
触らないファイルまで「変更なし」と明記されているのが、読む側としてはありがたいところでした。
計画を読んでから承認する
計画テキストの末尾には、そのまま進めていいかを聞く承認プロンプトが出ます。
Claude has written up a plan and is ready to execute. Would you like to proceed?
❯ 1. Yes, and use auto mode
2. Yes, manually approve edits
3. Tell Claude what to change
shift+tab to approve with this feedback
ctrl+g to edit in VS Code · ~/.claude/plans/<slug>.md
承認プロンプトの3つの選択肢
選択肢は3つです。
| 選択肢 | 選ぶとどうなるか |
|---|---|
1. Yes, and use auto mode |
フッターが auto mode on に切り替わり、そのまま実装が始まる |
2. Yes, manually approve edits |
編集のたびに確認が入る |
3. Tell Claude what to change |
計画そのものに注文を付けて書き直させる |
つまり、計画を読んで気になるところがあれば、実装を1行も走らせないまま3番で差し戻せるわけです。
承認を計画のレビューだと思っておくと、実装が走る前に差し戻せます。
最下行の ctrl+g to edit in VS Code · ~/.claude/plans/<slug>.md にも目を向けてください。
ここに出ているのが、この計画の保存先パスです。
あとで効いてくるので、頭の片隅に置いておいてください。
読んでみたら、計画に不備が混ざっていた
実際に読んでみると、動作確認の手順にこんな1行が混ざっていました。
確認後、手動実行で追記した検証用イベントは
data/events.jsonlから取り除く（またはバックアップから復元する）。
題材は、出来事を追記して再生する作りです。
そのため、追記済みの行を消すのはその前提そのものに反します。
機能の動作としては筋が通ってしまうぶん、できあがったコードを眺めているだけでは気づきにくい箇所です。
この手の食い違いは、実装が終わってから差分を追っても見つけにくいものです。
計画のうちに読めば、実装が1行も走る前に指摘して直せます。
ここが Plan モードの本筋の価値だと思っています。
その計画、ファイルとして残っている
承認画面の最下行に出ていたパス。
あれはファイルの実体で、実装が終わったあともそのまま残り続けます。
ここから話すのは「こういう使い方ができる」という提示です。
事前にしっかりすり合わせることがまず一番で、ファイルに残ることはついでぐらいの位置づけだと思っています。
保存先は ~/.claude/plans/<slug>.md です。
同じような依頼を何度か流したので、生成された計画も複数本あります（全体で 72行 / 5,545 B、もう1本は 48行 / 4,746 B）。
分量としては、渡された側がそのとおりに手を動かせる粒度でした。
中身はただの Markdown で、骨組みはこうなっていました。
# 機材の更新・削除機能を追加する
## Context
## 実装方針
### 1. `kizai/registry.py` — イベントのリプレイ処理を拡張
## 変更ファイル
## 検証方法
見出しの名前は毎回同じ形になるわけではありません。
実際、別の回では ## 検証方法 が ## 動作確認 になっていましたし、変更ファイルの一覧を独立した見出しに立てず Context の中に箇条書きで畳んでいる回もありました。
決まったテンプレートがあるというより、そのつど書き下ろされていると思っておくのがよさそうです。
粒度が伝わるように、「実装方針」の冒頭だけ実物を引いておきます。
### 1. `kizai/registry.py` — イベントのリプレイ処理を拡張
`build_items()` に以下の2種類の分岐を追加する:
- `item_updated`: 対象 `item_id` が既存であれば、イベントに含まれる `name` / `location` のうち **指定されているフィールドのみ** を上書きする（部分更新）。対象が存在しない場合は無視する（防御的に）。
- `item_deleted`: 対象 `item_id` を `items` から削除する。存在しない場合は無視する。
ファイル名は、依頼文から作った短い英字（スラッグ）にランダムな語を足したものになります。
そのため日本語で依頼するとスラッグ部分が空になり、fuzzy-purring-cocke.md のようなランダム語だけの名前が残ります。
中身を開かないと何の計画か分かりません。
承認画面に出るパスを控えておくか、ls -t ~/.claude/plans/ で新しい順に辿ってください。
別のセッション・別のモデルに渡せる
ファイルになっているということは、そのパスを別の相手に伝えれば済むということです。
筆者がよくやるのは、上位のモデルに計画だけ作らせて、その計画ファイルを別セッションの下位モデルに渡して実装させる型です。
ここでいう下位モデルとは、同じ Claude でも Opus と Sonnet のように能力とコストが違うラインナップのうち、軽いほうを指しています。
設計と計画は頭のいい相手に任せて、実装はジュニアレベルに回す、というイメージですね。
渡すときのプロンプトは、パスを指すだけで足ります。
> ~/.claude/plans/fuzzy-purring-cocke.md に計画があります。
この計画のとおりに実装してください。
何を作るかは計画に書いてあるので、渡された側が調査からやり直す必要はありません。
この渡し方は Claude Code どうしに限りません。
OpenAI の Codex CLI のような別のエージェントにも読ませられます。
あとから読み返せる
渡さずに、自分で読み返すぶんにも計画は効きます。
計画が残るということは、何をしようとしたかという記録が残るということです。
今の実装がどういう判断のうえに乗っているのかが、文章の形で手元に残ります。
コードのコメントにも、コミットメッセージにも、そこまでは書かれていません。
- プルリクエストのレビューで「どういう計画だったか」「そのとおりにいっているか」を照らし合わせる
- マージから数日経って実装の意図が分からなくなったときに読み返す
- 計画どおりにいかなかったときは、計画に矛盾があったのか、意図として書くべきことが抜けていたのかを振り返る
たとえば、計画ファイルごと AI に見せて確認させることもできます。
3つ目がいちばん面白いところで、原因を計画の側に返せます。
次に計画を立てるときや、設計そのものを見直すときの材料になるわけです。
opusplan：計画だけ上位モデルに任せる
渡すのも読み返すのも、こちらがファイルを動かす前提の話でした。
この流れを Claude Code 側に任せてしまう設定もあります。
/model の選択肢に opusplan があり、--model opusplan を付けて起動することもできます。
選ぶと、計画は Opus が立て、承認後の実装は resting model に切り替わります。
resting model というのは、計画が終わったあとに戻ってくる普段づかいのモデルのことです。
「下位モデルに渡す」話とは別の仕組みで、こちらは Claude Code が内部で自動的に切り替えます。
こちらは選べることを確かめただけで、効果までは測っていません。
そういう設定がある、という紹介にとどめます。
まとめ
Plan モードのデメリットは、計画を読んで承認するという一手間が挟まることだけです。
意図しない方向に進んだ実装を手戻りで直すほうがはるかに大変なので、承認の一手間はそれに比べればずっと小さいコストです。
使わない理由が見当たらないので、筆者は基本的に推奨する側に立っています。
書籍『Claude Codeで作って学ぶ AI駆動アプリ開発入門』では、承認モードの切り替えから Plan モードを使った実装まで、手を動かしながら順に進めます。
Xをフォローいただけると嬉しいです！
AI駆動開発（特に Claude Code）のノウハウや Tips をよく発信しています！