コンテキストウィンドウ料金ガイド：コンテキスト長に応じた入力トークンコストの変動

1. コンテキスト長がコストに影響する仕組み

LLM API の料金は文字数や単語数ではなく、トークン数ベースです。入力コンテキスト内のすべてのトークン — システムプロンプト、会話履歴、取得したドキュメント、Few-shot 例 — がモデルの 1 トークンあたりの入力単価に乗算されます。コンテキスト長が 2 倍になれば、リクエストあたりの入力コストも 2 倍になります。

計算式はシンプルです：

GPT-5（$1.25/1M 入力トークン）で 10,000 トークンの入力の場合、リクエストあたりの入力コストは $0.0125 です。同じモデルで 100,000 トークンの入力になると $0.125 に — 10 倍のコスト増加で線形にスケールします。

出力トークンは通常、入力トークンの 3-6 倍高額であるため、出力コストが全体を支配することが多いです。しかし、長い入力と短い出力（分類、抽出、ロングコンテキスト要約）のワークロードでは、入力コストが主要な費用になります。

2. コンテキスト別ティア料金

一部のプロバイダーは送信する入力トークン数に応じて異なる料金を設定しています。入力が閾値を超えると 1 トークンあたりの単価が — 場合によっては大幅に — 増加します。これはモデルの基本価格とは別物です。

3. ショートコンテキスト vs ロングコンテキストのコスト比較

以下の表は、人気モデルのコンテキスト長ごとのリクエストあたり入力コストを比較したものです。比較のため出力は 1,000 トークンに固定しています。

100k 入力トークンで最安のオプション：

• DeepSeek V3.2 — リクエストあたり $0.03（164k コンテキスト、ティアプレミアムなし）
• Gemini 2.5 Flash — リクエストあたり $0.03（65k コンテキスト、ティアプレミアムなし）
• GPT-5 Mini — リクエストあたり $0.03（128k コンテキスト、ティアプレミアムなし）
• Grok 3 Mini — リクエストあたり $0.03（131k コンテキスト、ティアプレミアムなし）

スケール時の月間コスト: 50k 入力トークン、1k 出力、月 10k リクエスト

50k 入力トークンで、Claude Sonnet 4.5 は月間コストが DeepSeek V3.2 より 1046% 高くなります。ティア別料金が適用される場合、コンテキスト長がさらに長いと差はさらに広がります。

4. トランケート vs ロングコンテキストモデルの選び方

トランケートすべきケース：

• フルコンテキストが不要な場合。200 ページのドキュメントを要約するが最初と最後の章だけが必要なら、それらだけを送信します。
• ティアプレミアムが適用される場合。Claude Sonnet 4.5 に 210k トークンを送信すると 2 倍の入力プレミアムが発生します。190k トークンにトランケートすればティアを完全に回避できます。
• 品質が劣化しない場合。分類、抽出、簡単な Q&A など、ノイズの多いフルドキュメントよりも焦点を絞った短いコンテキストの方が適しているタスクがあります。
• コストが完全性よりも重要な場合。高ボリュームワークロードでは、リクエストあたりの小さな節約が複合します。100k リクエストでコンテキストの 20% をトランケートするだけで、月間数千ドルを節約できます。

ロングコンテキストモデルを使うケース：

• フルコンテキストが必要的な場合。法的ドキュメントレビュー、コードベース分析、マルチドキュメント推論、大きな取得セットを含む RAG では、重要な情報を欠落しないためにフルコンテキストが必要です。
• ティアプレミアムがない場合。Gemini 2.5 Flash、DeepSeek V3.2、GPT-5 Mini、Grok 3 Mini はティアなしでロングコンテキストに対応 — トークンを多く送るほど比例してコストが増加し、指数関数的に増えることはありません。
• 品質が幅に依存する場合。複数ドキュメントの比較、矛盾の検出、大きなコーパスにまたがる質問回答など、一度にすべてを確認するメリットがあるタスク。
• レイテンシが許容される場合。ロングコンテキストは処理時間を増加させます。レイテンシが重要でない場合は、低コストなロングコンテキストモデルでフルコンテキストを使用する方が、前処理やチャンキングよりも安価であることが多いです。

5. コンテキストコスト管理のベストプラクティス

最適化前に測定する

実際のリクエストあたりのコンテキストサイズをログに記録します。多くのワークロードは、冗長なシステムプロンプト、不要な会話履歴、過剰に含められた取得ドキュメントのために、必要なトークンの 2-3 倍を送信しています。まず測定し、次に最大の問題をターゲットにします。

効率的なコンテキスト使用のためのプロンプト設計

最も重要な情報をコンテキストの最初と最後に配置します。明確なセクションマーカーを使用して、モデルが関連部分に集中できるようにします。出力品質を改善せずにトークンを無駄にする冗長な指示は避けましょう。

会話履歴を積極的に刈り込む

マルチターン会話では、最後の N ターンとシステムプロンプトだけを保持します。古いターンは現在の回答に有意義な寄与をすることが rare です。5-10 ターンのスライディングウィンドウがしばしば十分です。

取得ドキュメントをチャンク化する

RAG システムでは、フルドキュメントではなく最も関連性の高いチャンクだけを取得します。再ランキングを使用して取得チャンクのスコアリングを行い、LLM に送信します。5 つの高品質チャンク（2k トークン）を送信する方が、20 チャンク（8k トークン）を送信するよりも安価で、しばしばより効果的です。

安定したプレフィックスにプロンプトキャッシュを使用する

システムプロンプト、Few-shot 例、参照ドキュメントがリクエスト間で一貫している場合は、プロンプトキャッシュを有効にします。キャッシュされたトークンは 75-90% 低コストになるため、ロングコンテキストの送信コストを相殺できます。

ワークロードに適したコンテキストウィンドウを選ぶ

常に 10k トークンしか送信しないのに 1M コンテキストウィンドウに課金する必要はありません。GPT-4.1 Nano や Gemini 2.0 Flash のような小さくて安価なモデルが、ショートコンテキストワークロードにはよりコスト効率が高いです。ロングコンテキストモデルは本当に必要なタスクに使いましょう。

2 ステージパイプラインを検討する

非常に長いドキュメントの場合は、まず安価なモデルで関連セクションを抽出または要約し、その後にプレミアムモデルにCondensed な出力を送信して最終推論を行います。これにより、高額モデルに送信する入力トークンを削減できます。

6. よくある質問