Claude CodeのPlanモードの使い方｜変更する前に計画を確認する

Planへ切り替え、画面の状態を確かめる

CLIならclaude --permission-mode planで始めるか、会話中にShift+Tabでモードを切り替えます。VS Codeでは入力欄のモードからPlanを選びます。文字で「計画して」と頼むことと、実際の権限モードを切り替えることは分けて確認してください。

Planはソースを編集する前に調査して計画を示すためのモードです。調査のコマンドや計画の保存まで一切何も行わないという意味ではなく、設定によって許可の扱いも変わります。モードだけを頼りにせず、対象と作業範囲を依頼にも書きます。

• 出典：Claude CodeのPlanモードと承認操作（新しいタブ）
• 出典：VS Codeでの計画レビュー（新しいタブ）

症状と、直ったと判断する条件を伝える

たとえば、お問い合わせフォームで空欄のまま送信できてしまう問題を考えます。「フォームを良くして」では、見た目の変更まで入るかもしれません。「名前が空欄なら送信せず、入力欄の近くに案内を出す」と書くと目的が絞れます。

この段階では、本番への送信や公開は必要ありません。現在の処理を読む、変更案を出す、試す入力を決める、という順で頼みます。関係のないデザイン変更を含めないことも明示します。

良い計画は、あとで答え合わせできる

「入力を検証し、テストします」だけでは、何を変えて何を確かめるのか分かりません。対象ファイル、判定の場所、表示する案内、成功条件まで読んで確認します。分からない専門用語があれば、その場で具体例へ置き換えてもらってください。

次の表はこの架空のフォームで必要な確認です。実際のプロジェクトでは、すでにある送信処理やアクセシビリティなども踏まえて調整します。計画の行数が多いことより、読者や利用者が困っている問題へ答えているかが大切です。

今回のフォームなら、よい計画は「①送信処理で名前が空か調べる ②空なら送信を止めて名前欄の下へ案内を出す ③名前あり・空欄・スペースだけの3入力で試す」です。「全体を改善して品質を上げます」では、どのファイルを何のために直すかも、成功条件も分かりません。

納得できなければ、計画のまま直す

複数のファイルを作り直す案が出たら、「今回の問題を直すために本当に必要か」を尋ねます。共通部品へ影響する変更なら、ほかの画面への影響も説明してもらいます。

公式の承認画面では、計画を続けて見直す選択肢や、編集を個別に確認する選択肢があります。何を承認したかがあいまいなまま進めず、直してほしい点を計画へ反映してから選びます。

承認した後は、計画どおりかを見る

計画の承認でPlanを離れ、選んだ編集モードへ進みます。最初は個々の編集を確認する方法が取り組みやすいでしょう。変更が終わったら、予定したファイルだけか、3入力の確認を本当に行ったかを見ます。

テスト成功という返事には、実行したテストと結果があるかを確認します。実行できなかった項目は残してもらい、画面で試す必要があるものは別に確認します。計画を承認した事実と、実装が正しい事実を一つにしないでください。

実装後は名前欄に文字を入れた場合だけ成功し、空欄とスペースだけでは送信されないかを見ます。本番の問い合わせ先へテスト通知を大量送信せず、ローカルや検証環境で確認します。計画で約束した三つの入力がそろって通ったかを確認してから、見た目の微調整へ進むと手戻りを減らせます。

繰り返す仕事は、確認条件を残しておく

フォームを直すたびに同じ説明をするなら、守りたい動作や確認する入力を短いメモへ残します。すべての依頼に巨大なチェック表を付けるより、そのプロジェクトで壊れやすい箇所から始めると続けやすくなります。

こうしたAI開発の進め方を体系的に学びたい人には、開発向け書籍も候補です。下の本の目次を見て、環境構築だけでなく、依頼・修正・確認を学びたい自分の段階に合うかを確かめてください。