近年、AI検索プロジェクトにおいて、特にここ1〜2年で増えている課題があります。
「流行りのベクトル検索を導入したのに、既存のキーワード検索より精度が落ちたと現場から怒られています。どうすればいいでしょうか？」
特に、専門用語や型番が飛び交うB2B製造業やECサイトの現場において、このような事態が頻発しています。RAG（検索拡張生成）のブームに乗って、多くの企業がドキュメント検索や社内ナレッジ検索にAIを導入しました。しかし、いざプロトタイプを動かしてみると「思ったような検索結果が出ない」という壁にぶつかっているのです。
結論から申し上げます。「ベクトル検索は魔法の杖」ではありません。 特に、厳密性が求められるビジネスの現場においては、ベクトル検索単体では解決できない課題があります。
今回は、製造業における一般的な導入事例をもとに、一度は課題に直面したAI検索プロジェクトをどうやって立て直すのか、その「評価指標設計」と「ハイブリッド検索」の導入プロセスを解説します。
技術的な話も出てきますが、経営層から現場のエンジニアまで、どなたにもわかるように噛み砕いてお話しします。皆さんの現場ではどうでしょうか？ ぜひご自身のプロジェクトと照らし合わせながら読み進めてみてください。
【事例概要】部品メーカーが直面した「AI検索の精度の壁」
まずは、製造業の現場が置かれやすい状況と、初期PoC（概念実証）でのつまずきについてお話ししましょう。
取扱点数10万点、似て非なる型番の山
従業員数1,000名規模の産業用機械部品メーカーのケースを考えてみましょう。よくある悩みとして、取り扱う部品点数が10万点を超え、その仕様書や過去の不具合事例が膨大な社内サーバーに散在していることが挙げられます。
若手エンジニアが顧客から「XJ-500シリーズの耐熱仕様について知りたい」と問い合わせを受けても、該当するドキュメントを探し出すのに時間がかかってしまいます。ベテラン社員ならすぐに答えられるのですが、この属人性が組織のボトルネックになっているのです。
そこで多くのDX推進チームは、「AIを使って社内ドキュメントを検索できるようにしよう」とRAGシステムの導入を決定します。
「ベクトル検索なら魔法のように解決する」という誤解
プロジェクト初期、導入推進チームは最先端の「ベクトル検索」のみを採用しがちです。ベクトル検索とは、言葉を数値の列（ベクトル）に変換し、キーワードが一致しなくても「意味が近い」ものを探し出す技術です。
例えば、「PCが動かない」で検索しても、「パソコン 故障」「画面 真っ暗」といったキーワードが含まれるドキュメントをヒットさせることができます。これは従来のキーワード検索（完全一致検索）にはできないことです。
多くのチームはここで確信してしまいます。「これで表記ゆれも吸収できるし、曖昧な検索でもドキュメントが見つかるようになるはずだ」と。
現場エンジニアからのフィードバック
しかし、いざプロトタイプを構築し、現場のエンジニアに使ってもらうと、厳しい意見が出ることが少なくありません。
「全然使えない。これなら従来の検索の方がマシだ。」
何が起きているのでしょうか？
問題は、製造業特有の「型番」と「厳密性」にあります。
例えば、ユーザーが「XJ-200-S（ステンレス製）」という特定の型番を検索したとします。
ベクトル検索は「意味」を捉えようとします。その結果、AIは気を利かせて「XJ-200-A（アルミ製）」や「XJ-200（標準モデル）」のドキュメントも「意味的に近い」として上位に表示してしまうのです。
エンジニアにとって、ステンレス製とアルミ製は全くの別物です。しかし、汎用的なAIモデルにとっては「どちらもXJ-200シリーズの部品である」という文脈で高い類似度を持ってしまいます。
「欲しいのは『似ているもの』じゃない。『そのもの』なんだ」
この現場のリアルな声こそが、システム設計を見直す最大のヒントになります。
なぜ「ハイブリッド検索」が必要だったのか？技術選定の裏側
多くのRAGプロジェクトにおいて、課題解決のブレイクスルーとなるアプローチがあります。それは、ベクトル検索単体に固執するのではなく、従来から存在するキーワード検索と組み合わせる「ハイブリッド検索」への移行です。
キーワード検索の「完全一致」とベクトル検索の「意味理解」
まず、両者の特性を整理しましょう。これは技術選定において極めて重要なステップとなります。
| 特徴 | キーワード検索 (Lexical Search) | ベクトル検索 (Semantic Search) |
|---|---|---|
| 得意なこと | 型番、固有名詞、専門用語の完全一致 | 曖昧な表現、類義語、自然言語での質問 |
| 苦手なこと | 表記ゆれ（「サーバー」と「サーバ」）、多義語 | 厳密なキーワード一致、未知の固有名詞 |
| 製造業での相性 | ◎ (型番検索に必須) | △ (概念検索には有効だが型番に弱い) |
製造業のケースでは、型番や「JIS規格」といった特定のキーワードが含まれていることが絶対条件になる場面が多々あります。一方で、「ポンプから異音がする」といった症状ベースの抽象的な検索では、ベクトル検索の力が存分に発揮されます。
つまり、どちらか一方に頼るのではなく、両方のメリットを享受できる仕組みが不可欠となるのです。
両者のいいとこ取りをするための構成案
ハイブリッド検索の基本的な仕組みは以下の通りです。
- ユーザーのクエリに対して、キーワード検索とベクトル検索を並行して実行する。
- それぞれの検索結果（ランキング）を取得する。
- 2つの結果を統合（Re-ranking）し、最終的な順位を決定する。
この構成であれば、「XJ-200-S」と検索された時はキーワード検索が強く働き正確なドキュメントを拾い上げ、「異音」と検索された時はベクトル検索が類似事例を拾い上げる、という強固な補完関係が成立します。
導入における懸念点：チューニングの複雑さ
ハイブリッド検索は強力な反面、実装の難易度が上がります。どちらの検索結果をどれくらい信用するかというバランス調整（重み付け）が必要になるからです。
例えば、キーワード検索で1位、ベクトル検索で50位のドキュメントと、キーワード検索で圏外、ベクトル検索で1位のドキュメントが存在した場合、どちらを最終的に上位に表示すべきでしょうか。皆さんはどう判断しますか？
この問いに客観的に答えるためには、エンジニアの感覚ではなく、ビジネスの目的に直結した「定量的な評価指標」を導入することが求められます。
「精度が良い」をどう定義するか？現場で使える3つの評価指標
AIプロジェクトにおいて「精度を上げてください」という漠然とした要望は、開発現場を混乱させる典型的なパターンです。「精度」の定義が関係者間で合意されていないからです。
製造業の現場などでRAG（検索拡張生成）システムを導入する際、PoC（概念実証）の合否判定基準として、以下の3つの指標を明確に策定することが有効です。
学術的指標（NDCG/MRR）と現場感覚のズレ
検索エンジンの評価には、一般的にNDCG（Normalized Discounted Cumulative Gain）などの指標が使われます。NDCGは、二値評価（関連/非関連）ではなく、5段階などの段階的関連度を扱い、検索結果の品質を細かく区別して評価できるため、多段階評価に対応する主要指標として広く採用されています。2026年現在でも評価のデファクトスタンダードとして標準仕様が維持されています。
しかし、現場の実務においては、指標の計算そのものよりも、データリーケージ（評価データへの正解の漏洩）の除去や、ビジネス目的に沿った検証設計の見直しが優先される傾向にあります。数学的なスコアの高さが、必ずしも現場の「使いやすさ」と一致するとは限りません。そこで、ビジネスインパクトに直結する独自の指標を併せて定義することが求められます。
採用指標1：完全一致率（Exact Match Rate）
定義: 特定の型番やエラーコードで検索した際、その型番がタイトルやメタデータに含まれるドキュメントが1位に来ている割合。
狙い: 「型番で検索したら、その製品の仕様書が一番上に出る」という、業務現場にとっての「当たり前」を保証するためです。ベクトル検索の弱点である「意味は似ているが異なる型番」を排除できているかを確認する重要な指標になります。
採用指標2：トップKに含まれる正解率（Recall@K）
定義: 検索結果の上位K件（一般的にK=5程度）の中に、ユーザーが求めていた正解ドキュメントが含まれている割合。
狙い: 1位でなくても、上位5件に入っていればユーザーはクリックして内容を確認できます。これは「見つからない（検索漏れ）」を防ぐための指標です。特に「異音」や「動作不良」のような曖昧な自然言語検索において重要視されます。
採用指標3：再ランク付け後のユーザー納得度スコア
定義: 実際の現場エンジニアにテスト利用してもらい、検索結果に対して「役に立った」「まあまあ」「役に立たない」の3段階で定性的に評価してもらったスコア。
狙い: 数値上の精度が良くても、実際のユーザー体験が悪ければシステムは定着しません。例えば、正解ドキュメントが出ていても、その周辺に全く無関係なノイズが多すぎると「使いにくい」と判断されます。これを数値化して継続的に追跡します。
これらの指標を測定するために、まず「ゴールデンセット（評価用データセット）」を作成します。過去の実際の問い合わせログから質問を抽出し、業務知識を持つ担当者に「この質問に対する正解ドキュメントはこれ」というペアを作ってもらうプロセスです。
ここが最も重要です。 多くのプロジェクトが、この「正解データ作り」を省略してアルゴリズムの調整に走りますが、それは地図を持たずに航海に出るようなものです。まずはプロトタイプを動かしながら、地道に正解データを作り上げていく。この実践的なアプローチこそが、プロジェクト成功の鍵となります。
実装とチューニング：重み付けのバランスを探る
評価指標が決まったら、いよいよハイブリッド検索の実装とチューニング段階に入ります。
ここでは、異なる検索アルゴリズムの結果を統合する手法として RRF (Reciprocal Rank Fusion) を採用するケースで解説します。
ベクトル vs キーワードの重み付け（Alpha値）の調整
RRFは順位に基づいたスコアリングを行いますが、さらに「キーワード検索」と「ベクトル検索」のどちらを重視するかを調整するパラメータ（ここではAlpha値と呼びます）を導入することが一般的です。
- Alpha = 1.0 : 全てベクトル検索の結果のみ採用
- Alpha = 0.0 : 全てキーワード検索の結果のみ採用
- Alpha = 0.5 : 両方を均等に評価
作成したゴールデンセットを用いて、Alpha値を変化させながら、先ほどの「完全一致率」と「Recall@5」がどう変化するかを実験します。ここで重要なのは、仮説を即座に形にして検証するスピード感です。
最適な設定値は、扱うデータセットの特性に大きく依存します。
一般的には「ハイブリッドなら半々（0.5）が最適だろう」と思われがちですが、型番指定が多い製造業のデータセットなどでは Alpha = 0.3（キーワード検索寄り） の時に最も高いスコアが出るケースが報告されています。
これは、検索ニーズが「正確な記号・専門用語」に偏っていることを表しています。ベクトル検索はあくまで「キーワードで拾えなかった時の保険」や「表記ゆれの吸収」として機能させるのが、実務上のベストバランスとなる場合があるのです。
ドメイン辞書なしではキーワード検索も機能しない
また、キーワード検索側の強化も不可欠です。社内用語辞書（シソーラス）の整備がそれに当たります。
例えば、「SUS」と「ステンレス」を同義語として登録する。「Assy」と「アセンブリ」を紐付ける。こうした辞書登録を地道に行うことで、キーワード検索のヒット率は確実に向上します。
昨今のAI開発環境は急速に変化しています。例えば、Google Vertex AIの最新環境では、Geminiを基盤としたAPI経由での機能提供が主流となっており、画像の視覚推論とコード実行を組み合わせたAgentic Visionのような自律的な処理や、Cloud SQLとの統合によるオンライン予測・ベクトル埋め込みの直接呼び出しが可能になっています。このように、プラットフォームの機能は高度化・複雑化を続けており、特定の機能やブラックボックス化されたツール仕様への過度な依存にはリスクも伴います。
だからこそ、ツールが変わっても陳腐化しないドメイン知識の注入（辞書整備やデータクレンジング）が強力な武器になります。最新のLLMやAPI機能に頼り切るのではなく、人間が知恵を貸してあげるアプローチが、長期的なシステムの安定性を支えるのです。
失敗ケースの分析と改善ループの回し方
評価指標のスコアが低いクエリについては、個別にエラー分析を行います。
- ケース: 「ポンプ 振動」で検索しても、目的のトラブルシューティング資料が出ない。
- 原因: 資料内では「振動」ではなく「振れ」という言葉が使われており、かつベクトル的にも距離が遠かった。
- 対策: ドキュメントのメタデータに「タグ」として一般的なトラブル用語を付与する。
このように、アルゴリズムの調整だけで解決しようとせず、データ側（ドキュメント）をリッチにすることで問題を解決するアプローチも併用します。
導入後の成果と担当者へのアドバイス
適切なチューニング期間を設けて改善ループを回すことで、ハイブリッド検索システムは実運用に耐えうる水準に達します。
検索成功率の向上
導入前のベクトル検索単体と比較して、ハイブリッド化と適切なチューニングによって検索成功率（Recall@5）が大幅に向上するケースは珍しくありません。精度の壁を越えることで、システムの実用性が飛躍的に高まります。
「検索できないストレス」からの解放と業務効率化
現場からは「以前は検索しても目的の情報が出ないので諦めていたが、今はまず検索ツールを使おうという気になる」といったフィードバックが得られるようになります。検索システムへの信頼が回復し、組織内にナレッジシェアの文化が醸成され始めるのがこの段階です。
これから導入する企業への「評価データセット準備」のススメ
最後に、これからRAGやAI検索の導入を検討されている組織に向けて、AIエージェント開発や業務システム設計に長年携わってきた視点から重要なポイントを挙げます。
「アルゴリズムを選ぶ前に、『正解データ』を作ること」
どんなに高価なベクトルデータベースや最新のLLMを導入しても、それを評価する「物差し」がなければ、改善の方向がわかりません。現場の担当者の頭の中にある「正解」をデータ化すること。そして、まずはプロトタイプを動かし、アジャイルに検証を繰り返すこと。それが、AIプロジェクトを成功させるための確実な第一歩となります。
コメント