著者 Claudeの入力と出力トークン料金の差はなぜ5倍？
Claudeは出力トークンが入力の5倍です。Prefillとdecodingの速度差を解説し、60,000入力・800出力のエージェントなど実例で月額請求への影響を計算します。
入力トークンより出力トークンのコストが高い理由
現在のカタログにあるすべての Claude モデルでは、出力トークンのコストは入力トークンの 5 倍です。原因は計算の構造にあります。プロンプトの読み取りはモデルを 1 回通過させる処理です。返信の生成はトークンごとに 1 回処理する必要があり、各処理は直前の処理が終わるまで待機します。
この比率は料金表のすべての行で同じです。そのため、選択するモデルによって請求額に占める出力コストの割合は変わりません。割合を決めるのはワークロードの構造です。60,000 トークンを読み取り、800 トークンで回答するエージェントのステップでは、出力コストはほとんど発生しません。2,000 トークンを読み取り、12,000 トークンを書き出す草稿作成ジョブでは、入力コストはほとんど発生しません。以下では、Anthropic が公開している料金に基づき、2026 年 10 月 27 日に確認した両方のケースを計算します。
Prefill は 1 回、decoding はトークンごとに 1 回実行されます
推論サーバーは、コストが大きく異なる 2 つのフェーズでリクエストを処理します。Prefill はプロンプトを読み込みます。Decoding は応答を書き出します。
Prefill はプロンプト全体を一度に処理します。すべてのプロンプトトークンが同じ forward pass でネットワークに入力されるため、attention と feed-forward の処理は、一度に数千トークンを対象とする少数の大規模な行列乗算になります。モデルの重みをメモリから 1 回読み出すだけで、プロンプト全体を処理できます。アクセラレーターの行列演算ユニットは高い稼働率を維持するため、Prefill は通常 compute-bound です。制限要因は、チップが乗算できる速度です。NVIDIA のサービングドキュメントでは、短すぎる Prefill と、長い prefix がすでに cache hit になっている Prefill では、代わりに memory-bound になると説明されています。
通常の decoding は、この方法では処理できません。トークン 2 はトークン 1 に依存するためです。モデルが直前に生成したトークンが次のステップの入力に加わるため、各ステップは順番に実行されます。出力トークンごとに独自の forward pass が必要です。各 forward pass では、1 トークンを生成するために、モデルの全重みと KV cache（key/value cache。これまでの各トークンの attention 状態を保存したもの）を high-bandwidth memory から読み出します。そのため、decoding は通常 memory-bound になります。制限要因は、重みと cache された状態を移動できる速度であり、乗算の速度ではありません。長いコンテキストでは、NVIDIA は KV cache の読み出しをボトルネックとして挙げています。Prefill でプロンプト全体の処理に使ったのと同じ重みの転送量で、decoding では 1 トークンしか生成できません。
Speculative decoding は、この原則を破らずに緩和します。小さな draft model が先の複数トークンを予測し、大きなモデルがそれらを 1 回の pass で並列に検証します。NVIDIA によると、これにより decoding は compute-bound に近づく場合があります。ただし、大きなモデルは予測を順番に受け入れ、最初に誤った予測が出た時点で停止します。そのため、長い応答では依然として多数の pass が必要です。
Serving system は batching によってこの問題に対応します。多数のリクエストをまとめて decoding するため、重みを 1 回読み出すだけで、batch 内の各リクエストに 1 トークンずつ生成できます。これが、decoding を現実的なコストで実行できる理由です。上限は再びメモリによって決まります。処理中の各リクエストは固有の KV cache を保持し、その cache はトークンを生成するたびに増加します。アクセラレーターが cache で埋まると、batch をこれ以上大きくできません。
以上から正確な数値が得られるわけではありません。5x をハードウェアの測定比として解釈してはいけません。これは Anthropic が設定した価格であり、この非対称性を踏まえたものです。自分で確認できるのは方向性であり、確認には約 1 分かかります。
入出力の差分を自分で測定する
任意の Ubuntu マシンにツールをインストールします。
sudo apt update && sudo apt install -y curl jq moreutils次に、短いプロンプトで長い回答を求めるストリームを開始し、到着した時刻を各行に付けます。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s は、コマンド開始からの経過秒数を各行の先頭に付けます。この出力から読み取るべき点は 2 つあります。最初の content_block_delta 行が最初のトークンまでの時間であり、prefill はすべてその行の中で完了しています。その後の各行はデコードの小さな 1 ステップに対応し、message_stop が到着するまで時刻が増え続けます。
次に、形を逆にします。プロンプトに長いドキュメントを入れ、回答を数トークンに制限します。
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'最初の差分が短いプロンプトの場合より長くなるのは、prefill で読み取るテキストがはるかに多いためです。最初の差分が到着すると、デコードするトークンが数個しか残っていないため、回答はほぼ即座に終了します。数万トークンを入力しても、時計はほとんど進みません。数百トークンが出力されると、時計はその間ずっと進みます。
ストリーミングしないすべての応答は、請求対象となる数値で終了します。
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}リクエストごとに 4 つのフィールドをすべて記録します。output_tokens には thinking tokens が含まれるため、回答前に思考するモデルでは、その思考にも出力用のレートが適用されます。送信前にプロンプトの料金を見積もるには、POST /v1/messages/count_tokens にほとんどのリクエストと同じリクエスト本文を渡します。モデルを実行せずに {"input_tokens": N} を見積値として返し、独自の rate limit の範囲内では無料です。Messages API が受け付ける本文の一部は拒否されます。対象には、web search、MCP connector などの多くの server tools と、url または file source を持つ画像やドキュメントのブロックが含まれます。そのため、カウント時には画像と PDF を base64 で送信します。API には無料の部分がほかにもあり、初回プロジェクトの予算を組む前に、Claude API で請求されない部分を確認しておくとよいでしょう。
2026 年 10 月時点の Claude の 100 万トークンあたりの料金
このグラフのデータ
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]最後の列は出力を入力で割った値で、すべての行で 5 となっています。Haiku 4.5 の入力料金は $1、出力料金は $5 です。Opus 5 は $5 と $25 です。最も高価な Fable 5 は $10 と $50 で、最上段を除外する前に Fable 5 の料金で何ができるのか を読む価値があります。価格帯を上げると入力側と出力側の両方が同じ倍率で増えるため、合計額は変わりますが、入力と出力の比率はまったく変わりません。
Sonnet 5 の入力料金は $2、出力料金は $10 です。Anthropic はこの料金を導入価格として 2026 年 8 月 31 日まで適用し、9 月 1 日から $3 と $15 に値上げする予定でした。その後、標準価格を $2 と $10 に変更しました。値上げは実施されなかったため、以下の計算例で使う料金はすべて現在支払う料金です。
このページの初回公開後、Anthropic は新しいモデルもリリースしており、現在の claude.com/pricing では、上記の4モデルを引き続き利用できるレガシーモデルとして掲載しています。新しいモデルも同じ 5 倍の比率を維持しています。Opus 5.5 は $4 と $20、Sonnet 5.5 は $2 と $10、Fable 5.1 は $10 と $50 です。Haiku 5.5 は 100,000 トークンまで $0.10 と $0.50 で、それを超えると $0.50 と $2.50 です。下で計算する 60,000 トークンのエージェントステップはこの境界未満ですが、履歴が増え続けるエージェントはいずれ境界を超えます。Haiku 5.5 の2段階の料金が実際のジョブにどう適用されるか では、その変化が料金に与える影響を示しています。Opus 5.5 の入力と出力の基本料金は Opus 5 より 20% 低いため、以下のキャッシュされていない Opus 5 の数値はすべて、Opus 5.5 では 20% 低くなります。キャッシュヒットの読み取り料金は、Opus 5.5 が 100 万トークンあたり $0.20、Opus 5 が $0.50 なので、キャッシュヒットの読み取り料金自体は 60% 下がります。下で Opus 5 では $0.0725 かかるキャッシュ済みエージェントステップは、Opus 5.5 では約 $0.047 で、約 35% 安くなります。
料金は変わるため、このページで確認しないでください。正確な情報源は claude.com/pricing です。料金が変わっても有効なのは、この計算方法です。
注意点が1つあります。これは料金そのものではなく、Anthropic の料金表の下にある注記に記載されています。Anthropic の料金ページによると、Claude 4.7 以降のモデルは新しい tokenizer を使用しており、Sonnet 4.6 以前の tokenizer と同じテキストでも、およそ 30% 多くのトークンを生成します。100 万トークンあたりの料金だけで2つのモデルを比較すると、新しいモデルは有利に見えます。同じ文書でも、新しいモデルではトークン数が多くなるためです。完了したタスクあたりのコストで比較し、実際に使用するモデルに対して実際のプロンプトを数えてください。プロバイダー間でも tokenizer は異なるため、同じ問題が発生します。そのため、2つの料金表を並べて比較するよりも、Claude と ChatGPT の両方で実際のジョブの料金を計算する方法 のほうが有用です。Claude の 100 万トークンが実際のテキストでどの程度に相当するか では、この量が実際にどの程度になるかを説明しています。
出力が料金の大部分を占め始めるのはいつですか？
出力の単価が入力の 5 倍なら、損益分岐点は簡単に覚えられます。入力トークン数を I、出力トークン数を O とします。入力のコストは I です。出力のコストは O の 5 倍です。5 × O が I を上回ると、出力が総コストの半分を超えます。トークン数の比率では、入力 5 に対して出力 1 です。
したがって、プロンプトが応答の 5 倍を超える場合は、入力のほうが大きな費目です。それ未満では、出力のほうが大きくなります。
このグラフのデータ
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]100 対 1 では、出力が総コストの 4.8% を占めるため、取り組む価値があるのはプロンプトを短くすることだけです。5 対 1 では、両者は同じ割合になります。1 対 6 では、出力が 96.8% を占め、プロンプトの差は丸め誤差です。多くの人は自分の比率を誤って見積もるため、最適化する前にログから実際の値を確認してください。
エージェントの処理: 長いコンテキストを受け取り、短く回答する
検索したドキュメントと会話履歴を 60,000 トークン入力し、800 トークンで回答するエージェントの処理を 1 ステップ実行します。比率は 75 対 1 です。読み取ってから書き込む処理では、これは一般的な比率です。
このグラフのデータ
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]出力は、どのモデルでもこの呼び出しの 6.25% です。価格表全体で比率が固定されているためです。この呼び出しの料金は、Opus 5 で $0.32、Sonnet 5 で $0.128、Haiku 4.5 で $0.064 です。Opus 5 でこの処理を 1 日に 200 回実行すると、1 日あたり $64 かかります。
この内訳を見ると、効果の大きい対策は明確です。回答を 800 トークンから 400 トークンに減らしても、呼び出し全体の約 3% しか節約できません。プロンプトから古いコンテキストを 20,000 トークン削減すると、約 3 分の 1 を節約できます。読み取り中心のエージェントでは、出力長を短くしても、ほとんど効果がありません。コーディングエージェントのトークンが実際にどこで使われるかでは、そもそもプロンプトを何が埋めているのかを詳しく説明します。
生成ワークロード: 短いプロンプト、長いドラフト
ここで構成を逆にします。2,000 token の概要、12,000 token のドラフトで、比率は 1 対 6 です。
このグラフのデータ
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]出力がこの料金の 96.8% を占めます。Opus 5 はドラフト 1 件あたり $0.31 で、Haiku 4.5 は $0.062 です。この 5 倍の差はほぼすべて出力側で生じており、まさにここで安価なモデルによる削減効果が最大になります。
最後の列は、同じジョブを Batch API で実行した場合です。Batch API では入力と出力がそれぞれ 50% 引きになります。Opus 5 はドラフト 1 件あたり $0.155 まで下がります。Batch は即時実行ではなく非同期です。Anthropic によると、多くのバッチは 1 時間未満で完了します。ただし、24 時間経過時点でも処理中のバッチは期限切れになります。その時点までに処理されていなかったリクエストは、期限切れとして返され、課金されず、メッセージも返されません。そのため、夜間のレポート生成や一括分類には適していますが、期限切れになったものを再送信する手順が必要です。人が待機して結果を待つ処理には適していません。
ここでは、モデルルーティングが agent の処理段階では得られない効果を発揮します。ジョブの冗長な部分が機械的な処理、つまりテキストの再フォーマットや、すでに承認したアウトラインの展開であれば、安価なモデルはその token を 5 分の 1 の価格で生成します。Opus、Sonnet、Haiku の選択では、実際に品質の境界がどこにあるかを説明しています。
キャッシュは入力料金だけを割り引きます
プロンプトキャッシュは、プロンプトの先頭部分をサーバーに保存し、再度読み込む際の入力料金を一部だけ課金します。2026 年 10 月 27 日現在、このページで料金が示されているモデルでは、5 分間のキャッシュを書き込む料金は基準入力料金の 1.25 倍、1 時間のキャッシュを書き込む料金は 2 倍、キャッシュヒットを読み込む料金は 0.1 倍です。最新モデルではキャッシュヒットの読み込み料金がさらに安く、Opus 5.5 と Sonnet 5.5 では 0.05 倍、Fable 5.1 では 0.025 倍です。
出力はこの割引の対象外です。キャッシュされた出力はありません。モデルが生成するすべてのトークンは、プロンプトのどれだけがキャッシュヒットしたかに関係なく、毎回、出力料金の全額で課金されます。
Opus 5 で同じエージェントステップを実行し、60,000 個の入力トークンのうち 55,000 個がウォームキャッシュから提供される場合を考えます。
このグラフのデータ
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]この呼び出しの料金は $0.32 から $0.0725 に下がります。出力の料金は変わらず、実行前は $0.02、実行後も $0.02 です。キャッシュにより請求額が下がるだけでなく、内訳も変わります。この呼び出しでは、出力が 6.25% を占めていました。現在は 4 分の 1 を超えているため、次にどのコスト削減策を取る価値があるかが変わります。
最初の呼び出しでは書き込み料金が発生します。5 分間のキャッシュ書き込みは基準入力料金の 1.25 倍なので、1 回のヒットで元が取れます。1 時間の書き込みは 2 倍なので、2 回のヒットが必要です。書き込みと読み込みの倍率、およびキャッシュが採算に合わなくなる条件で、この計算を詳しく説明しています。
制御できる4つの手段
max_tokensはモデルの最大値ではなく、出力長の p95 に設定します。- 冗長な手順をより安価なモデルに振り分けます。
- 誰も待っていない処理はすべてバッチ処理します。
- 返信を膨らませる指示を削除します。
max_tokens は厳密な上限です。高く設定しても、それだけで費用は発生しません。請求対象は生成されたトークンであり、上限自体は請求対象にならないためです。余裕のある上限を設定すると、返信が想定外に長くなった場合でも途中で打ち切られなくなります。ログから output_tokens の分布を取り出し、上限を 95 パーセンタイルより少し上に設定します。stop_reason: "max_tokens" は、レスポンスを継続するか再試行することでコード側で処理します。検出できる切り捨ては、料金を支払ったうえで破棄する 4,000 トークンの長い返信よりも低コストです。思考も output_tokens に含まれ、max_tokens に対してカウントされます。そのため、同じ根拠から上限を決めます。適応型思考を備えたモデルでは、思考が返信を圧迫し続ける場合に effort level を下げます。
ある手順で高コストになる部分が判断ではなく量である場合、振り分けが有効です。判断は高性能なモデルに任せ、入力作業はより安価なモデルに渡します。重要なのは完了したタスクあたりのコストなので、まず自分の評価セットで振り分け後の構成を測定します。上記の agent step では、Haiku 4.5 を 2 回試行すると $0.128 かかります。Opus 5 を 1 回試行した場合は $0.32 です。そのため、価格差で 1 回か 2 回の再試行を吸収できます。ただし、誰も発見しない誤答のコストまでは吸収できません。
バッチ処理は、出力を割り引く唯一の手段です。入力と出力の両方が 50% off になり、多くのバッチは 1 時間以内に完了します。24 時間の時点で期限切れになるものをジョブが再送信できれば、スケジュール実行の処理も対象になります。
最後の手段は、見落とされがちです。「be thorough」や「explain your reasoning」のようなフレーズは、今後行うすべての呼び出しで出力長を増やします。求める形式を直接指定します。「Answer in at most three sentences」や「Return only the JSON object, with no preamble」のようにします。システムプロンプトがすべての返信に 300 トークンを追加すると、同じ 300 トークンでもプロンプト内の費用の 5 倍になります。実行中の agent のコストを継続的に管理する方法では監視について扱っています。また、サブスクリプションで吸収できるトークン単価の支出を 1 週間かけて調整する前に、自分の利用パターンでは API と定額サブスクリプションのどちらが安いかを決めておく価値があります。1 人の開発者の場合、主な判断は Claude Pro の月額 $20 と付属する利用上限で、それ以外なら従量課金する作業をカバーできるかどうかです。すでにセッション途中でその上限に達している場合は、まず どのウィンドウを待っているのかを確認する方法を調べます。その後の対策は、より小さいモデル、軽いコンテキスト、追加の利用クレジット、または従量課金の API への移行です。その作業では従量課金の API のほうが安いと分かった場合、より小さいプランへの変更または解約を行っても、すでに支払った月の利用分はそのまま残ります。そのため、切り替えによる追加費用は発生しません。比較対象のプランが従量課金の API ではなく ChatGPT のプランである場合は、2 つのサブスクリプション階層を料金とともに並べて比較した結果で、コーディング作業にどちらが安いかを確認できます。1 人の開発者ではなくチーム向けにこの問題を検討している場合は、Claude Enterprise は席あたりの料金と、同じ API 料金で従量課金されるトークンを組み合わせている点に注意してください。そのため、このページのすべての手段は、その請求の従量課金部分にも適用されます。
FAQ
出力トークンはなぜ入力トークンより高いのですか？
出力トークンの生成には、トークンあたりはるかに多くのアクセラレーター時間が必要だからです。プロンプトは全体を 1 回のフォワードパスで処理するため、モデルの重みを 1 回読み込むだけで数千トークンを処理でき、通常、ハードウェアは乗算スループットによって制限されます。通常のデコードでは、応答を 1 トークンずつ生成します。各トークンで、モデルの重みと増加する KV キャッシュを再度読み込む独自のフォワードパスが必要になるため、通常、ハードウェアはメモリ帯域幅によって制限されます。speculative decoding などの技術により、この差は縮まりますが、なくなるわけではありません。Anthropic は、Haiku 5.5 から Fable 5.1 まで、現在の全カタログで出力の価格を入力の 5 倍に設定しています。
prompt caching によって出力トークンは安くなりますか？
いいえ。prompt caching は入力にのみ適用されます。2026 年 10 月 27 日時点で、ほとんどのモデルではキャッシュの読み取りに基準入力料金の 0.1 倍がかかります（Opus 5.5 と Sonnet 5.5 では 0.05 倍、Fable 5.1 では 0.025 倍）。キャッシュへの書き込みには、5 分間の保持で 1.25 倍、1 時間の保持で 2 倍の料金がかかります。キャッシュの動作にかかわらず、出力は毎回、全額の料金で請求されます。そのため、キャッシュは請求額だけでなく、請求の内訳も変えます。入力側の料金が小さくなると、削減効果を検討すべき対象は出力になります。
高い max_tokens を設定しても、応答が短ければ料金は発生しますか？
いいえ。実際にモデルが生成したトークン数に対して請求されるため、max_tokens は上限であり、予約数ではありません。ただし、応答が際限なく長くなる場合の唯一の厳格な上限なので重要です。観測した output_tokens の 95 パーセンタイルを少し上回る値に設定し、stop_reason: "max_tokens" は、応答が黙って途中で切れた状態で配信されないよう、コードで処理してください。
入力トークンと出力トークンの比率はどのように確認できますか？
すべての応答の usage オブジェクトから input_tokens、output_tokens、cache_read_input_tokens、cache_creation_input_tokens を記録し、1 週間分の合計を割り算します。入力 5 に対して出力 1 を超える場合、コストの中心はプロンプトです。安定した部分をキャッシュし、残りを削減してください。それを下回る場合、コストの中心は応答です。応答の長さを制限し、最も多くの出力を生成する処理を、より安価なモデルまたは Batch API に移してください。