埋め込みモデル（Embedding）の選び方｜日本語品質とコストのバランス

AIを活用した社内検索システム（RAG）や推薦エンジンを構築する際、大規模言語モデル（LLM）の選定以上に重要となるのが埋め込みモデル（Embedding Model）の選択です。テキストをベクトル（数値の羅列）に変換するこのモデルの性能が、検索の「賢さ」を決定づけます。

特に日本語のコンテキストでは、英語圏で開発されたモデルが必ずしも期待通りの精度を発揮するとは限りません。本記事では、実務担当者が直面する「精度・コスト・運用負荷」のトレードオフを解消するため、主要な埋め込みモデルの比較と選定基準を具体的に解説します。

埋め込みモデル（Embedding）とは何か：RAG精度を左右する「心臓部」

埋め込みモデルとは、文章や単語を多次元のベクトル空間上の座標に変換する技術です。似た意味を持つ文章同士はベクトル空間上で近い位置に配置されます。この性質を利用することで、「キーワードの完全一致」ではなく「文脈や意味の近さ」による検索（セマンティック検索）が可能になります。

テキストを数値化する仕組みと検索精度の関係

例えば、「法務部への連絡先」というクエリに対し、従来の検索では「法務部」という言葉が含まれる文書しかヒットしません。しかし、優れた埋め込みモデルを使えば「コンプライアンス相談窓口」や「契約書の確認依頼」といった、言葉は違えど意味が近い文書を抽出できます。この抽出精度が低いと、その後のLLMによる回答生成がどれほど高性能でも、最終的なアウトプットは不正確なものになります。

なぜ「LLM本体」より「埋め込みモデル」の選定が重要なのか

RAG（Retrieval-Augmented Generation）において、回答の根拠となる情報を探してくるのが埋め込みモデルの役割です。
一度ベクトル化したデータは、モデルを変更するたびにすべてのデータを再ベクトル化（リインデックス）しなければなりません。数万件、数十万件のドキュメントを抱えるプロジェクトにおいて、モデルの選定ミスは多大な移行コストを生みます。そのため、最初の段階でコストと精度のバランスを見極める必要があります。

日本語対応埋め込みモデルの主要選択肢と比較

現在、実務で選択肢に上がる主要なモデルは、大きく分けて「商用API」と「オープンソース（OSS）」の2系統があります。

OpenAI text-embedding-3-small / large

現在、最もスタンダードな選択肢です。text-embedding-3-smallは極めて安価でありながら、多くのタスクで十分な性能を発揮します。一方、largeは最大3,072次元のベクトルを出力でき、より複雑な文脈把握が可能です。また、出力次元数を任意に削減できる「Matryoshka Representation Learning」という機能を備えており、精度を維持しつつベクトルDBの保存コストを抑える工夫がなされています。

Google text-embedding-004 (Vertex AI)

Google Cloudが提供する最新モデルです。日本語を含む多言語性能が高く、特にGoogle検索で培われた技術が反映されているため、日本語特有の揺らぎに強い傾向があります。256次元から768次元といった柔軟な次元設定が可能です。

Cohere embed-multilingual-v3.0

検索特化型のモデルとして評価が高いのがCohereです。特に「検索クエリ」と「ドキュメント」の性質の違いを理解してベクトル化する能力に長けています。実務上、短い検索文から長いマニュアルを探し出すRAG構成において、非常に高いリコール（再現率）を叩き出すことが多いモデルです。

日本語特化型OSS（multilingual-e5, st-sb-bert-jp 等）

データを外部のAPIに送信できない金融や医療などの現場では、OSSモデルを自前でホストする選択肢があります。特にintfloat/multilingual-e5-largeは、日本語を含む多言語ベンチマークで高いスコアを記録しており、GPUリソースを確保できるのであれば非常に有力な選択肢となります。

【比較表】日本語性能・次元数・コストの徹底分析

各モデルの主要なスペックを以下の表にまとめました。料金は2024年時点の各公式サイトの情報に基づきます（100万トークンあたりの概算）。

※コストの詳細については、各社の公式料金ページ（OpenAI, Google Cloud, Cohere）を必ずご確認ください。

実務における埋め込みモデル選定の5つの判断基準

1. 日本語のセマンティック検索（意味検索）の精度

単なるキーワードマッチングを超えた、日本語特有の「敬語」「略称」「業界用語」への対応力が必要です。多くのケースでは text-embedding-3-large または embed-multilingual-v3.0 を選択すれば、日本語でも高い精度が得られます。精度が足りない場合は、モデル自体の変更よりも、後述する「リランク（再順位付け）」の導入が効果的です。

2. ベクトル次元数とインフラコストのトレードオフ

次元数が増えるほど（例：1,536 → 3,072）、より細かい意味の違いを保持できますが、ベクトルデータベース（Pinecone, Weaviate, BigQuery Vector Search等）のストレージ容量と計算負荷が増大します。特に数百万件規模のデータを扱う場合、次元数を半分にすることでインフラコストを大幅に削減できるため、小～中規模のプロジェクトなら small モデルの 768次元程度でも十分なケースが多いです。

大規模なデータ基盤を構築し、他のマーケティングデータ等と連携させる場合は、以下の記事のようなデータアーキテクチャの視点が不可欠です。

高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ

3. 最大入力トークン数とチャンク分割の戦略

埋め込みモデルには、一度に処理できる「最大トークン数」の制限があります。例えば、OpenAIは8,191トークンと大きいですが、Cohereや多くのOSSモデルは512トークン程度です。長大なPDF文書を扱う場合、文書を小さな「チャンク（塊）」に分割する必要があります。この分割ロジック（スライディングウィンドウ等）が、モデルの制限と合致しているかを確認してください。

4. セキュリティとデータプライバシーの要件

企業の機密情報を扱う場合、パブリックなAPIの利用が制限されることがあります。Azure OpenAI ServiceやAWS Bedrockを介してモデルを利用すれば、入力データがモデルの学習に利用されないことが保証されています。これらマネージドサービスの利用は、社内規定をクリアする上で最も現実的な解となります。

一方で、バックオフィス部門での利用など、より厳格なアカウント管理が必要な場合は、以下のソリューションによる自動化が有効です。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

5. 運用形態（フルマネージドAPIか自前構築か）

実務においては「自前でGPUサーバーを立ててOSSを運用するコスト」と「API課金」を比較する必要があります。通常、月間のリクエスト数が数千万回を超えない限り、APIを利用したほうがエンジニアの工数を含めた総所有コスト（TCO）は低くなります。

埋め込みモデルの実装・運用のステップバイステップ

適切なモデルを選んだ後、実運用に乗せるための具体的な手順を解説します。

ステップ1：データソースのクレンジングと構造化

不要な改行、HTMLタグ、重複するヘッダー・フッターを削除します。ゴミが多いデータはベクトルの「ノイズ」となり、検索精度を著しく下げます。

ステップ2：適切なチャンクサイズの決定

情報をどの程度の長さで区切るか（例：500文字ごと、あるいは段落ごと）を決めます。

• 小さすぎるチャンク: 前後の文脈が失われ、意味が不十分になる。
• 大きすぎるチャンク: 複数のトピックが混ざり、ベクトルの「意味の焦点」がぼやける。

一般的には、300～800トークン程度に設定し、前後を100トークンほどオーバーラップさせる手法が推奨されます。

ステップ3：モデルの呼び出しとベクトルDBへの格納

Python等のSDKを用いて、テキストをモデルに投げ、返ってきた浮動小数点数の配列（ベクトル）をデータベースに格納します。
この際、後で元データを確認できるよう、メタデータ（ファイル名、ページ番号、URL等）も一緒に格納することが鉄則です。

よくあるエラーと対処法

• Rate Limit Error (429): 大量のデータを一括でベクトル化しようとすると、APIの制限に接触します。指数バックオフアルゴリズムを用いたリトライ処理を実装するか、バッチ処理APIを利用してください。
• Dimension Mismatch: モデルを更新した際、既存のベクトルDBの次元数と合わなくなるエラーです。この場合、DBのインデックスを作り直す必要があります。

日本語RAGにおけるコスト最適化の処方箋

精度を維持したまま運用コストを削減するには、以下のテクニックが有効です。

二段階検索（粗い検索と精緻なリランク）の導入

すべての検索を高性能な（＝高価な）モデルで行うのではなく、まず安価な text-embedding-3-small や軽量なOSSモデルで上位50件程度を絞り込みます。その後、Cohereの Rerank モデルなどを用いて、その50件だけを「本当にクエリと関連が高い順」に並び替える手法です。これにより、APIコストを抑えつつ、トップランクの精度を大幅に向上させることが可能です。

こうした最適化は、経理や労務といった、データの正確性が1円単位で求められる領域での業務効率化にも通じます。

楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

キャッシュ戦略によるAPI費用の削減

同じようなクエリが頻発する場合（社内Wikiのトップ画面など）、クエリのベクトル化結果や検索結果をRedisなどのインメモリDBにキャッシュします。これにより、API呼び出し回数を物理的に減らすことができます。

まとめ：ビジネス要件別・推奨モデルの最終結論

最後に、状況別の推奨モデルをまとめます。

• 「まずは最短で、安価に始めたい」

  → OpenAI text-embedding-3-small。次元数を512に絞って運用を開始するのが最もコスト効率が良いです。

• 「社内の技術文書やマニュアルを、可能な限り高精度に検索したい」

  → Cohere embed-multilingual-v3.0。検索に特化した学習がなされており、日本語の精度も極めて高いです。

• 「Google Cloud環境で統合管理したい、かつ安定性が欲しい」

  → Google text-embedding-004。Vertex AIの強固な基盤と、柔軟な次元設定が魅力です。

• 「データは1バイトも外に出せない」

  → OSS multilingual-e5-large。自前でGPUインスタンスを立て、セキュアな閉域網で運用します。

埋め込みモデルの選定は、AIプロジェクトの長期的な成否を分けます。単なる流行ではなく、自社のデータ量、予算、そして何より「日本語の検索体験にどこまでこだわるか」という基準に照らして、最適な一択を選び取ってください。