雑な依頼文は、途中で止まった瞬間に一気に崩れる。これ、かなり多い失敗だ。Claude Code は作業をかなり肩代わりしてくれるが、指示が「なんとなく」でできていると、中断したあとに再開しづらい。つまり、再開しやすい依頼、あるいは中断耐性のある指示にしておかないと、後で自分が困る。
この手の依頼文は、長文にしろという話ではない。むしろ逆だ。途中で切れても意味が保てるように、目的・作業単位・完了条件を先に固定しておく。そうすると、Claude Code が一度止まっても、同じ依頼を読み直してそのまま続けやすい。ファイル整理でも、文書作成でも、コード修正でも効くやり方だ。
実際、筆者も最初は「この辺を整理して、いい感じにしておいて」で投げて、途中再開で見事に手戻りした。何を優先すべきか、どこまで触ってよいかが曖昧だと、再開したときに別の方向へ進みやすい。コンテキストも無駄に食う。だから依頼文は、最初から“分割しやすい形”にしておくほうが得だ。
まず押さえるのは、依頼文の中に「止まっても復元できる情報」を入れることだ。具体的には、次の4つが要る。
これを入れるだけで、かなり壊れにくくなる。
たとえば、こんな書き方だ。
このディレクトリ内のMarkdown文書を整理したい。
目的は、重複した内容を減らして読みやすくすること。
やること:
1. 同じ内容が繰り返されているファイルを探す
2. 重複をまとめる候補を挙げる
3. 内容を壊さずに、必要ならファイル名の整理案も出す
制約:
- 文章の意味を変えない
- 既存の見出し構成は勝手に大きく崩さない
- 削除は提案まで。実行前に止まる
途中で止まったら、ここまでに見つけた候補と理由を箇条書きで残してから止める
この書き方のいいところは、途中で止まっても「候補」と「理由」が残る点だ。再開時にそのメモを起点にできる。逆に、ただ「整理して」とだけ書くと、止まったときに何を基準に進めていたのかが見えなくなる。
コード修正でも同じだ。中断に強い依頼は、いきなり作業を始めさせず、段階を切る。最初に現状把握、次に方針、最後に実行、という順にするのが安定する。
次の順で進めてください。
1. 現状を確認して、変更が必要そうな箇所を列挙する
2. 変更方針を短く示す
3. 実装する前に私に確認を取る
4. 確認後、最小限の差分で変更する
前提:
- 既存の動作を壊さない
- 変更理由が説明できるものだけ触る
- 関係ないファイルは触らない
途中で止まる場合は、最後に「次にやること」を1行で残す
こうしておくと、Claude Code が長い作業の途中で止まっても、再開時に迷いにくい。依頼文そのものが作業ログの骨格になるからだ。
ここでやりがちなのが、条件を盛り込みすぎて、逆に何が大事か分からなくなることだ。中断耐性を上げたいのに、禁止事項だけ増やしてしまうパターンである。これはだるい。指示が細かすぎると、Claude Code も「どれを優先すべきか」を判断しづらくなる。だから、制約は絞る。特に大事なのは「触ってはいけない範囲」と「止まるタイミング」だ。ここだけは明確にしておけばいい。
非エンジニアの用途でも考え方は同じだ。たとえば、案件ごとの書類整理や、メール本文の下書き、重複ファイルの洗い出しを頼むときも、途中で止まって困るのは一緒だ。依頼文には、目的のほかに「採用したい基準」を書く。ファイル整理なら「日付順にするのか、案件名順にするのか」、文書作成なら「社外向けの丁寧さを優先するのか、短さを優先するのか」を先に決める。ここが曖昧だと、中断後に再開したとき、別の基準で進められてしまう。
たとえば文書作成なら、こんな依頼が使いやすい。
次のメモを、社外向けの案内文に整えてください。
条件:
- 300字前後
- 断定しすぎず、でも曖昧すぎない
- 箇条書きは最大3項目
- 事実関係は変えない
- 不明点があれば、書き足す前に質問する
途中で止まったら、未確定の点を先に列挙してください
この形なら、中断しても「未確定の点」が残る。そこから再開しやすい。何も残らない依頼文は、途中で紙を失くしたのと同じだ。
もうひとつ大事なのは、依頼文の中に「再開の手がかり」を置くことだ。たとえば、途中までの成果物の置き場所、判断基準、優先順位だ。Claude Code への依頼で、毎回すべてを一から説明し直す必要はない。最初の依頼文に、再開しやすいようなマーカーを入れておけばいい。
作業メモ:
- 優先順位は「正確さ > 変更の少なさ > 見た目」
- 迷ったら変更しない
- 途中結果は /tmp/notes.txt に要点だけ残す
- 進め方に迷ったら、その場で止まって確認する
こういうメモがあるだけで、会話が長くなっても破綻しにくい。特に長い整理作業では、どこまで終わったかを言葉にして残すのが効く。筆者は昔、ここをサボって一気に片づけさせようとして、途中で「どこまで済んだか」が分からなくなった。結局、戻ってやり直しだ。最初から小さく区切っておけば、そんな無駄は減る。
少し進んだ使い方をするなら、依頼文を「本体」と「継続ルール」に分けるといい。本体はその回の目的、継続ルールは中断後の再開方法だ。毎回同じ土台を使えるので、作業が長くなってもぶれにくい。
【本体】
このフォルダの資料を見て、内容が重複しているものを整理したい。
【継続ルール】
- まず現状把握をする
- 変更案は一度止めて確認する
- 作業の節目ごとに、次にやることを1行で残す
- 中断した場合は、最後に触ったファイル名と理由を出す
この書き方は地味だが強い。依頼のたびに同じテンプレを使えるし、途中再開でも迷子になりにくい。要するに、依頼文の中に“戻り先”を作るわけだ。
最後に、やってはいけない癖をひとつだけはっきり言う。目的を広く書いて、作業は狭く書かないことだ。「このフォルダをいい感じにして」は広すぎる。中断したときに、続きを始める足場がない。逆に、「重複ファイルの候補を見つける」「削除はしない」「候補の理由を残す」まで書けば、止まっても崩れない。再開しやすい依頼は、最初の1行で勝負が決まることが多い。
Claude Code を使うときは、作業をうまく任せることより、止まっても続けられる形にしておくことのほうが大事だ。中断前提で組んだ依頼文は、後から見返しても読める。そこが実務ではかなり効く。仕様の細部が気になる場合は、公式ドキュメントで確認しながら、自分の作業に合う粒度へ寄せていけばいい。