Quick answer: コンテキストウィンドウは容量として宣伝されます。20 万トークン、100 万トークン、必要なだけ入る、と。しかし課金単位は容量ではありません。請求されるのは送信した分であり、複数ターンの会話ではそのほとんどを毎ターン送り直しています。それが二度目の支払いです。20 ターンの会話の冒頭で読み込んだ 3 万トークンの文書は、入力 3 万トークンではなく、60...

コンテキストウィンドウへの二重支払い

Updated September 1, 2026 · first published September 1, 2026

コンテキストウィンドウは容量として宣伝されます。20 万トークン、100 万トークン、必要なだけ入る、と。しかし課金単位は容量ではありません。請求されるのは送信した分であり、複数ターンの会話ではそのほとんどを毎ターン送り直しています。

それが二度目の支払いです。20 ターンの会話の冒頭で読み込んだ 3 万トークンの文書は、入力 3 万トークンではなく、60 万トークン近くになります。

誰も計算しない算数

コストは会話の長さに対して線形ではなく、二乗で増えます。ターン数が倍になれば入力トークンはおよそ 4 倍です。「メッセージあたりの費用」に件数を掛ける見積もりは、長いセッションを大きく過小評価します。

さらに三つ目の課金があることも多いです。多くのプロバイダーは長文脈のしきい値を超えたリクエストに割増料金を適用します。添付ひとつでその線を越え、呼び出し全体が再価格付けされます。

測るべきもの

コンテキスト利用率、つまり送信したトークンと実際に必要だったトークンの比を追ってください。入力トークンはリクエスト単位ではなく会話単位で測り、p99 を見ます。

3 つの対策

安定した接頭辞をキャッシュする。複数ターンの製品では最も効果の大きい変更です。

履歴を意図的に削る。古い部分は要約し、生のターンは捨てます。

コーパスではなく抜粋を送る。

Related


Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research