「ClaudeにCodexのコードをレビューさせたら、合格率が71.6%から89.7%に上がった」
こんなタイトルの投稿がRedditで大きな注目を集めました。
支持は1,000件を超えています。
そして、コメント欄では活発な議論が展開されました。
本記事では、話題になった研究の中身を紹介します。
あわせて、コメント欄で交わされた実践的な知見も取り上げます。
研究の概要
元になったのは、AIコーディングエージェントの組み合わせを検証した研究論文です。
研究者たちはClaude Opus 4.7とCodex（GPT-5.5）を用意しました。
そして、LiveCodeBenchというベンチマークから抽出した116問を解かせています。
中級・上級のPythonタスクです。
結果は次のとおりでした。
- Claude単独：91.4%
- Codexのドラフト＋Claudeレビュー：89.7%
- Codexのドラフト＋Codex自己レビュー：84.5%
- Claudeのドラフト＋Codexレビュー：82.8%
- Codex単独：71.6%
確かに、CodexのコードをClaudeがレビューすると合格率は大きく伸びています。
71.6%から89.7%への改善です。
しかし、この表をよく見てください。
見出しの数字に騙されるな
最高スコアを叩き出したのは、レビューなしのClaude単独です。
コメント欄で最も支持を集めていたのも、この指摘でした。
論文の結論部分には、こう明記されています。
Claude Opus 4.7がドラフトを書いたなら、そのまま提出せよ。
なぜなら、テストしたどのレビュアーもClaude単独の成績を超えられなかったからです。
逆方向の組み合わせは悲惨でした。
Claudeが書いたコードは単独で91.4%です。
ところが、Codexにレビューさせると82.8%まで落ち込みます。
内訳を見ると、その理由がわかります。
CodexはClaudeの失敗を3件修正しました。
しかしその一方で、正しかった解答を13件も壊しています。
弱いモデルに強いモデルの成果物を触らせると、改善よりも破壊のほうが多くなる。
この研究が示したのは、そういう非対称性です。
研究手法への批判
ただし、コメント欄では研究の設計自体に多くの疑問が投げかけられていました。
最大の問題は、レビュアーの役割です。
この研究の「レビュアー」は、フィードバックを返しません。
その代わりに、新しい最終解答を直接生成する設計になっていました。
これは現実のコードレビューとかけ離れています。
人間のチームでは、レビュアーは指摘を返すだけです。
修正するかどうかは元の作者が判断します。
そして、実際に手を動かすのも作者です。
作者にはタスクの背景知識があります。
だから、指摘が的外れなら却下もできるのです。
ジュニアエンジニアに、プリンシパルエンジニアのコードを書き直す権限を与えたらどうなるか。
想像に難くありません。
他にも批判はありました。
レビュアー役のモデルは、テストの実行もツールの使用もできませんでした。
つまり、コードを眺めて意見を述べるだけの状態です。
実運用とはかけ離れた条件と言えるでしょう。
さらに、使われたのはOpus 4.7とGPT-5.5という一世代前のモデルです。
そのため、現行のフロンティアモデルに結果がそのまま当てはまる保証はありません。
加えて、こんな声もありました。
特定のバージョンで得た結果を「Claude」「Codex」という一般名で語るのは誤解を招く、と。
それでもマルチエージェントは機能する
興味深い点があります。
研究の結論とは裏腹に、コメント欄には複数モデルの組み合わせで成果を上げている実践者が大勢いたことです。
彼らのワークフローには共通点があります。
まず、レビュー結果を直接コードに反映させません。
指摘は一度フィードバックとして元のエージェントに戻します。
そのうえで、妥当性を判断させるのです。
「良い指摘だ」と受け入れることもあります。
逆に、「この指摘は前提を誤解している」と却下することもある。
人間のチームと同じ構造です。
ある実践者は、Claudeに計画を立てさせていました。
そして、別のAIにその計画をレビューさせるループを回します。
両者が合意するまで計画を練り、その後に実装へ進む流れです。
計画には時間がかかります。
しかし、実装フェーズはほぼ一発で通るそうです。
もう一つの重要な視点は、決定論的なチェックを先に走らせることでした。
具体的には、テスト、リント、型チェックです。
これらが通ってから、初めてモデルによるレビューを行います。
機械的に検証できる部分を先に潰しておく。
そうすれば、「正しいコードに間違った指摘をする」コストが大幅に減るという理屈です。
そして最後の砦は人間です。
どの指摘を採用するかの最終判断を人間が握る。
その限り、悪い提案が自動的にコードへ混入することはありません。
18ポイントの正体
数字を分解したコメントも秀逸でした。
Codexの自己レビューは84.5%です。
この数字から、Claudeレビューが生んだ18ポイントの改善を分解できます。
およそ13ポイントは、二度目の視点でコードを見直したこと自体の効果です。
そして、レビュアーがClaudeだったことによる上乗せは5ポイント程度と推定できます。
別のコメントは、さらに踏み込んだ仮説を提示していました。
自分の作業履歴を見ながらの自己レビューでは、モデルは自分の判断を擁護しがちです。
一方、履歴を持たない新しいコンテキストならどうでしょうか。
結果だけを見て、正しさを再検証せざるを得ません。
つまり、「Claudeの自己レビューが効かなかった」のではないかもしれない。
実は「自分の答案を自分で採点しても意味がなかった」だけの可能性があるわけです。
モデルを切り替えることよりも、新鮮な目で見直すこと。
改善の主因はそちらにある可能性が高そうです。
レビューはタダではない
見落とされがちなコスト面にも触れておきましょう。
論文によれば、レビュアーを追加するとタスクあたりのコストは2倍以上に膨らみました。
しかも、処理時間は3倍近くまで伸びています。
数ポイントの改善のために、そこまでのコストと時間を払う価値があるか。
ワークフロー設計の際には、この視点も欠かせません。
まとめ
この研究から得られる教訓を整理してみます。
強いモデルが弱いモデルの成果物を検証すると、品質は上がります。
逆に、弱いモデルに強いモデルの成果物を触らせると品質は下がる。
つまり、レビューの価値は検証者の強さに依存するのです。
ただし、研究が検証したのは「レビュアーが勝手に書き直す」ワークフローでした。
これは現実にはあまり見ない形です。
指摘をフィードバックとして返し、元の作者と人間が判断する構造にする。
そうすれば、マルチエージェント構成は今も有効に機能します。
そして、改善の多くはモデルの切り替えから生まれたのではないかもしれません。
むしろ、新しいコンテキストでの見直しが主因である可能性があります。
結局のところ、コメント欄のある一言に尽きるのでしょう。
モデルがコーディングの重労働を担う時代になっても、堅実なソフトウェアエンジニアリングの技術は依然として重要である。
人間のチームを設計するように、AIのワークフローを設計せよ。
道具が変わっても、良い仕事の原則は変わらないようです。
