Webに現われつつある新たな潮流とそれらを利用した可能性について

1.1 機能不十分なブラウザ

　Webブラウザにおいても同じことが言える。現在ブラウザの大半(90%以上)を占めるMicrosoft社の(Windows版)Internet Explorerは比較的きちんとバージョンアップされている方だが、それは(Microsoft社のInternet ExplorerはOSの一部であるという建前の結果として、)ソフトの使用にInternet Explorerのバージョンアップと同時におこなわれる新たな部品の導入・更新(OSのアップグレード)を必要とすることを理由に、ソフトのインストール前にInternet Explorerのバージョンアップを強制させられるという仕組みが働くためである。(同時にこのことが企業等のシステム部門にバージョンアップを敬遠させる原因となっているのは、皮肉としか言いようがない。)また、Internet ExplorerやメーラーであるOutlook( Express)にはセキュリティ上のバグが多く、そういった穴をついてくるウイルスが流行した時にバージョンアップがはやるというような現象があることも忘れてはならない。(本来であれば「そういったバグが報告された時点で修正パッチを当てたり、新バージョンの導入に特に問題がなければ移行する」というようなウイルスの感染を未然に防ごうとする姿勢をとるべきなのだが、日本ではこういう事後対策的な姿勢が多い。)

　少し前までInternet Explorer以外に使われているブラウザのシェアのかなりの部分を、未だにNetscapeのバージョン4.Xが占めていた。(まだ結構いる。)これにはNetscapeのオープンソース・プロジェクトであるMozillaの開発がほぼ1からの作り直しというものになってしまったり、途中Netscape社がAOL(American Online)に買収されてしまったことなどによって、開発が大幅に遅れてしまったことや、Netscape 6.0として発表されたものがまだまだ開発途上のものであったためにパフォーマンスの悪さがユーザーを絶望させたというようなことを割り引いて考えても、これはユーザーが保守的な姿勢を取るということを示す好例だと言えよう。(本学でもやはりNetscape 4.Xが使われている。)

　問題は多くの人が古いブラウザをなかなか捨てようとしないため、Webサイト(特に企業サイト)の制作者はそのブラウザの持つバグと付き合わなければならないというところにある。(正確には公式規格が定められたあとに出た(リリースされた)にもかかわらず、公式規格をサポートしていないのもバグであると言えるが……これについてはあとで述べる。こういう意味でC++というプログラミング言語のコンパイラはバグだらけである。)特にNetscape 4.XはCSS(Cascading Style Sheet)関連に致命的なバグを幾つも抱えており、そのことがHTMLによる文書構造の記述とCSSによる表示の方法(レイアウト)の記述という合理的かつ望ましいスタイルからWebデザイナーを遠ざけ、文書構造を無視したテーブルレイアウト(本来は表を作るためのものであるtable要素を利用したレイアウト)などのような「読み上げソフト」を使う障害者などにとってやさしくないテクニックへと誘惑される原因の一つとなっている。

　幸い今はこの状況は多少改善された。Internet Explorerが90%以上のシェアを持つことはあまりいいことだとは言えないが、Operaが着実にある程度のユーザー層を獲得したし、パフォーマンスの悪さの大幅な改善(XUL (XML User Interface Language)を利用してブラウザコンポーネントを再設計したPhoenixではさらなるスピードアップがはかられている。)や、MacOS Xの流儀を理解したChimeraというインターフェースの登場、ネット利用であればLinuxでも十分というPC(Personal Computer)低価格化での新たな流れから(Netscape 4.Xを越えて)Mozillaが徐々にシェアを伸ばしつつある。(これにはOpenOffice.org普及も関わってくるだろう。)

　大きなシェアを持つブラウザが、それにも関わらず標準規格をきちんとサポートしないのも問題である。もちろん今の標準規格も決して十分なものではなく、それ以上のものを望む声を聞くことも多い。(そのためMozillaのCSSに対する野心的な独自拡張(その中のいくつかは規格化前の先取り実装)を利用するものもいるようだ。なかには自分で対応させてしまうハッカー肌の人もいるが、Webが多くの人々の間に広まってしまった現在、そういう人は少数派である。)だが、標準規格がきちんとサポートされていないということは、そこにすら至っていないことを意味する。

　特に各ブラウザのまちまちなCSSの実装は、多くのWeb制作者達を苦しめている。(HTMLのタグにきちんと対応してないためにCSSが適用できないというケースも同様である。もっともその場合、HTMLのタグにきちんと対応できていないことそのものに苦しめられるが……)Webサイト制作者達は、各ブラウザの持つバグとまちまちな実装への泥沼的な対応を迫られるのだ。実際、多くのブラウザで意図通りのデザインをかなえる為に泥縄・泥沼式の'コーディング'を行ったり、ブラウザごとにスタイルシートを切り替えるためのスクリプトを用意する者もいる。これでは何のためのスタイルシートなのか、何のための標準なのか、分からない。本来文書構造と表示・印刷方法を切り離すことで負担を軽減させるための仕組みが、意図通りのデザインをかなえるという段階では逆に大きな負担として働く……。特定の環境や規格上非推奨となっている表示用の要素(視覚的効果)に依存するデザインは決して誉められたものではない。だが、そうせざるをえない苦悩が標準の不徹底にあることを忘れてはならない。

　世間の目はこういった事態は次第に好転しつつある、という楽観的なものだ。「Microsoft社はあいかわらずWindows版 Internet ExplorerでのCSS2(CSS Level 2)サポートに消極的であるが、Macintochでの大きなシェアを占めるMacintoch版 Internet ExplorerはCSSをかなり忠実にサポートしているし、Mozillaもそれにつぐぐらいの精度での実装を行っている。また、他にもOperaやiCabなどCSS2の完全実装を目指しているブラウザがいくつか存在するようだ。これらがやがてそういった環境間の格差を消し去るだろう。」と彼らは言う。

　しかしながら、彼らはあることを見逃している。CSSも(その後バグフィックスされたり、XMLとして定義し直されたとはいえ)HTML4も4年以上前に勧告された規格であるということを。

　4年以上前に出来た規格に未だ完全に対応できていないという事実は、これからの展望が決して開けたものではないことを、むしろ暗い闇が待ち受けているであろうことを暗示している。

　既に「Webブラウザ」にはXMLとしての機能をきちんとサポートしていること、規格のモジュール化、(Macromediaの規格である)Flashやストリーミング・データなどのそれまで生データで提供されていたものに秩序(形)を与えるための規格であるSMIL(Synchronized Multimedia Integration Language)、数式記述用の言語であるMathML(Mathematical Markup Language)やベクトル画像を記述するための言語であるSVG(Scalable Vector Graphics)などに対応すること(また、これらを組み合わせてカスタマイズされたドキュメントを受け入れること)が求められている。それに、より強力な機能を持つXHTML(eXtensible HyperText Markup Language)2.0やCSS3(CSS Level 3)が規格化されようとしている。(XHTML 2.0では今もって羨望とともに語られる、Ted Nelsonのハイパーテキスト・ハイパーメディアを世界的なネットワークによってつなごうとする未完のプロジェクト(WWWに影響を与えた)――Xanaduが持つはずであった強力なリンク機能の一部、(双方向を含む)複数の方向へのリンク(XLink : XML Linking Language)やデータの一部だけを参照して取り出すためのより細かな指定(XPointer : XML Pointing Language)がサポートされる予定である。なお、Xanaduで窓と呼ばれていた埋め込み式のリンクは、iframe(インラインフレーム)要素やそれに代わるobject要素によって既にサポートされている。(もともとXLinkはSGMLの拡張リンク機構、HyTimeをひな型にしたものであったが、それゆえにもとのHyTimeと比べても現在のXLinkには機能的な制限(欠陥)があり、その結果HTMLの各種要素はXMLとしてイリーガルな存在となってしまう。この状況を改善すべく、XLinkのWG(Working Group)と交渉しつつ、独自のHLinkという代替案を示している。この仕様は後述するRELAX NGの影響を受けており、使用面での単純化を計るために、スキーマ(定義)方式を採用している。これによって、HTMLに対する絵やスクリプトや動画の埋め込み、文章の引用などが、埋め込み式のリンクとして再定義されることになる。))

　だが、だからといってそう悲観的になることもない。Windows版 Internet Explorerは比較的早い時期からHTMLとSMILの統合への対応をおこなっているし、MozillaはMathMLとSVG、XLinkの拡張リンクへの対応に乗り出してきているし、W3Cがその先進的な思想と規格を発信するためのブラウザ兼エディタ――AmayaがMathMLやSVG(の一部)などに対応したツールとして徐々にその存在を知られつつある。それに、プラグインのレベルではあるものの、Windows版 Internet Explorerでスタイルシートを切り替えれるようにする「ス切リボ」、NetscapeやMozillaにさまざまな機能を追加する「ContextMenu-Extensions for Netscape 7 & Mozilla」、視覚障害者をサポートとする「読み上げソフト」、Adobe Systems社の「SVG Viewer」などのようなブラウザに欠けている能力を補完するものが今後も出てくるだろう。こういったものを視野に入れ、それらをうまく活用するサイトがたくさん増えれば、それらはブラウザを提供する側にとって無視できないものになるはずだ。

1.2 迷走するオーサリングツール

　しかしながら、ブラウザがきちんと規格をサポートしたからといって、それが広まるとは限らない。上述したような試行錯誤をおこなうのは一部のWebサイト制作者であって、全体ではない。それに極度のこだわりでもない限り、多くのブラウザがサポートしていないもの、あるいはサポートが変なものを使わずとも大抵のデザインは実現可能であるため、そこに安住することも多い。人々は保守的であるため、現在のもので十分であると認識している場合、それをわざわざ変えることの価値を見出すことができない。

　だから依然として視覚的効果に依存したデザインが使われ続けるし、フレームを使ったページも使われ続ける。どちらもアクセシビリティ(特定の環境に依存することなく、障害者や初心者、外国人を含めた、だれにとっても使いやすいものを提供すること)に反した有害なものである言われているし、「使わないように」という意思の反映としてそういった要素は廃止される旨が勧告されているし、(良いか悪いかは別として)スタイルシートで実現可能であるにもかかわらずだ。(例えば、スタイルシートを使って段組レイアウトや擬似フレームを実現することも可能である。)それどころか、未だにそういったテクニックを紹介する本や雑誌さえある。その場合スタイルシートを使うにしても、「このデザインはスタイルシートがなければできないから」というスタイルシートの役割を履き違えた使い方がされることが多い。

　さらに、そういったものを是正しようと呼びかけていながら、自分では視覚的効果に依存したデザインを使っているようなところもある。

　こういった問題の一翼をオーサリングツールが担うことも多い。

　オーサリングツールとはWebサイトの作成に用いられる道具(ソフト)のことであり、以下のようなものがあげられる。

• 特にWebコンテンツの作成のために設計された編集ツール（例えば，WYSIWYG型のHTMLおよびXMLエディター）
• 資料をWebフォーマットとして保存するオプションを提供するツール（例えば，ワープロやデスクトップパブリッシング（desktop publishing: DTP）パッケージ）
• 文書をWebフォーマットに変換するツール（例えば，DTPフォーマットをHTMLに変換するフィルター）
• 特にWeb上での使用を意図したマルチメディアを作成するためのツール（例えば，ビデオ制作・編集機器一式，SMIL（Synchronized Multimedia Integration Language）オーサリングパッケージ）
• データベースから動的にWebサイトを自動生成するツール，編集中転換ツール，Webサイト公開ツールを含む，Webサイトの管理および公開のためのツール
• レイアウト管理ツール（例えば，CSSフォーマットツール）

　オーサリングツール、中でも特にWYSIWYGのエディタはきちんとした考慮が働いているとはいえないソースを吐くことが多い。年々、こうしたソースの品質は改善されてきたものの、凝ったデザインを行っているとすぐにコードは汚いものとなってしまう。だから(理想的なソースを吐くことが確認できない限りは)出てきたソースを手直しなければならない。だが、そういった意識は低く、そのままWebにアップロードされるケースも少なくない。

　オーサリングツールを提供する側(ベンダー)の都合・思い上がりが押し付けられることもある。例えばWYSIWYGのエディタを使ったとき、非推奨である装飾用の要素を使ったソースを吐くことや、CSSが上級用の機能に位置付けられている上、使いにくいインターフェースになっていることに気づくだろう。HTMLによる文書構造のマークアップとCSSを使った装飾に分離することが推奨されているにも関わらずだ。また、せっかく規格が書き手の都合から例外(省略記法など)が多く認められていて扱いにくいSGML(Standard Generalized Markup Language)から例外がなく扱いやすいXMLとして再定義されているにもかかわらず、変換ツールを用意してXHTMLに移行しようとしない姿勢には疑問を感じる。(かといってISO-HTMLに対応しているわけでもないし……。ちなみにHTMLをXHTMLに変換できるツール「HTML Tidy」はオープンソースで公開されている。)それどころか、ブラウザでサポートされていないもののみならず、サポートされている規格にさえきちんと対応できていないこともある。対応できていないだけならばともかく、HTMLで構造用の要素であり今後残ることの保証があるStrictに位置付けられているタグを不正扱いするのは明らかにおかしい。

　どうしてこんな風にするのだろう。ページの制作者は自分の望むサイトを作ることを重視するため、そのためならば喜んでブラウザのバージョンをあげるだろうし、プロのデザイナーなら顧客の要望に答える為には多少の苦労を厭わないだろう。なのになぜ、CSSを使ったデザインを基本にし、レガシー(負の遺産)な表示用の要素を使う機能を応用にしないのか。

　さらにいくつか例を挙げておこう。Adobe GoLiveは作成したページのデフォルトのタイトルとして " Welcome to Adobe GoLive " という文章を勝手に用意するという悪い癖がある。確かに、ページにタイトルをつけないのはユーザーの落ち度である。だが、そのことはベンダーに対する免罪符にはなりえない。勝手にタイトルをつけることが、情報を探しているユーザーや検索エンジンを惑わせてしまう原因となるのだから。こういったことはやめるべきだ。むしろ、タイトルから自動的にファイル名が作られるようにして、タイトルを決めないと保存できないようにした方が良かっただろう。こうしていればタイトルをつけることを習慣化させると同時に、ファイル名を考えると言うわずらわしい作業からユーザーを解放することができただろうから。

　IBMのホームページビルダーは、オーサリングツールでCSSを扱う場合における勘違いな実装の仕方の好例である。ただでさえCSSを使いにくいというのに、それ以上に外部スタイルシートを使いにくい……(特にこういうソフトで)スタイルシートを統一的なデザインに使わず何に使えというのか。さらにひどいのは最近のバージョンで実装された「どこでも配置モード」である。HTMLのdiv要素とCSSの " position: absolute; " を利用することで実現した(CSSを使用した機能のなかでは別格扱いの)このモードは、自由自在に意図通りのデザインを行うことを可能にする反面、CSSを適用しないと意味を読み取ることのできない構造のむちゃくちゃな文書を生み出す。つまりデザインを実現する機能としては理想的かもしないが、HTMLエディタとしては失格以前の代物なのである。

　タグ挿入型エディタは好きなところにタグを挿入できる。そして多くの場合、文法的に正しくないマークアップをおこなうことも妨げたりはしない。また、タグ補完型の能力を持つエディタは驚くほど少ない。……どちらにせよ、人はミスを犯すのでHTML/XMLを直接記述することは勧められない。とはいえ、タグつきのデータには処理しやすさや情報の厳密化・再利用といったような利点があるのも確かである。よってあえて直接記述したいという場合には、そのままプログラミング言語のコードとしても利用可能な(埋め込むこともできる)SLiPや SXMLなどのXMLの代替構文を利用して、そこから通常の構文のHTML/XMLファイルを生成することを勧める。そうすれば、プログラミング言語として記述することによるいくつかの利点―ファイルを生成する前の警告によって文書(データ構造)として不正であるかどうか確かめることができるし、(実際にXML文書を生成するためのプログラムの一部として使用するなら)DOMやSAX、XSLT(XSL Transformations)を使わずともそれら全ての利点を持ったような形で文書全体を操作したり、Servletのタグライブラリのように文書のパーツを切り離して再利用・一部だけを更新・自然な形でプログラムを埋め込んだりすることができる(ServletはLispのS式(symbolic expression)の車輪の再発明に過ぎないという意見もある)―を享受することができるからだ。

　Webサイト全体を構築できるツールの多くで、サイトマップの自動生成やきちんとした形でのlink要素生成がサポートされていないのは謎である。確かに最近のブラウザはlink要素をサポートしていないかもしれない。(iCabやMozilla、Opera7ではサポートされている。)だが、テキストブラウザはlink要素をきちんとサポートしているのだ。サポートしない理由がどこにあるだろうか、ツールのベンダー達がlink要素をサポートしていくことがブラウザにきちんとlink要素をサポートさせることへの圧力になったはずであるのに。そうなれば多くのユーザーの手によってlink要素のタイプやサポートし方が検証されたはずであるし、ウェブデザインにおけるナビゲーションの部分はもっと簡潔なものになっていただろうに……(もしかすると、もう必要なくなっていたかもしれない)。また、そうであれば今頃はXTM(XML Topic Maps)による索引リンクの実装に乗り出していたはずだ。(XHTML 2.0導入される予定のnl要素はlink要素の拡張をおこなったものではなく、文書中にナビゲーションを入れるという現在の慣習を追認したものに過ぎない。)

　そういうことができていないのはなぜだろうか？　それはおそらく(他の多くのソフトの例に漏れずオーサリングツールにおいても)ベンダーの側に明確なビジョンがないせいだろう。

　ターゲットを絞り込むことなく、出来上がっているコードを出来るだけ変更せずに使いまわし、自称「幅広いユーザーのニーズに対応した、使いやすいソフト」を提供して満足しているに違いない。またアクセシビリティに対する考慮もなく、そこにはアクセシビリティの高いサイトを作らせるためにユーザーを教育しようとする視点も欠けているようだ。

　これから先、こういうものを野放しにしておくわけにはいかないだろう。健全な進歩のためにも確かな知識と批判の精神が必要とされている。

1.3 HTMLに対する誤解

　特に重要なのが確かな知識である。知識が不足しているとダメなオーサリングツールを見分けることはできないし、自分でHTML文書として好ましくないものを作っていてもそれに気づくことはできない。それに知識が足りないと、批判や提案はしばしば的外れなものや間違ったものになってしまう。

　実際、Webのユーザビリティ(使いやすさ、利用しやすさなど。ユーザーエクペリエンス(ユーザー経験)と言われるものもここに含まれる。)に関する情報を日本人向けに提供することを意図して作られた『ウェブ・ユーザビリティ　ルールブック』という本には、本当にきちんと調べたのかと疑わせるようないくつかの根本的な勘違いや間違いなどが見られる。このような、ある程度知識をもっていると自負する人でも犯しやすい、いくつかの間違いには特に気をつけなければならない。

　例えば、table要素をレイアウトに使うことをよしとする考え方は、日本でウェブサイトのトップページではなくサイト全体をさしてホームページと呼ぶ(日本文化に馴染みの深い韓国や台湾でも同じ誤用がおこなわれているらしい。また、最近では英語圏にもこの誤用は広がっているようである。)のと同じくらい蔓延した過ちである。辛うじてホームページにtable要素を使ったレイアウトをおこなうことは許されるかもしれない。しかしその場合にはsummary属性にtable要素の要約を記述した上で、要約などから類推しやすい名前で下位ディレクトリにコンテンツを用意しておく必要があるだろう。table要素の内容を無視するような実装の存在は仕様上許容されているし(summaryがきちんと書かれていれば問題ないはずである。)、あるいはそうでなくてもレイアウトに使用することできちんと内容を表示することができなくなる可能性があるため、このような慎重な使い方をする必要がある。

　表示用の要素を使った手法が広まったために、起きた誤解もある。それはHTMLは視覚的な表示に対する表現しかできなくて構造を表現できないというものだ。実際はこの逆である。NetscapeとMicrosoft社のいわゆるブラウザ戦争によって相互運用性が失われることを防ぐために、独自拡張によって加えられた表示用の要素などを一時的に「記録した」に過ぎない。(このことが過度に定義づけされようとしていたHTML 3を廃止させ、シンプルなものへと軌道修正させた。そのことが後にMathMLやXHTML、メタデータなどを生み出す土壌となったのだろう。)なお、構造化をより厳密にしたのがISO-HTMLである。

　その証拠にXHTML 2.0では後方互換性を無視してさらなる構造化と再構築が大胆に計られている。h1-6要素を捨て(?)「章」や「節」などの固まりを示すsection要素の導入、p要素の中にリスト/blockquote/pre/tableなどを入れられるようにして、パラグラフとしての役割を強くする、br要素を廃し代わりに行を示すline要素を導入するよう方向づけていたが、さらにl要素へと差し替え、現在どうするか検討しているなど。(pre要素が残るのは詩やPython、Haskellのプログラムのコードなど、インデントやレイアウト自体が意味を持つものの存在を考慮してのことだと思われる。)　このことはHTMLが様々な文書の母体へと、TexやDocBookに近づきつつあることを意味しているとも言えるだろう。

　同様にブラウザの独自拡張を意識しすぎるあまり、object要素をInternet Explorer用のものであるかのように紹介する人もいる。本当はapplet要素やembed要素、bgsound要素、iframe要素、img要素などそれまでバラバラに扱われていたものを統合するものであるのだが……。(そのため、object要素を使えば代替メディアというものを表現することができる。代替メディアの例としては、img要素を使う際に必要とされる代替テキストがあげられる。)

　タグの省略などが許されなくなるからという理由だけで、XHTMLを避ける人も多い。確かにXMLに基づくXHTMLではSGMLに基づくHTMLで許されていたいくつかの記法が使えなくなる。しかしながらそれは許されていただけであって、望ましい記述の仕方はXHTMLで強制される省略などをおこなわないものなのである。

　また、省略などを許さないことでソフトでの扱いが楽になったり、可読性が上がることも忘れてはいけない。それに、MIME(Multipurpose Internet Mail Extension)タイプ(メディアタイプ)をそれまでのtext/htmlからapplication/xhtml+xmlに移行させれば(それまで拡張子は特に定められていなかったが、サーバー側で明示しない限りapplication/xhtml+xmlを使う場合拡張子はxht、xhtml、htmlのいずれかを使わなければならない)、ブラウザに致命的なエラーを発見してもらうことができるため、ほったらかしにせずに済ませれるようになる。(だが、それに安住することなくValidatorなどを使って文法的なミスを確かめる習慣をつけておくといいだろう。文法等の厳密な検査が必要な場合には HTML Validatorや Another HTML-lintなどを使って確かめた方がいい。)さらに、XML文書でもあるということが、自分でタグを作ることで文書を高度に定義したり(class属性を使えば「擬似的」に表現することはできるが、明示性はやや低い。)、別の規格からタグを持ち込んだり、といったようなXMLの機能を利用することを可能にする。(XMLの機能を利用することで未知のタグを解釈することも可能である。)

　そういったことを知らないがために、XMLがさかんに強調されているわりに「ブラウザの独自拡張がさかんにおこなわれていたときのような、目に見えた変化」が現われていないことに苛立ち、XHTML化することのデメリットばかりを強調してしまうのだろう。実際、そういう人からは「XHTML化するとどういうメリットがあるのか分からない」とか、「よく分からないからXHTML化しない」というような意見を聞くことが多い。

1.4 まとめ

　以上が理想からは程遠い、Webの現在の姿である。

　面白いことにこういった状況は、C++というプログラミング言語がおかれている状況と非常によく似ている。例えば「ライブラリを駆使し先進的な技法(テクニック)を使う者達がいる一方で、わざわざC++を使って書く意味のないCを引きずったコードから離れられない者達がいる。C++も普通に使う分には問題はないけれど、コンパイラが規格をきちんとサポートしきれていないために、機能を駆使する必要のある最新のテクニックを使うことができなかったり、使うのに多大な苦労をするはめになることが多い。そんな状況を尻目にさらなる強力な機能が規格として用意されようとしている。」など、おかれている状況の類似点をあげればきりがない。だけどそこには、こういった状況を変えようとする確かな動きがみられる。

　だからこういった状況を変えたいのであれば、C++でおこなわれていることを参考にするとよいだろう。Lispスタイルのプログラミングを望む社内の声を受けて作られたSTLが、外に広がり標準化された。 STLportはSGIによるSTLの望ましい実装をさまざまなプラットフォームに対応させる活動をおこない、その結果Borland C++ BuilderのSTLとして採用されることになった。 Boostコミュニティは「事実上の標準」ライブラリを確立することを目的として活動し、その結果実際に(たっぷりと議論を交わして作られてきた)幾つかのライブラリが標準として承認されようとしている。そのBoostを通じて新しいテクニックが議論され、広まることができる。C++のさまざまな新しいテクニックの潮流が、それらを駆使した Modern C++ Designという本とlokiという革新的なライブラリを生み、その結果コンパイラの開発者はModern C++ Designに使われているさまざまなテクニックとlokiをサポートすることが重要だと考えている。

　それらを見習い、幾つかの積極的な活動を――(アクセシビリティを損なわない範囲で)あまり使われない細かな機能や新しい機能を積極的に活用したり、望ましい機能をサポートしていないソフトをボイコットしたり(逆に望ましいソフトを他者に勧めたり、あるいは自分でソフトやプラグインなどを作って公開したり)、ベンダーに意見を送ったり、議論を交わしたりなどすることによって、多くの人々を啓蒙するための働きかけていくべきだろう。

　いずれSemantic Web(意味を持つWeb)が実現すれば、こういったギャップはすぐになくなる。……しかし、それでは遅すぎる。

　未来のWebは今までとは全く違ったものになる。だからこそ、できるだけ早くギャップを埋めて、現在のあるべき姿に到達し、未来のWebを構成する概念に慣れておく必要があるのだ。

　変化の波がまだ本格的なものになっていないうちに。

2.1 XMLの特徴

　先ほど、相互運用性だけであればテキストファイルにもあると述べた。だがその実、テキストファイルの相互運用性は非常に低いものである。

　周知の通り、テキストファイルで相互運用をおこなうときにはある一定の形式・書式(フォーマット)を使うことになる。別に特にフォーマットを決めていないファイルであっても相互運用は可能であるが、その場合互換性のあるものを作ったり、互換性のある状態を維持することが非常に困難である。これはソフトの新バージョン用のファイルを旧バージョンで開いたとき、新バージョンの機能が利用できないどころか、ファイルとして役に立たないことがあること(そもそも「エラーがあります」とか「不正なファイルです」というようなメッセージがでてきて、開かせてもらえないこともある)を考えてみれば分かるだろう。互換性に対する配慮が足りなかったり、フォーマットが安定していないときにこういったエラーは起きやすい。(互換性の低いフォーマットを作ってしまっても、SGMLやXMLであれば、未定義のもの(この場合、無視することが明確に決められている)などエラーの原因になるものに対する扱いが決められているため、ある程度まではそうした問題に対処できる。さらにXMLであれば、名前空間やスタイルシート、メタデータなどを利用することでそうした問題をほぼ克服することもできるだろう。)

　これを防ぐためには仕様変化のあまりない安定したフォーマットを使うか、SGMLやXMLに見られるような階層構造・フォーマットに対するルール定義が必要である。(もっとも、そうしたからといってこういったエラーが100%防げるわけではない。最近では " ,(コンマ) " を使うだけのCVSのような簡単なフォーマットですらきちんと扱えないというあきれるような出来事、Microsoft社のExcelが「CSV形式で保存した際カンマの数が17行以降異なる」というバグを持っていたことをご存知の方もいるだろう。)

　また、タグ付けされていないフォーマットには、「そこに書かれているものが何なのか、何を意味しているのかが分かりづらい(フォーマットを扱う側の実装に依存することになる)」といった欠点がある。

　次にSGMLとXMLについて考察することにしよう。

　SGMLが静かな革命を起こすに至らなかったのは、(様々な要望を過度に反映した結果)その規格が巨大で複雑なものだったためである。あまりに複雑なために、IBMなどの策定に関わった一部の組織やツールのベンダー達しか使いこなすことができなかった。さらに複雑であるがゆえに、その処理は重く(策定当時のマシンスペックは今よりずっと低いものであったから、なおさらである)、「他のプログラム同様、コンパイルしそれを閲覧する」という使用者にとっていささか使い勝手の悪いやり方が常識であるかのように受け取られていた。このように、SGMLはその巨大さ複雑さがネックとなっていたのである。

　対して、XMLはHTMLのとった戦略をとることにした。文書を扱うためのルールをスリムなものに、貧弱だと言われかねないほどシンプルなものしたのだ。

　また、ただシンプルにするだけでなく、幾つかの新しい概念を持ち込んだ。なかでも重要なのが、記述方法と表現する/される内容(スキーマ)を分離することで生まれた、DTD(Data Type Definition あるいは Document Type Definition)による構文のチェックを必須としない「整形式(well-formed)」と、タグの属するグループを規定することで別の規格から明示的にタグ(定義)を持ち込むことを可能にした「名前空間(namespace)」である。(名前空間の指定はURI(Universal Resource Identifer あるいは Uniform Resource Identifer)への有機的な結びつきとして表現される。つまり単にタグを拡張するのとは違い、複数の規格用のデータとして利用可能な複合ドキュメントが形成されることになる。また、こういったことを楽に行うためにも整形式という概念は重要である。)さらに(出遅れた感は否めないが)XML Information Set (Infoset)で、XML文書の11種類の情報項目におけるデータモデルの基礎的な部分の定義(抽象的な規定)が示されたことによって、XMLの各種応用規格の制定・把握・連携がやりやすくなった。

　ここでXMLはSGML時代の遺産を全て捨てさったと受け取られるなら、それは大きな誤解である。

　XML文書として作られたものは(DTDが必須でないことを除いて)概ねSGML文書としても適合するようにデザインされているし、DOMも(HTMLの操作系である)Dynamic HTMLがもとではあるものの、その制定にはXMLのみならずSGMLのツールのベンダー達が深く関わっている。つまり、XMLはSGMLの血肉を受け継いでいるのである。

　また、XMLはSGMLを古いものとして否定したわけでもない。SGMLの製版・印刷に対する役割の大きさは認めている。しかしながら、情報がWebという形を取る場合使い勝手が悪い。そのため、Webにより適したものとしてXMLが用意されたのである。

　要するに、両者の違いは「取ろうとするアプローチの違い」であると言えるだろう。

　実際、SGMLではスタイルシートにDSSSL(Document Style Semantics and Specification Languge)のようなScheme(Lispの方言の一つ)ベースのプログラミング言語を採用することで強力さを追求しているのに対し、XMLではCSSを採用したり、Web用に機能をしぼった上でLispのS式ではなくXMLの書式を使ったXSL(Extensible Stylesheet Language)を提供し、親和性を持たせようとしている。これはXSLを規格化する過程で、他の文書へと変換する役割を独立した規格にしたことからも窺い知ることができるだろう。(念のために書いておくがDSSSL自体はSGML文書として定義されているし、次に述べるようにXMLに比べて遥かに記述しやすくインデントが適正におこなわれているなら読みやすい。ここでの問題は様々な記法を認めたことではなく、(変換ツールを用意もせずに)ある文書に対し特定の記法を用いるように強制したことによって、様々な記法を学ばなければならなかったことにある。)

　……だが逆にXSLのXMLを使った記法が面倒で書きにくいという批判もあるし、機能をしぼりこんだことで強力さを失ったため、それ以上のことをやろうとするとXPathやjavascript等との連携が必要になる。(XSLT2.0ではxsl:function 要素等の導入によって、この状況が多少改善されはするが……)よって、結局のところXSL(T)の強みはブラウザやエディタ等、XMLアプリケーションによって直接的にサポートされることであり、そのような利点を生かせないのであれば中途半端なこれを使うよりも最初から別のプログラミング言語(特にパターンマッチの機構を持つ関数言語や、それ自身がXMLのもう一つ記法となるライブラリを持つ言語)を使うことを選んだ方が良いだろう。

2.2 XML Schema

　だが、XML=シンプルという図式はもはや妥当ではない。XMLに対する支持はあまりにも急速に、あまりにも大きな範囲に広がりすぎた。それゆえ数々の仕様は策定までに長い議論を経ることになり、その結果、Javaの時のようにシンプルであると喧伝され、そう思わされてきたものが複雑かつ難しいものであると気づかされるに至った。(余談であるが、C++のなかでJavaが複雑になるとして敬遠したまさにその機能によって、より簡潔なLisp的記法(数学的記法)などへの道を歩みつつあるという事実は皮肉である。)

　その代表格がXML Schemaである。XML Schemaは当初、DTDに代わるXMLの書式を使ったより強力(詳細)なスキーマとして注目されていた。だが、先に述べた通りXMLの予想外の広がり見せたため、当初の電子出版だけではなく様々なデータを取り扱えるようにする必要があった。そうして策定に加わっていった広範囲の人々の要望をポリシーなく受け入れていった結果、巨大で複雑な規格となり、作業は難航することとなった。

　また、習得に対する苦労のわりに、肝心な部分で機能の制約があるため見返りは少なく(処理系によって解釈が違ったりする。)、実質的な能力は XML Schema = DTD + データタイプ + 名前空間に過ぎない。(このことは 『XML Schema: やるべきこと、やってはいけないこと』に詳しく述べられている。)　その結果XForms等XML Schemaを利用する応用規格では独自にカスタマイズをおこなってしまっているため、データモデルが乱立するという新たな問題を生み出している。

　こうした状況を見てXML Schemaから離れ、独自にスキーマ言語を作ろうとするいくつかの動きがあった。そのなかの一つが村田真によりISO規格となっているRELAX(REgular LAnguage description for XML)であり、一つがJames ClarkによりOASIS(Organization for the Advancement of Structured Information Standards)の規格となっているTREX(Tree Regular Expressions for XML)である。

　その後、軽量級の規格が複数存在していても混乱させるだけで益がないという判断から、二人は協力し、この2つを一つにしてRELAX NGが作られた。この新しいスキーマ言語は、名前とは裏腹にTREXを基にRELAXの機能や思想を取り入れることで作られている。” スキーマ言語RELAX NGは、Document Schema Definition Languages(DSDL)のPart 2として2003年3月ごろにISO/IECの国際規格になり、ほぼ同時期に JIS規格になる予定”(『[xml-users 7940] RELAX NGのISO/IEC規格化について』(http://www2.xml.gr.jp/log.html?MLID=xmlusers & N=7940))である。

　XML Schemaは他での使用を考慮したり、データ交換を重視して作られていたため、実はこういった規格もデータ型の定義にはXML Schema Part 2にあるものを利用している。だが、そのことを以ってXML Schemaの有用性を語ることはできない。上記の繰り返しになってしまうが、本当に有用なのであればこうした規格は作られなかったはずであるし、 あまりにデータ交換を意識しすぎた結果、XML Schemaでは、XML本来の目的であったドキュメントとしての利用が困難になってしまうという問題もあるのだから。 また、XML Schemaの仕様があまりに巨大なため、XFormsのようなXMLの周辺仕様では、XML Schema仕様の一部だけを自分の仕様の中に取り込むようになっており、一貫性のないモジュール化があちこちで勝手に進む問題も指摘されている。(それゆえ、XML Schemaの利用は危険であると言われる。)

　以下にOMOMEMOというweblog(web上にある興味深いものへのリンクとコメントを載せたもの。blogとも呼ばれる。この定義によると、Web日記やニュースサイト、掲示板も一種のweblogであると言える。ここではそれを簡単に生成するためのシステムを使ったサイトのことをさすことにする。なお、それらを総合した一般名称として使おうという動きもある。)に掲載されていた、「 『James ClarkによるRELAX NGとW3C XML Schemaの比較』の要約とそれに対するコメント」(現在ではこのweblogは消えてしまっている。)を引用しよう。

James Clark いわく, XML Schema はダメだっつーの.

• RELAX NG は シンプル. 30 分でわかる. XMLSchema は複雑で誤解をまねく罠が多い
• XMLSchema の仕様書は救いがたく読みにくい
• RELAX NG は仕様書でセマンティクスを形式的に記述している. XMLSchema の形式化は遅々としてすんでない. そもそも形式化するための枠組みがない. RELAX NG は tree automata という理論的バックグランドがある
• attribute の記述能力が DTD 並にへっぽこ. RELAX NG は element と同じ枠組みで扱える
• XMLSchema 　unordered な要素のサポートがへぼい(要素の順番を指定する方法がへぼ言ってこと?). RELAX NG はそのへんもばっちり.
• XMLSchema におけるデータ型の扱いは モジュール化されてなくてしかも ad-hoc. RELAX NG のデータ型は modular. ドメイン依存のデータ型もドンとこい.
• XMLSchema はルート要素を指定する方法がない(まじっすか）. RELAX NG は指定できる
• xsi:schemaLocation はセキュリティは interoperability の観点からヤバイ (ふーん)
• XMLSchema は infoset まわりのやばい(よくわからんけどデフォルト値とかそういう話らしい).RELAX NG は valid/invalid 判定の機能しかないので明解.

　(XMLでは様々な規格が結びつき連携しあうようにデザインされているため、当然のことではあるが、)汎用性と統合という姿勢そのものには否定すべきところはない。HTMLから分離して機能を強化し、再統合される規格としてはXLink、XPointer、文書の取り込みを扱うXInclude(XML Inclusions)、フォームでのやり取りを扱うXForms、フレームの再定義であるXFramesなどがあげられる。(ただし、後二者には問題がある。XFormsについては既に指摘した通りであるし、XFramesに関してはブラウザが善良に実装してくるかどうかが心配である。場合によっては現在のようにデータの互換性やアクセシビリティに問題をきたす可能性がある。)これらの機能はHTMLを強力に……悪く言えば複雑なものへと変える。けれど、HTMLではXML Schemaほどの混乱を招くことはないだろう。HTMLという基盤が固まっているために、それらが強化する場合の位置付けがはっきりと見えているからだ。だから、こうした規格を何の疑問もなしに受け入れるようなことはせず、例えばXLinkであればHLinkのようにより望ましい姿を模索していこうとする。(同じく現在の仕様では少々使い勝手の悪いXPointerに対しても、このような使いやすさが提供されることを期待したい。)また、HTMLでは規格の普及にいくらかの猶予を持たせている。例えば、すぐには廃止せずにまずは非推奨に設定しておいたり、現行のHTMLを最新版のものとせずに(レガシーなものを含む)XHTML 1.0にしているところに、それは見られる。(その流れにすらユーザーがついてこないということもあるが……)　

　よって、XML Schemaの失敗は特に規格に対するビジョンを決めることなしに、盲目的に要望のある機能を豊富に提供しようとしたところにある。これとは逆にDOMは様々な規格を貪欲に取り入れているにも関わらず、最初にはあまり大きくはない規模での規格を出し、その後追加のモジュールを導入させるという形で発表するという方式を取ったことで、その地位を揺るぎないものにしている。(とはいえDOMもやはり後述する問題を抱えている。)今後、こういった姿勢に代わることを(そうして規格をすっきりさせることを)願ってやまない。(一番気まずいのはSGMLの時のように、IBMやMicrosoft社、Sun Microsystemsなどの巨大企業に支えられてこのまま生き延びつづけるという展開になることである。そうならないように祈りたい。)

2.3 XMLに関する問題点といくつかの試み

　完璧であることは望めないとしても、世に広がる技術が理想的であることすらまずなく、広がりと共にそうした欠点が目立つようになる。だが、そうした意見は多数の中に埋もれてしまうため、(外側から見て)それに対する活動は細々と続けられていくことになる。使いにくいさや欠陥は気になる人には気になるが、そうでない人は気づかなかったり、当然のことのように受け止めてしまい、むしろ移行コストの方を気にしてしまうからだ。それはかつてLispでドライバを書いて収入を得ていた人がいたり、Lispで書かれているOSが存在するにもかかわらず(最近でもPS(PlayStation)2のゲームのプログラミング(メモリ管理を含む)において活躍した例がある)現在手続き型(命令型)のCが広く使われていることや、よりメンテナンスのしやすいPythonやRubyが現れてもあいかわらずPerlがその地位を保ち続けていること、文字コードに関する議論などを見てみればよく分かるだろう。(文字コードについては、 『文字コード問題を考える』ほら貝やそこで紹介されている文献を参照のこと。)

　(Lispと同じ関数言語系に属する言語はアルゴリズムをほぼ直接的にコードに反映でき、命令型でよく使われる状態を保持するような副作用を伴うコードを多くの部分から切り離すことができるため、学習に優しく、その上多くはインタラクティブなインタプリタを備えているため、Cと比べて早くバグの少ないプログラムを作り出すことができる。実際、関数型言語を使うものや関数言語に似た状況を指向するもの達は、設計がそのままコードになることを利点として語るし、パフォーマンスが問題になるときはじめてCなどの命令型言語を使うことを選び、そのときの仕様・設計書として関数言語のプログラムを利用するというやり方を勧めるし、関数言語のなかには実際に仕様記述を目的として作られたものがプログラミング言語化したものもある(祖先のLispからしてもともとは数学の記述方法から生まれたものである)。さらに言えばその中の一つ、簡潔な記法と型推論(これによって正当性の証明に基づくプログラム(データモデル)の厳格なチェックが可能)などを用いるML(Meta Language)の子孫であるOCamlはその上Cよりも速いコードを吐く。IDEを含めたGUI環境まで兼ね備えた純粋遅延関数型言語(Concurrent) Cleanも同様に以前はCよりも速いという評判だったが、現在ではコンパイラの記述言語をCからClean自身に変更してゼロから書き直したため、若干遅くなってしまったようだ。大きなプログラムではコンパイル速度は約1.7倍遅くなってしまうらしい。とはいえ、 " 依然として純粋関数言語としてはかなり印象的 " (『Clean Version 2.0 言語報告』原文: " Clean Version 2.0 Language Report " )なようである。)

　XMLもまた同様の問題を抱えている。まずUnicodeの存在を前提としている技術のため、文字問題を抱え込むことになる。構造化したテキストという特徴から(xml:langの属性を使って言語を指定したり、SVGを使って文字の外見を埋め込んだり( 『古代へのXML』参照)することで)一見こうした問題を回避できるようにも見えるかもしれないが、URIの国際版として現在検討中の、アドレスに利用できる文字列を従来のASCII文字だけからUnicode文字全体に拡張したIRI(Internationalized Resource Identifiers )ではこうした問題を避けて通れない。さらに(本来は無視するはずの)改行文字の意味を受け取ったり、IBM一企業の都合で必要となる文字を受け入れたりなど、いくつかの批判されるべき失策も見られる。

　SGMLやHTMLの歴史を引きずっているXMLの書き方はまわりくどく、決して人にとって使いやすいものではないという立場から、より簡潔な書き方として SOX、機械での処理しやすさに注目した行指向のPYX、プログラミング言語であるPythonの書き方をもとにしたSLiP、DSSSLで使われていたS式の書き方を復活させた SXML(これは単なる記法にとどまらず、XML処理用のライブラリでもある。)といった記法を用いることが提案されており、それに対応したツール(ライブラリ)も存在するが、今のところこうしたものを利用しているのはごく小数に留まる。(RELAX NGのValidatorである Jingでも、独自の簡潔な記法をサポートしている。RELAX NGの場合にはXML記述/独自記述のからもう一方の記述、XML Schema、DTDへの変換をおこなう Trangという公式のツールが提供されているので、今のところ相互運用性の心配をする必要はない。) XML用の代替構文を調査するでこれらの簡単な例を見ることができる。

　DOMやSAXは標準的なAPIであるが、これもやはり汎用的であるがためにまわりくどく使いにくい。また、関数言語系からみれば命令型オブジェクト指向にべったり依存する形で煩わしい。SAXの場合、さらにイベントドリブンであるためにXMLの持ち味を全く生かせてないという手厳しい批判もある。よって、そうした立場からそれぞれの(プログラミング)言語に特化したAPIを実装するという試みも多いが、既にDOMやSAXがデファクトスタンダードとして認識されているため、外から見るとマイナーなイメージがつきまとってしまうことを否定できない。とはいえ、使用者にとってはそのようなAPIの方が遥かにうれしいようである。実際いくつかの解説本では、DOMやSAXに対してもう少し高いレベルでの処理を可能にするラッパーを用意している。最近ではこれに対する解決策として、同じW3CのXML技術であることやXSLTで利用可能なことによる認知度を生かして、SchemeのSXMLやRubyのREXML、C++のSOXライブラリであるyggdrasill(世界樹)のようにXPathを採用するものが増えているようである。

　マイナーではあるものの、現在のところXMLを扱える最高のAPIとしてSXMLの他にHaskellの HaXml(とその周辺のXMLライブラリ)がある。HaXmlはSXML同様XSLTのように他の文書に変換しつつ、同時にSAXやDOMを使ったのと同じようにフィルタなどの文書操作をおこなえるというそれぞれの良いとこ取りなものである上、DTDをモジュール(Haskellプログラムのデータ構造)に変換したものが型推論に利用できるため、自動的にDTDに適合しないコードを書くのを防ぐことができる。(その反面Servlet的な使いやすさに多少欠けるため、操作関数の不足が気になるところではある。)おそらくHaskellに似た言語であるCleanでも実装されれば同様のものになるだろう。

　C++でもSTLやlokiの思想を吸収したMPL(the Boost C++ template metaprogramming library)のような関数型プログラミングをサポートするライブラリの存在や、templateを利用して厳格な型チェックをおこなうテクニックが存在する(ある程度ライブラリ化されている)こと、BoostのspiritというパーサーフレームワークがC++のオーバーロードを悪用して、多少変更が必要であるがEBNF(拡張BNF(Backus Naur Form))記法そのものを書けるようにしていることを考えれば、こうした状態に至るのもそう遠くはないだろう。(ただし、もともとの関数言語に比べてあまりにも迂遠なスタイルになってしまう。これをかなり解決したML Interpreter for Template Metaprogrammingというアイデアも出されているが、こうしたものの実用化はまだまだ先だろう。また、コンパイルにそれなりの時間がかかりそうでもあるため、いっそのこと関数言語からの変換スクリプトを書いて、最適化や(C/C++のライブラリに依存する)ライブラリの基本部分を作るときだけ利用するようにしてしまった方がいいかもしれない。)

　XML Webサービスにおいても、同様の問題は存在している。技術者中心でユーザーのことを考慮せずに決められた規格であるため、SOAP(Simple Object Access Protocol)を利用して構築されたWebサービスによって生成したURLが、直接リンクとして用いるには有効なものではないという状況が色々なところで起きることになってしまった。提供側にとってはCGI(Common Gateway Interface)、Webアプリケーション、Webサービスそれぞれの定義や特徴の違いが当然のものであるかもしれないが、ユーザーにとってはどれも同じWeb上の機能(サービス)に過ぎず、そのためこれらの違いは全く見えないことが期待されている。よって、この欠陥は手痛い。この問題に対し、 REST(REpresentational State Transfer)いうスタイルを用いてWebサービスを構築することが提案されている。以下に 『Webの「正しい」アーキテクチャ』(番号なし)とOMOMEMOの 『REST - An Architectural Style, Not a Standard』(番号あり)からこの提案の要約を引用しよう。

• Webサイトが保持していて、外部に公開される内容には、すべて（論理的な）URI(URL）が付いていなければならない。
  1. 1.REST で作る web service のミソは 概念的なエンティティに識別子を与えることだ
  2. 2.各リソースに URL を振れ. 名前には動詞でなく名詞を使うこと(たとえば getPart ではなく part)
• Webサイトへアクセスした結果返されたものがリソースの表現（Representation）であり、ページからページへの遷移が状態の遷移（State Transfer）と見なされる。
  1. 3.データを受けとるだけのものと, データを書換えるものにリソースを分類せよ.
• Webサイトへのアクセスは、HTTPのPUT（Create)、GET（Read）、POST（Update）、DELETE（Delete）で行い、それぞれ処理内容に合わせた結果が返されなければならない。
  1. 4.GET なリソースの取得に副作用を伴ってはいけない.
  2. 5.相互接続型のリソース表現(ハイパーリンク)
  3. 6.データを孤立させない. あるデータから関連するデータへのリンクを用意せよ.
  4. 7.データを徐々に与えるよう設計せよ. つまり一度にデータを送るのではなく,詳細へはリンクを用意する

また、状態を持たせず、変わりにキャッシュを用い、プロキシがそれを活用できることが想定されているようである。……幸いにも批判を通してSOAP1.2の現在のドラフトでは不足していたHTTPバインディングでGET利用する手順が追加され、問題が解決されようとしている兆しがある。しかしながら、HTMLと同じくこうした提案が受け入れられるようになるには多くの時間がかかるかもしれない。

　最後に、BEEP(Blocks Extensible Exchange Protocol)というプロトコル・フレームワークについて説明しよう。BEEPは、SOAPのHTTPバインドやHTTPを拡張したWebDAV(Web-based Distributed Authoring and Versioning)のように何でもHTTPにやらせようとする動きはポート80に過負荷をかけてしまうし、またHTTPの対話モデルに拘束されてしまう結果、非同期、ステートフルな対話、ピアツーピア通信などを直接的ではない複雑な形で実装しなければならないという問題を抱えていると指摘する人々の間から、HTTP、FTP、SMTP、SOAP、およびさまざまなインスタンス・メッセージング・プロトコル、それぞれの特徴を抜き出し、それを再実装(再構造化(リファクタ))するものとして出てきたものである。

　BEEPは他にもいくつかの新規格としての強みを持っている。最初から暗号化や認証等、セキュリティを考慮した機能を持っているため、IPSec(IP security protocol)の一歩踏み込んだ運用を低レベルな操作を必要とせずに、(XML DTDとして定義された)プロファイルを変更するというごく簡単なやり方で柔軟におこなうことができるし、またやりとりできるデータの種類に制限を設けず、任意のタイプのペイロードをサポートするためにMIME規格を使用するため、 SOAP メッセージ内部でXML文書やバイナリー・ファイルをどのように送るかというSOAP の問題は、この方法によってうまく回避できるのである。

　この規格に限っては、実装や利用者が増加傾向にあり期待が持てる。とはいえ、まだまだ普及していないため現状ではファイアーウォールを越えることができず、それを理由に使用が見送られることも多い。よって、一般的に使われるどうかはこれからが勝負であると言えるだろう。

2.4 まとめ

　ここではXMLの明と暗について記した。……とは言っても、XMLの場合ただ暗い面が存在するわけではない。

　XMLの技術に暗い面があれば、それを改善するために必ず良くするための手段や代替が現れることになる。普通ならばそうした部分を改善した新しいものの登場を待つ必要があるのに、XMLではこれまでの延長線上に改善が現れることができる。これがWebの時代に、多くの自由度や拡張性を持ち、それらで人々を魅了していったXMLの強さである。 　残念ながらこうした改善はまだあまり普及していないし、手の行き届いてないものもある。だけど各種規格の実装状況やWeb上のサービスに見られるような各種技術の乱立状態を見れば分かる通り、まだ技術は完成していない。まだ安定と惰性の時期ではない。だから、そうした改善が広まる余地は十分にある。

　バイナリの互換性を喧伝していながら競争・対立のために結局そうではなくなってしまった過去のUNIXの過ちやWebブラウザのような過ちに陥ることなく、これからもXML技術は当初の精神を守り、コンピューターにではなく利用するものにとって扱いやすい理知的にシンプルな方向へと進み続けることができる。そう、信じたい。

3.1 Wikiというシステム

　Wikiは不思議なシステムだ。実際に使ってみないとよく分かないかもしれないが、あえて説明すると、BBSが突然変異を起こしたようなシステムで「誰もが、コメントをつけるだけではなく、編集したり、新しいページを作ったりすることができ、そうしていくことによって共有物としてのサイトが構築される」という変わった性質をもっている。この中ではサイトという概念が非常にあいまいなものになる。そのWikiがどこのサイトに属するかということには関係なく、Wikiの中に構築されたもの、場合によってはそのさらに一部、あるいは関連付けられたいくつかのWikiにまたがるページ群を一つのサイトだと認識することもおこりうるのである。(もっともある特定のトピックならともかく、複数のWikiの境い目があいまいになるようなそういう事態が生じた場合には、リファクタリング(複雑化したり過剰に分散したりなどして醜くなった構造を、すっきりするよう整え直すことを意味する、プログラミング分野での用語。)したり、複数のWikiを統合したりする必要があるが……)

　「誰でも編集可能である」という事実は、だからといって何でも書き放題・荒らし放題の無法地帯である、というようなことを肯定するわけではない。むしろ誰もが管理人となれるがゆえに、そこにいる人々はそこで構築されたコミュニティの規範に従って振る舞うようになるし、もしいたずらされてもすぐに誰かが元にもどすことができるし、オープンソースで自由に改変することができるため、悪質な行為に対するチェックなどの対抗手段を用意しておくことも可能だからだ。(実際、ページのバックアップはWikiの標準的な機能であるし、多くの実装はHTMLのタグを禁止することで閲覧者に危害を加えるスクリプトを置くことを未然に防いでいる。…もっとも、後者にはHTMLのタグを用いたページは気軽に編集することへの障壁となるという思想も込められている。)　また、完全に信頼のできる意見というわけではないが、「あまりに簡単にいたずらができてしまうために、やる気にならない」という意見もあるようだ。

　だが、着目すべきはそういった自浄的な働きではない。むしろ「ある瞬間のそこでは無価値であったものを、次の瞬間に有用なものへと変換するために別のところに持っていく、ということを簡単におこなえる仕組みがある」ことにこそ着目すべきだ。Wikiの持つ、書くことの簡単さ、編集することの簡単さ、新しくページを作ることの簡単さ、Wiki内のページにリンクを張ることの簡単さ―単語やフレーズに対してリンクを張るため、URLを意識する必要は全くない。これから作る予定のページへのリンクを用意することだってできる！　さらにInterWikiという異なるWiki同士をシームレスに結びつける機能によって、他のWikiやArchiveに保存されているメーリングリストのメール、ISBNやRFCなどのURN(URLを補完するURIの概念。URLがインターネット上のアドレスを示すのに対し、URNはこれにISBNが含まれることから分かる通り本などのリソースそのもの(名前)を指し示す。なお、これをサポートしたソフトではリンク先としてそのリソースそのものかそれに対する適切な資料のあるサイトへと転送する。)に対しても簡単にリンクできるようになるし、もちろんシステムの側でフォローしていればリンクを貼ってきたページに対し自動的に逆リンクを結ぶこともできる―が、それを可能にする。勘違いや間違いがあっても、誰かが指摘してくれてすぐに直すことができるから、それらを恐れずにどんどん文章をアップすることができる。おまけとして検索機能もついているので、(より望ましい結果が欲しければこまめに整理しておいた方がいいけど)書いた文章がどこにあるかを簡単に見つけ出すこともできる。

　文書を作成・編集するためのツール、アップロードするためのツール、いくつかの文書をまとめた全体を管理するためのツール……もはやいちいちそのようなソフトに頼る必要などないのだ。(ただし、現在の実装では編集中に他の人が編集してしまった時ページの更新全体にロックがかかってしまうため、その場合エディタ等でデータを保存しておき一度更新してから再度編集する必要がある。それに一部だけを編集したいという状況では全文編集は面倒に思えるところもある。そのため、一部だけを編集でき(そこだけにロックをかけ)る Click Critique(クリクリ)のような機能を組み込もうという提案がある。)とは言っても、もちろん利便性のためにお気に入りのエディタ等を利用することは否定されない。強制ではなく、利点であり自由なのだ。

　この簡単さ気楽さこそWikiの本質である。いつでも簡単に編集できるし誰でも簡単に編集できるからこそ、気軽にメモ帳のように書き散らすことができる。実際、語句を定義するためだけに新しいページを作ったり、そこに自分のページの出張所を作ってみたり、アイデアや自分のサイトのコンテンツのもとなどを書き散らしている人も結構いるし、ローカルな環境でメモ帳として使っている人さえいる。

　一方で、まとめようとさえ思えばいつでも簡単にまとめられる。そういった作業は自分がやるのかもしれないし、誰かがやってくれるのかもしれない。この時、誰もが簡単に編集できるという特徴が大きな利点をもたらす。文書が多くの人々の手で修正・改定され、次々と新しいページが付け加えられリンクで結ばれていくことによって、その文書は正確かつ重要(貴重)なものへと進化していくのである。この結果、Wikiのページが参照すべき価値の高い文献としてあげられることもある。(こうした文書が発展していくプロセスについては、 『ハイパーテクスト - 活字とコンピュータが出会うとき　第5章文学教育の再編』が詳しい。)

　この現象はオープンソースのモデル、特にバザール方式と呼ばれるものによく似ている。実際、Wikiを使って百科事典を作ろうとする試み、Wikipediaはオープンソースのプロジェクトである。

　オープンソースのモデルと似ているということは、同時に、オープンソースと似た弱みを有することをも意味する。必ずしもオープンソースのプロジェクトのように明確なリーダーを必要とするわけではないが、それでも運営の初期には積極的に関与する書き手が必要となるし、まとめようとすればいつでもまとめられることが引き起こす負の側面――誰も整理しようとはせずに書き散らしたままの状態で残される――を解消し、Wiki上のコンテンツの構造化を計るためには、構造化作業を積極的に行って規範を示す編集者の存在が欠かせない。そういったものの存在を軽視したWikiはうまくいかなかったり、後で致命的な問題を抱え込んだりする。

　初期の準備不足がWikiを失敗させる、その理由は至って簡単なものだ。人々はWikiの持つ極めて強力な特徴――自由に書いたり、編集したりすることができる、ということに対して慣れていない。他人のものに対してそう扱うことに慣れてはいない。そのため、皆が共有するために置かれているとはいえ、かってに書き足したり、改変したり、編集することに気後れを感じてしまうのだ。よって、そこで対象としようとしている話題をいくつか並べたり、その話題に対する具体的なページもいくつか用意したりすることで、基本的な構造や「こういうことが書ける、このように書いてもよい」という見本を提示する必要がある。場合によっては、自由に使ってもいい旨を明記しておく必要もある。

　また、現状では文書に対してコメントをつけることで、文書を書く(ドキュメントモード)以外のもう一つのモード、ページ上で会話を繰り広げるスレッドモードが存在することを気づかせる必要があるだろう。これによって、Wikiがオープンなものであり、コメントによってフィードバックが得られる・与えられることを伝えることができる。Wiki上でスレッドモードが成立しなかった場合、文書は他のWebページ同様静的なものになってしまうし、きちんとした文書を書かないといけないと思うあまり、気後れしてしまうからだ。こうなってしまうと、Wikiはうまく機能しない。それにこうしてコメントを入れておくことで、足りなかったり直さなければいけなかったりするところや、文書に関する誤解などを示した記録を残しておけるといった効果もある。だから最近ではWikiとBBSを一体化させたり、(Web日記等他の静的なページへのコメント機能から着想を得た)コメント書き込み用のフォームを持たせたり、という試みも行われている。

3.2 Wikiにとって望ましいもの

　次に視点を変えて、Wikiの位置づけについて目を向けてみよう。 　WWWはハイパーテキストとインターネットを結びつけることで、ハイパーテキストの規模を全世界に広げたという意味で進歩的であったが、同時にハイパーテキストの仕組みとしてはおそろしくシンプルで後退的なものであった。

　これには歴史的な理由がある。ハイパーテキスト関係者の協力を得られず、すべてを自分(達)でおこなうしかなかったし、人々に受け入れられやすいようHTMLを簡単なものとして提供した。その結果、(最初のクライアントはブラウザ兼エディタであり、ブラウザ兼エディタ用のソースコードを提供していたにもかかわらず、)副作用としてブラウザとエディタの間に溝があいてしまったのである。

　そのため、現在のWWWは協調作業の産物とはいうよりもむしろ、それぞれのサイトが独立した出版物のように扱われ、人によっては情報リソースとして価値・利便性よりも私物としての意識が重視するような状況になってしまっている。特に企業の場合、この傾向が顕著である。

　こうした中で、消えてしまうかもしれないリソースを保存しようという試みがさまざまな形での(Internet )Archiveであり、既にあるコンテンツのリソースとしての側面をより強化していこうという試みが後に述べるSemantic Webであり、ハイパーテキストとしての本来の能力を取り戻そうとする試みがWikiである。将来的には、完全な過去の資産を持つSemantic Webそのものを積極的に活用するというような形で三者は結合するだろう。しかし、そこまで巨大なものに成長するにはまだまだ時間が必要であるし、Wikiが理想のハイパーテキスト、ハイパーメディアに近づくまでにやるべきことはまだまだたくさんある。例えば、かつてのハイパーテキストシステムには存在した関連するコンテンツの関係を(グラフィカルに)表示したり(もちろん、そのなかの任意のコンテンツにアクセスできる)、関連付けや内容を対話的に変更するなどような機能は(もしかしたら存在するかもしれないが一般的には)まだ備わっていない。

　JAVA Appletやjavascript、Flash、ASP(Active Server Pageの方だが、ブラウザ上に提供しようという多くのApplication Service Providerも同じく。)などはWikiとは正反対のものである。確かにこれらはWikiを増強するのに役立てることができるが、これらはブラウザのインターフェースを拡張・改造するという性質上、インターフェースを一般的なものから遠ざけ固有のものにしてしまい、その結果(ユーザーの参加への障壁となり)Wikiのオープン性を失わせてしまう可能性が高い。また、ある程度広まっている種類のものを採用したとしても、競合するものが存在したり、場合によっては一般的なアプリケーションのできるものをWeb上に実装させていることが多く、その場合ユーザーから自由を奪ってしまうことになる。(同様のことが操作系も取り扱うときのSVGとSMIL、VoiceXML、音声操作のみに特化することなくマルチモーダルであることを意識したVoiceXMLの対抗規格であるSALT(Speech Application Language Tags)にも言える。Webサービスをうまく利用して、ユーザーの望むインターフェースを提供したり、インターフェースを切り替える、といったことをサポートすればこうした問題の一部は解決できるだろう。)かつて特定の組織内だけで運営されていたハイパーテキストシステムとは違い、開かれたシステムであるWikiにとって、そうしたことが起きてしまうのは致命的である。(もちろん、組織内で利用するというのもよいやり方である。)

　よって、インターフェースを拡張・改造するよりも、扱うフォーマットだけを決めて様々な道具を利用可能にした方が望ましい。実際PalmでのWikiの実装(PalmWiki)とデータを融通しあうための仕組みや、InterWikiに見られるような複数のWiki間でのデータを共有する仕組みの提案などは、そういった観点からおこなわれてきた。(ここで挙げた例の中に(PDA(Personal Desital Assistant)ではなくPCの)エディタからWikiを編集する仕組みを入れた場合、賛否両論が起こるだろう。なぜならUNIX文化圏で有名なEmacsというエディタは、常にそういった本来エディタでできること以上の機能を、拡張して取り込むということをやってきたからだ。)

　様々な道具を受け入れることによって、Wikiは無限のインターフェースを手にすることができる。ある種のインターフェースにとらわれることがないから、音声操作や磁気でインクを固定する電子ペーパーなどに舞台が移っても生き続けることができる。同時にキーボードが少数派になったとしてもWikiは差別しない。ここにこそ、Wikiの価値があると言えるだろう。

　……とはいえ、キーボードが将来なくなると想像するのは早計である。電子ノートや音声操作が一般的になっても、キーボードがなくなることはないだろう。ライトペンがはやらずにマウスが使われることになった背景には、垂直の画面では書きにくく、疲れるといった理由があったわけだが、キーボードをそのような過渡期的なデバイスと一緒にしてはいけない。キーボードには入力の速さという利点がある、これはペンや音声では変えがたい。

　ただし、キーボードで入力する必然性はなくなるため、(移行コストを無視して)より効率のよいものが求められることになる――現在のQWERTY方式のキーボードはなくなり、それぞれの使用言語とその幅に応じた最新の研究に基づいた入力方式(例えば自国語のみを使おうとする人と、英文混じりの文を書く人、プログラミングもおこなう人、ドイツ語や韓国語、アラビア語など多国語を駆使する人では、それぞれ望ましい入力方式が違う)と、(富士通のJapanistと同じく)言語入力ソフトという立場ではなく予測と例示による補完機能という立場から作られた入力ソフトであるPOboxや同じくそれまでの入力結果をもとに動的にマクロを作り上げるDynamic Macroのような補完機能を、組み合わせて使うようになるだろう。需要次第ではキーボードが売られなくなるかもしれないという可能性からこの意見に疑問を覚えるかもしれないが、それはVirtual Devicesが開発した キーボードの画像を適当な平面上に投影し、その投影画像をタイピングしてデータを入力できる、小さなデスクランプのようなデバイス「Virtual Keyboard」のようなものを使うことで対処できる。こうした技術は何もキーボードのみに使われるものではないからだ。

3.3 まとめ

　Wikiとその周辺について簡単に紹介した。

　より詳しい説明は 『Wiki Way - コラボレーションツールWiki』に書かれているが、まずは実物を見て触ってみた方がいい。その方が実感がわいて分かりやすいいだろうし、システムとしてもコンテンツとしても日々様々な変化が試みられているからだ。現在ではPalmWikiやEmacsWikiのように、わざわざサーバーに設置しなくてもいつも通りの形で強力な個人的なメモあるいはノートとして利用のできるWikiエンジンも出てきているが、やはり醍醐味は他の人との共同作業にあるだろう。(これらはテキストにWikiとしての機能を付与しただけなので、LAN(Local Area Network)内にファイルを置いて共有する、というのももちろんありである。)業務やメーリングリスト等などでの会話をまとめたり、または議論のための資料として活用するためのコミュニケーションツールとして利用するとき、Wikiはその真価を発揮する。保存性と変更容易性を兼ね備えているため、これまで壁であった、記録が残らない、残っても探しにくい、ドキュメントが古いままで役に立たないといった問題をある程度までは解決することができるのだ。

　Wikiの誰でも編集でき、できたものを誰もが自由に利用できるという性質は、次のSemantic Webとつながるところがある。果たしてWikiはこの先どう変わっていくのだろうか？　今後の進化に注目したい。

4.1 メタデータ

　この中核をなすのが、メタデータと呼ばれるものである。メタデータとは「データについてのデータ」のことであると同時にデータそのものでもあり（ " 例えば、ライブラリカタログは、出版物について記述しているのでメタデータである " (『 " Resource Description Framework(RDF) Model and Syntax Specification " の日本語参考訳 - 1. 序論』)し、著作物の説明、著作権情報、作成日、異なるバージョンや関連するページへのリンクなども著作物の情報について記述しているのでメタデータである） 、文書においては『あの文章で言いたいのは概ねこういうことである』や『この文章の大筋は正しいけど結論は間違っている』というような大まかな情報のみならず、『○○という単語は××という意味である』、『この文と次の文の'それ'の意味は違う』、『何々についての情報は'どれ'と'どれ'と'どれ'である』といったような細々とした情報さえも提供することができる。機械が文章を解析することの難しさ(検索エンジンや翻訳ソフトなどを思い浮かべてみよう)を考えれば、これがどれだけ強力なものであるか分かっていただけるだろう。……しかも、こういった情報を機械に対して提供することができるのである。

　(例えばHTMLであればmeta要素やaddress要素、datetime属性を使うなどして、)メタデータをデータのなかに明示的に記述する(埋め込む)ということをしない場合、メタデータによる情報の付加は外部のファイル・外部のサーバーに蓄えられる。メタデータを付与するのに、元あったファイルを書き換える必要はない。でも、そうして情報が付加されることによって、その姿は変わりうる。多くの人がここでBBSを連想するだろう。ある人の書いたものに対し、他の人や書いた人本人がコメントをつけあい、それらが集まって一つの全体像を作りだす――確かに、よく似ている。BBSのそういった仕組みは、元の文章を変えることなく、様々な意味や解釈などを付加してその性質を変えてしまうことができる。でも、それはメーリングリストだって同じだ。……いや、文章自体……言葉自体そんな性質を持っている。もっともこれは、話題(スレッド)を表現可能なBBS(やArchiveとして保存されているメーリングリスト)の方がより強力に全体像を表現できることを無視した意見であるが。それはさておき、こうしてみると、メタデータによる情報の付加とBBSとの類似は明らかなもののように思われる。だが、それは外見的なものに過ぎず、本質的なところで隔たりがある。所詮は「よく似ているけど、同時に似ていない」ものに過ぎない。引き合いに出すのはむしろWikiであるべきだろう、これは「似ていないけれど、同時によく似ているシステム」だ。

　少し注釈をつけておきたいだけなら、Wikiではコメントとして書く、メタデータも同様だ。情報を定義したいとき、Wikiではリンクを張るかページを作ってそこに関連付ける、メタデータでは直接他のものと関連付ける。Wikiで定義(のページ)に対する定義(のページ)があるように、メタデータに対するメタデータもある。Wikiで書くものが完全でなくてもいいように、メタデータも完全なものである必要はない。(Wikiと同様)他の人が別のデータを付け足してくれるし、あとで変更することだってできるからだ。信頼性を保証するには認証が必要であるため、メタデータ自体を誰もが自由に変更することができるというわけではないけど、その本質的な部分は同じだ。

　さて、「信頼性」という言葉が出てきた。これについて述べようと思う。メタデータにとって「知識の質」にかかわる「信頼性」は必要不可欠なものである。例えば、かつての強力な検索エンジン達はHTMLのタグmeta要素の中身を利用することで、精密な検査をおこなっていた。だがしかし、検索エンジンに引っかかるようにしたりランキングを上げたりするために、内容とは無関係な単語をメタデータとして埋め込むというテクニックが蔓延したために、検索結果に大量の「ゴミ」が紛れ込むことになった。また、メタデータの書き方がきちんと決まっていなかったために、好き勝手な形で書かれていて(信頼できる形で提供されていない)、その結果検索エンジンは適切な情報を利用することができず使いにくい。(本当はDublin Coreのような定型の書式が存在するが、成立時期がやや遅れたものであったし、その書き方を強制するものが何もなかったために残念ながらあまり使われていない。)

　信頼性(知識の質)を保証するためには、誰が書いたものであるか、いつ書かれたものであるか、改竄されていないか、というような情報がはっきりと保証される必要がある。こういったことをするためのXMLに対する電子署名の仕組みは、W3Cとインターネットの標準化団体「IETF(Internet Engineering Task Force)」によって標準化が進められている。また、データ内の要素として明示的に関連付けたり、埋め込んだりすることによって、元のデータの作成者がメタデータを保証することもできる。

　もう一つの信頼性を保証するための柱である定型化には、いくつかのフォーマットが定められている。その中の一つがW3Cがメタデータ記述するための基盤として用意しているRDF(Resource Description Framework)である。

　RDFではリソース(対象)、プロパティ(特性)、リテラル(リソースあるいは特性に付随する値)の3つを組み合わせて「ステートメント」と呼ばれる知識表現単位の集合(意味)を生み出す。このとき、コンテナによる集合や「ステートメントに対するステートメント」を定義することもできる。

　だが、RDFで用意されているのはあくまでデータ・モデル(データ同士を結びつけるための仕組み)であって、内容の記述し方そのものではない。そのためXMLの名前空間を使ってスキーマ、語彙などを持ち込み利用する必要がある。

　先に述べた通り、XMLでの表現内容の既定にはXML SchemaやRELAX NGを用いる。だがこれらはXML文書全体に対して制約を設けることを前提にデザインされているため、RDFの内容を定義するために用いるにはオーバーヘッドが気になるし、向いてもいない。そのため、RDFの内容を定義するための専用のスキーマ、RDF Schemaが用意されている。(もっとも、データタイプの指定にはXML Schemaを流用することもある。)

　だが、RDF Schemaの効用はRDFに適した形で意味的な制約を定義することにとどまらない。このとき、同時にプロパティに基づくリソース間の関係を、意味のモデルを構築することもできるのである。

　語彙は厳密には自分で定義することができるが、Dublin Coreやその拡張規格など既に存在するものを利用することが望ましい。

　他にもRDFの応用規格という位置付けではあるものの、(Webリソースのメタデータの集合をまとめ上げ、)サイト・インフォーメーションを示すためのフォーマットであるRSS(RDF Site Summary)、サイトの位置付け(または格付け)を表すPICS(Platform for Internet Content Selection)、サイトでの個人情報の取り扱いのポリシーを示すP3P(Platform for Privacy Preferences)などが用意されているので、そういったことについて公表する際には、これらを積極的に利用していくべきだろう。(これらはWebに託されたメッセージを端的に示している。RSSはサイトを見る前にそこにある情報を知る権利を与え、PICSはリソースに対しフィルタリングをおこなう権利を与え、P3Pはユーザーに情報をコントロールする権利を与える。つまり、(例えばユーザーにとって不都合なことや、法律あるいは社会的なルール違反がある場合に)サイトを運営する側を取り締まったり・強制させたりするのではなく、運営する側から利用する側への権利の委譲をおこなおう、というものである。)

　ここで「RDFを書くのは大変じゃないか？」という疑問があがるかもしれないが、その点については心配はいらない。すでに AnnoteaというブラウザでRDFによる注釈を記述させる研究プロジェクトがおこなわれているし、W3CによってRDFを視覚的に記述できるツール「IsaViz」が提供されているし、そのうえRSSに関しては自動的に生成するスクリプトも存在する。こういったツールの統合やブラウザでのメタデータの表現し方などに課題は残されるが、まずまずのスタートをきったと言えるだろう。(もっとも、RDFが最初に策定された時期(1999)を考えると遅いスタートである。これを「RDFの仕様が複雑であったため、なかなか普及しなかった」と見る人達もいるが、むしろこれは「RDFに対するサポートが不足していたため、単なるXMLではなくわざわざRDFを採用することへの動機が弱かった」と見た方が妥当だろう。(もっとも、RDFのなかでもいくつかの強力な機能は直観性に欠けていて利用しづらいものだった、という点は認めるが……))

　ここまで述べてきたことだけでも、さまざまな応用の可能性を考えることができる。例えば、BtoB(B2B : Business to Business)やBtoC(B2C : Business to Consumer)、CtoC(C2C : Consumer to Consumer)、あるいは輸送における求貨求送(求貨求車)などにおいて一番望ましいものを自動的に判断し、やりとりをおこなうようなシステムや、現在よりも的確で柔軟な検索エンジンといったようなものが実現可能であることは容易に想像できるだろう。 　だが、これではまだ不十分である。ここまでは単にあるものとあるものが論理的に結び付けられたに過ぎず、結び付けられたもの同士の等価性や違いといった「関連性」を表現していないため、意味を表すことはできているとは言いがたい。人間にとってはこれで十分かもしれないが、機械にとってはまだゆらぎがある。よって、望み通りの処理をきちんとおこなうことはできないだろう。

　それを解決するために、メタデータで記述された個々の知識を関連させる体系(集合)として「オントロジー」が使われる。 " 哲学の分野では、オントロジー(存在論)は「ある」ということの意味を問い、どのような形の事柄が存在するかを論理立てて考察する学問のことである。ただし、人工知能やウェブの研究者はこれを勝手に転用し、「用語間の関係を正式に定義している文書またはファイル」の意味で使っている。ウェブにおける典型的なオントロジーは、「分類体系」と「推論ルール集」だ。 " (『自分で推論する未来型ウェブ』 日経サイエンス 2001年8月号)

　こうしたオントロジーを記述するための言語の一つが、OWLである。(Web Ontology Languageの頭文字はWOLであるが、発音しやすさと智恵の象徴である梟をイメージさせる語呂のよさからこの名前となった。)OWLについてはまだまだ未定の部分が多いため、その前身であるDAML+OILについて説明する事にする。

　DAML+OILの開発は、DARPA(Defense Advanced Research Project Agency, アメリカ国防総省高等研究計画局)から資金提供を受けている、意味的な注釈づけをおこなうためのマークアップ言語DAML(DARPA Agent Markup Language)の開発プロジェクトと、オントロジーの表現とインターフェースを記述するための枠組であるOIL(Ontology Inference Layer)の策定プロジェクト、W3Cの三者の密接な協調・連携によっておこなわれてきた。

　OWLはRDFを基にいくつかの拡張を加えて作られている。例えば、これまで表現できなかった必須要素・排他知識(コンテナを使うことで択一であれば表現できた)や、 " あるクラスを、複数のクラスによって構成されるものとして定義したり、クラス間の同値性を記述したりするための機能 " (『XML World 特集 Semantic Web』 Java World 2002年5月号)などがある。(このために、「プロパティ中心型」のモデルから「クラス中心型」のモデルに拡張されていることに注目すべきだろう。)

　DAML+OILを生成するためのオーサリングツールとしては、OntoPrise社が無償バージョンも提供しているOntoEditがある。

　オントロジー以外にも、こうした関連づけをおこなうための試みは存在する。その中の一つ、目次のアプローチを使ってこれをおこなおうとするのが、XTMである。 　XTMでは用語間の関係の定義にさえ、オントロジーのような決められたルールではなく、参照を使用し、1つの大きな参照体系を作り上げる。「用語間の関係を用語が定義する」――いわば、辞書のアプローチをとるのである。

　既に察しの通り、オントロジーとXTMは排他的なものではない。むしろ、互いにできないこと補い合うものとして働く。(Semantic Webだけではなく、アプリケーションでの使用においても同様である。この場合、RDFには主にアプリケーションのデータ等が記述されることが多いのに対し、XTMではアプリケーションの構造そのものを記述することが多い。)両者が別々の方法でおこなった用語の定義、「論理」を、互いに結び付けあうことによって、より優れた「推論」のための基盤を手に入れることができるのである。

　オントロジーや辞書によって提供される推論のメカニズムにより、ゆらぎさえも克服されたかのように見える。……だが、ここで最後に残された問題がある。それは、互いに矛盾する情報が与えられた場合にそれをどう利用するかである。

　これを判断するための基準はいくつか考えられるだろう。例えば、「廃れるリンク(Dying Link)」で使われている「鮮度」や、メタデータの置いてあるサーバー、あるいは電子署名の発行機関(あるいは特定の団体や個人)を基にした「信頼性」などが優先すべき基準としてあげられるし、メタデータに対するメタデータも判断材料として利用できる。

　しかしながら、こうした基準さえも潜り抜けて矛盾が残りつづけるということはありうるだろうし、優先度が低いからといって無視していいというものではないだろう。結局、最終的には実装やユーザーの設定に頼らざるをえない部分もある。

　さて、こういった技術を導入することで何が実現されるのだろうか？　ここからはSemantic Webが目指すもの、果たす役割などについて具体的に説明していくことにしよう。 　Tim Berners-Leeはその著書や論文の中で、「エージェント(代理人ソフト)」と呼ばれるシステムが人の代わりに必要な情報を探し出し、必要な仕事をおこなう、という未来の姿を描いている。

　エージェントはいくつかの機能によって構成される。例えば、先に述べたようなことを直接おこなうのは「判断エンジン(reasoning engine)」であるが、(設定された信頼のレベルに基づき)その根拠となる情報の信頼性を完全に納得できるまで追及するのは「信頼エンジン(trust engine)」の役目である。

　またWebは広大であるから、こういった仕事はP2P(Peer-to-Peer)でつながった複数のエージェント同士が協働しておこなうことになるだろう。(ここでさらに、そういった他人のエージェントまたはエージェントのグループとの間での信頼性(アクセス権限であるとか、情報への信頼度であるとか)が使用されることになる。)

　こうした仕組みはWebそのものの外観を変えてしまうことを意味する。エージェントが必要な情報を探してくるのであれば、Webをブラウズする必要はない。また、(通常考えられるのとは違う方法で情報を見つけ出した時に、)エージェントが情報を探し出した方法や信頼性を確認した方法について説明を求める場合であっても、リンクやメタデータの関連性(モデル)を提示するというやり方がある(十分である)ため、(ユーザーが望まない限り)ブラウズさせる必然性はない。これはWebをブラウズするということがちょっとした(特殊な)スキルになる可能性を示唆する。かつて、WWWがインターネットの他の雑多な仕組みを覆い隠してしまったように、今度はWebそのものを隠してしまうのである。

　資料や文献を読むようなある程度ブラウズすることが必要不可欠なものであっても、そのままの形ではなく必要に応じて加工された形で、場合によってはエージェントによって作成された全く新しい文書として閲覧することになるだろう(現在の翻訳ソフトの状況を考えれば、こちらの実現には少々時間がかかることになりそうだが……)。

　その結果、かなりの部分で現在のWebのイメージ(利用形態)が通用しなくなるため、Webサイトの構成、出すべき情報、ビジネスモデルといったものは見直しをせまられることになるだろう。特に、来るべき「ユビキタス・コンピューティング(Ubiquitous Computing(ubicomp) : コンピューターがそれと分からない形で、ありとあらゆるところに存在する)」の時代においては、エージェントをあらゆる機器が持つことになるため、情報を発信する対象が人間ではなくなる、ということもありうるのだから。

4.2 P2P

　ここでP2Pについて説明する必要があるだろう。

　もともとは、P2Pは同等の資格を持つコンピューター同士が途中に他のコンピューターを介さずに相手のコンピューターと直接通信する形態のこと(この逆が間をサーバーが取り持つ、クライアント・サーバーモデルである。もっとも、現在ではNapsterのように多少サーバーが関わってくるような仕組みも、(ハイブリッドな)P2Pに位置づけられるようである。)を指していたが、音楽交換をおこなうソフトNapsterやファイル交換ソフトGnutellaの登場によって、そういった形で不特定多数とのコミュニケーションや情報のやり取りをおこなうシステムまたはテクノロジーへ、CPUのあまっている時間を利用して手伝ってもらうことによって、宇宙人探しをおこなおうとするSETI@HOMEや白血病の治療法を探すIntel Philanthropic Peer-to-Peer Project、(暗号の信頼性を確認することを目的としておこなわれる)暗号解読コンテストの鍵を探していくdistribute.netなどの登場により、そういった形での「分散コンピューティング(特に、これによって仮想的な高性能コンピューターを構築することをグリッドコンピューティングと呼ぶ。)」へとその範囲を広めた。(コミュニケーションと分散コンピューティングを組み合わせて、P2Pでのコミュニティやネットワークゲームを提供しようという試みもおこなわれている。これらの利点は、通常のシステムでは多くの負担を強いられる(そして、ユーザー数がある一定のラインを超えるとほとんど採算がとれなくなる危険性のある)設備投資を大きく抑えられることである。)

　現在ではP2P的なシステムを表す言葉となっており、そういった形での「コンテンツ配信」、「分散サーチエンジン」、「コラボレーショングループウェア」、さらにはビジネスモデルにもこれを当てはめる人もいる。

　P2Pによってもたらされた「ファイル交換」の仕組み(これに関してはHotlineなどの先行するものがあったわけだが、一般に認知されたという意味において……)や、P2Pを「分散コンピューティング」に利用するというアプローチ自体は画期的なものであった。だが、今のところ人々がそれに続いてとろうとする姿勢は、よく言えば常識的な、悪く言えば短絡的なものに過ぎない。

　例えば、ファイル交換に関する議論は型通りのものである。既得権益を揺るがすことは確かであるが、そこから「違法である」とか「合法である」とか「著作権法を変えなければいけない」とか、「プロテクトをすることは複製する権利を侵している」とか、「プロテクトをする側と破る側のいたちごっこである」とか……過激なものになると「著作権法はデジタルなものには通用しない概念である」というものも出てくるが、概ねいつも同じような議論が繰り返されるばかりだ。

　(議論・主張をおこなうグループや分野ごとの特色はある。また著作権でビジネスを行う者と著作者、利用者(従来の消費者というとらえ方ではない。)の間に考えの隔たりがあることや、この先、アメリカの暗号輸出規制に対する反対運動の時のように、既にいくつかの人々は言論の自由を以って立ち上がっていること、歴史を紐解いていけば分かる通り、提供側の利益を優先し利用者の利益を考えないものは結局は競争に負けてしまうことも指摘しておこう。なお、本気で著作権について議論する意思があるなら、最低限(類似を見出すことのできる)日本の流通業の歴史と結果の把握、Lawrence Lessingの 『コモンズ』あるいは それに対する白田秀彰の解説や火塚たつやの 『エンドユーザーの著作物使用から見える近代著作権法の問題点〜利用権中心主義 の提言〜』などを読む、ぐらいのことはしておいた方がいいだろう。)

　分散コンピューティングを利用したビジネスモデルの着眼点自体は悪くはない。多くの(複雑な)計算をしてくれるユーザーに対して対価を払おうというやり方が一般化し、さらにそれを発展させて「空き時間」の取引がビジネスとして成り立つ可能性は確かにあるだろう。でも、そうであるならば、これを著作権者に対する代金支払いの仕組みに役立てることができるのではないだろうか？

　デジタルによる複製の容易さを見て著作権の保護が脆弱になったと考える多くの人々は、むしろデジタルの世界に移ることによって、法律と技術のニ手段による制約とデジタルに対する過剰な制限の結果、著作権の保護が未だかつてないほど強力なものになってしまう危険性を孕んでいることに気づいていない。

　現行の著作権や著作を管理し収入を得る仕組みに限界があるのであれば、それらを取り去った全く新しいモデルを作り出してしまえばいい。これまで独立した存在と見なされていた「分散コンピューティング」と「ファイル交換」を結びつけることによって、こうした新たな道が開けるだろう。

　要するに、多くの計算を必要とするもの(組織でも個人でもよい)が依頼と、提供される(た)仕事の量に応じた料金の支払いをおこない、ユーザーは自由にファイル交換をおこなえる代わりに、ソフト起動時の裏処理としてマシンに計算をおこなわせるという義務を負い、著作権者は実際の交換量(ダウンロード量)に応じて代金を受け取るという仕組みである。(他にもそれが必要で価値のある仕事であれば、ユーザーに依頼するものは何でもいい。例えば、各家庭に(太陽電池や燃料電池などの)発電機が設置されているのなら、電力を供給してもらうということでもいいだろう。)

　これによって、多くの計算を必要とするものは比較的安い値段で効率よく結果を手にし、ユーザーは何の代価も支払うことなしに自由にファイルをやりとりする権利を保持し(こう見えること、つまりこの仕組みはユーザーの目からは見えないものであることが重要である。特にユーザーが望むのでない限り、マシンのスペックに応じた課題を任せるようにし、ソフトの操作にできるだけ違和感を抱かせないこと。また、スペックを尺度にしたファイルの交換可能範囲の差別もおこなわれてはならない。)、著作権者は自分の実績に応じた収入を得ることができるだろう。さらに、作品に対する評価という項目をこうしたシステムの中に含めることも考えられる。

　もちろん、(著作情報等を管理の負担をやわらげるために)こういったシステムの運用処理自体をこのモデルの中に委譲してしまってもいいし、著作料をもらわないという選択肢や交換せずに計算を手伝うだけということもありだ。(すべてをビジネスに当てはめる必要はない。人はビジネスのみで生きていくのではないのだから。　また、積極的に評価するならば、そういった行動は人類が著作物を共有するための基盤を支える、新しい形でのボランティアだといえるだろう。)

　著作権情報の管理には(現在著作権保護技術として)さまざまな情報が提案されているが、コラージュ等で二次利用したり、いくつかのものを組み合わせて詰め合わせや(LinuxやBSDのように)ディストリビューションをなど構築したりする場合のことを考えると、著作情報登録の項目に利用物やCRC、MD5などのファイルの同一性を照合できる情報(これはユーザーがファイルが無事交換できたかどうか確認する際の手がかりとなる)を含めておき、それらを利用することでこうした情報の嘘や申告漏れ、著作料の獲得を目的とした不正な転送なども管理していくようにするといいだろう。そうすれば、二次的・三次的なものかどうかということや、そうであるならばその元が何であったかなどの明示もきちんとおこなうことができるようになるため、その結果、原著作者の著作権や著作人格権に対しても保証をおこなうことができるのである。

　このシステムはソフトウェア業界も大きな影響を与えるだろう。一時の熱狂もおさまり、現在はオープンソースで儲けることは他で儲けるのと同じくらい難しいこと(きちんとしたマーケティングの視点が必要であるということ。もちろん、(Mozillaに見られるように)明らかに失敗だと思われていたプロジェクトが不死鳥の如く復活を遂げたり、企業がつぶれても残りつづけられるなど、オープンソースならではのメリットはある。)が認識されているが、(一部の特殊な業界向けのものを除いて)将来は逆にオープンソースでなければ儲けることができなくなるかもしれない。

　それはさておき、このようなP2Pのシステムに対してSemantic Webが大きな役割を果たすであろうことは容易に想像できる。実際、P2Pのシステムが扱う情報をメタデータ化しようという試みが既におこなわれているようだ。

　前に述べたようにSemantic WebもまたP2Pを必要とする。これから先、P2PとSemantic Webは不可分のものになっていくだろう。

4.3 ユビキタス

　次にユビキタスについて説明しよう。

　簡単に言うと、Semantic WebやP2Pが実装の話であるのに対し、ユビキタスは「ものにコンピューターを搭載して、相互にコミュニケーションをとり、様々な判断を下して生活を助けてくれる賢い道具にしよう」という環境の話である。

　ユビキタスは1988年に Xerox社のPARC(Palo Alto Research Center, パロアルト研究所)のMark Weiserによって提唱されたが、同じようなことは4年前の1984年に既に東京大学の坂村健によって「どこでもコンピュータ」というより進んだ形で提唱され、TRON(The Real-time Operating system Nucleus)プロジェクトとして具体的に進められていたし、さらにその発想自体はもっと昔から何人もの人が考えていたようである。

　この手の一歩先を見据えた研究にありがちなことではあるが、これらの概念は当初批判的に見られるというよりはむしろ、(議論する価値もないものとして)まともにとりあってはもらえなかったようである。だが、今ではこれらに到達するするためにいろいろと研究・開発、およびそれに関わる環境の整備がおこなわれているのは周知の通りである。

　なかでもTRONに対する評価は一定せず、多くの変遷を辿ってきた。今でも、BTRONの普及の挫折を以って失敗した過去のプロジェクトだとする人(BTRONはTRONのごく一部にしか過ぎないし、挫折の原因には企業間の思惑や陰謀劇が絡んでいたようであるのだが……)や携帯でのシェアを以って大成功だと見なす人、電脳都市・電脳住宅に思いを馳せる人、ユビキタスの担い手の一つとして冷静に眺める人、というように様々な見方が乱立する状態にあるようだ。(このあたりの事情は『ハッカージャパン21 VOL.8 プロジェクトX(バッテン) - 第2回 時代に翻弄されたトロンプロジェクト』に詳しい。また、/.jp(Slashdot Japan)の 『TRON、やっとお上に認められる』や 『国内電機大手がTRONをベースにデジタル家電OS を共同開発(かも)』、およびそこから辿ることのできる議論も興味深い。)

　ユビキタスの目標は、人の生活にさらなる豊かさを与えつつ環境の保全を図るために、身の回りにある全てのものがコンピューターを持ち(ゴミやチリさえも例外ではない)、(無線の)ネットワークによってつながったそれらが互いに協働し人の生活をサポートしていくことで(そういった仕組みを人に見せることなく働くこと、コンピューターの存在が空気のように透明なものであることが重要である。)、暮らしをよりよいものにしていくと同時にエネルギー・資源消費の効率化や再利用を計る、というものである。

　そこではまた、個々の使いやすい製品に機能が分散し、汎用的で使いにくいPCは姿を消すだろうと予測されている。(計算処理や個々の機器の援助、データの保存やバックアップなどをおこなうサーバーとして残る可能性はある。……だが、ゲーム機などのマルチメディア機器がその役割を担ったり、そういったサービスを提供する企業が現われる(もちろん、P2Pのところで述べたような『計算処理』と『著作物の共有』を結びつけたシステムでもよい)、というようなことも考えられるため、実際になってみないと分からない。)

　注目すべきは、機能が色々と付け加えられて使いにくくなってしまった今の機械とは別のアプローチであることと、中央集権的なシステムを否定していることであろう。 　ユビキタスへ向けての課題のうち、ネットワークやコンピューターの小型化・低価格化、機器間のインターフェースの統一(これについては疑問符がつくが……)といったものは、まだまだ完全とはいえないものの、解決しつつある。残された課題は、故障やセキュリティ、ヒューマンインターフェース(人と身の回りの「もの」との関わりあいに関するもの。分野に応じて、マン・マシン・インターフェース、ユーザビリティ、ユニバーサル・デザインなどと呼称される。)などに関するものである。

　故障への対策には、分散的なアプローチをとり、あるシステムが働かない場合には別のシステムに肩代わりさせること、データに対してはバックアップをとっておくことなどが提案されている。また、スイス連邦工科大学のDaniel Mangeらによって1993年に始められた電子胚芽(Embryonics)プロジェクトの一環として耐故障・自己修復コンピューターの研究が、イギリスヨーク大学のAndy Tyrrell率いる別の電子胚芽のチームによっていわゆる免疫システムの研究が進められている。(完全にとはいかないまでも、)故障のわずらわしさから解放されるのも時間の問題だろう。

　対して、セキュリティやヒューマンインターフェースに関する課題はいつまでも残り続ける。なぜなら、これらは一度解決してしまえばいいというものではないからだ。 　完璧なセキュリティはありえない。プロテクトである以上、守る側と破る側のいたちごっこが行われるのは世の常であるし、堅固さと利便性、どちらが欠けていてもうまくはいかないからだ。そこにはいつもトレードオフが存在する。

　また、技術の進歩や求められるものによっても変わってくるものなのである。このことは個々の情報の価値やその意味などについて考えてみれば、すぐにでも想像できるだろう。

　セキュリティというものが一筋縄ではいかないことを示す話はいくらでもある。ある重要なファイルをロックしたまま、その人が死んでしまったり……(文字通り秘密(password)を墓場まで持っていってしまったのである。これを回避するための階層セキュリティモデル(上位の権限を持つ人によってロックを解くことができるというやり方。一人ではなく複数人の合意によって解除できる方が望ましい。)を使うという手があるが、それは同時にロックを突破する方法も増えてしまうことを意味する。)、ネットワークによる侵入を警戒するあまり物理的にコピーして持ち運ぶことを選んだばかりに、落としたりコピーが氾濫したりして、情報が筒抜けになってしまったり、情報の整合性が取れなくなってしまったり……等。また、passwordや暗証番号を忘れたという苦い経験のある人も少なくないはずだ。

　ユビキタスの仕組みを利用することによって、こうした問題のかなりの部分を改善することができる。

　ユビキタスの持つ特徴である分散と協働をいかすことによって、passwordの廃止やキーの共有化によってセキュリティのわずらわしい面をできる限り見えなくして利便性をあげつつ、複数の方法による多重の認証をおこなうことによって強固さをあげることができるし、また、やろうとしていることに対して煩雑さや不便さを持ち込んだりして妨げることなく、「セキュリティを保証するために、そもそもやり取りできるデータを制限したり、断片化してしまう」というようなアプローチをとることのできる範囲を大幅に拡大することができる。(実際、そういう技術に対する研究もおこなわれている。)

　それでも、機械である以上、(適切な方法を使えば)だましたりごまかしたりするのは難しくないし、予期せぬ原因によってきちんと動作しないという事態もありえるだろう。さらに、セキュリティを越える権限をもったものが不正を働く可能性も否定できない。

　実はこういった問題に耐えうる究極のセキュリティというものがないことはない。それは、例えばありとあらゆる場所に監視カメラや盗聴器を設置したり、あるいは人々の体にタグ(ID)を取り付けて行動を追跡したりすることなどによって、人々の生活や行動の全てを監視下に置くという方法だ。特にユビキタスな環境下であれば、機器の協働によって、そういった監視の精度を限りなく高いものすることができるだろう。(それでも完璧ではない。)だが、それは同時にプライバシーが大きく侵害されることを意味する。プライバシーを犠牲にしてまで、人々は究極のセキュリティを手に入れたがるだろうか？

　(誤解のないように言っておくと、こうした技術自体には問題はない。適切に使用すれば、必要なときに必要なサービスが提供されるようになり、暮らしをより快適にすることもできるはずである。だが、こうした技術によって個人の情報の履歴(ログ)が蓄積されてしまい、個人についての全てを知ることやそうした情報を流すことが可能になってしまう……そこに問題があるのである。どうしても必要な場合・部分を除き、そういった情報の履歴が蓄積され続けるようであってはならない。そういった情報は必要なとき・部分だけ開示され、それ以外は適宜破棄されるような揮発性のものでなければならないし、必要なときには必要な部分だけが集合して初めて有用になるような(その用途以外に使用しようとしたり、もし何らかの手段で第三者が覗き見たとしても役に立たないような)断片化されたものでなければならないだろう。(もちろん、こうした技術は情報の保護と利便性の両者の立場からバランスをとったものである必要がある。)そのため、こうした技術を(安全な形で)導入するためには、アーキテクチャやソースコード、実際の働きなどの公開を、企業や政府、NGO、NPOなどに対する情報開示の義務のなかに盛り込む必要があるだろう。(適切なアーキテクチャーを使えば、設定等が公開されていてもセキュリティ上の問題の生じないものが作れるはずである。)もちろん、違反者に対しては厳重な処罰が下されなければならない。よって、将来的にはプライバシー保護の質によって所属する行政組織・機関を変えるというのが一般的に行われるようになる可能性もある。(現在の会社組織に様々な大きさのものが存在するように、そうした組織も様々な大きさを持つだろう。))

　このようにセキュリティにはさまざまな課題やトレードオフが存在する。優れた技術やアイデアが生まれたからといって、解決するものではないのである。

4.4 ユビキタスとユーザーインターフェース

　一方、ヒューマンインターフェースに関してはそこまでの困難さはない。ただし、対象となる「もの」自身や身の回りの環境などによってヒューマンインターフェースの意義は変わっていくものなので、この課題に対し唯一絶対の解答が与えられることはない。(注意を喚起するために、わざと意識的に使わなければならないものにすることもある。)それゆえ、この課題はいつまでも残り続けるのである。

　しかしながら、現在の身の回りのものに対する使いにくさの大半は、そういった理由によるものではない。何年も前から改善案が示されているにもかかわらず一向に変化が見られなかったり、あるいは改善されていてもその速度はじれったいほど緩やかなものであることが多い。それどころか、PCのソフトウェアやカメラ、(特に日本の)ビデオ・デッキのようにかえって悪化しているケースも見られる。(よって、よく宣伝文句として使われる「使いやすくなった」というフレーズは眉唾であることが多い。)

　いくつかの本では、こうしたことが起きる原因は組織や製品開発工程にあるとし、使いやすさをおざなりにしない組織のあり方や、インターフェースのデザイナーおよび認知心理学の専門家などが関わっていけるような製品開発のあり方に対する提言が述べられている。

　それらはなるほどと思わず頷かされるものが多く、少なくとも参考にする価値はある。……しかしながら、それだけでは到底十分だとは言えない。提案者達の多くはあることを見逃している。

　それは人々が使いやすさに対する意識や知識を持たなければならないということである。確かに専門家達の意見を仰ぐことは大切だが、人々が基礎的な知識や考え方を身につけてさえいれば、ある程度まではそういった問題を解決することができる。

　ユーザーが知識や考え方を身につけていればユーザーからより的確な要望を得ることができるだろうし(そこまでいかなくても全くの的外れではない、ましなものが得られるだろう)、技術者達が知識や考え方を身につけていれば最初から使い勝手を考慮した製品案を得ることができるだろう。(行政や非営利組織から出てくる提案も然り。)

　アフォーダンスについて知っている人がどのくらいいるだろうか？　(その「もの」の使い方を喚起するような性質。物理的あるいは視覚的な形や、振る舞いなどによって表される。誤解されることが多いが、これは学習によって理解されるものであって、直感性とは必ずしも一致するものではない。(直感とは日々の学習によって身につくものである。)よって、初心者に対する使いやすさよりも、それなりに使用するが熟練するには至らないユーザーを対象に定める方が望ましい。)

　何らかのミスによる事故が起きたとき、ヒューマン・エラーが起きるのではなく、「それが起きるように環境やシステムなどをデザインしたことが悪い」のだと理解している人はどのくらいいるだろうか？　(コンピューターを使っていてミスを犯したとき、自分や他人の失敗を責めるのではなく、そうさせるシステムの欠陥を認められる人がどのくらいいるだろうか？)

　こういった知識や考え方の欠如が使いにくさ(ミスも含む)を助長しているのである。特に仕事に必要なものであれば、使いにくさや分からなさよりも習熟していないものを責めることが多く、その結果変な先入観がもたれ、欠陥がそのまま残り続けるようなことも少なくない。

　GUI(Graphical User Interface)がCUI(Character User Interface)よりも使いやすいものであることは周知の通りであるが、ではなぜCUIにしがみついたり、ソフトウェアをGUIにしなくても構わないと思う人々がいるのだろうか？

　……もちろん、それまで身につけて来たものを無駄にしたくないという意識(上達することをよしとする意識)やCUIの方が作りやすいという理由もある。だが、それだけではない。

　CUI(UNIX)の世界では作り手=ユーザーであるため使い勝手の良さが常に探求されてきており、さらにGNU(GNU is Not UNIX)やMITによるフリーのUNIX開発が存在していたがためにオープンソース的な気風が失われず、その結果、一人の独善的な開発に陥ることなく、さまざまな人にとって使い勝手のいいソフトウェアを作ることができた。また、ないものは作るという哲学があったため、既存のものに対し不満がある場合には自分(達)にとってより望ましいものを作ることができた。システム管理を行ったことのあるものであれば、この例として、WindowsのショートカットはUNIXのエイリアス(別名)ほど便利ではないことや、GUIでのシステム管理はCUIに比べて不便なこと、年々密かに改良されているとはいえDOSプロンプトはUNIXのターミナルに比べて貧弱であることなどを挙げることができるだろう。(Cygwinを使ってWindows上に擬似的なUnix環境を構築すれば、このような欠点を多少は改善することができる。)

　そうして確立していった作法が親しまれ、よく理解されているがゆえに、彼らは彼らにとって望ましい(無理にGUI化しなくても構わないと思える)ソフトウェアを作ることができるのである。その証拠にGUIに関してはまだまだ未熟であり、Windowsにすら劣るところも少なくないし、Windowsを超えたと公言しているKDEプロジェクトの作っているものは(AppleやBeOS、またそれらGUIの原点などではなく、)Microsoftの真似をしたものばかりであったりする。さらに言えばGUIはそうした協力関係ではなく企業による独善が大幅に先行してしまったため、複数のソフトの連携というCUIの世界ではごく自然におこなえることにも大きな労力を必要とすることになってしまっている。だが一応、GUIになっても彼らの文化の持っているいくつかの大きなメリットを吸収したものも作られてはいるのだ。Ex. GIMP,Mozilla

　続いてMacintochの例も述べておこう。Macintochでは使いやすさを強調し独特の文化を築きあげてきたために、使いやすさに対する意識や知識がユーザー・開発者達の間で共有されており、その結果(他と比べて)使いやすいソフトウェアが提供されやすいし、Appleは(他と比べて)信頼のできる意見(フィードバック)を受け取ることができる。

　このように、人々が使いやすさに対する意識や知識を持つことによるメリットは無視できるものではない。また多くの人々がこのような知識を身につけることで、多くの人々から出された指摘が一人の優秀な人物の意見を上まわるという「デルファイ効果」をより確実なものにできる。よって、まだユーザー経験(User Experience)が求められるほど市場が成熟していない段階であっても、使いやすい製品を提供しユーザーを啓蒙していくことが長期的に見てよい戦略となるだろう。(もちろん、「長期的」にであるためより多くの労力を注ぎ込むことで「短期的」な効果をあげることを期待してはいけない。また、この結果現れることになるであろう、口うるさい、いわゆる「注文の多いユーザー」を歓迎する空気を培う必要もある。せっかく指摘しても拒絶されてしまうようであれば、誰が意見を言ってくれるだろうか？　ユーザーからの意見・要求はありがたいものとしてうけとらなければならない。これは(アメリカの悪いところが入ってきているわりに、口うるさい顧客を装いサービス等に対する評価を下す覆面顧客がない(定着していない)ためか、)些細なことですぐにクレーマー扱いしがちな現在の日本の状況と対照的である。)

　しかしながらそのために顧客のニーズを無視していいというわけではない。例えば今QWERTY方式でない配列のキーボードのような互換性のないもの作っても受け入れられない。(ドボラックやヒューマンインターフェース・キーボードも一応使われているようではあるが……市場全体からみるとささやかなものである。)

　その一方で、逆に主要な顧客からは否定されるにもかかわらず、後に圧倒的なシェアを占めることになる破壊的技術というものも存在する。破壊的技術の恐ろしいところはそれに対する現在の状況から「どういうものが望まれているか」を考えても決して成功することはなく、「それが提供されること自体」と(実際に使うものから見た)「安さ」がニッチな市場の要求に応え、そのことが後の成功要因となるところにある。つまり、この場合には想定する顧客のニーズを満たすために下手に作り込むことよりも、迅速に提供し、市場を作り上げていくことの方が重要なのである。

　こうしたジレンマを解決する最良の方法は最初から完璧なものを作り上げようという考えを捨て、まずものを導入し、使っていくなかで漸進的な改良を計りなじませていくというやり方をとることである。従来の製造業的な「作って売る」という文脈のなかではこのやり方の実現は難しいものであったが、現在移行しつつある製品そのものではなくサービスを提供しその「メンテナンスをおこなう」という文脈のなかではこれほど自然なやり方もない。

　特にアップデートという形でこれを容易におこなうことのできるコンピューターのソフトウェア、およびそれらが組み込まれる製品の場合にはこのやり方を重視した方がよいだろう。そう、このカテゴリーにはユビキタス時代の「もの」全てが含まれることになる。こういう形を取ることで、「ここで失敗した」、「これはうまくいった」、「これはちょっと大変」というフィードバックをもとに、少しずつ今使用者のそばにある「もの」を便利にしていくことだってできる。先に述べたP2Pによる出資者、利用者(消費者)、著作者の三者による料金支払いモデルが確立していれば、このようなアップデートの仕組みを完全に利用者の目の前から隠して、知らず知らずのうちに「もの」が便利になっていくように見せかけることも可能である。(もちろん、「もの」にとってのソフトウェアはできるだけ目に見えないものであることが重要であり、おしつけがましくわずらわしいものであってはいけない。これについては 『ユーザーインターフェースデザイン』、 『コンピュータは、むずかしすぎて使えない！』、 『ヒューメイン・インターフェース』等で示されている、現在のソフトウェアに対する批評や改善案が参考になるだろう。)

　ただし、利用者と関わる必要がなくなるからといって、利用者とのコミュニケーションを排除してしまっていいということではない。そうしてしまった場合、手痛い失敗を被ることになるだろう。また、見逃されがちなことであるが、個人へのカスタマイズを重視し過ぎると、他の人のやっていることと同じことをしようとするときにその人と経験を共有できなくなる、といった問題が存在することも忘れてはならない。

　ちょうどいいことに、ソフトウェア業界ではさまざまな限界や問題点(完璧にできあがったシステムが使い物にならないことすらある)から、今までの、決められた技能を持つ人が上からの決められた方針・計画などに従い、ただ決められた仕事をこなすというような工学的なアプローチが否定されて、オープンソースやXPなどのような漸進的(インクリメンタル)に適応し進化させていく開発方法を使い、その中で開発者はさまざまなことを柔軟・積極的におこなって自らの技能を磨き上げていく方法論へと移行しようとする流れがある。また、製造業においてもこれまでの大量生産にあわせたシステムが多品種少量生産の実情にあわず、在庫過剰・新製品への移行困難などのかえってコストがかさむ原因になっていることから、与えられた単純な仕事をただ早くこなすだけの単能工を止め、様々な仕事を一通りこなす技術を持つ熟練の多能工に変えるという流れがある。この機会に製品の販売中心からサービスの提供中心へと、ビジネスのやり方を移行させるべきではないだろうか？

　しかしながらそれは、これまでのサービスのやり方における常識の範囲に囚われたものであってはならないし、これまでのものを捨ててサービス業のやり方に盲従するものであってもならない。そのようなやり方では、文化論の置かれている現在の状況――未だ旧世代を引きずっていたり、旧世代に目を向けることなく現在を語ったり、ゲームのシナリオやWebの文化などを得意分野としながらも「ハイパーテキスト論に語られるポストモダンとコンピューターの幸福な結婚」などのあればおいしい……もしかしたら核となりうるかもしれないであろう概念の把握を疎かにしている者の論、といったものが横行し、未だ適切な言葉できちんと語られていない――のように、ある部分では正しくあるがそれ以外の部分では的外れか薄っぺらいものばかり、という考え方に陥ってしまう可能性がある。考察だけが目的ならまだしも、企業活動をおこなっていくなかではそれは致命的なことである。よってそれを避けるためにも、今のうちから両方のことをきちんとよく知っておく必要がある。また、全く無関係だと思われる分野にも関心を持つことが、新たなサービスやインターフェース、展望などを得るためのきっかけを生むことも忘れてはならない。

　さて、「これまでのやり方やサービス業のやり方にとらわれるな」と言っても、多くの人々は「では具体的にどうすればよいのか」検討もつかないだろう。よって、最後にここにいくつか指針を記しておくことにする。

　サービス中心のやり方に移行した企業にとって最良の状態とはサービスを受け持っていながら実際のサービスはほとんどおこなわなくていいというものである。(おこなわないというものではない。そうなると、間違いなく切り捨てられることになるだろう。)サービスを売るというと、相手に対して多くのサービスを提供する変わりに高い料金を支払ってもらうというモデルを考えがちであるが、ソフトウェア産業における近年の破壊的技術――オープンソースが今や高品位の市場に乗り出しつつあるということを考えると、それは得策ではないだろう。より高品位を求める市場にのみ焦点を絞るという方法を取ることも可能であるが、それは他の分野の例に漏れず最初は成功をおさめ大幅な収益増を見込めるかもかもしれないが、後にその市場にも乗り出してきた破壊的技術によってその市場すらも奪われ駆逐される運命になるというのが関の山である。(破壊的技術について詳しくは 『イノベーションのジレンマ　増補改訂版』を参照せよ。)よって、オープンソースの見込みの薄いごく一部の特殊分野を除き、オープンソースを利用して品質を高めることによって年々コストダウンを計っていくのが現実解であると言えよう。

　とはいえ、オープンソースによるソフトウェアの高品位化の行くつく先が、導入・保守といったサービスの死――いわゆる情報エントロピー的な状況に辿り付くのではないかと懸念する声もあるだろう。(情報エントロピーについては 『情報エントロピー（謎）について思考実験。』の考察も興味深い。)だが、ここで先の「ユビキタス社会では個々の使いやすい製品に機能が分散し、汎用的で使いにくいPCは姿を消すだろうと予測されている」という話を思い出す必要がある。そのような環境下では(この名前を使うことが妥当であるかどうかは別として)PCを扱うことは特殊なスキルとなることが容易に予測できるし、また、ソフトウェアを提供する先に限りがないことも思い出すことができる。要するに、サービスの終焉は現在のPC社会を前提にした仮定なのである。ユビキタスを指向する以上、それは正しくない。

　その上、そうした仮定は真に汎用的なシステムが成立しうるとことへの信頼をもとにたてられたものである。残念ながらそれは正しくない。周りにに目を向ければ、ソフトウェアであれそれ以外のものであれ、同じようなものがいくつも存在しながら、それぞれが違った特徴を持ち、それゆえに使い分けられていることに気づくだろう。そしてそれらの違いの持つ利点と欠点は、多くの場合、排他的なものであることに。なかには新たな別の方法が見つかってそういった問題が解決することもあるが、そのような例はまれであるし、トレードオフをよく考えてうまく組み合わせればよいとしても、その場合ケースによって組み合わせ方が異なることが多い。また、そういったことに目を向けずに下手に汎用的に適用しようとしてもうまくいかず、うまくいったかのように見えても大きな歪みを生み出していて、その結果流行の終わりとともに否定されることになるというのは歴史の示す通りである。

　だが、だからといって安心して良いというわけではない。真に汎用的なシステムは存在しないが、ものは何度か完成を迎えるだろう。それはニーズが一通り満たされてしまったからかもしれないし、次の段階への技術的障害を向かえたからかもしれない。その場合に向けて採れる当然の策が二つある。一つは人々の持つ潜在的なニーズを発掘するというものである。サービスの提供を中心にしたことで、そういったニーズの検証を積極的にできることが一つの武器となるだろう。また、それに対する需要が主流ではなくとも確実にニーズのある分野であった場合、オープンソースで開発できることも強みになる。もう一つは、一つの分野に安住することなく別の分野にも手を伸ばしておくというものである。企業行動としてこれは当然のことだ。どんなに順調であっても、どの分野のニーズがどのくらい満たされているかを常に把握し、適切に仕事を振り分けていくことが重要であることを忘れてはならない。

4.5 まとめ

　Semantic Web、ユビキタスなどを提唱する人々の描く図は壮大であるが、その技術自体の一つ一つは今の技術の延長線上あり、むしろこの足元の技術をどう発展・活用させていくかが鍵となる。

　メタデータの活用やものの出し入れの記録を(画像つきで)保持してくれる家具、人のいる場所を検知しての機器の稼動によるエネルギー消費の最適化、商品のタグづけによるレジの排除などは魅力的で比較的なじみやすい進歩のように思われるかもしれないが、その技術の導入の仕方によってはさまざまな問題が発生する可能性がある。だから、技術を中心に一気に先を目指すのではなく、ユーザビリティ、ユニバーサル・デザイン(特定のことを満たさないものに対して排他的・阻害的ではなく、他に対して開けたものであること。障害者配慮を意識して使われることが多いが、ユビキタスに対応したものと対応していないものをどう両立させていくかという視点も重要である。)、セキュリティ、プライバシー、それぞれの間でどうバランスをとりながらどう発達させていくか、ということが重要だということをよく肝に命ずる必要がある。

　次の段階が着たからといってそれまでの問題が解決するわけではない。そこまでの過程で問題をほったらかしにすれば、使いにくくスキルを必要とするという常識が一般に受け入れられてしまっている現在のPCのように、問題を抱えたまま進歩し続けることになる。そうした事態は防がなければならない。

　Semantic webやエージェント技術、ユビキタスなどに対しては既に様々な論文や本が発表されているが、そこで語られているものはあまりにも理想主義的で、こうした問題に対して楽観的過ぎる。よって、技術をよりよい形で普及させるためには、現実主義的な立場から真剣に議論・検証し、一歩一歩着実に取り組んでいかなければならないだろう。

5.1 インターネット広告批判

　かといって、インターネットを利用した広告活動をおこなうのも非常に難しい。

　バナー広告は散々乱用された結果、ユーザーは(特に定位置の)バナーやそれに似たものを(意図的にも無意識的にも)無視するようになってしまった。バナー広告は対象サイトのテーマに合うようなものでないと興味を惹くようなことはまずないと言ってもいいし、テーマに合うようなものであってもこれで広告主のWebサイトに招くのは難しい。ユーザーはそれよりもYahooなどの信頼のおけるサイトのコンテンツからのリンクを好むのだ。(実際、検索サイトのキーワードの一位はYahooであり、他にも情報そのものよりも企業などのページを探すために検索エンジンがよく利用されるという報告がある。これはGoogleが大きな力をもった現在でも、まだ検索エンジンで望みの情報にいける可能性や見つかった記事への信頼性が低いためと言われる。この点を改善するため現在いろいろな試みがおこなわれているが、なかでも検索エンジンを運営する側が記事を評価して適切なコメントの付与とランクの操作をおこなうというというアプローチはSemantic Webにおけるメタデータの活用を思い起こさせるものとして興味深い。)

　バナーとソフトを組み合わせるようなアプローチもやはりうまくいかない。未購入時のOperaや無料インターネット接続サービス、あるいは広告を見てもらう換わりにお金を支払おうといった形のビジネスモデルなどでは画面の一部を借りて広告を表示するという方法をとっているが、固定位置に存在するため実際のブラウズ時にはそのような広告の存在は忘れ去られてしまう。だからといって広告の位置を動かしたり、クリックを強制させるようなサービス(こちらは実際にあった)は嫌われて使用されなくなってしまう。この方法論の限界から、最近では有料コンテンツを無料でみせてあげる代わりに広告を見てもらうという手法が出てきているようだが、その場合コンテンツがそういった負荷を伴うに値するかどうかが勝負となる。今のところ好意的に迎えられているようであるが、現在検討がおこなわれている有料サイトのでのマイクロペイメント(小額決済)という手法は、支払いの姿をユーザーからできるかぎり意識しなくてよいものにすることを意図している。そのようなサービスと比較した場合、果たしてこれは有効な方法となるだろうか？　また、ユーザーから見える形をとることでマイクロペイメントの場合は回避できたであろう、非商業コンテンツとの争いが課題となることも忘れてはいけない。

　ユーザーの注意の喚起を意図して使われるポップアップ広告は、(ユーザーから主導権を奪い、操作を邪魔することから)嫌われ者の主役である。そうしたユーザーの意思を反映した戦いは、ユーザーによるブラウザのjavascript等の機能の停止などから始まり、ポップアップを切るための専用ソフト、Internet Explorerを拡張したタブブラウザでの拒否機能、MozillaやOperaでのブラウザ自身のポップアップ抑止機能と続き、ついにはAOLやMSNのようにプロバイダーがポップアップ広告の全廃を公表するというところにまできている。(Internet Explorer自体はようやく次のバージョン7でポップアップ抑止機能をサポートするようだ。)よって、この手の方法は使えないどころか企業のイメージを悪化させるものだと考えた方がいい。また、広告以外の手段であってもポップアップは同様に嫌われるので、自重する必要がある。(最近ではさらにPCそのもののWindowを表示させるというアプローチもあるが……これも上述したのと同じ理由で止めた方がいいだろう。)

　ブロードバンドを頼みの綱とした動画やFlashなどの押し付けもまた嫌われる。現在、サイトに誘う、サイトを利用価値のあるものまたは見せ物にする、キャンペーンをおこなうなどの従来のものよりも強力な広告手段としてストリーミングによる動画の配信は注目されている。そうした人々が、SMILやSVG、Webサービスなどと連携することによって得ることにできるインタラクティブな能力が従来の広告の限界をこえるという強い希望を抱いているであろうこと、そしてこれから先ユビキタス時代の確立に伴いそうした広告をPCのみならずTVや新聞・雑誌などへと広げていこうとしていることは、想像に難くない。こうした人々はこれらがうまくいかなかったのは昔は回線速度が不足していたためだと考え、動画やFlashを多用したページを復活させつつある。しかしながら、そうした期待は映像やインタラクティブであることに対しての過信に基づいたものである。かつてバナー広告がそうであったようにいくら新規性を持ち込んだところでそれが蔓延してしまえば飽きられてしまうし、それに対抗してポップアップ広告のように見せることを強制しに向かえばやはり同じように嫌われてしまう結果へと向かう。それに、動的なものが多くなればそういったものを無意識的に排除して、逆に静的なものに目を向けるようになるだろう。また、十分な回線速度があってもやはりユーザーはそういったサイトに拒絶の意思を示す傾向がある。よって、これらはあくまでサイトの部品―視聴可能なものか、ユーザーインターフェースをサポートするものとして提供しなければならない。

　CMのようないわゆる広告らしい広告では映像が判別の手段となる。それに対して音声のみであれば広告を飛ばしにくいという点に注目し、ネットラジオ等音声のみによる広告を積極的に進めようとする動きがあるかもしれない。しかしながら、インターフェースの改善によって将来的には音声のみでも不規則的流れる広告さえも飛ばすことができるようになるため(テープですら後で注釈をつけて任意の部分を聞くことのできるものが開発されている)、そういった特性に寄りかかっていくことはあまり懸命だとはいえないだろう。(ついでに言っておくが、Webサイト等で音声を強制的に再生しようとすれば映像のときと同様の反発を受けることになる。) 　このようなWebでの広告の難しさを見て、「じゃあ電子メールを使えばいい」と単純に思うかもしれない。しかしながら、電子メールにもやはり電子メールなりの難しさがある。

　電子メールの場合、顧客の興味にあわなければならないのみならず、そもそも送信者で判断される。つまり、どんなに顧客の興味を引こうと工夫をこらしても一見すらされない可能性もあるし、頻繁にメールを送りすぎることで嫌われる可能性もあるのだ。

　よって電子メールによる広告活動は、顧客の許可した場合に顧客の興味ある広告を、忘れられないほどには頻繁であるがうっとうしいと思われるほどではないつかず離れずの距離で……という恋やデートなどと比喩されるような細心の注意を払って行わなければならない。

　また、 賞味期限切れのEメールと呼ばれる問題も存在する。いくら顧客から許可を得たとはいえ、それは永久的なものではない。そのときはたまたま興味が持ってメールの配信を許可するが、後になって興味を失い、許可され配信しているはずの広告がSPAMと同じ扱いを受けるようになることも決して珍しくない。そうした場合、許可を得たはずのメールを配信する度に知らず知らずのうちに自分の信用を失わせているのだ。これに対する対策はレスポンスの悪いユーザーを管理していくことである。この方法として、定期的に顧客に配信許可の更新を求めるのも一つの手である。この時配信を止めたいユーザーに手続きをやらせるのはよくない方法である。そういうユーザーは止めるための手続きをすることすら億劫であるため、何の解決策にもならない可能性が高い。それよりも配信の更新手続きの方をおこなわせるべきだ。本当に興味を持つユーザーであれば、少々面倒でも更新の手続きをおこなってもらえるはずであるし、メールがどう受け取られているかに対するより正確な評価を受け取ることができるし、また、それにより自然と顧客のふるいわけがおこなわれることも期待できるからだ。

　このような個人を相手にする面倒を避けるため無料メーリングリストのサービスを提供して、そこに広告をのせることで新聞広告的な効果をアプローチを取ることもできるが、残念ながらそれもうまくいかないようである。メーリングリストの話題が加入者にとって興味深いものである場合、加入者はそのメールを隅から隅まで読みそのときに見られる、という効果を期待しての試みであるが、Web広告と同様無意識的に読むのを避ける傾向がある。実際、1000人以上の人が加入していて、興味深い記事を書いていたにもかかわらず、広告に見せかけて仕込まれた遊びに誰にも気づかれなかったという結果がでている。このような効果の低さにいらだってか最近では記事の後ではなく前に広告を挿入するという方法も見かけられるが、広告なしのメーリングリストが提供されている上、ブロードバンドの普及にともないいざとなれば自分でサービスを提供できる環境にある以上、そのような手法はユーザー離れを招くばかりであり望ましくない。さらに、前に広告を挿入しても、それでも無意識に読み飛ばされる傾向にあることを指摘しておこう。

　以上のように電子メールによる広告にも様々な問題が存在する。……いやむしろ、電子メールによる広告の方が他の広告よりも難しいと結論づけることもできるくらいである。(なお、電子メールによる広告の難しさを表現の貧弱さにあると見る者もいるが、それはどんなに表現を豊かにしようとそこに顧客の望みをすぐにかなえるものがなければ役に立たないというWebでの現実を対岸のことであるかのように思い込んだ見方である。遅かれ早かれ、そうした見方をするものは後悔することになるだろう。)

　このようななか、効果的な広告活動をおこなうにはどうしたらよいだろうか？　できればユーザーにとって本当に必要なものだけにより分けられるSemantic Webでも、排他されないようなやり方が望ましい。

5.2 コンテンツとの連携

　その答えの一つがコンテンツとの連携である。新聞や雑誌の例を出すまでもなく、広告活動にコンテンツを利用するというやり方はごく当然のようにおこなわれているものの、案外コンテンツと連携して広告活動をおこなうというやり方はあまり浸透していない。それはコンテンツビジネスにおいて、勝手にコピーされること、配布の主導権を奪われることが脅威になるという点によく現れている。コンテンツに十分に広告としての役割が浸透している状態ならば、むしろ自由に配布されることで宣伝効果を期待してもいいはずである。現在、アニメに関してはストリーミング(ようするにダウンロード形式ではない)による無料配信がおこなわれてきているが、それは後にDVDとして販売したり周辺商品を販売したりといったコンテンツビジネス(キャラクタービジネス)そのものに利用されているだけであり、そのため配布状態のコントロールといったものがやはり重要視される。誰でも勝手に(DVDに負けないような)高品質のもの(あるいはDVDの中身そのもの)を再配布していいわけではないのだ。

　市場規模を考えるに、こうしたコンテンツにコンテンツビジネスのみならず他の分野の広告塔も担ってもらおうという発想は、十分に理に適ったものであると言えるだろう。よって、これからはスポーツ番組や映画、ドラマなどのように、アニメやマンガ、ゲーム、さらには小説といった分野にもスポンサーとしてお金を出し、劇中でさりげなく商品(あるいは広告)を出してもらうというやり方を取っていくことが考えられる。(もちろん、そういう事がないわけではない。しかしながら、それは特定のビッグネームあるいは長寿番組として結びついているか、タイアップ作品であることをアピールしているような一部の作品に留まるのみであり、そうした作品は他の作品と比べて特殊な位置にある。あるいは商品が出された後にお礼としてその商品を送るといった行動も見られるが、あくまでこれは事後的な慣習である。一般的な方法論ではないのだ。)

　また、これまでそうしたやり方をとってきたスポーツ番組や映画、ドラマ等にも再配布時の効果を加味した広告料を支払うようにすることで、再配布を受け入れてさせていくことができるだろう。さらに、お互いがコンテンツビジネスや広告といった範囲にとらわれずに柔軟に提携していけば、新たな可能性を生みだすこともできる。例えば、マンガやゲームのキャラクターのために作家と協力して衣装をデザインし、その衣服を売り出すといったアイデアも、それらのコンテンツがある程度の力を持ち、コスプレ用のコスチュームを売るというビジネスすら存在する現在では(まだまだ意識的なギャップがあるし、そのような市場規模は小さいとはいえ)もはや絵空事ではないだろう。

　(このようにコンテンツに乗っかっていくことを指向した場合、コンテンツの受けやカバーされる範囲がより問題となる。このことへの対策としては、コンテンツビジネスのブランドに乗っかっていったり、後述するようにいくつかのまとまりに対して広告をおこなうようにしたり、評価や品質管理の仕組みを設けて対象作品のレベルの底上げを図ったり、コンテンツの層に偏りのある場合には少ない部分を補填するためにそうしたものの創作を支援していく、などが挙げられるだろう。また、コンテンツの価値を減じないためにもいろいろとバランスをとる必要があるため、もしかすると時には広告を載せないことに広告費を払うことが必要になるかもしれない。)

　このような広告手段としての可能性を考えた場合、(アメリカ企業のように)コンテンツビジネス同士が互いを著作権や商標等で牽制しあうよりも、(作者同士で了解のある場合や、同人活動、Web等におけるコンピューターソフトや音楽以外の分野での日本の黙認の状況、あるいはそれ以上に)お互いの中でお互いを取り上げていくことに対して寛容に肯定的に接していくことの方がより賢いものだと言える。それどころか、新聞や雑誌などと同じようにコンテンツがコンテンツに取り上げてもらうために広告費を払うということが一般化したとしても全然不思議ではない。実際、周りを見てみれば作品中で取り上げられた別の作品や作品のネタとなっていたものへの興味に対する便乗商売もおこなわれているのだ。そうしたものを利用することこそ、正しいビジネスのありかたであるべきだろう。

　ただし、 水夏を元にした教育ゲームが批判されたようにこうした急進的なやり方は何らかの難癖をつけられて批判を浴びせられる可能性が高いし、過去の作品であったり、イメージに合わないや作家性から行いたくないなどとの理由で人気作であるにも関わらず広告の入り込む余地のないこともある。前者に対してはうまく手綱を取りながら試していくしかないが、後者に対しては一作品ベースや一商品・一企業単位でのやりとりではなく、ある程度まとまりの中でやり取りをおこなうことで解決することもできる。ある広告を受けつけない人気作品があれば、その作品のファンが同時に見ている作品に対して広告を配置することによって補填を図ってもよいし、別のメディアに移された時に広告を織り込んでいくというやり方でもよいはずだ。究極的には先に述べたP2Pを使った著作料支払いのモデルの中に取り込んでしまうことで、こうした柔軟性を最大限に高めることができるだろう。

5.3 Webになじむ広告

　続いて、広告自体を見せるものにするという方向での可能性を見ていこう。 　実は、そもそもWebというフィールド上で広告とそれ以外を区別してしまうことが、Web上での広告の難しさを生む原因である。インターネット―特にそれぞれのプロトコルの境界をあいまいなものにしたWebの普及に伴い、いわゆる広告活動にあたるものを当該企業以外のものがおこなうという側面が強まってきた。実際、Web上では広告とそれ以外の間に本質的な違いはない。またたくまに情報が広がりうるこの世界では、あらゆる企業活動が広告としての責務、マーケティングとしての責務をも担うようになった。あえてこれらに違いがあるとすれば、今までの広告は起爆剤、促進剤としての効果を意識的狙ったものであるということだ。

　口コミや同人誌による普及活動や排斥活動といった行動は古くから見られていたが、Webというフィールドを得ることでその力をより強くした。波及力や影響力がより大きくなったのだ。と同時に、人気サイトが存在することから想像できるようにある程度はコントロールできる、という点も見出すことができるだろう。これらをうまく利用できれば、効果的な広告活動をおこなうことができる。……でも、人々はそれを知ることができるし、そこにある意図も同じく評価されることになる。下手をすると諸刃の剣ともなりうることに注意しておかなければならない。

　よって、そうしたことを考慮した上での方法論を取ることが懸命であると言えよう。

　経由したサイトにコミッションを支払うアフィリエイト・プログラムは、口コミの効果の増強をWebページに人を呼び込む可能性を高くするというストレートな方法で狙ったものである。特徴的なのは他のWebページの管理者にその価値観に基づいてリンクを貼ってもらうことを意識している点である。こうした報酬をエサに口コミを呼ぼうというアイデア自体は新奇でも独創的なものでもないし、リンクの結果に応じて報酬を支払うというスタイルも決して珍しいものではないが、ページ作成者に選択の権限を委ね、テキストの形であくまでページの一部として溶け込もうとする姿勢は評価に値する。コンテンツの中に添えるだけではなく、広告そのものを題材にしてコンテンツを作るといったこともやり易く、その出来具合によってはより大きな宣伝効果を望めるからだ。またその結果、思わぬ方向から興味を引いて予想外の効果をあげる可能性もある。マーケティングがサイト管理者の興味を引いたり、Amazon.comのように商品に対するレビューを掲載するなどしてリンク先となるページのリソースが有用であるようなとき、この効果をより確実あるいは強力なものにできるだろう。さらにアフィリエイト・プログラムを結んだ相手にメールを送って情報を伝えるなどの行動をとることで、口コミの火つけなどもおこなうことができる。

　最近になって検索サイトがおこなうようになった、検索結果として(バナーではなくテキストの形で)企業広告も提供するというビジネスもこれと通じるものがある。なぜならより検索結果として望ましいものや広告効果を見て高いものに重みをつけていくような選別や、検索をより有益なものとするために解説を添えようという試みは、同様の効果をもたらすものであるからだ。

　ただし、当然ながらこうした広告はリンク先がリンク先として望ましいものである必要がある。例えばある商品が欲しくなった時、リンクを辿っていった先がトップページでわざわざ商品や値段などを探さなければいけないのだとしたら、その商品を諦めたり別の代替サイトに行ったりしてしまうだろう。このようなことを避けるためにも、リンクは望みを果たすことのできるピンポイントへのものでなければならない。これは何も広告の場合のみではない。先に述べたように、Web上では広告とそれ以外間に大きな違いはなく、ただ広告は意図的な起爆剤・促進剤としての役目を担っているだけである。よって普段からサイト構築の際に、有意なリンクを提供できるか( 『Webの「正しい」アーキテクチャ』参照)、望んだ結果を手にすることのできるコンテンツであるか、しっかりとチェックしておく必要がある。一部の人たちがおこなっているようなトップページへのリンクを強制し、コンテンツ中へのリンクに対して非難を浴びせる行動は全くの愚行である。

　さて、最後に動画やFlashなどによる広告の、可能性の部分を見ていこう。前述した通り、これらはあくまで視聴可能なものとして提供しなければいけないという制限はつくものの、うまく利用できればそれなりに有効性はある。(将来的には手触りなどの別の感覚も加える必要があるが)商品の実物そのものを自由に見ることできる形で配信することもできるし、人気のあったCMを再配布可能な(できれば高画質の)形で提供したり、連作を一通り提供することで浸透度を高めようとすることもできる。それに、枠の限られるTVでのCMと違って時間的な制約がないため、複数の企業によるタイアップ型の広告(コラボレーション広告)を展開しやすいし、広告を作ったクリエーター―場合によっては、MAD(もとは(既存の作品の)音と映像を組み合わせたパロディ作品のことであったが、後にそうした形での(ミュージッククリップ的な)イメージムービーのことも指すようになった。)や " ほしのこえ " のような自主制作アニメの作者などWeb上での著名なクリエーターによる完成度の高い作品であることを売り物にして、広告自体を見るように仕向けることもできる。

　また、Webを見れば分かるように、企業が配信していったものに対する勝手な再配布や改変、個人の提供する実写またはイラスト画像、(FlashやMADを含め)動画などがしばしば口コミを強化するものとして働くということが実際に起こっている。こうした土壌を支えるためには、しばしばグレーゾーンに足を踏み入れがちなそれらに対する寛容や、時には援助が必要である、ということを心に留めておく必要があるだろう。

システムもサービスも最低だと批判されているにもかかわらず、コミュニティの効果で人気を保ちつづけるオンラインゲーム「Ragnarok」

　なお、これらの画像はコミュニティサイトのもの。

　上から、 バーチャルネットアコライト・さやさや１６歳、 鴨はうす、 観月堂WebSite、 街角 - Ragnarok Online管理運営改善活動。

　Ragnarokの問題については、 うさだ3に詳しく述べられている。(2003年1月10日現在)

　また、ネットワークゲームへの依存症について述べた 『【レポート】MMORPG - 終わりなき仮想世界の住人たち』も参照しておく必要があるかもしれない。

マーケティングとコミュニティが相乗効果を生んだ例「Sister Princess」

Web日記という形で、感想などをもとに一つのコンテンツを作り上げている。(コンテンツ中の画像はTVアニメ　『シスター・プリンセス　RePure』のもの)

雑誌記事をスキャナーで取り込み、リンクを張るだけの場合もある(例えば、左下のような記事がアップされる)。ファンによる(自作の)イラストコンテスト(右下)。

　特に貢献した例としてこれらをあげたが、こうした効果は何もコンテンツビジネス関係に限られたものではない。(2ちゃんねるで「ケンタッキーのビスケットがうまい」という話から生まれた擬人化キャラクターのビスケたん等、(コミュニティ)自らの手で勝手にコンテンツ化し、それによってこうした効果が生まれるといった特殊な現象もおこっているが……)

　そうした効果の実際やWebの文化的な側面などといったものは、本論分の範囲を超える。よって、そうした部分を補う本や論文が今後登場してくることに期待したい。

5.4 まとめ

　広告についてはWebのみを論じるよりもインターネット全体を扱った方がいいと考え、そのようにした。ここでの提案には荒削りの部分もあるだろう。しかしながらそれ以上に、今インターネット上でおこなわれている広告の大半は、既存の方法論あるいは技術的に可能であるからそれを使うという考えに取りつかれていて、誤ったアプローチを平気で使っていたり、インターネット・Webの持つ可能性を十分に引き出せていない。よって、より発展させるためのアイデアの素として叩き台として、そうしたものもあえて示すことにした。

　インターネットにおけるマーケティングの創生期はとうに終っている。これから先使えるものは使い、より適切でより効果的なアプローチを採る、ということのできないものは埋もれていく。そのような危機感をもってここでの考察・提案をとらえて欲しい。