Claude Codeのプランモードと作業範囲の決め方【Claude Code実践入門第2回】

「頼んでいないファイルまで直されていて、元に戻すのに手間がかかりました」
「プランモードを使うといいと聞きますが、毎回使うと面倒です。どんな作業なら使うべきですか」

第1回では、コンテキストは毎ターン送り直されること、公式の失敗パターンの1つに「終わらない探索」（範囲を決めずに調べさせ、コンテキストを使い切る）があることを見ました。走らせてから直すより、走らせる前に範囲を決めるほうが、ずっと安く済みます。

第2回では、Code タブでのプランモードの使い方、計画を省いてよい作業と要る作業の見分け方、計画を「実際に読む」ときの3つの見どころ、そして範囲を決めるプロンプトの4つのコツを扱います。数値・仕様は2026年10月時点です。

Codeタブでのプランモード
計画を省いてよい作業・要る作業
計画は「実際に読む」
プロンプトの4つのコツ
考えてみよう
まとめ
連載「Claude Code実践入門」全9回

Codeタブでのプランモード

プランモードでは、Claude は読み取りだけで調べ、変更案（計画）を出します。ファイルは何も変更しません。

Code タブのモードのメニューを示した図（日本語の表示。2026年10月時点）。枠の見出しは「モード（入力欄の下の表示をクリック）」。4行が並び、「自動：Claudeが権限の決定を処理します（1）」「手動：変更前に常に確認する（2）」「編集を受け入れる：すべてのファイル編集を自動的に承認（3）」「プラン：変更を加える前に計画を作成（4）」。どの行にも既定の印は付いていない。その下に破線の枠で「権限をバイパス」があり、「設定（Settings → Claude Code の Allow bypass permissions mode）で有効にしたときだけ出る」と添えてある。枠の外に2つの箱があり、「メニューから選ぶ（1〜4の数字でも選べる）」と「Ctrl＋Shift＋M（Macは Cmd＋Shift＋M）」。赤い文字で「CLIの Shift＋Tab は、Codeタブでは使えない」。小さな注記は「選んだモードはフォルダーごとに記憶される（プランを除く）」と「Code タブのモードのメニュー（日本語の表示。2026年10月時点）」。

切り替え方：入力欄の下のモード表示をクリックして、メニューから選びます。メニューが開いているときは数字キーでも項目を選べます。キーボードなら Ctrl＋Shift＋M（Mac は Cmd＋Shift＋M）でモードのメニューが開きます
CLI との違い：CLI の Shift＋Tab は、Code タブでは使えません。公式の文書は「Desktop では、Shift＋Tab はターミナルの対話モードのようには権限モードを切り替えない」と書いています
記憶される範囲：メニューで選んだモードはフォルダーごとに記憶されます。ただし 「プラン」だけは、そのセッション限りです。メニューで選んだモードは、そのフォルダーでは設定の既定（permissions.defaultMode）より優先されます
公式の勧め：複雑な作業は「プラン」で始め、計画を承認したら「編集を受け入れる」か「手動」に切り替えて実行します

日本語の画面でのモードの表示名は、「自動」「手動」「編集を受け入れる」「プラン」です。「権限をバイパス」は、Pro・Max では、設定（Settings → Claude Code）の「Allow bypass permissions mode」を有効にしたときだけメニューに出ます。入力欄の下には、モード・モデル・Effort が並んで表示されます。モードの詳しい違いは、第5回の「6つの権限モード」で扱います。

CLI では：Shift＋Tab で権限モードを切り替えます。auto から始まったセッションで最初に押すと default になり、その後は default → acceptEdits → plan の順に回ります（プランの後に、有効にしたモードが続きます）。プランモードで起動するには claude --permission-mode plan です。計画が出ると、承認の選択肢（Yes, and use auto mode／Yes, manually approve edits／No, keep planning）が出ます。Code タブの承認の画面の選択肢は、筆者は確かめていません。

連載「Claude活用入門」第5回「探索→計画→実装→検証→コミット」では、プランモードを「Shift＋Tab で切り替え」と紹介しました。これは CLI の操作で、Code タブでは上の方法を使います。

既定のモードについて：CLI と VS Code の拡張機能では、v2.1.283 以降は auto mode から始まります（活用入門第5回「権限と auto mode」）。デスクトップアプリだけの組み込みの既定の値は、公式の文書には書かれていません。デスクトップアプリは CLI と同じ設定ファイルを読み、permissions.defaultMode を新しいローカルのセッションに適用します。筆者の個人のアカウントの Code タブでは、新しいセッションは「自動」から始まりました（2026年10月4日の記録。第5回の「Code タブでの権限の操作」）。

出典は https://code.claude.com/docs/en/desktop と https://code.claude.com/docs/en/permission-modes です。

計画を省いてよい作業・要る作業

プランモードには手間がかかるので、すべての作業に使う必要はありません。

	例	進め方
計画を省いてよい	誤字の修正、ログの1行追加、変数名の変更	そのまま頼む
計画が要る	どこを変えるかはっきりしない、複数のファイルにまたがる、慣れていない領域	「プラン」で計画を出させ、読んで直してから実行する
Claudeに聞かせる	要件そのものがあいまい	「この作業について、私にインタビューして」と頼み、質問に答えてから計画させる

公式のベストプラクティスの基準は、「差分を1文で説明できるなら、計画は省く」です。計画がいちばん役に立つのは、方法に確信が持てないとき、変更が複数のファイルにまたがるとき、変更するコードに慣れていないときです（https://code.claude.com/docs/en/best-practices ）。

インタビューは、公式の文書の「Let Claude interview you」の節の使い方です。大きな機能では、最小限のプロンプトで始め、AskUserQuestion ツールを使って自分にインタビューするよう頼みます。公式の例の文は「I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.」です。

冒頭の2つ目の相談がこれです。計画が要るかどうかは、差分を1文で説明できるかで決めます。

計画は「実際に読む」

プランモードの価値は、計画を人が読んで直せることにあります。Claude Academy のレッスン「長時間セッションの操縦」（Steering long sessions）は、計画にざっと目を通すのではなく、実際に読むよう勧めています。計画が綿密であるほど、実行が始まってから驚くことが減ります。

プランモードの流れの図。「① プランで調べる（読むだけ）」から「② 計画」、「③ 人が読む」へ進み、③から「④ 承認」、「⑤ 実行（編集を受け入れる）」へ進む。③から②へ戻る赤い矢印に「直させる」とある。下の枠「③で読む3点」は、「計画にないファイルを変えようとしていないか」「本番の環境に触れる手順が入っていないか」「最後にどう確かめるか（検証の手順）があるか」の3つ。結びは「計画を直すほうが、走らせてから片付けるより速い」。

読むときは、変更するファイルの一覧、変更の順番、確かめ方の3つを見ます。

計画にないファイルを変えようとしていないか
本番の環境に触れる手順が入っていないか
最後にどう検証するかが書かれているか

ずれや抜けがあれば、「手順3の前に、現在の設定のバックアップを取る手順を足して」のように、計画に足すよう頼みます。計画を直すほうが、走らせてから後片付けするよりずっと速く済みます。

計画は流し読みせず、変更するファイル・順番・確かめ方を読む
計画にない変更、本番に触れる手順、検証の欠けを探す
計画を直すほうが、走らせてから片付けるより速い

CLI では、計画を Ctrl＋G で既定のテキストエディターに開き、直接直してから進められます（活用入門第5回「探索→計画→実装→検証→コミット」）。Code タブで使えるかは、確認できていません。

筆者が試したら：練習用のリポジトリ（NTP の chrony の参照先を設定する playbook）で、プランモードに「NTPの参照先を3台にしてください」と頼みました。ファイルは何も変わらず、計画が出ました。その計画には、頼んでいない「リストに無い server 行を削除する」タスクが入っていました。本番で既存の行を消すのは別の変更として扱うべきなので、外させました。参照先が2台のときも同じで、2回とも、頼んでいない削除が計画に入りました。計画を読まずに走らせていたら、実装の後で気づくことになります。

プロンプトの4つのコツ

作業範囲は、プロンプトでも決められます。公式のベストプラクティス（Provide specific context in your prompts）の4つのコツを、NTP の例で見ます。

コツ	悪い例	良い例
範囲を決める	「NTPの設定を直して」	「roles/ntp/ だけを対象に、chronyの参照先を ntp1〜ntp3.example.jp の3台に増やして」
情報源を示す	「ログを見て原因を調べて」	「/var/log/messages の10:00〜10:15を見て、chronydのエラーを調べて」
既存のやり方を示す	「playbookを作って」	「roles/syslog/ と同じ構成で roles/ntp/ を作って」
症状と「直った」の定義を書く	「時刻がずれる」	「server01で chronyc tracking の Leap status が Normal にならない。Normalになれば完了」

参照先を3台にするのは、連載「NTP入門」第3回「何台の時刻源を使うか」で見たように、2台は食い違ったときに決められず、1台と大差ないためです
chronyc tracking の Leap status の見方は、連載「NTP入門」第4回「chronyc trackingの読み方」にあります

出典は https://code.claude.com/docs/en/best-practices#provide-specific-context-in-your-prompts です。

渡し方の補足です。

ファイルは @ で指定できます（@ に続けてファイル名。場所を説明する代わりに、Claude が読んでから答えます）。Code タブでは、@ の指定は Local と SSH のセッションで使えます（クラウドと WSL のセッションでは使えません）
画像や PDF は、添付ボタンかドラッグ＆ドロップで渡せます（Code タブ）。公式のベストプラクティスは画像の貼り付けを一般の操作として書いていますが、Desktop の機能の比較表では、CLI の「File attachments」は「Not available」とされています。CLI で使うときは、お使いの版で試してください
URL も渡せます。ベストプラクティスは、よく使うドメインを /permissions で許可するよう書いています。ただし、Code タブでは /permissions のような引数なしのコマンドは「isn’t available in this environment」と返ります。権限の設定は、第5回の「Code タブでの権限の操作」と第6回の「allow・ask・denyルールの書き方」で扱います
「必要な情報は自分で取りに行って」と頼むこともできます

考えてみよう

最近 Claude Code に頼んだ作業のうち、差分を1文で説明できたのはどれですか。計画を省いてよかった作業と、計画が要った作業を分けてみてください。
計画を読むとき、あなたの環境で「本番に触れる手順」に当たるのは何ですか。（例：サーバーの設定ファイルの書き換え、サービスの再起動）
「NTPの設定を直して」のような頼み方を、4つのコツ（範囲・情報源・既存のやり方・「直った」の定義）で書き直すと、どうなりますか。

ヒント：「計画を省いてよい作業・要る作業」「計画は『実際に読む』」の節を見直してください。

まとめ

プランモードでは、Claude は読み取りだけで計画を出し、ファイルを変更しない。Code タブでは、メニューか Ctrl＋Shift＋M（Mac は Cmd＋Shift＋M）で切り替える。CLI の Shift＋Tab は Code タブでは使えない
選んだモードはフォルダーごとに記憶されるが、「プラン」だけはそのセッション限り
差分を1文で説明できるなら、計画は省く。範囲がはっきりしない・複数のファイル・慣れていない領域は計画が要る。要件があいまいなら、インタビューを頼む
計画は実際に読む。変更するファイル、本番に触れる手順、検証の手順を見て、足りなければ計画に足させる。計画を直すほうが、走らせてから片付けるより速い
プロンプトは、範囲・情報源・既存のやり方・「直った」の定義の4つを書く

演習の手順2で、プランモードの計画を読んで直す体験を試せます（第8回）。

次回は、走らせながら操縦することを扱います。途中で止める、戻す、向きを直す方法です。