microformatsの可能性とWebページの将来像

microformats （マイクロフォーマット）という言葉をご存じの方は、きっとWeb 2.0系サービスやその周辺技術にお詳しい方ではないかと察します。microformatsについては、これまでにもコラムのなかで数回にわたり触れてきましたし、最近ではWeb標準Blogにおいて「microformatsの対応状況と今後の展望」という記事をフロントエンド・エンジニアの矢倉が執筆しています。本コラムでは、改めてmicroformatsとは何かをご紹介し、それを取り巻く状況をごく手短に俯瞰したうえで、Webページの将来像に対する私見を述べたいと思います。

microformatsという語は、「micro」と「formats」から成ります。前者は極小の、後者は書式（「format」の複数形）という意味です。つまり日本語に直訳するなら、極小の書式ということになります。情報を書き表すうえで実に多くの種類や方法が書式として考えられますが、特定の情報に着目しますと、既に広く普及している書式が存在します。たとえば、一枚の名刺を思い浮かべてみてください。大抵、個人の名前やメールアドレス、所属組織に関する情報が書かれていると思います。そして所属組織については、住所や電話番号、FAX番号などが記載されていることでしょう。

しかしながら、こうした特定の書式を(X)HTMLを使ってマークアップしたところで、ある情報が名前であるとか、電話番号であるといったことをブラウザやユーザーエージェントは読み取ることができません。なぜなら、その目的に特化した要素が現行の(X)HTML仕様に定義されていないからです。かといって、将来の(X)HTML仕様に新しい要素を盛り込もうとすれば、それはそれで難しい問題が待ち受けています。仕様の改訂を含む標準化作業には非常に多くの時間を要するからです。また仮に、(X)HTMLとは別の新しい技術仕様を短期間で開発できたとしても、学習コストや既存技術との互換性が問題となります。

そこで考案されたのが、microformatsという考え方です。これは既存の(X)HTML仕様をベースとし、それに反することなく仕様にないセマンティクスを提供できるよう設計されています。特定の情報フォーマットに対して、特定の属性や属性値を使うことで、その意味するところを機械的に抽出できるようにするのです。microformatsの開発は W3C ではなく、誰もが自由に参加することのできる非常にオープンな場での議論（使用言語は英語になります）を通じ、草の根的に進められています。厳密にはWeb標準の範疇に含まれないでしょうが、しかし非常に近い位置づけの技術仕様ではあると思います。microformatsとWeb標準の相関については、microformatsコミュニティの中心的人物の一人であるJohn Allsopp氏にお話を伺っていますので、参考までにインタビュー動画をご紹介しておきます。

これまで、既に仕様として固まったものから目下ドラフト状態のものまで、実にさまざまなmicroformatsが考案されています。人や組織の情報についての hCard 、カレンダーやイベント情報についての hCalendar 、人間関係を記述する XFN 、ライセンス情報のための rel-license など。ほかにも、Blogやソーシャルブックマークなどでは情報内容にタグ付けすることが普及していますが、そのためのmicroformatとして rel-tag があります。また検索エンジンに対してリンク先の評価をしないよう指定するための rel-nofollow は、SEOに興味のある方なら目にしたことがあるかもしれません。microformatsの一覧は、 microformats Wikiのページ をご覧ください。有志による 日本語翻訳版 も用意されています。

果たしてmicroformatsは普及しているのでしょうか？ 見方は人それぞれでしょうが、 Google や Yahoo! 、 Technorati といった大手Webサービスベンダーをはじめ、最近では個人Blogなどでも採用されている実情を鑑みますと、既に一定の普及度、認知度には達しているといえそうです。とはいえ、通常のWebブラウジングを通じmicroformatsの恩恵を被る機会は、ブラウザ側の対応が道半ばゆえに稀ではないかと思います。その側面においては、残念ながら「鶏が先か、卵が先か」という状態をいまだ脱していない、といえるでしょう。

ここで一つだけ、microformatsの実装例をご紹介しておきます。もしWebブラウザに Mozilla Firefox をお使いでしたら、 Operator という拡張をインストールのうえ、会社案内のアクセスにアクセスしてみてください。すると、ページ中に埋め込まれたmicroformatsをOperatorが自動的に検知し、ミツエーリンクス本社とスタジオの連絡先情報を抽出できる状態になります。これにより、たとえば電子名刺形式の情報としてOutlookやアドレスブックなどのアプリケーションに簡単に取り込ませることができるのです。もちろん、Webブラウザ上から手作業でコピー＆ペーストをしても同じ結果は得られますが、特定の情報を機械的に取り出せることのメリットは、お分かりいただけると思います。

かくして、microformatsを用いれば、特定の情報に限って機械可読性を高めることができるようになります。これはつまり、静的なWebページであってもAPI（アプリケーション・プログラミング・インターフェース、アプリケーションが利用するためのインターフェースの意）となり得ることを示唆します。上述のJohn同様、microformatsコミュニティで重要な役割を担っている人物に、 Tantek Çelik 氏がいます。彼が今年3月に母校Stanford大学で講演したときの資料「 Microformats at Stanford 」のなかで、microformatsの定義に「The fastest and simplest way to provide an API for your website.（最も速く簡単にWebサイトでAPIを提供する方法）」を挙げています。

意味的にも文法的にも妥当な、Web標準に準拠したWebページというのは、それだけで既に一定の機械可読性を有しており、APIとして機能し得ました。しかしそれは、対Webブラウザ、対検索サービスという文脈におけるAPIであって、提供可能な機械可読性は(X)HTML仕様にあるセマンティクスに限定されていたと思います。しかし、コミュニティによって標準化されたmicroformatsを導入することで、より高機能なAPIとして豊かなセマンティクスとそれに紐づく利便性を期待できるようになります。

しかも、microformats導入にあたり必要とされる学習コストは、既存の標準技術を用いるがゆえに低く抑えることができます。Webページ上の情報にある意味を機械的に読み取れるようにする試みは、何もmicroformatsだけではありませんが、この学習コストの低さから今後さらなる普及が見込まれ、またWebブラウザ側の対応が進めば「鶏が先か、卵が先か」状態を脱する日もそう遠くないかもしれません。

情報は最終的には機械ではなく人間が解釈するものであって、それを踏まえた全体設計なり全体最適化は必須であるにせよ、Webページは今後APIとしての機能性を高めていく方向で発展していくものと考えます。APIを利用する側＝アプリケーション側の進歩と歩調を合わせる必要も生じるかもしれませんが、双方はいわば車の両輪。情報をマークアップするというプロセスにおいても、いかにしてビジネスメリットを生み出すかという部分に留意をし、また成果を上げるべく、microformatsやメタデータの利活用といった領域の調査研究、さらにはサービス開発を行っていきたいと思います。