１. はじめに

　 98年1月29日にInfoNavigatorがロボット系の検索サービスを強化しました。検索力を調べたところ従来より80%アップして985とgooの1,000に対してわずかの差で2位です。3位はInfoseekJで900です。検索サービスはまだ成長期であり、現状がどうなっているのか、今後どのように展開するのかなど流動的な要素が多く誰にも見通せません。

　 ここでは、上記の検索サービスをベースに日本語によるＷeb検索サービスの現状をレポートします。なお、使用したデータは1月31日時点のものです。

２. 検索数からみた推移

　 gooが登場したのは97年3月です。その時から日本の検索力を調査し、データを公開しています。goo、InfoNavigator、InfoseekJについて、検索力のベースになっている15種類の検索キーによる検索総数の推移をグラフ化したのが次の図１です。

　 この図からgooは4月以降データベースの増加はほとんどなく、毎週データがデコボコしており内容を更新していることがわかります。InfoseekJは4月から7月にかけて約7倍になりましたが、8月からゆるやかになり、半年で16%の増加です。InfoNavigatorはInfoseekJの60%位で同様なパターンを示しており、11月から3ヶ月間は更新されず、今回の大幅改造で2位になっています。

　 検索総数が表示される場合には検索力を調査することができますが、総数が示されない場合や上限のある場合には何も手がかりは得られません。このように、検索調査は単に検索総数の統計データに過ぎないのですが、これが継続されるといろいろと有用な情報が得られます。

３. ユニーク率は

　 ユニーク率は検索結果に重複URLを含んでいるかどうかを表します。この問題はすでに解決しており、重複データは除かれていますので調査を行っていませんでした。この機会に改めて調査してみました。

　 意思決定、翻訳、マック、うなぎ、javascriptの5種類の検索結果の最初から500個のデータをとり、その中に重複URLを含むかどうかをチェックしました。そのデータは付録１～３に示します。そして、集計したのを表に示します。gooの場合、alternate表示しますので、実質的には重複ゼロとみなせますし、InfoNavigatorやInfoseekJも完璧に近い結果を示しています。

　 ロボット収集では重複URLはつきものであり、URLが異なっていても、サーバーの変更、ドメインの変更、ファイル名の変更、ミラーサイトなどがあるため、取り除くのは不可能です。重複は少ない方がよいのですが2～3%までの重複はやむを得ないものです。最近、.or.jpから.ne.jpへとドメインが変更されていますが、検索システムには非常な負荷になっています。

４. 索引化率に関する考察

　 ロボット系の場合、収集ページ数は公開されないのですが、今回、InfoNavigatorが収集数1,200万件とWeb上に公開しました。推定ですが、現時点のgooは510万件、InfoseekJは730万件、数週間前のInfoNavigatorは310万件です。なお、AltaVistaの収集日本語ページ数は約640万件です。ここでは検索力と収集数との関係について述べます。

　 ロボットで収集してきたHTML文は検索用に索引が付けられます。日本語の場合、索引化はむつかしく、各検索サービスごとに独自な方法を採用しています。収集した情報が索引化され、検索されるわけですから、大変大まかですが、次の式が考えられます。

　 収集数　×　索引化率　＝　検索力

　 この式から各検索サービスの索引化率を求めると
索引化率＝検索力／収集数
goo 　　　　 １０００／５１０＝１．９６ １００％
InfoNavigtor ９８５／１２００＝０．８２ 　４２％
InfoseekJ 　 ９００／７３０　＝１．２３ 　６３％

　 収集したページから索引を作成するのに、gooが内容の99%を索引しているとすれば、InfoseekJは63%、InfoNavigatorは42%となります。この原因としては、数10KBと容量の大きなページは途中で打ち切るとか、Lycosが採用しているように最初から数10行しか索引しないとか、あるいはストップワードを使うなどが考えられます。収集数を減らして索引化率を高めるのがよいのか、索引化率を減らして収集数を増やすのがよいのかは議論がわかれるところで、簡単には結論がでないものです。

　 なお、InfoNavigatorは収集数が310万から1,200万と約4倍へ、それに対して検索力のデータは277から496へ約1.8倍です。出力結果のDate:をもとに確かめたところ、97年10月以前と以降のデータ数は約1対3でした。したがって、収集数の数値の妥当性が証明？されたとみなせます。しかし、収集数が4倍に対して検索力が1.8倍ですから、索引化率は以前に比べて46%((496/1200)/(277/310))と少なくなっています。この原因としては、大きな容量のページに上限を設けたり、キーワード識別を厳しく(正確に)するなどが考えられます。

５. 日本語処理機能

　 検索サービスはＷeb情報の文字情報を処理します。英文の単語は単語間にスペースがあるため、その識別は容易です。しかし、日本文の漢字の識別は難しく、それが索引化の際にも、検索でキーワードを入力する際にも影響しています。漢字、ひらがな、カタカナ、英字、数字、そして特殊文字が混在していますので、その文字種ごとに調べてみます。

　 5A 数字処理

　 1. 全角と半角の検索数は同じです。したがって、数字の検索には全角、半角のどちらを使っても同じ結果が得られます。
2. InfoNaviとIseekJは時刻のコロンや桁揃えのカンマはつけてもつけなくてもどちらでも同じ結果です。gooはコロンやカンマを付けた場合と付けない場合とでは異なった結果になります。

　 5B 英字処理

　 1. 全角と半角の検索数は同じです。したがって、英字の検索には全角、半角のどちらを使っても同じ結果が得られます。
2. gooとInfoNaviはmarketとmarketsとを厳格に区別します。IseekJは語尾処理するためmarketもmarketsも同じです。
3. gooとInfoNaviは小文字marketも大文字Marketも同じです。IseekJは小文字marketでmarket、Market、MARKETを検索し、先頭が大文字Marketは同じMarketだけを検索します。
4. InfoNaviのデータ数が多いのは英語ページが多いから？

　 5C カタカナ処理

　 1. gooとInfoNaviはプロバイダとプロバイダーとを厳格に区別します。IseekJは語尾に「ー」「－」などがあってもなくても同じです。
2. gooはプロでプロバイダも検索しますが、バレンタインにはバレンタインデーを含みません。
3. IseekJはバレンタインデーもバレンタイン・デーも同じで、「・」を無視します。

　 5D ひらがな処理

　 1. IseekJはひらがなの検索に制約を設けています。
2. InfoNaviは「ございます」は「ござい」以降を無視して、「ござい」で検索します。TITANも同様な処理をします。
3. gooは「プロ」と「プロバイダ」の時と同様に、「ありがとう」には「ありがとうございます」などを含んでいます。
4. InfoNaviは「ありがとう」よりも「ありがとうございます」の方が多く、完全一致したものを検索しています。
5. その他のロボット系で「ありがとう」を検索できるのは、ExciteJ、OpenTextJ、ODIN、Netplaza、Hole-in-One、千里眼、TITANです。

　 5E 漢字処理

　 1. 「旅」で「旅行」を検索しません。
2. 従来は「国内旅行」の検索で「国内 AND 旅行」を検索するのがよい方法でしたが、いずれの検索もAND検索よりも「国内旅行」の方が少なく、フレーズ処理をしています。
3. 「国内旅行」以下の3種類のデータですが、gooとInfoNaviは同じですが、IseekJは異なっています。

６. 基本的な検索機能

　 Web検索サービスがあつかう情報は多量で、そこから情報を引き出すにはしっかりとした検索機能が必要です。一方、ユーザーも、(1)一つのキーを入力する段階から、(2)２つのキーを使ったAND検索の段階、(3)さらにブーリアンといわれる検索式を使った検索の段階、へとシフトしつつあります。500～1,000万件のページをもつ検索サービスはやはり検索式が扱えなければ情報を探せないとみなせます。

　 検索機能の基本中の基本はAND検索、OR検索、NOT検索です。従来、あまりNOT検索は取り上げていませんが、上の５で見てきたように検索キーによっては余分なものを除く必要があります。早速、実際のデータで調べて見ますと、

　 キーＡの検索数をａ、キーＢの検索数をｂ、Ａ AND Ｂの検索数をｃ、Ａ OR Ｂの検索数をｄ，Ａ NOT Ｂの検索数をｅ、とすると、検索数の関係は次のようになります。
　　ａ　＋　ｂ　＝　ｃ　＋　ｄ
　　ａ　－　ｃ　＝　ｅ
gooとInfoNaviは上記の式が当てはまりますので合格です。IseekJは以前に調べたときは上手く処理してましたが現在はOR検索が不調です。

　 各検索サービスの検索機能を次の表にまとめました(Ａ，Ｂは検索キー)。フレーズ機能は海外でもこの１～２年で採用された機能であり、日本語検索サービスで採用しているところは少なく、英語のようにキーワードを二重引用符(")で囲む方法の定着が望まれます。なお、IseekJはかっこを使った検索式を作れませんが、その代わりに文章入力が可能です。

７. タグ内への検索機能

　 ロボットが収集したWebページはHTML文で書かれています。そのHTML文から検索用索引をつくるのですが、HTML文はブラウザで表示されるテキスト部分とテキストの配置やリンク情報などのタグ部分からなります。前節の検索機能はテキスト部分に対するものですが、ここではタグ部分に対する検索機能を調べます。

　 タグにはタイトル、章節、リンクなどあります。タイトルはブラウザ用とページ用の２種類あり、この２種類あることが混乱のもとになっています。さらにページ用はグラフが使われると扱えません。章節はH1～H6を使うわけですが、表現力の問題もあり、現在では章節を使ってなく、検索サービスも扱わなくなっています。リンクは大変有用な情報であり、テキスト部分の処理を必要最低限にしてリンク情報を99%処理するところもあります。テキスト部分を全文処理し、タグ部分のリンクまで処理する検索サービスを第２世代のサーチエンジンとみなしています。以下、その機能をリストします。

　 このタグ関連の検索機能は絞り込み用として検索キーと一緒に使うと有効に働きます。全般的に言えば、gooとIseekJは第２世代のサーチエンジンです。gooの検索機能はタイトルをカバーしてませんが一番優れています。

　 Inktome系列のHotBotは昨年夏にタイトルが選択できるように改善しています。IseekJはコマンド形式ですが、日付とデータ以外をカバーしています。InfoNaviはテキスト部分を全文処理していますが、タグのリンクを扱ってないため第１世代のサーチエンジンとみなせます。タグ内の検索機能は今すぐ必要ないかも知れませんが、大規模なデータベースには必要な機能とみなされます。

８. 検索結果について

　 検索に不慣れで、あまり絞り込み検索をしないと、検索数は何万件となります。すべての結果をブラウズする人はなく、関連性の高い順に表示される、せいぜい３０～４０位をブラウズするだけです。情報を速く探すには、このランキングや紹介文の善し悪しが影響します。

　 ランキングは非常に重要ですが、パラメータを少し変更するだけでまったく別のランキングが得られます。したがって、検索サービス側は絶えず試行錯誤しており、なかなか決め手がないのが現状です。いろいろな分野のランク結果を検証することは必要で、検索サービスだけで考えるのではなく、もっとユーザーが参加して改善できるような仕組みを考えなければと思います。

　 次に紹介文ですが、紹介文とオリジナルのページとを見比べてみれば、どのようなルールで紹介文をつくっているかすぐに見当がつきます。紹介文に関しては、紹介文の作成方法よりはむしろ玉石混交のWebページに問題があるのではと思っていますので、ここではあまり深入りしません。

　 登録系はサイト単位に、一方、ロボット系はページ単位にデータベースを作成しています。IseekJではあまり感じませんが、ロボット系は同じような結果がいくつも出てきて使いにくいといわれます。特に、多くのページを集めれば集めるほど目立つようになります。これは情報を発信する人のページ構成にもよります。30KBの文章を1ページ・1URLにする場合とそれを3KBに分割して10ページ・10URLにする場合などです。後者の場合、キーワードが同じであることから、同じランクのところに表示されます。

９. むすび

　 98年1月29日にInfoNavigatorが機能アップしました。そこで久しぶりに検索の視点を書きました。検索調査などで断片的に取り上げていましたが、今回は検索力の大きい、goo、InfoNavigator、InfoseekJに関して、いろいろな視点から総合的にレポートしました。

　 日本の検索サービスも日本語処理問題を克服してすばらしいものに育ちつつあると実感できました。現在、日本にどれくらいのWeb情報が存在するのかわかりませんが、網羅性の点から乖離しているのは明白です。今回、Infonavigatorが1,200万件収集ということで、他の検索サービスに刺激になり、発展していけばと願っています。

　 最後までお付き合いいただき、ありがとうございました。

付録１. ｇｏｏのデータ

付録２. InfoNavigatorのデータ

付録３. Infoseek Japanのデータ