コミット直前に「たぶん大丈夫」で流すのが、いちばん雑に事故る。差分が少ない日ほど油断するし、ファイル整理でも文書作成でも、ひとつの見落としがあとで地味に効く。
Claude Code には、コミット前確認、見落とし確認をやらせておくといい。要は、コミットする前に「何を変えたか」「消し忘れたものはないか」「別ファイルに漏れていないか」を一度洗う。人間がやると集中力が切れた瞬間に抜けるが、Claude Code は淡々と一覧化してくれる。そこが強い。
まず、作業ツリーを見せて、変更点を要約させる。これだけでも十分役に立つ。
claude
Claude Code が起動したら、こんなふうに頼む。
今の作業ツリーの変更を確認して、コミット前に見落としがないか洗ってください。
次を順に見てください。
- 変更ファイルの一覧
- 追加・削除・名前変更の有無
- 差分の要点
- 置き忘れた設定値、コメントアウト、デバッグコードの残り
- 仕様上まずい変更や、関連ファイルの更新漏れ
最後に、コミット前に人間が目で確認すべき点を短く箇条書きで出してください。
この頼み方のいいところは、Claude Code に「レビュー役」をやらせられる点だ。単に diff を読ませるだけだと、重要な見落としを拾いそこねる。だから、変更ファイルの列挙だけで終わらせず、残骸を探すように指示する。
たとえば、コードを触ったなら、こんな観点を足すと精度が上がる。
特に次を疑ってください。
- デバッグ用の print / console.log / dump が残っていないか
- 一時的なコメントや TODO が増えすぎていないか
- テストやドキュメントの更新漏れがないか
- 片方だけ直して、対になるファイルを直していない箇所がないか
ファイル整理や文書作成でも同じだ。たとえばフォルダをまとめていて、古い原稿や重複ファイルを消す前に確認させるなら、こうなる。
削除や移動の前に、見落としがないか確認してください。
- 同名だが中身が違うファイルがないか
- 参照されているのに孤立して見えるファイルがないか
- バックアップとして残すべきものが混ざっていないか
- 空フォルダや不要な一時ファイルが残っていないか
危ないと判断したものは、すぐ消さずに理由を添えて止めてください。
ここで大事なのは、「変更内容を説明して」で終わらせないことだ。説明だけなら、気持ちよく要約して終わる。コミット前確認で欲しいのは要約ではなく、抜け穴の発見だ。人間のレビューでも同じだが、見たいのは完成度ではなく、事故の芽である。
筆者は以前、設定ファイルを数か所いじって「本体だけ直せばいい」と思い込み、関連するサンプル設定を放置したことがある。動作確認は通ったのに、別環境でだけ壊れた。こういうのは、コミット前の見落とし確認を一回挟むだけでかなり減る。Claude Code に「関連ファイルの更新漏れ」を見させると、想像よりちゃんと引っかかる。
ただし、万能ではない。差分が大きすぎると、Claude Code も要点を取りこぼす。だから、巨大な変更を一気に見せるより、段階ごとに確認させたほうがいい。機能追加、リファクタリング、整形、ドキュメント更新、みたいに節目を切る。コミット前確認は、最後の儀式ではなく、途中の小さな確認として使うほうが強い。
もうひとつ、指示は曖昧にしないほうがいい。「見落としをチェックして」だけだと、ふわっとした感想が返ってくることがある。逆に、何を見てほしいかを明示すると、返答の粒度が安定する。
次の観点で見落としを洗い出してください。
1. 変更ファイル一覧
2. 想定外の副作用
3. 関連更新漏れ
4. 削除し忘れた不要物
5. そのままコミットしてよいかの判断
各項目について、気になる点があれば具体的なファイル名を挙げてください。
もしあなたが非エンジニア寄りの使い方をしているなら、「差分」より「変わったものの一覧」と言い換えたほうが通じやすい。たとえば契約書のドラフトや提案書の編集なら、誤字脱字だけでなく、数値、日付、固有名詞、見出しの階層、削除したはずの文言を確認させる。Claude Code はコード以外でも、テキストの変更点を洗う用途に向く。
最後に、見落とし確認の結果はそのままコミットメッセージの材料にもなる。たとえば「設定値の更新」「不要なデバッグ出力の削除」「関連READMEの追従」と並べれば、あとで履歴を見返したときに分かりやすい。コミット前に一度、何を直したかを外から見せるだけで、雑な取りこぼしはかなり減る。雑に急がないことだ。ここで手を抜くと、あとで差分を追いながらため息をつく羽目になる。