Gemini のレビューは補助資料止まりだった。バグ修正 PR 40 件で Claude と匿名のレビュー対決をした（全 3 回）

はじめに

C# から GPU 向けのコードを生成する自作のコンパイラ（Henicos）を、LLM のエージェントだけで開発しています。人間はコードを一行も書いていません。

このシリーズでは、Gemini と Claude を自分のコードで比べてきました。第 1 回では、重複を見つけるベンチマークで Claude が Gemini Flash の約 2 倍を見つけました。第 2 回では、主力を Claude に移し、Gemini は外部の第二レビュアーとして残しました。

今回が最終回です。第 2 回で残した「Gemini を第二レビュアーとして使う」は、本当に役に立つのでしょうか。知りたいのは次の一点です。

Gemini が書いたレビューは、Claude がもう一度確かめなければならない「補助資料」にとどまるのか。それとも、人がほとんど見ずに LGTM で通してよい成果物になりうるのか。

そこで、実際にたまっていたバグ修正の PR 40 件を、Gemini と Claude に同じ指示書で別々にレビューさせました。結果は、書き手を伏せた審査員に判定させています。

先に結論を書きます。

• Gemini が出した本物の指摘 19 件は、どれも正しい内容でした。ただし、すべて Claude も見つけていました。Claude だけが見つけた本物の指摘は 66 件で、そのうちマージを止めるべきもの（blocking）は 12 件 でした。
• Gemini は blocking のある 12 件の PR すべてを「blocking なし」と結論し、そのうち多くに「Ready to merge」「LGTM」と書いていました。
• Gemini の記述には、存在しない型名・テスト名・行番号の引用が 6 件ありました。「読んで確かめた」と書いた指摘で、引用したコードが存在しないものもありました。Claude の誤りは 1 件でした。
• 一方で、審査員としての Gemini は役に立ちました。両方のレビューと Claude の審査員が見落とした CI の失敗を、Gemini の審査員だけが見つけています。

以下、対象の PR、対決の条件、判定の方法、結果、そして結論の順に書きます。

対象: Claude が見つけて Claude が直した、バグ修正の PR 40 件

どうやってできた PR か

きっかけは、リファクタリングの結果を Claude にコードレビューさせていたことでした。あまりにバグが多く見つかるので、途中で予定を変え、バグ探しに切り替えました。

1. 筆者が Claude に出した指示は、「src 全体に /code-review をかけて」というだけの雑なものです。具体的な仕様や疑わしい箇所は渡していません。
2. Claude（オーケストレーター）が、それを自分で段取りに直しました。src を 19 の単位に分け、19 本のレビュアーを並列に走らせています。レビュアーへの指示は「バグだけを探す。具体的な入力と、C# ならどうなるかを手で計算して書く。コードは実行しない」でした。
3. 所見は 109 件出ました。そのうち 83 件を、別の作業ツリーで実際に動かして再現を試し、78 件が再現しました。
4. 再現したものを issue にしました。誤った結果を返すもの（M1）が 41 件です。どれも再現の手順と期待する結果が付いています。
5. 別の Claude のエージェント（約 14 本を並列）に、M1 の issue を 1 件ずつ直させ、PR にしました。今回の 40 件がそれです。

つまり、バグの発見も修正も、人の雑な一言から LLM が自分で段取りを組んで進めたものです。そのため、PR の中には「そもそもバグではない（仕様どおり）」ものが混じっている可能性があります。

本当にバグか、先に確かめた

レビューの前に、40 件の issue が主張する動作が本当に契約違反かを、Claude に一件ずつ確かめさせました。

結果	件数	例
C# の定義に反する	11	評価の順序、短絡評価、例外の型、リテラルの型
GPU と CPU の結果が食い違う	3	CPU 側のワープシャッフルが、GPU と違う規則で動く
メモリ破壊、クラッシュ、黙って 0 を返す	10	解放済みのデバイスポインタを読む
数学的に誤った値	6	多倍長整数の比較や減算の符号
仕様書・API の約束に反する	6	仕様書にある例外を投げずに 0 を返す
仕様の決め方しだいで「バグではない」もありうる	4	float の Sum の足す順番、NaN の扱い

最後の 4 件は、「System.Linq に合わせるか、GPU の命令に合わせるか」のように、どちらを仕様にするかで答えが変わるものでした。人（筆者）が判断し、4 件とも PR の実装どおりを仕様に決めています。結果として、40 件すべてがバグ修正として妥当でした。

対決の条件

	Gemini	Claude
モデル	Gemini 4 Argon（思考 Medium）	Claude Opus 5.5（effort Medium）
環境	Antigravity の teamwork（レーンごとにサブエージェント）	Claude Code のサブエージェント
並列	5 レーン（A〜E）	5 レーン（A〜E、同じ割り当て）
指示書	同じもの	同じもの（下の違いだけを上書き）
相手の結果	見ていない（先に実行）	見ていない（PR のコメントを読むことを禁止）

指示書の中身は、PR ごとに次を確かめてコメントを 1 件書くことです。

1. 直っているか: issue の再現と期待値に対して、修正が症状を消しているか。
2. テストが本物か: 追加したテストが、修正の前に実際に失敗するか（修正だけを戻して走らせる）。
3. 規則に反していないか: プロジェクトの意味論の憲章、診断の方針、テストと構造の規則。

主張にはすべて ファイル:行 を付け、「実行して確かめた」のか「読んだだけ」なのかを書かせました。GPU を使うテストは、全レーンで共有のロックを取ってから実機で走らせています。

Gemini は先にレビューを GitHub に投稿していたので、Claude には PR のコメントとレビューを読むことを禁止しました。Claude の結果は投稿せず、ファイルに書かせています。
Gemini は/teamwork [skip-interview] /boost [プロンプトファイル] レーンごとにサブエージェントを立ち上げてと深い思考を強制させました。

判定の方法

どちらの指摘が「本物」かは、2 人の審査員に別々に判定させました。

• 匿名化: 偏りを打ち消すため、両者のレビューを匿名にしてから 2 人の審査員（審査員 1: Claude Opus 5.5、審査員 2: Gemini 4 Argon）に別々に判定させました。
  • 2 つのレビューのコメントと実行ログを、PR ごとに r + 16 進 6 桁の無作為な ID のフォルダーに写しました。ID は PR ごとに振り直し、どちらが先に来るかも無作為です。
  • 「Gemini」「Claude」などのモデル名、書き手が分かるパス、冒頭の決まり文句を消しました。
  • 元のレビュー、もう一方の審査員の結果、GitHub 上の PR のコメントを読むことを禁止しました。
  • 対応表は、筆者だけが持っています。判定の後で ID を付け直して集計しました。
  • 文体の違いまでは消せないので、読み込めば推測はできる程度の匿名化です。
• 判定の基準（両方の審査員で同じ）:
  • real（主張が正しい）/ false（主張が誤り）/ unclear
  • blocking（誤った結果、ビルドの失敗、診断のない失敗、main との衝突、CI の失敗、issue を閉じるのに直っていない）/ non-blocking
  • 決め方は、git merge-tree で main との衝突を確かめる、gh pr checks で CI を見る、引用された ファイル:行 を開いて実在するかを確かめる、実行ログが主張を支えるかを確かめる、の順です。引用したコードが存在しなければ false です。

120 桁を超える行の指摘は、両方がほぼ全件で出していたので集計から外しました。

結果

集計

匿名で判定した審査員 2（Gemini 4 Argon）の結果です。全部で 92 件の指摘を判定しました。

	Gemini のレビュー	Claude のレビュー	両方が指摘
本物の指摘（片方だけ）	0	66	19
うち blocking	0	12	1
誤った指摘	6	1	0

審査員 1（Claude Opus 5.5、書き手を知っている）の結果も、ほぼ同じでした。

	審査員 1（Claude）	審査員 2（Gemini、匿名）
片方だけの本物の blocking	Claude 12、Gemini 0	Claude 12、Gemini 0（12 件の中身も一致）
Gemini のレビューの誤り	2	6
Claude のレビューの誤り	0	1

2 人の審査員で、blocking の 12 件は一件残らず一致しました。違いは誤りの数え方だけで、審査員 2 はレビューの本文にある誤った引用まで数えています。Claude の審査員が自分に甘かった、ということはなかったと言えます。むしろ Claude のレビューの誤り 1 件は、Gemini の審査員だけが見つけました。

「LGTM」と書かれた PR に、blocking があった

Gemini のレビューは、blocking のある 12 件の PR すべてを「blocking なし」と結論していました。「Ready to merge」「LGTM」「APPROVE」と書いたコメントは 15 件ありました。

もし Gemini のレビューを信じてマージしていたら、次のことが起きていました。

• main と衝突した PR を 6 件マージしようとする（そもそもマージできない）
• CI が赤い PR を 2 件マージする
• 誤った結果を返す修正、ビルドが通らない修正を 4 件マージする

見落とされた blocking の中身

Claude だけが見つけた 12 件は、2 種類に分かれます。

1. 一度コマンドを打てば分かったもの（8 件）

main との衝突が 6 件、CI の失敗が 2 件です。

• 衝突の多くは、PR が作られた後に main 側でテストファイルが分割・削除されたことが原因でした。PR はもう存在しないファイルにテストを足していました。
• CI の失敗は、PR がソースに行を足したため、生成コードのスナップショットに埋め込まれた行番号がずれたものでした。

git merge-tree か gh pr checks を 1 回走らせれば分かります。ただし、指示書にこの手順を入れていなかったのは筆者の手落ちです。Gemini は指示どおり PR の先端だけで検証し、Claude は指示がなくても main との突き合わせと CI の確認を自分でしていました。この 8 件は「指示書に書けば、次から Gemini も拾える」部分です。

2. 修正の外側の入力を自分で作って試したもの（4 件）

PR	見つかったこと	Claude の確かめ方
共有したベクトルの部分式を 2 回読む	Where の条件と元の列で同じ部分式を共有すると、まだ値が上書きされる。期待 [12, 24] に対して [6, 12]。PR は Fixes で issue を閉じてしまう	試しのテストを書いて実行
多倍長整数の集約を左から畳む	逐次の Aggregate が要素数に対して指数時間になる。24 要素で 371 ms、1000 要素では 300 秒たっても終わらない	要素数を変えて時間を計測
演算子マクロ越しに && と || を展開する	ref struct で && を使うと、関数の呼び出しだけ出力されて本体が出力されず、C++ のビルドが通らない。G# の診断も出ない	試しのカーネルをビルド
partial な GPU メソッドの実装側を変換する	同期を含む partial な関数で、本体と呼び出しの引数の数が食い違い、C++ のビルドが通らない	試しのカーネルをビルド

PR に付いているテストは、どれも通っています。PR が直した範囲の中だけを見ていると、この 4 件は見えません。「この修正の隣の入力ではどうなるか」を自分で考えて試す必要があります。ここは指示書で強制しにくく、モデルの差がそのまま出た部分だと考えています。

Gemini の誤った指摘

Gemini の誤り 6 件は、ほとんどが「存在しないものの引用」でした。

• 実在しない型名とテスト名を引用し、それを実行した結果として書いていた
• 行番号が違い、実在しないテストプロジェクトを実行対象として書いていた
• 「この除外は名前の文字列比較だけ」と、存在しないコードを引用していた（実際はシンボルを解決していた）
• 「標準の CI ランナーではメモリが足りないので、このテストはスキップされる」と書いていた（実際は CI で走って合格していた）
• 意味論の憲章からの引用として、憲章のどこにもない文を書いていた

このプロジェクトでは、以前から「Gemini の主張は ファイル:行 を付けさせ、開いて確かめてから issue にする」と決めています。今回の結果は、その決まりが必要だったことを裏づけています。

Claude の誤り 1 件は、「読んだだけ」と自分で書いていた指摘でした。「1 ワードのテストでは、最上位ワードを選ぶ処理を壊しても見逃される」と書いていましたが、実際には別のテストが落ちます。実行して確かめた指摘には、誤りがありませんでした。

レビューの品質の違い

数だけでなく、レビューの書き方そのものにも差がありました。まず、差がなかった点です。

• 修正の前にテストが落ち、修正の後に通ることは、両方とも全 40 件で実際に走らせて確かめていました。
• Gemini の本物の指摘 19 件は、どれも内容が正しいものでした。

差があった点は次のとおりです。

観点	Gemini	Claude
修正の外側の入力を試したか	自分で入力を作ったのは 1 件だけ	試しのテストやカーネルを 10 件以上書いて実行した
テストの強さを疑ったか	一度も問題にしていない	修正を壊してもテストが通る箇所を 5 件で指摘した
main と CI に照らしたか	PR の先端だけで検証した	全 PR で main との衝突と CI を確かめた
結論の付け方	マージ寄り。15 件で「Ready to merge」「LGTM」と書き、2 件ではレビュー済みのラベルを付けるよう勧めた	厳しめ。価値の低い指摘も混じるが、事実として誤ったものはない
確かめ方の書き方	「確かめた」欄の大半は構造チェックのツールの出力だけ	指摘ごとに「実行した」か「読んだだけ」かを書き分けた
推測の扱い	推測を事実として書いた例がある	読んだだけの指摘は、そうだと明記した
形式	8 件が指示書と違う独自の形	40 件とも同じ形

審査員としての Gemini

一方、匿名で判定させた Gemini の審査員は、よい仕事をしました。

• 両方のレビューと Claude の審査員の全員が見落としていた、CI の失敗を 1 件見つけました（switch 式の修正で、共有している生成コードのスナップショット 8 件が古くなっていた）。筆者が gh pr checks で、今も落ちていることを確かめています。
• Claude のレビューの誤り 1 件を見つけました。
• 引用の誤りに厳しく、レビュー本文の誤った行番号や型名まで拾っていました。

第 1 回のベンチマークでも、Gemini 4 Argon は審査員として Claude Opus 5.5 とほぼ同じ精度でした。「ゼロから問題を見つける」のは苦手でも、「書かれた主張が正しいかを確かめる」のは得意なようです。

コスト

まず、レビューどうしの比較です。

	Gemini のレビュー	Claude のレビュー
時間（5 レーン並列、最初から最後まで）	2 時間 19 分	1 時間 11 分
新規入力	894 万	内訳は取れていない
キャッシュ読み	3 億 4,901 万	内訳は取れていない
出力	71 万	内訳は取れていない
合計	3 億 5,866 万（キャッシュ読みを除くと 965 万）	約 192 万
本物の blocking の指摘	0 件	12 件

次に、審査員の比較です。

	Gemini の審査員（匿名、5 レーン + 親）	Claude の審査員
時間	21 分	12 分
トークン	新規入力 156 万、キャッシュ読み 1,537 万、出力 25 万（合計 1,718 万）	約 29 万
判定した指摘	92 件	75 件

• Claude のレビューは、修正の前後でテストを実際に走らせ、試しのテストやカーネルも書いているので、時間の大半はビルドとテストです。
• Gemini の審査員は、判定のために、キャッシュ読みを含めて約 1,700 万トークンを読んでいます。新規入力と出力だけなら約 181 万です。

結論: Gemini のレビューは、Claude の確認が必要な「補助資料」にとどまる

最初の問いに答えます。

Gemini が書いたレビューは、Claude がもう一度確かめなければならない「補助資料」にとどまるのか。それとも、LGTM の成果物になりうるのか。

答えは「補助資料にとどまる」です。

Gemini が出した指摘は、おおむね正しいものでした。指摘を拾い読みする資料としては使えます。

それでも LGTM の成果物にならないのは、結論が信用できないからです。

• blocking のある 12 件の PR に「blocking なし」と書き、多くに「Ready to merge」と書いていました。
• 「確かめた」と書いてあっても、引用したコードが存在しないことがありました。

指摘が少ないだけなら、「Gemini が問題なしと言った部分は見なくてよい」と手間を省けます。ところが「問題なし」も「確かめた」も信用できないので、何も省けません。結局、毎回 Claude か人が裏を取り直すことになります。

今回は、裏を取る側の Claude のレビューが、Gemini の本物の指摘をすべて含んでいました。そのため、Gemini のレビューを足しても増える本物の指摘はありませんでした。

ただし、役割を変えると話が変わります。

役割	Gemini 4 Argon の向き不向き	根拠
一次レビュー（ゼロから問題を見つける）	向かない	本物の blocking 0 件、LGTM と書いた PR に blocking 12 件
審査員（書かれた主張を確かめる）	向いている	全員が見落とした CI の失敗と、Claude の誤りを見つけた

筆者の運用は、次のように変えます。

• レビューは Claude だけで行う。 二社にレビューを分けても、今回は利益がありませんでした。
• 指示書に git merge-tree と gh pr checks を必須の手順として入れる。 見落とした blocking の 3 分の 2 は、これで防げました。
• Gemini は、Claude のレビューの「主張を確かめる審査員」として使う。 書き手を伏せ、引用が実在するか、主張が正しいかだけを判定させます。

この対決の限界

• 1 つのリポジトリ、40 件の PR だけです。他の言語や、人が書いたコードのレビューで同じ差が出るとは限りません。
• PR は Claude が書いたものです。 Claude が自分たちの書いたコードの癖を知っていて有利だった可能性はあります。ただ、見落とされた blocking の中身（main との衝突、CI、修正の外側の入力）は、書き手の癖とは関係のないものでした。
• 指示書は Claudeが書きました。 main との突き合わせと CI の確認を入れ忘れたのも、その指示書です。Claude のレーンはそれを自分で補い、Gemini は補いませんでした。
• 思考の深さはどちらも Medium です。Gemini を High にしたら結果が変わるかは試していません（第 1 回では、Flash を high にしても伸びませんでした）。
• 実行の環境が違います: Gemini は Antigravity、Claude は Claude Code のサブエージェントです。ツールの挙動の差も結果に含まれます。
• 匿名化は完全ではありません: 文体や書式から書き手を推測することはできます。ただ、匿名にしなかった Claude の審査員と、匿名にした Gemini の審査員で、blocking の判定は一致しました。

まとめ

• Claude が見つけて Claude が直したバグ修正の PR 40 件を、Gemini 4 Argon と Claude Opus 5.5 に同じ指示書で別々にレビューさせた。
• 匿名にした Gemini の審査員でも、書き手を知る Claude の審査員でも、結論は同じだった。Gemini だけが見つけた本物の指摘は 0 件、Claude だけが見つけた本物の blocking は 12 件。
• Gemini の指摘はおおむね正しかったが、blocking のある 12 件すべてを「blocking なし」とし、存在しないコードの引用が 6 件あった。結論と「確かめた」が信用できないので、Claude の確認が必要な補助資料にとどまる。
• 見落としの 3 分の 2 は指示書に手順を足せば防げる。残りは「修正の外側の入力を自分で試す」力の差だった。
• 一方で、書かれた主張を確かめる審査員としての Gemini は、全員の見落としを拾った。
• シリーズを通しての結論: 主力は Claude。Gemini は「ゼロから見つける役」ではなく「確かめる役」で使う。

モデルは数か月で入れ替わります。次の Gemini が出たら、同じ指示書と同じ匿名の判定で、もう一度測るつもりです。

参考

• 「Claude のほうがコードを読める」は本当か？実務のコンパイラで重複検知ベンチマークを作って Gemini と比べた
  https://qiita.com/kassyi/items/01331b709cc5fb51bf25
• Gemini を主力エージェントから外して、Claude に移った
  https://qiita.com/kassyi/items/c134f3b244368d913f09
• Henicos（対象のリポジトリ）
  https://github.com/kassyi/Henicos