エンタープライズサーチの選び方と比較｜導入前に決める文書・権限・版管理・評価

ここでいう「比較」は、製品名を並べた製品別の比較ではありません。候補製品を同じ自社資料で試し、導入できるかを判断するための比較です。機能名が同じでも、接続先ごとに同期方法や権限制御の対応は異なります。接続先・検索方式・セキュリティ・導入形態・運用負荷・費用の六つを、同じ条件で比べます。

ローカルAIエージェントの記事では、文書の処理場所と外部送信の範囲を扱っています。本記事が扱うのは、保存先を横断する検索製品の導入条件です。Microsoft製品内の社内FAQはCopilot AIエージェントの記事、営業の会話を残す仕組みは商談ナレッジの記事で分けて解説しています。

標準検索で足りない理由を、先に一文で決めます

一つの保存先で文書名や分類が整っているなら、標準の検索機能を改善する方が早い場合があります。エンタープライズサーチを検討する理由は、「複数の保存先に同じ業務の文書があり、利用者ごとの権限を保ったまま横断して探したい」のように一文にします。対象が曖昧なままでは、接続できるサービスの数が多い製品を選んでも、実際の探し物が減りません。

公式資料を見ても、製品やコネクターごとに対応範囲は異なります。たとえばElasticの現行一覧では、高度な同期、差分同期、文書単位のアクセス制御に対応するかがコネクターごとに示されています。候補を比べるときは「製品に機能があるか」ではなく、「自社が使う接続先との組み合わせで使えるか」まで確認します。出典：Elastic「Elastic connectors reference」

検索対象は、保存先ではなく実際の文書まで棚卸しします

最初に、探せないことで業務が止まっている文書を集めます。「共有フォルダー全部」のような指定ではなく、契約書、手順書、規程、商品資料など、誰が何の判断に使う文書かを書きます。同じ保存先でも、表が多いPDF、画像だけのスキャン、添付ファイル、長い表計算では読み取り方が変わるためです。

デモには、見栄えのよいサンプルではなく、自社で検索しにくい文書を使います。機密情報を渡せない段階なら、形式と構造を残した架空資料に置き換えます。検索対象、正本の管理者、更新頻度、利用者を整理する考え方はシステム連携で正本を決める方法と共通します。

権限は、取り込み用アカウントと検索利用者を分けて確認します

検索システムが文書を読み取れることと、検索した社員がその文書を見てよいことは別です。取り込み用の接続アカウントに広い権限があっても、その範囲を全社員へ見せてよいわけではありません。元システムのユーザーやグループの許可・拒否を検索結果へ反映できるかを確認します。

Microsoft Graphの外部コネクターでは、検索へ取り込む項目にユーザーやグループ単位のアクセス制御リストを設定する仕組みが公開されています。これは一つの実装例であり、すべての製品や接続先が同じ方式ではありません。出典：Microsoft Learn「externalConnectors acl resource type」

テストでは、一般社員、管理職、特定部門の担当者など、権限が異なる利用者を用意します。本文を開けないだけでなく、検索結果の件名、抜粋、件数、生成された回答にも権限外の情報が出ないかを見ます。異動、グループ削除、ファイル移動、共有解除を行った後、いつ検索結果から消えるかも記録します。同期前の空白時間が業務上許容できるかは、自社で決めます。

Googleの現行資料でも、データソースのアクセス制御には設定時点や対応する識別子などの条件があります。導入後に設定名だけを確認するのではなく、データストアを作る前に制約を読み、自社の認証と利用者情報で試します。出典：Google Cloud「Use data source access control」

「更新日が新しい」と「業務で使う正本」を分けます

最新の更新日時だけでは、正本を決められません。旧制度の説明へ注記を加えたファイルの更新日が、現行規程より新しくなることもあります。文書管理側で、承認済み、現行、廃止、差し替え待ちなどの状態を持ち、適用開始日、文書責任者、後継文書を記録します。

検索では、現行文書を優先し、廃版は通常結果から除外するか「旧版」と分かる形で表示します。削除だけに頼ると、過去の経緯を確認したい業務に対応できません。反対に、古い文書をすべて残して同じ重みで検索すると、正しい版へたどり着きにくくなります。元の文書管理と検索側の絞り込みを組み合わせます。

候補製品のデモでは、内容が似た現行版と廃版を同時に入れます。「出張申請の方法」のような質問で現行版が上に出るか、旧制度名で探したときに後継文書へ案内できるか、廃版を根拠に回答を作らないかを確認します。

検索精度と速度は、自社の質問と正解文書で比較します

製品が示す精度や速度の数字は、データ、質問、権限、設定、測定環境が違えば、そのまま自社へ当てはめられません。まず実際に聞かれる質問を集め、質問ごとに「開いてほしい正本の文書」と該当箇所を人が決めます。正解がない質問も含めます。

評価表には、期待する文書が上位何件までに出たか、廃版・権限外文書が混ざったか、該当なしの質問へ無関係な結果を返したか、結果と原文を開くまでに何秒かかったかを残します。平均だけでなく、遅い質問が業務を止めないかを見るために、同じ回数を実行したときの遅い側の値も記録します。合格値は一律に置かず、「窓口担当が電話中に使う」「翌日までの調査に使う」など、利用場面から決めてください。

Google Cloudの検索評価機能も、質問と対象文書の組み合わせを用意し、集計値と質問ごとの結果を確認する手順を示しています。製品固有の評価機能を使う場合でも、正解文書を自社で決める作業は残ります。出典：Google Cloud「Evaluate search quality」

生成AI・RAGは、正しい文書を取得した後の役割です

検索は質問に合う文書を取得し、利用者が原文を開けるようにします。RAGは、取得した文書を生成AIへ渡し、回答案や要約を作る構成です。文書を探すだけならRAGは必須ではありません。複数文書を読んで回答案をまとめたいときに検討します。

生成AIを加えても、検索が権限外の文書や廃版を取得すれば、回答も誤った根拠を使うおそれがあります。そのため、検索だけの結果を先に評価し、その後に回答の根拠リンク、引用箇所、答えられないときの止まり方を試します。Google Cloudの現行説明でも、キーワード・意味検索と、取得した情報に基づく引用付き回答は別の機能として案内されています。出典：Google Cloud「Introduction to custom search」

製品の比較は、機能一覧ではなく六つの観点で並べます

エンタープライズサーチの比較表は、対応コネクターの数や検索方式の名前を並べるだけだと、どの製品も「できる」に見えます。エンタープライズサーチの比較では、文書・権限・版管理・評価に加えて、接続先・検索方式・セキュリティ・導入形態・運用負荷・費用の六観点を同じ書式で記録します。そうすると、候補の差が運用の差として見えます。

クラウド型とオンプレミス型は、文書を置く場所で分けます

クラウド型は構築が早い一方、検索対象の文書や索引を外部のサービスに置くことになります。一般にオンプレミス型や自社環境に構築する型は、社外へ出せない文書にも使いやすい反面、サーバーの保守や更新作業が自社の仕事になる傾向があります。ただし、提供形態と責任範囲は製品ごとに異なり、クラウド型でも専用環境や閉域接続を用意する製品があります。エンタープライズサーチをクラウド型にするか自社環境型にするかは、候補製品の公式資料で責任分担を確かめたうえで、対象文書の機密区分と、サーバーの保守を担う人がいるかで決めます。

日本語の言い換えと表記ゆれは、自社の用語で試します

日本語の社内文書は、「出張費」「旅費」「交通費・宿泊費」のように同じ意味が別の言葉で書かれます。全角と半角、旧字体、略称も混ざります。辞書や同義語の登録がどこまで必要か、自動で吸収できるかは製品によって差が出ることがあるため、評価の質問に社内用語と略称を必ず入れます。

費用は、利用料と整備の人手を分けて見積もります

費用は利用者数や文書量による月額・年額のほか、初期の接続設定、権限の整理、評価用データの作成、導入後の同義語や正本の更新にかかる人手があります。見積もりを取るときは、利用料に含まれる範囲（接続先の数、文書量、問い合わせ件数）と、別料金になる範囲を同じ表で書いてもらいます。金額は構成で大きく変わるため、この記事では目安額を示しません。

導入は小さな範囲の試行から始め、広げる条件を先に決めます

最初から全社の文書をつなぐと、権限や正本の不備が一度に表に出ます。エンタープライズサーチの導入では、まず一部門・一種類の文書で試行し、あらかじめ決めた検索精度と速度の合格値を満たしたら対象を広げる、と段階を決めます。試行の終了時に、合格だった質問、落ちた質問、運用で直す点を残すと、次の部門や他の候補製品との比較にもそのまま使えます。

候補製品には、同じ受入条件を渡します

比較表は機能の有無だけで埋めず、受入条件と確認方法を一緒に書きます。たとえば「権限連携あり」ではなく、「一般社員のアカウントでは人事文書の件名・抜粋・生成回答が出ない。共有解除後は自社が定めた時間内に結果から消える」のようにします。候補ごとに資料や質問を変えず、同じ条件で記録します。

1. 目的：誰のどの探し物を減らすかを一文にします。
2. 対象：保存先、形式、正本、廃版、更新頻度を一覧にします。
3. 権限：利用者別の見える・見えない文書と変更ケースを用意します。
4. 評価：代表質問、正解文書、該当なし質問、合格値を決めます。
5. 役割：原文を探す検索、回答案を作るRAG、更新を行う業務フローを分けます。

ここまで埋めると、製品を導入せず文書管理を直すべきか、横断検索が必要か、検索後の回答生成まで必要かを分けられます。費用を比べるときも、利用料だけでなく、権限と文書状態の整備、評価データの更新、問い合わせ対応にかかる運用時間を含められます。

SalesDockは、製品を決める前の業務・データ設計を支援します

SalesDockは、エンタープライズサーチ製品のランキング提供や、特定製品の販売を目的としていません。自社で文書の正本、閲覧権限、版管理、代表質問と合格条件を整理し、検索だけで解く範囲と生成AI・RAGを加える範囲を決める支援を行います。個別製品の精度や効果を保証するものではありません。

相談前は、実際の機密文書ではなく、保存先の名前、文書の種類、閲覧する役割、よくある質問、現行版の決め方を箇条書きにしてください。AI活用を社内で進める体制まで検討する場合は生成AIを内製化する進め方も参考になります。

エンタープライズサーチのよくある質問