特集 エンタープライズ・サーチ
「あれ，去年の報告書データ，どこに保存したんだっけ？こっちのサーバーか，いや，こっちかな」。明日の会議で使うプレゼン資料作りに欠かせない データがなかなか見付からない。誰しも，1度や2度はこんな経験をしたことがあるだろう。そんなとき，社内システムにもGoogleのような検索の仕組み があれば話は早い。それが「エンタープライズ・サーチ」だ。やみくもにフォルダやファイルを開いて内容を確認する必要はなくなる。ただし，使いやすい仕組 みにするには，適切なシステム設計と継続的なチューニングが欠かせない。
第1回 社内版“Google”の正しい作り方
エンタープライズ・サーチ製品はこの1～2年，ぐんと充実してきた。並行して，国内での導入事例も徐々に 増えつつある。「社内のシステムを横断的に探し，欲しい情報を何でも即座に取り出せる」。グループウエアや社内Webサーバーなどの広がりとともに，検索 機能へのニーズは着実に高まっている。
個々のユーザーが勝手気ままにフォルダを作り，ファイルを保存してゴミためのようになってしまっているファイル・サーバー，膨大な数の文書が書き込まれているグループウエアや社内Webサーバー，玉石混交のイントラブログ/SNS──。いまや，企業内では数多くのサーバーが稼働し，大量の情報が分散している。その文書の合計数は，必要なデータを探し出すことが難しいと感じられるほどにまで膨れあがっている。
こうした状況下で重要性を増しているのが「エンタープライズ・サーチ」である。いわば社内版の“Google”だ。キーワードをいくつか指定すれ ば，社内にある各種のサーバーを横断的に検索し，瞬く間に該当しそうなデータを探し出して一覧表示してくれる。データが氾らんしている昨今，エンタープラ イズ・サーチは企業情報システムの必須アイテムになりつつある。
この1～2年で製品がぐんと充実
社内利用に向けたエンタープライズ・サーチ製品が登場し始めたのは2000年ころ。社内データの増加を背景に，2005年を境に製品がぐんと増加した。2006年には米オラクルが製品を投入するなど，選択肢が充実してきた（図1，末尾の表1）。
 |
| 図1●エンタープライズ・サーチの動向 2005年ころから企業内検索の製品が増加，2006年には米オラクルが製品を投入するなどさらに充実した。 |
導入ユーザーも徐々に増えている。例えばNTTコムウェアは2007年3月，オラクルの「Oracle Secure Enterprise Search」を導入。社内のファイル・サーバーやポータル・サイトに散在している多様な文書を横断的に検索するシステムを構築した（図2）。検索対象のファイルは約10万に上る。
 |
| 図2●社内に散在している情報を横断的に検索するエンタープライズ・サーチ 多様な文書を検索し，ユーザーの職位や職責に応じて閲覧を制限する。NTTコムウェアが2007年3月に運用を開始したエンタープライズ・サーチのシステムを基に作成。 |
第一の目的は，経営層に経営判断の材料となるデータを即座に探し出せる手段を提供することだった。山田哲夫エンタープライズ・ソリューション事業 本部担当部長は，「システム構築側の論理でメニューを決めるポータルのようなツールだけでなく，情報を探す側の立場にたったシステムが欠かせなかった」と 経緯を語る。実際に導入するにあたっては，営業部門や開発部門にも機能を開放。従業員が部門横断的に文書を検索できるようにした。効果はてきめん。「機密 情報から提案書まで，欲しい情報をすぐに取り出せるようになった」（山田担当部長）。
ただ，役員にしか見られないはずの情報が，検索によって一般社員にまで見えてしまっては困る。NTTコムウェアでは，「まず従業員向けの文書だけ を検索対象として，アクセス権限と検索結果の整合性を3カ月検証した。その上で，経営層向けの文書を検索対象に取り込んだ」（山田担当部長）。
この事例から分かるように，エンタープライズ・サーチでは利用者のアクセス権限に合わせて検索結果を変える仕組みが必要になる。検索対象のファイ ル数が多くなれば，応答性能にも気を配らなければならない。1回の検索に1分も2分もかかるようでは使い勝手が悪い。ユーザーの使い勝手を考えれば，検索 の精度を高めるためのチューニングも欠かせない。
この特集では，応答速度が速く，検索結果の上位に欲しい文書が表示される“社内版Google”を実現する構築ノウハウと，製品選択のポイントを，5回に分けて紹介していく。
 |
| 表1●主なエンタープライズ・サーチ製品 製品名のバージョンは2007年3月現在。 |
第2回 役割は文書の分析・索引・ランキング
各種サーバーに格納されている情報を整理し，情報を引き出せるようにするエンタープライズ・サーチ製品。文書の量やユーザー数によってシステムの設計方法は変わってくる。ポイントになるのは，サーチ・エンジンを構成する三つの基本機能の配置の仕方だ。
エンタープライズ・サーチのシステムは，インターネットで使われている検索エンジンと構造的には同じである。具体的には，（1）ネットワークを介 して検索対象のシステムから文書を収集する「クローラ」，（2）収集した文書からテキストを抽出して索引を作成する「インデクサ」，（3）ユーザーからの 問い合わせに従って索引を調べ，検索結果を返す「サーチャー」という三つのプログラム・モジュールが連携して動作する（図3）。エンタープライズ・サーチ製品は，これに簡易なポータル・サーバーの機能や，アクセス制御を実現するためのディレクトリ・サービス連携機能を持たせてある。
 |
| 図3●エンタープライズ・サーチ製品の基本構造 クローラが文書を収集，インデクサが文書の索引を作成する。サーチャーはユーザーのアクセス権限に応じた検索結果を返す。 |
検索システムの動作はこうだ。クローラは，あらかじめユーザー企業のシステム管理者が設定したスケジュールに基づいて各サーバーにアクセス。この際，サーバーには管理者権限でアクセスするため，サーバー上のすべての文書を収集できるようになっている。
対象がイントラネットのWebサーバーならHTTPでアクセスしてページを取得。グループウエアなら専用のAPIを 介すか，Webブラウザ向けのページにアクセスしてデータを取得する。WordやExcel，Acrobatといったオフィス・ソフトのファイルのほか， 各種グループウエア，Webページなど，よく使われているファイル形式の文書はたいてい収集可能で，製品間で大きな違いはない。
インデクサは，こうして収集した文書ファイルの内容を解析し，索引を付ける。文章を単語に切り分ける技術を使って文書に含まれている単語を抽出。これを索引として文書ファイルと対応付ける。
サーチャーは，いわばエンタープライズ・サーチの「顔」に当たる部分である。エンドユーザーに検索窓のあるWebページを提供し，検索の要求を受 け付ける。この「顔」のWebページは，エンタープライズ・サーチ製品が標準で備えているが，社内ポータルやグループウエアのページに組み込むこともでき る。
検索窓にキーワードが入力されると，サーチャーはこれをインデクサに送信。インデクサが索引を検索した結果を返すと，サーチャーがエンドユーザー 向けの検索結果ページを生成する。この際，結果の掲載順序（ランキング）は，あらかじめ設定したルールに基づいてサーチャーが自動判定する。
検索エンジンはどこに置く？
実際に導入する際には，製品によらず次の三つの点に注意しなければならない。ユーザーのログイン処理，多様なファイル形式への対応，そして検索エンジンの配置という基本設計である。
エンタープライズ・サーチでは，アクセス制御のためにエンドユーザーを検索エンジンにログインさせる必要がある。ただ，検索時にいちいちログインするのではユーザーには面倒。そこで，シングル・サインオン機能を使って検索エンジンへのログイン処理を隠ぺいする。どのエンタープライズ・サーチ製品もシングル・サインオンに対応している。導入に当たっては，検索対象システムとのシングル・サインオン設定が欠かせない。
ファイル形式については，WordやExcelといった一般的なファイル形式の文書は，エンタープライズ・サーチの標準機能だけで検索できる。た だし，グループウエアや文書管理製品を検索対象とする場合には，専用のゲートウエイ・ソフト（アダプタ）をオプションとして別途購入しなければならない製 品が多い。また，ベンダーの独自形式などオプションにないファイル形式に対応させたい場合は，個別に作り込むことになる。費用の観点から「どうしても検索 対象にしたい文書を選んで対応させる」（ネットマークス ストレージネットワーキング事業部グーグル・ビジネス・プロジェクトの久田直彦プロジェクトチーフ）のが得策だ。
数十万超の文書は分散処理で対処
システム設計についてはどうか。考慮すべきポイントは検索対象とする文書の数と応答性能，そしてアクセス制御である。
検索エンジンは基本的に，イントラネットのどこにあっても構わない。専用の検索サーバーを構築してもいいし，検索対象のサーバー上で稼働させても いい。製品によっては三つのモジュールを分散させることができ，例えば社内ポータル・サーバーにサーチャーだけを組み込んで，ほかのマシンで稼働するイン デクサに検索要求を送るようにすることも可能だ。
一番シンプルな構成は，クローラ，インデクサ，サーチャーを1台のサーバーで稼働させるもの。ただ耐障害性を考慮すると，冗長化を図り，負荷分散させるのが望ましい。
検索対象の文書の数が増えてくると，インデクサによるインデックスの作成時間が延び，運用面で問題になる。通常，インデックスの更新は夜間などに バッチ処理する。文書の数が増えればインデックス作成作業が始業時間になっても終わらなくなる可能性が出てくる。そこで考えたいのが3モジュールを別の サーバーで稼働させる方法である。アプライアンス製品を除くほとんどのエンタープライズ・サーチ製品は，役割ごとにサーバーを分けられる構造になっている （図4）。
 |
| 図4●エンタープライズ・サーチ導入時のシステム構成例 ボトルネックになるモジュールを分散配置することで，ドキュメント数の増量や検索速度の向上を図る。 [画像のクリックで拡大表示] |
具体的には，クローラ，インデクサ，サーチャーを別々のサーバーに分散させ，さらにインデックスは複数のサーバーに分割する。検索時にはサー チャーが複数のインデクサに問い合わせた結果をマージしてユーザーに返す。こうしておけば文書数が増えた場合でも，インデックスを追加していくことで理論 上無制限に拡張できる。例えば自社製品を社内導入している日本IBMの場合，「2000万文書を4台のサーバーで運用している」という。
同時に検索要求を出すユーザー数が増えてきた場合は，検索の応答処理にかかる負荷が高まる。この場合は，全く同じインデックスを持つインデクサを複数設置して，負荷分散させる。
第3回 アクセス制御の手法で応答性能が変化
社内システムには，一部の関係者しか見てはいけない機密情報がある。エンタープライズ・サーチを導入するこ とでこうした情報まで一般に公開されてしまうことは避けたい。システム構築に当たっては，検索とアクセス制御機能を連携させる仕組みが必要だ。また導入後 には継続的なチューニングが重要である。
アクセス制御も，応答性能に影響を及ぼす。前述のように，エンタープライズ・サーチではセキュリティの観点から，ユーザーの権限に合わせて結果の表示内容を変える必要がある。このためエンタープライズ・サーチ製品は，LDAPサーバーやActive Directoryといったディレクトリ・サービスを参照してユーザーの権限をチェックする仕組みを備えている。この権限と，それぞれの文書やサーバーに設定されているアクセス制御リスト（ACL）を付き合わせ，検索結果の表示内容を変える。
重要なのは，ACLの参照のしかたによって，サーチャーにかかる負荷やエンドユーザーへの応答性能が変わることだ。方法は大別して2通りある。検 索対象のサーバーにリアルタイムに問い合わせる方法と，各サーバーが持つACLをあらかじめインデックスにインポートしておく方法である（図5）。
 |
| 図5●検索対象文書に対するアクセス制御の実装形態 検索結果を表示する際に，ユーザーがアクセス権を持つ文書のみを検索結果に表示する。 |
リアルタイムに問い合わせる方法では，検索実行時にユーザーのアクセス権限と検索対象のACLを突き合わせ，検査結果からアクセス権限のない文書 を取り除いた応答ページを作成する。最新のアクセス権を検索結果に反映できる点がメリットだが，ACLを持つサーバーへの問い合わせが多くなるため，検索 結果が数千件に及ぶとエンドユーザーへの応答性能が劣化しやすい。
ACLをインデックスにインポートする場合は，エンタープライズ・サーチのシステム内で検索処理が完結する。インデックス作成の負荷は高まるもの の，「アクセス権が変わるのは，部署の異動や昇格など。1日に1回，夜間に更新すれば実用上はタイムラグはない」（アクセラテクノロジの進藤達也社長）。
実は，どちらの方法を選ぶかは，利用する製品によって決まる場合が多い。ほとんどの製品はACLにインデックスをインポートするようになってい る。ただ，中にはインデックスにACLを取り込んだうえで，一部の検索対象についてだけリアルタイムに照合する仕組みを加えられる製品もある。
ランキング・ルールのチューニングは不可欠
もう一つ考えておかなければならないのが，検索結果のランキング方法。ユーザーが求めている情報をどれだけ的確に，かつできるだけ上位に表示する かである。ビジネスサーチテクノロジの城野洋一・代表取締役COOは，「企業で導入する場合，ランキング・ルールをチューニングする案件がほとんど」とい う。
ランキングでは，複数のルールを基に個々の検索結果にスコアを付ける。どの製品もランキング・ルールを複数持ち，ユーザーはこれを組み合わせて使 う。例えば「一致する単語の数が多い」「出現位置が先頭」といった一般的なテキスト解析の結果を基にスコアを算出する。さらにテキスト以外の指標として， 「リンク文字列との一致」「ファイルの種類がプレゼンテーション・ファイル」といった基準を用いて最終的なスコアを合算する（図6）。
 |
| 図6●検索結果の順位付け（ランキング）に使う主な情報 ユーザーが求める文書をできるだけ上位に表示するために，文書内容だけでなく文書に付随する情報を活用する。マイクロソフトの「Microsoft Office SharePoint Server 2007」が採用するアルゴリズムを基に作成。 |
このほか，Googleで一躍有名になった「Page Rank」がある。「リンクされた数が多いほど価値のあるドキュメント」「価値のあるドキュメントからリンクされたドキュメントは価値が高い」という考え に基づいたものだ。ただ企業内でPageRankが機能するのは，文書間のリンクが張り巡らされた社内ポータルに限られる。ファイル・サーバーに格納され たファイル群のように，それぞれ孤立した文書を検索対象とする場合には適さない。
また，ランキングの精度を上げるには，導入後のチューニングが欠かせない。ユーザーの利用状況を把握し，ランキングのルールを見直すのである。実 際，「構築して1カ月ほど経つと，利用状況を踏まえたチューニングに本腰を入れ始める」（日本IBM ソフトウェア事業インフォメーション・マネジメント事業部CM営業部の中島冴香氏）という。
ユーザーの利用状況を把握するには，例えば入力された検索キーワードの履歴を分析する（写真1）。ユーザーのニーズが高い文書が分かれば，そのスコアを高めるチューニングを施したり，全社ポータルに「有用な文書」として紹介したりすることもできる。管理不要をうたう製品であっても，ユーザーの工夫次第で検索結果の精度を上げられる。
 |
| 写真1●米グーグルの「Google検索アプライアンス」の管理画面 ユーザーの利用動向や文書収集の状況などを把握できる。 |
また「多数のユーザーが検索したがヒットする文書がない」キーワードを管理画面で見つけ出し，インデックス化に失敗しているのか，そもそも見合った文書が存在しないのか，といった調査を実施するのも手だ。
第4回 製品選択のイロハを知る
一言にエンタープライズ・サーチといっても製品によって機能が異なる。製品の選択ポイントは，大規模システムに対応できるか，エンドユーザーの使い勝手を高める仕組みがあるかなどである。製品によって異なる検索技術を採用しているため、これが使い勝手に影響する。
ここまで見てきた機能は，現在市場にあるエンタープライズ・サーチ製品の多くが備える。ただ，製品によってアーキテクチャや細かな機能に違いがあり，対象ユーザーも異なる（表1）。具体的には，導入の容易さを重視する製品，数千万超の文書を扱える大規模指向の製品，キーワードと完全には一致しない単語を含む文書を検索する「あいまい検索」を特徴とする製品，ほかのユーザーが使ったキーワードの組み合わせを参照できるなど「検索ノウハウを共有」できる製品，といった具合だ（図7）。
 |
| 表1●主なエンタープライズ・サーチ製品 製品名のバージョンは2007年3月現在。 [画像のクリックで拡大表示] |
 |
| 図7●エンタープライズ・サーチ製品の分類 設計思想の違いから大きく4タイプに分類できる。 [画像のクリックで拡大表示] |
導入の容易さを全面に押し出す製品の代表格は，ハードウエアと一体提供するアプライアンス型の製品（写真2）。「Google検索 アプライアンス」や「Google Mini」，「QuickSolution Express」がこれに当たる。特に薄型サーバー1台で最大30万文書まで検索できるGoogle Miniは，エンタープライズ・サーチの認知度を一気に引き上げた。
 |
| 写真2●グーグルの「Google検索アプライアンス」と「Google Mini」 導入の容易さを全面に押し出すアプライアンス製品の先駆けとなった。 |
全社導入はもちろん，試験的に導入して使い勝手を試す用途にも有用だ。「文書を“捨てる”ために導入するユーザーもいる」（住友電工情報システム システム営業部の伊藤彰康チーフマネージャー）。利用価値がなくなった文書や重複ファイルが散在しているような場合に，検索結果を基に無駄なファイルを削 除していく。エンタープライズ・サーチ製品の多くが文書数やサーバー数に応じて課金するライセンス体系を採っている。このため検索したい文書を絞り込むこ とで，本格導入時の費用も下げられる。
拡張性を考えるなら大規模指向
Google Miniなどの対極にあるのが，IBMの「OmniFind」，オートノミーの「IDOLサーバ」など大規模指向の製品である。クローラ，インデクサ，サーチャーを独立させられるなど，全社，あるいは企業グループ全体への導入を視野に入れている。
「この1～2年で対象が数億文書という大規模な案件が増えてきた」（日本IBM ソフトウェア事業インフォメーション・マネジメント事業部ECM営業部の田中良幸部長）というように，最近はエンタープライズ・サーチを大規模展開する例 が徐々に出てきている。ストレージの容量に換算すると，「10Tバイト，20Tバイトはザラ」（サイバーソリューションズの秋田健太郎社長）である。導入 時には小規模展開でも，将来的に拡張する可能性があるなら，こうした大規模指向の製品を選ぶ方がよいだろう。
なお，アプライアンスであっても小規模向けとは限らない。Google検索アプライアンスはラックごと提供するタイプ。1ラックに収まるサーバー 台数でカバーできる3000万文書が仕様上の上限だが，「サーバー台数を増やすことで3000万以上の文書にも対応可能」（グーグル エンタープライズ セールスの大須賀利一マネージャー）だ。
エンドユーザーの習熟度見極めも重要に
エンドユーザーの多くが「検索時のキーワード選定でキーボードを打つ手が止まる」（ジャストシステム システム営業推進グループの高瀬雅利グループマネージャ）というような場合は，検索のノウハウを共有できる製品が便利だ。ジャストシステムの 「ConceptBase !)」は，検索条件を利用者間で共有する機能を持つ。
人づての情報を探せる製品もある。マイクロソフトの「Microsoft Office SharePoint Server 2007」は同製品のSNS機能が持つプロフィール欄の情報を検索できる。「特に大企業では人を検索するニーズがある」（インフォメーションワーカービジ ネス本部の昇塚 淑子エグゼクティブプロダクトマネージャ）。
ウチダスペクトラムも，2007年第2四半期に出荷を予定する「SMART/InSight」次期版にブログ連携の機能を追加する（写真3）。検索結果の一覧に，ブログやソーシャル・ブックマークへの連携ボタンを配置。ユーザーが「役立った」と判断したデータをブログやソーシャル・ブックマークに備忘録として記録できるようにする。
 |
| 写真3●ブログの記事作成やソーシャル・ブックマークへの登録ボタンが検索結果に ウチダスペクトラムが開発中の画面。 |
こうした機能を必要とするかどうかは，エンドユーザーのパソコンやインターネットに対する習熟度などによって異なる。使い勝手に関するエンドユーザーのニーズを見極めることが肝心である。
第5回 ライセンス体系次第でコストが激変
エンタープライズ・サーチ製品の選択に当たってはライセンス体系に気を配っておきたい。検索対象の文書数，サーバー/CPU数など、個別の製品によって体系は大きく異なる。さらに製品の使い方次第では導入コストが大幅に違ってくるので注意が必要だ。
製品選択に際しては，ライセンス体系も押さえておきたい。製品価格がサーバー台数で決まるもの，対象文書数で決まるものなど，ライセンス体系は様 々である。例えば法律事務所のように文書数は膨大だが利用者数が数人というようなケースでは，サーバー・ライセンスが有利。逆に文書数が少なく利用者が多 い場合は，文書数に応じて段階的に価格が変わる方が無駄な費用を払わずに済む。
特徴的なライセンス体系を持つのがウチダスペクトラム。ユーザー数と文書数，または同時利用ユーザー数とインデックス容量に応じて年次利用で課金 する。「導入初年度に共通費で導入し，効果を見定めつつ次年度から部門の予算で順次拡大していくようなユーザーを意識したライセンス体系」（町田潔社長） となっている。
「容量」で価格が決まる製品もある。例えば文書から抽出したテキストの容量である。数Mバイトのパワーポイント形式（.ppt）のファイルであっ ても，インデックス・データベースに格納するテキスト成分の容量は数Kバイト程度に過ぎない。住友電工情報システムの製品では10Gバイト，30Gバイ ト，1Tバイトとテキスト容量で価格が変わる。文書数に換算すると1000万件，3000万件，10億件程度になる。
総じて文書の数が多い場合は，検索対象に含める文書を導入前に整理する作業も費用の削減に効果がある。拡張子やフォルダ，サーバー単位でリスト アップしておけば，無駄なファイルをインデックスに格納するコストを減らせる。製品によっては，価格の安い下位版を選択する余地が生まれる。「文書を整理 する手間をかけたくないから導入する」（複数のベンダー）という場合は，アプライアンス型の製品や下位版の製品を導入して，サーバーやフォルダごとにファ イルを検索，重複や古さの目立つ文書を見つけて整理したうえで本格導入する手もある。
|
No comments:
Post a Comment