情報要求の 4 レベル

Google だったり、Yahoo! だったり、毎日何らかの情報を求めて、検索ってやってると思う。このとっても日常的な検索という行為をすこし考えてみたい。

R. S. Taylor の 1968 年の論文（Question-negotiation and information seeking in libraries）において、人間の情報要求（information need）が 4 つのレベルに分類されている。『言語と計算 - 5 情報検索と言語処理』（徳永健伸）から抜粋。

1. 直感的要求（visceral need）
   現状に満足していないことは認識しているが、それを具体的に言語化してうまく説明できない状態
2. 意識された要求（conscious need）
   頭の中では問題を整理できるが、あいまいな表現やまとまりのない表現でしか言語化できない状態
3. 形式化された要求（formalized need）
   問題を具体的な言語表現で言語化できる状態
4. 調整済みの要求（compromised need）
   問題を解決するために必要な情報の情報源が同定できるくらい問題が具体化された状態

ちょっと複雑な言い回しなんで、ちょっと簡単に翻訳してみる。

1. 直感的要求（visceral need）
   おなかが空いたなあ。
2. 意識された要求（conscious need）
   おなかが空いたんで、そろそろなんか食べたいんだけどな〜。なんか、こってりしてて、おなかにたまりそうなものがいいなあ。
3. 形式化された要求（formalized need）
   近場のラーメン屋で豚骨ラーメンでも食べようかな。こってりしてれば、丼ものでもいいかな。
4. 調整済みの要求（compromised need）
   そうだ、高田馬場のすた丼にしよう！
   

これを各レベルで、ウェブ検索してみようと思うと……。

1. 直感的要求（visceral need）：おなかが空いた
   なんと検索すればいいのかわからない……
2. 意識された要求（conscious need）
   「こってり」、「おなかにたまる」？　いまひとつピンとこない検索語……
3. 形式化された要求（formalized need）
   自分がいるのは「新宿」だから、「高田馬場」ぐらいまでは行ってもいいかな。ならば、場所の検索語は「新宿」か「高田馬場」。食べたいものは、「ラーメン」か「丼」。
4. 調整済みの要求（compromised need）
   検索語は決定。「高田馬場」と「すた丼」。

……こんなところだろうか。ここまでピンポイントに食べたいものが決まっちゃえばいいけど、欲しい検索結果が出てくるような検索語が思いつかないなんてことはよくあること。

「調整済みの要求」や「形式化された要求」ならともかく、それ以前のレベルだったりしたら、検索語の決定すらおぼつかない。コレならどうかな？　じゃあ、アレは？　……といろいろ試しているうちに、「調整済みの要求」や「形式化された要求」に近づくヒントらしきものが見えてきたり、偶然欲しいものにたどりついたり。

先日、こんなことがあった。サイト全体の HTML ファイルに共通のフッタ外部ファイルとして JavaScript で埋め込んでいる。そのファイルを毎回サーバから呼び出して、ちゃんと読み込んでほしいんだけど、ブラウザによっては PC の中に溜め込んだ情報（ローカルキャッシュ）を読み込んでしまって、こちらの希望する結果が得られない。ローカルキャッシュを読み込まないような回避策が欲しい。

これなんかは、まさに「意識された要求」レベル。せめて「形式化された要求」レベルにすべくいろいろ検索語を考える。「キャッシュ JavaScript 回避」、「JavaScript 外部 キャッシュさせない」、「no cache 外部ファイル インクルード」……などなど。検索語をとっかえひっかえ検索してみるが、なかなかびしっと決まるキーワードが思いつかない。

現在のウェブ検索は、基本的には「調整済みの要求」に対応するもの。検索結果ページに表示されたテキストを参考にしていけば、「形式化された要求」にもある程度は答えてくれる。しかし、それも知識と経験に基づいた人間からの歩み寄りによってしか実現されないことも多い。つまり、検索とは、既知情報から既知情報を経由して未知情報を探し出すこと……と定義されるものなのかもしれない。既知情報からしかスタートできない……このあたりが、キーワード検索の難しさなんだろうね。

追記：
……とかなんとか書いていたら、きょうの TechCrunch におもしろい記事が。

Powerset検索エンジンのデモ、初公開

記事によると、「在職中に亡くなった政治家（politicians who died in office）」といったフレーズで満足のいく検索結果が表示されると言う自然言語処理を応用した新しい検索技術だとのこと。この一例をもってどうこうう段階ではないけど、情報要求のより曖昧なレイヤーまでカバーできるようなものが今後登場してくるのかもしれない。

クローラの届かない世界：深層ウェブ

「深層ウェブ」（deep web / invisible web / hidden web）という言葉を聞いたことがあるだろうか。Michael K. Bergman が唱えた検索エンジンでは索引化することができないコンテンツのことだ（Bergman の論文は、こちらから日本語訳で読むことができる）。Bergman の論文（ちょっと古いので数値データは参考にならないけど、テーマは現在でも通用するもの）では、検索フォームから検索文字列の入力によって動的に生成されるコンテンツを指すが、英語版の Wikipedia の Deep Web の項によると以下のような分類に含まれるものとしている。

• 動的コンテンツ
• リンクされていないコンテンツ
• アクセスの制限されたコンテンツ
• スクリプト化されたコンテンツ
• 非テキストコンテンツ
  

確かにこれらは、検索エンジンが索引化するには敷居の高いものたちだ。07/05/25 の「検索エンジンってどんなもの？」で簡単に説明したように、検索エンジンの利用している索引は、クローラと呼ばれる装置によって収集されている。クローラは、種文書を読み、そこに記述されている別のページへのリンクをたどって、そのページを読む。各ページを読む過程において、主にそのページのテキストコンテンツを記録していく。これが検索エンジンの索引として利用されている。なので、

• 動的コンテンツ
  検索文字列を入力して、データベースなどから情報を取り出し、ページを動的に生成するもの。クローラには検索文字列は思いつかないので、索引化することが難しい。
• リンクされていないコンテンツ
  クローラはリンクをたどるものなので、リンクされていないとアクセスできない。サイトマップに記載されていれば、一般に公開されているページからリンクされていなくても、アクセスできるだろうが、それにしたってサイトマップからのリンクはあると言える。
• アクセスの制限されたコンテンツ
  リンクがはってあっても、ユーザ名とパスワードがわからなければ、入りこみようがない。
• スクリプト化されたコンテンツ
  Flash などに含まれるテキストは読めないし、JavaScript にリンク先のページの URL が仕込まれていても入っていきにくい。
• 非テキストコンテンツ
  画像や動画、バイナリーデータなど（MS Word や Excel、PDF なんかだったら、Google とかは解析しちゃうけど）。

……といった状況や理由でこうしたコンテンツは、検索エンジン（クローラ）泣かせと言われている。

今回フィーチャーしたいのは、その中でも「動的コンテンツ」だ。Bergman の論文でも主に取り上げられているのは、この動的コンテンツの部分。いわく、「深層ウェブには、表層ウェブの 500 倍のデータがある」、「深層ウェブの情報は品質の高いものが多い」……とのこと。量的な話で言えば、500 倍が正しいかどうかはわからないが、でも直感的に言って相当量あることはまちがいない。検索エンジンはともかく、ウェブ上で一般公開されているデータベースサービスなんてのは山のようにある。書誌情報を元に書籍の検索サービスを提供している Webcat Plus とか、ローソンの店舗検索とか、中古カメラの検索とか……。まさに枚挙にいとまなし。

こういうデータベース検索サービスの大きな分かれ目が、前回の「URL のよくわかんないアレ」でも取り上げた「GET」と「POST」だ。おさらいしておくと、大雑把に言って「GET」は「?」とか「&」とかよくわかんない記号がごちゃごちゃっとくっついている検索結果ページなんかを表示するやつ。「POST」はそんなののないすっきりしたやつ。見栄え的には、すっきりしているのがいいけど、URL による検索結果の再現性がないのが「POST」のイタイところ。

「POST」の再現性のなさの話。さっき例に挙げたローソンの店舗検索（http://map.lawson.co.jp/c/f）。Step 1 は無視して、Step 2 の「住所」にサンプルに従って、「町田市」と入力して検索。「町田森野一丁目店」を筆頭に 17 件の検索結果が表示される。そのときの URL が、「http://map.lawson.co.jp/c/f/」。さらに、「町田森野一丁目店」の詳細情報を見るべく、リンクをクリック。詳細情報ページの URL は、「http://map.lawson.co.jp/c/f/」。友だちに「町田森野一丁目店」の詳細情報の URL を教えようと思ったら、「http://map.lawson.co.jp/c/f/」を教えるしかない。教えられた友だちは、その URL をクリックする。すると、ローソンの店舗検索のトップページが表示される。これが、「POST」データの再現性のなさということ。

もうすこし詳しく見てみる。ここにはクローラにとって二段階の障壁がある。ひとつめは、「町田市」のような検索文字列の入力。もうひとつは、「町田森野一丁目店」のリンククリック。クローラが検索質問を自発的にしない以上、ここから先に進みようがない。「町田森野一丁目店」はクリッカブルな状態になってはいるものの、JavaScript を実行しなければ、検索結果が表示されないので、クローラには侵入不能。

「町田森野一丁目店」のページには、店舗の住所とか詳細情報が掲載されているので、それをキーワードにして検索してみる。試しに店舗名と電話番号で。Yahoo! JAPAN → 0、Google → 0。要は、「町田森野一丁目店」は索引化されておらず、深層ウェブの底に沈んじゃっている状態ってことだ。検索文字列を「店舗検索」として検索した結果、ローソンの店舗検索トップは、Yahoo! JAPAN で 1 位、Google でも 2 位の表示順。こんなにハイランクなのにクロールしてもらえないってのは、なんかもったいない気がするなあ（店舗数が多すぎるってのもわかんなくはないけど）。SEO の大前提で、「POST」でなく、「GET」がオススメされる理由はコレ。「GET」で呼び出せる動的ページであり、静的ページにその呼び出しのための URL がリンクとして記載されているとクローラにやさしいページになる。

次にピックアップするのは、クローラが、ごちゃごちゃした URL を嫌うと言う話。前に「検索エンジンってどんなもの？」を書いたときには、省略してしまったけど、索引を作るときに「重複ページの削除」という仕事もやっている。要は同じ内容のページを削除するということ。複数社のブログサービスを使って、一言一句変わらない同じ記事を書いたりする人がいたりして、それはそれで鬱陶しいんだけど、これは別次元の話。例えば、以下の URL。Ask.jp で「apple」とウェブ検索した結果。URL は微妙に違うけど、全部得られる結果はすべてまったく同じ内容。

1. http://ask.jp/web.asp?o=0&qsrc=3&ln=ja&q=apple&btnWeb.x=11&btnWeb.y=7
2. http://ask.jp/web.asp?o=0&qsrc=3&ln=ja&q=apple&btnWeb.x=67&btnWeb.y=2
3. http://ask.jp/web.asp?o=0&qsrc=4&q=apple&btnWeb.x=39&btnWeb.y=11&ln=ja&ps=
4. http://ask.jp/web.asp?o=0&qsrc=96&q=apple&hq=&btnWeb.x=46&btnWeb.y=10

ユーザとしての作業は以下のとおり。

1. Ask.jp のトップページで「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンの左上の方をクリック
2. Ask.jp のトップページで「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンの右下の方をクリック
3. Ask.jp のウェブ検索の検索結果ページの検索フォームに「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンをクリック（場所は意識せず）
4. Ask.jp のブログ検索の検索結果ページの検索フォームに「apple」と入力し、検索フォーム下にある「ウェブ検索」ボタンをクリック（場所は意識せず）

1 と 2 の違いは、「btnWeb.x」と「btnWeb.y」の値の違い。1、2 と 3 や 4 の違いは、「qsrc」の違い。ユーザにとって重要な意味を持つのは、「http://ask.jp/web.asp」というプログラムへのリクエストであるということと、「q=apple」という検索文字列だけ。実際問題、必須要素だけを残した「http://ask.jp/web.asp?q=apple」でも同じ結果が表示される。人間だったら、なんとなく想像してこうやって URL の単純化もできちゃうけど、クローラにまでその判断をして、重複ページを削除しろというのは厳しい話。そんなことをやっている間に、他にやらないといけない仕事は山のようにある。これが、SEO のコンテクストで「カタログページの URL は、Amazon みたいにした方がいいですよ。検索エンジンに嫌われますよ」とよく言われる所以。Amazon の検索結果は、URL に含まれる「?」や「&」がかなり少ない。無作為にいくつかの書籍の URL をチェックした見たけど、「ie=UTF8」というのと「s=books」だけだった。

特別な理由がなく、かつ持っているデータを検索エンジンに索引化してもらいたいんだったら、フォームはとにかく「GET」。静的ページからのリンクも用意。さらに、プログラムの引数（URL に含まれる「x=yy」みたいなもの）もシンプルに。でないと、コンテンツは深層ウェブから引き上げられる可能性は極めて低い。

こういう目で見ていくと、Wikipedia のURL は極めてシンプル。英語版の Wikipedia の URL は、「http://en.wikipedia.org/wiki/Apple_Computer」。以前だったら、Wikipedia なんてのも「良質なコンテンツなんだけど、深層ウェブだから、Wikipedia に行って検索しなきゃいけないんだよね〜」となってたところなんだろうな。この辺の設計が、Web 2.0 時代の CMS（コンテンツマネジメントシステム）って感じがするな〜。

※この記事に記載した URL の数々。けっこう途中で切れちゃってるけど、ちゃんとリンクは生きている（はず）。

検索エンジンってどんなもの？

「検索エンジン」という言葉が、一般的に広く用いられるようになってひさしい。Yahoo! や Google が提供しているウェブ検索サービスのことを指示する場合がとても多い。別にそれだけが検索エンジンってわけじゃないけど、まあ代表格のようなものだから、これはこれでよしとする（きょうのところは）。「検索エンジンに登録されたら、うちのサイトも PV が上がっちゃって」……なんていうアレ。きょうはこのあたりについて簡単に説明しておこう（いろいろ書くにあたって、そろそろ簡単にでも説明しておかないと都合が悪くなってきた。。。）。

ウェブ検索のユーザに支配できる部分はごく一部に限られている。

• キーワードを入力する
• 検索ボタンをクリックする
• 検索結果が表示される
• ページタイトルや URL、ページコンテンツの抜粋を閲覧できる
• ページタイトルや URL をクリックすると、そのサイトを閲覧できる
  

これを実現するためにどんなことが裏側でおこなわれているか……という話。ごく簡単に書くと、こんな感じ。

1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく
2. 採取されたページコンテンツは、URL を基準に整理され、分析される
3. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス（索引）化される（形態素解析しない場合もある）
4. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する
5. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される

ざっくりとした説明なので抽象的なところも残っている。もう少し詳しく見ていこう。

1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく

クローラの業務内容は比較的シンプルなイメージで説明できる。

• ウェブページを開く
• そのページを保存する
• そのウェブページに書かれているリンクをたどって、別のページに行く

の繰り返し。どこから見ていくかということなんだけど、その元になるのが「台帳」。この「台帳」のことを「Seed」（種）と言う。イメージとしては、巨大なブックマークリスト……が近いだろうか。これを見ながら、次から次へとページを渡り歩いて、ページコンテンツ採取をコツコツとこなしていく。そうしてデータが集まってくると、

2. 採取されたページコンテンツは、URL を基準に整理され、分析される

このページとあのページがリンクされているとか、外部のサイトにリンクしているとか、このページは他のページからどれぐらいリンクされているか（被リンク）……といったリンク構造や、ページの作成日（更新日）などの分析がおこなわれる（Google の有名な Page Rank の基礎データもここで取得できるものなんじゃないかな）。次に、

3. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス（索引）化される

どんな形態素解析処理（Cf. 「コンテンツ連動型広告の仕掛けを考える〜その弐」）をおこなっているのかは、検索結果ページからちょこっと見られたりする。Yahoo! JAPAN の場合だと、検索結果に「キャッシュ」っていう地味なリンクがあったりする（必ずあるわけじゃない）。そこを開いたときに、ページ上部にボックスが表示されて、そこに自分の入力したキーワードに何色かの背景色が付いて表示されているのを見たことがあるんじゃないかな（本記事の画像をクリックするとサンプルが見られる）。ユーザとしては、それを元に検索結果ページのどこにその文字列がどこに記述されているかが、背景色でハイライトされているので、見つけやすい……と言った用途に使うもの。実は、コレが形態素解析の結果。たとえば、「現代用語の基礎知識」だと、

• 現代
• 用語
• の
• 基礎
• 知識

……と分解される。採取されたページコンテンツ（テキスト）は、こんな風にバラバラに解体されて、ウェブ検索のインデックス（索引）データとして利用されているわけだ。つまり、「現代用語の基礎知識」という検索文字列で検索した場合には、「現代」「用語」「の」「基礎」「知識」が含まれているページが検索されることになる。たまに「インデックスがアップデートされた！」というニュースが出たりする（SEO 業界を中心にちょっとした騒ぎになることもしばしば）けど、このインデックスの更新が意味するところは、ここで紹介したような内容（同時に新規ページのインデックスへの追加やなくなってしまったページのインデックスからの削除もおこなわれる）。

こうして索引ができて検索可能になった段階で、

4. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する

……ことになる。ココの部分が、狭義としての「検索エンジン」ってことになるんだろう。抽出すればそれでオシマイと言うわけではないのが難しいところ。いかにして、ユーザが探したいものを最短の時間、最小の労力で提供するかというのがサービスとしての検索の要となる。

5. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される

……が重要となるわけだ。やはり単純にサービスを使う立場としては、いち早くお目当ての結果にたどりつきたい。「検索結果は、Google がいいね」とか「いや、Yahoo! も最近はかなりいいよ」とかそういう文脈で語られる良し悪しの多くは、ここの結果のアウトプットに起因する。大量の検索語でひとつひとつの検索結果を各社のサービスで調べて、一定のルールでそれらを評価すると、それなりの結論は出るようにも思うけど、ユーザの主観やそのときのユーザの意図によって印象は変わってきてしまうものではある。また、同じ会社のサービスであっても時期によって、チューニングが異なっていたりするので、一概にどこのサービスがいいというのは難しい。じゃあ、何をベースにチューニングするかということなんだけど、メジャーなものとしてはこんなものがある（個人的におもしろいなと思う順番に）。

• どんなキーワードでそのページがリンクされているか
  有名な例としては、「18歳未満」で検索すると、Yahoo! JAPAN のトップページが上位にランクされる……というヤツ。アダルトサイトとかで「18歳未満はこちら」というテキストリンクが、Yahoo! JAPAN などに誘導するというケースが多い）
• 検索キーワードの近接性
  「中華料理」での検索だったら、そのままズバリの「中華料理」と書かれているページの方が、ページのどこかに「中華」とか「料理」とかバラバラに記述されているものよりも関連度が高いだろうという考え
• そのページがどれだけのページからリンクが張られているか
• そのページがどれだけ人気のあるページからリンクが張られているか
  SEO 業者が「まずはYahoo! JAPAN のディレクトリ登録を」とオススメしてくる根拠
  
• 検索キーワードのそのページでの扱われ方
  SEO のテクニックでよく言われる「H1 タグで囲まれていると評価が高い」……とか言うアレ

……などなど。どの要素をどれだけ重視するかというのがチューニング。SEO 業者は、その特徴を帰納法的に類推し、試行錯誤する。ランク上位表示を目指して、荒技（リンクファーム：Link Popularity を上げるためだけの意味のないリンクの張り合い）なんかで検索結果を荒らす者もいる。検索エンジン側でそうした行為を無にするような新たなチューニングを投入する……イタチごっこ。SEO 業者の日々の糧はそこにある。

検索の未来形？ Yahoo! ブログ検索

Pipe を作るためにひさしぶりに Yahoo! ブログ検索をいじってみたら、いろいろ機能アップしているのに気づいた。「これでもか！」と言わんばかりのてんこもり状態。おもしろそうなところをいくつかピックアップ。サンプルクエリは「水曜どうでしょう」で♪

【キーワードの注目度】
画面の左カラムのいちばん上にある折れ線グラフのモジュール。 これは、最初からついている機能。検索キーワードに関する話題がどの時期にどれぐらい盛り上がっていたのが視覚的にわかるところがいい。細かい機能なんだけど、マウスでグラフ上をなぞると、期間の範囲選択ができて、その期間に限定しての絞り込み検索を実行してくれる。いちばん盛り上がっているところは、どうやら07/03/21。 絞り込んだ結果を見れば、盛り上がった理由は一目瞭然。DVD の引き渡しの日だったんだね〜。

このモジュールの下の方に「拡大表示」というリンクがあって、これがまたおもしろい。ここはリリース時より機能アップしてる。検索キーワードの注目度がグラフ化されているのは当然として、これと比べて別のキーワードはどうだったのかがチェックできるようになっている。つまり、「水曜どうでしょう」とその出演者「大泉洋」の注目度の比較が見られるわけ。だから、こんなこともできちゃうわけ。

【評判情報】
「キーワードの注目度」モジュールの下にあるのが、「評判情報」 モジュール。これは、ブログ検索サービスでは、いくつかの会社が取り組んでいる技術。ブログ検索を口コミ情報の素材だと考えれば、自然言語処理技術の応用 として思いつくトピックでもある。これを見ると、検索キーワードの含まれるブログの中からポジティブな表現、ネガティブな表現、ポジティブともネガティブとも言えないけどなんらかの評価をしている表現を拾ってきて、それをグラフ化しているみたい。

これにも「詳細な評判情報を見る」というリンクがあるのでクリックしてみる。このページでは、モジュールにも表示されていた円グラフと、ピックアップされた評判表現、それらの表現が含まれるブログ記事が表示される。評判表現の処理がなかなかいい感じ。「面白い」という表現を見てみると、「面白いです」、「面白かった」という活用形もちゃんとカバーしている。さらに「おもしろい」とひらがなだけで記述されているものも同一視して処理されているのも注目に値する。評判情報処理の難点としては、係り受けの問題がある。つまり、

• 『水曜どうでしょう』の後に放送してる番組がむちゃくちゃ面白くって……
• 最近話題になってる『水曜どうでしょう』を見た。これだったら昔の『電波少年』の方が面白かったなあ……

……というようなテキストも単純な「水曜どうでしょう」「面白い」の複合検索ではひっかかってしまう。これらのテキストで「面白い」と評価されているのは、「『水曜どうでしょう』の後に放送している番組」であり、「『電波少年』」である。本来は、評判表現がどの語に対して係り受けしているのかを見なければいけないわけで、構文解析という技術が必要なレベル。でも、構文解析は高負荷な処理なので、なかなか大規模テキストに対して利用するのは難しい。想像ではあるんだけど、この Yahoo! ブログ検索ではおそらく検索キーワードと近接する評判情報に限定して処理しているんじゃないかな。それだと、まったく関係ない語への係り受けを評価対象に加えてしまうリスクはある程度防げる。もちろん網羅率という犠牲はともなうけど。

係り受けの抱えるもうひとつの問題は、照応詞とゼロ代名詞。いわゆる「それ」、「あれ」といった指示代名詞や主語・主題の欠落（省略）。とはいえ、これは検索キーワード自体が含まれない可能性も十分にあると思われる（そもそもキーワードでの検索ができない）ので、実用レベルのプロダクトではさほど大きな問題にならないのかもしれない。

goo のブログ検索では、「キーワードの注目度＋評判情報」みたいな形で表現していて、これはこれでおもしろい。評判表現の処理がいまひとつなんだが……。

【まとめ検索】
「キーワードの注目度」モジュールの上あたりにひっそりと「検索結果をまとめて表示」という地味なリンクがある。これもなかなかおもしろい。クリックした先にあるページはこんなもの。左カラムにキーワードが並んでいる。おそらく「水曜どうでしょう」が含まれるブログ記事に特徴的な頻度で出現している語彙のリストだろう（抽出方法は、TF/IDF だろうか）。少し変なものも含まれてはいるけど、けっこういいリストかも。

• 水曜どう、大泉洋、北海道、放送、classic、番組、TEAM NACS、最新作、クラシック、本……

これらのキーワードの重なり具合をベースにブログ記事を束ねているように思われる。この機能、地味ながら検索支援という意味でかなり示唆に富むもの。自分のよく知っている話題であれば「ふーん」で終わってしまう話題なんだけど、よく知らない話題の場合だとかなり意味がある。ウェブ検索の場合は、

• snippet（すにぺっと：検索結果の下に表示される本文中のテキストなどを抽出したもの）を読む
• 実際に検索結果ページにリストされているページに行って、コンテンツを拾い読みして、なんとなく関連しそうなキーワードらしきものを拾いだす

という作業が必要なのだが、その作業を省力化してくれる試みと言えるだろう。

その他にも「似たものワード」なんてキーワードリストが検索結果ページの下の方にあったり、「関連検索ワード」なんてのがページ上部に表示されたり。ちょっとこのあたりは盛りだくさんすぎて、ユーザ的にはなにがなんだかわかんないかもしれない。何をベースにして算出しているものなのかの、もうちょっと説明がほしいところ。

……とはいえ、今回ピックアップしたさまざまな機能は、検索技術の未来を垣間みさせてくれたような気がする。