トークンとコンテキストウィンドウ — LLM のコストと限界を決める単位

LLM の料金表には「100 万トークンあたり何ドル」と書かれ、モデルのスペック表には「コンテキストウィンドウ 100 万トークン」と書かれています。この 2 つの数字を正確に読めれば、LLM 導入コストの見積もりは半分終わったようなものです。結論を先に書くと、トークンはモデルがテキストを処理する最小単位であり、コンテキストウィンドウは 1 回のリクエストでモデルが扱えるトークン総量の上限です。 コストも、性能の限界も、アーキテクチャの選択も、結局はこの単位の上で決まります。API コスト構造の全体像は LLM API vs セルフホスティングで扱いました。この記事はその計算の基礎になる単位そのものを整理します。

トークン — 単語でも文字でもないサブワード #

モデルはテキストを単語でも文字でもなく、トークン(token) という単位で処理します。学習データに頻出する文字列の断片を語彙として持っておき、入力テキストをその断片に分割する方式です。BPE(Byte Pair Encoding)系のアルゴリズムが広く使われています。

• 英語ではよく使う単語がそのまま 1 トークンになることが多く、おおよそ 4 文字あたり 1 トークンです。
• internationalization のような長い単語は international + ization のように数個に分割されます。
• 日本語や韓国語は語彙に占める割合が英語より小さいため、同じ内容でもトークン数が多くなります。モデルによって差はありますが、英語比 1.5〜2 倍と見ておくのが安全です。

ここから重要な事実がひとつ導かれます。トークン数はモデル(正確にはトークナイザー)ごとに異なります。 同じ文書でも A 社のモデルと B 社のモデルではトークン数が違い、同じ会社の中でもモデルの世代交代でトークナイザーが入れ替わり、同一テキストのトークン数が 30% 近く変わった実例があります。他モデル用のトークナイザーライブラリで出した推定値をそのまま信じてはいけません。各ベンダーが提供するトークンカウント API で、実際に使うモデルに対して測定する必要があります。

料金構造 — 入力と出力で単価が違います #

LLM API の料金は入力トークンと出力トークンを別々に計算し、出力の単価は入力の 3〜5 倍です。 生成はトークンを 1 つずつ順番に作る必要があり、計算コストが高いためです。同じ 100 万トークンでも、「長い文書を読んで短く要約する」のと「短い指示で長い文章を生成する」のではコストが大きく違います。

会話型のサービスではもうひとつ要素が加わります。LLM API はステートレスなので、毎ターン、それまでの会話全体を入力として送り直します。 10 ターン目の入力には、それ以前の 9 ターン分の質問と回答がすべて含まれます。会話が続くほどターンあたりの入力トークンが累積的に増えるため、総コストはターン数に比例するのではなく、それより急な勾配で増えていきます。長い会話を放置するとコストが静かに膨らむ構造です。

この構造を緩和する仕組みが 2 つあります。

• プロンプトキャッシュ: 毎ターン繰り返し送られる先頭部分(システムプロンプト、会話履歴)をサーバー側にキャッシュしておくと、キャッシュされた区間は定価の 10 分の 1 程度で処理されます。キャッシュ書き込み時には小幅なプレミアムが付きますが、同じプレフィックスを 2 回以上使うなら得になります。ただしキャッシュは先頭からの完全一致(prefix match)なので、プロンプトの前方にタイムスタンプのような毎回変わる値を入れるとキャッシュ全体が無効になります。
• バッチ API: リアルタイム応答が不要な処理をまとめて送ると、多くのベンダーが 50% 割引を提供しています。

コンテキストウィンドウ — モデルが一度に見られる範囲 #

コンテキストウィンドウは、1 リクエストでモデルが扱えるトークン総量です。システムプロンプト、会話履歴、添付文書、ツール定義、そしてモデルが生成する出力まで、すべてこの中に収まる必要があります。2026 年現在、主要モデルは 20 万〜100 万トークンが標準で、それ以上を提供するモデルもあります。100 万トークンはおよそ小説 10 冊分のテキストです。

2 つの数字を区別する必要があります。

リクエスト時に指定する max_tokens は出力の上限を決める値です。低くしすぎると応答が文の途中で切れ、切れた応答を再リクエストすればコストは二重にかかります。応答が切れたかどうかは、レスポンスに含まれる終了理由(stop reason)フィールドで確認できます。

大きなコンテキストの落とし穴 — 入ることと使いこなせることは別です #

コンテキストウィンドウの拡大で「文書を丸ごと入れればいいのでは」というアプローチが可能になりましたが、落とし穴が 2 つあります。

1. 性能低下: コンテキストが非常に長くなると、モデルが中間に位置する情報を見落とす傾向が報告されています(lost in the middle)。最新モデルはかなり改善されていますが、コンテキストを満杯にした状態の精度が短いコンテキストと同じだと仮定してはいけません。重要な情報を先頭か末尾に配置するのは、今でも有効なテクニックです。
2. コスト: 入力トークンはリクエストごとに課金されます。100 万トークンの文書を入れて質問を 10 回投げれば、入力コストを 10 回払うことになります。キャッシュで緩和はできますが、必要な部分だけ検索して入れる RAG のほうが構造的に安いケースが多くあります。

文書を丸ごと入れるか、検索して一部だけ入れるか、モデルに学習させるかの判断基準は RAG vs ファインチューニング vs ロングコンテキストで詳しく扱いました。

実務チェックリスト #

• まず測定します。 代表的なプロンプトをベンダーのトークンカウント API で実測し、想定トラフィックを掛けて月額を見積もります。他モデル基準の推定値を使い回さないようにします。
• 日本語サービスはトークンの膨張を織り込みます。 英語基準のベンチマークコストに 1.5〜2 倍を掛けて保守的に見積もります。
• 履歴を管理します。 古いターンを要約するか切り捨てるロジックを最初から入れます。ベンダーによってはサーバー側で自動圧縮してくれる機能もあります。
• キャッシュ前提でプロンプトを設計します。 固定の内容(システムプロンプト、ツール定義)は前方に、毎回変わる内容は後方に配置します。
• max_tokens と終了理由をセットで見ます。 切り捨てを検知できないと、不完全な応答がそのままユーザーに届きます。

まとめ #

• トークンはサブワード単位で、トークン数はトークナイザーごとに異なります。実際に使うモデルのカウント API で測定するのが唯一正確な方法です。
• 日本語は同じ内容でも英語よりトークンを多く消費します。コスト見積もりに反映する必要があります。
• 料金は入力と出力で単価が異なり、会話は履歴の再送信のせいで長くなるほど急速に高くなります。プロンプトキャッシュとバッチ API が主な緩和手段です。
• コンテキストウィンドウは入力と出力を合わせた上限で、最大出力トークンは別のスペックです。
• 入るからといって全部入れるのが最善ではありません。長いコンテキストには性能とコストの落とし穴があり、RAG との選択はワークロード次第です。