本記事の要点
Embedding（エンベディング）は、テキストを「意味を持った数値の列」に変換する技術です。RAGで社内文書を検索するとき、キーワードの完全一致ではなく「意味が近い文書」を見つけられるのは、このEmbeddingが裏側で働いているからです。本記事では仕組み、主要モデルの比較、日本語対応の注意点、導入の第一歩までを非エンジニア向けに整理します。
Embeddingとは何か
Embedding（エンベディング）とは、人間が読む文章をコンピュータが計算できる「数値の列」に変換する技術です。この数値の列をベクトルと呼びます。
ポイントは、単なる文字コード変換ではなく「意味」を数値に載せるという点です。たとえば「東京」と「日本の首都」は文字としてはまったく異なりますが、Embeddingで変換すると非常に近い数値になります。逆に「東京」と「大阪」は、どちらも都市ではあるもののやや離れた数値になります。
Embeddingの有名な例
王 − 男 + 女 = 女王 単語をベクトルに変換すると、意味の「足し算」「引き算」ができるようになります。「王」から「男性」の要素を引き、「女性」の要素を足すと「女王」に近い値が出る。これはEmbeddingが言葉の意味関係を数値で捉えている証拠です。
この技術が実用面で威力を発揮するのは、文章同士の「意味の近さ」を数値で測れるようになることです。「新入社員向けの福利厚生ガイド」と「入社した人が使える社内制度まとめ」は、キーワードがほとんど被っていませんが、Embeddingを使えば「ほぼ同じ話題」と判定できます。
なぜRAGにEmbeddingが必要なのか
RAG（Retrieval-Augmented Generation）は、AIが回答を生成する前に社内文書やナレッジベースから関連情報を検索し、その情報をもとに正確な回答を返す仕組みです。詳しくは前回の記事「RAGとは？」で解説しています。
RAGの精度は「検索フェーズでどれだけ的確な文書を引っ張ってこれるか」で大きく決まります。ここでEmbeddingが登場します。
キーワード検索との決定的な違い
従来のキーワード検索（BM25など）は、検索ワードと文書中の単語が一致するかどうかで判定します。「車」と検索したら「車」という文字を含む文書だけがヒットし、「自動車」「クルマ」「マイカー」は拾えません。
一方、Embeddingベースの検索（セマンティック検索）では、「車」のベクトルと「自動車」のベクトルが近いことを利用して、表現が異なっても同じ意味の文書をヒットさせることができます。
検索方式の違い
キーワード検索（BM25） — 「車」で検索 → 「車」を含む文書だけヒット。「自動車」「クルマ」はヒットしない。 Embedding検索（セマンティック検索） — 「車」で検索 → 「自動車」「クルマ」「マイカー」「車両」もヒット。意味が近ければ文字が違ってもOK。
RAGの検索フェーズにEmbeddingを使うことで、ユーザーが使う言葉と社内文書の表現が多少ずれていても、本当に必要な情報を見つけ出せるようになります。これがRAGの回答精度を底上げする最大のポイントです。
Embeddingの仕組み — ベクトルとは
Embeddingの出力である「ベクトル」は、具体的には数値の配列です。たとえば「東京は日本の首都です」という文をEmbeddingモデルに通すと、以下のような数値の羅列が返ってきます。
ベクトルの例（実際にはもっと長い）
[0.0231, -0.0892, 0.1547, 0.0034, -0.0678, 0.1123, -0.0456, 0.0891, ...]
この配列の長さを「次元数」と呼びます。次元数が多いほど、より細かい意味の違いを表現できますが、そのぶん計算やストレージのコストが増えます。
次元数の感覚をつかむ
非エンジニアの方にとって「384次元」「3072次元」と言われてもイメージしにくいかもしれません。身近な例えで説明します。
ベクトル = 文章の「住所」と考えてください。住所は「日本 → 東京都 → 渋谷区 → 〇〇町 → 〇番地」と細かくなるほど正確な場所を指し示せます。次元数が多いベクトルは、この住所の階層が深いイメージです。256次元なら「市区町村」まで、3072次元なら「部屋番号」まで指定できるような違いがあります。
コサイン類似度で「意味の近さ」を測る
2つのベクトルがどれくらい似ているかを測る指標がコサイン類似度です。2つのベクトルの「角度」を計算し、0から1の数値で表します。
| コサイン類似度 | 意味 | 具体例 |
|---|---|---|
| 1.0 | 完全に同じ意味 | 「犬」と「犬」 |
| 0.85〜0.95 | 非常に近い意味 | 「犬」と「ワンちゃん」 |
| 0.60〜0.85 | 関連がある | 「犬」と「ペット」 |
| 0.3以下 | ほぼ無関係 | 「犬」と「決算書」 |
RAGでは通常、ユーザーの質問をベクトルに変換し、社内文書のベクトルとコサイン類似度を計算して、上位の文書をAIに渡します。この「ベクトルの近さで検索する」仕組みがEmbeddingの核心です。
主要なEmbeddingモデル比較
Embeddingモデルは各社が提供しており、それぞれ特徴が異なります。2026年時点で実用的な主要モデルを比較します。
| モデル名 | 提供元 | 次元数 | 特徴 |
|---|---|---|---|
| text-embedding-3-large | OpenAI | 3072（256まで縮小可） | 英語で最高精度。次元縮小に対応しており柔軟 |
| text-embedding-3-small | OpenAI | 1536 | 低コストで十分な性能。小〜中規模の導入に最適 |
| embed-v4 | Cohere | 1024 | 100以上の言語に対応。画像も扱えるマルチモーダル |
| voyage-3 | Voyage AI | 1024 | コード検索やドメイン特化のバリアントが豊富 |
| BGE-M3 | BAAI | 1024 | オープンソース。自社サーバーでの運用が可能 |
| all-MiniLM-L6-v2 | sentence-transformers | 384 | 軽量・高速・無料。ローカル環境でもサクサク動く |
選ぶときのポイント
次元数が大きい＝高精度とは限りません。384次元のall-MiniLM-L6-v2でも、社内文書の検索には十分な精度が出るケースが多くあります。「最高スペック」を選ぶより、自社のデータ量・予算・運用体制に合ったモデルを選ぶことが重要です。
次元数とコストのトレードオフ
「次元数が多い方が高精度なら、最大次元数のモデルを選べばいいのでは」と考えるのは自然です。しかし実際には、次元数とコストのバランスを考える必要があります。
次元数を上げても精度は比例して上がらない
OpenAIのtext-embedding-3-largeは3072次元ですが、256次元まで圧縮しても精度の低下は約5%程度にとどまります。一方で、ストレージは12倍の差があります。10万件の文書を扱う場合、この差は無視できません。
| 比較項目 | 3072次元 | 256次元 | 差 |
|---|---|---|---|
| 精度（MTEB平均） | 64.6% | 約62% | 約-5% |
| 1ベクトルのサイズ | 12,288バイト | 1,024バイト | 12倍 |
| 10万件のストレージ | 約1.2GB | 約100MB | 12倍 |
| 検索速度 | 遅い | 速い | 大幅改善 |
はてなベースの実例
はてなベースでは、all-MiniLM-L6-v2（384次元）で60,410ファイル・679,733チャンクをEmbedding化して運用しています。APIコストはゼロ（ローカル実行）で、日常の社内ナレッジ検索には十分な精度が出ています。「最高次元＝最高精度」ではなく、ユースケースに合った選択が重要です。
日本語Embeddingの注意点
Embeddingモデルの多くは英語を中心に学習されているため、日本語で使うときにはいくつか注意点があります。
日本語対応の温度差
モデルによって日本語の扱いに大きな差があります。英語では高精度なモデルが、日本語では期待ほどの精度を出せないケースも珍しくありません。
| モデル | 日本語対応 | 補足 |
|---|---|---|
| OpenAI text-embedding-3系 | 実用レベル | 日本語もそこそこ。英語ほどの精度は出ない場合あり |
| Cohere embed-v4 | 高精度 | 100以上の言語に対応。日本語を含む多言語に強い |
| BGE-M3 | 高精度 | 多言語オープンソース。日本語ベンチマークでも好成績 |
| multilingual-e5-large-instruct | 高精度 | 日本語に強い多言語モデル。オープンソース |
| ruri-large | 日本語専用 | 日本語に特化して学習されたモデル |
| all-MiniLM-L6-v2 | 基本レベル | 英語中心だが、日本語でも基本的な検索は可能 |
日本語特有の課題
- 表記ゆれ — 「お問い合わせ」「お問合せ」「問い合わせ」が別物として扱われやすい。Embeddingである程度吸収できるが、前処理で統一するとさらに精度が上がる
- 漢字・ひらがな・カタカナ — 「サーバー」「サーバ」「さーばー」の表記差。モデルによってはうまく同一視できないことがある
- 専門用語・業界用語 — 汎用モデルでは業界固有の略語（例えば「稟議」「起案」「決裁」の関係性）を正しく捉えられない場合がある
日本語メインなら事前にテストを
モデルを選定する際は、自社の実際の文書で検索テストを行うことを推奨します。公開ベンチマークの数値と、自社文書での実際の精度は必ずしも一致しません。10〜20件の検索クエリを用意し、期待する文書がヒットするかを確認してから本番導入に進みましょう。
Embeddingの品質を左右するもの
Embeddingモデルを導入すれば自動的に高精度な検索ができるわけではありません。モデル以外にも、検索品質を左右する要素がいくつかあります。
チャンキングの方法
長い文書をそのままEmbeddingに通すと、1つのベクトルに複数の話題が混ざってしまい、検索精度が下がります。文書を適切な長さの「チャンク」に分割してからEmbeddingにかけることが重要です。分割の粒度や方法（段落単位、見出し単位、文単位など）が検索品質に直結します。
テキストの前処理
社内文書にはHTMLタグ、不要なヘッダー・フッター、改行コードの混在など、意味に無関係なノイズが含まれていることが多くあります。これらを除去してからEmbeddingにかけることで、ベクトルが文章の「意味」により集中できるようになります。
クエリと文書の形式を揃える
検索クエリ（質問文）と検索対象の文書で、文章のスタイルが大きく異なると精度が落ちることがあります。たとえばユーザーが「有給休暇の申請方法は？」と質問形式で検索するのに対し、文書側が「有給休暇申請規程 第3条」のような箇条書き体裁だと、意味は近くてもベクトルの距離が開く場合があります。
品質向上の4つのポイント
1. 適切なチャンキング — 文書を意味のまとまりで分割する 2. テキスト前処理 — HTMLタグや不要な装飾を除去する 3. 形式の統一 — クエリと文書のスタイルを揃える 4. 同義語対策 — 業界用語の表記ゆれを前処理で吸収する
実践 — はてなベースのEmbedding環境
はてなベースでは、社内ナレッジの横断検索にEmbeddingを本格活用しています。実際の構成を紹介します。
構成の全体像
- 対象ファイル — 社内の全プロジェクトから60,410ファイルをインデックス対象として収集
- チャンク分割 — 各ファイルを意味のまとまりで分割し、679,733チャンクを生成
- Embedding変換 — all-MiniLM-L6-v2（384次元）でチャンクごとにベクトル化。ローカル実行のためAPIコストゼロ
- インデックス保存 — ベクトルデータをローカルに保存。差分更新で常に最新状態を維持
- 検索実行 — Claude Codeから自然言語で検索クエリを投げると、意味的に近いチャンクが上位に返ってくる
all-MiniLM-L6-v2を選んだ理由
- ローカル実行が可能 — 外部APIを呼ばないため、社内情報が外部に送信されない
- APIコストが一切かからない — 68万チャンクをEmbedding化しても無料
- 軽量で高速 — 384次元のため、検索もインデックス更新もストレスなく動く
- 十分な精度 — 社内ナレッジ検索という用途では、3072次元のモデルと体感差がほとんどない
「60,410ファイルをAPIゼロ円で検索可能にした」という事実
OpenAI text-embedding-3-smallで同じ量をEmbeddingすると、トークン数にもよりますが数十ドル〜のAPI費用が発生します。all-MiniLM-L6-v2なら初期構築もランニングもゼロ円です。「まず小さく始める」にはうってつけのモデルです。
Embeddingを始めるならどこから
Embeddingの導入を検討する際、最初の一歩としてどのモデルを選ぶかは重要です。以下のフローチャートを参考にしてください。
Embeddingモデル選定フローチャート
Q1. API利用にコストをかけられるか？ - はい → 手軽さ重視 → OpenAI text-embedding-3-small - いいえ → コストゼロ → all-MiniLM-L6-v2 Q2. 日本語の精度を最大化したいか？ - はい（多言語対応）→ Cohere embed-v4 - はい（自社運用）→ BGE-M3
用途別のおすすめ
| 想定シーン | おすすめモデル | 理由 |
|---|---|---|
| まず試したい・PoC段階 | OpenAI text-embedding-3-small | APIキーさえあれば数行で動く。低コスト |
| コストをかけたくない | all-MiniLM-L6-v2 | 完全無料。ローカルで動く |
| 日本語の精度が最優先 | Cohere embed-v4 | 多言語ベンチマークで高精度 |
| 大規模・自社管理 | BGE-M3 | オープンソース。自社サーバーで完結 |
| セキュリティ最優先 | BGE-M3 / all-MiniLM-L6-v2 | 外部APIにデータを送らない |
最初の一歩は「小さく試す」
完璧なモデル選定を目指して動けなくなるよりも、まず手元の文書100件でEmbeddingを試し、検索結果を見てみることをおすすめします。「意味で検索できる」感覚を体感すると、自社に合ったモデルや運用方法が自然と見えてきます。
まとめ
Embeddingは、テキストを「意味を持った数値の列（ベクトル）」に変換する技術です。RAGの精度を決定づける検索フェーズで中核を担い、キーワードの完全一致に頼らない「意味検索」を可能にします。
本記事のポイント
- Embeddingはテキストを数値ベクトルに変換し、「意味の近さ」を計算可能にする技術 - RAGの検索精度はEmbeddingの品質で大きく変わる - 次元数が大きい＝高精度とは限らない。384次元でも実用的な検索は十分可能 - 日本語では、モデル選定時に実データでのテストが不可欠 - チャンキング・前処理・クエリ設計など、モデル以外の要素も品質を左右する - まずは小さく試し、自社のデータで「意味検索」の感覚をつかむことが第一歩
前回のRAG入門記事と合わせて読むことで、「RAGがどう検索しているか」の全体像がつかめるはずです。
社内データのAI活用を、はてなベースがお手伝いします
たとえばこんなケースで活用できます。 - 社内に散在するナレッジや文書を整理し、AIで横断検索できる基盤をつくりたい - 既存の業務フローにAIエージェントを組み込み、問い合わせ対応や情報検索を自動化したい - 「全社でAIを使いたいが、外部にデータを送りたくない」という方針に合う、オンプレミスAI基盤を導入したい データ基盤の整備からAIエージェントの組み込み、オンプレミスAI導入まで、経理DX事業部が伴走します。