Claudeの出力トークン料金が入力の5倍の理由

入力トークンより出力トークンのコストが高い理由

現在のカタログにあるすべての Claude モデルでは、出力トークンの料金は入力トークンの5倍です。原因は計算の構造にあります。プロンプトの読み取りは、モデルを1回通すだけです。返信の生成は、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 はこの方法では処理できません。token 2 は token 1 に依存するためです。モデルが直前に生成したトークンが次のステップの入力に加わるため、各ステップを同時には実行できません。出力トークンごとに独自の forward pass が必要です。各 pass では、1 個のトークンを生成するために、モデルの全重みを high-bandwidth memory から読み出します。そのため Decoding は memory-bound です。制限要因は、重みを乗算する速度ではなく、重みを移動できる速度です。Prefill でプロンプト全体の処理に使ったのと同じ重みの転送量が、Decoding では 1 個のトークンの生成に必要になります。

Serving システムは batching によってこの問題に対処します。複数のリクエストをまとめて Decoding することで、重みを 1 回読み出すだけで、batch 内の各リクエストについて 1 個のトークンを生成できます。Decoding が実用的なコストで処理できるのはこのためです。ただし、上限を決めるのは再びメモリです。処理中の各リクエストは KV cache（key/value cache。これまでの各トークンの Attention 状態を保存したもの）を保持します。KV cache はトークンを生成するたびに増加します。アクセラレーターが KV 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 には拡張思考が含まれるため、回答前に思考するモデルでは、その思考にも出力レートで課金されます。送信前にプロンプトの料金を見積もるには、POST /v1/messages/count_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 を使用します。この tokenizer では、Sonnet 4.6 以前の tokenizer と同じテキストでも、生成されるトークン数が約 30% 増えます。100 万トークンあたりの料金だけで 2 つのモデルを比較すると、新しいモデルを実際より有利に評価することになります。同じドキュメントでも、新しいモデルではトークン数が増えるためです。実際に完了させるタスクのコストで比較し、使用する予定のモデルに実際のプロンプトを入力して確認してください。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 回のフォワードパスで処理するため、モデルの重みを 1 回読み込むだけで数千トークンを処理でき、ハードウェアは積和演算のスループットによって制約されます。これに対して、応答は 1 トークンずつ生成されます。各トークンでモデルの重み全体を読み込むフォワードパスが必要になるため、ハードウェアはメモリ帯域幅によって制約されます。Anthropic は現在の全製品ラインで、Haiku 4.5 から Fable 5 まで、出力に入力の 5 倍の料金を設定しています。

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

いいえ。プロンプトキャッシュが適用されるのは入力だけです。2026 年 8 月時点では、キャッシュ読み取りの料金は基本入力料金の 0.1 倍です。キャッシュ書き込みは、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 に移してください。