GitHubのPRのレビューを頼まれて荷が重い人向け
誰かから「このPR見ておいて」と振られて変わった行が多く一人で読むのがしんどいときや、自分が出したPRを人にお願いする前にセルフチェックしたいときに、対象PRのあるプロジェクトで /review にPR番号を足して叩く
GitHubに上がっているコードの変更案（PR）を1件まるごと読んで、おかしい所や直した方がいい所を指摘してもらうコマンドです。誰かから「このPR見ておいて」と振られて、変わった行が何十ファイルもあって途方に暮れる。あの状況をClaude Codeに肩代わりさせるのが /review です。
ポイントは、これが読むだけのコマンドだということ。指摘は返ってきますが、コードを勝手に書き換えたりはしません。だから安心して投げられます。
噛み砕くと
新しく入った職場で、同僚が書いた書類の束を「これ目を通しておいて」と渡される場面を想像してください。/review はその束を読み込んで、「ここの計算が合ってない」「この一文は前のページと矛盾してる」と付箋を貼って返してくれる係です。
ただし、貼るのは付箋だけ。書類そのものに赤ペンを入れて直すことはしません。直すかどうかを決めるのは、あくまで自分です。
ここが地味に大事なところ。
レビューを丸投げできるのに、勝手にコードがいじられる心配がない。だから「とりあえず見てもらう」のハードルがすごく低いんです。
大事な前提：GitHubにPRがある状態で叩く
このコマンドは、レビューしたいPRがGitHub上に実際に存在していることが前提です。手元のパソコンで適当に書きかけたコードを見てほしい、という用途のものではありません。
Claude Codeはコマンドを受け取ると、GitHubに問い合わせてそのPRの中身を取りに行きます。なので、対象のPRが立っているプロジェクトで作業していることが出発点になります。
「料理ブログのレシピ検索PR」を例に、実際の手順を見る
cooking-blog という料理ブログのプロジェクトを作っているとします。そこに、別の人から「レシピを名前で検索できる機能を足しました」という変更案が届きました。番号は42番です。
このPRを /review でレビューさせる流れを順に見ていきます。
ステップ1: 対象のプロジェクトを開いてClaude Codeを起動する
まず、レビューしたいPRが立っている cooking-blog のフォルダに入って、Claude Codeを立ち上げます。
$ cd cooking-blog
$ claudeここでのポイントは、PRが立っているプロジェクトの中で起動すること。公式の説明にある通り、レビューは「いま開いているセッションの中」で行われるので、対象のプロジェクトを開いた状態で始めます。
ステップ2: レビューしたいPRの番号を確認する
GitHubのページを開くと、届いた変更案に「#42」のような番号がついています。今回はこの42番をレビューさせます。
番号は、後でコマンドの後ろに書き足す情報として使います。
ステップ3: /review にPR番号を書き足して叩く
Claude Codeの入力欄で、コマンドの後ろにPR番号を足して送ります。
/review 42ここで初心者がやりがちな勘違いがあります。番号を書かずに /review だけ叩けば「今いる作業ブランチを勝手に判断してくれる」と思い込むパターン。公式は番号を省いたときの動きをはっきり書いていないので、最初のうちは /review 42 のように番号を明示して叩くのが確実です。
ステップ4: Claudeがコードを読み込むのを待つ
コマンドを送ると、Claude CodeがGitHubから42番のPRを取りに行き、変更されたファイルを順に読み始めます。レシピ検索機能なので、検索の入力欄、検索の処理、結果の表示まわりあたりが対象になります。
少し待ちます。
ステップ5: レビュー結果がセッションに返ってくる
読み終わると、気になった点がそのセッションの画面に返ってきます。たとえば「検索欄を空のまま送ると全レシピが出てしまう」「日本語の表記ゆれ（『鶏肉』と『とり肉』）が拾えていない」みたいな指摘です。
このとき返ってくるのは指摘だけ。コードは1行も書き換わっていません。読み取り専用、というのはこういうことです。
ステップ6: 指摘を見て、直すかどうかを自分で決める
返ってきた指摘を読んで、「空欄チェックは入れたい」と思ったら、そこで改めて「空欄のときは検索しないようにして」と次の指示を出します。/review 自体は直してくれないので、修正は別の指示になる、という流れです。
レビューと修正を分けて考える。これに慣れると使いやすくなります。
つまり /review は何をしてくれるのか
- やってくれる: GitHubに上がっているPRを手元のセッションに読み込んで、間違いや改善点をじっくり読んで指摘する
- やってくれない: 指摘した箇所のコードを書き換えること。あくまで読むだけで、直すのは別の指示が要る
- 意味が薄い場面: レビュー対象のPRがそもそも無いとき。手元の書きかけコードを見てほしいだけなら、変わった行を見せる別のやり方の方が向く
使いどころ3シナリオ（具体題材で再現）
シナリオ1: 料理ブログに来た外部からのPRを安全に見たいとき
cooking-blog に、知らない人から「レシピのお気に入り登録機能を足しました」という変更案が来たとします。中身をいきなり取り込むのは怖い。かといって全部自分で読むのも大変。
こういうときに /review 51 のように叩けば、変なコードや危なっかしい処理がないかを読んで指摘してくれます。読み取り専用なので、レビューしただけで勝手に変更が入る心配がないのが効きます。
シナリオ2: 自分が出したPRを取り込み前に最終チェックしたいとき
家計簿アプリを作っていて、自分で「支出をカテゴリ別に集計する機能」のPRを出した直後。GitHub上で同僚にお願いする前に、一度自分でセルフチェックしておきたい場面です。
自分のPRの番号を /review に渡せば、見落とした抜けや読みづらい箇所を先に拾えます。人にお願いする前のひと手間として、私はこの使い方が一番しっくりきました。
シナリオ3: コピーしてきたOSSのPRを勉強がてら読みたいとき
気になるオープンソースのプロジェクトを自分のパソコンにコピーしてきて、議論が盛り上がっているPRの中身を理解したい、というとき。変わった行が多いと、自力で全部追うのはしんどいです。
そのPR番号を /review に渡すと、何をやろうとしている変更なのかを読み解いて指摘の形で返してくれます。コードの読み方の練習台としても使えます。
初心者が踏みやすい落とし穴
- 「直してくれる」と勘違いする。
/reviewは読んで指摘するだけ。コードを書き換えてほしいなら、結果を見てから別の指示を出す必要があります - PR番号を書き忘れる。公式は番号を省いたときの動きを明記していません。最初は
/review 42のように番号を足して叩くのが確実です - PRが無いプロジェクトで叩く。レビュー対象のPRがGitHub上に存在していないと、そもそも読むものがありません
- 違うプロジェクトのフォルダで叩く。レビューは今いるセッションの中で行われます。対象のPRが立っているプロジェクトを開いた状態で叩くのが基本です
- /code-review と混同する。
/code-reviewは手元の変わった行をチェックして、修正の適用までできる別物です。読むだけが/review、直しまでやるのが/code-reviewと覚えると整理しやすいです - もっと深いレビューが必要なのに /review で粘る。公式は、より深いクラウド上のレビューとして
/code-review ultraを案内しています。大きな変更で複数の視点が欲しいときは、そちらを検討する手もあります - セキュリティ目的に使ってしまう。脆弱性に絞って見てほしいなら
/security-reviewという専用コマンドがあります。目的に合わせて使い分けると指摘の精度が上がります
書き方
/review [PR番号]やってみるとこうなる
入力
/review 42出力例
42番のPRを読み込み、気になった点をセッション画面に指摘として返す（例: 「検索欄を空のまま送ると全レシピが出てしまう」）。コードは書き換えず、指摘だけが返るこのページに出てきた言葉
- PR
- pull request（プル リクエスト）の略。コードの変更を本体に取り込む前に中身を見てもらうための提案ページ。GitHub上に番号つきで並ぶ
- 変わった行
- 元のコードと比べて、どの行が増えて・消えて・書き換わったか。GitHubでは色つきで一覧表示される
- プロジェクト本体
- プロジェクトのファイル一式と変更履歴をまとめて保存した箱。GitHub上で見えるあれ
- 取り込み
- PRの変更を、プロジェクト本体に正式に反映すること
- 読み取り専用
- 中身を読んで返すだけで、ファイルを書き換えない動き方のこと