依頼に何を書き、どこで計画を先に出させるか

ここまでで、どこで動かし、どこまで任せ、どのモデルで動かすかが決まりました。残っているのは、何を頼むかです。

依頼文はコードではないので、書き間違えても構文エラーにはなりません。そのぶん、書き方の差がそのまま結果に出ます。ここでいう差は言い回しのうまさではなく、必要な情報が入っているかどうかです。

依頼に入れるのは3つ

文脈、制約、完了の条件です。

文脈は、どのファイル、どのフォルダ、どの資料、どのエラーが関係するかです。制約は、従うべき規約や慣習です。完了の条件は、何が真になれば終わりと言えるかです。

第4回で出した例を、この3つに当てはめてみます。

src/lib/date.ts の formatDate を、和暦にも対応させてください。    ← 文脈
既存の呼び出し側は変えず、第2引数で切り替える形にしてください。  ← 制約
テストは tests/unit/date.test.ts に追加し、
npm test が通ることを確認してください。                          ← 完了の条件

たった3行ですが、3つとも入っています。長く書く必要はありません。

抜けたときに一番困るのは完了の条件

この3つのうち、抜けやすいのが完了の条件です。そして抜けたときの損も、ここが一番大きい。

文脈が足りなければ、関係のないファイルを読む時間が増えます。制約が足りなければ、周りと違う書き方のコードが返ります。どちらも差分を見れば気づけます。

完了の条件がないと、終わったかどうかを判定するのが人の目だけになります。テストを走らせたのか、型検査まで通したのかが、頼んだ側からは見えません。「できました」と言われたものが実は壊れている、という一番面倒な形になるのがここです。

毎回同じ条件なら、依頼文ではなく CLAUDE.md に書きます。第9回で扱います。

ファイルは名指しする

文脈を渡すとき、探させるより、こちらから名指しするほうが速く確実です。

プロンプトの入力欄では @ に続けてファイル名を打つと、そのファイルを会話の文脈に加えられます。行の範囲まで指定する形もあり、macOS では Option+K、Windows と Linux では Alt+K で @file.ts#5-10 のような参照を挿入できます。

「認証まわりを直して」ではなく「@src/auth/session.ts の有効期限の扱いを直して」と書く。探す手間が減るだけではありません。こちらが場所を把握しているという情報自体が、制約として働きます。見当違いのファイルを大きく書き換えられる事故が減ります。

画面の不具合を直すときは、スクリーンショットを貼るのが速い場合があります。画像と PDF は、添付のボタンからも、プロンプトの入力欄への貼り付けでも渡せます。「ボタンの位置がおかしい」と文章で説明するより、崩れている画面を1枚渡すほうが確実です。

変更の前に計画だけ出させる

複数のファイルにまたがる変更では、いきなり書かせないほうが結局は安く済みます。

プランモードは、調べて提案するところまでを行い、変更はしない状態です。公式ドキュメントによれば、Claude はファイルを読み、シェルのコマンドを実行して調べ、計画を書きますが、ソースは編集しません。計画を承認するまで編集は止まります。

入り方は3つです。Shift+Tab を押す。その回の依頼の先頭に /plan を付ける。起動時から始めるなら次の形です。

claude --permission-mode plan

計画を承認せずに抜けるときは、もう一度 Shift+Tab を押します。

使いどころは3つあります。

1. 変更が複数のファイルにまたがるとき
2. 手順の順番が結果を左右するとき（データの移行など）
3. 自分自身がまだやり方を決めていないとき

3つ目を挙げたのは、これが実際には一番多いからです。やり方が決まっていないまま依頼を出すと、返ってきたものを評価する基準も決まっていません。計画を先に見れば、少なくとも「この道筋でよいか」という1つの判断に絞れます。

反対に、直す場所も直し方も決まっているなら、計画を挟むぶん往復が増えるだけです。

計画中にコマンドが走ることについて

プランモードでも、調べるためのコマンドは実行されます。ここの扱いがモードによって変わります。

公式ドキュメントによれば、auto モードが使える状態で useAutoModeDuringPlan が有効なとき（既定で有効です）、計画中のシェルコマンドは確認ではなく分類器が審査します。承認されたものは実行され、拒否されたものは止まります。そうでない場合は、読み取り専用の組み込みの一覧に入っていないコマンドは確認が出ます。

言い換えると、プランモードは「何も起きない」モードではありません。ソースは編集されませんが、調べるためのコマンドは動きます。第5回で見た分類器が、ここでも働いています。

計画を承認するときの3つの選択肢

計画ができると、どう進めるかを聞かれます。選択肢は3つです。

• はい、auto モードで進める。承認して auto モードに入ります。auto モードが使えない場合は「はい、編集を自動で受け入れる」という表示になります
• はい、編集は1つずつ承認する。承認して、編集を個別に確認します
• いいえ、計画を続ける。プランモードのまま、直してほしい点を伝えます

つまり、承認は同時にモードの選択でもあります。第5回のモードの話と、ここでつながります。読み切れる大きさの計画なら1つずつ、長い作業なら auto、という選び方になります。

計画そのものを直したいときは Ctrl+G です。既定のエディタで開いて、進む前に書き換えられます。

返ってきた計画の、どこを読むか

全部を同じ密度で読む必要はありません。見る場所は3つです。

1つ目は手順の数。10を超えていたら依頼が大きすぎるので、分けてください。

2つ目は最初の1手。「既存の実装を調べる」から始まっているか、いきなり「新しいファイルを作る」から始まっているか。後者のときは、似た仕組みがすでにあるのを見落としている可能性があります。

みっつ目は、戻せない操作が入っていないかです。データの削除、外部への送信、本番への反映。入っていたら、その手順の前で必ず止まるように依頼を足すか、第5回の deny 規則で塞いでください。

プランモードを既定にする

調べる時間のほうが長いプロジェクトでは、プランモードを既定にできます。

{
  "permissions": {
    "defaultMode": "plan"
  }
}

.claude/settings.json に置けば、そのプロジェクトのセッションはプランモードで始まります。第5回で触れたとおり、auto と bypassPermissions はここに書いても効きませんが、plan は効きます。

緩める方向の設定は効かず、厳しくする方向の設定は効く。プロジェクトの設定ファイルはリポジトリを開いた全員に適用されるので、この非対称は理にかなっています。

依頼文を使い捨てにしない

ここまで書いてきたことを毎回手で打つのは続きません。

同じ依頼を繰り返すなら、依頼そのものを保存できます。よく使う手順に名前をつけて /名前 で呼び出す仕組みがあり、第10回で扱います。リポジトリ全体に効かせたい規約なら CLAUDE.md に書きます。第9回です。

この講座の後半が「覚えさせる」に割かれているのは、依頼文の質を毎回の気合いで保つのが無理だからです。うまく書けた依頼は、その日のうちに置き場所を決めてください。

次の回

依頼の出し方が決まりました。第8回では、出したあとの話をします。気に入らない結果を巻き戻す方法と、長くなった会話を畳む方法です。

参照した公式情報

• Anthropic「Choose a permission mode」「Interactive mode」「Best practices for Claude Code」（code.claude.com/docs、2026年9月時点）