AIモデルルーティングのベンチマーク：トークン単価よりもタスク単価が重要

トークン単価はモデルの料金を示すものであり、業務を完了させるためのコストを示すものではありません。タスク単価に基づくAIモデルルーティングのベンチマークは、再試行、コンテキスト長、出力の冗長性（実際に請求書に反映される数値）を含め、正確で利用可能な出力を得るためにかかる総支出を測定するものです。

重要なポイント

• トークン単価は、再試行、冗長性、完了の失敗を無視しており、これらはすべてタスクの真のコストを変化させます。
• タスク単価は出力の長さと成功率を正規化するため、モデル間の比較が有意義になります。
• 単なる「安価な」モデルへの切り替えよりも、最低料金ではなくタスクタイプごとにモデルを選択するルーティングロジックの方が、総支出を削減できる傾向があります。
• コーディング、動画、画像タスクでは失敗や再試行のプロファイルが異なるため、ベンダーが公開する料金表を鵜呑みにするよりも、独自のワークロードをベンチマークする方が効果的です。

なぜトークン単価が誤った指標なのか

トークン価格は経済学者が好み、プロダクトチームが誤用しがちな単位です。入力トークン100万あたり0.15ドルのモデルは、0.50ドルのモデルよりも安く見えますが、その比較が成り立つのは両方のモデルが同じ出力長で、かつ最初の試行で成功した場合のみです。

実際には、そのようなことはほとんどありません。説明文で回答を埋め尽くす冗長なモデルは、同じ質問をされても簡潔なモデルの3倍の出力トークンを消費することがあります。マルチステップのコーディングタスクにおいて推論能力の低いモデルは、コンパイル可能な結果を得るために2〜3回の再試行が必要になることが多く、再試行のたびに完全なコンテキストウィンドウが再送信されます。Fireworks AIのブログでは、スループット最適化モデルと精度最適化モデルを比較する際にこのパターンが繰り返し文書化されており、再試行率を考慮に入れると、生のトークン価格と実効タスク価格が乖離することが指摘されています（fireworks.ai/blog、2026年7月7日確認）。

その結果、単にリスト上のトークン価格だけでモデルを選択するチームは、タスクの成功率に基づいて選択するチームよりも、完了したタスクあたりのコストが高くなることがよくあります。失敗した試行もトークンを消費し、レイテンシに起因するエンジニアリングのオーバーヘッドを増加させるためです。

タスク単価が実際に測定するもの

タスク単価は、以下の式から導き出される指標です：

タスク単価 = (入力トークン数 x 入力単価 + 出力トークン数 x 出力単価) x 成功までの平均試行回数

「成功までの平均試行回数」という項目は、トークン単価の比較では完全に無視される部分です。これには、テストスイートの通過、JSONスキーマへの適合、利用可能な画像のレンダリング、動画生成における品質しきい値の達成など、ワークロードにとって「成功」が何を意味するのかを定義する必要があります。

これが、一般的な価格比較から得られるような単純な料金比較が、出発点にはなっても最終的な答えにはならない理由です。それは各プロバイダーがトークンあたりいくら請求するかを示すだけであり、特定のタスクタイプで平均して何トークン必要か、あるいは特定のモデルが何回に1回再試行を必要とするかまでは教えてくれません。

ベンチマーク設定：タスクタイプ間でのモデル比較

有用なルーティングベンチマークは、タスクのカテゴリごとにワークロードを分離します。失敗モードや冗長性がカテゴリ間で大きく異なるためです。

タスクタイプ	主なコスト要因	典型的な失敗モード	現在のモデルの確認先
コード生成	コンパイル/テスト失敗時の再試行率	ロジックエラー、不完全な関数	コーディングに最適なAIモデル
長文テキスト	出力トークンの冗長性	パディング、トピックからの逸脱	OpenRouter比較
画像生成	画像ごとの固定料金 vs 解像度ティア	プロンプトの誤解釈、再生成の必要性	最適なAI画像モデル
動画生成	秒単位のレンダリングコスト	再レンダリングが必要なアーティファクト	最適なAI動画モデル

テキストやコードのタスクについては、一般的なベンチマークスイートではなく、独自のログから抽出した固定の代表的なプロンプトセットに対して各候補モデルを実行してください。モデルごとに、平均入力トークン数、平均出力トークン数、初回試行の成功率の3つの数値を追跡します。プロバイダー間で価格が頻繁に変更されるため、直接確認した最新の公開料金を使用して、上記の式で計算を行ってください。TokenLabのモデルディレクトリには、プロバイダー全体の最新料金とコンテキストウィンドウがまとめられており、独自のテストを実行する前のベースライン数値の取得に役立ちます（tokenlab.sh/en/models、2026年7月7日確認）。

画像や動画のタスクでは、価格設定が通常トークン単位ではなく出力単位であるため計算はより単純ですが、同じ原則が適用されます。画像あたりの価格は低いものの、プロンプトの読み取りミスによる再生成率が高いモデルは、受け入れ可能な出力あたりのコストが高くなる可能性があります。

タスク単価を削減するルーティング戦略

いくつかのモデルのタスク単価が算出できれば、ルーティングの決定は「お気に入りのプロバイダーを選ぶ」ことではなく、機械的な作業になります。

デフォルトモデルではなく、タスクカテゴリごとにルーティングしてください。コーディングタスクと長文作成タスクでは、同じプロバイダーのラインナップ内であっても最適なモデルが異なります。すべてを1つのデフォルトモデルに送信するルーターは、そのモデルが単純なタスクに対して過剰にプロビジョニングされ、複雑なタスクに対して不足している場合、コスト削減の機会を逃しています。

タスクタイプごとに再試行予算を設定してください。タスクタイプの初回成功率がしきい値を下回る場合は、安価なモデルで無期限に再試行するのではなく、再試行を制限して、より強力で高価なモデルにフォールバックしてください。安価なモデルでの3回の失敗は、高価なモデルでの1回の成功よりもコストがかかる可能性があります。

冗長性が価値を生まない場合は、出力長を制限してください。JSON、コード差分、APIレスポンスなどの構造化された出力については、最大トークン数を制限するか、簡潔な出力を指示するシステムプロンプトを使用してください。これにより、モデルを変更することなく、タスク単価の式における出力トークンの項を直接削減できます。

四半期ごとにベンチマークを再実施してください。プロバイダーの価格やモデルのバージョンは頻繁に変更されるため、6か月前に調整したルーティング設定が、タスクごとの最安値ルートを反映していない可能性があります。ライブのモデルリーダーボードを表示することで、新しいモデルが登場した際に特定のカテゴリのタスク単価ランキングがどのように変化したかを把握しやすくなります。

チェックリスト：タスク単価に基づいたモデルルーターの評価

ルーティング設定を確定する前に、以下を確認してください：

• 記憶や古い比較記事ではなく、プロバイダーから直接最新のトークン/出力単価を取得したか
• タスクカテゴリごとに少なくとも20個の代表的なプロンプトを各候補モデルで実行したか
• モデルごと、タスクタイプごとに、平均入力トークン数、平均出力トークン数、初回試行成功率を記録したか
• 生のトークン単価ではなく、再試行調整後の式を使用してタスク単価を計算したか
• 定義されたフォールバックモデルを用いて、タスクカテゴリごとに再試行上限を設定したか
• 構造化タスクや短文回答タスク向けに最大出力トークン数を制限したか
• モデルや価格の更新に合わせてランキングを再確認する定期的なレビュー（月次または四半期）をスケジュールしたか

エビデンスの境界

モデルルーティングの研究は、3種類のエビデンスを組み合わせたときに最も強力になります。公開されているモデルディレクトリや公式の価格ページは、その時点での単価と可用性を示します。Artificial Analysisのような独立したパフォーマンスソースは、速度、レイテンシ、広範な品質シグナルを明らかにするのに役立ちます。RouteLLMを含むルーター研究は、ルーティングポリシーが許容可能な品質を維持しながらコストを削減できる理由を説明していますが、依然としてワークロード固有のラベルと評価データに依存しています。

公開されたルーティング結果を、普遍的な節約見積もりとしてそのまま自分のスタックにコピーしないでください。真の節約は、プロンプトの組み合わせ、成功の定義、再試行予算、フォールバックポリシーから生まれます。カスタマーサポートの分類器、コーディングエージェント、動画ジョブオーケストレーターは、それぞれ失敗のコストが異なります。ここで引用したソースは、独自のベンチマーク設計のための足場として扱ってください。それらは何を測定すべきかを説明し、あなたのログと評価セットがどのモデルが実際に勝者であるかを決定します。

FAQ

トークン単価が低いことは、常にタスク単価が低いことを意味しますか？ いいえ。再試行率と出力の冗長性が、トークン単価の安さを完全に相殺してしまう可能性があります。トークン単価は高くても、初回成功率が高く、出力スタイルが簡潔なモデルの方が、完了したタスクあたりのコストが低くなることはよくあります。安価な料金が勝つと仮定する前に、独自のプロンプトを使用して両方をテストしてください。

タスク単価の数値を信頼するには、何件のテストプロンプトが必要ですか？ 固定のルールはありませんが、タスクカテゴリあたり15〜20件未満のプロンプトでは、特に合否がバイナリであるコーディングタスクにおいて、成功率の推定値が不安定になる傾向があります。難易度が変動するタスクタイプでは、サンプルサイズが大きいほど重要になります。

シンプルにするために、すべてを1つのプロバイダーでルーティングすべきですか？ シンプルさにはコストがかかりますが、断片化にもコストがかかります。OpenRouter比較や価格比較ページなどのリソースを使用してプロバイダーを直接比較し、特定のタスクミックスにおいてマルチプロバイダールーティングが追加の統合作業に見合う価値があるかどうかを判断してください。コード、テキスト、画像、動画生成にわたって大量の処理を行うチームにとっては、単一プロバイダーのデフォルト設定よりも、プロバイダーをまたいだタスクベースのルーティングの方が一般的です。

---

プロバイダー全体の最新料金、コンテキストウィンドウ、タスク別のランキングを1か所で確認するには、独自のタスク単価テストを実行する前に、TokenLabモデルディレクトリで利用を開始してください。

ベンチマークを実行したら、結果をフィールドと比較してください。モデルリーダーボードを閲覧して、選択したモデルが現在の価格とパフォーマンスデータでどの位置にランク付けされているかを確認しましょう。