Claudeの入力・出力トークン料金差はなぜ5倍？

入力トークンより出力トークンの料金が高い理由

現在のカタログにあるすべての Claude モデルでは、出力トークンの料金は入力トークンの5倍です。原因は計算の構造にあります。プロンプトの読み取りは、モデルを1回実行する処理です。返信の生成は、トークンごとに1回ずつ実行する処理で、各実行は直前の実行が終わるまで待つ必要があります。

この比率は料金表のすべての行で同じです。そのため、選択するモデルを変えても、請求額に占める出力分の割合は変わりません。割合を決めるのは、ワークロードの構成です。60,000トークンを読み取り、800トークンで回答するエージェントのステップでは、出力料金はほとんど発生しません。2,000トークンを読み取り、12,000トークンを書き出す下書き処理では、入力料金はほとんど発生しません。以下では、Anthropic が公開している August 2026 の料金を使って、両方のケースを計算します。

Prefill は 1 回実行し、Decoding はトークンごとに 1 回実行します

推論サーバーは、コストが大きく異なる 2 つのフェーズでリクエストを処理します。Prefill はプロンプトを読み込みます。Decoding は応答を書き出します。

Prefill では、プロンプト全体を一度に処理します。すべてのプロンプトトークンが同じ forward pass でネットワークに入力されるため、attention と feed-forward の処理は、一度に数千トークンを対象とする少数の大規模な行列乗算になります。モデルの重みをメモリから 1 回読み出すだけで、プロンプト全体を処理できます。アクセラレーターの行列演算ユニットは高い稼働率を維持します。そのため、Prefill は compute-bound です。制限要因は、チップが乗算を実行する速度です。

Decoding はそのように処理できません。トークン 2 はトークン 1 に依存するためです。モデルが直前に生成したトークンは次のステップの入力に含まれるため、各ステップを同時に実行できません。出力トークンごとに独自の forward pass が必要です。各 pass では、1 つのトークンを生成するために、モデルの全重みを high-bandwidth memory から読み出します。そのため、Decoding は memory-bound です。制限要因は、重みを乗算する速度ではなく、重みを移動する速度です。Prefill でプロンプト全体の処理に使われたのと同じ重みの転送量が、Decoding では 1 トークンの生成に使われます。

Serving システムは、バッチ処理によってこの問題に対処します。複数のリクエストをまとめて Decoding することで、重みを 1 回読み出すだけで、バッチ内の各リクエストについて 1 トークンを生成できます。これにより、Decoding が実用的な速度になります。ここでも上限を決めるのはメモリです。処理中の各リクエストは KV cache（key/value cache。これまでの各トークンの attention の状態を保存したもの）を保持します。この cache はトークンを生成するたびに増加します。cache がアクセラレーターを埋め尽くすと、バッチをこれ以上大きくできません。

これらから正確な数値が得られるわけではありません。また、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 には拡張思考が含まれるため、回答前にモデルが思考する場合、その思考にも出力と同じレートで課金されます。送信前にプロンプトの料金を見積もるには、POST /v1/messages/count_tokens に同じリクエスト本文を渡します。モデルを実行せずに {"input_tokens": N} を返すため、料金はかかりません。無料なのは API の一部だけではありません。最初のプロジェクトの予算を立てる前に、Claude API で決して課金されない部分を確認しておくとよいでしょう。

2026 年 8 月時点の Claude の 100 万トークンあたりの料金

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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 回登場するのは、導入料金の適用期間が終了するためです。2026 年 8 月 31 日までは、入力が $2、出力が $10 です。2026 年 9 月 1 日からは、入力が $3、出力が $15 の標準料金が適用され、入力側と出力側の両方で 50% 高くなります。以下の計算例ではすべて 8 月の料金を使用しています。

料金は変更されるため、確認にはこのページを使用しないでください。claude.com/pricing が正式な情報源です。料金が変わっても使えるのは、計算方法です。

料金表には示されない注意点が 1 つあります。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 (Aug)",
    "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、8 月の料金で 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 (Aug)",
    "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 で実行した場合の料金です。入力と出力が50%割引されます。Opus 5 はドラフト1件あたり $0.155 になります。Batch は結果を即時ではなく24時間以内に返すため、夜間のレポート生成や大量分類に適しています。人が結果を待機している処理には適していません。

ここでは、モデルルーティングがエージェント処理の場合にはない効果を発揮します。処理のうち冗長な部分が機械的な作業、たとえば承認済みのテキストの再フォーマットやアウトラインの展開であれば、安価なモデルによって、そのトークンを5分の1の料金で生成できます。Opus、Sonnet、Haikuの選び方では、実際に品質の境界がどこにあるかを説明しています。

キャッシュで割引されるのは入力だけです

プロンプトキャッシュは、プロンプトのプレフィックスをサーバーに保存し、再度読み込む際の入力料金を一部だけ請求します。2026年8月時点では、5分間のキャッシュを書き込む料金は基準入力料金の1.25倍、1時間のキャッシュを書き込む料金は2倍、キャッシュヒットを読み込む料金は0.1倍です。

出力はこの対象ではありません。キャッシュされた出力は存在しません。モデルが生成するすべてのトークンには、プロンプトのどれだけがキャッシュヒットになったかにかかわらず、毎回、通常の出力料金が全額請求されます。

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回のヒットが必要です。書き込みと読み込みの倍率、およびキャッシュが採算に合わなくなる条件 では、この計算を詳しく説明しています。

Four levers you control

1. Set max_tokens at your p95 output length, not at the model maximum.
2. Route the verbose steps to a cheaper model.
3. Batch anything nobody is waiting for.
4. Delete the instructions that inflate replies.

max_tokens is a hard ceiling, and setting it high costs nothing by itself, because you are billed for tokens produced and never for the ceiling. What a generous cap does is remove the limit on a reply that goes wrong. Pull the output_tokens distribution out of your logs, set the cap a little above the 95th percentile, and handle stop_reason: "max_tokens" in code by continuing the response or retrying. A truncation you detect costs less than a 4,000 token ramble you pay for and throw away. Extended thinking lands in output_tokens too, so set that budget from the same evidence.

Routing works when the expensive part of a step is volume rather than judgement. Keep the strong model on the decision, and hand the typing to something cheaper. Measure the routed version on your own evaluation set first, because a cheap model that needs two attempts costs more than one expensive attempt.

Batching is the only lever that discounts output. 50% off both sides, results inside 24 hours, and anything on a schedule qualifies.

The last lever is the one people skip. Phrases like "be thorough" and "explain your reasoning" set your output length on every call you will ever make. Replace them with the shape you want: "Answer in at most three sentences", or "Return only the JSON object, with no preamble". A system prompt that adds 300 tokens to every reply costs five times what the same 300 tokens cost in the prompt. keeping a running agent's costs under control covers the monitoring side, and whether the API or a flat subscription is cheaper for your pattern is worth settling before you spend a week tuning per-token spend that a subscription would have absorbed. For one developer that mostly comes down to whether Claude Pro's $20 a month and the usage limits that come with it cover the work you would otherwise be metering. If you are already hitting those limits mid-session, working out which window you are waiting on comes first, because the fix from there is a smaller model, a lighter context, extra usage credits, or moving that work onto the metered API. If the metered API turns out to be the cheaper home for that work, dropping to a smaller plan or cancelling it leaves the month you have already paid for intact, so making the switch costs you nothing on the way out. If the plan you are weighing Pro against is ChatGPT's rather than the metered API, the two subscription ladders priced side by side shows which one comes out cheaper for coding work. If that question is being asked for a team rather than one developer, note that Claude Enterprise pairs a per seat fee with tokens metered at these same API rates, so every lever on this page still applies to the metered half of that bill.

FAQ

出力トークンはなぜ入力トークンより高いのですか？

出力トークンの生成には、トークンあたりで大幅に多くのアクセラレーター時間が必要です。プロンプトは全体を対象に 1 回の forward pass で処理されるため、モデルの重みを 1 回読み込むだけで数千トークンを処理でき、ハードウェアは乗算処理性能によって制約されます。これに対して、応答は 1 トークンずつ生成されます。各トークンで独自の forward pass が必要になり、そのたびにモデルの重み全体を再読み込みするため、ハードウェアはメモリ帯域幅によって制約されます。Anthropic は現在のカタログ全体で、Haiku 4.5 から Fable 5 まで、出力を入力の 5 倍の価格に設定しています。

プロンプトキャッシュを使うと出力トークンは安くなりますか？

いいえ。プロンプトキャッシュの対象は入力だけです。2026 年 8 月時点では、キャッシュの読み取り料金は基本入力料金の 0.1x です。キャッシュへの書き込み料金は、5 分間の保持では 1.25x、1 時間の保持では 2x です。キャッシュの状態にかかわらず、出力は呼び出しごとに通常料金で課金されます。そのため、キャッシュは請求額だけでなく請求の構成も変えます。入力側のコストが小さくなると、削減に取り組む価値があるのは出力側になります。

高い 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 に移してください。