エンタープライズサーチとは — 「探して一覧」から「調べて答える」へ、生成AI時代の社内検索

「あの資料、どこにあるか分かる人いますか」——チャットにこの投稿が流れない日はない、という会社は多いはずです。ファイルサーバにもグループウェアにも検索窓はある。それでも人に聞くほうが早い。エンタープライズサーチの話は、いつもこのギャップから始まります。

この記事では、エンタープライズサーチとは何かの整理から、従来型が「使われない」理由、生成AI（RAG）で何が変わるのか、そして導入を製品で行くか構築で行くかの判断軸までを、社内文書検索を実案件で作ってきた実装者の視点で書きます。

エンタープライズサーチとは

エンタープライズサーチとは、社内の複数のシステム——ファイルサーバ、グループウェア、チャット、業務システム——に散らばる文書・ナレッジを、横断して検索できるようにする仕組みです。「社内版のGoogle」と説明されることが多いのですが、実際に作ってみると、Web検索とは前提が3つ大きく違います。

この違いが、後で述べる「使われない」問題の根っこになります。世間の検索技術をそのまま持ち込んでも、社内の文書と語彙はそれに合わせて整っていないからです。

検索窓はあるのに「使われない」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精度の診断ガイドにまとめています。

ChatGPTやCopilotがあれば、エンタープライズサーチは要らないのか

最近の相談で増えているのが、この問いです。ChatGPT（Enterprise / Team）はGoogle DriveやSharePointにつなぐコネクタを備え、Microsoft 365 CopilotはM365内の文書・メール・チャットを横断して答える。汎用のAIアシスタントが、社内検索の入口を兼ね始めています。

これで足りるケースは、実際にあります。文書の大半が主要なSaaS（M365 / Google Workspace）の中にあり、権限もそのSaaSの権限そのままでよく、用途が「関連しそうな資料に当たりをつける」——つまり「見つかれば良い」寄りなら、まず手元のアシスタントを試すのが早い。私たちも、この条件に当てはまる相談には構築をすすめません。

一方で、限界の出方もはっきりしています。第一に、対象の穴。独自の業務システムやファイルサーバに文書が残る会社では、コネクタの届く範囲だけが検索対象になり、「あの資料は出てこない」が残ります。第二に、外したときに直しにくいこと。汎用アシスタントの中の検索は調整の余地が小さく、社内略語や製品コードで取りこぼしても、打ち手がほとんど残らない。第三に、精度を測る物差しを持てないことです。「この質問に答えられれば合格」という評価を自社の業務で回したい——答えの正確さが業務要件になる規程・契約・技術文書の領域——に入ると、検索と評価を自分たちで握れる構成が要ります。

つまり分かれ目は、前の節と同じ場所に戻ってきます。「見つかれば良い」なら汎用アシスタントで足り始めている。「正しく答えてほしい」に踏み込むなら、検索品質を自分で測って直せる構成が要る。ChatGPTの登場でエンタープライズサーチが不要になったのではなく、「見つかれば良い」側の入口が安くなり、本命の勝負が検索品質と評価に寄った、というのが実装者としての実感です。

主要な選択肢の顔ぶれ

「エンタープライズサーチのシェア」を調べたくなる場面だと思いますが、シェアの数字より役に立つのは、選択肢がどの系統に分かれていて、自社の状況にどれが向くかの整理です。市場でよく名前が挙がるものを系統で並べます。

注意点はひとつ。どの系統を選んでも、検索対象のデータが整っていない問題（第二の理由で述べたスキャンPDF・命名規則・版の混在）は製品側では解決しません。製品比較に使う時間の一部を、自社の文書の棚卸しに回すほうが、導入後の体感には効きます。

製品を買うか、構築するか

最後に、導入形態の判断軸です。私たちは構築を生業にしていますが、すべてを構築すべきだとは考えていません。

分かれ目は、「見つかれば良い」のか「正しく答えてほしい」のかです。後者に踏み込むほど、自社の文書と語彙に合わせた設計と、精度を測る評価セットが要ります。そしてどちらの道でも、データ整備だけは避けて通れません。

よくある質問

エンタープライズサーチとRAGはどう違うのですか。

エンタープライズサーチは「社内の文書を横断して探せる仕組み」という目的の名前で、RAGは「検索結果を根拠にLLMが答える」という構成の名前です。生成AI時代のエンタープライズサーチは、中身がRAGで組まれることが実質標準になりつつある、という関係です。

ChatGPTに文書をその都度アップロードして聞くのと、何が違いますか。

個人がその場で数ファイルを読ませる使い方は、それで足りる場面も多いです。エンタープライズサーチが担うのはその常設版——誰が聞いても、権限の範囲で、最新版の文書から、出典つきで答えが返る状態を組織として維持することです。「どの文書を読ませるか」を人が毎回選ぶ運用は、文書を知らない人が使えないという、社内検索が解きたかった問題に戻ってしまいます。

費用はどれくらいかかりますか。

系統で構造が変わります。SaaS製品はユーザー数課金が多く、人数が多いほど月額が積み上がる。構築は対象文書の範囲と精度要件で初期費用が決まり、利用者数への感度は低い。どちらが安いかは規模と要件次第なので、まず対象文書と用途を絞った小さな範囲で試し、費用構造を見てから広げる順番をすすめています。

何から始めればよいですか。

全社一斉ではなく、「困っている度合いが強い部署×文書の種類」を1つ選ぶことです。その範囲で文書を棚卸しし、「この質問に答えられれば合格」という質問を現場から集める。この2つは製品選定より先にでき、どの系統を選ぶことになっても無駄になりません。

導入前チェックリスト

• 検索対象の文書はどこに散らばっているか。権限モデルと合わせて棚卸ししたか。
• 廃止版・下書き・重複ファイルを、検索対象から区別できるか。
• 社内略語・表記ゆれを吸収する手段（辞書・正規化・ベクトル検索）を持っているか。
• 「この質問に答えられれば合格」という質問リストを現場から集めたか。
• 回答に出典を付け、根拠が無いときは「無い」と言える設計か。
• 「見つかれば良い」のか「正しく答えてほしい」のか、要件をどちらかに言語化したか。

「人に聞くほうが早い」を、卒業しませんか

エンタープライズサーチは、検索窓を置く仕事ではなく、社内の知識を「聞けば答えてくれる状態」に整える仕事です。いまの文書の散らばり方と「見つからない」症状を聞かせていただければ、データ・検索・評価のどこから手を付けるべきか、当たりをつけてお伝えします。

参考文献

• 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 工藤大地がファクトチェック・編集・監修を行っています。事例の数値はすべて公開済みの実案件既出値です。