Fable 5・GPT-5.6 Sol・Kimi K3、単価3.3倍の差は実コスト3.3倍の差なのか？

トークンと料金表の読み方

モデルの料金は文字数でもリクエスト回数でもなく、トークン数で決まる。トークンとは文章を処理単位に細かく分割した断片だ。Kimi の公式ドキュメントは、一般的な英文では1トークンがおよそ英字3〜4文字に相当すると説明している。日本語や韓国語はより細かく分割されるため、同じ意味の文でも英語よりトークンを多く消費する。

料金表はこのトークン100万個あたりの価格を示したもので、通常は三つの列に分かれる。入力は自分がモデルに送り込むプロンプトと添付文書、出力はモデルが生成して返す文章、キャッシュヒットは以前送ったものとまったく同じ前半部分を再送する際に適用される割引価格だ。エージェントのように同じ指示文と同じコードベースを繰り返し投入する作業ほど、キャッシュヒットの比重は大きくなる。

ここで誤解しやすい点がある。表の価格は100万トークンあたりの単価であって、1回の呼び出しで支払う額ではない。請求額は常に単価×数量であり、本稿が扱うのはその数量の側で起きることだ。

三つのモデルの公式単価はどれだけ違うか

2026年7月26日時点で各社の公式ドキュメントに記載されている値は次のとおりだ。三つともおよそ100万トークン規模のコンテキストウィンドウを持ち、扱える作業の大きさ自体は同等である。

単価だけを見れば順序は明確だ。Fable 5 は Kimi K3 の3.3倍で、正確なのは入力と出力に同じ倍率がかかるという点だ。Sol と比べると入力は2倍だが出力は1.7倍で、差はやや狭い。注目すべきはキャッシュヒットの列で、三社とも自社の入力価格のちょうど10%に揃えられている。つまりキャッシュは三つのモデルの絶対コストを同時に下げるだけで、どれか一つを相対的に有利にはしない。コストを気にする人がまずキャッシュを思い浮かべることは多いが、この比較では答えにならない。

同じ文章なのになぜトークン数が変わるのか

トークナイザーとは文章をトークンに分割する規則だ。この規則が変われば、同じ文でもトークン数は変わる。Anthropic は公式の料金ドキュメントで、Claude 4.7 以降のモデルと Mythos Preview が新しいトークナイザーを使用し、同一テキストに対して約30%多いトークンを生成すると明記している。性能向上と引き換えの選択だという説明も併記されている。

この30%が何との比較なのかは正確に押さえる必要がある。Anthropic 自身の前世代トークナイザーとの比較値であり、他社モデルとトークン数を直接比較した公式数値は公開されていない。したがってこの値を持ち出して会社間のコスト差を掛け算で求めてはならない。

それでも実務上の結論は明確だ。料金表の倍率は実支出の差の下限であって上限ではない。同じ文書を入れてもモデルごとに請求トークン数が異なりうる以上、本当の比較は同じ作業を双方で一度ずつ走らせ、各コンソールに記録された使用量を確認することだ。三社とも応答にトークン使用量を返すので、この確認は難しくない。

長くなると単価そのものが変わる区間がある

OpenAI は Sol に長さに基づく割増を設けている。入力が27万2000トークンを超えると、そのリクエスト全体が入力2倍・出力1.5倍で計算される。100万トークン換算で入力10ドル、出力45ドルだ。超過分だけが高くなるのではなく、リクエスト全体に適用される点が重要である。

この区間は思ったより簡単に届く。リポジトリ全体を読ませてリファクタリングさせる作業や、長い議事録と契約書の束をまとめて投入する作業がこれに当たる。反対に Fable 5 と Kimi K3 の料金表には長さ区分がない。Anthropic は100万トークンのコンテキスト全域を標準単価で課金すると明記しており、Kimi K3 の料金表も1,048,576トークンのコンテキストに対して単一の行しか置いていない。

したがって同じ三つのモデルでも、作業の性格によって順位は動く。短いリクエストを大量に回す作業では料金表の順序がそのまま保たれるが、一度に数十万トークンを流し込むエージェント作業では Sol の実効単価が Fable 5 側へ寄っていく。

一度で正しく出るか — 再実行は単価に掛け算される

三つのモデルに同じプロンプトを一度ずつだけ与え、成果物を比較したレビューがある。人間が途中で介入すればモデルの実力ではなくなるため、単一プロンプトで統制した方式だ。都市交通シミュレーター、エージェント UI、ブラウザ格闘ゲームの三課題を同条件で課している。

結果は分かれた。交通シミュレーターでは、Fable は車両が交差点を通過する物理処理と信号の表現まで作り込んだ一方、Sol は車を四角い箱で描いたうえ衝突処理がなく、車同士が重なって積み上がった。Kimi はその中間で、道路の表現は Sol より良く、重なりの問題は Sol と同程度だった。エージェント UI では Fable が最も良く Kimi が次点、Sol は接続線が誤った位置に付いた。レビュアーは Sol について、完成度を自ら確認して修正し直す反復が不足しているように見えると評した。

この点がコストの話につながる。結果が一度で出なければ同じ作業をやり直すことになり、そのたびに入力と出力が再び課金される。同じ作業をもう一度走らせれば、安いモデルの実効単価は二倍になる。3.3倍の差はおよそ三回余計に試して初めて覆る大きさなので、依然として安い側が有利な区間は広い。ただし料金表だけで計算した節約額がそのまま実現するわけではない。

もう一点付け加えると、同じレビュアーは、同一のモデルでもどの実行ツールで走らせたかによって成果物の完成度に目に見える差が出たと述べている。モデルを替える前に、いま使っている実行環境を点検すべき理由がここにある。

ではどう選ぶか

まず自分の作業がどの項目に引っかかるかを確認する。一度に入れる入力が27万トークン前後に達するか。同じ指示文を繰り返し投入してキャッシュの比重が大きいか。結果をそのまま使うのか、二度三度直して使うのか。この三つの答えが決まれば、どのモデルが有利かは計算で出る。

簡単な例を見よう。入力20万トークン、出力2万トークンの作業を一度、キャッシュなしで回すと、Fable 5 は2ドルに1ドルを足して3ドル、Sol は1ドルに0.6ドルを足して1.6ドル、Kimi K3 は0.6ドルに0.3ドルを足して0.9ドルになる。ここまでは表の3.3倍がそのまま出る。ところが入力を30万トークンに増やした瞬間、Sol だけが割増区間に入り、3ドルに0.9ドルを足した3.9ドルになる。同じ作業で Fable 5 は4ドルなので、両者の差は事実上消える。20万トークンで1.9倍あった Sol の価格優位はここで1.03倍まで縮み、同じ条件で1.2ドルの Kimi K3 との差は1.8倍から3.3倍へ広がる。順位がひっくり返るわけではないが、表から計算した節約分はこの区間で蒸発する。

サブスクリプションを使う個人なら、判断基準がもう一つある。いま使っているモデルで使用量に余裕があるなら、あえて変える理由はない。逆に上限が頻繁に尽きて、そのたびに数時間待たされるなら、尽きる区間をより安いモデルで埋める組み合わせの実益が大きい。いずれにせよ判断の根拠は料金表ではなく自分の使用履歴だ。

組織であればここにもう一つを加える。成果物をやり直す回数はモデルだけの問題ではなく、指示をどれだけ正確に与えるか、結果を検証する手順があるかにも左右される。同じモデルのままでも再実行を半分に減らせば、単価を三分の一に下げたのと同じ効果になる。モデルの入れ替えより、たいていこちらの方が安く速い。