エンタープライズサーチ入門

このブログでは、エンタープライズサーチについて紹介していきます。 エンタープライズサーチソリューションの選定基準や、組織固有のニーズに基づいた開発におけるヒントをいくつか取り上げます。

本投稿は、エンタープライズサーチの理解を深めたい業務部門の人、事前に主要コンセプトの概要を理解しておきたい技術部門の人（エンジニアなど）の両方の役に立つ内容となっています。

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

これは単に「ググる」以上のものです。サーチ（検索）は、この世界に関する質問に答えるために情報（ドキュメント/記録/ファクト）を特定する手段の1つですが、エンタープライズサーチはこれを大きく超えます。

エンタープライズサーチには以下の4つのカテゴリがあります。

1. 探す：どこかにドキュメント/記録/ファクトがあるはずなので、それを発見したい。
   • 社内の出張規則の最新版が必要だ。
   • エンタープライズサーチに関するスタッフミーティングの議事録が見たい。
   • ジョン・スミス氏の住所と電話番号を知りたい。
   • また高度なユースケースとしては以下のようなものがあります：私の担当地域内の不良部品によるリコール対象の顧客名と電話番号を知りたい。また、不良品の発生以降にその部品を含む製品を購入した顧客全員を対象としたい。 この結果を年間の発注総額順に並べることで、一番重要な顧客を把握したい。
2. ディスカバリー（発見）：ある特定のトピックについて調べている。これに関する情報領域を探索したい。
   • 我が社における「機械学習」の取り組みはどのようなものか。午後のプロダクトミーティング前に知っておきたい。
   • 今始めようとしているプロジェクトにおいて、どのようなコンプライアンス規則が適用されるのか。
   • 我が社の製造工程において改善の余地があるのはどの部分か。
3. モニタリング：あるトピックを監視し、何らかの変化があった場合に通知してほしい（自分で同じ検索を繰り返さなくても済むように）。
   • 朝ログインした際に、私のプロジェクトに関係する新しい記事や社内メモを表示してほしい。
   • 私の担当地域で強盗が発生した場合、メールで通知してほしい。
   • 私が取り組んでいる飛行機の翼の空気力学に関して新しい論文が発表されたら通知してほしい。
4. 分析：関連データの一部だけを入手して（一連の基準に基づく）、分析に使用したい（機械学習アルゴリズムやBIツールなどで）。
   • 自分の機械学習モデルで顧客のマスタリングをするが、マスタリングが必要だと思われる人にだけ予め対象を絞りたい。
   • 機械学習モデルのテスト用に、いくつかの基準を満たした金融取引の無作為サンプルが必要だ。
   • 担当地域内のセールス（最小/最大/中央値）および保守更新すべてを、種別に分析したい。結果を垂直方向のグループ化棒グラフで表示したい。

エンタープライズサーチが素晴らしい理由

エンタープライズサーチは、単なるインデックス付けツールではありません。

私たちが考えるエンタープライズサーチとは、使用データに合わせてカスタマイズされた一流の検索「アプリケーション」のことです。カスタム開発されたUIがあり、自社のコンテキストに合わせて答えを返すことで、パーソナライズされた検索体験を提供します。

例えば、MarkLogicのユーザー企業の1つに、シュプリンガー・ネイチャーがあります。彼らの検索アプリケーション、SpringerLinkはエンタープライズサーチの好例です。これは一般公開されています（MarkLogicユーザー企業の検索アプリケーションのほとんどは社内向けに限定されていますが）。一見していただくと、これは Google というよりもAmazon.comに近いことがわかるでしょう。自社のコンテンツに合わせてカスタマイズされており、また収益化を目的としてデザインされています。

もう1つの例として、BBC Sportのwebサイトがあります。これはほとんど検索アプリケーションには見えません。右上に検索ボックスがあるくらいです。しかしこのサイトのコンテンツはセマンティック検索を活用しており、ユーザーに合わせてかなりカスタマイズされています。

3つめの例は、最近私たちが発表したファーマリサーチハブです。これの技術的基盤は、先ほどと同様MarkLogic^® データハブプラットフォームです。しかし製薬研究データ（遺伝子、化合物、論文など）の検索用にカスタマイズされています。

これらはそれぞれ大きく異なっています。これらを見ると、検索開発者がどれほど強力かつ多様なものを生み出せるのかがわかると思います。

ここでは、まず何をやったらよいのでしょうか。

必要なステップは次のようになります。それぞれについては詳しく後述します。

1. 検索を処理する
2. データを処理する
3. UIに取り組む
4. 通知機能を持たせる
5. モニタリングし改善する
6. エンドツーエンドのセキュリティを実現する

1.検索を処理する

「データクエリアプリケーション」では、ユーザーにかなり助けてもらっています。指定フィールドに入力してもらったり、SQL（のようなもの）を記述してもらうことすらあります。 しかし検索アプリケーションでは、いくつか言葉を入力したら完璧な結果が返ってくることをユーザーは期待しています（Google のように）。以下に、検索アプリケーションにおいて、わずかな情報に基づいてユーザーが何を求めているのかを把握する方法をいくつかご紹介します。

クエリ拡張

単語や語句ごとに、対象ドキュメントに出現する語句の表現をアプリケーション側で追加しておくものです。クエリ拡張の一般的なテクニックとして以下があります。

• ステミング（語幹処理）：ユーザーが「mouse」と入力した場合、語幹が同じ言葉（複数形であるmiceなど）も検索の対象とします。
• 同義語：ユーザーが「account」と入力した場合、「ledger」（銀行のコンテキストの場合）あるいは「description」（ジャーナリズムのコンテキストの場合）も返します。
• タームの拡大/縮小：ユーザーが「タイレノール」と入力した場合、「アセトアミノフェン」あるいは「鎮痛剤」なども検索対象にします。

セマンティック検索

世界や得意分野に関する知識を活用して、検索タームを拡張して関連するタームも含めます。

例えば、今後製造を開始する製品に関する安全基準を調べたいとします。検索エンジンの場合、「心臓カテーテル」と入力すると、この語句が含まれる結果のみが返されます。しかしセマンティック検索の場合、「『心臓カテーテル』は体内埋め込み機器」であり、「『体内埋め込み機器』は『無菌状態』で使用する」といった知識を活用できます。これは重要であり、「心臓カテーテル」で検索した場合、「体内埋め込み機器」および無菌状態で使用するその他の機器に関する安全基準も返すようにできます。

オートコンプリート（入力支援）

ユーザーが入力を開始すると、アプリケーション側が想定する単語・語句のリストを表示します。

この機能によりタイピングが減るため、ユーザーには人気です。アプリケーションにとっても、間違っていない綴り・文字（インデックスが付いている）が使用されるので、好ましいです。またオートコンプリートによってアプリケーションがユーザーを導くことができます（人気順/新着順/ユーザーの分野・業務における重要度などで並べることで）。

ファセット

検索画面に一連のファセットを追加することで、検索対象を明示的に絞り込めます。ほとんどのユーザーはファセットに馴染みがあります。例えば、Amazon.comでは、ブランドや価格帯で検索を絞り込めます。

ファセットでは、アプリケーションがユーザーにさらに作業してもらうようになっていて、データクエリユーザーがフォームに入力するのにちょっと似ています。しかしこの方が、ユーザーが本当は何を探しているのかがさらにはっきりと分かるようになります。ファセット検索はより厳密な検索に適しています。インサイト（検索結果の概要と件数を表示）および検索領域の探索に適しています。

サジェスト

「次の検索結果を表示しています [x]」。サジェスト機能により、アプリケーションはユーザーが本当に言いたかったことを確認できます。例えば、ユーザーが「Apache」と入力した際、「知りたいのはApacheヘリコプター、Apache族、Apacheソフトウェア財団のどれですか」とアプリケーションがユーザーに聞くことができます。

ファインチューニング

開発者は、タームの重み/フィールドの重み/ドキュメントのクオリティなどに基づいて検索結果を並べ替えることができます。最も関連性が高いものを検索結果の一番上に表示できることが重要です。「最も関連性が高い」というのは若干主観的です。これは、ユーザー/ロール/作業中のタスク/検索対象分野/入力された検索ターム/結果のコンテンツによって変わってくるからです。

通常、各結果の関連度（重要度）スコアはTF-IDFに基づいて検索インデックスによって計算されます。

例えば、ユーザーが「president」を検索している場合、検索インデックスは各結果における「president」の出現件数を数えます。これがTF（term frequency：単語の出現頻度）です。またこの単語を含むコーパス全体のドキュメント数も数えます。これがDF（document frequency：ドキュメントの出現頻度）です。珍しい単語の方がより重要なので、インデックスはその珍しさの指標としてIDF（inverse document frequency：逆ドキュメント頻度）を計算します（ある単語がドキュメント2件に1回だけ出現する場合、IDFは1/2。ドキュメント1000件に1回だけ出現する場合は、IDFは1/1000）。 これにより、「president OR Nixon」で検索した場合、「Nixon」を含むドキュメントの方が「president」を含むドキュメントよりも上位に返されることになるでしょう。

検索アプリケーションでは、こういったデフォルトスコアの計算方法をコンテキストやユースケースに応じて開発者がファインチューニング（微調整）できます。

以下に検索アプリケーションのファインチューニングの仕方をいくつか上げておきます。

• ユーザーが入力するタームのいくつかに重みを付けておく。セマンティックグラフによりあるタームが他のものよりも重要だとわかっている場合、またユーザーがそのように言っている場合、このタームに重みを付けます。
• ドキュメント内のいくつかのセクションに「フィールド重み」を付けておく。例えばタイトルに重みを付けておくと、あるタームがタイトルに出現した場合は、本文に出現した場合よりも大きなスコアが得られるようにできます。この作業はクエリ内で行うこともできますし、あるいは常に同一フィールドに重みが付けられるようにインデックスを設定することもできます。
• ドキュメントのクオリティについては後で詳述しますが、基本的な考え方は、検索タームとは無関係に、このドキュメントが他よりも重要である（権威がある/信頼できる）とするものです。
• また「値」（日付や数値）も関連度に影響することに注意してください。例えば、他の条件が同じ場合、最近の結果を上位に表示したいのではないでしょうか。しかし単に新しいだけでは上位に表示したくないはずです。ユースケースや分野にもよりますが、数値を関連度スコアに少しあるいは大きく影響させたいのではないでしょうか（「ニュース記事の検索」 VS 「研究論文の検索」）。また結果を古い順に並べたいこともあるかもしれません（過去のアカウントの検索や特許出願の検索などの場合）。

いずれの技法においても、「コンテキスト」（どのような種類の情報が検索されているか、ユーザーのロール/タスク/関心）が重要になってきます。検索アプリケーションの構築においては、コンテキストの活用を促進することでユーザーの満足度を向上できます。

2.データを処理する

適切なドキュメントやデータを見つけたいユーザーに対してインサイトを与えたり、対象領域を探索できるようにすることで、答えとなるデータが見つかるようにします。注釈（アノテーション）を付けることで、適切な検索によって適切な情報が見つけられるようにします。

情報が「神聖不可侵」（変更せずにそのまま保持しなければならない）場合もOKです。その場合、注釈データをオリジナルへのリンクとともに別途格納することもできます。情報がXMLまたはJSONドキュメントとして保存されている場合はさらに好都合で、オリジナルを論理的エンベロープでラップできます。ここでは、注釈をオリジナルと物理的に同じ場所に持つことができます。またオリジナルはそのままのかたちで保持できます。 これは「エンベロープパターン」と呼ばれます。

「私を見つけて！」「私を見つけて！」

まず最初に、検索にマッチすべきドキュメントを示す「注釈」から始めます。こうするとドキュメント自体が「もし犬（あるいはニクソンや中国）に関する情報を探しているのなら、私を見つけて！」と言ってくるようになります。これにより検索アプリケーションによってデータを（少なくともメタデータに関しては）完全に制御できるようになります。

これは検索のパラダイムをひっくり返すものです。というのもそれぞれのドキュメントに「自分のことを自分で説明せよ」といっているようなものだからです。具体的には、「見つけられるべきときにユーザーにどんなふうに検索してもらいたいか説明せよ」ということです。

役に立つ「私を見つけて！」注釈には、以下のようなものがあります。

• キーワード – この情報を検索する際に、ユーザーが入力しそうな語のリストです。これは「私を見つけて！」原則の一番わかりやすい例です。つまりドキュメント自体がどの検索にマッチされるべきかを指定しているからです。ドキュメントのメタデータのキーワードセクションに「犬」が入っている場合、「このドキュメントは犬に関するものです」と表明されていることになります。この場合、本文にこの語自体が出現しなくてもいいです。「ユーザーが犬について調べているのなら、このドキュメントを提供してください」ということです。昔、ストレージが高価でインデックスが原始的だった時代は、全文検索をするにはキーワードを手作業で追加する必要がありました。今日ではキーワードは最終的な救済策となっています。つまり見つけられるべきレコードがちゃんと見つかるようにするのです。
• メタデータ – 情報についての情報です。例えば出自（情報の入手先）、執筆者、最終変更日などの情報です。
• 分類 – この情報が含まれるグループにタグ付けします。また分類は推論によって行うこともできます。例えば、あるドキュメントをボブ（ラボで働いている）が提供しており、タイトルに薬の名前が含まれている場合、この情報は「ラボ」および「薬」の両方のカテゴリに含まれるでしょう。
• エンティティ – 自由文のなかで言及されている、私たちがよく知っている物事のこと。例えば、「ニクソンが中国に行った」という文章において「ニクソン」はある人物のことを指しており、この人物はおそらくリチャード・ニクソンだということになります。そしてリチャード・ニクソンは米国の大統領でした。この文章を含むレコードに適切に注釈が付けてあれば、「人物」「リチャード・ニクソン」「元大統領」「政治家」などを検索している人がこれを発見できるようになります。

一般的なエンティティタイプとしては、他に会社/組織、場所、物（武器、薬など）、パターン（数値、日付、クレジットカード番号など）があります。これにより、リッチな検索（「北朝鮮から1000マイル以内のアジアの国に、70年代にアメリカ大統領が訪問したことを記述しているレコードをすべて探せ」など）ができるようになります。

エンティティはデータ内にも発生します。データ統合時の問題として、自分たちがどのようなデータを持っているのかを把握していない、ということがよくあります。エンティティを特定することで、どのレコード（の部分）が場所、人、物（武器、薬など）を表現しているのかわかるようになります。

ここまでのところは大丈夫でしょう。検索の開発が順調に進んできて、なかなか良さそうな結果が得られそうです。

しかしこれでも、検索によっては「当たり前だと思われる」ベストな結果が返されないことがあります。例えば、法務データベースで「シチズンズ・ユナイテッド」を検索した場合、一番最初に表示される結果は「シチズンズ・ユナイテッド対FEC裁判、558 U.S. 310」になるべきです。これは対象ドキュメントにおける「シチズンズ・ユナイテッド」の出現回数に関係なくそうなるべきなのです。

この問題に対処するために検索結果をファインチューニングする方法はいくつかあります。

• 「super-keywords」のような新しいキーワードフィールドを追加する。今回の例では「シチズンズ・ユナイテッド」をこのフィールドに追加すれば、検索の際にこのフィールドが最初に確認されます（このフィールドとマッチする検索に「重み付け」する方法については後述します）。
• 「クオリティ」フィールドを追加し、クオリティが高いドキュメントを結果の上位に表示させるようにする。

どのようなコーパスにおいても、レコードによってクオリティは異なります。法務データベースにおいては、「シチズンズ・ユナイテッド」に対する判決自体は、この判決に関する議論よりもクオリティが高くなります。別の言い方をすると、これには「より権威がある（公式である）」と言えます。

web検索において、ラリー・ペイジとセルゲイ・ブリンが「ページランク」アルゴリズムを発明しました。これは、Google 検索の成功の大きな要因となっています。ページランクでは、権威あるページが数多くリンクされているwebページほど権威があるということになります。しかし残念ながら、このリンク分析はエンタープライズサーチでは利用できません。

クオリティはさまざまなものの集合体である可能性があります。例えば、ソース（出典）/著者/ドキュメントタイプなどすべてがクオリティに影響します。このため、大企業の社内wikiページ「社員周知事項」に掲載されている社長によるPDFレポートは、「その他」ページに投稿された作者不明の「覚書」というメモ帳ファイルよりもクオリティが高くなります。

検索アプリケーションでは、ドキュメントのクオリティ設定を完全に制御できます。また検索コーパスに関する自分の知識/ロール/タスク/ドキュメントのコンテンツを考慮できます。

クオリティは完全にドキュメント/レコードの属性であり、ユーザーの検索からは独立していることに注意してください。

• ダイナミックな「スター（星）評価」を各ドキュメントに追加する。理想的には、検索結果に対して「素晴らしい」から「役に立たない」までの評価をユーザーにしてもらうことで、アプリケーションに直接かつ完全にフィードックできればいいです。しかしこれまでの経験によると、ユーザーはわざわざ時間を取って（かつ考えて）直接フィードバックしてくれることはありません。このため手作業をお願いする「スター評価」スキーマは通常は失敗します。しかしここで今取り上げているのは、アプリケーションです。このアプリケーションでは、特定の検索タームに対して結果のドキュメントがうまくいったかどうかを判断できます（またどれが検索とは独立して成功したかどうかも）。下の「すべてトラッキング」を参照してください。
• ズルをすることもできます。つまり「ベスト・ベット（最善の賭け＝一番良いと思われるもの）」をプログラミングして仕込んでおくことも可能です。開発者はアプリケーションが自分の思い通りに動くよう自由にプログラミングできます。このため午前9時前の検索では、結果が「今日のニュース」から始まるようにしたり、ネットショッピングを検索すると「本日のお薦め」が冒頭に出てくるようにもできます。

検索の開発者は、「検索エンジン」およびそのインデックスをリバースエンジニアリングすることで、ユーザーが求めているものを提供するためにかなりの時間と労力を割いています。「検索アプリケーション」では、開発者はいつでもユーザーエクスペリエンスに介入し、自分がしたいように作ることができます。

任意のものから任意のものへ、手作業でマッピングすることもできます。例えば、ユーザーの検索に「シチズンズ・ユナイテッド」という語句が含まれていた場合、結果のトップに必ず「シチズンズ・ユナイテッド対FEC裁判、558 U.S. 310」を返すようにし、「これは2010年1月21日における米国最高裁判所の所見である」という説明を付けることができます。

これはユーザー/分野/ロール/タスクに特化したものです。ユーザーが法学部の学生だった場合、すぐに判決文を見たいと思うでしょう。一方、ユーザーが「シチズンズ・ユナイテッド」に言及したスピーチについて記事を書こうとしている記者の場合、判決文よりもWikiページを見たいかもしれません。

検索（あるいは検索の一部）にベストな結果を割り当てておくこの実践的な手法は「ベスト・ベット」と呼ばれます。ベスト・ベットを追加しておくことで、結果の質およびパフォーマンスが改善されます（ベスト・ベットは検索ではなくシンプルなマッピングであるため）。

3.UIに取り組む

一般的な検索エンジンの結果ページでは、ドキュメントの青いリンクがリスト表示されているだけですが、これをもっと素敵にすることもできます。

このステップは大切なので飛ばさないでください。というのも、これはブラウザの機能や視覚化、またコンテキスト情報を最大活用するチャンスだからです。検索対象領域に関するインサイトや、次に何をすべきなのかのヒントをユーザーに与えられます。

検索結果から、ユーザーは次の2つを知りたいと思うでしょう。「結果の上位には何があるのか？」「結果の全体の様子はどのようなものか？」。

各結果に関する情報

ユーザーは上位の検索結果に関する情報を見て、どれをクリックすれば答えが得られるのかを判断します。結果に関する情報が優れている場合、検索結果を見ただけで十分知りたかったことがわかってしまうこともあります。

各結果の情報（今回の検索で解決したい問題に関するドキュメントやレコード）を表示する方法をいくつかご紹介します。

スニペット

よく利用されている手法として、結果ページの各ドキュメントのリンクの下に「スニペット」を表示します。これはドキュメントの内の数行を表示したもので、検索タームが強調表示されています。スニペットの目的は、一目で「ドキュメントがどんなものか」、「何に関するものなのか」をわかるようにすることです。これにより、これをクリックすべきかどうかを判断できます。

スニペットをよりリッチにする方法を以下にいくつか取り上げます。

• メタデータを追加する – このドキュメントを「書いたのは誰か」、「いつ書かれたのか」、「どのくらいの長さなのか」が表示されていれば、このドキュメントが自分が探しているものかどうかを判断するうえで役に立ちます。
• 情報を追加する – 例えば、著者が自分の会社のCTOだった場合、あるいはその分野の著名人と論文を共著している人だった場合、そのドキュメントは他よりも優れていることになります。ここで問題となるのは、できるだけ多くのコンテキストを利用し、ユーザーが素早くかつ容易に利用できるように表示（視覚化）することです。
• 画像や表を表示する – ドキュメントに含まれていた画像や表をいくつか表示することで、コンテンツの要約をリッチに表示できます。
• 見出しとリンクを表示する – 見出しもドキュメントのある種の要約だと言えます。これにより、ドキュメント内の該当箇所にすぐアクセスできます。
• 「私を見つけて！」注釈を表示する – キーワード、スーパーキーワード、分類、エンティティ。ユーザーは検索結果をちょっと見ただけで、どれを選んだらよいのかを判断することを忘れないでください。つまり、一見して確認できる情報が多い方が良いということです。
• カードなどによる結果ごとの視覚化 – 結果のタイプによっては、スニペットよりも「カード」で表現した方がより効果的です。通常カードは、四角で囲まれたセクションで、検索結果が一見してわかるように効果的なコンポーネント（画像/スター評価/見出しなど）を含んでいます。カードはタイプごとに分類し、「カルーセル」形式で表示できます。カルーセルでは、結果のグループをスワイプして簡単に確認できます。例えば、「Trump news」を Google で検索した場合、3つのカルーセル（トップストーリー/Twitter/ビデオ）が表示され、それぞれにスニペットが付いています。カードの方がスニペットよりもリッチであり、タイプ別の分類に適しています。しかしこれは容量をかなり消費します。最もアクセス頻度が多く、関連性が高く、分類された結果のカードをいろいろ組み合わせて試してみてください。また「その他」にはスニペットを使用します。

結果セットに関する情報

各結果に関する情報に加えて、ユーザーはコンテキストも求めています（「結果セットの全体の様子はどのようなものか？」「ユーザーのタスクに役立つ情報としてアプリケーションは他に何を知っているのか？」）。

ファセット

ファセットについては、ほとんどの人々がAmazon.comなどの小売りサイトで馴染みがあることでしょう。これによって、特定のブランド、価格帯、その他の属性に基づいて検索できます。これについては、検索対象の絞り込み方法の1つとして前述しています。ファセット（および件数）は、結果ページにおいて重要な役割を担っています。これにより結果セットの概要を把握できます。

リコメンデ―ション：似たものを提示する

検索の結果、欲しかったものにかなり近い結果が得られたとします。あるいはユーザーは自分が探していたものを見つけることができたけれど、さらにそれを深堀りしたいとします。ここで、それぞれの結果にリコメンデーションのリンクをつけて、似た結果をさらに提供できます。「似たもの」としては、カテゴリ/メタデータ/エンティティから構成されるものが想定されます。

視覚化：ワードクラウドなど

ワードクラウドは、結果セットにおける最も重要な語を示した画像です。重要なものほど文字が大きくなります。ワードクラウドによっては、色で何らかの内容（感情やエンティティのタイプなど）を表現するものもあります。

関連性（重要度）は通常、この語が出現する結果の件数であり、出現件数とこの語の希少性に基づいて重み付けされていることが多いです（極めて珍しい語が頻出しているものは極めて重要だということです）。ワードクラウドは、結果の概要を示すことができます。つまり「この検索の結果がどのようなものになるのか」を表現します。これがクリック可能な場合、ユーザーが本当に探しているものを提供できます。

ワードクラウドの概念は、さまざな方向に拡張できます。

• タームの共起のクラウド – 他の方法ではわからなかった結果の関係性や意味を発見できます。例えば「ゲータレード」と「インフルエンザ」が一緒に出現することが多いということを発見できます。
• エンティティのクラウド – 結果セット内で言及されている人、場所、モノすべてを「クラウド」として表現できます。より重要な（より一般的な）エンティティは大きく表示されます。人、場所、モノを色分けして表示できます。
• 流行語/エンティティのクラウド – データや検索において出現回数が増えている語やエンティティを色や大きさで表現します。
• カッコ内の数値/日付 – メタデータやマークアップを活用することで、値の一般的な範囲（作成日やスター評価など）を表示できます。
• データの視覚化：グラフ（棒グラフ、円グラフ） – 問いに対する答えは、一連のドキュメントの提示に限りません。検索の結果を、棒グラフや円グラフのようなデータの視覚化で表現した方が良い場合もあります。
• 情報パネル – 検索結果の右隣にパネルを追加し、検索のコンテキストを表示します。例えばユーザーが「マルチモデル」という語で検索している場合、検索アプリケーションはこの語を含むすべてのドキュメントを表示します。しかしこの検索アプリケーションは「マルチモデル」についてそれ以外にもさまざまなことを知っています。これを「情報（ナレッジ）パネル」内に表示しない手はありません。 Google はこれをたくさんやっています。情報パネル内の情報だけで、ユーザーが知りたいことが十分なことも多々あります。そうでなくても、少なくとも結果セットにおけるコンテキスト用ファクトのベースラインが設定されます。
• セマンティックグラフ – 検索のメイントピックをセマンティックグラフとして表現します。情報パネルが検索の概要のファクトを提示するのに対し、セマンティックグラフは検索のコンテキストを提示します。理想的には、グラフのリンクをクリックすることで、ユーザーが検索対象領域をナビゲートできるようになっていると良いでしょう。

4.通知機能を持たせる

検索によっては、新しい情報が発生したらすぐに知らせたいこともあります。例えば、ユーザーがブラジルの石油掘削施設のニュースをトラッキングしているとします。ここでアナリストが、毎日（あるいは1時間ごとに）「石油掘削施設　ブラジル」と検索して、何か新しい情報がないか調べることもできます。

このような保存した検索の利用では、満足いくユーザーエクスペリエンスは得られません。第1に、何か新しいことがないかを確認するために同じクエリを何度も実行しなければなりません。第2に、毎日定時にチェックしている場合、情報取得までに最大で1日の遅れが発生する可能性があります。第3に、新しい情報が大量の結果セットのなかに埋もれてしまい、全く目に入らなかったということも起こりえます。

検索アプリケーションでは、検索を保存して後から実行できます。検索を保存したならば、検索が条件を満たした際に取るアクションを割り当てることができます。「石油掘削施設　ブラジル」の例では、この検索に新しいドキュメントが該当した場合にアラートが出る（画面上のフラグあるいはメール通知）ようにアプリケーションを設定できます。該当ドキュメントが読み込まれるとすぐにアラートが自動表示されます（ユーザーが何もしなくても）。

これを効率的に行うには、使用する検索エンジンにアラート用の特別なインデックスが必要です。多くの検索システムにはベーシックなリアルタイムアラートしか備わっていないため、大規模導入においてはうまく機能しません。

5.モニタリングし改善する

「ユーザーは何を検索しているのでしょうか？」「これらの検索は時間の経過に伴いどのように変化しましたか？」「これらの検索では、適切な結果が返されていますか？」「うまくいかない検索はどのくらいの頻度で発生しますか？」「結果が返ってくるスピードは十分早いですか？」

検索アプリケーションを開発している人は、こういった問いに答える必要があります。さらに、文書化されたしっかりとしたSLA（サービスレベル合意書）を持つべきです。 自分のアプリケーションをこのSLAに照らし合わせて定期的（かつ頻繁）に査定し、可能な限りSLAを向上させてください。

これらの問いについてさらに確認していきましょう。

• 「ユーザーは何を検索しているのでしょうか？」

検索アプリケーションのモニタリングの基本は、各検索のテキストをログとして記録することです。誰かが毎日検索ログを確認すべきです。リストをざっと見るだけで驚くほどの情報が得られます。

例えば、ユーザーが欲しがっている結果は何なのか、人間には当たり前にわかることがよくあります。そのような結果となるように、クエリ/データ処理を改善したり、「ベスト・ベット」を使ったりできます。

でも「ユーザーが数百人もいて、何千もの検索をやっているのですよ。すべての検索をモニタリングするには大量のスタッフが必要です」という声が聴こえてきそうです。アルファテストでユーザーが利用を開始したらすぐに検索のモニタリングを始めてください。パターンを発見したならば、この処理を楽にするスクリプトを書くことができます。しかし成熟したスクリプトがあったとしても、一番多い検索は何なのかを毎日確認すべきです。ほとんどの実装では、上位20～50位の検索がユーザーアクティビティの80％を占めます。

• 「これらの検索は時間の経過に伴いどのように変化しましたか？」

検索タームの変化（スパイクや新しい語）を確認しましょう。

スパイク：例えば、金融サービスのユーザーの多くが突然Ｘ社に関するドキュメントを検索しはじめたとします。これはX社の収支報告や不正、あるいは他の何らかのスキャンダルがニュースになったことが理由かもしれません。このようなスパイクを初めて見た場合、「ベスト・ベット」（上記参照）を追加し、X社への検索を「完璧な検索結果」や「事前に準備されたドキュメントリスト」にマッピングしておけます。

その後、検索内の会社名を特定し、この会社のスパイクが発生したらアラートを出すスクリプトを追加することもできます。

そのうち、この金融サービス企業が収支報告書を発表するたびにスパイクが発生することがわかったとします。この場合、収支報告書発表前日に「ベスト・ベット」を作成しておくことで事前に対応しておくべきかもしれません。

新しいターム：新商品の発表/企業による宣伝/街の噂などによって、新しいタームの検索が始まることがあります。検索ログに対するシンプルなスクリプトによって、新しいタームを特定できます。特定したならば、クエリ処理（同義語、タームの拡大/縮小など）の対象としてこの新しいタームを含めます。

• 「これらの検索では、適切な結果が返されていますか？」

ユーザーの疑問が解決されたならば、検索が成功したということになります。「検索の成功/失敗」の判断基準を決めるのは難しいですが、確認しておくべき事項はいくつかあります。

• • ユーザーが結果リスト内のものを1つもクリック「しなかった」ことをトラッキングする。この場合、結果ページが美しく完璧であったため、スニペットと概要だけで十分だった「可能性もあります」が、実際には、ユーザーはどの結果にも満足せず、他の言葉で検索し直している可能性の方が高いです。

検索ログに、ユーザーと時間のインデックスを付けておけば、このユーザーの次回の検索を確認できます。もしこのユーザーが2、3回検索した後、何もクリックしないで終えていた場合、これはかなりダメな状態です。このような場合、2番めおよび3番めの検索をヒントとして最初の検索を改善してください。

• • どの結果がクリックされたのかをトラッキングする。ユーザーがクリックしたものが結果の1ページめになかった場合は、1ページめに表示されるように調整してください。1ページめにあった場合は、そのランキングがさらに上位になるように調整してください。
  • 結果をクリックしたあとの時間をトラッキングする。ドキュメント検索の場合は、この時間が長いほど良いです。ユーザーがちゃんと結果を読んでいると思われるからです。長文のドキュメントなのに滞在時間が短い場合は、間違った結果であった可能性が高いです。その場合は、スニペットを改善します。
• 「うまくいかない検索はどのくらいの頻度で発生しますか？」

最高の検索アプリケーションでも、検索が「失敗する」ことがあります。SLAをきつめに設定しましょう（最大でも10％以下）。またユーザーからフィードバックが貰える仕組みを追加しておきましょう。ほとんどの場合、ユーザーからフィードバックをもらうのは極めて困難です。とはいえユーザーは最悪な検索結果について文句を言いたがるものです。

• 「パフォーマンスはどうですか？」「検索は速いですか？」

パフォーマンスの現実的な目標値を設定する場合、「何に比べて良い/悪いのか」を考えてください。

理想的には、タスクの最初から最後までにかかった時間を計測し、これと同じタスクをこの検索アプリケーションを使わずに行った際の時間と比較できるといいでしょう。これが絶対的な基準値となります。次に現在のアプリケーション/プラットフォームのタスク時間を、検索アプリケーションプロジェクトの評価フェーズにおいて検討した他のアプリケーション/プラットフォームの（想定）タスク時間と比較します。この際、現在のパフォーマンスを、全然違う作業を全然違うハードウェア上で実行しているほぼ別種のアプリケーション（Google など）と比較しないことが重要です。

またユーザーの期待値を把握しておくことも重要ではありますが、物理的に不可能なものをパフォーマンス目標にはできません（「無限の量のデータに対する検索をほぼ0秒で返してほしい」）。これはすべてトレードオフになります。検索開発者の仕事の1つとして、機能/パフォーマンス/リソース消費量間のトレードオフを計測し、他の人と共有するということがあります。

ここでは少なくとも2つの重要な指標があります。「何らかの結果が表示されはじめるまでの時間」と「結果ページが完全に表示し終わる時間」です。まずは何らかの結果を素早く表示することに注力しましょう。それから残りの部分を時間をかけて表示させるように調整します。

継続的な改善

エンタープライズサーチアプリケーションは継続的に「世話」しなくてはなりません。機械学習はどんどん改善されてきてはいますが、それでもSLAを確認し、クエリ/データ/世の中の変化に応じてシステムを調整していく人員が必要です。

自分の作業のROIに注意してください。完璧は求めず、SLAに大きな改善をもたらすであろう小さくかつ容易な変更を探してください。

他のエンタープライズアプリケーションと同様の導入ルールに従ってください。小さく始めて、関係者と密にやり取りし、合意済みの目標（SLA）に基づいて、継続的にクオリティやパフォーマンスを査定してください。利用者にもっと喜んでもらえるように、さらにカスタイマイズし、結果の可視化を改善し、よりスマートなリコメンデーションを提供できるよう、常に新しいやり方を追求してください。

6.エンドツーエンドのセキュリティを実現する

「まずは『公開済み』のすべての情報を検索可能にすることに注力し、セキュリティについては後から考えよう」というのは誤りです。第1に、想定よりもすぐにセキュリティ問題が発生します。効果的な検索アプリケーションは、一見存在しなかった情報を明らかにするものなのです。第2に、ある段階に到達した際でも、使用中のプラットフォームが必要なセキュリティを実現できると確信できることが必要です。

セキュリティを「情報へのアクセスを制約するもの」だと考えずに、「『データ共有』の管理」の観点から考えてください。セキュリティが優れているほど、共有できる情報も増えます。あらゆる情報へのあらゆるアクセスを制限するのは、とても簡単です。検索の開発者がやるべき仕事とは、「適切な限り最大限の情報に対して最大限のアクセスを提供する」ということです（それ以上のものではありません）。

以下を確認してください。

• ロールベースのアクセス制御（RBAC）：ユーザー/ロールごとに異なるアクセス（読み取り/書き込み/更新）を許可できます。
• 認証と認可：自社の規則に準拠し、会社のディレクトリを活用できるもの。
• きめ細かなセキュリティ：データベース/ディレクトリ/ドキュメントの全体あるいは一部へのアクセスを制御します（題名と概要は一般公開だが全文を読めるのは有料会員のみなど）。
• データベースレベルのアクセスセキュリティ（アプリケーションレベルではなく）。これによりユーザーにはセキュリティ制御が必ず適用されます。
• ファイルシステムレベルの暗号化。アプリケーションが実行されているコンピュータにアクセスできても、このプラットフォームの元となるファイルを読み取ることはできません。

セキュリティのもう1つの要素として、運用上のセキュリティがあります。例えば、情報のバックアップとリストアが必要です。つまり災害対応用に同期コピーを保持し、高可用性システム上で実行することで、障害発生時においてもユーザーが常にアクセスできるようにしておきます。また、テスト/パートナー用に情報の墨塗りコピー（リダクション：一部の機密情報を隠したもの）を提供できる必要があります。

Google ではダメなのか？

お客様と話していると、「うちの社内チームは、情報を探すための社内システムはもう諦めて、単に Google を使っています」と言われることがよくあります。もちろん Google はプライベートデータは扱えないのですが、「なぜ社内のエンタープライズサーチは Google ほど良くないのか」という疑問は出てきます。ここで問題なのは、「エンタープライズサーチは、Google のインターネット検索とは全く違う」ということです。

Google とエンタープライズサーチの違い

Google は、2002年にGSA（Google Search Appliance）でエンタープライズサーチ業界に進出してきました。GSAは、究極にコモディティ化されたエンタープライズサーチを目指していました。Google が送ってきたブラックボックス的なハードウェアを社内イントラネットに接続し電源を入れると、組織内のすべてのドキュメントを発見し、webページから検索できるようになります。

実際には、エンタープライズサーチはそんなに単純ではなく、そんなに同質的なものでないことは明らかです。組織ごとにニーズは違っています。またエンタープライズサーチはインターネット検索と多くの点で大きく異なっています。

• セキュリティ – 社内情報のうち、インターネットで一般公開されているものは比較的少ないでしょう。ほとんどの情報は一般公開されておらず、きめ細かなアクセス制御が求められます。
• 関連度 – Google の強力な機能としてページランクがありました。これはそのページへのリンク数に基づいて、ページの信頼性を計算する関連度アルゴリズムです（逆にこのページにリンクしているページの信頼性も計算します）。これは相互リンクされたドキュメント（ページ）の集合体であるインターネットではとてもうまくいきました。しかし社内の場合、ドキュメント間にはリンク（関連付け）はほとんど/全くありません。また前述のように、ある検索（あるユーザーがある分野において何らかのタスクを行っている）における結果の関連度の計算は極めて難しいだけでなく、各ユーザーごとに関連度（重要性）は違います。

Google Search Appliance は失敗として広く認識され、2016年に終了しました。当時、CMSWire は、「これは明らかに検索のコモディティ化の終焉を示すものだ。またこれはweb検索とエンタープライズサーチは完全に違うという事実をはっきりさせた」と述べています。

Google は確かに速いけれど…

ユーザーの期待値が Google のパフォーマンスを基準としている場合、以下のように反論できます。「Google は確かに速いけれど…」。

• Google がやっていることは、エンタープライズサーチアプリケーションがやっていることとは別物です。検索対象のドキュメントは1種類だけ（webページのみ）です。長年にわたって、Google の結果ページはだんだんとリッチになってきています（カード/カルーセル/情報パネルなど）が、エンタープライズサーチアプリケーションの結果ページほどリッチではありません。これらリッチなものすべて（結果のスニペット/ファセット/情報パネルなど）は個々人のパーソナリティ/分野/ロール/業務に応じてカスタマイズされます。Googleではこれはできません。
• Google のこのアプリケーションは大量のハードウェア（どのくらいなのかは誰も知りませんが、百万台以上のコンピュータと想定されている）とカスタムソフトウェア（博士号を持つ人々によってスタック全体が入念にカスタム構築されている）上で実行され、大量の人々がこれを世話しているのです。

なぜそんなに難しいのですか？ Google ではそんなことはしませんよ。

もう1つの反論として聞かれるのは、「自分でクエリを処理し、データを処理し、全部トラッキングし、関連度を常に調整しなくてはならないのですか？Googleではそんなことはしませんよ」。

実は Google もこういったことを（ほとんどすべて）やっています。最高の結果を得るために、間違いなくクエリを処理しています。またあらゆるものをトラッキングしています（Google の一番の強みは、自らの関連度チューニング用に莫大な量のクエリがあるということです）。そして関連度や結果の表示について常に調整しています。

彼らがやっていないのはデータの処理だけです。Google の人間が、検索対象となるwebページに手を入れて見つけやすくなるように変更することはありません。しかしそもそも、Google はそんなことをやる必要はないのです。というのも、コンテンツを作っている人の方が、SEO対策として自らのコンテンツが見つけられやすくなるように調整してくれるのですから。

Google が期待値を決めている

ここで Google の悪口を言うつもりはありません。Google のインターネット検索は最高です。高速で正確だし、結果ページはリッチで、常に既存の機能を強化しつづけ、新機能（カードやカルーセルなど）を追加しています。

検索開発者は、間違いなくGoogleをお手本にすべきです。Google の機能をフォローし、新機能（カルーセルなど）が追加されたらこれを自分たちの検索アプリケーションに追加することを検討すべきです（エンタープライズ用に味付けして）。自分たちのユーザーに対して、より優れた/パーソナライズされた体験を提供することに注力すべきです。Google が大衆用に最適化している一方、あなたの検索アプリケーションはよりディープでパーソナライズされた検索向けにカスタマイズされたものとなります。

次のステップ

これで素晴らしいエンタープライズサーチには何が必要なのか分かったと思います。それでは開発を始めましょう。

MarkLogic のビルトイン検索についてさらに知りたい方はこちらをクリックしてください。

さらに技術的な内容を知りたい方は、メアリー・ホルスティージによる第一原則に基づく検索の設計のビデオをご覧ください。

開発を始めようとしている方には、無料のトレーニングも提供しています。提供しているトレーニングのほとんどでは、MarkLogic データハブにおける検索を扱っていますが、検索アプリケーション開発に特化したトレーニングクラスもあります。