Claude Code に雑に「これやっといて」と投げると、だいたい一回で終わらない。むしろ、そこで作業の切り方を決めていないせいで、途中からコンテキストを食い、diff がふくらみ、最後に人間が手で戻す羽目になる。ここを外すと、便利なはずの道具が一番だるい道具になる。
この話で大事なのは、細かい命令文のテクニックではない。最初に「どこまでを Claude Code にやらせるか」「どの粒度で区切るか」を決めることだ。別名でいうなら、作業の切り方、進め方の設計、段取りである。ここが決まると、ファイル整理でも、ディスク削減でも、文書作成でも、頼み方が急に安定する。
筆者も最初はやった。ひと息で終わる気がして、長い依頼をそのまま投げた。結果は見事に散った。調査、修正、確認、微調整が全部ひとつの依頼に入って、Claude Code は便利に働くが、こちらは何を確認すればいいのか見失う。あとで見る diff はでかいし、どこから崩れたのか追いにくい。あれは気持ちが悪い。最初に切らないと、最後に手戻りで払うことになる。
やることは単純だ。最初に「一発で終わる依頼」を捨てる。代わりに、次の3つを分ける。
この3つを先に決めてから投げる。たったそれだけで、作業の質が変わる。
たとえば、散らかった資料フォルダを整理したいなら、最初から「全部いい感じに整理して」と頼まない。まずは棚卸しだけやらせる。重複、空フォルダ、明らかな古いファイル、移動候補を出させる。そこから、どれを消すか、どれをまとめるかを人間が決める。これが段取りだ。
Claude Code には、最初にこう頼むといい。
このフォルダの中身を確認して、整理方針を立ててください。
まずは削除や移動はしないで、次の3つだけ出してください。
1. 重複していそうなもの
2. ほぼ使っていない古いファイルの候補
3. まとめて整理しやすい単位
最後に、実行するならどの順番が安全かも書いてください。
この頼み方のいいところは、最初の一手で壊さないことだ。いきなり実行させないので、見当違いの整理をされにくい。ファイル整理でも文書作成でも、いきなり「完成品」を求めると、途中の判断が見えなくなる。まず見取り図を出させるほうが強い。
文書作成でも同じだ。いきなり「この契約説明を全部書いて」と投げると、長くて粗い草案が出やすい。そうではなく、段階を切る。
次の文書を3段階で進めたい。
1. まず論点の見出しだけ出す
2. 次に各見出しの要点を短く書く
3. 最後に全文を整える
今は1だけやってください。論点が抜けていたら先に指摘してください。
この切り方だと、途中で「そもそも話の順番が変だな」と気づける。全文を書かせてから直すより、はるかに軽い。手戻りが少ない。Claude Code は速いが、速さは雑さと背中合わせだ。だから最初に階段を作る。
コード作業なら、もっとはっきり切る。調査、修正、テスト、整形を全部一緒にしない。筆者はこれをひとまとめにして依頼し、思った以上に広く触られて困ったことがある。変更範囲が広いと、どの修正が効いたのか見えにくい。テストが通っても安心しきれない。だから、こう分ける。
まずは原因の特定だけをしてください。
コード変更はまだしないでください。
次に、最小限の修正案を1つだけ出してください。
そのあとで、必要なテストコマンドを提案してください。
ここで重要なのは、「最小限」と「1つだけ」をわざわざ書くことだ。Claude Code は放っておくと、親切に複数案を出したり、広めに直したりする。悪くないが、作業がぼける。切り方を先に指定すると、道が細くなるぶん、確認もしやすい。
段取りを決めるときの実用的なコツは、依頼の中に「止める条件」を入れることだ。これがないと、延々と先まで進めがちになる。
この作業は、差分を出すところまでで止めてください。
その先のコミットや反映はしないでください。
不明点があれば勝手に埋めず、質問してください。
「止める条件」があると、こちらが見たいところで止まる。逆に、止めどころがない依頼は、終わったように見えて終わっていない。あとから「そこまでやるつもりじゃなかった」となる。かなりよくある。
非エンジニアの用途でも、この考え方はそのまま使える。たとえば、請求書や契約書、議事録の整理であっても、最初から完成を狙うより、棚卸しを先にやるほうが強い。ディスク削減でも同じだ。全部消す前に、サイズの大きいもの、重複候補、再取得できるものを分ける。実際、最初の分類が雑だと、削除していいファイルまで曖昧になる。そこで焦って一発依頼をすると、後で人間が確認する作業が増えるだけだ。
ここで気をつけたいのは、「細かく切る」こと自体が目的ではない点だ。切りすぎると逆に面倒になる。たとえば、たった一行の修正なのに、調査、提案、実装、確認の4回に分けるのはやりすぎだ。そういうときは、段取りを短くして一気に済ませればいい。要するに、切り方は「失敗したときに痛いところ」だけを分割するのがちょうどいい。
判断の目安はシンプルだ。やり直しが高い作業、戻すのが面倒な作業、対象が広い作業は分ける。逆に、確認しやすく、失敗しても被害が小さいものはまとめていい。ここを雑にすると、丁寧なつもりでかえって遅くなる。
最後に、実際に使える頼み方の型を置いておく。これはかなり使い回せる。
この作業は一度に完了させず、まず切り方を決めてください。
目的は [目的] です。
対象は [フォルダ名 / ファイル名 / 文書名] です。
まずやることは [棚卸し / 調査 / 見出し整理 / 差分確認] だけです。
まだ変更はしないでください。
出力は次の順番でお願いします。
1. 現状の整理
2. 作業をどう分けるか
3. いちばん安全な進め方
4. ここで止めるべき点
この型のいいところは、Claude Code に「考える順番」を先に渡せることだ。順番が決まると、出力のブレが減る。こちらも確認しやすい。結局、便利な使い方は派手な命令ではなく、切り方がうまい依頼に落ち着く。最初に段取りを決める。これだけで、作業はかなり片づく。