AIコードレビューが主流になりつつあります。Anthropicは最近、GitHubのPR用マルチエージェントレビュー system for GitHub PRs. It optimizes for 深さ を最適化しており、1回のレビューの費用はおおよそ$15-$25です:

Claude Code Reviewの価格に関するAnthropicのツイート。

私たちはしばらくの間 Kilo Code Reviewer を使っていますが、人々がそれを気に入っている点の一つは、異なるモデルを選べることです。

この投稿では、別の点に焦点を当てます：コスト。この投稿では、2つの異なるモデルを用いて実際のオープンソースPR上でKilo Code Reviewerを実行し、すべてのトークンと金額を追跡します。

セットアップ

このテストでは、実世界の例にできるだけ近づけるため、TypeScriptのウェブフレームワークである Hono の実際のコミットを使用しました（GitHubで約4万スター）。

このリポジトリを v4.11.4 でフォークし、そのベースに対して PR を作成するために、実際の2つのコミットをチェリーピックしました：

• 小さなPR（338 行、9 ファイル）:コミット 16321afd は getConnInfo の接続情報ヘルパーを AWS Lambda、Cloudflare Pages、Netlify アダプター向けに追加し、完全なテストカバレッジを備えています。3つのアダプター ディレクトリにまたがる9つの新しいファイル。

• 大型PR（598 行、5 ファイル）:コミット 8217d9ec は JSX のリンク要素のホイスティングと重複排除を React 19 の意味論に合わせて修正します。5ファイルで575行の挿入と23行の削除、うち485行が新しいテストです。

どちらも実際の貢献者によって書かれた実際の変更であり、どちらもHono v4.12.xに実装されています。

私たちは、スペクトラムの両端にある2つのモデルで同じ差分を走らせるために、各PRごとに重複したブランチを作成しました：

• Claude Opus 4.6、Anthropicの現時点での最前線モデルであり、Kilo Code Reviewerで利用可能な最も高価なオプションの1つです。

• Kimi K2.5、Moonshot AI のオープンウェイト MoE モデル（総パラメータ1兆、トークンあたり320億の活性化）で、トークンあたりの価格はごく一部です。

両モデルはBalancedレビュー形式でPRを審査し、すべてのフォーカスエリアを有効にしました。

コスト結果

最も費用が高かったレビューは、598行のPRでのClaude Opus 4.6です。その費用は$1.34でした。

さらに詳しく見ていきましょう。

トークン使用量の内訳

Kilo Code Reviewerは差分を読むエージェントを配置し、その文脈を得るために周囲のファイルを取り込みます。モデルごとにアプローチは異なり、私たちの4つのレビューにおけるトークン使用量の差はそれを示しています。

1. Small PR (338 行). Opus 4.6 は 618,853 入力トークン を使用しました。Kimi K2.5 は 同じ差分に対して 3×59,556 を使用しました。つまり、同じコード変更に対して入力トークンが約72%多くなっています。

出力トークンは類似していました（6,142 vs 5,374）。差はほとんど、レビューエージェントが周囲のコードをどれだけ取り込んだかに依存します。Opus 4.6は、Lambdaアダプターがサポートするイベントタイプを理解するために、既存の handler.ts ファイルを取り込み、それによって欠落していた LatticeRequestContextV2 型を検出しました。Kimi K2.5は差分により近づき、問題を見逃しました。

2. Large PR (598 行). Opus 4.6 は 1,184,324 入力トークン を消費しました（Kimi K2.5 の 219,886 の約5.4倍）。Opus 4.6 は JSX レンダリングコードベースの多くを取り込み、変更を評価する前に既存の重複排除ロジックがどのように機能したかを理解しました。Kimi K2.5 はより軽い検査を行い、問題を見つけませんでした。

費用を左右する要因

レビューの費用は3つの要因に左右されます。

1. トークンあたりのモデル料金。

• Claude Opus 4.6 は、入力トークン100万あたり$5、出力トークン100万あたり$25 です。

• Kimi K2.5 は、入力トークン100万あたり$0.45、出力トークン100万あたり$2.20 です。

これは、トークンあたりの価格が約10倍の差であり、最大のコスト要因です。

2. エージェントが読む文脈の量。 レビューエージェントは差分だけを見ているわけではありません。

変更の文脈を理解するために関連ファイルを取り込みます。

モデルによってこれに取り組む方法は異なり、あるモデルは他のモデルよりもはるかに多くの周囲コードを読みます：

• Opus 4.6 は、私たちの2つのPRにまたがって618K-1.18M 入力トークンを読み込みました。

• Kimi K2.5 は、219K-359K を読み込みました。

より多くの文脈は、より多くのトークンとなり、費用が高くなります。

3. PRのサイズ。 大きな差分は審査するコード量を増やし、周囲の文脈を取り込む量を増やします。

• 私たちの598行PRは、Opus 4.6の338行PRより83%多くかかりました ($1.34 対 $0.73)。

• Kimi K2.5 では、大きなPRの費用は小さなPRより実際には安くなりました ($0.05 対 $0.07)、おそらくエージェントが堅牢にテストされた JSX 変更に対してより軽い検査を行ったためです。

課題1件あたりのコスト

データをもう1つの見方として、見つかった課題1件あたりのコストです。

小さなPRでは、Kimi K2.5は見つかった課題がより多く、1件あたりのコストが低く（$0.02 対 $0.37）でした。しかし、発見内容の性質は異なっていました。Opus 4.6は差分外のファイルを読む必要がある問題を見つけました（欠落していたLatticeイベントタイプ、XFF偽装リスク）。Kimi K2.5は差分自体の防御的コーディングに焦点を当てました（ヌルチェック、エッジケース）。

大型のPRでは、Opus 4.6が$1.34の実際の問題を1件見つけました。Kimi K2.5は$0.05で問題を見つけませんでした。

これら2つのコミットはHono v4.12.xとして出荷されました。Opus 4.6が見つけた問題（欠落していたLatticeイベントタイプ、shouldDeDupeByKey の潜在的な TypeError）は実際のリリースコードに含まれています。生産リリースに移る前に小さなバグを捕捉する $1.34 のレビューは、デバッグ時間の回避と潜在的なインシデント対応を何倍にも節約します。

課題1件あたりのコストはPRごとに異なります。クリーンでよくテストされたコード（485行のテストを含む JSX 修正のような）は、モデルに関係なく発見を減らします。表面積が大きいコード（3つのクラウドプロバイダーにまたがるマルチアダプターPRのような）は、両モデルから発見を生み出しますが、深さは異なります。

平均的なチーム利用を想定した月額コスト

私たちは、10人の開発者からなるチームを前提に、1日あたり各自3件のPRを開く3つのシナリオをモデル化しました（おおよそ月間660件のPR）

フロンティア推定は、当社の Opus 4.6 の 2 件のレビューの平均（$1.04）を使用します。予算推定は、当社の Kimi K2.5 の 2 件のレビューの平均（$0.06）を使用します。混合アプローチは、PR の 20%（main へのマージ、リリースブランチを含む）がフロンティアレビューを受け、80% が予算レビューを受けると仮定します。

各価格帯で得られる内容

安価なモデルは検出する問題が少ない。以下は、同じコード上で各モデルが見つけた問題です。

小さなPR の Claude Opus 4.6 ($0.73) は 2 件の問題を見つけました。LambdaRequestContext の結合型に欠落している型を検出し（LatticeRequestContextV2 のイベントタイプは処理されていませんでした）、X-Forwarded-For ヘッダ解析が最初の IP を信頼しているため、ロードバランサの背後で偽装され得ることを指摘しました。どちらの発見も、差分外のコードを理解する必要がありました。

小さな PR の Kimi K2.5 ($0.07) は 3 件の問題を見つけました。c.env の null チェックが欠落していること、空の X-Forwarded-For ヘッダが空文字を生成し、undefined の代わりになるという端点ケース、そして不要なテストアサーションを指摘しました。また、差分外の問題として、テストファイルが現実的な IP の代わりにランダム値を使用していることや、Netlify アダプターには公開されていない有用なジオデータがあることも挙げられました。

大きな PR の Claude Opus 4.6 ($1.34) は 1 件の問題を見つけました。エクスポートされた shouldDeDupeByKey 関数は、予期しないタグ名で呼び出された場合に TypeError をスローすることを示しました。未知のキーには deDupeKeyMap[tagName] が undefined を返すためです。レビューには PR の目的と、変更が React 19 の挙動とどのように整合するかの要約も含まれていました。

大きな PR の Kimi K2.5 ($0.05) は 0 件の問題を見つけず、マージを推奨しました。レビューの要約は、PR が何をするかを正しく説明し、テストカバレッジが十分であることを指摘しています。

小さな PR では、両方のモデルが実際の問題を見つけましたが、異なる内容でした。Opus 4.6 の発見は、差分外のファイルを読んで Lattice イベントタイプを理解したことに由来します。一方、Kimi K2.5 は差分自体の防御的コーディングパターンに焦点を当て、件数では多くの問題を見つけました（3 対 2）ですが、深刻度は低めでした。

大きな PR では、差がよりはっきりしていました。Opus 4.6 は Kimi K2.5 が見逃した実際の潜在的な TypeError を検出しました。

モデル選択のポイント

コードレビューにおいて選ぶモデルは、何を最適化するかによって決まります。

重要な PR に対して最大の網羅性を求める場合、Claude Opus 4.6 のようなフロンティアモデルは、差分外のコードを理解する必要がある問題を読み取り検出します。私たちの最も高価なレビューは、598 行の PR で $1.34 でした。

すべての PR でコスト効率の高いスクリーニングを望む場合、Kimi K2.5 のような予算モデルは、コストの一部で実際の問題を検出します。最も安いレビューは $0.05 でした。すべてを検出するわけではありませんが、ほとんど費用をかけずに、すべての変更について基礎的なチェックを提供します。

両方を望む場合、PR に応じて Kilo Code Reviewer のモデルを切り替えることができます。日常の機能ブランチのレビューには予算モデルを、main へマージしたりリリースを切ったりする際にはフロンティアモデルへ切り替えます。私たちの混合シナリオの推定は、660 PR につき月額約 $165 でした。

私たちが以前のコードレビュー投稿でテストした無料モデル（前回のコードレビュー投稿、Grok Code Fast 1、MiniMax M2、Devstral 2）も別の選択肢です。Grok Code Fast 1 は、仕込まれたセキュリティ脆弱性を 100% 検出し、そのテストで Claude Opus 4.5 の検出率と同等でした。無料モデルはベータ期間中、1 回のレビューあたり $0 です。

結論: フロンティアモデルはより多くの文脈を読み取り、より深い問題を検出し、費用は高くなります。予算モデルは表面的な問題を迅速かつ安価に検出します。しかし、フロンティアの端でも、ユーザーへ公開される前の 1 つのバグを検出する $1.34 のレビューは、デバッグの回避、ホットフィックス、インシデント対応の回避によって何倍も元を取ることになります。1 回のレビューあたり $0.05-$1.34 の範囲では、どのモデルを選択しても数学的には成り立ちます。