Claude Codeのcode-reviewスキルで、PRを安全性・性能・正確性から見る

engineeringプラグインのcode-reviewスキルは、PRのURLやdiffを渡すと、安全性・性能・正確性・保守性の4つの観点で変更を点検し、決まった表の形で結果を返すスキルです。ツールを何もつながなくても動き、GitHubなどを接続するとPRの差分取得まで自動になります。

ここでは、導入から呼び出し名の落とし穴、渡し方の工夫、出力の読み方、コネクタ有無の違いを順に扱います。同名の別物が複数あるので、使い分けの表も置きます。

code-reviewスキルは何を見るスキルか

スキル定義の説明文は「セキュリティ・性能・正確性のためにコード変更をレビューする」です。呼び出しのきっかけとして、PR URLやdiffを渡す場合のほか、「マージ前にレビューして」「このコードは安全か」といった言い回し、N+1クエリ・インジェクションの危険・抜けているエッジケース・エラー処理の穴の確認が挙げられています。

見る観点は4グループに分かれています。

定義の図解には「OWASP top 10」という語も出てきますが、チェックリストとして項目が展開されているわけではありません。OWASPの一覧と1項目ずつ突き合わせたい場合は、依頼文で明示する必要があります。

engineeringプラグインを入れる

導入はマーケットプレイスの登録とプラグインの追加の2行です。プラグインのバージョンは1.2.0で、作者はAnthropicと記載されています。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-plugins

READMEによれば、このプラグインは主にCowork向けに作られ、Claude Codeでも動きます。セッション内で /plugin install を使うと、すぐには入らず /plugin パネルの詳細画面が開き、スコープを選んでから確定する流れです。

呼び出し名は /engineering:code-review

READMEのコマンド表には /review が載っており、使用例も /review https://github.com/org/repo/pull/123 です。ところが、リポジトリのengineeringフォルダにあるのは skills だけで、commands フォルダがありません。/review という名のコマンド定義は同梱されていないことになります。

Claude Codeのドキュメントでは、プラグインのスキルは /プラグイン名:スキル名 の名前空間付きで呼ばれると説明されています。したがって実際の入力は次の形です。

/engineering:code-review https://github.com/acme/shop/pull/482

素の /code-review はClaude Code本体の組み込みコマンドを指す別物です。プラグイン側を使いたいときは、名前空間付きで打ちます。

PR URL・diff・ファイルを渡す

スキル定義の引数ヒントは <PR URL, diff, or file path> で、使い方の節には「指定がなければ何をレビューするか尋ねる」とあります。渡し方は3通りです。

• PRのURLを渡す。差分の取得はコネクタ次第（後の節）
• git diff の出力を貼る。ツールなしで確実に動く
• ファイルパスを渡す。リポジトリ内のファイルを読ませる

手元のブランチ差分を渡すなら、貼り付ける前に絞っておくと精度が安定します。

git diff main...HEAD -- src/orders > /tmp/orders.diff

出力した差分ファイルのパスを、/engineering:code-review /tmp/orders.diff のように渡せます。

引数の取り込まれ方に癖がある

スキル本文には「レビュー対象: @$1」という行があります。Claude Codeのドキュメントでは、$N は0始まりの位置引数で、$0 が最初、$1 が2番目です。ドキュメントの規則どおりなら、引数をひとつだけ渡したときに $1 に当たるものはなく、@$1 は文字のまま残ります。

ただし同じドキュメントに、どのプレースホルダーも引数を受け取らなかったときは、末尾に ARGUMENTS: <入力> が自動で足されるとあります。URLやパスは、この経路でClaudeに届きます。実運用では問題になりにくい仕様ですが、「渡したのに無視された」と感じたら、依頼文にもう一度対象を書き添えると確実です。

文脈を一緒に渡すと焦点が絞れる

スキルのTipsは3つの工夫を挙げています。文脈を添える（「これはホットパス」「個人情報を扱う」）、懸念を指定する（「セキュリティ重視で」）、テストも含めて渡す（カバレッジと品質も見る）の3つです。次のような依頼が一例です。

/engineering:code-review https://github.com/acme/shop/pull/482
注文確定APIの変更。1日30万リクエストが通るホットパス。
支払い情報を扱うので、認可漏れとログへの出力を重点的に。
性能はN+1とインデックスだけ見てくれればいい。

観点を絞る一文を入れないと、4グループを均等に浅く見る形になりがちです。

出力の読み方

スキル定義には、返す形式のテンプレートが決まっています。実際の出力そのものではなく、定義側の雛形です。

重大度の列があるのはCritical Issuesの表だけです。Suggestionsは重大度ではなくカテゴリで分類されるため、「直さないと危ない」と「直すとよい」が表の種類で分かれる構造になっています。

Verdictが「Approve」でも、Suggestionsが空とは限りません。マージ判断はVerdictだけでなく、Critical Issuesの件数で見るほうが漏れません。

コネクタをつなぐと何が変わるか

定義の図は、ツールなしでも動く部分と、接続で強化される部分を分けています。

プラグインのコネクタ一覧では、ソース管理の「含まれるサーバー」はGitHub、トラッカーはLinear・Asana・Atlassian、ナレッジベースはNotionです。同梱の .mcp.json にはこれらのMCPサーバーのURLが入っています。GitLabやBitbucketなどは「その他の選択肢」の扱いで、自分でMCPサーバーを追加します。

ここで押さえたい点が2つあります。

• 同梱されているのは接続先の設定で、認証はこちらで通す必要がある。未認証のままだと、PR URLを渡しても差分は取得されない
• GitHubを接続しなくても、gh コマンドを使えるClaude Codeなら、依頼文で「gh pr diff で差分を取ってからレビューして」と書けば代替できる

ただし後者は、スキルの機能ではなくClaude Codeの通常の動作に頼る方法です。

自社の基準に寄せる

スキルは汎用の観点で書かれているので、チーム固有の基準はCLAUDE.mdに書いておくと反映されやすくなります。ナレッジベースを接続しない構成での代替策です。

## コードレビューの基準(code-reviewスキルで必ず確認)
- 外部入力を使うSQLはプレースホルダ必須。文字列連結は Critical 扱い
- ループ内でのDBアクセスは N+1 として Suggestions に挙げる
- 金額計算は Decimal を使う。float は Critical
- 公開APIのレスポンス変更は、フィールド削除なら Critical
- ログに個人情報(メール・氏名・カード番号)を出していないか必ず見る

「Criticalに入れる条件」を書いておくと、重大度の振り分けが安定します。数字や型の指定は一例なので、自分のスタックに置き換えてください。

常駐コストと、勝手に呼ばれる可能性

このスキルのフロントマターには、自動呼び出しを止める設定（disable-model-invocation）がありません。ドキュメントの表によれば、既定では説明文が常に文脈に載り、Claudeが会話から判断して読み込めます。スキルの説明に「マージ前にレビューして」という言い回しが入っているため、そう頼んだ会話では自動で呼ばれることがあります。

止めたい場合の手段には注意が要ります。ドキュメントは、skillOverrides はプラグインのスキルには効かず、プラグインのスキルは /plugin から管理すると明記しています。プラグインを無効にする以外に、スキル単位で止める設定は用意されていません。

似た3つのレビューとの使い分け

「code-review」の名前は3か所で使われています。

PRに自動でコメントを残したいならcode-reviewプラグイン、修正まで一気に進めたいなら組み込み版です。effortの指定は/code-reviewのeffortに、実行経路の全体像は4つの実行経路の使い分けにあります。ブランチ全体の脆弱性だけを見たいならsecurity-reviewコマンドが専用です。

engineeringプラグインのスキルは、その場で会話しながら「ここは意図的」「この観点だけ深掘りして」と追い質問できるのが強みです。デプロイ前の確認はdeploy-checklist、負債の洗い出しはtech-debtスキルが同じプラグインに入っています。

つまずきやすい点

• /review が見つからない: READMEの記載と実際の同梱物が違います。/engineering:code-review で呼びます。
• PR URLを渡したのに差分が見えていない: GitHubのMCP認証が通っていない可能性があります。差分を貼るか、gh pr diff の実行を頼みます。
• 指摘が浅い: 観点を絞る一文と、対象の性質（ホットパス・個人情報）を添えます。
• 勝手に呼ばれて文脈を食う: スキル単位では止められません。使わない期間はプラグインを無効にします。

まとめ

code-reviewスキルは、PRのレビュー結果を「重大な指摘」「提案」「良い点」「判定」の4部構成で受け取るための型です。ツールなしでも使えますが、実力が出るのは、観点を絞る一文と自社基準のCLAUDE.mdを添えたときです。PRへの自動コメントが目的なら別のプラグインのほうが近く、このスキルは「手元で追い質問しながら詰めるレビュー」に向きます。まずは今日のPRで、懸念をひとつ指定して1回回してみてください。