Claude Code に雑に「直して」とだけ頼むより、「まず調べて、次に直して」と分けて指示したほうが、手戻りが減ります。
とくに、既存コードの修正、フォルダ整理、重複ファイルの洗い出し、文書の整形のように、先に状況把握が必要な作業で効きます。
理由は単純で、いきなり修正に入ると、Claude Code が「何を根拠に直すか」を自分で補ってしまうからです。
先に調べさせると、対象のファイル、命名、依存関係、似た設定、既存の方針を確認したうえで、その情報に沿って直せます。人間がレビューするときも、この順番のほうが判断しやすいはずです。
たとえば、README を整えたいときに、最初から「読みやすくして」とだけ頼むと、書き換えの方向がぶれやすいです。
先に「このリポジトリの README、見出し構成と重複表現を確認して」と頼み、その結果を見てから「では、その指摘に沿って最小限で直して」と続けると、修正の筋が通ります。
同じことは、開発者以外の用途でも起きます。
たとえば、外付けディスクの中身を減らしたいとき、いきなり「不要なものを消して」では危ない。まず「このフォルダ群の中で、重複していそうなもの、キャッシュっぽいもの、古い書き出しを洗い出して」と頼み、候補を見てから削除判断に進むほうが安全です。
弁護士や編集者のように、案件ごとに資料が分かれる仕事でも、「まず整理して把握、次に整える」はそのまま使えます。
実際の頼み方は、次のように二段に分けると扱いやすいです。
まず調べてください。
対象はこのフォルダです。内容を確認して、修正が必要そうな箇所を列挙してください。
まだ変更はしないでください。
調査結果を見たあとで、こう続けます。
では、次の方針で直してください。
・変更は最小限にする
・意味が変わる場合は事前に指摘する
・関連するファイルがあれば一緒に確認する
・最後に、何を変えたか短く報告する
Claude Code がコードベースを扱うときは、まず確認してから変更する流れがとても相性よく機能します。
確認段階で、関連ファイルまで見ておくよう頼むと精度が上がりやすいです。たとえば「この機能に関係する設定ファイルも探して」「同名の関数や似た文書があれば並べて」と書いておくと、局所的な見落としを減らせます。
このとき大事なのは、「調べる」と「直す」を、ただ言葉で分けるだけで終わらせないことです。
Claude Code は、先の指示を受けて実際に読み取りや検査を進めるので、調査結果を見たあとに、次の修正指示を出す。ここまでを一連の作業として扱うと安定します。途中で結果を確認せずに「そのまま全部直して」と畳みかけると、せっかくの下調べが活きません。
やってはいけないのは、最初の段階で曖昧すぎる命令を出すことです。
「まず調べて」の対象が広すぎると、Claude Code は広い範囲を読み、時間も意図もぼやけます。対象はできるだけ絞ります。
「このディレクトリだけ」「この.mdファイル群だけ」「この機能に関係する箇所だけ」と言い切るほうが、調査の質が上がります。
逆に、最初から修正の条件を詰め込みすぎるのもよくありません。
「まず調べて、次に直して、しかも見た目は変えず、文体は丁寧に、さらに重複は全部消して、関連箇所も全部反映して……」と一度に盛ると、どこを優先すべきかが曖昧になります。段階に分けると、調査では事実、修正では方針、という役割分担ができます。
もう一つ、見落とされがちなのは「調べた結果をそのまま修正条件に使う」ことです。
ここを飛ばして、頭の中で読み替えるとズレます。Claude Code にも、人間にも、結果を短く要約してから次の指示に渡すと安定します。たとえば「古いテンプレートが3つ、似た文書が2つある。名前が近いので、まず重複候補から整理して」と明示すると、修正対象がぶれません。
少し進んだ使い方としては、「調べる」段階で観点を固定しておく方法があります。
開発なら「エラーの原因候補」「設定の衝突」「参照されている箇所」、文書なら「重複表現」「見出しの飛び」「用語の不統一」、ファイル整理なら「重複」「古い版」「中身が空に近いもの」のように、見る軸を先に渡します。軸があるだけで、調査結果の粒度がそろいます。
Claude Code を使うときは、こうした段階分けがそのまま安全策になります。
先に調べることで、手を入れる理由が見える。次に直すことで、変更が必要最小限に収まる。
派手なテクニックではありませんが、日々の作業ではこれがいちばん効きます。公式の仕様や細かな挙動は docs.claude.com で確認しつつ、基本の頼み方としては、まず調べて、次に直す。この順番を習慣にするだけで十分に違いが出ます。