トークンとは/コンテキストウィンドウとは｜LLMの入出力を測る単位と上限の仕組み

LLMのAPIを触りはじめると、必ず出てくるのが「トークン」と「コンテキストウィンドウ」という2つの言葉です。料金表はトークン単位で書かれ、モデルの仕様には「コンテキストウィンドウ20万トークン」といった数字が並びます。この2つは、LLMを業務で使ううえでコスト・精度・設計のすべてに関わる土台の概念です。この記事では、トークンとは何か、コンテキストウィンドウとは何かを仕組みから説明し、日本語での注意点、上限を超えたときの挙動、課金との関係、そして「上限が大きいほど良いわけではない」理由と実務の勘所までを整理します。

トークンとは：LLMが文章を読み書きする単位#

トークンとは、LLMが文章を処理するときの最小単位です。LLMは文字や単語をそのまま扱うのではなく、文章を「トークン」と呼ばれる小さな断片に分解してから読み書きします。この分解作業をトークナイズ(tokenization)と呼びます。

トークンは単語そのものとは限りません。英語では、よく使う短い単語は1トークンになりますが、長い単語や珍しい単語は複数のトークンに割れます。一般に英語では、1トークンはおよそ1文字から1単語程度の長さになります。Googleは目安として、Geminiモデルではトークンはおよそ4文字に相当し、100トークンが英語のおよそ60から80単語にあたる、としています(いずれも公式ドキュメント記載の目安で、モデルにより異なります)。

サブワードで区切る（トークナイズ）#

現在の多くのLLMは、サブワード分割という方式でトークナイズします。これは、頻出する文字の並びを1つのトークンにまとめ、珍しい語はより小さな断片に分ける仕組みです。たとえば英語の「tokenization」のような長い語は、tokenとizationのように複数トークンへ分割される、といった具合です。こうすることで、辞書に無い未知の語でも既知の断片の組み合わせとして表現でき、語彙のサイズを抑えつつ幅広い文章を扱えます。

重要なのは、トークンの区切り方はモデル(正確にはそのモデルが使うトークナイザ)ごとに異なるという点です。同じ文章でも、モデルが違えばトークン数は変わります。したがって「この文章は何トークンか」を厳密に知りたいときは、使うモデルに対応したトークナイザで数える必要があります。

日本語は英語よりトークン数が増えやすい#

日本語を扱ううえで押さえておきたいのが、同じ内容でも日本語は英語よりトークン数が多くなりやすいという傾向です。多くのトークナイザは英語のテキストを中心に効率よく圧縮できるよう作られており、日本語は1文字が1トークン以上に割れることも珍しくありません。漢字・ひらがな・カタカナが混在する日本語は、英語ほど1トークンあたりの文字数を稼げないためです。

この差は、コストと上限の両方に効いてきます。「英語なら収まる長さの文書が、日本語だと同じ文字数でもトークン数が膨らんで上限に近づく」「同じ処理でも日本語のほうが料金が高くつきやすい」といったことが起こり得ます。正確な数値はモデルとトークナイザ次第なので、断定はできませんが、日本語主体の運用ではトークン数を多めに見積もっておくと安全です。

コンテキストウィンドウとは：入力と出力の合計上限#

コンテキストウィンドウ(context window)とは、LLMが一度のやり取りで参照できるトークンの総量の上限です。モデルの「作業机の広さ」や「短期記憶の容量」にたとえられます。学習済みの膨大な知識とは別物で、その場のやり取りで実際に見えている範囲を指します。

ここで最も間違えやすいのが、コンテキストウィンドウは入力だけの上限ではないという点です。Googleの公式ドキュメントは「コンテキストウィンドウは入力トークンと出力トークンの合計の上限を定める」と明記しています。Anthropicの公式ドキュメントも、システムプロンプト、messages内のすべてのメッセージ(ツールの実行結果・画像・ドキュメントを含む)、ツール定義、そしてモデルが生成する出力(拡張思考=extended thinkingのトークンを含む)まで、リクエストに含まれるあらゆるものがコンテキストウィンドウに算入されると説明しています。

つまり、コンテキストウィンドウは次のような要素の合計で消費されます。

• システムプロンプト(役割・制約の指示)
• 会話履歴(過去のユーザー発言とAIの応答)
• 今回のユーザー入力(質問、貼り付けた文書など)
• ツール定義や検索で取得した外部テキスト(RAGで渡す文書など)
• これから生成する出力(応答本文。推論・思考トークンがあればそれも)

会話を続けるほど履歴が積み上がり、その分だけ使える余地が減っていきます。長い会話やエージェントの動作で「だんだん詰まってくる」のは、この累積が原因です。

上限を超えるとどうなるか#

コンテキストウィンドウの上限を超えたときの挙動は、大きく2つのパターンがあり、モデルや実装によって異なります。

1つ目は、入力だけで既に上限を超えているケースです。この場合はそもそもリクエストが受け付けられず、エラーが返ります。Anthropicの公式ドキュメントでは、入力だけで上限を超えるとinvalid_request_error(prompt is too long)という400エラーが返ると説明されています。

2つ目は、入力は収まっているが生成の途中で上限に達するケースです。この場合は生成が打ち切られます。Anthropicのドキュメントでは、新しめのモデルでは入力とmax_tokensの合計が上限を超えるリクエストも受け付けたうえで、生成が上限に達するとstop_reason: "model_context_window_exceeded"で停止する、と説明されています。古いモデルではこの場合に検証エラーになる、という差もあります。

一方、チャットのUI(claude.aiなど)では、古い発言から順に押し出す「先入れ先出し(FIFO)」で会話を回すことがある、ともAnthropicは注記しています。この場合、上限を超えると古い会話が黙って切り詰められ、AIが前半の内容を忘れたように振る舞うことがあります。

課金はトークン単位#

LLMのAPI料金は、原則としてトークン単位で課金されます。しかも多くの提供元で、入力トークンと出力トークンは単価が異なり、一般に出力のほうが高く設定されています。使ったトークンの量が、そのまま費用に直結する構造です。

だからこそ、送信前にトークン数を見積もる手段が用意されています。OpenAIはトークン数を数えるためのトークナイザ(tiktoken)やトークン数を数えるAPIを提供しており、Googleも入力を送る前にcountTokensを呼んでリクエストの大きさを確認することを推奨しています。Anthropicにもトークン数を見積もるためのtoken counting APIがあります。

注意したいのは、「文字数÷4」のような手元の概算は目安に過ぎないという点です。OpenAIのドキュメントは、画像やファイルはこの概算では正確に数えられず、ツールやスキーマも局所的に数えにくいトークンを追加すると指摘しています。正確なコスト試算をしたいときは、実際に使うモデルのトークナイザや公式のトークン数計測を使うのが確実です。トークン課金の全体像とコスト削減の定石は、別記事にまとめています。

上限が大きいほど良いとは限らない#

モデルのコンテキストウィンドウは年々拡大し、100万トークン級の大きな上限を持つモデルも登場しています。ただし、上限が大きいほど常に良い、というわけではありません。理由は主に2つあります。

1つはコストです。前述のとおり課金はトークン単位なので、大きな上限を活かして毎回大量の文脈を詰め込めば、その分だけ費用がかさみます。上限が大きいことと、毎回それを使い切るべきことは別問題です。

もう1つは精度です。Anthropicの公式ドキュメントは、トークン数が増えるにつれて正確性や想起(recall)が劣化する現象を「context rot(コンテキストの劣化)」と呼び、より多くの文脈が自動的に良い結果につながるわけではないと説明しています。関係の薄い情報を大量に入れると、モデルの注意が分散し、本当に重要な箇所が埋もれてしまうためです。長い入力では、中ほどに置いた情報が使われにくくなる傾向(いわゆる「lost in the middle」として知られる現象)も指摘されています。

実務の勘所#

トークンとコンテキストウィンドウの仕組みを、日々の実装にどう落とすかを整理します。

同じプレフィックス(システムプロンプトや共通の指示)を繰り返し送る用途では、プロンプトキャッシュを併用するとコストとレイテンシを下げられます。ただしキャッシュしたトークンもコンテキストウィンドウは消費する(算入される)点は変わらないので、上限の見積りとは切り離して考えます。

本記事のトークン数の目安(1トークンが英語で1文字から1単語程度、Geminiで約4文字、100トークンが約60から80英単語)、コンテキストウィンドウが入力と出力の合計上限であること、上限超過時のエラー・停止挙動、context rotの記述は、Anthropic「Context windows」、Google「Understand and count tokens」、OpenAI「Counting tokens」の各公式ドキュメント(2026年7月時点)を参照しています。具体的な上限値・料金・挙動はモデルや提供元により異なり、今後変わり得ます。実装時は使うモデルの最新の公式ドキュメントで確認してください。

よくある質問#

まとめ#

トークンはLLMが文章を測る単位であり、コンテキストウィンドウはその入力と出力の合計を縛る上限です。この2つを押さえると、料金表の読み方、上限に収める設計、そして「なぜ大量に詰め込むと逆に精度が落ちるのか」までが一本の線でつながります。まずは自分が使うモデルで、代表的な入力が何トークンになるかを実際に数えるところから始めてください。そのうえで、限られたコンテキストに何をどう載せるかという次の設計に進むと、コストと精度の両方を無理なく管理できるようになります。