第1章: 言葉を「単位」に切る — トークン化
ChatGPT に「東京タワーまで歩いて何分？」と入力する。 あなたから見れば、自然な日本語文だ。
ところが画面の向こうの機械にとって、まず最初の仕事は この文字列をどこで切るか を決めることだ。 「東京 / タワー / まで / 歩い / て / 何分」なのか、 「東京タワー / まで / 歩いて / 何分」なのか。 あるいはもっと細かく「東 / 京 / タワ / ー」かもしれない。
この 切り方ひとつ で、機械が見る世界は丸ごと変わる。 本章は、機械が言葉を扱う旅の最初の一歩 ──「単位に切る」という地味で、しかし全工程の運命を握る関門の話だ。
1.1 そもそも、なぜ「切る」必要があるのか
機械は文字列を「文字の並び」としては読める。 だが、序章で確認したとおり、最終的には言葉を 数（ベクトル） として扱いたい。
ここで素朴な作戦を考えよう。
作戦A: 1 文字に 1 つずつ番号を振る ── たとえば「あ」は 1、「い」は 2、「う」は 3… 作戦B: 1 単語に 1 つずつ番号を振る ── 「猫」は 100、「犬」は 101、「東京」は 5000…
どちらにも長所と短所がある。 だが共通して必要なのは、文字列をある「単位」に切って、それぞれに番号（=後でベクトルを割り当てるための ID）を渡す という工程だ。
この 切る + 番号を振る 工程を、自然言語処理では トークン化（tokenization） と呼ぶ。 切った 1 単位を トークン（token） と呼ぶ。
トークン化は、機械が言葉を見る 最初のレンズ を決める。 このレンズの解像度が後の全工程の上限になる。 だからこそ、文字列を「どんな単位に切るか」は、思っているより重い設計判断だ。
1.2 「切る」のはこんなに難しい ── 「東京タワー」は1語か2語か
直感的には簡単に思える。「単語の境目で切ればいい」と。 ところが、実際にやろうとすると、すぐに困る。
英語の都合のいい事情
英語の文 I love Tokyo Tower. は、スペースで自然に切れる。
[I, love, Tokyo, Tower, .] のように 5 つに分けるのは機械的にできる。
これが英語圏の NLP が長らく 「単語＝スペース区切り」を前提 にできた理由だ。
日本語の困難
ところが日本語 東京タワーが好きだ には、スペースがない。
どこが境目か、自分で判定する必要がある。
しかも候補は複数ある：
| 切り方の候補 | 解釈 |
|---|---|
| 東京タワー / が / 好き / だ | 「東京タワー」を 1 語と見る |
| 東京 / タワー / が / 好き / だ | 2 語に分ける |
| 東 / 京 / タワー / が / 好き / だ | 「東京」も 2 文字に分ける |
| 東 / 京 / タ / ワ / ー / が / 好 / き / だ | 全部 1 文字に |
どれが正解か は、目的によって変わる。検索なら「東京タワー」をひとかたまりに残したいし、文字レベルの誤字訂正なら 1 文字ずつ見たい。 唯一の正しい切り方は存在しない。
言語ごとの事情の違い
| 言語 | 単語の境目 | 厄介な点 |
|---|---|---|
| 英語 | スペース | 縮約形 (don't, it's)、複合語 (New York) |
| 日本語 | 存在しない | 単語境界も品詞も全部推定が必要 |
| 中国語 | 存在しない | 一般に日本語より単語数が多く境界推定が難しい |
| ドイツ語 | スペース | 単語を繋げて長大語を作る (Donaudampfschifffahrtsgesellschaft) |
| アラビア語 | スペース | 接辞が単語に張り付く (و+ال+كتاب = and+the+book) |
英語のような「スペース区切り言語」は世界の言語の一部に過ぎない。 「単語の境目」というものが言語によってあったりなかったり する事実は、トークン化を一筋縄でいかない問題にしている。
1.3 古典的な解 ── 単語分割と形態素解析
スペースのない日本語をどう切るか。日本では 1990 年代から長く取り組まれてきた問題で、いま広く使われているのが 形態素解析（morphological analysis） だ。
形態素解析は、文を 意味のある最小単位（形態素） に切ったうえで、品詞・原形・読みなどを付与する。
東京タワーが好きだ
↓
| トークン | 品詞 | 原形 |
|---|---|---|
| 東京タワー | 名詞 | 東京タワー |
| が | 助詞 | が |
| 好き | 形容動詞 | 好き |
| だ | 助動詞 | だ |
代表的なツール：
- MeCab （2003年、京都大学発）── 標準的な形態素解析エンジン
- Juman++、Sudachi ── 後発の改良版
これらは内部で「辞書 + 統計モデル」を使って、もっとも自然な分割と品詞付与を推定する。
補足形態素解析は日本語 NLP の縁の下の主役で、現在も検索エンジン、機械翻訳、企業の社内システムなどで広く現役だ。本書は LLM 時代の言葉の扱いに焦点を当てるため深入りしないが、日本語特有の重要なテクノロジーであることは押さえておきたい。
1.4 でも、それでは LLM 時代に困った
形態素解析は強力だが、現代の LLM が要求するスケール に来ると、3 つの大きな壁にぶつかる。
壁①: 未知語（Out-Of-Vocabulary）問題
辞書ベースで切ると、辞書にない単語が来た瞬間にお手上げ になる。
- 新語：「インプレ稼ぎ」「生成 AI」「Claude」
- 専門用語：「コクリエーション」「ベイズ最適化」
- 固有名詞：「Lechu」「xAI」「DALL-E」
辞書に登録されていない単語は、丸ごと「不明トークン（UNK）」になる ── つまり機械にとっては「何か知らない単語」という雑な情報しか残らない。
壁②: 語彙爆発
仮に「世界中の単語を辞書に詰め込む」ことを目指すと、語彙が 数百万単位 に膨らむ。 日本語は活用や複合語、英語は派生語、専門用語の山。後の章で扱うベクトル化のコストが爆発する。
壁③: 多言語の壁
ChatGPT は 日本語も英語もスペイン語もコードも数式も 同時に扱う。 言語ごとに別々の形態素解析を組み合わせる構成は、設計として持たない。 全言語に共通の単位 が要る。
古典的な形態素解析は「言語学的に正しい切り方」を追求する。 だが LLM 時代に必要なのは「全言語・全領域・全未知語に対応できる、頑健で機械的な切り方」だった。 両者は問題の立て方そのものが違う。
1.5 LLM 時代の解 ── サブワード分割
そこで現代の LLM が採用するのが サブワード分割（subword tokenization） という発想だ。
核となるアイデアはひとつ：
頻出する文字列は 1 トークンに、まれな文字列は文字単位に近く分割する。 単語より細かい単位（=サブワード）で、辞書サイズと未知語耐性をバランスさせる。
たとえば、こんな切り方になる：
| 文 | サブワード分割の例 |
|---|---|
tokenization | token + ization（頻出語幹 + 接尾辞） |
unbelievable | un + believ + able |
東京タワー | 東京 + タワー（または 東京タワー 1 つ） |
Donaudampf... | Donau + dampf + schiff + … |
Claude （新語） | Cla + ude または C + lau + de |
すごいのは、これを 言語ごとのルールなしで、データから自動学習 するところだ。 人間が「これは語幹」「これは接尾辞」と教えなくていい。
代表的なアルゴリズム ── BPE
代表選手は BPE（Byte-Pair Encoding） という手法だ。元はデータ圧縮のアルゴリズムで、NLP に転用された。 アイデアはあっけないほど単純：
BPE のレシピ
- 最初は全部 1 文字ずつ。語彙は「ひらがな、カタカナ、漢字、アルファベット、記号…」だけ
- 大量のテキストを眺めて、もっとも頻繁に隣接する 2 つの記号のペア を見つける
- そのペアを 1 つの新しい記号 として語彙に追加
- ステップ 2〜3 を、語彙が目標サイズ（たとえば 5 万）になるまで繰り返す
この手順だけで、頻出する token, ization, 東京 などが自動的に「1 トークン」に育つ。
逆に新語や珍しい名前は、自然に細かい単位のまま残る。
一族の仲間たち
BPE には親戚がいて、現代のモデルはこれらのどれかを使う：
| 手法 | 採用する主なモデル |
|---|---|
| BPE | GPT-2、GPT-3、GPT-4、Llama |
| WordPiece | BERT、DistilBERT |
| SentencePiece | T5、ALBERT、多くの多言語モデル |
| Byte-level BPE | GPT-2 以降の OpenAI 系（バイト列ベースなので絵文字も扱える） |
細部は違うが、「頻度ベースで自動学習する」「サブワード単位に落とす」 という大方針は共通だ。
1.6 トークンは現代 LLM の「単位通貨」
トークン化は単なる前処理ではない。現代 LLM のあらゆる量 が、トークンを単位として計算される。
課金単位はトークン
ChatGPT、Claude、Gemini ── これらの API 利用料金は、ほぼ全て 「入力トークン数 × 単価 + 出力トークン数 × 単価」 で決まる。
- 「100 万トークンあたり 3 ドル」のような価格表記がスタンダード
- 文字数や単語数ではなく、トークンで数える
なので、エンジニアが「このプロンプトは何トークン？」と気にする場面が頻繁に出てくる。
コンテキスト長もトークン
「Claude は 100 万トークンのコンテキストに対応」のようなニュース表現も、全部トークン基準だ。
- GPT-4: 一般版で 12.8 万トークン前後
- Claude Opus / Sonnet: 100 万トークン
- Gemini: 100 万〜200 万トークン
これは「LLM が一度に頭に入れて読める長さ」を意味する。 日本語の場合、おおむね 1 トークン ≒ 0.5〜1 文字 くらいの感覚で、英語の場合は 1 トークン ≒ 0.75 単語 くらい。
実務メモ日本語は英語より「文字あたりのトークン数」が多くなる傾向がある。同じ意味の文章でも、日本語のほうがトークンを食い、結果として 同じプロンプトでも日本語のほうが API 料金が高くつく ことがある。
最近のモデル（GPT-4o 系、Claude 系）は日本語トークナイザを改善し、この差は縮まったが、ゼロにはなっていない。
「単語数」ではなく「トークン数」で考える理由
人間にとっては「文字数」「単語数」のほうが直感的だが、LLM 業界ではトークン数が標準単位だ。理由は：
- 計算量がトークン数に比例（後の章で出る Transformer の処理は、トークン数の 2 乗に近いコストがかかる）
- モデルの記憶長もトークン基準（コンテキスト長はトークンで規定）
- 課金もトークン基準
つまり、LLM の性能・コスト・制約は、ほぼ全部「トークン」という単位の上に乗っている。 だから本書でも、これ以降の章で「単語」と言わずに「トークン」と言うことが多くなる。
1.7 トークン化を実感する
頭で理解するより、自分で見たほうが早い。
OpenAI が公開している Tokenizer ビジュアライザ （platform.openai.com/tokenizer）に、好きな文章を貼ってみよう。
たとえば次の文を入れてみる：
自然言語処理は楽しい。Natural language processing is fun. 😊
すると、文がトークンごとに色分けされて表示される。
- 英語の
Naturallanguageprocessingは 1 単語 = 1 トークン で切れる - 日本語の
自然言語処理は 何個か（2〜4 個）に分割 される - 絵文字 😊 は 複数バイトのトークン に分解される
これを眺めるだけで、「現代 LLM が見ている言葉の単位」が直感的にわかる。
1.8 この章の振り返り
- 機械に言葉を扱わせる最初の関門は「文字列をどんな単位に切るか」
- スペースのない日本語・中国語、絵文字・新語・多言語が混じる現代 LLM では、唯一正しい切り方は存在しない
- 古典的解は 形態素解析（MeCab など）── 言語学的に正しい単位に切る
- 現代 LLM の解は サブワード分割（BPE 系）── 頻度ベースで自動学習、未知語・多言語に強い
- トークン化は単なる前処理ではなく、LLM の課金・コンテキスト長・計算量の単位 そのもの
- これ以降、本書では「単語」より「トークン」という呼び方を多用する
切り終わった後、各トークンは ベクトル（数の並び） に変換される。 ここから機械は、言葉を初めて 計算できるもの として扱える。
次章では、その「トークンにベクトルを与える」工程 ── 埋め込み（embedding）の話に進む。 「王 − 男 + 女 ≈ 女王」という、機械が言葉の意味の構造を捉えはじめる瞬間だ。