TL;DR: 同じコードレビュータスクをClaudeの4つのtierに投げ、その後、別ベンダーのLLMベースのコードレビューツール（Claudeモデルではない）に、すべての指摘を「確認済み」「却下」「不明」のいずれかに判定してもらった。tierをトークン単価だけで比較するのは間違っている——最安tierはトークン単価では10倍安かったが、「確認済みバグ」1件あたりで見ると約3.7倍安いにとどまった。
検証したこと
Claudeの4つのモデル（安価tier=Haiku 4.5、中位tier=Sonnet 4.6、上位tier=Opus 4.8、最上位tier=Fable 5、トークン単価はおおよそ1倍・3倍・5倍・10倍）に、同じ3つのファイルを独立してレビューさせた。2つはデータ収集スクリプト、1つは財務指標抽出コードで、いずれも実運用中の本物のコード。プロンプトも対象ファイルも指示も同一——「あらゆるバグを見つけよ、特にサイレントに失敗してクラッシュではなくもっともらしい誤答を返すタイプのものを」。
各モデルはseverity（P1が最高）でタグ付けされた指摘リストを返す。ここで止まらず、ファイルごとに4モデル全員のclaimをプールし、テスト対象とは別ベンダーのLLMベースのコードレビューツールに実コードを読ませ、claimごとに「確認済み」「却下」「不明」の判定と、コードを引用した一行の理由を出させた。
tier別の結果
| tier | モデル | 監査対象claim | 確認済み | 却下 | 精度 | 総コスト | 確認済みバグ単価 | 確認済みバグあたりトークン数 |
|---|---|---|---|---|---|---|---|---|
| 安価tier | Haiku 4.5 | 41 | 28 | 6 | 68% | $0.51 | $0.018 | 63,406 |
| 中位tier | Sonnet 4.6 | 42 | 39 | 0 | 93% | $1.33 | $0.034 | 28,099 |
| 上位tier | Opus 4.8 | 44 | 39 | 0 | 89% | $2.16 | $0.055 | 31,341 |
| 最上位tier | Fable 5 | 58 | 57 | 1 | 98% | $3.87 | $0.068 | 15,627 |
安価・中位・上位tierのclaim件数は、4モデル全員のclaimをプールして近い重複をマージした監査パスの結果。最上位tierの全claim集合は別途、マージなしで1件ずつ監査している。集計上の違いであって発見そのものではないが、正確な比率をこの非対称性以上に精密なものとして読むべきではない。
素朴な読み方は逆を示す
severity1（P1、最高）のclaim件数だけを見ると、安価tierは最上位tierのほぼ2倍のP1件数で最もお得に見える。件数を指標にするなら「高いモデルの方がバグを見つけるのが下手」という結論になる。
そうではない。全severityを含む完全なclaim集合で見ると、研究全体で出た7件の却下claim（監査者がコードを読んで「明確に間違っている」と判定したもの）のうち6件は安価tierから出ていた。唯一の例外は最上位tierの、より網羅的で別途監査されたclaim集合から出たもの。重要なのは、却下された7件のうち1件もP1タグは付いていなかったこと——安価tierの6件はすべてP2かP3、名前空間のパース・タイムスタンプの書式・ファイル検出のエッジケースについての、もっともらしいが実コードとは異なる推測だった。
「トークン単価」が隠すもの
最上位tierはトークン単価で安価tierの10倍。素朴に考えれば確認済みバグ単価も同程度の差になりそうだが、実際には約3.7倍にとどまった。
理由の一部はトークン効率にある。最上位tierは確認済み1件あたり、安価tierのおよそ4分の1のトークンで済んでいる（63,406 対 15,627）。安価tierのおよそ半分のトークン総量で、確認済みバグ数はおよそ倍——この2つの比率を掛け合わせると、確認済みバグあたりトークン数でおよそ4倍のアドバンテージになる。
これがきれいに10倍の定価差を割って3.7倍を導き出すわけではない。定価は単一の数字ではなく、キャッシュされたコンテキストは新規入力より大幅に割引されて課金され、その混合比率が4tierで異なるからだ。「このタスクでは定価が実コスト差を過大に見せる」というのが発見であって、公式ではない。
価格とは関係ない部分: 検証行動
4モデルのうち2つは、誰にも頼まれていないことをやった——実際に確認しに行ったのだ。財務指標抽出コードで、あるモデルは子会社の単体収益を親会社の連結数値であるかのようにサイレントにラベル付けするコードのケースを指摘し、さらに実際のfilingを開いて実数値がおよそ4倍ずれていることを確認した。
中位tierは純粋な静的推論だけで（実行なしで）同じ最高severityの結論の多くに到達していた。捕まえたケースについては、より安価に正解にたどり着く経路だが、特定のファイルの特定の数値に依存するclaimには自動的には拡張されない。
この話の限界
- タスク特異性。 検証可能で高リスクな、検証しやすいコードレビューに当てはまる話であって、4tierの普遍的な序列ではない。
- 統計的限界。 単発の評価であり、誤差幅はない。
- 監査の非対称性。 最上位tierのみ1件ずつ監査、他3tierはプールしてマージ。
- severityクロス集計、部分的。 却下claimがP1ではなかったことは確認したが、全tierのseverity加重精度は未完了。
まとめ
誤答のコストが高いタスクでモデルtierを選ぶなら、「トークン単価が最も安いか」ではなく「本当に信頼できるバグ1件はいくらか」を問うべき。今回の4tierすべてで確認済み1件あたり2〜7セント程度——最上位tierでも絶対額としては安い。トリアージ作業を省くための小さなプレミアムを払うか、自分で仕分けるか、というのが実質的なトレードオフだ。
本稿は、我々が日々AIシステムをどう実運用しているかを記録し続けているシリーズの一部です——ベンチマークスコアではなく、運用上の判断そのものを扱っています。