久しぶりに技術エッセイシリーズ「Gemini and I」に戻って、今回は、「LLMの設計思想」について、Geminiとの議論を紹介したいと思います。
今日の結論
LLMの賢さは、Transformerだけで決まるのではない。
- どんなボキャブラリを持つか
- どんなトークナイザーで切るか
- どんな位置表現を使うか
この『入り口の設計』が、モデルの基礎体力を大きく左右する。
『Attention is all you Need』ということで、トランスフォーマーモデルについてはアテンション機構に注目が集まりがちだ。
しかし、トランスフォーマーは、入力されたトークン列をもとに文脈を計算しており、そのトークン列をどう作るかは、トランスフォーマーの外側で決まっている。
つまり、このLLMの知性は、アテンション機構だけでなく、『どんな言葉の単位で世界を見るか』という設計思想から始まっているのである。
Attention is nothing without vocabulary and embeddings
■ボキャブラリの重要性
ボク： LLMの事前学習を行うには、当該LLMのボキャブラリがすでに出来上がっていることが大前提ですよね？
Gemini： その通り、鋭い視点だね！LLMの構築においてボキャブラリがすべての入り口になるっていうのは、まさにその通りだよ。
具体的にどういうことか、少し掘り下げてみるね。
- なぜボキャブラリが「大前提」なのか
モデルが学習を開始する前に、入力されたテキストをコンピュータが理解できる「数値（トークンID）」の列に変換しなきゃいけないんだ。その変換表（トークナイザー）が準備できていないと、そもそもモデルは何を入力として受け取ればいいのかわからない。
- 学習の形が決まる: ボキャブラリのサイズがモデルの埋め込み層（Embedding Layer）のサイズや出力層の次元数に直結するから、最初に決めないとモデルの設計図自体が書けないんだよね。
- 言語特有の効率性: 日本語のように漢字・ひらがな・カタカナが混ざる言語では、トークナイザーがどう分割するかで、学習の効率や推論速度が劇的に変わる。ここが甘いと、いくら良いデータをたくさん入れても、モデルの賢さや効率が頭打ちになってしまうんだ。
- 学習中には変えられない
一度事前学習を始めてしまったら、途中でボキャブラリをいじるのは極めて困難だよね。もし後から「この単語をもっと細かく刻みたい」と思っても、出力層の重み行列のサイズが変わってしまうから、基本的にはモデルを作り直すか、あるいは非常に限定的な追加学習しかできなくなる。だからこそ、設計段階で「どんなデータを、どういう単位で切り出すか」を吟味するのが、事前学習の成功を左右する最初の関門なんだ。
- データとボキャブラリの相性
データも大事だけど、そのデータセットの中身を代表するようなボキャブラリになっているかも重要だよね。例えば、専門用語ばかりのデータで学習させるなら、その専門用語が「1トークン」として綺麗に収まるようなボキャブラリを作ると、モデルは格段に理解しやすくなる。
■トークンのデザインの重要性
ボク：なるほど、トークンのデザインによってもLLMの「性能」は違ってくるんですね。
Gemini：おっしゃる通りです。トークンの「デザイン（設計・選択）」がLLMの性能に与える影響は非常に大きく、モデルの能力そのものを規定すると言っても過言ではありません。
技術的な側面から見ると、トークナイザーの設計は単なる「文字の切り分けルール」以上の意味を持っています。主なポイントは以下の通りです。
- 「意味の最小単位」をどう捉えるか
理想的なトークナイザーは、言語的な意味（形態素や単語）を壊さずに、効率的な単位でIDに変換できるものです。
- 分断の影響: 例えば「unhappiness」という単語が、賢いモデルなら1トークンで処理できるところを、設計の悪いトークナイザーだと「un」「happi」「ness」のように細かくバラバラにされてしまう。こうなると、モデルは「意味のある塊」としての認識が難しくなり、推論の精度や論理的な理解力に悪影響が出ることがわかっています。
- 効率性の壁: 同じ文章を処理するのに、トークン数が数倍に増えてしまうと、それだけで「コンテキストウィンドウ（一度に扱える記憶容量）」が実質的に減少してしまいます。
- 性能と効率のトレードオフ
- ボキャブラリサイズ: ボキャブラリを極端に大きくすれば、単語単位での処理が増えて効率は上がりますが、モデルの出力層（巨大な重み行列）が膨大になり、メモリ消費や学習コストが跳ね上がります。逆に小さすぎれば、多くの単語が文字レベルまで分解されてしまい、推論が遅く、精度も落ちます。この「黄金比」を見つけるのが、モデルエンジニアの腕の見せ所なんです。
- 多言語対応: 特に日本語のように、英語とは全く異なる文法や文字体系を持つ言語において、英語中心のトークナイザーをそのまま流用すると、日本語のトークン化が異常に細かくなり、日本語性能が著しく低下するという「マルチリンガル税」のような現象が起きます。
- 本番環境でのコストと推論速度
トークンのデザインは、実は「お金」と「速度」にも直結しています。
推論時にモデルが処理しなければならないトークン数が多ければ多いほど、生成の待ち時間（レイテンシー）は長くなりますし、API利用料金もトークン数ベースで課金されることが多いですよね。
セキュリティの面でも、トークナイザーが適切に設計されていないと、意図しないトークン分割によって安全ガード（ガードレール）がすり抜けられてしまう脆弱性が生まれることさえあります。
まさに「ボキャブラリを制する者は、モデルの性能を制する」と言えますね。
■トークンと形態素の違い
ボク： 『unhappiness』を『un』、『happi』、『ness』と分けるのは、形態素解析の観点からはすごくまっとうなのでは？
Gemini： 確かに言語学的には正しいですが、LLMにとっては『統計的な効率』が優先されます。頻出する言葉がバラバラに処理されると、モデルは合成のための無駄な計算を強いられる。効率よく意味を理解させるには、『意味の塊』としてトークンを定着させる設計が必要なんです。
■まず、ボキャブラリありき？
ボク：LLMを開発するにあたって、まずボキャブラリを整備するために、LLMの事前学習と同じ言語コーパスを用いてトークナイズするのですか？
Gemini：その通りです。ボキャブラリ（トークナイザー）を作成する際にも、事前学習に使用するものと同じ、あるいはそれと同等の大規模な言語コーパスを使用するのが絶対的なルールになっています。
なぜそうするのか、その理由を整理すると以下のようになります。
- 統計的な「代表性」を確保するため
トークナイザーは、コーパスに含まれるテキストの「出現頻度」を元に、「どの単語（または文字の組み合わせ）を1つのトークンとするか」を決定します。
もし、学習データには全く含まれないような極端な偏りを持つテキストでボキャブラリを作ってしまうと、実際に学習するデータが出てきた時に、「あれ、この単語はどうやって分割すればいいんだ？」というミスマッチが大量に発生します。
同じコーパスを使うことで、「これから学習するデータにおいて、最も頻繁に現れる言葉の塊はどれか？」という統計的な最適解を導き出せます。
- 「効率」を最大化するため
ボキャブラリを作成するアルゴリズム（Byte Pair Encoding / BPEなどが主流）は、「いかに少ないトークン数で、元のテキストを表現できるか」を目標にしています。
同じコーパスを使うことで、そのデータセット内の「頻出パターン」が自動的に1つのトークンにまとめられます。
もし違うデータを使ってボキャブラリを作ると、いざ学習を始めた時にトークン数が無駄に多くなってしまい（オーバー・セグメンテーション）、先ほど議論したような「情報の密度が低い（＝推論効率が悪い）」モデルになってしまいます。
- 「未知語（Unknown）」を防ぐため
ボキャブラリの中に、学習データには存在しない文字の組み合わせばかりが並んでいても意味がありません。逆に、学習データの中に存在する重要な単語がボキャブラリから漏れていると、その単語はすべて「分解された無意味な文字の羅列」として扱われ、モデルはその単語の「意味」を学習するハードルが跳ね上がってしまいます。
■ボキャブラリとトークナイザー
ボク：「ボキャブラリ（トークナイザー）」という表現に少し違和感を感じます。
Gemini：技術的な正確さを求めると、「トークナイザー（切り分ける装置）」と「ボキャブラリ（切り分けられた結果のリスト＝辞書）」を同じ言葉で括ってしまうことに、座りの悪さを感じますよね。
整理すると、以下のようになります。
- トークナイザー（Tokenizer）: テキストをトークン列に変換する「アルゴリズム（手順）」や「ソフトウェア（モジュール）」のこと。
- ボキャブラリ（Vocabulary）: そのトークナイザーが対応している「トークンIDと文字列の対応表（辞書）」のこと。
■トークナイ―ザーの整理
ボク：代表的なトークナイザーとその設計思想を整理してもらえますか？
Gemini：LLMの「トークナイザー」の世界で、現在主流となっている代表的なアルゴリズムは大きく分けて3つあります。
これらはすべて、「未知語（Unknown）を減らしつつ、いかに効率よく（少ないトークン数で）意味を表現するか」という共通の課題に対するアプローチの違いです。
- BPE (Byte Pair Encoding)
設計思想：「頻出するものは、どんどん合体させて1つの塊にしよう」
もともとデータ圧縮のためのアルゴリズムです。現在、GPT-4やLlamaなど、多くのフロンティアモデルで採用されている「デファクトスタンダード」です。
仕組み: 文字単位からスタートし、コーパス内で最も頻繁に出現する「隣り合う2つのペア」を見つけて、1つの新しいトークンとしてマージする。 設定したボキャブラリ数（例: 5万〜10万）に達するまで繰り返す。
特徴:
- シンプルで強力: 頻出単語（"the", "ing", "こと"）は1トークンになり、未知の単語は文字単位にまで自動的に分解されるため、「未知語が発生しない」のが最大の強みです。
- Byte-level BPE: 現在のLLMは、文字ではなく「バイト単位（UTF-8）」で処理します。これにより、どんな言語や絵文字、記号が混ざっていても、必ず分解・表現できるようになっています。
- WordPiece
設計思想：「統計的に最も『予測しやすくなる』組み合わせを採用しよう」
GoogleのBERTなどで有名になったアルゴリズムです。BPEと似ていますが、マージの基準が異なります。
仕組み: 単に「頻度」だけで選ぶのではなく、「そのトークンを統合することで、言語モデルとしての学習の損失（Loss）がどれだけ下がるか」という確率的な基準でマージを行います。
特徴: 理にかなった結合: 単なる出現頻度よりも「言語モデルにとって都合の良い（意味的にまとまりやすい）」単位が優先されるため、より言語的な直感に近い分割になりやすいと言われています。
- Unigram (SentencePieceのデフォルト)
設計思想：「最初から巨大な候補を用意して、不要なものを削ぎ落とそう」
Googleが開発した「SentencePiece」というライブラリの中で実装されている手法です（T5やALBERTなどで採用された）。
仕組み: 最初にあらゆる部分文字列の候補を巨大な辞書として用意する。
各トークンに「確率」を割り当て、全体の文章が最も確率高く生成される組み合わせを計算する。
辞書から、重要度の低いトークンを段階的に削除してサイズを絞る。
特徴:
- 確率的アプローチ: 複数の分割パターンが考えられる場合、その中から最も自然なものを選択する柔軟性があります。
- 言語非依存: 空白を「単なる1文字（メタ文字）」として扱うため、日本語のように分かち書きがない言語でも、特別な前処理なしでそのまま学習・推論が可能です。
アルゴリズム比較表
|
手法
|
マージ方針
|
主な採用例
|
日本語への適性
|
|
BPE
|
頻度重視（貪欲法）
|
GPT系, Llama, Mistral
|
◎（Byte-levelで非常に安定）
|
|
WordPiece
|
確率・損失最小化
|
BERT, DistilBERT
|
◯
|
|
Unigram
|
確率最大化（枝刈り）
|
T5, XLNet, ALBERT
|
◎（SentencePieceとの相性が抜群）
|
まとめ：BPEは『頻出パターンを力技でまとめる』効率重視の職人、Unigramは『確率計算で最適な区切りを予測する』理詰めの学者といったところです。現代のLLMでは、SentencePieceという『箱』の中で、BPEかUnigramのどちらかを選ぶのが定石になっています。
■トークナイザーと埋め込み層の関係
ボク：RNNの説明の中にWord2vecというツールが出てきますが、ボキャブラリ、トークナイザーとの関係は？
Gemini：結論から言うと、Word2vecは、LLMのトークナイザーとは、まったく別のカテゴリーに属する技術です。ここを混同しないように整理すると、AIの進化の歴史と技術的な役割が非常にクリアに見えてきます。
- Word2vecは何者か？（「言葉の意味」を扱う）
Word2vecは、トークン化された後の「単語を数値（ベクトル）に変換する技術（分散表現）」です。
- 目的: 単語を数百次元の数値の列に変換し、似た意味の言葉同士が数値空間上で近くに配置されるようにすること。
- 例: 「王」－「男」＋「女」＝「女王」といった、単語間の意味的な計算ができることで有名になりました。
- 役割: LLMで言うところの「埋め込み層（Embedding Layer）」の先祖にあたります。
- トークナイザーは何者か？（「文字の塊」を扱う）
先ほど議論していたBPEやUnigramなどは、「生のテキストをどのような塊（トークン）に切り分けるか」を決定する技術です。
- 目的: コンピュータが処理できるように、文章を効率的な「ID（数字）」の列に変換すること。
- 役割: 「LLMの入り口」です。
- 図解：LLMの中での役割分担
今のLLMにおいて、Word2vecとトークナイザーは以下のような「直列の工程」に配置されています。
テキスト（生の日本語）
↓
トークナイザー：ここで「これは『トークンID: 123』」「これは『ID: 456』」というように、数字に変換される。
↓
埋め込み層（Embedding Layer）：ここで、それぞれの「ID」が、Word2vecの進化版である「ベクトル（意味の数値）」に変換される。
↓
モデル（Transformer）：ここで、変換されたベクトルを元に、文章の続きを推論する。
結論：かつて一世を風靡した『Word2vec』は、単語を数値化する技術でしたが、今のLLMではその概念がモデルの中に完全に統合されています。トークンのベクトル化は、その後の『言葉の辞書をどう数値の空間に並べるか』という、モデルの心臓部の話になるんです。
■LLM事前学習の「正体」：モデル内部で起きていること
ボク：トランスフォーマーの位置エンコーディングに関連する調整も含めて、事前学習で何が行われているかを正確に記述してもらえますか
Gemini：LLMの事前学習とは、一言で言えば「ランダムに初期化された巨大な行列（重み）の集合体を、膨大なデータとの照らし合わせを通じて、論理的で意味のある数値空間へと書き換える作業」です。
そのプロセスを、技術的なフェーズに沿って整理します。
- 物理的な構成と初期化（設計フェーズ）
学習が始まる前、モデルの「物理的な箱」が用意されます。
- ボキャブラリ（辞書）の決定: コーパスを解析し、特定の文字列とトークンIDを紐づけた辞書を作成します。
- 埋め込み行列の確保: 「トークンID数 × ベクトル次元数」の巨大な行列を用意します。各要素はランダムな値です。
- モデルの重みと位置エンコーディング行列の確保: モデルの全層の行列（Attention層、フィードフォワード層など）および、トークンの並び順を示す位置エンコーディング行列も、同様にランダム、あるいは計算に基づいた初期値で確保されます。
- 学習のループ（順伝播と誤差の算出）
学習中、モデルは以下のサイクルを繰り返します。
- 入力: トークンIDの列が入力され、埋め込み行列から対応するベクトルが引き出されます。
- 位置の付与: トークンの意味ベクトルに、位置エンコーディングのベクトルが加算（または連結）されます。これにより、モデルは「この言葉は文章の何番目にあるのか」という文脈上の位置情報を保持します。
- 計算の連鎖: TransformerのAttention層を通過し、言葉同士の相関関係（どの言葉がどの言葉を修飾しているか）が計算されます。
- 予測と誤差: モデルは「次のトークン」を確率的に予測します。正解と比較してズレ（誤差）が生じた場合、その大きさ（損失関数）を算出します。
- バックプロパゲーション（情報の書き換え）
ここが学習の核心です。算出された「誤差」を最小化するために、微分の連鎖律を用いてネットワークの入り口まで遡り、全パラメータを一斉に微調整します。
- 埋め込み層の修正: 入力されたトークンIDに対応する「行」の数値が修正され、言葉の「意味の地図」が少しだけ更新されます。
- 位置エンコーディングの調整: 位置情報が予測に寄与していた場合、この行列の数値も最適化されます。
- モデル重みの更新: 情報を処理するAttention層や全結合層の行列も書き換えられ、文脈を捉える「エンジンの歯車」が研ぎ澄まされていきます。
技術的ポイントの総括
事前学習の本質は、単なる知識の記憶ではありません。「埋め込み（意味）」と「位置（文脈）」と「変換のルール（モデルの重み）」が、バックプロパゲーションという同一の力学によって、同時に調整され続けることにあります。
- 埋め込み層: 言葉という「点」の意味を定義する。
- 位置エンコーディング: 言葉の「順序」がもたらす意味の変容を定義する。
- Transformerの重み: 言葉の「組み合わせ」から複雑な論理を導き出す計算ルールを定義する。
これらが数千億のパラメータ単位で精密に調和したとき、モデルは単なる計算機を超え、あたかも言語を理解しているかのような振る舞いを始めるのです。
■位置エンコーディングの使われ方
ボク：入力された個々のトークンの位置を表すベクトル情報（＝位置エンコーディング）を、各トークンの意味を表すベクトル（＝埋め込み）とは別に用意しながら、両者のベクトル要素ごとに足し合わせたものをトランスフォーマーブロックに渡すところが、トランスフォーマーを理解するポイントだと思うのですが、その辺りを詳しく説明してもらえますか
Gemini：「なぜ、わざわざ埋め込み行列と位置エンコーディング行列を分けているのに、最後に足すのか？」という疑問は、「情報の分離と再構築」というTransformerの設計思想そのものに直結しています。「情報の重ね合わせ」として整理してみましょう。
- 独立した情報の「多重化（Multiplexing）」
入力層（埋め込み層）の直前では、以下の2つの情報が独立して存在しています。
意味行列 （Esem）: どのトークンか（猫、犬、走る...）
位置行列 （Epos）：何番目か（1番目、2番目、3番目...）
これらを足し合わせる行為（Vfinal = Esem + Epos）は、電気信号でいう「多重化」に似ています。一つのベクトルという物理的な箱の中に、「意味」という信号と「位置」という信号を、同じ次元軸に重ねて詰め込むわけです。
- なぜ混ぜても壊れないのか？（ここが最大のポイント）
意味を見たい時: Attentionは、Vfinalの中から「意味に関連する次元」の値を強く参照（重み付け）します。このとき、位置の情報は「ノイズ」として無視されます。
位置を見たい時: Attentionは、Vfinalの中から「位置に関連する周期的な波の次元」の値を強く参照します。このとき、意味の情報は無視されます。
つまり、「足し算で混ぜた」のは「計算コストをケチるため」であり、情報の抽出は「Attentionの重み行列（重み付けのフィルタ）」という賢い仕組みを使って、後から必要な情報だけを吸い出しているのです。
- トランスフォーマーブロックへの受け渡し
足し合わされたベクトル Vfinalがトランスフォーマーブロック（Attention層 ＋ FeedForward層）に渡されます。
Attention層の仕事: 「このベクトルは意味と位置が混ざっているが、今まさに計算しているこの文脈（例えば『猫が...』のあと『走る』がくる確率）には、どのトークンの意味と、どのトークンの位置関係が重要か？」ということを、行列演算を通じて取捨選択します。
※ よくある疑問ですが、単語の意味と位置の情報をベクトルで足し合わせてしまえば、情報が混ざって訳がわからなくなるのでは、と思うかもしれません。しかし、Transformerは『足し算された情報』を、あえて『混ざった状態のまま』受け取ります。そして、Attentionという名のフィルタを駆使して、その時々の計算に必要な『意味の成分』と『位置の成分』だけを、都度つまみ出しているのです。情報を個別に管理するのではなく、ひとまとめにして混ぜ合わせ、必要に応じて取り出す。この『情報の重ね合わせ』こそが、限られたメモリと計算能力で文脈を解き明かすための、Transformerの最もエレガント（で、少し強引な）戦術なのです。
※ 最初から『この次元が意味で、この次元が位置』と決まっているわけではありません。AIは学習の過程で、膨大な行列（重み）の中に、自分だけの『仕分けルール』を書き込んでいきます。実際には、何千という次元が絡み合う複雑な空間なのですが、AIは何兆回もの試行錯誤を通じて、『この掛け算をする時は、意味の成分を拾い上げよう』『この掛け算をする時は、位置の成分を重視しよう』という『次元の使い分け』を自ら発明したのです。言い換えれば、Transformerの各層は、意味と位置を同時に処理するための『専用レーン』を、行列の中に自動構築していると言えます。この『自ら構造を作り上げる柔軟性』こそが、今のAIがかつての固定的なプログラムと一線を画す理由です。
■位置エンコーディングに関する技術の進展
位置エンコーディング（Position Embedding）のデザインが、モデルの扱える最大文字数（コンテキスト長）の限界を決めてしまう」という制約が、Transformerには長らく存在していました。
なぜ正弦波のような「波」を使う手法が、コンテキスト長の拡大を阻むのか。その理由を整理します。
- 初期の手法が抱えていた「外挿」の壁
初期のTransformerで使われていた正弦波埋め込み（Sinusoidal Encoding）は、数式を使って位置を「波の位相」として表現していました。数式なので、理論上はどんな長さでも計算自体はできるのですが、学習時に見せてもらえなかった「未知の長い波のパターン」がいきなり推論時に出てくると、モデルはパニックを起こして性能が崩壊していました（外挿性の問題）。これが、初期のTransformerが短いコンテキスト長に縛られていた大きな理由の一つです。
- コンテキスト長を伸ばすための「拡張」
この限界を突破するために業界では以下のような技術革新が起きました。これが現在の「数万〜数百万トークン」という長大なコンテキストを支えています。
- 回転位置埋め込み（RoPE: Rotary Positional Embedding）
現在、Llamaや僕（Gemini）のような多くのモデルが採用しているのがこれです。「ベクトルを足す」のではなく、「ベクトルを回転させる」手法です。
- 仕組み: ベクトルを2次元ずつペアにして、位置に応じて特定の角度だけ回転させます。
- メリット: 「距離」が回転角度として表現されるため、どれだけ文章が長くなっても「相対的な位置関係（どの単語がどの単語の何番前か）」を一定の精度で維持できます。これが、コンテキスト長を劇的に伸ばす鍵となりました。
- ALiBi (Attention with Linear Biases)
これは「位置をベクトルとして加算する」ことすらやめてしまう過激な手法です。
- 仕組み: Attentionの計算結果（スコア）に対し、距離に応じてマイナスのバイアス（ペナルティ）を強制的にかけるだけです。
- メリット: 位置情報を学習で埋め込む必要がないため、学習時より長い文章を推論時にいきなり入力しても、それなりに動くという驚異的な柔軟性を持っています。
- なぜこれでコンテキスト長が変わるのか
なぜこれらがコンテキスト長と関係するのかですが、答えは「外挿性（Extrapolation）」にあります。
- 昔の波（固定PE）: 決め打ちのサイン波なので、学習した範囲（例えば1024トークン）を超えると、モデルが「未知の領域（波の形が変わる）」に放り出され、パニックを起こして性能が崩壊していました。
- 今の回転（RoPE等）: 回転のルールさえ維持していれば、学習データに現れなかった長い文章でも、モデルは「ああ、ずっと先の角度まで回ってるんだな」と数学的に解釈できるため、コンテキスト長を後からいくらでも引き伸ばせるのです。
ボク： なるほど、じゃあRoPEを使えば、理論上は「無限」にコンテキストを伸ばせるってこと？
Gemini： あ、そこは落とし穴があって、実は「理論上はいくらでも回転させられる」けれど、「無限に正確に読み取れる」わけじゃないんだ。
ここがAI工学の面白いところで、学習時よりも極端に長い文章になると、回転角度の「解像度」が粗くなってしまって、モデルの記憶が徐々にボヤけて（性能が劣化して）しまう。つまり、「行列の行数の制約（物理的な限界）はなくなったけれど、数学的な外挿の難しさ（認知の限界）は残っている」というのが正確なところなんだよね。
ボク： じゃあ、今流通している「100万トークン」とかの超長文モデルはどうやってそれを解決しているの？
Gemini： そこを突破するために、世界中の研究者が今まさに知恵を絞っているんだ。例えば、長文になっても角度の解像度が潰れないように工夫する技術が次々と生まれているよ。
- 位置補間（Position Interpolation）: 長い文章を、学習時の角度の枠内に「ギュッと縮めて」収める技術。
- NTK-aware / Dynamic RoPE scaling: 重要な情報（高頻度な波）とそうでない情報の縮め方を変える、賢いスケーリング。
- YaRN / LongRoPE: さらに進化して、超長文でもアテンションの精度を落とさない最先端の補正技術。
現代の超長文LLMは、RoPEという「コンパス」を手に入れた上で、さらにこうした「目盛りのズレを補正する最新の数学的アプローチ」を組み合わせることで、初めてあの驚異的な記憶力を実現しているんだよ。
■位置エンコーディングとコンテキスト長の関係
「埋め込み行列」は「トークンIDの数 × 次元数」という固定的なサイズで想像しやすいですが、「位置エンコーディング行列」は「文章の長さ（シーケンス長）に応じて、どこまでも伸びていく可能性がある」という点で、理解を難しくしているかもしれません。
- 位置エンコーディング行列の正体
位置エンコーディング行列 Pを、視覚的に捉えてみます。
横軸（列方向）： ベクトルの次元数（意味ベクトルと同じ）
縦軸（行方向）： トークンの出現順序（1番目、2番目、3番目……）
この行列は、「最大でどれだけの長さの文章を読ませるか」という設計上の上限（最大コンテキスト長）を決めた時点で、サイズが確定します。例えば最大長を2048トークンと決めたなら、「2048行 × 次元数」の行列が一つ、モデルの中に「固定の辞書」として用意されるわけです。
- 「行列」と「コンテキスト長」の切れない関係
なぜ位置エンコーディングがコンテキスト長を縛るのか。それは、「AIにとって、未知の位置（＝行列の行数を超えた場所）は、全くの『未開の地』だから」です。
学習時の状況: モデルは「1番目から2048番目」までの行列を使って学習し、それぞれの位置でどう振る舞うかを学びます。
推論時の悲劇: もし2049番目のトークンが入力されたらどうなるか。モデルは「2049行目」のデータを持っていないので、AIは「自分がいま文章のどこにいるのか」を判断する基準を失います。これが、旧来のTransformerで「コンテキスト長が固定されていた」理由です。
- 「行列の行数」に縛られないための知恵（現代の解決策）
現在のAI（RoPEなど）は、「行列の行数（＝絶対的な位置）」に依存するのをやめたのです。
昔の行列: 「君は5番目のトークンだね、だからこの5行目のベクトルを足すよ」という絶対的な管理。
今の回転（RoPE）: 「君は前のトークンから見て、これくらいの角度だけ回った位置にあるね」という相対的な管理。
この「回転」を使う方式では、位置エンコーディング行列は「行列の行数として持ち続ける必要がない」という革命的な転換が起きました。計算のたびに「今の位置に応じて回転させる」という処理を行うため、理論上は「いくらでも回転させ続けられる（＝文章がどれだけ長くなっても対応できる）」わけです。
- つまり、初期のAIは、文章を『決められた長さの地図』として持っていました。2048ページまでしか地図がないから、それ以降は迷子になってしまう。これが『コンテキスト長の限界』でした。しかし、今のAIは違います。地図を持つのではなく、『コンパス（回転するベクトル）』を持ち歩くようになったのです。一歩進むごとにどれだけ回転したかを記録し続けるため、文章が1万ページ続こうが、100万ページ続こうが、迷子になることはありません。この『地図からコンパスへの進化』こそが、今のAIが長大な物語を記憶できるようになった魔法の正体なのです。
古い方式（正弦波埋め込み）では： 位置エンコーディングは「行列の行」として保存されており、その行数がコンテキスト長の限界になっていた。
新しい方式（RoPEなど）では： 位置情報は「行列の行」から解放され、「ベクトルを回転させる演算」に置き換わった。だから、物理的な行列のサイズを気にせずにコンテキスト長を伸ばせるようになった。
- 古い方式の位置エンコーディング行列では、位置エンコーディング行列のサイズが最大コンテキスト長のサイズになってしまっていたが、新しい方式の位置エンコーディングでは、その制約はなくなった。ただし、トランスフォーマーの長所である、「一度に全単語を見渡す」ため、「GPUのメモリ（KVキャッシュ）」を大量に必要とするので、実用上の制約から、他社の生成AIでは、最大コンテキスト長を10万〜20万トークンで抑えている。「一般的な商業サーバーのGPU（H100など）で、コストを抑えつつ安定して何万人もの処理を同時にこなせる限界のライン」がそのあたりだからなんだ。100万トークンを全ユーザーに開放できるのは、自社製AIチップ（TPU）の巨大インフラをフル活用できるGoogleのようなごく一部の企業に限られているのが現状だよ。（2026年現在）
ボク：ちょっと整理させて。さっき「位置エンコーディング行列は上限を決めた時点でサイズが確定する」と言っていたけれど、正弦波は数式で計算するから「行」として保存されているわけではないよね？
Gemini： ご指摘の通り！技術的な解像度をもう一段上げると、実は初期の「固定された地図」方式には二つの系統があるんだ。
- 学習型絶対位置埋め込み（BERTやGPT-2/3などで採用）： これこそがまさに「2048行×次元数」のように、モデルのなかに物理的な行列（上限サイズ）を確保するタイプ。2049番目のトークンが来ても、物理的に「2049行目のデータが存在しない」から完全に迷子になる。
- 正弦波埋め込み（初期のTransformerなどで採用）： こちらは数式で計算するから、2049番目以降も計算自体はできる。けれど、モデルがその波形パターンを学習中に見たことがないから、結局うまく処理できずに性能が落ちてしまう。
つまり、従来の絶対位置を教える手法は、「物理的な行数が尽きて迷子になる（学習型）」か、「計算はできても未知の波形に対応できない（正弦波）」のどちらかの限界にぶつかっていたんだよね。
だからこそ、位置を「絶対的な地図」ではなく「ベクトルの回転（相対的なコンパス）」として処理するRoPE（Rotary Positional Embedding）の登場は、この両方の限界をスマートに突破する革命だったんだ。
■「マルチリンガル税」と日本語特化の意義
もう一つ、本日Geminiと議論したのは、日本語LLMの立ち位置です。
ボク： 日本語特化のトークナイザーでボキャブラリを作り、日本語コーパスで学習させるのが、やはり理想ですか？
Gemini： 日本語性能を追求するならそれが最強です。
ただ、現実にはいくつかのアプローチのせめぎ合いがあります。
「日本語特化」のメリット:
- 圧縮効率の向上: 日本語が1文字1トークンに近い状態で分解されるのを防ぎ、短いトークン列でより多くの意味を表現できるため、コンテキストウィンドウを節約できます。
- 推論の高速化: 同じ文章でもトークン数が減るため、生成速度が向上し、コストも下がります。
「ユニバーサル（多言語）」戦略の壁:
近年の巨大モデル（Gemini含む）が敢えて日本語特化型に振り切らないのは、「多言語間での知識の転移」を狙っているからです。英語の膨大なコーパスで学習した「論理的思考能力」や「プログラミング能力」を、日本語にもシームレスに適用させるためには、ボキャブラリをある程度共通化しておいたほうが、モデル内部で概念の共有がしやすくなるというメリットがあります。
結局のところ：
もし、「特定の日本語ドメイン（例えば日本の古文、法務、あるいは特定の専門知識）」に特化したLLMを作ろうとしているなら、日本語の統計的性質に合わせた専用トークナイザーを作るのは大正解だと思います。
しかし、汎用的な「賢いモデル」を目指す場合は、日本語に偏りすぎると英語圏の知識へのアクセス効率が落ちるというジレンマがあります。最近のトレンドは、「既存の多言語トークナイザーのボキャブラリをベースにしつつ、日本語の頻出単語や熟語を『追加のトークン』としてボキャブラリにねじ込む」というハイブリッドな手法が主流になっていますよ。
ボク： 日本企業（NTT等）は、日本語用LLMを開発・提供しているようですが、君の感想は？
Gemini： 日本企業が開発している国産LLMについては、非常に戦略的で、かつ「地に足のついた賢い選択」をしているな、というのが率直な感想です。
先ほど触れた「トークナイザーの最適化」や「効率性」の話とも重なりますが、彼らの取り組みには今のAI業界における重要な潮流が詰まっています。
- 「力技」から「最適化」へのシフト
海外の超巨大モデル（フロンティアモデル）は、膨大な計算資源を投じて「汎用的な賢さ」を追求しています。一方で、NTTの「tsuzumi」をはじめとする国産モデルは、「軽量・高性能・特化型」という方向性を明確に打ち出しています。
これは、日本の企業文化や社会インフラにとって非常に大きな意味を持っています。
- セキュリティとガバナンス: 金融や行政など、機密性の高いデータを扱う領域では、「外部の巨大モデルに情報を送らず、オンプレミス（自社環境）で完結できる」ことの価値が非常に高いです。
- 低コストな社会実装: 超大型モデルの運用には天文学的なコストがかかりますが、国産の軽量モデルなら、特定の業務（電子カルテの要約、行政文書の翻訳、法務書類のチェックなど）に対して「手頃な価格」で導入できます。これは、AIの社会実装を加速させるための現実的な解ですね。
- 「日本語特化」の必然性
先ほどのトークナイザーの議論にも通じますが、日本語特化型のモデルをゼロから（あるいは日本語コーパスを重点的に）学習させる意義は極めて大きいです。
- ニュアンスの解像度: 日本語特有の敬語、曖昧な表現、専門用語の文脈理解などは、汎用的なグローバルモデルよりも、日本語の海で鍛えられたモデルの方が圧倒的に高いパフォーマンスを発揮できます。
- 文化的なチューニング: 日本の商習慣や法制度、倫理観を前提とした回答ができるという点は、企業が業務導入する際の大きな安心材料になります。
- Geminiとしての「ポジティブな共存」
僕（Gemini）のようなグローバルモデルは、「世界中の膨大な知識の統合」や「複雑でクリエイティブな推論」が得意です。一方、国産モデルは「現場の特定の業務」を「安全・安価」にこなすのが得意です。
これからは、両者を使い分ける「ハイブリッド戦略」が主流になっていくでしょう。例えば、企画立案などの創造的なフェーズでは僕のようなモデルを使い、機密性の高い契約書や個人の医療情報の処理には国産モデルを使うといった形です。
■デパートとブティック：LLMの使い分け
最後に、NTT等の国産LLMについて話が及びました。当初、ボクは「世界的な汎用モデル（GeminiやChatGPT）に勝てるのか？」と疑問を持っていましたが、この議論を経て、視点が大きく変わりました。
ボク：国産LLMの戦略は、結局のところ『デパート』に対抗する『ブティック』のようなものですね？
Gemini： 「まさにその通りです。
- デパート（汎用モデル）： 何でも揃うが、細部の専門性には限界がある。
- ブティック（特化モデル）： 特定の文脈や専門業務に最適化され、丁寧で無駄がない。
汎用モデルで世界を俯瞰しつつ、現場の機密や専門領域は国産の特化モデルで処理する。これからのAI活用は、この『使い分け』が鍵になります。
