user-level AI 環境でつくる複合QA — Claude / Codex / Gemini 相互レビュー運用
- AI コーディング環境は「どのモデルが賢いか」より「どのモデルに何を監査させるか」で品質が変わる
- Claude / Codex / Gemini を user-level で常設し、実装者・レビュアー・調査役を分けると確証バイアスを減らせる
- キモは、どのAIが統率者になっても同じ規約・ログ・レビュー手順を使って活躍できる自己整備済み環境を作ること
- レビュー発火条件を
CLAUDE.md/AGENTS.md/settings.jsonに書き、ログを残すと個人技から運用に変わる - 2026-05-27 時点の体感では、Codex が統率力・読解力・ファイル横断理解・成果物・速度の総合力で最も強い
- Gemini は大コンテキストの第三者レビュー、Claude Code は複雑なファイル関係の把握と Agents 統率、Codex は主実装・diff review・統合判断に向く
- 複合QAは人間レビューの代替ではなく、人間が見る前に論点を圧縮するための前段フィルターとして使う（コンテキストを持ちすぎている状況を、コンテキストを持たずにレビューする差を利用する）
概要
Claude Code、OpenAI Codex、Gemini CLI のようなエージェント型AIが開発環境に入ると、AI が実装し、AI がテストし、AI がレビューする流れを組めるようになる。ただし、同じモデルに実装とレビューを閉じると、自分の前提を自分で肯定する構造になりやすい。
この記事では、user-level のAI開発環境に Claude / Codex / Gemini を併設し、複合的なQA・レビュー環境として使う運用を整理する。対象は、ソロ開発や少人数チームでAIエージェントを常用していて、「速くなったが、本当に品質が上がっているのか」を検証したい開発者だ。
結論を先に言うと、重要なのは「今日一番強いAIを当てる」ことではない。Claude、Codex、Gemini のどれが統率者になっても、同じ規約、同じ外部メモリ、同じレビュー発火条件、同じ安全境界を使って仕事を進められる環境を作ることだ。AIの強弱は日単位で変わる。だから統率者を固定するより、統率者が入れ替わっても破綻しない作業環境を user-level に整備する。
目次
- 状況 / 課題
- 候補 / トレードオフ
- 採用案と理由
- 実装抜粋
- 運用上の学び
- 振り返り
- まとめ
- 参考
状況 / 課題
AIエージェントを導入すると、実装速度はすぐに上がる。Claude Code に仕様を渡すとコードを書き、Codex に差分を見せるとレビューし、Gemini に聞くと別角度の懸念を返してくれる。
問題は、それらを場当たり的に呼ぶだけでは品質保証の仕組みにならないことだ。
たとえば、実装したAIと同じAIに「レビューして」と頼むと、コンテキスト共有が強すぎる。なぜその設計にしたかを知っているため、前提の妥当性ではなく実装の整合性だけを見てしまう。これは人間の自己レビューと同じで、速度は出るが盲点は残る。
Claude Code 公式は、Claude Code を次のように説明している。
"Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands"
Codex も同様に、ローカルレビューやCLI上のワークフローに組み込める。
"Get your code reviewed by a separate Codex agent before you commit or push"
Gemini CLI は、ターミナル上で Gemini を使えるエージェントとして位置づけられている。
"Gemini CLI is an open-source AI agent"
つまり、各ツールは単独でも強い。しかし実務で効くのは、単体性能ではなく 役割分担と相互監査の設計 だった。
| 項目 | 内容 |
|---|---|
| ワークロード特性 | AI エージェントによる実装、調査、レビュー、Issue 起票前確認が日常的に発生 |
| SLA / 可用性 | 人間レビュー前に、重大な設計漏れ・回帰・セキュリティ懸念を拾いたい |
| コスト制約 | 個人または少人数チームで運用できる範囲。高価な deep review は発火条件を絞る |
| 期限 | 常時運用。セッション開始時に user-level 規約を読み、必要時に自動発火 |
2026-05-27 時点の各AIの特色
ここからは、公式機能の説明ではなく、2026-05-27 時点で私の user-level 開発環境に常設しているAIを使い比べた運用上の印象だ。モデルやサービスは頻繁に変わるため、絶対評価ではなく「今この環境では、どの役を任せると事故が少ないか」という実務メモとして読んでほしい。
ただし、この表は序列表ではない。2026-05-27 時点では Codex を統率者に置くのが最も安定しているが、Claude Code が統率者になる日も、Gemini が大きな文脈を握ってレビュー主導する日もある。その入れ替わりを許容できるように、規約・記録・レビュー手順をAIの外側に置く。
| AI / モデル系統 | 強いところ | 弱いところ | 任せやすい役割 |
|---|---|---|---|
| Gemini Pro 系 | 大きなコンテキストを渡せる。長いdiff、仕様メモ、ログ、設計資料をまとめて読ませやすい | 複雑なファイル間関係や、暗黙の依存関係を正確に追うのは苦手な場面がある | 第三者レビュー、長文資料の要約、設計セカンドオピニオン、同一エラーの別角度分析 |
| Claude Code Opus / Sonnet 系 | 複雑なファイル関係を読み、どのファイルをどう動かすべきかを理解しやすい。Agents の統率やタスク分解が強い | 読解力と成果物の安定度に波がある。2026-05-27 現在、私の環境では日本時間の夜に品質が崩れやすく、作るより問題を増やす傾向が目立つ | 複雑な既存実装の把握、Agents への委譲、段取り作成、局所実装、レビュー結果の統合 |
| Codex 系 | 2026-05-27 時点では総合的に最強。統率力、読解力、ファイル横断理解、成果物、速度のバランスがよい | 強すぎる分、任せすぎると人間側のレビュー観点が薄くなる。安全境界と承認ルールは必要 | 主実装、diff review、ファイル横断修正、テスト追加、最終統合前の品質確認 |
Gemini については、Google 公式ドキュメントでも長大なコンテキストを主要な特徴としている。
"Many Gemini models come with large context windows of 1 million or more tokens."
この「大きく渡せる」性質は、レビュー環境ではかなり効く。コード単体ではなく、設計メモ、テストログ、エラー履歴、過去のレビューを一緒に渡せるからだ。一方で、ファイルAの微妙な変更がファイルBの初期化順序を壊す、といった関係性の追跡は、Claude Code や Codex の方が安定する場面がある。
Claude Code は、公式にも subagent によるコンテキスト分離と委譲を前提にしている。
"Each subagent runs in its own context window"
このため、複雑なリポジトリを探索役、実装役、レビュー役に分ける運用と相性がよい。特に「この変更はどのファイル群を触るべきか」を考える段階では強い。ただし、同じ Claude Code でも時間帯やセッション状態によって出力品質の揺れを感じる。日本時間の夜に品質が落ちるという体感は、公式仕様ではなく私の運用ログ上の観察だが、実務では重要な制約として扱っている。夜は大規模実装を任せず、レビュー・調査・小さな修正に寄せる。
Codex は、2026-05-27 時点の私の環境では最も信頼している。 OpenAI も Codex を「agentic software engineering」向けに最適化されたものとして説明している。
"trained on complex, real-world engineering tasks"
実際の運用でも、ファイル横断の読み取り、変更方針の整理、テスト追加、diff review までの流れが速い。Claude Code が「関係性をつかむ」のに強いとすると、Codex は「つかんだ関係性を、破綻しにくい成果物へ落とす」のが強い。現時点では、主実装を Codex、重い別視点レビューを Gemini、複雑なタスク分解や Agents 統率を Claude Code という配置が一番安定している。
候補 / トレードオフ
候補 A: Claude 単独で実装からレビューまで行う
- 特徴: Claude Code を中心に、実装・テスト・レビュー・最終応答までを同じAIに任せる
- 長所: コンテキストが分断されない。実装意図を把握したままレビューできる。操作が少ない
- 短所: 実装時の前提をレビュー時にも引きずる。設計判断の妥当性より、実装整合性の確認に寄りやすい
- 見積コスト: 低〜中。追加ツールの認証やログ運用は不要
候補 B: Claude + Gemini の二段レビュー
- 特徴: Claude が実装し、Gemini が第三者レビューを行う
- 長所: 異なるモデルがコールドリードするため、確証バイアスを減らせる。設計・例外処理・性能懸念の指摘が出やすい
- 短所: Gemini に渡すコンテキスト設計が必要。コードベース全体ではなく、diff や設計メモをどう切り出すかが品質を左右する
- 見積コスト: 中。deep review は発火条件を絞る必要がある
候補 C: Claude + Codex + Gemini の複合QA
- 特徴: Claude を実装・統合判断、Codex を差分レビュー・安全境界、Gemini を独立レビュー・セカンドオピニオンに分ける
- 長所: モデルだけでなく、ツールの得意領域も分けられる。CLI、GitHub、ローカルレビュー、調査を組み合わせやすい
- 短所: user-level 規約、発火条件、ログ保存先を整えないと運用が散らかる。レビュー結果の衝突を裁く最終判断者が必要
- 見積コスト: 中〜高。常時 deep review ではなく、重要局面だけ多重化する設計が必要
採用案と理由
採用: 候補 C
理由は、AIを「一人の万能開発者」として扱うより、「複数の専門ロール（コンテキスト量の差）」として扱った方がレビュー品質を設計しやすかったからだ。
もう一つ重要なのは、統率者を固定しないことだ。今日の主役が Codex でも、明日の主役が Claude Code でも、あるいは巨大コンテキストを握った Gemini でもよい。大事なのは、どのAIが先頭に立っても同じ作業原則に戻れることだ。
そのため、採用案は「Codex を中心にする」ではなく、Claude / Codex / Gemini のいずれも統率者になれる user-level 環境を作る ことだ。現時点では Codex を主実装に置くことが多いが、それは環境上のデフォルトであり、固定された組織図ではない。
1. Claude Code は複雑な関係性と Agents 統率に強い
Claude Code はコードベースを読み、ファイル編集やコマンド実行まで行う実装者として扱いやすい。CLAUDE.md、skills、hooks のような運用規約を読み込ませやすく、プロジェクト固有のルールを実装フローに載せられる。
特に強いのは、複雑なファイル関係を読んで「どの探索をどの Agent に任せるか」を切る場面だ。実装そのものより、作業を分解し、複数のサブエージェントから返ってきた情報を統合する役が合っている。
ただし、Claude が書いたコードを Claude だけで最終承認すると、自己レビューになる。また、2026-05-27 時点の私の環境では時間帯による出力品質の揺れが大きい。そこで Claude Code は「複雑な関係性の把握 + Agents 統率」とし、重要なレビューや最終確認は別モデルにも逃がす。
2. Codex は主実装と差分レビューの中心に向いている
Codex はCLI、IDE、クラウド、GitHub など複数の面で使える。特にレビュー対象が diff として明確な場合、「この変更は意図どおりか」「テストは足りているか」を見るレビュアーとして使いやすい。
それに加えて、2026-05-27 時点の私の環境では、主実装者としても最も安定している。統率力、読解力、ファイル横断理解、成果物、速度のバランスがよく、複数ファイルにまたがる修正でも破綻しにくい。
OpenAI は Codex の安全運用について、サンドボックスと承認の関係を明示している。
"Approvals and sandboxing work together."
この思想は user-level 環境にもそのまま使える。低リスクな読み取りやテストは自動化し、外部通信・破壊的操作・権限外ファイル編集は承認を挟む。
3. Gemini は大コンテキストの独立QA役として使いやすい
Gemini CLI は settings.json や環境変数、プロジェクト設定を持てるため、レビュー専用の使い方を定義しやすい。
"Gemini CLI uses JSON settings files for persistent configuration."
Gemini には、実装者ではなく「別視点の監査役」として入ってもらう。大きなコンテキストを渡せるため、diff、仕様、エラーログ、過去の判断をまとめて読ませるレビューに向いている。
一方で、複雑なファイル間の依存関係を精密に追う役は苦手な場面がある。だから Gemini には「この設計は危ないか」「この差分に抜けている観点はあるか」を聞き、実際にどのファイルをどう直すかは Codex または Claude Code に戻す。
実装抜粋
user-level の責務分担
~/.claude/CLAUDE.md や ~/.codex/AGENTS.md のような user-level 規約に、AI同士の役割分担を明文化する。
## AI QA Roles
- Claude: 実装、設計整理、タスク分解、最終統合判断
- Codex: 主実装、ローカル diff レビュー、テスト不足確認、安全境界の確認
- Gemini: 大コンテキスト第三者レビュー、設計セカンドオピニオン、同一エラー反復時の原因分析
## Review Trigger
- Issue 起票前は Gemini に要約レビューを依頼する
- commit 前は Codex に diff review を依頼する
- 同じエラーに 3 回遭遇したら Gemini deep review を依頼する
- 破壊的操作、外部通信、認証情報を扱う操作は人間承認を必須にする
ここで重要なのは、AI に「必要ならレビューして」と曖昧に書かないことだ。発火条件を具体化しないと、長い作業の途中でレビューが抜ける。
さらに、統率者が入れ替わっても読める共通プロトコルにしておく。
## Leader-Agnostic Protocol
どのAIが統率者になっても、以下を必ず実行する。
1. 作業前に user-level 規約を確認する
2. project-level 規約でビルド・テスト・公開不可情報を確認する
3. 過去判断が関係する場合は SurrealDB を recall する
4. 実装者とレビュアーを同一AIに閉じない
5. 重要変更では review_log にレビュー結果と採否を残す
6. 破壊的操作・外部通信・認証情報操作は人間承認を求める
この形にすると、Claude Code が統率者でも、Codex が統率者でも、Gemini がレビュー主導でも、最低限の作業品質が同じになる。AIの能力差を吸収するのはプロンプトではなく、環境側のプロトコルだ。
Claude 実装 → Codex diff review → Gemini deep review
以前は Claude 実装を起点にしていたが、2026-05-27 時点では Codex を主実装に置くことが増えている。典型的な流れは次のようにしている。
# 1. Codex が実装・テストを実行
codex "この不具合を修正し、関連テストを追加して"
# 2. Codex または Claude Code が commit 前の差分をレビュー
codex "Review the current git diff for regressions, missing tests, and unsafe operations."
# 3. 重要変更だけ Gemini で別視点レビュー
git diff --stat
git diff | gemini "この変更を第三者レビュアーとして確認し、設計・性能・セキュリティ上の懸念を優先度順に出して"
git diff 全体が大きすぎる場合は、対象ファイルと設計メモに分ける。
git diff -- src/app/auth src/app/api > /tmp/review.diff
gemini <<'PROMPT'
以下の差分を、実装者とは独立したQA担当としてレビューしてください。
観点:
- 仕様との不整合
- 例外処理
- 回帰リスク
- テスト不足
- セキュリティ懸念
出力:
- Blocking
- Should fix
- Nice to have
- 確認質問
差分:
PROMPT
cat /tmp/review.diff | gemini
実運用では shell のつなぎ方よりも、「何を渡し、何を返させるか」のほうが重要だった。レビュー出力形式を固定すると、Claude 側で修正タスクへ戻しやすい。
レビュー結果をログ化する
AIレビューを運用にするには、レビュー結果を残す必要がある。毎回チャットに流すだけでは、同じ指摘が繰り返されているかを見られない。
surreal-query.sh --review-create \
--mode "qa" \
--model "gemini" \
--target "current-diff" \
--tags "ai-qa,gemini-review,codex,claude-code" \
--content-file /tmp/gemini-review.md
ログ化する項目は最低限でよい。
- target: 何をレビューしたか
- mode: qa / deep / issue / error など
- model: どのAIがレビューしたか
- tags: 後で検索するための分類
- content: 指摘内容と採否
これにより、「Gemini が何度も同じ種類のテスト不足を指摘している」「Codex は互換性リスクを拾うが、仕様の前提漏れは Gemini のほうが拾いやすい」といった傾向が見える。
運用上の学び
1. 時点評価を運用ルールに反映する
AIツールの性能差は固定ではない。2026-05-27 時点では Codex を主実装に置いているが、これは永続的な序列ではなく、現時点の実務評価だ。
そのため、user-level 規約には「どのAIが偉いか」ではなく、「今はどのAIに何を任せるか」を書く。たとえば、Codex の成果物が安定している時期は主実装を Codex に寄せ、Claude Code の品質が揺れる時間帯は Agents 統率と調査に絞る。Gemini は大きな材料を読ませるレビュー役として残す。
この切り替えを明文化しておくと、AI環境の流行やモデル更新に振り回されにくい。
2. 統率者非依存の環境を作る
複合QAの本質は、強いAIを一つ選ぶことではない。どのAIが統率者になっても活躍できる環境を、あらかじめ整えることだ。
統率者に依存しないために、次の要素をAIの外側に置く。
| 外部化するもの | 置き場所 | 目的 |
|---|---|---|
| 共通作業規約 | user-level CLAUDE.md / AGENTS.md
|
どのAIでも同じ原則で動く |
| プロジェクト制約 | project-level docs | ビルド、テスト、公開不可情報を固定する |
| 過去判断 | SurrealDB knowledge
|
統率者が変わっても過去判断を引ける |
| レビュー履歴 | SurrealDB review_log
|
どのAIが何を指摘したかを残す |
| 成果物履歴 | SurrealDB output_log
|
計画、記事、調査結果を再利用する |
| 安全境界 | sandbox / approvals | 強いAIにも権限の上限を置く |
この環境があると、AIの役割を柔軟に変えられる。Codex が主導する日は Codex が規約とログを読んで進める。Claude Code が主導する日は Agents を切り、必要なレビューを Gemini や Codex に回す。Gemini が主導する日は大きな設計資料を読み、実装は Codex や Claude Code に戻す。
統率者は可変、環境は固定。この分離があると、AIモデルの流行や時間帯の品質変動に強くなる。
3. レビューは多ければよいわけではない
すべての変更に Claude、Codex、Gemini の三段レビューをかけると、すぐに重くなる。小さな文言修正や局所的な型修正まで deep review すると、品質より摩擦が勝つ。
運用上は次の分岐が扱いやすかった。
| 変更内容 | レビュー |
|---|---|
| 1〜2 ファイルの軽微修正 | Codex 自己確認 + テスト |
| commit 前の通常変更 | Codex diff review |
| 仕様・設計に影響する変更 | Codex + Gemini |
| 同一エラー 3 回目 | Gemini error review |
| セキュリティ・認証・権限 | Gemini deep review + 人間確認 |
4. AI同士の意見が割れた時の裁定者を決める
Claude が「問題なし」、Gemini が「危険」、Codex が「テスト不足」と言うことがある。この時に多数決をすると危ない。
採用している裁定ルールは単純だ。
- Blocking 指摘は、人間または最終統合者が根拠を確認するまで無視しない
- AI の結論ではなく、再現手順・該当コード・失敗条件を見る
- レビュー結果が衝突したら、より具体的な証拠を出したAIの指摘を優先する
AIレビューは判決ではなく、調査票として扱う。
5. user-level と project-level を分ける
user-level には「全プロジェクト共通のAI運用」を置く。project-level には「そのリポジトリ固有のビルド、テスト、設計制約」を置く。
user-level:
- どのAIをどう使うか
- いつレビューを発火するか
- 承認が必要な操作は何か
- ログをどこに残すか
project-level:
- ビルドコマンド
- テストコマンド
- ディレクトリ構造
- コーディング規約
- 公開不可情報の検知ルール
この分離をしないと、別プロジェクトに移った時に「前のプロジェクトの前提」をAIが引きずる。
6. 複合QAは採用活動にも効く
開発環境として Claude / Codex / Gemini の複合QAを整えると、単に内部品質が上がるだけではない。外部に説明できる開発文化になる。
「AIを使っています」では弱い。今は多くの開発者がAIを使っている。差が出るのは、AI の出力をどう検証し、どう記録し、どう人間の判断に戻すかだ。
この運用を記事化する価値はそこにある。採用候補者に対しても、「AIで速く書く」ではなく「AI同士を監査させ、人間が意思決定する」開発文化を示せる。
振り返り (ディレクター視点)
- 判断時に重視した軸: 実装速度ではなく、AIの出力をどう検証可能にするか、統率者が入れ替わっても作業品質を維持できるかを重視した
- どこを譲歩したか: 2026-05-27 時点では Codex が最も強いと感じているが、すべてを Codex に閉じない。統率者は可変とし、重要判断では Gemini や Claude Code の別視点を残した
- どこは譲らなかったか: 実装者とレビュアーを同一モデルに閉じないこと。少なくとも重要変更では別モデルの視点を入れる
- もう一度判断するなら: 最初から review_log のスキーマを整え、レビュー指摘の採否まで記録しておく。後から傾向分析しやすくなる
まとめ
- user-level AI 環境では、Claude / Codex / Gemini を「複数の専門ロール」として扱うと品質保証に使いやすい
- キモは、どのAIが統率者になっても動けるように、規約・ログ・外部メモリ・安全境界をAIの外側に用意すること
- 2026-05-27 時点の体感では Codex が主実装・diff review・統合判断の中心に向く
- Claude Code は複雑なファイル関係の把握と Agents 統率、Gemini は大コンテキストの第三者QAと deep review に分ける
- 発火条件を規約ファイルに明文化しないと、複合QAは場当たり的な相談で終わる
- レビュー結果はログ化し、同じ指摘が繰り返されていないか後から見られる状態にする
- AIレビューの最終目的は、AIに承認させることではなく、人間が見るべき論点を圧縮すること
参考
公式 1 次資料
- Claude Code overview — Anthropic — Claude Code の概要、CLI / IDE / browser / hooks / skills / MCP などの公式説明
- Create custom subagents — Claude Code Docs — Claude Code の subagent、独立コンテキスト、Agent Teams の説明
- How large is the context window on paid Claude plans? — Claude Help Center — Claude / Claude Code のコンテキストウィンドウに関する公式ヘルプ
- CLI — OpenAI Codex — Codex CLI のセットアップ、ローカルコードレビュー、サブエージェント、承認モードなどの公式ドキュメント
- Codex — OpenAI — Codex の製品概要。CLI、IDE、アプリ、バックグラウンド作業、コードレビューの位置づけ
- Introducing upgrades to Codex — OpenAI — GPT-5-Codex、コードレビュー、AGENTS.md 追従、複雑タスク処理の公式説明
- Introducing the Codex app — OpenAI — 複数エージェント並列実行、worktree、diff レビューの公式説明
- Codex for (almost) everything — OpenAI — Codex の長期タスク、memory、ソフトウェア開発ライフサイクル全体への拡張
- Running Codex safely at OpenAI — OpenAI — Codex を安全に運用するためのサンドボックス、承認、監査ログの考え方
- Gemini CLI documentation — Gemini CLI の公式ドキュメント
- Gemini CLI Configuration — Gemini CLI の user / project / system settings と環境変数の設定方式
- Long context — Gemini API — Gemini の 1M token 以上の長大コンテキストに関する公式説明
- Gemini models — Gemini API — Gemini 2.5 Pro の入力トークン上限や long context の公式モデル仕様
関連事例
- Claude + Gemini 2 段レビュー文化 — LLM レビューを開発フローに組み込む実例 — 本記事の前段にあたる二段レビュー運用
- 「自己完結プロンプト」でサブエージェント運用 — Opus = PM / Sonnet = Worker — Claude 内部のPM/Worker分担パターン
- SurrealDB を「組織記憶」として使う運用 — review_log / output_log を残す組織記憶の設計