Life is beautiful

昨日から今日にかけて（米国時間８月１９日〜２０日）、皆既日食を観るためにオレゴンまでドライブして来たので、時系列で書いて「週刊 Life is beautiful」の特別号として配信することにしました。

一ヶ月前

かなり前から、「せっかくの機会なので是非とも行かねば」とは思っていたのですが、具体的な計画を立て始めたのは、１ヶ月前ほどです。Tesla の自動運転をたっぷりと試すにも絶好の機会です。

シアトルからだと、車で４時間ほどのところなので、日帰りも可能かも知れませんが、かなりの渋滞が予想されるので、朝の１０時までに現地に着くためには、夜中に出発しなければいけません。そこで、前日に一泊だけポートランドに泊まることにしました。

幸いなことにホテルの部屋はその時点では少しは空いており、予約は出来ましたが、料金は通常の倍の５００ドル超です。AirBnB も一応調べましたが、予約率は９７％で、泊まりたい様なところは空いていませんでした。

同時に、アマゾンで日食を観るためのメガネを購入しました。色々な商品が並んでいましたが、「ISO Certified」と書いてある商品ならば安心だろうと注文しました。紙で出来たメガネなので１０個で $12.99 という安価な商品です。

一週間前

ところが、一週間前になって、アマゾンからこんなメールが送られて来ました。

We're writing to provide you with important safety information about the eclipse products you purchased on Amazon (order #112-6468158-7825003 for Solar Eclipse Glasses CE & ISO Certified - Safe Solar Viewing - Eclipse Glasses 2017 (10pack)).

To protect your eyes when viewing the sun or an eclipse, NASA and the American Astronomical Society (AAS) advise you to use solar eclipse glasses or other solar filters from recommended manufacturers. Viewing the sun or an eclipse using any other glasses or filters could result in loss of vision or permanent blindness.

Amazon has not received confirmation from the supplier of your order that they sourced the item from a recommended manufacturer. We recommend that you DO NOT use this product to view the sun or the eclipse.

Amazon is applying a balance for the purchase price to Your Account (please allow 7-10 days for this to appear on Your Account). There is no need for you to return the product. You can view your available balance and activity here... 

その商品は、安全ではないので使わない様に、というのです（料金は払い戻し、返品の必要はなし）。アマゾンによると、安全のためにはメガネメーカーに NASA の認証を受ける様にリクエストしたのですが、この製造元は、それに返事をしなかったとのことです。

アマゾンとしては万が一のことを考えて、最大限のことをしたのでしょうが、大した売上のない中小の業者にとっては、認証を取ることはかなりの負担になると思います。

私が購入した（リコールされた）メガネも、それで（日食ではない）太陽を観ても問題なさそうです。小学校の頃は、下敷きで日食を観ていたことを考えれば、十分に安全に思えます。試しに、そのメガネで太陽を観てみると、ちょうど下敷きごしで観た様な感じで、危険とは思えません。ISO の認証番号もちゃんと書いてあります（ただし、この認証番号は特定の商品に着くものではなく、安全基準を表すものなので、勝手に名乗ることは違法ですが可能です）。

その頃になると、地元のメディアも盛んに日食に関して報道をし始め、日食は肉眼で観ない様にと注意をしたり（当然、アマゾンによるリコールの話題もありました）、皆既日食を観るためには、オレゴン州までドライブする必要があることなどを指摘しています。

大勢の人が行くと道路が渋滞するので（基本的に I-5 という高速が一本あるだけです）、あまり報道しては欲しくなかったのですが、そこからは毎日の様に報道が繰り返されました。

その頃になって少し気がかりになって来たのは、Tesla の充電です。シアトルからポートランドまでは約２００マイルなので、途中で充電なしでたどり着くことは可能ですが（私の Model X は満タンで 230マイル）、Portland 市内には（Tesla が提供する）スーパーチャージャーはないので、やはり途中の Centralia で充電することが必要です。さらに、Portland から皆既日食が観られる Salem への行程で再度充電することが可能ですが、１００万人もの人が日食のために集まると言われている Salem のすぐ近くの Super Charger で簡単に充電できるとは考えない方が良さそうです。

一度は Tesla でない方の車で行くことも考えたのですが、この長距離ドライブは Tesla の Autopilot 機能のメリットを試すには最高の機会です、多少のリクスを負ってでも Tesla で行こうと思いました。

前々日（８月１９日）

前日になり、妻が「私は行きたくない」と言いだしました。報道によると、普段２万人しかいない Salem に１００万人近くの人が集まるらしく、渋滞だけでなく、駐車場、レストラン、公衆トイレなどが足りなくなるだろうと言い始めたからです。

なんとしてでも行きたい私は、水と食料だけは十分に詰め込み、最悪の場合に使う様にと（米国では手に入らない）「携帯トイレ」代わりにオシメを買い込んだのですが、それがトドメを刺した様です。

少し残念でしたが、色々と問題があった時に私一人の方が対処しやすいこともあり、一人で行くことにしました。

充電に関しては、相変わらず気がかりでしたが、予約したホテルに電話してみると、ラッキーなことに Tesla 専用のチャージャーが一台だけあり、車の鍵を預けてくれれば充電はしておくと言ってくれました。「チャージャー一台で足りるのか？他のゲストが Tesla に乗って来たらどうするのか？」という疑問符が頭に浮かびましたが、とりあえずホテルでの充電がうまく行く前提で計画を立て直しました。

往路では、シアトルから９０マイル強のところにある Centralia で充電し、そこからPortland では（同じく９０マイル強）のホテルに移動します。夜中にホテルで充電してもらい、そこから Salem （５０マイル強）までの間に、もう一つスーパーチャージャー（Woodburn というう場所）がありますが、そこには立ち寄らずに一気に下って日食を観ます。

しかしそうすると、帰りに Woodburn に立ち寄らなければ、Centralia まで行けないので、Salem で一般の充電施設で充電する必要があります。スーパーチャージャーではないので、時間はかかるし有料ですが、朝早く起きて行けば、なんとかなりそうです。

Blink という充電ネットワークの専用アプリをダウンロードしてみると、Salem の Walmart に充電器が二つあるので、そこに止めて充電しながら 日食を見ることにしました。

ちなみに、一人で長時間運転するとなれば、なんらかの退屈しのぎが必要です。そこで、あまり褒められた話ではありませんが、いくつか映像を用意して行くことにしました。ダウンロードを可能にした Amazon に対抗して、最近は Netflix アプリでも映像を前もってダウンロードしておくことが可能なので、それを活用することにし、映画を数本とアニメのシリーズを二つほどダウンロードしておきました。

前日（８月２０日）

Portland までは、通常であれば３時間ぐらいで行けますが、渋滞が予想されるので少し早めに出ることにしました。Autopilot を使うとは言え、途中で眠くなっては行けないので、早めのお昼を食べ、１８分の昼寝をしてから出発しました。ちょうど午後の１時でした。

最初の目的地を、Centralia のスーパーチャージャーのステーションに設定して出発しました。到着予測時刻は午後の３時ちょうどでした。制限速度は時速７０マイルの高速道路なので、それを少しオーバーするぐらいのスピードで運転できれば、２時半には着くはずですが、やはり渋滞が始まっているのでしょう。

最初の２０分ほどは、真面目に運転していましたが、I-5 に入ったところからは、単調な道が続くので、運転は Autopilot に任せて、映像を楽しむことにしました。

こんなことを書くと、「違法だ」「危険だ」「悪い見本だ」という批判が来るだろうことは十分承知ですが、Tesla の Autopilot に関しては、毎日の様にテストを繰り返しているので、どんな環境で任せられるのか／任せられなくなるのかは十分に把握しているつもりです（いわゆる「テレビを観ている良い子は真似しないでね！」です）。

ちなみに、ワシントン州では、運転中に映像を観ることは（明示的には）禁止されていませんが（厳密に言えば「注意義務」違反とも言えますが）、携帯電話を操作することは法律で禁止されています。

最初は、途中まで観ていた Netflix オリジナルの Okja の続きを観ようとダウンロードして置いたのですが、韓国映画なので、字幕を読む必要があり、これは無理なことに気がつきました。そこで、同じくダウンロードしておいた、「ソードアートオンラインII」を観ることにしました。

「ソードアート・オンライン」のことは、（Facebook が買収した VR ゴーグルを開発・販売している）Oculas のファウンダーの Palmer Luckey のインタビューで知り（大ファンだそうです）、シリーズ I とシリーズ II の前半のみ観ていたので、その残りをダウンロードしておいたのです。

ちなみに、iPhone は、クラスターメーターの上に置きました（下図）。この位置であれば、目線を道路からほどんど離す必要もないからです。

唯一の問題は、熱がこもって iPhone が熱くなってしまうことでしたが（あまり熱くなると、動かなくなります）、時々クーラーの吹き出し口に挟んで冷やしてあげることにより解決しました。

Centralia までの運転は、とても順調でした。ところどころ渋滞もありましたが、カーナビの予想通り３時ちょうどに着きました。Autopilot にしていると、時々遅い車の後ろに引っかかってしまうので、何度かは手動に切り替えて追い抜きをしましたが、基本は Autopilit に任せきりでソードアート・オンラインを楽しみました。

Centralia の充電ステーションに到着してみると、全てのチャージャーが使われています。幸い、待っている車は見当たりません。スーパーチャージャーを使うのは初めてなので、どんな流儀で待つべきかが分からなかったので、単に向かい側に駐車して待っていました。

すると、すぐにもう一台の Tesla がやって来ました。家族連れの乗る Model X です。「お前は待っているのか？」と聞かれたので、「そうだ」と答え、これから「これから日食を観に行くんだ」「私もだ」「どこから来たんだ？」などと他愛のない話をして待ちます。そうこうする内に、さらに二台がやって来たため、「あなたは三番目」「あなたは四番目」などとリーダーシップを発揮せざるを得ませんでした。本来ならちゃんと並ぶべきだったのかも知れませんが、私が真ん中に陣取ってしまったため、後の祭りです。

１０分ほど待つと、ようやく一台が空いたので、すかさずバックで入れて充電を始めます。専用のアプリで調べると満タンまで１時間２０分と出ているので、近くのマクドナルドで時間を潰すことにしました（この特別号の前半は、そこで書きました）。

小一時間ほど経つと、スマフォに「充電が終わりました」という連絡が入ります。その時は知らなかったのですが、スーパーチャージャーの充電器は、二台ごとにペアになっており、最初に接続した方により多くの電流を流すように設計してあるそうです。そのため、（隣で先に充電していた車が入れ替わることにより）当初の予想よりも実際には短くなるケースが多いそうです。

空いている時により高速に充電するための工夫だそうですが、結果的に「良いおもてなし」をすることになっています。

充電が終わって、今度は Portland のホテルを行き先に指定してドライブの開始です。到着予定時刻は午後の６時でしたが、これもほぼ予定通りに着きました。Tesla は Google Map をカーナビに使用していますが、渋滞予測に関しては、Google のカーナビよりも優秀なように感じます。ひょっとすると、渋滞予測のみは、他の Tesla の走行状況から計算しているのかも知れません。

Portland のホテルに着くと、ベルボーイ（駐車場の担当者）に車と鍵を預け、充電しておくように頼みます。充電器が一つしかないことは知っていたので、ちゃんと充電してもらえるかどうかが心配で、部屋に行ってすぐにアプリで確認すると、すでに充電が始まっていました。

ただし、充電のスピードは、スーパーチャージャーとは大きく違い、満タンになるまで４時間１５分かかります。これでは、４人の客が Tesla で乗り付けたら一晩でフル充電することは不可能になってしまいます。全部で３００室ぐらいのホテルなので、Model 3 が普及するまでには充電施設を増やす必要があります。

いずれにせよ、予定通りホテルで充電が出来たのは幸いでした。これであれば、Salem までは充電なしで問題なく行けるので、自由度が大きく増しました。

夕食は、ホテルの近所の日本食屋で軽く済ませ、明日に備えて早く寝ます。フロントに電話をして、朝食のルームサービスを６時に頼んでおきました。さらに、ベッドに入る前に、充電が順調に進んでいること確認して、安心して眠りに着きます。目覚ましは６時５分前にセットしておきました。

当日（８月２１日）

先日、早く寝すぎたのか、興奮しているのか、朝の３時に目が覚めてしまいました。パソコンで時間を潰していたところ眠くなったので、再びベッドに入って眠りました。

すると、目覚ましが鳴る少し前に、電話の音で叩き起こされました。何だろうと思い、受話器を取ると、フロントからで、「キッチンでトラブルがあったので、朝食を持ってこれるのが６時半になる」と言います。

困ったなとは思いましが、朝食抜きでは出かけたくなかったので、シャワーを浴びたり、荷物をまとめたりして朝ごはんを待ちます。Google Map で調べると、すでに渋滞は始まっています。

実際には６時２０分には朝食が来たので、手取り早く食べて、６時４０分には部屋を出ます。それも５分前にはフロントに電話をして、車をフロントドアの前にまで前もってもって来てもらうという念の入れようです（普段は、チェックアウトしてから頼むので、５分ほどロスします）。

チェックアウト後、すぐに出発し、高速に乗ったのは良いのですが、Autopilot がオンになりません。どうしたものかと色々と操作していると、原因が分かりました。ホテルで車を預ける時に「Valet モード」にしておいたのです。「Valet モード」にすると、プライバシー上問題になる「自宅に戻る」や「電話帳」などの機能がオフになるのですが、Autopilot までもがオフになるとは知りませんでした。

運転しながら、何とか「Valet モード」をオフにしようと試みるのですが、うまく行きません。一度車を止める必要があるようです。

仕方がないので、一旦高速道路から降り、車を止めて「Valet モード」をオフにします。時間は若干ロスしますが、Autopilot 機能なしで長距離運転は出来ません。

すぐに高速に戻り、（Portland 市内の迂回路である I-405 から）I-5 に乗り換えると、再びAutopilot に運転を任せて「ソードアートオンラインII」の視聴をします。

ちなみに、ソードアートオンラインは、ライトノベルがベースですが、とても良く出来ています。オンラインゲームをしたことがない人には理解しにくいとは思いますが、オンラインゲームでの人間関係が、リアルの人間関係と同じぐらいに人の感情を動かす、ということが、とても丁寧に描かれている逸品です。

２時間ほど運転すると、Salem の手前の Woodburn という町のスーパーチャージャーがカーナビに表示されました。昨日立てた予定では、そこで充電する必要はなかったのですが、高速の出口のすぐ近くなので、試しによってみるのも悪くないと思いました。チャージャーが空いていなければ、すぐに高速に戻れば良いだけの話です。

高速から降りると、ちょうど別の Tesla が目の前を走っています。「この人もスーパーチャージャーに行くのだろうな。どうせ混雑しているだろうな」と思いつつ後をついて行くと、最後の最後で、その Tesla は別の駐車場に入ってしまいます。

「あれ、間違ったのかな？」と思いつつ、カーナビの指示通りにスーパーチャージャーに向かうと、何と一台だけステーションが空いています。「ラッキー」と思いつつ、バックで駐車していると、さっき別の駐車場に入った Tesla がそこにやって来ました。やはり、間違った駐車場に入ってしまったのです。

少し申し訳ない気持ちもありましたが、だからと言って譲る理由もないので、充電を始めます。

満タンまで５０分、その時はまだ８時を少し回っただけだったので、十分に時間はあります。ここで満タンにすれば、Salem まで行って日食を観て、折り返しで一気に Centralia まで戻れます。

時間を潰そうと近所のレストランを観ると、すぐ近くにあるレストラン二つのうち、一つはしまっており、もう一つは超満員で人が溢れています。仕方がないので、しばらく歩いたところにあるスターバックスに行くと、そこも人が溢れています。さらにすごいことに、トイレにも十五人ほどが並んでいます。

「この人たちも全員 Salem に行くつもりなのか！」と驚いて周りを見渡すと、少し様子が違います。駐車場は満杯だし、駐車場の横にある建設予定地には、ピクニックシートの上に座った家族づれや、高級そうなカメラを設置している人なのがたくさんいます。

私が、折りたたみの椅子に座っている老夫婦に、ここでも皆既日食が観えるの？と尋ねると、「そうよ、ここでも１分半ぐらいは観れるのよ。Salem まで行けば２分だけど、人の数がすごいから、ここにしたの」と言います（ちなみに、その夫婦はカルフォルニアから飛行機で来たそうです）。

それを聞いて「それであれば、ここで観るのも悪くない」と気がつきました。と言うのも、Salem まで行くと、帰りの渋滞がすごいことになりそうな予感がしていたからです。１００万人もの人が集まっていれば、高速の入り口どころか駐車場の出口からすごい渋滞になることは目に見えているし、そこで時間を少しでもロスをすれば、I-5 の渋滞が悲惨になることは明らかだからです。

目的は「皆既日食を観ること」なので、それが２分から１分半になったことで、大した違いはありません。それよりも、渋滞のために家に戻る時間が１時間、２時間遅くなる方がずっと苦痛です。

そこで少し気が楽になったので、そこから近所の公園を散歩したりして時間を潰しました。９時に充電状況を確認すると、すでに９７％を超えています。これだけあれば十分なので、車まで戻ると、４台も並んで待っています。Centralia とは違い、秩序正しく列になって待っているので、やはり私の待ち方が間違っていたのだと少し反省しました。

充電ステーションから車を移動させて困ったのは、駐車するところが皆無だったことです。仕方がないので、先の散歩で見つけた、近所の住宅地に駐車させてもらうことにしました。米国の住宅地の道路は、ほとんどが地元の住人のために駐車可能になっているので、こんな時には便利です。

そこから先のスターバックスの隣の建設予定地まで戻りましたが、そこで悩んだのがトイレです。１０時１７分に始まる１分半の皆既日食が終わったら、すぐに出発し、休憩なしで Centralia まで３時間近く、走る必要があるので、日食の前にトイレに行っておく必要はありますが、なるたけギリギリの時間に行きたかったのです。

とはいえ、スタバのトイレの列は結構長いので、タイミングが大切です。そこであえてすぐには列に並ばず、ちょうど自分の番が１０時少し前になるようなタイミングを狙って列に並ぶという手間をかけました。

首尾よく１０時前にトイレを済ませ、建設予定地に戻り、用意しておいたタオルを敷いて準備をします。すでに日食は始まっており、（自称 ISO 認証済みの）日食サングラスを通して観た太陽は三日月型です。

それを iPhone で撮影しようとしても無理だったので、ホテルから持って来た紙に穴を開けた即席の「日食ビューアー」で撮影した日食が下の写真です。

ちなみに、私がこれを撮影していると、「何をしているの」と近くにいた子供が尋ねて来たので、理屈を教えた上で、穴の空いた紙をあげるととても喜んでいたので、ついでにいくつか作って、他の子供達にも配ったりして時間を過ごしました。

「少し暗くなって来たかな」と感じたのは１０時１０分ぐらいです。しかし、その時点でも、まだ太陽を直視することは不可能です。

そこからは、今までに経験したことのない勢いで、空が暗くなって行きました。１０時１５分ぐらいに、近くに座っていた子供が「星だ！」と叫びました。見上げると、確かに星が一つ、輝いています。明るさからも位置からも、多分金星だと思います。

心持ち、風も冷たくなって来ます。暗さのため、駐車場の街灯が一斉につきます。

それから、おもむろに皆既日食が始まりました。突如、それまで輝いていた太陽が、肉眼ではっきりと輪っかが見えるようになるので、すぐに分かります。周りからは、歓喜の声とため息が聞こえます。一気に暗くなるため、妙に心がざわつきます。夕暮れの寂しさが、一気に押し寄せて来たような感覚です。

その１分半は、私にはとても長く感じられました。皆既日食の感覚は実際に体験しないと分からないと言いますが、まさにその通りです。昔の人たちが、不吉な予感や神の力を感じたのも当然だと思います。

皆既日食の終わりには、輪っかの一点が輝くダイアモンドリングが一瞬見えます。しかし、それもすぐに眩しすぎる光に代わり、肉眼で観ることが不可能になります。

そこからすぐに撤退の開始です。一人身だし、荷物も少ないので、とても用意です。そこから隣の住宅地まで走り、すぐに車をスタートさせ、高速道路に向かいます。

他の車はまだ動き出していないので、渋滞は始まっていません。そこかしばらくは、Autopilot は使わず、制限速度を７〜８マイルほどオーバーさせながら帰路を急ぎます。途中、二度ほどスピード違反で捕まっている車を見かけてドキッとしますが、この程度ならば大丈夫なのが米国です。

そこから一気に Centralia まで走り、充電しなが昼食を食べ（充電ステーションは半分以上空いていました）、帰路を急ぎます。一度だけコーヒーを飲むために高速を降りましたが、結局、家についたのは午後３時。ほとんど渋滞もなく、とても快適な帰路でした。

エンジニアtypeに「Facebook HOMEが引き起こすのは、待ち受け争奪戦ではなく次世代の『メッセージングツール戦争』だ」という記事を掲載した。私なりに Facebook Home の意味を解説してみた。

Facebook Home を最初に見たときは、「単に待ち受け画面を取りにきただけか」と思ったが、iPhone 向けの Facebook アプリにも ChatHead を搭載し、そこから４G経由で VoiP 電話が無料でかけられることを知った時、２年以上前に Zackerberg が宣言してたことを思い出した。

"Facebook はメールや電話に代わるコミュニケーション・プラットフォームになる"

Facebook Home の本当の狙いはここにある。ChatHead で通信事業者が提供する音声通話やメッセージングなどのサービスを置き換え、人と人がコミュニケーションする際になくてはならないサービスになること、これが Facebook の狙いだ。

この動きに一番の危機感を持つべきは、ひょっとしたら Google ではなくて、NTT ドコモなどの通信事業者なのかも知れない。ChatHead ですべてのコミュニケーションが成り立つのであれば、データ通信以外のサービスは一切不要になり、文字通り「ただの土管」になってしまうからだ。

私が漠然と感じていたことを上手に表現してくれているブログエントリーを見つけたので紹介する。

There Will Be No Files In The Cloud

すべてが本当の意味でクラウドに移動した時には、ファイルという観念が不要になるのでは、という話。Dropboxの提供しているような「クラウド型ストレージサービス」というのはデスクトップからクラウドへシフトする段階での過渡的なものでしかなく、行き着く先はGoogle Docsのようの形だ、というのが筆者の主張。

デスクトップ・アプリというものがあるからこそ、ファイルという概念が必要であり、アプリケーションすらクラウド上のウェブアプリケーションになれば、ドキュメントの共有はリンクを渡すだけで良いのでファイルは不要だという話。

確かに、この「ブログ・エントリー」も実体は「ファイル」ではなく、データベース上のレコードでしかないわけで、それよりもユーザーから見て一つの「エントリー」であることだけに意味がある。時代は明らかにそんな方向に進んでいる。

今朝、私の目を引いたのは、「iPad Sales May Lead to Huge Missteps by Competitors」という記事。AppleのiPadが飛ぶ様に売れている事に目を付け、Samsung、Motorola、Research In Motionなどが続々とタブレット市場に進出しているが、ユーザーが欲しているのは単なるタブレットではなくてiPadであり、需要がないところに無理矢理商品を押し込んだところで在庫が増えるだけだ、という警告。

確かに考えてみると、私の回りにiPadを持っている人はたくさんいるが、iPad以外のタブレットを持っている人は見た事がない（唯一の例外はUIEジャパンが開発用に購入したGalaxy Tab）。

パソコンやテレビの場合、消費者はまず最初に「そろそろパソコン／テレビを買おう／買い替えよう」と思い、次に「パソコン／テレビならどのメーカーのものを買おうか」と考える。iPhoneが強いスマートフォン市場でも、やはり「スマートフォンが欲しいけど、どれが良いんだろう」と考える人は多いと思う。

しかし、タブレット市場に関して言えば、最初に「そろそろタブレットを買おう」と思う人は皆無に近く、いきなり「そろそろiPadを買おう」となってしまっているのだ。実際、先日も知り合いの弁護士が「私の仕事仲間はみんなiPadを持っていてね、私もそろそろ買おうかと思うんだ」と言っていたがこれが良い例だ。

そういう意味では、現時点では「汎用タブレット市場」というものは存在しないに等しく、単に「iPad市場」があるだけだ。以前、ここでも「Androidタブレットはヨドバシカメラの『Androidタブレットコーナー』に横並びにされた時点で負けだ」と書いたが、そもそも汎用デバイスとしての「タブレット」の需要がないのでは勝負にならない。

ちなみに、以前、日本の某メーカーにタブレット戦略の相談をされたことがあったのだが、その時には「ヨドバシカメラに並ぶようなものを作ってもアップルには勝てないし、まず利益は出ないと思います。どうしても出したいというのであれば、いっそのこと、東急ハンズで文具として売ってもらえるように文具メーカーと共同開発するとか、医者と看護婦が日常の医療現場で使う医療システムのアクセス端末として一括で導入するとか、特定の市場・用途に特化したものを作るのはいかがでしょう？」と答えておいたのだが、そのメーカーからはまだ何も市場には出ていないようだ。

　９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？

　iPhoneをハックして、Appleが認めている以上のカスタマイズを可能にしたり、Apple公認のApp Store以外からのソフトをインストール可能にしたり、することをJailbreak（＝脱獄）と言うのだが、PhotoShareでの会話とかを見ていると、その危険性をちゃんと理解せずにJailbreakしている人たちがたくさんいるようなので、ひとこと警告しておく。

　まず最初に考慮しておくべきことは、iPhoneはNintendo DSやSony PSPと違い、携帯電話でありメールマシンであり、インターネットマシンであり、住所録やらメールやらウェブサイトのパスワードなどの個人情報を思いっきりやりとりする、ある意味パソコン以上にプライバシー管理が大切なマシンであること。当然、ウィルスに感染したり、セキュリティホールからハッカーに情報を盗まれたりしないようにすることがものすごく大切。

　パソコンの場合は、元々がセキュリティホールだらけのオープンすぎるアーキテクチャであるがために、市販のアンチウィルス・ソフトやファイヤーウォールなどをわざわざ入れておく必要があるのは、多くの人の知るところ。

　iPhoneの場合は、「アンチウィルス・ソフトなんかよりずっと効果的な方法」として、開発者の認証コードが付いたApple公認のアプリケーションしかインストールできない、という制限を加えることによりユーザーをその手の危険から守るという方法をAppleが選択している。

　この仕組みおかげで、iPhoneを持つユーザーは、市販のアンチウィルス・ソフトなど面倒なものを導入せずに、安心してさまざまなアプリケーションを楽しめる、という仕掛けになっている。この面に関しては、後手後手のMicrosoftやNokiaよりもずっと高く評価できる。

　Jailbreakをするということは、せっかくAppleが提供してくれているこの「セキュリティの枠組み」を外すことである。そのため、ウィルスに感染してしまう可能性もあれば、予想もしないセキィリティホールから個人情報を盗まれてしまう危険に自分をさらすことになる。もちろん、jailbreakしたiPhone向けのアンチウィルス・ソフトなどを本気で作る会社もない。

　つまり、jailbreakしたiPhoneで電話をかけたり、メールをしたり、パスワード付きのウェブサイトにアクセスすることは、セキュリティホールだらけの少し前のWindowsマシンをアンチウィルス・ソフトなしで走らせるのと同じぐらい、もう少し分かりやすく言えば、新宿歌舞伎町のマンションの１階の部屋で窓を開けっ放しで女性が一人で眠る、ぐらい危険なのである。

　ということで、そんなリスクを理解した上でJailbreakをしている人たちにお願いがある。技術のことに詳しくない人たちから「jailbreakって僕もして大丈夫かなあ？」とたずねられた時に、「アップルからの保証が受けられなくなるけど、それでよかったら」とか「ちゃんと勉強してリスクを理解した上で自己責任でやると良いよ」などと不親切・無責任なことを言わずに、「ウィルスとかに感染するのがいやだったら絶対に辞めた方がいいよ」と言っていただきたい。

　もしあなた自身が、すでにjailbreakしてしまっており、jailbreakのリスクはアップルから保証を受けられなることぐらいなどと大きな誤解をしているとしたら、なんとかしてすぐに元に戻した方が良い。悪意を持ったハッカーにとって、jailbreakされたiPhoneほど簡単に個人情報を盗めるデバイスはないのだから。iPhoneが壊れてもたかだか２〜３万円の被害だが、銀行口座に不正アクセスされたら被害はそんなものでは済まない。

　先日のPhotoShareのスケーラビリティのエントリーに関しては、さまざまなご意見をいただき、とても良い勉強になっている。ただし、少し分かりにくかった部分があると思うのでそこに関して補足しておく。

　サーバーのスケーラビリティに関してはすでに色々なところに書かれているが、今回の私が注目しているのは、どうやってサーバーのキャパシティを増やすか、という話ではなく、サーバーのキャパシティを超えたトラフィックが来てしまった際にどんな挙動をするように設計しておくのが良いか、という話である。

　限られた資源を使って数万人・数十万人の人たちにサービスを提供するかぎり、予想外の急激なトラフィック増加でサーバーに過負荷がかかったりすることはどうしてもあるわけで、そこで問題となるのは、その手の過負荷をどうさばくか。

　たとえば写真に付いたコメントを表示させる場合、「最新の情報をすぐに」表示するのが良いのが当たり前だが、それが過負荷のためにどうしても不可能になった場合に、

・表示するまで１５秒かかる
・表示はすぐにするが、それは１５秒前の状態（投稿されたコメントが反映されるまで１５秒かかる）

のどちらがユーザーから見てストレスが少ないか、どちらの状況になるように設計しておくべきか、という部分が私は重要だと考えている。

　また、通常ピーク時に３秒で処理出来ているところに、通常の倍のトラフィックが来てしまった時に、それを倍の６秒で処理出来るように作ってあるか、倍以上の９秒かかってしまうように設計してあるか、というのが「リニアにスケールするかどうか」という部分である。HTTP Requestに対するレスポンスが遅くなると、それに応じて同時アクセス数が増えてしまい、ペンディング中のスレッドが増えてしまう、そのためにさらにレスポンスタイムが遅くなる、という悪循環は、マルチスレッド型のHTTPを使ったアーキテクチャの根本的な弱点。安易にマルチスレッドに頼ったプログラミングは良くない理由はこの辺りにもある。

　そしてもちろん、もっとも大切なのは、トラフィックがキャパシティを超えて来てしまった時に、サーバーが落ちてしまうのか、単に処理速度がそれに応じて遅くなるだけなのか、という点。

　これらの点を考慮した上で、PhotoShareのようなCGMサービスの場合、「トラフィックがキャパシティを超えて増えてしまうとレスポンスが幾何級数的に遅くなり、しまいにはサーバーが落ちてしまう」という同期型のアーキテクチャではなく、「トラフィックがキャパシティを超えて増えてしまっても、レスポンス時間は常に一定で、単にユーザーの変更がサーバーに反映される時間がリニアに遅くなるだけで、サーバーが落ちることもない」という非同期型のアーキテクチャの方が適しているのではないか、というのが今回の話である。

　ずいぶん前に、「マルチスレッド・プログラミングの落とし穴、その１（かもしれない）」というエントリーを書いたが、今回はPhotoShareサーバーを運営していて、まさにこのあたりの深い考察が必要になって来たので、良い機会なので続編エントリー。

　PhotoShareのバックエンドのようにCRUD（Create/Read/Update/Delete）のAPIをサポートするバックエンドを作る場合、Create/Update/Deleteのリクエストに対してはクライアントからのAPIコール時にすぐに（HTTP Requestに返事をする前に）データベースに変更を加え、Readの際にも（キャッシュを使う・使わないを別にして）データベースの最新の状況を反映するデータを返すように設計するのが普通である。

　このアーキテクチャの問題は、ユーザーのアクティビティが増えた時に、データベースやI/Oがボトルネックとなり、アクセス量に応じてレスポンスタイムが伸びるため、同時に処理しなければならないHTTP Requestの数が増え、さらにレスポンスタイムが遅くなり、結果的にはレスポンスタイムはリニアにでなく、幾何級数的（exponential）に増えていく。そのため、あるしきい値を超えたアクセスが来ると急激にレスポンスが遅くなり、しまいにはサーバーが落ちてしまう。

　アクセス数が増える→HTTP Requestへのレスポンスタイムが遅くなる→同時アクセス数が増える→しまいにはサーバーが落ちる、という悪循環に陥るのだ。

　通常、その場合はキャッシュを導入したり、スレッド・プロセス・CPUを増やしたり、データベースを多重化したり対処するのが普通だが、私はPhotoShareのようなCGMサービスに限って言えば、まず最初に、そもそものアーキテクチャを非同期なものにする必要があると考えている。

　PhotoShareのように、大勢の人が写真やコメントを投稿してコミュニケーションをとるサービスの場合、オンラインバンキングのように「常に最新のデータを見せなければ大問題が起こる」サービスとは根本的に違う性質がある。具体的には、「この写真に付いたコメントを読みたい」というシナリオではすばやいレスポンスが要求されるが、自分が投稿した写真やコメントが他の人のアプリに反映されるまでの時間はそれほど重要ではない。新しい写真やコメントに関するNotificationも、最終的に届きさえすれば良い訳で、秒単位でのリアルタイム性は必要ない。

　そう考えると、私にはCreate/Update/Deleteのリクエストに対して、クライアントを待たせながら（つまり、HTTP Requestの処理に必要なスレッド・プロセスを保持したまま）データベースに変更をかけることが根本的に間違っているように思える。

　そうではなくて、Create/Update/Deleteのリクエストに関しては、そのリクエストをキューにしまい、クライアントにはすぐにレスポンスを返した上で（つまり、HTTP Requestの処理に必要なスレッド・プロセスはすぐに解放して）、別プロセス（それもシングルプロセス）でキューにたまったリクエストを順繰りに非同期で処理すべきだ。

　アクセス数が上がると、ユーザーがした投稿がデータベースに反映されるまでの時間がかかるようになるが、それが直接的におもてなしの低下に繋がることはない（ユーザーから見ると、単にコメントのレスが遅くなったように見える）。

　結果的には、先の悪循環が解消し、アクセス数が増える→ユーザーの投稿が反映されるまでの時間がかかる→ユーザー間のコミュケーションの速度が落ちる→ユーザーによる投稿数が自然に減る、というより自然なスケーラビリティを持った「より落ちにくい」サービスとして提供することが可能になる。

　それに加えて、キャッシュの生成もオンデマンドで行うのではなく、Create/Update/Deleteのリクエストをキューから取り出してデータベースに変更を加えるときに行えば、Readは基本的に静的ファイルを返すだけになるので、データベースへのアクセスを極端に減らすことができて、WriteよりもReadの方が多いというCGMサービスに適した設計となる（MTとかはすでにそんな設計になっている）。

　Twitterがスケーラビリティで苦しんでいるのをみると、同じ過ちは絶対に犯したくないので、ユーザー数の少ない今のうちに、根本的な設計でスケーラビリティを上げて置くべきだとつくづく思う。富豪プログラミングの時代とは言え、このあたりの設計を誤ると、いくらサーバーの台数を増やしたところで追いつかないので。

　このあたりの設計に関しては、私よりももっと多くの経験を積んだ方がいると思うので、ぜひともコメントやトラックバックを通じた議論・ご教授をお願いしたい。

　今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。

　９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。

　一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は別物ということを意識すれば、当然との流れ言えば当然、典型的な「コロンブスの卵（＝誰かがやれば当たり前のことになる）」とも言える（注：IE8はすでにそうしている、という指摘あり）。

　せっかくここまでやるのであれば、同じタブ内でドメインを移動した時にもプロセスを切り替えるべきだと思うんだが、いかがだろうか。クロスドメインのセキュリティを徹底的に強化した先はそこだと思うんだが。

　URLバーをタブの下に持ってくるというのも、ユーザーモデルをUIにキチンと反映させることを考えれば当然と言えば当然。既存のブラウザーがインクリメンタルに進化した結果たどりついたタブ・ブラウザーという形を、ユーザーモデルからキチンと見直した上でURLバーをタブの下に持って来た点は評価できる（注：Operaはすでにそうだ、という指摘あり）。

　Googleがレンダリング・エンジンにWebKitを採用する・独自の高速JavaScriptエンジンを作っているらしい、という話は以前から業界の人々には知られていたので、目新しい話ではないが、コンパチビリティで一番苦労する作業をAppleと協力して、比較的純粋なエンジニアリングで勝負できるJavaScript VMは自分で作るあたりが、GoogleらしいといえばGoogleらしい。

　ターゲットユーザーを考えれば、短期的にマーケットシェアを失うのは、IEではなくFirefoxだろう。私の場合は、すでにWebkitベースのSafariをメインで使っているので、OS-X版さえ出してくれれば乗り換えは簡単だ。当然、長期的にはIEにも影響を及ぼすだろうけど、結局は「最初から入っていたブラウザー」を使う人が多いことを考えれば、Googleがすべきことは、Dellなどのパソコンメーカーを説得して、デフォールトのブラウザーにしてもらうこと。

　Googleにとって、戦略的にもっとも大きな意味を持つのは、これによりGearsの普及が大きく進むこと。Gearsの普及が進むことがGoogleにとってどうして重要なのかに関しては、長くなるので別の機会に。

　ここのところブログの更新がさっぱりなのは、iPhone向けのアプリの開発で大忙しだから。４月１５日にApple Desng Awardの件がアナウンスされてから二週間、ようやくAward向けのアプリも形になって来たので一息つける。締め切りの５月１２日まではまだ少し余裕があるが、締め切り寸前にプログラムを変更するのが大嫌いな性分の私はこのくらいの段階で「今日出そうと思えば出せる」ぐらいのクオリティに仕上げておかないと気が済まないのだ。後は徹底的なテストと、見た目の微調整。「ベータ版」としては十分のできだ。

　iPhone SDKもbeta4になり、ようやくチューニング用のinstrumentsも安定して動き始めたので、今日はメモリー・リークの徹底的なチェック。非同期通信だらけなのと、Objective-C覚えたての時に書いたコードが混ざっているため、予想通りリークだらけだったが、このツールのおかげて順調にリークを直すことができた。ガベージ・コレクションのないiPhone OSの場合、自分でリファレンスカウントの管理をちゃんとする必要があるが、非同期通信をきちんとサポートするためには、Model-View-Controllerのアーキテクチャ徹底した上で、それぞれのライフサイクルをきちんと考え抜いてノーティフィケーションのメカニズムを作らないと安定しては動いてくれない。このあたりのノウハウに関しては、一度ちゃんとまとめて書いてみたいが、少なくともiPhone SDKのNDAの呪縛が解けてからのことだ。

　ちなみに、３月からはじめたObjective-Cにもすっかり慣れたが、これはすばらしい言語である。スクリプト言語なみの自由度を持ちながら、必要なところはstrong-data-typeな部分を活用して「つまらない人的ミス」を減らすことができる。C++やJavaよりは明らかに開発効率が良く、JavaScriptやActionScriptよりも遥かに自由度と完成度が高い点が私としてはたまらなくうれしい。

　しかし何と言ってもすごいのが、iPhone OSと開発環境の充実度。Interface Builderまでもがきちんと動くので、「組み込み系の開発環境」としてはブッチギリでNo.1だ。数年前からこの分野でプラットフォームを提供している、Sun Microsystems、Microsoft、Qualcomm、Symbianがここまであっさりと抜かれると誰が予想できただろう。まあ、それもこれも、スティーブ・ジョブズが一度アップルを追い出され、NeXTを作ったからこそiPhone OSが存在するというのは何と言うドラマだろう。