OTCHY.NET

最近、Google 日本語入力なるものが発表されて、にわかに注目を浴びています。
使用後のレビューなどを見る限り、Google が持つ圧倒的な情報量を武器に、Social IME の理想を実現したと思わせる秀逸な出来のようです。
例によって、Google は無料配布してますし、MS IME の馬鹿さ加減も手伝って、今後、普及が進んでいくのではないかと思います。

そのニュースの興奮もさめやらぬ中、Google Public DNS なるものが発表されました。
こういった流れをもって、いよいよ Google 帝国の世界支配が現実味を帯びてきた…という論調が、以前にも増して声高に聞こえるようになってきました。
(ちなみに、無料 DNS の煽り文句に踊らされている人もいますが、DNS サーバをホスティングするわけではなく、Google の超パワーで高速なキャッシングを提供する話っぽので、レンタルサーバ業者に与える影響は限定的だと思います。)

では、MS が独禁法で訴えられたのと同じように、Google が訴えられるかというと、それは違うのではないかと思います。
例えば、Chrome ブラウザや Google DNS を通さないと使えないサービスがあったり、Google のサービス同士じゃないと連携しない制限をかけたり、といった事を Google がやっていないからです。

MS に例えて言うなれば、Google は最初から、IE や Media Player を他のアプリに置換可能な状態でリリースしていると言えます。
しかも有料 OS に無料ソフトを添付したりではなく、最初から全てが無料なので、独禁法に定められた、不当な/不公正な「取引」 に当たるのかさえ、微妙に感じます。

もし Google を日本の法律の枠組みで訴えるとしたら、それは独禁法ではなく、不正競争防止法では無いでしょうか？

ただ難しいのは、例えば ATOK を擁するジャストシステムが不当に安価な製品を提供して市場を破壊した、と Google を訴えたとしても、Google IME 自体に直接広告がなければ、「これは商用製品ではありません。当社の社会奉仕活動です。当社に利益をもたらすものではありません。」と言えてしまうところです。
これは、直接的に広告を表示させていない全ての無料サービスについて、同様の理屈が成り立ちます。

もちろん、Google に全く利益をもたらさないかというとそれは違います。
ユーザ体験の向上によってブランディングの効果があったり、検索量が増える事で、結果的に広告収入が増えるという事は十分考えられます。

Google DNS や Chrome ブラウザ等、Google がスピードにこだわるのも、当然表向きはユーザ体験の向上が目的、と言いますが、実態はそれだけではありません。
ユーザが高速な Web を体験できるようになることは、実は Google の収益に直結しています。

Google：0.5秒遅くなると、検索数が20%減少する
Amazon：0.1秒遅くなると、売り上げが1%減少する
Aberdeen Groupというリサーチ会社が出したレポートによると、一般的に表示スピードが1秒遅くなると、PVは11%、CVは7%、顧客満足度は16%ダウンする
–
High Performance Web Design ~デザインから考えるハイパフォーマンスWebサイト~ | warikiru

しかし、こういった因果関係を法廷で証明するのは難しいのではないでしょうか？
仮に、因果関係が認められ、Google 敗訴となった場合だって、「Google IME の権利を放棄します。サジェストの API を公開して、IME はオープンソースに寄贈します。」と言ってしまえば、それっきりになってしまいます。

「最初に作った名誉」という形のブランディング効果は残り、Google 自体は訴訟から完全に解放されつつも、ユーザが増え続ければ、Google は自身の目的を達する事が出来ます。
これは怖いです。こうなったらどうやっても止められません。

実はすでに、Android がこの状態です。そう遠くない将来、Symbian OS や Palm OS、Windows Mobile などは駆逐されていってしまうのではないでしょうか？

この傾向が進んだ未来はどんな世界でしょうか？
影から世界を牛耳る Google 帝国が完成するのか、あるいは世界共和国とでも呼ぶべき、民主的な世界になるのか、全ては Google の社訓 “Don’t be evil” がどれほど守られるかにかかってる気がしてなりません。
そして、それを担保するのは、Google サービスを利用する我々にかかっていると思うのです。

Google のサービスはほとんどが無料ですし、便利で有用なものが多いですが、Google のサービスを利用する時は「その情報は全て Google が握っているのだ」という事実と、「evil に堕ちた時はいつでも糾弾するのだ」という監視の目を忘れずにいたいですね。

あるいは、もう、すでに…。

TwitterAPI.js の Ver 0.9.3 をリリースしました。

バージョンとしてはマイナーバージョンアップとしていますが、全面的に書き直して、大幅な機能追加を行っています。

JavaScript だけで Shift_JIS/EUC-JP のページから UTF-8 に変換して POST する方法 や、JavaScript だけでクロスドメインで POST メソッドを送る方法 の POST 完了時にコールバック関数を呼び出す技の成果などを取り込んだり、従来不可能と思っていた BASIC 認証における再ログインを実装したりと、意欲的なバージョンアップです。

全面的なリファクタリングに際して記述を洗練させたため、機能が増えても、容量や実行速度は減っています。
最初、Ver 1.0.0 を付けて華々しく…と思ったものの、全面書き換えでバグがあったりすると切ないので、やめました。「バグフィックス版の Ver 1.0.2 がスタンダードになる」みたいのって、格好悪いじゃないですか。

それと、本家の Twitter API も以前と比べ色々と追加されていたので、それらにも追随しました。report_spam とか、search とか出来るようになったので使い道も増えたんじゃないでしょうか？
近々、リスト系の API が追加されれば、それも取り込んでいきたいと思います。

さしあたって、スパム報告機能については、TwitMgr と相性が良さそうなので、そこで使っていきたいですね。

今日 (2009-10-28) の朝、とほほの WWW 入門 で有名なとほほ(杜甫々)さんが亡くなったのでは？というニュースが Twitter を駆けめぐりました。
発端になったのはこの投稿です。

この投稿にはてブが付き始めたり、「とほほ」がばずり始めたりすると、訃報が一気に広まったのです。
また個人のブログで、広島在住、Perl 使いという特徴から「とほほ(杜甫々)さん＝平志朗氏」説を述べているページが以前からあった事も、ニュースを補強します。

とほほの WWW 入門にお世話になった世代と、日本で Twitter を使っている世代が重なった事もあって、Twitter 上のあちこちで訃報を悲しむ声が上がりました。

そんな中、冷静にとほほ（杜甫々）さんと同一人物とはまったく思えないといった指摘があがります。

ここで指摘されているサイトはどうやら亡くなった平志朗氏のサイトなのですが、確かに「とほほの WWW 入門」からは想像出来ないサイトの作りです。

しかもソースを見る限り、ホームページビルダーで少なくとも 2004 年以降に作成されています。
このあたりから、徐々に、とほほ(杜甫々)さんと平志朗氏は別人ではないかという見方が広がり始めます。

ただ、Twitter の特徴として各人の TL で情報伝播速度に違いがあるため、この段階では真偽入り乱れる非常に混乱した状態になってきていました。
訃報に悲しみ続けている人、さらなるソースを求めて真偽を見定めようとする人、結論を保留して様子見を決める人もいます。

そしてついに、ソースが発見(追記：初出はこちらとの事です)されます。

平志朗氏のサイトで、平志朗氏自身がとほほ(杜甫々)さんとは別人であると書き込む内容です。

すると、TL の内容も徐々に誤報を伝えるコメントが増え、訃報が広まったのと同じ速度で誤報であるという情報も広まっていきました。
今回の騒動を機に、とほほ(杜甫々)さんの影響の大きさを感じた人も多かったようです。

こうして今回の騒動は収束し始めていったのですが、この間、時間にしたらおよそ 1 時間程度でしょうか？
Twitter 検索でずっと情報を追っていたのですが、あまりのスピードに驚きました。

次の Web のトレンドはリアルタイムだと言われて久しいですが、今回まさにそれを体験した思いです。
こういった事象をもっと早い段階で何度も見せられた米国のネット関係者は、Twitter のすごさをもっと早くに理解していたんですね。
Google や MS が自前の開発ではなく、Twitter との提携に踏み切った理由もよく分かります。

これからの Web はますます面白くなりそうです。

また、今回の騒動はとほほ(杜甫々)さん≠平志朗氏で決着が付きましたが、それでも誰かが亡くなった事実には変わりません。ご冥福をお祈りします。

追記(2009-10-29)

その後、とほほ(杜甫々)さんご本人より、平志朗氏の訃報を悼むコメントが とほほの WWW 入門に掲載されました。

Twitter 上の自分のつぶやきを元にブログをポスト。

詳細に関しては、他のニュースサイトで大きく取り上げられていますが、アキバの事件の時にあったような実況がいまイランでも行われています。
どうやら携帯電話の動画撮影機能で取った動画が、ネットにアップされているようです。ネットワークに繋がったカメラを一般市民が持つというのは、こういう事なのですね。

そしてその情報伝達のスピードも、既存メディアではあり得ない速度で世界中を巡っていきます。
イランでポストされた Twitter のつぶやきが、世界を巡って自分の元に届くまで果たして何分かかるのでしょう？いや、分のオーダーですらなく、数十秒の内に到達する事もあるでしょう。

しかし、そのスピードは信頼性を犠牲にした上でのスピードである事は忘れないようにしたいです。
1次情報が何の裏付けもないまま自分の元に届くという事には、メリットとデメリットの両面がある事は間違いありません。
情報伝達の速度が上がればあがるほど、情報の信頼性が落ちていくというのは肝に銘じておきたいですね。

悪意を持った嘘を流すのが今ほど簡単な時代も、人類の過去の歴史には無かったのですから。

「Twitterの最新のバグ: "ダイレクトメッセージの誤配達"」という記事があって、Twitter のダイレクトメッセージ (DM) に超重要な情報を流すような人は、セキュリティ意識が足りてないよね～、なんて事を思っていた矢先、自分のアカウントにどうも「誤フォロー」では無いかと思われるお知らせメールが届きました。

フォローしてきたのは外人さんなんですが、TL みても普通の人だし、フレンズ数も普通。その後何度か見てもフレンズがばんばん増えているわけでもなく、ボットやスパムのたぐいではなさそう。
じゃあ、本当に興味を持ってフォローしてくれたのかというと、そんな要素は欠片も感じません。

唯一特徴的な点があるとすれば、たかだか 1 時間前の発言がその人の最初の発言で、「twitter twitter twitter! I finally joined :d」となっている事でした。どうも、すごい最近 Twitter を始めた人のようです。
そこで、このフォローが誤フォローだったとすると、DM の誤配信と同じ原因ではないかと気づきました。その原因を推測してみます。

Twitter のアカウントを特定する ID として公開されているものに数字の ID と文字列の ID があります。
文字列の ID も全体で唯一のものなので、API の呼び出し時に指定したりもできるのですが、元々本来のプライマリーキーは数字の方であると思われます。
そしてその数字が 32bit で管理されていた場合に、その数値を使い切ってしまったのでは無いでしょうか？*1

Twitter の利用者数はまだまだ 1 億にも届かないですし、32bit あれば約 43 億まで扱えるので不思議に思うかも知れませんが、実際に利用されているアカウントだけではなく、ボットやスパマによって日々作られ、消されているアカウントがそれこそ膨大な数存在するはずです。

プライマリキーを使い切ってしまうと何が起こるかというと、またゼロに戻ってカウントし直しとかになり、プライマリーキーの重複が発生してしまいます。
根本的にはこれが DM 誤配送や、誤フォローの原因になったのではないかと思われます。

もちろん、Twtiter 側もただ手をこまねいていたわけではないでしょうから、DB やカラムを追加するなり、文字列 ID を活用するなりして、対処したのだと思いますが、修正に漏れがあってプライマリーキーだけで判断する古い処理が残ってしまい、それが原因になったというわけです。

さらに言うのであれば、プログラミング的なミスではないと思います。
さすがにそれは相当頑張ってテストをしてからリリースしているはずなので、むしろ本番サーバへのリリース時にミスがあったのではないでしょうか？

Twitter を運用しているサーバが全部で何台あるのかは知りませんが、相当な台数のサーバで平行してプログラムが稼働していると思われます。
前述の修正プログラムを適用する時に、適用が漏れてしまったサーバ、適用に失敗した事に気づいていなかったサーバが存在したとすると、”一部に” 誤配送があった事にも説明がつくのです。

最初の誤フォローの話に戻ってみると、そのアカウントはかなり新しいものでした。
すなわち上記の推測が正しいとすると、最近友達何人かで Twitter を始める事になってお互いをフォローしあったんだけれども、最近の新しいアカウントはプライマリーキーが一周した後のアカウントだったため、同一のプライマリーキーを持った別アカウントをフォローしてしまった、というストーリーが考えられるわけです。

本当の原因は全然違うかも知れませんが、Twitter 側が「問題の原因は“弊社のサービスにおける基本的データの不整合性”にある」と言っている事からも、上記の推測もあながち外れていないように思うのです。

もし上記の推測が当たっていて、誤フォローが本当に発生したとすると、Twitter の発表とは裏腹に、まだ不具合が残っているかも知れません。
そもそも、公開を前提とした Twitter と、例えば Gmail のような非公開を前提としたサービスでは、設計思想からして異なっていて当然です。
今回の件に限らず、Twitter の DM が漏れる可能性は常にあると考えるべきです。
Twitter の DM 機能はあくまでオマケ機能として捉え、本当に重要な情報を Twitter でやり取りするのは控えた方が良いですね。

*1
実際の数値を見るとまだせいぜい 3000 万台がいいところなので、全然関係ないように見えるかも知れません。ですが、真のプライマリーキーは表に見せないのが普通なので、表に見ている数字の ID 自体、真のプライマリーキーから、アカウント作成時にエラーで弾かれたレコードを除いた総数なのだろうと考えています。
その場合であっても、真のプライマリキー自体はエラーで弾かれるたびに 1 つずつインクリメントされると思われるので、同様の論法が成り立ちます。