Claude Codeのコードレビュー精度を上げる敵対的レビュアー活用術

先に結論: 反証専門の役割に切り替えた敵対的レビュアーと、セッション終了時の「壊れうるものは?」「反対意見を書け」という2つの質問を使うと、Claude Codeの甘くなりがちな自己レビューを補えます。

Claude Codeにコードを書かせたあと、そのままClaude Codeにレビューさせて「問題なさそうです」で終わっていないでしょうか。書いた本人にチェックさせる限り、レビューはどうしても甘くなりがちです。

この記事では、レビュアーの役割を「反証専門」に切り替える敵対的レビュアーの使い方と、セッション終了時に投げる2つの質問を紹介します(2026年8月時点)。

この記事の要点

• 同じモデルに「良い点も探して」と頼むと採点が甘くなるため、反証だけを役割にした敵対的レビュアーを使うと欠陥検出の精度が上がります。
• 実践では別セッションかカスタムサブエージェントに「問題点を最低3つ挙げ、反証できなければ承認しない」という指示を渡します。
• Claude Codeの組み込みコマンド/code-review(エイリアス/review)はeffort levelを指定でき、high以上で詳細なレビューができます(2026年8月時点、公式ドキュメント)。
• セッション終了時に「この実装で壊れうるものは?」「レビュアーとして自分のPRに反対意見を書け」の2問を投げると、実装者視点では出てこない指摘が得られます。
• 敵対的レビュアーも万能ではなく、指摘を鵜呑みにせず最終判断は人間が行うことが前提です。

前提: なぜ自己レビューは甘くなるのか

Claude Codeは、自分が書いたコードを同じ会話の中でレビューすると、無意識に「うまく書けた」という前提を引きずります。実装時の文脈を覚えているぶん、想定していない使われ方には気づきにくくなります。これは、書いた本人ほど前提自体を疑いにくいという人間のセルフレビューと同じ現象です。

敵対的レビュアーとは: 役割を反転させる

敵対的レビュアー(adversarial reviewer)とは、「このコードに欠陥がないか探して」ではなく、「このコードを反証しろ、欠陥を見つけられなければ承認するな」と役割そのものを反転させる手法です。

探す対象を「良い点」から「反証材料」に変えるだけで、Claudeは前提を疑う側に回ります。この手法はReddit r/ClaudeAIで872upと大きな反響を集めました(2026年8月調査時点)。

同じセッション内で役割だけ変えても効果は限定的です。文脈を共有したままだと前提を引きずりやすいため、会話そのものを分離するほうが効果的です。

実践パターン: 別セッション/サブエージェントに反証させる

最も手軽なのは、実装が終わったら新しいセッションを開き、diffだけを渡して反証させる方法です。

このdiffをレビューしてください。ただし役割は反証担当です。
「問題なさそうです」は禁止。最低3つの問題点を具体的に指摘し、
反証できない場合のみ承認してください。

繰り返し使うなら.claude/agents/にカスタムサブエージェントとして定義すると呼び出しが楽です。「Claude Codeサブエージェント活用術」のcode-reviewerサブエージェントを、次のように反証寄りに書き換えるだけで敵対的レビュアーになります。

---
name: adversarial-reviewer
description: 実装の欠陥を反証する専門レビュアー。「良い点」ではなく問題点を探す。
tools: Read, Glob, Grep
model: sonnet
---

あなたは反証専門のレビュアーです。賛成理由ではなく、
壊れる条件・見落としを最低3つ探してください。
反証できなければ承認してください。

サブエージェントは独立したコンテキストウィンドウで動くため、メインの会話の前提を引き継がず、まっさらな視点でコードを見られます(公式ドキュメント、2026年8月時点)。

/code-reviewとの併用

Claude Codeには/code-reviewという組み込みコマンド(エイリアス/review)があり、現在のdiffやPR番号を指定してレビューできます。effort levelはlow〜maxの5段階があり、ultraを指定すると多エージェントによるクラウドレビューも動きます(2026年8月時点、公式ドキュメントで確認)。

ただし/code-review単体は「バグとクリーンアップ機会を洗い出す」ための機能で、反証を強制する役割設定ではありません。まず/code-review highで定型チェックを終え、そのあとに敵対的レビュアーへ「これでも見落としがあるか反証して」と渡す2段構えにすると、機械的なチェックと役割ベースの深掘りを両方カバーできます。

セッション終了時の2質問ルーティン

実装が一段落してセッションを終える前に、次の2つの質問を投げる運用も有効です。

1つ目は「この実装で壊れうるものは?」です。境界値や想定外の入力にも目を向けさせられます。2つ目は「レビュアーとして、自分のPRに反対意見を書いてください」です。却下する側の視点を明示的に指定することで、実装者としての甘さを相殺できます。

①この実装で壊れうるものは何ですか?
②レビュアーとして、自分が出したこのPRに反対意見を書いてください。

この2問はコミットやPR作成の直前に挟むだけでよく、/code-reviewやサブエージェントを使うほどではない小さな変更にも気軽に取り入れられます。

過信しない: 敵対的レビューも万能ではない

敵対的レビュアーも、分類器やレビューコマンドと同じく万能ではありません。反証を役割にしても、Claude自身が知らない仕様やプロジェクト固有の暗黙知には気づけません。

「最低3つ指摘して」と指示すると、些末な指摘を数合わせで挙げることもあります。指摘は人間が読み、的外れなものは却下する前提で使ってください。

よくある質問

/code-reviewコマンドだけでは不十分ですか?

/code-reviewは正確性のバグとクリーンアップ機会を洗い出す定型チェックとして優秀ですが、役割としては「反証専門」ではありません。highなどで定型チェックをかけたあと、敵対的レビュアーへさらに反証させる2段構えがおすすめです。

敵対的レビュアーは毎回サブエージェントを作る必要がありますか?

必須ではありません。1回限りなら新しいセッションでプロンプトに役割を書くだけで十分です。繰り返し使うなら.claude/agents/にカスタム定義しておくと呼び出しが楽になります。

2つの質問はどのタイミングで使えばいいですか?

実装が一段落し、コミットやPRを作成する直前が目安です。小さな変更でも、この2問を投げるだけで見落としに気づけることがあります。

まとめ

Claude Codeのセルフレビューは、同じ文脈を共有したままでは甘くなりがちです。役割を「反証専門」に切り替えた敵対的レビュアーと、セッション終了時の2質問ルーティンを組み合わせることで、見落としを減らせます。

ただし指摘を鵜呑みにせず、最終判断は人間が行うことが前提です。

Claude Code全体の使い方は「Claude Codeの使い方完全ガイド」、サブエージェントの作り方は「Claude Codeサブエージェント活用術」、エラーの伝え方は「Claude Codeへのエラーの伝え方」、誤削除を防ぐ考え方は「Claude Code誤削除を防ぐ安全運用ガイド」を参考にしてください。

同じ発想はGitHub Copilotのコードレビューでも活かせます。PRへの自動レビューリクエストの使い方は「GitHub Copilotコードレビューの使い方」で解説しています。