RAG（検索拡張生成）では、社内文書を検索して関連する情報を取り出し、その内容をもとにAIが回答する。このとき「質問に近い文書を探す」役割を担うのが埋め込み（embedding）モデルである。検索の精度は、生成の前段にあるこの埋め込みの良し悪しに大きく左右される。どんなに高性能な生成AIを使っても、検索で正しい文書を引けなければ、的外れな回答になる。
本記事は、RAGに使う埋め込みモデルの選び方を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。埋め込みモデルというと技術的に聞こえるが、発注者として「日本語に強いか」「自社の用語を扱えるか」「コストと精度のどちらを優先するか」を整理できれば、開発会社と論点を共有できる。
結論：日本語対応・コスト・後からの変更しにくさを軸に選ぶ
埋め込みモデルは、種類によって精度・コスト・運用の負担が変わる。万能な正解はなく、自社の文書や要件に合うものを選ぶことになる。GXOが埋め込みモデルの選定で重視するのは、次の3点である。
- 自社の文書（日本語・専門用語・社内固有語）をきちんと扱えるか
- 商用API型かOSS自社ホスト型か、コストと運用の負担で見極める
- 後からモデルを変えると再インデックスが必要になる点を、最初から見込む
埋め込みモデルは一度決めると差し替えに手間がかかる。最初に論点を押さえて選ぶことが、後の作り直しを避けることにつながる。検索基盤全体の考え方は社内ナレッジ活用のためのRAG・AI検索導入ガイドでも扱っている。
埋め込みとは何か
埋め込みとは、文章を「数字の並び（ベクトル）」に変換することである。意味の近い文章どうしは、変換後のベクトルも近い位置になる。これを使うと、質問文と社内文書をそれぞれベクトルにして、「意味的に近い文書」を計算で探せる。
従来のキーワード検索は、同じ単語が含まれているかどうかで探す。これに対して埋め込みによる検索（ベクトル検索）は、言い回しが違っても意味が近ければ拾える。たとえば「有給はいつから使えるか」という質問に対し、「年次有給休暇の付与時期」という見出しの文書を、単語が一致していなくても関連づけられる。
RAGでは、この埋め込みで関連文書を絞り込み、その内容を生成AIに渡して回答を作る。つまり埋め込みモデルは、RAGの「検索の目」にあたる。ここが自社の文書に合っていないと、後段の生成がいくら優秀でも精度は上がらない。発注者として細かい仕組みを理解する必要はないが、「埋め込みが検索精度を決める」という関係は押さえておきたい。
日本語対応と社内固有語への対応
埋め込みモデルを選ぶうえで、まず確認したいのが日本語への対応である。
日本語に強いモデルを選ぶ
埋め込みモデルには、英語を中心に学習されたものと、日本語を含む多言語を意識して作られたものがある。日本語の社内文書を扱うなら、日本語の文章でも意味の近さを正しく捉えられるモデルを選ぶ必要がある。日本語対応が弱いモデルだと、言い換えや敬語表現を含む文書をうまく拾えず、検索の取りこぼしが増えやすい。
専門用語・社内固有語の扱い
業界の専門用語や、自社だけで使う製品名・略語・部署名などは、一般的なモデルが学習していないことが多い。こうした語が多い文書では、汎用モデルだけでは意味の近さを正しく捉えきれない場合がある。対策としては、次のような方向がある。
- 文書の前処理で略語や社内用語を正式名称に補う
- 用語集を整え、検索時の補助に使う
- どうしても精度が出ない場合に限り、自社データに合わせた調整を検討する
ただし、いきなり調整に踏み込むより、まずは日本語対応の汎用モデルで試し、どの程度拾えるかを見るのが現実的である。なお、モデルそのものを自社データで学習し直す方針との違いはファインチューニングとRAGの選び方で整理している。
商用API型とOSS自社ホスト型の違い
埋め込みモデルは、大きく「商用API型」と「OSS自社ホスト型」に分けられる。どちらが優れているということではなく、コストと運用の負担、データの扱い方で選び分ける。
| 観点 | 商用API型 | OSS自社ホスト型 |
|---|---|---|
| 導入の手間 | 少ない（鍵を取得して呼び出す） | 多い（モデルを動かす環境が要る） |
| 初期コスト | 抑えやすい | サーバー・構築の負担がある |
| 継続コスト | 件数に応じた従量課金 | 自社インフラの維持費 |
| データの所在 | 外部サービスに送信する | 自社環境内で完結させやすい |
| 運用の手間 | 提供元に任せられる | 更新・保守を自社で担う |
商用API型は、鍵を取得して呼び出すだけで使え、運用の手間が少ない。少量から始めたい場合や、すぐに試したい場合に向く。一方で、文書や質問を外部サービスに送ることになるため、機微なデータを扱うなら送信先の規約や情報の扱いを確認しておきたい。
OSS自社ホスト型は、モデルを自社環境で動かすため、データを外に出したくない場合に向く。ただし、動かすためのサーバーや構築・保守の負担が発生する。中小企業では、まず商用API型で要件を確かめ、データの扱いやコストの見通しが立ってから自社ホストを検討する、という段階的な進め方が現実的なことが多い。どちらを選ぶかは、扱う情報の機密度・想定件数・社内の運用体制から判断したい。
次元数とコスト・速度のトレードオフ
埋め込みモデルが出力するベクトルには「次元数」がある。次元数は、文章を表す数字の並びの長さだと考えればよい。次元数が大きいほど、文章の意味を細かく表現できる傾向がある一方で、扱うデータ量が増え、保存や検索の負担も大きくなる。
| 次元数 | 期待できること | 負担 |
|---|---|---|
| 小さめ | 保存・検索が軽く、速度を出しやすい | 表現の細かさは控えめになりうる |
| 大きめ | 意味をより細かく捉えやすい | 保存容量・検索の負担が増える |
次元数は「大きいほど良い」というものではない。文書量が多い場合、次元数が大きいと保存するデータ量や検索の負担が膨らみ、コストや応答速度に影響する。逆に文書が少なく、ある程度の精度で足りるなら、小さめの次元数で軽く運用するほうが扱いやすいこともある。
ここで重要なのは、次元数の選び方が、ベクトルを保存・検索する基盤（ベクトルデータベース）の選定とも関わる点である。次元数が大きいほど、保存先に求められる容量や処理能力も上がる。埋め込みモデルと保存先は、切り離さずにセットで考えたい。保存先の選び方はベクトルデータベースの選び方で詳しく扱っている。
発注者としては、具体的な次元数を自分で決める必要はない。「文書量はどの程度か」「速度とコストのどちらを優先したいか」を伝えられれば、開発会社が適した次元数とモデルを提案できる。
モデルを後から変えると再インデックスが要る
埋め込みモデルの選定で見落とされやすいのが、「後から変えにくい」という性質である。
埋め込みは、使ったモデルごとに固有の変換結果になる。あるモデルで作ったベクトルと、別のモデルで作ったベクトルは、互いに比較できない。そのため、埋め込みモデルを変更すると、これまで蓄積した全文書を新しいモデルで作り直す「再インデックス」が必要になる。
- 文書量が多いほど、再インデックスの処理時間とコストがかかる
- 作り直しの間、検索結果の整合をどう保つかを考える必要がある
- 商用API型の場合、全文書を再変換する分の費用が改めて発生する
これは、最初のモデル選定を慎重に行う理由でもある。安易に決めて後から変えると、相応の手間が生じる。一方で、最初から完璧を狙いすぎると進まないため、「将来モデルを変える可能性がある」と見込んだうえで、再インデックスの手順を運用に織り込んでおくのが現実的である。発注前に「後からモデルを変える場合、どのくらいの手間がかかるか」を確認しておくと、判断を誤りにくい。
発注前チェックリスト
- 自社の文書が主に日本語であることを、選定の前提として共有したか
- 専門用語・社内固有語が多いかどうかを整理したか
- 商用API型とOSS自社ホスト型のどちらを軸に検討するか方針を持ったか
- 機微なデータを外部サービスに送ってよいかを確認したか
- 想定する文書量と、速度・コストのどちらを優先したいかを伝えたか
- 埋め込みモデルと保存先（ベクトルデータベース）をセットで検討しているか
- 後からモデルを変える場合の再インデックスの手間を確認したか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 日本語に強い埋め込みモデルを使えますか | 日本語対応 |
| 社内固有語が多い文書でも精度を確かめられますか | 専門用語への対応 |
| 商用API型と自社ホスト型のどちらを提案しますか | コストと運用の方針 |
| 文書を外部に送らない構成にできますか | データの所在 |
| 文書量に対して、次元数や保存先はどう選びますか | 速度・コストの設計 |
| 後からモデルを変える場合、どのくらいの手間がかかりますか | 再インデックスの見通し |
「とにかく高性能なモデルを使えば大丈夫」という説明には注意したい。自社の文書に合っているか、コストと運用に無理がないかが、実際の使い勝手を分ける。
相談前に整理しておくとよい情報
- 検索の対象にしたい文書の種類と、おおよその件数
- 文書が主に日本語か、英語や他言語も混ざるか
- 業界の専門用語や、自社だけで使う略語・固有名詞が多いか
- 個人情報や機密情報が含まれるか（外部送信の可否）
- 速度・コスト・精度のうち、特に優先したいもの
これらが完全に整理されていなくても相談は可能である。扱いたい文書と、その性質（言語・固有語・機密度）が見えていれば、適した埋め込みモデルの方向を一緒に絞り込める。
関連記事
よくある質問
Q1. 埋め込みモデルは、性能の高いものを選べばよいのですか
一概にそうとは言えない。性能の指標が高くても、自社の日本語文書や専門用語に合っていなければ、検索精度は上がらない。コストや運用の負担も含めて、自社の要件に合うかどうかで選ぶのが現実的である。
Q2. 商用API型と自社ホスト型は、どちらから始めるのがよいですか
機密性が特に高くない文書なら、導入の手間が少ない商用API型で要件を確かめるのが始めやすい。データを外に出したくない、あるいは件数が多くコストが読みにくい場合に、自社ホスト型を検討するという順序が取りやすい。
Q3. 一度選んだ埋め込みモデルは、後から変えられますか
変えられるが、これまで蓄積した文書を新しいモデルで作り直す再インデックスが必要になる。文書量が多いほど時間と費用がかかるため、最初の選定を慎重に行い、変更の可能性も見込んで進めるのが望ましい。
RAGの埋め込みモデル選定を一緒に整理しませんか
GXOでは、日本語対応・コスト・運用を踏まえた埋め込みモデルや検索基盤の選定を、発注前に整理するご支援をしています。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。