Claude + Gemini 2 段レビュー文化 — LLM レビューを開発フローに組み込む実例
TL;DR
- 実装した LLM と同じ LLM にレビューさせると、前提の共有が強すぎて盲点を見逃しやすい
- Claude を実装、Gemini を第三者レビューに分けると、設計・性能・例外処理の見落としを別角度から拾える
- レビュー発火条件を CLAUDE.md に書き、結果を SurrealDB
review_logに残すと運用が属人化しにくい - LLM レビューは人間レビューの代替ではなく、Issue 起票前・重要設計判断・同一エラー 3 回目の検査レイヤーとして使う
なお、Tipsとして、「ゼロコンテキストレビュー」という依頼方法で同AIサービスでも同様程度のことができる。いわゆる担当外（視座違い）からのレビューだ。
概要
対象読者は、AI ペアプログラミングの品質保証を強化したい開発者、または LLM レビューを場当たり的な相談から再現性のあるワークフローへ移したいチームです。この記事を読むと、実装モデルとレビューモデルを分離する理由と、その運用を仕組み化して属人化させない方法がわかります。
LLM を使った実装フローに、別モデルによるレビューを組み込んだ運用事例を紹介します。Claude Code で実装し、Gemini CLI で第三者レビューを取り、結果を組織記憶として残すまでの流れを、チーム文化として定着させる観点で整理します。
目次
- 状況 / 課題
- 候補 / トレードオフ
- 採用案と理由
- 実装抜粋
- 運用上の学び
- 振り返り
- 適用限界
- まとめ
- 参考
状況 / 課題
Claude Code (Opus) で実装したコードを、そのまま同じ Claude にレビューさせると「自分が書いたものを自分で読む」構造になる。確証バイアスが働き、論理的なミスや設計上の盲点を見逃しやすい。LGTM を自分で押して自分で安心する、というのは人間の自己レビューでもよくある光景だが、AI がやると規模も速度も上がる分だけ気づきにくい。
"An LLM cannot objectively review its own output because the training distribution, context window, and confirmation bias all point the same direction."
— I Built an AI Code Reviewer That Uses Any LLM to Review Claude Code Output — DEV Community
この課題を解決するために Claude (実装) + Gemini (第三者レビュー) の 2 段構成を導入した。
| 項目 | 内容 |
|---|---|
| ワークロード特性 | ソロ開発 + AI ペアプログラミング。1 日に複数 Issue をクローズする高頻度リリース |
| 発火条件 | Issue 起票前・重要設計判断時・同一エラー 3 回目以降を候補にする |
| コスト制約 | 利用中の契約・quota・入力tokenを計測し、上限超過時のfallbackを用意する |
| 期限 | 常時運用。セッション起動時に CLAUDE.md を読んで自動発動 |
候補 / トレードオフ
候補 A: 人間によるコードレビューのみ
- 特徴: 従来型。人間が diff を読んでレビューコメントを付ける
- 長所: 文脈・ビジネス要件を深く理解したレビューが可能。責任の所在が明確
- 短所: ソロ開発では自己レビューになり限界がある。レビューに時間がかかり高頻度リリースのボトルネックになる
- 見積コスト: 人件費のみ。スケールしない
候補 B: Claude Code 単独レビュー
- 特徴: 実装も Claude、レビューも Claude。同一セッション内でセルフレビュー
- 長所: 即時フィードバック。コンテキストが完全に共有されているため精度が高い局面もある
- 短所: 確証バイアスが抜けない。Claude が「正しい」と判断した実装をそのまま「問題なし」と返す傾向
- 見積コスト: Claude API コストのみ
候補 C: Claude 実装 + Gemini deep review の 2 段構成
- 特徴: 実装者 (Claude Opus) とレビュアー (Gemini Pro) を分離。異なるモデル・異なる学習分布で互いの盲点を補完
- 長所: 別のmodel familyとfresh contextで、実装時の前提を問い直せる
- 短所: latencyと利用量が増え、同じ誤りへ収束する可能性もある。渡していない文脈は評価できない
- 見積コスト: 契約と時期で変わるため固定値を置かず、reviewごとの時間・token・失敗率を記録する
採用案と理由
採用: 候補 C
実装時の前提を別contextから問い直すため、「異なるmodel familyがコードを読む」構成を選んだ。ただし、これだけで確証バイアスを排除できるとはみなさない。
理由:
- 視点の分離: ClaudeとGeminiは別model familyであり、fresh contextを渡すことで実装会話の前提を引き継がずに読ませられる
- 評価可能性: review結果を構造化して残せば、人間確認後のtrue/false positiveを集計できる
- 発火条件の共有: CLAUDE.mdなどに条件を定義し、重要な変更でreviewを忘れにくくする。完全自動を保証するものではない
LLM-as-a-Judge の研究でも同様の知見が蓄積されている。
"ensuring the reliability of LLM-as-a-Judge systems remains a significant challenge"
この研究はLLM judgeの信頼性に課題があることを示す根拠であり、本構成の有効性を直接証明するものではない。だからこそ、人間のverdictを残して測る。
実装抜粋
# gemini-review.sh の呼び出しパターン
echo "コードや設計内容" | ~/.claude/hooks/gemini-review.sh review # 通常レビュー (flash-lite)
echo "コードや設計内容" | ~/.claude/hooks/gemini-review.sh review --pro # deep レビュー (pro)
echo "エラー履歴" | ~/.claude/hooks/gemini-review.sh error # セカンドオピニオン
echo "設計内容" | ~/.claude/hooks/gemini-review.sh deep # 徹底レビュー (pro 強制)
~/.claude/hooks/gemini-review.sh issue "タイトル" "本文" # Issue 起票前レビュー
# CLAUDE.md への自動発動ルール記述例
## Gemini レビュー 自動発動条件
1. **Issue 起票時**: `gh issue create` 前に `gemini-review.sh issue` でレビューし、結果を提示してから起票
2. **3 回目以降の同一エラー**: 同じエラーに 3 回遭遇したら `gemini-review.sh error` でセカンドオピニオン取得
3. **重要な設計判断**: アーキテクチャ変更・大規模リファクタ時に `gemini-review.sh deep`
# review_log への SurrealDB 記録
surreal-query.sh --review-create \
--mode "deep" \
--model "gemini-3.1-pro-preview" \
--target "src/feature.rs" \
--tags "code-review,gemini,rust,2026-05" \
--content-file /tmp/review-result.md
Gemini CLI は OSS として公開されており、ターミナルから直接 Gemini モデルを呼び出せる。
"An open-source AI agent that brings the power of Gemini directly into your terminal."
利用枠とmodel名は変更されるため、Google公式の現行quotaを導入時に確認する。記事中の固定値を運用設計へ転記しない。
運用上の学び
Gemini が Claude と異なる指摘を出す可能性があるケース
- 実装側が当然としたpreconditionを、fresh contextのreviewerが明文化する
- query loopをN+1候補として挙げ、実行計画やquery count testを要求する
ただし、これは効果測定済みの改善率ではなく、review観点の例である。実際の有効性は次の台帳で測る。
| 項目 | 記録値 |
|---|---|
| finding | 指摘内容と対象行 |
| verdict | 人間がtrue positive / false positive / unclearを判定 |
| severity | merge block / follow-up / no action |
| cost | 経過時間、入力・出力token、失敗・retry |
| escaped defect | merge後に発覚した見逃し |
最低でも一定期間、単独reviewと二段reviewを同じseverity基準で比較しない限り、「品質が上がった」とは断定しない。
review_log の活用
SurrealDBのreview_logには指摘だけでなく、人間のverdictと対応結果を残す。指摘件数だけを成果にするとfalse positiveを増やす誘因になるため、採用率と見逃しも併記する。
自動発動条件の調整
当初はすべてのコード変更後に deep レビューを走らせたが、レイテンシとコストの両面でオーバーヘッドが大きかった。現在は「Issue 起票前」「3 回目以降の同一エラー」「重要な設計判断」の 3 条件に絞っている。
振り返り (ディレクター視点)
- 判断時に重視した軸: 確証バイアスの排除を最優先にした。コスト・レイテンシは二次要件
- どこを譲歩したか: Gemini が参照できるコンテキストは渡したプロンプト内に限定される。コードベース全体を渡すとトークン量が膨れるため、レビュー対象を diff 単位に絞ることにした
- もう一度判断するなら: hookify ルールによる機械的サポートをもっと早期に導入すればよかった。自動発動ルールを「Claude が覚えている」前提で運用すると、長い会話の中でルールを忘れるケースがあった。健気にレビュー条件を守ろうとしていたのに、会話が長引くと本人（Claude）が一番先に忘れる、というオチである
適用限界
モデルの挙動、価格、コンテキスト長、データ取り扱い方針は更新される。二段階レビューは視点を増やす仕組みであって、正しさの保証ではない。機密情報の送信可否を組織方針で確認し、型検査、テスト、静的解析、責任を持つ人間のレビューを最終ゲートとして残してほしい。
まとめ
- Claude と Gemini は異なるモデルであるため、片方の盲点をもう片方が補完できる構造的なメリットがある
- 発動条件 (Issue 起票前・同一エラー 3 回目・重要設計) を CLAUDE.md に明記することで自動化できる
- Gemini のレビュー結果は「参考意見」であり、最終判断は Claude または人間が行う
-
review_logテーブルへの記録により、レビュー履歴を検索可能な組織知として蓄積できる - hookify ルールで機械的に発動を想起させることで、長い会話でもルールを維持できる
実装者とレビュアーを別モデルに分けるという発想自体は単純だが、効果を出すには「いつ呼ぶか」を明文化し、結果を検索可能な形で残す仕組みが不可欠だった。身も蓋もない言い方をすれば、モデルを分けただけでは何も解決しない。呼び出しルールを人間の記憶に頼らない形にして初めて効いてくる。ルールを人間の記憶や Claude のセッション内記憶に依存させず、CLAUDE.md と SurrealDB のような外部化された仕組みに載せることが、レビュー文化を定着させる鍵になる。
参考
公式 1 次資料
- google-gemini/gemini-cli — GitHub — Gemini CLI の公式 OSS リポジトリ。README にモデル・無料枠・インストール手順を記載
- Gemini CLI | Google Cloud Documentation — Google Cloud 公式の Gemini CLI ドキュメント
- Claude Code | Anthropic — Claude Code 公式製品ページ。Opus/Sonnet/Haiku の役割説明を含む
関連 issue
- A Survey on LLM-as-a-Judge — arXiv:2411.15594 — LLM を評価者として使う手法のサーベイ論文。信頼性・バイアス軽減戦略を体系的にまとめている
- From Code to Courtroom: LLMs as the New Software Judges — arXiv:2510.24367 — ソフトウェアエンジニアリングにおける LLM ジャッジの適用研究
補足解説
- I Built an AI Code Reviewer That Uses Any LLM to Review Claude Code Output — DEV Community — 外部 LLM を使って Claude のコード出力をレビューする OSS ツール cc-review の解説
- AI Code Reviewer to Enforce Code Conventions using Gemini and MCP Server — Medium — Gemini と MCP サーバーを組み合わせた AI コードレビューの実装例