はじめに:この token は、あの token ではない
最初に、いちばん混同されやすい点を確認しておきたい。今日扱う token は、ログイン認証で使う token や、暗号資産でいう token とはまったく別の概念だ。
私たち人間には、「この資料を要約してください」は一つの自然な文に見える。だが AI は、私たちが見ている文をそのまま理解しているわけではない。まず文字をより小さな単位に分割し、そのうえで後続の処理を行っている。この「より小さな単位」が token だ。
以下、大きく三つに分けて見ていく。token とはそもそも何か、推論はどのように進むのか、そして費用はどう決まるのか。token が分かれば、この三つはすべて筋が通る。
一、AI が受け取るのは文章そのものではなく、token ID の列
もっとも基本的な流れはこうだ。人間が入力するのは文字、たとえば「token とは何か?」。人間にとっては普通の一文だが、モデル内部では自然言語の文字列をそのまま処理することはできない。その前に Tokenizer(分割器) という処理を通す必要がある。
Tokenizer の役割は二つ。文字をより小さな単位に分割し、語彙表にもとづいてそれぞれの単位を番号へ変換する。この番号が token ID と呼ばれる。モデルが実際に受け取るのは、私たちの目に見えている文字ではなく、数字の列だ。
人間が見るもの: token とは何か?
│
▼ ① Tokenizer で分割
token に分割: [token] [と] [は] [何] [か] [?]
│
▼ ② 語彙表を引いて番号に変換
token ID: [ 2374 ] [ 891 ] [ 55 ] [ 4102 ] [ 67 ] [ 31 ]
│
▼
モデルが実際に受け取るのは、この数字の列
プログラミングにたとえると分かりやすい。私たちがコードを書くとき、書いているのは人間にとって読みやすい高級言語だ。しかしコンピュータが実行するときには、機械が処理できる形式へ変換する必要がある。AI による自然言語処理もこれに似ていて、自然言語はまず tokenizer を通り、token と token ID に変換され、その数字をもとにモデルが推論を進める。
ここで重要なのは、実際にどう分割されるか、いくつの token になるか、どの ID に対応するかは、世界共通で固定されているわけではないという点だ。使うモデルや tokenizer によって変わる。
二、token 数は文字数でも単語数でもない
誤解されやすい点を見ていこう。token 数は、文字数と同じではない。単語数とも同じではない。
例として「お誕生日おめでとう」という日本語の文をとる。見た目は 9 文字だ。しかし encoding、つまり tokenizer の分割方法が異なると、結果も変わる。OpenAI Cookbook の例では次のようになる。
| Encoding | token 数 |
|---|---|
r50k_base(少し古い) |
14 |
cl100k_base |
9 |
o200k_base |
8 |
だから、ある文の token 数を「永久に固定された答え」として覚える必要はない。本当に覚えておくべき原則は一つ、token は tokenizer によって決まるということ。同じ文でも、モデルや tokenizer が変われば token 数も変わりうる。
実際の開発やコスト見積もりで正確な数字が必要なら、対象モデルの tokenizer や公式ツールで確認するのがいちばん確実だ。
三、語彙表:文字から数字への辞書
もう一段深く見ると、モデルごとに tokenizer や**語彙表(vocabulary)**の設計が異なる場合がある。
この語彙表は、辞書の目次のようなものだ。分割された単位が得られたあと、それを対応する token ID へ変換する。つまり「文字から数字」への変換に使われる。
ここでは DeepSeek を例にする。DeepSeek はオープンソースなので、語彙表の設計を実際に見ることができる。
https://huggingface.co/deepseek-ai/DeepSeek-V3/raw/main/tokenizer.json
tokenizer.json を見ると、たとえば次のような取り決めになっている。
id 0 → 開始を表す記号
id 1 → 終了を表す記号 ← これが出力されたら「出力が完了した」の意味
id 2 → 空白
id 3 → 感嘆符
...
つまり、AI のある推論で id 1 の token が出力されたら、それは「出力が完了した」という意味になる。
ここで持ってほしい感覚は、AI に入力されるのは最終的にはすべて数字の情報だということ。そして、人間が入力した文字を対応する数字へ変換するには、このような表が必要になる。
四、token ID は「意味の座標」へ変換される — 埋め込みベクトル
では、AI は token ID という数字を受け取ったら、そのまますぐ推論を始めるのだろうか。実はそうではない。次に、その token の意味情報を取得する必要がある。
たとえば AI に apple という単語を入力したとする。これは食べ物のりんごを指すのか、それとも Apple 社や iPhone のような意味なのか。文脈によって変わる。これを区別するために意味情報が要る。
token ID がファイルの中で定義された番号であるのに対し、token の意味は一般に学習によって得られ、高次元のベクトルとして表現される。
これは「意味空間の中の座標」と考えると分かりやすい。二つの単語の意味が近ければ、その空間内での位置も近くなる。
意味空間(イメージ)
猫 ● 犬 ● 子犬 ← 動物。互いに近い
自動車 ● トラック ← 乗り物。動物からは遠い
大規模言語モデルは、推論のたびに同じ次元数のベクトルを出力する。そして、そのベクトルがどの token のベクトルにもっとも近いかを計算し、近い token を出力として選ぶ。
概念としては少し抽象的に感じるかもしれないが、数学的な原理は大学の線形代数の基礎にかなり近い。興味があれば、Udemy などで AI の原理に関する講座を見てみると理解しやすいと思う。
五、推論の全体像:一つの文から一つの回答まで
ここまでの要素をつなげると、人間が入力する文字から最終的な出力が生成されるまでは、おおむね次の手順を通る。
- 文字を入力する
- プログラムが文字を token に分割する
- token を対応する数字の ID に変換する
- 数字の ID から対応する特徴ベクトル(embedding)を取得する
- 特徴ベクトルに位置情報を加える
- この [特徴ベクトル + 位置情報] からなる高次元の行列を大規模言語モデルへ入力して計算する
- 計算のたびに token を一つずつ出力し、終了記号が出るまで続ける
一つの例で通してみる
例として、とてもシンプルな質問を使う。「日本で一番高い山は?」
第一ステップ、文字の入力。つまり、私たち人間が書いた自然言語だ。
第二ステップ、token 化。この文は 7 個の token に分割され、それぞれに ID が対応する。
[日本] [で] [一番] [高い] [山] [は] [?]
│ │ │ │ │ │ │
ID ID ID ID ID ID ID
第三ステップ、それぞれの token の特徴ベクトルを取得する。各 token の特徴ベクトルは、モデルの学習が完了したあとは基本的に固定されている。
第四ステップ、特徴ベクトルに位置情報を重ねる。同じ単語でも、文の中で現れる位置が違えば意味も変わる。たとえば「私はあなたを愛している」と「あなたは私を愛している」では、使っている単語は似ていても意味はまったく違う。位置情報は、この順序を表すためのものだ。
第五ステップ、最終的に生成された行列データを大規模言語モデルへ入力し、推論を始める。推論では一度に一つの token だけを出力し、終了記号が出るまで続く。
1 回目の推論 → 出力ベクトルが「富士山」に最も近い → 「富士山」を出力(終了記号でない、続行)
2 回目の推論 → 「です」に最も近い → 「です」を出力 (終了記号でない、続行)
3 回目の推論 → 句点「。」を出力 → (終了記号でない、続行)
4 回目の推論 → 終了記号を出力 → 推論完了
最後に、モデルが生成する回答は「富士山です。」となる。
「意味」だけでなく「順序」も必要
第三・第四ステップは、もう少し強調しておきたい。
第三ステップでは、モデルは token ID を使って内部の「埋め込みテーブル(embedding table)」から対応するベクトルを検索する。token ID は目次番号、特徴ベクトルはその番号に対応する中身、と考えると分かりやすい。このステップは推論時にその場で新しく計算しているわけではなく、モデルの学習が完了したあと、内部パラメータとしてすでに保存されている。推論時には、主に token ID にもとづいて対応するベクトルを取り出す。
ただし「意味」だけでは不十分だ。モデルは、それぞれの token の順序も知る必要がある。そこで第四ステップで位置ベクトルを加える。embedding ベクトルに位置ベクトルを加えることで、入力行列 X が得られる。この行列では、おおよそ各行が一つの token に対応し、各列がその token のある特徴次元に対応する。
ここで大事な直感は、私たちが書いているのは一つの文でも、大規模言語モデルに入るときには数字の行列になるということ。その後の推論は、本質的にこの行列を中心に大量の計算を行う処理だ。
六、費用は通常、入力 token と出力 token で決まる
token が理解できると、費用の仕組みもかなり説明しやすくなる。token は電気やガスのようなものだと考えるとよい。多く使えば費用が増え、少なく使えば費用も抑えられる。
多くの AI API では、token 数にもとづいて料金が計算される。通常は二種類に分かれる。
- 入力 token:AI に渡す文字、資料、会話履歴、ログ、コードなど。
- 出力 token:AI が生成する回答。
実務上、覚えておきたいポイントは三つ。
- 価格は通常「100 万 token あたり」で表示される。
- 出力 token は入力 token より高いことが多い。
- 同じ入力を何度も再利用する場合、一部のサービスではキャッシュ機能でコストを下げられることがある。
七、議事録の要約を例に token 量を見積もる
日常業務に近い例で token 量を見積もってみよう。
たとえば、約 3000 字の議事録があり、それを AI に要約してもらうとする。実際の呼び出しでは、入力は議事録本文だけではない。「決定事項、TODO、担当者ごとに表形式で整理してください」といった指示も含まれる。
かなり粗い例として、次のように見積もる。
入力 ≈ 5000 tokens
出力 ≈ 1000 tokens
─────────────────────
1 回の呼び出し ≈ 6000 tokens
もし AI 提供会社の価格が「100 万 token あたり 500 円」だとすると、この一回の呼び出しにかかる費用は約 3 円だ。
もちろん、この数字は固定の公式ではなく、あくまで量感をつかむための例だ。日本語や中国語のようなテキストでは、ざっくり「1 token は 1 文字前後」と見積もれることも多いが、実際にはモデルや tokenizer によって変わる。
日常的な判断なら粗い見積もりで十分なこともある。一方で、システム開発・予算評価・大量呼び出しを行う場合には、各社の公式 tokenizer や token counting ツールを使って正確に計算するべきだ。
八、モデルによって価格は大きく変わる
同じタスクでも、提供会社やモデルが違えば、コストが数十倍変わることがある。
1000 回程度の同じようなタスクを実行する例で見ると、おおむね「OpenAI の高性能モデルがもっとも高く、DeepSeek がもっとも安い」という形になる。
- 高性能モデルが向くのは:複雑な推論、重要文書、品質要求が高い場面。
- 安価なモデルが向くのは:大量でシンプルな処理や、ある程度の誤差を許容できる場面。
実務で大事なのは、常に一番高いモデルを使うことでも、常に一番安いモデルを使うことでもない。タスクのリスク、品質要求、コストに応じて、適切なモデルを選ぶことだ。
九、まとめ:今日覚えておきたい四つのポイント
最後に、AI token について今日覚えておきたいことを四つにまとめる。
-
token は AI が処理する情報量の単位だ。 AI は文章全体をそのまま処理しているのではなく、文章を token に分割し、それを数字表現に変換して処理している。
-
AI の回答は token を一つずつ生成して作られている。 次の token を予測し、それを文脈の後ろにつなげていき、回答が終わるまで続ける。
-
入力が長くなるほど、また出力が長くなるほど、コストと処理時間は通常増える。 モデルが処理しなければならない token が増えるためだ。
-
実際に使うときは、必要な情報だけをできるだけ絞って渡し、出力の形式や長さを明確に指定する。 「こんにちは」「ありがとうございます」のような、処理上あまり必要のない言葉を毎回入れすぎないことも大切だ。AI には感情があるわけではないので、目的に対して必要な情報を簡潔に渡す、という意識を持つとよい。
この四つを押さえれば、AI の使い方は「なんとなく」から「見通しを持って」へと変わっていく。