Claude Codeのプランモードで計画を先に出させる：実装前に見るべき7項目

プランモードで何が起きるか

公式ドキュメントでは、プランモードは変更を提案するために調査し、ソースコードは編集しないモードと説明されています。ただし、シェルコマンドの実行可否はセッション設定で変わります。自動モードが利用可能で計画中の使用が有効なら、コマンドは分類器の審査を受け、承認されたものが実行されます。それ以外では、読み取り専用の範囲を超えるコマンドに承認を求められる場合があります。通常は計画の承認まで編集がブロックされますが、対話型ターミナルでbypass permissionsが利用可能な場合は例外です。詳細はPermission modesを参照してください。

• 入り方：Shift+Tabで切り替える、1回のプロンプトの先頭に/planを付ける、またはclaude --permission-mode planで起動します。状態表示の見え方はCommon workflowsに記載があります。
• 承認時の選択肢：「Yes, and use auto mode」「Yes, manually approve edits」「No, keep planning」です。auto modeが使えないセッションでは1つ目が「Yes, auto-accept edits」になるなど、表示は環境で変わります。
• 計画の直接編集：Ctrl+Gで提案された計画を既定のテキストエディタで開き、編集してから進められます。

注意したいのは、「編集しない」は「何も実行しない」ではない点です。計画中のシェルコマンドが審査されるか、個別の承認を求められるかは、セッションの種類と設定で変わります。計画段階でも、実行されうるコマンドと権限設定を事前に確認してください。

計画をレビューしやすい形で出させる依頼文

自由形式で計画を出させると、項目の抜けを探すところから始まります。出力の形を先に指定します。次は説明用の例です（架空の注文管理アプリで、一覧APIにページネーションを足す想定）。

/plan 注文履歴一覧API（GET /orders）にページネーションを追加したい。
今は実装しないでください。次の7項目で計画だけ出してください。

1. 目的と完了条件（何ができれば完了か。1〜3行）
2. 変更するファイルと内容（新規・修正・削除の別、ファイルごとに1〜2行）
3. 触らないもの（今回の範囲外にするファイル・機能）
4. 根拠（実際に読んだファイルと分かったこと。読んでいない部分は「未確認」と書く）
5. 手順（1ステップごとに動作確認できる単位で）
6. 検証方法（実行するコマンドと、期待する結果）
7. リスク、元に戻す方法、私に確認したい点

背景として、公式のBest practicesは、コードを読むだけでは分からない情報をClaudeに伝えること、完了を確認するチェックを与えることを勧めています。上の依頼文では、4と6がそれに当たります。

7項目のチェックリスト

以下は編集上の提案で、公式の仕様ではありません。使うときは、赤信号が1つでも出たら承認せず、右端の観点で差し戻します。

• 1、項目：目的と完了条件、OKの目安：自分が頼んだことと同じ言葉で、終わりの条件が書かれている、赤信号：目的が言い換えられて範囲が広がっている。完了条件がない
• 2、項目：変更するファイルと内容、OKの目安：ファイル名ごとに何をどう変えるかが分かる、赤信号：「関連ファイルを適宜修正」のような曖昧な表現。想定外のファイルが入っている
• 3、項目：触らないもの、OKの目安：範囲外が明示されている、赤信号：空欄。ついでのリファクタリングや依存更新が混ざっている
• 4、項目：根拠、OKの目安：読んだファイルと、そこから分かった事実が書かれ、未確認が区別されている、赤信号：読んでいないはずの挙動を断定している。既存の書き方に触れていない
• 5、項目：手順の分け方、OKの目安：各ステップの終わりで動作確認でき、途中で止めても壊れない、赤信号：全部を1ステップで変更する。順序の理由がない
• 6、項目：検証方法、OKの目安：実行するコマンドと期待結果がある、赤信号：「テストする」だけ。既存テストの実行しか書かれていない
• 7、項目：リスク・戻し方・未決事項、OKの目安：影響範囲、戻し方、人に聞きたい点が具体的に書かれている、赤信号：「特になし」。仕様の分かれ目なのに質問がない

見る順番

1→3→2→4→6の順がおすすめです。まず「何を、どこまで」が合っているかを見て、次に根拠と検証を見ます。5と7は、前半が合ってから確認すれば十分です。

説明用の例：赤信号が出た計画の一部

次の記述が計画に含まれていたとします（架空）。

2. 変更するファイル
   - src/routes/orders.ts：ページネーション対応
   - src/db/*：必要に応じて調整
   - package.json：依存の更新
6. 検証：動作を確認する

src/db/*の「必要に応じて」は項目2、package.jsonの更新は項目3、「動作を確認する」は項目6の赤信号です。3か所とも、次の差し戻し文で修正を求められます。

差し戻し文の例

承認画面で「No, keep planning」を選び、続けて次のような文を送ります。いずれも説明用の例なので、括弧内は自分のプロジェクトの内容に置き換えてください。

1. 目的と完了条件

完了条件が不足しています。「limitとcursorを指定でき、省略時は従来と同じ応答になる」を完了条件に含めて、計画を書き直してください。

2. 変更するファイル

「必要に応じて」は使わず、変更するファイルを列挙してください。src/db配下は、実際に変更するファイル名と変更理由を1行ずつ書いてください。

3. 触らないもの

今回の範囲外に、依存パッケージの更新と、orders以外のルートの変更を明記してください。package.jsonの変更は計画から外してください。

4. 根拠

計画の各主張について、読んだファイルを挙げてください。読んでいない部分は「未確認」とし、必要なら先に読んでから計画を更新してください。

5. 手順

手順を、各ステップの終わりでテストが通る単位に分けてください。ステップ1は、挙動を変えずに型だけ追加する段階にしてください。

6. 検証方法

実行するコマンドと期待結果を書いてください。ページネーションの境界（0件、limitちょうど、limit超過）に対する新しいテストも手順に含めてください。

7. リスクと未決事項

既存クライアントが影響を受ける可能性と、元に戻す方法を書いてください。仕様が分かれる点（件数上限の初期値など）は、決め打ちせず私への質問として挙げてください。

複数の赤信号があるときは、1回で全部送って構いません。

承認画面でどれを選ぶか

7項目を確認したあと、どの選択肢に進むかの目安です（これも編集上の提案です）。

• 1〜3に問題がある、または根拠が薄い、選ぶもの：No, keep planning＋上の差し戻し文
• 方向は合っていて、直したいのが1〜2行の文言や項目だけ、選ぶもの：Ctrl+Gで計画を直接編集してから進める
• 7項目がそろっている。ただし変更が広い、または重要なコード、選ぶもの：Yes, manually approve edits（編集を1件ずつ確認）
• 7項目がそろっていて、範囲が小さく、検証コマンドも明確、選ぶもの：auto modeでの承認も候補。ただし組織の設定などで選べない場合がある

承認後も、差分を読むときは計画の2・3・6を手元に置きます。計画にないファイルが変わっていたら、その時点で止めて理由を尋ねてください。

誤字修正や1行の変更のように、差分を一文で言える作業なら、計画を先に出させる必要はありません。計画は、複数ファイルにまたがる、仕様の判断が要る、影響範囲が分からない、といった場面で効きます。機密情報を含むコードや設定を扱う場合は、計画に貼られる内容も含めて、扱ってよい情報かどうかを自分の環境のルールで確認してください。