結論から書きます。AIの利用料は、公表されているトークン単価だけでは見積もれません。IBM Researchが同じ417タスクで比較したところ、単価の安いモデルの総額が155ドル、単価の高いモデルが79ドルと、実測で約2倍ひっくり返りました。比べるなら小さく試して実請求額で見るしかありません。
何が測られたのか（一次資料の実測）
IBM Researchが公開した記事「Model Routing Is Simple. Until It Isn't.」に、エージェント運用のコスト実測が載っています。条件は AppWorld Test Challenge というベンチマークの417タスクを、CodeAct形式のエージェントで最後まで走らせる、というものです。同一条件で使うモデルだけを差し替えて比較しています。
| 比較項目 | Claude Sonnet | GPT-4.1 |
|---|---|---|
| 総コスト | 79ドル | 155ドル |
| 1タスクあたり | 0.19ドル | 0.37ドル |
| タスク数・条件 | AppWorld Test Challenge 417タスク／CodeActエージェント | 同一条件 |
公表されているトークン単価は GPT-4.1 のほうが安いにもかかわらず、実測の総額はおよそ2倍になりました。著者はこの逆転の主因をキャッシュの効き方だと説明しています。エージェントは1タスクを終えるまでに何度も往復するため、過去のやり取りを再送する量と、それがキャッシュに乗るかどうかで請求額が大きく動く、という構造です。
もう一つ、モデルの振り分け（ルーティング）を入れた構成の実測も出ています。レイテンシを最適化した振り分け構成では、精度84%、コスト93ドル、レイテンシ83秒。これを Opus 単独で回した場合と比べると、コストは21%減、レイテンシは9%減、その代わりに精度は4ポイント低下しました。振り分けアルゴリズム自体の処理コストは1タスクあたり約6ミリ秒、メモリ約2kBとされています。
（出典：IBM Research（著者: Yara Rizk、Eyal Shnarch、Jason Tsay、Merve Unuvar）、2026-07-15、https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt）
なお、この記事は IBM Research 自身による発表であり、同社はエンタープライズ向けAI基盤およびエージェント技術の提供者です。つまり「モデルの振り分けは有効だ」という結論が出ることに利害関係のある発信元が、自ら測って自ら公開した数字だという点は、読む側が最初に把握しておくべき前提です。数字そのものを疑えという話ではなく、都合のよい条件が選ばれていないかを自分の目で確かめる必要がある、という意味です。
読者への意味：見積書の数字はどこから来ているか
中小企業の経営者・情報システム担当にとって、この実測が持つ意味は一点に集約されます。AI導入の見積もりが「トークン単価×想定利用量」だけで組まれていたら、その数字は実請求額と乖離しうる、ということです。
なぜ乖離するのか。理由は大きく2つです。
- 1タスクを終えるまでの往復回数（推論の長さ）がモデルごとに違い、単価が安くても往復が多ければ総額は膨らむ
- 過去のやり取りがキャッシュに乗るかどうかで、同じ作業でも課金対象のトークン量が変わる
どちらも、カタログに載っている単価表からは読み取れません。だから比較の方法は一つしかありません。候補を2つに絞り、同じ業務・同じ件数で小さく走らせて、月末の実請求額を並べる。これ以外に正しい判断方法はありません。見積もりの前提を業者に聞くときは、「その金額は実測ですか、単価からの計算ですか」と一言確認するだけで、精度がかなり変わります。
コストの内訳をどう分解して見るかについては、AIの利用コストは何で決まるのか で整理しています。あわせて、評価そのものにコストの観点を組み込む考え方は コストを含めて評価する が参考になります。
「全部いちばん賢いモデル」以外の選択肢はあるのか
もう一つ実務的な材料が、振り分けの数字です。用途ごとに高性能モデルと軽量モデルを使い分けると、コスト21%減・レイテンシ9%減という結果が出ています。ただし精度は4ポイント落ちています。
これは無条件の改善ではありません。削れたコストは、落ちた精度と引き換えです。判断すべきは「4ポイントの精度低下を許容できる業務かどうか」であって、「安くなるからやる」ではありません。社内向けの下書き生成や一次分類なら許容できるかもしれませんが、見積書の金額計算や契約書の条項確認のように、間違いが直接損害になる業務では話が違います。
同じ記事の中で、難易度ベースの単純な振り分けは、同等の精度をより高いコストで達成した、とも報告されています。つまりやり方を間違えると、複雑さだけ増えて何も得られないということです。振り分けは「やれば得する仕組み」ではなく、設計次第で損もする仕組みだと理解しておく必要があります。
振り分けの効果がどこまで一般化するかという論点は ルーティングの上限は領域に依存しないのか でも扱っています。用途に応じてモデルや道具を選ぶ考え方全般は AIツールの選び方 を参照してください。
この数字が当てはまらない範囲
誠実に書いておくべき限界が、記事自体に複数明示されています。
- 著者は、コスト逆転の原因が「モデル・ワークロード・サービング基盤の相互作用に依存する」と述べています。同じ結果が別の環境で再現する保証はありません
- タスクの難易度は振り分けの時点では見えない（difficulty is often invisible at routing time）と認めており、事前に難易度を判定して振り分けるという発想自体が原理的に不確実です
- ステップ単位で細かく振り分ければ適応性は上がるものの、レイテンシと運用の複雑さが増す、とトレードオフが明示されています
- 検証は AppWorld という単一ベンチマークのみで、業種別・業務別の一般化可能性は示されていません
- 振り分けアルゴリズム自体の処理コスト（約6ミリ秒、メモリ約2kB）については、測定環境や試行回数の記載がありません
- 記事は後続の技術記事を予告しており、この時点では手法の詳細や再現手順は公開されていません
- 前提は数百タスク規模のエージェント運用です。社内で数人がチャット用途に使う程度の規模には、この数字は直接当てはまりません
最後の点は特に重要です。417タスクを自動で回し続けるエージェント運用と、担当者が1日に数十回チャットを打つ使い方では、キャッシュの効き方も往復回数もまるで違います。自社がどちらの使い方をしているのかを先に確認してください。
TOEの読み筋
はじめに明記します。TOEでは、この記事で紹介されているモデル振り分け構成を実施していません。以下は実測ではなく、公開された数字をどう読むかという解釈です。
その上で、この記事から実務に持ち帰るべきものは、振り分け技術そのものではなく、「公称値と実測値は違う」という一点だと考えています。振り分けの設計は、数百タスク規模で継続的にエージェントを動かしている組織の課題であり、多くの中小企業にとってはまだ先の話です。一方で、単価の安いモデルを選んだのに請求額が想定の倍だった、という事態は、規模が小さくても普通に起こりえます。
現実的な進め方としては、次の順番を勧めます。
- 対象業務を1つに絞り、月に何件処理するかを数える
- 候補モデルを2つに絞り、同じ業務・同じ件数で1か月走らせる
- 月末の実請求額と、失敗して人が手直しした件数を並べて比べる
- そこで初めて、振り分けを検討する規模かどうかを判断する
順番を逆にして、先に振り分けの仕組みを作り込むと、複雑さだけが残ります。特定のモデルや基盤に深く寄りかかった構成を先に作ってしまうリスクについては ベンダーロックインで失敗した話 に書きました。
そしてもう一度書きますが、今回の数字は提供者自身が測ったものです。方向性の参考にはなりますが、自社の請求額を予測する根拠にはなりません。根拠になるのは、自社で1か月走らせた明細だけです。
まとめ
- IBM Research の実測（AppWorld Test Challenge、417タスク、CodeActエージェント）で、公表単価の安い GPT-4.1 が総額155ドル、単価の高い Claude Sonnet が79ドルと、約2倍の逆転が起きた
- 逆転の主因はキャッシュの効き方であり、著者自身が「モデル・ワークロード・サービング基盤の相互作用に依存する」として再現性を限定している
- モデル振り分け構成は精度84%・コスト93ドル・レイテンシ83秒で、Opus単独比でコスト21%減・レイテンシ9%減だが、精度は4ポイント低下する引き換えがある
- この記事は IBM Research 自身による発表であり、同社は当該領域の技術提供者である。検証も単一ベンチマークのみで、業種別の一般化は示されていない
- 中小企業が取るべき行動は振り分けの導入ではなく、候補2つを同じ業務で小さく走らせ、実請求額と手直し件数で比べること。TOEでは本記事の振り分け構成は未実施である