Sitemap プロトコルをオープンなものにする提案

要約

 2006 年 11 月 16 日、 Google と Yahoo と Microsoft はウェブ検索用のクローラーの性能を向上させるために Sitemap プロトコルをサポートすることを発表しました。今後ウェブサイト運営者が Sitemap プロトコルに対応し、クローラー側もこのプロトコルで提供される Sitemaps データを活用するようになれば、ウェブサーバーの負荷は軽くなり、クローラーの効率は良くなり、最新情報も容易に検索できるようになり、良い技術だと思うのですが、今の規格では結果的に知名度の高いクローラーを優遇することになるので、改善してほしいです。

Sitemap プロトコルの概要と利点

 2006 年 11 月 16 日、ウェブ検索用のクローラーを運営する Google と Yahoo と Microsoft の 3 社は、ウェブサイト管理者がサイトのページ構成やページの更新をクローラーに通知するための共通規格「Sitemap プロトコル」をサポートすることを発表しました (スラッシュドットの記事。なお、現時点では、 Google と Yahoo はプロトコルの一部を実装済、 Microsoft は未実装のようです)。クローラーの三大企業が共通規格を使うということで、このニュースはあちこちのニュースサイトやブログで驚きをもって迎えられました。「オープンな共通規格」ということで歓迎する向きも多いようです。

 今の時点での Sitemap プロトコルの最新バージョンは 0.90 で、これは Google 単独で立案して Google だけが使っていた Sitemap プロトコル 0.84 の後継です。以降の記述は Sitemap プロトコル 0.90 を対象にします。

 Sitemap プロトコルの中心となるのは、ウェブサイトを構成するページのリストを記述した「サイトマップファイル」です。このファイルには、ウェブサイトを構成するページ一つ一つについて URL を記述し、さらに各ページの最終更新日時、予定される更新頻度、サイトの中での相対的な重要度などの付加情報も記述することができます。ウェブサイト管理者は、サイトマップファイルをウェブサーバーに載せた上で、クローラーに対してサイトマップファイルの URL を通知します (この説明は厳密には正しくありませんが、その違いは本題には関係がないのでここでは無視します)。ページが増えたり減ったり、ページの内容が変更されたりした場合は、それに合わせてサイトマップファイルも更新し、サイトマップファイルを更新したことをクローラーに通知します。

 このような仕組みを使うことで、検索サービスの側には次のような利点があります。

  1. サイトマップファイルを読むだけでサイトにどのようなページがあるのかわかるので、ページ中にあるリンクを一つ一つたどらなくても素早くサイトのページ全体にアクセスできる。
  2. サイトマップファイルを読むだけでどのページが更新されたかがだいたいわかるので、ページが更新されていないことを確認するだけのために一つ一つのページを定期的に検査する必要性が減る。
  3. サイトマップファイルの更新を知らせてもらえるので、知らされたときにページのデータを読みにいくことで最新のデータを得ることができる。
  4. サイト管理者がどのページを重要と考えているかがわかるので、検索サービスのユーザーに検索結果を提示するときの順序をより的確に決めることができる。
  5. クローラーに余力が生まれれば、今まで能力の都合でクローラーが読めていなかった重要度の低いページまで読み込むことができる。

 これらの事実は検索サービスにとってだけでなく、サイトマップファイルをクローラーに提供したウェブサイト運営者にとっても利点にあります (厳密に下のようになるとは限りません。すべてのウェブサイト運営者がクローラーに対して友好的とは限らないので……ただ、これはこれで難しい問題で、今の僕にこの問題を論じるだけの知識や考察はないので、ここではリンクファームのようなクローラーに対して非友好的なウェブサイトの存在は無視します)。

  1. サイトのすべてのページを確実に検索サービスに登録してもらえる。
  2. 更新されていないページに対するクローラーのアクセスが減り、サーバーの負荷が軽くなる。
  3. 新しいページや更新されたページの内容を素早く検索結果に反映させることができる。
  4. 一つのサイトの中では、サイト管理者が重要と考えているページが検索結果の中でより上位に表示されるようになる。

 さらに、検索サービスの利用者にとっても、最新情報が検索できる、今までより多くのページが検索できる、重要度によって検索結果の表示順が的確になるなどのメリットがあり、しかも全体としてはネットワークへの負荷を軽くすることができるので、誰にとっても良いことのように思われます。これぞまさに win-win の関係の究極の形。……本当にそうでしょうか?

 「誰にとっても良いこと」と聞いて素直に喜べる人は幸せかもしれませんが、僕は性格が悪いのか、どうもこの点が気に入らないのです。誰もが光の面を見て讃えているときに、影の面を探してしまう。この規格で損をする人といえば……真っ先に思いつくのは、知名度の低いクローラーや新規参入のクローラーです。

 断っておきますが、僕はこの規格を上で述べたような利点から良いものだと認識しています。でも、現在の規格のままでは知名度の低いクローラーが恩恵に与れず、知名度の高いクローラーだけが得をするという仕組みになっていると思います。そして、そのような規格をオープンな規格であるとは僕は考えません。また、この問題点をある程度改善することは現在の規格を拡張することで可能だと考えています。どうして問題かを簡単に述べ、それを改善する案を提示します。

知名度の低いクローラーからみた Sitemap プロトコルの短所

 知名度の低いクローラーにとって Sitemap プロトコルがあまり役に立たないことは、次の 2 点から説明することができます。

 一つは、サイトマップファイルを発見するのが困難であることです。 Sitemap プロトコルでは、サイトマップファイルのファイル名は決められていません (一部に sitemap.xml という名前にしなければならないというような誤解があるようですが、これは仕様の規約部分と例示部分を混同した誤読の結果だと思います)。そのため、サイトマップファイルの情報を確実に受け取れるのは、ウェブサイト管理者からサイトマップファイルの存在を通知してもらったクローラーだけということになります。知名度の低いクローラーや新規参入のクローラーはこの時点でハンディキャップを負うことになります。

 もう一つは、サイトマップファイルの更新情報を知らせてもらえないことです。 Sitemap プロトコルの特徴の一つはウェブサイト側がクローラーに通知する機能です。運良く知名度の低いクローラーが何らかの方法 (sitemap.xml 等ありがちなファイル名を探してみるなど) でサイトマップファイルを見つけたとしても、ウェブサイトはサイトマップファイルの更新情報を知名度の低いクローラーには通知してくれないので、この機能の恩恵にも与れないわけです。

 これらは、知名度の低いクローラーからみた場合の Sitemap プロトコルの短所です。しかし、知名度が低いからこそ、 Sitemap プロトコルを改良して新たな事実上標準を作っていくだけの力はないでしょう。これを規格の提案者である大手クローラー企業が Sitemap プロトコルの「長所」と考えるならば、そんなものをオープンな規格とは僕は呼びません。これらをプロトコルの問題点と認識して、改善していって、初めてオープンな規格ができると僕は思います。

Sitemap プロトコルの改善案

 上で述べた二つの点を問題点と認識するならば、これらはいずれも既存の技術の応用または変形で対処できます。以下のような拡張が改善案として考えられます。

サイトマップファイルの自動発見

 一部のクローラーしかサイトマップファイルの場所を教えてもらえないという問題に対処するには、自動発見という方法が有効だと思います。 RSS や Atom などの更新情報 (フィード) のデータを用意しているウェブページには、これらのデータの URL が埋め込まれています。一部のブラウザはこれを検出することで「このページにはフィードが用意されていますよ」ということをユーザーに通知しています。この機能はフィードの自動発見 (autodiscovery) と呼ばれます。同様の機能をサイトマップファイルに対しても用意するべきだと思います。

 方法はいくつか考えられますが、 HTML の link 要素か HTTP のヘッダーを使うのが最も単純だと思います。

 自動発見の代わりにサイトマップファイルのファイル名を固定するという方法もありますが、自動発見に比べればセンスが悪いと思います。ただ、自動発見で見つからなかったら sitemap.xml という名前のファイルを探すことにするという選択はありうるかもしれません (ただし固定ファイル名のファイルを探す場合、どのディレクトリを調べるべきかなどの問題があります。詳しく検討していません)。

サイトマップファイルの購読

 サイトマップファイルの自動発見ができるようになるだけでも、知名度の低いクローラーにはかなり大きなメリットがあると思います。サイトマップファイルを定期的に調べるだけでサイト全体の情報が得られるのですから。しかし、これではまだ知名度の高いクローラーを優遇していると言わざるを得ません。

 知名度の低いクローラーがサイトの更新情報を受け取ることができないという問題に対処するには、一部のウェブサイトで用意されている「更新アナウンス専用メーリングリスト」というのが参考になります。このメーリングリストを用意しているサイトでは、ウェブサイト管理者は何か更新があるたびにメーリングリストにアナウンスのメールを流します。これによって、ウェブサイトが更新されたときにそれを知りたい人は、メーリングリストを購読することでサイトを定期的にチェックすることなく更新を速やかに知ることができます。アナウンスのメールは手で書いている場合もありますが、更新作業の一環として自動化する場合もあるでしょう。

 サイトマップファイルあるいはサイトの構成の更新の通知も基本的にはこれと同じ目的のことをしていると考えられます。ただし、更新の通知を受け取るのが人ではなくクローラーというシステムに変わっただけです。現在の規格は、サイト運営者が「この人とこの人に更新を通知しよう」と自分で決めている状態に対応します。ほかにも更新を通知してほしい人がいても、そのことをサイト運営者に伝えるすべがありません。メーリングリストの場合と同様に、クローラーの側から「更新を通知してほしい」とサイト運営者に申請できるようにするべきです。いわば「サイトマップファイルの購読」です。メーリングリストの購読と同じ考え方を使うというだけで、電子メールを使う必要はありません。

 (なお、紛らわしいですが、「フィードの購読」と呼ばれるのは単にクライアントがフィードの更新を定期的に調べることを意味し、更新したときにウェブサイトから購読者に自動的に連絡が届くわけではありません。このため、本質的にメーリングリストの購読とは意味が違います。「サイトマップファイルの購読」という言葉はメーリングリストの購読に対応する意味で使っています。)

 これを実現するためには、申請を自動化できるように申請の方式を規格化する必要があります。メーリングリストの場合に他人を勝手に登録することができないように購読の確認を行うのと同様の仕組みが、この更新通知を受け取る申請でも必要でしょう。また、メーリングリストでエラーが返ってくるようになったメールアドレスの購読を自動的に停止するのと同じように、一度は申請してきたけれど消滅したクローラーに対する処理も決める必要があるでしょう。メーリングリストと違って受け取るのは人間ではないので、申請を期限付きにして定期的に申請し直すことをクローラーに求めるのでもよいかもしれません (ただしこの間隔があまり短いと、毎回更新を検査しているのと変わらなくなってしまうので、適当な長さに決める必要があります)。

プロトコル 2007 年 4 月 11 日版での更新について (追記)

 2007 年 4 月 11 日、 Sitemap プロトコル 0.90 の仕様が更新されてサイトマップファイルの自動発見の仕様が追加されました (プロトコルのバージョンは変わっていません)。 robots.txt に「Sitemap: http://www.example.com/sitemap.xml」のようにサイトマップファイルの URL を書いておくと見つけてくれるようです。これは一歩前進と言ってよいでしょう。更新を知らせるのは相変わらず個々の検索エンジンに対して行う必要がありますが。

 robots.txt はサイトのルートディレクトリに置く必要があるので、当サイトのようにサイト全体がサブディレクトリの下にある場合には使えません。でも、本当にサイトマップデータが重要になるのは大規模な (ページ数の多い) ウェブサイトであって、多くの大規模なウェブサイトは自分のドメイン名を持っているでしょうから、ルートディレクトリに置かなければならないという制約はさほど問題ではありません。

仕様書の不明確な点について

 話はだいぶ変わりますが、現在のプロトコルの仕様書は、プロトコルの概要説明としては使えても、仕様書としては少々お粗末です。 normative な部分と informative な部分の区別が明確でなかったり、基礎技術である XML の仕様の一部が重複して書かれていたり、 XML の「要素」と「タグ」を混同しているなど用語がおかしい部分もあります。 XML 名前空間の扱いも明確には書かれていません。僕などより XML や仕様書の書き方に詳しい人が見た方が良いと思うので、ここでは誤りをすべて挙げることはしません。

 仕様がはっきりしていないと、プロトコルの実装者 (ウェブサイト側もクローラー側も) は実際に動いているものの挙動を調べてそれに合わせる、という非効率な作業を強いられます。さらに、そのときに調べる対象は大手のクローラーの動作になります。このため、不明瞭な仕様というのは、暗黙のうちに既に力のある者にさらなる力を与えることになります。

 オープンな規格を目指すなら、仕様書は明確に書くべきです。

まとめ

 Sitemap プロトコルは、クローラーの動作を大幅に効率化して、検索サービス運営者とウェブサイト運営者のいずれもが恩恵を受けるだけでなく、検索サービスのユーザーも恩恵に与れる、優れた規格だと思います。しかし、現在の規格では、あと一歩のところでオープンな規格になっていません。真にオープンな規格を目指すなら、知名度の低いクローラーもが恩恵に与れるよう、規格を改善するべきです。

本サイトの方針

 「フルーツチョコレートパフェ」ではこのサイトについてにあるように、数ページだけからなるごく小さなサイトのくせに現在実験的にサイトマップファイルを提供しており、更新のたびに Google と Yahoo に更新を通知しています。本サイトのような小さいウェブサイトが Sitemap プロトコルに対応してもおそらくメリットはありません。ただ、実際に手を動かすことによって、このページに書いたような問題点を知ることができたので、無駄ではなかったと思います。

 あなたは僕のことを不誠実だと思うかもしれません。僕は「Sitemap プロトコルは大手クローラーを優遇している」と欠点を挙げて一見知名度の低いクローラーの味方のような振りをしながら、自分はサイトマップファイルを提供し、しかも大手クローラーに更新通知までしているのです。このことについて、僕の考えを書いておきます。

 僕は Sitemap プロトコルを評価しているし、技術的にも面白いと思っています。だから、実際にファイルを用意してみたし、技術的な興味から、更新通知の仕方がわかった Google と Yahoo には更新通知をしています。これは趣味の範囲です。しかし、同時に、これによって本サイトのページが大手の検索サービスで表示されるようになってほしいとも思っています。それは、僕が書いたものが誰かの役に立つなら、その人のところに届いてほしい、という思いからです。

 本当は、大手だけではなくて、他の検索サービスでも同じことを望んでいます。ただ、たかが一サイトの管理人でしかない僕ができることは限られています。だから、一方では規格を改善してほしいとこうして声を上げながら、一方では僕の書いたものを必要としている人に届けるために可能な範囲で努力をしているのです。

 二枚舌と言われるかもしれませんが、僕は自分のできる範囲のことをしているつもりです。まあ、そもそもこのサイト全体が僕の趣味だし、こんな小さいサイトが何をしたところで社会的影響があるわけがありませんが……。

2006 年 11 月 22 日公開、 2007 年 4 月 27 日最終更新。著者: fcp / このサイトについて