/code-review と、このコマンドを使わずに直接会話の中でコードを貼り付けてClaudeに見てもらうこととは、実際にどう違うのか？
最大の違いは「実行方式」と「コンテキストの使い方」にある。会話の中で直接コードを貼り付けて質問すると、レビューのプロセスがメイン会話のコンテキスト空間を消費し、対象ファイルが多い場合、会話が冗長になりやすい。一方 /code-review は現在バックグラウンドSubagentとして実行され、独自の独立したコンテキストウィンドウを持っており、ファイルごとの分析プロセスはメイン会話のスペースを消費せず、最終結果だけが返される。
もう1つの違いはデフォルトのレビュー範囲である。会話の中で直接質問する場合、レビュー範囲は完全にあなたが貼り付けたもの、尋ねたものに依存する。一方 /code-review は明確に定義されたデフォルトの挙動（現在の差分、または指定したPRをレビューする）を持っており、これはあなたが手動でレビューしたいコードをコピー＆ペーストする必要がなく、実際の変更内容を直接読み取ってくれることを意味する。すでに明確な差分やPRがある状況では、/code-review の方が手動でコードを貼り付けて質問するよりも通常は手間が省ける。しかし、ある小さなロジックについて素早く議論したいだけであれば、会話の中で直接尋ねる方がかえって直接的かもしれない。
もしどのPR番号を使うべきか分からない、あるいは現在の差分の範囲が実際何なのか分からない場合、事前に簡単に確認する方法はあるか？
最も直接的な方法は、/code-review を実行する前に、一般的なgitコマンドで状態を確認することである。git status で現在どのファイルが変更・追加・削除されているかを確認でき、git diff で具体的な変更内容を確認できる。もし変更がすでにPRとしてプッシュされている場合は、GitHub（またはあなたが使用しているコードホスティングプラットフォーム）上で直接そのPRの番号を確認し、その番号をコマンドに組み込めばよい。
まだコミットしていないものがあるかどうか分からない場合、実用的な習慣として、/code-review を実行する前に自分にこう問いかけるとよい。「もし今回のレビュー結果が自分がまだコミットしていない変更しかカバーしていないとしたら、チェックしてほしいと思っているものを見逃してしまわないか」。答えが「見逃してしまう」であれば、あなたが本当にレビューしたいのは現在の作業ディレクトリの差分ではなく、すでに提出済みのPRである可能性が高く、その場合はコマンドの後に直接PR番号を付け加える方がより正確である。
バックグラウンドでのレビューが完了した後、ある提案が十分具体的でなく、何を言っているのかよく分からないと感じた場合、どう追加で質問するのが効率的か？
より効率的な追加質問の方法は、レビュー結果の中でよく分からなかった具体的な文言を直接引用し、次の2点を明確に尋ねることである。「この提案は具体的にどの行、どの関数を指しているのか」と「なぜこれが問題になるのか、修正しなければ実際にはどんな状況が起こるのか」。このような具体的な追加質問は、漠然と「これはどういう意味か」と尋ねるよりも、通常は有用な答えを早く得られる。なぜなら、あなたがすでに質問の範囲を絞り込む手伝いをしているからである。
もし追加で質問した結果、その提案が実際にはあなたのプロジェクトの実情に合っていないことが分かった場合（例えば、提案されている書き方が、プロジェクト内の特定の理由でそのようにはできない場合など）、その背景となる文脈を直接説明し、単純に受け入れる・拒否するのではなく、「この提案は私たちの状況に合わせてどう調整すべきか」という会話に持っていくとよい。この行き来する議論自体も、その提案が本当に採用すべきかどうかを判断するプロセスであり、最初の時点で急いで決定を下す必要はない。
もし自分がチームの中で初めて /code-review を日常のワークフローに取り入れようとする人である場合、他のチームメンバーにどう説明し、みんなに合理的な期待を持ってもらえばよいか？
より実践的な方法は、まず自分自身で何回か実際に実行して具体的な事例を集め、それらの事例を持ってチームに説明することであり、「このツールは便利だ」と漠然と言うのではない。例えば、「これらのレビューでは、自分自身が気づかなかったエッジケースを確かに拾ってくれた」という事例と、「これらのレビューでは、提示された提案が私たちのチームの慣例に合っておらず、人による判断が必要だった」という事例の2種類を整理し、みんなにその強みと限界がそれぞれどこにあるかを明確に理解してもらい、それを万能な自動チェック機構だと誤解させないようにするとよい。
チームへの説明において最も重要な心構えの調整は、/code-review が提供するのは参考にする価値のある意見であって、人によるレビューを置き換える仕組みではないということである。それを「人によるレビューの前に一度走らせて、明らかな問題をふるい落とし、人によるレビューがより専門的な判断が本当に必要な部分に力を注げるようにする」と位置づける方が、「このツールがあれば人によるレビューはもう必要ない」とみんなに誤解させるよりも、実際の使用効果に近く、期待が過剰にならないため、最初に限界にぶつかった際にこのツールへの信頼を失いにくい。
もしClaude Codeで初めてコードレビューを実行するなら、最も直接的な入り方は、すでに何らかのコード変更がある（コミットしていない、あるいはすでにPRとして提出済みの）プロジェクトを開き、会話の中で /code-review と入力することである。このコマンドは現在の差分（diff）または指定したPRを分析し、コードの問題を1つずつチェックし、完了すると結果を報告する。以下、初めて使う人が最もよく遭遇する一連の流れを使って、各ステップで実際に何が起きるのか、初心者がどこでつまずきやすいのかを説明する。
/code-review はデフォルトで現在の差分——つまりすでに変更したがまだコミットしていない可能性のある内容——をレビューする。特定のPRをレビューしたい場合は、コマンドの後にPR番号を直接付け加えることができる：/code-review <level> <pr#>。初心者によくある混乱は、「今実際にどの範囲がレビューされているのか」が分からないことである。より確実なやり方は、まず git status や git diff で現在実際にどんな変更があるかを確認してから /code-review コマンドを実行することであり、想定していたレビュー範囲と実際の範囲がずれるのを避けられる。
現在 /code-review はバックグラウンドSubagentとして実行されており、これはレビューのプロセス自体（各ファイルの読み込みや分析）が会話にリアルタイムで表示されないことを意味する。表示されるのはレビューが完了した後に報告される結果であり、その間も同じ会話スレッド内で他の作業を続けることができる。初めて使う人は「画面が動いていない＝止まってしまった」と誤解しがちだが、これは実際には正常な状態である。バックグラウンド実行の目的は、レビューのプロセスで会話画面が埋め尽くされないようにすることであり、辛抱強く報告を待てばよい。進捗を確認したい場合は、まだバックグラウンドで実行中かどうかを確認することもできる。
レビューが完了すると、報告される内容は通常、具体的な問題点（潜在的なエッジケース、可読性についての提案、プロジェクトの慣例に沿っているかどうかなど）を指摘している。この段階でよくある誤解は、「すべての提案を必ず修正しなければならない規則だと捉えてしまう」ことである。実際にはこれらは提案であり、あなたはそのコードに対する自分自身の理解を用いて、本当に修正すべきものとひとまず保留してよいものを判断する必要がある。もしある提案が自分になじみのないロジックに関わっているように見える場合は、同じ会話の中で直接「この提案は具体的にどこを指しているのか、なぜ問題になるのか」と尋ねる方が、自分の感覚だけで推測するよりも通常は早く明確になる。
最初のよくある誤解は、/code-review を一度きりの、何も気にしなくてよいブラックボックスの操作として扱ってしまうことである。より良い心構えは、それを「経験豊富だがあなたのチームの慣例を知らない同僚」からの意見として受け止めることである。それが指摘する問題は通常真剣に検討する価値があるが、最終的にそれに従うかどうかは、あなた自身のプロジェクトの文脈への理解と組み合わせて判断する必要がある。2つ目の誤解は、レビュー範囲を誤って捉えてしまうことである。例えばファイル全体をレビューしていると思い込んでいたのに、実際には差分の変更部分だけがレビューされており、変更されていないが実際には問題のある古いコードを見逃してしまう、といったケースである。変更部分だけでなくファイル全体をレビューする必要がある場合は、その旨を別途明確に伝える必要がある。
初めて使う人への最も実践的なアドバイスは、まず影響範囲が限定的で、レビュー結果が完全に正確でなくても深刻な結果にならないブランチで一度試してみて、それが拾い上げる問題のタイプが自分が普段行っているレビューの習慣とどう異なるかを実際に体感してから、正式な開発フローに組み込むかどうかを決めることである。1〜2回実行してみれば、それがどんな種類の問題を拾うのが得意か（明らかなエッジケースの見落としなど）、そしてどんな種類の問題はやはり自分自身がプロジェクトの文脈に基づいて判断する必要があるか（チーム内の暗黙の慣例に沿っているかどうかなど）が、より明確に分かってくるだろう。