Claude Codeのcode-reviewプラグイン — PRを多角レビューする手順

code-reviewプラグインは、Anthropicが公開しているプルリクエスト（PR）向けの自動レビュー用プラグインです。複数のレビュー担当エージェントを並列に走らせ、各指摘に0〜100の信頼度を付け、80以上のものだけをPRのコメントとして投稿します。

名前が組み込みの/code-reviewと同じなので、混同されやすい組み合わせです。このプラグインは別物として入り、呼び出しは/code-review:code-reviewになります。ここでは入れ方、コマンドの中身、閾値とCLAUDE.mdの扱い、組み込み版との使い分けを順に書きます。

code-reviewプラグインは何をするのか

マーケットプレイスの説明では、Anthropic verifiedの表示があるプラグインで、提供元はAnthropicです。目的は「専門化した複数のエージェントと信頼度によるフィルタで、PRのレビューを自動化する」ことです。

誤検知を減らすために、投稿する指摘を絞る設計です。指摘を増やして網羅するのではなく、「出すなら確度が高いものだけ」に寄せています。

対象外のPRも最初に弾きます。閉じているPR、ドラフトのPR、自動生成で単純なPR、すでに同じレビューが付いているPRは、レビューを始めません。すでにレビュー済みかどうかを見る判定が、実行の最初と最後に入っています。

コメントの形式も決まっています。各指摘に、フルのコミットSHAと行範囲を含むGitHubのリンクが付きます。コマンド定義は、フルSHAを使わないとMarkdownのプレビューが正しく表示されないとして、形式を厳密に指定しています。

入れ方と呼び方

導入はプラグインの標準手順です。公式マーケットプレイスは対話セッションの初回起動で登録されます。

/plugin install code-review@claude-plugins-official

セッション内では、このコマンドはすぐにインストールせず、プラグインの詳細パネルを開きます。そこでスコープを選んで確定します。シェルから入れる場合は次の形です。

claude plugin install code-review@claude-plugins-official

前提は2つです。GitHub CLI（gh）が入っていて認証済みであること、そしてGitHubと連携したGitリポジトリで動かすことです。CLAUDE.mdは必須ではありませんが、あると準拠チェックが働きます。

呼び出しは名前空間付きになる

プラグインの部品は、プラグイン名の名前空間の下に置かれます。たとえばdeploy-toolsのreviewerはdeploy-tools:reviewerとして現れます。code-reviewプラグインのコマンドも同じで、呼び出しは次の形になります。

/code-review:code-review

素の/code-reviewは、Claude Codeに同梱された組み込みの/code-reviewです。プラグインのスキルは/plugin-name:skill-nameとして名前空間が分かれるため、両者は共存します。GitHub Actionsから呼ぶ例でも、プロンプトは/code-review:code-review --comment <owner>/<repo>/pull/<番号>の形で書かれます。

コマンドの中では何が起きるのか

プラグインの実体はcommands/code-review.mdという1枚のコマンド定義です。ここに手順が8段で書かれていて、Claudeがその順に実行します。

コマンド定義の冒頭にはallowed-toolsとして、gh pr comment、gh pr diff、gh pr view、gh pr list、gh issue view、gh issue list、gh searchの7つが書かれています。投稿に使えるのはgh pr commentで、コードをビルドしたり型検査を走らせたりはしない設計です。ビルドや型検査はCIの仕事だとコマンド側が割り切っています。

レビュー担当は4人か5人か

担当の数は、資料によって書き方が違います。READMEは「4つの並列エージェント」と書き、担当を次のように割ります。

• エージェント1と2: CLAUDE.mdへの準拠を監査する
• エージェント3: 変更の中にある明らかなバグを探す
• エージェント4: git blameと履歴から、文脈に基づく問題を探す

一方、マーケットプレイスの説明は「5つの独立したレビュアー」で、CLAUDE.mdの準拠、バグ検出、gitの履歴、過去のPRコメント、コード内コメントの検証を挙げます。コマンド定義（commands/code-review.md）も5つで、手順4が次のように分かれています。

READMEはCLAUDE.md準拠を2人で見る割り方で、コマンド定義とは担当の分け方も違います。実際にClaudeが読んで実行するのはcommands/code-review.mdの中身です。挙動を知りたいときは、READMEよりコマンド定義を見るのが確実です。この記事の担当表も、コマンド定義に沿った5担当で書いています。

READMEの「Launch 4 review agents」を信じてコスト見積もりをすると、実際の呼び出し数が合いません。担当の数に加えて、手順1・2・3・5・7でHaikuエージェントが動くからです。指摘1件ごとに採点エージェントが1つ付く点も、見積もりに効きます。

信頼度80のフィルタと、落とされる指摘

採点は次の目盛りで、エージェントに一字一句そのまま渡されます。

投稿されるのは80以上だけです。

CLAUDE.mdを根拠にする指摘には、追加の確認が入ります。採点エージェントが、CLAUDE.mdが本当にその点を名指ししているかを確かめます。曖昧な規約を根拠にした指摘は落ちやすい仕組みです。

コマンド定義は、誤検知として扱う例を列挙しています。

• 以前からある問題（PRで入ったものでない）
• バグに見えるが実際にはバグでないもの
• シニアエンジニアなら指摘しない細かい指摘
• リンター、型検査、コンパイラが拾う問題
• CLAUDE.mdが求めない一般的な品質の話（テスト不足、ドキュメント不足など）
• CLAUDE.mdで禁じられていても、lint ignoreコメントなどで意図的に黙らされたもの
• 意図したと思われる機能変更
• PRで触れていない行の問題

つまり、このプラグインは「新しく入った、CLAUDE.mdか明白なバグに根拠がある指摘」に寄せたレビューです。網羅的な品質監査や、スタイルの指摘は期待しない道具です。

CLAUDE.mdを書いて精度を上げる

準拠チェックの担当が働くかどうかは、CLAUDE.mdの書き方で決まります。READMEも「CLAUDE.mdをより具体的にする」ことを、誤検知対策の第一手にしています。

PRレビューで拾わせたい規約は、検査可能な形で書きます。「きれいに書く」ではなく、違反を1行で指せる規則にします。

# Review rules
 
- OAuthのコールバックは必ずエラーを処理する（`catch`で握りつぶさない）
- 関数名はcamelCase、型名はPascalCaseにする
- `src/payments/`のDB書き込みは必ずトランザクション内で行う
- 外部APIの呼び出しにはタイムアウトを指定する

規約はディレクトリごとに置けます。コマンドは、PRが触ったファイルのディレクトリにあるCLAUDE.mdも集めます。src/payments/CLAUDE.mdのように範囲を絞った規約を置けば、その配下の変更のレビューで参照されます。

READMEのコメント例でも、指摘の根拠にCLAUDE.mdの文言が引用されます。たとえば「OAuthのコールバックのエラー処理が欠けている（CLAUDE.mdに"Always handle OAuth errors"とある）」のような形です。規約の文言がそのまま根拠に出るので、レビューの指摘が出たときに、どの規約が効いたのかを追えます。

READMEは、繰り返し出るレビューの指摘をもとにCLAUDE.mdを更新することも勧めています。

閾値やスキップ条件を変えたいとき

マーケットプレイスの説明は、信頼度の閾値と重点領域（セキュリティ、パフォーマンス、アクセシビリティ）を「コマンドの設定を編集して」変えられる、と書いています。専用の設定項目やフラグがあるわけではなく、変える場所はcommands/code-review.mdの文面です。

閾値は手順6の「80未満の指摘を落とす」の数字です。重点領域を足すなら、手順4の担当の指示文に書き足します。引数で厳しさを変えたい場合は、後述の組み込み版にeffortの指定があります。

投稿されない理由は、READMEのトラブルシュートが5つ挙げています。

• PRが閉じている
• PRがドラフトである
• 自動生成や自明で、レビューするまでもないと判定された
• 以前のレビューがすでに付いている
• 80以上の指摘が1件もなかった

最後の項目は、動作の失敗ではありません。コメントが付かないときは、指摘が閾値に届かなかった可能性も含めて切り分けます。

コメントのリンクが壊れる場合は、フルSHAと#L<開始>-L<終了>の形、そして指摘の前後に最低1行の文脈を含む範囲になっているかを確かめます。ghが失敗するなら、認証状態を見直します。大きなPRで時間がかかるのは通常の挙動で、PRを小さく分けるのが対処です。

組み込みの/code-reviewとどう使い分けるか

Claude Codeには、同名の組み込みコマンドがあります。こちらは現在の差分、またはPR番号・ブランチ・パスを指定して、正しさのバグを調べます。--fixで指摘を作業ツリーに適用し、--commentでGitHubのPRやGitLabのMRに投稿でき、lowからmax、ultraまでのeffortを指定できます。

PR単位でレビューを走らせ、規約への準拠を指摘させたいなら、プラグインが向きます。手元の変更を修正まで進めたいなら、組み込み版です。effortの使い方はClaude Code /code-reviewでeffortを指定するに、Actionsを含めた実行経路の比較はClaude Codeコードレビューの4つの実行経路にあります。

クリーンアップ寄りの確認が欲しいときは、/simplifyコマンドが別の役割を持ちます。外部サービス型のレビューを入れたい場合は、Optibotプラグインのような別のプラグインが選択肢になります。

使わないほうがよい場面も、READMEは明記しています。即時マージが必要な緊急のホットフィックスと、閉じている・ドラフト・自動生成のPR（そもそも自動でスキップされる）です。逆に向くのは、意味のある変更を含むPR、重要な経路に触れるPR、複数人が関わるPR、規約への準拠が重要なPRです。

自動化に組み込む

READMEは、PR作成のたびに自動実行し、すでにレビューがあればスキップする運用を、CI/CDへの組み込み例として示しています。実際のワークフローの書き方は、Claude Codeコードレビューの4つの実行経路にYAMLの例があります。

ローカルで使う基本の流れは単純です。PRを作り、プラグインのコマンドでレビューし、指摘を直してからマージします。出た指摘は人のレビューの代わりではなく、確認の出発点として扱うのがREADMEの位置づけです。

まとめ

code-reviewプラグインは、PRに対して「CLAUDE.mdか明白なバグに根拠のある、信頼度80以上の指摘」だけを返す道具です。素の/code-reviewは組み込み版で、プラグインは/code-review:code-reviewとして呼びます。

挙動はREADMEの「4担当」ではなく、コマンド定義の5担当と、Haikuによる採点が基準です。コメントが出ないときは、まずPRの状態と閾値を疑ってください。精度を上げる近道は、検査できる粒度でCLAUDE.mdに規約を書くことです。