雑に「これ直して」で投げると、Claude Code はだいたい手広く動きすぎる。調べるべきことと、直すべきことが頭の中で混ざるからだ。
先に調べさせ、あとで直させる。この順番に分けるだけで、無駄な修正、見当違いの変更、差分の膨張がかなり減る。ファイル整理でも文書作成でも同じで、いきなり“完成形”を頼むより、まず現状を見せたほうが話が早い。
実際、筆者も最初は「このフォルダを整理して」「この文章を直して」と丸投げして、あとで手戻りした。Claude Code は賢いが、前提が曖昧だと遠慮なく広く動く。削除していいものまで候補に入れるし、文書なら表現だけでなく構成までいじってくる。悪気はない。だからこそ、段階を切る。
やり方は単純だ。最初の依頼では、変更禁止で調査だけさせる。次の依頼で、調査結果を前提に修正を指示する。
たとえばコードなら、こういう頼み方にする。
まず調べてください。変更はしないで、次を出してください。
- 何が原因候補か
- どのファイルを触る可能性があるか
- 修正方針を2〜3案
- それぞれのリスク
まだ編集しないで、調査結果だけ返してください。
この一段目で大事なのは、「直して」まで言わないことだ。ここで修正に踏み込ませると、調査と実装が混ざって、何を根拠に変えたのか追いにくくなる。調べるフェーズでは、出力の役目を限定する。原因、影響範囲、候補案。ここまでで止める。
次に、調査結果を読んでからこう続ける。
ありがとう。案2で進めてください。
- 変更対象は最小限にする
- 既存の挙動は変えすぎない
- 変更後に確認すべき点も一緒に書く
- 可能なら差分を小さく保つ
この形にすると、Claude Code は「何を見て、何を直すか」がはっきりする。結果として、余計な巻き込みが減る。バグ修正でありがちな「ついでに周辺も整えました」が少なくなるのが地味に大きい。
非エンジニアの使い方でも同じだ。たとえば大量の書類を整理したいなら、いきなり削除を頼まず、まず棚卸しをさせる。
まず調べてください。削除や移動はしないで、次を一覧にしてください。
- 重複していそうなファイル
- 古そうだが残すべきか迷うファイル
- 形式がばらばらで整理しやすいグループ
- 手を付けると危ないもの
まだ何も動かさないでください。
これだけで、いきなり消されて困る事故を避けやすい。人間でも、いきなり片づけろと言われると捨てていいものの判断を雑にしがちだ。Claude Code も同じで、先に見取り図を作らせるほうが強い。
段階で頼むと精度が上がる理由は、もう少しはっきりしている。ひとつは、コンテキストを節約しやすいことだ。最初から修正まで一気にやらせると、調査対象、判断材料、実装手順、確認まで全部を同じ流れで抱える。すると、説明が長くなり、差分も大きくなりやすい。段階を切れば、調査フェーズで必要な情報だけ集め、実装フェーズではその情報だけに集中できる。
もうひとつは、指示の曖昧さを早めに潰せることだ。よくある失敗は、本人が「軽い修正」のつもりでも、Claude Code から見ると「構造ごと直したほうがよさそう」に見えてしまうことだ。調査だけ先にやらせると、候補案の段階で「そこまでやる必要があるのか」を確認できる。ここで止めれば、勝手に広げられる前に軌道修正できる。
筆者はここで一度痛い目を見た。古い設定ファイルを整理させたとき、最初から「整理して」とだけ頼んだら、見た目はきれいになったのに、後で必要だった補助ファイルまで候補に入っていた。削除前確認があったから事故にはならなかったが、最初に「何を残すべきかを調べて」と分けていれば、そもそもその候補が出にくかったはずだ。雑な丸投げは、後から人間が読み直すコストを増やすだけである。
注意点もある。段階を分けるときに、最初の「調べて」が長くなりすぎると逆効果だ。目的は会議を増やすことではない。調査は短く、判断材料を絞る。必要以上に広く見させないのがコツだ。
それから、「調べて」と言ったのに、実は一部だけ先に直してほしい、という頼み方もよくない。そこは分けるか、最初から許可範囲を明示したほうがいい。
まず調べてください。変更はしないでください。
ただし、明らかな誤字だけはその場で候補として挙げてください。
本格的な修正は次の指示で行います。
このように境界をはっきりさせると、Claude Code が勝手に深追いしにくい。曖昧な「いい感じで」は、だいたい差分を育てる合図になる。
応用するなら、三段階にしてもいい。
まず調べる。次に、直し方の案を出させる。最後に、承認した案だけを実装させる。この流れは、コードだけでなく文章の推敲にも向く。たとえば企画書なら、先に「論点の抜け」を洗い出し、次に「直し方」を並べ、最後に本文を直す。いきなり全文を磨かせるより、ずっと戻りが少ない。
Claude Code を使うときは、能力より順番を疑ったほうがいい。
まず調べる。次に直す。たったそれだけで、出力の精度はかなり変わる。雑に一発で当てにいくより、はるかに実務向きだ。