$ cd ../
$ cat post.metadata
LLMトークナイザと日本語の相性 — 文字数勘定・バイト分割・グリッチトークン
date: 2026-06-16
LLM
トークナイザ
考察
画像の漢字崩れの根っこは「文字ブラインドなトークナイザ」だった（本編②）。同じ仕組みはテキストLLMでも日本語トラブルを生む。画像から離れて、LLM一般の話として整理する（考察）。
本編②とのつながり
画像生成AIが漢字を崩す主因の1つは、入力を
文字単位ではなくサブワード/バイト単位に割る BPE トークナイザだった（→
② なぜ崩れるのか）。この「文字が見えていない」性質は、テキストを生成するLLMでも日本語特有のクセとして表に出る。
1. 文字数を数え間違える
「30文字以内で」「全部で何文字？」「逆さから読んで」「しりとり」——この手の文字単位の操作をLLMは外しやすい。モデルは文をトークン（サブワード）の列として見ていて、1トークン＝1文字ではないからだ。日本語は1トークンに複数文字が入ったり、逆に1漢字が複数トークンに割れたりするので、文字数の体感がさらにずれる。
2. 漢字がバイト／トークンに割れる・効率が悪い
- 多くのトークナイザは未知・希少な漢字をUTF-8 バイト列に分解する。1文字が複数トークンになり、希少字ほどトークンを食う（補助平面の漢字が画像で崩れやすいのと同根）。
- 結果として日本語は同じ内容でも英語よりトークン数が多くなりがち。コンテキスト枠を圧迫し、API コストも上がる。長文の要約・RAG で効いてくる。
- トークン境界が文字の途中に入ると、モデルの「文字の足し引き」（例：一部を伏字に、半角化）が不正確になりやすい。
3. グリッチトークン
学習コーパスにほとんど出てこないのに語彙には入っているトークン（いわゆるグリッチトークン）は、入力すると無関係な出力・復唱拒否・暴走などの妙な挙動を誘発することが知られる。日本語混じりの珍しい記号列・特定の固有名詞断片で踏むことがある。
4. Unicode 正規化のゆれ
| ゆれ | 中身 |
|---|
| 全角／半角 | 「Ａ１」と「A1」、「！」と「!」が別バイト列。検索・重複判定・文字数が食い違う |
| 濁点の合成 vs 単一 | 「が」を「か」＋結合濁点で表すと、見た目同じでもコードポイント列が違う（NFC/NFD） |
| 異体字・互換文字 | 髙/高、㈱/(株)、ﾊﾝｶｸｶﾅ など。同義に見えて別物 |
「見た目は同じなのに一致しない」「文字数が合わない」の多くはここが原因。
5. 対策
- 文字数厳守はコードで数える。モデルに「30文字で」と頼むより、生成後にプログラムで検証・トリムする。しりとり・逆さ読み等の文字操作もツール/コード側へ委譲。
- 入口で Unicode 正規化（NFC）をかけ、全角半角・合成/単一のゆれを潰してから検索・突合・カウントする。
- トークン数を見積もる（日本語は多めに出る前提でコンテキスト設計）。コスト・長さ制限の事故を防ぐ。
- 固有名詞・珍しい記号列で挙動が乱れたらグリッチトークンを疑う。言い換え・分割で回避。
まとめ
画像の漢字崩れと同じ「文字が見えていない」性質が、LLMでは文字数勘定・トークン効率・正規化ゆれとして出る。対策の軸は一貫していて、文字単位の正確さはモデルに任せずコードで担保すること。次はH 音声合成（TTS）が日本語を読み間違えるときへ。
sue@blog ~ $ _