エンタープライズサーチとは?社内横断検索の対象・権限・鮮度の整え方

エンタープライズサーチの導入では、まず「何を検索できるようにするか」「誰に表示してよいか」「変更をいつ反映するか」を決めましょう。製品の検索画面を比べる前に、この3点を接続先ごとに整理すると、試行で確認すべき条件が明確になります。

本記事では、社内文書を横断して探すための導入判断表と確認手順を提案します。製品仕様の例は公式資料に基づき、試験項目や運用方法は編集上の提案として区別しています。

エンタープライズサーチで何を探せるようにするのか

ここでいうエンタープライズサーチは、社内の複数の情報源を横断して、業務に必要な文書や情報を探す仕組みです。検討対象には、共有ストレージの規程、社内Wikiの手順書、問い合わせ管理システムの対応記録などがあります。実際に検索できる範囲は、採用する製品と接続先の組み合わせで確認します。

この記事では、原文を見つけて開くまでを導入の対象とします。検索結果を材料に文章を生成する機能は、別の評価項目に分けましょう。まず「正しい版の文書に到達できるか」を試す構成です。

導入判断表:接続先ごとに3つの条件を決める

次の表は、要件整理に使う提案です。全社で一括して埋めるより、最初に扱う業務と接続先を絞って記入してください。

判断軸 決めること 試行で残す証拠 条件を満たさないときの案
検索対象 対象の保存場所、文書種別、正本、除外する範囲 探すべき文書と除外すべき文書の結果 対象を縮小し、文書の置き場や版を整理する
閲覧権限 利用者・グループと元システムの権限の対応 権限の異なる利用者による表示結果 当該接続先の提供を保留する
鮮度 本文更新・削除・権限変更それぞれの反映期限 元データ変更時刻と検索側の反映時刻 許容時間を見直すか、別の確認経路を用意する

「接続できた」だけでは、業務で使えると判定しないことが重要です。対象文書の発見、権限外の情報の非表示、変更反映を、それぞれ受入条件にします。

検索対象:正本と除外範囲を先に決める

最初の試行では、利用者が繰り返し探す業務資料を対象にすることを提案します。たとえば申請手順なら、現行の手順書を対象にし、個人の作業メモや旧版をどう扱うかも決めます。この例は導入実績ではなく、対象を絞るための考え方です。

接続先の台帳には、保存場所だけでなく「正本を決める担当者」「対象のフォルダーや領域」「除外対象」「原文のURL」を記入しましょう。似た文書が複数ある場合は、どれを正として案内するかを文書の管理者に確認します。

対象の制御機能の例として、Amazon KendraのS3コネクターは包含・除外フィルター、利用者アクセス制御、全件・増分同期を対応機能として挙げています。これはS3接続の仕様例です。採用候補の接続先でも同じ制御ができるかは、個別に確認してください。AWS公式資料:Amazon S3接続

評価時は「ファイル形式に対応しているか」に加えて、実際の文書から探したい語が検索できるか、原文を開けるかを試します。画像中心の文書や複雑な表など、利用予定の文書をサンプルに含めると確認対象が具体的になります。

閲覧権限:取り込み権限と利用者への表示条件を分ける

検索システムが文書を取り込めることと、利用者にその文書を見せてよいことは、別の確認項目として扱いましょう。

Microsoft Graphでは、検索に追加する外部項目にACL(アクセス制御リスト)、プロパティ、コンテンツを持たせます。ACLで利用者やグループ等への許可・拒否を指定し、外部の利用者をMicrosoft Entraの利用者へ対応付ける必要もあります。この仕様例から、本文の取り込みに加え、利用者の識別と権限の対応関係を確認する必要性が分かります。Microsoft公式資料:外部項目とACL

試行には、全社公開資料だけでなく部門限定の資料も含め、閲覧できる人とできない人で同じ検索を行うことを提案します。確認するのは原文を開けるかだけではありません。検索結果のタイトルや抜粋にも、権限外の情報が出ていないかを見ます。

また、異動などでグループから外した後の状態を試してください。検索用アカウントと元システムの利用者をどう対応させるか、権限変更をどの処理で反映するかは、導入担当者が説明できる状態にします。対応が不明な接続先は、全社利用の対象からいったん外す判断を提案します。

鮮度:本文・削除・権限変更を別々に試す

検索の鮮度は、更新間隔の設定値だけで評価せず、変更が実際に検索結果へ届くまでを測りましょう。Microsoft Graphの外部項目管理でも、元データが変わった際には接続項目を同期する必要があると説明されています。Microsoft公式資料:コンテンツ変更時の同期

次の3種類を分けて試す方法を提案します。

試験 操作と確認 先に決める条件
本文更新 手順書を更新し、新しい内容で検索・表示される時刻を記録 業務上許容できる遅延
文書削除 試験用の文書を削除し、検索結果から消える時刻を記録 削除を反映すべき期限
権限変更 試験利用者の閲覧権限を外し、タイトル・抜粋も含めて非表示になるか確認 権限変更の反映期限と未反映時の対応

一律の「何分以内」を前提にせず、文書の用途ごとに条件を決めてください。特に権限変更は、本文更新と同じ反映経路・周期かどうかも確認対象にします。

同期の監視では、処理全体の状態と文書ごとの結果を分けて見ます。Amazon Kendraでは、データソース単位のエラーは同期履歴、文書単位のエラーはCloudWatch Logsで確認できます。また、同期状態がIncompleteの場合、一部文書が正常に索引化されていない可能性があります。AWS公式資料:同期のトラブルシューティング

運用担当者には、失敗の通知先、再試行後の確認方法、復旧までの原文への案内方法を決めてもらいましょう。権限変更が期限内に反映されない場合には、対象の検索提供を止めるなど、選択する製品で実行できる対応を事前に検証します。

小規模な試行から利用範囲を広げる手順

導入は次の順序で進めることを提案します。

  1. 対象業務と接続先を絞り、業務担当者から実際に使う検索語と探したい文書を集める。
  2. 正本・除外範囲・利用者の権限を台帳にまとめる。
  3. 検索語ごとに、目的の文書が見つかるか、原文を開けるか、権限外の情報が出ないかを確認する。
  4. 本文更新・削除・権限変更を行い、決めた反映期限を満たすか測る。
  5. 検索で見つからない場合と同期に失敗した場合の担当者を決め、条件を満たした範囲から利用を始める。

評価表には成功件数だけでなく、「文書自体がない」「対象から除外されている」「権限の設定を確認する必要がある」「同期が未完了」といった調査結果も残してください。原因に応じて、文書管理者と検索基盤の担当者へ作業を割り振るためです。

まずは接続先を一つ選び、検索対象・権限・鮮度の判断表を埋めるところから始めましょう。製品の機能説明を、自社で確かめられる受入条件に置き換えることが、試行の目的です。

記事一覧へ戻る

ITの困りごとを、
まずはご相談ください。

何から手をつけるか決まっていない段階でも構いません。ご相談内容に応じて、担当者からご連絡します。

まずは相談する

採用へのご応募は採用エントリーからお願いします。