「RAGを導入したけど、全然ヒットしない」──そんな相談を受けて現場を見たとき、原因は大抵埋め込みモデルの選択ミスだった。

RAGの構成要素はLLM・ベクトルDB・埋め込みモデルの3つだが、検索精度を左右するのは圧倒的に埋め込みモデルだ。どんなに優秀なLLMを使っても、関連文書を正しく引っ張ってこられなければ意味がない。にもかかわらず、埋め込みモデルは「なんとなく有名なやつ」で選ばれるケースが多い。

この記事では、2025年秋から2026年春にかけて実際の中小企業案件（社員30〜80名、日本語ドキュメント中心）で4つの埋め込みモデルを試した記録を書く。技術スペックの比較だけでなく、「なぜそのモデルをやめたのか」という判断の経緯も含めて残す。

試した4つの埋め込みモデル

比較したのは以下の4モデル。選定基準は「実際にプロダクトで使われている頻度」「日本語対応」「API/OSS両方のカバレッジ」の3点。

1. text-embedding-3-small / text-embedding-3-large（OpenAI）

最も導入事例が多い。APIキーさえあればすぐ使える手軽さが強み。料金は small が $0.02/100万トークン、large が $0.13/100万トークン。日本語も一応通るが、後述するように純日本語タスクでは精度に限界がある。

2. multilingual-e5-large（intfloat）

2023〜2024年ごろ、日本語RAGのデファクトスタンダードだったオープンソースモデル。「日本語ならこれ」とZennやQiitaでよく紹介されていたため、最初に試した。セルフホストが必要で、起動時のVRAM消費は約3GB。

3. BGE-M3（BAAI）

中国のBAIが開発したオープンソースモデル（MITライセンス）。中国語・英語・日本語の3言語対応で、MTEB（Massive Text Embedding Benchmark）での性能は商用APIに匹敵する。セルフホスト時の運用コストが魅力だが、初期構築に時間がかかる。

4. ruri-v3（名古屋大学）

2025年にリリースされた日本語特化の埋め込みモデル。JMTEBベンチマークの平均スコアは77.2で、それまでのSOTA（75.5）を大きく上回った。特に ruri-v3-30m はパラメータ数わずか37Mながら、OpenAIの text-embedding-3-large を日本語タスクで超えるというかなり強い結果を出している。

実際に比較してわかったこと

評価は同一のドキュメントセット（社内規程・FAQ・議事録など約2,000件）に対して、実際の社員が使うような50問のクエリで検索精度（Top-5 Recall）を測定した。

モデル	Top-5 Recall	API費用(1M tokens)	セルフホスト	日本語特化
text-embedding-3-small	71%	$0.02	不要	×
text-embedding-3-large	78%	$0.13	不要	×
multilingual-e5-large	81%	無料（自費）	必要（VRAM 3GB+）	△
BGE-M3	84%	無料（自費）	必要（VRAM 6GB+）	△
ruri-v3-30m	88%	無料（自費）	必要（VRAM 1.5GB程度）	◎

数字だけ見るとruri-v3の圧勝だが、実際の選定はそう単純ではなかった。

「なぜやめたか」の記録

text-embedding-3-small をやめた理由

精度が思ったより低かった。特に日本語の敬語・略語・社内固有名詞の検索でミスが目立った。コストは安いが、検索がハズれると社員が「AIは使えない」という評価を固めてしまうリスクが高い。精度よりコストを優先する段階ではまだないと判断した。

multilingual-e5-large をやめた理由

2024年の時点では最有力候補だったが、ruri-v3の登場で相対的に見劣りするようになった。精度は十分だが、「ruri-v3がパラメータ1/5で上回る」という事実を前にするとモデルを維持する理由が薄い。同じセルフホストコストを払うなら、より軽くて精度が高いモデルを選ぶ。

BGE-M3 を本番採用しなかった理由

性能は非常に良い。しかし中小企業案件ではインフラ保守コストが問題になった。VRAM 6GB以上のGPUインスタンスを常時起動する費用（AWS g5.xlarge で約$1.01/時間）と、モデル更新・監視の運用工数を考えると、社内にMLエンジニアがいない環境では持続しにくい。大量ドキュメントを扱うプロジェクト（月1,000万トークン超）では逆転するが、今回の規模（月10〜50万トークン）ではAPIコスト優位の方が大きい。

最終選定：ruri-v3-30m + APIフォールバック構成

最終的に選んだのは ruri-v3-30m のセルフホストだった。理由は3つ。

精度が一番高い：日本語タスクでのTop-5 Recallが88%は、他モデルと比較して明確に優位
軽量で保守しやすい：37Mパラメータなので、CPU推論でも許容範囲内の速度が出る。GPUなしでの検証環境構築が可能
コストが読める：APIに依存しないため、ドキュメント件数が増えてもAPI費用が跳ね上がらない

ただし、初期構築・モデルアップデート対応の工数を最小化するため、本番インフラは軽量Dockerコンテナで構成し、モデルのバージョン固定と定期ヘルスチェックをCI/CDに組み込んだ。障害時のフォールバックとして text-embedding-3-small のAPIを用意しておくことで、「モデルサーバーが落ちてもRAGが止まらない」状態にした。

# フォールバック構成の概念コード
def get_embedding(text: str) -> list[float]:
    try:
        return local_ruri_embed(text)  # ruri-v3-30m (primary)
    except Exception:
        return openai_embed(text)  # text-embedding-3-small (fallback)

中小企業が埋め込みモデルを選ぶときの判断軸

今回の経験を踏まえると、中小企業がRAG埋め込みモデルを選ぶ際の判断軸は以下の3点に集約される。

1. 月間トークン数を先に試算する

月10万トークン未満ならAPIが圧倒的に楽。50万を超えるとセルフホストを検討するラインに入ってくる。100万を超えたら積極的にセルフホストを検討すべきだ。

2. 社内のML保守体制を正直に評価する

「BGE-M3が最高性能だから」とセルフホストを選んでも、モデルが落ちたときに対応できる人がいなければ事業リスクになる。保守工数ゼロを望むならAPIオンリーが正解。

3. まず text-embedding-3-small で動かして、精度不足を確認してから乗り換える

最初からruri-v3を導入するのはオーバーエンジニアリングになる可能性がある。small で十分な場合も多いし、精度不足が実際に確認されてから乗り換えた方が判断根拠が明確になる。

まとめ

RAGの埋め込みモデル選定に「絶対正解」はない。しかし、選定プロセスを記録しておくことには大きな価値がある。なぜそのモデルを選んだか、なぜ他をやめたかが残っていれば、半年後にモデルを乗り換えるときのコストが劇的に下がる。

今回の結論は「日本語中心なら ruri-v3-30m、セルフホスト難しければ text-embedding-3-large」だが、これは2026年5月時点の判断だ。モデルの進化は早い。判断の記録と定期的な再評価の仕組みを作っておくことが、長く使えるRAGシステムの前提条件になる。

#ruri-v3実装

中小企業のRAG実装：埋め込みモデル比較と最終選定の記録