エンベディングとは？｜ベクトル空間でAI調査が記憶する仕組み

この記事の要点

エンベディング（embedding、埋め込み）は、テキストや画像を高次元のベクトル空間に写像し、意味の近さをコサイン類似度で測る技術です。OpenAI text-embedding-3-small（1,536次元、$0.02/1M tokens）から始めれば、多くの用途で十分です。本番運用では Vector Database（Pinecone、Qdrant、Weaviate、Milvus、Chroma のいずれか）、Chunking 戦略（256〜512 tokens）、Cross-encoder Reranker の3点セットが必須で、Hybrid Search（BM25 + Dense + Reciprocal Rank Fusion）が 2026 年の standard になっています。日本語なら Ruri v3、多言語なら bge-m3 か multilingual-e5 が有力候補です。エンベディングは RAG の Retrieval を実現する1つの方法であり、リサーチエージェントの記憶と検索を作るときの心臓部になります。Vector DB を自作する以外の選択肢としては、完全記憶型ナレッジグラフの Snorbe が別軸で有効です。

エンベディングの直感的理解 ベクトル空間とコサイン類似度

エンベディング（embedding、埋め込み）は、テキストや画像などの離散的なデータを、数値のベクトルに変換する技術です。ここで大事なのは「ただの数字にする」のではなく、意味が近いものは数値上でも近くなるように変換する、という点です。

たとえば「猫」と「犬」を数値ベクトルに変換すると、この2つは「動物」というカテゴリで近い場所に配置されます。一方で「猫」と「量子力学」は、まったく違う場所に置かれます。この「近さ」を数値で測ることで、AIは意味を理解しているように振る舞える、というのがエンベディングの基本アイデアです。

ベクトル空間とは何か

エンベディングが作り出す空間を、ベクトル空間と呼びます。私たちが暮らしている3次元空間（縦・横・高さ）は、たまたま次元の数が3つの空間です。ベクトル空間は、次元の数を100や1000にまで拡張したものだと考えてください。

OpenAIの text-embedding-3-small は、テキストを1,536次元のベクトルに変換します。つまり、1つの文章が1,536個の数字の並びとして表現されます。text-embedding-3-large は3,072次元です¹。

「1,536次元の空間なんて想像もつかない」と感じるかもしれません。それで問題ありません。人間の脳は3次元までしか直感で扱えないので、高次元は数学的な操作として扱えれば十分です。大事なのは、次元数が多いほど表現力（意味の細かい違いを区別できる力）が上がる、というシンプルな法則です。

ただし次元数が多いほど計算コストとストレージコストも増えます。100万件の文書を1,536次元で保存すると、単純計算で15億個の浮動小数点数を持つことになります。あとで説明するVector Databaseの選び方や、Matryoshka（マトリョーシカ）による次元削減の話は、このコスト問題への対処法だと思っておいてください。

コサイン類似度で「意味の近さ」を測る

ベクトル空間の中で、2つの点の近さを測る方法はいくつかあります。ユークリッド距離（普通の直線距離）が最も直感的ですが、エンベディングの世界で最も使われるのはコサイン類似度（Cosine Similarity）です。

コサイン類似度は、2つのベクトルが「同じ方向を向いているか」を測る指標です。式は次のようになります。

Sim(A, B) = (A · B) / (‖A‖ × ‖B‖)

A · B はドット積（内積）、‖A‖ と ‖B‖ はそれぞれのベクトルの長さです。スコアの範囲は -1 から 1 で、意味は次の通りです²。

• 1 に近い ⇒ 2つのベクトルはほぼ同じ方向を向いている（意味が近い）
• 0 に近い ⇒ 2つのベクトルは直交している（意味の関係がない）
• -1 に近い ⇒ 2つのベクトルは逆方向を向いている（意味が正反対）

なぜユークリッド距離ではなくコサイン類似度なのでしょうか。理由はシンプルで、ユークリッド距離は「ベクトルの長さ」の影響を受けるからです。長い文章と短い文章では、embedding のベクトルの絶対的な長さが変わることがあります。ですが、私たちが知りたいのは「意味が似ているかどうか」であって、「文章が長いかどうか」ではありません。

コサイン類似度は、内積を各ベクトルの長さで割ることで、長さの影響を消しています。ですから、文章の長さに関係なく、意味の方向だけを見ることができるわけです。IBMのドキュメントでも「コサイン類似度はベクトルの方向を測るもので、大きさを測るものではない」と明記されています³。

「王 – 男 + 女 ≈ 女王」というアナロジーが成り立つ理由

エンベディングの面白い性質として、ベクトル同士の足し算・引き算が意味の変換になる、というものがあります。有名な例が「王のベクトル – 男のベクトル + 女のベクトル ≈ 女王のベクトル」です。

これは偶然ではなく、モデルが大量のテキストを学習する過程で、性別や地位のような概念が、ベクトル空間の特定の方向に対応するように配置されているからです。つまり、単語の意味的な関係が、幾何学的な操作として取り出せる状態になっているのです。

この性質は、リサーチエージェントを作るときにも活きてきます。たとえば「AI エージェントの記憶設計」というクエリと、「LLM のコンテキストウィンドウ管理」というクエリは、キーワードとしては違いますが、ベクトル空間上ではそれなりに近い位置に配置されます。エンベディングは、キーワード完全一致では拾えない「意味的な関連性」を検索できる仕組み、と考えるのが正確です。

最小コード例 OpenAI で embedding を取得する

理屈をつかんだら、実際に叩いてみるのが早いです。OpenAI の Python SDK で embedding を取得する最小コードは、次のようになります。

from openai import OpenAI

client = OpenAI(api_key="your-api-key")

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="エンベディングは意味を数値ベクトルに変える技術です"
)

vector = response.data[0].embedding  # 1536次元のfloat配列
print(len(vector))  # 1536

このコードで、1つの文が1,536次元のベクトルに変換されます。あとは複数のテキストを同じようにベクトル化して、コサイン類似度を計算すれば、意味検索の最小プロトタイプが動きます。

Numpy を使うなら、コサイン類似度の計算はさらにシンプルです。

import numpy as np

def cosine_sim(a, b):
    a = np.array(a)
    b = np.array(b)
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

sim = cosine_sim(vector_a, vector_b)

この関数を100万件のベクトルにナイーブに適用すると計算が遅くなるので、実運用ではVector Database（Pinecone、Qdrant、Weaviate、Milvus、Chroma など）を使います。そこはセクション3で扱います。

次元数を後から削れる Matryoshka という工夫

「1,536次元は多すぎるかもしれない」と感じたら、Matryoshka Representation Learning（MRL）を検討してください。OpenAI の text-embedding-3 シリーズと Cohere の一部モデルが対応しています⁴。

Matryoshka は、embedding の先頭 N 次元だけを使っても、精度がそれなりに維持されるように学習された性質です。API の dimensions パラメータで 256 / 512 / 1024 を指定すれば、その次元数のベクトルが返ってきます。Vector DB のストレージコストは次元数に比例するので、これだけでコストを1/6〜1/4に削れる場合があります。

実際、OpenAI の公式ドキュメントによると、text-embedding-3-large を 256 次元に削っても、text-embedding-ada-002（旧世代モデル）より高いスコアを維持したとの結果があります⁵。「デフォルトの次元数を使う」以外の選択肢を持っているだけで、コスト設計の幅が広がります。

直感理解のまとめ

セクション1で押さえた要点を整理します。エンベディングは、テキストや画像を高次元のベクトル空間に写像する技術です。ベクトル空間内での意味の近さは、コサイン類似度で測るのが標準です。次元数は表現力とコストのトレードオフで、Matryoshka を使えばあとから削減できます。Python で数行のコードで叩けます。

ここまでで「エンベディングとは何か」の直感がつかめたはずです。次のセクションでは、実際にどのモデルを選ぶべきか、2026年時点の選択肢を数値で比較していきます。

出典

主要エンベディングモデルの選び方 OpenAI Cohere Voyage bge Ruri

セクション1でエンベディングの基本を押さえたので、次は「どのモデルを使うか」の判断に入ります。2026年時点で選択肢は膨大にあります。OpenAI、Cohere、Voyage AI、Google Gemini、NVIDIA、それに OSS 系の bge-m3、Jina v3、Nomic、日本語特化の Ruri v3。それぞれ性能と価格が違うため、用途に合わせて選ぶ必要があります。

このセクションでは、代表的なモデルを数値ベースで比較し、選び方の判断フローを整理します。

商用モデル OpenAI text-embedding-3 シリーズ

まずは最も広く使われている OpenAI の text-embedding-3 シリーズから見ていきます⁶。

どちらも Matryoshka 対応で、dimensions パラメータで次元数を後から削れます。多くの用途では text-embedding-3-small で十分です。日本語ドキュメントの意味検索、社内ナレッジベースの構築、簡単な RAG プロトタイプは、まず small で始めて、精度が足りなければ large に切り替える、という段階的なアプローチが安全です。

価格差は 6.5 倍あります。100万件の1000トークン文書を embedding すると、small なら $20、large なら $130 です。プロトタイプ段階では体感できない差ですが、10億トークンを扱う本番システムになると、月額の差額が数千ドル規模になるので無視できません。

商用モデル Cohere と Voyage AI

Cohere は多言語検索とビジネス用途で強いモデルを出しています。Cohere embed-english-v3.0 は MTEB スコア 63.1 で、日本語を含む多言語版も提供しています⁷。特にビジネス文書の類似度判定で強く、後述する Cohere Rerank と組み合わせて使うと本領を発揮します。

Voyage AI は 2026 年時点で MTEB リーダーボード上位を占めるモデルを提供しています。Voyage-3.1-large は $0.05 / 1M tokens で、Google Gemini Embedding 001 に近い性能を持ち、Google Cloud を使えない環境の代替として注目されています⁸。retrieval タスクに特化した Voyage-3-large は、2026 年 4 月時点で MTEB Retrieval で首位級です⁹。

OSS モデル bge-m3 Jina v3 Nomic

セルフホストを検討するなら、OSS モデルが選択肢に入ってきます。

BGE (BAAI General Embedding) シリーズは、北京智源人工智能研究院が提供する Apache 2.0 ライセンスのモデル群です¹⁰。中でも bge-m3 は、Dense（密ベクトル）、Sparse（疎ベクトル）、Multi-vector（多ベクトル）の3種類の表現を1モデルで出力できる珍しい設計です。多言語対応で、日本語もそれなりに扱えます。ダウンロード数の多い bge-large-en-v1.5 は MTEB 63.9 と、有料モデルにも引けを取らないスコアを出しています。

Jina Embeddings v3は、8,192 tokens の長いコンテキスト、1,024 次元、MTEB 65.5 という高い性能を持ちます¹¹。「late chunking」という機能があり、長文をチャンクに分けたときに、境界での意味の切れ目を最小化できます。長文ドキュメントを扱うリサーチエージェントで有力な選択肢です。しかも OpenAI text-embedding-3-large より精度が高く、価格は text-embedding-3-small より安いという評価もあります。

Nomic Embed は、Apache 2.0 で 137M パラメータの軽量モデルです¹²。CPU で推論できるサイズで、Matryoshka 対応（768 → 64 次元まで削減可能）です。ただし英語特化なので、多言語タスクではスコアが著しく落ちます。日本語で使うなら別のモデルを選んでください。

MTEB 2026年4月時点のリーダー

Massive Text Embedding Benchmark（MTEB）は、embedding モデルの標準的なベンチマークです。2026 年 4 月時点のトップは次のようになっています¹³。

• Google Gemini Embedding 001: MTEB 68.32（首位）
• NVIDIA NV-Embed-v2: MTEB 69.32（legacy スコアでは首位、2024〜2025年からの継続王者）
• Voyage-3-large: retrieval タスクで首位級
• Alibaba Qwen3-Embedding-8B: MTEB 70.6（多言語）¹⁴

ただし、MTEB のスコアだけで選ぶのは危険です。MTEB は英語ベンチマークが中心で、日本語や特定ドメイン（法律・医療・特許）での性能は保証されません。「MTEB スコア 70 のモデルが自分のドメインで最高」とは限らないので、必ず自分のデータで再評価してください。

日本語なら Ruri v3 が最有力

日本語のエンベディングモデルとしては、cl-nagoya が公開している Ruri v3 が 2026 年時点で最有力です¹⁵¹⁶。

Ruri v3 は、ModernBERT-Ja をベースにした日本語特化モデルで、8,192 tokens のコンテキスト長を持ちます。JMTEB（Japanese MTEB）スコアは 74.5〜77.2 で、パラメータ数は 30M〜310M まで複数サイズが用意されています¹⁷。

sentence-transformers で呼び出せる設計で、Query と Passage にプレフィックス（クエリ: 〜 パッセージ: 〜）を付ける方式です。ハイスペック GPU がなくても動くサイズで、日本語ドキュメントを扱うプロジェクトの第一候補になります。

比較対象として、intfloat/multilingual-e5 は 100 言語以上をカバーする BERT ベースのバイエンコーダで、MTEB 多言語オープンソース部門で長らく首位でした¹⁸。Ruri v3 が登場する前は日本語でも最有力候補でしたが、JMTEB では Ruri v3 に負けているケースが多いです。

さらに歴史をさかのぼると、cl-nagoya/sup-simcse-ja（教師あり SimCSE の日本語版、base 111M / large 337M）や cl-tohoku/bert-base-japanese が、Ruri v3 以前のデファクトでした。もし過去のシステムを引き継ぐ場合、これらが使われていることも多いので、更新の余地として Ruri v3 を検討する価値があります。

商用モデルで日本語を扱うなら、OpenAI text-embedding-3-large は日本語でも高い性能を出します。Cohere multilingual と併用するケースもあります。ただし価格と精度のバランスを考えると、Ruri v3 をセルフホストする選択肢は 2026 年時点でかなり魅力的です。

選び方の判断フロー

ここまでの情報をもとに、モデル選定の判断フローを整理します。

1. 日本語がメインか、英語がメインか
   • 日本語メイン → Ruri v3（OSS）または OpenAI text-embedding-3-large（商用）
   • 英語メイン → OpenAI text-embedding-3-small が第一候補、精度不足なら Voyage-3-large か Cohere v3
   • 多言語 → bge-m3 または multilingual-e5、または商用 Voyage-3.1-large
2. セルフホスト前提か、API 前提か
   • セルフホスト → Ruri v3、bge-m3、Jina v3、Nomic の順で検討
   • API → OpenAI、Cohere、Voyage、Gemini の順で検討
3. 予算はいくらか
   • 100万文書以上を扱うなら Matryoshka で次元圧縮を必ず検討
   • コスト最優先なら OSS モデルをセルフホスト
   • 精度最優先なら Voyage-3-large か NV-Embed-v2
4. 長文を扱うか
   • 8,192 tokens 以上のドキュメントが多いなら Jina v3 の late chunking か、事前の chunking 戦略を工夫
   • 通常の RAG 用途なら 8,191 tokens で十分

落とし穴 MTEB スコアだけで決めない

もう一度強調しておくと、MTEB や JMTEB のスコアは参考値です。自分のドメインで使ってみて、Recall@10 が 0.80 を超えているか、実際のクエリで意味的に近いドキュメントを拾えているかを、必ず自分で評価してください¹⁹。

「MTEB で 5 点高いモデルに切り替えたが、自分のデータでは 5 点低いモデルの方が使い勝手が良かった」というのはよくある話です。数値は数値、実装は実装、と分けて考える姿勢が大事です。

セクション2のまとめ

2026 年時点のエンベディングモデル選択肢と、選び方の判断フローを整理しました。主要モデルの MTEB スコア、価格、次元数、コンテキスト長を比較すれば、自分のプロジェクトに合った候補が絞れます。日本語なら Ruri v3、英語なら OpenAI text-embedding-3-small が第一候補という理解で、まず動かしてみてください。

次のセクションでは、モデルを選んだあとの実装アーキテクチャ、Vector Database の選定、Chunking 戦略、Reranker の使い方に入ります。

出典

実装アーキテクチャ Vector Database と Chunking と Reranker

モデルを選んだら、次は実装アーキテクチャの設計に入ります。エンベディングを本番運用する場合、単に API を叩いてベクトルを取得するだけでは不十分です。数十万〜数千万件のベクトルを高速に検索するための Vector Database、意味のまとまりを保つ Chunking 戦略、精度をさらに引き上げる Reranker の3点セットが必要になります。

このセクションでは、それぞれの選び方と組み合わせのパターンを整理します。

全体アーキテクチャの流れ

まず、Embedding ベースの検索システムの全体像を描いておきます。データが流れる順序は次の6ステップです。

1. ドキュメントをチャンクに分割する（Chunking）
2. 各チャンクを Embedding モデルに投入してベクトル化する
3. Vector Database にベクトルとメタデータ（元テキスト、URL、日付など）を保存する
4. ユーザーのクエリを同じ Embedding モデルでベクトル化する
5. Vector Database でコサイン類似度検索して top-K（例: 上位20件）を取得する
6. Cross-encoder Reranker で top-K を再スコアリングし、top-5〜10 を LLM に渡す

セクション1で説明したエンベディング理論は、この流れの2、4、5に関わります。3が Vector DB、1が Chunking、6が Reranker です。順に見ていきます。

Vector Database 主要5選の比較

2026 年時点で本番運用に耐える Vector DB は 5〜10 種類あります。中でも代表的な5つを比較します²⁰²¹。

Pinecone は Managed サービスとして「サーバー運用したくない」チームに最適です。オートスケールと SLA が魅力で、エンタープライズ RAG では事実上のデファクトになっています。ただし料金は使用量ベースで、大規模になると急激に高くなります²²。

Qdrant は 2026 年時点で最も注目されている選択肢です。Rust で書かれており、in-memory モードで p50 遅延 4ms 前後を叩き出します²³。フィルタ検索が特に速く、メタデータ絞り込みが必要なリサーチエージェントで有力です。OSS 版を Docker で立ち上げれば無料で使えて、必要になったら Managed 版に移行できます。

Weaviate は Hybrid Search（後述）を最初から標準搭載している点が強みです。BM25 と Vector Search を組み合わせた検索を、追加設定なしで使えます。

Milvus は Billion scale の分散処理が得意で、10 億ベクトルクラスの大規模データセットを扱うプロジェクト向けです。GPU 対応もあり、スケール要求が高いエンタープライズで採用されます。

Chroma は開発とプロトタイプ向けです。Python ネイティブで、pip install chromadb して数行のコードで使えます。プロダクション運用には他の選択肢を検討したほうが良いですが、最初のプロトタイプを回すには最速です。

Chunking 戦略 256〜512 tokens が本番標準

Chunking は、長いドキュメントをそのまま embedding にかけるのではなく、意味のまとまりごとに分割するステップです。ここの設計が甘いと、検索精度が大きく下がります。

2026 年時点で、Recursive Character Splitting で 256〜512 tokens に分割するのが本番の安全ゾーンとされています²⁴²⁵。理由は次の通りです。

短すぎる（100 tokens 以下）と、文脈が失われて意味検索の精度が落ちます。「この段落は何について書かれているか」を判断するには、それなりの情報量が必要です。

長すぎる（1,024 tokens 以上）と、1つのチャンクに複数の話題が混ざって、embedding のベクトルが平均化されてしまいます。結果として「特徴のない中庸なベクトル」ばかりが並び、検索でヒットしにくくなります。

256〜512 tokens は、日本語で言えばおおむね 300〜700 文字程度です。段落を尊重しつつ、意味のまとまりを 1 チャンクに収める粒度として、多くの実装で採用されています。

高度な Chunking 手法

Recursive Character Splitting は最小構成として使えますが、より高度な手法もあります。

• Sentence-based Chunking: 文単位で切って、複数文を1チャンクにまとめる
• Semantic Chunking: 文の意味的な切れ目を LLM や小型モデルで検出して分割
• Late Chunking (Jina v3): 長文をまず全体で embedding してから、あとから領域ごとに分割ベクトルを取り出す

Jina Embeddings v3 の Late Chunking は、長文ドキュメントで意味の境界情報を保ちたい場合に有効です。8,192 tokens までのドキュメントを一度に embedding してから、各チャンクの位置に対応するベクトル領域を取り出す仕組みです²⁶。研究論文や法律文書のような長文を扱うリサーチエージェントで検討する価値があります。

Hybrid Search BM25 + Dense Vector + RRF

2026 年時点で本番運用の最小構成は、Dense Vector 検索単体ではなく、Hybrid Search になっています²⁷²⁸。Hybrid Search は、次の3つを組み合わせたアプローチです。

• BM25 検索: キーワード完全一致の伝統的な検索アルゴリズム
• Dense Vector 検索: エンベディングによる意味検索
• Reciprocal Rank Fusion (RRF): 2つの検索結果を融合するアルゴリズム

なぜハイブリッドにするのかというと、Dense Vector 検索だけでは弱い場面があるからです。たとえば、製品コード（ABC-1234）や固有名詞、レアな技術用語などは、Dense Vector にすると意味的な類似性が薄れて、他の何かに引っ張られることがあります。一方、BM25 はキーワードが完全一致するかどうかで判断するので、こういう「識別子」に強いです。

逆に、BM25 は言い換えや同義語に弱いです。「電気自動車」と「EV」を同じものとして扱えません。Dense Vector 検索なら、この2つのベクトルは近い場所にあるので、うまく拾えます。

Reciprocal Rank Fusion (RRF) は、この2つの結果を融合するアルゴリズムです。それぞれの検索結果を順位（rank）で表現し、順位の逆数を足し合わせて最終スコアを出します。スコアの絶対値ではなく順位ベースなので、BM25 と Dense のスコア範囲が違っても公平に融合できます²⁹。

Weaviate、Vespa、Qdrant、Milvus は Hybrid Search をネイティブ対応しています。Pinecone や Chroma でも実装できますが、コードを自分で書く必要があります。

Cross-encoder Reranker で精度を引き上げる

Hybrid Search で top-20 を取ったあと、さらに精度を引き上げるステップが Cross-encoder Reranker です³⁰³¹。

Bi-encoder（embedding モデル）は、クエリとドキュメントを別々にベクトル化して、あとで類似度を計算します。速いですが、精度は「粗い」のが特徴です。

Cross-encoder は、クエリとドキュメントを1つのペアとして受け取り、Transformer で同時に処理します。両者の相互作用を捉えられるので精度が高いですが、その代わり計算コストが高く、100万件のドキュメントを直接処理するのは現実的ではありません。

そこで、Bi-encoder で top-20〜100 を高速に絞ってから、Cross-encoder で top-5〜10 に絞り込む2段構えが、2026 年の production 標準になっています。研究では、Cross-encoder reranking で検索精度が最大 40% 向上したという結果もあります³²。

代表的な Reranker は次の3つです。

• Cohere Rerank 4 Pro: 業務系（金融/ビジネス）で v3.5 比 +400 ELO の改善³³
• BGE Reranker: OSS で無料、bge-reranker-large が広く使われる
• Jina Reranker: Jina v3 と組み合わせて使うと便利

ただし Reranker が万能ではない点も注意です。Cohere Rerank 3.5 は関数名や変数名など identifier-heavy なクエリで性能が落ちるという指摘があります³⁴。また Reranker は「recall が高くて precision が低い」ときに効きますが、そもそも recall が低い（正解が top-20 に入っていない）状況では改善しません。

実装スタックの構成例

ここまでの要素を組み合わせた、実運用向けのスタック例を示します。

予算重視 セルフホスト構成

• Embedding: Ruri v3 または bge-m3（GPU 1台でホスト）
• Vector DB: Qdrant（Docker で立ち上げ）
• Reranker: bge-reranker-large
• Orchestration: LangChain または LlamaIndex

初期投資は GPU サーバー代のみ、月額運用費は電気代とサーバー費のみ。100万〜1000万件のドキュメントを扱うプロジェクトに向きます。

開発速度重視 商用構成

• Embedding: OpenAI text-embedding-3-small（API）
• Vector DB: Pinecone（Serverless）
• Reranker: Cohere Rerank v4（API）
• Orchestration: LangChain または自社実装

構築は最速です。全部 API 経由なのでサーバー運用が要りません。プロトタイプから本番投入まで最短距離ですが、月額コストは使用量に比例します。

エンタープライズ大規模構成

• Embedding: Voyage-3-large または NV-Embed-v2
• Vector DB: Milvus（Kubernetes 分散）
• Reranker: Cohere Rerank 4 Pro
• Orchestration: 自社実装

10 億ベクトルクラスで、精度と拡張性の両方を求めるケース向けです。

セクション3のまとめ

Vector Database 5 選、Chunking 戦略の 256〜512 tokens 標準、Hybrid Search と Reciprocal Rank Fusion、Cross-encoder Reranker の使い方まで、実装アーキテクチャの中身を整理しました。単に embedding を作るだけでは本番に耐えるシステムにはならず、この3点セット（DB / Chunking / Reranker）が実運用の質を決めます。

次のセクションでは、これらを組み合わせた RAG との違いを整理し、リサーチエージェントで embedding を使う具体的な場面を見ていきます。

出典

RAG との違いと調査エージェントでの応用

エンベディングを学ぶと必ずぶつかる疑問が「RAG と何が違うのか」です。「エンベディングを使えば RAG になる」と誤解している人も多いです。このセクションでは、RAG とエンベディングの関係を整理してから、リサーチエージェントで embedding を使う具体的な場面を見ていきます。

RAG は「検索 + 生成」の総称、エンベディングはその部品

RAG（Retrieval-Augmented Generation、検索拡張生成）は、LLM が回答を生成する前に、外部のドキュメントから関連情報を検索して、その情報をコンテキストに含めるアーキテクチャの総称です。「LLM が持っていない最新情報や社内固有情報を、検索で補って回答させる」仕組みだと捉えてください。

RAG の中身をブロックに分解すると、次のようになります。

• Retrieval（検索）: 質問に関連する情報を外部から取ってくる
• Augmentation（拡張）: 取ってきた情報を LLM のプロンプトに埋め込む
• Generation（生成）: LLM が拡張されたプロンプトを元に回答する

エンベディングは、この Retrieval フェーズで使う技術の1つです。ですから「エンベディングを使えば RAG」ではなく、「エンベディングは RAG の Retrieval を実現する1つの方法」と理解するのが正確です。

Retrieval には他にも選択肢があります。BM25 のようなキーワード検索、SQL データベースへの構造化クエリ、Knowledge Graph へのグラフ探索、Web 検索 API 呼び出し。エンベディングによる意味検索は、その中で最も柔軟な選択肢の1つ、という位置づけです。

Advanced RAG 2026 の主要技法

2024〜2025 年にかけて、単純な RAG（Naive RAG）では回答精度が足りないケースが増えました。そこで登場したのが Advanced RAG の各種テクニックです³⁵³⁶。

代表的なものをいくつか挙げます。

Query Rewriting / HyDE: ユーザーの質問をそのまま検索に使うのではなく、LLM で書き換えたり、仮想的な回答文を先に生成してそれを検索クエリにする手法。検索精度が上がります。

Recursive Retrieval / Multi-hop: 1回の検索で終わらせず、最初の検索結果から次の検索クエリを組み立てて連鎖的に検索する。複雑な質問に対応できます。

Corrective RAG (CRAG): 検索結果を LLM に評価させて、質が低ければ Web 検索にフォールバックする。

Self-RAG / Reflection: LLM が「この情報で十分か」を自己判断し、必要に応じて追加検索する。

Contextual Compression: 検索で取ってきた文書を、そのまま LLM に渡すのではなく、質問に関連する部分だけを抽出して圧縮する。

Cross-encoder Reranking: セクション3で扱った通り、top-K を Cross-encoder で再スコアリングする。

これらの技法は、エンベディングを含む Retrieval の周辺で発展しているものです。エンベディング単体の精度を上げるより、システム全体でどう検索の質を高めるかを考える方向にシフトしているのが 2026 年のトレンドです。

リサーチエージェントでの応用場面

ここからは、AI リサーチエージェントを作る視点で、embedding がどこで役に立つかを整理します。

1. 意味検索による情報収集

最も基本的な使い方が、蓄積した資料や過去の調査ノートから、質問に関連する箇所を意味ベースで拾うことです。「AI エージェントの記憶設計」というクエリで、過去に読んだ論文・記事・メモの中から、関連する部分だけを取り出せます。

キーワード検索だけだと「エージェント」「記憶」の完全一致しか拾えませんが、意味検索なら「長期記憶」「コンテキストウィンドウ管理」「外部メモリ」といった関連概念も一緒に拾えます。

2. 長期記憶の実装

LLM は基本的に「今のプロンプト」しか覚えていません。会話が長くなると、以前の内容を忘れてしまいます。そこで、過去の会話や調査結果を embedding して保存し、必要に応じて呼び出す仕組みが必要になります。

Zep（getzep.com）は、この長期記憶の実装例として参考になります。Zep は3種類の検索を組み合わせています³⁷。

• Cosine Semantic Search: embedding によるコサイン類似度検索
• Okapi BM25 Full-text Search: キーワード検索
• Breadth-first Graph Traversal: ナレッジグラフ上の幅優先探索

この3つを組み合わせて、sub-300ms の遅延で応答します。MemGPT との比較実験では、Deep Memory Retrieval benchmark で 94.8% vs 93.4% と Zep が上回り、応答遅延を 90% 削減したと報告されています³⁸。エージェントの記憶を作るときの1つの参照実装として知っておくと便利です。

3. Vector DB × Knowledge Graph のハイブリッド記憶

2026 年時点で、単純な Vector DB だけでリサーチエージェントの記憶を作るアプローチは、少し古くなりつつあります。理由は、Vector DB は「意味的な近さ」は測れますが、「関係性」を保持しないからです。

たとえば「Anthropic は Claude の開発元」という事実を保存するとき、Vector DB なら「Anthropic」「Claude」「開発元」というテキストを embedding するだけで、両者の関係は数値に埋め込まれるだけで、明示的に保持されません。一方、Knowledge Graph なら「Anthropic —(develops)—> Claude」というエッジとして関係を保持できます。

そこで、Vector DB と Knowledge Graph をハイブリッドで持つアプローチが台頭してきました³⁹⁴⁰。

Cognee の Cognify パイプラインが好例です⁴¹。次の6段階でドキュメントを取り込みます。

1. ドキュメント分類
2. アクセス権限チェック
3. テキストチャンクの抽出
4. LLM で (subject, relation, object) のトリプレット抽出
5. 要約生成
6. Vector Store への embedding 保存 + Knowledge Graph へのエッジ書き込み

Memify という補助機能で、古くなったノードの剪定、利用頻度に応じたエッジの再重み付け、派生的な事実の追加もできます。エージェントの記憶が「育つ」設計になっているわけです。

Graphiti という OSS プロジェクトも、Temporal Knowledge Graph（時間軸付きナレッジグラフ）でエージェント記憶を管理しています⁴²。過去の事実と現在の事実が競合するケースを、時間軸で解決する仕組みです。

4. ドキュメント間の重複検出

リサーチエージェントが Web スクレイピングや API 経由で大量の記事・論文・特許を集めると、重複が問題になります。「同じニュースが違うメディアで転載されている」「同じ論文が違う format で流通している」というケースです。

タイトル完全一致だけでは拾えない類似性を、embedding のコサイン類似度で検出できます。閾値を 0.90 以上に設定して、それ以上の類似度を持つドキュメントは重複候補としてフラグを立てる、という運用が一般的です。

5. クロスモーダル検索

CLIP や BLIP のようなマルチモーダル embedding モデルを使うと、画像と文章を共通のベクトル空間に埋め込めます。「猫の写真」という文章クエリで、猫が写っている画像を検索するといった応用が可能です。

リサーチエージェントで PDF を扱うときにも役立ちます。PDF から抽出した文章と、PDF に含まれる図表を、同じ embedding 空間で扱えば、「このグラフの説明を探す」といったクエリが自然に実装できます。

セマンティック検索の限界も知っておく

エンベディングは強力ですが、万能ではありません。次のような場面では期待通りに動かないことがあります。

識別子ベースのクエリ: 「型番 XYZ-9876」のような固有識別子は、embedding では意味的な近さを持たないので、BM25 と組み合わせないと拾えません。

否定表現: 「猫以外の動物」というクエリを embedding すると、猫のベクトルにも近い場所にあることが多く、正しく除外できません。LLM で否定条件を分離してから検索するなどの工夫が必要です。

時系列の要求: 「2025 年以降の論文」というクエリで、embedding は年号の意味を厳密に扱えません。メタデータでフィルタリングする必要があります。

論理的な関係: 「A の親会社は誰か」という質問で、embedding だけでは正確な答えを出すのが難しいです。ここで Knowledge Graph が効きます。

セクション4のまとめ

エンベディングは RAG の Retrieval を実現する1つの方法であり、RAG の全体像ではないという整理を示しました。リサーチエージェントの視点では、意味検索、長期記憶、ナレッジグラフとの併用、重複検出、クロスモーダル検索という5つの応用場面があり、それぞれに実装のパターンがあります。

次のセクションでは、ここまでの内容を実務に落とし込むときの落とし穴と、既存の選択肢としての Snorbe の位置づけを見ていきます。

出典

落とし穴と Snorbe という別軸の選択肢

ここまでで、エンベディングの理論・モデル選び・実装アーキテクチャ・RAG との関係・リサーチエージェントでの応用を見てきました。最後のセクションでは、実務に落とし込むときの落とし穴と、Vector DB を自作する以外の選択肢として Snorbe を紹介します。

落とし穴 1 MTEB スコアだけで選ぶ

セクション2でも触れましたが、モデル選定でよくある間違いが「MTEB / JMTEB のスコアだけで決める」です。ベンチマークは参考値であり、自分のドメインで再評価する必要があります。

理由はいくつかあります。MTEB は主に英語の一般タスクで測っています。日本語や、法律・医療・特許といった専門ドメインでの性能は保証されません。学術タスクとビジネスタスクで得意なモデルが違うこともあります。それに、モデル提供者が「MTEB で高いスコアを取れるように」チューニングしているケースもあります。

対策としては、自分のプロジェクトのデータから 100〜500 件程度の「正解ペア」（クエリと、それに正しく対応するドキュメント）を作り、複数の embedding モデルで Recall@10 を測る、という地道な評価が必要です。ここを飛ばすと、あとで「モデルを変えたら性能が落ちた」という事故が起きます。

落とし穴 2 コスト設計を後回しにする

もう1つよくある落とし穴が、コスト設計を後回しにしてスケール時に困るケースです。OpenAI text-embedding-3-large を 100 万件のドキュメント（1件平均 1,000 トークン）に適用すると、embedding 生成コストは $130 です。ここまでは大したことないですが、Vector DB のストレージコストがボディブローで効いてきます。

3,072 次元 × 100 万件 = 30 億個の float32 = 約 12GB のベクトルデータ。Pinecone のような Managed サービスで持つと、月額数百〜千ドルの範囲になります。10 億件クラスになると、月額数千〜1万ドルを超えることも珍しくありません。

対策は次のような組み合わせです。

• Matryoshka で次元圧縮する（例: 3,072 → 512、ストレージ 1/6）
• スケール前にセルフホスト（Qdrant + Ruri v3）に切り替える
• Hot / Cold データを分けて、Cold は BM25 だけで済ませる
• 定期的にドキュメントを間引く（古い情報を Knowledge Graph 側に集約）

Vector DB のストレージコストは次元数に比例するので、Matryoshka の効果はダイレクトに効きます。ドキュメント数が増えることが最初から見えているプロジェクトでは、最初から次元数を落として設計するのが賢明です。

落とし穴 3 Cosine Similarity が意味を反映しないケース

意外な落とし穴として、Cosine Similarity が期待通りに意味の近さを反映しないケースがあります。arXiv に “Is Cosine-Similarity of Embeddings Really About Similarity?”（2403.05440）という論文があり、正則化の入れ方によっては cosine similarity が意味の類似性を保証しない、という指摘がされています⁴³。

具体的には、行列因子分解ベースのモデルで学習された embedding では、cosine similarity が「意図した意味の近さ」ではなく、単に統計的な相関を測っているだけの場合があります。特にファインチューニングでバイアスが強く入ったモデルでは、この現象が起きやすいです。

対策としては、コサイン類似度以外の距離指標（ユークリッド距離、内積、Manhattan 距離）も試して、自分のデータで挙動を確認することが重要です。多くの Vector DB は距離指標を選べます。

落とし穴 4 日本語で英語モデルを使う

日本語のドキュメントを扱うのに、英語特化のモデル（Nomic Embed など）を使ってしまうケースは、いまだに見かけます。Nomic Embed のドキュメントには英語特化と明記されていますが、「多言語対応」と勘違いして採用してしまう例が実際にあります。

英語特化モデルを日本語に使うと、多くの場合、単語レベルの類似性は拾えても、文脈の理解が浅くなります。「ですます調」と「である調」の違い、敬語の使い分け、日本語特有の言い回しは、英語モデルではほぼ拾えません。

日本語プロジェクトでは、Ruri v3 か multilingual-e5、または OpenAI text-embedding-3-large を選ぶのが安全です。

自作リサーチエージェントの限界

ここまでの内容を踏まえて、リサーチエージェントを自分で作ろうとすると、次のような課題にぶつかります。

課題1: 記憶の継続性: エンベディングだけで長期記憶を作ると、時間の経過とともに古い情報と新しい情報が混ざり、「今の事実」と「過去の事実」を区別できなくなります。Zep や Graphiti のような Temporal Knowledge Graph を組み合わせる必要があります。

課題2: 専門データベース統合: リサーチエージェントは、Web だけでなく、特許（JPO・EPO・Google Patents）、学術論文（arXiv・PubMed・Semantic Scholar）、企業データ（PitchBook・CB Insights）などの専門DBを横断する必要があります。それぞれ API 仕様が違い、embedding だけで統合できるものではありません。

課題3: クエリの自然言語化: エンベディング検索は「クエリを短めのキーワードにする」と精度が上がる傾向があります。ユーザーが「AI エージェントの記憶実装について詳しく教えて」と自然な日本語で聞いても、そのままだと検索精度が落ちます。クエリ書き換えの工夫が要ります。

課題4: 記憶の育成: ユーザーが何度も同じテーマで質問した場合、システムがそれを学習して「このユーザーはこの分野に興味がある」と理解する仕組みが必要です。単純な Vector DB だけでは実装が重くなります。

これらの課題を自作で解決するには、開発リソースが相当必要です。Zep、Cognee、Graphiti のような OSS を組み合わせる方法もありますが、それでも運用と保守にコストがかかります。

別軸の選択肢としての Snorbe

そこで、既存の選択肢として Snorbe があります。Snorbe は Deskrex.ai が提供するリサーチエージェントで、Vector DB 型ではなく完全記憶型ナレッジグラフをベースに設計されています⁴⁴。

Snorbe の設計思想は、自作アプローチとは別軸です。

完全記憶型ナレッジグラフ: 過去のすべての調査結果がグラフとして連結され、時間軸を持って保持されます。「先週調べた AI エージェントの記憶実装」と「今日調べたコンテキスト管理」が自動的に関連付けられ、記憶が育つ設計です。

専門データベース 6 種統合: JPO（日本特許）、EPO（欧州特許）、Google Patents、arXiv、PubMed、Semantic Scholar を横断検索できます。特許・学術・技術ブログを1つのエージェントで扱えるので、リサーチが分断されません。

自然な日本語クエリ: エンベディング検索のようにクエリを短くする必要がなく、「AI エージェントの記憶実装で、Vector DB と Knowledge Graph をハイブリッドで持つアプローチについて、Zep や Cognee の実装例を含めて調べて」といった長文クエリをそのまま投げられます。エージェント側でツール選択と検索の分解をやってくれます。

ワークスペースへの蓄積: 調査結果はワークスペースにグラフとして残り、次に同じテーマで質問したときに、過去の記憶を活用してより深い回答が返ってきます。エンベディングを自分で管理する必要がありません。

自作の Vector DB 型アプローチと Snorbe を比較すると、次のような住み分けになります。

• Vector DB 自作: 特定用途に最適化したい、社内固有データを完全にコントロールしたい、コスト最小化が最優先
• Snorbe: リサーチを今日から始めたい、専門DB統合を自分で作らずに済ませたい、記憶の継続性を担保したい

今日から試せる反復ループ

Snorbe を試す最短ステップは次のようになります。

1. Snorbe のワークスペースを作る（https://lp.deskrex.ai/）
2. 調べたいテーマを自然な日本語で投げる（「AI エージェントの記憶実装のトレンドを、Zep と Cognee の比較を含めて教えて」など）
3. 返ってきたレポートを読みながら、追加で気になった点を続けて質問する
4. 記憶が育つので、翌日に同じテーマで質問すると、より深い回答が返ってくる
5. 週次で振り返り、記憶グラフを確認して知識の広がりを把握する

このループを 1 週間回すだけで、自作 Vector DB を組む場合の 1〜2 ヶ月分の開発ステップを飛ばして、リサーチの実務に集中できます。

まとめ 記事全体の要点

セクション1〜5 で扱った内容を振り返ります。

• エンベディングは意味を高次元ベクトルに変換する技術で、コサイン類似度で近さを測る
• 2026 年の主要モデルは OpenAI text-embedding-3、Cohere、Voyage、bge-m3、Jina v3、Nomic、日本語なら Ruri v3
• 実装アーキテクチャの3点セットは Vector DB、Chunking 戦略、Cross-encoder Reranker
• RAG は「検索 + 生成」の総称で、エンベディングは Retrieval の1つの選択肢
• リサーチエージェントで使うなら Vector DB × Knowledge Graph のハイブリッドが 2026 年のトレンド
• 落とし穴は MTEB スコア盲信、コスト設計後回し、Cosine Similarity の意味、日本語で英語モデル
• 自作の限界を感じたら、Snorbe のような完全記憶型ナレッジグラフを別軸の選択肢として検討する

エンベディングは「AI 調査エージェントの心臓部」であり、理論と実装の両方を押さえておくことが、これからのエンジニアには必須です。ぜひ自分のプロジェクトで試して、数値と体感の両方で理解を深めてください。

出典

よくある質問

Q1. エンベディングと Word2Vec の違いは何ですか

エンベディングは、テキストや画像を高次元のベクトル空間に変換する技術の総称です。Word2Vec は 2013 年頃に登場した初期のエンベディング手法で、主に単語単位でベクトル化するものでした。現代のエンベディングモデル（OpenAI text-embedding-3、Cohere Embed v3、Ruri v3 など）は Transformer ベースで、文単位・段落単位の意味を扱えるように進化しています。Word2Vec は単語埋め込みの入門として理解する価値がありますが、実装では 2024 年以降の Transformer 系モデルを使うのが標準です。

Q2. text-embedding-3-small と 3-large、どちらを選ぶべきですか

まずは text-embedding-3-small で始めるのが安全です。1,536次元、$0.02/1M tokens で、多くの RAG プロトタイプや社内ナレッジベースでは十分な精度が出ます。精度が足りないと判断した時点で 3-large（3,072次元、$0.13/1M tokens）に切り替える段階的アプローチをお勧めします。両者とも Matryoshka 対応で、dimensions パラメータで次元を後から削減できるので、コスト設計に柔軟性があります。

Q3. 日本語のエンベディングモデルは何が最強ですか

2026 年 7 月時点では、cl-nagoya の Ruri v3 が JMTEB スコア 74.5〜77.2 で最有力です。ModernBERT-Ja ベースで 8,192 tokens の長いコンテキストに対応し、パラメータ数は 30M〜310M まで選べます。商用モデルなら OpenAI text-embedding-3-large が日本語でも高い性能を出します。intfloat/multilingual-e5 は多言語対応の OSS 候補で、Ruri v3 より少し劣るものの、100 言語以上をカバーする点で強みがあります。

Q4. エンベディングと RAG は何が違うのですか

RAG（Retrieval-Augmented Generation）は「検索 + 生成」の全体アーキテクチャの総称で、エンベディングはその中の検索フェーズを実現する1つの方法です。検索の他の選択肢には、BM25 のキーワード検索、SQL への構造化クエリ、Knowledge Graph へのグラフ探索、Web 検索 API 呼び出しがあります。「エンベディングを使えば RAG になる」というのは誤解で、正確には「エンベディングは RAG の Retrieval を実装する手段の1つ」と理解してください。

Q5. Vector Database は結局どれを選べばいいですか

用途で選び分けます。Managed でゼロオペレーションが最優先なら Pinecone、遅延最小化と OSS 併用なら Qdrant、Hybrid Search を標準で使いたいなら Weaviate、10 億ベクトル規模なら Milvus、開発とプロトタイプなら Chroma です。多くのプロジェクトでは Qdrant で始めて必要に応じて Managed 版に移行するのがコスパ良好です。

Q6. Cross-encoder Reranker は本当に必要ですか

本番運用では強く推奨します。Bi-encoder（embedding モデル）で top-20〜100 を高速に絞り、Cross-encoder（Cohere Rerank、bge-reranker-large、Jina Reranker など）で top-5〜10 に絞る2段構えが 2026 年の production 標準です。研究では Cross-encoder reranking で検索精度が最大 40% 向上したという報告もあり、コストに見合う投資です。ただし、そもそも recall が低い（正解が top-20 に入っていない）状況では reranker では改善しないので、その場合は embedding モデルや chunking を見直してください。

調査手法について

こちらの記事はグラフAIリサーチプラットフォームのSnorbeを使って作られています。Snorbeは研究開発・新規事業向けの調査テーマに応じた幅広い項目のオートリサーチや、ナレッジグラフの構築、構造化レポートの生成ができるAIリサーチツールです。

Screenshot

調査したいテーマを入力するだけで、AIが深堀りすべき観点や広げるべき調査項目をレコメンドしながら、自動でリサーチを進めます。収集した情報はナレッジグラフとして蓄積され、未調査領域（ホワイトスペース）を可視化しながら調査の網羅性を高めていけます。

また、観点マトリクスを30秒・構造化レポートを10分で自動生成する機能があり、出典付きのレポートをMarkdown/PDF形式でエクスポートできます。調査の元データも保存されるため、ファクトチェックや社内共有も容易です。

ご利用をご希望の方は、こちらよりお申し込みください。

また、グラフAIを活用した社内ナレッジ管理や、研究開発・新規事業のリサーチ支援、セルフホスト導入のご相談も受け付けています。お困りの方はお気軽にご連絡ください。

Deskrex.ai

DeskRexは市場調査のテーマに応じた幅広い項目のオートリサーチや、レポート生成ができるAIデスクリサーチツールです。https://lp.deskrex.ai / 新規事業に役立つ生成AIの情報を発信するメディアも運営しています。https://media.deskrex.ai

lp.deskrex.ai/