AIが何を変えたか分からずコミット？ /diffで保存前に変更を一目で確認

Claudeに「これ直して」と指示したら複数のファイルがずらっと変わりました。でも正確に何がどう変わったのか全部見ましたか。見ずにそのままコミット（保存）して、あとで意図と違う一行のせいで事故が起きた経験、バイブコーディングをしていると一度は遭います。/diffはこれを防ぎます。何が変わったか色で一目で見せる、コミット前の最後の点検ツールです。

定義

/diffはまだ保存（コミット）されていない変更内容を色で見せるコマンドです。

ここで「コミット（commit）」とは、変更内容を一つの記録として確定して保存する行為です。コミットする前は「変わったがまだ確定していない」状態ですが、/diffはまさにその状態の変更を見せます。

画面には通常こう表示されます。

• 追加された行: 緑色（または+表示）
• 削除された行: 赤色（または-表示）

つまりどこが新しく入ってどこが消されたか、色を見るだけですぐ分かります。（「diff」はdifference、つまり「差」の略です。）

使い方（難易度別）

基礎 — 変更を見る

Claudeがコードを直したあと、チャット欄に入力します。

/diff

入力するとまだ保存されていない変更内容が色で表示された画面が出ます。緑は追加、赤は削除。コミットする前に「自分が意図したとおりに変わったか」を目で確認する段階です。

応用 — ターン別に見る

/diff

/diffの画面が出た状態で左右の矢印キーを押すと、Claudeが作業した各段階（ターン）別の変更を行き来して見られます。「3番目の段階で何を変えたっけ」と特定の時点の変更だけピンポイントで確認するとき便利です。

発展 — ファイル別に探索する

/diff

複数のファイルが一度に変わったなら、/diffの画面で上下の矢印キーでファイル単位で移動しながら検討できます。ファイルが多いとき一つずつめくって漏れなく検討するのです。

よくある落とし穴 — /diffは「見る」だけ、戻しはしません

混同しやすいですが、/diffは変更内容を見せるだけです。ここで何を押しても変更がキャンセルされたり戻ったりするわけではありません。「検討画面」にすぎません。

だから流れはこうなります。

1. /diffで変更を確認する。
2. 意図と違う部分を見つけたら、会話で「ここのこの行はこう直して」ともう一度依頼する。
3. 満足したらそのときコミットする。

/diffは「確認する目」で、直すのは依然として会話で指示するという点を覚えてください。

実例

Claudeに複数のファイルを一度に直させたことがあります。結果だけ見るとうまくいったように見えましたが、習慣的に/diffを開いてみました。左右の矢印で段階別の変更をさらっていたら、あるファイルで意図と違ってまともな一行が消えていたのを発見しました。

/diff

すぐに「今消えたその行をまた生かして」と依頼して戻しました。そのままコミットしていたら、あとでさんざん迷わされたバグでした。コミット前の/diff一度が事故を防いでくれたのです。

もっとこう使えます

• 保存前の確認: コミットする前に変更内容を必ず目で一度見ます。
• ターン別の変更追跡: 左右の矢印で各段階の変更を別々に確認。
• ファイル別の探索: 上下の矢印でファイル単位で漏れなく検討。
• コードレビュー前の点検: 本格的なレビューに入る前、/diffでまず素早くさらうと効率的です。

ヒント: 「AIが勝手にうまくやっただろう」と見ずに進めるのが、バイブコーディングの一番よくある事故の原因です。変更が小さく見えても、コミット前の/diffを習慣にしましょう。

他の人はこう使っています

• 初心者は/plan、/diff、/compactの三つをきちんと使うだけで作業効率が目に見えて上がる。— よく使うスラッシュコマンド (Dale Seo)

まとめ

肝心なのは一文です。コミット前に/diffで何が変わったか必ず確認しろ。AIが速くたくさん変えてくれる分、その変更を検討する責任は人に残っています。/diff一行が、知らずに見過ごした事故を未然に防いでくれます。

基準: Claude Code v2.1.154 (2026.05)