LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）として、社内システムの開発・保守・運用を受託しています。

情報が社内に散らばり、必要な文書にたどり着けないという課題

提案書はファイルサーバーに、顧客情報は基幹データベースに、議事録やナレッジはグループウェアやSaaSに——。多くの企業で、業務に必要な情報は複数のシステムに分かれて蓄積されています。担当者は「どこにあるか」を記憶と勘で探し、見つからなければ作り直す。この重複作業が、静かに生産性を削っていきます。

この課題は、システムを個別に足していくほど深くなります。SaaSが増え、部門ごとに保管場所のルールが分かれ、退職者のフォルダが放置される。情報の総量は増えるのに、必要な一件へ到達する時間はむしろ延びていきます。窓口を1つにまとめ、複数のシステムを横断して一度に探せる仕組みが求められる背景がここにあります。

近年は、この横断検索の価値が生成AIの普及でさらに高まりました。社内文書を根拠に回答するRAG（Retrieval-Augmented Generation。検索で集めた社内情報を大規模言語モデルに渡して回答を生成する構成）では、まず正確に文書を引き当てる検索の質が回答の質を左右するためです^*1。

エンタープライズ検索とは、文書・DB・SaaSを横断する全文検索基盤

エンタープライズ検索とは、社内に分散した文書・データベース・SaaSなどの情報を横断的に検索できるようにする基盤を指します。核となるのは全文検索です。ファイル名やタグだけでなく、文書の本文中の語まで対象に含めて探せる点が、単なるファイル一覧との違いになります。

技術的には、対象コンテンツをあらかじめ取り込んで「インデックス」を作ります。たとえばElasticsearchでは、インデックスは「ストレージの基本単位」であり、格納されるドキュメントは「フィールド（キーと値のペア）の集合」であるJSONオブジェクトとして扱われます^*5。マッピングが各フィールドのデータ型やインデックスのされ方を定義し、内部ではApache Luceneのインデックスとして保持されます^*5。この取り込み処理を通じて、大量の文書から目的の語を高速に引ける状態が作られます。

クラウドの検索サービスも同じ発想です。Azure AI Searchは、Azure Blob StorageやAzure Cosmos DB、Microsoft SharePointといった複数のデータ源にアクセスし、取り込んだテキストをトークン化して転置インデックス（inverted index）に格納すると説明されています^*1。全文検索に加えてベクトル検索やハイブリッド検索、関連度チューニング、ファセットナビゲーション、シノニムマッピング、オートコンプリートといった機能も利用できます^*1。

そして冒頭で触れたRAGとの関係です。Azure AI Searchは、企業や社内のデータにエージェントやチャットボットを接地（グラウンディング）させ、文脈に沿った正確な回答を生成させる用途を主要なユースケースとして挙げています^*1。つまりエンタープライズ検索は、人が使う検索窓としてだけでなく、生成AIに社内知識を供給する「検索エンジン」としても機能します。

データカタログ・BIダッシュボードとの違い——検索は「本文」に届く

社内の情報活用というテーマでは、データカタログやBIダッシュボードもよく登場します。役割が重なって見えるものの、扱う対象と目的は別物です。混同したまま要件を固めると、本来必要な機能が抜け落ちてしまいます。

データカタログは、社内にどのようなデータ資産が、どこに、どのような意味で存在するかというメタデータを管理する仕組みです。データの所在や項目定義、来歴を整理する台帳に近く、本文そのものを検索して返すことは主目的ではありません。一方でBIダッシュボードは、売上や稼働率といった構造化された指標を集計し、グラフや表で可視化する道具です。数値の傾向をつかむには強力ですが、契約書の一節や議事録の記述といった非構造の本文を探す用途には向きません。

これに対してエンタープライズ検索が目的とするのは、文書やレコードの本文に届くことです。キーワードを入れれば、その語を含む提案書や仕様書、メールを、情報源をまたいで一覧できます。データカタログが「どこに何があるか」を、BIが「数値がどう動いたか」を担うのに対し、エンタープライズ検索が担うのは「その中身に直接たどり着く」役割です。三者は競合ではなく、補完関係にあります。

構成要素——インデックス設計・ACLフィルタ・関連度ランキング

エンタープライズ検索を「使える」水準にするには、いくつかの構成要素をそろえる必要があります。単に全文検索エンジンを立てるだけでは、ヒットしすぎる、権限のない文書まで見えてしまう、目当ての一件が上位に来ない、といった問題が起きがちです。ここでは4つの要素を押さえます。

インデックス設計と更新——何を、どの粒度で取り込むか

最初の要素はインデックス設計です。どの情報源から、どのフィールドを、どの型で取り込むかを決めます。Elasticsearchでは、マッピングが各フィールドの型やインデックスのされ方・格納のされ方を定義し、この設計が使えるクエリや集計の種類を左右します^*5。加えて、元データが更新されたときにインデックスをどう追随させるか（更新頻度や差分反映）も設計段階の論点になります。ここを詰めないと、検索結果が古いまま返る事態を招きます。

ACLフィルタ——アクセス権を考慮した検索

社内検索で最重要ともいえるのが、権限の考慮です。人事や経営の文書が、権限のない社員の検索結果に出てはいけません。Azure AI Searchでは、文書単位の認可としてビルトインのACL（アクセス制御リスト）サポートがあるほか、それが使えない構成向けにセキュリティフィルターのパターンが用意されています^*2。

このパターンでは、各ドキュメントにグループやユーザーの識別子を表す文字列フィールド（Collection(Edm.String)、filterable=true、retrievable=false）を持たせます^*2。検索時にはsearch.in関数を使ったフィルターを付けることで、リクエスト元が読み取り権限を持つドキュメントだけに結果を絞り込めます^*2。権限設計を検索側に正しく反映できているかは、社内検索の信頼性を大きく左右します。

シノニムと関連度ランキング——探し当てる精度

3つ目は精度に関わる要素です。全文検索では、利用者が入力した語と文書中の語が一致しないと取りこぼしが起きます。ここで効いてくるのがシノニム（同義語）です。Azure AI Searchのシノニムマップは、同等の語を関連づけて、利用者がその語を入力しなくてもクエリの範囲を広げます。たとえばdog、canine、puppyを同義語として登録すると、canineでの検索がdogを含む文書に一致します^*4。内部的には、元のクエリを同義語とOR条件で書き換えるクエリ拡張の手法です^*4。

そのうえで、ヒットした文書をどの順で見せるかを決めるのが関連度ランキングです。Elasticsearchのmatchクエリは「全文検索を行う標準的なクエリ」であり、入力テキストを解析してからブールクエリを構成して実行します^*6。各文書には関連度スコアが割り当てられ、boostのようなパラメータでスコアを調整できます^*6。業務に応じて、新しい文書を優先する、特定部門の資料を上げるといった調整を行い、上位に本当に必要な一件が来る状態へ寄せていきます。

ファセット——結果を絞り込む導線

4つ目は、探索を助けるファセットナビゲーションです。これは検索結果に対する利用者主導の絞り込みで、カテゴリやブランドといった単位に結果をスコープするフォーム部品をアプリ側が提供します^*3。ファセットは各クエリの結果集合から動的に作られ、それぞれの件数が一致件数として表示されます^*3。「部門」「文書種別」「年度」などで段階的に絞れる導線があると、ゼロ件で行き詰まらずに目的へ近づけます。

外注時に確認したい4つのポイント

エンタープライズ検索の構築を外部に委託する場合、依頼範囲の広さと前提のすり合わせが成否を分けます。検索エンジンの導入そのものより、社内の情報源や権限体系にどう適合させるかが難所になるからです。契約前に、少なくとも次の4点を確認しておくとよいでしょう。

第一に、対象とするデータ源の範囲です。ファイルサーバー、基幹データベース、利用中のSaaSやグループウェアのうち、どこまでを横断対象にするか。コネクタが用意されていない情報源については、取り込みの実装をどちらが担うかまで明確にします。Azure AI Searchのように、Blob StorageやSharePointなど複数のデータ源に対応するサービスもありますが、自社の情報源が対象に含まれるかは個別の確認が要ります^*1。

第二に、アクセス権の設計です。既存の権限体系（Active DirectoryやEntraのグループなど）を検索結果の絞り込みにどう反映するか、ACLフィルターの実装範囲を委託先とすり合わせます^*2。ここが曖昧なまま進むと、公開してはいけない文書が検索に出る事故につながりかねません。

第三に、インデックスの更新設計です。元データの更新をどの頻度で、どの方式（全件再取り込みか差分反映か）で追随するか。検索結果の鮮度に直結するため、運用に入ってからの調整コストにも関わります。第四に、精度チューニングの範囲です。シノニムの整備や関連度ランキングの調整、ファセットの設計をどこまで含むのか。検証環境での確認範囲まで含めて契約前に線引きしておくと、運用開始後の後戻りを避けられます^*3*4。

対象データ源の数や権限体系の複雑さによって、必要な工数は変わってきます。現状の情報源と権限設計を棚卸ししたうえで、内製と外注の切り分けを検討することが実務的でしょう。

まとめ：エンタープライズ検索の外注で押さえる3つの視点

本稿では、エンタープライズ検索の役割と構成要素を、検索サービスの公式情報をもとに整理しました。要点は3つに集約できます。第一に、エンタープライズ検索は文書・DB・SaaSに散らばる情報を横断して全文検索する基盤であり、生成AIのRAGの土台にもなります^*1。第二に、メタデータを管理するデータカタログや指標を可視化するBIとは役割が異なり、本文そのものに届くことを目的とします。第三に、インデックス設計・ACLフィルタ・関連度ランキング・ファセットが品質を支える構成要素であり、外注時はデータ源と権限設計の範囲を明確にすることが重要になります^*2*3。自社の情報源と権限体系を棚卸ししたうえで、委託範囲を具体的に定めていきましょう。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft「Introduction to Azure AI Search」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/search/search-what-is-azure-search）
2. *2　出典：Microsoft「Security filters for trimming results in Azure AI Search」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search）
3. *3　出典：Microsoft「Add facets to a query in Azure AI Search」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/search/search-faceted-navigation）
4. *4　出典：Microsoft「Add synonyms to expand queries in Azure AI Search」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/search/search-synonyms）
5. *5　出典：Elastic「Index basics」（Elasticsearch Guide）（ https://www.elastic.co/docs/manage-data/data-store/index-basics ）
6. *6　出典：Elastic「Match query」（Elasticsearch Query DSL Reference）（ https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-match-query ）

Tweet