Tagging、Folksonomy というコンテクスト

tag がずいぶんと浸透してきた。自分のブログの記事や flickr の写真を整理するため、検索できるようにするために、ユーザが自発的にそれらにラベル付けをする行為。それが tagging。自分のコンテンツでなくても、ニュース記事や動画に思いついたラベル付けをするスタイルの tagging もある（こちらを前例と区別して「social tagging」と言う）。この tag や tagging という行為について少し考えてみよう。

動画や写真など、現在のテキスト中心の検索技術では検索しにくいファイルには、tag は非常に有効な検索支援になる。先般閉店となってしまった大勝軒で食べた「つけ麺」の写真を写真共有サイトに投稿するときだったら、「大勝軒」、「つけ麺」、「池袋」などの tag を付与するなんてこともあるだろう。この tag が付与されているおかげで、「池袋」の「大勝軒」で食べた最後の「つけ麺」を撮影した「img128.jpg」※といった無味乾燥なファイル名の画像が「池袋」や「大勝軒」、「つけ麺」という文字列で検索可能になる。これらの tag がなければ、flickr にアップされた無数の写真の中から大勝軒のつけ麺の写真を探すなんてことは、ほぼ不可能に近い。

この写真の場合、「鹿島鉄道」、「八木蒔駅（やきまき）」、「キハ602」、「キハ714」といった tag が付与されている。被写体に関する付帯情報が tag となっている。

• 「鹿島鉄道」という運営会社の名称
• 撮影が行われた「八木蒔駅（やきまき）」という場所に関する情報
• 「キハ602」、「キハ714」という型式と車輌番号

これらの情報は本来、

　鹿島鉄道
　　├（が所有する）八木蒔駅
　　├（が所有する）キハ602
　　└（が所有する）キハ714

という情報のヒエラルキーがあるのだが、これが flickr のタグとしてはフラットな状態で存在する。個々の tag の間には、（tag を付与したユーザ自身には何らかの意図があるにしても）何の関連性も意味付けも与えられていない。投稿者以外のユーザにとっては、投稿された画像と何らかの関連性が関連性があるのだろうという想像するしかない。性善説に基づいた信憑性（まったく関連性のない tag はつけないだろう……という思い）に依存することになる。

ミクロに見ればそういうことなんだけど、マクロに見ると状況はもっとおもしろい。例えば、Flickr の場合、投稿された画像の横に tag が表示されている。それをクリックすると、同じ tag でラベル付けされた他のユーザから投稿された画像を閲覧することができる。

• tag = signifiant
• 画像 = signifié

……という関係で言えば、signifiant と signifié が、1 対 N の関係となって見えてくる。つまり、同じ tag を有しながら、まったく違う signifié を指示している場合。「red」という tag であっても、写真は「リンゴ」だったり、「バラ」だったり……。その逆（N 対 1）があるのは、先に示したとおり。投稿者自身がいくつもの tag（signifiant）を、同一の写真（signifié）に付与するケース。投稿者自身がそうなのだから、同じようなものを撮影したとしても別の投稿者だと違った tag を付与するということがあっても何の不思議もない。こうして signifiant と signifié の関係は、N 対 N の関係となり、無限の意味的リンクを創造する……というのが、tag の面白さなんだろう。

tag を語る上で、重要なコンセプトに folksonomy というものがある。簡単に説明すれば、ユーザによる分類……ということにでもなろうか。Yahoo! のディレクトリサービスへの登録作業がサーファーと呼ばれる職種の人たちによって分類され、適切なディレクトリに格納される……という例をひくまでもなく、専門家による分類はさまざまな分野でおこなわれてきた。図書館の蔵書の仕分けもそうだし、生物学上の分類もそう。権威者（オーソリティ）による分類が taxonomy であるのに対して、folksonomy の世界ではユーザにその分類の自由が与えられている。ロボット型検索エンジンによる画一的な視点ではなく、人の目を通した分類に回帰してきている現象のひとつとも考えられる。

……と書いたところで、あえてアンチテーゼ。ロボット型検索エンジンもあれでいて folksonomy な要素も持っている。検索エンジンについての解説を思いだしてもらいたい。「18歳未満」を検索文字列にした場合の検索結果。つまり、「18歳未満」（アンカーテキスト）が Yahoo! JAPAN や Disney の tag となっている……とも考えられる。作者が書き連ねたテキストが形態素解析されて、そこに含まれる内容語のひとつひとつが tag として扱われている。さらに、H1 などの HTML タグでマークアップされていれば、より重要な tag と解釈される……などと読み替えることも可能だろう。そう考えていくと、social bookmark で何人のユーザが登録してるか……という指標も、PageRank と似たようなコンセプト（どれぐらいの被リンクという指示を受けているか）と言える。

最近は少なくなったみたいだけど、Yahoo! オークションの出品者が自分の出品した商品がより多くのユーザの目に触れるように、その商品にあまり関係ないキーワードを説明文に埋め込む……というテク ニックがかなり目についた時期があった。例えば、Leica のカメラを探しているユーザが、「Leica」で検索するという場合。検索結果には、もちろん Leica も含まれるが、Leica でないクラシックカメラも含まれていたりする（いまチェックしたら、Rollei 35 がひっかかってきた）。出品者の思いとしては、「Leica に興味のある人は、きっと Rollei にも興味があるだろう」といったところだろう（どちらもドイツの高級カメラメーカー）。その商品がなぜ検索にひっかかってきたのかを見てみると、 「◆Rollei 35T ローライ Tessar40/3,5 LEICAMINOXZEISS◆」という商品名のつけ方に起因することがわかった。前半部分は、その商品そのものなんだけど、後半部分 「LEICAMINOXZEISS」が原因。これは、カメラ好きならすぐにわかるんだけど、「Leica」、「Minox」（小型カメラのメーカー）、 「Zeiss」（ドイツの有名なレンズメーカー）をくっつけて書いたもの。これも出品者の tagging であることは言うまでもないだろう。あまりにも無関係な tag（例えば、「Leica」で検索したのに「綾波レイのフィギュア」なんてのが検索結果に上がってくるとか……さすがにないか）が横行すると、検索機 能がその機能を果たせなくなり、サービスレベルの低下につながってしまうが、この程度の tag であれば、全然許容範囲。

こう考えていくと、tagging、folksonomy の面白さって、ユーザにその自由が与えられていることに尽きるのかもしれない。そうした自由の中から見いだされる関連性と意外性。大量の signifiant と signifié を処理することで、何らかの特性みたいなものが浮かび上がってくるんじゃないのかな。

※無作為に「img128.jpg」というファイル名をサンプルにしてみたけど、意外にも自分の写真にも「img128.jpg」というファイル名の写真をアップしてたことに気づいた。。。さすがに「つけ麺」じゃないけど。

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

「検索エンジン」という言葉が、一般的に広く用いられるようになってひさしい。Yahoo! や Google が提供しているウェブ検索サービスのことを指示する場合がとても多い。別にそれだけが検索エンジンってわけじゃないけど、まあ代表格のようなものだから、これはこれでよしとする（きょうのところは）。「検索エンジンに登録されたら、うちのサイトも PV が上がっちゃって」……なんていうアレ。きょうはこのあたりについて簡単に説明しておこう（いろいろ書くにあたって、そろそろ簡単にでも説明しておかないと都合が悪くなってきた。。。）。

ウェブ検索のユーザに支配できる部分はごく一部に限られている。

• キーワードを入力する
• 検索ボタンをクリックする
• 検索結果が表示される
• ページタイトルや URL、ページコンテンツの抜粋を閲覧できる
• ページタイトルや URL をクリックすると、そのサイトを閲覧できる
  

これを実現するためにどんなことが裏側でおこなわれているか……という話。ごく簡単に書くと、こんな感じ。

1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく
2. 採取されたページコンテンツは、URL を基準に整理され、分析される
3. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス（索引）化される（形態素解析しない場合もある）
4. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する
5. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される

ざっくりとした説明なので抽象的なところも残っている。もう少し詳しく見ていこう。

1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく

クローラの業務内容は比較的シンプルなイメージで説明できる。

• ウェブページを開く
• そのページを保存する
• そのウェブページに書かれているリンクをたどって、別のページに行く

の繰り返し。どこから見ていくかということなんだけど、その元になるのが「台帳」。この「台帳」のことを「Seed」（種）と言う。イメージとしては、巨大なブックマークリスト……が近いだろうか。これを見ながら、次から次へとページを渡り歩いて、ページコンテンツ採取をコツコツとこなしていく。そうしてデータが集まってくると、

2. 採取されたページコンテンツは、URL を基準に整理され、分析される

このページとあのページがリンクされているとか、外部のサイトにリンクしているとか、このページは他のページからどれぐらいリンクされているか（被リンク）……といったリンク構造や、ページの作成日（更新日）などの分析がおこなわれる（Google の有名な Page Rank の基礎データもここで取得できるものなんじゃないかな）。次に、

3. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス（索引）化される

どんな形態素解析処理（Cf. 「コンテンツ連動型広告の仕掛けを考える〜その弐」）をおこなっているのかは、検索結果ページからちょこっと見られたりする。Yahoo! JAPAN の場合だと、検索結果に「キャッシュ」っていう地味なリンクがあったりする（必ずあるわけじゃない）。そこを開いたときに、ページ上部にボックスが表示されて、そこに自分の入力したキーワードに何色かの背景色が付いて表示されているのを見たことがあるんじゃないかな（本記事の画像をクリックするとサンプルが見られる）。ユーザとしては、それを元に検索結果ページのどこにその文字列がどこに記述されているかが、背景色でハイライトされているので、見つけやすい……と言った用途に使うもの。実は、コレが形態素解析の結果。たとえば、「現代用語の基礎知識」だと、

• 現代
• 用語
• の
• 基礎
• 知識

……と分解される。採取されたページコンテンツ（テキスト）は、こんな風にバラバラに解体されて、ウェブ検索のインデックス（索引）データとして利用されているわけだ。つまり、「現代用語の基礎知識」という検索文字列で検索した場合には、「現代」「用語」「の」「基礎」「知識」が含まれているページが検索されることになる。たまに「インデックスがアップデートされた！」というニュースが出たりする（SEO 業界を中心にちょっとした騒ぎになることもしばしば）けど、このインデックスの更新が意味するところは、ここで紹介したような内容（同時に新規ページのインデックスへの追加やなくなってしまったページのインデックスからの削除もおこなわれる）。

こうして索引ができて検索可能になった段階で、

4. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する

……ことになる。ココの部分が、狭義としての「検索エンジン」ってことになるんだろう。抽出すればそれでオシマイと言うわけではないのが難しいところ。いかにして、ユーザが探したいものを最短の時間、最小の労力で提供するかというのがサービスとしての検索の要となる。

5. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される

……が重要となるわけだ。やはり単純にサービスを使う立場としては、いち早くお目当ての結果にたどりつきたい。「検索結果は、Google がいいね」とか「いや、Yahoo! も最近はかなりいいよ」とかそういう文脈で語られる良し悪しの多くは、ここの結果のアウトプットに起因する。大量の検索語でひとつひとつの検索結果を各社のサービスで調べて、一定のルールでそれらを評価すると、それなりの結論は出るようにも思うけど、ユーザの主観やそのときのユーザの意図によって印象は変わってきてしまうものではある。また、同じ会社のサービスであっても時期によって、チューニングが異なっていたりするので、一概にどこのサービスがいいというのは難しい。じゃあ、何をベースにチューニングするかということなんだけど、メジャーなものとしてはこんなものがある（個人的におもしろいなと思う順番に）。

• どんなキーワードでそのページがリンクされているか
  有名な例としては、「18歳未満」で検索すると、Yahoo! JAPAN のトップページが上位にランクされる……というヤツ。アダルトサイトとかで「18歳未満はこちら」というテキストリンクが、Yahoo! JAPAN などに誘導するというケースが多い）
• 検索キーワードの近接性
  「中華料理」での検索だったら、そのままズバリの「中華料理」と書かれているページの方が、ページのどこかに「中華」とか「料理」とかバラバラに記述されているものよりも関連度が高いだろうという考え
• そのページがどれだけのページからリンクが張られているか
• そのページがどれだけ人気のあるページからリンクが張られているか
  SEO 業者が「まずはYahoo! JAPAN のディレクトリ登録を」とオススメしてくる根拠
  
• 検索キーワードのそのページでの扱われ方
  SEO のテクニックでよく言われる「H1 タグで囲まれていると評価が高い」……とか言うアレ

……などなど。どの要素をどれだけ重視するかというのがチューニング。SEO 業者は、その特徴を帰納法的に類推し、試行錯誤する。ランク上位表示を目指して、荒技（リンクファーム：Link Popularity を上げるためだけの意味のないリンクの張り合い）なんかで検索結果を荒らす者もいる。検索エンジン側でそうした行為を無にするような新たなチューニングを投入する……イタチごっこ。SEO 業者の日々の糧はそこにある。

コンテンツ連動型広告の仕掛けについて考える〜その弐

「コンテンツ連動型広告の仕掛けについて考える」の第二弾。前回は、ページに書かれた内容（ページコンテンツ）の取得まで。今回は、その解析部分から。（第一弾は、こちら）

前回の処理のステップをまとめたもので言えば、

4. クローラが取得したコンテンツは、解析サーバにより解析される

ここから。ページコンテンツを取得したら、そこからそのテキストが扱っているトピックを抽出しなくてはいけないわけだけれど、まずは、形態素解析という処理が必要になる。形態素解析というのは、簡単に言えば文章の構成要素を細切れにする作業。分かち書き。例えば、「うどんは讃岐に限る」という文章は、

• うどん
• は
• 讃岐
• に
• 限る

と分解できる。この分解のときに、

• うどん（名詞）
• は（助詞）
• 讃岐（名詞）
• に（助詞）
• 限る（動詞）

こんな感じで、品詞分類（上記の例はかなり雑に分類してるけど、ホントはもっと詳しい）もついてくる。名詞や動詞、形容詞なんかは、大分類では内容語とカテゴライズされて、助詞なんかは機能語とされる。重要なコンセプトの抽出に助詞などは、さほどの影響は及ぼさないだろうということで、捨てちゃう。そうなると、

• うどん
• 讃岐
• 限る

が残る。これだけでも原文のコンセプトは十分判断できるよね。その中からさらにコンセプトを含む確率が高いものということで、名詞を取り出す。

• うどん
• 讃岐
  

ずいぶんとすっきりした。「讃岐うどんはまずい」という文章だってあるじゃないか……という意見もあるだろうけど（ネガティブイメージな文章に広告を出すのかという議論もちょっと脇に置いておいて）、

• 讃岐
• うどん
• まずい
  

なので、テーマが「讃岐うどん」であることには変わりない。シンプルな文章を例に出したので、あっさりとしてしまったけど、本当はその文章の周囲には、

• 先月の出張で、香川に行った。
• 香川の取引先の山田部長はなかなかの人格者で、彼を慕う部下も多いと聞く。
• 彼のチームメンバーからいろいろお話を聞くことができた。
  
• 山田部長の若いころのエピソードで面白かったのは、食い道楽の話。
• あんなスリムな人なのにありえないぐらい食べるらしい。
• なんでも近くのうどん屋でうどん七玉食べた後、もう一軒別のところに行ってそこで三玉。
• ありえない。。。
• しかし、山田部長のオススメのうどん屋さん、マジうまいっす。
• やっぱり、うどんは讃岐に限る。
  

……などという文脈があるとすると、もう大変。名詞の量がずいぶん多い。そうしたときに使える手法とオーソドックスなのは、特定のキーワードの出現頻度を利用するという手法。文章を通して、何回「山田部長」や「うどん」が登場したか……ということ。「うどん」、「うどん」と何回も言ってるぐらいだから、「うどん」は重要なキーワードなんだろう……という推測。ただ、これだけでは重要なテーマは、絞りきれない。

さっきの文章では「山田部長」だけがフィーチャーされていたけど、「山田部長はじめ、高橋部長、佐藤部長には大変お世話になりました。 m(_ _)m」という文章も入ってくると、重要なのは形態素解析の結果としての最小単位で最頻出語は「部長」になってしまう。「うどん」か「部長」かで考えると難しいのだが、少なくとも「部長」の中でいちばん重要なのは、「山田部長」だろう。「山田」＋「部長」。このように単語と単語の組み合わせ（連接）に着目して開発されたのが、専門用語自動抽出サービス「言選Web」。ブラウザから簡単に使えるので、ちょっと試してみる（より重要だと判断されたキーワードが上になるように並んでいる。横の数値は、その評価値。何点満点とかいう尺度ではない）と……

• 9.73　：　山田部長
• 3.46　：　うどん屋
• 3.46　：　うどん
• 2.00　：　香川
• 2.00　：　m
• 1.93　：　高橋部長
• 1.93　：　佐藤部長
• 1.41　：　人格者
• 1.41　：　大変お世話
• 1.41　：　取引先

お、「山田部長」がフィーチャーされてますね。「高橋部長」や「佐藤部長」に圧倒的なリード。こういう複合語に着目するってのもなかなかいい手法。

この「言選Web」については、『図書館の窓』東京大学付属図書館報に寄稿された「「言選Web」の世界」という記事でとてもわかりやすく説明されているので、興味のある人はどうぞ。

『たつをの ChangeLog』の「形態素解析と検索APIとTF-IDFでキーワード抽出」という記事もおもしろい。数式とか、Perl のコードとか出てくるんで、ちょっととっつきにくいかもしれないけど、文章はいたって平易。いわく、Yahoo! のウェブ検索を利用して、

• 文章（さっきの「うどん」の日記のようなもの）の中に特定のキーワード（例えば「うどん」）が出現する回数
  
• Yahoo! のウェブ検索でキーワードにマッチした文書数
• Yahoo! のウェブ検索の総文書数
  

これらの数値をぐにぐにっと計算すると、特徴となる語彙が抽出できる……というもの。ここにはデモインターフェイスが置いてないのが残念。。。前に動いているところを見たことあるけど、かなりおもしろい♪

他にもいろいろ手法はあるんだけど、基礎的なところとしては、こんなところだろうか。

こうして、文章の特徴となる言葉が抽出されて、じゃあ次は……ということになると、

7. 商品引き当てサーバは、解析結果に基づき、妥当な商品を商品データベースから検索し、オススメ商品データを返す

……というのが大きな山になりそう。

• 抽出されたキーワードで商品データベースを検索する
• 検索結果が複数ある場合、その中でいちばん売れそうなものから順に表示候補にする

この「売れそうなもの」っていうのがクセモノ。

• 文書との関連度が高いから「売れそう」
• 文書との関連度は若干低いけど、けっこう売れてるから「売れそう」
• 文書との関連度は全くないけど、むちゃくちゃ売れてるから「売れそう」

おおざっぱに言えば、こんな感じなんだろうか。

「おまかせリンク」は、まだβ版だからなのか、関連性の低い結果が出ちゃってるのかどうかが微妙なところ。ちょっと前に書いた「心地よいユーザインターフェイス」に出てくるのは、『女性の品格』とか『不思議の国のアリス』の洋書、英文法の教科書（洋書）、プロジェクトマネジメントの本（洋書）、『のだめカンタービレ（18）』……。Ajax の本とか、インターフェイスデザインの本とかいろいろあるだろうに……。少なくとも『女性の品格』、『のだめカンタービレ』は売れせん狙いのフィラー広告だな。『わかりやすい洋ランの育て方』……大泉洋の「洋」ってことかい？　それだったらまだ大泉洋の本の方がいいな。……とはいえ、なんかこうやって文句を書いている間に、『Web API マッシュアップブック』も Pipes の記事あたりで表示されるようになってきた。

とはいえ、AMAZON のコンテンツ連動型広告の場合は、

• 書籍に付随するメタ情報（著者名や出版社名、書籍の概要）
• 関連づけの対象となる商材が有限であること（バリエーションが多いとはいえ限られている）
• 商品ごとの売り上げ情報（売り上げランキング）
• その商品といっしょに買われた商品
  
• 検索から購買までのコンバージョン情報
• カスタマーレビュー情報
• リストマニア！（個人のオススメ作品リスト）
  

……などなどパラメータとして利用できそうな付帯情報がもりだくさん。今後の展開にかなり期待♪

コンテンツ連動型広告の仕掛けについて考える〜その壱

以前 Blogger に自分のブログをホスティングしていたんだけど（Blogger が Google に買収されたちょっと後）、しばらくぶりに使ってみると、けっこういろんなところがバージョンアップされてる。AdSense の導入なんかもとても簡単になってるし、Google アカウントともちゃんと連動している。管理画面なんかの日本語化もずいぶん進んできた。意外に快適。

ついでに Amazon Affiliate Program も導入しちゃおうと思って、Amazon に行ってみたら知らない間に「Amazon おまかせリンク」なんていうプログラムが1年弱前にリリースされていたのを知った（遅…）。面白そうなので、さっそく導入してみた。これは、Amazon 版の AdSense といったところのプログラム。ブログの記事の内容に合致した Amazon の取り扱い商品を成功報酬型の広告として配信するというもの。さっそく導入してみる。最初はブログと何の関係もないものが表示されていたけど、しばらくリロードしているうちに、『鈴井貴之編集長 大泉洋』が表示された。Pipes の記事を書いたときに「大泉洋」をサンプルクエリにしたので、それに連動してピックアップされたんだろう（スクリーンショットを見ればわかるけど、ブログ記事の本文に何回も「大泉洋」というキーワードが出現している）。

「コンテンツ連動型広告は、記事中のテキストを解析して、その内容にマッチした広告を掲出する」とさらりと解説されていることが多いけど、もうちょっと詳しくコンテンツ連動型広告の仕掛けについて考えてみよう。Amazon のヘルプページや drk7.jp の Amazon Search のページあたりを参考に想像を交えながら。

導入から広告配信までの作業の流れを追ってみよう。

1. Amazon Affiliate Program に参加（アソシエイト ID が発行される）
2. 配信したい広告を指定（広告の形態や表示商品の指定など）して、広告配信用のスクリプト（JavaScript）を入手する
3. スクリプトを自分のサイトに埋め込む（ページの HTML に 2 のスクリプトのコードをコピー＆ペーストする）
4. 最初は、コンテンツに連動していない商品情報が配信される
5. しばらくすると、コンテンツに連動した商品情報が配信されるようになる

大雑把に言えばこんなところだろう。すこし細かく見ていく（推論増量中）。

1. 2 で広告配信用のスクリプトが発行された時点で、そのスクリプトにはアソシエイト ID が埋め込まれている。
2. 3 で埋め込まれたコードが 4 で初めて Amazon のサーバと情報をやりとりする（そのコードが埋め込まれたページの URL をURL 格納サーバに保存し、クローラ※にその URL を伝える）
3. クローラは、その URL のコンテンツ（テキストデータ）を取得する
4. クローラが取得したコンテンツは、解析サーバにより解析される
5. その解析結果は、先に取得した URL とひもづけられて、URL 格納サーバに保存される
6. 指定された URL からスクリプトが呼び出されると、URL 格納サーバはそのページの解析結果を商品引き当てサーバに渡す
7. 商品引き当てサーバは、解析結果に基づき、妥当な商品を商品データベースから検索し、オススメ商品データを返す
8. 広告配信サーバは、その商品データをスクリプトが呼び出された URL に広告データとしてを返す

基本的にはこんな流れだろう。

まず、C の部分がどういう処理をしているのかが気になる。というのも、特にカスタマイズしていないクローラの場合、ページ内のテキストをすべてそのまま取得してきてしまう。特にブログにおいて顕著な傾向だけど、ページ内にブログ内の記事へのリンクテキスト（記事のタイトルとか）が多数設置されている。そのテキストからキーワードを多く取得してしまうと、ページのコンテンツとの齟齬が発生してしまう可能性があるわけだ。例えば、海外旅行の感想を記事として投稿したとしても、リンクテキストに「最近読んだ本のタイトル」や「昨日のランチ」が並んでたりすると、下手をするとその日の投稿には記述されていない「最近読んだ本」や「料理本」がオススメ商品になってしまうことだってありうる……ということ。

こんな工夫って実装されている（ないしは予定されている）のかな？　こういうのがあると、コンテンツ解析の精度が上がるよね。

• スクリプトを呼び出したページがブログだった場合は、その RSS（ないしは Atom などのフィード）※※を解析する：
  このメリットは、ページコンテンツだけを取得できるという点。ただし、ブログ ASP によって出力する RSS のテキスト量がかなり違うようなので、テキスト量が少ない ASP（楽天ブログとか）の場合は、あまりよい精度での商品引き当てができなくなるリスクもありうる。
  
• HTML の構造解析をおこない、構造のパターン分析をし、ページコンテンツと直結したテキストだけを取得する：
  例えば、このブログであれば、左カラムにメニュー、右側のメインカラムにコンテンツ……というような構造になっている。であれば、HTML を解析して、左カラムの部分だけを取得すればいい……ということになる。とはいえ、これは相当大変。ブログは簡単に見た目を変えることができちゃうから、ページの HTML コードがころころ変わっちゃう。
  
• Google AdSense で導入しているようなセクションターゲットの利用（あるいは、それをそのまま利用）：
  Google AdSense では、セクションターゲットという特別なタグを用意している。そのタグは、「このページは、ここからここまでがページコンテンツだよ。ここの内容にあった広告を配信してね」というブロガーの主張を伝えることができるというもの。ブラウザでそのページを閲覧しても、そのタグはブラウザに表示されたりすることはないんだけど、クローラには読める。クローラが取得したコンテンツデータを解析するときに、「あ、ここから、ここまでですね」と理解してもらえる。無関係なコンテンツデータは入り込まない可能性が高くなるので、広告の関連度も高くなるだろう……というもの。
  

まだ、ページコンテンツの取得の話しか書いてないのに長くなってしまった……。続きは次回。コンテンツ解析から商品引き当てのところまで行けたらいいな。

※クローラ：ウェブページにアクセスして、そのページ内容を取得する計算機。ロボットとも呼ばれる。ページに含まれたリンク（クモの糸）をたどって、ウェブ（クモの巣）を徘徊することから、スパイダーと呼ぶことも。クローラが取得したデータが加工されて、検索エンジンの索引データのもとになる。有名なクローラとしては、Google の Googlebot、Yahoo! inc. の Slurp などがある。

※※RSS：ブログの見出しや本文（ないしはその抜粋）などのデータを一定の形式でページの更新時などに出力したもの。それを RSS リーダーと呼ばれるソフトに登録しておくと、更新情報が自動的に収集できるので、便利。RSS リーダーが普及するまでは、そのページが更新されたかを確認するには、そのページに行ってみる……などの原始的な手段しかなかった。

Roland Barthes と Web 2.0

Tim O'Reilly の提言した Web 2.0 というムーブメントがあるが、いくつかあるそのキーコンセプトのうち、Data is the Next Intel Inside、Light Weight Programming Models あたりで語られることを考えるにつけ、想起される人物がいる。20世紀のフランスの記号学者、Roland Barthes（ロラン・バルト > cf. Wikipedia JA）だ。彼の著作に The Death of the Author（『作者の死』> cf. Wikipedia EN）なるエッセイがある。文芸批評理論のコンテクスト下で書かれたものではあるが、現在の Web 2.0 のキーコンセプトに非常に近いものを感させる。その中で語られているコンセプトが、Wikipedia にうまくまとめてあったのでそのまま紹介しよう（Wikipedia JA「作者」より）。

文芸評論理論において、「作者」は、テキストの意味とその作者の意図の関係を巡る問題においての重要概念である。1968年に発表した評論「作者の死」において、ロラン・バルトはあるテキストの作者がそのテキストにおいて何を意味させようと意図したかは、そのテキストの解釈において重要ではないと説いた。この理論によると、テキストは作者一人の声のみにより構成されるのではなく、むしろ外部の影響、無意識的衝動、その他の既存のテキストなども含む、そのテキストとのコミュニケーションを形成する様々な要因によるものだとされる。それゆえ批評家は、テキストをその解釈を一意的に決定する作者の言明にとらわれない「自由な戯れ」の空間として扱うべきであり、テキストとのふれ合いはそれ自体が性交にも通じる快楽であると主張した。凝り固まった教訓的な形式主義の枷から解き放たれて、バルトはテキスト読解の芳醇な不完全さと創造的書き換えの可能性を示唆したのである。

この記述に出現するいくつかのキーワードを以下のように置換してみたらどうだろう。

• 文芸評論理論　→　現代のインターネットをめぐる環境
• 1968年　→　2005年
• 「作者の死」　→　What Is Web 2.0
  
• 文芸評論理論　→　Web 2.0
• 作者　→　データ作成者
• テキスト　→　データ
• ロラン・バルト　→　Tim O'Reilley
  

まさに Web 2.0 のキーコンセプトを説明するものになる。Roland Barthes が「作品」を「作者」から奪い、読者に委ねる「テキスト」に変質させた。その40年後に Tim O'Reilley が、計算機やインターネットの普及にともない、データ作成者側の意図により集積され、提供される情報は、いまや独占的に使われるものではなく、インターネットや HTTP プロトコル、Web API、XMLなどを媒介に「自由な戯れ」を提言するにいたったわけだ。

Ferdinand de Saussure（フェルディナン・ド・ソシュール > cf. Wikipedia JA）のアイディアを借りれば、

• signifié としてのデータ（実体）
• signifiant としての mash up（表現）
  

……という構図も考えられるかもしれない。言語における記号論的考察だと、

　日本語で「海」と表現される事物（signifié）
　　├ 海（signifiant）
　　├ 綿津見（signifiant）
　　├ sea（signifiant）
　　└ ……

このように signifié と signifiant の関係は、1 : N の関係になることが多いように思われるが、mash up の場合は、素材となる実体の signifié は複数、開発者も複数だとすれば、mash up における signifié と signifiant の関係は N : N の関係になり、無数の組み合わせの「自由な戯れ」がインターネット上で展開されることになる。

疎結合したデータ（signifié）は、新たな表現（signifiant）を産み、その利用および価値判断は「読者」たるユーザに委任される。

おもしろい時代になってきたなあ。Web 2.0 の胎動の兆しもなかったころ、Amazon の書籍データほしいなあ……とか思ってたのが懐かしく感じられる。。。

Tim O'Reilly の What Is Web 2.0 - Design Patterns and Business Models for the Next Generation of Software は、以下のページで日本語で読むことができる。

• 「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（前編）」（CNET JAPAN）
• 「Web 2.0：次世代ソフトウェアのデザインパターンとビジネスモデル（後編）」（CNET JAPAN）

※写真は、Wikipedia より拝借。しかし、本家 Wikipedia の記述は、クオリティが高いなあ。日本もがんばらないと。。。

心地よいユーザインターフェイス

なんだか西海岸では、Google 祭りをやっているようだ。祭り囃子や群衆のざわめきが、はるかかなたからケーブルに乗って伝わってくる。ユニバーサル検索か。ネーミングの陳腐さはさておき、単純にいくつかの検索サービスにクエリ投げて、帰ってきた検索結果をごちゃっとまぜるようなかっこわるいものなどではなさそう。

そんなざわめきのひとつの CNET の記事の片隅にこんなことが書いてあった。

また、ユーザーは「Google Labs」で、同社が実験中の「Google Experimental」の機能を試すことができる。そのなかの例としては、左利き用検索ナビゲーション、検索結果の上部に時系列表示を追加する機能、検索結果に地図画面を追加するものなどがある。
http://japan.cnet.com/news/media/story/0,2000056023,20348967-3,00.htm

控えめな記事ながら、なんとなく気になった。「Lab」（研究室）の中の「Experimental」（実験）というなんとも……。その記事にも語られていなかったひとつのユーザインターフェイス案が、「キーボードショートカット」。

• 検索結果ページの第一候補に「>」のマークがついている
• 「j」のキーを打つと、「>」は第二候補に移動する
• もう一度「j」のキーを打つと、「>」は第三候補に移動する
• 「k」のキーを打つと、「>」は逆に第二候補にもどる
• 「j」を連打して第十候補まで来たときに、さらに「j」のキーを打つと、次ページに遷移する
• 検索結果のいずれかに「>」がついているときに「o」のキーを打つと、その検索結果ページが開く。「enter」キーも同様
• 「/」のキーを打つと、検索窓にカーソルが移動して、入力文字列が選択される（つまり次の検索語をすぐに入力できる！　絞り込み検索をしたい人には、ちょっと……）
• 「esc」のキーを打つと、検索窓のカーソルが解除されて、直前に「>」のついていた検索結果にもどる

……という内容。なんかこれ見たことあるなあ……と思ったら、Bloglines（有名なウェブベースの RSS リーダー）のユーザインターフェイスもこのタイプ。たまったフィードをざくざくチェックするときに使ってた。なので、コードは違うにしてもユーザインターフェイス的にはさほど新しいものではない。

でも、これすごく便利。ずらっと並んだ検索結果を眺めているとときどきいま見ているのがどこだったかわからなくなって、ブラウザ上で意味なくカーソルで追っかけていることってある。このユーザインターフェイスだったら、「>」が先頭に表示されるので、一目瞭然。バックグラウンドに薄いハイライトがかかったり、大きめの文字で表示されたりするなんていうオプションもありだと思う。検索結果チェックが効率よくなりそう。

……なんてことを言うと、某社のエンジニアくんは、「j とか k なんて敷居が高いですよ」とか「それはやっぱり vi ※に慣れた人の発想ですよ」などと言う。そうかなあ……。じゃあ、「j」とか「k」でなくてもいい。「↑」や「↓」でもいい……などと話をしているうちに思ったんだけど、ホットスポット※※をマウス操作でクリックしたり、Ajax な地図サービスのマップをぐりぐり動かしたり、ブラウザ操作はどうもマウスに支配されすぎている気がする※※※。確かにマウスでなければできないこともたくさんあるし、マウスの方が便利なこともたくさんあるんだけど、検索結果の閲覧など作業の連続性がある程度予測されるようなサービスでは作業効率の向上を目的としたキー操作をもう少しフィーチャーしてもいいんじゃないだろうか。Excel なんかだと、上下キーとか普通に使うと思うんだけどな。

Ajax を利用して画面遷移回数を低減するのも、ユーザインターフェイスの向上に一役買っている。Google マップで「マイマップ」を作るときのスポット登録のインターフェイスもかなり心地よい。作業の連続性が分断されないインターフェイス。スポットを思いつく限りどんどん登録できる。先日、AdSense の申し込みのときもおもしろいユーザインターフェイスを目にした。あるページに誘導されたのだが、そのページには質問がひとつ掲載されているだけ。その質問に答えると、次の質問が表示される……というもの。質問の多いページだと、山のようにフォームが表示されて、それを見るだけで萎えてしまうということが多々ある。でも、この質問票にはそんな圧迫感はなかった。その質問票の続きに郵便番号を入力する欄があったのだが、ここにもいい工夫があった。「123-0001」のように「半角数字3桁＋半角ハイフン＋半角数字4桁」という形式で入力するように促すための工夫。入力フォームの脇に注意書きを掲載することもできるのだが、それだとフォームの周囲にテキストが増えて、鬱陶しくなる。フォームの脇に小さな「？」アイコンを設置して、それをクリックしてもらって、ヘルプメッセージを表示することもできるだろう。ここで、Google がやっていた工夫というのは、これ。郵便番号を入力しようとしたとき（郵便番号記入用欄が選択されたとき）に、脇に吹き出しで注意書きを表示するというもの。画面に「ぽっ」と表示されるので、視線が自然に移動する。で、注意書きを読む。入力が完了（別の項目の記入欄に移動）すると、吹き出しは消える。スマートなユーザインターフェイスだ。

別に驚くような工夫がなくてもいい。ユーザが快適に作業できるという心地よさの提供が大事。

※ UNIX に標準でインストールされているエディタ。「j」とか「k」とかキーを打つと、エディタ上のカーソルが上下移動する。あまりにシンプルなユーザインターフェイスで、初心者には敷居が高いけど、慣れると心地よい（やっぱり慣れると心地いいんじゃないか！）
※※あんまりこんな言い方しなくなったけど、ウェブブラウザ上の画面でクリックできるリンクのこと。
※※※だいたいのブラウザは、ホットスポットやフォームの移動に「tab」キーが使えたり、フォーム送信に「enter」が使えたりするけど。

検索の未来形？ Yahoo! ブログ検索

Pipe を作るためにひさしぶりに Yahoo! ブログ検索をいじってみたら、いろいろ機能アップしているのに気づいた。「これでもか！」と言わんばかりのてんこもり状態。おもしろそうなところをいくつかピックアップ。サンプルクエリは「水曜どうでしょう」で♪

【キーワードの注目度】
画面の左カラムのいちばん上にある折れ線グラフのモジュール。 これは、最初からついている機能。検索キーワードに関する話題がどの時期にどれぐらい盛り上がっていたのが視覚的にわかるところがいい。細かい機能なんだけど、マウスでグラフ上をなぞると、期間の範囲選択ができて、その期間に限定しての絞り込み検索を実行してくれる。いちばん盛り上がっているところは、どうやら07/03/21。 絞り込んだ結果を見れば、盛り上がった理由は一目瞭然。DVD の引き渡しの日だったんだね〜。

このモジュールの下の方に「拡大表示」というリンクがあって、これがまたおもしろい。ここはリリース時より機能アップしてる。検索キーワードの注目度がグラフ化されているのは当然として、これと比べて別のキーワードはどうだったのかがチェックできるようになっている。つまり、「水曜どうでしょう」とその出演者「大泉洋」の注目度の比較が見られるわけ。だから、こんなこともできちゃうわけ。

【評判情報】
「キーワードの注目度」モジュールの下にあるのが、「評判情報」 モジュール。これは、ブログ検索サービスでは、いくつかの会社が取り組んでいる技術。ブログ検索を口コミ情報の素材だと考えれば、自然言語処理技術の応用 として思いつくトピックでもある。これを見ると、検索キーワードの含まれるブログの中からポジティブな表現、ネガティブな表現、ポジティブともネガティブとも言えないけどなんらかの評価をしている表現を拾ってきて、それをグラフ化しているみたい。

これにも「詳細な評判情報を見る」というリンクがあるのでクリックしてみる。このページでは、モジュールにも表示されていた円グラフと、ピックアップされた評判表現、それらの表現が含まれるブログ記事が表示される。評判表現の処理がなかなかいい感じ。「面白い」という表現を見てみると、「面白いです」、「面白かった」という活用形もちゃんとカバーしている。さらに「おもしろい」とひらがなだけで記述されているものも同一視して処理されているのも注目に値する。評判情報処理の難点としては、係り受けの問題がある。つまり、

• 『水曜どうでしょう』の後に放送してる番組がむちゃくちゃ面白くって……
• 最近話題になってる『水曜どうでしょう』を見た。これだったら昔の『電波少年』の方が面白かったなあ……

……というようなテキストも単純な「水曜どうでしょう」「面白い」の複合検索ではひっかかってしまう。これらのテキストで「面白い」と評価されているのは、「『水曜どうでしょう』の後に放送している番組」であり、「『電波少年』」である。本来は、評判表現がどの語に対して係り受けしているのかを見なければいけないわけで、構文解析という技術が必要なレベル。でも、構文解析は高負荷な処理なので、なかなか大規模テキストに対して利用するのは難しい。想像ではあるんだけど、この Yahoo! ブログ検索ではおそらく検索キーワードと近接する評判情報に限定して処理しているんじゃないかな。それだと、まったく関係ない語への係り受けを評価対象に加えてしまうリスクはある程度防げる。もちろん網羅率という犠牲はともなうけど。

係り受けの抱えるもうひとつの問題は、照応詞とゼロ代名詞。いわゆる「それ」、「あれ」といった指示代名詞や主語・主題の欠落（省略）。とはいえ、これは検索キーワード自体が含まれない可能性も十分にあると思われる（そもそもキーワードでの検索ができない）ので、実用レベルのプロダクトではさほど大きな問題にならないのかもしれない。

goo のブログ検索では、「キーワードの注目度＋評判情報」みたいな形で表現していて、これはこれでおもしろい。評判表現の処理がいまひとつなんだが……。

【まとめ検索】
「キーワードの注目度」モジュールの上あたりにひっそりと「検索結果をまとめて表示」という地味なリンクがある。これもなかなかおもしろい。クリックした先にあるページはこんなもの。左カラムにキーワードが並んでいる。おそらく「水曜どうでしょう」が含まれるブログ記事に特徴的な頻度で出現している語彙のリストだろう（抽出方法は、TF/IDF だろうか）。少し変なものも含まれてはいるけど、けっこういいリストかも。

• 水曜どう、大泉洋、北海道、放送、classic、番組、TEAM NACS、最新作、クラシック、本……

これらのキーワードの重なり具合をベースにブログ記事を束ねているように思われる。この機能、地味ながら検索支援という意味でかなり示唆に富むもの。自分のよく知っている話題であれば「ふーん」で終わってしまう話題なんだけど、よく知らない話題の場合だとかなり意味がある。ウェブ検索の場合は、

• snippet（すにぺっと：検索結果の下に表示される本文中のテキストなどを抽出したもの）を読む
• 実際に検索結果ページにリストされているページに行って、コンテンツを拾い読みして、なんとなく関連しそうなキーワードらしきものを拾いだす

という作業が必要なのだが、その作業を省力化してくれる試みと言えるだろう。

その他にも「似たものワード」なんてキーワードリストが検索結果ページの下の方にあったり、「関連検索ワード」なんてのがページ上部に表示されたり。ちょっとこのあたりは盛りだくさんすぎて、ユーザ的にはなにがなんだかわかんないかもしれない。何をベースにして算出しているものなのかの、もうちょっと説明がほしいところ。

……とはいえ、今回ピックアップしたさまざまな機能は、検索技術の未来を垣間みさせてくれたような気がする。

Pipes でらくちんマッシュアップ♪〜その弐

Pipes のステップ2。（Pipes 第一弾は、こちら）

自分のかかわったプロジェクトがどんな風に世の中に受け入れられているのか気になるでしょ。そんなときどうする？Yahoo! JAPANや Google のウェブ検索でチェックしてみる？　でもちゃんと口コミを集められるかどうかはわかんないよね。口コミチェックならやっぱりブログ検索！　ブログ検索は、ウェブ検索と違って、いろんな会社が参入している。ウェブ検索の覇者、Google、Yahoo! JAPAN はもちろん、livedoor や goo などのポータルでも早期からサービスインしている。Technorati、Ask.jp なんかもある。NAMAAN というスタートアップも参入している。ウェブ検索が、Google と Yahoo! に席巻されていることを考えれば、ありえないほどの敷居の低さ。

まあ、それはさておき、こんどは検索窓を設置して。検索語を自由に受け付けるモデルを作ってみる。各社のブログ検索サービスに自分の気になるトピックを一気に問いあわせちゃおう……という Pipe。各社のブログ検索は、検索結果自体を RSS として配信している。それを使っちゃおうというわけ。普通の RSS は新着ニュースなんかを更新情報として流しているってのが多いけど、ブログ検索はキーワードに対する検索結果を RSS 配信しているって言うんだから、使わない手はない。

今回使うモジュールは、検索語を入力するインターフェイスモジュール、各社のブログ検索の検索結果にその検索語で問いあわせるモジュール、そこから RSS を取得するモジュール。あとは、前回同様、重複削除処理、時系列での並べ替えのモジュール。中核となる部分は、スクリーンショットを用意しているので、見てみてください。

検索語の入力モジュールは、「User Inputs」の「Text Input」を利用。このモジュールをキャンバスに持ってくると、いくつかのオプションが表示される。

• Name
• Prompt
• Position
• Default
• Debug
  

の5項目。わかるようなわからないような……。「Prompt」は、きっとユーザインターフェイスの検索窓の横に表示される説明書きなんじゃないかな。「Default」は、初期値。ここに「大泉洋」と記入しておけば、最初から検索窓に「大泉洋」って記入されて表示されるんだろうな。「Debug」。これは、ここに記入した文字列でうまくいくかどうかを試すことができるんだろう……と想像しながら、作業を進めていく。

次に必要なのは、各社のブログ検索の結果 RSS を引き出すための URL。例えば、Google で「温泉」と検索してみる（検索結果）。Google は他社のサービスと違って、関連度順にランキングされるのが初期設定なので、画面右上の「日付順に表示する」をクリック。それで得られた検索結果のURLは、以下のとおり（クリックして URL を参照のこと）。

• Google ブログ検索で「温泉」を新着順で検索した結果ページ
  

なんだかごちゃごちゃいろいろ文字の含まれている長い URL。検索結果画面の左カラムを見てほしい。ここに「フィードを取得　Atom | RSS」とある。「Atom」と「RSS」の違いは別の機会に譲るとして、「RSS」をクリック。すると、こんな URL（クリックして URL を参照のこと）。

• Google ブログ検索で「温泉」を新着順で検索した結果の RSS
  

これが今回の Pipe で使う素材のひとつになる。これを前回の「Fetch Feed」に入れることもできるけど、それでは毎回「温泉」の検索結果しか出てこない。それではダメなので、別のモジュールを使う。「URL」の「URL Builder」モジュール。これをキャンバスにもってくる。すると、

• Base
• Path Elements
• Parameters

といった入力項目が表示される。ここにさっきの RSS の URL を分解して入れていく。こういった URL は、特定のプログラムとパラメータの組み合わせでできていることが多い。Base や Parameter に下記の要素を放りこんでみる。

• Base：Google ブログ検索の検索結果 RSS を生成するプログラムの URL を指定（一般的には長い URL の「?」より前の部分）
  http://blogsearch.google.co.jp/blogsearch_feeds
• Parameters：上記のプログラムにどういう挙動をさせるかを決定するパラメータ（引数とか環境変数とか呼ばれる）
  • hl=ja（日本語のページってことかな。素直に入れておきましょう）
  • q=%E6%B8%A9%E6%B3%89（最重要アイテム！　検索語はコレ！）
  • lr=lang_ja（日本語のページってことかな。素直に入れておきましょう）
  • scoring=d（？　素直に入れておきましょう）
  • ie=utf-8（input encoding の略かな。入力文字コード。素直に入れておきましょう）
  • num=10（出力件数？　もしかしたら面白いことができるかも）
  • output=rss（出力フォーマット。素直に入れておきましょう）

Parameter の入力は、「hl=ja」だったら、左の箱に「hl」、右の箱に「ja」といった感じで。ここでいちばん大事なのは、「q」。これが検索文字列用の箱なので、ここの右の箱は空にしておく。で、この右の箱の脇にある「○」と、さっきの「Text Input」をパイプでつなげてやる。おまけで出力数を指示する「num」を受け付ける「User Inputs > Number Inputs」もくっつけてみた（初期値50件で）。

仕上げに、前回も登場した「Fetch Feed」モジュールの再登場。これを「URL Builder」モジュールとパイプで接続。あとは、重複処理、時系列並べ替えをして、ひととおりのフローは完成。

マッシュアップということで、その他各社の RSS を「URL Builder」で作り込んでいって、パイプでつなげて、完成〜♪　検索語を入力して、いろいろ試してみてください〜。

• ブログ横断検索パイプ：blogsearch_unfixed
  

Pipes でらくちんマッシュアップ♪〜その壱

Yahoo! inc. の Pipes がおもしろいよ……という話をエン友（エンジニアのおともだち）から聞いたのが、ことしの初旬。ちらっと覗いてみて確かにおもしろそうだなとは思ったものの、「必要は発明の母」ではないが、さして必要でもなかったので実験にはいたらず（この辺がダメなんだよね……）。

Pipes は、いくつかの RSS を好きなように組みあわせて、自分好みの RSS を作っちゃおう……というサービス。ブログとかニュースサイトとかで新着記事のチェックを RSS リーダーでやったりするよね。Asahi.com と、ZAKZAK と、なんとかと、かんとかと……といくつも RSS リーダーに登録しちゃうこともできるけど、それだとバラバラに RSS が飛び込んできて、ちょっと鬱陶しい。Pipes を使うと、もろもろの RSS がさくっと一本の RSS にまとめられちゃう。それがあんまり高度な技術的な知識もなく、いくつかのモジュールを組みあわせるだけでできちゃうってのが、このサービスの特徴。いくつかのモジュールって言うのが、RSS の取得だったり、検索文字列入力窓みたいなインターフェイスだったり、並べ替えの処理だったり。これらをパイプでつないでやる。パイプでつなげることによって、データがモジュールからモジュールに流れていくわけ。方眼紙状のキャンバスの上に、自由にモジュールをならべて、パイプでつないでやる。モジュールにしてもパイプにしても Ajax でぐりぐり動かせたりして、プログラムを組み立てていく楽しみもある（ブラウザ上でこういうことができることだけでも楽しい）。

社内で Q&A サービスを立ち上げたいという話があり、それだったらまずは既存のサービスでどんな Q&A が飛び交っているのかリサーチした方がいいんじゃないかと思ったわけ。で、Pipes に行ってみると、人気の Pipe に「Yahoo Unanswered Questions」なんてのがある。Yahoo! inc. 版『知恵袋』の『Yahoo! Answers』のまだ誰も回答をつけていない質問だけをピックアップしてくれる Pipe。な〜るほど。そういう使い方があるか。確かに、Q&A サービスは誰よりも早く回答したい！というアツい（ヒマな？）人たちがたくさんいるので、そういう人たちにはうってつけのサービスかも。Pipes には、人の作った Pipe の設計図を見る機能があって、それを見るとどんな風にこの Pipe が作られているかがわかる。これがまたいい機能。

となると、俄然ヤル気が出てくる。まずは Yahoo! 知恵袋をチェック。ここが RSS を配信しているのは知っている。で、見てみると、質問のカテゴリごとに RSS が配信されていることがわかった。「回答受中の質問」、「投票受付中の質問」、「解決済みの質問」の3つ。例えば、「インターネット、PCと家電 > デジタルカメラ」カテゴリだと、こんな感じ。

• 回答受中の質問
• 投票受付中の質問
• 解決済みの質問

今回作りたいのは、「どんな Q&A がやりとりされているかが何となくわかる」Pipe なので、これらを全部マージしてみる。左カラムに「Sources」というのがあるが、これが元ネタの RSS を取り込むためのモジュール群だ。この中にある「Fetch Feed」が使えそう。「Fetch Feed」をキャンパスに展開して、さっきの3つの URL をコピペ。「＋ URL」で入力欄が自由に増やせる。これで、全部の RSS が取り込めたことになる。

これをこのまま出力してもいいんだけど、それぞれの RSS に同じ Q&A がダブっていたりすると嫌だな（そんなことはなさそうな感じだけど）……と思い、「Operators」メニューの「Unique」というモジュールを「Pipe Output」（出力モジュール）に送る前にはめこんでみる。これで重複しているものを削除してくれるはず。でも何をもって重複していると判断するの？……ってのを Pipe に教えてやらなくてはいけない。そこで「Filter non-unique items based on [......]」のオプションを使ってやる。「[......]」の部分がプルダウンメニューになっている。ここでどれを選ぶのが適切かよくわかんないけど「item.title」にしてみる。タイトルが違ってれば、別の質問だとみなしてもいいでしょ……という安易な判断。ダメならあとで直せばいい。「Fetch Feed」と「Unique」をパイプでつないでやる。

これで概ね完成なんだけど、最後の仕上げに表示順をいじってみる。「Operators」メニューに「Sort」っていうのがあるので、これも使うことに。オプションは、「Sort by [......] in [ascending | descending] order」となっている。「[......] をキーに昇順・降順に並べろ」ってことらしい。だったら、投稿日時の「item.pubDate」をキーに降順にしてやれば、新しいもの順になるはず。最後に、「Sort」と「Pipe Output」をパイプでつないでやる。

これでひとまず完成。「Save」ボタンをクリックして保存したら、「Run Pipe」をクリック。プログラムが稼働する。出来映えを見て、いまひとつの動きだったら、各モジュールの値を調整したり、途中のモジュールを追加したり、削除したり。ステップごとに変な動きをしていないか、思ったとおりの動きをしているかも開発途中でチェック（Debug）できるのもうれしい。

せっかくだったら、『教えて！goo』のデジカメの Q&A も取り込んじゃった方がマッシュアップっぽくて、おもしろいかなと思い、RSS を追加（あんまり情報量多くないけどまあいいか）。はてなの『人力検索』は、カテゴリの粒度が粗すぎて、ちょっと使えないかも。これでひとまず完成！　お試しはこちらから〜。

※Pipes を作ったり、設計図を見たりするには、Yahoo! inc. の ID （Yahoo! JAPAN の ID ではダメ）が必要。

※※LEGO のパーツと小さなコンピュータを組みあわせて作る LEGO Mindstorms ってのがあるんですが、このコンピュータのプログラミング環境とこの Pipes、ユーザインターフェイスが似ていると思う。

to begin with...

被覆ケーブルであるか、ワイヤレスであるかは別にして、ON であるか OFF を問わず、無意識かつ暗黙的に計算機のネットワークという結界の中で生活していることに気づく。「これがないと死んでしまう」という明確なメリットを感じさせるほどのものではないけど、「これがあると楽だなあ」とか「これっておもしろ〜い」と感じさせるものなんてのは星の数ほど。「これって中身、どうなってんだろう」って、知的好奇心をくすぐるものなんかもあったりする。

そうした IT 周辺のトピックに関してメモ書き的にまとめておこうと思った。こどものころに夢中になったブルートレインを懐かしむように、10年後、いや2年後にも「あ〜、こんなんあった、あった〜」と思えるんじゃないか……と。