◀ 10.

トークン / コンテキストウィンドウとは？料金・上限・最適化

▶

編集

本稿は トークン（Token）とコンテキストウィンドウ（Context Window） に関する記事です。

この記事の要点

トークン = LLM が処理する最小単位。「単語」とは限らず、サブワード（文字列の断片）
日本語は1 文字 ≒ 1〜2 トークンになりがちで、英語より消費が多い
コンテキストウィンドウ = 1 回のリクエストで入出力できる最大トークン数
2026 年現在: GPT-5 / Claude 4 / Gemini 2.5 で20 万〜100 万トークン超が一般的
API は入力 + 出力 + システムプロンプトすべてが上限内に収まる必要
料金は入力トークン × 単価 + 出力トークン × 単価。出力の方が高いケースが多い
長コンテキストでも中央が見落とされる「Lost in the Middle」問題が知られる

トークンとは？

トークン (Token) は、LLM がテキストを処理する際の最小単位です。LLM は文字列をそのままではなく、トークナイザで分割した整数 ID 列として扱います。

「単語ごとに分割」と思われがちですが、現代の LLM はサブワード（部分文字列）でトークン化します。これにより未知の単語も扱え、辞書サイズを抑えられます。

トークン化の例

文字列	トークン分割例 (GPT 系)	トークン数
`Hello, world!`	`["Hello", ",", " world", "!"]`	4
`tokenization`	`["token", "ization"]`	2
`こんにちは`	`["こん", "にち", "は"]` 等	3〜5
`機械学習`	`["機", "械", "学", "習"]` 等	4〜8
`🎉`	絵文字 1 個	3〜4

補足: 日本語のトークン消費は英語の 1.5〜2 倍
英語は単語＋スペース単位で効率良く圧縮されますが、日本語はバイト単位や漢字 1 文字 = 数トークンに分割されることがあり、同じ意味の文章で英語の 1.5〜2 倍のトークンを消費します。GPT-4o 以降は日本語向けに改善されつつありますが、API コストの見積もり時に意識すべき点です。

主要トークナイザ

方式	採用モデル	特徴
BPE (Byte-Pair Encoding)	GPT 系、Llama、Mistral	頻出ペアを統合して語彙構築
WordPiece	BERT 系	BPE 派生
SentencePiece	多言語モデル、T5、mT5	言語非依存、空白も含む
Tiktoken	OpenAI 公式 BPE 実装	高速・GPT 互換

コンテキストウィンドウとは？

コンテキストウィンドウ は、LLM が1 回のリクエストで処理できるトークンの最大数です。「入力 + 出力 + システムプロンプト」のすべてが上限内に収まる必要があります。

主要モデルのコンテキストウィンドウ（2026 年時点の目安）

モデル	入力上限	出力上限
GPT-4o	128K	16K
GPT-5 / o3	200K〜	32K〜
Claude 3.5 Sonnet	200K	8K
Claude 4 Opus / Sonnet	200K〜	32K〜
Gemini 2.5 Pro	1M〜2M	8K〜
Llama 3.x 系	128K (バリアント次第)	8K〜
Mistral Large 2	128K	8K
DeepSeek V3	128K	8K

数値はバージョンによって変動します。1M = 100 万トークン ≒ 70〜80 万英単語 ≒ 文庫本 5〜10 冊分に相当します。

トークン数の見積もり方

言語	概算ルール
英語	1 トークン ≒ 0.75 単語 ≒ 4 文字
日本語	1 文字 ≒ 1〜2 トークン（モデル依存）
コード	言語による。Python は比較的効率良し
JSON	記号類が多くトークン消費大
画像 (マルチモーダル)	1 枚で 200〜10000 トークン相当（解像度依存）

事前にトークン数を測る方法

# OpenAI モデルの場合
pip install tiktoken

import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o")
tokens = enc.encode("ここに文章")
print(len(tokens))

# Hugging Face モデル
from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("meta-llama/Llama-3.2-3B")
print(len(tok.encode("ここに文章")))

料金との関係

料金体系の基本	内容
入力単価	1M トークンあたり数十セント〜数ドル
出力単価	入力の3〜5 倍が一般的（生成は重い）
キャッシュ割引	同じプロンプトを使い回す場合、入力単価が大幅割引（OpenAI / Anthropic / Gemini で対応）
バッチ割引	非リアルタイムなら 50% 引き等（OpenAI Batch API）
画像入力	解像度に応じてトークン換算

長コンテキストの「Lost in the Middle」問題

注意: 長文を入れれば良いわけではない

LLM は長い入力でも先頭と末尾を優先的に参照し、中央の情報を見落とす傾向があります（"Lost in the Middle" 現象）。

対策:

重要な情報はプロンプトの先頭または末尾に置く
RAG で関連箇所だけ抽出して投入する
セクション区切り（--- 区切り --- 等）で構造化
本当に長い文書は要約してから入れる

運用上のヒント

Tips

本番アプリは事前にトークン数を計測してから API 呼出（上限超過防止）
長い会話履歴は古い部分を要約して圧縮
システムプロンプトを変えない設計ならプロンプトキャッシュで大幅コスト削減
出力長は max_tokens で必ず制限（無限生成のコスト爆発防止）
用途別に軽量モデル / 大型モデルを使い分け（同じプロンプトでも料金が桁違い）
長コンテキストはレイテンシも増える。リアルタイム性が重要なら短く保つ

注意点

よくある落とし穴

サイレント切り捨て: 上限超過で末尾が黙って削られるモデルがある。事前計測必須
料金見積もりミス: 日本語は英語の倍くらいトークンを使うことを忘れがち
会話履歴の肥大化: 何ターンも続けると履歴で上限を圧迫
モデル切替時の互換性: トークナイザが違うと同じ文字列でもトークン数が異なる
「全部入れれば賢くなる」誤解: Lost in the Middle で逆に精度が落ちる
JSON や Markdown は記号でトークン消費が増える。Structured Output API を使うとオーバーヘッド削減

ページ一覧

その他