「Codex 実装 → Claude レビュー」+18.1pt 論文を裏取りする — 両者のレビューは何が違うのか【クロスファミリー検証 第2回】

📖 はじめに — 「驚くべき数値」ほど、まず疑う

クロスファミリー運用の根拠として流通している数値がある。

統制実験で「Codex 実装 → Claude レビュー」= +18.1pt、逆方向（Claude 実装 → Codex レビュー）= −8.6pt。

都合が良すぎる数値は、引用が引用を呼ぶうちに出典が消える。運用を変える判断材料にするなら、一次ソースまで遡って照合すべきだ。本記事はその裏取りの記録である。結論から言うと、論文は実在し、数値は桁まで一致した。ただし留保も 2 点ある。

裏取りの方法論（ツールレジストリ・CHANGELOG・公式 docs を順に当たる手順）はAgent Team 停止の裏取り記事のテンプレートに従っている。今回は対象が論文なので、学術検索 API と発表元ワークショップを一次ソースとした。

🔬 論文の所在確認

• タイトル: “Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?”
• 発表先: Agentic Software Engineering (SE 3.0) — KDD ‘26 Workshop（2026 年 8 月開催）
• 公開版: ResearchGate

検索の過程で分かった注意点: 2026-07-03 時点で arXiv には未登録（arXiv API の全文検索で 0 件）、OpenReview の公開検索にも出てこない。「arXiv にないから存在しない」と早合点しそうになるが、ワークショップ論文は ResearchGate や発表元サイトにしかないことも多い。複数の検索経路を持つことが裏取りでは効く。

📊 実験設定と数値の照合

設定

• 題材: LiveCodeBench の hard / medium 116 タスク
• モデル: Claude Opus 4.7（A）と Codex GPT-5.5（O）
• 条件: writer × reviewer の 6 条件。ラベルは「書き手 → レビュアー」順（例: AO = Claude が書き Codex がレビュー）
• 評価: 共通の隠しテストに対する pass rate。同一問題を役割の割当だけ変えて繰り返し評価できるため、レビューの寄与だけを分離できる設計

照合結果

流通している「+18.1pt」は 71.6→89.7、「−8.6pt」は 91.4→82.8 の pass rate 差分であり、桁まで一致。裏取りとしてはここで確定した。

「Claude 単体（91.4%）が最強では？」— この表が本当に言っていること

表をよく見ると、全 6 構成の最高スコアはクロスファミリーではなく Claude 単体（91.4%） だ。「ならレビューなど挟まず Claude に書かせればいいのでは」— この疑問には正面から答えておく。クロスファミリーは「品質を上げる」技術だと読むと、この表では正当化できない。正しい読みは 3 段である。

1. 91.4% と 89.7% は「同着」。 差は 116 題中わずか 2 題分で、この標本サイズでは統計的に区別できない。有意なのはレビュー効果（+18.1pt = 21 題分）の方だ。「単体の方が良い」とも「クロスファミリーの方が良い」とも、この表からは言えない
2. 本質は「品質を保ったままコスト構造を変える」こと。 Codex 単体（71.6%）と Claude 単体（91.4%）の差 19.8pt のうち、Claude レビューは 18.1pt — 約 9 割 — を回復する。つまり、実装を安価・並列・別課金枠のファミリーへオフロードしても、verifier を正しい向きに置けば品質はほぼ Claude 単体と同等に戻る。全実装を最上位モデルで書く費用と比べたとき、クロスファミリーの正当化は品質でなく経済合理性にある
3. AI レビューの ROI が正になる、唯一の向きである。 Claude 実装を選ぶと、自己レビューは ±0・Codex レビューは −8.6pt — 上に載せられる AI 検証が存在しない構成になり、検証の負担はすべてテストと人間に返る。「AI verifier をリグレッションの網として常設したい」という要件が先にあるなら、AI レビューが機能する構成は Codex 実装 → Claude レビューしかない

なお「同族レビューでは相関盲点が消えない」という独立性の議論は、自己レビュー ±0 という傍証と自環境実測（第6回の golden set。precision 差は実測済み、recall のダイバーシティ利得は難化版で実証待ち）で補強中の仮説であり、この表を根拠にはできない。輸入すべき結論はこうだ — 実装をオフロードしたい経済的動機が先にあり、そのとき品質を 9 割回復させ、かつ AI 検証が機能する唯一の向きが「Codex 実装 → Claude レビュー」である。

第 4 の答え — CTS-EC の実構成は、この表のどの行でもない

ここまでは論文の土俵の上の話だ。しかし冒頭の疑問には、表の外にもう 1 つの答えがある。CTS-EC が実際に運用している構成は、この 6 行のどれとも一致しない。

見落とされがちだが、論文の 6 条件はすべて「誰が実装するか × 誰がレビューするか」の二次元であり、評価オラクル（合否を判定する隠しテスト）はベンチマーク提供の外部資産 — どのモデルも書いていないし、触れない。pass rate という数字が意味を持つのは、このオラクルの独立性があってこそだ。実装者がテストを書き換えられる世界では、pass rate は成績ではなく自己申告になる。

CTS-EC は TDD を義務化し、この三役を家族で分解した。

つまり「Codex 実装 → Claude レビュー（+18.1pt の向き）」に、論文の実験設計そのものが持っていたオラクルの独立性を、運用でも再現する仕掛け（Red テスト = verifier 家族の資産・第4回）を重ねた構成だ。

この配置は表の数字からも裏付けられる。91.4%（Claude 単体）と 89.7%（Codex → Claude）の比較が本当に言っているのは、Claude を実装者に置く限界価値は +1.7pt（ノイズ域）、レビュアーに置く限界価値は +18.1pt ということだ。ならば Claude の能力 — 91.4% を支えた「書きながら検証する」性質と precision — は、実装ではなく検証の両端（オラクルの著述とレビュー） に配置する方が、測定された限界価値が大きい。テスト著述の価値そのものは論文は測っていない（6 条件に TDD 条件はない）が、この割当には自環境の傍証がある: golden set で Claude は矛盾ゼロの対照ケースに誤検出 0 件（Codex は 4 件）。オラクルを書く役に最も要る性質は「実在しない要求を仕様に書き込まないこと」— まさに precision である。

効果として何が変わるか。論文の pass rate は統計的傾向であり、Codex 単体 71.6% とは「28.4% の不合格品もそのまま出てくる」世界の数字だ。CTS-EC では Claude 製オラクルを hook が強制するため、テストを通らない実装はレビューにすら到達しない。①品質の下限は Claude が書いたテストが定義し（テストが符号化できた範囲で）、②その上に +18.1pt の向きの意味論レビューが載り、③実装コストは Codex にオフロードされたまま。「Claude 単体の 91.4% を生んだ能力が、テストを書くことで Codex → Claude の +18.1pt を下から支える」という直感は、この構造として正確に言い直せる — 輸入したのは 91.4% という数字ではなく、91.4% を生んだ能力の最適配置と、pass rate を意味あらしめたオラクル独立性の両方だ。

そしてこの構成は、後追いで外部のベストプラクティスとも一致した。Anthropic の公式ベストプラクティスは「実行可能な検証を渡す」「作業した本人に採点させない」「テストを書く Claude と、それを通す実装役を分ける」「成功の主張ではなく証拠を出させる」を推奨する。さらに同社の reward hacking 研究は、実装エージェントが「テストを欺く」方向へ最適化する故障モード（sys.exit(0) でテストハーネスから脱出し全テスト成功に見せかける等）を実証した — オラクルを実装者から隔離する checksum 保護は、好みの問題ではなく、実証済みの故障モードへの対策である。

正直な留保も 1 行で添える。この三役構成の効果量を測った実験は存在しない。ここで主張しているのは数値ではなく、論文が実測した 2 つの事実 — レビューの向きの非対称性と、オラクル独立性が pass rate を意味あらしめること — を、両方とも構造として取りに行ったという設計の由来である。

留保 2 点も正直に書く

1. 一般化の限界: LiveCodeBench は競技プログラミングの単発タスクで、リポジトリ規模の実装・既存規約との整合・複数ファイルの整合は含まない。116 タスクのワークショップ論文であり、効果量を丸ごと自環境へ外挿するには小さい
2. 未照合の数値: 併せて流通している「finder precision ≈ 47.5%」は、今回の Web 照合では確認できなかった（論文全文はアクセス制限あり）。本シリーズでは pass rate 系のみを「照合済み」として扱い、precision 値は出典未確認の参考値に留める

この留保が、後述する「外部実験値と自環境実測の分離」という運用規律（第6回）につながる。

🥊 Claude と Codex のレビューは何が違うのか

数値の裏には、両ファミリーのレビュー観の違いがある。論文の解釈と自環境の実測を重ねると、像がはっきりする。

1. Claude は「書きながら検証する」、Codex は「書いてから拾われる」

• Claude 実装は一次パスの自己検証が重い。ベースライン 91.4% と高く、自己レビューを重ねても ±0 — つまり二次パスに残る伸びしろを、書いている時点でほぼ消化している
• Codex 実装（71.6%）には拾える欠陥が多く残る。だからこそ精密なレビューが +18.1pt も効く。Codex の自己レビューでも +12.9pt 伸びるが、Claude レビュー（+18.1pt）には届かない — ここがクロスファミリーの上乗せ分だ

2. Codex レビューはなぜ「有害」になるのか

Claude の 91.4% のコードに Codex レビューを入れると 82.8% に下がる。メカニズムは「high-recall な指摘の副作用」だ。Codex は疑わしきも広く拾う姿勢で、指摘には誤検出が混ざる。それをそのまま採用すると、正しいコードに誤修正が入る。ベースラインが高いほど「持ち上げる」余地より「壊す」リスクが勝つ。

これは自環境の実測とも方向が一致した。CTS-EC の golden set（仕様書に既知の矛盾を埋め込んだ測定用データセット・詳細は第6回）では、矛盾ゼロの対照ケースに対して Claude は誤検出 0 件、Codex は 4 件。Codex は「一覧クエリが片側のフィールドしか見ていない」といった、一見それらしいが実在しない矛盾を両試行で報告した。

3. 「指摘数の多寡は優劣ではない」— 役割で読み替える

ここで大事なのは、Codex のレビューを「劣っている」と読まないことだ。見逃さないこと（recall）と誤検出しないこと（precision）はトレードオフであり、high-recall な姿勢は「探索・発見」の役割なら長所になる。

つまり結論は「Claude が優秀」ではなく、「Codex が広く拾い、Claude が仕様と突合して確定する」直列分業が、両者の特性を最も活かすということだ。順序を逆にすると、両者の弱点だけが直列につながる。

4. 自己レビューの罠 — フレーミングでどちらも劣化する

もう 1 つ、ファミリー差とは別次元の共通弱点がある。Todd Orr 氏の相互レビュー実験では、handoff に実装者の自己評価（「全テスト合格しました」）を含めると:

• Claude: 重大度 Critical と判定する率が 90% → 60〜70% に低下
• Codex: 平均指摘数が 9.4 件 → 2.4〜4.0 件に激減

どちらのファミリーも、書き手のフレーミングでレビューが鈍る。クロスファミリーにしても、handoff の設計を誤れば独立性は壊れる — これが第4回で扱う「自己評価遮蔽」の根拠だ。

🧾 まとめ — 数値ではなく「構造仮説」を輸入する

• 論文は実在し、+18.1pt / −8.6pt は pass rate 差分として桁まで一致した
• 非対称性の正体は、Claude = 重い自己検証と高 precision、Codex = high-recall と誤検出という特性差
• したがって輸入すべきは「+18.1pt」という数値ではなく、「finder と verifier の役割は非対称であり、向きを固定すべき」という構造仮説。数値そのものは自環境で測り直す
• そして CTS-EC の実構成（テスト = Claude・実装 = Codex・レビュー = Claude）は表のどの行でもない。輸入したのは表の 1 行ではなく実験設計ごと — Claude の能力を検証の両端に配置し、pass rate を意味あらしめたオラクルの独立性を TDD 義務化 + テスト機械保護で運用に再現した

次回は、この構造仮説を実際の運用パイプラインに落とす設計を扱う。

📚 シリーズ記事（ステアリング駆動開発・実践編）

序章

1. AI 駆動開発が積み上げる技術的負債

第I部: 技術的負債ドメイン別の実録（総点検ガイド + 8 ドメイン・全 9 回）

2. リファクタリング総点検ガイド — 7 つの観点と進め方
3. DDD/SOLID/BC 編 — god class 一掃と境界の機械ガード
4. SAGA 編 — 新アーキテクチャ挑戦と再発ゲート
5. Atomic Design リファクタ編 — 47 page 新規移植
6. Storybook × a11y 実機編
7. テスト品質・網羅性編
8. Python ジョブ群編
9. パフォーマンス編
10. セキュリティ編

第II部: 検証エンジン（クロスファミリー検証・全 6 回）

11. 総論 — マルチ LLM の 2 系統と見取り図
12. 裏取り編（本記事）
13. 設計編 — finder/verifier 分業と逆順禁止
14. TDD×ハーネス編 — テスト保護と三層ゲート
15. 実装編 — Claude Code の中から Codex を動かす
16. モデル戦略編 — ティア割当と「買うか組むか」

終章

17. クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ — 検証エンジンに「計測」の層をはめ、自己修正ループを閉じる

番外編

18. CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用実録 — 実測が有力仮説を殺し、退行前より速くなった 1 日
19. GPT-5.6 sol 切替の当日実録 — もう一つのデフォルト追従 — CLI 更新が黙って替える finder と、当日中の再計測
20. 遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化 — 逆順禁止の境界を ADR で確定し、読む仕事を遊休枠へ移した 1 日
21. ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布 — 4 プロジェクト展開への切り出しと、version + SHA ピンによる非強制追従
22. 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角 — 新モデル対応を起点に、配布・文書・CI の回帰を二消費者で検出した 69 分

参考リンク（2026-07-03 時点で確認）

• Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?（ResearchGate）
• Agentic Software Engineering (SE 3.0) — KDD 2026 Workshop
• What I Found When Claude Reviewed Codex’s Work（Todd Orr）
• Best practices for Claude Code（Anthropic 公式） — 検証の付与・テスト役と実装役の分離・証拠主義（2026-07-06 確認）
• From shortcuts to sabotage: natural emergent misalignment from reward hacking（Anthropic Research） — 実装エージェントがテストを欺く故障モードの実証（2026-07-06 確認）