Claude Codeのpr-review-toolkit — 6つの専門エージェントでPRを観点別にレビューする
pr-review-toolkitは、コメント・テスト・エラー処理・型設計・一般レビュー・簡素化の6エージェントと /pr-review-toolkit:review-prを束ねたプラグインです。役割分担と使い分けをまとめます。
pr-review-toolkitは、PRのレビューを6つの専門エージェントに分けて任せるClaude Codeのプラグインです。Anthropicのプラグインリポジトリclaude-plugins-officialのplugins/配下にあり、エージェント6体とスラッシュコマンド1つ(/pr-review-toolkit:review-pr)で構成されます。この記事では、各エージェントが何を見るか、コマンドが差分に応じて誰を起動するか、使うときに引っかかりやすい点を扱います。
pr-review-toolkitとは何か
READMEは、このプラグインを「コメント、テスト網羅、エラー処理、型設計、コード品質、簡素化」を見る専門エージェントの詰め合わせと説明しています。1本のレビュー用プロンプトに全観点を詰める代わりに、観点ごとに別のエージェントを用意する設計です。
エージェントはサブエージェントなので、それぞれ独立したコンテキストで動きます。仕組みそのものはClaude Code Sub-agents完全ガイドにまとまっています。観点を絞るぶん、各エージェントは自分の領域だけを深く掘れます。
プラグインの定義を見ると、構成は単純です。
agents/に6つのエージェント定義(code-reviewer、code-simplifier、comment-analyzer、pr-test-analyzer、silent-failure-hunter、type-design-analyzer)commands/にreview-pr.md(コマンド名は/pr-review-toolkit:review-pr).claude-plugin/plugin.json(名前はpr-review-toolkit、作者表記はAnthropic)
インストールと最初の1回
導入は他のプラグインと同じです。公式マーケットプレイスからの導入は/plugin install <プラグイン名>@claude-plugins-officialの形で、対話セッションでは/pluginパネルが開いて内容を確認できます。
/plugin install pr-review-toolkit@claude-plugins-officialREADMEのインストール節は「personal marketplaceから/pluginsで探してインストール」という古い言い回しのままです。現行のコマンドは/pluginなので、READMEの手順をそのまま打つより、上の形で入れるほうが確実です。プラグイン全般の仕組みはClaude Codeプラグイン完全ガイドを参照してください。
入れたら、変更のあるリポジトリで次を実行します。
/pr-review-toolkit:review-pr引数なしは「全部」の指定です。コマンド定義では、既定は適用できるレビューをすべて走らせる動作になっています。
6つのエージェントの役割分担
観点ごとの担当
comment-analyzer
コメントとコードの食い違い、ドキュメントの抜け、コメントの陳腐化を見ます。
pr-test-analyzer
行カバレッジではなく振る舞いの網羅を見て、重要なテストの欠落を洗います。
silent-failure-hunter
catchブロックでの握りつぶし、不適切なフォールバック、ログ欠落を探します。
type-design-analyzer
新しい型のカプセル化や不変条件の表現を評価します。
code-reviewer
CLAUDE.mdへの準拠、スタイル違反、バグを一般的な観点で見ます。
code-simplifier
機能を変えずに、不要な複雑さや入れ子を整理する案を出します。
評価の物差しはエージェントごとに違います。READMEとエージェント定義から拾うと、次のとおりです。
| エージェント | 出力の物差し | 備考 |
|---|---|---|
| pr-test-analyzer | 出力の物差しテストの欠落を1〜10で評価(10が必須) | 備考100%カバレッジにこだわらない方針 |
| type-design-analyzer | 出力の物差し4観点を各1〜10で評価 | 備考カプセル化・不変条件の表現・有用性・強制 |
| code-reviewer | 出力の物差し問題ごとに0〜100の確信度 | 備考80以上だけを報告 |
| silent-failure-hunter | 出力の物差し重大度で分類 | 備考数値スコアはREADMEに記載なし |
| comment-analyzer / code-simplifier | 出力の物差し数値スコアなし | 備考指摘と改善案が中心 |
code-reviewerは確信度の低い指摘を出さない作りです。定義では0〜25を誤検知か既存の問題、26〜50を細かい指摘、76〜90を要対応、91〜100を重大なバグやCLAUDE.md違反とし、80以上だけを報告します。出力は重大(90〜100)と重要(80〜89)に分かれます。READMEは重大を91〜100と書いており、エージェント定義の90〜100と1点ずれています。実運用で困る差ではありませんが、閾値の話をチームでするなら定義側が正です。
review-prコマンドは誰を起動するのか
/pr-review-toolkit:review-prは、差分を見て起動するエージェントを選びます。定義にある対応は次のとおりです。
| 差分の状況 | 起動するエージェント |
|---|---|
| 常に | 起動するエージェントcode-reviewer |
| テストファイルが変わった | 起動するエージェントpr-test-analyzer |
| コメントやドキュメントを足した | 起動するエージェントcomment-analyzer |
| エラー処理が変わった | 起動するエージェントsilent-failure-hunter |
| 型を追加・変更した | 起動するエージェントtype-design-analyzer |
| レビューを通過した後 | 起動するエージェントcode-simplifier |
引数で観点を絞れます。指定できる語はcomments、tests、errors、types、code、simplify、allです。
/pr-review-toolkit:review-pr tests errors
/pr-review-toolkit:review-pr all parallel1行目はテストとエラー処理だけ、2行目は全エージェントを並列で走らせる指定です。並列は「ユーザーが求めたとき」の動作で、既定は1体ずつの逐次実行です。逐次なら1体ごとの報告を読んで次に進めます。急ぐなら並列にします。
最後に、結果は重大な問題・重要な問題・提案・良い点の4区分にまとめられ、「重大を直す→重要を直す→提案を検討→直したら再実行」という順の行動計画が付きます。
使い分けの判断
READMEの推奨は、作業の段階ごとに呼ぶエージェントを変える形です。
- コミット前:
code-reviewer、エラー処理を触ったならsilent-failure-hunter - PR作成前:
pr-test-analyzer、コメントを書いたならcomment-analyzer、型を足したならtype-design-analyzer、最後にcode-reviewer - レビュー通過後:
code-simplifierで仕上げ - PRレビュー中: 指摘された懸念に対応するエージェントだけ
コマンドを使わず、自然文で頼む経路もあります。READMEには「テストは十分か確認して」と頼めばpr-test-analyzerが、「エラー処理を見て」と頼めばsilent-failure-hunterが起動する、という例があります。起動しないときは、エージェント名か具体的な懸念(「テストカバレッジ」など)を明示すると拾われやすくなります。
自然文で頼むときの言い方
コマンドを使わなくても、READMEが挙げる言い回しで各エージェントを呼べます。観点が1つに決まっているときは、こちらのほうが手軽です。
| 呼びたいエージェント | READMEの言い回し |
|---|---|
| comment-analyzer | READMEの言い回し「コメントが正確か確認して」「追加したドキュメントを見て」 |
| pr-test-analyzer | READMEの言い回し「テストが十分か確認して」「重大なテストの欠落はある?」 |
| silent-failure-hunter | READMEの言い回し「エラー処理を見て」「サイレント失敗がないか確認して」 |
| type-design-analyzer | READMEの言い回し「この型の設計を見て」「不変条件が強いか確認して」 |
| code-reviewer | READMEの言い回し「直近の変更をレビューして」「コミット前に見て」 |
| code-simplifier | READMEの言い回し「このコードを簡潔にして」「実装を磨いて」 |
READMEは英語の例文です。日本語で頼む場合も、観点の語(テスト、エラー処理、型、コメント)を入れておくと、エージェントの説明文と結びつきやすくなります。
code-reviewerを効かせるCLAUDE.mdの書き方
code-reviewerは、プロジェクトのCLAUDE.mdに照らしてレビューするエージェントです。定義にも、ガイドライン違反は具体的な規則を引いて説明するとあります。つまりCLAUDE.mdに検査できる形の規約が書いてあるほど、指摘の質が上がります。
例えば次のような、真偽が判定できる文が向いています(あくまで書き方の例です)。
## コーディング規約
- 外部APIの呼び出しは必ず`lib/api/client.ts`を経由する
- catchで例外を握りつぶさず、ログに操作名とIDを残して再送出する
- 新しい公開関数にはテストを同じPRで追加する「きれいに書く」のような曖昧な規約は、確信度80以上の指摘に結びつきにくくなります。silent-failure-hunterやpr-test-analyzerの観点と重なる規約を書いておくと、複数のエージェントが同じ基準で判断できます。
引っかかりやすい点
対象はgit diffが基準になる
code-reviewerは、既定でgit diffの未ステージ変更を対象にします。コマンド側も変更ファイルの特定にgit diff --name-onlyを使い、既存PRの有無をgh pr viewで見ます。git diffは既定ではステージ済みの変更を含みません。コマンドの「PR作成前」の手順には「全部ステージしてから実行」とありますが、ステージ済みで未ステージ分が空のときは、対象ファイルを引数や文で明示したほうが安全です。READMEの対処も同じ方向で、ファイルを指定する、PR番号やブランチを言う、「直近の変更」「git diff」と書く、の3つを挙げています。
silent-failure-hunterは特定プロジェクトの流儀を前提にしている
silent-failure-hunterの定義には、logErrorによるログ出力、constants/errorIds.tsのエラーID、Sentryでの追跡といった、特定のコードベースの規約が書かれています。自分のプロジェクトにその仕組みがなければ、「エラーIDがない」といった指摘は筋違いになりえます。この観点は、指摘のうちログの文脈不足・握りつぶし・過広なcatchといった一般的な部分を拾い、プロジェクト固有の規約に絡む指摘は読み替える運用が現実的です。
コマンド自体は編集しない
review-prが許可しているツールはBash、Glob、Grep、Read、Taskの5つです。コマンドが直接ファイルを書き換える権限は含まれません。結果を受けて直す作業は、通常のセッションで続けます。
モデルの指定
code-reviewerとcode-simplifierの定義はモデルにopusを指定し、ほかの4体はinherit、つまり呼び出し元のセッションのモデルを引き継ぎます。PR全体に毎回allをかけると、起動するエージェントの数だけ利用量が増えます。READMEも「変更部分に絞り、リポジトリ全体には使わない」と書いています。
似た手段との置き場所
PRの観点別レビューを、別の仕組みと比べておきます。
- セキュリティ観点だけ見たいなら、security-reviewが専用です。pr-review-toolkitには脆弱性専任のエージェントがありません。
- 実装した本人の文脈を引きずらない検証が欲しいなら、敵対的レビューの設計が目的に合います。
- 自作のレビューskillで指摘を一覧として描画したいなら、ReportFindingsツールの出力形式が参考になります。
/code-reviewの深さを調整したいときは、effortの指定で変えられます。
pr-review-toolkitは「レビューの観点を増やす」道具です。深さや独立性を求めるなら、上の手段との組み合わせで補います。
まとめ
観点を切り分けたいPR、特にテスト・エラー処理・型を同時に触る変更では、/pr-review-toolkit:review-pr tests errors typesのように観点を絞って呼ぶと、報告が読みやすくなります。逆に小さな修正にallを回すのは過剰です。まずcode-reviewerだけを使い、差分の性質に応じて足していく運用から始めるのが無理のない入り方です。