こんにちは。CTOの小林です。
最近は実装だけでなくコードレビューもAIにやらせるチームが増えてきたと思います。今日は、そんなAIコードレビューに最適なモデルを探した話をします。
きっかけは料金改定
これまでkickflowでは長い間コードレビューに外部のコードレビューサービスを使用しており、その指摘を修正してから人間が最終レビューをする、という運用でやってきました。それで困っていなかったのですが、使用していたコードレビューサービスの仕様変更でプランあたりのレートリミットが一気に厳しくなり、ちょっと立て込むとすぐ上限に張り付くようになりました。しかも従来はクレジットを買い足せばその場をしのげたのが、その追加課金もやりづらい料金体系に変わってしまいました。レビュー待ちでPRが詰まると普通に仕事が止まって困ります。
で、よく考えると、やっていることは「PRのdiffを投げてLLMにレビューさせる」だけです（もちろん他にも細かい機能は一杯付いてますが）。だったらGitHub ActionsとLLM APIを直接叩く形で自前で組んでしまえばいいのでは、ということで検証してみました。
モデルの選定
自作する場合、いちばん悩むのがどのモデルを使うかです。基準はシンプルに、コストと性能の二軸です。
まず外したのがフラッグシップ級です。GPT 5.5やClaude Opus 4.8あたりは確かに賢いのですが、いかんせん高すぎます。この1年でAIで開発が高速化された結果、各開発者はかなりの頻度でPRを出すので、全PRをこのクラスに通したら請求金額がとんでもないことになってしまいます。レビューという用途には明らかにオーバースペックでもあります。
かといって最安クラスまで落とすと、今度は指摘が雑になって信用できません。安かろう悪かろうでは人間やAIが間違った指摘に振り回されたり、指摘内容が妥当かを毎回検証する羽目になり、自動化した意味がなくなります。
というわけで「フロンティアモデルの一個下で、費用と性能のバランスのいい中堅どころ」で、3系統からそれぞれ一つずつ選びました。
- GPT系: GPT 5.4 mini
- Claude系: Claude Sonnet 4.6
- Gemini系: Gemini 3.5 Flash
スペックと料金を並べるとこんな感じです。
| モデル | 入力 (/1M tokens) | 出力 (/1M tokens) | コンテキストウィンドウ |
|---|---|---|---|
| GPT 5.4 mini | $0.75 | $4.50 | 400K |
| Claude Sonnet 4.6 | $3.00 | $15.00 | 1M |
| Gemini 3.5 Flash | $1.50 | $9.00 | 1M |
| （参考）GPT 5.5 | $5.00 | $30.00 | 1.05M |
| （参考）Opus 4.8 | $5.00 | $25.00 | 1M |
料金は記事執筆時点（2026年6月）の各社の公開価格です。プロンプトキャッシュやバッチ適用でもっと下がる余地はありますが、ここでは素の単価で比較しています。
参考にフラッグシップ二つも入れましたが、出力単価で見るとGPT 5.4 miniとGPT 5.5で6倍以上の差があります。大量にPRが飛ぶ前提だと、この差がそのまま月額に跳ね返ってきます。コンテキストウィンドウはどれもdiff一回分には十分なので、今回は判断材料から外しました。
実際にレビューさせてみる
3モデルそれぞれでPRをレビューするワークフローをGitHub Actionsで実装しました。トリガーはPRのopen/synchronize、diffを取ってきてプロンプトに詰めてAPIを叩き、結果をコメントとしてぶら下げるだけのシンプルな構成です。3モデルともに公式のGitHub Action用のアクションが公開されており、これらを利用しました。
公平に比べたいので、プロンプトは3モデルとも完全に同一にしました。レビュー観点も出力フォーマットも一字一句変えていません。ここを揃えないと、後の評価がモデルの実力じゃなくプロンプトチューニングの巧拙の話になってしまいます。
あとは普段の開発で実際に流れているPRに、3モデル分のレビューを同時に走らせて、しばらくコメントを溜めていきました。
性能をどう測るか
問題はここからで、「どのレビューが良かったか」をどう判定するかです。コメントを全部人力で読み比べるのは大変なのと、レビュー内容を評価するときに主観は排除すべきです。
そこで今回はいわゆる LLM as a judge を使いました。3モデルが出したレビュー内容を、それより明確に格上のモデル（GPT 5.5とOpus 4.8）に採点させ、評価対象より一段高い目線でジャッジしてもらう方式です（本当はFableを使いたかったのですが、この検証をする前にFableが停止されてしまいました...）
評価基準で何を重視するかは事前に決めておきました。我々のコードレビューで本当に困るのは「重大な問題を見逃すこと」であって、多少の空振りは許容できます。なので、Critical/Majorの検知率を優先しつつ、誤検知の少なさと網羅性も評価するという方針にしました。瑣末な指摘をいくら積んでも、本番を落としかねないバグを一個スルーされたら話にならないという思想です。コードレビューで何を重視するかはチームによるため、この記事を読んで同じことを試される場合には性能評価の優先度を事前に決めておき、評価用のLLMに渡すプロンプトの中で明示しておくとよいと思います。
始める前の予想
採点を見る前に、自分なりの予想を立てていました。
うちの普段の開発はCodex（GPT 5.5）が中心です。つまり書いたコードはすでに同系統のGPTにかなり目を通されている状態です。だとすると、同じGPT系で安価なGPT 5.4 miniは「Codexが見たのと同じ穴」しか見つけられず、毛色の違うClaudeやGeminiのほうが、Codexの見落とした未知の不具合を拾ってくれるのではないか、と踏んでいました。
加えて、3モデルの中で料金的にいちばん高いのはSonnet 4.6です。高いんだから一番賢いはず、という素朴な期待もあって、正直いちばん当てにしていたのはSonnetでした。
結果
GPT 5.5とOpus 4.8による評価結果はそれぞれ以下のようになりました。採点が出揃って、それぞれの傾向がきれいに分かれたのが面白かったです。
2つのAIでやや評価が分かれていますが、傾向としては「ノイズが少なく検知力の安定するGPT 5.4 mini」「ノイズは多いが網羅性が高くたまに重大な不具合を検知するGemini 3.5 Flash」「ノイズが少なく安定しているが軽微な指摘に終止しがちなSonnet 4.6」という結果でした。
「Codexと同系統のGPTより、毛色の違うClaudeやGeminiのほうが未知の不具合を拾うはず」という読みは、検知力に関してはGeminiが当ててみせました。ただ、そのぶんノイズも多く、最終的に運用で扱いやすかったのは同系統のGPT 5.4 miniとなりました。一方で「いちばん高いSonnetがいちばん賢いはず」という期待は完全に外れ、Sonnetは軽微な指摘に終始しました。値段と賢さは別ですし、検知力と運用しやすさもまた別。あたりまえの教訓を、お金を払って再確認した格好です。
念のため、評価が高かったPRと低かったPRをいくつかピックアップして自分の目でもレビューを読み比べてみましたが、judgeの判定とおおむね一致していました。検知力のGemini、運用のしやすさのGPT、補助のSonnetという住み分けは、肌感としても納得のいくものでした。
おわりに
注意したいのは、これは「うちのコードベースとうちのプロンプトでの結果」でしかないということです。言語やフレームワーク、レビュー観点が変わればランキングは普通にひっくり返ると思います。Sonnetの「スタイルとテストに細かい」性質も、チームによっては逆にありがたいはずです。
とはいえ、自前で組んでみて分かったのは、レビュー用途なら必ずしもフラッグシップは要らないということでした。中堅モデルでも観点さえ揃えれば実戦投入できる精度は出ます。レートリミットに振り回されるくらいなら、GitHub Actionsで自作してしまうのは案外悪くない選択でした。
さらに精度を上げるなら、複数のモデル（今回の結果からだとGPT 5.4 miniとGemini 3.5 Flash）で並列で評価をして、最終的にアグリゲーションした結果をレビュー内容とするような工夫でさらに精度が向上する余地がありそうです。ただし、その分コストが倍かかるのと、レビューにかかる時間が伸びるため、そこまでやるべきかは微妙なところです。モデルの進化が非常に速く、次世代のSonnetが出たら一気に他の2系統を抜く可能性もあります。しばらくはGPT 5.4 miniをメインで運用しながらプロンプトのチューニングを行う予定です。
（宣伝：エンジニア絶賛募集中です！）
