社内ナレッジ検索
エンタープライズサーチとは — 「探して一覧」から「調べて答える」へ、生成AI時代の社内検索
「あの資料、どこにあるか分かる人いますか」——チャットにこの投稿が流れない日はない、という会社は多いはずです。ファイルサーバにもグループウェアにも検索窓はある。それでも人に聞くほうが早い。エンタープライズサーチの話は、いつもこのギャップから始まります。
この記事では、エンタープライズサーチとは何かの整理から、従来型が「使われない」理由、生成AI（RAG）で何が変わるのか、そして導入を製品で行くか構築で行くかの判断軸までを、社内文書検索を実案件で作ってきた実装者の視点で書きます。
エンタープライズサーチとは
エンタープライズサーチとは、社内の複数のシステム——ファイルサーバ、グループウェア、チャット、業務システム——に散らばる文書・ナレッジを、横断して検索できるようにする仕組みです。「社内版のGoogle」と説明されることが多いのですが、実際に作ってみると、Web検索とは前提が3つ大きく違います。
| 前提 | Web検索 | エンタープライズサーチ |
|---|---|---|
| 誰が見てよいか | 全員に公開 | 部署・役職ごとの閲覧権限を反映する必要がある |
| 語彙 | 世間の一般語 | 社内略語・製品コード・独自の言い回しが主役 |
| 品質の手がかり | 被リンクなど、世間の評価が豊富に使える | 世間の評価は使えない。版の新旧・正式/下書きの区別が頼り |
この違いが、後で述べる「使われない」問題の根っこになります。世間の検索技術をそのまま持ち込んでも、社内の文書と語彙はそれに合わせて整っていないからです。
検索窓はあるのに「使われない」3つの理由
私たちが相談で聞く症状は、だいたい次の3つに集約されます。
第一に、言葉が合わないと見つからない。キーワード検索は「解約 手続き」と「中途解約」を別物として扱います。社内略語や表記ゆれが多いほど、検索は「正しい言葉を知っている人」にしか使えない道具になります。
第二に、そもそも検索できる状態でデータが置かれていない。スキャンしたままのPDF、命名規則のないファイル、廃止済み規程と現行版の混在。検索技術の問題以前に、データの問題です。私たちの経験では、ここが一番効く改善点であることが多い——地味ですが、RAGの前処理・データ整備とまったく同じ構図です。
第三に、リンク一覧を返されても、読む時間がない。20件のヒットから正解を探して開いて読む手間を考えると、「隣の詳しい人に聞く」が最短経路であり続けます。検索が人に勝てなかったのは、探すことではなく答えることが求められていたからです。
生成AIで何が変わるか — 「探す」から「答える」へ
RAG（Retrieval-Augmented Generation＝検索拡張生成）は、検索で見つけた文書を根拠にLLMが回答を組み立てる仕組みです（Lewis et al., 2020）。エンタープライズサーチの文脈で言えば、リンク一覧の代わりに、「答えそのもの＋出典」が返るようになる。これが3つ目の問題への答えになります。
ただし、見落としやすい点が2つあります。
一つは、出典の提示は省略できないということです。社内の意思決定に使う以上、「どの規程のどの条項に書いてあるか」まで返して初めて信頼されます。根拠が見つからなければ、それらしく生成せず「見つからなかった」と言わせる。ここを妥協すると、一度の誤答で現場の信頼を失います。
もう一つは、RAGにしても検索品質の問題は消えないということです。回答の質は、その手前の検索が正解文書を拾えているかで頭打ちになります。「探す」の質が「答える」の質の上限を決める——ここは生成AIになっても変わりません。
それでも本質は検索品質 — 全文検索は捨てる資産ではない
だからこそ、既存の全文検索（キーワード検索）は、生成AI導入で捨てるものではなく、半身として組み込むものです。社内検索は製品コード・略語・規程番号のような固有名詞の一致が主戦場で、ここはキーワード検索（BM25）の得意分野です。意味の言い換えに強いベクトル検索と組み合わせ、両者の結果を統合するハイブリッド検索が、社内文書では実質的な標準構成になります。設計の詳細はハイブリッド検索の設計に書きました。
導入の実際 — 数字が動いた例
私たちが手がけた大手商社の週次レポート検索は、まさにこの構図でした。導入初期の正答率は38.8%。原因は検索エンジンの性能ではなく、データの切り方・固有名詞の取りこぼし・そして「どの質問に答えられるべきか」が測られていないことに分散していました。文書構造に沿ったデータ整備、ハイブリッド検索、業務シナリオ49問の評価セットという順で積み上げ、正答率は93.6%まで届きました。経緯は事例記事に詳しく書いています。
数字よりお伝えしたいのは、改善の中身に魔法が一つも無いことです。エンタープライズサーチの成否は、製品カタログの機能表よりも、データ整備・検索設計・評価という工程を踏んだかどうかで決まります。全体の設計指針はRAG精度の診断ガイドにまとめています。
製品を買うか、構築するか
最後に、導入形態の判断軸です。私たちは構築を生業にしていますが、すべてを構築すべきだとは考えていません。
| 状況 | 向いている選択 |
|---|---|
| 文書が標準的（Office/PDF中心）・権限モデルが単純・まず全社横断の検索窓が欲しい | SaaS製品の導入が早い |
| 業務語彙が独特・答えの正確さが業務要件（規程・契約・技術文書）・精度を測って上げたい | RAG構築（評価セットを含む） |
| 閉域・国内データ要件・既存システムとの深い連携が要る | 構築または柔軟な製品の組み合わせ |
分かれ目は、「見つかれば良い」のか「正しく答えてほしい」のかです。後者に踏み込むほど、自社の文書と語彙に合わせた設計と、精度を測る評価セットが要ります。そしてどちらの道でも、データ整備だけは避けて通れません。
導入前チェックリスト
- 検索対象の文書はどこに散らばっているか。権限モデルと合わせて棚卸ししたか。
- 廃止版・下書き・重複ファイルを、検索対象から区別できるか。
- 社内略語・表記ゆれを吸収する手段（辞書・正規化・ベクトル検索）を持っているか。
- 「この質問に答えられれば合格」という質問リストを現場から集めたか。
- 回答に出典を付け、根拠が無いときは「無い」と言える設計か。
- 「見つかれば良い」のか「正しく答えてほしい」のか、要件をどちらかに言語化したか。
「人に聞くほうが早い」を、卒業しませんか
エンタープライズサーチは、検索窓を置く仕事ではなく、社内の知識を「聞けば答えてくれる状態」に整える仕事です。いまの文書の散らばり方と「見つからない」症状を聞かせていただければ、データ・検索・評価のどこから手を付けるべきか、当たりをつけてお伝えします。
参考文献
- Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS — arXiv:2005.11401
- Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997
この記事は、AIツールを活用して作成し、Cognisant 工藤大地がファクトチェック・編集・監修を行っています。事例の数値はすべて公開済みの実案件既出値です。
Read next