AIが書いたコード、別のAIに見せれば客観的？ 新しいセッション・別モデル・テスト・人で「直るもの」と「残るもの」

AIにコードを書かせたら、別のAIにレビューさせる。いまはかなり普通のやり方になってきました。

でも、ここでひとつ気になりませんか？

「同じAIが書いて、同じ系列のAIが見て、『問題なし』。それ、ほんとに客観的なの？」

じゃあ、別のモデルならいいんでしょうか？ テストを足せばいいの？ それとも結局、人が全部見るしかない？

この記事では一次資料（論文・公式ブログ・公開されたプロンプト）に当たって、この問いを整理しました。

01先に結論

• 新しいセッションや別モデルでレビューすると、直る問題は確かにある。 116問のコード課題の実験では、レビュー後に誤答が21〜26問直った条件があります。
• でも、同じレビューで正解が壊れることもある。 同じ実験で、元は正解だったコードが13問壊れた組み合わせもありました。
• 「別のAI」だから客観的、とは言えない。 独立しているのは「会話」であって、「知識や思い込み」とは限りません。
• レビュー役を増やしても、全員が見逃す問題は残る。 増やすほど費用も増えます。
• テストは「決めた性質」を確認できる。でも、要件そのものが違うと何も言えない。
• 最後に残るのは、「何を正しいとするか」の判断。 これは人の仕事です。

つまり答えは「客観的になる」でも「ならない」でもありません。何を足すと、何が直って、何が壊れて、何が残るのか。 それぞれを分けて見るのが正解です。

こんな人に向けて書いています。

• AIにコードを書かせて、レビューもAIに任せ始めた人
• 「別のモデルに見せれば安心」と聞いたけれど、本当か確かめたい人
• 自分のチームでAIレビューの効果を測りたい個人開発者・小規模チーム

02用語を3つだけ

エンジニアの人は読み飛ばしてOKです。

• レビュー：コードを取り込む前に、別の人（またはAI）が見て、間違いがないか確かめること。
• セッション（コンテキスト）：AIとのひと続きの会話。作者AIの「ここはこういう意図で書いた」という説明も、そこに入っています。
• 誤検知（FP）と見逃し（FN）：誤検知は「問題じゃないのに、問題だと言われた」こと。見逃しは「問題があるのに、気づかれなかった」こと。

03「別のAI」には、独立の段階がある

「別のAIに見せる」と言っても、何が別になっているかはバラバラです。

たとえば要件が「期限ちょうどの時刻で無効にする」なのに、その一文がレビュー役に渡っていなかったとします。作者もレビュー役も now <= expires_at を自然だと思うかもしれません。モデルの名前を変えても、渡っていない要件は補えません。 これは説明のための例で、起きる確率を測ったものではありません。

ちなみに「AIは自分の出力をひいきする」という研究もあります。ただしPanickssery et al.（2024）は要約の評価、Chen et al.（2025）は検証できる課題での自己選好が対象で、どちらも業務コードのレビューを測ったものではありません。「同じモデルは必ずなれ合う」とも「別会社なら客観的」とも言えないので、実際に測るのがいちばんです。

04研究1：レビューで直ったもの、壊れたもの

いちばん分かりやすいのがXiang et al.（2026）の実験です。LiveCodeBenchの中・高難度116問で、AIが書いたコードを別のAIにレビューさせ、最終的に隠しテストに通るかを数えています。レビュー役はコードを実行できません。

（出典：論文の表2・表4。作者モデルはClaude Opus 4.7とCodex GPT-5.5。費用は取得できた行のみ記載）

読み取れることを整理します。

• 同じモデルの新しいセッション（Codex→Codex）でも、15問ぶん増えた。 「別会社でなければ意味がない」とは言えません。
• 別モデル（Codex→Claude）は、さらに増えた。 21問ぶん。ただし費用は約2.3倍です。
• 逆向き（Claude→Codex）は、むしろ10問ぶん減った。 もともと106問正解していたのに、レビューの結果96問に。
• Claude→Claudeは直った3・壊れた3で差し引きゼロ。 増えたのは費用だけです。

合格数の差は「直った数 − 壊れた数」と同じです。だから、差だけでなく直った数と壊れた数を別々に見てください。Claude→Claudeは差し引きゼロでも、3問直って3問壊れています。「指摘が出た」「修正された」だけを見ていると、壊れた分が見えません。

注意点も正直に書いておきます。

• これは競技プログラミング系の課題で、業務のPRレビューではありません。
• 組み合わせの順位を、いまのモデルの優劣として読まないでください。論文で使われたモデルは特定のバージョンです。
• 同じ2モデルでも、作者とレビュー役を入れ替えると結果が逆になりました。「このモデルが良い」ではなく「この組み合わせ、この条件で」と言うのが正確です。

05研究2：役を増やす、人数を増やすとどうなる？

Yang et al.（CRBugBench、2026）は、実在のOSSの変更に混入した既知バグを、レビューAIがどれだけ拾えるかを測っています。OSS 98リポジトリの1,000課題と、企業の非公開リポジトリ800課題です。

GPT-5.6-Sol（xhigh）での既知バグ回収率（上位5指摘中）は、論文の表3で次のとおりでした。

5候補で+4.8ポイント。著者はこれを約5.5倍の費用と並べて報告しています。しかも「子役を起動する方式」のように、増やしたのに下がった構成もあります。

ここから言えるのは「役を増やせば必ず良くなる」ではなく、「増やした分の費用に見合うか、同じ額を別の使い方にした場合と比べないと分からない」ということです。この表だけでは、同額で比べた結果は分かりません。

もうひとつ、数字を読むときに気をつけたいことがあります。この「回収率」は過去に見つかった既知のバグのうち、何割を見つけたかです。まだ誰も知らないバグまで含めた「検出率」ではありません。

06実運用では：Anthropicの報告から

AnthropicはClaude Codeチームのレビュー運用を公開しています（2026年10月15日）。

• 6〜9月に、マージされたPRは2倍超になり、リバートが必要だった割合は40%超減った。
• 流れは事前の実行検証 → 新しい文脈のサブエージェントによる差分レビュー → 並列のバグ探索 → 別グループによる指摘の検証 → 人の承認、といった複数段。

ただしこれは同社の運用報告で、AIレビューだけの効果を比べた実験ではありません。CIも承認方針も同時に変わっています。

そして、うまくいかなかった話も書かれています。

• あるPRは、一晩で50回超のレビューと修正を往復してから、作者が止めた。
• 調べた指摘のうち、約59%は「レビュー役の最初の確認の時点から、すでにあったコード」への指摘だった。

後者は「指摘の59%が誤検知」という意味ではありません。今回の変更と関係の薄い、前からある問題を掘り続ける様子が、この数字に表れています。対策として挙げられているのは、3ラウンドで方針を見直すこと、数回目以降は追加差分に絞ること、同じ種類の問題をまとめて指摘することです。

小さなチームが持ち帰れる教訓は、「承認を省略する」ことではありません。見つける・確かめる・決める・戻すという仕事を分けて、別々に測ることです。

07検証役を足すと、誤検知は減る。でも…

指摘が多すぎるなら、別の役に「その指摘は本当か」を確かめさせる方法があります。

• Claudeの公式プラグインの公開プロンプトは、複数の探索役が候補を出し、別の役が候補ごとに採点して80点未満を落とす作りです。ただしこの「80」は 「本物である確率80%」ではありません。
• AlibabaのOpen Code Reviewは、固定されたプロンプトで、検証側に「差分が事実誤認を証明できる指摘だけを除く」方針を取っています。

どちらも設計の考え方として参考になります。ただ、ここには引き算の罠があります。

• 「確認できないから落とす」と、正しい少数意見まで落ちる（誤検知は減るが、見逃しが増える）。
• 「間違いと確認できないから残す」と、誤検知が残る。

どちらを選んだかで、適合率と見逃しの両方が変わります。だから、検証役を入れたら落とした指摘もいくつか取り出して、人が標本確認するのがおすすめです。残った指摘だけを見ると、検証役が正しい指摘を捨てたことに気づけません。

数字を直接比べてはいけない例も挙げておきます。CodeRabbitに対する開発者の反応を調べた研究（Lin et al.、239リポジトリ・31,073件の指摘と応答）では、受け入れ36.4%、議論7.3%、拒否56.3%でした。けれど拒否された理由には、誤検知だけでなく、重複、範囲外、設計上の意図的なトレードオフ、好みの違いも含まれます。「拒否56.3%＝誤検知56.3%」ではありません。

08テストで直るもの、直らないもの

テストはAIの「それっぽい判断」から離れられる手段です。でも万能ではありません。実際に動かして確かめてみましょう。次の教材は自作で、AIにレビューさせた実験ではありません。要件は先に決めておきます。

本人だけが参照できる。期限ちょうどで失効する。本人かどうかの照合は、この関数で行う。

def base(owner, viewer, now, expires_at):
    return owner == viewer and now < expires_at

def head(owner, viewer, now, expires_at):
    # AIが書いた変更（期限ちょうどを有効にしてしまっている）
    return owner == viewer and now <= expires_at

def fixed(owner, viewer, now, expires_at):
    return owner == viewer and now < expires_at

def harmful_fix(owner, viewer, now, expires_at):
    # 「上流で認証済みだから本人照合は不要」という誤った指摘に従った例
    return now < expires_at

4つのテストケースで確かめます。

cases = [
    ("有効な本人", ("alice", "alice", 9, 10), True),
    ("期限ちょうど", ("alice", "alice", 10, 10), False),
    ("期限後", ("alice", "alice", 11, 10), False),
    ("有効期間の別人", ("alice", "bob", 9, 10), False),
]

手元で実行して確認した結果がこちらです。

base []
head ['期限ちょうど']
fixed []
harmful_fix ['有効期間の別人']

読み取れることは3つです。

1. head の境界バグはテストで確実に再現できる。 「<= は怪しい」というAIの指摘も、テストが通る・通らないで白黒つきます。しかも、baseでは起きないので、この変更が導入したバグだと確かめられます。
2. harmful_fix は、期限の再現テストは通る。でも、別人を通してしまう。 「指摘されたテストが通った」だけで修正を採用すると、元々守れていた条件が壊れます。再現テストとは別に、元の受入テストの再実行が必要です。
3. 要件が間違っていたら、テストは役に立たない。 本当は「期限ちょうどは有効」が正しかった場合、head のほうが正しく、テストのほうが間違いです。期待値はAIの出力ではなく、要件から決めます。

もうひとつ。AIに修正させると、テストを通すためにテストを消す、skipする、assertを緩めることがあります。修正差分にテストの変更が入っていないか、毎回見てください。

09テストが測れる範囲

c-CRABという公開ベンチマーク（Zhang et al.、2026）は、人間のレビューコメントを実行可能なテストに変換し、AIレビュー → 修正 → テスト通過を測っています（184件のPR・234テスト）。

• Claude Code 32.1%、Devin 24.8%、PR-Agent 23.1%、Codex 20.1%。
• 4つのツールの和集合でも、234テスト中97（41.5%）。

人間のコメントから問題を作っているので、人の100%は「人のほうが優秀」の証拠にはなりません。それでも、複数のツールを組み合わせても過半数は残ることは分かります。また、テストの73.5%は「コードの構造を確かめる」形式で、動作が同じでも書き方が違う修正を落とす可能性があります。

もうひとつ、おもしろい論文があります。Jin・Chen（2026）は正常なコードをAIに判定させたとき、プロンプトによって誤って「バグあり」にする割合が変わることを報告しました。GPT-4oで、HumanEvalの正しいコードを誤って否定した割合が、簡単な判定プロンプトで26.2%、説明と修正案まで求めるプロンプトで73.2%。「丁寧に見て」と頼むほど、ないバグまで見つけることがある、という結果です。ただし、コード課題での結果なので、PRレビュー全般には広げられません。

10人に残る仕事

では、AIとテストで確かめた後、人にはどんな仕事が残るのでしょう？

• 要件が合っているか。 作者もレビュー役も同じ要件を読み違えていたら、AI同士の合意は意味を持ちません。
• 許容できるリスクか。 認可、課金、データ移行、取り消しにくい変更は、個人開発でも判断が重い。
• 出していいか。 「指摘がゼロ」と「予算切れで止まった」は別です。
• 戻せるか。 問題が起きたとき誰が戻すかを決めておく。

人自身も見落とします。だから「人が見た」だけを安心材料にせず、どの確認が何を担当したかを分けて残すのが大事です。

11まとめ：何が直って、何が残るのか

12今日から試す：10〜20変更で測る

「どれがいいか」は自分の変更で測るのが確実です。難しく考えなくても大丈夫。最初はこれで十分です。

1. 最近の10〜20変更を選ぶ（成功例だけにしない）。レビュー時点のbase/headと要件を固定する。
2. いつものCIと人のレビューを基準にする（それで拾える問題を、AIの手柄に数えない）。
3. 既知の問題（後でバグ修正や障害になったもの）を正解の集合にする。
4. 同じ会話で読み直す vs 同じモデルの新しいセッションで、まず2条件だけ比べる。次に別モデルを足す。
5. 指摘を出した条件を隠して採点する。真偽・新規性・確認にかかった時間を記録する。
6. 費用（API、人の時間）と、修正で壊した数も数える。

こんな集計表を作ると判断できます（数字は全て架空の例です。10変更・既知バグ10件、時給30ドル）。

3行目では、誤検知を10件減らしましたが、正しい指摘も1件捨てています（8→7）。単独と比べると、既知バグ1件を追加で見つけるのに総費用が10ドル増える計算です。この例から、一般の損益分岐は出せません。自分のチームの数字で出すものです。

レビュー依頼文（そのまま使えます）

目的：対象変更が導入した、利用者に影響する欠陥を探してください。
base=<SHA>、head=<SHA>、要件=<文書または添付>。
初回レビューでは、作者の会話と他レビュアーの出力を参照しないでください。
要件・関連コード・呼出元・型・DB制約は直接確認してください。

各指摘に、以下を付けてください。
- 対象headと、最小のコード位置
- 成立する具体的な入力・状態・実行順序
- 破る要件と、利用者への影響
- 変更前から存在する問題か、変更で生じた問題か、その根拠
- 再現方法（実行していなければ「未実行」と明記）

件数を満たす必要はありません。仕様が不明なら、新しい要件を作らず「不明」としてください。
同じ根本原因はまとめ、改善提案・好み・既存問題は別欄にしてください。

止めどきを先に決める

「指摘ゼロになるまで」を終了条件にすると、Anthropicの50回往復のようになりかねません。たとえば、探索 → 検証 → 最小の修正 → 修正差分の再レビューを基本にして、修正は2回、3ラウンド、金額・時間のどれかで止めると決めておきます。これは提案で、最適値と実証されたものではありません。

止めた理由も「問題なし」とは別に残してください。「予算切れ」を「指摘ゼロ」に混ぜないのが大事です。

13この記事の限界

• 紹介した数字は、ぼくが追試したものではありません。論文・公式文書の本文を確認したもので、数字の大半は特定のモデル・特定の課題でのものです。
• ベンチマークの多くはAIが書いた変更だけを集めたものではありません。AIが書いたコードへの効果は、自分の変更で確認する必要があります。
• Anthropicの結果は同社の運用報告です。AIレビュー単独の因果効果ではありません。
• 教材コードは自作で、AIの発見率は測っていません。評価票・上限・依頼文は提案で、効果は未検証です。
• 次のことは、現時点で答えが見つかっていません：小規模チームでマージ後の重大事故がどれだけ減るか／同額・同じ人手で揃えた最良の配分／同じモデル・別モデルが共有する誤りの程度。

14参考にした一次情報

• Xiang et al., Cross-Model LLM Code Review, arXiv 2607.21656v1
• Yang et al., CRBugBench, arXiv 2610.13668v1
• Zhang et al., c-CRAB, arXiv 2603.23448v1
• Jin & Chen, Are LLMs Reliable Code Reviewers?, arXiv 2603.00539v1
• Lin et al., CodeRabbitへの開発者の反応の研究, arXiv 2607.03316v1
• Panickssery et al., arXiv 2404.13076 ／ Chen et al., arXiv 2504.03846
• Anthropic, How the Claude Code team does code review（2026-10-15）
• Anthropic, Claude Code公式ドキュメント「Code Review」
• Alibaba, Open Code Review（READMEと固定commitの検証プロンプト）

15再現用の素材

• 教材コード（review_demo.py）