検索体験の再設計

この記事の目的

「検索して読む」体験を「聞いて答えを得る」体験へ再設計する際の構成と、従来検索との共存を判断できるようになります。回答型 UX の構成類型・社内検索を作り直すか活かすかの判断・出典と「見つからない」の扱い・検索ログという資産・評価の 2 層構造を、実務の設計判断として持ち帰れる状態を目指します。

対象読者

• 社内検索やヘルプ検索を「回答を返す」体験(アンサーエンジン)へ作り替えたいプロダクト責任者・エンジニア
• RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。 は動かせるが、それを「人間向けの検索プロダクト」として設計する視点がほしい実装者

前提知識

• ナレッジ Agent のケーススタディ — 知識源の品質が体験を決めた実例

本文

概要: 体験の主語が「探す」から「答える」へ変わる

従来の検索は「クエリを入れる → 結果一覧を見る → 自分で読んで判断する」体験です。これを「質問する → 答えが返る」体験に変えるのが、いわゆるアンサーエンジン(answer engine)です。RAG はその技術的な土台ですが、RAG 実装パターンが「Agent の知識源」を扱うのに対し、本記事は「人間向けの検索プロダクト」としての設計を扱います。

回答を生成するなら、検索結果の選択に加えて、主張が根拠文書に支えられているかもプロダクトの評価対象になります。検索一覧にも権限・順位・表示内容の設計責務があります。ここで扱うのはプロダクトの品質設計であり、利用者から提供者へ法的責任が移るという説明ではありません。

構成の類型

回答型の検索体験には、複雑さの異なる 3 つの類型があります。すべてを一足飛びに目指さず、知識源と用途に合う段階を選びます。

• 検索結果 + 要約: 最も導入が軽い型です。既存の検索基盤を残したまま、上位結果の要約を足す案です。課題達成率や待ち時間を比較し、要約の各主張と元文書の対応を示します。結果一覧の併記だけでは引用の正確さを保証しません
• 会話型検索: 曖昧な問いに聞き返し、条件を絞りながら答えます。問いの意図が定まっていない社内検索に向きます
• エージェント型検索: 多段で調べ切る型で、実態はディープリサーチ型エージェントに近づきます。コストとレイテンシが上がるため、「1 回で答えが出ない問い」に用途を絞ります

社内検索の作り直し(活かすか置き換えるか)

社内検索を回答型にするとき、「既存の検索基盤を活かすか、置き換えるか」で迷います。多くの場合、活かすほうが現実的です。

• 既存の検索資産を活かす: 全文検索・アクセス権・メタデータといった既存基盤は、そのまま RAG の検索段(一次検索)として使えることが多いです。特にアクセス権の反映は既存基盤が持つ強みで、これをゼロから作り直すのは大きなリスクです(RAG 実装パターンの権限反映検索RAG の検索段で、質問したユーザーのアクセス権を必須フィルタとして反映し、権限外の文書を候補から構造的に除外する仕組み。生成段で伏せる方式は権限外の内容がプロンプトに載った時点で漏えいリスクになるため、検索基盤の層で強制する。)
• 置き換えの前に不足を見極める: 既存検索の不満が「検索精度」なのか「知識源の質」なのかを切り分けます。後者(古い・重複した・欠けた文書)なら、検索エンジンを替えても解決しません(後述)
• 段階的に載せる: いきなり全面刷新せず、「検索結果 + 要約」から始めて効果を測り、必要なら会話型・エージェント型へ進みます

回答型 UX の設計(出典・確度・「見つからない」)

答えを返す以上、UX の設計は「正しく見せる」ことより「検証できるように見せる」ことを優先します。

• 出典を必須にする: 回答の各主張に、根拠となった文書へのリンクを添えます。出典のない断定は、利用者が確かめられず、幻覚モデルが事実でない内容をもっともらしく生成する現象。「もっともらしい続きを生成する」という学習目的の自然な帰結であり、対策は指示の強化ではなく、根拠の外部供給(RAG)・出典要求・検証という構造側にある。と区別がつきません。出典は「飾り」ではなく「回答の一部」です
• 確度を表示する: 根拠が薄い・情報源が食い違うときは、その理由を示して断定を避けます。数値の信頼度を表示するなら較正モデルの言う確信度と実際の正解率が一致している性質。「確信 80% のケースが実際に 8 割正解する」なら較正が良い。LLM は過信に寄りやすく、較正はモデル更新でずれるため再測定が要る。の検証が必要で、モデルの自己申告をそのまま正答確率にはしません(信頼度と較正)。自信満々に間違えるより、控えめに正しいほうが信頼されます
• 「見つからない」を正しく言う: 知識源に答えがないとき、もっともらしい作り話をせず「見つかりませんでした」と言えることが、回答型検索の生命線です。ゼロ結果を無理に埋めない設計(幻覚対策)を、UX とプロンプトの両方で担保します
• 答えと一次資料を往復できる: 答えだけで完結させず、元の文書へ辿れる導線を残します。重要な判断ほど、利用者は一次資料を自分で読みたがります

検索ログという資産

回答型に変えると、利用者は「キーワード」ではなく「自然な問い」を入力します。この問いのログは、知識の欠落を映す鏡であり、改善の最大の資産です。

• クエリを知識源の改善に還流する: よく聞かれるのに答えられない問いは、情報の欠落や検索経路の不具合を調べる手がかりになります。検索ログを分析し、不足している文書・古い文書を特定して知識源を直します(フィードバックループの運用)
• ゼロ結果・低評価を追う: 答えられなかった問い・低評価の回答を継続的に追い、優先度の高い欠落から埋めます
• プライバシーに配慮する: 問いには機微な情報が含まれます。ログの保存・分析はデータガバナンスの対象として扱います

ゼロ結果の診断と知識源の品質

回答型検索でうまくいかないとき、知識源・索引・検索・権限・生成を切り分けます。原因を測らずに検索エンジンや知識源の一方だけを変えると、効果を得られない場合があります。ナレッジ Agent のケーススタディがこの構造を示しています。

• 知識源の品質が回答の上限を決める: 古い・重複した・矛盾した文書からは、正しい答えは出ません。検索エンジンをチューニングする前に、知識源の棚卸し(重複排除・鮮度・欠落の補充)をします(AI のためのデータガバナンス)
• 「答えがない」を放置しない: ゼロ結果では、原文に答えがないのか、索引未更新・検索語の不一致・権限による非表示なのかを診断します。欠落なら文書を補い、検索や索引の不具合ならその箇所を直します。権限による非表示を解消するために認可を緩めてはいけません
• オーナーシップを決める: 知識源を誰が保守するかが曖昧だと、品質は下がり続けます。文書のオーナーと更新プロセスを決めるのが、検索体験を支える土台です

評価(検索指標と回答品質の 2 層)

回答型検索の評価は、2 層に分けます。片方だけでは品質を見誤ります(評価データセット)。

• 検索層の評価: 正しい根拠文書を候補に取れているか(再現率・上位の適合率)。ここが取れていないと、生成がどれだけ賢くても正しい答えは出ません
• 回答層の評価: 取れた根拠から、正しく・出典付きで・過不足なく答えているか(LLM-as-a-Judgeと人手)。「見つからない」を正しく言えるか(答えるべきでない問いに答えていないか)も測ります
• 2 層を分けて診断する: 悪い回答が「検索の失敗」か「生成の失敗」かを切り分けられると、直すべき場所が分かります。合算した 1 指標だけでは、原因が見えなくなります

実務での注意点

アンチパターン

チェックリスト

関連トピック

• RAG 実装パターン — 検索と生成の実装(本記事はその上の検索体験)
• ディープリサーチ型エージェントの設計 — 多段で調べ切るエージェント型検索の先(自律調査のレポート生成)
• ナレッジ Agent のケーススタディ — 知識源の品質が体験を決めた実例
• AI のためのデータガバナンス — 知識源の品質・オーナーシップの管理
• フィードバックループの運用 — 検索ログの改善への還流
• 信頼度と較正 — 確度表示と「見つからない」の判断
• 評価データセットの構築と保守 — 検索層・回答層の評価
• LLM-as-a-Judge — 回答品質の評価

参考資料

• Shao ほか, STORM (2024)  — 出典付き情報整理の実装例(アクセス日: 2026-09-10)
• Amershi ほか, Guidelines for Human-AI Interaction (CHI 2019)  — 能力・誤りの伝達と修正可能性。検索 UI の類型と診断手順は本記事の設計整理です(アクセス日: 2026-09-10)

TODO・未確認事項

なし