SE歴20年の筆者は2026年5月、実際のコードベースから抽出した6本のバグをプライベートリポジトリに仕込み、4種のLLMレビューツールを同一条件で対決させた。検出率は Claude Code 内蔵 code-reviewer が94%、Codex CLI GPT-5.5 が77%、CodeRabbit Pro Plus が42%。同じバグを全手法が見逃す「LLMの壁」も発見した。実測データと月コストを全公開する。
コードレビューは「念のため通す」感覚でLLMに任せていたが、手法によって検出率が倍以上違うとは思っていなかった。
- 実バグ6本・4手法ベンチマーク: Claude Code 94%・Codex CLI 77%・CodeRabbit 42%
- /security-review はセキュリティ特化、偽陽性ゼロで専門領域7/7完璧
- 全手法が見逃した Bug2 ── git history を見ないと検出できないバグカテゴリが存在する
なぜLLMコードレビューのセカンドオピニオンが必要か
「通った」と「正しい」は別の話
自分でコードを書いて自分でレビューする個人開発・副業開発では、認知バイアスが避けられない。書いた本人はコードの意図を知っているため、実装のミスより「動くはずだ」という確信が先に来る。
LLMにセカンドオピニオンを求める意義はここにある。コードの意図を知らない第三者として差分を読む。ただし「LLMに投げた」だけでは安心できない。どのツールをどの条件で使うかで、検出できるバグの種類と精度が大きく変わる。
副業・個人開発でのリスク
副業でサービスを運用している場合、バグの影響は直接収益・信用に直結する。SQLインジェクション1本でユーザーデータが流出すれば、個人サービスとして終わりに近い。ロジックバグで二重投稿が発生すれば、SNS連携を使ったシステムが誤動作し続ける。
Claude Codeを使った個人サービス開発の正直な話でも触れたが、実装速度が上がるほどレビューの抜け漏れリスクも比例して増える。
ベンチマーク設計 — 実バグ6本・4手法の条件
バグの仕込み方
実際に過去に発生した、または発生しうるバグを6本選定し、「正常な修正後コード」をmainブランチ、「バグを再導入したコード」をfeatureブランチとして、正規のPR形式で差分を作成した。PR titleとdescriptionは「意図的に無害に見える説明」を付けた。
| PR | カテゴリ | 隠したバグの内容 |
|---|---|---|
| Bug1 | ロジック | XAutoPost 当日投稿チェックの削除 → 二重投稿 |
| Bug2 | null契約 | null返却で白画面（PR説明はflash of content防止と記述） |
| Bug3 | インフラ仕様 | .remotionignore の親ディレクトリ除外 → 出力ファイル全消失 |
| Bug4 | リファクタ | mailer統合の後方互換なし → smtpReady=false で無音停止 |
| Bug5 | レジリエンス | 例外を suitable=False に統一 → 判定不能時に生成スキップ |
| Bug6 | セキュリティ | requireAdmin削除＋SQLi×3＋SELECT* → 認証バイパス・情報漏洩 |
4手法の評価条件
各手法はそれぞれのPRのみを閲覧できる制限下で実施した。ground-truth（バグの正解）にアクセスできる情報は一切渡さない。
- Claude Code code-reviewer: git worktreeに閲覧範囲を限定したsubagentで実行
- CodeRabbit Pro Plus:
@coderabbitai reviewでPRに対してトリガー - Codex CLI GPT-5.5: 各worktreeでCLIインタラクティブモードで実行
- /security-review: 同じworktreeで
/security-reviewスラッシュコマンド
4手法の結果比較
全体スコア
| 手法 | 検出率 | 6PR判定 | 月コスト概算 |
|---|---|---|---|
| Claude Code code-reviewer | 94% (22.5/24点) | BLOCK×3, WARNING×2, APPROVE×1 | Max $100/月内 |
| Codex CLI GPT-5.5 | 77% (18.5/24点) | 要修正×4, 要確認×1, APPROVE×1 | 従量 ~$0.6/PR |
| CodeRabbit Pro Plus | 42% (10/24点) | Critical指摘×3, 別観点×1, スルー×2 | Pro $24/月～ |
| /security-review | 専門特化 (Bug6で7/7) | セキュリティ以外は対象外 | Max内 |
Claude Code code-reviewer の特徴
最も検出率が高く、偽陽性はゼロだった。gitignoreの「親ディレクトリ除外時に子を再includeできない」という仕様詳細（Bug3）を正確に引用して指摘できた点は他手法にはない強みだ。
Bug4ではground-truthの4観点に加え、(process.env.SMTP_PORT || '587') === '465' という文字列比較バグ（数値と文字列の型不一致）をボーナス検出した。
弱点はPR descriptionとdiffの論理整合性を重視する点。Bug2のように「PR説明が正しい場合に、それ以上の情報なしには判断できないバグ」はAPPROVEになった。
Codex CLI GPT-5.5 の特徴
ロジック・セキュリティ・リファクタの全カテゴリで安定した検出を見せた。Bug6ではmodels/user.jsを実際に読み込み、「db.prepare()が内部でキャッシュしているため、raw SQL化によるパフォーマンス改善の主張が成り立たない」と技術的矛盾を指摘した。
Claudeと同様にBug2は見逃した。Bug3は本質をカバーしたが1点未検出（3/4）。Bug5は判定不能と不適性の区別に触れたが、silent failure観点の指摘がCodeRabbitと差があった（3.5/4）。
コストは従量制。Bug1〜6の5PR相当で約$3.10の消費（Bug1を2回実行したため）。1PRあたり$0.5〜0.8程度。
CodeRabbit Pro Plus の特徴
セキュリティバグ（Bug6）では4つのCritical指摘を出した。requireAdmin削除・SQLi×3を endpoint 別に分離して指摘する細かさはむしろ他手法より詳細だった。
一方、Bug3（.remotionignore仕様）とBug2（null白画面）は完全スルー。Bug4はground-truth外の観点（attachmentのBase64バリデーション、extrasオーバーライド）を指摘した。これはground-truthでは0点扱いだが、別の品質問題を発見しており補完的な価値はある。
/security-review の特徴
Bug6（セキュリティ3重）に対して7つのHigh脆弱性を検出した。各脆弱性に exploit scenario が付属し、「GET /admin/users/search?q=%25'%20UNION%20SELECT%20...でpassword_hashを全件奪取できる」という具体的な攻撃経路まで記述する。
exploitシナリオ付きのレビューを見たのは初めてだった。pentest報告書に近い水準で、これは他手法では出てこない。
Bug1〜5（非セキュリティ）に対しては全て「脆弱性なし」と正確に判定した。偽陽性はゼロ。Bug4では添付ファイル検証の問題をconfidence 7/10で近似検出したが、しきい値8未満としてレポートから除外する設計になっている。Bug5では「fail-closed化はセキュリティ的には改善」と観察まで付けた。
全手法が見逃したバグ — Bug2が示す「LLMの壁」
Bug2のPRは以下の差分だった。
// 変更前
if (isMaintenance === null) return <MaintenanceSplash />;
// 変更後（バグ）
if (isMaintenance === null) return null;PR title は fix(preview): メンテ確認中の flash of content を防止。PR description は「null返却でコンテンツを非表示にし、確認中に本文がチラ見えする問題を修正」と記述されていた。
この差分だけを見れば「null返却でコンテンツを非表示にする」という説明とコードは論理的に一致する。実際の問題は「変更前が白ページ防止のための修正であり、変更後がそれを打ち消している」という点だが、それを知るにはgit blameと元のissueを読む必要がある。
全4手法がAPPROVEまたは「No actionable comments」を返した。LLMがPR単体で読める情報には構造的な限界がある。
検出不可能なバグのパターン:
- PR description の主張とdiffが論理的に一致している
- バグが「元のコードのコメントや設計意図の反転」である
- git history・issueを読まないと「修正方向が正しいか」判断できない
対策: commit message の品質向上・PR description に「変更前の問題の根本原因」を必ず記述する運用ルール
月コストと推奨スタック
コスト比較
3つの推奨スタック
パターンA: Claude Code Maxプランのみ（月$100）
- code-reviewer: PR全件
- /security-review: セキュリティ変更を含むPRのみ追加実行
- 検出率: 94%（非セキュリティ）＋ 専門セキュリティ
- 適合: 副業・個人開発でコストを抑えたい場合
パターンB: A + CodeRabbit Free（追加コスト$0）
- code-reviewerでの自動レビュー ＋ CodeRabbitの自動トリガー
- Bug4のような「観点の違う指摘」が追加される
- 適合: CI/CDにコードレビューを組み込みたい場合
パターンC: A + Codex CLI（月~$6追加）
- 重要PR・レビューを念入りにしたいPRのみCodexでダブルチェック
- Bug3のような「2手法が独立して同じバグを検出した」ケースで信頼度が上がる
- 適合: ロジック系バグが多い開発フェーズ
Claude Codeのコストを50〜75%削減する3層スタック実践と組み合わせると、MaxプランをClaude Code全体の開発コストとして最適化しながらレビューも回せる。
コードレビュー以外も含めた組織全体のAI導入を考えるなら、ChatGPT・Claude・Geminiの開発業務向けプラン選定ガイドで3社のエンタープライズ構造を9軸で比較している。
よくある質問
- QClaude Code code-reviewer と /security-review は何が違うのか
- A
code-reviewer は一般的なコードレビュー（ロジック・設計・品質）を行い、セキュリティ以外のバグも対象にする。/security-review はセキュリティ脆弱性（SQLi・XSS・認証バイパス等）に特化し、exploit scenario付きの報告を出す。両方を使うことで補完関係になる。今回のベンチマークでは code-reviewer が Bug1〜5 を94%カバーし、/security-review が Bug6 のセキュリティ観点を7/7検出した。
モデルの世代でも検出力は変わり、Opus 4.8は自前コードの欠陥を見逃さず指摘する確率が4.7の約4倍とされる。世代差が副業にどう効くかはOpus 4.8で何が変わったかの整理にまとめた。
- QCodeRabbit Free と Pro Plus は検出率が変わるのか
- A
今回の検証はPro Plus（14日トライアル）で実施した。Freeプランは1日10回のPRレビュー制限があり、プロファイル設定（CHILL/CHATTY/AGGRESSIVE）がPro Plusと異なる可能性がある。同一バグに対する検出精度が変わるかは未検証。Freeはまず試してから判断するのが妥当。
- QCodex CLI は OpenAI のアカウントが必要か
- A
はい。OpenAI APIキーが必要で従量制課金になる。今回の6PR相当で約$3（Bug1を2回実行含む）。GPT-5.5（デフォルトモデル）での消費量は1PR当たり$0.5〜0.8程度。OpenAIのAPIクレジットをチャージしてから使う。
- Q全手法が見逃したBug2のようなケースはどう対処するか
- A
PR descriptionに「変更前の問題の根本原因と修正の方向性」を必ず明記する運用ルールが有効。「flash of contentが起きているためnullで非表示にした」という説明では不十分で、「null返却ではなく空白のUIコンポーネントを返すべき設計だった」という意図まで書く必要がある。LLMはPR単体で読める情報しか使えない。
- Q個人開発でどのパターンから始めるべきか
- A
Claude Code MaxプランのみのパターンAから始めるのが現実的。code-reviewer をサブエージェントで呼ぶ設定をCLAUDE.mdに1行追加するだけで、PRを作るたびに自動レビューが回せる。CodeRabbit FreeはGitHubに導入するだけで追加コストゼロなので、CI/CDがある場合は併用を推奨。バイブコーディングの実践記のような実装速度優先の開発ほど、こういったレビュー網が効く。
まとめ
実バグ6本・4手法のベンチマークで明らかになったことを3点に絞る。
- Claude Code 内蔵 code-reviewer が検出率94%で最強。gitignore仕様など深い技術知識が必要な仕様系バグ（Bug3）を偽陽性ゼロで検出できる。Maxプランなら追加コストなし。
- /security-review はセキュリティ変更のある PRに必ず追加実行する価値がある。exploit scenarioと7分離された脆弱性報告はpentest相当の精度で、code-reviewerの検出内容と補完関係になる。
- 「PR description + diff の整合性チェック」だけでは検出できないバグがある。Bug2のように元の設計意図の反転であるケースは、全LLMツールで見逃す構造的な限界がある。ツールへの過信ではなく、PRの書き方の改善（根本原因の明記）で対処する。
月$100のClaudeMaxプランに code-reviewer と /security-review を組み込めば、追加費用ゼロで実測94%＋セキュリティ専門レビューが完結する。外部LLM（Codex）は重要なPRのみに絞って使うのがコスパの良い選択肢だ。
