Skip to Content
Docs10. LLM 基礎トークナイザとトークン経済
初級llm-foundationstokenizationcost-management更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

トークナイザとトークン経済

この記事の目的

LLM の課金・コンテキスト消費・速度の共通単位である「トークン」を正しく見積もり、計測できるようになります。「文字数で概算したら数倍外れた」「モデルを移行したら単価は同じなのに請求が変わった」という定番の失敗を、トークナイザ(tokenizer)の仕組みから防げる状態がゴールです。

対象読者

  • LLM アプリのコスト・コンテキスト予算を見積もる立場のエンジニア
  • 多言語対応やモデル移行で、トークン数の変動に直面している人

前提知識

本文

概要: トークンは LLM 世界の通貨

トークンは、モデルの入出力の最小単位であると同時に、課金の単位・コンテキストウィンドウの単位・生成速度の単位でもあります。API 料金は入出力トークン数に単価を掛けて決まり、コンテキスト上限「N トークン」もこの単位で数えられ、生成時間は出力トークン数にほぼ比例します。つまり LLM アプリの経済はトークン建てで動いており、文字数で考えている限り見積りは合いません。

テキストとトークン列を相互変換する部品がトークナイザです。重要な性質は 2 つ — 分割のされ方はテキストの内容と言語で大きく変わること、そしてトークナイザはモデル(世代)ごとに異なることです。

トークンとは何か: サブワード分割の直感

多くのテキスト LLM は「サブワード(subword)」方式でテキストを区切ります。BPE や SentencePiece はその代表例です。語彙に含む頻出の語・語片をまとめ、未知の語も複数の単位へ分解して扱います。文字・バイト単位を使う構成もあり、すべてのモデルが同じ方式や語彙を使うわけではありません。

  • 英語の一般的な単語は 1 トークン前後に収まることが多い
  • 日本語の分割単位は語彙に依存し、同じ内容の英語文とはトークン数が異なりうる
  • 空白・改行・記号・絵文字もトークンを消費する(コードのインデントは見た目より高くつく)
  • 数値やランダムな文字列(ID・ハッシュ)は圧縮が効かず、特に非効率

「珍しい文字列ほど分割が細かくなる」という直感を持っておくと、ログ ID の羅列やミニファイされていない JSON がコンテキストを大食いする理由が説明できます。

言語と内容による効率差

トークナイザの学習データ・語彙・前処理により、同じ意味の文章でも言語によってトークン数が変わります。日本語と英語の費用差を文字当たりの比率だけで決めず、代表的な同じ業務入力を採用モデルのカウント手段で比較します。実務への影響は 3 つです。

  1. コスト: 同じ機能を提供しても、日本語ユーザーのリクエストは英語より高くつくことがある。多言語プロダクトのコスト見積りは言語別に実測します
  2. コンテキスト予算: 「N トークンまで入る」の実容量が言語と内容で変わる。RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。 へ入れる文書も言語別に数えます(コンテキストエンジニアリング)
  3. プロンプトの言語選択: システムプロンプトを英語で書くとコンテキスト効率が上がる場合がありますが、出力品質・保守性とのトレードオフなので、効率だけで決めないことです

モデル間の非互換: 移行時の再見積り

トークナイザはモデルファミリーごと、ときには同一ベンダーの世代交代でも変わります。ここから見落とされやすい帰結が出ます。

  • 「同じプロンプト」のトークン数はモデルごとに違う: 単価が同じでも、トークナイザが変われば請求が変わります。モデル移行の比較は「単価 × 自社ワークロードの実測トークン数」で行います(モデル選定ガイド、主要 LLM の全体像)
  • コンテキスト上限の比較も同じ罠: 上限値が同じでも、トークナイザの効率が違えば「入る文章量」は変わります
  • 世代交代での更新: 同一ベンダー内でも新世代でトークナイザが更新されることがあります。移行の際は、公式のカウント手段で自社の代表的なプロンプト・文書を数え直すのが確実です(バージョニング・デプロイ・モデル更新追従)

見積りと計測の実務

  • 見積りは公式のカウント手段で: 各社が提供するトークンカウント API・ライブラリで、自社の実データ(代表的なプロンプト・文書・会話)を数えます。「1 トークン ≈ 何文字」の定数換算は、言語と内容によって数倍単位で外れます
  • 計測は usage を毎回記録する: API レスポンスに含まれる使用トークン数(usage)をトレースに記録します。これがコスト管理・履歴肥大の検知・キャッシュ効果の測定の一次データになります(コスト管理、可観測性とトレーシング)
  • 会話は「積み上がる」: チャット形式では毎ターン過去履歴を再送するため、入力トークンはターンごとに積み上がります。この構造への対処(履歴圧縮・キャッシュ)はコスト管理とメモリと状態管理が正です

この理解が効く場面

  • コスト見積りの精度: 「ユーザーあたり月いくら」を言語・実データベースで出せる(ROI とビジネスケースのコスト側の入力にもなります)
  • コンテキスト予算の設計: 何をコンテキストに入れるかの取捨選択を、体感ではなくトークン数で判断できる(コンテキストエンジニアリング)
  • モデル移行の判断: 単価表の比較ではなく実測トークン数での比較ができる

実務での注意点

アンチパターン

  • 文字数 × 定数でコストを見積もる → 言語・内容によって数倍外れ、予算が崩れる → 公式のカウント手段で自社の実データを測る
  • モデル移行時にトークン数を再見積りしない → 単価が同等でもトークナイザ差で請求・コンテキスト消費が変わる → 移行前に代表データで数え直す
  • usage をログに残さない → コスト異常や履歴肥大に気付くのが請求書になる → リクエストごとの usage をトレースに記録する
  • 英語での実測値を日本語にそのまま適用する → 言語・語彙の差によってコストとコンテキストの見積りが外れる → 主要言語ごとに実測する

チェックリスト

  • コスト・コンテキストの見積りに公式のトークンカウント手段を使った
  • 対応する主要言語ごとにトークン効率を実測した
  • リクエストごとの usage(入出力トークン数)を記録している
  • モデル移行の手順に「トークン数の再見積り」が含まれている
  • ID・ログ・生 JSON など非効率なデータをコンテキストに入れる前に加工を検討した

関連トピック

参考資料

TODO・未確認事項

なし

LLM はどうやってテキストを生成するか注意機構とコンテキストウィンドウの仕組み