LLMのトークンとは？数え方と料金・コンテキストとの関係を解説
LLMにおけるトークンとは、モデルが文章を読み書きするときの最小単位です。 文字でも単語でもなく、その中間にあたる「サブワード」と呼ばれる断片で、LLM APIの料金はこのトークンの数で決まります。OpenAI互換APIを使ううえで、リクエストの上限もコストも、すべてトークンを基準に考えることになります。
この記事では、トークンがどう作られるのか、入力と出力でどう数えるのか、そしてコンテキストウィンドウや料金とどう結びつくのかを整理します。
トークンとは：文字でも単語でもない単位
人間は文章を「文字」や「単語」で捉えますが、LLMはテキストをまずトークン列に変換してから処理します。この変換を行うのがトークナイザで、多くのモデルは BPE（Byte Pair Encoding）系の方式を採用しています。
BPEは、学習データの中で頻繁に隣り合う文字の組み合わせを順にまとめていき、数万〜数十万件の「語彙」を作ります。よく出てくる英単語は1トークンにまとまり、珍しい単語は複数の断片に分かれる、という具合です。
目安としては次のとおりです（モデルによって変わります）。
| テキスト | トークン数の目安 |
|---|---|
| 英語の一般的な単語 | 約1トークン（3〜4文字程度） |
| 日本語の文字 | 1文字あたり1〜2トークン程度 |
| 空白・記号・絵文字 | それぞれ1トークン以上 |
重要なのは、同じ文章でもモデルが変わればトークン数も変わるという点です。語彙はモデルごとに違うため、「このプロンプトは何トークンか」はモデルを決めてから初めて答えが出ます。
なぜトークンが課金の単位なのか
LLMの計算量は、処理するトークンの数にほぼ比例します。長い入力を読めば読むほど、長い出力を生成すればするほど、計算資源を使います。だからAPIの料金は「リクエスト回数」ではなくトークン数で決まります。
課金は2種類に分かれます。
- 入力トークン（prompt tokens） — システムプロンプト、会話履歴、ユーザーの質問など、モデルに渡すすべてのテキスト。
- 出力トークン（completion tokens） — モデルが生成した応答。
多くのモデルで出力トークンの単価は入力より高く設定されています。つまり「長い応答を返させる」ことは、「長いプロンプトを送る」こと以上にコストへ効きます。FastMetalでも課金はこの入力・出力それぞれのトークン数に基づき、モデルごとの単価は料金ページで確認できます。
トークン数の数え方：レスポンスの usage が正解
「送る前に正確なトークン数を知りたい」という要望はよくありますが、実務で最も確実なのはレスポンスに含まれる usage を見ることです。これはモデル自身のトークナイザで数えた値なので、推測ではなく実測になります。
curl https://api.fastmetal.ai/v1/chat/completions \
-H "Authorization: Bearer $FASTMETAL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "anthropic-claude-haiku-4-5",
"messages": [
{"role": "user", "content": "トークンとは何ですか？一文で答えてください。"}
]
}'
レスポンスの末尾に、次のような usage が含まれます。
{
"usage": {
"prompt_tokens": 24,
"completion_tokens": 38,
"total_tokens": 62
}
}
prompt_tokens— 入力トークン数completion_tokens— 出力トークン数total_tokens— その合計
数値はあくまで例で、実際の値はモデルと文面で変わります。開発中は、代表的なプロンプトを数パターン投げて usage をログに残しておくと、コストの見積もりが現実に近づきます。
送信前に見積もりが必要な場合は、FastMetalが公開しているトークンカウント用のエンドポイントも利用できます。ただし最終的な課金は、実際のリクエストで返る usage の値に基づきます。
コンテキストウィンドウとの関係
各モデルには、一度に扱えるトークン数の上限があります。これがコンテキストウィンドウで、入力と出力の合計がこの枠に収まる必要があります。
会話が長くなると履歴がすべて入力トークンとして毎回送られるため、枠を圧迫するだけでなく、リクエストごとのコストも積み上がっていきます。「上限に達してエラーになる」より前に、「毎回のリクエストが静かに高くなっている」ことのほうが実務では厄介です。詳しくはコンテキストウィンドウの解説を参照してください。
日本語はトークンを多く使う
同じ内容でも、日本語は英語よりトークン数が膨らみやすい傾向があります。語彙が英語中心のデータで学習されているため、日本語は細かく分割されがちだからです。ただしトークナイザの世代やモデルによって差は大きく、モデル選びとプロンプトの書き方で縮められます。この点は日本語のトークンコストの記事で詳しく扱っています。
料金を抑えるための基本
トークンの仕組みが分かると、コスト削減の打ち手も自然に見えてきます。
- 出力の長さを指示する — 「200字以内で」など上限を示すと、単価の高い出力トークンを抑えられます。
- 履歴は必要な分だけ送る — 会話全体ではなく、直近の数往復や要約だけを渡します。
- タスクに合ったモデルを選ぶ — 分類や抽出のような定型処理は、軽いモデルで十分なことが多いです。
- usage を計測し続ける — 推測でなく実測で、どのリクエストが重いのかを把握します。
より踏み込んだ方法はLLM APIのコストを下げる方法にまとめています。
よくある質問
Q. トークンと文字数はどう違いますか？ 文字数はテキストそのものの長さですが、トークン数はモデルのトークナイザがテキストを分割した結果の数です。英語は数文字で1トークン、日本語は1文字が1〜2トークンになることが多く、同じ文章でもモデルによって値が変わります。
Q. 入力と出力、どちらのトークンが課金に効きますか？ 両方が課金されますが、多くのモデルで出力トークンの単価のほうが高く設定されています。長い応答を返させる設計は、長いプロンプトを送る以上にコストへ影響します。
Q. 送信前に正確なトークン数を知る方法はありますか？
最も確実なのは、実際のレスポンスに含まれる usage を確認することです。事前の見積もりにはトークンカウント用のエンドポイントも使えますが、課金は実リクエストの usage に基づきます。
まとめ
トークンは、LLMがテキストを扱う最小単位であり、料金とコンテキストの両方を決める基準です。仕組みを理解し、レスポンスの usage で実測する習慣をつければ、コストは推測ではなく数字で管理できます。Chat Completions APIの基本と合わせて押さえ、ドキュメントから最初のリクエストで usage を確認してみてください。利用できるモデルはモデルカタログにまとまっています。