前回の記事（EmbeddingGemma 2とGemini Embedding 2の比較）公開後、OpenRouterにおける月間ランキング の利用統計を確認しました。首位のOpenAI text-embedding-3-small は月間約6億6,000万リクエストに達しており、2位のQwen3 Embedding 8B（約2億3,100万）や3位のGemini Embedding 2（約1億2,700万）を大きく突き放しています。
もちろん、OpenRouterの数字が開発者コミュニティ全体のすべてを代表しているわけではありません。しかし、OpenAIの公式ドキュメントで今も主力として扱われており、LlamaIndexなどのフレームワークでも新規プロジェクトの初期設定として推奨されていることからも、現場で根強く使われ続けている実態が伺えます。
ただ、これだけ広く普及しているからといって、あらゆる検索タスクで最善の選択肢であるとは限りません。特に日本語やベトナム語などの多言語データを扱うRAG（Retrieval-Augmented Generation）システムでは、本当にこのままで良いのか立ち止まって検証する価値があります。
現場での実体験：リランカーでも救えなかった検索漏れ
数か月前、社内のチャットボット開発で厄介な不具合に直面しました。社内Wikiに答えがそのまま書かれている質問であるにもかかわらず、ボットが「十分な情報がありません」と返答したり、事実と異なる内容（ハルシネーション）を答えたりする報告が相次いだのです。
そのシステムのRAGパイプラインは、一般的な2段階検索の構成をとっていました：
- 第1段階（ベクトル検索）：Embeddingを用いてデータベースから上位50件の候補チャンクを取得
- 第2段階（リランキング）：クロスエンコーダー（Cross-encoder）を用いて50件を再評価し、上位5〜10件をLLMに渡す
検索ログを詳細に調査したところ、原因はすぐに判明しました。ベトナム語や日本語のクエリにおいて、text-embedding-3-small は正解のドキュメントの1つを60位前後に配置し、関連する他のドキュメントは100位圏外にまで沈んでいたのです。
リランカーは、手元に届いた候補の中でしか順位を入れ替えることができません。第1段階のベクトル検索で上位50件に入らなければ、リランカーは正解ドキュメントを評価することすらできません。LLMには文脈として不適切なノイズだけが渡されるため、プロンプトをどれだけ工夫しても、モデルのパラメーターを調整しても、そもそも手元にない情報を答えることは不可能です。
この検証では、EmbeddingモデルをGemini Embedding 2に変更した結果、正解ドキュメントが第1段階の上位5〜10位以内へ安定して浮上し、不具合は解消しました。
もちろん、この切り替えには社内ドキュメントをGeminiのベクトル空間向けにすべて再埋め込み（Re-indexing）する必要がありました。異なるモデル間でクエリベクトルと保存済みベクトルを照合することは、数学的な空間が全く異なるため不可能です。
また、Embeddingモデルを入れ替えることだけが唯一の解決策ではありません。BM25によるキーワード検索を組み合わせたハイブリッド検索（Hybrid Search）を導入することも、完全一致の単語を拾い上げる有効なアプローチです。ただし、ユーザーの言い回しとドキュメントの記述が異なる場合には、やはりEmbeddingモデル自体の意味理解力が重要になってきます。
なぜtext-embedding-3-smallはこれほど定着しているのか？
性能面で優れた後発モデルが登場する中、なぜ text-embedding-3-small はここまで広く使われ続けているのでしょうか。技術的な優位性というより、エコシステムの持つ慣性が主な要因です。
1. フレームワークの初期設定とサンプルコードの存在
多くのRAG解説記事、LangChainのチュートリアル、GitHubのスターターキットでは、デフォルトのモデルとして text-embedding-3-small が指定されています。開発者がプロトタイプを立ち上げる際、用意されているサンプルコードをそのまま使うのが最も自然な流れです。
from langchain_openai import OpenAIEmbeddings
# 一度書くと見直されにくい初期設定
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
プロトタイプが実用フェーズや本番環境へ移行しても、初期検証で表面上動いていた基盤コンポーネントをあえて差し替えるケースは多くありません。公式ドキュメントに記載された初期設定が、そのまま本番運用のスタンダードになっていきます。
2. 英語のドキュメント検索であれば十分実用的
英語のドキュメント検索において、text-embedding-3-small は多くの場面で破綻なく機能します。英語タスクを集めたベンチマーク（MTEB）でも62.3%を記録しており、リランカーを併用していれば、致命的な検索ミスとして顕在化しにくいのが実情です。
世の中に流通している技術デモの多くが英語を前提に組まれているため、他言語を本格的に流し込むまで弱点に気づきにくいという背景もあります。
3. ベクトルインデックスの再構築コスト（Re-indexing Cost）
移行を躊躇させる最大の現実的な要因は、インデックス再構築にかかる手間とリスクです。
Pinecone、Qdrant、pgvectorなどのベクトルデータベース自体が特定のモデルに縛り付けているわけではありません。新しいモデルを採用する場合、保存されているドキュメントのベクトルをすべて再生成し、インデックスを作り直す必要があります。
すでに数百万チャンクのデータを運用している企業にとって、全ドキュメントの再埋め込み、次元設定の変更、類似度閾値の再調整は、それなりの計算コストとエンジニアの工数を伴います。結果として、「動いているなら触らない」と後回しにされがちです。
4. 気にする気も起きないほどの低価格
100万トークンあたり0.02ドルという価格は、月々のクラウド請求書の中でもほぼ誤差の範囲に収まります。インフラ費用が月額数十円から数百円程度で済むものに対して、わざわざ工数をかけて最適化しようという動機は、経営面からもエンジニアの視点からも生まれにくいと言えます。
多言語データにおける見落としがちなポイント
text-embedding-3-small が単なる割り切りを超えて実際の課題になりやすいのが、多言語環境での検索です。
OpenAIの発表時、英語ベンチマーク（MTEB）では62.3%だったのに対し、多言語検索ベンチマーク（MIRACL）では44.0%と報告されています。これらは評価設計が異なる別々のベンチマークであるため、数値の差をそのまま性能低下幅として比較することはできませんが、多言語検索が異なる難しさを持っていることを示しています。
多言語検索の品質は、単に単語をどう分割するか（トークナイズ）だけでなく、学習データセットの言語比率や、異なる言語間で概念がどれだけ綺麗にマッピングされているかによって大きく左右されます。推測で判断するのではなく、自社のアプリケーションが実際に扱う言語とクエリを使って直接テストしてみることが確実です。
コーパス全体を埋め込む場合のコスト感
価格の安さから text-embedding-3-small を選び続けるチームも少なくありません。標準的なテキスト入力におけるAPI費用の比較は以下のようになります：
| 埋め込み対象トークン数 | text-embedding-3-small ($0.02 / 1M) | Gemini Embedding 2 ($0.20 / 1M) |
|---|---|---|
| 1,000万トークン | $0.20 (約30円) | $2.00 (約300円) |
| 1億トークン | $2.00 (約300円) | $20.00 (約3,000円) |
| 10億トークン | $20.00 (約3,000円) | $200.00 (約30,000円) |
(標準的なテキスト入力API料金。大量利用割引やキャッシュ適用前を想定。)
単価が高いモデルが常に優れているわけではありません。しかし、システム全体の運用費の中でEmbeddingの費用がごく一部であるなら、取得できる検索品質の向上に対して十分に見合う投資になる場合があります。
RAGパイプライン全体のコスト構造において、最も大きな割合を占めるのは後段のLLM（GPT、Claude、Geminiモデルなど）の推論費用です。検索で無関係なドキュメントを拾ってしまうと、LLMは無駄な文脈を読み込むためにフルプライスのトークンを消費し、結果として誤答やハルシネーションを出してしまいます。
設計時の実践的なアドバイス
text-embedding-3-small を使い続けるべきか、別モデルへ移行すべきかは、扱うデータと要件によって判断が分かれます：
現状維持で問題ないケース
- 対象ドキュメントが完全に英語であり、社内マニュアルなどの平易な文章が中心である
- すでに精度の高いリランカーやBM25ハイブリッド検索が機能しており、日常的な検索パターンを満たせている
- すでに数百万件規模のインデックスがあり、現時点で移行検証を行う開発リソースが割けない
移行の検討を推奨するケース
- 日本語やベトナム語など、非英語データを日常的に扱うプロダクトである場合。「英語で問題ないから大丈夫だろう」と過信せず、対象言語での検索精度を個別に確認することをおすすめします
- 新規プロジェクトを立ち上げる場合。最初から古い設定に合わせる理由は薄く、Gemini Embedding 2やオープンウェイトのEmbeddingGemma 2など、多言語対応力の高い選択肢を初期候補に入れる方が合理的です
- ユーザーから「回答が抜けている」「検索がヒットしない」といった不満が上がっている場合。プロンプトを書き換える前に、まず1段目のベクトル検索で正解が何位に拾えているかを確認してみる価値があります
text-embedding-3-small が広く使われているのには、安さ、手軽さ、知名度という十分な理由があります。しかし、「みんなが使っているから」という理由だけで、自社のRAGシステムにとって最良のモデルであるとは限りません。