貼ったログをそのまま信じて進むと、あとで「そこ、直ってないじゃん」で止まる。いちばんだるいのは、直したつもりの差分と、実際に変わったファイルがズレていることだ。
ここで使うのがログ照合、つまり貼ったログと実際の変更を突き合わせるやり方である。Claude Code に作業を振ったあと、返ってきた説明と、リポジトリ上の実ファイルや git diff を並べて見る。これをやるだけで、見落とし、やり残し、説明だけ立派な変更をかなり潰せる。
筆者はこれをサボって、README の説明は更新されたのに設定ファイルの例が古いまま、という半端な状態を何度も踏んだ。見た目はそれっぽいのに、実行すると壊れる。ああいう事故は、照合を省いたときに起きる。
まず、Claude Code には「作業後に変更内容を要約して」と頼む。大事なのは、要約だけで終わらせず、実際の差分と照合する前提を最初から入れることだ。たとえばこんな頼み方でいい。
この作業で変更したファイルを一覧にして、各ファイルで何を変えたかを短く要約してください。
そのうえで、実際の差分と照合して、説明と食い違う点や見落としがあれば指摘してください。
最後に、まだ確認が必要な点があれば列挙してください。
Claude Code は、こういう「一覧化」と「突き合わせ」を同時に頼むと役に立つ。単なる感想文ではなく、確認用の材料を出させるわけだ。ここで雑に「変更内容を説明して」とだけ振ると、細部が抜ける。そこが危ない。
実務では、照合の基準を先に決めておくと強い。たとえば、文書作成なら「本文」「見出し」「参照先リンク」、ファイル整理なら「移動先」「削除対象」「重複の有無」、開発なら「コード」「設定」「テスト」のように分ける。Claude Code にも、その粒度で見せるとズレを見つけやすい。
次の観点で、今回の変更が漏れなく入っているか確認してください。
- 文書の本文
- 見出しと目次
- 参照リンク
- ファイル名や配置
- 関連する設定や例示
各観点ごとに、変更済みか、未確認か、問題がありそうかを分けて書いてください。
このやり方のいいところは、変更の「説明」と「現物」を分けられる点だ。Claude Code の返答だけ読むと、なんとなく全部終わった気になる。だが、実際には一部のファイルだけ直して、周辺の整合性が残っていることがある。特に文書修正や整理作業では、本文だけ更新してリンクやファイル名を放置しがちだ。そこが後で刺さる。
照合するときは、Claude Code の返答を鵜呑みにせず、git diff か git status を必ず見る。これは地味だが効く。説明が合っていても、差分が想定外なら止まるべきだ。逆に、差分はあるのに説明に出てこない変更もある。そういう見落としを拾うための作業である。
git status
git diff
もし変更が多いなら、いきなり全体を読むより、ファイルごとに見たほうがいい。Claude Code にも分割で確認させる。
変更した各ファイルについて、次の順で確認してください。
1. このファイルで実際に変わった箇所
2. その変更の目的
3. 影響を受ける周辺箇所
4. まだ残っていそうな見落とし
特に、見出し・リンク・参照・ファイル名のずれを重点的に見てください。
ここで大事なのは、「何を直したか」ではなく「何がまだ残っているか」まで聞くことだ。人は完了報告を聞くと満足しやすい。だが、照合の本体は未確認の洗い出しにある。そこを抜くと意味がない。
筆者がやって痛かったのは、Claude Code に文書の整形を頼んだときに、見出しの修正は入ったのに本文中の古い表現が一つだけ残ったケースだ。見出しを直したので安心していたら、本文が古いままで読者を混乱させた。こういうのは、変更の意図だけ見て終えるとまず見逃す。だから、実ファイル側で「古い語句が残っていないか」を機械的に見る癖が要る。
本文中に、古い名称や旧仕様の記述が残っていないか確認してください。
残っている場合は、どの行をどう直すべきかを具体的に示してください。
開発寄りの作業なら、差分と一緒にテスト結果も照合する。コードを直したのにテストが増えていない、設定を触ったのに関連ドキュメントが古い、というのはよくある。Claude Code には、変更の説明だけでなく「確認した証拠」も出させるといい。
今回の変更について、
- 変更したファイル
- 影響を受ける箇所
- 実際に確認したテストやチェック
- まだ残るリスク
を分けて整理してください。確認していないものは、確認していないと明記してください。
「確認していないものは、確認していないと明記」と書くのがコツだ。ここを曖昧にすると、Claude Code はつい空白を埋めたくなる。埋めたくなる、というのが厄介だ。人間のほうがそこを見抜けないと、ログ照合の意味がなくなる。
非エンジニアの作業でも同じだ。たとえば大量の文書整理やファイル削減をやるとき、Claude Code は「重複候補」「不要そうなキャッシュ」「移動済みフォルダ」をまとめてくれることがある。だが、その一覧だけで消すと危ない。実際に消したいものと、名前が似ているだけの必要ファイルが混ざるからだ。だから、削除前に必ず照合する。
削除候補を列挙したうえで、各候補について
- なぜ不要と判断したか
- ほかに似た名前の必要ファイルがないか
- 削除せず保留にすべきものがあるか
を確認してください。
この手順で見ていくと、Claude Code の出力は「作業ログ」ではなく「照合用のメモ」に変わる。そこまで持っていければ強い。作業後に全部を思い出しながら確認する必要がなくなるし、見落としも減る。
最後に一つだけ言う。照合は、作業の最後に気が向いたらやるものではない。最初から「実際の変更と突き合わせる」前提で頼む。そうしておくと、Claude Code の返答がふわっとした要約で終わらず、確認しやすい形に寄る。結果として、手戻りが減る。これがいちばん大きい。必要なら次は、Claude Code に差分レビューをさせるときの頼み方までつなげるといい。