TidBITS#942/25-Aug-08 TidBITS#942/25-Aug-08最近の潮流に倣って、今週号は iPhone と MobileMe に焦点をあてる。iPhone が世界中の 43 カ国で利用できるようになったという事実を除き、ニュースは全面的に肯定的なものとは言えない。iPhone 2.0 ソフトウェアで独立のアプリケーションがロードしないという人に対して、Steve Jobs から直接の回答があって彼はこれがバグだと認め、修正は 9 月に出されるとのことだ。また MobileMe については、Rich Mogull がこのサービスのウェブインターフェイスがセキュアでないことを説明するが、他のアプリケーション、例えば Mail、iChat、iCal といったものたちが実際セキュアな通信を使っていることも彼は確認する。Apple はまた MobileMe のメンバーシップをさらに 60 日間無償延長したが、Adam は同社が実際すべての問題点について謝罪することなくこの行動に出たことに注目し、Apple による MobileMess (MobileMe のゴタゴタ) の処理と、Google による Gmail の機能停止の処理や Netflix による出荷のトラブルの処理を比較してみる。さて、ギアを切り替えよう。Charles Maurer が、彼のワインのコレクションを追跡記録するためのアプリケーションを探索し、結局 FileMaker の Bento にたどり着く。今週の監視リストでリリースをお伝えするのは、重要な MacBook Air Update と、Mactracker 5.0.4 と Keyboard Maestro 3.4 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Adam C. Engst <[email protected]>
訳： 笠原正純<panhead@draconia.jp>
Apple は 新たに 21 ヶ国で iPhone を発進させ、合計で 43 ヶ国で使えるようになった。Reuters は ロシアも 2008 年 10 月には iPhone のサービスが始まると伝えた。私たちは Apple がローカルキャリアとの交渉を進めることでさらに多くの国々が iPhone をつなぎ始めるであろうと確信している。Apple の世界制覇のプランは着々と進行中だ。
iPhone が 6 億 6 千万人の潜在顧客を抱えることになったことについていろいろ言われているが、それは純粋に誇大広告だ。なぜなら、それが各市場でどれだけ売れるか、Apple がローカルキャリアとどんな契約を結ぶのかを知る術はないからだ。私がもっと興味深く見守るであろう事は App Store の売上に対する影響だ。iPhone のインストールベースが 100 万前後も増加することは、個々のアプリケーションもそれぞれ従来を大きく上回る売上を達成できる可能性があるからだ。
文： Jeff Carlson <[email protected]>
訳： 羽鳥公士郎 <http://www.ousaan.com/mail/>
Apple は自らを不透明にしようと多大な努力を払っている。近ごろは特にそうだ。最近のソフトウェアアップデート、たとえば iPhone 2.0.2 では、リリースノートに「バグ修正」としか書かないし、MobileMe 立ち上げ時の問題やその後も続いた電子メールの問題については、まったく認めないか、認めたとしてもいいかげんだ。（2008-08-19 の "Apple の MobileMe に関する懺悔を Google や Netflix と比較" 参照。）
そんなわけで、裏ルートで有用なコミュニケーションが出現したことには大変驚いた。そこでは、Apple の広報担当者が提供できない直接の回答が得られる。提供しているのは、Apple の CEO、Steve Jobsだ。
１人の TidBITS 読者が、何人かの人が直面している iPhone の問題に関するJobs からの個人的な返信メールを私たちに提供してくれた。彼女は、iPhone 2.0 ソフトウェアと iTunes 7.7.1 にアップデートして以来、サードパーティーのアプリケーションがまったくロードできなくなり、iTunes ではiPhone のメモリが空だと表示されるようになった。その後の iPhone アップデートでも問題は解決されなかった。（この問題に対するユーザーの反応についは、 Apple Support Discussion のスレッドをお読みいただきたい。）
彼女の電子メールに対する Jobs の返信は１文だけで、直接的かつ有用だ。問題を認め、その解決にかかるおおよその時間を提示している。「これはiPhone の既知のバグで、次回の 9 月のソフトウェアアップデートで修正される予定です。」（私たちは Jobs からの電子メールを以前にも見たことがある。この電報のような直接的なスタイルは彼のトレードマークだ。2007 年 1月、１人の読者が、多くの Mac モデルに隠されていた Wi-Fi 機能を有効にする Draft N 有効化ソフトウェアに半端な 5 ドルを課したことについて Jobsに電子メールで不平を述べ、その CEO からの返答を見せてくれた。「それが法律です。」というものだった。）
Jobs は明らかに、彼の従業員たちに課している緘口令にしばられていないようだ。率直に言って、これは胸のすくような話だ。ユーザーが[email protected] にメールを出して返事をもらえるからというだけでなく、その返事が実質を伴っているのだから。もしも Jobs が現在の Apple のやり口にしたがわなければならないなら、彼はほとんどの企業からやってくるような頼りないせりふで答えることになっていただろう。「電子メールをありがとうございます。Apple は弊社製品をできる限り改善するよう全力を尽くしております・・・」云々。
私たちとしては、Jobs が Apple でオープンなコミュニケーションを促進することを願いたい。未発表の製品を守るために緘口令が必要なことは理解できるが、同社の最近の回答拒否は逆効果になっている。Cupertino が頑固なまでに沈黙していれば、便りがないのはよい便りというイメージを与えるどころか、Apple のユーザーや彼らを追いかけている私たちとしては、カーテンの後ろに悪いことが隠されているのではないかと疑問を抱き始めることになる。
文： Rich Mogull <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
MobileMe の打ち上げは Apple にとって製品リリースの見せ場の一つとは言えないものだったが、最も辛辣な批評家でさえ、そのウェブインターフェイスが市場にある最もうまくデザインされたものの一つであることは不承不承ながら認めるところだ。けれども残念ながら、MobileMe のウェブアプリケーションはまた最もセキュア度の低いものの一つでもある。Apple は、電子メールの内容やカレンダーのアップデートを含むあなたのコミュニケーションを誰にでも傍受できるものにしてしまっているのだ。
AppleInsider は、MobileMe について書いた 2008 年 8 月 15 日の記事で、MobileMe のウェブインターフェイスが悪意ある傍受や乗っ取りから接続を保護するために SSL 暗号化を使っていないことに関する 懸念を和らげようと努めている。その記事の主張は SSL が以下の理由で不必要というものだった：
「MobileMe のウェブアプリケーションにおけるデータ転送のセキュリティは、HTTPS において用いられる SSL ウェブページ暗号化ではなく、自己完結した JavaScript クライアントと Apple のクラウドとの間における JSON データ交換の認証付き処理に基づいている。MobileMe がサーバとの間で交換する本物のウェブページは、アプリケーションの構成要素となる HTML、JavaScript、および CSS ファイルに限られており、それらについては最初にユーザー認証が行なわれるため、SSL 暗号化の必要はない。このことはウェブのセキュリティがブラウザの SSL 錠前アイコンと同義だと考えるウェブユーザーの間で無用のパニックをひき起こした。加えて当然ながら、インターネットの電子メールはいったんあなたのサーバを離れれば元来セキュアでない媒体である。」
「もしも Apple がブラウザに SSL 暗号化を適用したならば、それは実際にはセキュリティを増すことなくすべてのデータ転送をただ速度低下させるだけの結果となるだろう。その上、本物のセキュリティの脅威から心をそらせ、その代わりに偽りのセキュリティの感覚を評論家たちに提供するのみとなる。」
ああ何たることか、これは明白な虚偽の主張だ。Star Trek ファンの方ならば、「テクノバブル」という用語をご存知だろう。事実でない、むやみにテクノロジー用語で埋め尽くされた言葉を俳優たちが声に出すことで、あたかも科学的に正確であるかのような印象を与えることだ。「クリンゴンのタキオンビームに調和共鳴する周波数へとシールドを調整せよ」という文章は、まるで本物のように聞こえながら実はたわ言の山に過ぎないが、「MobileMe のウェブアプリケーションにおけるデータ転送のセキュリティは、HTTPS において用いられる SSL ウェブページ暗号化ではなく、自己完結した JavaScript クライアントと Apple のクラウドとの間における JSON データ交換の認証付き処理に基づいている」という文章もそれと同じだ。そのことは単に、あなたがログインする際に MobileMe との間の通信に JavaScript が用いられるということしか意味しておらず、そこには何らのセキュリティの魔術も存在していない。
Jens Alfke が Thought Palace ブログで報告したように、MobileMe にあなたがログインする最初の段階では暗号化が使われるが、それ以後のセッションはプレインテキストとして送信される。もしも誰かあなたのネットワークにいる人があなたの接続を傍受してあなたの電子メールを読んでやろうと思ったら、彼らを止める方法は何もない。
結局 AppleInsider の主張が言っているのはこういうことだ。「Apple はあなたがログインする際にあなたが本物のユーザーであることをチェックしている。それ以外のすべてのものはあなたのブラウザと同社のサーバの間で暗号化なしに送られる。だから、我々が思うに SSL はパフォーマンスを落とすだけで何もセキュリティを改善しない」と。この最後の結論付けは、これ以上ないほどに間違っている。
金を惜しめばそれ相応の物のみ手に入る (はずだ) -- 公平を期して言えば、Yahoo Mail や Hotmail も、同じように最初のログインのみにしか SSL を使っていない。Google は最近になってやっと、全セッションで SSL を使うオプションを Gmail に追加した。でも、だからと言ってそれが Apple の決定の言い訳になる訳ではない。Yahoo Mail も Hotmail も無料のサービスだ。一方私たちは MobileMe に年額 $99 も払っている。注文が厳しすぎると言うなら言うがよい。それでも私は営利サービスには高いレベルを期待したい。Google も今では無料で SSL を提供しており、電子メールを提供する営利のウェブサービスならばほぼ例外なく SSL をオプションとして（あるいはデフォルトで）提供しているのが現状だ。
Apple によるユーザー認証の処理にはまたもう一つ、微妙だが重要な欠陥がある。Alfke も報告したように、セキュア認証ページは auth.apple.com を指すのに、それ以外の部分の MobileMe は me.com ドメインを使っている。ドメインの検証のために SSL が使うデジタル証明書と、大部分の相互作用が実行されるドメインとの間の繋がりを断ち切ってしまうことによって、ユーザーたちはリダイレクト攻撃を受けてしまう脆弱性を持つ結果となる。これは最近話題になった DNS 脆弱性への攻撃と同じことだ。（2008-07-24 の記事“Apple、DNS が攻撃される危機的な欠陥をパッチせず”参照。）DNS がローカルネットワークで汚染されることもあり得る。セキュアでないドメイン、例えばあなたがログインしているホットスポットのようなところで、アタッカーがネットワークを偽りの応答で溢れさせる攻撃が可能だということだ。
悪い奴が me.com ドメインを一時的にハイジャックして、あなたのログイン体験を全く変えることなくあなたを悪意あるサイトに振り向けることが可能なのだ。なぜなら、あなたは引き続きハイジャック対象ではない apple.com ドメインにおいて認証を受けているからだ。MobileMe のウェブインターフェイスを完璧に模写する悪い奴がそう多くいるとは思えないが、よくある攻撃方法は（これは私が最近の DefCon ハッカーカンファレンスで Wi-Fi を使って実演して見せた方法でもあるが）リダイレクトによってあなたを悪意あるサイトに振り向けてから、その悪意あるサイトが素早くあなたの Mac を攻撃し、その後であなたの気付かないうちに本物の me.com にあなたを転送して戻す、というものだ。
全セッションを SSL でセキュアにすることは「実際にはセキュリティを増すことなくすべてのデータ転送をただ速度低下させる」のではない。MobileMe はウェブベースのアプリケーションなので、あなたはページがリフレッシュされるまで待つ訳ではない。あなたがするのは、非常に少量のデータが行き来するのを待つだけだ。（あのたわ言だらけの段落に出てきた JSON というのは、実際には軽量の JavaScript オブジェクトのためのフォーマットだ。）
（Apple がブラウザに保存される認証クッキーをセキュアフラグでマークしているのは事実だ。このトークンは、持続的にログインされた状態を保つために使われるが、auth.apple.com に SSL を使って送られるのみだ。これによってサイドジャッキング攻撃は回避できる。この攻撃テクニックは以前は Gmail やその他の Google サービスで動作していたが、同社が問題点に気付いてこのトークンもパスワードと同様に保護されるよう対策を講じてからは動作できなくなった。2007-08-27 の記事“開いた Gmail、その他サービスを Sidejack 攻撃がこじ開ける”参照。）
良いニュースもある、あなた自身を守ろう -- あなたが公共の場所に出かけている時には、小さいながらもある程度の可能性で誰かがあなたの接続を傍受しているリスクがあるが、リダイレクト攻撃を受ける可能性は極めて低い。それに、MobileMe のウェブインターフェイスが基本的にセキュアでないとは言え、他の MobileMe サービス（ただし iDisk 以外）は適切に保護されている。
あなたの MobileMe 電子メールアカウントの設定をする時は、セキュアな接続がデフォルトとなっている。また、私は iCal をテストしてみて、プッシュも、手動の同期も、どちらも SSL を使っているらしかった。私自身のシステムにスニファーを使ってみても、同期中のカレンダー項目や電子メールの内容のいずれにもアクセスできなかったからだ。iChat の認証もやはりセキュアで、MobileMe はデジタル証明書をインストールすることで他の iChat ユーザーたちとの間にセキュアなチャットを実現している。この点は AOL Instant Messenger やその他多くの無料のインスタントメッセージング方法とは違うところだ。ただし注意すべきは、あなたが MobileMe 暗号化とともに iChat を使ったとしても、もしもあなたがセキュアでない AIM ユーザーと通信すればその iChat 接続はやはりセキュアでないものになってしまうことだ。
私はいつも Mac か iPhone の近くにいるので、実際に使う必要があることは少ないのだが、私は新しい MobileMe のウェブインターフェイスが大好きだ。けれども私がそれを使うのはたいていの場合セキュアでないシステムやネットワーク、例えば外国を旅行中のインターネットカフェなどでなので、やはり私は Apple が SSL を適切にサポートする日が来るまでは、この便利な方法から一歩距離を置いて、もっとセキュアな方法を使い続けざるを得ないだろう。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
2008 年 8 月 18 日遅く、MobileMe ユーザーたちに送られた電子メールの中で、Apple はこのシステムにおけるすべてのアカウントを 60 日間延長すると発表した。2008 年 8 月 19 日の午前 0 時（米国西海岸時間）の時点で有効であったすべての購読アカウントおよびフリートライアルアカウントが二ヶ月間延長される。この 60 日間無償延長は、Apple が前回行なった 30 日間の無償延長を受けた購読者にもやはり適用される。（誰が前回の延長の対象になったかについては 2008-07-16 の記事“MobileMe 罪を認める： Apple の謝罪と Tiger の状況説明”参照。）今回の 60 日間延長は数日以内にユーザーのアカウントに適用される。
双方合わせて 90 日間のメンバーシップの延長は、年額 $99 のフル料金を払って .Mac/MobileMe を購読している個人にとって $24 に相当する。（ヒント： 新規アカウントには箱入り版の MobileMe を買えば節約になる。例えば Amazon では定価 $149 の MobileMe Family Pack を $109.99 で販売中だ。）Apple は MobileMe の購読者数を発表していないが、オンラインの噂では二百万人という数字が言われることが多い。けれども、私がその数字を Apple 内部の筋から聞いたのは数年前のことなので、おそらく現在のユーザー基盤はもっと大きいだろう。とりわけ、六百万とも言われる iPhone および iPod touch ユーザーたちのために MobileMe が果たす役割を考えればなおさらだ。つまり、Apple は少なくとも合計で四千八百万ドル、おそらくはそれよりずっと大きな金額を、MobileMe メンバーシップ料金として徴収せずに見送る計算になる。
財務上の打撃がそれほどに大きいことが、MobileMe への移行に際して起こったいろいろの問題、例えば失われた電子メール、サービスの機能停止、同期の問題その他について、Apple があまり申し訳なさそうな態度を見せていないことの原因の一部となっているのかもしれない。内部的には、Apple がこのサービス無償延長について大きく発表すべきものと感じていることは間違いないと私は思う。なぜなら、会社にとってこれは相当大きな金額になるからだ。あるいはより正確に言えば、相当に大きな額の収入を未来に先送りにすることになるからだ。この延長が実際に意味するのは、現行の購読者たちから MobileMe 更新の料金収入が入ってくるまでに、Apple はあと 90 日間待たなければならないということだからだ。
けれども個々のユーザーにとっては、$24 というのはそれほど大きな金額ではない。もしもあなたが失われた電子メールを処理しながら、あるいは同期の問題に髪を掻きむしりながら何時間も費やしたとすれば、たったの $24 ではその埋め合わせにもならないだろう。特に、Apple からの通信文のどれ一つとして「すみませんでした！」の一言で始まっているものはないのだから。Apple は、この状況についていくつもの公式声明を出して問題点が存在したことは認めたが、率直にものを言うという点では Steve Jobs 本人による内部的電子メールが断然他を圧倒しており、公式声明の中で「謝罪」という単語を使ったものはたった一つだけ、それもたった一回使っただけだった。
MobileMe ユーザーたちに最初に送られた電子メールの一部を抜粋すると、
「私たちは忠実なる顧客の皆様に謝罪し、皆様が忍耐強くいて下さることへの感謝の意を表するため、すべての現行の購読者の皆様に MobileMe 購読を自動的に 30 日間無償で延長することに致しました。」
これはまた、実際に何が起こっていたのかを説明した唯一の公的なメッセージでもあった。それ以降の声明はすべて、今日の電子メールも含めて、忍耐を求めるとともに MobileMe への移行が予想よりも障害の多いものであったことについて漠然とした言葉を並べていたものの、謝罪を繰り返すことはしなかったし、詳細情報を明かすこともなかった。今日の電子メールの一部はこうだ：
「私たちは既に多くの改善を MobileMe に加えましたが、まだ改善しなければならない点が数多く残っています。ユーザーの皆様の忍耐にお応えするため、私たちは本日時点すべての MobileMe 購読者の皆様に 60 日間の無償延長を提供することに致しました。これは、多くの購読者の皆様に既に提供されております一ヶ月に追加して延長されるものです。私たちは現在、MobileMe が誰もが誇りにできる素晴らしいサービスとなることを目指し懸命に作業を進めております。私たちは MobileMe のスタートが栄光の時とは言えないものであったことを承知しており、その状況を良いものとする間、皆様にお待ちいただけることを心から感謝しております。」
ライターとしての私は、この Apple の声明が問題の本質を避けてただ周辺を跳ね回っているだけという印象を強く受ける。また、親としての私の頭には、友だちに謝りなさいと言われてきちんと「ごめんなさい」が言えない子どもにいつも言っている言葉が即座に浮かんだ。「あの子にちゃんと聞こえるように言いなさい、あなたが言いたいことをはっきりと言いなさい」と。ここで、いくつかの最近起こった有名どころの機能停止と比較をしてみるのも教訓的かもしれない。
MobileMe Mail と Google の Gmail とは、どちらも 2008 年 8 月 11 日に数時間にわたってダウンした。Apple からの最近の電子メールには移行における障害の具体例としてメールの機能停止は触れられていないし、私の知る限りそれに触れているのは MobileMe System Status ページ（皆さん、このページはぜひブックマークしておこう！）における二つの項目のみだ。ほとんど匿名の MobileMe Status ブログに至っては今回の機能停止は全く載っておらず、最後の記事が 2008 年 7 月 29 日だった時には電子メールが失われたが復旧されたと主張した上、その週のうちにもう一度記事を出すと約束した（けれども実際には出なかった）だけであった。私が当初この記事を書いた後、Apple は公式に MobileMe Status ブログを閉鎖してしまった。おそらくこれが最初から全く信憑性のないものであったと気付いたのではないだろうか。
それとは対照的に、Google は“We feel your pain, and we're sorry”と題した 非常に低姿勢の謝罪のメッセージを素早く Official Gmail Blog に掲載した。その中で、何が問題だったのか、なぜそれが起こったのか、将来問題が再発しないために Google がどのような対策を講じているのかについて適度に詳しい説明を記している。Google が Google Apps Premier Edition (99.9% のアップタイムが保証されている) の有料購読者に対して何らかの返金を提供したのかどうか私は知らないが、Gmail はもともと大多数のユーザーには無料なので、必要なのはおおむね謝罪が中心となるだろう。
もう一つ別の例として、Netflix で先週起こった出荷システムの機能停止をめぐってどのようなコミュニケーションの処理がなされたかを見てみよう。二日経たないうちに、“We're Sorry DVD Shipments Are Delayed”と題した電子メールが届いた。そのメッセージの最初の段落に何が起こっているのかの説明があり、第二段落には謝罪の言葉と、迷惑に対するお詫びとして Netflix がユーザーに補償をするという説明、そして第三段落では再び謝罪と、更なる援助を必要とする人のためのカスタマーサービスの電話番号が記されていた。考えてみればこれは、決して MobileMe や Gmail のような少なくとも一部の人々にとってビジネス上依存するところのあるサービスではなく、単なる娯楽サービスでの話なのだ。
翌日また Netflix から、“We're sorry your DVD shipment was delayed”と題した同様のメッセージが届いた。そこには何が問題であったかの説明があり、既にシステムは回復していると記されていた。それに続いてまた何度か謝罪の言葉が繰り返され、次のような巧みな文章も含まれていた：
「私たちは皆様に楽しんでいただくことを誇りとしています。にもかかわらず私たちは皆様の期待を裏切りました。私たちは大変申し訳なく思い、皆様のアカウントに数日以内に 15% の返金をさせていただきます。皆様は何もなさる必要はございません。返金分は次回の請求書において自動的に適用されます。」
それだけでなく、Netflix は Netflix Community Blog にもアップデートを掲示してユーザーたちが状況を常に知ることができるように見事な仕事をしてのけた。2008 年 8 月 12 日に始まって、2008 年 8 月 15 日に状況が解決するまで、毎日一通か二通の記事が必ず出された。これこそ、誠意というものではないだろうか。過ちを認め、謝罪の気持ちのこもった言葉遣いをし、四日以内に返金を発表したのだ。
Apple も、問題の存在を否定している訳ではないし、すべてのことがじきに解消されるだろうというふりをしている訳でもない。それは良いことだ。けれども少なくとも私の耳には、Google や Netflix によるブログや電子メールのコミュニケーションの方がはるかに深く悔いた気持ちが伝わってくるように聞こえる。私に迷惑をかけたことに対し、これらの人たちは本当にすまなく思っているのだ、と。また、私は現実の人間から届いたメッセージに対しての方が優しい気持ちになれる。ことに、Netflix ブログの記事からは、Netflix の人たちがどんなに一生懸命問題の解決に努めているか、この機能停止についてどんなに申し訳ない気持ちでいるか、という感覚が伝わってくる。それに比べて、Apple からの匿名ないしほぼ匿名のメッセージは、その気持ちの重みの点で比較のしようもない。
その上、謝罪の言葉を表明することは有罪を認めることになる、あるいは弱点をさらけ出すことになるという理由で避けたがる人たちがいることは事実だが、その一方で誠実な謝罪の方が実際には訴訟沙汰を回避できる結果になることもあるという証拠も多数存在している。石の壁に囲まれたような気持ちになることが、人々が訴訟を起こす動機になることも多いからだ。このことについては Sarah Kellogg による DC Bar の記事“The Art and Power of the Apology”を読むことをお勧めする。また、最良の謝罪の方法や謝罪の有用性の解説などに焦点を絞ったウェブサイトPerfect Apology というものもある。
単に解説者としてだけでなく、私たちの 18 年にわたる歴史の中で一度ならず何万人もの TidBITS 購読者の皆さんへのメーリングを台無しにしてきた経験のある者として、ここで心に留めるべき教訓はこうだ： 相当多数のユーザーたちに影響を及ぼす問題に直面した時には、素早く明確に状況の詳細を知らせること、そのメッセージは現実の人間から出されたものであること、そして、お願いだからわが子よ、巻き込まれた人たちみんなにちゃんと聞こえるように「ごめんなさい」とはっきり言うことだ！
文： Charles Maurer
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
私はワインが好きである。私は容易に気取ったワイン通にもなりうるかもしれないが、三つの障害がある：まずお金がなさ過ぎる、名前も味もすぐ忘れてしまう、そして - 実際の所、ソムリエが私のフランス語にくすくす笑いしている傍らで気取ったポーズを保つのも並大抵ではない。
私のフランス語に関してはどうすればうまくなれるのか未だ見当もつかないが、20 年前に私の記憶が欲するものを私のお金が欲するもので部分的に補う術を覚えた：高価でないワインを買いそれを何処に置いたか忘れるのである。5 から 10 年経った頃たまたまこれらを見つけ出すと、これらのワインは結構良いものになっている。
しかしながら、安ワインなら何でも良いわけではなく正しい種類のものでなければならない。もしあなたが良い葡萄ジュースに酵母をいれそして何をやっているのか良く理解しえいるのであれば、口当たりのいいワインを造れる。このワインは安く出来るが、その中には時とともに良くなっていくものは何もない。その代わりに、ワインをすぐに瓶詰めするのではなく、1 から 2 年の間小さなオークの樽に入れて寝かすのである。このやり方だとお金も少々余計にかかり、そしてそのワインを瓶詰めする時にはその味はいただけるものではない。これは貯蔵しておく類のワインである。このいただけない味は木から滲み出したタンニンのせいである。このタンニンが年月とともに徐々に酸化してくる。この酸化物が葡萄ジュースと合わされて複雑で味わいのあるものになるのである。
年月をかけて妻と私はこの戦略を用いてセラーを造り上げてきた。我々はオークの中で寝かされたあまり高くないワインをケースで買い他のケースの裏側に置くのである、そうすればそこにあるのも忘れてしまう。何年かたった頃、それらを目にする。こうすれば、我々の予算が通常許してくれるよりも良いワインを飲めるのである。しかしながら、問題は我々がどんなワインを持っているのか皆目見当もつかないことであり、我々のセラーにボトルが何本あるのかすらわからない。
この夏、我々はこの事態を何とかしなければいけない時が来たと判断した - いやもっと正確に言えば、妻は私が何とかしなければならない時が来たと判断したのである。整理整頓は私の得意とするところではないので、私を助けてくれるソフトウェアはないものかと思った。
市場に出ているもの -- 本当に役に立つためには、コンピュータは単に我々のボトルのリストを保持する以上のことをやってくれなければならない、それ自身でボトルのリストを作ってくれるのである。まさにこの作業をやってくれるハードウェアとソフトウェアの組み合わせが $199 で出ている：IntelliScanner Wine Collector 250 である。ハンドヘルドのスキャナーがついていて、最近のボトルには殆ど皆ついているバーコードを読取り、次にアプリケーションがインターネットに接続してデータベース上でそのワインを調べるのである。私はこれは素晴らしいと思い、早速一文をしたためお願いをし、届いたらすぐに試してみた。私は色々な国からのボトル 10 本をスキャンした。ところが、Wine Collector が何らかの情報を埋められたのはたったの 2 本しかなく、残りは情報が全くないか間違っていた。IntelliScanner の Paul Scandariato はこう説明してくれた、"我々のデータベースには 67,000 のワインが載せられているが、これは世界中で出ているワインのほんの一部分にしかすぎないのです 。"
私の Mac はボトルのリストを生成することは出来ないかもしれないが、リストを保持する罫紙の役目は間違いなくしてくれる：スプレッドシートである。しかしながら、このリストは多くのテキストも含まねばならず、スプレッドシートの中のテキストは入れるのも読むのもぎこちない。この理由から、データ入力フォームを Mac 上で使えれば有用である。
これが専用のワインセラーアプリケーションがすることである。残念ながら、これらのフォームは私があまり気にしない多くの細かいことにスペースを割き、私の欲しいフィールドが一つか二つは必ず漏れている。私は、誰かよその人の物事に対する考え方を反映した複雑なフォームを埋めていくのに喜びは覚えないので、専用アプリケーションは使わないことにし代わりに一般用途の製品を使ってもっと簡単なフォームを作ろうと決めた。これがもっと前なら私はきっと今は廃版となっている AppleWorks を使ってやっていたであろうが、代わりとなるものとして Bento を見つけた。これは $50 の製品で、Apple の子会社 FileMaker から出されている。
自前の瓶詰め -- Bento は、ポイント＆クリックのダイアログボックスを提供してくれるので、私が追跡したい情報の種類を手早く定義していくことが出来る、それはスプレッドシートで言えばコラム、データベースの専門用語で言えばフィールドにあたる。いったんフィールドを定義すれば、後はそれをデータ入力フォームにドラッグすることで、レコードの入力準備完了となる。ワインのリストを作成するために、"Table" と名付けられたボタンをクリックし、次にフィールドのリストの脇にあるチェックボックスの幾つかにチェックをいれた。チェックを入れることでフィールドがコラムとして現れる。コラムを気に入るような順序に並べ替え、次に Finder のスマートフォルダの様な "スマートコレクション" を実現する Spotlight に相当するものを設定した。幾つかのこれらスマートコレクションのためにコラムをカスタマイズした。ここまで来れば、ワインのついての情報を私が最も理に適うと思う方法で入力出来、そしてアイコン一つをクリックすれば簡便な我々の二つ星の白とか三ツ星の赤のリストを表示してくれる。
Bento は、個人用データベースとして宣伝されているが、FileMaker Pro とは違って、複雑なやり方で使われる複雑なデータベースを管理するように意図されて設計されたものではなく、リストを管理するように意図されている。データベース管理とリスト管理の違いは些細なものではあるが奥は深い。複雑な情報を効率的に保存しそして操作するためには、データベースマネジャー（管理プログラム）は情報を可能な限り小さい要素にまで分解し、かつ統一されたフォーマッティングを保ちそして如何なる重複も避けなければならない。これに対して、リストマネジャー（管理プログラム）は検索し並べ替えを行なうだけである、従ってその中の情報と言うものは自然な形を保つことが出来る。多くの人がデータベースマネジャーと思っているものは実際にはリストマネジャーなのである - 例えば Apple の Address Book がそうである。これがなぜ Address Book が電話番号をあなたの好きなどの様なフォーマットでも入れさせてくれるかの理由なのである。これに対して、大企業のための電話番号を管理するデータベースは番号を四つの違ったフ ィールドに分解することを要するであろう：国コード、エリアコード、電話番号そのもの、そして内線番号である。(ここで敢えて言わせてもらえば、Bento も Address Book もどちらも複雑なデータベースを管理するよう作られたエンジンを使っているのだが、これらのエンジンは一つのシリンダーだけでぐったらぐったら動いているだけなのである。)
データベースマネジャーを設定するにはそれ相当の専門知識と準備が必要であるが、リストマネジャーの方はそんなことはない。必要なことは、自分のリストを並べ替えるやり方をどの様にするかを決めること - ワインが赤か白かで、値段で、等々 - そしてこの情報を個別のフィールドに割り付けることである。残りの情報は、自分の好みに応じた大きさに分けてやればよい。
理屈の上では、リストマネジャーを設定するやり方はこうである：まず紙と鉛筆を用意し、自分のリストをどの様に並べ替えるかを考える、必要とするフィールドを決定、データ入力のフォームを設計、それからコンピュータに向かってそれを作り出すのである。現実は、問題について考え、コンピュータの前で何が必要かを考え仮の入力を入れてみる、そこであるカテゴリを忘れていた事に気付き、現実的でないと思えるものも出て来る。そこでフィールドとフォームに変更を加え、更に幾つかの仮データを入れて見る、そしてらスペースが大きすぎるところ少なすぎるところが出て来たりする。その変更をした後で、別なやり方でやればもっとうまく行くことに気付く。こんなことを数回繰り返した後でようやく全部がおさまる所に収まるが、一週間いや一ヶ月も経つと他に変更したい所が出てきてしまう。
Bento は、このプロセスをユーザーに幾つかの選択を可能にする簡単なグラフィックインターフェースを提供することで簡素化してくれる。データベースプログラマーの立場からすると、これらの選択肢はあまりに限られており非常識とも言えるぐらいである。(この点は Jeff Porten の Bento のプレリリース版に対する意見にも含まれている； "FileMaker の Bento： 生煮えで、ちょっと臭う" 2007-11-14 参照。) 例えば、あるフィールドは空ではいけないと規定することは出来ない。しかしながら、Bento は簡単な個人のリストを管理するもので、企業の複雑なデータ用ではない。たとえ私がワインの年次を入力するのを忘れたとしても、リストを表示すればその抜けには気付くであろうし、その時に入力してやればよい事である。Bento のあら捜しをしようと思えば出来る - スマートコレクションで見えている時にあるレコードを削除できないと言うのはとりわけ気に入らない - しかしながら全般的にはその制限の多さは後ろ向きというよりは助けになるし、構成も良く考え抜かれていると思う 。私はこれを使うことで、殆ど時間を取られることなく専用に作られた製品のような外観と感触を持ったワインセラーアプリケーションを作ることが出来たし、これまで見たどの専用製品よりも私の気に入っている。
我々の本の目録を作ると私が決心する日がいつか来るとしたら (あまり期待しないように)、私は Bento をそこには使いたいと思う。他にもクラシック音楽の CD 用に、ハードウェアの一覧に、或いはその他のもの何でも、それについての説明がインターネット上ではプログラムを使って確実にはアクセス出来ないようなもの用には使いたいと思う。(映画 DVD に関して言えば、インターネットデータベースに良く記載されており、私は Bruji の DVDpedia を使う。) Bento はファイルをコンマ区切りテキストとしてエクスポート出来るので、研究データを入力するのにスプレッドシートに対する好適な補助手段としても使える。
Bento のユーザーインターフェースにある幾つかの小さなバグに気付いたが、現在のリリース版は実用には十分なだけ磨かれており、そして Mac OS X 10.5 Leopard に組み込まれたツールも良く活用していると思う。(Tiger の下では動かない。) 願わくばもう少し機能を持っていて欲しいとも思うし、FileMaker がそれらを追加するのは容易い事だろうとも思うが、それよりも FileMaker が機能主義で Bento を殺してしまうのは更に易しいことだとも思うので、あまりその願いを一生懸命願わないようにしようと思う。現状では、Bento はあなたのお婆さんが外からの手助け無しに使い始められる程簡単ではないが、Bento でデータ入力フォームを設定し使うのは Address Book や iCal をカスタマイズし使う以上に難しいと言うこともない。Address Book や iCal は専用に作られたリストマネジャーであるので、これは印象的な設計の快挙と言えよう。
私のワインセラーファイルを試してみて -- もしあなたがワインセラー用のソフトウェアをお探しなら、私の Bento ファイルの空バージョンをダウンロードして、それが出発点として適当かどうか見てみるのは大歓迎である。しかし気をつけて欲しいのは、これはテンプレートではないことで - Bento はテンプレートをインポートしない - Bento の実際のデータファイルの単なる空バージョンであり、Bento が ~/Library/Application Support/Bento/ の中に保持する "bento.bentodb" というファイルである。もしあなたが既に Bento を使っているのであれば、あなたの既存のデータを保護するのに十分なる配慮が必要であり、そして私のファイルからあなたのへとフォームをコピーすることも出来ない；代わりにそれらを再度作り出す必要がある。Bento 自体は 30日限定の無料試行版が出ている。
もしあなたが Bento には詳しくないが私のファイルを試してみたいと言うのであれば、Bento の二つの設定を変えておいた方がいいと思う。Bento はあなたのアドレス帳とカレンダーと一緒に働き、デフォルトではこれらを表示する設定になっているので、これらを表示させると煩くなるし混乱も増す結果となるかもしれない。これらを隠すには、File メニューに行き、Address Book and iCal Setup を選択、そして出て来るダイアログで両方のボックスともチェックをはずす。
下記は私の入力フォームとリストフォームで、その内のフィールドの幾つかに対する説明も付け加えてみた。
[もしあなたが Charles の記事が役に立つと思われたら、あなたが通常飲まれるワイン一本分相当の金額を Save the Children 宛てに寄付して頂けるよう筆者は願っている。他の国での同組織に対するリンクは下記を参照されたい。]
文： Adam C. Engst <[email protected]>
訳： 笠原正純<panhead@draconia.jp>
文： Jeff Carlson <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Leopard と Microsoft Office の問題 -- システムをアップデートして以来、Leopard は登録済みのバージョンでなくデモ版の Microsoft Office を走らせるようになってしまった。(メッセージ数 6)
Time Capsule のアーカイブ -- Time Capsule ドライブをアーカイブすると、当初はうまく動くように見えるが、次第に耐えられないほど遅くなる。何が遅れの原因だろうか？ (メッセージ数 2)
iPhoto Update 7.1.4 以後、.Mac スライドが消えた -- MobileMe になって、写真をスクリーンセイバとして他の人と共有する機能が提供されなくなってしまったが、既存の .Mac スライドならばまだスクリーンセイバとして出てくる。(メッセージ数 14)
旅の途中で写真のバックアップをとる（続編） -- デジタル写真のバックアップについて、読者たちが新たなアイデアを寄せる。(メッセージ数 2)
私が Eye-Fi Share ワイヤレス SD カードを嫌う理由 -- Eye-Fi Share カードに対する Adam の体験談に、一つの問題点へのある解決策と、他の読者たちの体験談も寄せられる。(メッセージ数 10)
運転中に iPhone を使う -- 運転中に iPhone で他の人としゃべりたい、という読者がいる。もちろん、自分自身を危険に晒すことは望まない。TidBITS 寄稿編集者の Mark H. Anbinder が、新型の Audi に搭載された機器を紹介する。(メッセージ数 4)
iWeb と MobileMe の質問 -- あるマシンで作ったウェブサイトを、新しいラップトップ機でアップデートするのはやりにくい。(メッセージ数 6)
iPhone Ver 2.0.2 の「バグ修正」 -- バグ修正リリース iPhone 2.0.2 で何が修正されたのか誰か知ってるかい？ 私たちは知らない。だからこそ、私たちは Apple をからかうことができるのさ。“MobileMess”の状況もそうだ。(メッセージ数 6)
IMAP メールボックスを大掃除 -- Mail で IMAP メールボックスのサイズを管理するには、どんな方法が使えるか？ (メッセージ数 3)
Office 2008 アップデートがインストールしない -- 最新の Microsoft Office アップデートのインストールでトラブルに見舞われた読者たちが、このスイートで何が変わったのかを議論する。(メッセージ数 4)
Wine と Bento_-- ワインコレクションを Bento で管理しようという Charles Maurer の記事を読んで、例えば書籍や楽曲など、他のものをカタログ化するツールはどうかという座談会が始まる。(メッセージ数 6)
MobileMe ウェブインターフェイスは非セキュア、他のアップは正しく動く_-- rich mogull の詰事を受けて‖読者たちが mobileme のホネュリテッ面について議論する｜(メッホーヘ数 3)
Flash の問題 -- 長年ずっときちんと動いてきたのに、突然 Flash が正しく動かなくなった読者がいる。犯人は JavaScript かもしれない。(メッセージ数 2)
Outlook にサヨナラしたい -- Outlook の呪縛から逃れるのは難しいが、代わりとなる方法はいくつかある。(メッセージ数 3)
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2008 TidBITS: 再使用は Creative Commons ライセンスによります。
, 
日本語版最終更新：2008年 8月 31日 日曜日, S. HOSOKAWA
Take Control 電子ブック日本語版好評発売中