ラボ神部です。

PHP の PEAR ライブラリ XML_RSS はよく働いてくれ本当に助かっていますが、RSS ではなく Atom を読み込ませたいときには少し困ってしまいます。そういうときはブログのタイトルと偽りありで申し訳ありませんが XML_RSS ではなく素直に XML_Feed_Parser を使いましょう。

詳しくはこちらのブログで。

-Atomのフィードを取得できるPEARのライブラリ　XML_Feed_Parser (たつやブログ)

XML_RSS と XML_Feed_Parser の扱いはほとんど同じですが、若干違うのは、

XML_RSSでは

$rss =& new XML_RSS("http://rss.slashdot.org/Slashdot/slashdot"); $rss->parse();

と初期化するところを、

XML_Feed_Parser では

$text = file_get_contents($atom_url); $feed = new XML_Feed_Parser($text);

と二段階で行い、

値の取り出しは

foreach のイテレータで $item で取り出したとき、

XML _RSS では

$item['title']

とるすところを、

XML_Feed_Parser では

$item->title

と取り出すところくらいです。

元のフィードの種類で自動的に切り替わるような関数をつくってみても便利かもしれませんね。

ラボ神部です。

Adobe AIR のプロダクト、なにか作ってみたいです（主にウェブカムセンシング系）。そこで、役立つ Adobe AIR 関連のエントリを、このブログエントリで集めてみようと思います。

-【ハウツー】AIR自作工房 - Adobe AIRで創るアナログ時計 (1) 身近なアナログ時計をAIRでつくろう | パソコン | マイコミジャーナル・・・０からのステップアップにちょうどよさそうな記事

-いまさら聞けないAdobe AIR「超」入門（1/4）- ＠IT・・・こちらはデジタル時計。今年一月時点のものなので、多少現況と違っている部分もあるかもしれませんが。

-Adobe AIRアプリ いろいろ - DesignWalker・・・海外版ですが、AIR クライアントのサンプル。デスクトップの争奪戦がはじまっていますね・・・。

ラボ神部です。

今日はまるでどこかにブログのお題ゲッターがあるかの如く、Google Chrome についての話題でもちきりです。国内のエントリをまとめて見ようかと思いましたが数も多いですし誰か他の人がやっていそうな気がするので、海外のブログエントリの変わった反応をまとめてみます（海外と行っても、英語ブログだけですけどね）。

-Google Chrome Review ***** 5 stars I love it | Google Chrome Browser

ごく普通のエントリに見えますが、実はこのブログ自体 Google Chrome Browser と言う名前。どうやらSEOスパムのチャレンジのようです。機能紹介やよい点などについてありきたりに述べ、まんまと Technorati 検索で一位をゲットしています。この個人か会社は、バズワードが出るたびにこういうことを繰り返しているのでしょうね。

-Google Chrome - Sean Percival's Blog

DocStoc という Flash Paper のようなドキュメント共有サービスで、Google Chrome について紹介したコミックの転載を行うとともに、コミックの感想を述べています。コミック部分を読むためのインターフェースとしては、Google が用意したものよりもかなり見やすい感じです。このコミックももうちょっとおおらかなライセンスだったら、各国語訳とか出てきて盛り上がりそうなのに。

-stationsvakt: Video: Google Chrome

Youtube を探せば見つかるのかもしれませんが、Google Chrome に関するビデオです。先ほどのコミックの内容とかぶる部分もあるかもしれないですね。

-Google Picasa 3.0 launched

Google は Chrome をリリースしたが、 Picasa 3.0 もリリースしたよというエントリ。こちらもメジャーアップデートだそうで、本当だとしたら Picasa 利用者は要注目ですね。

と、軽く４件を Technorati を使って検索してみましたが結構見ない切り口もあり面白い感じです。検索エンジンの検索結果においても、日本は大いなるガラパゴス状態に陥ってしまっているのかもしれませんね。次は日本語環境からの英語リソースの検索方法とかまとめたくなってきましたが、とりあえずこんなところで。

突然ですが、
データベースは好きですか？

データベースといってもおカタいものを考える必要はありません。毎日見ているニュースサイトもニュースというデータの宝庫ですし、Google や Yahoo! のような検索エンジンだってウェブのデータをめいっぱいに詰め込んだ史上最大のデータベースです。ニコニコ動画だって YouTube だって動画のデータベースですし、携帯からもパソコンからもアクセス出来る掲示板も、ユーザコメントを集積しつづける回転のめちゃめちゃ速いデータベースです。あなたの時間をたっぷり盗んでいる Wikipedia はまさにデータベースの権化と言ってもよいでしょう。Amazon だって決済機能はついていますが元はと言えば膨大な商品データベースです。

そうなんです、今、楽しいものはみんなデータベースの中に入っているのです。よいものや楽しいもの、大事なことなどをデータベースにめいっぱい詰め込み、共有して検索してコメントを付けて、知らず知らずのうちに毎日夢中になっている自分に、みんなもっと早く気がついてこう叫ぶべきです。

「アイラブデータベーース！」

と。

紙とペンさえあればデータベースはつくれる

データベースの魅力は十分おわかりになっていただけたと思いますので、さっそく次はどうやったらデータベースを作れるか考えてみましょう！データベースを作るのは実に簡単です。

紙とペンさえあればデータベースはつくれます。

意外に思った方もいらっしゃるかもしれませんが、まずは紙とペンを用意してみてください。そして自分がお気に入りにしているお店のリストを書き出してみましょう。

・・・いくつか書き出せましたか？それでデータベースは完成です。この紙は、紛れもなく「あなたのお気に入りのお店データベース」なのです。ちょっと物足りないと思ったら、お店の名前の前に順番に番号を振ったり、お店の特徴や売っているものの種類を書き足してもよいでしょう。

ここで大事なのは、どうやってデータベースを作るかということよりも、どんなデータを集めるかというコンセプトを決めるのがなにをおいても大切だということなのです。ここは本当に大事です。自分の嫌いなものを集めても、データベースは充実していきませんし、データをメンテナンスしていこうという気も起きなくなってしまいます。しかしそこさえ間違えなければ、データベースを作ることの楽しさにどっぷりとハマれること間違い無しです。ファックスがあればできあがった紙データベースを、友達や家族に送ってみるとちょっとした話のネタになるかもしれません。これも立派なデータベースの共有です。

もっともっとデータベース作りを楽しむには

何枚も紙のデータベースをつくっていたら、さすがに疲れますよね。そんなときは文明の利器「パソコン」を使ってみましょう。あらかじめ「エクセル」みたいな表計算ソフトがついていればラッキー。今までは紙に書いていたリストを、そのままエクセルのシートに記入してしまいましょう。行番号も自動的についてとても便利です。リストを作り終わったら、名前を付けて保存しましょう。これでデジタル化されたデータベースの作成完了です！

デジタル化されたデータベースのすごいところは、共有がしやすいことです。できあがったファイルを電子メールに添付して送れば、たちまちデータベースの内容を他人と共有することが出来ます。ファックスの通話料金もかかりません！デジタルって便利ですねぇ～。

でも、この表計算ソフトを使った方法にはちょっと問題があります。編集しやすい分、エクセルのような専用のソフトが自分にも送る相手にも必要で、持っていなければ購入しなければなりません。それに、編集するたびにメールで送っていては自分もめんどくさいし相手にも迷惑です。これでは楽しくありませんよね！ では、どうしたら作ったデータベースを手軽に共有出来るでしょうか？

利用しちゃってよいデータベースはとことん使おう！

どうしたら作ったデータベースを手軽に共有出来るか？・・・実は、これは全然悩む必要はありません。既にあるものを使わせてもらえばよいのです！しかも利用料は無料。

食べ物のお店であれば、[食べログ.com]、お気に入りのデジタルガジェットや電気製品なら 価格.com、ブックレビューならブクログなども面白いです。デートスポットのデータベースのデート通.jpなんてものもありますし、食べ物もジャンルを絞れば ラーメンデータベースといったものもありますし、ドッグカフェデータベースもあります。こうしたデータベースを使うことのメリットはなんと言っても自分で管理しなくて良いことにつきます。とにかく自分が書き留めておきたいことを放り込んでおけば、あとは公開されたデータベースの方で自動的に公開し、整理して検索しやすくしてくれるのです。なんて楽ちんなんでしょう。

こういう既にあるウェブサイトと自分のフィーリングがマッチしたなら、あなたはめちゃめちゃラッキーです。楽しいデータベースライフをお送りください♪いつかあなたはその分野でのデータベースの星☆になれるかもしれません！

もっとわがままに、自分のスタイルでデータベースを作りたい！

自分の集めている情報のデータベースを見つけても、なーんかデザインが気に入らなかったり、登録がめんどくさかったりで好きになれないこともあるでしょう。そんなときは発想を転換して、ブログのレンタルサービスを使ってしまいましょう！数が多くなるので例は挙げませんが、たいていどんなブログでも、タイトルと本文という形式でデータを入力することが出来るので、入力フォームが多すぎて混乱することもないはずです。その上画像やビデオを添付したり、携帯から見られちゃったりするブログも多いので、安心してデータベースづくりに打ち込むことが出来ます。

あなたの家の近所の素敵な場所をリストにしていったり、自分がつくった作品を載せていったり、お茶の飲み比べや料理のレシピなど、自分が作りたいデータベースを作ることが出来れば、人生ホントに楽しくなってしまうこと間違いなし！

さらに上を目指したい！神レベルを目指したい人へ～

いや、自分はクチコミ的なサイトでも、ブログでも満足できないという人は・・・もうすっかりデータベースの虜ですね！！確かに自分の見せたい形でリストを見せたり、ページのデザインを統一感あるものにしたかったりした場合は、これまでのやりかたでは不満も出てくるでしょう。それに、自分だけが入力するのではなく他の人もデータベースを作るのに協力してくれたらもっと内容も充実するはず・・・！

ここから先は棘の道になりますが、そこまで思うなら一気にハイレベルな方法を紹介してしまいます。なにを言っているかわからないところもあるかもしれませんが、やらなければならないことは３つ。

１．ホームページを公開するスペースをレンタルサーバなどで確保する

２．MySQL や PostgreSQL という、サーバ上で動く「データベースシステム」を用意する

３．Perl や PHP といった言語、あるいは Ruby on Rails や CakePHP のようなフレームワークの使い方を習得し、データの出し入れの部分や公開の方法を自分で０から作ってしまう

どうですか？具体的なことはサッパリかもしれませんが、基本はホームページを公開するサーバ上にデータベースを自分で用意し、それをどうやって外に向けて公開するということを、なにから何まで自分でやってしまえばいい！という考え方です。

良いところだけを書いておくと、とにかくこのやりかたなら何から何まで自分の好きに出来ます。入力フォームも自分好みに出来ますし、データベースを利用するルールも公開するルールも全部自分で決めることが出来ます！サーバをメンテナンスしたり、難しいプログラミングをしたりしなければいけませんが、その分全ての自由が手に入ります！ここまでやったら免許皆伝！（データベース好きの）

次回予告

ということで、駆け足でデータベース活用方法を語ってきましたが、次回気が向いたら CakePHP を使ったデータベースの公開、共有、APIの公開なんて話をしてみたいと思います。本当はこちらの話がメインだったのですが、自分のデータベースへの愛が思ったより深く、前置きだけでこんなに長くなってしまいました。次回はもう少し自重しようと思います。

（つづく）

"Hands Free" by Turkinator

ラボ神部です。

ちょっと思うところあって、１０月以降いったんコーディング無しでプロジェクトをすすめるチャレンジをしてみようと思いたちました。これまで基本は自分の手を動かすことで生計をたててきた自分が「なにかやりかたを変えなくては」と思った結果、自分の今の立ち位置、これからの立ち位置を見直すうえで有効なやり方がこれではないかと思ったのです。

自分の手でなにかを作ること、手を動かすことは非常に大事だし、よいコードを書ける人やコミュニティがあることは楽しいし、とてつもなく重要だと考えることはこれからも変わりないでしょう。しかし逆に言うと、それ以外のやりかたについて自分は十分知らないということに気づきました。それはすなわち自分の弱みでもあります。

私が時々同僚や後輩に「神部は自分がやれることはなんでも巻き取ってしまう」と時折言われることがあります。実現可能性や効率を考えた上での自分なりの判断だったのですが、常にそういう進め方しかできないというのでは、自分の幅を大きく狭めてしまうことになってしまうのではないでしょうか。

自分が得意なやり方を極めるのではなく、自分が苦手なやり方でなにかをすすめるということ、つまり自分のケースにあてはめると自分自身は主要な部分について手を動かすことをせずになにか Web 上のサービスを完成させる、そういうことが必要ではないかと思ったのです。ですので、私は２００８年１０月以降、しばらくノーコーディング宣言をして、しかしなにかを生み出すと言うことにチャレンジしてみたいと思います。

今までとは違うやりかたで、今までと同じことにチャレンジする、それは今までに得られなかった貴重な経験を与えてくれるのではないかと、今からわくわくしています。

今こういう気持ちになって思い出すのは10年前の大学生時代にやった試みです。ちょうど WWW が普及しはじめたばかりの頃で、すっかりそのブームにほだされた自分は世間の情報を既存のメディアを通さずネット経由で取得出来ないかと思い、TVやラジオ、新聞の情報をいっさい遮断しようとしました。しかし現実には、２００１年９月１１日に起きたアメリカ同時多発テロ事件の実情をありありと理解したのはTVやラジオといったメディアを通じての出来事でしたし、情報をストリームで取得するのにIP経由の通信と比べ電波ほど効率的なものはないということもよくよく理解できました。

この経験と同じように、今まではコーディングで全てとは言わなくとも大半の部分を解決しようと思っていた意識を一度捨てることで、今度は何が見えてくるのでしょうか。そして、その両方を知り得た上で、どれだけ　＜やりとげたいこと＞　に対する実行力が変わってくるのかを、見極めてみたいと思います。

ラボ神部です。

最近、はてなブックマークを見ていると、えがちゃんこと永上裕之さんの作成されたブログエントリや、Ｗｅｂを使ったコンテンツが上位に来ているのを見かけることがあるかと思います。はてなブックマーク - タグ これはえがい などでうまくまとまっているのですが、なんともこう、新しいタイプの切り口を感じます。スキルとかリテラシーがもてはやされる時代って、一部では終わるのかな、とも思ってしまいます。それはけして悪いことではなく、Web で使われている技術がコモディティ化していくにあたってはむしろ歓迎されることかもしれませんが、ある種カルチャーショックというか目からウロコが生えるというか価値観の違いという気持ちになる方もいらっしゃるのではないでしょうか。

そんな彼から週末の成果物の案内が来ました（彼は平日は普通に仕事をされているようで、日曜デベロッパとでもいう感じで、そのエネルギーは見習いたいものです）。以下の２つになります。

-はてブ.in - はてブ数を表示してくだちい（笑）

-加護ちゃん.in - あいぼんの行動共有サイト

普段、Web 上のサービスの開発者としてとかプログラマとして、とかいろいろ考えている方は、これらのサービスをじっくり見てみるとどのように思われるでしょうか。はてブのタグに「自戒の念」とかついているのを見るとなんとなく心境がうかがわれます（笑）一方、普段からクリエイティブとか企画とかの面から考えてる人から見ると、彼の動きはちょっと面白く見えるのかもしれません。

私はその中間でいろいろと考えなければ行けないので、そのあたりを理解するためにも、マイタイトルメーカー以来久々にこれらのサービスのクローンサイトを作ってみることにしました。

-はてぶ.in クローン

-辻ちゃん.in - 辻ちゃんの行動共有サイト

どうでしょう、たしかに機能的なものはほぼ再現できたといえますが、何かが足りない気がします。なんというか、押しの強さというか、でもやっぱり気になっちゃうみたいな、そういう部分てなかなか数値化しにくいのですが、これまで彼が書いてきたエントリや作ってきたコンテンツなどを見ると、そういったものがあるような気がしているのです。

なおかつ彼はデフォルトで炎上属性というものを持っているらしく、注目を集めることによって disrespect (dis る）を受けたり、炎上が起きてもむしろ彼はそれをある程度いなしてエネルギーに変えちゃったりも出来るみたいです。ネットイナゴ様ようこそという感じですよね。

こういうタイプのひとは実は結構貴重なのではないかと思います。真面目にリスクを考えると、例えば２ちゃんねるやニコニコ動画のようなサイトをやろうと考える人はいないと思うのですが、実際にはそれらが大きな支持を受けている側面もあります。一方で最近の Web の動きが前ほど面白くないよねなんて声も聞くことがあり、今は停滞期なのかもしれませんが、そういうときほど彼のようなリスクテイカー（崖の下に何があるかわからないけど飛び降りちゃうような人）がある種の革新のために必要なのかもしれません。

そんなわけで、クローンサイトの紹介というよりはむしろえがちゃんこと永上裕之さんに関するエントリになってしまいましたが、これからも彼のモチベーションが続く限りいろいろななにかを送り出してくれると思いますので、いままでなんか抵抗がある、と思っている方がいたらちょっと角度を変えて彼の成果物を眺めてみてはどうでしょうか。

参考エントリ：

-最近話題の「えがい」人から学ぶ若い人プログラマーたちのモチベーション

-彼が今後やろうと考えていること

-たった2週間でWEBサービスを6つ立ち上げる究極の方法！ - 粋blog

-Twitter / HolyGrail: これはえがい、の人のサービス見てると.

-永上裕之とは - はてなキーワード

ラボ神部です。

9月になってからでしょうか、mixi のモバイル版で外部のURLが貼り付けられている場合、これまではリンクされなかったりコンテンツ自体が無いことになっていたのですが、いつからか PC 版サイトを要約し、テキストと画像を抜き出して表示するようになりました。これがなかなかのスグレものです。

例えばこちらのブログエントリ

-MAKE: Japan: 音声ゲームシステム「キキミミ」

ＰＣのブラウザで見ると、このようになります。

ここで、mixi の日記に任意のエントリを作り、その本文中に上記エントリの URL、http://jp.makezine.com/blog/2008/09/kikimimi.html を記述し全体に公開してみましょう。そのあと、その日記を携帯電話のブラウザから見ると、次のようにPCサイトを要約した状態のページを閲覧することが出来ます。

どうでしょうか。このように、PCサイトのコンテンツがかなりきれいに収まっています。ページが複数になったり、重要な画像が漏れたりすることもあまりありません。特にブログからの変換が得意な印象を受けます。

いまのところこの機能について特に mixi から大きなアナウンスがなされていた記憶はないのですが、いままで外部日記が参照できなかったことは、おそらく mixi の友達つながりを生かしつつ外部にブログを持っている人にとってはこれまで大きなネックになっていたのは間違いなく、そういった要望は多かったに違いありません。しかしそれに応えてこなかったのは、技術的な問題だけではなく、ユーザを mixi の外に逃したくないという理由があったのではないでしょうか。

しかしこのように、外部ブログの中身を「要約」というやり方で見せることで利用者を mixi の外に出さないまま、mixi の滞在時間を延ばすことが出来るようになりました。それだけでなく、外部ページの要約が閲覧できるということは、Web 上のコンテンツをすべて mixi の中に取り込むことを可能にしてしまっているのです。これってちょっと怖いことだと思いませんか。

もちろんこの機能は携帯版のみです。しかし、携帯電話しか持たないユーザにとっては、このＰＣサイトのコンテンツはまったくの新規コンテンツ。一気に mixi を使ってリーチ出来る情報量が増えたことになります。もしこれと同じことをＰＣ版で実施したら、著作物の改編といった側面やコンテンツの盗用といった側面から大きな非難を浴びていたことでしょう。しかし、携帯版でユーザからの要望に答えるというかたちで、外部のコンテンツを自分たちのものにしてしまう機能を実装した mixi の狙いはやや Google 的な恐ろしさを感じてしまいました。

もしかしたらモバゲータウンにもこういった機能が既にあるのかもしれませんが、「変換」というロンダリング処理をすることでコンテンツの所有権を曖昧にしてしまう行為はグレーではありながら大変有効にはたらくように感じます。たとえば面白いまとめサイトについて友達同士で話題にしたとして、例えば友達から「どこでみつけたの？」と聞かれたとき、もしその変換元が外部ＰＣサイトであっても、「mixi で見た」と答えることになるでしょう。そのサイトのコンテンツが面白いということが、すなわち mixi 面白いということにつながり、mixi が面白いコンテンツのある場所としての認知を上げることになるわけです。このように自分たちが一生懸命書いたコンテンツが mixi による変換という手続きをはさむことにより自動的に mixi のコンテンツになってしまうということは、はたして何も言わずに見逃しておいてもよいことなのでしょうか？

Goggle モバイルもPCサイトの検索結果を携帯用に自動変換していますが、こちらはかなり不便なのでこれまでは脅威に感じることが少なかったのですが、この mixi の変換処理はPCサイトをほとんど違和感を感じないレベルで携帯サイトに変換してくれちゃっているので、今後この問題が顕在化することもあるのではないかと予想しています。

（追記）

これに関するニュースがないかどうか探してみたtころ、どうやら９／４にひっそりとリリースされていたようです。大きなアナウンスがなかったのは、やはり意図したところだったようですね。

-mixiモバイル、外部サイトを携帯電話向けに変換するサービス

より引用：

同変換ページはmixi内のページのため、mixiのPVとしてカウントされるという。なお、この機能は9月4日から実装されているが現時点でユーザーへの告知はなく、ミクシィでは今後も告知の予定はないという。

（追記２）

このエントリへリンクしてくださった方のブログ によると、どうもこの変換機能はプロキシを使って処理しているようですね。毎回変換しているのにしては動作が速い気がするし、なにか独自のキャッシュのしくみを構築しているのかと思いましたが、こういった伝統的な方法が安定運用にはかなり有効なのかもしれません。

ラボ神部です。

紹介が前後しますが、～になる頃には(´；ω；｀)置き書き場 というコンテンツを作りました。するとはてなブックマークコメントに「フィードを吐いて欲しい！」とのリクエストが。

今回たまたま CakePHP で作ったので、なんとなく楽に実装出来るような気がしていろいろ調べてみたらビンゴでした。いつもお世話になっているねねとまつの小部屋さんをはじめ、いくつかのサイトでその利用方法について書かれていました。

-RSSフィードが好きだ！ - Favorites!

具体的な手順

-CakePHP1.2でRSSフィードを使う | エムティシステム・・・以前は webservice というコンポーネントが使われていたようですが、今では Router::parseExtensions() を使うようになったようです。手順についても参考になりますが、次のリンク先の方が初心者にはわかりやすいかもしれません、

-"1.2でのRSS出力の仕組み" フォーラム - CakePHP Users in Japan・・・こちらはフォーラムでの解説ですね。2008年3月の投稿。

-【CakePHP】iTunesのPodCast用のRSSを出力する | ねねとまつの小部屋・・・さらに iTunes の PodCast用にフィードを吐くため Dublin Core を私用する方法について。Dublin Core、懐かしいなぁ。

またもしかしたら不要かもしれませんが、試行錯誤の途中で XML_Serializer を入れたいという場面がありました。そちらはこちらが役に立ちましたのでついでに併記しておきます。

-PEAR install メモ (Nega Diary)・・・ちなみに、XML_Util もインストールが必要でした。

なにはともあれ、作ったものに反応があることは最高のモチベーションですね！引き続きたくさんの人に興味を持って楽しんでもらえるようなネタを考えて行きたいと思います。

ラボ神部です。

はてなブックマークの注目エントリーに 「オリジナルの検索を作る」‐カスタムサーチはじめました - Yahoo!検索 スタッフブログ というのが上がっていたので、早速ひとつ作ってみました。

要は Google のカスタム検索作成ツールである、Google フリー検索 (カスタマイズ版)と同じなのですが、左上にロゴがアップロード出来たり、ナビゲーションが親切だったりして、使いやすさでは数倍上のように感じました。

メリットに感じたところ

・ロゴを使うことによりサイト内検索の親和性がよりサイトと高くなる

・Mac OS X 用のフォームスタイルもついてくる

・いくつもつくってストックしておける

・検索結果は Yahoo! Japan オリジナルのものよりもかなりシンプル

ちょっと気をつけたいところ

・利用には Yahoo! JAPAN ID が必要

・しょせんはカスタムフォームなので、自分で JavaScript 書いたりしない限り何が検索されたかは取りにくい

・複数のドメイン検索は出来ない？（サブドメインを包含することは可能）

・スタイルシートは別ファイルでくれないので、手動で HTML との分割が必要（難しくないけどね）

Google のカスタム検索は Google であることをはっきり主張していますが、このカスタム検索フォームにより、より水面下にじわじわ的な感じで Yahoo! 検索フォームが浸透していったらちょっと面白いかもしれませんね。将来は検索結果に広告が載るかもしれませんが、それは予想の範囲内でしょうということで。

この勢いで、モバイルサイトのサイト内検索フォームとかもリリースしてくれたら嬉しいんですけどね。

（追記）

はてなブックマークオンリー版も作った方がいるようです。

Yahoo カスタムサーチで、はてなブックマークを検索するツールを作ってみました - hoge256ブログ

そう、実は自分もこのバージョン最初つくりましたｗ　でもユーザ数とか出せないので意外と見せ方が難しく、検索結果にいろいろあった方がいいかと思い、横断検索にしたりしてみました。ちゃんちゃん。

ラボ神部です。

10年ほど前を振り返ると、Web ブラウザの改良につれて SSI から CGI、そして JavaScript と、一部の処理が徐々にクライアントサイドに下りてきた過程がありました。ご存じの通りブラウザ間での相互運用性は低く、むしろそこを他のプロダクトに対するアドバンテージとして締め出しを行うという傾向すらあり、今でこそ Web 標準の考え方がゆっくりと勝利を収めつつありますが、当時の混乱の時期にはPC向け Web サイトの制作者はブラウザ間の相互運用性確保に苦慮していたものです。

そんなときよく助けていただいたのが、tato さんこと高橋登史朗さんによる JavaScriptサンプル集/support というサイト。いつからか自分はそれほどブラウザ上のクライアントサイドスクリプティングは必要なとき意外は利用しなくなり、積極的に情報を集めることをしなくなっていたのですが、ふと All About のガイドをやっていたことを思い出し、お名前で探すとどうやら去年あたりから新しいブログを立ち上げられていたことを発見しました。

-JavaScript++かも日記/Ajax,Google Maps,etc...

JavaScriptサンプル集/support というサイトをやられていた頃は、それこそブラウザベンダー同士が好き勝手にレンダリングエンジン開発を行っていましたし、準拠すべき ECMAScript の仕様そのものが規定の途上にあった中で、なんとかしてクロスブラウザなスクリプトを書こうとしていた努力に対しては、今から振り返っても本当に頭が下がります。

最近のエントリでも、iPhone用Webコンテンツ作成のためのリソース集 を作られたり Firefox拡張機能「Ubiquity」の研究 をされてたりと引き続き活発なようです(^^;;

JavaScript は新しく出てきたひとが元気という印象がありますが、こちらのブログも変わらずアグレッシブなようなので、さくっと RSS リーダーに入れて愛読してみようと思います。

ラボ神部です。

なんだか昨日は知らないうちに GINZA TECH LOUNGE feat. OpenID というとても興味惹かれるイベントがあったらしいのですが、参加出来ず残念です。

こちらにあるレポート やListPod での OpenID 利用について LT してきたを読んで会場の模様を思い浮かべながらいろいろ考えていたのですが、その中で続報的に上がっていた次の記事

-増えすぎた OpenID をどう管理するか - まちゅダイアリー (2008-09-11)

に書かれていることがちょっと気になりました。

希望

* 信頼できるサイトが「OpenIDおまとめサービス」とかで提供してほしい。URLも短く

これはしかにそうだと思います。OpenID 対応アプリケーションを作ってみると感じるのですが、ユーザからはいろいろなサービスがひとつの ID で利用出来て便利なのですが、アプリケーション側からは同じ人でも別の OpenID プロバイダ経由で認証に来た場合は別のユーザ扱いになっちゃうんですよね。

たとえばはてなみたいに一人一ID（サブアカウントを除く）のを基本にしているサービスがありますが、そういうポリシーのもとに一IDあたりの重みを強く持たせたいときは OpenID は少し採用しにくくなってくるのです。

OpenID の仕組みはお店とポイントカードに仕組みに似ていて、お客さんが例えばDVDレンタル店舗 T 社のポイントカードを持っていたとしたら、まず T 社のお店に行けば特典サービスが得られるとします。次に T 社のポイントカードがコンビニ F 社のポイントカードシステムと提携し、T 社のポイントカードを持って行くと F 社でも特典サービスが得られるようになったとします。

このとき、ユーザは T 社のポイントカードを使っても F 社のポイントカードを使っても特典サービスが得られますが、お店側からすればそれは別々のお客さんに見えるわけです。カードを持っている人は同一人物なのに、持っているカードによって ID が変わってしまい、見ようによっては同一人物を複数のお客さんとして取り扱わなければ鳴りません。これではお店側も利用者の実情がつかみにくくなってしまい、実際に有効な利用者母数がわかりにくくなってしまうだけではなく、ユーザから預かるデータの管理もより複雑になってしまいます（もちろん現状ではユーザデータは ID ごとに別々に管理するよ、という軽さを持たざるを得ないわけですが）。

当面の対処方法としては、例えば手元の Open ID のアプリケーション側で複数の Open ID の「おまとめサービス」を提供することです。こうすると、いち利用者が複数の ID でログインしてくるという複雑なことは多少解決に向けられるような気がします。しかし同時に元エントリでも指摘されているような、アプリケーション運営者側による利用者の ID 統合情報掌握につながり、これはユーザにとって嬉しいことではありません。だからこそ、元エントリで述べられているような「OpenID おまとめサービス」が必要になってくるのではないかと思います。

この問題は OpenID が普及するにつれ、将来必ずぶち当たる壁なのではないでしょうか。本当はこういうのは保険証番号とか住基ネットIDとかがインフラになってくれればいいのかもしれませんが、国のIT施策に期待するのも難しいところなので、どこか意表をついたところがこういう認証サービスをはじめたら面白いかなーと思います。以前 IIJ4u とかをやっていた IIJ とかがやりはじめたら、ブランド面も含め結構面白いんじゃないでしょうか？

ラボ神部です。

既に何度か紹介していますが、下記のプチサービスをリリースしました。

～になる頃には(´；ω；｀)置き書き場

「若かったころの自分を思い出す「33歳になるころには(´；ω；｀)」 :教えて君.net」でもご紹介いただき、ブックマーク数も投稿も若干伸びている感じなので、ひさびさに「つくるぶ」に登録してみました。訪問者数グラフがあって便利なんですよね～、ここのサイトスカウター。今回は「ネタ度」と「グッと来る度」でつくってページの最下部に貼り付けてみたので、ポチッと評価してもらえると嬉しいです。

またこのつくるぶのお披露目掲示板で、おとなりでサイトを紹介していた開発者の方がちょっと気になりました。

-My Name Is FMAction ド素人プログラマー(仮)

基本情報源は書籍とのことですが、そこから自分で吸収出来るチカラはすばらしいですね～。

また、昨日 Yahoo!検索のカスタム版エントリで紹介した hoge256 さんも興味深いです。単にコードを書くだけでなくいろいろ検証とかもブログでされているよなのですが、すっごくブログが読みやすいので注目です。あ～、こういう記事イライラせずに書ける人になりたいｗ

また、面白い方をみかけたら、紹介させていただきたいと思います。

ラボ神部です。

今日夕方、excite から「エキサイト・ザ・マンション」からの終了のお知らせが届いていました。これはセカンドライフライクなゲームで、エキサイトブログと連動したりレア家具が登場したりと結構がんばっていたようなのですが、徐々に過疎化が進みついに閉鎖になってしまったようです。

また以前リクルートのやっていた「スゴイ地図」というサービスがあり、いくつかの広告賞やグッドデザイン賞を受賞したものの、８／７を持ってサービス終了していたとのことです（こちらのブログ経由で知りました）確かにあまり継続運用がやりやすそうなモデルではなさそうな感じですし、Flash 的な一発芸の要素も少なからずあったとは思いますが、実際に閉鎖の報を聞くと少し悲しいものがあります。

やはりサーバを設置する以上、維持管理のコストや人員が保てなければサービスの閉鎖はせざるを得ないですし、むしろ前向きに考えればちゃんと終了するだけましです。最近は後処理が出来ないためにクレジットカード情報を流出させてしまったＥＣサイトもありました。ですが、打ち上げ時の勢いと、終わり方のささやかさにあまりにも対比があると、ウェブ上のサービスをまさしくサービスとして運用することについて、少し考えてしまいます。

そもそも現状はさまざまなサービスがあってもそれらがばらばらに提供されており、また日本語圏のユーザ層は非常に限られているわけで、おそらくウェブ上のサービスやコンテンツは、いくつかのポピュラーなものの寡占になっていることが用意に予想されます。そうなると、立ち上げ時から一定期間以内に、どこからからユーザを奪ってこないとそのサービスに未来は無くなってしまいます。しかし逆に、そういう状態ありきでサービスの寿命が短めに設定されているとしたら、それは少し悲しく思います。

そのサービスを通じて、なにか生まれたものは無かったのか、残すべきものはなかったのか、せめてそういった総括が共有されていれば、同様のサービスを提供している他のサービスや、その後を受け継ぐようなサービスにとっても参考になるのではないかと思うのです。今は、アイディアを考えて形にするところまではノウハウがありますが、そこから先のライフサイクルを考え、アイディアやリソースの一部をリサイクルを行うということについてまでは、あまり思いが巡らされていないのではないでしょうか（余談になりますが、これはサービスを越え、国内のビジネスモデルにも言える気がします）。そこに足りないのはコミュニケーションだったり経験の共有の機会の少なさにあると思うので、そういったものについて話せる場所のようなものをつくることに、いつか取り組んでみたく思います。

ラボ神部です。

総務省が、携帯メールアドレスやアプリにもポータビリティを持たせようと検討しているようです。こちらのブログ メールアドレスも持ち運び可能へ。 でも指摘されていますが、ドメイン部分の統一が必要になり、これはなかなか悩ましいところ。@より前の部分も、早い者勝ちになるか、xxxx@docomo.ne.jp が、xxxx-docomo@mobile.ne.jp みたいな感じに変換されるか、微妙なところですね。

コンテンツプロバイダーと顧客の関係で見ると、ドワンゴやコーエーはキャリアを変更してもコンテンツを引き継ぐとりくみをしているようです。また、Yahoo!コンテンツストア もキャリアに関係無く、購入時の ID で利用出来るようです（機種別に非対応のアプリはもちろん除きます）。

※コンテンツ課金に関しては あのコンテンツは使えるのか？ キャリアによって異なる“コンテンツ事情” （１）あのコンテンツは使えるのか？ キャリアによって異なる“コンテンツ事情（２）が詳しいです。

ＰＣでも携帯電話でも市場が成熟してくると、自分とコンテンツ、あるいは自分とサービスの間の関係をよりシンプルにしたくなってくるのかもしれません。普通のお店に行くように、自分が対価を払って目的の品物やサービスを受け取る、それくらい抽象化出来る用になった方が、法整備などもしやすくなっていくのかも。でも現実はそう簡単にいきそうにないことも容易に想像できます。この制度が導入されるころ、携帯電話市場はどうなっているのでしょうか・・・。

ラボ神部です。

いろいろなウェブサービスの API を利用する際、毎回スキーマの異なる XML 文書から必要な箇所を抜き出すのは苦労するものです。DOM を使うにも構文が複雑ですし、PEAR の XML_RSS ライブラリのように毎回同じ書式でやればいいというわけでもありません。

（例えば、そう、こんな感じで。）

require_once("XML/RSS.php"); $rss =& new XML_RSS($rss_url);

$rss->parse();

foreach ($rss->getItems() as $item) {

//$item に対して何かの処理

}

しかし、Keith Devens .com - PHP XML Library, version 1.2b で配布されている xml.php を読み込むだけで、どんな XML スキーマの XML ドキュメントでも、とりあえずは PHP の配列に取り込むことができます。

（こんな風に）

include('xml.php');

$data = XML_unserialize($xml);

さらに、配列を XML 化することも出来ちゃうようです。

include('xml.php'); $xml = XML_serialize($data);

これはすごい！

今まで面白そうな API が公開されていても、parsing の処理の手間を考えるとちょっと手をつけにくいなと思っていたものも、気軽に試すことが出来そうですね。こういう部分の敷居がグッと下がるのはとっても助かります。ブックマークのコメント を見ると、2005年当時からあったようですが、いまいちこれで決め手という感じもないですね。

もう少し調べてみると、PHP4でxmlのパース処理をする方法はいくつかあるようですが、いずれもくせがあるようです。自分的には、xml.php 的な使い方がすごく使いやすいので、PHP4 な環境ではこれで行こうかとも思いますが。

ちなみに、PHP のバージョンが 5 以降なら、SimpleXML関数 の simplexml_load_string - PHPマニュアル を使うのが正しいようです。DOM風に要素を取り出す方法もあるようですが、PHP5を試してみる - SimpleXML関数でRSSしてみる - Do You PHP? で紹介されているように、要素名の配列から子要素を $parent->child という形で呼び出すのが扱いやすそうですね。

$article = simplexml_load_file('test.xml');
echo $article->subject;

このあたりはもう少し研究してみたいと思います。一度身につけておけばそれでずっと使えるものでしょうから。

（追記）

外部サーバのファイルオープンを禁止していると、SimpleXML は使えないようです。地味ですがこちらも注意。

薬箱 - PHP simplexml_load_file 関数について

ラボ神部です。

６月から募集が開始されていた Mashup Awards 4 / MA4 に二作品を応募しました。締めきりの正午までに申し込みを済ませ、先ほど受理の確認メールが来ました。受付が受理されたあとも機能追加や不具合修正はお粉手も大丈夫ということなので一安心。つくったものを簡単に紹介させていただくと、次の２つになります。

１．
Artres - tokyo art island
http://labs.spicebox.jp/artres/

これは簡単に言ってしまうと、今までに作ったことのないUIにチャレンジしたかった！というものです。Wbe の API でマッシュアップというとどうしてもフォームがあってボタンがあってという感じになるし、かといってすべてを Flash で作ってしまうとスゴイのが作れる代わりに高いソフトを購入しないと作成すらままならないとい現実があります。誰でも気軽に構築できるような仕組みでありながら、パソコンを普段使い慣れていない人にも、またむしろパソコンを使わないからこそ直感的に使ってもらえる仕組みや、使いながら楽しんでもらえる方法がないかなと思いました。

今回は Mashup Award ということで、ひとつの作品の中に２個以上のAPI出力を、とりあわけ１つは主催側で指定のものを使わないといけないということだったのですが、今回チョイスした Tokyo Art Beat の API はまさにこのような目的にぴったりだったように思います。イベント情報が東京中心なので、まずは２３区の白地図を用意し、それを海に浮かぶ孤島のように見せかけて好きに触ってもらい、その中でイベント情報を発見してもらえれば、単に情報を調べるためだけの道具で、ちょっとだけ楽しんでもらえるのではないかと思ったのです。イベントを探し続けることで発生する波の打ち引きの見立てに、遊びながら気づいてもらえるでしょうか？実際に海水浴に言ったとき、引く波の間から貝殻を見つけたときの感覚を、このサービスでアートのイベントを見つけたときにも持ってもらえるでしょうか？そこが伝わるかどうかを、楽しみにしてみたいと思います。

２．
Favorites! - 「好き」でつながる話題コミュニティ
http://labs.spicebox.jp/favorites/

こちらは打って変わってわかりやすく、「好きなもの」について書き込みで共有出来る掲示板風のコミュニティです。今回こういうものを作りたくなったのは TRIPIT Labs » WebAPI の一部機能である関連語検索WebAPI を使ってみたくなったからです。要は新垣結衣といきたら　⇒　恋空を連想するシソーラス辞典のような仕組みなのですが、このアウトプットが結構ツボでどうやら Web のクロール結果も参考にしてるのではないか、という情報の細かさです。有名人の名前であれば出身校の名前が出てきたりするのもご愛敬。

キーワードの内部リンクで自動集約系のサービスにしてもよかったのですが、見ていてもあまり面白くない自動生成っぽさを避けるために、今回は掲示板風にしてみてみました。今時自分が一種のスレッドフロート式の掲示板を作るようになるとは思いませんでしたが、もしこれがいくらかでも刺さって利用してくれる人がいたら楽しいだろうなぁ、と想像を膨らませています。

もちろんコミュニティ運用にはリスクもコストもかかりますので、急にめちゃめちゃ流行っちゃったら困りますけど、まずはこのサイトが器としてサーチエンジンにインデックスされていくかどうかが楽しみです。

さて、この Mashup Award、受賞発表は一ヶ月後の１０／１９に（日）なるそうです。たぶん多くの猛者が参戦していることでしょう。こういった盛り上がりは嬉しいし楽しいですね。
またこういったコンテストがあれば、知恵を絞って参加してみたいです。腕も日々みがいておかないとね。

（追記）

逆に残念なお知らせも入ってきました。、以前インタビューもしていただいた「つくるぶ」が今月いっぱいで更新を休止するとサイトトップに情報を掲載しています。

これ系では マッシュアップポータルサイト【Mashupedia.jp】 も二ヶ月くらい「リニューアル」という告知を出したままになっているようです。たしかにマッシュアップは手軽ですが、実際問題誰でもプログラミングを始めてくれるわけではないですし、いざサービスを立ち上げても長期的に実のあるものにしていくのは難しく、また華々しいわけでもないということを考えると、仕方のない側面もあるのかもしれません。

しかし今回も Mashup Award に参加してみて、Web 経由で提供されるさまざまな API を材料にサービスを組み上げていく作業はやはり楽しく感じました。なかなかおもしろさが伝わっていかないのなら、そのおもしろさを伝えられるようなものをつくってみたいですね。

ラボ神部です。

アイディアを形にすることは楽しいプロセスです。アイディアを出して行くこと自体が楽しいと思える人には、それが結実する瞬間というのは嬉しいものです。それがハンドメイドでつくられた物であったり映像作品であればそこで基本的にはやることは終わりになるのですが、Web 上でサービスを立ち上げることになったばあい、リリースしてそれで終わりというわけではなく、むしろそこからが本番になります。そこから先も含めて「つくった」ということになるので、ある意味手離れが悪いとも言えますね。

そんなことを考えながら読んでいて次になったのが次のエントリのある一部分。

シリコンバレー訪問８：VC（日本人）-こっちと日本VCの違い

・VCに話すとパクられるというリスクについて。

出し惜しみをして開花しない方がリスク。真にユニークはゼロに近い。最終的なビジネスの勝負は、技術の優位性だけではなく、いかに優れた組織を作り上げて、世の中に認知され（Mkting)、買い手が付き（営業）、満足するか（Retention)であり、IP勝負ではない。

これを Web 上のサービスにあてはめて考えると、

「真にユニークはゼロに近い。最終的な勝負は、技術の優位性だけではなく、いかに優れた運営体制を作り上げて、世の中に認知され（Mkting)、買い手が付き（営業）、満足するか（Retention)であり、アイディア勝負ではない。

という感じでしょうか。この場合の買い手というのはビジネスの場合は buy out になるのでしょうけど、インターネット上のメディアとしては広告枠としてよい価格がつくというのも出口になるでしょう。また、IP というのは知的財産（Intellectual Property=IP）なので、アイディア勝負ではないととると…それはそれで希望が持てるような持てないような。やはり、アイディアと技術で大きく勝負がつくのであれば、そこに希望を持って勝負をかけることもできるのですが、他の部分に大きく依存するとなると、それは旧来のビジネスなりやり方とあんまり変わらないものになってしまい、その分おもしろみは下がってしまうかもしれません。

昨日ちょっと話題になっていた「boketeβ(ボケてベータ版) : 写真で一言ボケるお笑いウェブサービス」は、形だけなのかもしれませんが、そういう起承転結の所を押さえようとがんばっている気がしています。

・古いかもしれないがきっちりとしたウケ要素を持っている
・ネタをサービスにかえる技術力
・ちょっとした利用規約も完備
・広告掲載やプレスの問い合わせ先も明示
・サービスを通じて 株式会社オモロキ - webに面白さと驚きを の宣伝にもつながっている

こんな風にイロハは十分な感じなので、あとはサービスに品揃えや実績、体制作りがしっかりすれば結構真面目にいけるのではと思えるところもあります。こういったよい例を参考に、アイディア出しや開発の他の部分にも目を向けて、楽しんでいくやりかたが広がって行けばいいのかなと思いますが、そうなるとビジネス化の方に目が向いちゃって面白くないなぁ、とも思えるわけで、難しいところです。

Web ならではの手離れの悪さとどうやってつきあっていくかは、引き続き考えて行きたいところです。そうするとキャンペーンサイトのように、３ヶ月でなくなってしまう”作品”としての Web 上のサービスというのも、いいやり方かもしれませんね。

ラボ神部です。

かなり周回遅れですが、こちらのニュース「女性向け2次元恋愛シミュレーションSNS「ウェブカレ」の会員数が1万人を突破--リンクシンク - VENTURE VIEW」をみて、ウェブカレについて調べてみたところ、どうやら Web アプリケーションの脆弱性の指摘で有名なはまちちゃんさんがつくられているということを知りちょっと驚きました。脆弱性の指摘については最近あがっていたご本人のエントリが面白かったなーと。

-個人だから甘いのかな - ぼくはまちちゃん！(Hatena)

完成に向けてはいろいろあったようですが、蓋をあけてみれば大成功、よかったんじゃないですかね－。でも、後者のエントリの方で、はまちちゃんことはまちや２さんが開発ではなくプロデューサーだったことがわかり新たな驚き。そりゃープロデューサーがミーティングにいなかったら話が進まない気がするなーｗ　あんまり面白くないバックエンドのところの作り込みに対してモチべーションが上がらなくてばっくれてるのかと思ったらそういうわけでもなかったようですね。まあ、遅刻というのもネタなのかもしれないし。今は対応に追われている所ということなので、ますます大変になっているかもしれません。

今のところ、ウェブ上のサービスを作るにあたり開発者になるのはそれほどハードルが高くはないと思っています（どんな薄っぺらなサービスでもよいのであれば）。でも、複数のメンバーで出来たチームの中でプロデューサーを担えるというのはなかなか難しいと思います。特にこういうウェブカレみたいなコンテンツになってくると、若い人のコミュニケーションになってくるので、すごく難しいんだろうなー、と思います。†フェイス女学園† （顔診断サービス） を作成したときも、ターゲットが若い人だったのですが、開発を担当していた自分からは、フェイス女学園のとった方向性が果たして正解だったのかわからなかったのですが、これも蓋を開けてみれば結果実際に若いひとたちが沢山使ってくれました（PC版だけでなくモバイル版の勢いもすごく、そこからのクチコミが長続きした）。

今回も根本的な舵取りについてはまちや２さんが音頭をとったのであれば新しいコンテンツプロデューサーの誕生に居合わせたってことになりとっても幸せなこと（？）なのかもしれません。歌って踊れるかどうかは知りませんがイケメンで脆弱性も指摘しちゃうプロディーサーだとしたら、十分コワザ（と怖さ）が効いていると思います。ウェブカレの盛り上がりが一段落するか、うまく軌道に乗るようになったら、次はどんなものを出してくるのが本当に楽しみですね。

ちょっと不思議なのは、～素敵ボーイズと、ラブな乙女の物語～ ウェブカレの、サーチエンジンの検索結果がぜんぜん高くないこと。はてなのキーワードにも負けちゃってるのはなんでだろう。携帯からはアクセスできないようなので、あんまりリンクを張られていないってわけでもないと思うんだけどな－。

（９／１８追記）

求めたのはネットを使った女性の“癒し”--「ウェブカレ」プロデューサーのはまちや2氏 - VENTURE VIEW という記事を見ると、どうやら既に「ウェブカノ」宣言されているみたいです！次はどんなイラストレーターさんとキャスティングで来られるのかめっちゃ楽しみですね！女の子版なら歌とかダンスに持って行ったって良いわけですし。

またこのエントリーのはてブコメントページにはまちや２さんがいらしてくださいました。ありがとうございます！ウェブカノ本当に楽しみにしています！

（９／１９追記）

ハマチをちゃんとテリヤキの id:se-mi さんよりブックマークで突っ込みがあったので、タイトルを微妙に修正。

ラボ神部です。

「アルバイトの勤怠管理」という本来ちょっと硬めのサービスが、今週ちょっと話題になりました。名前は「シフター」。アルバイトのシフト管理の悩みを解決してくれるそうです。なんで注目されてるのかなーと不思議に思っていたのですが、【急募】ウェブサービス開発のプログラマとデザイナー - p4lifeのメモ というエントリーをきっかけに今日偶然にも社長の石原明彦さんと Skype Chat 経由でお話させていただく機会があり、思い切ってその理由をエントリーに起こしてみることにしました。ついでに他の勤怠管理ASP/SaaS プロダクトとの比較もしつつ、この「シフター」についてまとめをしてみたいと思います。

すっごく長いので、競合との比較に興味がなく読み飛ばしたい方は「続きを読む」の続きから読んでみてください。

３０分くらいリサーチしてみていろいろわかってきたことがあるのですが、結論から言うと大成功のスタートを切った新世代のサービスだな－、という印象です。ただし、それはニッチな部分での大成功であって、ここから成長して市場で一定のシェアを納めるところまでいくのかどうかはまだまだ未知数なところです。そこで、かんたんに競合製品と比較してみます（社名などは敬称略でいかせていたきます）。

早速競合製品をかたっぱしからあたってみる

Job Communicator by 株式会社ウェブインパクト

世間的な実情はわかりませんが、Google で複数の単語の組み合わせでアルバイトの勤怠管理 ASP について調べていくと、とにかく一番最初に出てくるのが株式会社ウェブインパクトの Job Communicator です。ここは国内のグループウェア市場ではかなりのシェアを持っていると思われる desknet's を開発している NEOJAPAN,Inc. 株式会社ネオジャパン と提携して グループウェアから勤怠管理を使えるようにする など既に裾野を広げる作業に入っています。

画面としては 操作方法のページにあるような感じ でいかにも業務アプリ－、って感じですね。ASP なので対応動作環境も大事になりますが対応ブラウザは IE のみ、携帯電話は 2G 以降が対応（ウィルコムは記載無し）のようです。人材派遣、店舗・チェーン店向け・コールセンター向けの３パッケージがあり、人材派遣向けのパッケージでは300名前後から、数千人規模までカヴァーできるとのことです。当然実績もあるでしょうし、このあたりはさすがですね。トップページにある１ユーザあたり月額１５７円という数字も覚えておきたいです（desknet's との組み合わせバージョンでは、199円を割らないんですけどね）

Fooding Journal by 株式会社 プロス

ニュースサイトの記事によると、まずは飲食店をターゲットに ということですので、同カテゴリである フーディングジャーナルというASP について見てみたいと思います。とはいえこちらは売り上げ管理や仕入れまでやれちゃうので、あまり比較にはならないと思いますし、主にシフト管理はとりまわしを行う従業員が行い、アルバイトはタイムカードの打刻のみのようです。アルバイトの都合というよりは、予算面でオーバーしない（売上予算に基づいたシフト作成）が出来るというという経営面からのトップダウンという特徴があるようです。たしかに、アルバイトが一生懸命働いてくれたのはいいけど、払うお金がないのでは本末転倒ですしね。VPNを経由して POS との連携が出来たり各種帳票がつくれたりと、これはもうかなり本格的です。初期導入費用は20万円から、月額利用料は応相談と言うこと。店舗が十数店舗レベルになってきた段階で頼るべきサービスと言えそうです。

バイトマスター・勤怠管理タイプ by データバンク株式会社

つづいて、バイトマスター・勤怠管理タイプ。 これはかなりシフターに近いのではないでしょうか。作成はデータバンク株式会社。
主要機能の項目を見ると目を引かれるのが勤怠管理システムに「信頼ポイント」というものを設けていること。いわゆるポイント制でモチベーションを上げようという取り組みで、これはちょっと面白いかも。なんとなくバリュープレスの経験値システムを思い出しますね。動作環境は IE のみ、携帯電話は携帯三キャリア。

その他変わり種

横道にそれますが、最近の勤怠管理の流行りとしては、AIS の静脈認証・指紋認証を用いた ＡＳＰ 勤怠管理システム や SONY 開発の Felica を使った勤怠管理システムもあります。ただしこれはら設備の導入も含めると初期費用が若干ですが上乗せしてかかりそうです。

ラボ神部です。

ラボブログなので、考察や技術ネタばかりでなく、ライフハックネタでもやれないかな～と思ったら偶然おかしなことを思いついてしまいました。それは、マクドナルドのメニューをハックしてオリジナルスペシャルバーガーを作るライフハックです！

実は今日からマクドナルドでは 夜だけ「フィレオフィッシュ」が100円になるキャンペーン を開始していて、これから９／２８（日）まで１０日間行われます（ファーストフード好きなGIGAZINEに載っているかと思ったら載っていませんでした）。Yahoo!知恵袋 にあるように、基本は来客キャンペーンなのですが、客としてはありがたく利用させてもらえればハッピーなのでOKというものです。

確かにポスターが貼ってある

しかしここで問題なのは、フィレオフィッシュはマクドナルドのバーガー類の中でもカロリーが抑えめで、あっさりしている分食べ応えがない！せっかく１００円で買えるのに、セットメニューもない。これではちょっと寂しいですよね。同じようにフィレオフィッシュで満足出来ない、でも１００円フィレオフィッシュを食べてトクした気分になりたいという方のために、こんな技を伝授！

１００円フィレオフィッシュと一緒にシャカシャカチキンを購入しましょう！

これで肉分が足りない貴方も満足・・・なーんてしょぼいことを考えてはいけません。本番はここからです！

まず手元に次の物を用意してください。

・１００円フィレオフィッシュ

・シャカシャカチキン

・ホットチリ・チーズ・ブラックペッパー（新）のうち、好きなシャカシャカチキンのスパイス

準備はよいですか？

そしたら次に、おもむろにスパイスをシャカシャカチキンの袋に入れ、そしてシャカシャカして混ぜましょう！年齢とか仕事のことは考えてはいけません。まんべんなく混ざるようシャカシャカしましょう！

そしたら次に、１００円フィレオフィッシュの包装をゆっくりと開き、けっして食べずに一番上のパンズとフィッシュフライが入っているところで分離しましょう！（タルタルソースが塗られているところ）※下の方のパンズだとフライが貼り付いて取れにくい可能性があるのでおすすめしません。

ここまできたらもうおわかりですね！そう、さっきできあがったシャカシャカチキンをあくまで食べずにフィッシュフライの上に乗せます！そしてタルタルソースのついたパンズではさみます。そしてもう一ゆっくりと包装します。これで世界にひとつしかない、あなただけのオリジナルバーガーの完成です！

実際同じバーガーにフィッシュとチキンが同居という組み合わせというのはマクドナルド史上一度も登場したことがないはずで、いわば新感覚タルタルチキンフィッシュフィレオバーガーとでも呼んでしまっても過言ではないのではないでしょうか！？

そしてこれが完成した実物の写真！

ぜひ、普通のフィレオフィッシュと見比べてみてください。もちろん元のフィレオフィッシュよりもボリュームアップ。ましてやけっしてメガマックの理想と現実のような悲しいことにはなっていません。むしろ、今までフィレオフィッシュでは味わったことのないおいしそうな厚みを誇っています！（以前はダブルフィレオフィッシュもありましたが、フィッシュフライ自体に厚みがないので結果としては当然・・・）フィッシュとチキンの組み合わせに期待感も抜群！

更にアップ。

見てください！普通のフィレオフィッシュでは分厚く見えるフィッシュフライを、シャカシャカチキンが完全に覆い隠してしまうほどの圧倒的存在感を放っています（実際シャカシャカチキンの方がひとまわり大きい）

さすがにもう耐えきれません。早速食べて見ると、これが鬼ウマい！もうレギュラーメニューにしたらってくらい、フィッシュのまろやかさとチキンのスパイシーさが混ざり合って新メニュー爆誕生という感じです。しかも忘れてはならないのは、シャカシャカチキンのフレーバーによって３種類自分好みの味にカスタム出来るのです！！！（プレーン状態も含めれば４種類ですね）

本当は GIGAZINE に負けないように食べかけの断面図も撮影しようかと思っていたのですが、あまりのおいしさに気がついた時には全部食べきってしまっていましたｗ

価格はと言えば・・・フィレオフィッシュ１００円＋シャカシャカチキン１００円でたった２００円！・・・と言いたいところですが東原亜希さんが新フレーバーを提案したあと１２０円になったためほんの２２０円で楽しめます！

しかもここだけの話利益率の高いと噂のフライドポテトや自由に選べるドリンクをセットで購入するかどうかは自分次第なので、本当にケチれば２２０円でこの新味が楽しめます。これぞ消費者の勝利！

真面目な話、不況の今この１００円フィレオフィッシュは本当にありがたく、わたしもいつものデパ地下の値引き弁当よりも今日はマックだな、と思って店頭に足を運んだ矢先に思いついたライフハックでした。そんな庶民の味方の割安メニューでこんなに楽しませてもらうのは正直申し訳ないですが、本当においしくいただきました！＆残業前のおなかをちょうどいい具合に満たしてくれました。どう考えてもおトクです本当にありがとうございました。

（ごちそうさまでした。）

・・・もしこのおバカな試みに自分もチャレンジしてくださったという方がいたら、ブログにばしばしコメントしてやってください！（どうやらラボブログへのトラックバックが今うまく動かないようなので・・・）

そして次はいつになるかわからないですが、またいつかライフハックネタにチャレンジしたいと思います（このネタが本当にライフハックと言えるほどのものだったかどうかは、ものすごーく疑問ですが・・・！）

（閑話休題。）

ところで私の最寄りのマクドナルド恵比寿ガーデンプレイス店はちょっといい取り組みをやっています。”EBISU STYLE” という POP を自作して、包装を（おそらくマクドナルドの許容するギリギリのところまで）減らそうという努力をしています。

一般的に見れば包装や中袋は多くなりがちですが、ドリンクの外袋、ビニールの手提げ袋をなくせるのは店舗とオフィスが一体になっているガーデンプレイスならではの取り組みなのかもしれません。マクドナルドのような会社の誰かが毎日利用するような店舗こそ、スターバックスのタンブラーのような割引付きのエコバッグ（しかもくにゃくにゃしておらずマクドナルドの食べ物を運びやすい固い材質のもの）を作ってくれたらいいのになと日々妄想しています。

しかしリアルハックの道は厳しい！今回は広告キャンペーン研究の意味も若干含めつつやってみたつもりですが、こんな記事で少しでも話題になることで、いつかメッセージとして伝わる日が来ればいいなぁーと思っていたりします。

あと今回のように自分の好きな食材を購入して組み合わせるタイプのファーストフードがあっても面白いんじゃないかと思いました。その分職員の人件費が減らせたりするかもしれないし、そんな実例があったらぜひぜひコメントいただければと思います。

（了）

ラボ神部です。

はてなブックマークのホットエントリに、英文の単語内の文字順を並べ替えても読めるというトリビアが上がってました。これって以前小ネタで作った text crusher というのに似てる感じがしたので、ver 2 としてアルファベット版を作ってみました。

-> text crusher 2 - alphabet edition -

BBCのニュース本文がデフォルトで入っており、変換する文章は自分で内容を上書きすることも出来ます。とにかく何か入力されている状態で crush ボタンを押してください。子のとリビアに従った変換が行われます。実際結構読めるものですね。日本語版の ver .1と併せてどうぞ。

-> text crusher - original edition -

ちなみに同様の物を考えて作った方もいるようです。

-> Raiendg Tset Getreaonr

ホットエントリをお題に一品作るなんて動き、もっと広がるといいなぁ。あと、2ch の専用ブラウザなんかに機能として取り込むと、また新しい流行になったりすることもかるんじゃないですかねー。

ラボ神部です。

ちょっと機会が会ったので、ajax-tooltip.js の設定方法と、マウスアウトしても吹き出しが消えない方法についてまとめたのでブログにコピペしておきます。便利ですよ！

▼1.ライブラリの取得

Ajax tooltip
http://www.dhtmlgoodies.com/index.html?whichScript=ajax-tooltip

に行き、次の zip ファイルを取得
http://www.dhtmlgoodies.com/scripts/ajax-tooltip/ajax-tooltip.zip

▼2.フォルダの配置

zip ファイルを解凍し、任意の場所に、css, images, js フォルダを配置
（できればコンテンツのルートフォルダに）

▼3.HTML に追加

ポップアップを使用したいページのヘッダ（の間）に、下記の行を追加する

<script type="text/javascript" src="/js/ajax-dynamic-content.js">
<script type="text/javascript" src="/js/ajax.js">

<script type="text/javascript" src="/js/ajax-tooltip.js">
/**********************************
(C) www.dhtmlgoodies.com, June 2006
***********************************/
</script>
<link rel="stylesheet" href="/css/ajax-tooltip.css" media="screen" type="text/css">

また、ポップアップさせたいオブジェクトを タグで囲い、下記のように設定する

<a href="#" onmouseover="ajax_showTooltip('（リンク先ファイルの相対パス）',this);return false" onmouseout="ajax_hideTooltip()">リンクテキスト

※ # の代わりにリンク先を設定することも出来ます。

▼4.メソッドの変更

うまく動作しなければ、

ajax.jsの9行目

this.method = "POST";

を

this.method = "GET";

と書き換えてください。

▼5.タイマーの設定

デフォルトだとマウスがリンク先からはずれるとポップアップが
消えてしまうので、タイマーを設定します。

ajax-tooltip.js を開き、

function ajax_hideTooltip()
ajax_tooltipObj.style.display='none';
}

となっているところを探し、下記のように書き換えてください。

function ajax_hideTooltip()
{
var tid=setTimeout(hide,3000);
}

function hide(){
ajax_tooltipObj.style.display='none';
}

以上です。

参考：

» JavaScriptでTooltipを実装する。(4) -Ajax tooltip 寺子屋未満: 最新Web情報をコツコツお届け・・・IE6 だめなんかなー

Rails：Ajax Tooltipでスマートにポップアップさせる・・・サイズ変更したいとき

ラボ神部です。

Flickr API を調べていたら、PHP で扱いやすい形で Flickr API を作る方法を見つけました。

REST の戻り値を配列に放り込もう！

通常 Flickr から REST でデータをはき出すとき、XML フォーマットで帰ってくるのですが、

format=php_serial

という呼び方をしておくと、下記のような形で PHP の配列に読み込めます。

$url = "http://api.flickr.com/services/rest/?".implode('&', $encoded_params);

$rsp = file_get_contents($url);

$rsp_obj = unserialize($rsp);

参考リソース

Flickr API を使ってみよう « foot mark

Flickr Services・・・これも同様のやりかた。

Flickr Services: Flickr API: flickr.photos.licenses.getInfo：by ライセンスで探したいときは4・・・初めてのFlickr API - file-glob こと k.daibaの日記 より

PEAR::Flickr_API・・・こちらは使いませんでした。

　
floatingdays: なぜPEAR::Services_Flickrが無いのか？

ラボ神部です。

今日発売になる 映画『ブラックサイト』のDVD のエピソードに倣ったブログパーツを作ってみました。

▼hangman - 見る人が多いほど男が死んでいくブログパーツ

（ブログパーツの貼り付けサンプルはこちら）

なんていうか、やってみていただくとわかると思いますが、なんだろう？と思って最後前見ていくと悲劇が起こってしまうというパターン。好奇心が人を殺してしまう仕掛け。あまりイイ趣味とはいえませんよね（笑）

そもそも「ブラックサイト」という映画には映画には killwithme.com という悪意の固まりのようなサイトが登場するのですが、このサイトに人がアクセスすればするほど、ライブ中継で拘束されている男性に毒物が注入されていくという、まったくありえないとは言えないそら恐ろしいバッドアイディアです。

しかし、そんなサイトがあったとき最初に訪問した人はこれが本当なのか偽物なのかわからず、それを誰かに教えて真偽を確かめようとするでしょう。それがまた噂を呼び、バズで広がったサイトが結果として本当に劇中の拘束された男性の命を奪ってしまう・・・ある意味ネットの歯止めの利かない部分を端的に表していると思います。

これが新聞や雑誌で「読まれれば読まれるほど誰かが傷つく」のであれば、そもそも流通する前に発行が停止されるでしょう。テレビであれば政治的な配慮で放送局からの送出信号を止めればよいでしょう。もちろんネットでも当局がサーバを突き止めてそのサーバを停止するなりそこに至る経路を封鎖すればいいわけですが、そういった運用が可能な法整備や実働体制が現実的には存在していないとも言えるでしょう。そういったまだ未完成な部分をついた映画としては面白い視点で作られていると思いました。

ちなみにそんな killwithme.com の 日本語版的な位置づけ、 サイバー捜査官ジェニファーの顔プロファイリング の方は顔診断の部分で少しお手伝いをさせていただきました。ちょっと心臓に悪い演出が入ってますが、心を落ち着けて一度遊んでみてください。

プロジェクト 10 の 100 乗
http://www.project10tothe100.com/intl/JA/index.html

というのがはじまったようです。

プロジェクト 10100 (「プロジェクト 10 の 100 乗」と読みます) では、世界のできるだけ多くの方々の役に立つ画期的なアイデアを募集します。応募方法は次のとおりです。

1. 10月20日までにアイデアをお送りください。
アイデアの要旨を応募フォームに入力します。アイデアを補足する 30 秒の動画を送信することもできます。

2. 1月27日よりアイデアへの投票を開始します。
Google が選出した 100 のアイデアの中から、最終選考に進む 20 のアイデアを投票で決めます。その後、専門の選考チームにより最終的に 5 つのアイデアが選出されます。 投票開始の通知メールを受け取る

3. Google がアイデアの実現をサポートします。
Google ではプロジェクトの実現資金として 1,000 万ドルを提供します。ただし、Google の目標はできるだけ多くの人々の役に立つことであり、資金はあくまでもきっかけで、重要なのはアイデアそのものです。

とのこと。応募してみようかな。

ラボ神部です。

hangman をモバイル対応にする過程でいろいろメモしたいことが出てきたので、書き残しておきます。

１．PHP のセッションで携帯対応にしたい場合

冒頭で
<?php
ini_set("session.use_trans_sid", "0");
session_start();
?>

URL の引数に
next.php?<?php echo session_name() . "=" . strip_tags(session_id()); ?>

２．Flash Lite でバイブレーション

Flash Liteで、ユーザフィードバックを与えるためのバイブレーション使用 - Forum Nokia Wiki

とりあえずは

fscommand2("StartVibrate", 100, 0, 1);

だけでも振動する。

２．Flash Lite の埋め込みタグ

-Flashでやってみよう 「Flash Lite」を使ってみよー!! （作り方 2 / 2 ）

-Flash Lite 1.0/1.1メモ

後者は object の type 属性にハイフンが入っていないため誤っており、動かない。

ラボ神部です。

今日いちばん盛り上がったネタは、やっぱり賞金200万円を獲得したという第３回日本ケータイ小説大賞「あたし彼女」だったと思います。ネットだけかな～と思っていたら、社内でも「みたいな」「みたいな」と声がちらほら聞こえてきたので、そんな声を聞きながらこんなのを作ってみました。

あたしブログ ～あなたのブログを２００８年最高のケータイ小説形式に変換～

これはどういうものかというと、ブログかブログのＲＳＳのＵＲＬを入力すると、それを受賞したケータイ小説と出来るだけ近い書式に変換するというものです。今回は午後１５：００頃に思いついて１９：００には細かい直しも終わったので、だいたい四時間くらいでしょうかね。

やはり最初はちゃんと Yahoo!デベロッパーネットワーク - テキスト解析 あたりをつかって形態素解析して体言止めなどを再現しようかなと思ったのですが、結構クエリが多くなりそうなので断念。Mecab にも精通しているわけではないので、ここはなんちゃって変換で。

見ての通り「のに」とか「だし」みたいな若者ことば特有の語尾では必ず改行するようにしていて、あとはちょこまかと「みたいな」をはさんだりとほんとに単純につくってあります。URL が本文に入っていたりコード断片が入っているとかなり苦しいですが、全角のみのブログなら結構雰囲気が再現できているように思います。

また最初は RSS の URL を直接入力してもらう感じだったのですが、それだと利便性が心許ないので、UnderDone | Re: Keith Devens - Weblog: RSS auto-discovery with PHP - June 03, 2002 のエントリを参考に RSS Auto-Discovery に対応してみました。

あと付け足したのは「このブログ小説を発行」リンク。変換したあと、そのブログのリンクをトップに出せます（一応、著者の人がリンクとして公開したいときに押してもらえるものとキタししています）。

あとは Google Analytics のコード貼り付けたりしていてアナウンスが１８：３０過ぎになっちゃったので出足が遅かったかな～と心配でしたが、はてなブックマーク も順調に伸びているようでよかったです。id:orangestar さんは何かの締めきりに追われているのでしょうか・・・心配ですｗ

もし人気が出てきたら、今度こそちゃんと形態素解析して、本格的に改行を挿入したいですね。元の小説で「みたいな」を読点の「。」に変換して読みたいというネタもあるみたいですが、こちらは Greasemonkey のスクリプト向けかな。なんにせよミームのキャチアンドクリエイトはまた続けていきたいです。

（追記）

ブックマークレットとブログパーツも作ってしまいました！

（Re:はてブコメント）

id:anigoka 「改行と「みたいな。」付け加えるだけならそりゃ早いわな」

ちんたら Yahoo! の テキスト解析 API の評価とかしてなければもっと早く終われたはずですが欲張ったせいで判断が遅れました。突発的に使う機会が来ても対応出来るように、普段からいろんなものを試しておくクセは付けるようにしたいと思います。

（ご紹介ニュース！）

-ねとらぼ：「あたしブログ」――あなたのブログをケータイ小説大賞作品っぽく変換 - ITmedia News・・・ニュースで紹介されると思わずめちゃめちゃ驚きですが紹介されました！ありがとうございます！

-「あたしブログ」――あなたのブログをケータイ小説大賞作品っぽく変換（ITmediaニュース） - Yahoo!ニュース・・・Yahoo! ニュースにも配信されました。

-[mixi] 「あたしブログ」――あなたのブログをケータイ小説大賞作品っぽく変換（ITmediaニュース）・・・同じソースですが mixi にも。あと、MSN にも。

（ご紹介ブログ）

-404 Blog Not Found:404あたしも彼女も見つかりません・・・スゴイところに紹介されてしまった・・・ちなみに Google Mobile Proxy が冒頭に来ているのは、mixi の新しい外部ブログ要約機能がすごい (ラボブログ) がホットエントリになってることとの対比かと思います。こ、これがアルファブロガーのガッツポーズか！直撃でくらった！

-−あたしブログ−を試してみた。みたいな。 / DESIGN Oil BLOG

-マジック１　つづく - ま、こんなもんでしょ

-2008-09-26 - 子持ちししゃもといっしょ・・・ブログパーツ設置ありがとうございます！

-なんだか悲しくなってきた。-あたしブログ - 人生てげてげ、ネコまっしぐら。

-浅倉大介貴水博之access::ソノハナ; | [雑記] あたしブログ　みたいな

-ヲタク入門中 | [ネット]あたしブログ。変換？みたいな。

-2008-09-26 - あなたわ　しにました

-9/25のメモ - propellershaft annex

-Q.給料日だけど給料ない。なぜ？ - みずしけのゴミ箱のようなもの

-2008-09-25 - auto-bookmark-agent

-2008-09-25 - チラシの枠＠はてな支部

-あたしブログ ～あなたのブログを２００８年最高のケータイ小説形式に変換～ htt... - Wassr [お気軽メッセージングハブ・ワッサー]

-あなたのブログをケータイ小説風にしちゃう　みたいな　「あたしブログ」*二十歳街道まっしぐら
　

ラボ神部です。

※2009/05/29追記※

楽天市場から個人情報がスパム業者に流出か、実名の記載された迷惑メールが楽天でしか使っていないメールアドレスに届き始める - GIGAZINE という記事の影響でこのエントリの参照が増えていますが、この記事が書かれたのは２００８年の９月２９日であり、昨今の事案とはあまり関係がないものと思われますので、念のためご了解をお願いしておきます。

※追記終わり※

今日、楽天市場のメルマガ登録確認画面から個人情報が流出しているらしいという話が話題になっていますが、流出経路が何とも不可解。そこで、可能性をいくつか挙げてみて、下手な推理をしてみようかと思います。考察を飛ばして結論だけ読みたい方はこちらへどうぞ。

そもそもの原因は

そもそもの原因は、Google のロボットのように、メルマガの本来のセッション所有者以外が、メルマガ登録の画面遷移の跡をたどっているところにあります。

URL で言うと

https://emagazine.rakuten.co.jp/ns?act=chg_rmail_delete_conf&k=

の act= のあとがコマンド、k= のあとの部分がセッション ID になっているのは明らかです。楽天がどのようなプラットフォームの上で動いているのかわかりませんが、PHP なら php.ini で session.use_trans_sid オプションを ON にするとこのような URL でセッションが処理されることになります。※ちなみに trans はtransparent（明白な）のことと推察されます。

この形式をとるときにはセッションハイジャックなどの対策が必要ですが、楽天のメルマガ登録ではそのようなセッションハイジャックの対策が十分に取り切れていなかったのが原因かと思います。

しかし、それだけではすぐに Google のロボットが検索可能になるわけではありません。これらのセッション情報を含んだ URL が外部にどこかで晒される必要があるわけです。ここから先はその原因について考えてみます。

Google などサーチエンジンが悪いよ説

emagazine.rakuten.co.jp/robots.txt を見ると、今回キャッシュされている /q や /rs /n /ns 以下の確認画面系はすべての User-agent に対して Disallow になっています。これを無視してクロールしたなら、まずは Google のロボットに責任があるわけですが、これは現時点のものですし、明らかに今回の問題の対策と見られる記述内容とも取れますので、Googlebot のマナーが悪かったという考えはひとまず排除しておきましょう。

実際問題、MSN で同様のクエリを実行しても、同様にキャッシュから個人情報を確認することが出来ます。名前とメールアドレスのペアはすぐには見つかりませんが、メールアドレスだけならすぐに確認することが出来ます。Yahoo! Japan の検索結果には該当するキャッシュはありませんでしたが、一般的なクローラが到達可能な箇所に、これらのセッション情報を含んだ URL が置かれていたと考えるのが自然で、そういう意味でも Google、もとい一般の検索エンジンのクローラーの動きを情報流出のプロセスと考えるのは難しそうです。

今回登録が yahoo や hotmail などフリーメールが多いため、それらのウェブメールのメールボックスをなぜかクローラーが検索してしまったのならこれらの個人情報が含まれたページをインデックスする可能性もありますが、それであれば楽天以外のセッションハイジャックされたページもいくらか見つかっていてもよさそうなものです。結論としても面白くないので、少しこの可能性は置いておきます :)

楽天が積極的に情報を公開しちゃったよ説

検索エンジンのロボットを呼び込む方法はいくつかありますが、より確実なのは各検索エンジンにサイトマップを登録することが挙げられます。特に 2006年に Yahoo!,Google,MSN共通のサイトマッププロトコル[sitemap.org] が策定されたことにより、同じ形式のサイトマップでどのような検索エンジンのロボットも呼び込み安くなりました。

あり得ない間違いですが起こりうる話としては、楽天の使用しているプラットフォームが、内部で処理された URL（あるいはアクセスログの解析結果）からサイトマップを自動生成して、各サーチエンジンに登録していた場合でも、現在のような状況が再現できないとは言えません。

しかし、そもそもサイトマップを自動アップデートするためには、まずは手動でサイトマップ情報を申告する URL を登録しなければなりません。ここで人為的ミスが発生し、不要なホストのサイトマップまで登録してしまったという可能性も考えられますが、誰でも十分目視できる分、あまりこの可能性は高く見積もるべきではないと考えます。それに、Yahoo! Japan のクローラだけが、これらの URL を全くインデックスしていないのも不自然です。

第三者のサービスを使ったユーザが悪いよ説

サーチエンジンでも楽天でもなければ、個人情報をオウンゴールしてしまったのは誰でしょうか。まだ考えられるのが、ブラウザを使ったユーザーである可能性です。例えば Alexa や Pathtraq を使ったサイトアクセス履歴の情報収集のアドオンをインストールしている場合、これらが結果的に表面化する機会があれば、その履歴公開されているサービスの公開ページが十分にユーザ情報をサニタイズしていなかった場合、サーチエンジンのクローラに見つかってしまい、セッションハイジャックされた状態でインデックスされてしまう可能性があります。

しかし見たところ、Pathtraq のデータベースには emagazine 以下のホストは今日以前のトラフィックはほとんど無いようで、データベースの母数がまだそれほど莫大でもない限りは、これらの情報が整理され消えてしまったとは考えにくいでしょう。そもそも多くのサーチエンジンにある程度の量インデックスされるためには、一定量のリンクが公開されているべきでしょうが、そのような物量も感じられません。

他にもブラウザネイティブで Google Chromeのアドレスバー「Omnibox」に入力されたユーザー情報を収集するであるとか、Mozilla の会長が匿名ユーザ情報の収集をすることを示唆するなどの動きがありますが、これもまだ先のことで、履歴の自動収集というところまでには至ってません。

メールに対応したセッションハイジャックツールがあった可能性

楽天のメルマガを一括配信停止するためのインターフェースとして、【楽天市場】楽天のメルマガというページがあります。ここに自分のメールアドレスを送ると、

[楽天ショップのメルマガ一覧 登録情報確認・変更・配信停止]
https://emagazine.rakuten.co.jp/ns?act=chg_rmail&k=******************

という形式で、セッションID付きの URL がメールで返ってくるそうです。いちはやく楽天のセッションハイジャックが可能がだと気づいたスパマーがいれば、ユーザ情報収集のために手持ちのアドレスを投げ、万が一ユーザとの配信経路の間でパケットキャプチャが可能な状態が何度も続けて起こり、返信メールの内容からセッションをハイジャックした後ユーザ情報（氏名や住所など）を獲得したかもしれません。

しかしこの場合は、その情報を Google のクローラや MSN のクローラにプレゼントする動機がありませんので、流れとしてはありそうですが実際に起こることかどうかはやや疑わしく感じられます。ユーザ情報が漏れていることが公になってしまったら、困るのはスパマー自身ですからね！それにユーザにも心当たりのないメルマガ配信停止確認のメールが来たりすると、不審に思ったユーザが楽天に通報してことが発覚する可能性も高いです。

またパケットキャプチャはベタな方法ですが、今回のサイトは https:// で保護されているので、正しく設定されていれば通信経路は暗号化され、パケットキャプチャに対してはある程度の安全性が確保されているようです。HTTPSの通信内容をキャプチャする方法 もあるようですが、これを実施するにはスパマーが介在しなければはサーチエンジンベンダー自らがそういった Evil なツールを使用する必要があるので、現実的な理由には考えがたいように思います。Google と MSN が同時に同様のツールを使ったとなると、ますます考えにくいでしょう。ましてやセッション情報の入った URL をインデックスするために、そんなことをするでしょうか？

犯人は何処に？～もうひとつの可能性～

このエントリを書き出した時点では、それほど犯人の検討はついていなかったのですが、情報をまとめているうちに自然な形でアクセス履歴が流出する可能性について思い当たりました。可能性としては、emagazine.rakuten.co.jp の Web サーバのアクセスログが、なんらかのかたちで外から参照可能になっていた場合です。

これを発見した誰かが、巨大なものでなくてもどこかのブログや小さな掲示板に記載としたら、それを起点にサーチエンジンが多くのセッション情報をクロールし、結果として多くの個人情報が含まれたページをインデックスしていった可能性が考えられるのではないでしょうか？

しかし、真面目に考えるのならメルマガ配信サーバのアクセスログ（ましてやセッション情報が記録されているような類のログ）が十分に管理されていたのなら、この推測は破綻します。楽天のような大きな事業のサイトでは、こういったセキュリティの細かい部分の見落としよりは管理が徹底していそうな気もしますし、可能性はやっぱり低いかもしれません。

最後にやっぱり確率が高そうなもの＆犯人の似顔絵

いろいろ考えてみると、やっぱりメルマガ配信停止 URL の

http://emagazine.rakuten.co.jp/ns?act=chg_data

およびそこから返信されてくる

https://emagazine.rakuten.co.jp/ns?act=chg_rmail&k=******************

のコンボがとっても怪しい気がします。スパマーツールではなくとも、なにかここにメールアドレスを投げてウェブ上でメールの返信が閲覧できるような仕組みがあれば、そこが一番怪しいのではないかと思います。

似顔絵に例えて漏洩元となったページの条件を挙げるとすれば

１．楽天のサービス・ショップの顧客が多く使っている

２．サーチエンジンもそのページにアクセス出来る可能性がある

３．ウェブメールのようにメールアカウントをコントロール出来、内容もウェブで読める（＝セッションID付きのURLを含んだ文章が半永続的に保持されたページが含まれる状態）

といったものを満たすものになるはずですが…。

最終的には原因はどこに出てくるのでしょうか。セッションハイジャック対策について勉強しながら、続報を待ちたいと思います。

（追記）

はてなブックマーク の関連エントリーを見ていて、JavaScript によるCookie 情報の組み合わせからメルマガ解除 URL を再構築するツールに、その部分に脆弱性のあるウェブブラウザでアクセスしたら、最後の似顔絵と同様のものが出来るような気もしました。JavaScript を使わなくても、なんらかのリファラーが漏れるタイプの掲示板があれば、そこを通じて流出する可能性もありますね。

そうすると、emagazine.rakuten.co.jp にリンクしているページが怪しいということで、容疑者としてはこのあたりでしょうか。重要参考人というほどでは、ありませんけどね。

link:emagazine.rakuten.co.jp - Google 検索

（追記２）

セキュリティホール memo さん経由で、@水無月ばけらのえび日記さんでも同様の考察がされていることを知りました。やっぱり Google Chrome 疑われています。なんらかの形で個人情報を収集しているウェブブラウザなどのツールは、今後もあらゆるセキュリティ or プライバシーインシデントで容疑者に挙げられそうですね。

それから Google と MSN Live Search で確認されているので、ひょっとしたらと思って探してみたらどうやら 百度 のキャッシュでも露呈しているようです。これはどうやら持ってけ状態になっていたことは確実ですね。むしろ Yahoo! Japan は YST で集めた後は何か別の理由のためにセルフサニタイズしているのかもしれません。

（追記３）

さらに Baidu を調べていると、かなりの重要参考人とおぼしきページを見つけました。Baidu を link:emagazine.rakuten.co.jp で調べると、ある共通点を持ったページが出てきます。

その共通点というのは、ほとんどがメルマガのバックナンバーページということ。これは似顔絵の項目で挙げた３つの項目を、７５％は満たしていると思われます。肝心のセッション情報は保持されてはいないものの、メルマガ配信停止 URL として、ショップオーナーのものとおぼしきメールアドレスが URL エンコードされて公開されています・・・

ということは、今回流出したメールアドレスが顧客の物ではなくショップオーナーのものであれば、説明はショップオーナーに対してだけで済むことになりそうですね。ただし、ショップオーナーが自らのメールアドレスの配信ページからセッション情報が含まれた URL にまでたどり着く機会があるかちょっと不明です。クローラがリンクをたどっていく過程で、メールアドレスがセッション情報に変換されてしまう機会があれば或いは・・・という感じですが。

ひとまずこのショップオーナーのメルアド入りメルマガバックナンバーの配信停止 URL にはもう少し注目してみたいと思います。これが楽天により自動生成されたものか、オーナーが自分で記載したものかによって、また対応が変わってきそうです。

（追記４）

ちょっと過程は省きますが、

https://emagazine.rakuten.co.jp/ns?page=0&sort_type=0&r_type=4&act=chg_rmail&k=(セッションID)

という、ユーザが登録しているメルマガの一覧を確認出来るページが Google のインデックスにキャッシュされていることが確認出来ました。

ここから、

https://emagazine.rakuten.co.jp/ns?act=chg_usr&k=(セッションID)

という、ユーザの氏名や生年月日、住所の確認出来る件「登録情報の変更」ページにリンクが張られています。どうやら実行犯はこのページということで確実なようです。

となると、あとはこのようなユーザ情報ページにどうやってサーチエンジンが到達したかという疑問がやっぱり残ります。どこかに、認証済みセッションの URL のリストが公開されていたと考えざるを得ませんね…。

そのとき、たまたま本当のユーザがログインして運悪くセッションがアクティブになっており、サーチエンジンのロボットも同時に内部に進入できてしまったという感じかもしれません。おそらく楽天からの報告では、その部分が明らかになるのではないでしょうか。

こういう場合の対処方法としては、脆弱性を修正した後ユーザは強制的にログアウトさせて、セッションIDを変更してもらうしかなさそうですね…。

（追記５　犯人はソーシャルブックマーク？）

こちらの はてなブックマークコメントページ で、id:kengo9999q さんが「某ブックマークサービスを疑ってる」とコメントを書いていらっしゃいますが、限りなく正解に近いようです。

実際に、はてなブックマークのドメイン b.hatena.ne.jp 以下を emagazine.rakuten.co.jp で検索してみると…見事にセッション ID 付きでブックマークされているページがいくつか発見できますね…。ちなみにそのうちの日付のひとつは 2007年05月13日になっています。

ブックマーク先の URL としてポイントされているのは

https://emagazine.rakuten.co.jp/ns?act=chg_rmail&k=(セッションID)

この事実から流出過程を組み立ててみるとすると、次のような感じになりそうです。

１．ソーシャルブックマーク（例えばはてなブックマーク）にユーザがセッション ID 付きでメルマガ解除 URL を追加（たぶん、メルマガ情報解除した後に、これは便利だと言うことで）

２．サーチエンジンのクローラが新しく生成されたページをクロール

（共犯としてはソーシャルブックマークの提出したサイトマップの可能性も考えられる）

３．Googlebot がセッションが有効な間、もしくは再度セッションが有効になった際に偶然クロールして、本名や住所が見えた状態でインデックスされる

流出の原因となった経路は複数あるかも知れませんが、少なくとも昨年からこのように外部からクロールされる状況が確認出来る以上、これは経路のひとつとして認定しても良さそうです。このケースに於いては、ユーザが自分のセッション情報を残したままブックマークしたところに突破口が生まれてしまったわけですが、ここで多少判断のグレーゾーンが生まれそうです。

もしユーザとしてもパブリックにするつもりでなくブックマークしていたのなら、ブックマークのプライベート性の有無についてアナウンスが十分でなかったソーシャルブックマークサービスが悪い、と見る人もいるでしょうし、もっと言えばセッション情報をソーシャルブックマーク側でサニタイズすべきだ、と極論を述べる人もいるかも知れません（大手サービスのセッション情報に対してはそれもサービス継続のリスクを排除するための防衛策としては有効かも）。

しかし根本的なところを見直すとすれば、やはりメルマガ解除の仕組みのセッション管理についての扱いに配慮が必要だったのではないでしょうか。そこの対策があれば、クローラが来てもユーザの情報を持って行かれないように最大限努力することはできたように思います。

もし、同様の仕組みを実装する機会があれば、毎回異なるセッション ID を発行するようにするとか、期限を十分に短くしたり、ユーザエージェントの監視、robots.txt の設定をきっちり行うなどが必要になってきそうです。

また万が一の場合に備えて、ソーシャルブックマーク（Not オンラインブックマーク）などにこのような URL をブックマークしないように呼びかけることも有効かも知れませんが、それは広くお願いするにはちょっと酷なお願いかもしれませんね。自分で同様のものをつくったときも、同じような穴を作ってしまうこともありそうなので、このような事例を知見として今後の開発に生かしていければと思います。

（追記６

ソーシャルブックマークも原因のひとつ、という続報が出たようです。対策調査とあわせて別のエントリにまとめてみました。