トークン（Token）は、LLMがテキストを処理するときの最小単位です。定義だけなら一行ですが、実務では料金・速度・入力可能な長さすべてがトークン基準で決まります。本記事はプロンプトの書き方やモデル構造ではなく、「何トークン使っているか」という運用の感覚に絞って整理します。
試験で問われる見方
生成AIパスポートでは、「トークン＝一文全体」といった過度に粗い定義が×になる問題があります（TF-0156）。また、LLMが次のトークン確率を計算して出力する、という生成の仕組みと結びつく問題もあります。
G検定では、系列生成や教師強制の説明で「トークン」が登場します。NLPの文脈では系列の要素として理解しておくとよいです。
トークンとは
人間が文章を「単語」で読むように、LLMは入力をトークン列に変換して処理します。トークンは、英語の単語全体だったり、日本語の数文字だったり、記号や改行の一部だったりします。分割の仕方はTokenizer（トークナイザ）という仕組みに依存し、モデルごとに異なります。
LLMの出力も、1トークンずつ（内部的には確率計算の上で）追加されていきます。だからこそ、出力が長いほど時間とコストが増えるのです。
単語・文字と同じではない
試験でよくある誤解を表にまとめます。
| 誤解 | 実際 |
|---|---|
| 1文＝1トークン | ×。文は多くのトークンに分割される |
| 1単語＝1トークン | 必ずしもそうではない（語の一部に分割されることも） |
| 日本語1文字＝1トークン | Tokenizer次第。英語よりトークン効率が悪いことが多い |
| トークン数＝文字数 | APIの課金・上限は文字数ではなくトークン基準が一般的 |
日本語の目安
厳密な換算はモデルとTokenizerによりますが、実務のざっくり感覚（2026年6月時点）として次を覚えておくと便利です。
- 英語 — おおよそ4文字前後が1トークン程度になることが多い
- 日本語 — 1文字あたりのトークン消費が英語より大きいことが多く、同じ意味でも日本語の方がトークン数が増えやすい
- コード・記号 — インデントや記号もトークンになる。無駄な空行も積み重なる
長い日本語のプロンプトを毎回丸ごと送ると、気づかないうちに上限や料金に効いてきます。
コンテキスト上限との関係
モデルにはコンテキストウィンドウ（一度に扱えるトークン数の上限）があります。入力（プロンプト＋会話履歴）と出力の合計がこの上限を超えると、古い履歴を切り捨てるか、エラーになるか、要約するか——製品の挙動は異なります。
| 消費されるもの | 例 |
|---|---|
| システム指示 | アプリが裏で入れる役割設定 |
| ユーザー入力 | 貼り付けたPDF全文、長いコード |
| 過去の会話 | 多ターン対話の履歴すべて |
| モデル出力 | 長文回答・コード生成 |
用語としての詳細はコンテキストウィンドウの記事を参照してください。
料金・コストの考え方
クラウドAPIでは、多くの場合入力トークン単価と出力トークン単価が別です。出力の方が高いプランもあります。チャットUIの定額プランでも、裏側では同様の制約があると考えてよいです。
入力が長い
毎回同じ長い指示を送ると、リクエストごとに課金が重なる
出力を長く要求
「詳しく」「箇条書き100個」などはトークンと時間が増える
履歴を溜める
会話が長いほどコンテキストが膨らむ。新規チャットも選択肢
トークンを節約するコツ
試験知識と実務の橋渡しとして、次を覚えておくと十分です。
- 依頼は簡潔に、要件は明確に — プロンプトの4要素は維持しつつ冗長表現を削る
- 長文は要約してから渡す — 全文貼り付けより、必要段落だけ
- 出力長の上限を指定 — 「300字以内」「5項目まで」
- 会話をリセット — 話題が変わったら新規スレッド