単語を数字に変えるって、いったい何を言ってるの?

0. 読む前に

F1 から F4 までお疲れさまでした。いまごろは「Transformer が何で、attention が何をしているのか」は頭にある程度腰を落ち着けていると思います。ところがこのシリーズの中でずっと「ベクトル」という言葉が出てきていましたよね。単語をベクトルに変える、Q・K・V もベクトル、attention はベクトル同士を内積する、こういう感じで。

今回はその「ベクトル」という言葉の根っこを掘る回です。具体的には 単語や文章を数字の塊 (ベクトル) に変える技術 — つまり embedding です。LLM、RAG、意味検索、レコメンドシステム、全部この1層の上で動いています。この層を感覚的につかんでおくと、これから出てくる編たち (F6 学習編、F7 RAG 編、M1 retrieval layer 編など) がずっと楽になります。

この記事のゴールはひとつだけ。「王 – 男 + 女 = 女王」という奇妙な引き算が本当に動く という話、ありますよね。それが何を意味しているのか、どうしてそれが可能なのか、そしてそれが今私たちが使っているあらゆる AI ツールとどうつながっているのか — 最後までほどいてみます。

比喩は 地図 一枚を使います。単語がばらまかれた巨大な地図を思い浮かべてください。意味が近いものは近くにあって、関係ない単語は遠くにある地図。このイメージひとつを握ったまま進めば、埋め込みは最後まで読めます。

1. なぜコンピュータは「りんご」という単語をそのまま扱えないのか

出発点は少し素朴な問いです。コンピュータは「りんご」という単語を読めるのでしょうか。

文字そのものを表示することはできます。画面に「りんご」を打つのはただのピクセルパターンの問題ですから。ところが 「りんご」と「なし」が似た果物だということを、コンピュータが計算で見つけられるか はまったく別の話です。

なぜかというと、コンピュータの中で文字列はただの 記号の並び だからです。「り」という文字の次に「ん」「ご」という文字がくっついているだけ。この 3 文字の組み合わせに「赤くて丸くて食べられる」という意味はどこにも書かれていません。同じように「なし」もただの文字で、りんごとの関係なんてものはコンピュータ視点では分からないわけです。

なので初期の自然言語処理 (NLP) は、この問題を回り道で解きました。「りんご」と「なし」が一緒に出てくる文書の数を数えたり、辞書で2つの単語の定義が重なる割合を測ったり、人が直接類義語辞書を作ったりしました。手間が多い仕事でした。そして限界がはっきりしていました。辞書にない関係は拾えないんです。「りんご」と「iPhone」の関係みたいなものは普通の辞書には載っていませんから。

問題の核心はこれです。コンピュータは数字しかうまく扱えません。 足す、引く、掛ける、距離を測る。記号に対してはあまりできることがありません。そうすると問いがひっくり返ります。「単語を数字に変えられたら、その数字同士を演算して意味を扱えるんじゃない?」 この発想が embedding の出発点です。

ちなみに私も初めてこれを勉強したとき、「単語を数字に変える」という言い方がちょっと無理やりに聞こえました。単語は意味があるのに、数字に変えたらその意味がどこに行くのか、という感じで。答えを先に言ってしまうと、数字ひとつではなく 数字数百〜数千個の配列 (ベクトル) に変えます。そしてその配列の中に、意味のいろんな側面が分かれて入っている構造です。この話は後でゆっくりほどきます。

2. 最初の試み: one-hot encoding — 単語ごとに独立したスロット

単語を数字に変える一番シンプルな方法から見ていきます。one-hot encoding という名前で呼ばれる方法です。

アイデアは文字通りシンプルです。語彙辞書に単語が 10 万個あるとします。すると各単語に 10 万マスのベクトル を1つずつ用意します。「りんご」という単語のベクトルは 17 番目のマスだけ 1 で残りは全部 0。「なし」は 2,341 番目のマスだけ 1。「iPhone」は 78,562 番目のマスだけ 1。こんな感じです。

この方式の利点はハッキリしています。シンプル です。各単語が自分専用のスロットを1つずつ持っているので重なりません。そして計算機の視点からも扱いやすい。

ところが欠点はずっと大きく、そのうちのひとつが致命的です。すべての単語同士の距離が同じ なんです。

言葉遊びみたいですが真面目な話です。「りんご」のベクトルと「なし」のベクトルを比べると、1 が打たれた位置が違うだけで、共通の成分はひとつもありません。内積 (2 つのベクトルを掛けて足した値) を計算すると 0 になります。「りんご」と「iPhone」を比べても 0。「りんご」と「数学」を比べても 0。全部 0 です。

つまり one-hot encoding の世界では すべての単語が互いに無関係な独立した点 です。意味が近いのか遠いのか、関係があるのかないのか、同じ範疇に属するのか — 一切入っていません。コンピュータの視点では「りんご」と「なし」の関係が「りんご」と「微分積分」の関係とまったく同じです。

もう一つ問題があります。語彙が増えると次元が狂ったように大きくなります。10 万単語 = 10 万次元。大規模コーパスでは語彙が数百万を超えるのに、単語一つ表現するのに数百万次元を使うのは話になりません。99.99% が 0 の疎ベクトルなのでメモリももったいない。

なのでこの方式は、「単語を数字に変える」という宿題は解けたけど、「意味を入れる」という本来の目的はまったく解けなかった わけです。この限界を越えるにはまったく違う発想が必要でした。次のセクションで出てくる 空間の比喩 です。

3. 解決: ベクトル空間の上に「意味」を配置するという発想

発想を変えてみます。単語ごとに独立したスロットを与えるのではなく、ひとつの大きな空間の上にすべての単語を散らして置く んです。そしてその位置をうまく決めて、意味が似た単語同士は近くに、関係ない単語同士は遠くに 置かれるようにしよう、という発想です。

地図の比喩がここで出てきます。

世界地図を思い浮かべてみてください。ソウルと釜山は近いです。ソウルとニューヨークは遠い。都市の一つひとつが地図上の「点」で、2 点間の距離が「どれくらい近いか」を教えてくれます。これが地理的な地図なら、embedding が作るのは 意味の地図 です。

embedding の地図の上では、

• 「りんご」と「なし」と「バナナ」が一つの街に集まっています。果物の街です。
• 少し離れたところに「車」と「飛行機」と「電車」が集まっていて。乗り物の街です。
• もっと離れたところには「うれしい」「悲しい」のような感情の単語たちがまたそれぞれで集まっていて、
• 「りんご」と「よろこび」は果物の街と感情の街の間のどこかでゆるく関係しているかもしれません。

これで全部です。単語をベクトル (座標) に変えて、その座標を意味に合わせて配置しよう。 この発想ひとつで one-hot encoding の限界を一気に破りました。なぜならこれで単語同士が「どれくらい近いか」が自然に数字で出てくるからです。座標さえあれば距離を測れますよね。その距離が、そのまま「意味の類似度」になるんです。

ひとつだけ先に言っておきます。私たちが思い浮かべる地図は 2 次元 (紙の上の x, y 座標) ですが、実際の埋め込みが使う空間はずっと高次元です。数百〜数千〜万次元 とか。なぜそんなに多くの次元を使うのかは後で 8 番目のセクションで別にほどきます。とりあえず今は「高次元の地図の上に単語たちが点として散らばっている」という絵だけを頭に入れておいてください。

ところがここで自然な問いが出てきます。その座標はいったい誰が、どうやって決めるのか? 人が単語数十万個の座標をいちいち打つわけにはいかないでしょう。この問いへの答えが、Word2Vec です。

4. その「座標」をどうやって見つけるか — Word2Vec の直観

2013 年に Google の Tomas Mikolov チームが Word2Vec という方法を発表しました。この方法が embedding を大衆化させた分水嶺です。それ以前にもベクトル空間モデルの試みはありましたが、Word2Vec は 大規模テキストを与えると座標が自動で決まる ことを実用的な速度で見せたんです。

核心のアイデアは言語学から借りてきました。Distributional Hypothesis というもので、訳すと「分布仮説」です。John Rupert Firth という言語学者の有名な言葉で要約されます。

“You shall know a word by the company it keeps.”
(一つの単語は、その周りに来る単語たちを見れば分かる。)

この言葉を実務感覚でほどいてみます。次の 2 つの文を見てください。

• 「猫は魚が好き。」
• 「犬はおやつが好き。」

この 2 つの文で「猫」と「犬」は 似たような位置に登場 していますよね。どちらも動物で、どちらも何かが好きと書かれています。このような文脈の重なりを数千、数万、数億の文から積み上げると、結局 「猫」と「犬」はほぼ似た文脈で使われる という統計が出てきます。すると 2 つのベクトルを近くに配置するのが自然になります。一方で「猫」と「微分方程式」は一緒に出てくることがほとんどないでしょう。ベクトルも遠くに置かれます。

Word2Vec の具体的な訓練方法は2つあります。

• CBOW (Continuous Bag of Words): 周りの単語を見て真ん中の単語を当てる課題。「猫は___が好き」で空欄を予測する感じです。
• Skip-gram: 逆に、真ん中の単語を見て周りの単語を当てる課題。「魚」を与えると周りに「猫」「好き」が来る確率が高い、という具合に。

2 つの方式とも 「文脈を予測する課題を解かせる」構造 です。その予測をうまくやるには、モデルが各単語のベクトルをうまく配置しないといけないですよね。なので課題そのものは単語当てなのに、副産物として意味がよく配置されたベクトル空間が飛び出してくる わけです。賢い設計です。

ここで感覚が来てほしいことがあります。Word2Vec は「猫と犬は似ている」と人間が教えたことがないんです。 ただものすごい量の自然言語データを与えて、空欄当てをさせただけ。ところがその課題を解いていくうちに、モデルが自ら「猫」と「犬」のベクトルを近くに置くようになった。意味の構造が 統計から自然と浮かび上がった んです。

この自己教師あり学習 (self-supervised learning) の力が、その後 BERT、GPT へとつながるすべての LLM の基本動力です。ラベル付けなしで、ただ「次の単語を当てる」ような課題さえ与えれば、モデルが言語の構造を自分で学んでいく。出発点がまさに Word2Vec だったわけです。

5. 有名なベクトル数学 — 「王 – 男 + 女 = 女王」

さあここがこのシリーズのハイライトです。Word2Vec が 2013 年に注目された決定的なエピソードがあります。ベクトル空間の上で本当に意味の算数が動く という話でした。

日本語に直すとこうなります。ベクトルを v(単語) と書きます。

v(王) - v(男) + v(女) ≈ v(女王)

ほどいて読むと 「王というベクトルから男らしさという成分を引いて、女らしさを足したら、女王のベクトルが出てきた」 という話です。これが本当に実験的に確かめられました。だいたいそれっぽく合うというレベルではなく、かなり綺麗に合います。

初めてこの結果を見たとき、私は何か騙されているような気分でした。「まさかこれが成り立つの?」という感じで。数学的な引き算ひとつで意味の関係が飛び出してくるというのは劇的すぎますからね。ところが原理を追いかけてみると、なぜそうなるのかが自然に腑に落ちます。

ポイントはこれです。Word2Vec が単語をベクトルに配置するとき、意味の複数の軸を、別々の方向に分けて保存します。

感覚的にほどいてみます。高次元空間の中で、ある 方向 は「性別の軸」に該当します。その方向に少し移動すると「男性性 → 女性性」のほうに移ります。また別の 方向 は「王族性の軸」です。その方向に移動すると「平民 → 王族」のほうに動きます。この軸たちは人が事前に指定したのではなく、訓練の過程で自然と現れます。

そうやって訓練されると、こんな関係が成り立ちます。

• 「王」 = (王族性の成分 + 男性性の成分 + その他)
• 「女王」 = (王族性の成分 + 女性性の成分 + その他)
• 「男」 = (平民の成分 + 男性性の成分 + その他)
• 「女」 = (平民の成分 + 女性性の成分 + その他)

ここで 王 - 男 をすると男性性が打ち消されて、王族性から平民の成分を引いた「王族の抽出物」みたいなものが残ります。そこに 女 を足すと「王族の抽出物 + 女性性 + 平民の成分」になって、これがまさに女王のベクトル構成とほぼ一致するんです。

衝撃的なのは、こうした「意味の軸の分解」を 人が設計したことがない という点です。Word2Vec はただ周りの単語を予測する課題を解いただけなのに、最適な答えを探すうちに、意味を座標軸に乗せる構造が自然と出てきた。まるで世界を数字に「翻訳」する方法を自分で発明したかのように。

これが embedding がなぜ不思議なのかを象徴するエピソードです。ベクトル空間には意味が幾何学的な関係として入っています。 引き算が「差の抽出」になり、足し算が「属性の付与」になる世界です。「パリ – フランス + ドイツ ≈ ベルリン」みたいな首都の関係も似たように捉えられます。「走る – 歩く + 食べる ≈ 走って食べる (?)」のような動詞変形の関係もある程度捉えられたり。

もちろんすべての関係がこう綺麗に解かれるわけではありません。学習データにない文化・ドメインの関係はブレますし、韓国語や日本語のように助詞や形態素が豊富な言語では、助詞処理のせいで関係がぼやけることもあります。それでも「意味がベクトルの上に幾何学的に配置される」という大きな絵は、数多くの後続研究で再確認されました。

このエピソードがなぜ大事かというと、今私たちが使っている LLM、RAG、意味検索、レコメンドシステム全部が、この「意味の幾何学」の上で回っている ということを見せてくれるからです。王-男+女=女王 が成り立つ空間感覚が、ChatGPT が文脈を理解する原理の一番深い底にあるんです。層を上がるほど計算方式は複雑になっていきますが、根っこはここにあります。

6. 現代の embedding は「単語」単位ではなく「文脈」単位

Word2Vec はカッコいいんですが、ひとつ大きな限界がありました。同じ単語はいつも同じベクトル なんです。

たとえば「はし」という単語。日本語で「はし」は箸でもあり、橋でもあり、端でもあります。ところが Word2Vec はこの 3 つの意味全部をひとつのベクトルで塗りつぶしてしまいます。文脈によって区別がつかないんですね。英語で言うなら「bank」が銀行でもあり川岸でもあるのに、ベクトルがひとつだけある状態です。

実務ではこれが大きな問題になります。「はしを持つ」のはしベクトルと「はしを渡る」のはしベクトルが同じだと、意味検索を作るときに関係ない文書が混ざってきてしまいます。

この限界を破ったのが 2018 年以降の contextual embedding です。代表が BERT (2018) です。BERT 以降の埋め込みは 同じ単語でも文脈によって違うベクトルを出力 します。

どうやって? 前の編 F4 で話した Transformer の構造を思い出してください。Attention が文全体を見ながら単語同士の関係を計算します。その結果、各単語は 周りの単語の情報が溶け込んだベクトル に更新されます。「はしを持つ」と書けば「はし」ベクトルの中に「持つ」が溶け込んで「食器っぽいはし」のベクトルが出てきて、「はしを渡る」では「橋っぽいはし」のベクトルが出てくる、というふうに。

これが現代 embedding の核心的なアップグレードです。Word2Vec は 単語辞書 だったのが、BERT 以降は 文の解釈装置 になった。入力として単語ひとつではなく文 (または長い文書) を入れると、その文脈の中での意味が詰まったベクトルを返してくれるんです。

いま実務でよく使われている embedding ツールは、ほとんどこの系譜です。

• OpenAI embedding API (text-embedding-3-small, text-embedding-3-large): OpenAI が提供する汎用 embedding。文単位で入力してベクトルを受け取ります。2026 年時点で RAG 構築で一番よく使われる選択肢のひとつです。
• sentence-transformers (オープンソース): BERT 系列を文 embedding 用にチューニングしたモデルたち。all-MiniLM-L6-v2 のような軽いモデルから大きな multilingual モデルまであり、ローカルで回せるのでコスト・プライバシー面で有利です。
• BGE、E5、Cohere embed、Voyage のような 2024〜2026 年の新モデルたち: 性能・多言語対応・コストでそれぞれ強みを持って競争しています。

2026 年の視点で言うと、いまや embedding モデルは 文 → ベクトル の水準を超えて 長い文書 → ベクトル まで扱います。8K トークン、32K トークンの入力を一度に受け取るモデルがあって、RAG パイプラインで chunk をどう切るかという悩みは依然として残りますが、昔よりかなり余裕ができました。この話はこのシリーズ後半の M1 (Retrieval Layer) の回でもっと詳しく扱います。

核心だけ一文で整理すると、Word2Vec は「単語をベクトルに」、BERT 以降の現代 embedding は「文脈の中の単語・文・文書をベクトルに」 移します。根本発想は同じですが、解像度が比較にならないほど上がったわけです。

7. これが RAG・意味検索の根っこ

さあここまで来ると、なぜ「embedding は RAG の根っこ」という言い方をよく聞くのか、感覚がつかめてきます。

RAG (Retrieval-Augmented Generation) は、LLM に外部文書を添えて回答させる構造です。たとえば「うちの会社の休暇規程ってどうなってますか?」と聞くと、まず社内文書から関連部分を取ってきて (retrieval)、それを LLM に一緒に入れて回答を作らせる (generation) わけです。

この過程で「関連部分を取ってくる」段階はどう回るでしょうか。昔の方式では キーワードマッチング でした。「休暇」という文字が入った文書を検索して持ってくる、というやつです。これには明確な限界があります。ユーザーが「休みの日のルール」と尋ねると、「休暇」と書かれた文書を拾えないんです。文字が重ならないから。

embedding がこの問題を破ります。流れはこうです。

1. 社内文書を適当なサイズに切って (chunking)、各ピースを embedding モデルに入れてベクトルに変換する。このベクトルたちを ベクトル DB (Pinecone、Weaviate、Chroma、pgvector など) に保存する。
2. ユーザーが質問すると、その質問も同じ embedding モデルに入れてベクトルに変換する。
3. 質問のベクトルと 距離が近い 文書ベクトルを上位何個か (top-k) 取り出す。距離の測り方はたいてい コサイン類似度 を使う。
4. その文書たちを LLM に一緒に入れて答えを作らせる。

ここで大事なのは、「距離が近い」の判断基準がキーワードではなく意味 だということです。質問の「休みの日のルール」というベクトルは、社内文書の「休暇規程」というベクトルと 意味的に近いところに置かれています。文字は重ならなくても意味が重なりますから。これが 意味検索 (semantic search) です。

私はこの瞬間が AI 検索のパラダイム転換点だと思っています。検索がキーワードマッチングから意味マッチングに変わった瞬間。 これがいま、ChatGPT の「Talk to your data」、Claude の Projects、Perplexity の AI 検索、Notion AI の Q&A など、ほぼすべての現代 AI ツールの基盤に敷かれています。

実務的な観点で一つ付け加えると、この原理を理解しているのと理解していないのとの差が、RAG を作るときに大きく現れます。たとえば「なぜうちの RAG がとんちんかんな文書を引っ張ってくるのか?」という問題の原因は、ほとんどが (a) embedding モデルがドメインに合っていないか、(b) chunk を大きく切りすぎか小さく切りすぎか、(c) 質問自体が複数の意図を混ぜていてベクトルが曖昧な地点に打たれるか — このどれかです。この 3 つを疑えるようになれば、デバッグが速く解けます。

8. ベクトルの次元数がなぜ大きいのか

さっき地図の比喩をするとき「実際は数百〜数千次元」と言って通り過ぎましたよね。ここでもう少し入っていってみます。

具体的な数字から言うと、

• Word2Vec 系列: たいてい 100〜300 次元
• BERT base: 768 次元
• OpenAI text-embedding-3-small: 1,536 次元 (縮小可能)
• OpenAI text-embedding-3-large: 3,072 次元
• GPT-3 モデル内部の embedding 次元 (hidden size): 12,288 次元

人間の直観では 3 次元空間が限界です。x, y, z までは想像できますよね。4 次元以上は私たちの視覚では描けません。ところが 機械は次元がいくつだろうと同じ方法で距離を計算します。各次元の座標差を二乗して足してルートを取る距離公式に、次元数の制限はないですから。だから人の目には負担でも、機械視点では何の問題もありません。

次元が多いほど何がいいのか というと、微細な意味の区別が可能になる んです。

感覚的な説明をしてみます。次元ひとつは「意味の1つの軸」に該当すると見てください (正確には軸同士が絡み合っていますが、感覚的にはこう理解してよいです)。2 次元の平面の上では「性別」軸と「年齢」軸しか区別できません。男性・女性、子ども・大人くらいの大きな区別です。ところが次元が 1,000 個あれば、性別・年齢・職業・感情・時間・場所・フォーマル度・ポジティブさなど、数えきれないほどの軸を同時に入れられます。その多くの軸にまたがって単語を配置すると、ずっと細かい意味の差まで区別できるようになります。

「りんご (果物)」と「りんご (謝罪)」が 1 つの平面の上にあったら区別できないかもしれませんが、1,000 次元空間では「果物性の軸」に捉えられた りんご (果物) と、「行為性の軸」に捉えられた りんご (謝罪) が、はっきり違う地域に置かれます。

ただし次元が多いほどいいというわけでもありません。トレードオフがあります。

• 計算コスト: 次元が増えるとベクトル演算 (内積、距離計算) が比例して遅くなります。RAG で数百万の文書ベクトルと質問ベクトルを毎回比較するとなると、次元が 10 倍なら時間・コストも 10 倍近くかかります。
• ストレージコスト: ベクトル DB がたくさんのディスクを食います。1,000 万文書 × 3,072 次元 × 4 byte = 約 122GB 程度。スタートアップ規模ではなかなかの量です。
• 効率が下がる区間: ある地点以上では、次元をさらに増やしても品質の向上はほぼありません。研究上はタスクによって違いますが、一般的に 1,000〜4,000 次元の間でほとんどの収益が実現されると見られています。

なので最近は Matryoshka Embedding のような手法も登場しています。ひとつの embedding を訓練しておけば、必要に応じて先頭の N 次元だけ切って使っても品質が保たれる方式です。精度が必要なときは 3,072 次元を全部使い、速い検索が必要なときは先頭 256 次元だけ使う、というふうに。OpenAI text-embedding-3 系列がこの構造をサポートしています。

実務の結論はこうです。 ただ一番大きい次元を選ぶのではなく、精度・速度・コストの交差点を見て決めてください。小さなコーパスなら 768〜1,536 次元で十分だし、精度が大事な大規模 retrieval なら 3,072 次元を検討する、というふうに。高次元が「いい」ではなく「用途に合う」が正しい表現です。

9. 実務で使うときの注意点

embedding が動く原理は上でずっと説いてきました。これからは実際に使うときに足を取られやすい地点を整理します。私も初めて RAG を作ったとき何度か泥沼にはまった部分です。

(a) モデルごとに embedding 空間が違います

これが一番大きな落とし穴です。OpenAI の embedding で作ったベクトルと BERT で作ったベクトルを同じ空間で比較してはいけません。 数字としては両方とも 1,536 次元あるいは 768 次元のベクトルですが、各次元が意味する軸がまったく違います。モデルごとに訓練データ・アーキテクチャ・目的関数が違うので、同じ「りんご」でも OpenAI 空間と BERT 空間で全然違う位置に打たれます。

実際こうやってミスするケースがあります。DB に入っている文書ベクトルは昔 OpenAI text-embedding-ada-002 で作ったのに、クエリを新しく text-embedding-3-small で作って比較する場合。2 つのモデルは次元も同じで OpenAI が作ったものなのに、互いに互換性がありません。検索結果が完全におかしくなります。

原則は 1 つだけです。文書とクエリは必ず同じ embedding モデルで作ったベクトルでなければならない。 これを「embedding space consistency」と呼びます。このルールを守るだけで RAG デバッグの半分は消えます。

(b) embedding モデルを変えると DB 全体を再計算

(a) の延長ですが、もっと実務的な痛みです。もしプロジェクトの途中で「もっと良い embedding モデルにアップグレードしよう」という決定が出たら、既に保存してある全文書ベクトルを再計算 しなければなりません。数百万の文書があれば再計算コストはかなりです。時間もかかるし、API コストもたまります。

なので実務設計のコツは、

• 初期に embedding モデルを慎重に選ぶ (ベンチマーク確認 + サンプルデータでテスト)
• モデルのマイグレーション手順を事前に設計しておく (段階的アップグレード、dual-write、fallback)
• 可能ならモデルバージョンをベクトルのメタデータに一緒に保存する

私は個人的に、初めて RAG を作るときは高価な大型モデルよりも 軽量なオープンソースモデル (sentence-transformers 系列) で始めるのをおすすめします。コストがほぼ 0 で、品質も結構よくて、初期に何をすべきかの感覚をつかむのにちょうどいいんです。規模が大きくなったときに大型 API に移せばいい。

(c) 日本語 vs 英語の品質差

これは日本語ユーザー視点で大事なポイントです。多くの embedding モデルは 英語データの比重が圧倒的 なので、日本語の性能が英語より落ちます。代表的には、

• 同じ意味の英語の文はよくまとめるけど、日本語の文はあまりまとめられない。
• 日本語の助詞 (「は/が/を」) のせいで微妙なバリエーションが出てもベクトルが揺れる。
• 技術用語・外来語 (「コード」「データ」) は日本語文脈でも英語基準で処理されるケースがある。

幸い 2024 年以降、日本語・多言語対応の embedding がたくさん出ています。multilingual-e5、bge-m3、jina-embeddings-v2-ja、Voyage multilingual など。日本語中心のプロジェクトならこうした multilingual モデルや日本語特化モデルを先にベンチマークすることをおすすめします。英語ベンチマークで上位のモデルが自動で日本語でもよいとは限りません。

(d) chunk サイズの戦略

実はこれが RAG 品質の隠れた半分を占めています。embedding モデルがいくらよくても、chunk をとんちんかんに切ると retrieval がこんがらがります。

• 大きすぎる chunk (例: 5,000 字) → ベクトル1本の中に複数の主題が混ざって意味がぼやける
• 小さすぎる chunk (例: 50 字) → 文脈がなくて意味をつかめない
• 適正線 (たいてい 200〜1,000 字 あたり、ドメインによって違う) → 1 ピースが1テーマに集中するように

文書の構造によって段落単位・文単位・スライディングウィンドウなど、いろんな戦略があります。embedding の品質に問題が出たときに、モデルを変える前に chunk 戦略をまず疑う 習慣をつけると、実務で時間がかなり節約できます。

10. Tokenizer と embedding の関係 (ボーナス)

最後に短く、よく混同される 3 層の区別をきれいに整理して終わります。単語、トークン、embedding ベクトル この 3 つは違います。

流れはこうです。

原文の文字列 → (tokenizer) → トークン ID → (embedding) → ベクトル

• 単語 は人が見る言語の単位。「embedding」は1単語。
• トークン はモデルが見る単位。単語1個がトークン1個とは限りません。日本語では「埋め込み」が 埋、め、込、み のように分かれたりしますし、英語では unbelievable が un, believ, able に割れたりします。Tokenizer がこの分割ルールを決めます。BPE、WordPiece、SentencePiece のようなアルゴリズムが使われます。
• embedding ベクトル は各トークンに割り当てられた数字の配列。モデルの中ではトークンが ID として表現され、その ID に対応するベクトルを “embedding matrix” から取り出して使います。

つまり embedding の入力は 単語ではなくトークン です。まず tokenizer が文字列をトークンに割って、そのトークン ID で embedding matrix を引いてベクトルが出てくる、という順番です。

この区別が実務でなぜ大事かというと、「トークン数 = コスト」構造 のためです。OpenAI も Anthropic も API コストがトークン数に比例します。日本語は英語よりトークナイズ効率が落ちるので、同じ情報を入れるのにトークンが 1.5〜2 倍使われます。つまり 日本語 RAG は英語 RAG よりトークンコストが体感的に大きい んです。これを知らずに設計すると請求書で驚くことになります。

もう一つ。Tokenizer が違う 2 つのモデルは embedding 空間がさらに離れている可能性 が高いです。トークンの分割方式が違えばベクトルの意味も変わりますから。セクション 9 で言った「モデルごとに空間が違う」ルールが、ここでもう一度強調されるわけです。

なので embedding を勉強するときは、この3層を 頭の中で分離 しておいてください。「単語 ≠ トークン ≠ embedding ベクトル」。この区別がきれいになるだけでも、RAG、プロンプトエンジニアリング、fine-tuning 関連の文書がずっとよく読めるようになります。

11. 一枚の地図にまとめる

ここまで来てくださってお疲れさまでした。一度整理するとこうなります。

• コンピュータは数字しか扱えないのに、文字列には意味が直接入っていません。そのため 単語を数字に変える作業が必要 です。
• One-hot encoding は単語に独立したスロットを与えますが、意味の関係はまったく入りません。すべての単語が互いに無関係になります。
• 発想の転換は 高次元空間の上に単語を点として散らして、意味の近い単語同士を近くに配置しよう ということでした。これが embedding の核心アイデアです。比喩するなら、意味の地図を1枚描くことです。
• Word2Vec (2013) が大規模データでこの座標を自動で見つける方法を示しました。周りの単語を予測する課題を解かせると、意味空間が自然に現れた。
• その結果 「王 – 男 + 女 = 女王」 のようなベクトル数学が本当に動くことが確認され、これが embedding が注目された決定的エピソードです。
• BERT (2018) 以降の embedding は 文脈単位 に進化しました。同じ単語でも文脈によって違うベクトルが出ます。OpenAI embedding API、sentence-transformers、BGE、E5 などがその系譜です。
• この構造が RAG、意味検索、レコメンドシステム、AI 検索エンジンの根っこ です。検索がキーワードマッチングから意味マッチングになる瞬間が、まさにここで開きます。
• 実務では モデル間の互換不可、モデル交換時の再計算負担、日本語の品質差、chunk 戦略 の4つを特に気をつけてください。
• トークン ≠ 単語 ≠ embedding ベクトル。この 3 層は分けて考える必要があります。

F6 ではいよいよ、モデルが実際に どうやってこのベクトル空間を「学習」するのか を扱います。Loss、gradient descent、backpropagation のような言葉が出てきますが、今日のように比喩を先に引っ張っていきます。多くがこの編とつながります。embedding が「結果物」なら、F6 はその結果物を作る「過程」です。

---

締めの一文: Embedding は、単語・文・文書を「意味の地図」の上の座標に移す仕事であり、その地図の上で距離は意味の類似度になり、足し算・引き算は意味の演算になる。いま私たちが使っているほぼすべての AI 検索・RAG・レコメンドが、この一枚の地図の上で回っている。

次の読みもの

• F6 — モデルはどう学習するのか [公開済み]
• F7 — プロンプトエンジニアリングの原理 [準備中]
• M1 — Retrieval Layer がなぜ必要か [準備中]

シリーズのはじめから: F1 — LLM とは何か · F2 — Transformer は何をしたのか · F3 — ディープラーニングがただ大きな計算である理由 · F4 — Attention Is All You Need 解説

よくある質問 (FAQ)

Q1. Embedding と LLM は同じものですか?

違います。Embedding は 入力をベクトルに変える変換器 で、LLM は そのベクトルたちを入力として受け取り、次のトークンを予測する生成器 です。順序で見ると 文字列 → トークナイズ → embedding → Transformer 層たち → 次のトークンの確率 で、embedding はこのパイプラインの入り口にあたります。LLM 内部にも自前の embedding レイヤーがあって、別途の embedding API (OpenAI embeddings のようにベクトルだけ返すもの) は、そのレイヤーを独立して使えるようにした製品です。LLM がとても大きくて精巧な機械なら、embedding API はその機械の1部品だけ取り出して使えるようにしたもの、というイメージです。

Q2. なぜ embedding の品質が RAG 品質の半分しか決められないんですか?

RAG 品質は (a) chunk をどう切ったか、(b) どの embedding モデルを使ったか、(c) どの distance metric を使ったか、(d) top-k 何個を LLM に入れたか、(e) re-ranker を使ったか、(f) LLM が結果をどうまとめたか — こう複数のレイヤーで決まります。Embedding はこの中の1軸です。大きな軸のひとつですが、唯一の軸ではありません。だから「embedding モデルだけ最新のものに変えれば RAG がよくなる」はしばしば本当ではありません。パイプライン全体を視野に入れてデバッグする必要があります。このシリーズの M1 の回で retrieval layer 全体を本格的に扱う予定です。

Q3. いますぐ embedding を実験してみるなら何を使うのがよいですか?

コスト0円で始めるなら、Python の sentence-transformers ライブラリを使ってください。pip install sentence-transformers 1 行で入って、all-MiniLM-L6-v2 みたいな小さなモデルを読み込んで文をいくつかベクトルに変えてみると、「ああ、これがベクトルなんだ」の感覚があっという間につかめます。ベクトル2つのコサイン類似度を直接打ってみれば、「王 – 男 + 女」みたいな遊びもしてみられます。次のステップとして OpenAI embedding API を使って品質の差を比べてみたり、pgvector・Chroma のような軽いベクトル DB でミニ RAG を作ってみたりすれば、この記事の内容が手になじんできます。

---

ニュースレターのご案内

毎週月曜日、AI・LLM・エージェント関連の実務整理を一通ずつお届けします。「AIのしくみ地図」シリーズも、このニュースレターで新しい編が公開されるたびに先にご案内します。技術解説を落ち着いて積み上げていきたい方は、ぜひ購読してください。

ニュースレター登録(無料・30秒)

---

シリーズのご案内 (AIのしくみ地図 20編)
– F0: AI・ML・DL・LLM の用語整理
– F1: LLM とは何か
– F2: Transformer は何をしたのか
– F3: ディープラーニングがただ大きな計算である理由
– F4: Attention Is All You Need 解説
– F5: Embedding — 単語を数字に変える理由 (現在の記事)
– F6: モデルはどう学習するのか
– F7: プロンプトエンジニアリングの原理
– M1: Retrieval Layer がなぜ必要か
– (以下20編まで)

---

著者: バイブコーディング テイラー(Lovable公式アンバサダー)
運営: テイラーの隠れ家(shuntailor.net)

ソースリスト

• テイラー知識百科事典 — AIのしくみ地図カテゴリ（本シリーズ20編全編）
• AIのしくみ地図 エントリーマップ — 全体構造 + 3つの読み方
• “Attention Is All You Need” (Vaswani et al., 2017)
• Anthropic · OpenAI · Google 公式ドキュメント
• mathbullet (YouTube) / Jay Alammar “Illustrated Transformer” / 3Blue1Brown — 易しい解説のリファレンス

---

著者: バイブコーディング テイラー (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ「AIのしくみ地図」20編は、ウィキの蓄積と公式論文・公式ドキュメントを根拠に整理した体系的学習カリキュラムです。