エンベディングとは？やさしい説明

エンベディング（embedding）は、テキスト・フレーズ・文書を数値の並び - 固定長のベクトル - に変換する方法です。エンベディングモデルは意味が近い表現が数値空間で「近く」、違うものは遠くなるよう学習します。意味検索、RAG、レコメンド、文書クラスタリングの土台です。以下ではエンベディングの意味、トークンや LLM の回答との違い、ビジネスで本当に必要な場面を説明します。

• ベクトル - 数百〜数千の数値リスト、テキストの「意味の指紋」
• Embedding model - テキストをベクトルに符号化する別のニューラルネット。チャットモデルではない
• 意味的な近さ - 「宅配便」と「速達配送」は「配送」と「確定申告」より近い
• 主な用途 - 意味による検索、RAG、重複除去、分類
• 混同注意 - エンベディングは回答を生成しない。関連テキスト片を見つけるためのもの
• 実務 - ナレッジベースを一度索引化し、クエリごとに Top-K 近傍チャンクを取得

エンベディングを一言で

図書館で本を著者順ではなくテーマ別に並べるイメージです。物流はまとめ、会計は別棚、マーケはまた別。エンベディングはテキストに対して同じことを、多次元の数値空間で行います。

エンベディングはエンコーダモデルの出力です。入力「返品の手続きは？」、出力は例えば 1 536 次元のベクトル。ドキュメント断片、チケット、段落ごとにベクトルがあります。ユーザーの質問も同じモデルで符号化し、最も近い一致を探します。

エンベディングは人のように「理解」したり回答を書いたりしません。意味の座標を与え、数百万断片を素早く比較できるようにします。

通常検索があるのにベクトルが要る理由

キーワード検索は完全一致を探します。クエリ「返品」では「refund policy」や「返送フロー」だけの段落はヒットしません。意味検索は文字ではなく意味を比較します。

典型的な用途：

1. 社内 FAQ・サポート - オペレーターやボットが顧客の言い回しから規程を特定
2. RAG - LLM 回答前に wiki・PDF・チケットから関連チャンクを取得
3. 類似チケット - 手動タグなしで「同じ障害があった」を発見
4. 重複除去 - ほぼ同じ記事・レビュー・商品カードを除外
5. クラスタリング - 問い合わせ・レビュー・フォーラムテーマを分析用にグループ化

必要テキストがモデルのコンテキストウィンドウに収まり、更新が少ないならエンベディングは必須ではありません。コーパスが大きく、生きていて、よく変わる - ベクトル索引は毎回全部を prompt に入れるよりほぼ常に安上がりです。

テキストが数値になる流れ

簡略パイプライン：

文書 → チャンク分割 → embedding model → ベクトル → vector DB
ユーザークエリ → 同じ embedding model → クエリベクトル → Top-K 検索 → LLM

1. チャンク分割

長い PDF や記事库は 256-1 024 トークン程度の断片に分割し、段落の途中で切らないよう少しオーバーラップします。小さすぎると文脈欠落、大きすぎると検索精度低下。

2. Embedding model

専用モデルが各チャンクを処理し、固定次元ベクトルを返します - モデルにより 384、768、1 536、3 072 など。クラウド：OpenAI text-embedding-3、Cohere、Voyage。オープンソース：BGE、E5、multilingual-e5。Ollama や自前サーバーでローカル実行も可。

3. 索引化と検索

ベクトルは vector store に格納 - pgvector 付き PostgreSQL、Qdrant、Weaviate、Chroma。クエリ時に質問ベクトルと DB ベクトルの距離を計算。多くはコサイン類似度。最も近い Top-K 断片を返す（通常 3〜10）。

検索品質の約 80% は「チャンク分割 + embedding model」で決まり、最も賢いチャット LLM ではありません。retrieval + generation の詳細は RAG の記事へ。

意味の近さに魔法はない

ベクトルの「近さ」は辞書の同義語ではありません。巨大コーパスで学習し、近傍点が似た文脈に対応します。だから：

• 「配送料」と「宅配サービス費用」は近い；
• 「データ分析の Python」は「pandas チュートリアル」に近く、「動物園のヘビ」には遠い；
• 多言語モデルでは日本語クエリで英語の同義段落が見つかることも。

重要：同じ embedding model・同じバージョンのベクトルだけ比較可能。OpenAI と BGE のベクトルを一つの索引に混ぜるのは無効 - 別の「地図」です。

プロダクトでの登場場面

いずれも ベクトル retrieval + LLM 推論。エンベディングはコンテキストウィンドウと API コストを節約 - prompt には見つかったチャンクだけ、全 DB ではない。

エンベディング vs トークン vs ファインチューニング

混同されやすい三つの仕組み：

トークン はチャットモデルの課金・分割単位。エンベディングは別 API 商品で 1M 単価もモデルも異なります。戦略比較はコンテキストウィンドウ vs RAG vs ファインチューニング。

embedding model の選び方

実務では四つの観点：

1. 言語 - 日英中混在コーパスには多言語モデル（bge-m3、multilingual-e5、voyage-3）
2. 次元 - 次元が大きいほど精度は上がりやすいが索引・保存は重い
3. レイテンシとコスト - 数百万文書では初回索引と更新時の再索引を見積もる
4. デプロイ - クラウド API は着手が早い；ローカルモデルは SaaS に送らない機密データ向け

MVP では実績あるモデル 1 つ + 既存 PostgreSQL の pgvector で足りることが多い。検索指標が頭打ちになってから reranker 複数や BM25 + ベクトルハイブリッドを検討。

よくあるミス

• 適当に索引 - HTML 未整理、チャンク戦略なし、重複あり - ノイズだらけの検索
• モデル変更だけで再索引しない - 新旧ベクトルは非互換
• エンベディングに推論を期待 - ベクトルは答えない；取得チャンクの上に LLM かテンプレートが必要
• 指標無視 - 「質問 → 期待文書」のテストセットなしでは本番に耐えにくい
• 全文検索と混同 - SKU・正確なコードはキーワード + エンベディングのハイブリッドが有利

まとめ

エンベディングはテキストの数値による「意味の指紋」です。大きなコーパスから見つけることが重要な場面で必要：RAG、サポート、社内 wiki、コード検索。1 ファイルをコンテキストに入れる短いチャットならベクトル索引は任意。更新の激しいナレッジベースではエンベディングが基礎ブロック；LLM はその上に構築され、代わりにはなりません。

よくある質問

エンベディングとトークンの違いは？

トークンはチャットモデル用のテキスト断片：prompt 長と API 費用の単位。エンベディングは文・段落・チャンク全体に対する 1 ベクトルで、検索用に意味を符号化します。トークンは生成のための分割、エンベディングは比較のための意味符号化です。

ChatGPT や Claude があるのに embedding model が別にある理由は？

チャットモデルは回答生成に最適化。エンベディングモデルは意味を圧縮ベクトルにし高速検索するよう最適化。専用エンコーダは大規模索引で安く、高価な output トークンで文書を「要約」しません。

異なるモデルのベクトルを一つの DB に混在できる？

いいえ。 モデルごとに座標空間と次元が違います。索引は 1 つの embedding model で構築；変更時は全再索引。同じエンコーダ・同じバージョンのベクトルだけ比較してください。

API 経由のエンベディング費用は？

同プロバイダのテキスト生成より安いことが多い：embedding エンドポイントの input トークン課金で output なし。正確な単価はモデルと規模次第；月次予算はコーパストークン数 × 1M 単価 + 再索引を見込む。トークン計算の詳細はトークン費用。

シンプルなサイトのチャットボットにエンベディングは必要？

常にではない。 十数ページの固定 FAQ だけ、または PDF を一度コンテキストウィンドウに入れるだけなら prompt で足ります。文書が多く頻繁に変わり、ユーザーの言い回しでの検索が重要 - サポートや社内アシスタントの典型 RAG - のときエンベディングが要ります。