「やったつもり」で終わる調査ほど、あとで面倒なものはない。ログは残した、変更もした。なのに、どこが期待と違ったのか分からない。そういうときに効くのが、調査ログと変更結果を突き合わせるやり方だ。要するに、ログと差分を突き合わせる、期待とのズレを読む、という作業である。
Claude Code を使うと、この照合をかなり人力より楽にできる。しかも、コード修正だけの話ではない。ファイル整理でも、不要ファイル削除でも、文書の置き換えでも同じだ。先に「何を確認したか」を残し、あとで「実際に何が変わったか」を見比べる。これだけで、変な手戻りがかなり減る。
筆者は昔、似たようなことを雑にやって失敗した。ログは長いのに、肝心の変更結果を見ていなかったのだ。結果、Claude Code がちゃんと動いていても、別の場所のファイルを触っていたことに気づくのが遅れた。調査が浅いと、出力の量だけで安心してしまう。そこが罠だ。
この手の作業で大事なのは、まず「期待」を先に書くことだ。調査のメモと、実際の変更結果を比べるとき、期待が曖昧だとズレも見えない。逆に、期待がはっきりしていれば、Claude Code にも「どこが外れたか」を見つけさせやすい。
たとえば、コード修正ならこういう頼み方になる。
次の3点を確認して、調査ログと変更結果を照合してほしい。
1. 変更前に確認した内容
2. 実際に行った変更
3. 変更後にまだ残っているズレ
特に、期待していた対象と実際に触った対象が違っていないかを見てほしい。
もしズレている場所があれば、ファイル名、行番号、差分の観点で列挙して。
もう少し実務っぽくするなら、最初から観点を決め打ちしておくといい。
以下の観点で、調査ログと変更結果の差分を確認して。
- 対象ファイルは合っているか
- 変更した条件は合っているか
- 削除・追加・置換の方向が合っているか
- 変更が漏れている箇所はないか
- 想定外に触ってしまった箇所はないか
出力は、「期待」「実際」「ずれ」の3列で整理して。
Claude Code は、曖昧なお願いでも動くことは動く。だが、曖昧なままだと確認対象がぼける。ここでほしいのは、ただの要約ではない。どの場所が、何の前提から外れたかを掘ることだ。だから、ログだけを投げるのでは足りない。変更後の差分や結果も一緒に見せる必要がある。
実際には、こんな流れが使いやすい。
まず、調査の段階でメモを残す。対象、仮説、確認した点を書く。次に、変更後の差分を見せる。最後に、Claude Code に「ズレのある場所だけ拾え」と指示する。全体を説明させると、また長くなるだけだ。欲しいのは、穴の位置だ。
調査メモ:
- 対象: 受領済みPDFを格納するフォルダ
- 仮説: 重複ファイルが増えている
- 確認: 拡張子、更新日時、ファイル名の類似性を見た
変更結果:
- 重複候補を移動した
- ただし一部は残した
この2つを照合して、残ったズレを特定して。
「移動しなかった理由」が妥当かどうかも見て。
ここでよくある失敗が、調査ログと変更結果を同じ粒度で書いていないことだ。調査では「この辺が怪しい」で終わっているのに、変更では「具体的にこのファイルを消した」となっている。粒度が違うと、照合が雑になる。Claude Code に任せても、入力が粗ければ出力も粗い。これはかなり素直な道具だ。
もうひとつ、ずれを見つけるときに効くのは、差分を「見た目」ではなく「意味」で読むことだ。たとえばファイル整理なら、単に移動できたかでは足りない。移動先が本当に適切か、重複の判断基準がぶれていないか、不要ファイルを消しすぎていないかを見る必要がある。文書作成でも同じで、表現を直しただけではなく、意図が残っているかを確認する。ここを外すと、見た目は整っているのに中身がずれている、という面倒な状態になる。
変更結果を見て、次の観点でズレを指摘して。
- 対象の取り違え
- 条件の取り違え
- 優先順位の取り違え
- 期待した結果と逆の変更
- 手を入れるべきだったが残っている箇所
単なる差分の説明ではなく、「どの前提が外れたか」まで書いて。
筆者は一度、変更結果だけを見て「直った」と思い込んだことがある。ところが、調査ログを後から見直したら、そもそも見ていたフォルダが違っていた。つまり、修正は正しくても、問題の場所がずれていたわけだ。こういう事故は、ログを残していても起きる。残すだけではだめで、あとで照合する前提で書かないと意味が薄い。
照合するときのコツは、ログを時系列で並べることだ。調査した順番、判断した順番、変更した順番を混ぜない。順番がぐちゃぐちゃだと、どこで判断が曲がったか追えない。Claude Code に渡すなら、最初から順番を整えておくといい。
時系列で整理したログを以下に貼る。
1. 最初に確認した事実
2. その時点で立てた仮説
3. 仮説を元に実施した変更
4. 変更後に確認した結果
この流れの中で、どの段階で期待とのズレが入ったかを特定して。
非エンジニアの作業でも、このやり方はかなり効く。たとえば、案件ごとにフォルダを整理して書面を整える場面だと、調査ログは「どの書類がどこにあるか」「重複がどれか」「不要な下書きがどれか」というメモになる。変更結果は実際の移動や削除だ。これを照合すると、うっかり別案件の書類を触った、古い版を残した、といったズレが見つかる。ディスク削減でも同じで、キャッシュを消したつもりが本当に消すべき巨大ファイルを見落としていた、ということがある。照合は地味だが、こういう失敗をかなり減らす。
注意点もある。Claude Code に「違いを探して」とだけ言うと、差分の表面をなぞって終わることがある。そうではなく、何を期待していたかを必ず添える。期待がない差分確認は、ただの見比べで終わる。さらに、ログに根拠がない推測を書きすぎると、あとでズレの原因がぼやける。事実と推測は分けて書くべきだ。これはかなり大事だ。
事実と推測を分けて整理して。
- 事実: 実際に確認できた内容
- 推測: そこから考えた仮説
- 変更: 仮説を元に行った作業
- 結果: 変更後に実際に起きたこと
この4つを照合して、推測が外れた箇所を指摘して。
最後に覚えておくといいのは、ずれを見つける目的は「ミス探し」ではないことだ。次に同じ手戻りを起こさないために、期待の書き方を直すことにある。Claude Code を使うと、変更の痕跡は見えやすい。だからこそ、調査ログとの照合で前提のズレを見つけると、次回の指示が一段よくなる。
雑にやると、毎回同じ穴にはまる。丁寧に照合すると、穴の形が見える。そこまで行けば、ただ修正するだけの作業から、再発しにくい作業へ変わる。