結論：2026年9月現在、Claude Code v2.1.260以降の/diffパネルを使うと、会話を止めずに未コミット変更を横で確認し、気になる行を選んでそのまま修正依頼までつなげられます。
- 利用条件は、Gitリポジトリ、フルスクリーン表示、横幅110列以上、Claude Code v2.1.260以降です。
Ctrl+X Bで「このセッション」「未コミット変更」「デフォルトブランチからの差分」を切り替えられます。/diffは目視確認、/code-reviewはレビュー、/rewindは復元です。役割を分けると安全に運用できます。
対象読者：Claude Codeを個人利用からチームの開発工程へ広げたいエンジニア、テックリード、プラットフォーム担当者。
今日やること：claude --versionでバージョンを確認し、Gitリポジトリ内で/diffを開いて、比較範囲と行選択を一度試してください。
Claude Codeに実装を任せると、速度より先に問題になるのが「どこまで変わったかを、会話の流れを切らずに把握できるか」です。別ターミナルでgit diffを開く運用でも確認はできます。しかし、ファイルを往復し、対象行を説明し直し、修正後にまた差分を開く手順は、変更量が増えるほど認知負荷になります。
Anthropicは2026年9月3日公開のClaude Code v2.1.260で、フルスクリーン表示の会話横に開く/diffパネルを追加しました。これは「AIが書いたコードを人間が承認する」という工程を、後工程の一括レビューから、実装中の小さなレビューへ移すためのUIです。本稿では公式ドキュメントで確認できる仕様だけを使い、業務導入向けの5手順、レビューコマンドとの分担、失敗しやすい運用、導入チェックリストまで整理します。
Claude Code /diffパネルとは何か
/diffは、Claude Codeを終了せずに作業ツリーの変更を確認するコマンドです。公式ドキュメントによると、Claudeが行った編集だけでなく、まだコミットしていない他の変更も表示対象になります。つまり「AIの変更だけを盲目的に承認する画面」ではなく、現在の作業ツリーをレビューする入口です。
v2.1.260で変わった点
従来のクラシック表示では、/diffを実行するとプロンプト領域が差分ビューアに切り替わり、確認後に閉じる方式でした。v2.1.260以降のフルスクリーン表示では、会話の横に差分パネルが開いたまま残ります。Claudeがファイルを編集したとき、またはシェルコマンドを実行したときにパネルが更新されるため、指示、変更、確認を同じ画面で往復できます。
追加日は2026年9月3日です。利用時点で仕様が変わっている可能性があるため、まず公式のClaude Code changelogとInteractive modeを確認してください。
パネルとビューアの違い
| 項目 | diffパネル | diffビューア |
|---|---|---|
| 表示位置 | 会話の横 | プロンプト領域と切り替え |
| 表示中の会話 | 続行できる | 確認後に閉じて戻る |
| 主な条件 | フルスクリーン、Git、110列以上、v2.1.260以降 | パネル条件を満たさない場合の代替 |
| 向いている場面 | 実装中の継続レビュー | 一時的な差分確認 |
条件を満たさない場合、/diff自体が使えなくなるとは限りません。公式仕様では、パネルが開けない場合にビューアへ切り替わるか、理由が表示されます。まず表示方式を切り分けるのがトラブルシューティングの第一歩です。
業務導入前に確認する4つの条件
1. バージョンを確認する
claude --versiondiffパネルの条件はClaude Code v2.1.260以降です。チーム展開では「最新版を使う」だけでなく、検証済みバージョンと更新手順を決めます。個人ごとにバージョンが違うと、ある端末ではパネル、別の端末ではビューアという差が生まれ、手順書と実画面が一致しません。
2. Gitリポジトリで作業する
git rev-parse --show-toplevel
git status --short/diffはGitの作業ツリーを前提にします。リポジトリ外で試す、または意図しない親ディレクトリのリポジトリを参照すると、表示対象の理解を誤ります。作業開始時にリポジトリルートと現在の未コミット変更を確認してください。
3. 端末幅と表示方式を確認する
パネルには横幅110列以上が必要です。横幅144列以上で、Claudeが編集を始めたときに自動で開く条件も公式に記載されています。自動表示を一度有効にした後はプロジェクトごとの状態が記憶されます。狭い分割ペインでパネルが出ない場合は、端末を広げるかビューアを使います。
4. 作業開始時点をきれいにする
git status --short
git diff --stat
git diff --name-only未コミット変更が残ったままClaude Codeを開始すると、/diffには開始前の変更も含まれます。これは仕様どおりですが、担当者の手作業とClaudeの編集を混同しやすくなります。既存変更をコミットする、別ブランチへ退避する、あるいは「開始前から存在する変更」として記録してから作業を始めてください。
/diffを業務フローへ組み込む5手順
手順1：開始前の基準点を確認する
最初に作業ツリーの状態と現在ブランチを確認します。ここでの目的は、変更をゼロにすることではなく、レビュー対象の境界を明示することです。
git branch --show-current
git status --short
git diff --stat既存変更がある場合は、その理由をセッション冒頭でClaudeへ伝えます。たとえば次のように範囲を固定します。
既存の未コミット変更は触らず、src/auth配下だけを対象にしてください。
変更前に対象ファイルを列挙し、完了後は実行したテストと残課題をまとめてください。手順2：小さな単位で編集を依頼する
大きな要件を一度に渡すより、レビュー可能な単位に分けます。差分パネルは変更を見やすくしますが、要件の曖昧さまでは解消しません。1回の指示に、対象、変更目的、非対象、確認方法を含めます。
対象はsrc/auth/token.tsと対応するテストだけです。
期限切れ判定を共通関数へ切り出してください。
公開APIの型は変えないでください。
既存テストを実行し、追加したテスト名を最後に列挙してください。手順3：/diffを開き、比較範囲を選ぶ
/diffパネルでは変更ファイル、追加行、削除行を確認できます。Ctrl+X Bで比較対象を切り替えられます。公式仕様の3範囲は次のとおりです。
- このセッションの変更：いまのClaude Codeセッションで生じた変更を追う
- 未コミット変更：作業ツリー全体の未コミット変更を1つの一覧で見る
- 分岐後の変更：デフォルトブランチから現在ブランチが分かれた後の変更を見る
レビュー目的に合わない比較範囲を使うと、必要な差分を見落とします。実装中はセッション範囲、コミット前は未コミット範囲、PR前は分岐後の範囲、というようにチーム規約へ落とすと迷いが減ります。
手順4：問題の行を選び、修正を依頼する
パネル内で行をマウス選択すると、その選択が次のプロンプトへ添付されます。説明のためにファイル名や行番号を手入力し直す必要がありません。次のように、選択箇所への懸念と受け入れ条件を短く伝えます。
選択した条件分岐はnullと空文字を同じ扱いにしています。
既存仕様では別扱いなので、公開型を変えずに分岐を修正し、境界値テストを追加してください。ここで「直して」だけにしないのが重要です。何が問題か、守る仕様は何か、どう確認するかをセットにします。修正後はパネルが更新されるため、同じ場所を再確認できます。
手順5：テスト、レビュー、コミットを分離する
diffパネルは差分を表示する機能であり、テスト結果や設計妥当性を保証しません。次の順序でゲートを分けます。
- 目視で変更範囲と意図しないファイルを確認する
- プロジェクト固有のテスト、型検査、lintを実行する
/code-reviewまたは/reviewで差分レビューを実行する- 必要に応じて
/security-reviewで現在ブランチの変更を確認する - 人間が結果と残課題を確認してからGitへコミットする
Claude Code公式コマンド一覧では、/code-reviewは現在の差分を正しさや改善観点でレビューし、/reviewはその別名です。/security-reviewは現在ブランチの変更を対象にするため、実行中サイトやデプロイ済み環境を検査するものではありません。
チーム導入ではコマンドよりレビュー境界を設計する
/diffを配布するだけでは、誰が何を確認して承認するかは決まりません。UravationのClaude Code個別指導・導入支援では、対象リポジトリの権限、CLAUDE.md、テストゲート、レビュー責任を一緒に整理します。
- 既存開発フローの棚卸し
- Claude Codeの権限とレビュー基準の設計
- 実際のリポジトリを使ったハンズオン
3つの表示範囲をどう使い分けるか
セッション差分：担当作業の因果関係を見る
「この指示で何が変わったか」を追うときに向きます。複数の指示を段階的に出した場合でも、どのターンでどのファイルが変わったかを追いやすくなります。クラシックのdiffビューアでは、左右キーでCurrentと各ターンのビューを移動できます。
ただし、公式ドキュメントでは、Claudeがシェルコマンド経由で作った変更はターン別ビューではなくCurrentにだけ現れると説明されています。ターン別の表示だけで完結せず、最後にCurrentまたは未コミット変更全体を確認してください。
未コミット差分：コミット直前の抜けを探す
コミット候補を確認するときは、担当者の手作業を含めた作業ツリー全体が対象です。生成ファイル、設定ファイル、デバッグ用ログなど、意図しない変更が混ざっていないかを見ます。diffパネルはテストファイルや生成ファイルを最初は省略表示する場合があり、件数表示をクリックすると展開できます。省略されているから変更が存在しない、とは判断しないでください。
分岐後の差分：PR全体の整合性を見る
ブランチ上で複数コミットを積んだ後は、直近の未コミット差分だけではPR全体を説明できません。デフォルトブランチからの差分へ切り替え、要件、テスト、ドキュメント、設定変更の整合を見ます。並列開発でブランチ境界を明確にしたい場合は、Claude Code×git worktree並列開発ガイドも参照してください。
/diff、/code-review、/security-review、/rewindの役割
/diffは変更を見えるようにする
/diffの役割は、変更ファイルと変更行を人間が確認しやすい形で表示することです。表示されたから安全、という判定はできません。意図しないファイル、公開APIの変更、例外処理の欠落など、確認観点はチーム側で用意します。
/code-reviewは差分を評価する
/code-review high
/review high公式ドキュメントでは、ローカルの/code-reviewはGitHub Appをインストールせずにターミナル内で差分をレビューし、正しさのバグや再利用、単純化、効率化の候補を報告します。TeamとEnterprise向けの管理サービスとしてのCode Reviewとは提供条件が異なるため、ローカルコマンドとPR上のサービスを混同しないでください。詳しい使い分けはClaude Codeでコードレビューを効率化する実践ガイドで整理しています。
/security-reviewは現在ブランチの変更を見る
/security-review公式のSecurity guidanceでは、/security-reviewは現在ブランチの変更に対する単発確認として整理されています。実行中アプリへの侵入テスト、依存関係の継続監視、CIの静的解析を置き換えるものではありません。既存のSAST、依存関係スキャン、シークレット検知は残したまま追加のレビュー層として扱います。
/rewindはセッション内の復元を助ける
/rewindチェックポイントはユーザープロンプトごとに作成され、会話の復元、コードの復元、その両方を選べます。一方で、Bashコマンドが変更したファイル、通常のサブエージェントによる編集、別セッションや手作業の変更などは復元対象にならない場合があります。公式にも「Gitの代替ではない」と明記されています。復元範囲の詳細はClaude Code rewindで巻き戻すガイドを確認してください。
チームで使えるレビュー用プロンプト5本
以下は公開仕様に基づく構成例です。プロジェクトの言語、テストコマンド、設計規約に合わせて調整してください。実測結果を示すものではありません。
1. 変更範囲を固定する
この作業ではpackages/api/srcだけを変更対象にしてください。
作業前に変更予定ファイルを列挙し、対象外ファイルが必要になったら編集前に理由を説明してください。
完了後は/diffで確認すべきリスクの高い3点を挙げてください。2. 公開APIの互換性を確認する
選択した差分が既存の公開API、型、エラー形式を変えていないか確認してください。
変更がある場合は呼び出し元を列挙し、互換性を保つ代案を提示してください。
推測ではなく、リポジトリ内の参照を根拠にしてください。3. テストの空白を探す
現在の差分に対して、正常系、境界値、失敗系のテスト不足を分類してください。
既存テストの命名規則に合わせて追加候補を示し、実行したコマンドと結果を分けて報告してください。
実行していないテストを成功扱いしないでください。4. 設定変更をレビューする
現在の未コミット差分から、権限、環境変数、CI、デプロイ設定に関わる変更だけを抽出してください。
各変更について、影響範囲、ロールバック方法、秘密情報の混入有無を確認してください。
値そのものは出力しないでください。5. コミット前サマリーを作る
デフォルトブランチからの差分を前提に、変更目的、主要ファイル、テスト結果、既知の制約をまとめてください。
未確認事項は「未確認」と明記し、完了したように書かないでください。
最後に人間が目視すべき差分を優先順で列挙してください。失敗しやすい4つのパターンと対策
❌ パネルが見えるのでレビュー済みと考える
⭕ 対策：/diffは可視化、テストは動作確認、/code-reviewは評価、人間の承認は責任判断として分けます。表示機能に品質保証の役割を持たせないでください。
❌ ターン別差分だけを確認する
⭕ 対策：シェルコマンド経由の変更はターン別ビューに出ない場合があります。最後は未コミット変更全体とgit statusを確認します。
❌ /rewindをGitの代わりにする
⭕ 対策：チェックポイントの対象外を理解し、ブランチとコミットを長期履歴の正本にします。Bashや外部プロセスが作った変更を復元できる前提で運用しません。
❌ チーム全員へ一斉に有効化する
⭕ 対策：対象リポジトリを1つに絞り、バージョン、端末幅、レビュー観点、テストコマンド、ロールバック方法を確認してから展開します。Claude Codeの権限自体はClaude Code権限設計ガイドに沿って別途設計してください。
導入チェックリストと想定シナリオ
最小チェックリスト
- Claude Code v2.1.260以降を検証済みバージョンとして記録した
- 対象がGitリポジトリであることを確認した
- 開始前の未コミット変更を記録した
- セッション、未コミット、分岐後の比較範囲を使い分けられる
- 省略されたテスト・生成ファイルも展開して確認する
- 行選択から具体的な修正依頼を出せる
- プロジェクト固有のテストコマンドが決まっている
/code-reviewと/security-reviewの対象範囲を理解している/rewindの対象外を理解している- Gitブランチ、コミット、PRの承認工程を残している
想定シナリオ：認証処理の小規模修正
構成例として、認証処理の境界値修正を考えます。担当者は作業開始前にgit statusを確認し、対象ファイルと公開APIを変えない条件をClaudeへ渡します。Claudeが実装したら、セッション差分で今回の変更だけを追い、条件分岐の行を選択して境界値テストを追加させます。その後、未コミット差分へ切り替えて対象外ファイルが変わっていないかを確認し、テストと/code-reviewを実行します。最後に分岐後の差分を見て、PR全体の説明と一致することを人間が承認します。
これは導入設計を説明する想定シナリオであり、実運用の測定結果や特定企業の公開事例ではありません。品質指標を設ける場合は、レビュー指摘数、差し戻し理由、テスト失敗、リードタイムなどを自社環境で定義し、測定条件を保存してください。
git diffやIDEの差分表示とどう分担するか
Claude Code /diffは会話との往復を短くする
/diffの強みは、変更を見た直後に同じセッションで修正指示を出せることです。行選択が次のプロンプトへ添付されるため、レビューコメントの対象を言葉だけで説明する負担を減らせます。実装中の細かな確認、意図しない編集の早期発見、受け入れ条件の追加に向いています。
一方で、差分の表示対象は現在のGit状態とClaude Codeが追跡している編集に依存します。リポジトリ全体の履歴調査、複雑なref間比較、機械処理可能な出力が必要ならGitコマンドを使います。どちらか一方に統一するのではなく、会話中は/diff、自動化や確定前の記録はGitという分担が現実的です。
git diffは再現可能な確認に使う
git status --short
git diff --stat
git diff --name-only
git diff --checkこれらは一般的なGitコマンドの構成例です。git status --shortで変更ファイルの状態、git diff --statで規模、git diff --name-onlyで対象ファイル、git diff --checkで空白エラー候補を確認できます。プロジェクトの正本手順がある場合は、そちらを優先してください。
CIへ組み込む確認は、対話UIではなく終了コードやログが扱えるコマンドへ寄せます。/diffの目視結果をCI合否に置き換えず、既存のテスト、lint、型検査、依存関係スキャンを残します。
IDEはファイル単位の精査に使う
IDEの差分表示は、構文ハイライト、参照ジャンプ、周辺コードの閲覧と組み合わせやすい点が利点です。大規模な変更や複数ファイルをまたぐ設計確認では、Claude Codeのパネルで対象を絞り、IDEで詳細を確認し、必要な指摘をClaude Codeへ戻す流れも使えます。
ツールの優劣ではなく、確認の粒度で分けてください。/diffは対話中の早期発見、IDEは文脈を含む精査、Gitは再現可能な履歴と自動化、PRはチーム承認を担当します。
チーム展開のための運用ルール例
Definition of Doneへ差分確認を追加する
「Claude Codeを使ったら/diffを見る」だけでは、完了条件が人によって変わります。Definition of Doneには、何を確認したら次へ進めるかを具体化します。たとえば、変更ファイル一覧を確認した、対象外の設定変更がない、公開APIの差分を確認した、テスト結果を保存した、未確認事項をPRへ記載した、という状態で定義します。
ここでは確認の有無を記録し、品質を断定しないことも大切です。「AIレビュー済み」だけでは、どの範囲をどの条件で見たのか分かりません。比較範囲、実行したコマンド、未解決の指摘を残すと、次のレビュー担当者が同じ前提から確認できます。
変更の大きさではなくリスクでレビューを深くする
少ない行数でも、認証、課金、権限、データ削除、外部送信、マイグレーションに関わる変更は影響が大きくなります。逆に、自動生成されたスナップショットの大量差分は行数が多くても確認観点が限定される場合があります。追加・削除行数だけでレビュー強度を決めないでください。
- 通常変更：
/diff、テスト、担当者レビュー - 高リスク変更：上記に加えてセキュリティ確認、別担当者の承認、ロールバック手順
- 生成物中心：生成元の変更、再生成手順、生成結果の整合を確認
これは固定の保証基準ではなく、チーム設計の例です。規制業種や本番権限を扱うリポジトリでは、既存の変更管理規程とセキュリティポリシーを優先します。
PRテンプレートへ証跡欄を置く
## Claude Code利用範囲
- 対象セッション:
- 確認した比較範囲:
- 人間が重点確認したファイル:
## 検証
- 実行したテスト:
- 実行結果:
- 未確認事項:
## ロールバック
- 戻す単位:
- 影響する設定やデータ:Claude Codeの会話全文を貼る必要はありません。レビューに必要な範囲、実行事実、残課題を短く残します。シークレット、個人情報、内部URLなどをPRへ転記しないことも明文化してください。
導入後に見るべき指標
速度だけでなく差し戻し理由を見る
導入効果を測るとき、作業時間だけを追うとレビュー負荷が見えません。少なくとも、PR作成までの時間、レビュー待ち時間、差し戻し理由、テスト失敗の種類、対象外ファイルの変更、リリース後の不具合を分けて記録します。数値目標は既存チームのベースラインを取ってから決めてください。
本稿では特定の削減率や成功率を提示しません。リポジトリ規模、言語、テスト網羅性、変更の難度、担当者の経験で結果が変わるためです。測定する場合は、対象期間、件数、対象リポジトリ、比較条件を保存し、別のチームへそのまま一般化しないでください。
運用の健全性を確認する
/diffを開いた記録だけで承認済みにしていないか- テスト未実行を成功と表現していないか
- 高リスク変更に別担当者の確認が入っているか
- チェックポイントをGitの代替にしていないか
- バージョン差で手順書と画面がずれていないか
- 未コミット変更を別タスクへ持ち越していないか
月次やリリース単位でこの項目を見直すと、UI追加を一時的な便利機能で終わらせず、変更管理の改善へつなげられます。新しいClaude Codeバージョンを導入するときはchangelogを確認し、比較範囲、キーバインド、復元範囲に変更がないかを再確認してください。
よくある質問
Q1. /diffパネルが表示されません
Gitリポジトリ、Claude Code v2.1.260以降、フルスクリーン表示、端末幅110列以上を確認してください。条件を満たさない場合は、クラシックのdiffビューアへ切り替わるか、理由が表示されます。
Q2. /diffはgit diffの代わりになりますか
確認の入口にはなりますが、Gitの履歴管理やチームの承認フローの代わりではありません。コミット前にはgit statusとプロジェクトの既存手順も確認してください。
Q3. Claudeがシェルで変更したファイルも見えますか
Currentには表示されます。一方、公式ドキュメントでは、シェルコマンド経由の変更はターン別ビューには出ず、Currentにだけ現れると説明されています。
Q4. /reviewと/code-reviewの違いは何ですか
現在の公式コマンド一覧では/reviewは/code-reviewの別名です。引数や提供条件は公式Code Reviewドキュメントで確認してください。
Q5. /rewindすればすべての変更を戻せますか
戻せません。Bashコマンドや外部プロセスの変更、別セッションの変更などは追跡されない場合があります。チェックポイントはセッション内の復元補助であり、Gitの代替ではありません。
Q6. チーム導入では何から始めるべきですか
1つのリポジトリと1つの変更種別に限定し、開始前確認、差分確認、テスト、レビュー、人間承認の順序を決めてください。全社配布より先にレビュー境界を固定することが重要です。
結論と次の一歩
/diffパネルの価値は、差分表示そのものより「実装中に確認して、その行を次の修正依頼へ渡せる」点にあります。2026年9月時点の公式仕様では、v2.1.260以降、Gitリポジトリ、フルスクリーン、110列以上がパネルの条件です。条件外でもビューアへ切り替わるため、表示形式の違いを理解して手順化してください。
今日の最小アクションは、claude --version、git status --short、/diffの3つです。その後、比較範囲を切り替え、問題の行を選び、具体的な受け入れ条件とともに修正を依頼してください。最後はテスト、レビュー、Gitの履歴管理で閉じます。
Claude Codeを安全な開発フローへ組み込みたい方へ
Uravationでは、Claude Codeの個別指導、チーム導入設計、既存リポジトリを使った実装支援を行っています。
- 導入上の課題を相談する
- 対象リポジトリと現在のレビュー工程を整理する
- 権限、テスト、差分レビュー、ロールバックの最小構成を試す
次回予告：/code-reviewをローカル差分、ブランチ、PRで使い分ける設定例を整理します。
公式情報
- Anthropic, Claude Code changelog（v2.1.260、2026年9月3日）
- Anthropic, Interactive mode: Review changes with /diff（2026年9月4日閲覧）
- Anthropic, Commands（2026年9月4日閲覧）
- Anthropic, Code Review（2026年9月4日閲覧）
- Anthropic, Checkpointing（2026年9月4日閲覧）
- Anthropic, Security guidance（2026年9月4日閲覧）
