• MTの普及はCSS信者を増やしたのか (2004/6/30 04:03) （>>この記事のみを表示）
• MP3は何処に向かうのか (2004/7/30 09:38) （>>この記事のみを表示）
• 現時点におけるRSSとは何なのか (2004/8/20 02:55) （>>この記事のみを表示）
• RSSとはURLリストである (2005/2/19 22:48) （>>この記事のみを表示）
• マッシュアップの「敵」の定義 (2006/6/01 03:06) （>>この記事のみを表示）
• マッシュアップの「敵」を倒す (2006/6/03 01:54) （>>この記事のみを表示）
• 「それでも」タグに未来を見る (2006/7/26 03:55) （>>この記事のみを表示）
• ウェブサービスの復興とDL (2006/11/11 11:37) （>>この記事のみを表示）
• RSS全文配信はWeb2.0か (2007/7/28 18:14) （>>この記事のみを表示）
• mixi魚拓を作るメカニズム (2008/1/23 10:40) （>>この記事のみを表示）
• 「主従」としての携帯世代 (2008/5/25 18:33) （>>この記事のみを表示）

僕は正直に言うとtokix.netを運営していた2003年夏まで、そしてその後一年間弱をblogというモノと全く関わらずに生きてきたんですが、この「MovableType」というツールが一般的なサイト運営者に与えた影響は凄く大きいように、今MT解説サイトやらを見ていると思うのですよ。「MT以前」・・・こういう言い方をするのは凄く嫌なんだけど・・・の僕から見て一番不思議なのが、W3C信者をウザいなぁと思う一般的な運営者がCSS信者になってることなんですね。実に不思議だ。

これは「文字サイズは絶対指定すべきか相対指定すべきか」という苔の生えた議論なんかだと顕著なんですが

1. やっぱり一般的なユーザーはIEの文字サイズをデフォルト(中)にしてる訳で、その状態で見て見やすいようにすべきだよ
   =絶対指定するか或いは相対指定で本文を90%とかにすべきだ
2. そんなのは閲覧者側の怠慢だ
   =本文を100%にしないのは変

この議論の焦点が、つまり「CSSをどう使うか」になっている。僕は、運営するこのサイトが見ての通り本文100%なんですがそれは「つーかウチのサイトの読者(正確にはかつての読者)という時点でいくらなんでも文字サイズ中にして『文字デカいなぁ』と思ってるヤツはいねーだろ」という「運営者の驕り」であり「怠慢」なので放置して欲しいんですが、心情的には1側で、つまり「W3C信者ではないです」。

で、つまり「W3C信者でない」一般的なサイト運営者が「やっぱり多数派はデフォ設定なのよね」と思った時に何故下記の方法を使わないのかが解せない。

<font size=2>本文</font>

「解せない」と書いたけど実は何となく理由は推測できて、つまりMTってCSS前提なんですよね。「あらゆる要素はdivかpに入って、そのdivなりpなりに対して共有cssファイルで指定を行う」ということが前提になっている。なので上記の「苔の生えた議論」がいつの間にか「CSSは前提なんだがその上でCSSをどう使うか」になっている。・・・ように、僕には見えます。

何故font size指定を勧めるかと言えば理由は単純で、より多くの人間に対応できるから。単純なサンプルを見せると

1. ヤフー：http://www.yahoo.co.jp/
   例えば「ショッピング」とかいうあらゆる本文はsize=2です(「smallタグ」=「font size=2」)
2. フレッシュアイ：http://www.fresheye.co.jp/
   例えば「天気」とかいうあらゆる本文はsize=3です

二つのサイトで文字サイズを中にしたり小にしたりすれば差は歴然でしょう。つまり「size=3は文字サイズ次第で実際のサイズが大きく変わるがsize=2は変わりにくい」。これはもうIEが設計おかしいだけであってそれ以上の理由ではないですが(あとNNやOperaは最小フォントサイズを指定できるのでちゃんと使い込んでる人なら「読みにくい」ということはないし残念ながら「ちゃんと使い込んでない」人はそもそもNNやOperaなんざ使わない/Mac版IEやらは知りません)。

僕は一番最初に触れた議論に対し何ら「こっちが正しい」と言う気はないですが、「一般的な読者」を想定し「その一般的な読者の閲覧を想定する」なら、font sizeを無視するのは損です。CSSで90%とかやると、それは「文字サイズを中にしてる人にとっては読みやすく、小にしてる人にとっては読みにくい」サイトになる。size=2なら「中でも小でも読めるサイト」になる。

もちろんfont sizeなんてのは、というかむしろfontタグ自体がW3C的にはあり得なくていずれブラウザから廃止されるっていう超既出にして延々と(多分永遠に)実現しない話は知ってます。ので「その議論に踏み込む気はない」のです。自分が想定する来訪者にとって読みやすいということは重要だ、というその部分で共感するので「そのための手段を自分でわざわざ狭めていませんか？(ここで触れたfont sizeなんかはその最たるところで)」と言ってみます。

最後に、「一般人にとってのアクセス性」を最優先にしつつCSS信者ってのは立ち位置として極めて中値半端ですよ？と反論想定をしつつ終わり。

※

「ウェブ媒体でこういうことを過剰に気にするのもなぁ」というのと「正直俺は日本人平均の10倍くらいはCD買ってる」というのがあるのである程度露骨な表現をします

MP3は当初、シングルCDをリプレイスするモノだったように思えます。具体的にはウェブやFTPからNapsterの時代でしょうか。アナログ〜ISDN程度で5分のMP3を20分くらいかけて落としていた時代。

当時僕はレンタル屋でシングルCDを適当に10枚くらい借りるということを一ヶ月に一回くらいやってました。それで気に入った曲があったらその人（なりバンドなり）のアルバムを買うかレンタルするかする、と。借りたシングルCDは「シングル集」みたいなMDにまとめて録音し、そのMDは一ヶ月もすれば聴かなくなっていた。「聴き続ける」のはアルバムだった。

MP3は、この「シングルCD」をリプレイスするモノとして非常に便利でした。まだ60MBといった「アルバム全部」を一気に落とせる時代ではなかった。5MB程度のファイルでも落とせた時は「やった」という感覚があった。レンタル屋に入ってから棚の前で行っていた「どの曲を聴いてみようかな」と悩む作業をデスクトップの前で行えることは非常に便利だった。

回線は高速化し、.zip.mp3の時代がやってきた。MP3はアルバムレンタルをリプレイスするモノになっていた。64MB〜128MB程度の内蔵メモリを搭載したポータブルMP3プレイヤーが普及した。Nikeまでもが「ジョギング中にどうぞ」とかいうコピーで商品を出していた。それは確実に「アルバム一枚が入るサイズ」だったように思えます。WinMXや（高速回線下での）FTPは「アルバム同士の交換」に便利だった。HDD内MP3フォルダに「アーティスト名」「アルバム名」といった階層ディレクトリを作りアルバムを集めていった。WinMX（や趣味の合う会員鯖）はレンタルに来ないようなマイナー洋楽の視聴に便利だった。Winnyによって、キーワードを設定して放置するだけで手に入るという環境すら実現した。

聴く音楽の幅をMP3で広げ、本当に気に入ったアルバム・・・昔なら「レンタルで借りてMDに落とすだけじゃなくてCDを買う」レベルで気に入ったアルバム・・・だけを買っていた。

そして、今僕らのHDDには数十GB超のMP3が溜まっている。

iPodがHDD型ポータブルMP3プレイヤーの時代を作ろうとしている。「容量15GB」とは「約250時間」を指す。平均的な社会人・学生の通勤通学時間を往復2時間とするなら125日分。

HDDに溜まっているMP3を30GBと仮定する。雑誌の「あなたのPC使用時間は？」に対する最も多い選択肢が「5時間以上」。「30GB」とは「約500時間」であり、一日5時間MP3を再生しても100日分。

HDD型プレイヤーや自分のHDDを見て、僕らはそろそろMP3の新しい姿を見つけるべきなのかもしれません。「アルバムをリプレイス」していた当時と同じようにMP3を使うなら、iPodとは「入れ替えの手間がないけど音質が悪いポータブルMDプレイヤー」に過ぎない（省スペース性という利点はHDD化で消えた）。そしてその「入れ替えの手間」というのは、先の計算を使うなら「通勤通学中一日一回の手間」に過ぎない。一日一回の手間をなくすために高い金を払って音質の悪いプレイヤーを買うのか？と。

「デジタルデータ」というモノの利点はいくつもあると思うんですが、例えば三ヶ月ほど前の記事なんですが

アルバムを最初から最後まで通して再生するといった、古臭くて堅苦しい聴き方をやめて、再生する曲を音楽プレーヤーに無作為に決めさせることが人気を集めている。

ランダムな選曲は、何万曲にもおよぶ楽曲ライブラリーという膨大な音楽コレクションを伴ったとき、その真価を発揮する。このような大規模なコレクションでは、放っておいたら一度も再生されない曲を聴かせてくれる優れた方法――場合によっては唯一の方法――だろう。

『iPod』のシャッフル再生で音楽の聴き方が変わる

こういうのが「ユーザーサイドで出来る変遷」でしょうね。シャッフル再生を行えばiPodは「入れ替えの手間がないけど音質が悪いポータブルMDプレイヤー」を超えることが出来る。MDには出来なくてHDD型MP3プレイヤーだから出来る、という。しかしシャッフル再生というのはつまるところランダムであり、「古臭くて堅苦しくない」聴き方であるのと同時に「納得いかない繋ぎ方にキレるハメになる」聴き方でもある。では、ユーザーサイドで出来ることに限界がある現状、プログラムサイドはどうすべきなのか？どうやってMP3をMD以上のモノに変えていくのか？

という、この流れが今後のスタンダードになっていくと思うのです。僕らが本当にCDやMDに対して抱いていた不満・・・MP3が解決するべき「不満」（「それを解決できないならMP3は低音質形式に過ぎない」という類の不満）・・・とは、つまり「CDやMDの時代、僕らは選曲を自分で決めなければいけなかった」であり、「それが故に肥大化していくMP3フォルダ/ポータブルプレイヤーのHDD容量は再生されない曲を増やしているだけだ」ということではないのか？と。

このところ、PCの前にいるときは以下で紹介するネットラジオを聞きっぱなし。

仕事中はCDを入れ替えるのもめんどくさいので、ここのチャンネルは非常に助かる。選曲もナイス。

なんといっても、選曲レパートリーに偏りがないのが良い。次のCD考えるだけでも大変だった（笑

airoplane.net内一日中クラシックを聞いて生きよう

というようにCD持っていてもその理由でネットラジオにハマってる方もいますし（笑。

具体的に言えば今後のMP3プレイヤーなんですが、例えばWinamp信者の僕はインターフェイスや音質や対応形式の問題でWinampを捨てることはあり得ない。捨てることがあるならば、Winampというプレイヤーが持つ再生スタイルの旧世代性・・・つまりディレクトリレベルでアーティストやアルバムによる階層構成を取りプレイリストから再生することを主とする/マニュアルで選曲を決めることを「デフォルト」とした設計/いわば「数百連装CDコンポ」としての設計・・・に限界を感じた時でしょう。ネットランナー8月号に書いてるんで詳細は省略しますが、ディレクトリレベルではなくタグレベルでMP3を管理するジュークボックス型のプレイヤーソフト・ユーザーの好みを覚えて好みに従ったシャッフル再生（つまり完全なランダムではないシャッフル再生）を行うプレイヤーも登場しています。おそらくその進化の果てにあるのは、例えば

というプレイヤーソフトであり将来のiPodはプレイヤーソフトの書き換え機能を実装しプレイヤーソフトを定期的にバージョンアップするはずであり、そうなった時にMP3は本当の意味でMDを超えることが出来て、僕らの数十GBのMP3コレクションやiPodにも意味が出て、MP3の真価が発揮されるように思えるのです。

この文章は「RSSって言葉を聞いたことはあるんだけど結局導入していない」という人にRSSというモノの現時点における実体を解説するものです。故にRSSの本来の目的とかその設計思想とかは割と無視しています。それと最後の方で現在のRSSの実体を考えた上での提起とかをしてみます。

これは当たり前のことを難しげな言葉で語るだけですが、ウェブサイトというモノは形式的な定義であって性質的な定義ではありません。例えば「インターネットは新聞というメディアを滅ぼすのか」といった議論（がその昔ありましたが「新たなメディアが既存メディアを縮小させることはあっても滅ぼすことはない」という歴史的事実・・・例えばラジオは今でも存在する・・・がようやく浸透してきたように思えます）における「インターネット」「ウェブサイト」は具体的にはニュースサイトとかニュース系のメールマガジンやニュースサーバー等を指している訳で「全てのウェブサイト」を指している訳ではない。

このため、「自分がよく行くサイト」というのをリストアップする場合、その「よく行くサイト」は必ず「性質」によって分類可能です。下記は僕の意図的な分類ですが、例えばこのように。

• データベースとして有用なサイト
  imdbやAllMusicのようなサイトも勿論そうですし、Googleのような検索エンジンも「ウェブページに関するデータベース」と言い換えることが出来るでしょう。別の言い方をすれば「更新」にはあまり意味が無く「自分の必要に応じてアクセスするサイト（もちろんデータベースとしての性能を維持するには更新は必要ですが更新とアクセスに関連がない）」。
• 連載テキストとして面白いサイト
  いわばサイト自体が「一つの発刊物」の性質を持っており、日々その「連載」が継続していくタイプのサイト。例えば日記サイトなんかがその典型ですし、blogの大半もここに分類されるでしょう。別の言い方をすれば「更新されていたら必ず一度アクセスしたい」「更新されていなければアクセスする必要がない」サイト。
• 情報の取捨選択が可能な網羅性の高いサイト
  これが最初の例で使った「新聞を滅ぼす可能性のあるサイト」ですかね。新聞読者の大半は新聞の全ての記事を読む訳ではない。自分に必要な記事・興味のある記事を取捨選択する。そのためには当然網羅性が高くなくてはいけない。朝日や読売や毎日やCNNのウェブ版、ウェブ独自のメディアを挙げるならHotWired等。
• アーカイブとして興味深いサイト
  上の言い方を引き継ぐならば、これは「本を滅ぼす可能性のあるサイト」でしょうか（最初に書いたように僕は滅ぼすとは思ってません）。学術系とかも勿論そうなんですが、例えば2chのまとめサイトなんかもこの部類でしょうね。かなり旬を逃しながら「まぁでもいまだに週刊誌レベルだと現役だし」ということで電車男のアレを例に挙げてみます。

さて、このように「ウェブサイト」と一言で言っても「どのようにそのサイトを利用するか」というスタイルは一通りではない。にも関わらず、今でもWindows+IE環境では（というかほとんどの環境では）「よく行くサイト」を管理する方法は一通りしかない。「お気に入り」「ブックマーク」と呼ばれるアレです。

「お気に入り」「ブックマーク」というのは、ウェブページのURL/タイトルをツリー構造で管理する方法です。ツリーによる階層管理が可能なので「アーカイブとして興味深いサイト」を管理するのに適している。別の言い方をすれば、他のサイトを管理するのには適していない。

• データベースとして有用なサイト
  例えばGoogle検索をする時に毎回Googleトップページを開く必要がない。やりたいことは常に「Googleトップページの検索窓に何らかの文字を入力して検索結果ページを見る」ということであり、「トップページを開く」は無駄なアクションである。また、例えば「CDを買いたい」と思った時にAmazon検索結果を見た後で行いたいことは「HMV検索結果を見る（そして値段を比べたりする）」であって「Amazonサイト内で家電カテゴリに移動する」では無い。
• 連載テキストとして面白いサイト
  「更新されていたら必ず一度アクセスしたい」「更新されていなければアクセスする必要がない」のに（URLとタイトルが記録されているだけの）「お気に入り」では「更新されていても気付かない」「アクセスしたのに更新されていない」ということが頻繁に起こる
• 情報の取捨選択が可能な網羅性の高いサイト
  トップページに行く必要がない。知りたいことは常に「どのような記事がアップされているか」であり、興味深い記事があればその記事のウェブページを開く必要があるが必ずしもトップページを経由する必要はない。また、例えば朝日でオリンピック記事を見た後に行いたいことは「他のメディアで似たような記事を探す」であって「朝日のおくやみカテゴリーを見る」では無い。

こういった問題点・・・「お気に入り」「ブックマーク」が本質的に「アーカイブを管理する方式」であってそれ以外ではないという問題点・・・を解決するために、人は新たな「ウェブサイト管理方法」を考えてきました。

• データベースとして有用なサイト
  「検索バー」というのは、実のところ「データベースとして有用なサイト」を管理するための方法です。タブ型ブラウザを含む、IE以外の主要ブラウザでは大抵導入されており、IEでもGoogleツールバーなどを導入すれば組み込むことが出来ますが、バー上に文字を打ち込み検索エンジンを選択してエンターを押せば「検索結果」が表示される。検索エンジンは自由に追加/削除できるため、自分がよく行くデータベースサイト（いわゆる「検索エンジン」に限らない）を管理することが出来る。またSleipnir等のタブ型ブラウザでは「複数エンジンで同じ文字を検索した結果を複数タブに表示」といった芸当も可能であるため、「アルバム名を入力してエンターを押せばAmazon/HMV/TowerRecord/Tsutayaの値段を一発で比較」といった環境を構築することも出来る。
• 連載テキストとして面白いサイト
  「更新チェッカー」「アンテナ」による管理。ただこれは実のところ、完全に実現されたことが過去一度もありません。「更新されていたら」という日本語を根元的な言葉に翻訳すると「ウェブサーバー上でHTMLファイルの最終更新時刻が変化していたら」「HTMLファイルの内容が書き換えられていたら」ということになりますが、ファイルの最終更新時刻を取得できないサーバーでは前者の方法は使えませんし、HTMLファイル内の文章自体と関係のない部分（例えば広告部分/blogにおけるコメント部分）が更新されるサイトでは後者の方法は使えません。はてなアンテナ等一般的な後者の方式を用いる更新チェッカーでは「更新チェックを行う範囲」「無視する行」を定義することでこの問題を解決しようとしていますが・・・そして体感的に90%のサイトではこの方法でチェックが可能ですが・・・100%ではないし、100%になることはあり得ない。
• 情報の取捨選択が可能な網羅性の高いサイト
  RSSとは、（本来は）このようなサイトの管理方法として生まれた技術です。

さて、ここまで来てようやく「RSSとは」という話になりますが、RSSとはウェブサイトが発行する小さなファイルです。このファイルには、そのサイトで公開されている記事の「見出し」「更新時刻」「概要」などが記述されている。ウェブページ自体と比べると非常に小さなファイルであるためダウンロードしてもクライアント/サーバー共に負荷が小さく、また形式が決まっているため専用ソフトを使ったチェックが非常に容易です。・・・と言葉で説明するより一枚の画像を紹介した方が分かりやすいと思ったのでGlucoseのスクリーンショットをご覧下さい。Yahoo! NewsやCNETといった「網羅性の高い」複数のサイトから見出しを取得しメーラーのような3ペインアプリで管理し、その中で「携帯電話」が含まれる記事のみを抽出しています（Glucoseトップページはこちら）。

例えば朝日でオリンピック記事を見た後に行いたいことは「他のメディアで似たような記事を探す」であって「朝日のおくやみカテゴリーを見る」では無い。

RSSとは、このような「ネットサーフィン」を行うための技術です。

では、RSSは普及しているのか。現時点におけるRSSの実体は下記です。

• インターネット上でニュース等を精力的に求める場合、RSS/RSSチェッカーは非常に有用である。
• ただし、RSSを発行しているサイトの大半はGlucoseのような「本来の」RSSチェッカーを想定していない。

これは、ぶっちゃけて言えばウチもそうなんですがblog系サイトの功罪です。MT等のblogツールは「RSS発行」が非常に簡単です。それが故にRSSを発行する個人サイトが増えて「RSSが今熱い！」といった論調になっていく訳ですが、さて、例えば小鳥さんとか真鍋かをりblogに通ってる人の何割が「見出し」をベースにしてアクセスしているのだろうか。別に日記系blogに限らずとも、僕はX51.ORGさんとこは「更新されていたらアクセス」してます。即ち、RSSを発行しているサイトの大半（blogサイト）は（仮に管理人が否定しようと）「情報の取捨選択が可能な網羅性の高いサイト」ではなく「連載テキストとして面白いサイト」である。

・・・ここに、RSSという技術の今日における問題点が集約されているように思えます。

「連載テキストとして面白いサイト」を管理するための技術は既に存在している。WWWCやはてなアンテナを使っている人にとって「一部サイトではRSSを使う（チェッカーを複数にする）」ことは非常に面倒です。何でろじっくぱらだいすさんの更新をアンテナで取得した上で小鳥さんとこはGlucoseで取得しなくてはいけないのか。RSSは「見出し」「更新時刻」を含みますから、RSSチェッカーを更新チェッカー代わりに利用する（例えば上で紹介したスクリーンショットで行われているような「RSS/RSSチェッカーの特性を十分活用したサーフ方法」ではなくて「更新されていたらアクセスする」という目的でRSS/RSSチェッカーを利用する）ことも可能です。しかしRSSチェッカーの大半は「RSSを発行していないサイト」に対応していない。既存の「更新チェック方法」、つまり「ウェブサーバー上でHTMLファイルの最終更新時刻」「HTMLファイルの内容」を取得しての更新チェックを行うことができない。

今日におけるRSSとは、RSSを発行するサイトの中では「極一部」に過ぎない「情報の取捨選択が可能な網羅性の高いサイト」を管理するための技術です。即ち、インターネット上で発行されているRSSの大半は多くの人にとって「意味がない」。

RSSリーダー利用者は4.7％

ModernSyntaxさんのRSSリーダー利用者は4.7％より

この数字というのは、つまりそういうことでしょう。

「多くの人に」というのは、つまり「例外もある」ということで（blog管理者の話はここでは外します、非サイト管理人の話です）、もし「通ってる『連載テキストとして面白いサイト』は全てRSSを発行している」という人がいたら、「連載テキストとして面白いサイト」の管理にGlucoseとは設計理念の異なる「アップされた記事を全て（或いは大半）開く」ことを前提としたRSSチェッカーを利用するのも良いでしょう。cococというRSSチェッカーをその目的で紹介します。この場合二つのRSSチェッカーを使い分けると良いと思います（cococは「情報の取捨選択が可能な網羅性の高いサイト」の管理には向いていないのでそっちにはGlucose等を使う）。

これが、今日におけるRSSの実体だと、僕は考えます。RSSが「情報の取捨選択が可能な網羅性の高いサイト」の管理方法としての熟成を目指すのであれば、「RSSは（blog管理人が思うほど）普及していない」と言わざるを得ないし（少なくとも君が発行しているRSSには意味がない）、RSSが「情報の取捨選択が可能な網羅性の高いサイト」の管理方法だけでなく「連載テキストとして面白いサイト」の管理方法にまで手を伸ばすのであれば、cococ型のRSSチェッカーは既存のウェブページ更新チェック方法を取り入れるべきでしょう。

別の言い方をすれば、そういった「（既存のチェック方法だけでなくRSSにも対応した）更新チェッカー」に、僕は期待したいと思います。それはおそらくRSSの本来の設計理念とは異なるけど、「全てのサイト（連載テキストとして面白いサイト）がRSSを発行する」ということが現実的に夢物語である以上、それこそが唯一（多くのサイトで発行されている）RSSによって「ネットサーフィン」を今よりも便利にする方法だと思うのです。

だから「RSS」という言葉を知っていてもチェッカーを導入していない人に対して僕が（偉そうに）助言するなら下記です。

「『情報の取捨選択が可能な網羅性の高いサイト』を精力的に利用しているなら導入した方が便利です。ただ、そうでないのならば現在の（例えばblogサイトで発行されている）RSS/RSSチェッカーには意味が無いです。はてなアンテナを利用した方がよっぽど便利ですし（はてなアンテナで更新を取得できない日記系サイト<<RSSで更新を取得できない日記系サイト）。」

僕は「お行儀の良い技術」というのが嫌いだ。

これは、例えば「金儲けのことしか考えていないMSは嫌いだ」とか「囲い込みを当然のような顔で行うAppleは嫌いだ」とかと並列の台詞と思って貰えれば、という感じなんだけど、お行儀が良く、そのお行儀の良さを他人に強要するオープンソース/非営利団体周辺の技術への嫌悪感、の意味であり、分かりやすく言えばWinユーザーを「貧乏人のドザ」とバカにするマカーと同じように、オープンソース信者を「インポ野郎」とバカにしていなくもない、の意味であり、かつ先のセリフと同レベルに信者に反発されると困るよねという意味でもある。

多分あれなんすよね、僕は今は厨房サイト管理人だけど（こういう台詞を素で書くのもどうかと思います）昔は割と正しく理系ヲタプログラマー少年だったりもしたので、多分同類嫌悪なんだろうな、とも思う。なのでマジで真剣には反発しないで下さい、と予防線をはったりもする。

技術はエロと結びつかないと普及しない、という台詞・・・即ち、ビデオデッキはAVのおかげで普及した・・・を言うのであれば、Firefoxはエロサイト用ブラウザだ。ウェブで最も「セキュリティ」というものを真剣に考えなければいけない場所はエロか割れだ。だから「僕は安心して割れるためにFirefoxを導入しました」とか「エロサイトをIEで回るのは怖いけど、Firefoxに乗り換えれば安心」とかいう売り文句でFirefoxは宣伝を行えばいいと思うのだが、そういう論調はネットの何処にも存在しない。

同じレベルの話として、RSSとはURLリストだ。汎用性が高く、リーダーとの組み合わせにおいて様々なスタイル（メーラー型リーダーを使ってデータベースを作ることもできるしデスクトップ貼り付け型リーダーで常時表示させておくこともできる）で利用可能なURLリスト。以前別の記事でblog周辺のRSS熱にクエスチョンマークを書いたけど、「RSS」というものは

• 発信者である自分の情報
• ウェブページのタイトル
• ウェブページのURL
• ウェブページの概要

を羅列したファイルに過ぎない。それは究極的に言えば日記ともblogとも（一応ここでは『blog≠日記』という書き方をする）個人運営サイトともニュースサイトとも関係がない。

合法ビデオのtorrent情報（BTはファイルの情報が記載されたtorrentファイルを元にしてダウンロードを行う）をRSSで配信しBTによる地引ダウンロードを行うVideoraだとか、ワンクリックでiTunesに転送可能な音声ファイルRSSを配信するPodcastだとか、RSSは「新しい活用方法」を求めている。でもさ、そういう風に「RSSを更に新しいシステムと組み合わせることで」という話をする前に、それ以前の問題として、RSSはURLリストなんだよ。その意味において、僕はBTで言うならisoHunt（ネット上からtorrentファイルを検索した結果をRSS配信している、つまり割れやエロに利用可能）やヤフオクのRSS対応（検索結果をRSSで配信するようになった）を評価するし、面白いと思う。ちなみに僕が初めてRSSについて書いたときに「例」にしたのはFeedAmazonだったりする。Videoraによる地引ダウンロードはたしかに「面白い」のだけど、RSS以外のシステムとの組み合わせでしか動作しない以上、「RSS」の最大の長所であったはずの「汎用性」は消えている。つまり、Videoraを起動していないと「地引ダウンロード」は発動しないのであり、例えば「それはnyによる地引とどのように違うのか」と問われると答えが難しい。汎用性の高さが長所だったはずの技術を「このプラットフォームでこのツールを使うとこれができる」と限定的な方向性で進化させれば、既存の技術と「かぶる」可能性/ある限られた範囲の人間以外に見向きもされなくなる可能性が高くなるのは必然だ。・・・別にVideoraやPodcastを叩いているのではなくて、「それももちろん面白いんだけど、足下を見るという行為もしようぜ（まだRSS自体が『市民権を得ていない』技術なんだし）」の意味。

そして「足下を見た」とき、RSSとは、汎用性が高く、リーダーとの組み合わせにおいて様々なスタイルで利用可能なURLリストだ。デスクトップに何を貼るか・何に関するデータベースを作るかは、ユーザーに委ねられている。従って、それは確実にエロや割れと繋がる「べき」技術でもある（こういうことを書くと「お前が厨だからといって皆が同じだと思うなよ」と言われそうだけど、全く同じ理由で僕は個人blogとかのRSSよりAmazon商品やヤフオクのRSSに注目しているのでそれを言い訳にしておきます）。それが本当の意味での「RSSの普及」だし、多分「そんな普及の仕方ならしなくて良い」と思う人間の手を離れたときに、RSSは・・・AVを得たビデオデッキと同じように・・・市民権を手に入れる。そしてエロや割れと繋がったとしても、ビデオデッキがAV以外のビデオをも再生するように、RSSは「正しい」利用方法もされ続けるはずなんだ。「だからRSS信者は俺を否定するな」という意味ではない。

確認しておこう。

人は本質的には所有欲を持っている。別にそれは悪いことではなく当たり前のことで、例えばイラストレーター系の個人サイトから画像を取得し一覧表示するサービスが（法的問題以前に）叩かれるのは「当たり前」だ。

「マッシュアップ」とは、いわばこの常識の破壊でもある。つまり、Googleマップは、それが短期的に自分への利益を生まず損失（サーバー負荷）のみを生むにしてもAPIを公開しこういうサービスを成立させている。その長期的視野なり思想なりが「マッシュアップ」と呼ばれる概念に他ならない。

だからマッシュアップは現代インターネットの唯一の常識ではない。「今はマッシュアップ時代なんだからお前の書いた絵で俺がどんなサービスを動かそうが勝手だ」は通らない。

それに乗るか乗らないか。その選択肢が存在している、という、このことを確認しておこう。

「はてな」はたしかに何も生んでいない。例えばソーシャルブックマークサービスは他人のウェブページを羅列したサービスであって、「はてな」が生んだコンテンツなど何一つ存在しない。けれど、「はてな」は他人（コンテンツ制作者）に依存してサービスを動かすのと同時に、他人を依存させている（例えばAPIの公開）。だから「はてな」は、この時代に存在するサービスとして「悪」でも「ゴミ」でもない。

一般論としていえば、いわゆる「PC上級者」はコマンドラインオプションのあるツール・コマンドラインで動かすツールを好みます。何故かといえば、「連携」が可能だから。ツール起動してツール上でzipファイル選ばないと解凍できない解凍ツールより「送る」やドラッグ＆ドロップで解凍できるツールの方が便利で、その延長線上の「連携」を求める思想。いわば、オフラインのマッシュアップ。

別の言い方をすれば、マッシュアップとはウェブにおける連携の概念。川の流れのように、データを流れさせる概念。その概念がウェブに拡大されたことが「今日的」とか「Web2.0」とかいう話であり、今存在しているのは、川に身を投じるか投じないかという、その選択だ。

川・・・これは「ウェブサービス」のみを指すのではなく「連携」の意味・・・に身を投じ、他人のサービスに依存し、他人を依存させない。それこそが、この時代の「敵」だ。他人を川の上流と見なし、しかし自分は川の最下流であるという主張を行う存在が、だ。川に飛び込んだなら、己の川における位置を主張することはできない（「俺は最下流にはならんしょー」という主張は可能だけど）。

APIの公開は「一機能」に過ぎない。別にページを取得しHTMLを解析するツールくらい、APIがなくたって組める。「API」のイニシアチブは提供者でなく利用者であって、いってしまえばAPIとは「HTMLを取得されると負荷がヤバいんでこうして下さい」「しかもほら、こっちのが便利でしょ？」という提案に過ぎない。

逆に言えば、APIの提供は「義務」とはならない。APIがなければ勝手にページを取得すればいい。「川に身を投じている相手に対して」それを行うことは悪でも何でもない。・・・いわゆる「RSSを配信してないサイトを解析し勝手にRSSを作成」系は、この意味で微妙だ（そのサイトは「川に身を投じている」のか？個人イラストレーターのケースと違うのか？）。ただ別にそこら辺の人を怒らせる気は毛頭ないし「皆が取得するより誰かが代表して取得してRSS作って皆に撒いた方がベターですよね！」と、つまりここまでの話とは全く別の次元の問題ですよね、・・・と言っておきます。

この時代の「敵」とは、他人のサービスに依存し、しかし他人を自分に依存させないという強い意志を持ってサービスを動かす人間に他ならない。もう一度書くが、APIとかRSSとか、そもそもウェブとかいう限定的な話ではなく、「連携」の話。他人に依存しながら、他人を「自分の上流にいる存在」と見なしながら、他人に依存されにくいHTMLを吐く人間・URLリストに過ぎないRSSを「自分のサイト内ページに人をアクセスさせるための道具」と見なす人間こそが、この時代の「敵」だ。

例えば、マッシュアップの「敵」を倒すということの意味、について。

URLリストに過ぎないRSSが「Rich Site Summary」であることに、昨年頭あたりから違和感を持っていた。

「RSS」というものは

• 発信者である自分の情報
• ウェブページのタイトル
• ウェブページのURL
• ウェブページの概要

を羅列したファイルに過ぎない。それは究極的に言えば日記ともblogとも（一応ここでは『blog≠日記』という書き方をする）個人運営サイトともニュースサイトとも関係がない。

RSSとはURLリストである

もし「はてな」が、はてなサイトの広告をクリックさせるためにRSSを配信していたなら、僕は「はてな」に悪意を持つ。・・・この文章は端的だけど二つ嘘がある。もう少し詳しく、かつ二つの嘘について書く。

はてなブックマークでタグ検索を行うと表示されるページ、例えば「タグ『youtube』を含む注目エントリー」ページにはRSSへのリンクがある。RSSファイルはこれ。RSSに記述されているURLは、ブックマークされた記事そのもの。ユーザーがRSSをリーダーに登録し、表示された記事をクリックした時に開かれるのは「ブックマーク対象の記事」であって、例えばこういうページではない。

□1：嘘1・・・広告について

別に広告はどうでもいい。広告が無いサイトは善意の産物で広告のあるサイトは金儲けの道具、なんてとらえ方はどうでもいい。「広告は必要悪」といった話ではない。アクセスは、それ自体が力だ。広告があろうがなかろうが、「誰かを自分のサイトにアクセスさせる」「誰かに自分のサービスを使わせる」ということそのものが「力の入手」である。それが、皆大好きWeb2.0の世界だ。

□2：嘘2・・・悪意について

人は悪を憎みクズを蔑視するが、（それが「はてな」サイト内URLであるという理由で）役に立たないRSSは「悪」でも「クズ」でもない。ただの「敵」であり、倒すべき存在に過ぎない。

APIの公開は「一機能」に過ぎない。別にページを取得しHTMLを解析するツールくらい、APIがなくたって組める。「API」のイニシアチブは提供者でなく利用者であって、いってしまえばAPIとは「HTMLを取得されると負荷がヤバいんでこうして下さい」「しかもほら、こっちのが便利でしょ？」という提案に過ぎない。

APIとかRSSとか、そもそもウェブとかいう限定的な話ではなく、「連携」の話。

マッシュアップの「敵」の定義

データの連携を「止める」存在（「生まない」存在、ではない）は「敵」に過ぎない。

・・・一応ここらへんで確認しておきますが、「はてな」はこの意味で「悪」でも「クズ」でも、「敵」でもない。良い、役に立つ、皆の味方なサービスです。

「データの連携」という概念の元では、「絶対的な最下流」というものは本質的に存在しない。基本的に、それこそ広告をクリックして貰えるのは最下流だけだけど、「絶対的に最下流にしかならない場所」というものは本質的には存在しない。

例えば、「はてな」はRSSを提供しており、RSSリーダーを使っている人は注目記事情報を得るために「はてな」サイトにアクセスする必要がない。

• だけど、自分がブックマークを行うためにはアクセスする必要がある
• だけど、RSSリーダーを使っていない人はアクセスする必要がある
• だけど、今見ているページに「はてな」ユーザーがどんなコメントを残しているか知りたい場合はアクセスする必要がある
• だけど、どんなRSSがリクエストされたかログることはできる
• だけど、RSS自体に広告を仕込むビジネスモデルだってあり得る
• etc

どんな言い方でもいいが、「最下流」は人によって、ケースによって異なっているし、そもそも「最下流」のみが意味を持つ訳ではないケースもある。・・・と、いうことに意味を感じられないなら

別の言い方をすれば、マッシュアップとはウェブにおける連携の概念。川の流れのように、データを流れさせる概念。その概念がウェブに拡大されたことが「今日的」とか「Web2.0」とかいう話であり、今存在しているのは、川に身を投じるか投じないかという、その選択だ。

マッシュアップの「敵」の定義

川には飛び込まない方がいい。

役に立たないRSSは「悪」でも「クズ」でもない。ただの「敵」であり、倒すべき存在に過ぎない。

例えば、当サイトは以前、Proxomitronを使いHTMLソースを書き換えダウンロードを行う、という方法論を（別にマッシュアップとかそういう話題の上でではないけど）提示した。そういった意味だ。

「タグ」という言葉が「Web2.0」とか「マンパワー」とかいった言葉の中で語られたことは、確実に弊害を生んでいる。一言で言えば、何故世界を彩る全ての要素にタグを付けさせたがるのか、ということだ。

「タグ」という言葉が「フォルダ構造」といった言葉と敵対する言葉（「フォルダ管理はもう古い」）として普及したことは、確実に弊害を生んでいる。一言で言えば、何故フォルダ構造を無視するのか、ということだ。

最近はYouTubeを、なんつーか、割と偏執的に追いかけてるのだけども、その課程の中でいくつかの方法論を提示してきた。その中の二つを軽く紹介します。

□1:HATENA-TUBEを使い話題動画を自動ダウンロード

ネットランナー2006年8月号で書いたネタだけど、「自動」でなければ別に特に工夫の必要もないので軽く書く。Irvineと連動するダウンロードスクリプトを使えば良い。Irvineには「登録日付で分ける」という機能があって、この機能を使うと「ダウンロードフォルダ\20060716」みたいなフォルダが自動生成されて、日付別フォルダ内にFLVファイルが蓄積されていく。

□2:TAGIRIを使いYouTube動画をサムネイル管理

「にゅーあきばどっとこむ」の記事で書いたけど、エクスプローラでは縮小表示でもサムネイルにならないFLVをサムネイル管理できる動画ブラウザ「TAGIRI」は、YouTube動画の管理にピッタリ。監視フォルダを設定すると、そのフォルダ（と子フォルダ）内に追加された動画が自動でカタログに加わる仕組み。

二つの方法論を併記したとき、ある疑問がTAGIRIに対して生まれる。何故、TAGIRIは「子フォルダ」という構造を無視して「全ムービー」に動画を一覧表示させるんだろう、という点だ。

TAGIRIはタグ管理に対応しており、特定タグが付加された動画を抽出表示する機能、「タグAとタグBの両方が付加された動画だけ」という形で動画を抽出表示する機能（スマートフォルダ）を搭載しているけど、いずれにしてもタグベース。フォルダ構造は無視されており、「特定フォルダと子フォルダ内の動画を全て並列に管理」「その上でタグ管理」という方式をとっている。「にゅーあきば」の記事だと見辛いんだけど、左カラムのツリーは完全タグベースなのです。

タグには、大きな欠点がある。付加しなければ付加されない、という欠点。故にタグは使えない……と言う程当サイトはWeb1.0的ではないので(!)、例えばTAGIRIに関しては以下のような「タグ活用法」を提示する。

「従って」、TAGIRIが「全ての動画」の下位（ツリーにおける）に子フォルダを配置しない（＝特定フォルダと子フォルダ内の動画を全て並列に管理している）点こそが、タグ論の危険性を如実に表している。少なくとも現在のWindowsはタグベースで動いていない。故にタグはツール間で共有されておらず、フォルダ構造は共有されている（例えば、Irvineから見てもTAGIRIから見ても、ある動画ファイルのパスは同じだ）。なら次期Windowsはタグベースで動けば良い……と言うかもしれないが、その「タグ」が付加される対象が「ファイル」であるなら、それは「フォルダ構造からの脱却」にはなっておらず、「タグという並列な選択肢の提示」でしかない。

そして、この上で、当サイトは「タグ」に未来を見る。おそらく、未来は二つある。

• 可能性A：OSはタグベースの管理を取り入れるべき
  タグは、フォルダ構造と同様に、ツール間で共有されるべき
• 可能性B：タグを扱うツールは、タグを「ファイル」のみに付加する時代から次のステップを目指すべき
  例えば動画ブラウザであるなら「この動画の1分23秒目に『これはひどい』を付加」が可能であるべき。・・・この例はあんま良くないかも

いずれにしても「タグ」は「フォルダ」を駆逐せず、並列な存在に過ぎない。ただ、「どのレイヤーで」並列であるか、だ。

YouTubeが主張したことは「Winnyに流してハッシュ貼ってファイルを拡散させるよりウェブにアップした方が早い/簡単でしょ」ということにある。例えば「スプー」でも何でもいいんだけど

1. 誰かがブツをアップする
2. 少しの人間がそれを見る
3. 見た人間が（ブログで紹介したりといった形で）紹介する
4. 多くの人間がそれを見る

この、スピード。

そもそもにおいてウェブは他の情報伝達手段・他のメディアよりも上記のスピード感において優れた情報伝達手段・メディアであり、上記のスピード感を求め続ける情報伝達手段・メディアであり、YouTubeは、従来的なアップローダーやFTPやWinnyよりも「早い」情報伝達手段・メディアであった。そして、おそらく現在最も「早い」。

そして、ウェブサービスが復興した時代における。

汎用性のあるURLリスト

汎用化されたURLリストデータ、即ちRSS。RSSが主張したことは「汎用性の高いデータは利用スタイルに無限の可能性を持つ」ということにある。この意味においてPlaggerの（ギーク層における）流行は必然であって、サイトの更新をRSSリーダーでチェックすることを覚えた人間は必然的にRSSの、他の方法による活用方法（例えばBT+RSSでもいいし、端的に言ってしまえば「出口」）を求めるし、他の方法による生成方法（即ち「入り口」）を求める。汎用化された形式を手に入れたデータは、自由な形で生成され、自由なルールによって変換され、自由な形で出力される。

特定サイト用ダウンローダーの盛り上がり

2006年において面白かったダウンローダーとは、特定サイトに特化されたツールだった。ウェブサービスが復興し、大量のファイルを抱え、リーチしやすいURL（YouTubeにおける個別動画ページ）と落とすべきURL（YouTubeにおける動画本体アドレス）との間に（ブラウジングという作業における）隔たりを作るのなら、両者を繋ぐツールが必要だった。それらは、「（いわゆるプログラミングにおける）関数」に他ならない。YouTubeダウンローダーは、Flickrダウンローダーは、「関数」だ。

ダウンロード作業の分業化

特定サイト用ダウンローダーの本質が「関数」であるが故に、作業は分業化される。特定サイト用ダウンローダーは、必ずしもダウンロード作業を行う必要がない。YouTubeダウンローダーにとって重要な作業は、YouTube動画の本体アドレス・保存ファイル名を取得することであり、ダウンロード作業自体は別のダウンローダーが行えばいい。・・・と、いう事は、補足として書いておくと、もう一つの事実も示している。特定スタイルに特化されたダウンローダーにも必要性（「Firefoxは拡張をたくさん入れないと使えないので初心者向けではない」に近しい必要性*1）があるという点。例えば、YouTube動画をダウンロードしてiPod形式に変換しiTunesに登録するiTube。

必要な物は、関数だ。YouTube個別動画ページアドレス（を含む汎用的なリスト）から動画本体アドレス（を含む汎用的なリスト）を返す関数だ。或いは、ウェブページアドレス（を含む汎用的なリスト）からページ内に埋め込まれた動画の個別動画ページアドレス（を含む汎用的なリスト）を返す関数だ。それらは世界に各一つずつ存在すれば良く、その組み合わせこそが、ウェブサービスが復興した時代の、或いはURLリストが汎用的な形式を手に入れた時代の。

• *1: 補足の補足になるけど、Firefoxにおける拡張は並列であり、ここで述べている「関数」は直列だ。この意味において両者は別物だが、共に「並列性と直列性の両方を持った存在から片方を除外した存在」である。

かつて、tokixはtokix.netの中の人だった。今、tokix.netはtokixのコンテンツ発信の場であり、今後この傾向は強まっていく。ただ、「今」は「今」だ。

……本当は「rhyme」「ムーノーローカル」とか書いた方が伝わりやすい気がしなくもないんですが、僕がどんな個人サイトのファンだったか/どういう集合の中にいる人間か、とかいう話と今回の話は微塵も関係ないのでネットの片隅の零細サイトが例でごめんなさい。

2005年11月に「ユーザーのためのweb2.0講座」という記事を書いた。まぁ、抽象的というか電波な記事なんだけど、基本的な部分での方向性は間違っていなかったと思うので引用しておく。

コンテンツとは、一人一人のユーザーが行う「発言」と言い換えられるだろう。

この言い換えも「Web*」の「*」によって進化するものであり、例えばWeb1.0においては「ウェブサイト（ウェブページ）」であったし、（ハイパーリンクとトラックバックで関連性を持ち合う）blogにおいては「ウェブページ（記事）」であるのだが、究極的には、web2.0の世界においては「発言」と言い換えられるだろう。

ユーザーのためのweb2.0講座

この問題故に、ブログRSSの全文配信は、現在〜近未来において必ずしも望ましいことではない。

ブラウザお気に入りに登録される個人サイトの数は減少している。このことだけを取っても「サイト管理人たるものは毎日自分のサイトを更新しなければならない」という傾向（つまり、まぁ、ムーノーローカル〜九十九式の時代の時代性/を生んだもの、とでも）は縮小しており、しかし、まだ残っている。原因は三つ。

• ブラウザお気に入り内に個人サイトは残っているから
• 「RSSリーダーに登録される」と言い換えれば、おそらく総数（ブラウザブックマーク＋RSSリーダー）には大きな変化が見られず、「更新が頻繁でないブログはユーザーのRSSリーダーから削除される」から
• というかそもそも「αClipperClipsははてブより面白い」で書いたような「スマートサーチ」が全く発達していないので、好きなサイトのHTML/RSSをチェックするのは、「そのサイトの、自分が読みたい新着記事」を読み逃さないためにほぼ必須だから

ただ、それでも、現在が「途上に向かう途上」であるとしても、「サイト名」という情報の重要度は下がっている。文字通り、それは「ウェブサイト」に付けられた名前だからだ。（はてブ経由などで）月に一度以上アクセスし続けているサイトのサイト名が実はうろ覚えだったり……という時代は、既に一部の人間の間では始まっているはずなんだ。

インターネット中の何処かで行われる「発言」の関連性のみが「特定CDの評価」や「また大阪かで1000を目指す」や「映画DVDISOハッシュ一覧」や「Web2.0とは何なのか」などを作り上げるが、その前提は、全てのコンテンツがそれぞれユニークなIDを所有し、関連性を持ち合うことだ。

ユーザーのためのweb2.0講座

「コンテンツ」の単位は「ウェブサイト」から「ウェブページ」にシフトしており、この意味において、かつて、tokixはtokix.netの中の人だったが、今、tokix.netはtokixのコンテンツ発信の場であり、今後この傾向は強まっていく。ユニークなIDを付加可能なコンテンツは全て並列に「コンテンツ」であり、Twitterはこの意味で「惜しかった」。

貴方がネットに発信する、ユニークなIDを有するコンテンツは、全て並列だ。……具体的に書こうか、今の状況なら、それはおそらく「Googleウェブ検索に引っかかるんだから」という意味だ。この意味において、俺はいわゆる旧型の掲示板（スレッド単位のURLすら持っていない）での「初心者です○○というツールの使い方が分かりません助けてください」に貴重な時間を割いて答えている人の労働が勿体なくて仕方ない。そんな時間があったら「はてな人力検索」「教えてGoo」に書き込んで欲しいと常日頃願っている。そこに貴方が書き込んだ文章は、「コンテンツ」「ネットの資産」を形成するのだから。

即ち、Twitterは、Google検索に引っかからないメッセンジャー上での会話を、「コンテンツ」とする手段だ。……という部分に僕は本質的に魅力を感じられなかった*1が、これは、ちょっとした設計の違いで「頭の中を流れたフレーズを〜」になり得た。

だから、Tumblrは、ある程度面白い。そして、それらに書き込まれる「コンテンツ」と、その人が個人運営しているブログで公開される「コンテンツ」は並列だ。並列に、その人間*2が発信したコンテンツだ。

「ブログの全文配信はWeb2.0」とかいう文章に疑問を感じていない人には、たぶん共通して一つの観点が欠けている。この先、暫定的に訪れるのは、おそらく「ウェブサイトをRSSリーダーに登録しなくなった」「RSSリーダーで一サイトの記事見出しを羅列表示させることがなくなった」という時代である、という観点。

「RSS」というものは

• 発信者である自分の情報
• ウェブページのタイトル
• ウェブページのURL
• ウェブページの概要

を羅列したファイルに過ぎない。それは究極的に言えば日記ともblogとも（一応ここでは『blog≠日記』という書き方をする）個人運営サイトともニュースサイトとも関係がない。

RSSとはURLリストである

RSSはURLリストであり、「Rich Site Summary」という言葉を無視して言えば、「一サイトの記事内容を羅列するRSSなんて『材料』に過ぎない」。従って、はてブは一サイトより面白いし、αClipperClipsははてブより面白い。URLリストたるRSSを取得した上で、各記事を「あるサイトに従属する要素」と見なしているBloglinesは、この意味において「現代的」であるに過ぎず。

……長くなってきたが、ここまでに同意して貰えたなら、結論は自然と出る、はずだ。

「RSSを全文配信するか否かで変わるのはアクセス数/それに付随する広告収入」という前提は、間違っている。

Web2.0への途上である現在〜近未来において（「究極の像とは」といった話はこの記事では外す）、RSSを全文配信するか否かで変わるのは、「それが誰のコンテンツか」という、実際的な効力を持つ「記名」だ。近未来的に、僕は様々なサイトの名称や各管理人名を知らなくなる可能性がある。誰の物とも分からない「はてブ人気記事の全文RSS」を読んでいても。……「それで構わない」「それが良い」という「コンテンツ」（はてな匿名ダイアリーはそれを目指している、はず）でないなら、全文RSSの配信には慎重であるべきだ。全文RSSが過去と未来を繋ぐ線の上/或いは線上から少し外れた場所にあること自体を疑わなくても、だ。

だって、Web2.0への途上である現在〜近未来において、ブログのHTML/CSSは、Twitterの似顔絵アイコンは、「発信者」という、実際的な効力を持つ記名情報なんだから*3。

……ここを突き進めていくと、あれだけ昔にfavicon.icoを独自仕様で組み込んだIEはとても未来を見ていた、のかもしれなくもない。

• *1: 「んなもん価値のあるコンテンツか？」「それこそ『ブログすら』実名で始めようとしている人がいる時に言われても……」とかいう問題
• *2: 一応書いておくが、別にリアルの一人がネットの二人三人でも逆でも全く構わない、という類の「人間」。
• *3: 凄い蛇足だけど、故にいわゆる「リニュしました★」みたいな姿勢は、この意味でもWeb1.0的だ。「それでも自分が自分として認識されている」というのは、（「ウェブページ」でなく）ウェブサイトが「コンテンツ」であった時代の話でしかない。

自分で作る時間は無さそうなので、この記事が合っていた場合（後述するが法的問題が絡んでくるので100%の自信がない、間違っていたらツッコミ希望）ご自由に作って頂いて構いません。ていうか作っていただければ「おおおー」と思います(？)。

mixi上の日記が、本当に公開されていたことを証明する。即ち、いわゆる炎上時に記事削除や公開範囲変更、アカウント削除で「逃れる」ことを防ぐ。と、いうメカニズムの提案。

「教えて君.net」の記事で書いたんだけど

「この記事はいずれ削除/変更されるに違いない」と思ったら、まずIE/Firefoxツールバーとして公開されている「存在証明サービス」ツールを使ってウェブページを保存する。しかし、このままでは、後から保存データを提示し「このページを公開していただろ！」と問い詰めても、「そんなページは公開していない/（記事ページを保存した）お前が勝手に改ざんしたんだろ？」と言い逃れされてしまう。「Webページの存在証明」が凄いのは、ウェブページの保存と同時にタイムスタンプを生成している点。後で検証用ツールを使うと、そのタイムスタンプが正しいか、ウェブページデータが保存後に改ざんされていないかをチェックすることができる。タイムスタンプが正しく、改ざんの痕跡がなければ、そのページデータは間違いなく当該日時に当該URLで公開されていたものだ。記事の削除/変更で「なかったこと」にされるのを防ぐことができるぞ。

記事削除で逃げさせない「Webページの存在証明」

この方法論（だけ）では、mixiの存在証明を生成することはできない。実際、この「Webページの存在証明」は、mixiなどの会員制サイトには対応していない。

ちょっと基本的な部分というか前提から話を始めるので、ある程度知識がある人は次のhrまで飛ばして下さい。

ウェブページの存在証明（キャッシュ/魚拓）を生成するには、二つの方法論がある。

• 一般ユーザーの自分自身のマシンにデータ取得を行わせる
• 信頼できるマシン（例えば「Webページの存在証明」サーバー）にデータ取得を行わせる

mixiなど会員制サイトのキャッシュを取る場合に関して言うと

• mixiユーザーであるユーザー自身にデータ取得を行わせる
• サーバー側でmixiアカウントを持っておいて、そのユーザーにデータ取得を行わせる

の、二択な訳だ。そして、これらは両方共に問題を持っている。

まず、分かりやすいのが後者。

先にはっきり言っておくと、mixiの会員規約はあくまでmixiの会員規約であり、それを破ることは「mixiから見た悪」でしかない。これは、まぁ、例えばMMOにおけるRMTのポジションを考えればいい。運営側がそれを禁止したところで、それは例えば「アカウント削除しますよ」の意味でしかない（従って、この記事で書くメカニズムは「mixiの会員規約に反しない」を命題とはしない）。しかし、「mixi日記を取得する」という場合は、少しまずい。不正アクセスになる可能性があるからだ。

mixiの日記、例えば僕の日記は、全てのmixiユーザーに公開されている。しかし、非mixiユーザーには公開されていない。非mixi ユーザーが「僕の日記」の取得を、サーバーなど第三者経由で行った場合、それは「自分が閲覧する権限のないウェブページの取得」となる。この法的解釈は結構微妙だし争えば勝てるかもしれないが、少なくとも、争う覚悟が必要になる。

次に、前者。

これは即ち「ブラウザで今表示しているデータをそのまま保存する」ということなんだけど、これでは「そのページが本当に当該URLとして公開されている」ということを証明できない。例えば「hostsファイル」というキーワードで理解してくれれば話が早いんだけど、ブラウザを騙す、即ち、本来のウェブページと異なるウェブページを「そのURLのページ」とブラウザに思いこませることは可能なんだ。そのようにしてブラウザを騙せば、例えば他人のmixi日記を偽造し、それを「当該URLにおいて公開されていたmixi日記である」と偽ることができてしまう。故に、この方法では「保証」を行うことができない。

と、いうことで、つまり会員制サイト内ウェブページの存在証明には

• 一般ユーザーの自分自身のマシンにデータ取得を行わせる
• 信頼できるマシン（例えば「Webページの存在証明」サーバー）にデータ取得を行わせる

の、二つの方法論がある訳だ。それぞれ単体では問題があるが、これを組み合わせれば、話は変わってくる。以下の動作だ。

1. 上記「Webページの存在証明」のようにローカルアプリケーションを用い、「今ユーザーが表示しているウェブページ」を取得する
2. 同時にサーバーに対してリクエストを行う。サーバーは、リクエストを受けて、作っておいたmixiアカウントで当該URL（mixi日記）の取得を行う
3. ユーザーのローカルアプリケーションは、1で取得されたデータをサーバーに対して送信する
4. サーバーは、送信されたデータと、2で取得したデータとの同一性をチェックする
5. 同一であれば「当該時刻に当該URLで公開されていたデータ」として存在証明発行を行う。上記「Webページの存在証明」と同様にページデータをタイムスタンプ付きでクライアントに渡す

この方法であれば、上記の二つの問題点を解決することができる。ブラウザを騙して偽mixi日記の存在証明を行おうとしても、そのデータはサーバーが取得したデータと同一でないため弾かれるし、非mixiユーザーは存在証明発行を行うことができなくなる。非mixiユーザーが（例えば第三者から受け取ったデータなどを使って）存在証明発行を行う可能性があるとしても、その責任をサービス提供側からユーザー側に投げることができる。あと、Proxomitronを使った広告削除などを行っていると、「同一」でなくなるために存在証明発行ができなくなる訳だけど、それは「Proxomitron切れよ」という話だ。

……という提案なんですが、間違ってたらツッコミ宜しくお願いいたします。

違う、そこにあるのは主従関係だ。

例えば、CDをPCで取り込んでポータブルプレイヤーに転送するという、iPodも「契機」の一つだっただろう。

携帯電話は、iPodと同様に「携帯端末」であり、独立したガジェットではない。故に僕はもう結構前から、Outlookとのスケジュール同期を「携帯電話に求める最低限の機能」としている。自宅でOutlook（なりOutlookと同期可能なGoogleカレンダーなり）を弄ってスケジュールを組み、携帯に転送して持ち歩き、出先で追加/変更される予定はその都度携帯に入力しておく（追加/変更は帰宅後の同期時にPC側にも反映される）、という使い方だ。

この方向性は、実はこれ自体、一般的に言われている「ウェブの未来」とは少し異なっている。単純化して言えば、この方向性は必ずしも携帯端末のネット接続機能を求めないからだ。

※参考

touch「マップ」を外出先で使うGMDL＋Maps Offline

safaribm2stdoutとwgetでMobile Safariのブックマークを巡回してダウンロード

……もちろん、それにしたってネット接続機能はあった方が良い（上記のマップネタにしたって「検索はネット接続下でしか行えない」）ので「非常に乱暴な言い方をすれば」という話だけど、我々が大なり小なり（例えばそれこそ「iPod nanoを買った時点で」）PC/ガジェット間で主従関係を構築しているという、そのことを確認しておく。

そして、あらゆる主従関係は、それが唯一であるか否かを疑われなくてはならない。

「携帯電話世代」とステレオタイプに言ったとき、それは必ずしも、例えば「Winny/YouTube/ニコニコ動画から完全に隔絶された世代」を意味していない。現在形として彼らが隔絶されているならば、その主原因は経済面や年齢だ。「携帯電話世代」……この手の「世代」というキーワードは本質的にアレなんだが、この記事ではステレオタイプに従うので深く気にしないで下さい……が我々と違う集合であるならば、最も重要な「違い」は、彼らが携帯電話を「主」としている/としか今後もしないという点にある。

かつて、携帯電話とPCは完全に分離していた。それでもどうにかEメール受信機能が付いた携帯電話を手に入れた僕が最初に挑戦したことは、「プロバイダーメールを転送させる」だった。無料な癖にフィルタ/転送機能が完備されたGMailなど無く、というかプロバイダーのメールサービスでも、転送機能は「有料オプションとして用意されていればマシ」だった（僕のプロバイダーにはそのサービスすらなかった）。……と、まぁそんな懐古はどうでも良いんだが、あの時代、携帯電話はPCから完全に独立した、文字通り「携帯できる電話」で、だから僕らPCユーザーはそれを「電話」として、つまり「携帯端末」としてではなく、使っていたんだ。

「携帯電話世代」にとっての現在のPCは、あの頃の僕らにとっての携帯電話に過ぎない。「学校のレポートを書くために仕方なく起動するもの」に過ぎない。「PCを主とし、携帯電話などの端末を従とする」というスタイルに向けられたツール/ウェブサービス/ハードウェアは多数登場し、僕らはそれらを使うことができる。けれど。

我々は、PCというガジェットの便利さ、素晴らしさを彼らに「啓蒙」しようとしてきた。しかしそれは、「持ち運べない携帯電話の賢い使い方」であったか？ただ我々は、彼らの根底を、崩そうとしてきた（「携帯電話は持ち運べるPCに過ぎない」）だけではないか？

例えば、そう、大人な君が「PCと携帯電話は使い分けだよ（＝であるべきだよ）」と言う、その台詞は、だ。

PCは、「従」としてはどのように利用されうる/利用されるべきか。言い換えれば、PCと携帯電話は「二種類の主従関係」の中でいかなる役割を果たし合うのか。我々が真に「提案」すべきは、そういうことなのではないか？

我々の世代が、いずれこの世界において彼らに「食われる」ならば、その原因は「携帯電話がPCを駆逐すること」ではなく、「携帯電話に対する従としてのPCを提案できないこと」になるだろう。おそらく、いずれ彼らはそういうものを作り始める。それが、この世界における、我々の「世代」が「食われた」領域となるだろう。

……まぁはっきりいって、ここにおいて素晴らしい提案をできるならベンチャーを作るし、そもそも個人サイトで普通に垂れ流したりなんか絶対しないけど（ぉぃ）、抽象的すぎる気がするので「悪い例」を一つ出しておく。

携帯電話（WM携帯とかムダに重い端末の話はしていない）は無線LAN接続機能を搭載するべきだ。その時俺は、「お父さんのパソコンを騙して借りてP2Pプロクシ＋Proxomitron＋携帯用フィルタ群あたりを入れてスパイウェアチックに静かに常駐させるテク」を紹介するだろう。フィルタをぶっつぶせ。