本件、原因不明のまま、金曜深夜に復旧いたしました。
復旧も突然で、また繋がりにくいということもなく快調に接続しております。
いろいろご心配をおかけしました...それにしても何だったのだろう...マジで乗り換えた方がいいのだろうか。

---------------------------------------------------------------------------------------

原因がまだ不明なのだが突然障害が起きて2日前から家がネット孤島状態。
26日の深夜24時頃突然ルータからプロバイダへのPPPoE接続が切れて、その後全く繋がらない状態。
断続的、とかでもなく全く繋がらない。

ルータ上のログを拾ってみたが、こんな感じ。

2007/09/27 23:03:24 PPPoE Couldn't get channel number: Transport endpoint is not connected
2007/09/27 23:03:24 PPPoE Connecting PPPoE socket: 00:00:00:00:00:00 0000 0x10012000
2007/09/27 23:03:24 PPPoE Re-sending (3/4)...
2007/09/27 23:03:16 PPPoE Re-sending (2/4)...
2007/09/27 23:03:12 PPPoE Re-sending (1/4)...
2007/09/27 23:03:10 PPPoE Re-sending (0/4)...
2007/09/27 23:03:09 PPPoE Sending PADI

ルータがプロバイダと通信できていないっぽいので、まず断線を疑って、ルータ -- VDSLモデム間のLANケーブルを変えてみたが状況に変化なし。
次に、VDSLモデムから引き込み口までの電話線ケーブルを交換したが、これでも変化なし。
というか、VDSLモデム経由で接続している電話から普通に通話できるので、物理的な断線はないっぽい。
念の為、電話線の引き込み口も他の部屋のに移してみたりもしたが、全く改善なし。

2日間So-net及びUSENの障害情報もチェックしたが、全くうちの周りでは、数分の瞬断以外は何も報告がない。

こうなると、問題がありそうなのはVDSLモデムか戸外でマンション内の機器ぐらいしか思いつかないのだけど、モデムは業者から送られてきたレンタル品（DASAN H320）なので代替を繋いで比較、なんかもできないし、戸外の設備なら何も手を出せないので、お手上げ状態。
仕方ないのでテクニカルサポートに電話したのだけど...もうなんかテクニカルサポートと言うとWindowsネットワーク接続できない！とかってレベルの問い合わせばかりのせいか、いちいちOSが、Webブラウザが、メールソフトが、みたいなレベルでたらい回しにされてイライラさせられそうな感じが嫌。
なので、最初に全部、ここまで調査して、ここまでは切り分けた、といった事象を全部伝えてみた。
すると、「判りました、それではお客様のお使いのOS、Webブラウザ、メールソフトを教えて下さい」もうええっちゅうねん！
だからそういう次元の話じゃない、もっと下位レイヤの話なんで調査なり来てもらわないといけないかもしれないから、そのレベル判る人と変わって欲しかったんだが、次は「それでは、PCを操作いただけますでしょうか」ときた。
平日昼間、ユーザサポートが対応している時刻なんかに、PCが操作可能な家におるかっちゅうねん！仕事場や仕事場！
それに、PC操作させてどないすんねん？PCのネットワーク設定レベルの話じゃないことは散々話したし、それ以上の確認しようにもサポートセンターの人はうちのネットワーク環境の構成なんか知っとるんか？それが判らんかったらPC触らせたって何にもできんやろうに。
時間ばっかりかかって埒があかないので、もうあきらめて電話サポートは切った。

今度はメールサポートを見つけたので、上で書いたようなこちらで調査し切り分けた内容、エラーメッセージ、等等もろもろを全部書いた上で、メール通知してみた。
そしたら何？レスポンス希望日として同日午後に希望を出したら、レスポンスは早くてもメールでのサポート申請から3日後以降になりますってどんだけ！
ネットが切れてるという一大事に対し、初動まで3日間待てってか？しかもそれで直るとは限らんわけなのに。
原因特定・復旧までにさらに数日かかるとしたら、下手したら新しく他社サービスに乗り換えた方が早いくらいの時間スケールとちゃうの？

電話サポートのレベルは低いわ、メールサポートのレスポンスは殺人的に遅いわ、So-net光（UCOM）最悪！！
何を考えてるのやら。

まだ俺の場合、サラリーマンで私用でしか使わん家庭回線だからええよ。
障害に関する情報集めたり、復旧までの代替回線としてケータイモデムのドライバダウンロードしたり、なんてのも会社でやろうと思えばできる（それが会社ネットの私的利用として、よいかどうかは別として）。
家でSOHOやっててこんないい加減なサポートのために1週間以上もネット断されたとしたら、死活問題じゃなかろうか。

Windowsの設定ができません、レベルのサポートも当然必要なのは判るけど、もうちょっとレベルが高くてこちらで確認したレベルからの話がすぐできる、レスポンスの早いサポートを準備して欲しいなあ。

あーあ、iGoogleガジェットコンテストの〆切が来週明けなので、追い込もうと思ってたのに、この調子じゃ週末中には復旧しそうにないなあ。
くそ、マジムカつくSo-net光（UCOM）！So-net光（UCOM）！So-net光（UCOM）！ボケ！

戦中に朝鮮人帝国陸軍将校だった洪思翊中将のことを調べていて、こんな記事に出会った。

洪思翊??忠誠　-犬鍋の韓国便り-

洪中将の為人はおぼろげに知っていたが、このブログには彼だけでなく、他にも日帝時代の実際を生きた数々の朝鮮人の証言が引用・紹介されていた。

カテゴリ：日帝時代の証言　-犬鍋の韓国便り -

どの証言一つとっても、「日本は韓国人を差別した、収奪した」とか、「日本は韓国によいこともした、併合は韓国人が望んだ」とか、どちらの立場からも一刀両断にはできない複雑さを持っているし、また個々のケースも、日本に留学した者、祖国で暮らした者、それぞれの立場の違いをはらんでいる。

どのケースも時代の証言として貴重なものだし、またここで紹介されているものに限らず、あらゆる時代の証言が一面では真実なのだろうと思うが、しかしだからといって、そのうちの一つを取って時代を代表する証言とすることはできない。
例えば、

• 創氏改名は強制性をはらんだ制度ではなかった、と言ったところで、末端の運用現場では事実上の強制だったケースがままあったようであり（ちょうど最近、北九州で本来の生活保護の精神と異なる運用が現場で為されて餓死者が出たように）、それに接した朝鮮人が「創氏改名は強制」と主張するのに対し、「強制ではない」と主張したところで何も真実には近づけない。
• また日本の責任と救済と訴える慰安婦達にとって、慰安婦になったのは確かに、騙されたりして自分の意図と異なることを強制された結果の不幸であったのは事実かもしれないが、しかしだからといって、その彼女達に不幸を押し付けた犯罪的な実体が、本当に彼女達が主張するように日本の軍部そのものであったのか、それとも単に悪徳業者の暴走であったのかは、彼女達の証言だけでは証拠にはならない。

といったふうに。
ましてや、当事者でもない者が、自分達の政治的立場に都合のよい証言だけを持ち上げ、自分達の主張の補強として政治利用し、対立する証言をする当事者を「嘘吐き」等と罵倒するような卑劣な行為は、信用し鵜呑みにするようなことはあってはならないと思う。
出来うるとすれば、いくつもの時代の証言に直接接して、謙虚に個別事例として受け止め、その上で自分なりに時代の全体像を整理し、雰囲気を大まかに感じとることだけではないかと思う。

最初に引用したブログ記事内で、韓国の文化日報記者が

人間とはわれわれが考えるよりずっと複雑な存在だという点だ。

と述べているが、その人間が多く集まって成立しているこの「社会」は、さらに複雑な存在だ。
一面からだけ見て判った気になり、軽々しく断罪するようなことは、あってはならないと思う。
我々にできることはせいぜい、その時代に翻弄されて不利益を蒙った人間が今も生きているならば、それを救済できるならばせめても救済する事、そして同じ不幸に陥る人間が再び出ることがないよう学ぶ事、くらいしかないのではないかと思う。

携帯の位置情報エンタテイメントサイトを作る際の強敵、位置情報詐称について以前取り上げましたが、勝手サイトで位置情報エンタメサイトを構築する場合、もう一つ強敵がいるように思います。
それは、DoCoMoでのセッションハイジャックによるユーザ詐称の問題です。

DoCoMoは、公式サイトだとアクセスする各ページ毎にユーザの登録者IDを返してくれるI/Fが存在するので、ユーザが詐称される危険性は存在しません。
問題は勝手サイトです。

勝手サイトでは、DoCoMoはユーザの登録者IDは通知してくれず、代わりに端末IDを返すI/Fが用意されています。
端末IDでも、機種変した場合他人になってしまうことや、端末を譲渡した場合他人が同一人物になってしまう点に注意すれば、基本的には個人認証に利用可能です。
ですが、このI/Fが曲者で、このI/Fを通じてアクセスする毎にユーザに「端末番号を伝えてもよいですか？」とユーザに注意喚起するダイアログが出るので、全てのリンクに埋め込む事はできません。
にも関わらず、端末IDの通知はI/Fを通じたアクセス時にしか通知されないので、その後のアクセスについては、ログイン状態を保持しようとすると、自前でセッション機構を作って保持しなければならない仕組みになります。
さらにDoCoMoはクッキーが使えないので、そのセッションIDはURLに埋め込むより他に方法がありません。
勢い、セッションIDが漏れればセッションハイジャックの危険が存在することになります。

これについては、私の仕様確認不十分や、技術的手法検討不十分の可能性も考えていろいろ調査しましたが、私なんかより数倍数十倍上のクラスの技術者が多数在籍する会社のサービスなんかでも、余裕でセッションIDをコピーすれば他の端末からでもセッションハイジャックできてしまう状況だったので、間違いないと思います。
もちろん、これは仕様上回避しようがないことですし、また当然、その中でハイジャックの可能性を極限まで避けるようセッションの時間制限を設けたり、いざハイジャックされても被害を最小限に抑えるよう、登録情報の変更等センシティブな部分へのアクセスは事前にID/PWの再入力を促す等、最大限のセキュリティ施策が打たれています。
自分から好き好んで、セッションハイジャックしてもらうためにセッションIDを漏らすような奴もいないでしょうから、これはこれである程度のセキュリティは保たれているといえます。

しかしながら、位置情報を使ったゲームサイトでは、話が違ってきます。
やれブログだ、SNSだ等だと、自分のセッションを乗っ取られてもユーザに何の得もありませんが、位置情報エンタメ・ゲームサイトでは、セッションをわざと乗っ取らせて自分の分身をたくさん作った方が、明らかに有利になります。
複数の端末から同時に「自分」としてアクセスし、別行動を取らせて別の場所に同時多発、という状況を作った方が、ゲームで有利な立場になるわけです。
セッションIDに時限を設けても、URLを表示してセッションID部をコピペする等一瞬ですから、詐称に加担する仲間が居れば、すぐにでもメールで広めて自分の分身をいくつも作れるわけです。
かといって、セッションIDをコピペする時間もないほどセッションの有効時間を短くすれば、今度はまともにゲームとして成り立ちません。
この問題は、もう少し検討してみる必要がありますが、今のところ防ぎようがないように思います。

実際、過去私がこちらのゲームを前管理人として運営していたころ、ユーザの機種変やキャリア変時に便利だろうと単一アカウントに複数の端末を割り当てられる仕組みにしていたところ、見事に複数人でアカウント共有されて、不正されたことがあった（まあ、当時の俺は「不正ではなく仕様、マターリやろうよ」とか逃げてましたが）。
それと同じ状況が、DoCoMo勝手サイトだとセッションIDを用いてできてしまい、防ぐのは非常に困難になります。

というか、位置情報詐称問題と回避法を紹介したの前回のエントリと違い、今回は問題の紹介だけで、回避法は私もまだ思いついてません。
何かよい案を思いつかれた方がいましたら、共有いただければ嬉しいです。

友人からの依頼に基づき、私も「なんちゃって」ながら民族楽器奏者として賛同の上、呼びかけさせていただきます。

目下、東京芸術大学は小泉文夫記念資料室（以下、小泉資料室）の管理体制を経済的な理由から変更しようとしています。そして、小泉文夫が収集した資料が分散されようとしています。

これらの変更の話は以前から耳に入っており、来月に小泉資料室の運営について意思表示する為に音楽イベントを行うことを計画していましたが、来週（２００７年９月１７日からの週）に、今後の方向性を決定する会議が行われるという情報が突然入りました。

そこで以下の文章をできるだけ多くの方にメールで回すことに致しました。世の中での小泉資料室への関心を高め、こうした改悪をやめさせるべく、皆様の意思表示やお力添えを頂けますよう、よろしくお願い致します。さらに、お知り合いへ回覧して頂けると幸いです。

この度は時間が限られているため、メールを活用しての署名活動を行います。ご賛同頂ける方は下記のメールアドレスまでご意見をお寄せ頂きたく存じます。その際はタイトルを「Re; 小泉文夫の資料が散逸の危機にあります。御力添えをお願い致します。 」とし、本文の最初に「小泉文夫の資料の分散と助手の常駐の廃止に反対。小泉文夫の資料の一括管理と助手の常駐に賛成。」として頂き、ご意見とお名前をお寄せ頂けますよう、よろしくお願い申し上げます。

東京芸術大学音楽学部音楽環境創造科３年
西原 尚

一学生の僕にはなかなか現状把握は難しいのですが、確認ができている範囲の事と、利用している学生の立場から感じた事を以下にまとめます。

「ひとつ、小泉文夫の蔵書を学内の他の蔵書と混ぜてしまう」

小泉資料室は音楽研究センターという組織の管理下にあります。そして、この度の変更によっては、この音楽研究センターの蔵書と一緒に小泉文夫の蔵書をアイウエオ順などで並べて、混ぜてしまうことになりそうです。小泉文夫が残した資料がせっかく一堂に集めてあるものを、わざわざ散り散りにしてしまうのは愚の骨頂です。小泉資料室には１万８
千点の書籍、写真、ノート、等と１万９千点のレコード、テープ、DAT、等の資料があります。（※１）パンフレットやチラシには小泉文夫のメモ書き等も数多く残されています。管理が変わることによってこれらの資料は散逸し、五十年後には神田の古書市で発見されたりするのでしょうか？

そして、小泉資料室には７００点を越える世界のあらゆる地域の楽器があります。これらの楽器は、ただ現地で買い付けた物ではなく、小泉文夫が世界各地の音楽家達と交流し一緒に吟味したり薦められる等して入手した、最高級の楽器ばかりです。これまではその膨大な展示楽器の隣に書架が有ったので、楽器を手に取り、蔵書を閲覧し、さらに音源を試聴するといった、五感を総動員する活発な勉強ができました。しかし、蔵書が移動してしまえば、こうした旺盛な学習は全くできなくなります。

また、私事になりますが、これまでの小泉資料室では、まず壁全体を覆い尽くす楽器群に息をのみ、隣のビル群のように膨大な蔵書に腰を抜かしました。そして小泉文夫の好奇心と行動力とエネルギーに鼓舞されたものです。また、小泉資料室から本を借りる時は学校の図書館ではなく、小泉文夫自身から本を借りるような愉快さもありました。蔵書が無くなれば、これらの体験は無くなります。

「ひとつ、世界各地の音楽を専門とする助手の常駐がなくなる」

これまで小泉資料室の開室時間には助手が常駐されていました。助手は理解ある寛大な態度で、しかし楽器の為に鋭いまなざしで、小泉資料室を見守っていました。管理体制の変更後はこれらの助手の常駐も無くなるようです。言うまでもなく専門家の常駐は非常に有効で、これまでは疑問を持ったその場で質問しすぐに回答やアドバイスを頂くことができました。それだけでなく、助手がいなくなる→施錠が必要になる→自由な出入りができなくなる→楽器に触れられなくなる、こうした図式も十分あり得ます。これは多くの学生の希望に反しているだけでなく小泉文夫自身の言葉にも反していると思われます。（※２）

繰り返しになりますが、ご意見を下記のメールアドレスへ頂けると幸いです。よろしくお願い致します。

東京芸術大学音楽学部音楽環境創造科３年
西原 尚

※１

図書	日本語　約３,６００冊　　外国語　約１,８００冊
楽譜	６７０冊
雑誌	日本語　約４３０種　　外国語　約５０種
楽器	約７００点
録音テープ	２,３２０点
映像資料	８０点
レコード	３,３７７点（国内盤　２,５１７点　　国外盤　８６０点）
スライド	約１３,０００点
プリント写真・絵はがき	１０,０００点以上
民族衣装	５８点
その他フィールドノートなど研究資料	１,６００ファイル以上
（２００６年４月現在）

※２　「…民族楽器が、僕の家には約千点ぐらいあるんだけど、どれにもいろいろな思い出があるんです。それらは学生が遊びに来た時、いつでも使えるようにしてあるんです。」小泉文夫著作選集２『呼吸する民族音楽』より

ゾロ目だお。

ちなみにBlogRankingのカテゴリ別順位は40位。
惜しい！もう少し下なら4×7ゾロ目だったのに。

遅れるにもほどがある記事ですが、9/6・7の二日間、慶応の三田キャンパスで行われた、gコンテンツワールド2007に行って参りました。
今回は、W3CのSVG WORLDが日本であることもあって、そちらとの共同開催となっていました。

9/7のみの参加で、おまけにダラダラしてたら朝一のインディゴさんのセッションを聞き逃す始末。
第2セッションの三重県庁のGIS事例（今回のスピーカーは、三重の鉄人コバテツさんではなく存じ上げない人）から聴いてまいりました。

第3セッションが、今回の主目的だった、友人の株式会社ゴーガの小山さんの発表「携帯向けGISソフトウェアの可能性と課題」。
ゴーガで作られているdoodle等のWeb位置情報アプリの実例を元に、Web及び携帯の業界での位置情報アプリの歩みを概観されていました。
さらに、私もいっちょかみさせていただいているのですが、携帯GISアプリが個別に位置情報を持っているだけじゃユーザに不便だよね、サイト間で位置情報の流通ができたら便利だよね、と言う発想から進められている、GISゲートウェイ構想について紹介。

なかなか好評だった模様。
隣の席だったKDDI研の高木先生にも、「ガチガチの仕様を作って対応するアプリが何もない、というような状況よりも、まず今のデバイスでできることから、という姿勢はいいね」という意見をいただきました。

その後昼休み。
小山さんや共通の友人と近くのファミレスで食事していたのですが、話が盛り上がりすぎて午後のセッションをかなり飛ばしてしまいました。
その食事の席で、小山さんの発案ですごい面白いGIS系のアルゴリズムの案が出てきました（アルゴリズムそのもの、ではなく、こんなことを計算できるアルゴリズムがあれば面白い、という案）。
詳しくは書けませんが、その話でもかなり盛り上がったり。

午後はまず、展示スペースを覗いてみました。
オークニーのMapServer・MAPGUIDEや、インディゴ等のSVGビューアといったお馴染みの展示の他に、驚いたのが可視光通信コンソーシアムの展示があったこと！
いやあ、以前この記事書いてから、私可視光通信萌えだったんですが、まさかgコンテンツワールド会場で会えるとは！
実際に動く機器も見せてもらいました。
というか、可視光通信萌え、といいながらも別にメインで追っかけはしてなかったんですが、既に利用する周波数帯や通信の規格等も定められていて、それに準じた発信・受信機器も数社から発売されているそう。
数mくらいの距離まで通信可能で、数kbps程度の通信速度なのでID情報程度をブロードキャストし、実際の情報は別のルートで取ってくる、といった仕様みたい。
でも、私の期待していた可視光通信というのは、街角の信号機から常に街の情報がブロードキャストされているとか、そんなのを夢想していたので、数mしか通信できないの？とか思って聞いてみた。
すると、今決まっている仕様ではそうだけど、当然私が行ったようなことを研究している人もいて、別の周波数帯で別の規格として研究・調整されているとのこと。
安心した。実現する将来が楽しみだ。

ところで、裏の繋がりは知らないけど、表で知る限りでは、これまでgコンテンツ協議会と可視光通信コンソーシアムって特に絡んでいた様子はなかったんだけど。
それが今回のgコンテンツワールドで出てきたのってどうしてかなとか考えた時に。
最近、gコンテンツ協議会が本を出して、そこに私もミニコラム書かせてもらってるんですけど、その中で個人的萌え位置情報デバイスとして、可視光通信を紹介させてもらってるんですね。

gコンテンツ革命 時空間情報ビジネス最新ガイドBook posted with amazlet on 07.09.15 gコンテンツ流通推進協議会 柴崎 亮介 翔泳社 (2007/07/18) 売り上げランキング: 176300 Amazon.co.jp で詳細を見る

今回のgコンテンツワールドも、その本の出版記念講演があったりとその本と密接に繋がってるんですけど、もしかしたら私が記事を書いたことが、gコンテンツと可視光通信が繋がった原因だったりしたら嬉しいなあと、大人の事情はさっぱり判らん万年精神年齢15歳のオサーンは妄想するですよ。

講演会場に戻ると、第6セッションの、Yahoo!Japanのgコンテンツに関する取り組みから。
Yahoo!はやっぱり、持っているコンテンツの豊富さと、ワイワイマップや古地図等、エディトリアル的にユーザを引き込んで盛り上げるのがうまいなあという印象を受けました。
APIとしても、豊富なPOIのI/Fの他、普通の地図APIだけでなくFLASHで地図を回転させられるAPIなど、面白い取り組みをされているみたいです。
あ、そうそう、年内には世界地図にも対応するとの事。

次は、MicrosoftのLive Searchの話題。
驚いたのは、まだ世界40都市くらいしか実現していないらしいのですが、「普通のGoogleMapsライクな、地図と衛星写真のフリースクロールWeb地図」から、ぐいっと視線を変える操作をするとシームレスに3D都市マップになったこと。

どうやって実現してるんだろう？さすがにAjaxじゃないよね？FLASH？というか今MicrosoftがやるんならSilverlightか。FirefoxやSafari、他のOSでも動くんだろうか？Windows&IEオンリーっつうんだったらそれほど魅力ないけど、マルチに実現できるならすごい。
あとで確認しようと思ってアクセスしてみたけど、どこで確認できるのかよく判らなくて未確認。

ちなみにこの3D地図、買ったのではなくMicrosoftが自前で作っているものとのこと。

写真のような特殊なカメラを設置したセスナを各都市の上空に飛ばし、一通りスキャンした後写真をまとめてプログラムで計算してやれば、自動で3D地図を作ってくれるらしい。
もうこんな形で、ほとんど自動作業といってよい感じで、1ヶ月何都市、といった頻度で都市の3D地図を増やしているらしいんだけど、それには過去Microsoftが買収した、Vexcel社の技術がつぎ込まれているらしい。

しかし、このイベント「gコンテンツワールド」、事務局はgコンテンツのプラットフォームとしてオープンで汎用的な仕様「SVG」を推しているわけなんだけど（それもSVGWORLD2007と共催された理由）、にも関わらずこうして非標準独自仕様を提供しているYahoo!やMicrosoftといったところも参加して、「我々のソリューションでgコンテンツの世界を推進してください」見たいな感じで訴える呉越同舟っぷりが面白かった。
SVGが標準として推されている理由、及び独自仕様に対するメリットとしては、今後のgコンテンツが抱える課題

1. 新たな囲い込みの懸念(特定企業のAPI仕様に基づいた位置情報コンテンツ)　
   　⇒　標準仕様の必要性
2. POIデータの分散化、国際化対応におけるアノテーション（注記）のロケール分散管理化　　　　　　　　　　　　　　　　　　　　　　　　　　
   　⇒　分散ソースからの重ね合わせが可能な仕様（プログラミング等を介することなく）
3. モバイル等での用途(軽いデータ、進行方向を上にした地図が欲しい)　　　
   　⇒　ベクタデータの優位性

といったあたりに対して、

1. SVGで記載されたコンテンツは、JavaScript DOM等の標準APIでXMLタグを操作することで容易にオペレーションできる(独自APIのGoogle Maps API等に対する優位)
2. SVGで記載されたコンテンツは、ベクタデータであるため、回転・拡縮等がJavaScript等で容易に可能である
3. SVGで記載されたコンテンツは、JavaScript等さえ使わなくとも、リンク等で簡単に複数データソースからの分散POIデータやアノテーションレイヤ等を重ね合わせられる

といった明確な優位があるので、SVGを推し進めることに積極的な利点があるわけですが、しかしそれは、少なくとも現時点のSVGでは2Dの地図が業界の中心であるからで、今回のMicrosoftのソリューションのように3D化された地図というのが今後ユーザニーズの中心になってくるのであれば、SVGでは太刀打ちできないなと思いました。

最後はインデックスによる、モバイル業界におけるgコンテンツビジネスの現状・展望について。
最近よく聞くのは、ケータイがネット等ここまで「電話」以外の用途で利用されているのは日本だけの現象で、外国ではPDAあたりがその辺の地位を占めているわけなので、今後ケータイWebの世界は発展性や将来性はなく尻つぼみ、という話なんだけど、今回のインデックスの話を聞いて、そんなことはないな、と思わせられた。
確かに、ケータイでできる個々のことは、PDAなんかでもより高機能に代替できるんだけど、それらの機能を結びつけてハブのように連携させる力においては、ケータイ側に、PDAでは到底及ばない百日の長がある。
例えば、街角のポスターからQRコードでその場でイベントの情報を得て、すぐにチケットの販売サイトで個人認証して課金決済を行い、イベント会場までナビゲートしてもらい、イベントの様子を写真に撮って友達にメール送付する、等。
個々のことはPDAでもできるかもしれないが、それがここまでシームレスに、それも特にソフトをインストールする必要もなくデフォルトの状況でできる（デフォルトでできるというのは、ユーザにとって利便というだけでなく、それをプラットフォームとして使うビジネス側でも、端末を持つユーザ全員が潜在市場になるという意味で、利点である）、というのはケータイ以外のデバイスでは今のところ無理だろう。
インデックスはその事を、ケータイはメディア（現実）とメディア、或いはメディア（現実）とデータ（仮想）のハブ、という表現をしていたが、この立場を脅かすデバイスが現れない限り、ケータイの隆盛は続くだろうという感じの話で、非常に納得できた。

その後は懇親会。
オークニーの森さん等も来られていたので、さっそく昼に小山さんと話した新アルゴリズムの話をする。
森さんも非常に面白いとの好反応、オークニーでは、類似アルゴリズムのソリューションを既に提供されているので、それの新機能としてアルゴリズム検討・開発していただけるとのこと。
何をする、どんなアルゴリズムかは、数ヵ月後、オークニーからソリューション発表がある、或いはそれを用いたゴーガのアプリケーション発表まで待って。
今のところ世にない、非常に面白いソリューションになると思います。

PiTaPaがポストペイだということは知らなかったんだけど、その理由を読んで中々感銘した。

とりあえずリンクと心にひっかかったところの抜き出し。

PiTaPaはなぜ“ポストペイ方式”なのか――スルッとKANSAIに聞く

• スルッとKANSAI協議会は私鉄・バス会社がサービス改善を一体的に図るための「参加企業が集まる場の提供」（松田氏）と位置付けられている。同協会の取り組みは乗車券システムに留まらないのが特徴である。
  　…
  他にも、企画乗車券として従来では取り込むのが難しかった旅行者向けのサービスにも取り組んだ。それがスルッとKANSAIの43社局で乗り放題になる「3Dayチケット」や「2Dayチケット」である。これは国内旅行者はもちろん、海外からの旅行者も取り込んで年3万枚を超えるヒット作になった。
  　…
  スルッとKANSAIは設立当初から、私鉄・バス会社がお互いの経営状況を鑑みながら、力を合わせてサービス改善とコスト削減を総合的に行う仕組みになっていた。これが後のPiTaPa誕生における伏線になる。

• しかし、磁気式を導入してから3年しか経っていませんでしたから、ここで（同様のサービスとして）ICカードをやろうと言い出したら、各社局が『もう、やってられへんわ』という事になる。特に私鉄・バス会社は厳しい経営状況の中で、（磁気式のために）設備をすべて入れ替えて、多額の設備投資をしています。当時はバブル崩壊後の一番厳しい時期で、そうでなくても年2?3％の利用客減少が起きていた。その中で無理して磁気式に投資していただいる中で、 ICカードシステムの検討を始めたのです」（松田氏）
  　…
  一方、オクトパスでは当時すでに『オートチャージ』や『ポストペイ』の仕組みがありました。この口座引き落とし／ポストペイ方式を採用すれば、券売機や定期券発行機の（改修に伴う）投資コストがいらない。また、定期券や割引サービスへの対応も容易になることに気付きました。つまり、ポストペイ方式を採用することで“投資コストは改札機の改修だけ”で済み、“様々な割引サービスの対応もしやすくなる”わけです」（松田氏）
  　…
  PiTaPaの特徴である「ポストペイ方式のみ」という仕組みは、磁気式カード導入からわずかな期間しか経っていない中で、各私鉄・バス会社の投資コストを抑えて、いち早く非接触ICシステムの導入を実現するための“発想の転換”だったのだ。
  「ポストペイ方式での導入で試算したところ、（非接触IC対応が）改札機だけならば、投資コストは1/5ですむことがわかりました。これであれば各社の厳しい経営状況でも、何とか導入できる見込みが立ちました」（松田氏）

• 「我々は磁気式プリペイドカード導入時に『切符を買わずに乗り降りできる』とPRしたのですけれど、サービス開始後すぐにお客様から『（広告は）ウソやないか!!』と非常に多くのクレームをいただきました。確かに切符は買わずに乗り降りできるけれど、何回かに1回は必ず、カードを買い直したり、乗り越し精算しなければならないじゃないか、とお客様に怒られたのです。
  プリペイド方式を取る以上、非接触ICカード化しても、ご利用前のチャージ（プリペイド）や、残額を意識しなければならない部分が残ります。磁気式プリペイドカードで多くの苦情をいただいたことを鑑みると、お客様がこれら（チャージや残額確認）を望んでいるとは考えられない」（松田氏）
  　…
  「もうひとつお客様からの苦情が多かったのが、（カード購入で利用が多いのに）『なんでオマケがないの? おかしいんやないの?』というご意見です。これはものすごく言われました。
  また、回数券と定期券のどちらが得かがわかりにくいというご意見もありました。週休二日制が浸透してまいりますと、（どちらが得かは）非常に微妙なんですね。今でも通勤には定期券がお得だと思われる方が多いのですが、週休二日制だと実際は回数券の方がお得になるケースが多くなります。以前から割引制度が分かりにくいという意見があり、それらの改善も必要でした」（松田氏）

• PiTaPaはポストペイ方式を前提にし、駅設備の対応は自動改札機を中心とした改修のみ。自動改札機においても、従来型の磁気対応改札機に後付けできるFeliCaリーダーライターを導入し、設備投資コストは最小限に抑えられる仕組みとした。
  一方で、利用者側の利便性向上については、前出の5つの課題すべてをクリアーする内容になっている。ポストペイ方式なのでPiTaPaカードの発行さえ受ければ、その後は事前入金や乗越精算といった手続きは必要ない。電子マネーとしての利用とJR西日本との相互利用も当初から計画された。
  さらにPiTaPa最大の特徴が、割引適用のきめ細かさだ。PiTaPaでは1ヶ月分の利用が集計されたときに、各利用区間の実績に応じて定期券もしくは回数券と同率の割引が適用される。ユーザーが意識することなく、利用状況に応じて「自動的に安くなる」のがポイントだ。事前の手続きなどは必要ない。

引用し過ぎかな？
でもすごいなと思った。まさに一石二鳥、三鳥、四鳥。
「導入ありき」でなく、現場に立ってのコストダウンやユーザの視点で考えないと、できない発想だなと思った。

翻って我らがSuica/PASMO（というか関西出身なのでPiTaPaの方こそ我らが、と言いたいんだけど使ってるのはSuicaやPASMOだからねえ）。

私がPASMOを“買えない”理由

東京メトロの回数券は割引率が高く、区間運賃×10倍の金額（160円区間なら1600円）で、通常の回数券なら11枚、時差回数券（平日10時?16時と土日に利用可能）なら12枚、土・休日割引回数券なら14枚となっている。電車に乗る時間に合わせれば、かなりおトクに電車に乗れるだけに、“回数券＋定期券”ができなくなるのは非常に不便だ。
関西の私鉄で利用できるPiTaPaでは、1カ月の間に同じ区間に何度も乗ると、乗車回数に応じて割引が適用されるようになっている。後払いであることを生かした割引サービスだが、これに比べると、SuicaとPASMOは正規運賃のみで、複数回同じ区間を乗車した場合に回数券に相当する割引サービスがない（バスを除く）。プリペイド（前払い）だからPiTaPaと同じ方法での割引は難しいのかもしれないが、既存の回数券相当の割引が無理なら、せめて回数券との併用くらいはできてもいいのではないだろうか。

やっぱりPiTaPa魅力的。
導入コストがはるかに高いにも関わらず、ユーザにもメリットのないシステムって何なの？と思ってしまう。

何とかマッシュアップアワード出品。
開催発表と同時に申し込んだにも関わらず、「まだ時間あるよねー」で何もせず、結局また〆切前数週間でドタバタ。
次はこんな事がないようにしたいな（いや、繰り返されるのは判っているのだが）。

で、とりあえず出品も終わったので、今回は

はてなブックマーク > ここギコ！: MappletやiGoogleのガジェット等でOpenIDやはてな認証等を使う方法を思いついた

kazuhooku 実装みてみないとわかんないけど、危ない橋のにおい。別のガジェットからiframeされたらどうなるのとか、Consumerの身元をどうやってユーザーに提示するの、とか

の指摘で導入見送った「MappletやiGoogleのガジェット等でOpenIDやはてな認証等を使う方法を思いついた」の件続き。

認証情報の受け取りにJSONPを利用する -snippets from shinichitomita’s journal-

受け渡しをフロントでやることで、正当なConsumerかどうかをHTTPリファラレベルでチェックできる（AOL OpenAuthの場合とおなじ）。

ああ、なるほど…と言いつつ正しく理解しているか自信がないので、もういっぺん図に起こしてみる。

こんな感じかなと思ったんだけど、どうでしょう？
SIDをJSONPでサーバからもらった後、かつサーバに外部認証API起動ポップアップを出させる前に、もう一度サーバに確認する、とか必要でしょうか？

実装は…とりあえず出品して実装する目的がなくなったんで、気が向いたら、する。

全くの思いつき。
マッシュアップアワードあたりで使おうと思ってるんだけど、セキュリティとかツッコミどころ満載かもしれないので、晒してツッコミを待とうという。

と言っても、さすがにMappletと外部認証サーバだけで認証させるのは無理。
外部の自前サーバの助けがいる。

原理は上のシーケンス図に示したとおりだけど、自前サーバ上にログイン作業の進行状況を通知するCometインタフェースと、外部APIに遷移させるだけのWebインタフェースを用意する。
で、Mapplet上でユーザのログイン操作を受け取ると、Mappletでは適当なセッションIDを生成し、そのセッションIDを付加して自前サーバのCometインタフェースに、ログイン状況監視のリクエストを非同期で投げる。
同時に、その同じセッションIDを付加して、外部APIに遷移させるだけの自前サーバのWebインタフェースをポップアップする。
自前サーバのWebインタフェースは、付与されたセッションIDをユーザのクッキーに食べさせると共に、外部認証APIにリダイレクトする。

外部認証APIでの認証作業が完了すると、ログイン情報付き処理が自前サーバのWebインタフェースに戻ってくる。
そこでWebインタフェースは、クッキーからセッションIDを読み込み、そのセッションIDを持つCometインタフェースにログイン情報を通知し、同時にユーザのクッキーを消去、そして自分自身のWindowをクローズする。
Webインタフェースからログイン情報をもらったCometインタフェースは、非同期に返答を待っているMappletに対しログインの結果を返答し、それを受け取ったMappletは、結果に従いログイン状況の変数をセットする。

というような形を考えたのですが。

セッションIDがそのまま流れたりクッキーに保存されるので、ばりばりセッションハイジャック余裕かもしれないのですが、結局ログイン作業の一連の中で、ユーザ画面の遷移とログイン結果を待っているCometインタフェースとを紐付けるためだけのセッションIDで他の事に使うわけではないし、かつ都度発行するIDなわけなので、ハイジャックされたからといって何？してどうするの（セッションハイジャックして何か悪さしたところで、その結果が表れるのはハイジャックしたユーザ画面ではなくされた方のMapplet画面なので）？という感じなので、問題ないんじゃないかなあと。

とは思うのですが、見落として何か問題があるかもしれないと思うので、晒してみました。
ツッコミお願いいたします。