古いコードや見慣れない削除を前にしたとき、いちばん欲しいのは「誰が書いたか」より「なぜ残っているか」です。Claude Code には、対象ファイルを読みつつ git の履歴も手がかりにして、変更の背景を文章で整理させる使い方があります。単なる要約ではなく、「この行がいつ入ったか」「直前に何が壊れていたか」「削除してよいかの判断材料は何か」を拾わせるのがコツです。
たとえば、リファクタリング前の分岐が妙に残っている、見えないところで古い設定が生きている、文書フォルダに古いテンプレートが増殖している。そういう場面で、Claude Code に履歴を追わせると、コードの現在形だけでは見えない理由が見えてきます。非エンジニアでも、ファイル整理や文書作成の「これは何のために置いてあるのか」を詰める用途に向いています。
使い方は、先に「いま見えているファイル」と「履歴」を両方見せることです。Claude Code に対して、対象の場所を決めたうえで、こんなふうに頼みます。
このファイルについて、git 履歴を手がかりに「なぜこのコードやこの記述があるのか」を説明してください。
見てほしい観点:
- どの変更で入ったか
- その直前に何を直していたか
- 今も必要そうか、削除候補か
- 断定できない点は断定しない
最後に、変更の背景を3〜5行で要約してください。
もう少し具体的に、コードの一部だけが気になるなら、その周辺を指して依頼すると話が早いです。
`src/payments/checkout.ts` のこの if 分岐がなぜ残っているのか、git 履歴から説明してください。
特に、いつ追加されたか、どの不具合や仕様変更に対応したか、後から条件が増えた理由を知りたいです。
文書や設定ファイルなら、同じ考え方で十分使えます。
この README の古い注意書きがなぜ残っているのか、git 履歴をたどって説明してください。
削除されずに残った理由と、今の運用にまだ必要かどうかを整理してください。
実際に役立つのは、Claude Code が「履歴を読む」だけでなく、「いまの内容」と突き合わせて言葉にしてくれる点です。たとえば、ある条件分岐が「昔の外部 API の不具合回避として入った」ものなら、単に古いという理由では消せません。逆に、テンプレートに残っている注意文が、実際には別の運用に置き換わっているなら、削ってよい候補になります。履歴の事実と現在の意味を分けて説明させると、判断しやすくなります。
ここで大事なのは、Claude Code に「削除して」と先に言わないことです。理由探しのつもりが、いつのまにか改変の提案に寄ってしまいます。まずは背景の説明だけを求める。必要ならその次に、「残すべきか」「消すならどこまで影響があるか」を尋ねる。順番を間違えると、説明と提案が混ざってしまい、履歴の読み解きが甘くなります。
もうひとつの注意は、履歴の見え方です。git 履歴は、コミットメッセージが丁寧であるほど役に立ちますが、常にそうとは限りません。雑なメッセージしかない、途中で大きな整理コミットが入っている、別ブランチの事情が混ざっている。そんなとき Claude Code の説明は参考になりますが、万能ではありません。断定しすぎる出力が出たら、その場で「どのコミットのどの差分に基づくか」を確認させるのが安全です。最新版の挙動や細かなコマンドの差は、公式ドキュメント（docs.claude.com）で確認すると確実です。
少し進めるなら、「背景説明」と「安全な整理」を分けて依頼すると実務で使いやすくなります。前半で履歴を読ませ、後半で整理方針を出させる流れです。
まず git 履歴から、この記述が入った理由を説明してください。
そのうえで、削除・統合・現状維持の3案に分けて、判断材料を短く整理してください。
推測は推測と分かるように書いてください。
この形にしておくと、ファイル整理にも向きます。たとえば、古い案件フォルダの中に同じような書面が何本もあるとき、「なぜこの版だけ残ったのか」を履歴から探らせれば、最終版なのか、途中保存なのか、参照用に置かれたのかが見えやすくなります。ディスク削減の前に中身の意味を確認したいときにも、かなり相性がいい使い方です。
最後に、履歴を読ませるときは、質問を広くしすぎないことです。「このコードの意味を全部説明して」だと現在の仕様説明に流れやすいので、「なぜあるのか」「いつ入ったか」「何を守っているか」のように、理由に焦点を絞ったほうが、履歴の価値が出ます。Claude Code はソースを読むのが得意ですが、理由探しは問いの立て方で精度が変わります。そこを押さえると、古いコードや古い文書の前で立ち止まる時間がかなり減ります。