LLMのAPI料金や入力上限を調べると、必ず「トークン数」という単位が出てくる。一方で、日本語の文章を書くときは「何文字か」で感覚を持っている人が多い。
この記事は、トークンとコンテキストウィンドウを初心者向けに整理し、実務でコスト試算やプロンプト設計をするときに「文字数ではなくトークンで考える」理由を説明する。
トークンとは何か
トークン（token）は、LLMがテキストを処理するときの最小単位だ。
人間が「単語」や「文字」で文章を区切るのに対し、モデルは学習時に使ったトークナイザーという仕組みで、テキストをトークンの列に変換してから処理する。
OpenAIのドキュメントでは、トークンは「単語の断片（piece of a word）」と説明されている。
英語では hello が1トークンになることもあれば、understanding が under + stand + ing のように複数トークンに分割されることもある。
LLMの生成処理は、ざっくり言うと 「与えられたトークン列の続きを、1トークンずつ予測する」 という動きだ。
だから課金・上限・速度の議論は、ほぼ例外なくトークン単位で行われる。
なぜ「文字数」では測れないのか
サブワード分割のため
現代のLLMは、語彙全体を1語ずつ覚えるのではなく、頻出する断片（サブワード） を組み合わせて表現する方式（BPEやSentencePieceなど）を使うことが多い。
同じ見た目の文字列でも、言語・記号・改行の有無によってトークン数は変わる。
たとえば、次の2文は日本語の文字数は近いが、トークン数は一致しないことがある。
今日は天気がいいですね。
今日は、天気が、いいですね！
句読点・記号・全角半角の違いが、トークン分割に影響する。
「1000文字 ≒ 1000トークン」という換算は成り立たないのが実務上の前提だ。
日本語は1文字あたりのトークン消費が多い傾向
英語は比較的「短いトークン列」で表現しやすい一方、日本語は漢字・かなが混在するため、同じ情報量でもトークン数が増えやすい傾向がある。
英語向けのコスト感覚をそのまま日本語プロンプトに当てはめると、試算がずれる典型パターンになる。
目安として使えるざっくり換算
正確な数はモデルとトークナイザー依存だが、初心者の感覚づくりとしては次の表が参考になる。
| 言語・形式 | ざっくり目安（1トークンあたり） | 注意点 |
|---|---|---|
| 英語 | 約4文字（0.75語程度） | 単語の長さでブレる |
| 日本語 | 1〜2文字程度 | 漢字・記号で変動大 |
| コード | 行数より記号密度が効く | インデント・コメントもカウント対象 |
正確に数えたいときは、各プロバイダが提供するトークンカウント用ツールやAPIを使うのが確実だ。
# OpenAI公式ライブラリでの例（tiktoken）
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o")
text = "トークン数を正確に数えるには、トークナイザーを使う。"
tokens = enc.encode(text)
print(len(tokens)) # トークン数
print(tokens) # トークンID列
コンテキストウィンドウとは何か
コンテキストウィンドウ（context window）は、モデルが一度の推論で参照できるトークン数の上限だ。
入力（プロンプト）と出力（生成テキスト）を合わせた総量が、この上限を超えない必要がある。
よくある誤解は次の2つだ。
| 誤解 | 実際 |
|---|---|
| 「会話のターン数」が上限 | ターン数ではなく、送ったテキスト全体のトークン合計が上限 |
| 「古いメッセージは自動で忘れてくれる」 | サービス側の要約・切り捨て実装に依存。仕様として保証されない |
モデルによってコンテキストウィンドウの大きさは異なる。
たとえば、2026年時点の主要モデルでは、数万〜100万トークン級のウィンドウを謳る製品もあるが、大きいほど常に安い・速いというわけではない。
長い入力はレイテンシとコストが増える。
入力と出力の関係
多くのAPIでは、次のように考える。
消費トークン ≒ 入力トークン + 出力トークン
コンテキストウィンドウが128Kトークンのモデルでも、入力に120K使えば出力に使える余地は約8Kしかない。
長文の資料を丸ごと渡して「詳細なレポートを書いて」と依頼すると、出力が途中で切れるのはこのためだ。
実務での見積もりと設計のポイント
コスト試算はトークン単価 × トークン数
API料金表に載っているのは「$ / 1M input tokens」「$ / 1M output tokens」のような形式が一般的だ。
文字数から逆算するのではなく、代表プロンプトを実際にトークナイズしてから試算するのが安全だ。
プロンプト設計で効く3つの工夫
| 工夫 | 効果 | 例 |
|---|---|---|
| 要約してから渡す | 入力トークン削減 | 100ページPDF → 章ごとの要約だけRAGに載せる |
| 出力上限（max_tokens）を明示 | 想定外の長文生成とコスト暴走を抑制 | max_tokens=500 |
| システムプロンプトを固定・短く保つ | 毎リクエストの固定コストを下げる | 役割定義は簡潔に、詳細はユーザーメッセージへ |
会話履歴の扱い
チャットUIで過去のやり取りを全部送り続けると、トークンはリクエストごとに累積する。
実装では、次のいずれか（または組み合わせ）が一般的だ。
- 直近Nターンだけ送る
- 古い履歴を要約して1メッセージに圧縮する
- 重要な事実だけ構造化（JSON等）して保持する
どの方式を選んでも、上限はトークン数で管理するのが基本になる。
実装チェックリスト
- 本番で使うモデル名とトークナイザーで、代表プロンプトのトークン数を計測した
- 入力単価・出力単価を料金表から確認し、1リクエストあたりの上限コストを試算した
-
max_tokens（または同等パラメータ）で出力上限を設定した - コンテキストウィンドウに対し、入力＋想定出力が収まるか確認した
- 長文ドキュメントは要約・チャンク分割・RAGなどで入力を絞る設計にした
- 会話履歴の保持方式（直近のみ／要約／切り捨て）を決め、ログでトークン使用量を監視している
失敗パターン
パターン1：文字数ベースでコスト見積もりをする → 対策：実際のトークナイザーで計測する。日本語プロンプトは特に乖離しやすい。
パターン2：コンテキストウィンドウが大きい＝何でも丸ごと渡せると思い込む → 対策：入力を圧縮し、出力に必要なトークン分の余裕を確保する。
パターン3：会話履歴を無制限にAPIへ送り続ける → 対策：直近Nターン制限、要約、またはトークン上限での切り捨てを実装する。
パターン4：出力が途中で切れても「モデルが壊れた」と判断する → 対策：max_tokens と残りコンテキストを確認する。必要なら続きを生成する設計か、入力を短くする。
まとめ
- トークンはLLMが処理する最小単位で、課金・上限・速度はほぼトークン基準だ。
- 文字数とトークン数は一致しない。日本語は特に1文字あたりのトークン消費が増えやすい。
- コンテキストウィンドウは「一度に扱えるトークン総量の上限」であり、入力と出力の合計で効く。
- 実務ではトークナイザーで計測し、履歴管理と出力上限をセットで設計するのが基本だ。
参考リンク
- What are tokens and how to count them? (OpenAI Help Center)
- Tokenization (OpenAI Cookbook)
- Understanding tokens (Anthropic Docs)
- Context windows (Anthropic Docs)
- Introduction to Large Language Models (Google Cloud)
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。