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

「深層ウェブ」（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 の数々。けっこう途中で切れちゃってるけど、ちゃんとリンクは生きている（はず）。

URL のよくわかんないアレ

前回の「文字コードについて」では、URL のヒミツ（っていうほどでもないけど）をすこし覗いてみた。なんだかよくわからない文字がごにょごにょって書いてあるアレ。きょうはアレをもう少し見ていこう。

この記事を書くのに使っているパソコンは、Macintosh PowerBook G4。ブラウザは、Firefox 2.0.0.4（ウェブブラウザのひとつ）の日本語版。ブラウザの右上に検索プラグイン（ここに文字を入力すると、選択されているサービスで検索できる）がついている。そのプラグインから Yahoo! JAPAN を選択。「東海林さだお」と入力し、検索実行。すると、Yahoo! JAPAN のウェブ検索結果が表示される。そのときの URL は、

http://search.yahoo.co.jp/search?p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A&ei=UTF-8&fr=moz2&rls=org.mozilla:ja-JP:official

こんな感じ（もしかしたら途中で切れてるかも……）。これを細かく分解して見ていこう。分解のカギは、「?」と「&」。

• http://search.yahoo.co.jp/search?
• p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A
• ei=UTF-8
• fr=moz2
• rls=org.mozilla:ja-JP:official

読みにくくなるので「&」は省略したけど、こんな感じ。前回の記事を読んだ人はわかると思うけど、「%E6%9D%B1%E6%B5%B7%......」の意味するところは検索文字列に相当するもの、「ei」が検索文字列の文字コードってこと。これを上から順に翻訳していくとこんな感じ。

• http://search.yahoo.co.jp/search?
  • これから「http://search.yahoo.co.jp/」の「search」というプログラムに問い合わせをしますよ
• p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A
  • 検索文字列（p）は、「%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A」ですからね
• ei=UTF-8
  • 検索文字列の文字コード（ei）は、「UTF-8」ですよ
    • だから、「%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A」は「東海林さだお」って読めるでしょ
• fr=moz2
  • 検索文字列がどこから入力されたのか（fr）って言うと、「moz2」ですよ（Firefox 2 のこと？　あるいはその上位カテゴリ）
• rls=org.mozilla:ja-JP:official
  • これ、なんだろ？　日本語版の Firefox のオフィシャルプラグインからの入力ですよってことかな？

つまり、Yahoo! JAPAN のウェブ検索プログラムに、なんだかんだと条件を指定しているということがわかるだろう。ユーザの意識に残っているものといえば、「東海林さだお」という検索文字列だけなんだけど、Firefox の検索プラグインを使うという行為により、検索プラグインに仕込まれているいくつかの情報がセットで送られているということだ。

Firefox の検索プラグインは、XML 形式で記述されているけど、その中身を見てみると……

  <url type="text/html" method="GET" template="http://search.yahoo.co.jp/search">
    <param name="p" value="{searchTerms}">
    <param name="ei" value="UTF-8">
    <mozparam name="fr" condition="pref" pref="yahoo-fr-cjkt">
    <param name="rls" value="{moz:distributionID}:ja-JP:{moz:official}">
  </url>

……こんな感じ（関係のある部分だけ抜粋）。{ } で囲まれている部分は、変数。例えば、{searchTerms} は検索文字列、{moz:distributionID}、{moz:official} あたりは、Firefox の規定値を参照することになっているものだろう。HTML を書いたことがある人ならわかると思うけど、FORM の記述方法にとても似ている。その書き方に無理に翻訳すると……

  <form method="GET" action="http://search.yahoo.co.jp/search">
    <input type="text" name="p" value="{searchTerms}">
    <input type="hidden" name="ei" value="UTF-8">
    <input type="hidden" name="fr" value="moz2">
    <input type="hidden" name="rls"
    value="{moz:distributionID}:ja-JP:{moz:official}">
  </url>

……こんな感じだろうか（mozparam のところはちょっと手抜きした）。「input」は、文字どおり入力文字列を受け付けるタグ。その中でも「type="text"」となっているものは、ユーザの画面上にテキスト入力欄が表示される。それに対して「ei」と「fr」、「rls」は「type=hidden」なっている。「hidden」で送信されるものは、ユーザの画面上には表示されない。なので、ここはユーザの意志と無関係に規定値などが記入される。用途はさまざま。これによって、プログラムの挙動が変わったりすることもあれば、一見何も変化の起きないこともある。今回の例で言えば、「fr」と「rls」はユーザに対しては特に大きな役割は果たさない。おそらくクエリ分析に利用されるもの（どこからリクエストが来たかを判定するとか）。なので、それらを削っても、ユーザとしては得られる情報は同じもの（少なくともそう見える）。

http://search.yahoo.co.jp/search?p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A&ei=UTF-8

「hidden」の項目がユーザの画面やプログラムの処理結果に影響を与えるかどうかを知るには、どうすればいいかということになるとすこし難しい。ひとつひとつ試してみるしかない。URL 欄に表示されたものをちょこちょこいじってみる……ということになる。

FORM で重要なのは、どんな情報をユーザから受け付けて、どんな情報を補助情報（ユーザの入力に委ねないもの）として送信するかということ。補助情報は、「hidden」で送信される。

もうひとつ重要なことがある。それは、「GET」と「POST」。さっきの例で言えば、

  <form method="GET" action="http://search.yahoo.co.jp/search">

…で、「method="GET"」となっている。「method="GET"」であっても、「method="POST"」であっても、データがプログラムに送信されるのは同じなんだけど、送られ方がずいぶん違う。Yahoo! JAPAN のウェブ検索プログラムが「method="POST"」で送信されたデータを受け付けるかどうかはわからないけど、それが受け付けられるとすると、

  <form method="POST" action="http://search.yahoo.co.jp/search">
    <input type="text" name="p" value="{searchTerms}">
    <input type="hidden" name="ei" value="UTF-8">
    <input type="hidden" name="fr" value="moz2">
    <input type="hidden" name="rls" 
    value="{moz:distributionID}:ja-JP:{moz:official}">
  </url>

での送信結果の URL は、

http://search.yahoo.co.jp/search

となる。つまり、URL の後半部のごにょごにょがなくなってしまうわけ。そうなると、上の URL をクリックしてもらえばわかるけど、検索文字列を入力して送信した結果の URL なのにその URL を後で再利用しようと思っても、同じ画面はユーザに提供されない……ということ。例えば、Yahoo! JAPAN で「吉祥寺 いせや」と検索した結果のページの URL をともだちに知らせてあげようと思っても、「http://search.yahoo.co.jp/search」しか表示されないので、それをともだちがそれを受け取っても同じ検索結果画面を見ることができない。つまり、再現性がないというわけだ。フォーム送信するようなページは、「GET」にしておかないと、検索エンジンにインデックスされない……ということが SEO の文脈で言われたりすることがあるけど、これも「POST」で生成される URL の再現性のなさが原因。

じゃあ、なんでも「GET」だったらいいのかというとそうでもない。「GET」には、文字数制限や情報の秘匿性の脆弱さということがある。WWW のさまざまなお約束を策定している W3C で規定されていたかどうかはわかんないけど、Microsoft の Internet Explorer だと、2083字（半角英数字）以上の URL は処理できないようだ。

情報の秘匿性の脆弱さについては、ログインフォームを考えるとわかりやすい。ID やパスワードを入力して送信するというのがログインフォームの仕事なわけだけど、「GET」で送信するということは、URL に ID やパスワードがまるわかりの状態で流れてしまうということ。これでは情報流出のリスクがある。Yahoo! JAPAN は、「GET」送信のフォームが多いけど、ログインフォームはきちんと「POST」送信になっている（それに加えて、送信内容を暗号化するようにセキュリティサーバを利用している。「https」で始まる URL はセキュリティサーバで保護されていることの目安）。

  <form method="post" action="https://login.yahoo.co.jp/config/login?"
  autocomplete="off" name="login_form">

「GET」がよいのか、「POST」がよいのか、そのメリットとデメリットを考えていくのが大事。

文字コードについて

タイプライターが好きで、小学生のころから Olivetti ※のタイプライターのキーを叩いていた。母親が会社で使っていたのがこの写真にある和文タイプライター。英文タイプライターは、キー配列はパソコンとほとんどいっしょ。和文タイプライターは、構造からしてまったく違う。写真に見える白い部分に升目が引いてあって、その升目の中に小さな文字が印刷されている。盤面に黒いノブのようなものが写っているけど、これで盤面の文字を探す。打刻したい文字がみつかったら、そこでノブを押す。そうすると、その文字が紙に印字される……というモノ。ノブをカチッと押す（現代的な表現で言えばクリックする）と、その活字を拾って、インクリボンに向けて活字を叩き付ける……という仕掛け。

和文タイプライターの盤面に整然と並んでいる文字たちのことを考えていると、文字コードの配列表を連想する。コンピュータで記述する文字はすべてなんらかの文字コードに従って、ID とでもいうべきもので整理されている。ウェブブラウジングが一般化する前は、ワープロを使ったりするときも、文字コードを気にしたりすることはなかった。強いて言えば、Windows で作成した文書を Macintosh で開くと、一部の文字が文字化けするなんてことぐらいだろうか。最近はそんなことも少なくなったけど、ウェブブラウジングの普及以降、ブラウザで開いたページがまるっきり文字化けしていて読めない、そんなときはブラウザのメニューから文字コードをいじってみたり……なんていう経験は誰しも一度はあるんじゃないだろうか。Shift JIS となっていたものを、EUC-JP に変更したら読めた……っていう経験。

どんな風に文字が整理されているかと言うと、こんな感じ。「亜」という字であれば、16 区の一列目にいる。Shift JIS だったら 16 区は、889E。「亜」の字が配置されているのは、+1 の列。これを組み合わせて、889E + 1 = 889F ※※。EUC-JP だったら、同じ 16 区で、同じく +1。でも、基礎となる数字が B0A0。なので、「亜」は、B0A0 + 1 = B0A1。つまり、同じ「亜」の字であっても、

• Shift JIS の「亜」：889F
• EUC-JP の「亜」：B0A1

……なので、コンピュータの中ではまったく別の ID で管理されている。いわば、別の暗号表に割り当てられていると言っていい。そのため、暗号表（文字コード）が違っていれば、「ちゃんと解読できない」→「文字化けする」……という状況が発生するわけだ。

この B0A1 とかって、どこかで見たことない？　例えば、Yahoo! JAPANとかで検索したときにブラウザの URL 欄でよくわからない文字列がごちょごちょっと書かれているアレ。Yahoo! JAPAN のトップページから「亜」と検索してみる。すると、URL 欄に表示されるのが、

http://search.yahoo.co.jp/search?p=%B0%A1&ei=euc-jp

……こんな文字列（説明に不要な部分は省略してある）。この %B0%A1 が「亜」の B0A1。後ろの「ei=euc-jp」は、「検索文字列は、EUC-JP の暗号表で暗号化されてますよ」と言う意味。これをサーバが受け取って、EUC-JP の暗号表で解読する。excite だと、

http://www.excite.co.jp/search.gw?search=%88%9F

……こんな感じ。これは言うまでもなく、Shift JIS の 889F。

最近は、UTF-8 なんて文字コードもよく見かける。Google なんかは、どのページも UTF-8 で書かれている。そんな Google で検索したりすると、

http://www.google.co.jp/search?q=%E4%BA%9C&lr=lang_ja&ie=utf-8&oe=utf-8

……と表示される。さっきからの類推で行けば、%E4%BA%9C か。UTF-8 の文字コード表を参照すると、確かに E4BA9C とある。「ie=utf-8」は、Yahoo! JAPAN の「ei=euc-jp」が「検索文字列は、EUC-JP の暗号表で暗号化されてますよ」と言っているのと同様に、Google は、「ie=utf-8」で「検索文字列は、utf-8 の暗号表で暗号化されてますよ」と言っている（ちなみに oe は検索結果ページの文字コード指定）。試みに Google に検索文字列「亜」をShift JIS で送ってみる。

http://www.google.co.jp/search?q=%88%9F&lr=lang_ja&ie=shift_jis&oe=utf-8

さっきの検索結果と同じものが表示される。

UTF-8 は、新しい文字コードの規格で、これまでのShift JIS や EUC-JP と比較して、圧倒的に多数の文字を表の中に格納することができる。大雑把に言えば、Shift JIS や EUC-JP は、日本語の文字が担当範囲。UTF-8 は世界各国の文字が担当範囲。文字コードが UTF-8 だったら、同じページの中で、中国語、韓国語、日本語を同時に表示できちゃう（もちろんロシア語でもタイ語でも）。Yahoo! JAPAN は、長年文字コードを EUC-JP で統一してきていたけど、翻訳サービスなんかは、UTF-8。この理由も UTF-8 が多国語を扱えるというところにつきる。

こんな風に考えていくと、なんだかよくわからなかった文字コードなんてのもおもしろく思えたりしない？

おまけ：「亜」が URL の中で「%E4%BA%9C」（UTF-8）で暗号化されてるというのは、ここまでに説明したとおり、この暗号化を「URL エンコード」っていう。覚えておいてもいい用語かも。（07/06/04 追記）

※ Olivetti：イタリアのタイプライターメーカー。赤い Valentine っていうのが代表的な製品。こいつがなんともいえずスタイリッシュ。いまの Valentine は、プリンターなんかのメーカーになっちゃったけど、

※※889F：F は、文字ではなく、16 進数の数字。0123456789ABCDEF という順番。つまり、A は、10 進数だったら、11。なので、E は、15。15 + 1 = F = 16。

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

「検索エンジン」という言葉が、一般的に広く用いられるようになってひさしい。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 業者の日々の糧はそこにある。