AI×レリバンスエンジニアリングによる、社内ナレッジの『検索から解決』への進化

第1章：[課題の現場で揺れる検索]

社内ナレッジを束ねるのは、ある意味「宝探し」の作業だと知っていた。情報基盤を統括するリエゾン部の若手リーダー、佐藤海斗のデスクには社内PDF、マニュアル、会議メモ、部署別Wikiが山のように積まれている。しかし現実は検索が相変わらずキーワード頼みで、正解は見つかりにくい。

言い換えられた表現や専門用語の揺れは頻繁に起きる。例えば「承認フロー」か「ワークフロー」か、規程の改定前後で用語が入れ替わっている書類が混在する。検索結果はファイルの一覧で終わり、文脈（なぜその判断が出たか）や最新の適用範囲が示されない。古い規定と最新ルールの混在は意思決定を遅らせ、担当者は「どれが本当に正解か分からない」と嘆く。

同僚の片岡が口にするのは、いわゆるPoC疲れの現場感だ。調査ではAIプロジェクトの失敗率が約85%に達し、日本企業のDXで期待された成果は20〜30%程度に留まるという報告もある。PoCから本番移行に関する課題は約90%がボトルネックになるとも言われ、ツール単体（UiPath Autopilot、Google Document AI、Azure AI Document Intelligence、Elasticsearch、あるいは大規模言語モデルのClaude 3.5 SonnetやGPT-4o）を導入しただけでは解決しない現実がある。

海斗は手元の検索画面を俯瞰し、「私たちのUXを変える――検索だけでなく、解決までを提案できる仕組みを作ろう」と誓った。彼の課題認識は明確だ。単に文書を集めるだけでなく、エンティティ拡張検索や長文の自動ベクトル化、ハイブリッドリトリーバルといった技術を、現場の文脈と権威付け（どのルールが最新であるか）まで結びつけていく必要がある。次章以降で、海斗と仲間たちはその実装設計へと歩みを進める。

用語集

• PoC疲れ: PoC（概念実証）が多数行われる一方で、本番化や価値実現に至らない疲弊状況。
• エンティティ拡張検索: 人名・組織名・製品名などの固有表現（エンティティ）を認識・展開して検索精度を上げる手法。
• 長文の自動ベクトル化: 長い文書をベクトル（数値表現）に変換し、意味的な類似度で検索・比較する技術。
• ハイブリッドリトリーバル: キーワード検索と意味検索（ベクトル検索）を組み合わせる検索手法。
• RAG: Retrieval-Augmented Generation。外部文書を検索して生成モデルの出力に活用する仕組み。
• Elasticsearch: 分散型全文検索エンジン。キーワード検索に強いが単独では文脈理解が限られる。
• Google Document AI / Azure AI Document Intelligence: 文書の構造抽出やOCRを提供するクラウドサービス。
• UiPath Autopilot: RPA（ロボティック・プロセス・オートメーション）関連の自動化ツール。
• Claude 3.5 Sonnet / GPT-4o: 大規模言語モデル（生成AI）。文書理解や要約、対話生成に用いられる。

第2章：[従来の検索の限界と痛み]

現場の痛みは明確だった。海斗は社内アンケートとログ解析で、検索行動と意思決定遅延の相関をあぶり出した。検索クエリの約45%が再検索やワード修正を伴い、クリック先で「読むだけ」で終わる割合が高い――これは部署横断の手続きで致命的になる。レビュー担当の吉岡が言うように、「古いマニュアルに依存してしまい、最新の規定がどれか分からない。検索結果には根拠の出典もない。結局、誰かが人力で検証してからしか動けない。」

構造的原因は複数ある。まず情報の断片化と所有権の不明確さ。ドキュメントがファイルサーバ、Wiki、メール、ナレッジベースに散在し、どれが“正”なのかを示すメタデータが欠けている。次に用語揺れ──部門ごとに同義語や略語が違い、従来のBM25やElasticsearch/Opensearch、Solrといった語句一致型検索は語形・文脈のズレに弱い。結果としてヒットはするが関連性が低く、利用者は大量の“ファイルの羅列”に時間を消費する。さらに情報の陳腐化。規定変更のタイムスタンプや出典が紐づかないと、古いルールが現行ルールと混在してしまう。

組織プロセスの側面では、横断的な合意形成が必要なケースでは「答えを提示して責任を取る」仕組みがないことが痛手になる。検索で提示されるのはあくまで参照一覧であり、意思決定に必要な根拠（出典＋適用条件）とアクション提案が不足している。加えてログや検索のメトリクスが経営層まで届かないため、改善投資の優先順位が低く抑えられる。海斗はここに技術と組織設計の両面解決が必要だと確信した。

この章で示された問題は、単なるUI改善だけでは解決しない。語彙の正規化、出典と適用条件の明示、文書の寿命管理、そしてBM25系検索とLLMを組み合わせたRAG（Retrieval-Augmented Generation）のようなハイブリッド手法が必要になる。次章では、海斗たちがこれらをどのように設計に落とし込むかを描く。

用語集

• レリバンスエンジニアリング：検索結果の関連性を人と機械で継続的に改善する手法。
• RAG：検索結果を補強してLLMが解答を生成するアーキテクチャ（Retrieval-Augmented Generation）。
• LLM：大規模言語モデル。文脈理解・生成が得意。
• BM25：従来の語句一致型の情報検索アルゴリズム。
• Elasticsearch / OpenSearch / Solr：全文検索エンジンの代表的実装。
• Uber / Spotify / Zalando：大規模検索・レコメンド改善の事例が知られる企業。

第3章：[転機となる出会いと気づき]

社内セミナーで春日野美咲に出会った海斗は、設計の視点が一変する話を聞いた。美咲はまずこう示す──「検索は意図と結果を接続する設計です」。彼女がチームに示した3つの柱は次の通りだ。

1. UXを“読む”から“聞く”へ（会話的インターフェース）
2. 知識を散在化から構造化へ（エンティティ化とスキーマ化）
3. 改善ループを回す（観測→評価→再学習）

これを実現する具体的アプローチを、海斗は仲間と議論して3案に整理した。

アプローチA：RAG＋会話フロント（素早い導線）

• 概要：BM25系リトリーバルで候補を絞り、LLMで統合して回答。対話UIで補足質問を投げる。
• メリット：証拠（retrieved source）を示せるため説明責任が高い。導入コストが比較的低い。
• デメリット：長文や意味揺れには弱く、エンティティ同定が不十分だと誤答が出る。レイテンシとAPIコストも考慮要。

アプローチB：ハイブリッド検索（エンティティ拡張＋ベクトル）

• 概要：エンティティ正規化で語彙ゆれを解消し、長文を自動で分割・ベクトル化して意味検索。BM25とベクトルを組み合わせて再ランキング。
• メリット：意味理解が深まり、文脈に沿った高精度な抽出が可能。古い規定と最新ルールの紐付けが得意。
• デメリット：前処理とストレージ、ベクトルストア運用の負荷が高い。チューニング工数も増す。

アプローチC：パーソナライズ＋改善ループ（継続改善）

• 概要：ユーザープロファイルと業務コンテキストを加味して結果を個人化。フィードバック（クリック、適用結果）を学習に回す。
• メリット：意思決定までの工数削減、組織内合意形成が進む。効果測定でROIが見える化。
• デメリット：プライバシー配慮や跨部門でのデータ同意が障壁。初期データ不足だと改善が遅い。

海斗は3案を統合する設計図を描いた。まずBで知識基盤を固め、Aで即時的UXを提供、Cで継続的に改善する。RAGは「根拠を付けた意思決定支援」を実現する中核として位置づけられるが、運用面（コスト・監査・説明可能性）は同時に設計しなければならない──それが春日野の示した転機だった。

定義：レリバンスエンジニアリング
情報検索の結果を「有用な行動」へ接続する設計領域。意味理解・個人化・改善ループを含む。

定義：RAG（Retrieval-Augmented Generation）
外部知識を検索で取得し、生成モデルが統合して回答を作る手法。根拠提示と生成の利点を併せ持つ。

定義：ハイブリッドリトリーバル
BM25等のレキシカル手法とベクトル意味検索を組み合わせ、候補抽出と再ランキングで精度を高める方式。

用語集（章末）

BM25：確率的な文書ランキング手法。キーワード一致に強い。
エンティティ拡張検索：固有表現の正規化・同義語展開を行い検索精度を上げる技術。
長文の自動ベクトル化：文書を文・段落に分割して埋め込み（ベクトル）化する処理。
Elasticsearch／OpenSearch／Vespa／Solr：BM25等を実装する検索エンジン。

海斗たちの実装は、三つの柱を順に“手を動かせる”レベルで組み上げた。

1. エンティティ拡張検索（Next.js SSR を例）

• 実装手順：
  1. 検索クエリ受領（サーバーサイドで SSR 受け取り）→クエリ正規化。
  2. 関連エンティティ（例：React, Server-Side Rendering, Hydration）をクエリ語に付与して拡張クエリを生成。
  3. 拡張クエリをEmbeddingモデルでベクトル化（例：OpenAI系 or ベクトルAPI）。
  4. Supabase の content_vectors とクエリベクトルでコサイン類似度を算出し、閾値（例：0.75）以上を候補抽出。
  5. 抽出結果をSSRで受け取り、Hydrationでクライアント表示。

2. 長文の自動ベクトル化

• 実装手順：
  1. 原稿を1000文字ごとにチャンク化（境界は文末優先）。
  2. 各チャンクから「パッセージ抽出」→意味単位のフラグル（fragment）化。
  3. パッセージ＋フラグルをセマンティック・トリプル（主語・述語・目的語）に組織化。
  4. 各トリプルをEmbeddingしてメタデータ付きでDB保存。保存はPOSTハンドラで受け、ペイロード検証→LLMによる意図分類→INSERT。
  5. メタは出典位置、作成日、チャンクIDを含める。

3. ハイブリッド検索と二段階リトリーバル

• 実装手順：
  1. 第一段階（百万件規模）：Elasticsearch/OpenSearch で BM25 を実行し上位100件候補を抽出。同時にBi-Encoderで同クエリを埋め込み、候補群をベクトルでスコアリングし再ランク。
  2. 閾値で絞り込み（top100→top10）。
  3. 第二段階（RAG）：top10の本文・トリプルをプロンプト形式で整形し、LLMに流し根拠付きの回答を生成（出典明示、根拠フラグ付与、推奨アクション提示）。
  4. UXは「回答＋根拠スニペット＋出典リンク＋推奨次アクション」で設計。

定義（専門要素）

エンティティ拡張検索：クエリに関連エンティティ語を追加し意味領域を広げてベクトル検索の精度を上げる手法。
RAG（Retrieval-Augmented Generation）：外部知識を取り込みつつ生成系LLMで根拠付き回答を作る設計パターン。
フラグル：意味単位に分割したテキスト断片。検索／合成の最小単位として扱う。

用語集

• レリバンスエンジニアリング：検索結果の関連性を設計・評価する工学的アプローチ。
• LLM：大規模言語モデル。テキスト理解と生成を担う。
• BM25：確率的文書検索のランキング関数（Elasticsearch等で用いる）。
• Bi-Encoder：クエリと文書を別々に埋め込んで高速類似検索を行うモデル。
• Supabase content_vectors：ベクトルを格納し検索するDB領域（pgvector等）。

第5章：[成果とビジネスインパクト]

海斗たちのPoCは、1,000名規模・文書20万件の社内データで実施された。エンティティ拡張＋長文チャンク化＋ハイブリッド検索（BM25で候補絞り、ベクトルで精査）を組み合わせた結果、検索→解決までの平均時間は従来の約18分→7分に短縮（約61%削減）。意思決定会議の回数は月間120回→84回に減り、部署横断の承認遅延は平均3.2日→1.1日に短縮した。RAGを用いて回答に根拠（原文リンク＋抜粋）を付すことで、社内満足度スコアは58→82に改善し、ミスコミュニケーションに起因する手戻りは約45%減少した。

具体的効果の背景には、検索UXの再設計がある。ユーザーは「読む」→「聞く」へと操作負荷が下がり、エージェント型の次アクション提案（例：ワークフロー起点のテンプレ案提示）により属人化が解消された。また、Elasticsearch/OpenSearchやVespa、Solrといった検索基盤の組合せ検討によりコストと精度のバランスを最適化し、スケール時にも安定した応答を確保している。業界ではUberやSpotify、Zalandoといった企業が類似のハイブリッド設計で効率化を達成しており、本実装もその道筋を辿っている。

将来的にはマルチモーダルと二段階リトリーバル（候補生成→文脈融合）を取り入れ、複数データ源を自律巡回して最適解を組み立てるフェーズへ移行予定だ。

用語集

• RAG：Retrieval-Augmented Generation。検索で取得した根拠をもとに生成モデルが回答を作る手法。
• エンティティ拡張：組織固有の固有表現（製品名・手続き名など）を辞書化して検索語の意味域を広げる手法。
• チャンク化：長文を意味単位で分割してベクトル化・保存する処理。
• ベクトル検索：文書を数値ベクトルに変換し、意味的に近いものを検索する手法。
• ハイブリッド検索：BM25などの伝統的手法とベクトル検索を組み合わせる方式。
• BM25：キーワード照合に強い古典的ランキングアルゴリズム。
• Elasticsearch/OpenSearch/Vespa/Solr：スケーラブルな全文検索エンジンの代表実装。

海斗は振り返り、こう結んだ。レリバンスエンジニアリングとRAGは単なる高速化ではなく、組織の意思決定を支える「知的基盤」へと昇華したのだと。彼の学びは三つに集約される。

• 学び1：検索は「意味と意図の接続」だ。キーワード一致ではなく、ユーザーの意図を推定して最短の解決へ導く設計が必要である。
• 学び2：根拠と次のアクションを必ず示す。出典を明示し、回答に具体的な「次の一手」を添えるUXが信頼を築く。
• 学び3：データは構造化して継続的に改善する。エンティティ拡張や長文の自動ベクトル化を組み合わせて精度と速度を両立させる。

重要ポイント（箇条書き）

• 検索→解決の評価指標を定める（時間、満足度、承認日数、手戻り率）
• クエリログを基に意図ラベリングを継続的に行う
• 根拠（ソース）と短期アクションを標準出力に組み込む
• ハイブリッドリトリーバル＋RAGで回答生成の信頼性を上げる

具体的な行動提案（実装イメージ）

1. クエリログ収集 → 意図タグ付け
2. エンティティ辞書更新（週次）
3. 長文チャンク＆ベクトル化を再生成（夜間バッチ）
4. ハイブリッド検索をA/B試験で比較
5. RAG出力に必ず出典＋「次の一手」を付与

用語集

• レリバンスエンジニアリング：検索結果の関連性を改善する技術・設計手法
• RAG：Retrieval-Augmented Generation。外部知識を取り込み生成する方式
• 大規模言語モデル（LLMs）：大量データで学習した生成モデル
• 知識グラフ：エンティティ間の関係を表す構造化データ
• エージェント型検索：意図を解釈し自律的にタスクを遂行する検索UX
• マルチモーダル：テキスト以外（画像・音声等）を扱うモデル
• Elasticsearch / OpenSearch / Vespa / Solr：代表的な検索エンジンソフトウェア