2007/06/26

はてな × ジャストシステム

07/06/20 の CNET の話題。「読了、スレタイ…:日本語辞書ATOKに、はてなのキーワード5万語を採用」(その日にこの記事を書きはじめたんだけど、なんかバタバタしちゃって……)。

曰く、

ジャストシステムはてなは6月19日、ジャストシステムの日本語入力システム「ATOK 2007」で、はてなのブログサービス「はてなダイアリー」のユーザーが作成し共有するキーワード群「はてなダイアリーキーワード」のコンテンツを活用できるサービスで連携し、提供を開始した。(CNET の記事より引用)

……とのこと。

ジャストシステムの ATOK にアドオンで追加できる辞書ができましたよ……というプレスリリースなわけです。ジャストシステムの当該プロダクトの紹介ページ曰く、
はてなダイアリーキーワードのうち、アクセス数上位5万キーワード(2007年5月31日時点)を、ジャストシステムが辞書・省入力データ・電子辞典として登録したものです。ネットで生まれた流行語や日常語など、現在の世相を映し出すこれらキーワードをATOK 2007上において、スムーズに入力でき、そのキーワードの説明を参照することができます。(ジャストシステムのダウンロードページより引用)

……とのこと。過去をひもといてみると、「ATOK の機能を利用した「goo」の新検索サービス開始 〜ATOKがかしこくなると「goo」がかしこくなり、「goo」がたくさん利用されるとATOKがかしこくなる〜 」という 2005/10/27 のプレスリリースに行きついた。そういえばこの頃から、ジャストシステムは、こうしたいろんな試みに挑戦している。ジョルダンとの駅名変換辞書、東洋経済新報社との企業名変換辞書。そして、このはてなキーワードの採用。

この動きを進めていったところで、ATOK が爆発的に売れるようになるとか、一太郎が Microsoft Word のシェアを奪還する……なんてことはないだろうけど、顧客のニーズにあった製品開発をしていこうという姿勢がいい。駅名や企業名なんていうのは、よく「あ〜、なんでこんな簡単な変換ができないの?」って苛つくポイントになりやすい部分。まあ、これまでのかな漢字変換装置からしてみれば、コロケーション(語連接)とか語彙の区切りの精度なんての(ずいぶん前に TV CM で話題になった「入れた手のお茶」みたいなの)が注力ポイントだったんだろうけど(もちろん固有名詞の収集も手抜きはしてなかったと思うけど)。

ただ、こうした単一企業による努力には、限度がある。駅なんていうのはそんなに数が大規模に増減するようなものではないけれども、駅名の変更をジャストシステムが常にモニターしているわけにはいかない。企業名なんてのは駅名以上にダイナミックに変化が観測されるものだ。ダイナミズムで言えば、その頂点に立つのが、やはり検索サービスのクエリなんだろう。人が興味のある事象について検索する。その興味の範囲は、anonymous(匿名)なユーザの diversity(幅広さ)に直結する。さらに、ここに量による重要度の推定が可能になるというありがたい状況(そんなによく検索される言葉なんだったら、きっと意味がある言葉なんだろう……という推測)が成り立つ。このあたりが、はてなキーワードのアドオン辞書で言えば、「アクセス数上位5万キーワード」というあたりに反映されている。

伝統的な紙の辞書や百科事典の場合には、物理的な制限もあって、無限に収録語数を増やしていくことはできない。あっという間に使われなくなってしまう一過性の言葉を記録しておくだけのモティベーションも発生しにくい。しかし、こういうアドオンの辞書であれば、それをインストールすることによって占有されるディスクスペースのことなんか考えるまでもなく小さいわけだ。自分で入力しなければ、邪魔にもならない(とも言い切れないかもしれないけど……)わけだ。さらに、デフォルトでこれらの辞書が組み込まれるわけではなく、ユーザのニーズに応じて、必要な人だけがインストールすればいい。

ハードウェアよりソフトウェア、ソフトウェアよりデータ……という流れをこの業界にいると感じることが多々ある。いまや、そのデータすらも一元管理の純粋培養ではなく、「餅は餅屋」なフレッシュかつ専門的なものが望まれる、ないしは必要だと提供者側が考える……そんなトレンドを感じるできごと。いまちょうど『ウィキノミクス マスコラボレーションによる開発・生産の世紀へ』を読んでるんだけど、これにも通じるところがある。間接的なマスコラボレーションの成果の利用としてね。

2007/06/16

機械翻訳にやさしく

Google のオフィシャルブログをいつも読もう、読もうと思っているんだけど、英語が面倒で常に 3 桁の未読フィードがたまっている状態……。これではいかんなと思い直し、不本意ながら「Yahoo! 翻訳」のお世話になることにした(ホントは、原文で読みたいんだけど、残念ながら時間がない。翻訳結果を斜め読みするのが精一杯)。

いくつかの記事を翻訳していくうちにおもしろいことに気づいた。なかなか翻訳精度がよいようなのだ。そこそこ読めるというか、ある程度背景のわかる話題とかだと、ほぼ誤解することなく理解可能。しかし、ある記事を翻訳すると、極端に翻訳精度が落ちる。オリジナルの英文を見てみる。英語としては特に変な文章ではないけど、すこしくだけた表現が多く含まれているみたい。やはりそういう「こなれた」表現だとまだ機械翻訳には厳しいようだ。

「Yahoo! 翻訳」のガイドページに「Yahoo! 翻訳のコツ」というページが用意されている。これは主に日英翻訳(日本語の原文を英語に翻訳)のときの Tips を書いているわけだけど、読んで見ると機械翻訳の特性や日本語と英語の違いがあぶり出し的に見えてくる。以下、同ページ群より引用。

  • 日本語入力で気をつける点
    1. なるべく漢字を使う
    2. 漢字の間違いに注意する
    3. 長音記号はハイフンではなく、「ー」を使う
    4. 略語は略さずに書く
  • 文章を短くする
    1. 動詞の切れ目や「~が」(接続助詞)、「~だが」などで、文章を分割する
    2. 文章を分割した後に、必要に応じて適切な接続詞や主語を補う
    3. 不要な言い回し(「~ということ」「~ものである」「~したいと思う」など)を取り除く
    4. 重複する表現を避ける
  • あいまいな表現を避ける
    1. 適切な助詞を使う
    2. 省略を補う
    3. 修飾語がかかる範囲を明確にする
  • 訳文を編集する
    1. 単数・複数を確認する
    2. 時制の一致に気をつける
    3. 代名詞を確認する
    4. 前置詞を確認する
最後の「訳文を編集する」は翻訳結果が得られてからの作業(post-processing)だけど、それ以外は機械翻訳する前の準備作業(pre-processing)。英語が苦手な場合は、翻訳結果(英語)を編集するってのは難しいかもしれないけど、準備作業なら日本語を相手にするだけだから簡単。どれも言われてみれば、ごく当たり前のことばかり。

「日本語入力で気をつける点」で語られていることは、主に辞書の参照に関する問題。「なるべく漢字を使う」なんかは、ひらがなが多いと、翻訳作業の前処理の形態素解析(文章を単語単位で分解する作業)の障害になってしまう。ここでつまづくと、翻訳結果はめちゃくちゃになってしまう。よく言われる例は「ここではきものをぬいでください」が「ここでは着物を脱いでください」なのか、「ここで履物を脱いでください」なのか……というもの。確かに、これは文脈(店の入り口の貼り紙なのか、健康診断の会場での指示なのか)がなければ、人間でもその判断は厳しい。「漢字を間違いに注意する」なんてのも、辞書検索の障害になるので要注意。

「文章を短くする」は、主に構文に関するもの。形態素解析は、高速かつ精度高く処理できるのでいいのだが、構文解析っていうのは、単語の前後関係だけでなく、文章内のすこし離れた単語の関係を見なくてはいけなかったりするわけで、これは難易度がぐっと高くなる。日本語は簡単な接続詞で文章をゆるやかにつなげていくことができるけど、それが逆説関係なのか、順接関係なのかその関係性が曖昧だったりすることも、この構文解析の難易度を高める一因なんだろう。

「あいまいな表現を避ける」は、英語と日本語の語用の違いが主な話題。「具体的な動詞を使う」というのは、「英語は動詞が中心、日本語は名詞が中心」というよく言われる話にも通じるもの。「適切な助詞を使う」というのは、英語は厳格な語順によって主語や目的語が識別できるのに対して日本語では適切な助詞が付与されていれば語順にはさほどこだわらないということだったり、助詞に与えられている役目の多さ(機械翻訳の立場から見ると曖昧さ)に帰因するものだろう。

機械翻訳は、計算機による自然言語処理のかなりの要素を詰め込んだかなり高度な作業をこなしているわけだけど、どうも一般的には評価が低い。翻訳結果がこなれた日本語でなかったり、文章の解析に失敗したりして、ヘンな訳になってしまうことが多いからだろう。その結果だけを見て、笑うのは簡単なことなんだけど、その前に元の文章が翻訳ソフトにもわかりやすい文章になっているかどうか、もう一度確認するという作業をやってみてはどうだろう。それだけで、けっこう精度上がるものだ。

あ、あと、安い翻訳ソフトを買って、「なんだこんな単語も訳せないの?」っていうのも要注意。安い翻訳ソフトには基本語彙しか登録されていない。専門用語なんかはそれらよりも高価なソフトにしか登録されてなかったりするわけ。辞書作りというのは、なかなか時間のかかる作業で、このコストってのは馬鹿にならないらしいよ。

2007/06/12

ソーシャルブックマークが検索結果に及ぼす影響

きょうは別の話題を書こうと思ってたんだけど、『Yahoo! 検索スタッフブログ』におもしろい記事が載っていたので、そのネタで。「Yahoo!検索結果にブックマーク登録人数表示を開始!」という記事。

4 月の半ばに『Yahoo! ブックマーク』が大幅にリニュアールされた。リニューアルというよりは、過去の資産を利用した新しいプロダクトだと言える。そもそもの『Yahoo! ブックマーク』は、シンプルなオンラインブックマークサービス。自分のお気に入りのページをブラウザのブックマーク機能を使って、自分の PC に蓄積するのではなく、Yahoo! ID にひもづけて、Yahoo! のサーバに置いておきましょう……というもの。そうすることによって、会社でブックマークしたページを『Yahoo! ブックマーク』経由で自宅の PC でもブックマークとして利用できる……というパーソナルな用途に特化したサービスだった。数多くのユーザが、自分の利便性のためにいろいろなページをブックマークしていた。新『Yahoo! ブックマーク』は、そうしたパーソナルな利用法も残しつつ、ソーシャルブックマークとしての新境地にいたった。ソーシャルプロダクトに転身することで、ユーザ間で共有(share)することができるようになった。その際に過去の資産(ソーシャル化する前のパーソナルな大量のブックマーク)を一気に獲得するに至る。

実はこの段階では、まださほどのインパクトは感じていなかった。逆にパーソナルな資産をいきなりソーシャルなものにしちゃうってのはどうなんだろう……と懐疑的でさえあった。ソーシャルブックマークは、どんなユーザがどんなアンテナを張っているのかが伺い知れるところが醍醐味だったりするわけ。だけど、この時点の『Yahoo! ブックマーク』は、当然のことながら非公開ブックマークの山。ユーザとのコンセンサスがない以上、ブックマークを個人とひもづけて公開するわけにはいかない。とはいえ、登録者数は把握できる。ここのところが肝心なところで、これをどう活用するのかな……いや、これをいつ検索結果に反映するのかな……そこが最大の関心事だった。で、きょうのリリース。

実際に目にしてみるとけっこうなインパクト。例えば、「国内旅行」でウェブ検索をしてみる。現時点での 5 位までの検索結果は、以下のとおり。

  1. じゃらんnetホームページ
  2. JTB 国内旅行 [国内ツアー | 旅館・ホテル | 割引チケット | 高速バス]
  3. H.I.S.国内旅行(東京発) - 格安航空券・ツアー・宿泊予約
  4. 国内旅行・国内ツアー - スカイゲート - 国内航空券・国内旅行・高速 ...
  5. エイチ・アイ・エスホームページ
各検索結果の最後のあたり(URL の後ろ)に「○○人が登録」と地味に書いてある。この数字を先の検索結果と並べて記載してみる。
  1. じゃらんnetホームページ:9996 人が登録
  2. JTB 国内旅行 [国内ツアー | 旅館・ホテル | 割引チケット | 高速バス]:100 人が登録
  3. H.I.S.国内旅行(東京発) - 格安航空券・ツアー・宿泊予約:32 人が登録
  4. 国内旅行・国内ツアー - スカイゲート - 国内航空券・国内旅行・高速 ...:23 人が登録
  5. エイチ・アイ・エスホームページ:4025 人が登録
こうやって登録者数をフィーチャーしてみるとなかなかおもしろい。100 人が興味を持っている 2 位、32 人が興味を持っている 3 位、23 人が興味を持っている 4 位……これらが 4025 人のブックマークを獲得している 5 位と比較してどちらがより多くの顧客の誘導を実現できるか……ここのところが非常に興味深い。おそらく多くのユーザは、ここに数字が書いてあることに気づきもしないかもしれない。しかし、これ、気にしだすと、けっこう気になってくるから不思議。ブックマーク数が 0 の場合には、「0 人が登録」とは書かれず、何も表示されることはない。しかし、その数字がたとえ 1 や 2 であっても、何も書かれていないよりはなんかご利益があるように思えてくる。

そうなると、SEO 業者は着目すること間違いなし。「弊社の SEO 対策は、いま話題の SMO 対策も同時におこないますので、御社へのトラフィック誘導も成功しますよ」なんてセールストークをいまごろ練っているに違いない。明日には企画書に盛り込まれるかもしれない。SMO 対策オプションの料金表を作っているかもしれない。そうなってくると、発生しそうなのがアビューズ。とにかく大量のアカウントでクライアントのページをブックマークしまくるとかね。もちろん数多ある SEO 業者がみんなそんなことをするとは思わないけど、必ずいくつかは現れる。そういうアビューズが横行すると、ブックマークサービスの価値の低下が起こる。それは、Yahoo! JAPAN としては望むことではないはずだから、何らかの対応策が取られることになる(何らかの対抗策はもう仕込んであるかもしれない)。怪しげな SEO 業者と Yahoo! JAPAN のいたちごっこなんてこともありうる。さて、どんなことが起こるのかとても楽しみ。

実際、既にいろんな人たちが、いろいろ考えはじめている。現時点での『Yahoo! 検索スタッフブログ』の「Yahoo!検索結果にブックマーク登録人数表示を開始!」へのトラックバックは、12。Yahoo! ブックマークがリニューアルされたときのエントリへのトラックバックが 3 であることと比較しても、本件がどれほど人の興味を引く話題であるのかは明白。『Yahoo! ブログ検索』でチェックすると、こんな感じ。「このブックマーク登録数の結果がランキングに影響を与えるのか?」といった憶測も。SEO 業界の有名人のアイレップ・渡辺氏なんかは、極めて冷静。ある意味、懐疑的だともとれるコメント。

とはいえ、個人的にはけっこうオプティミスティック。ブックマーク資産の起源がパーソナルであろうが、ソーシャルであろうが、なんらかの意味があってユーザはブックマークしているはず。これって、Google の PageRank テクノロジーの根幹であるページ間のリンクと思想的にはかなり近い。人気度のひとつの尺度としては成立しうると考える。強いて言えば、ソーシャルブックマーク的な要素がブーストされるともっと有益なリソースになりうるなあ……とも感じる。良質なブックマークを数多く蓄積しているユーザが、PageRank 的な考え方で言えば、良質なサイト……と読み替えることもできるだろう。そうした処理ができるようになれば、シンプルな登録者数ではなく、ブラックボックスな数値に換算され、ランキング決定のためのパラメータとして利用される……なんていう発展的な成長がありそうな気がする。

素人目にもいろいろリスクのありそうな施策なわけだけど、そのリスクを乗り越えてプロダクトとして醸成されてくることだろう。当面は、ブックマーク登録数がランキングに影響を与えるところまではいかない……というのが読み。いまのところは、SEO の施策の一環として、もっと SMO のことを考えましょうね……という契機としてはいいんじゃないかな。さてさて、次に何が出てくるか……。

2007/06/11

情報要求の 4 レベル

Google だったり、Yahoo! だったり、毎日何らかの情報を求めて、検索ってやってると思う。このとっても日常的な検索という行為をすこし考えてみたい。

R. S. Taylor の 1968 年の論文(Question-negotiation and information seeking in libraries)において、人間の情報要求(information need)が 4 つのレベルに分類されている。『言語と計算 - 5 情報検索と言語処理』(徳永健伸)から抜粋。

  1. 直感的要求(visceral need)
    現状に満足していないことは認識しているが、それを具体的に言語化してうまく説明できない状態
  2. 意識された要求(conscious need)
    頭の中では問題を整理できるが、あいまいな表現やまとまりのない表現でしか言語化できない状態
  3. 形式化された要求(formalized need)
    問題を具体的な言語表現で言語化できる状態
  4. 調整済みの要求(compromised need)
    問題を解決するために必要な情報の情報源が同定できるくらい問題が具体化された状態
ちょっと複雑な言い回しなんで、ちょっと簡単に翻訳してみる。
  1. 直感的要求(visceral need)
    おなかが空いたなあ。
  2. 意識された要求(conscious need)
    おなかが空いたんで、そろそろなんか食べたいんだけどな〜。なんか、こってりしてて、おなかにたまりそうなものがいいなあ。
  3. 形式化された要求(formalized need)
    近場のラーメン屋で豚骨ラーメンでも食べようかな。こってりしてれば、丼ものでもいいかな。
  4. 調整済みの要求(compromised need)
    そうだ、高田馬場のすた丼にしよう!
これを各レベルで、ウェブ検索してみようと思うと……。
  1. 直感的要求(visceral need):おなかが空いた
    なんと検索すればいいのかわからない……
  2. 意識された要求(conscious need)
    「こってり」、「おなかにたまる」? いまひとつピンとこない検索語……
  3. 形式化された要求(formalized need)
    自分がいるのは「新宿」だから、「高田馬場」ぐらいまでは行ってもいいかな。ならば、場所の検索語は「新宿」か「高田馬場」。食べたいものは、「ラーメン」か「丼」。
  4. 調整済みの要求(compromised need)
    検索語は決定。「高田馬場」と「すた丼」。
……こんなところだろうか。ここまでピンポイントに食べたいものが決まっちゃえばいいけど、欲しい検索結果が出てくるような検索語が思いつかないなんてことはよくあること。

「調整済みの要求」や「形式化された要求」ならともかく、それ以前のレベルだったりしたら、検索語の決定すらおぼつかない。コレならどうかな? じゃあ、アレは? ……といろいろ試しているうちに、「調整済みの要求」や「形式化された要求」に近づくヒントらしきものが見えてきたり、偶然欲しいものにたどりついたり。

先日、こんなことがあった。サイト全体の HTML ファイルに共通のフッタ外部ファイルとして JavaScript で埋め込んでいる。そのファイルを毎回サーバから呼び出して、ちゃんと読み込んでほしいんだけど、ブラウザによっては PC の中に溜め込んだ情報(ローカルキャッシュ)を読み込んでしまって、こちらの希望する結果が得られない。ローカルキャッシュを読み込まないような回避策が欲しい。

これなんかは、まさに「意識された要求」レベル。せめて「形式化された要求」レベルにすべくいろいろ検索語を考える。「キャッシュ JavaScript 回避」、「JavaScript 外部 キャッシュさせない」、「no cache 外部ファイル インクルード」……などなど。検索語をとっかえひっかえ検索してみるが、なかなかびしっと決まるキーワードが思いつかない。

現在のウェブ検索は、基本的には「調整済みの要求」に対応するもの。検索結果ページに表示されたテキストを参考にしていけば、「形式化された要求」にもある程度は答えてくれる。しかし、それも知識と経験に基づいた人間からの歩み寄りによってしか実現されないことも多い。つまり、検索とは、既知情報から既知情報を経由して未知情報を探し出すこと……と定義されるものなのかもしれない。既知情報からしかスタートできない……このあたりが、キーワード検索の難しさなんだろうね。

追記:
……とかなんとか書いていたら、きょうの TechCrunch におもしろい記事が。

Powerset検索エンジンのデモ、初公開

記事によると、「在職中に亡くなった政治家(politicians who died in office)」といったフレーズで満足のいく検索結果が表示されると言う自然言語処理を応用した新しい検索技術だとのこと。この一例をもってどうこうう段階ではないけど、情報要求のより曖昧なレイヤーまでカバーできるようなものが今後登場してくるのかもしれない。

2007/06/04

クローラの届かない世界:深層ウェブ

「深層ウェブ」(deep web / invisible web / hidden web)という言葉を聞いたことがあるだろうか。Michael K. Bergman が唱えた検索エンジンでは索引化することができないコンテンツのことだ(Bergman の論文は、こちらから日本語訳で読むことができる)。Bergman の論文(ちょっと古いので数値データは参考にならないけど、テーマは現在でも通用するもの)では、検索フォームから検索文字列の入力によって動的に生成されるコンテンツを指すが、英語版の Wikipedia の Deep Web の項によると以下のような分類に含まれるものとしている。

  • 動的コンテンツ
  • リンクされていないコンテンツ
  • アクセスの制限されたコンテンツ
  • スクリプト化されたコンテンツ
  • 非テキストコンテンツ
確かにこれらは、検索エンジンが索引化するには敷居の高いものたちだ。07/05/25 の「検索エンジンってどんなもの?」で簡単に説明したように、検索エンジンの利用している索引は、クローラと呼ばれる装置によって収集されている。クローラは、種文書を読み、そこに記述されている別のページへのリンクをたどって、そのページを読む。各ページを読む過程において、主にそのページのテキストコンテンツを記録していく。これが検索エンジンの索引として利用されている。なので、
  • 動的コンテンツ
    検索文字列を入力して、データベースなどから情報を取り出し、ページを動的に生成するもの。クローラには検索文字列は思いつかないので、索引化することが難しい。
  • リンクされていないコンテンツ
    クローラはリンクをたどるものなので、リンクされていないとアクセスできない。サイトマップに記載されていれば、一般に公開されているページからリンクされていなくても、アクセスできるだろうが、それにしたってサイトマップからのリンクはあると言える。
  • アクセスの制限されたコンテンツ
    リンクがはってあっても、ユーザ名とパスワードがわからなければ、入りこみようがない。
  • スクリプト化されたコンテンツ
    Flash などに含まれるテキストは読めないし、JavaScript にリンク先のページの URL が仕込まれていても入っていきにくい。
  • 非テキストコンテンツ
    画像や動画、バイナリーデータなど(MS Word や Excel、PDF なんかだったら、Google とかは解析しちゃうけど)。
……といった状況や理由でこうしたコンテンツは、検索エンジン(クローラ)泣かせと言われている。

今回フィーチャーしたいのは、その中でも「動的コンテンツ」だ。Bergman の論文でも主に取り上げられているのは、この動的コンテンツの部分。いわく、「深層ウェブには、表層ウェブの 500 倍のデータがある」、「深層ウェブの情報は品質の高いものが多い」……とのこと。量的な話で言えば、500 倍が正しいかどうかはわからないが、でも直感的に言って相当量あることはまちがいない。検索エンジンはともかく、ウェブ上で一般公開されているデータベースサービスなんてのは山のようにある。書誌情報を元に書籍の検索サービスを提供している Webcat Plus とか、ローソンの店舗検索とか、中古カメラの検索とか……。まさに枚挙にいとまなし。

こういうデータベース検索サービスの大きな分かれ目が、前回の「URL のよくわかんないアレ」でも取り上げた「GET」と「POST」だ。おさらいしておくと、大雑把に言って「GET」は「?」とか「&」とかよくわかんない記号がごちゃごちゃっとくっついている検索結果ページなんかを表示するやつ。「POST」はそんなののないすっきりしたやつ。見栄え的には、すっきりしているのがいいけど、URL による検索結果の再現性がないのが「POST」のイタイところ。

「POST」の再現性のなさの話。さっき例に挙げたローソンの店舗検索(http://map.lawson.co.jp/c/f)。Step 1 は無視して、Step 2 の「住所」にサンプルに従って、「町田市」と入力して検索。「町田森野一丁目店」を筆頭に 17 件の検索結果が表示される。そのときの URL が、「http://map.lawson.co.jp/c/f/」。さらに、「町田森野一丁目店」の詳細情報を見るべく、リンクをクリック。詳細情報ページの URL は、「http://map.lawson.co.jp/c/f/」。友だちに「町田森野一丁目店」の詳細情報の URL を教えようと思ったら、「http://map.lawson.co.jp/c/f/」を教えるしかない。教えられた友だちは、その URL をクリックする。すると、ローソンの店舗検索のトップページが表示される。これが、「POST」データの再現性のなさということ。

もうすこし詳しく見てみる。ここにはクローラにとって二段階の障壁がある。ひとつめは、「町田市」のような検索文字列の入力。もうひとつは、「町田森野一丁目店」のリンククリック。クローラが検索質問を自発的にしない以上、ここから先に進みようがない。「町田森野一丁目店」はクリッカブルな状態になってはいるものの、JavaScript を実行しなければ、検索結果が表示されないので、クローラには侵入不能。

「町田森野一丁目店」のページには、店舗の住所とか詳細情報が掲載されているので、それをキーワードにして検索してみる。試しに店舗名と電話番号で。Yahoo! JAPAN → 0、Google → 0。要は、「町田森野一丁目店」は索引化されておらず、深層ウェブの底に沈んじゃっている状態ってことだ。検索文字列を「店舗検索」として検索した結果、ローソンの店舗検索トップは、Yahoo! JAPAN で 1 位、Google でも 2 位の表示順。こんなにハイランクなのにクロールしてもらえないってのは、なんかもったいない気がするなあ(店舗数が多すぎるってのもわかんなくはないけど)。SEO の大前提で、「POST」でなく、「GET」がオススメされる理由はコレ。「GET」で呼び出せる動的ページであり、静的ページにその呼び出しのための URL がリンクとして記載されているとクローラにやさしいページになる。

次にピックアップするのは、クローラが、ごちゃごちゃした URL を嫌うと言う話。前に「検索エンジンってどんなもの?」を書いたときには、省略してしまったけど、索引を作るときに「重複ページの削除」という仕事もやっている。要は同じ内容のページを削除するということ。複数社のブログサービスを使って、一言一句変わらない同じ記事を書いたりする人がいたりして、それはそれで鬱陶しいんだけど、これは別次元の話。例えば、以下の URL。Ask.jp で「apple」とウェブ検索した結果。URL は微妙に違うけど、全部得られる結果はすべてまったく同じ内容。

  1. http://ask.jp/web.asp?o=0&qsrc=3&ln=ja&q=apple&btnWeb.x=11&btnWeb.y=7
  2. http://ask.jp/web.asp?o=0&qsrc=3&ln=ja&q=apple&btnWeb.x=67&btnWeb.y=2
  3. http://ask.jp/web.asp?o=0&qsrc=4&q=apple&btnWeb.x=39&btnWeb.y=11&ln=ja&ps=
  4. http://ask.jp/web.asp?o=0&qsrc=96&q=apple&hq=&btnWeb.x=46&btnWeb.y=10
ユーザとしての作業は以下のとおり。
  1. Ask.jp のトップページで「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンの左上の方をクリック
  2. Ask.jp のトップページで「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンの右下の方をクリック
  3. Ask.jp のウェブ検索の検索結果ページの検索フォームに「apple」と入力し、検索フォーム右にある「ウェブ検索」ボタンをクリック(場所は意識せず)
  4. Ask.jp のブログ検索の検索結果ページの検索フォームに「apple」と入力し、検索フォーム下にある「ウェブ検索」ボタンをクリック(場所は意識せず)
1 と 2 の違いは、「btnWeb.x」と「btnWeb.y」の値の違い。1、2 と 3 や 4 の違いは、「qsrc」の違い。ユーザにとって重要な意味を持つのは、「http://ask.jp/web.asp」というプログラムへのリクエストであるということと、「q=apple」という検索文字列だけ。実際問題、必須要素だけを残した「http://ask.jp/web.asp?q=apple」でも同じ結果が表示される。人間だったら、なんとなく想像してこうやって URL の単純化もできちゃうけど、クローラにまでその判断をして、重複ページを削除しろというのは厳しい話。そんなことをやっている間に、他にやらないといけない仕事は山のようにある。これが、SEO のコンテクストで「カタログページの URL は、Amazon みたいにした方がいいですよ。検索エンジンに嫌われますよ」とよく言われる所以。Amazon の検索結果は、URL に含まれる「?」や「&」がかなり少ない。無作為にいくつかの書籍の URL をチェックした見たけど、「ie=UTF8」というのと「s=books」だけだった。

特別な理由がなく、かつ持っているデータを検索エンジンに索引化してもらいたいんだったら、フォームはとにかく「GET」。静的ページからのリンクも用意。さらに、プログラムの引数(URL に含まれる「x=yy」みたいなもの)もシンプルに。でないと、コンテンツは深層ウェブから引き上げられる可能性は極めて低い。

こういう目で見ていくと、Wikipedia のURL は極めてシンプル。英語版の Wikipedia の URL は、「http://en.wikipedia.org/wiki/Apple_Computer」。以前だったら、Wikipedia なんてのも「良質なコンテンツなんだけど、深層ウェブだから、Wikipedia に行って検索しなきゃいけないんだよね〜」となってたところなんだろうな。この辺の設計が、Web 2.0 時代の CMS(コンテンツマネジメントシステム)って感じがするな〜。

※この記事に記載した URL の数々。けっこう途中で切れちゃってるけど、ちゃんとリンクは生きている(はず)。

2007/06/03

URL のよくわかんないアレ

前回の「文字コードについて」では、URL のヒミツ(っていうほどでもないけど)をすこし覗いてみた。なんだかよくわからない文字がごにょごにょって書いてあるアレ。きょうはアレをもう少し見ていこう。

この記事を書くのに使っているパソコンは、Macintosh PowerBook G4。ブラウザは、Firefox 2.0.0.4(ウェブブラウザのひとつ)の日本語版。ブラウザの右上に検索プラグイン(ここに文字を入力すると、選択されているサービスで検索できる)がついている。そのプラグインから Yahoo! JAPAN を選択。「東海林さだお」と入力し、検索実行。すると、Yahoo! JAPAN のウェブ検索結果が表示される。そのときの URL は、

http://search.yahoo.co.jp/search?p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A&ei=UTF-8&fr=moz2&rls=org.mozilla:ja-JP:official

こんな感じ(もしかしたら途中で切れてるかも……)。これを細かく分解して見ていこう。分解のカギは、「?」と「&」。

  • http://search.yahoo.co.jp/search?
  • p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A
  • ei=UTF-8
  • fr=moz2
  • rls=org.mozilla:ja-JP:official

読みにくくなるので「&」は省略したけど、こんな感じ。前回の記事を読んだ人はわかると思うけど、「%E6%9D%B1%E6%B5%B7%......」の意味するところは検索文字列に相当するもの、「ei」が検索文字列の文字コードってこと。これを上から順に翻訳していくとこんな感じ。
  • http://search.yahoo.co.jp/search?
    • これから「http://search.yahoo.co.jp/」の「search」というプログラムに問い合わせをしますよ
  • p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A
    • 検索文字列(p)は、「%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A」ですからね
  • ei=UTF-8
    • 検索文字列の文字コード(ei)は、「UTF-8」ですよ
      • だから、「%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A」は「東海林さだお」って読めるでしょ
  • fr=moz2
    • 検索文字列がどこから入力されたのか(fr)って言うと、「moz2」ですよ(Firefox 2 のこと? あるいはその上位カテゴリ)
  • rls=org.mozilla:ja-JP:official
    • これ、なんだろ? 日本語版の Firefox のオフィシャルプラグインからの入力ですよってことかな?

つまり、Yahoo! JAPAN のウェブ検索プログラムに、なんだかんだと条件を指定しているということがわかるだろう。ユーザの意識に残っているものといえば、「東海林さだお」という検索文字列だけなんだけど、Firefox の検索プラグインを使うという行為により、検索プラグインに仕込まれているいくつかの情報がセットで送られているということだ。

Firefox の検索プラグインは、XML 形式で記述されているけど、その中身を見てみると……

<url type="text/html" method="GET" template="http://search.yahoo.co.jp/search">
<param name="p" value="{searchTerms}">
<param name="ei" value="UTF-8">
<mozparam name="fr" condition="pref" pref="yahoo-fr-cjkt">
<param name="rls" value="{moz:distributionID}:ja-JP:{moz:official}">
</url>

……こんな感じ(関係のある部分だけ抜粋)。{ } で囲まれている部分は、変数。例えば、{searchTerms} は検索文字列、{moz:distributionID}、{moz:official} あたりは、Firefox の規定値を参照することになっているものだろう。HTML を書いたことがある人ならわかると思うけど、FORM の記述方法にとても似ている。その書き方に無理に翻訳すると……

<form method="GET" action="http://search.yahoo.co.jp/search">
<input type="text" name="p" value="{searchTerms}">
<input type="hidden" name="ei" value="UTF-8">
<input type="hidden" name="fr" value="moz2">
<input type="hidden" name="rls"
value="{moz:distributionID}:ja-JP:{moz:official}">
</url>

……こんな感じだろうか(mozparam のところはちょっと手抜きした)。「input」は、文字どおり入力文字列を受け付けるタグ。その中でも「type="text"」となっているものは、ユーザの画面上にテキスト入力欄が表示される。それに対して「ei」と「fr」、「rls」は「type=hidden」なっている。「hidden」で送信されるものは、ユーザの画面上には表示されない。なので、ここはユーザの意志と無関係に規定値などが記入される。用途はさまざま。これによって、プログラムの挙動が変わったりすることもあれば、一見何も変化の起きないこともある。今回の例で言えば、「fr」と「rls」はユーザに対しては特に大きな役割は果たさない。おそらくクエリ分析に利用されるもの(どこからリクエストが来たかを判定するとか)。なので、それらを削っても、ユーザとしては得られる情報は同じもの(少なくともそう見える)。

http://search.yahoo.co.jp/search?p=%E6%9D%B1%E6%B5%B7%E6%9E%97%E3%81%95%E3%81%A0%E3%81%8A&ei=UTF-8

「hidden」の項目がユーザの画面やプログラムの処理結果に影響を与えるかどうかを知るには、どうすればいいかということになるとすこし難しい。ひとつひとつ試してみるしかない。URL 欄に表示されたものをちょこちょこいじってみる……ということになる。

FORM で重要なのは、どんな情報をユーザから受け付けて、どんな情報を補助情報(ユーザの入力に委ねないもの)として送信するかということ。補助情報は、「hidden」で送信される。

もうひとつ重要なことがある。それは、「GET」と「POST」。さっきの例で言えば、

<form method="GET" action="http://search.yahoo.co.jp/search">

…で、「method="GET"」となっている。「method="GET"」であっても、「method="POST"」であっても、データがプログラムに送信されるのは同じなんだけど、送られ方がずいぶん違う。Yahoo! JAPAN のウェブ検索プログラムが「method="POST"」で送信されたデータを受け付けるかどうかはわからないけど、それが受け付けられるとすると、

<form method="POST" action="http://search.yahoo.co.jp/search">
<input type="text" name="p" value="{searchTerms}">
<input type="hidden" name="ei" value="UTF-8">
<input type="hidden" name="fr" value="moz2">
<input type="hidden" name="rls"
value="{moz:distributionID}:ja-JP:{moz:official}">
</url>

での送信結果の URL は、

http://search.yahoo.co.jp/search

となる。つまり、URL の後半部のごにょごにょがなくなってしまうわけ。そうなると、上の URL をクリックしてもらえばわかるけど、検索文字列を入力して送信した結果の URL なのにその URL を後で再利用しようと思っても、同じ画面はユーザに提供されない……ということ。例えば、Yahoo! JAPAN で「吉祥寺 いせや」と検索した結果のページの URL をともだちに知らせてあげようと思っても、「http://search.yahoo.co.jp/search」しか表示されないので、それをともだちがそれを受け取っても同じ検索結果画面を見ることができない。つまり、再現性がないというわけだ。フォーム送信するようなページは、「GET」にしておかないと、検索エンジンにインデックスされない……ということが SEO の文脈で言われたりすることがあるけど、これも「POST」で生成される URL の再現性のなさが原因。

じゃあ、なんでも「GET」だったらいいのかというとそうでもない。「GET」には、文字数制限や情報の秘匿性の脆弱さということがある。WWW のさまざまなお約束を策定している W3C で規定されていたかどうかはわかんないけど、Microsoft の Internet Explorer だと、2083字(半角英数字)以上の URL は処理できないようだ。

情報の秘匿性の脆弱さについては、ログインフォームを考えるとわかりやすい。ID やパスワードを入力して送信するというのがログインフォームの仕事なわけだけど、「GET」で送信するということは、URL に ID やパスワードがまるわかりの状態で流れてしまうということ。これでは情報流出のリスクがある。Yahoo! JAPAN は、「GET」送信のフォームが多いけど、ログインフォームはきちんと「POST」送信になっている(それに加えて、送信内容を暗号化するようにセキュリティサーバを利用している。「https」で始まる URL はセキュリティサーバで保護されていることの目安)。

<form method="post" action="https://login.yahoo.co.jp/config/login?"
autocomplete="off" name="login_form">

「GET」がよいのか、「POST」がよいのか、そのメリットとデメリットを考えていくのが大事。

2007/06/01

文字コードについて

タイプライターが好きで、小学生のころから Olivetti ※のタイプライターのキーを叩いていた。母親が会社で使っていたのがこの写真にある和文タイプライター。英文タイプライターは、キー配列はパソコンとほとんどいっしょ。和文タイプライターは、構造からしてまったく違う。写真に見える白い部分に升目が引いてあって、その升目の中に小さな文字が印刷されている。盤面に黒いノブのようなものが写っているけど、これで盤面の文字を探す。打刻したい文字がみつかったら、そこでノブを押す。そうすると、その文字が紙に印字される……というモノ。ノブをカチッと押す(現代的な表現で言えばクリックする)と、その活字を拾って、インクリボンに向けて活字を叩き付ける……という仕掛け。

和文タイプライターの盤面に整然と並んでいる文字たちのことを考えていると、文字コードの配列表を連想する。コンピュータで記述する文字はすべてなんらかの文字コードに従って、ID とでもいうべきもので整理されている。ウェブブラウジングが一般化する前は、ワープロを使ったりするときも、文字コードを気にしたりすることはなかった。強いて言えば、Windows で作成した文書を Macintosh で開くと、一部の文字が文字化けするなんてことぐらいだろうか。最近はそんなことも少なくなったけど、ウェブブラウジングの普及以降、ブラウザで開いたページがまるっきり文字化けしていて読めない、そんなときはブラウザのメニューから文字コードをいじってみたり……なんていう経験は誰しも一度はあるんじゃないだろうか。Shift JIS となっていたものを、EUC-JP に変更したら読めた……っていう経験。

どんな風に文字が整理されているかと言うと、こんな感じ。「亜」という字であれば、16 区の一列目にいる。Shift JIS だったら 16 区は、889E。「亜」の字が配置されているのは、+1 の列。これを組み合わせて、889E + 1 = 889F ※※。EUC-JP だったら、同じ 16 区で、同じく +1。でも、基礎となる数字が B0A0。なので、「亜」は、B0A0 + 1 = B0A1。つまり、同じ「亜」の字であっても、

  • Shift JIS の「亜」:889F
  • EUC-JP の「亜」:B0A1
……なので、コンピュータの中ではまったく別の ID で管理されている。いわば、別の暗号表に割り当てられていると言っていい。そのため、暗号表(文字コード)が違っていれば、「ちゃんと解読できない」→「文字化けする」……という状況が発生するわけだ。

この B0A1 とかって、どこかで見たことない? 例えば、Yahoo! JAPANとかで検索したときにブラウザの URL 欄でよくわからない文字列がごちょごちょっと書かれているアレ。Yahoo! JAPAN のトップページから「亜」と検索してみる。すると、URL 欄に表示されるのが、

http://search.yahoo.co.jp/search?p=%B0%A1&ei=euc-jp

……こんな文字列(説明に不要な部分は省略してある)。この %B0%A1 が「亜」の B0A1。後ろの「ei=euc-jp」は、「検索文字列は、EUC-JP の暗号表で暗号化されてますよ」と言う意味。これをサーバが受け取って、EUC-JP の暗号表で解読する。excite だと、

http://www.excite.co.jp/search.gw?search=%88%9F

……こんな感じ。これは言うまでもなく、Shift JIS の 889F。

最近は、UTF-8 なんて文字コードもよく見かける。Google なんかは、どのページも UTF-8 で書かれている。そんな Google で検索したりすると、

http://www.google.co.jp/search?q=%E4%BA%9C&lr=lang_ja&ie=utf-8&oe=utf-8

……と表示される。さっきからの類推で行けば、%E4%BA%9C か。UTF-8 の文字コード表を参照すると、確かに E4BA9C とある。「ie=utf-8」は、Yahoo! JAPAN の「ei=euc-jp」が「検索文字列は、EUC-JP の暗号表で暗号化されてますよ」と言っているのと同様に、Google は、「ie=utf-8」で「検索文字列は、utf-8 の暗号表で暗号化されてますよ」と言っている(ちなみに oe は検索結果ページの文字コード指定)。試みに Google に検索文字列「亜」をShift JIS で送ってみる。

http://www.google.co.jp/search?q=%88%9F&lr=lang_ja&ie=shift_jis&oe=utf-8

さっきの検索結果と同じものが表示される。

UTF-8 は、新しい文字コードの規格で、これまでのShift JIS や EUC-JP と比較して、圧倒的に多数の文字を表の中に格納することができる。大雑把に言えば、Shift JIS や EUC-JP は、日本語の文字が担当範囲。UTF-8 は世界各国の文字が担当範囲。文字コードが UTF-8 だったら、同じページの中で、中国語、韓国語、日本語を同時に表示できちゃう(もちろんロシア語でもタイ語でも)。Yahoo! JAPAN は、長年文字コードを EUC-JP で統一してきていたけど、翻訳サービスなんかは、UTF-8。この理由も UTF-8 が多国語を扱えるというところにつきる。

こんな風に考えていくと、なんだかよくわからなかった文字コードなんてのもおもしろく思えたりしない?

おまけ:「亜」が URL の中で「%E4%BA%9C」(UTF-8)で暗号化されてるというのは、ここまでに説明したとおり、この暗号化を「URL エンコード」っていう。覚えておいてもいい用語かも。(07/06/04 追記)

※ Olivetti:イタリアのタイプライターメーカー。赤い Valentine っていうのが代表的な製品。こいつがなんともいえずスタイリッシュ。いまの Valentine は、プリンターなんかのメーカーになっちゃったけど、

※※889F:F は、文字ではなく、16 進数の数字。0123456789ABCDEF という順番。つまり、A は、10 進数だったら、11。なので、E は、15。15 + 1 = F = 16。

2007/05/30

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」というファイル名の写真をアップしてたことに気づいた。。。さすがに「つけ麺」じゃないけど。

2007/05/25

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

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

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

  • キーワードを入力する
  • 検索ボタンをクリックする
  • 検索結果が表示される
    • ページタイトルや URL、ページコンテンツの抜粋を閲覧できる
    • ページタイトルや URL をクリックすると、そのサイトを閲覧できる
これを実現するためにどんなことが裏側でおこなわれているか……という話。ごく簡単に書くと、こんな感じ。
  1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく
  2. 採取されたページコンテンツは、URL を基準に整理され、分析される
  3. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス(索引)化される(形態素解析しない場合もある)
  4. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する
  5. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される
ざっくりとした説明なので抽象的なところも残っている。もう少し詳しく見ていこう。
  1. 台帳に基づいて、クローラがいろんなウェブサイトを訪問して、ページ上のリンクをたどりながら、ページコンテンツを採取していく
クローラの業務内容は比較的シンプルなイメージで説明できる。
  • ウェブページを開く
  • そのページを保存する
  • そのウェブページに書かれているリンクをたどって、別のページに行く
の繰り返し。どこから見ていくかということなんだけど、その元になるのが「台帳」。この「台帳」のことを「Seed」(種)と言う。イメージとしては、巨大なブックマークリスト……が近いだろうか。これを見ながら、次から次へとページを渡り歩いて、ページコンテンツ採取をコツコツとこなしていく。そうしてデータが集まってくると、
  1. 採取されたページコンテンツは、URL を基準に整理され、分析される
このページとあのページがリンクされているとか、外部のサイトにリンクしているとか、このページは他のページからどれぐらいリンクされているか(被リンク)……といったリンク構造や、ページの作成日(更新日)などの分析がおこなわれる(Google の有名な Page Rank の基礎データもここで取得できるものなんじゃないかな)。次に、
  1. 採取されたページコンテンツのテキストデータは、形態素解析されて、インデックス(索引)化される
どんな形態素解析処理(Cf. 「コンテンツ連動型広告の仕掛けを考える〜その弐」)をおこなっているのかは、検索結果ページからちょこっと見られたりする。Yahoo! JAPAN の場合だと、検索結果に「キャッシュ」っていう地味なリンクがあったりする(必ずあるわけじゃない)。そこを開いたときに、ページ上部にボックスが表示されて、そこに自分の入力したキーワードに何色かの背景色が付いて表示されているのを見たことがあるんじゃないかな(本記事の画像をクリックするとサンプルが見られる)。ユーザとしては、それを元に検索結果ページのどこにその文字列がどこに記述されているかが、背景色でハイライトされているので、見つけやすい……と言った用途に使うもの。実は、コレが形態素解析の結果。たとえば、「現代用語の基礎知識」だと、
  • 現代
  • 用語
  • 基礎
  • 知識
……と分解される。採取されたページコンテンツ(テキスト)は、こんな風にバラバラに解体されて、ウェブ検索のインデックス(索引)データとして利用されているわけだ。つまり、「現代用語の基礎知識」という検索文字列で検索した場合には、「現代」「用語」「の」「基礎」「知識」が含まれているページが検索されることになる。たまに「インデックスがアップデートされた!」というニュースが出たりする(SEO 業界を中心にちょっとした騒ぎになることもしばしば)けど、このインデックスの更新が意味するところは、ここで紹介したような内容(同時に新規ページのインデックスへの追加やなくなってしまったページのインデックスからの削除もおこなわれる)。

こうして索引ができて検索可能になった段階で、
  1. ユーザから与えられた検索文字列をインデックスに照らし合わせて、該当ページを抽出する
……ことになる。ココの部分が、狭義としての「検索エンジン」ってことになるんだろう。抽出すればそれでオシマイと言うわけではないのが難しいところ。いかにして、ユーザが探したいものを最短の時間、最小の労力で提供するかというのがサービスとしての検索の要となる。
  1. 該当ページは、妥当だと思われる順番に並べ替えられて、検索結果として提供される
……が重要となるわけだ。やはり単純にサービスを使う立場としては、いち早くお目当ての結果にたどりつきたい。「検索結果は、Google がいいね」とか「いや、Yahoo! も最近はかなりいいよ」とかそういう文脈で語られる良し悪しの多くは、ここの結果のアウトプットに起因する。大量の検索語でひとつひとつの検索結果を各社のサービスで調べて、一定のルールでそれらを評価すると、それなりの結論は出るようにも思うけど、ユーザの主観やそのときのユーザの意図によって印象は変わってきてしまうものではある。また、同じ会社のサービスであっても時期によって、チューニングが異なっていたりするので、一概にどこのサービスがいいというのは難しい。じゃあ、何をベースにチューニングするかということなんだけど、メジャーなものとしてはこんなものがある(個人的におもしろいなと思う順番に)。
  • どんなキーワードでそのページがリンクされているか
    有名な例としては、「18歳未満」で検索すると、Yahoo! JAPAN のトップページが上位にランクされる……というヤツ。アダルトサイトとかで「18歳未満はこちら」というテキストリンクが、Yahoo! JAPAN などに誘導するというケースが多い)
  • 検索キーワードの近接性
    「中華料理」での検索だったら、そのままズバリの「中華料理」と書かれているページの方が、ページのどこかに「中華」とか「料理」とかバラバラに記述されているものよりも関連度が高いだろうという考え
  • そのページがどれだけのページからリンクが張られているか
  • そのページがどれだけ人気のあるページからリンクが張られているか
    SEO 業者が「まずはYahoo! JAPAN のディレクトリ登録を」とオススメしてくる根拠
  • 検索キーワードのそのページでの扱われ方
    SEO のテクニックでよく言われる「H1 タグで囲まれていると評価が高い」……とか言うアレ
……などなど。どの要素をどれだけ重視するかというのがチューニング。SEO 業者は、その特徴を帰納法的に類推し、試行錯誤する。ランク上位表示を目指して、荒技(リンクファーム:Link Popularity を上げるためだけの意味のないリンクの張り合い)なんかで検索結果を荒らす者もいる。検索エンジン側でそうした行為を無にするような新たなチューニングを投入する……イタチごっこ。SEO 業者の日々の糧はそこにある。

2007/05/23

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

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

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

  1. クローラが取得したコンテンツは、解析サーバにより解析される
ここから。ページコンテンツを取得したら、そこからそのテキストが扱っているトピックを抽出しなくてはいけないわけだけれど、まずは、形態素解析という処理が必要になる。形態素解析というのは、簡単に言えば文章の構成要素を細切れにする作業。分かち書き。例えば、「うどんは讃岐に限る」という文章は、
  • うどん
  • 讃岐
  • 限る
と分解できる。この分解のときに、
  • うどん(名詞)
  • は(助詞)
  • 讃岐(名詞)
  • に(助詞)
  • 限る(動詞)
こんな感じで、品詞分類(上記の例はかなり雑に分類してるけど、ホントはもっと詳しい)もついてくる。名詞や動詞、形容詞なんかは、大分類では内容語とカテゴライズされて、助詞なんかは機能語とされる。重要なコンセプトの抽出に助詞などは、さほどの影響は及ぼさないだろうということで、捨てちゃう。そうなると、
  • うどん
  • 讃岐
  • 限る
が残る。これだけでも原文のコンセプトは十分判断できるよね。その中からさらにコンセプトを含む確率が高いものということで、名詞を取り出す。
  • うどん
  • 讃岐
ずいぶんとすっきりした。「讃岐うどんはまずい」という文章だってあるじゃないか……という意見もあるだろうけど(ネガティブイメージな文章に広告を出すのかという議論もちょっと脇に置いておいて)、
  • 讃岐
  • うどん
  • まずい
なので、テーマが「讃岐うどん」であることには変わりない。シンプルな文章を例に出したので、あっさりとしてしまったけど、本当はその文章の周囲には、
  • 先月の出張で、香川に行った。
  • 香川の取引先の山田部長はなかなかの人格者で、彼を慕う部下も多いと聞く。
  • 彼のチームメンバーからいろいろお話を聞くことができた。
  • 山田部長の若いころのエピソードで面白かったのは、食い道楽の話。
  • あんなスリムな人なのにありえないぐらい食べるらしい。
  • なんでも近くのうどん屋でうどん七玉食べた後、もう一軒別のところに行ってそこで三玉。
  • ありえない。。。
  • しかし、山田部長のオススメのうどん屋さん、マジうまいっす。
  • やっぱり、うどんは讃岐に限る。
……などという文脈があるとすると、もう大変。名詞の量がずいぶん多い。そうしたときに使える手法とオーソドックスなのは、特定のキーワードの出現頻度を利用するという手法。文章を通して、何回「山田部長」や「うどん」が登場したか……ということ。「うどん」、「うどん」と何回も言ってるぐらいだから、「うどん」は重要なキーワードなんだろう……という推測。ただ、これだけでは重要なテーマは、絞りきれない。

さっきの文章では「山田部長」だけがフィーチャーされていたけど、「山田部長はじめ、高橋部長、佐藤部長には大変お世話になりました。 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! のウェブ検索の総文書数
これらの数値をぐにぐにっと計算すると、特徴となる語彙が抽出できる……というもの。ここにはデモインターフェイスが置いてないのが残念。。。前に動いているところを見たことあるけど、かなりおもしろい♪

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

こうして、文章の特徴となる言葉が抽出されて、じゃあ次は……ということになると、
  1. 商品引き当てサーバは、解析結果に基づき、妥当な商品を商品データベースから検索し、オススメ商品データを返す
……というのが大きな山になりそう。
  • 抽出されたキーワードで商品データベースを検索する
  • 検索結果が複数ある場合、その中でいちばん売れそうなものから順に表示候補にする
この「売れそうなもの」っていうのがクセモノ。
  • 文書との関連度が高いから「売れそう」
  • 文書との関連度は若干低いけど、けっこう売れてるから「売れそう」
  • 文書との関連度は全くないけど、むちゃくちゃ売れてるから「売れそう」
おおざっぱに言えば、こんな感じなんだろうか。

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

とはいえ、AMAZON のコンテンツ連動型広告の場合は、
  • 書籍に付随するメタ情報(著者名や出版社名、書籍の概要)
  • 関連づけの対象となる商材が有限であること(バリエーションが多いとはいえ限られている)
  • 商品ごとの売り上げ情報(売り上げランキング)
  • その商品といっしょに買われた商品
  • 検索から購買までのコンバージョン情報
  • カスタマーレビュー情報
  • リストマニア!(個人のオススメ作品リスト)
……などなどパラメータとして利用できそうな付帯情報がもりだくさん。今後の展開にかなり期待♪

2007/05/21

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

以前 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 リーダーが普及するまでは、そのページが更新されたかを確認するには、そのページに行ってみる……などの原始的な手段しかなかった。

2007/05/19

Roland Barthes と Web 2.0

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

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

Roland Barthesこの記述に出現するいくつかのキーワードを以下のように置換してみたらどうだろう。
  • 文芸評論理論 → 現代のインターネットをめぐる環境
  • 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 SaussureFerdinand 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 は、以下のページで日本語で読むことができる。
※写真は、Wikipedia より拝借。しかし、本家 Wikipedia の記述は、クオリティが高いなあ。日本もがんばらないと。。。

2007/05/18

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

なんだか西海岸では、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」が使えたりするけど。

2007/05/17

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

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

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

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

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

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

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

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

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

【まとめ検索】
「キーワードの注目度」モジュールの上あたりにひっそりと「検索結果をまとめて表示」という地味なリンクがある。これもなかなかおもしろい。クリックした先にあるページはこんなもの。左カラムにキーワードが並んでいる。おそらく「水曜どうでしょう」が含まれるブログ記事に特徴的な頻度で出現している語彙のリストだろう(抽出方法は、TF/IDF だろうか)。少し変なものも含まれてはいるけど、けっこういいリストかも。
  • 水曜どう、大泉洋、北海道、放送、classic、番組、TEAM NACS、最新作、クラシック、本……
これらのキーワードの重なり具合をベースにブログ記事を束ねているように思われる。この機能、地味ながら検索支援という意味でかなり示唆に富むもの。自分のよく知っている話題であれば「ふーん」で終わってしまう話題なんだけど、よく知らない話題の場合だとかなり意味がある。ウェブ検索の場合は、
  • snippet(すにぺっと:検索結果の下に表示される本文中のテキストなどを抽出したもの)を読む
  • 実際に検索結果ページにリストされているページに行って、コンテンツを拾い読みして、なんとなく関連しそうなキーワードらしきものを拾いだす
という作業が必要なのだが、その作業を省力化してくれる試みと言えるだろう。

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

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

2007/05/16

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

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

自分のかかわったプロジェクトがどんな風に世の中に受け入れられているのか気になるでしょ。そんなときどうする?Yahoo! JAPANや Google のウェブ検索でチェックしてみる? でもちゃんと口コミを集められるかどうかはわかんないよね。口コミチェックならやっぱりブログ検索! ブログ検索は、ウェブ検索と違って、いろんな会社が参入している。ウェブ検索の覇者、GoogleYahoo! JAPAN はもちろん、livedoorgoo などのポータルでも早期からサービスインしている。TechnoratiAsk.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 を参照のこと)。
なんだかごちゃごちゃいろいろ文字の含まれている長い URL。検索結果画面の左カラムを見てほしい。ここに「フィードを取得 Atom | RSS」とある。「Atom」と「RSS」の違いは別の機会に譲るとして、「RSS」をクリック。すると、こんな URL(クリックして URL を参照のこと)。
これが今回の 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」で作り込んでいって、パイプでつなげて、完成〜♪ 検索語を入力して、いろいろ試してみてください〜。

2007/05/15

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年後にも「あ〜、こんなんあった、あった〜」と思えるんじゃないか……と。