そのコード、ただ動くだけで満足していないか。いちばん厄介なのは「何のために残っているか誰も覚えていない行」だ。消すと壊れそうで怖い、残すと読みづらい。こういうときに Claude Code に git 履歴を当たらせると、ただの謎コードが「いつ、誰が、どの意図で入れたか」に変わる。意味が見えるだけで、保守のストレスはかなり減る。
この手の調査でやることは単純だ。コード片を見せて、「このコードが入った経緯と目的を、git 履歴から説明して」と頼む。うまくやれば、変更を入れたコミット、関連しそうな差分、前後の文脈をたどって、なぜそこにその実装があるのかを整理してくれる。非エンジニアなら、たとえばファイル整理ツールの不思議な判定条件や、ドキュメント生成用のスクリプトがなぜその保存先を使うのかを理解するのに使える。弁護士や事務職でも、案件フォルダの命名ルールや不要ファイル削除の条件を追うときに役立つ。
やり方は、まず対象を小さく切るのがコツだ。巨大なファイル丸ごとを投げると、履歴の説明より表面の要約に逃げやすい。むしろ「この関数」「この定数」「この if ブロック」のように、意味を知りたい単位を切り出すほうが当たりやすい。
たとえば、作業ディレクトリで Claude Code を開いて、こんなふうに頼む。
この `cleanupCache()` がなぜ存在するのか、git 履歴から説明して。
関連するコミット、修正された理由、前後で何が変わったかを追って、
1) この関数の目的
2) 代替案ではだめだった理由
3) 今も残すべきか
の順で整理して。
不明な点は不明と言って、推測で埋めないで。
コードの一部があるなら、そのまま貼ってもいい。
以下のコードについて、git 履歴から存在理由を説明して。
```python
def cleanupCache(path):
...
知りたいのは、なぜこの処理が必要になったのか、どの変更で入ったのか、
似た処理とどう違うのかだ。
ここで大事なのは、「説明して」で終わらせないことだ。Claude Code は雑に聞くと、もっともらしい要約を返すだけで終わることがある。履歴を見てほしいなら、対象、観点、出力形式を決める。そうすると、単なる感想文ではなく、追跡結果として読むに耐える形になりやすい。
もう少し実務っぽくするなら、調べたい情報を最初から固定しておくといい。
```text
この処理の由来を git から追って、次の順で出して。
- 最初に入ったコミット
- その直前に起きていた問題
- その変更で解決したこと
- 後から手直しされた点
- 今なら削除できるかどうかの判断材料
コミットメッセージだけで断定せず、差分も見て説明して。
最後の一文が効く。コミットメッセージは雑なことが多い。現場では「とりあえず修正」「調整」みたいな名前が山ほどある。そこだけ読んで納得すると痛い目を見る。実際、筆者も以前、コミット名だけ見て「不要な保険だろう」と思って消しそうになり、差分を追ったら外部システムの不整合回避だったことがある。履歴の名前は手がかりにすぎない。本体は diff だ。
Claude Code に渡すときは、できればリポジトリのルートで作業させる。履歴を追うには、ファイル単体より周辺の変更が重要だからだ。変更時点の前後関係を見ないと、なぜそのコードが必要になったのかが抜け落ちる。特にリファクタリングが多いプロジェクトでは、ファイルが移動していても同じ意図の変更が別コミットに分かれていることがある。そういうときは、ひとつのコミットだけ見て決め打ちしないほうがいい。
使い方の感覚としては、こんな頼み方がちょうどいい。
`src/reporting/export.ts` の `buildFilename()` がなぜあるのかを説明して。
履歴をたどって、初出コミットと、その後の変更理由をまとめて。
もしファイル名変更や移動で追跡が途切れるなら、そこも明記して。
これで、単なる「この関数はファイル名を組み立てるためのものです」では終わらない。必要なら「誰のための命名規則か」「外部連携の制約があったか」「重複実装を避けるためか」まで見えてくる。文書作成の場面なら、「この章立てがなぜこの順番なのか」を履歴から説明させるのも有効だ。改稿の跡をたどると、見出し順の理由が出ることがある。
ただし、ここでひとつ落とし穴がある。履歴があるからといって、すべての理由がきれいに残っているとは限らない。古い変更ほど、コミットメッセージはざっくりしているし、途中で大きくリファクタリングされていると、元の意図と現状の実装が分離している。Claude Code にもそこは無理をさせないほうがいい。
たとえば、こういう頼み方は危ない。
このコードの存在理由を完全に断定して。
これはだめだ。履歴に残っていない会話や口頭の合意まで、AI に埋めさせようとすると雑になる。代わりに、断定と推測を分けさせる。
git 履歴から確認できた事実と、推測にしかならない点を分けて説明して。
事実にはコミット ID を添えて。
推測は「推測」と明記して。
この分け方にしておくと、後で人間が判断しやすい。自分でレビューするときもラクだし、非エンジニアが読む説明文にも使いやすい。履歴から確認できたことだけを拾えば、説明の筋がぶれない。
もうひとつ、よくある失敗がある。調べたいコードの周辺に、現在は使われていない古い実装が残っている場合だ。Claude Code に雑に広く聞くと、現行コードと死んだコードを混ぜて語ることがある。これを避けるには、「今の実装だけなのか」「過去の実装も含めて見たいのか」を先に決める。
この条件分岐が、現行コードで本当に必要かを判断したい。
git 履歴で入った背景を追ったうえで、今のコードベースで同じ制約がまだ生きているかも確認して。
不要なら、削除時のリスクを具体的に挙げて。
ここまでやると、履歴調査がただの考古学で終わらない。今も残すべきか、整理してよいか、判断の材料になる。Claude Code の強みは、git の変更を読む作業を人間の代わりに細かく回せることだ。人間がやると面倒で見落としやすい「この行はいつ増えたか」「その直前に何を直したか」をまとめて拾わせると、かなり効く。
実務での使いどころを、少しだけ具体化しておく。たとえばディスク削減のために古いキャッシュ削除スクリプトを見直すとする。コードの意味が不明なまま消すと、必要なログまで消す事故が起きる。そこで Claude Code に履歴を見せて、「これは容量節約のための掃除なのか、運用上の保険なのか」を説明させる。文書作成なら、テンプレートの注意書きがなぜ残ったかを追って、消していいかを判断する。どちらも、見た目は同じ「変なコード」に見えて、中身はぜんぜん違う。
最後に、頼み方の型を一つだけ置いておく。これでだいたい外しにくい。
このコード片について、git 履歴をもとに「なぜ存在するか」を説明して。
条件:
- 初出コミットを探す
- 直前の変更理由も追う
- コミットメッセージだけで断定しない
- 差分と前後関係を優先する
- 事実と推測を分ける
- もし履歴だけでは分からないなら、分からないと書く
出力:
1. 要約
2. 履歴で確認できた事実
3. まだ不明な点
4. 今後このコードを触るなら注意する点
この聞き方にしておくと、Claude Code は「説明」だけでなく「判断の土台」まで返しやすい。コードの由来が見えると、消すべきか残すべきか、修正してよいかの判断がずっとやりやすくなる。謎を謎のまま抱え込むより、git に聞いたほうが早い。