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

エンタープライズサーチの検索結果には、製品の比較やランキングが多く並びます。ただし、機能名が同じでも、接続先ごとに同期方法や権限制御の対応は異なります。この記事では特定製品を順位付けせず、候補製品を自社資料で比較し、導入するかを判断する方法に絞ります。

ローカル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を内製化する進め方も参考になります。

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