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。