近年、RAG（検索拡張生成）システムを導入したものの、「期待したような回答が得られない」という課題に直面するプロジェクトが多く見受けられます。
原因を分析すると、多くの現場でLLM（大規模言語モデル）のプロンプト調整に多大な時間を割いている傾向があります。しかし、システム全体を俯瞰すると、LLMに渡す前の「検索」段階に根本的な課題が潜んでいるケースが少なくありません。
RAGにおいて、LLMは渡された情報をまとめて回答する役割を担います。もし、検索段階で的外れなドキュメントを抽出していれば、LLMがどれほど優秀でも正確な回答は生成できません。いわゆる「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」の状態です。
そして、その検索精度を決定づける重要な要素の一つが、「埋め込みモデル（Embedding Model）」です。
今回は、多くのプロジェクトで見落とされがちな「埋め込みモデル選定」について、プロジェクトマネージャーの視点から、ROI（投資対効果）を最大化するための実践的なアプローチを解説します。
なぜ「モデル選び」がRAGの成否を分けるのか？
埋め込みモデルの選定がシステム全体を左右する理由として、RAGの検索品質への直接的な影響と、後戻りの難しさ（スイッチングコスト）が挙げられます。特に近年のRAGは、テキストだけでなく図表なども扱うマルチモーダル化が進んでいます。さらに、情報のつながりを重視するGraphRAGのような高度なアプローチが、Amazon Bedrockなどのクラウド環境でもサポートされ始めるなど、埋め込みモデルが担う役割はかつてなく広がっています。
検索精度の天井はLLMではなく埋め込みモデルで決まる
RAGの仕組みを料理に例えるなら、LLMは「シェフ」、埋め込みモデルとベクトル検索は「食材調達係」と言えます。
シェフ（LLM）がいかに優秀でも、調達係（埋め込みモデル）が不適切な食材を持ってきたら、美味しい料理（回答）は作れません。多くのプロジェクトでは、シェフの腕前ばかりに気を取られ、調達係の能力チェックを怠っている傾向があります。
埋め込みモデルは、テキストや画像データを「ベクトル」という数値の羅列に変換します。この変換精度が低いと、「契約書の解約条項」を探しているのに「契約の締結手順」を抽出するといったミスマッチが起こります。これでは、現在標準となっているGPT-5.2や、APIとして活用されるGPT-4oのような高性能なLLMを導入しても、その真価を十分に引き出すことはできません。
後からの変更が困難な「データの再インデックス」問題
埋め込みモデルは、一度選定して運用を開始すると、簡単には変更できないという特性を持っています。
LLM自体は、LangChainのようなフレームワークを利用していれば比較的容易に交換可能です。LangChainのアーキテクチャでは、コア機能（langchain-core）とコミュニティ機能（langchain-community）が整理されており、コードレベルでのモデル切り替えや保守性は大きく向上しています。
しかし、埋め込みモデルを変更するということは、ベクトルデータベースに保存されている全データを、新しいモデルで変換し直す（再インデックスする）ことを意味します。これには以下のリスクが伴います。
- 計算コストと時間の増大: データ量が数百万件規模になると、再計算だけで数日を要するケースも珍しくありません。
- ダウンタイムの発生: インデックス再構築中は検索機能が制限される可能性があります。
そのため、システムの初期段階で、将来のデータ増加やマルチモーダル対応も見据えた比較検証を行うことが強く推奨されます。
盲点1：多言語対応モデルの「日本語理解力」の落とし穴
「とりあえずOpenAIの埋め込みモデルを使っておけば間違いない」という意見をよく耳にします。
確かにOpenAIは生成AIの分野をリードし続けており、公式情報（2026年2月時点）によれば、標準モデルであるGPT-5.2やコーディングに特化したGPT-5.3-Codexなどを展開しています。GPT-4oなどのレガシーモデルはWebサービス（ChatGPT）での提供を終了し、高度な推論（Thinking機能とInstant機能の自動ルーティング）を備えたGPT-5.2へ統合されるなど、進化のスピードは留まることを知りません。なお、旧モデルのAPI自体は継続して提供されていますが、プロンプトを最新のGPT-5.2で再テストするなどの移行対応が推奨されています。
しかし、ここで混同してはならないのが、「生成モデル（LLM）の賢さ」と「埋め込みモデル（Embedding）の検索性能」は全くの別物であるという事実です。
「Multilingual」表記でも日本語が得意とは限らない
「多言語対応（Multilingual）」というのは、「日本語も入力として処理できる」という意味であって、「日本語の文脈や文化的背景を深く理解している」ことを必ずしも保証しません。
最新のGPT-5.2が100万トークン級のコンテキストを扱い、流暢な日本語で長文を安定して処理できる一方で、検索のベースとなる埋め込みモデルが、日本語特有の「同義語」「表記ゆれ（引越し／引っ越し）」「敬語表現」を正確に捉えきれないケースは依然として存在します。
例えば、汎用的な多言語モデルを使った結果、「銀行」と「金融機関」という言葉の類似度を低く見積もってしまい、重要なドキュメントが検索にヒットしない（Recallが低い）という事態が起こり得ます。これを日本語処理に特化したモデルに切り替えるだけで、検索精度が劇的に改善することも珍しくありません。
ベンチマークスコア（MTEB）の正しい読み方
モデルの実力を測る際、MTEB (Massive Text Embedding Benchmark) という指標が業界標準として使われます。リーダーボードの上位にあるモデルを選びたくなりますが、ここで注意すべきは「どの言語でのスコアか」という視点です。
総合スコアが高くても、それが英語タスクでの圧倒的な高得点に牽引されているだけという可能性があります。日本語環境でのRAG構築を目指すなら、日本語タスク（JSTSやJSQuADなど）での個別スコアを確認するか、実際に自社の日本語ドキュメントを使って検証を行うことが不可欠です。
「有名だから」「ランキング1位だから」という理由だけで判断せず、「自分たちの扱う日本語データに最適化されているか」を論理的かつ冷静に見極める必要があります。
盲点2：ベクトル次元数が招く「クラウド破産」のリスク
ランニングコストの観点から、埋め込みモデルの選定基準を掘り下げます。モデルの選択は、初期構築のしやすさだけでなく、システム運用中の継続的な支出に直接的な影響を与えます。AI導入においてROIを最大化するためには、このコスト意識が欠かせません。
高次元＝高精度とは限らないが、高次元＝高コストは確実
埋め込みモデルを評価する際、「次元数（Dimensions）」というスペックが1つの指標になります。例えば、OpenAIの text-embedding-3-large は最大3072次元、text-embedding-3-small は1536次元で設計されており、オープンソースの軽量モデルでは384次元や768次元が広く採用されています。
多くの開発現場では、「次元数が高いほど、より複雑な意味や文脈を表現できるため、検索精度も向上するはずだ」と直感的に期待されます。しかし、この認識は必ずしも正解とは言えません。対象となるドキュメントの性質や検索タスクの要件によっては、過剰な次元数がかえってノイズとなり、意図しない検索結果を引き起こすケースが報告されています。
一方で、確実な事実が1つあります。それは「次元数が増加すれば、それに比例して運用コストも跳ね上がる」という点です。
ベクトルDBのストレージと検索コストへの影響
PineconeやWeaviateといったマネージドベクトルデータベースを活用する際、業界全体の課金体系のトレンドは大きく変化しています。
特にPineconeのサーバーレスアーキテクチャでは、従来のインスタンス単位で発生する固定費モデルから、「Read/Write Units（RU/WU）」と「ストレージ容量」に基づく従量課金へと移行が進んでいます。この仕組みにより、システムが稼働していない待機時間のコストは劇的に削減されましたが、その反面、扱うデータ量そのものがコストに与えるインパクトは以前よりも大きくなっています。
具体的に考えてみましょう。1536次元のベクトルデータは、768次元のベクトルのちょうど2倍の容量を占有します。これは単にストレージの空き容量を圧迫するだけでなく、インデックスの作成や類似度検索といったデータの読み書き処理において、必要なユニット消費量（RU/WU）を直接的に押し上げる要因となります。
つまり、「大は小を兼ねる」という発想で安易に高次元モデルを採用すると、データ量に比例して以下のような経済的リスクが膨らみます。
- ストレージコストの増大: 保存するデータ量が倍増すれば、月々の保管料金も当然引き上げられます。
- 操作コストの上昇: データの書き込みや検索時に消費される計算リソースが増加し、クエリ1回あたりの単価が高止まりします。
Weaviateをはじめとする他の主要なベクトルデータベースでも、機能拡張や課金体系の見直しは頻繁に行われています。そのため、本番環境への導入前には、必ず公式ドキュメントで最新の仕様と料金体系を確認することが不可欠です。
「わずかな精度向上のために、倍増するデータ量と継続的なコスト負担を受け入れる価値があるのか？」という厳しい視点を持ち、費用対効果のバランスを見極めたモデル選定を推奨します。
盲点3：API型 vs ローカル型の「レイテンシとセキュリティ」
LangChainの大きな魅力は、GPT-4oや最新の標準モデルであるGPT-5.2といったクラウドAPI型だけでなく、Hugging Face上のモデルをローカル（自社サーバー内）で動かす構成へと柔軟に切り替えられる点にあります。ここで、システム要件を大きく左右する「API型 vs ローカル型」のトレードオフを深く検討する必要があります。Webブラウザから利用するChatGPTでは標準モデルがGPT-5.2へと移行するなどの変化が起きていますが、API経由でのGPT-4o利用は引き続きサポートされており、プロジェクトの目的に応じて最適なAPIモデルを選択できる環境が整っています。
外部API依存によるネットワーク遅延の蓄積
RAGシステムで大量の社内ドキュメントをインデックス化したり、高いリアルタイム性を求めたりする場合、API型モデルではすべてのテキストをインターネット経由で外部サーバーに送る必要があります。
近年のモデル（GPT-4oやGPT-5.2など）は推論速度自体が劇的に向上していますが、物理的な通信に起因する課題は依然として残ります。
- 通信レイテンシ: 処理すべきファイル数が膨大な場合や、ユーザーとのチャットの往復回数が多い場合、ネットワークの通信時間がボトルネックとなり、体感速度（UX）を損なう可能性があります。
- API制限と安定性: レートリミット（分間アクセス制限）への到達や、外部サービス側の一時的な障害により、重要な業務プロセスが中断するリスクを常に考慮しなければなりません。
機密データを外部に出さないローカル埋め込みの選択肢
金融機関や医療現場、あるいは製造業における未発表の設計データなど、「データを一切社外のサーバーに出せない」という厳格なセキュリティポリシーが存在する場合、パブリックなAPI型モデルは最初から選択肢から外れるケースが一般的です。
LangChainを活用すれば、HuggingFaceEmbeddings クラスや、近年利用が拡大している Ollama などを組み込むことで、完全なオフライン環境での埋め込み処理や推論が可能になります。これにより、機密データは自社インフラ（オンプレミスやプライベートクラウド）から一切出ることなく、外部通信による遅延もないセキュアな環境を構築できます。
ただし、ローカル型を選択する場合は、自前で高価なGPUリソースを調達・管理する運用コストが継続的に発生します。「手軽に導入できて高性能なAPI」を選ぶか、「確実な安全性と低レイテンシを担保するローカル」を選ぶか。プロジェクトに求められるセキュリティ要件とインフラ予算を慎重に天秤にかけ、最適なアーキテクチャを選定する視点が求められます。
盲点4：トークン制限が及ぼす「チャンク戦略」への制約
RAGの実装で極めて重要なのが、ドキュメントを適切な長さに分割する「チャンク化（Chunking）」です。このチャンク戦略は、使用する埋め込みモデル（Embedding Model）の「最大入力トークン数（Max Tokens）」に直接的な影響を受けます。
扱えるテキストの長さはモデルによって異なる
モデルには一度にベクトル化して処理できる長さの限界があります。
一般的に、従来のBERTベースのオープンソースモデルなどは512トークンが限界であることが多い一方、OpenAIの埋め込みモデルなどは8191トークンまで扱える設計になっています。
ここで重要な視点があります。「生成モデル（LLM）」と「埋め込みモデル」の進化スピードと制約の違いです。
現在、生成モデル側は飛躍的な進化を遂げています。例えば、2026年2月時点でOpenAIの業務標準モデルとなっているGPT-5.2は、100万トークン級の長大なコンテキストを安定して処理でき、高度な推論能力を備えています（なお、以前主流だったGPT-4oなどのレガシーモデルはChatGPT上では廃止され、GPT-5.2へ統合が進む一方で、API経由での利用は継続されています）。このようにLLM側が非常に長いコンテキストを扱えるようになった反面、RAGの検索プロセスで使われる埋め込みモデル側には、依然として厳格なトークン制限が存在します。
もし512トークンしか扱えない埋め込みモデルを選んだ場合、どんなにGPT-5.2のような高性能なLLMをバックエンドに控えていても、ドキュメントを細かく分割せざるを得ず、情報の断片化が避けられません。
文脈分断を防ぐための最大トークン数の確認
文章が細切れになりすぎると、「文脈（Context）」が失われるリスクが劇的に高まります。
例えば、「その結果、組織は事業撤退を余儀なくされた」という文があったとして、その前の段落にある「急激な市場変化への対応遅れにより」という理由部分が別のチャンクに切られてしまうケースを想像してください。検索時に「なぜ撤退したか」という問いに対して、理由が含まれていないチャンクだけがヒットしても、いかに賢い最新の生成AIであっても正しく回答を生成することは困難です。
長いコンテキストを扱える埋め込みモデルであれば、ある程度まとまった意味の塊（段落やセクションごと）でベクトル化できるため、文脈を保持しやすくなります。
生成AI側のモデルがGPT-5.2のように進化し、長文脈や高度な推論が可能になったとしても、検索の入り口となる埋め込みモデルのトークン制限を見落とすと、適切な情報抽出ができないという「ボトルネック」が生じます。モデル選定時には、生成モデルの性能だけでなく、埋め込みモデルの最大トークン数も必ず確認することをお勧めします。
盲点5：汎用モデルでは対応できない「業界用語」の壁
最後に、B2B領域で特に顕著な「専門用語」の問題です。
医療・法律・製造現場用語の検索精度
汎用的な埋め込みモデルは、Wikipediaや一般的なWebテキストで学習されています。そのため、社内独自の略語や、特定の業界でしか通じない専門用語（ドメイン固有語）の意味を正しく理解できないことがあります。
例えば、製造業の現場で使われる型番「XJ-900」と、その後継機「XJ-900改」が、汎用モデルにとっては「全く関係のない文字列」として処理されるか、あるいは単なる「文字の羅列」として扱われ、意味的な関連性を見出せないことがあります。
ファインチューニングやハイブリッド検索の必要性
この課題を解決するには、2つのアプローチがあります。
- モデルのファインチューニング: 自社データを使って埋め込みモデル自体を追加学習させる（難易度高）。
- ハイブリッド検索: ベクトル検索だけでなく、従来のキーワード検索（BM25など）を組み合わせる。
特にLangChainでは、EnsembleRetriever を使うことで、ベクトル検索とキーワード検索を簡単に組み合わせることができます。「型番」のような完全一致が重要なキーワードはキーワード検索で、概念的な質問はベクトル検索で、と補完し合う構成にするのが有効な場合があります。
モデル単体で解決しようとせず、「アーキテクチャ全体で補う」という論理的な視点も重要です。
まとめ：失敗しない選定のためのチェックリスト
ここまで、埋め込みモデル選定における注意点を整理しました。これらは技術的な詳細に見えて、プロジェクトの予算、スケジュール、ビジネス価値に直結する重要な要素です。
最後に、選定時に確認すべきチェックリストをまとめます。
- 言語適合性: 日本語特化のベンチマークや実データでの検証を行ったか？
- コスト試算: ベクトル次元数に基づくDBコストと、データ増加時の見積もりをしたか？
- セキュリティ: データを外部APIに送信して問題ないか？（ローカル運用の必要性は？）
- トークン制限: 想定するチャンクサイズに対して、モデルの入力制限は十分か？
- 専門用語対応: 業界用語が多い場合、ハイブリッド検索などの対策を盛り込んでいるか？
LangChainを使うことで、これらのモデルや構成を柔軟に切り替えることができます。開発の初期段階で決め打ちせず、いくつかのモデルを実際に動かして比較検証（PoC）を行うことが推奨されます。
最初のモデル選定に時間をかけ、論理的なアプローチをとることで、将来の手戻りを防ぎ、ROIの最大化に繋げることができるでしょう。プロジェクトが成功することを願っています。
コメント