TidBITS#926/28-Apr-08 TidBITS#926/28-Apr-08Apple は前会計四半期に十億ドル以上の純利益を稼ぎ出したが、果たしてそれで終わりだろうか？ 同社が iPhone の収益を計上しているやり方を見ると、まだまだこれからこの機器に関連した収入の多くがこれから入ってくることになる。具体的な数字を挙げて説明しよう。今週号では、Glenn が Microsoft の新しい Live Mesh サービスを概観してこれがデータ保存の将来に対するどのような前兆になっているかを語り、またこれだけ長年を経てもまだまだ多数のウェブサイトがいまだに手作業で HTML コーディングをして作られていることについても論じる。Rich Mogull は悪化する可能性のあるセキュリティ状況に対し、最新の QuickTime の改善がこれを整理して終わらせるためのほんの第一歩に過ぎないと説明する。さらに Mark Anbinder が最新の高速化されたiMac のニュースをお届けし、Charles Maurer がデジタル写真のカタログ分けと保存という難しい仕事に立ち向かうための戦術とツールの記事で再び登場する。その他の TidBITS 出版関係のニュースとしては Ted Landau の iPhone 本が iPhone 1.1.4 ソフトウェアの情報を加えてアップデートされたところで、また今週の DealBITS 抽選では写真用ジオコードソフトウェア HoudahGeo が当たる。最後に、今週の TidBITS 監視リストでは Boot Camp、VMware Fusion、TextExpander、Default Folder X、ScreenFlow、MacBook Pro Firmware、Apple の Firmware Restoration CD、それに Keyboard Maestro のアップデートにスポットライトを当てる。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Mark H. Anbinder <[email protected]>
訳：上松慮生 <ryo.uematsu@gmail.com>
Apple は、珍しい月曜日の朝の製品発表を行い、アルミニウム外装の iMac のアップデートを行った。20 インチと 24 インチのフラットパネル・オールインワンコンピュータは従来の 2.0、2.4、2.8 GHz のチップよりも高速な Intel Core 2 Duo プロセッサを搭載している。20 インチのフォームファクターでは 2.4 と 2.66 GHz の選択肢があり、24 インチでは 2.8 と 3.06 GHz の選択肢がある（"Apple、新しいアルミ iMac をリリース、Mac mini を更新"2007-08-13 を参照）。
iMac は最大 4 GB のメモリとともに、より大きな SATA のハードディスクに変更できる。$1,199 の最低価格の構成では最大 500GB に、$2,199 の最高級の構成では最大 1 TB に、それぞれ変更が可能だ。
熱烈なゲームファンは最高級の構成に含まれる（そして、2.8 GHz 24 インチモデルでは $150 で変更できる） 512 MB のビデオメモリを搭載した Nvidia GeForce 8800 GS ビデオカードを気に入るだろう。Apple は Quake 4デモにおけるテストで Nvidia のグラフィックカードは他の iMac の構成に含まれている ATI Radeon HD （最初の 3 つの iMac は 128 から 256 MB のメモリ容量を持つさまざまな Radeonカードを搭載している）に比べて倍の性能を有していると述べている。
文： Adam C. Engst
<[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Apple が 2008 会計年度第２四半期の決算報告をリリースした。2008 年最初の三ヶ月のこの期間に、ほぼすべてにわたって好調な結果が示された。四半期での売上高は 75.1 億ドルで、そこからの純利益は 10.5 億ドル、１株あたりの利益は 1 ドル 16 セントだった。これに対して前年同期は売上高 52.6 億ドル、純利益 7.7 億ドル、１株あたり 87 セントという結果だった。つまり売上高で前年同期比 43% 増、純利益で 36% 増となる。
売上高は高い数字を示した（2007 年最後の三ヶ月にあたる 2008 会計年度第１四半期のホリデー期間の数字よりは下がったが、前年同期よりは大きく伸びた）ものの、Apple の会計慣行のせいでこの数字には現在の iPhone 売上げの莫大な金額が含まれていない。Apple は、収益計算において iPhone の売上げを（Mac の売上げのように）単体購入として扱わず、24ヶ月単位の購読のようにして扱う道を選んだ。Apple TV や AppleCare の売上げも同様に処理されている。
Apple はさらに、2008 年 3 月 6 日（同社が iPhone SDK を発表した日）以降の iPhone のすべての売上げ勘定を iPhone 2.0 ソフトウェアが出荷されるまで延期することにした。その理由として同社が挙げているのは、その日以後に iPhone を購入した人たちはまだ入手できないそのソフトウェアを期待しながら購入したのだから、というものだ。これは売上勘定を延期する理由としては極端に控え目なものと言えるだろう。なにしろ、彼らがまだ勘定に入れていない売上げが今や 38 億ドルにも達しているのだから。その結果、次の四半期には途中で詰まっているこの大量の丸太の一部分がどっと流れ込むことになるだろう。（もしもあなたが AppleCare なんてはした金だと思っているのなら、2008 会計年度第２四半期現在、延期された売上勘定としてこれが 10 億ドルに達していることに注意されたい。ただしその一部は保証修理を実行するための費用と相殺される。）
Apple は 2008 年 1 月に、iPod touch の売上げはすべて即座に勘定に入れられると述べたことがある。これは、ソフトウェアアップデートに料金を課すことを正当化するためのものだった。iPod touch のバージョン 2.0 ソフトウェアリリースについても同じことが言える。
さて、米国市場以外での売上高は全体の 44% を占めた。これは前年同期の 43% に比べてわずかな上昇を示したが、2008 会計年度第１四半期の 45% よりはわずかに下がった。最も好調だったのは日本の市場で、前年同期の売上高に比べて 49% の伸びを示し、ヨーロッパ市場の 45% や南北アメリカ市場の 46% を上回った。
けれども、単一区分として最も突出した伸びを示したのは Apple のリテール店で、2007 会計年度第２四半期に比べて何と 74% も増加した。リテール店の売上高は 15 億ドル、１店舗あたりの平均にして 710 万ドルとなる。（一年の大半開いている店舗数が 205 という数字をもとに算出した。）2006 年の末にあるアナリストが計算したところでは、 店舗面積あたりの売上げで Apple はダイヤモンド小売店の Tiffany and Co. をはるかに上回っているという。その後 Tiffany が同程度の売上げ増加を達成していない限り、今や Apple は他のどんな小売店をもはるかに引き離す勢いを持っているのだろう。
Apple の現金残高も前四半期の 184 億ドルから 194 億ドルへと増えた。これだけの運営資本があれば、新製品を導入するにも十分以上だろうし、ひょっとしたら小さな国を買い取ることだってできるかもしれない。Microsoft 社は、2003 年からほぼ倍に増えた現金残高を前にして、株主たちからの圧力の下に四半期ごとの配当金といういささか古めかしいアイデアを導入することを余儀なくされた。今のところ Apple はそのようなアイデアには手を染めていないようだ。
一番素晴らしかったのは Mac の売上げの増加だ。前年同四半期に比べて台数で 51% 増加、売上高で 54% の増加となった。もはや全体的な傾向となっている通り、ラップトップがその牽引車となって、販売台数は 1,433,000 (61% の増加) となり、四半期四期連続でラップトップ機販売台数の記録を更新した。これに対しデスクトップ機の販売台数は 856,000 (37% 増加) だった。ラップトップ機の販売台数はホリデーシーズンだった 2008 年度第１四半期さえをも上回った。ほんの２年前、2006 年度第２四半期には、Apple が販売したラップトップ機はたったの 498,000 台だった。
もちろん、iPod の売上げはホリデーシーズンの第１四半期の 22,121,000 台には遠く及ばない 10,644,000 台で、第２四半期としては前年同期からほんの 1% しか伸びなかった。ただし、iPod touch の販売が伸びたお陰で、iPod の売上高としては前年同期に比べ 8% の増加を示した。iTunes Store (iPod のサービスと iPod アクセサリを含む) の売上高への寄与は 8 億 8,100 万ドルで、第１四半期から 9% の伸び、前年の四半期からは 35% の伸びとなった。
Apple は 1,703,000 台の iPhone を販売し、これは台数としては第１四半期より 26% 減ったが、興味深いことに売上高としては 57% の増加となった。つまり、Apple は iPhone １台あたり相当に多くの収入を得るようになったということだ。先ほど述べたように売上勘定の延期を行なったにもかかわらずだ。同社は現時点で全世界で合計 570 万台の iPhone を販売しており、2008 年末までに販売累計は一千万台に達するだろうとの予測を明言している。
Apple CFO の Peter Oppenheimer は、2008 会計年度第３四半期には売上高として約 72 億ドル、１株あたりの利益として約 1 ドルを見込んでいると述べた。その目標が達成されれば、2007 年度第３四半期に比べておよそ 33% の増加となる。
今回の決算報告で、iPod の売上げの伸びが芳しくなかったことを除いてただ一つ目立って良くない数字を示したのは、売上総利益率、つまり売上額の中で Apple の利益分となる割合だ。この四半期の結果は 32.9% となり、これは前四半期の 34.7% よりも、2007 年度第２四半期の 35.1% よりも低かった。
文： Glenn Fleishman <[email protected]>
訳： 亀岡孝仁 <takkameoka@bellsouth.net>
Microsoft は Live Mesh について語ることで、久方ぶりに最初の真に新しいものを明らかにした。これは、ツールとサービスが一式になったもので、これによりユーザーはそのデスクトップからクラウドサービス - インターネットベースの保管庫 - に対してデータを自動的にシンク出来るようになり、一方でデベロッパーに対しては、何処にデータがあろうがそしてどの様な機器が使われようが、同様の経験を提供できるようなソフトウェアを作り出す枠組みを提供する。
複数の人達の間で情報を共有しそしてグループ内の他の人が何をやっているのかの最新情報が見られるという共同作業 - 個人的でも職業的でも構わない - が Live Mesh の鍵の部分である。そして、その通り、Mac サポートも計画され約束されていて、それも単に漫然と述べられているだけでなく、Live Mesh のプロダクトマネジャーによってブログにきちんと書き込まれている。
Live Mesh は、現存しているサービスやソフトウェアの要素を組み合わせたものであるが、もっとずっと進化したものになる可能性は秘めている。Apple の .Mac 加入サービス (年間 $99.95) を使えば、Tiger 及び Leopard のユーザーは iDisk 経由でデータをシンク出来、一方で Mac OS X がファイルに対する変更、追加、削除のアップデートを自動的に受け持っている。これは複製と同期であるが、Address Book, iCal, そして Yojimbo と言った比較的少数のアプリケーション (殆どは Apple からのもの) での記録レベルのサポートを別にすれば、.Mac のシンクはあまりきめ細かな対応は出来ないし、それに大量のデータを扱う性能も取り分け良いわけではない。
Live Mesh のプレビューを見ると、誰かが Live Mesh につながっている機器の上に特定のフォルダを追加することが出来、その上でこれらのフォルダが他のどの機器上に現れるべきかを管理する事が出来る様子がうかがえる。これらのフォルダは勿論のこと他のユーザーとも共有できる。ここが Live Mesh は .Mac や他のオンラインファイル共有サービスをはるかに超える所で、他のどのユーザーがフォルダにアクセスしているのかをデスクトップ上から見ることが出来る。これは個々のフォルダに付属した一般的な "ニューズフィード" の一部分で、同時に変更や他の情報も見えるようにする、そしてこれはサードパーティによって延長されることも出来る。(私は AFP 経由でフォルダを共有している時、Leopard でももっと優れたコントロールを欲しいとずっと思っていた、その中身は対象のフォルダに誰がどれぐらい長く接続しているかである；これは通常はサーバーの機能に属する。)
このシステムは遠隔デスクトップアクセスも許可する、Timbuktu Pro, GoToMyPC, 或いは、強いて言えば Back to My Mac 風の。Back to My Mac に言及するのに多少戸惑いを感じるのは、TidBITS の読者から聞いている、これを動くようにするのは如何に難しいかに関する話をあまりに多く聞いているからである ("Back to My Mac のための風穴を開ける," 2007-11-07 参照)。
Microsoft はまず Live Mesh の基礎となる技術に対するアクセスを 10,000 のデベロッパーに与えつつある；ユーザーアクセスが実現するのはかなり先になる。Microsoft の多くの他の部門のプロダクトマネジャーや高位の人達は、その紹介の時に Live Mesh は一つのプラットフォームであり、一枚板のサービスではないと言っている。Live Mesh の全ての構成部品がデベロッパーに提供されるはずであり、言葉を変えれば、プログラマーや企業は Live Mesh システムの上に住むソフトウェアを作ることが出来るわけで、必要とする機能を最初から自分で作ることなく統合可能になる。敢えて批判を覚悟で言えば、Live Mesh は標準、良く理解されたプログラム言語 (最近人気の Ruby on Rails も含めて) と合わせて使うことが出来、そして標準経由で、独自プロトコルではない、情報を提供出来ることを指摘しておきたい。Apple の Cocoa プログラミング構造ですら、Live Mesh と相互運用する技術の中に挙げられている。
これは紛れもなく人気を集める考え方で、突然にして、コンピュータサービスと保管庫のクラウドが現れ、その上にデスクトップコンピュータからスマートフォンやその他のハンドヘルドに至る機器上で性能と複雑さを個々の機器に合わせたものにしながら豊かなアプリケーションを構築出来るのである。
Amazon のクラウドコンピューティングサービス - 保存のための S3, オンデマンド仮想マシンの EC2, そして一種のデータベース保管庫である SimpleDB - はこの傾向の一例であろう。先週打ち出された Google App Engine もその一つである。 Adobe AIR ですらこの部類に部分的ではあるが属する、ここでは元をなすデータは何処に保管されているかに関係なくクロスプラットフォームにアクセス出来て、インターフェースは使っている機器に合った表示とすることが出来る。
Live Mesh は、二年前にその地位を引き受けた Microsoft Chief Software Architect Ray Ozzie によって概念から実行まで導かれた最初の大きな取り組みのように見える。Ozzie は、Microsoft のアプリケーションとプラットフォームを生き返らせるために Bill Gates が以前保有していた地位の一つに昇進させられていた；彼は 30年に近いキャリアにわたって最も重要なビジネスと共同作業のソフトウェアの幾つかを作り出し或いは形作るのに携わってきた、Lotus Notes がその代表である。(私は重要なとは言ったが、最も愛されたとは言っていない。)
Ozzie の Microsoft 従業員に対する Live Mesh に関するメモ全文は示唆に富んでいる、なぜならばそこには彼の、そして恐らくは Microsoft の包括的な見方が繰り広げられているからである：Microsoft そしてインターネットの未来は、社会と携帯機器の相互作用のハブとして Web に向かおうとしている所である、そこでは情報は独占的であったり独自仕様のしがらみ無しに色々なやり方で容易にアクセス出来なければならない。
これは Microsoft の新しい日なのであろうか？同社は賭けに出たのは間違いなく、全く新しい聴衆を引き込む可能性のあるプラットフォームを導入してきた、そしてアプリケーションもオペレーティングシステムも何が出来るかが制限されてしまう独自仕様から抜け出せない動きの遅い組織というイメージを払拭しようとしている。Live Mesh は、相互運用性、平易性、そして開放性の開花を示唆している。Microsoft がその約束を実現できるか、或いは Windows と Office と言う稼ぎ頭が Live Mesh の足を引っ張ってしまうことになるのか、興味深く見守りたいと思う。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
トラブルシューティングの導師 Ted Landau の著した“Take Control of Your iPhone”のバージョン 1.1 が出たことをご紹介したい。今回は iPhone 1.1.4 ソフトウェアの情報を入れてアップデートし、あなたが iPhone の良さを最大限に引き出せるための最新のアドバイスを満載している。同期に関係した情報、EDGE と Wi-Fi がいかに相互運用されるか、Maps の最新機能、Mail の設定、iPhone のハッキング、着信メロディの作り方 (と買い方)、バッテリの扱い、その他が盛り込まれた。また、この電子ブックでは問題解決法にもしっかりと焦点があてられているので、もしもあなたの iPhone が変な挙動をし始めても、この本を読めば解決法が見つかる可能性が高い。（この電子ブックの既存のオーナーの方は無料でアップグレードができる。お持ちの PDF を開いて、最初のページの右上にある Check for Updates をクリックして頂きたい。）
この電子ブックの通常価格は $15 だが、2008 年 4 月 29 日までは半額セールをしているので $7.50 で入手できる。オンラインカタログの Lifestyle タブで、iPhone 関係の電子ブックが見つかる。この記事から直接クリックして開けば、必要なクーポンコードが自動的にショッピングカートの最初のスクリーンで適用される。（カタログのタブ付きインターフェイスで違ったタブにある複数個の本を選んでおいて、それから Buy Selected Ebooks ボタンをクリックして一緒にショッピングカートに入れることもできることに注意されたい。）
［訳者注： この号の翻訳が完成した時点で、この半額セールも、下の記事の DealBITS 抽選の応募期間も、どちらも終わってしまっています。翻訳が遅れて申し訳ありません。今後このような事態を減らすためにも、皆さんのお力がぜひとも必要です。どうか、次の記事をご覧になって、翻訳チームにあなたの力をお貸しいただけませんか？］
文： Adam C. Engst <[email protected]>
訳： 細川秀治 <hosoka@ca2.so-net.ne.jp>
もしあなたが英語と日本語（または英語とオランダ語）に堪能なら、我々を助けてください。TidBITS 日本語版とオランダ語版の翻訳チームは僅かの翻訳者で過大な作業をこなしていて、もう少し人手があればこの負荷を分担できます。つまり、これらの翻訳語版を読んでいるそれぞれ数千名の TidBITS 読者に応えて、あなたも翻訳に参加して TidBITS の翻訳チームを助けてください。 日本語版とオランダ語版の翻訳作業の詳細については、それぞれ該当するページに説明があります。また査読や校正、翻訳アドバイスでご協力頂ける方も募集します。ご協力へのささやかな感謝として、翻訳者はすべての Take Control 電子ブックを無料で受け取ることができます。
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
オーストラリア在住の親しい友人たちが最近北アメリカへの旅行のついでに Ithaca に立ち寄ってくれたので、私たちは素晴らしい眺めの渓谷や滝などに連れて行き、彼らはそこで、轟き落ち流れ行く水を次々に写真に撮り続けた。乾燥した地域に住む彼らにとって、これはとても珍しい風景だったのだろう。彼らはこの旅行で既に 10 から 12 ギガバイトもの写真を撮り溜めていたが、まだ四週間も旅行が残っていれば、その終わりにはどんなことになっているかと私には容易に予想がついた。でも、それは新たな問題を生む。将来、彼らがこのたくさんの美しい写真のどれかを見た時に、この風景が Ithaca だったかそれとも Hammondsport か、あるいはこの花のクローズアップ写真はバーモント州 Montpelier で撮ったかそれともアルバータの Jasper で撮ったのだったかを、どうやって思い出せばよいのだろうかと。
そのための一つの解決法が、HoudahGeo を使えばできる。これは Macintosh 用ソフトウェアで、あなたの写真に「ジオコ−ド (geocode)」付けをする、つまり、写真の日付・時刻スタンプと GPS 記録とを照合したり、Google Earth を使って正確な場所を指定したり、HoudahGeo 内蔵の地図を使ったり、写真を GPS のウェイポイントに繋げたり、あるいは手動で座標値を入力したりといった方法で、写真に緯度と経度の情報を添付させることができるのだ。いったん写真にジオコード付けができれば、その情報を使って写真をブラウズしたり特定の写真を探したりできるし、またあなたの写真を直接 Flickr に投稿したり、Google Earth での閲覧用に出版したりもできる。
今週の DealBITS 抽選では、この $40 の HoudahGeo を３本、賞品にする。幸運が足りずに当選から漏れた応募者にももれなく HoudahGeo の割引価格の資格が贈られるので、ぜひ奮って DealBITS ページで応募して頂きたい。寄せられた情報のすべては TidBITS の包括的プライバシー規約の下で扱われる。また、もしもあなたがこの抽選を紹介して下さった方が当選すれば、紹介に対するお礼としてあなたの手にも同じ賞品が届くことになるのもお忘れなく。
［訳注： 応募期間は 11:59 PM PDT, 04-May-2008 まで、つまり日本時間で 5 月 5 日（月曜日）の午後 4 時頃までとなっています。］
文： Glenn Fleishman <[email protected]>
訳： 羽鳥公士郎 <http://www.ousaan.com/mail/>
1994 年にさかのぼるが、私が初めて HTML コードを書いて NCSA Mosaic に表示させることを学んだとき、私は「もっとよい方法があるはずだ」と考えた。そもそも私は、高校の新聞で Mac Plus と PageMaker 1.0 を使ってから 10年近くの写植と DTP の作業から手を引こうとしていた。私は、コードに悩まされるということがなかった。高校では Compugraphic 写植システムのコードを学んだが、これはフォーマット用のタグを埋め込むという、似たような方法を使っていた。しかしそれは 1994 年の話だ。そして実際、HTML のごたごたを上手に包み込むグラフィカルエディタは１つ存在していた。
それなので、14 年にわたってそのようなエディタの数々（FrontPage、PageMill、GoLive、Dreamweaver など多くがあったが、虐殺をくぐり抜けて生き残ったのはわずかだ）が登場したあとでも、ページを構築する好みの方法の最上位がハンドコーディングであるというのは、面白いことだ。The New York Times のデザイン部門責任者 Khoi Vinh は最近、同社ウェブサイトの 読者からよくある質問コーナーに、次のように書いている。「私たちは、Dreamweaver などの wysiwyg（見たとおりのものが得られる）HTML およびCSS オーサリングツールを使うよりも、HomeSite、TextPad、TextMate のようなテキストエディタを使ってすべてを『手打ち』することを好んでいます。この方がよりよい結果をより速く得られると思います。」（ところで、GoLiveは今日付けで抹殺された。）
Vinh はここで Dreamweaver を軽蔑しているのではない。彼が指摘しているのは、私がこの 14 年間、次第にあちこちで見聞きするようになったことだ。すなわち、TidBITS から The New York Times まで、規模の大小にかかわらずほとんどのウェブサイトの基盤となっているテンプレートベースのシステムでは、グラフィカルなツールはうまく機能しない。
ほとんどのウェブサイトは、静的なページから構築されているのではなく、ウィジェットやサーバサイドスクリプト、IFrame（ほかのサーバから引っぱってきたコンテンツを埋め込む）、そしてコンテンツ管理システム（CMS）に組み込まれた情報を挿入するためのプレースホルダの集まりだ。これらは１つ１つがきわめて特異的であることが多い。商用システムとして購入した場合ですら、しばしばカスタマイズされているため、グラフィカルなウェブツールでは適切に編集やプレビューができないことがある。
このようなシステムでは、テンプレートによって、特定のリクエストがあったときにどのようなページを構築するかを定義している。たとえば、あなたがdb.tidbits.com に対し "/article/9569" を要求したとして、それは articleディレクトリの中にある静的ページではない。私たちのシステムはそのリクエストを解析し、9569 番の記事を GetBITS せよというクエリにする。そしてデータベースのいくつかのテーブルからデータを引っぱり出して、その結果をテンプレートに放り込む。テンプレートはさらに、広告や TidBITS Talk での議論へのリンクなどのさまざまな動的要素を照会し、それらが挿入される。それがウェブページとしてあなたに届けられるわけだ。
この種のハンドコーディングは、１つ１つの HTML ページを手で書くというのとは必ずしも同じでない。それはむしろ、彫刻や機械の部品といったものの原型を手で作るのに似ている。つまり、何かを大量生産するための指示だ。原型にわずかな欠陥があれば、すべての複製が台無しになる。
私たちが TidBITS の裏側に CMS を構築したのは、コンテンツの流れを管理しやすくし、私たちが少なくとも以前よりは迅速に動けるようにするためだ。長年の読者であれば、私たちが以前よりも多くのコンテンツを定常的に生み出していることに気がついているだろう。CMS によって以前の膨大な作業が簡素化されたためだ。（私たちは TidBITS Publishing System をさらに簡素化し拡張するための作業を続けている。ブログ投稿システムを改善し、翻訳版記事を増やし、短い項目を効率的に表示し、その他の改善をしたいと思っている。2007-09-10 の "近代的な TidBITS ウェブサイトをデザイン" 参照）。
1990 年代の終わりには、私はスクリプトを使って、自家製のテンプレートで数千の静的ページをはきだしてページを構築していた。しかし同時に、数百のページがあるサイトでデザイナーたちとも仕事をしており、そこでは GoLiveや FrontPage、Dreamweaver が繰り返し現れる要素を管理していた。テンプレートへの移行は、実際に使い物になるコンテンツ管理システムの出現と時を同じくしている。コンテンツは１か所に格納され整列されるので、記事を更新してさまざまな場所に異なった仕方で公開するのがすばやくできる。ホームページではヘッドラインが更新され、記事のメインページが変更され、記事の宣伝文が別の場所に現れ、そのあいだに RSS フィードが同期される。
大規模なサイトのデザイナーが手打ちに慣れるにつれ、グラフィカルツールは、初心者であっても見栄えのよいサイトを比較的少ない労力でデザインし公開できるように改善されてきた。私は Apple の iWeb の最新リリースにはかなり感心した。旧バージョンにあった多くの悪いコードや悪いアイディアを切り捨て、合格点以上のクロスプラットフォームな HTML と JavaScript を生成するようだ。同様に、私は Easy WebContent というオンライン専用のエディタを試したが、これはウェブベースのエディタとしては驚くほど強力なツールだ。（私は PC World で Easy WebContent をレビューしたが、これはプラットフォームを選ばない。）
そして Dreamweaver は、先ほど述べたように、軽蔑すべきものではない。CS3リリースは、私が使ったことのある中でもっとも簡単に使えるバージョンだ。私は、個人サイト glennf.com を Dreamweaver で管理し、その制御能力には完全に満足している。
HTML のような、当初から敷居が高い、つまり正しく表示されるようにコードを書く方法を知るためには構造化テキストやプログラミングの理解が要求される表示用言語に、今ではそれと異なるが似た敷居が加わったというのは、ちょっと反語的だ。常に変化し増大するコンテンツを伴う、リッチで複雑なサイトを構築するには、ほぼ間違いなく、ボンネットの下に潜りこんで、何らかのテンプレートシステムで指を汚さざるを得ないのである。
文： Rich Mogull
<[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
最近出た QuickTime 7.4.5 リリースで、Apple はただ単にいくつかの脆弱性を（正確に言えば 11 個だが）パッチしただけではなかった。QuickTime 7.4.5_. According to a eWeek の報道によれば、このアップデートには Mac OS X 用と Windows Vista 用ともに一連の改善が盛り込まれて、QuickTime に根本的なセキュリティの改善がなされ、アタッカーたちによる脆弱性の攻撃をより困難なものにするようになっているとのことだ。これらがどうしてそれほど重大なニュースなのかを理解するために、ここではまず、悪い連中がコンピュータをどうやって攻撃するのか、また QuickTime をセキュアのものにするのがどうして特別困難なことなのかについて、少しだけ復習しておこう。
Leopard のセキュリティのプレビュー記事（2007-10-22 の記事“Leopard はあなたのセキュリティをどう改善するか”参照）で私が議論した通り、「バッファオーバーフロー」と呼ばれる種類のソフトウェアのバグがあって、これがアタッカーたちの格好のターゲットとなる。バッファオーバーフローは、予期されるより多くのデータを入力する攻撃によって生じる脆弱性だ。もしもそのソフトウェアを書いたプログラマーがその入力フィールドにデータ量の上限を指定しておくのを忘れれば、データが予期された量を超えて流れ込み、メモリの他の部分を上書きしてしまうことがあり得る。私たちの使うコンピュータの大多数では、メモリというのは単にたくさんのコマンドとデータとを積み重ねた巨大なスタックに過ぎないので、もしもどれだけのデータを入力すればそうなるかを厳密に知っていれば、そのコンピュータが正当な指令として期待している場所に悪意ある指令を書き込むことで、そのコンピュータを騙して任意のコマンドを実行させることが可能になってしまう。これが正確に実行されれば、アタッカーがあなたのコンピュータのコントロールを完全に掌握してしまうことにもなる。
QuickTime は、多くのメディアプレイヤーと同様、この種の脆弱性に悩まされる運命にある。それは、それが作られているやり方に内在するとともに、このソフトウェアに期待される特殊な需要、すなわち何十ものフォーマットによるリアルアイムのオーディオやビデオを扱わなければならないという性格によるものだ。
あなたが QuickTime をインストールする際、そこには Java でプログラムされた拡張が含まれる。Java は、ハイレベルのプログラミング言語だ。それと反対にローレベルのプログラミング言語、例えば C のようなものは、メモリや CPU の処理をプログラマーがほぼ直接に扱うことを要求する。私たちが使うソフトウェアのほとんどすべてで、たとえそれが他のプログラミング言語で書かれていたとしても、その基盤にはいつも C がある。けれども C はプログラムを組むのもデバッグするのも難しいことで有名だ。例えて言えば、手工具だけを使って家を建てるようなものだ。時には、自分自身のツーバイフォーを彫り出さなければならないこともある。これに対して、Java のようなハイレベルのプログラミング言語では、メモリ管理のような面倒な仕事の多くをプログラマーの手から取り去ってくれるので、作業がずっと楽になる。また、Java が特に興味深いのは、プログラマーが一度ソフトウェアを書けば、Java をサポートするどんなオペレーションシステムにでも持って行って走らせられる点だ。現実にはそこまで単純には行かないが、大まかに言えばあなたが Java プログラムを Mac OS X で書けば、それを Windows や Linux で走るようにするのもそれほど大した手間ではない。
Java ではプログラマーたちが直接あなたのコンピュータのメモリを扱うことがないので、バッファオーバーフローの脆弱性にはほぼ無関係と言ってよい。理論的には、そのためこれらの Java 拡張は非常にセキュアなものということになる。けれども問題は、オーディオやビデオのように高パフォーマンスを真の意味で要求するようなものに対し Java はあまり適していないということだ。従って結局、それらの部分については C に立ち戻ってしまうことになる。QuickTime の場合、メインのプログラムも、またあなたのコンピュータでこのようなメディアファイルをプレイするためのいろいろなプラグインも、すべて C のコードで書かれているため、これらがバッファオーバーフローのターゲットとなる可能性が生まれてしまう。さらに悪いことには、サイズの大きなメディアファイルを扱うことの複雑性もバッファオーバーフローの確率をさらに高くする。未知のサイズのビデオを相手にしなければならないプログラマーにとって、これはテキスト入力フィールドに最大 140 文字の上限を簡単に定められるのとはわけが違うのだ。
QuickTime の動作方法はこうだ。まずメインのコードがオーディオとビデオを処理し、それからそれをプラグイン（codec と呼ばれることも多いが、これは“compressor-decompressor”の略だ）に送る。プラグインはそのファイルフォーマットを知っていて、ファイル内容の 0 と 1 の羅列をサラウンド・サウンド付きの高精細ビデオに変換する。QuickTime がこれらのデータすべてを検証するのは困難だし、またプログラム自体の各部分の間でものごとを受け渡しする処理のプロセスは非常に複雑なものだ。その上さらに、この Java 拡張の部分が、さらにもう１レイヤーの複雑度を重ねるだけでなく、ほぼ常時アタッカーに手を触れさせる入り口ともなり、また普通ならばウェブブラウザを通じてアクセスすることはできない QuickTime プログラムの一部分を人目にさらす働きもする。その結果、アタッカーたちがこの余分の露出と、これら C 言語でプログラミングされた各部分やプラグインたちとの間の複雑なハンドオフ制御に、巧みに便乗してしまうことになる。
実際、QuickTime におけるセキュリティ脆弱性の原因の上位三位のうち一つがこれらの Java 拡張だ。その次の大きな原因は、たくさんある異なったタイプのメディアファイルをたくさんある異なった codec を使って処理する部分だ。アタッカーたちは悪意あるオーディオまたはビデオファイルを作って、それがプレイヤーをクラッシュさせてバッファオーバーフローを生むようにする。あともう一つの問題も、これらさまざまのメディアタイプをサポートしなければならないことに関係している。アタッカーたちは、QuickTime が最初にそのファイルがどんな種類のものでどの codec を使うべきかを判断する働きをする部分で脆弱性を攻撃しようとするのだ。彼らはファイルのヘッダに修正を加えて、ファイルのコンテンツが codec に送られるよりも前に QuickTime を攻撃する。こうして、QuickTime をセキュアにするのが困難なのは、これがあらゆるメディアファイルに対処できるオールマイティの働きをしなければならないからであり、また複数種類のプログラミング言語を使うように書かれているからでもある。QuickTime の本体も、Java 拡張も、私たちが送りつけたデータがどんな種類のものなのかを確実に知ることは不可能で、また実際の処理にはデータをプログラムの C 部分に送り込んでやる必要がある。こうした相互作用はどこか途中で、さらに言えば異なる二つの部分が互いにデータのやり取りをする部分で、バッファオーバーフローが起こる可能性を増やしてしまう。QuickTime はまた、新たなメディアタイプのためにサードパーティのプラグインを成り行き任せでサポートすることもしているが、そのようなプラグインを保護する方法はない。
バッファオーバーフローの攻撃を成功させる確率を減らす一つの方法は、ソフトウェアがメモリと相互作用する方法に保護を加えることだ。これこそ、私たちが「アンチ攻撃テクノロジー」と呼ぶものだ。たとえそのソフトウェアがバッファオーバーフローの脆弱性を持っていたとしても、アタッカーがそれを利用してシステムへの攻撃を成功させることを難しくするのがこのテクノロジーだ。
その実例の一つが、Windows Vista で用いられている Address Space Layout Randomization (ASLR) テクニックだ。アタッカーがバッファをオーバーフローさせた後でシステムに何か特定のことができるためには、メモリの中にあるオペレーションシステムのコマンドを彼らが挿入した指示に「向ける」必要がある。Vista は、これらのコマンドをそれらが走る度に毎回ランダムな位置に移動させるので、アタッカーがどこを向くべきかをあらかじめ知ることは決してできない。今回の QuickTime 7.4.5 で、Apple は QuickTime に ASLR のサポートを加え、QuickTime コマンドの多くについて、同じくそれらが走る度にその位置を移動させるようにした。これで、アタッカーが好きな QuickTime コマンドに指示を振り向けてそれを利用してコンピュータの乗っ取りを計ることが難しくなっている。Apple はこれを QuickTime のすべてのコマンドには適用しなかったので、QuickTime はまだ少し脆弱だが、それでも大きな前進の一歩だとは言える。
Apple は Mac OS X 10.5 Leopard に独自のバージョンの ASLR を含めたが、それは Vista のものとはちょっと違った動作のしかたをする。これは Library Randomization と呼ばれ、すべてのコアシステムコマンドを再配列するわけではなく、特にダイナミックリンカーと呼ばれるものを定位置に残しているので、これがまだアタッカーが Mac を攻撃するのに使われる可能性がある。今後のアップデートで Apple がこの点を修正してくれることを望みたい。
Apple はまた、Mac OS X 用の QuickTime を他の二つの方法、すなわちスタック保護とデータ実行保護によってメモリを保護することでも拡張し、バッファオーバーフローが成功するのを防ごうとしている。
特に、スタック保護はメモリのスタック部分に対して攻撃可能なバッファオーバーフローが起こる可能性を完璧に防いだものと言えるかもしれない。たとえアタッカーがスタックをオーバーフローさせたとしても（スタックにはユーザーの入力したものとプログラミングコマンドの大部分が格納されている）スタック保護がそれを探知して、アタッカーによるコマンドが働くのを食い止める。それでもまだメモリのもう一つのカテゴリー、ヒープと呼ばれるものが丸々残っていて、こちらはまだ脆弱だが、ヒープの脆弱性を攻撃するのはスタックの脆弱性を攻撃するよりもずっと困難であると考えられている。
データ実行保護の方は、Intel CPU の持つ特殊なハードウェア設定を利用する。（従ってこちらは Intel ベースの Mac でしか動作しない。）これを使えばプログラマーがメモリ位置を指定してそこにはデータのみしか置けず、コマンドとしては決して実行されないように設定でき、従ってこれもバッファオーバーフロー攻撃をくじくための別の防衛手段となる。
QuickTime において常に問題を生む可能性を残す分野の一つが、新たなメディアタイプに対処するためのサードパーティのプラグインだ。これらのプラグインは Apple が書いたり配布したりしているわけではないので、それらのプラグインのプログラマーたちが Apple のエンジニアたちと同じ予防措置を採っている保証はない。これも、あなたがサードパーティのプラグインをインストールする際に注意しなければならない理由の一つだ。
ASLR を追加し、スタック保護とデータ実行保護を加えたからといって、これで QuickTime がアタックに対し完全に免疫を持ったわけではない。バッファオーバーフローは単に脆弱性の一形態に過ぎないし、Apple がこれであらゆる攻撃の道を閉ざしたわけでもない。実際、この記事を出すほんの少し前、Windows Vista で走る QuickTime が ゼロデイ攻撃を受けたという記事が eWeek に載った。
そうは言っても、これら三種類の変更の組み合わせによって、実際的なセキュリティの利点に関する素晴らしい最初の一歩が、すべての QuickTime ユーザーたち、すなわちほとんどすべての Mac ユーザーたち（とますます増え続ける Windows ユーザーたち）のために踏み出されたのは事実だ。Apple がこれらのステップを QuickTime に組み込んでくれた今、Apple にはさらにもっと努力を積み重ねて、同様のテクノロジーを Mac OS X 全般にも拡張することを目指してもらわねばならない。
文： Charles Maurer
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
私がフランス語をしゃべるところを聞いたことがある人でも、私にはそれよりももっと下手なことがあると知ったら驚くだろう。それが何かというと、書類のファイリングだ。適切なしまい場所がはっきりしている場合は、たいてい私はいずれ書類をその場所に置くことができる。けれども、どうも私は頭がぼんやりしていることが多いようで、しまい場所がはっきりしていると思うことはめったにない。例えば、今私の目の前にカラーオルガンについての記事がある。19 世紀のオルガンで、音楽を演奏しながら色を投影したというものだ。でも、この記事は何に分類すべきだろうか？ 音楽、楽器、オルガン、カラー、映像、それとも共感覚（感覚の混和）か？
これまで、この難問に対する私の解決法は、書類をどこでもそれを読み終えた場所に置きっぱなしにして、私の妻が乱雑な状態に耐え切れなくなって何もかも一緒くたに箱に放り込むまで放っておく、というものだった。書類を探すには... いや、もしもそれがまだあたりに置いたままになっていて私がそれを読みながらお菓子を食べていたのなら、愛犬に頼んで食べかすを嗅ぎ分けてもらうこともできただろうが、たいていの場合私にできることは、何か他のものを探している間に偶然その書類が見つかるのをあてにするしかなかった。でも、つい最近の何年間かに、私はやっと実用にかなった方法を思いつくことができたと思う。今では、私はすべてを自分のコンピュータの中の“papers”と名付けたフォルダに保存して、(Tiger では) CTM Development の FoxTrot か (Leopard では) Spotlight を使ってその内容を検索するようにしている。
けれども、写真はまた別の話だ。画像を索引付けすることはできない。写真を内容で検索できるためには、(1) 内容を言葉で記述しておいてから (2) その説明を画像に添付しておくことが必要になる。これら二つの必要条件が、いずれも言うほど簡単ではないことを私は体験から学んだ。
写真の内容を記述する -- キーワードを使えば、簡単に写真が検索できるということになっている。コンピュータはたくさんのキーワードを扱えるので、十分たくさんのキーワードを与えておきさえすれば何でもきっと見つかるのだろう。けれども残念なことに、どんな写真にも私は非現実的とも言える数の記述語を思いつくことができ、全部を含めるわけにはいかないので数を減らそうと思ってもどれを外せばよいのか決断できたためしがない。一例を挙げれば、この写真で私が思いついたキーワードはこんな感じだ：
職人、熟練工、建築業者、大工、木挽き、骨組み、木組み職人、のこぎり、木挽きのこぎり、弓形のこぎり、胴付きのこぎり、仕事場、安全、作業環境の安全、建築、家屋建築、住宅、建設、住宅建設、産業写真、肖像写真、産業肖像写真、旅行写真、撮影旅行、モンスーン、雲、モンスーン雲、曇り、素足、田舎、中国、雲南省、中国の田舎、雲南省の田舎
キーワードを選ぶための良い方法を見つけたいという願いをこめて、私は当時アリゾナ大学の Center for Creative Photography に在籍していたプロの写真カタログ専門家の Marcia Tiede に相談してみた。Tiede が私に言ったのは、もしも私が職人の写真を識別したいと思うなら、キーワードは“workman”でなく複数形の“workmen”として入力すべきだ、ということだった。私が上の例で挙げた他の 16 のキーワードも、同じく複数形の tradesmen, builders, carpenters, sawyers などとすべきだ。けれども彼女はそれ以上私の作業をすっきりとさせられるような助言はしてくれなかった。彼女はまたあと五つのキーワードを提案した： 男、労働者、職業、道具、ツール (men, labourers, occupations, equipment, tools) だ。
Tiede は、記述語の選び方に標準のものは何もないと説明を続けた。The U.S. Library of Congress（米国議会図書館）が二部から成る Thesaurus of Graphic Materials（グラフィック素材の専門用語集）を出版していて、米国内のいくつかの図書館ではこれを事実上の標準として使っているが、これは絶えず変更され続けているものなので昨日や明日に使われた用語が今日もそうである保証はない。それに、この用語集は膨大だ。830 ページあってまだ増え続けている。他方、これだけ大きいにもかかわらず、Tiede はここにはまだまだ適切な記述語で欠けたものがあるという。もしも私がこの用語集に準拠するとしたら、さきほどの写真のキーワードリストは次のようになっていただろう：
大工、のこぎり、横引きのこぎり、のこぎり木工、安全、危険、建築、住宅、木造建築、建設業、肖像写真、旅行、道具、ツール、男、労働者、職業、道具、ツール
私は長い時間をかけて用語集からこれだけの単語のリストを抽出した。Tiede は写真のカタログ分けの仕事をもう何十年も毎日続けているので、彼女がすればこの作業はもっと能率的だ。それでも、彼女が言うにはその作業に写真１枚あたりおよそ５分かかる、「それより短いことが多いけれどもっとかかることもある」という。写真を言葉で記述するのはこれほどに時間のかかる作業なので、多くの博物館の管理者たちは wiki のようなシステムを使って 公衆の力で形成されるカタログを開発しようと試みているくらいだ。そして、どうやらトム・ソーヤーが生きてカリフォルニアに住んでいるらしいが、Google Image Labeler は、キーワード作成作業を ゲームの形にすることで一般大衆を誘導して Google の索引にある写真の識別をさせようと試みている。
私は Tiede と話をしながら、特定の限定された状況ならばキーワードによる索引付けも有用だろうが、それでもたいていの場合にはキーワードの選択が限られた、行き当たりばったりのものにならざるを得ないために検索がキーワードを全く使わない場合とそう変わらないものになるのではないか、と不意に思った。その代わりとして、もっと豊かに叙述的な説明文を付けるようにすれば、きっともっと滑らかに言葉の流れが頭の中から紡ぎ出されるのではないかと考えたのだ。Tiede もこれに賛成してくれた。実際いくつかの図書館のグループでこれが試みられていて、多くの場合その上にはウェブ (World Wide Web) の拡張として Semantic Web と呼ばれているものの構成要素である構文マーカー (syntactical markers) も追加されている、と彼女は教えてくれた。
写真と記述をリンクさせる -- そういう情報を写真に添付しようとする段階で、さらにいろいろな問題が起こる。カメラによって供給される EXIF 情報は、その標準を定める組織がどこにもなく、カメラのメーカーがその場その場で選んで使っている慣習に過ぎない。また、画像ファイルの内部にテキストによるメタデータを保存するための IPTC (International Press Telecommunications Council) 標準は年々進化を続けている。実際、その最新バージョンは拡張可能、つまり今後の変更を許すものとなっている。こうしていろいろな標準や慣習があまりにも無秩序な状態になっているので、すべてのアプリケーションが同じフィールドを認識できるわけでもなく、また同じフィールドに異なったアプリケーションでは異なったラベルが付くこともある。アプリケーションによってはあなたが自分でフィールドを定義できるようになっているためこの混乱になおさら輪がかかる。そういうフィールドは他のアプリケーションが認識できるフォーマットかもしれないし、そうでないかもしれない。それからもう一つ、画像のメタデータを読んだり編集したりできるためには、そのアプリケーションが画像ファイルを丸ごと読んだり保存したりする必要がある。1 キロバイトの変更のために 100 メガバイトを保存しなければならないということだ。
（サイズの小さな写真、例えば 1 MB 程度のものならば、その写真は JPEG として圧縮されているだろう。この圧縮法は情報を失うので、本格的な写真家ならば通常写真を非圧縮のフォーマットで保存しておき、それをウェブに置いたり電子メールで送ったりする時にだけ JPEG に変換することが多い。非圧縮の写真は何十メガバイトという単位のものになる。Photoshop で作業する時は、写真を別のレイヤーに複製してその上で作業をし、さらにそのプロセスを何回も繰り返すことが普通なので、最終的な画像が数百メガバイトになることも珍しくない。）
写真のうちいくつかを示すために、どんなアプリケーションでもそれらオリジナルを小さくしたバージョンを表示して、それらに付随したメタデータがあればすべて見られるようにする必要がある。そのための方法はほんの数えるほどしかないが、それぞれに短所を持っている：
1. 必要となる度にすべての情報をディスクから読み込んで、小さなプレビュー画像も必要に応じてその都度生成する方法。非圧縮の写真を扱う時にはこの方法はあまりにも時間がかかるので、頻繁に変更を受けるフォルダ、例えばメモりカードの内容などをカタログ化するような場合以外は現実的でない。
2. 最初に必要とされた際にプレビュー画像を生成し、その小さな画像とメタデータをキャッシュに保存する方法。多くの写真がある場合にはさきほどの方法よりもうまく働くが、数が多くなってくると扱いにくくなる。
3. まずプレビュー画像を生成してから、そのプレビューとメタデータとを永続的な、効率の良いデータベースに保存する方法。この方法はどんなに数多くの写真でも扱えるが、そのデータベースとオリジナルの写真ファイルのどちらかが少しでも変更を受ける度にきちんと同期させておかなければならない。この種の同期化には間違いが起こることが多く、混乱に陥ったり仕事の成果を失ったりすることもある。
4. まずプレビュー画像を生成してから、そのプレビューとメタデータとを永続的な、効率の良いデータベースに保存し、さらにオリジナルの画像もそこに移動するという方法。この方法ならば間違った同期によるダメージを予防することができるが、長い目で見ればマイナスの面もある。デジタル写真を取り巻くテクノロジーはすべて日々急速な進化を続けており、それらを保存すべきデータベースもその例外ではない。数年もすれば、きっとあなたは今とは違った方法で写真を保存したいと思うようになり、今のデータベースから書き出しをしたいと思うだろう。けれども、データベースからテキストを書き出すのと、データベースから 100 MB の画像ファイルを書き出すのとはわけが違う。非常に多数あるならばなおさらだ。それにかかる時間と、必要なドライブ容量とは、容易に確保できるものではないかもしれない。
シンプルなツール -- 写真の整理のために私が個人的に採用している方法は、私が書類のファイリングでしているのと同じくらい行き当たりばったりの方法だ。私は写真にいちいちラベルを付けられるほど自己修練を積んでいないが、大切に思う写真については、それを撮影した旅行の名前、あるいは写真の題材の名前などの付いたフォルダに入れておくように心がけている。そういう写真を見つけ出すには、それらのフォルダを調べて、そこにあるサムネイル画像や小さなプレビューなどを隅から隅まで高速で一覧する。この作業のためにはほとんど Finder だけで十分だ。ただし、Finder はプレビュー画像を必要とする度にいちいち新たに描画し直す。私たちのコンピュータでは 100 MB の画像で Finder がプレビューを表示するのにたいてい 6 秒から 7 秒かかる。（これは 2 GHz デュアルプロセッサで 8 GB の RAM を持つ Power Mac G5 でも、2 GB の RAM を持つデュアルコアの Intel ベース iMac でも同じことだ。）あまりにも時間がかかり過ぎるので、大きな画像のたくさん入ったフォルダを隅から隅まで調べるためにはこの方法は実用的でない。
その次のステップは、Creative Suite 3 にも Photoshop Elements 6 にも含まれているAdobe Bridge だ。Bridge は、プレビューを作ってそれらをキャッシュする。これは旧バージョンの Elements におけるプレビューモードや、 GraphicConverter のブラウザモードと、ほぼ同等のものを提供する。私は Adobe Bridge を持っているのでしばらくこれを試してみた。確かに Finder でするよりはましだけれど、それでもまだまだのろのろし過ぎていると思った。それに、私がよく編集を必要とする一行のテキスト、つまり私がその写真を撮った日時の記録の編集ができないのだ。私はタイムゾーンを越える度にいちいちカメラの中でこの情報を変更することなどまず忘れてしまう。それに、カメラの日付設定を間違えたり、違う年に設定してしまったことも何度かある。だから、画像ファイルの中で日付や時刻を変更したいと思うことはよくあるのだ。
Aperture と iPhoto -- この時点で、私は Apple の Aperture を試してみることに決めた。これは iPhoto の兄貴分にあたり、上級のアマチュアやプロを対象にしたものだ。Aperture は写真の識別・選択・処理について iPhoto よりもずっと多くのツールを提供しているが、iPhoto '08 になって変更が施され、内部の動作としては Aperture と似た働きをするようになった。だから私が Aperture に関して以下に書くことは特に断わりのない限り iPhoto にも当てはまる。
Aperture は独自のデータベースを生成し、オリジナルの写真を独自仕様のデータ構造の中に読み込んでから、素早いプレビューのためにそれぞれの写真のコピーを生成する。このやり方はさきほども書いたように長所と短所を持っている。さしあたりの高速性と安全とを提供する代わりに、あなたが将来違った方法で写真を保存したいと思う日が来たならば（いや、その可能性は高いので、そう思う日が来た時には、と言うべきだろう）長い目で見たマイナスの面を持つ。けれども、説明のテキストをメタデータとして含めてあったファイルを読み込ませようとしてみた時、私は情報の一部だけしか含まれておらず、私の書いた説明文やキーワードがそこにはないことに気付かされた。Aperture は、すべてのメタデータを写真とは別途に保存し、メタデータの埋め込みは写真を書き出しする際にしか行なわないのだ。
写真の保存以外に、Aperture は写真の編集もできる。Aperture の編集ツールは iPhoto のものよりもずっと数も多く高度なものだが、それでもまだまだ不十分だ。Apple がつい最近発表したサードパーティのプラグインを加える機能を使ってこれらのツールを補完することが、絶対に不可欠だと思う。けれども、それをした上でもまだ大きく欠けた所が残る。例えば、遠近法の調整ができないし、歪みを修正したり、（Photoshop の smart sharpening control のように）光学的な輪郭のぼけを低減したりすることもできない。（2007-09-07 の記事“Aperture 2.1 が写真編集のためのプラグイン導入”参照。）また、Aperture では画像の一部分だけを選択して Aperture またはプラグインにその部分だけを修正させるということもできない。
Aperture の編集ツールにはまた長い目で見たマイナスの面もある。外部のエディタで、あるいはプラグインを使って写真を編集する際、Aperture はまずその写真の複製を作り、その複製の方を変更のために送り出す。けれども Aperture 内蔵の編集ツールはこれと違った動作をする。これらのツールはオリジナルの画像を変更するのではない。これらは単に数学的な命令を出すのみで、それらはスクリーン上に描いたり、印刷したり、あるいはファイルに書き出したりする際に初めて適用される。これらの数学的な命令は、確かにディスク容量をほんの少ししか要しないし、いつでも変更したり順序を入れ替えたりできる。けれども、もしも Apple が将来の Aperture リリースでこのアルゴリズムを変更することがあれば、あなたが苦労して修正を加えてきた写真がすべて一挙に変えられてしまうだろう。もちろん Apple はこのことに気付いていて、電話による会見の中で、一人の製品マネージャが Adam と私に対して Apple は将来にわたって常にオリジナルのコードを残しておき、ユーザーたちの写真が変わらずに残ることを保証すると言ってくれた。けれども、時代遅れとなったコードを会社が保持することに関して「常に」という言葉はあまりにも長い時間を意味する。あなたが自分の写真に対する編集を永続的に残しておきたいと思うならば、それをプラグインまたは外部エディタで開いてからファイルのコピーを作るか、あるいは画像の書き出しをしておくかする必要がある。
Aperture はすべての画像の最後の状態を JPEG で表示し、キーワードをその JPEG に付随させる。こうすることで、もしもあなたが Aperture を通じて写真にアクセスできなくなったとしても、それでもあなたはまだ写真をラベル付きで、編集を施された状態で Aperture のデータパッケージの中から掘り出して見ることができるわけだ。（パッケージというのは、一見ファイルのように見えるフォルダで、Finder の中でそれを選んで Control-クリックし、そこで現われるコンテクストメニューから パッケージの内容を表示 を選べば普通のフォルダと同じように開けるようになる。）そうやって見られるのは JPEG のみで、 TIFF や raw 画像が見られるわけではないが、少なくともあなたは何らかのフォーマットですべての写真とそのメタデータを手にすることができる。（iPhoto も同様の JPEG をその iPhoto Library パッケージの中に保管するが、そこにはメタデータが何も添付されないので、もしも iPhoto データベースへのアクセスがもしも失われてしまえば、あなたのキーワードはすべて消え去ることになる。ただし、以前のバージョンとは違い、iPhoto '08 で画像を書き出しすればそこには写真のキーワードが添付される。）
Aperture のユーザーインターフェイスは現行バージョンでぐっと改善され、大部分のアイコンやコントロールにはっきりとした英語でラベルが付いたが、それでもまだ判読できない絵文字が二十ほど使われている。これらはアイコンと呼ぶべきかもしれないが、とうていそれぞれの意味を表わしたものとは言えない。私はこれらの意味を捉えるのが難しいと思うし、机の向こう側にあるモニタ上では判読するのさえ難しいと思う。その上、それぞれを説明するツールチップは Apple 標準の黄色地に黒文字ではなくて黒字に白文字なので、読めたものではない。書物が白い紙に黒のインクで印刷されているのは偶然ではないし、ワードプロセッサで白地に黒文字がその反転ビデオに勝利したのもちゃんと理由があってのことだ。光学的その他の理由によって、白地に黒文字の方が黒字に白よりも読みやすいのだ。Apple が黒字に白い文字を使っているのは、愚かにもファッション（流行）をファンクション（機能）に優先させているに過ぎない。
Apple は写真の表示の背景を選択できるようにしている。選択肢は黒から白までで、デフォルトは中くらいのグレイだ。一番目に優しいのはグレイで、写真が一番良く見えるのは黒だが、写真がプリントされた時にどう見えるかを一番忠実に示してくれるのは白だ。Aperture の第一の目的はプリントに先立って写真を仕分けることなのだから、私は本当は背景を白にしたいのだが、でもそうはできない。Aperture でそれが実用的でない理由は、選択されたものを示すために Aperture は写真を白い枠で囲み、コントラストのある階調やカラーを使ってくれないからだ。
Apple のインターフェイス・ガイドラインによればメニューに訳の分からない単語を並べるのは避けるべきだとなっているが、Aperture には Show Inspector HUD、Show Keywords HUD、Show Lift & Stamp HUD といったものが並んでいる。この“HUD”は“heads-up display”(警告表示) の略で、これはフローティングウィンドウを意味する Apple の新しい用語だ。これらのフローティングウィンドウはそれぞれ黒の背景に小さな白い文字を表示するので、読むのも難しいし、使っていてイライラする。
ユーザーインターフェイスにそういう問題があるものの、Aperture 2 は従来のバージョンに比べて大きく進歩している。他の点では、いまや優秀なアプリケーションになったと言えるだろう。けれども、インターフェイスがどうであろうと、これは私の使いたいアプリケーションではない。私は、自分のメタデータがオリジナルの写真とともに保存されていて欲しいし、コンピュータの世界が変わって行くのをあまりにも多く目にしてきたので、私の写真がベクターベースのエディタに縛り付けられるのは嫌だ。たとえ、そのエディタに私の望むことすべてができたとしても。
Expression Media と Extensis Portfolio -- そこで、私は他の写真管理用ソフトウェアを見てみることにした。見つかったものはすべて試してみたが、その主なものを挙げれば Extensis Portfolio 、Microsoft Expression Media (前身は iView MediaPro)、Adobe Photoshop Lightroom、 MediaDex (Canto Cumulus のシングルユーザ版)、それに QPictがある。中でも最初の二つ、Portfolio と Expression Media はじっくり見てみる価値があると思った。この二つはいずれも、私がさきほど挙げた三番目の構造を使用している。つまり、テキスト情報とプレビューとを構造化されたデータベースの中に保持し、そのデータベースとオリジナルのファイルの間で同期をとるのだ。いずれも動作は素早く、同期も相当程度信頼できて、堅牢性もかなりある。また、Expression Media の方は写真の編集もできるが、その編集ツールは初歩的なものだけだ。
これら二つのパッケージのうちどちらがより望ましいかと言われれば、それは Expression Media の方だと言うべきだろう。実際、ほぼ理想的と言っても差し支えない。ここには私が欲しいと思うような機能が事実上すべて揃っており、また現在ベータ版の段階にある次期バージョンでは欠けている一つ、階層的キーワードも備わる。もしも私がキーワードを定義するとしたら、そのうちいくつかはカテゴリーに分けられるだろうし、階層的な表示があればより簡単に見つけられるようになるだろう：
フォーマット: 縦長 横長 正方形
肖像写真: 友人 親戚 個人的 仕事上
Aperture も階層的キーワードを提供するし、iPhoto は Keyword Manager を通じてそれができるが、Portfolio ではできない。また Portfolio ではその他の面でも付加的機能は少ないと言える。
けれども、確かに Expression Media には機能が充実しているが、私はこの製品に我慢がならない。すべてはそのユーザーインターフェイスのせいだ。私はすべてのコマンドごとにいちいちマウスでメニューを辿ってまわるのは嫌いだし、キーボードショートカットもそれほどたくさんは覚えていられない。だから、たいていの場合私はツールバーを使いたくなる。それなのに Expression Media のツールバーはほとんど使い物にならないしろものなのだ。意味のあるアイコンの代わりに、そこには判読不能な象形文字が並んでいる。これらの象形文字には英語のラベルなど付いていないし、互いを区別する助けになるカラーなどもない。その上、これらの象形文字のうち半数は私が絶対に使いもしないようなコマンドのためのものなので、ただただ混乱を引き起こすためにあるようなものだ。ツールバーをカスタマイズしてそれらを取り除くこともできない。象形文字の意味を知る方法はただ一つ、ポップアップするツールチップだけだ。ということは、どこから見ても、このツールバーはその項目の一つ一つの内容を表示するのに毎回一秒の遅延時間を要する、出来の悪いメニューとしてしか機能していないわけだ。私はいくつかのキーボードショートカットを変更して自分が覚えやすいものにしようと試みたが、どうやっても変わってくれないメニュー項目もあったし、また一つのコマンドにショートカットを追加しても別のコマンドからショートカットが削除されることはなかった。
Expression Media の前身である iView MediaPro は、そのツールバーがより良いものであったこと以外は現バージョンの Expression Media と同一だった。iView のツールバーの象形文字にはカラーが付いていて、それらの間にいくつか意味の分かるアイコンがちりばめられていた。そのお陰で iView のツールバーはちゃんと使えたし、ツールバーが使い物になったお陰で iView は製品として使えた。私は喜んでこれを使っていたし、もしも Microsoft がこれを引き続き保守してくれたならば今後も使い続けるだろう。でも、Expression Media のツールバーは、私を Extensis Portfolio へと追い立てるものでしかなかった。Portfolio には私を満足させるだけの機能が揃っていないが、仕事を済ませるのに最低限の機能は持っており、またこちらは素敵な Cocoa インターフェイスで私が快適かつ便利に使えると思えるまでカスタマイズできる。機能の数は少なくても簡単に見つけ出せるものの方が、機能満載だが毎度捜しまわらなければならないものよりも私は好きだ。
Portfolio では、最高に素晴らしいと言えないまでも十分満足のいく方法で、私の望むすべてができることが分かった。ただし二つだけ例外がある： 写真を撮影した日付と時刻の記録を変更することができないことと、キーワードの階層的リストが作れないことだ。でも、私は日付の変更ができる無料のアプリケーションを見つけた。Jim Merkel の PhotoInfo だ。それに、きっと私がすべてにいちいちキーワードを付けられるだけの勤勉性を身に付ける時が来るよりも、Portfolio の開発者たちが競合相手たちにせかされて階層構造を追加してくれる時が来る方が早いだろうと思う。
Expression Media と Portfolio はどちらも、メタデータのためにデータベースを別途保持する。けれども Aperture とは違い、これらはオリジナルのファイルにもメタデータを書き込んでくれる。私はこれを非常に貴重な機能だと思う。コンピュータの世界では何事も永遠には続かない。いつの日か、あなたが写真を Aperture から外に取り出したくなる、あるいは取り出さなければならなくなる時が来るだろう。その時、あなたのメタデータを抽出するためにすべての写真を書き出ししなければならないとなれば、その時あなたの写真たちが占めているのと同じくらいの追加のドライブ容量が必要になるだろう。現役の写真家のファイルならば、軽々と数テラバイトの領域に突入するかもしれないので、それを丸ごと複製するとなれば、これはもうちょっと車を駐車する場所を探す程度の騒ぎではない。町中で 18 輪の大型トレーラーの駐車場所を探すようなものだ。Expression Media と Portfolio ならば、あなたの写真はすべてそのまま今の駐車場所に置いたままで、ただ単にそれらのカタログ分けをするプログラムを変更するだけで済むわけだ。そのすべての鍵が、あなたのメタデータが個々の画像ファイルの中に保存されるようにする、ということにある。
選ぶのはあなた -- 私自身の Aperture に対する査定は、単に iPhoto よりも優れた編集機能でより拡張されたものが欲しいという本格的なアマチュアが使うのでなく、プロフェッショナルたちが使う場合には、長い目で見たマイナスの面のためにこれはあまり適切なものとは言えない、ということだった。アマチュアたちならばたぶんそこに詰め込んでいるのは JPEG ファイルであって、raw ファイルや TIFF ではないだろうから、将来の書き出しの際の問題点も桁違いに小さなものになるだろう。また、Aperture の編集ツールでも十分だという人も多いに違いない。
それから、Portfolio も Expression Media も、どちらかと言えばビジネスの世界の方に適したものと言えるだろう。Aperture とは違って、これら二つの製品は Mac だけでなく Windows 版もあり、Extensis と Microsoft の両社はどちらのプラットフォーム用にも無料のリーダーを提供して、プロフェッショナルたちがデータベースを CD に収録して送り出せるようにしている。その上、Portfolio にはマルチユーザー用のバージョンもあり、同僚たちがネットワーク上で画像を共有するためにも使える。
Expression Media と Portfolio のどちらを使うかの選択は、例えて言えばキッチンに二人のシェフ用に包丁のセットが揃っているようなものだ。片や 12 本の包丁が刃先の見えない状態で包丁台に収納されていて、片や 6 本の包丁がオープンな状態でラックにぶら下がっている。前者の包丁ならばあらゆる目的に理想的なものが選べるけれど、欲しい包丁を見つけるまでに台から数本引き出して捜さなければならないかもしれない。後者の包丁ではその場の目的に理想的なものは見つからないかもしれないが、その目的に十分使える包丁が瞬時に取り出して使える。私にとってこれら二つのアプリケーションの違いが最も際立つのは、あるテーマで写真を見る際に微妙な違いがあるものたちの中から選びたい場合だ。例えば、肖像写真でほんの少しずつ違った微笑が並んでいるような場合だ。どちらのプログラムも、小さなプレビュー画像をフルスクリーンに拡大して、それらのフルサイズのプレビュー同士で瞬時に切り替えができるが、画像同士が非常に似たものである場合には、私は両者を連続表示するのでなく、同時に隣り合わせに並べて見比べたいと思う。Expression Media ではこれができるが、Portfolio ではできない。Portfolio では、比較したい写真を Photoshop に開かせなければならない。これはツールバー上のクリック一つでできるのだが、オリジナルの写真はプレビューよりもずっと大きいので、開くにはより長い時間がかかる。
全体的に見て、Expression Media と Portfolio の違いは、機能の違いというより好みの違いだと言える。私は Portfolio の方が好きだが、それはあくまでも個人的な好みであってそれだからこちらをお薦めするということではない。私がお勧めするのは、皆さんはぜひ両者を比べながら使ってみて頂くのがよいということだ。どちらも、使用制限なしで 30 日間使えるフル機能のデモ版がある。
[写真のカタログ分けについての Charles Maurer の考察がもしもあなたのお役に立ったのなら、ぜひとも Save the Children への寄付を考えて下さるよう、彼からのお願いです。そのページの末尾には、いろいろな国での組織へのリンクもあります。]
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
文： Jeff Carlson <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Time Machine バックアップ（ローカル）をスパースバンドル（ネットワーク）に変換 -- 直接接続のハードディスクに保存しておいた Time Machine バックアップを、今は Time Capsule に接続されているそのドライブからどうやって復元するのか、とある読者が質問する。(メッセージ数 1)
Entourage 2004 (vers. 11.4.0) の問題 -- ある古いルールが AppleScript スクリプトを参照していたため、Entourage がメールをチェックできなくなっていた。それと関連して、いくつかのトラブルシューティング情報源を読者たちが紹介する。(メッセージ数 7)
テキストメッセージの印刷 -- MegaPhone があれば、ファイルを手軽に iPhone に転送して簡単にアクセスできるようになる。(メッセージ数 5)
プリンタ共有の問題 -- 共有プリンタが動かなくなった。これは Leopard が悪いのか？ その解決には、いろいろなプリンタドライバを探索し探り当てなければならないかもしれない。(メッセージ数 4)
Gmail と２台の Mac の奇妙な挙動 -- Gmail があるマシンではいくつかのメッセージを無視して別のマシンではそうしないのは、何が原因なのか？ (メッセージ数 5)
そんなに否定的にならなくても... -- Apple の最新の四半期業績で、たった一つ影の部分だと見られるのは iPod の売上げが活発でなかったことだ。でも、一千万台売れたのなら、本当に悪い知らせと言えるだろうか？ (メッセージ数 2)
FLAC オーディオファイルの扱い方 -- iTunes は FLAC フォーマットのオーディオファイルを再生できないが、他のユーティリティでいくつか使えるものがある。(メッセージ数 10)
bash で Classic をシェルスクリプティング？ -- これまで Mac 上で Classic の下でしか走らなかったデータを、どうやってアップデートすれば Windows の下で（MacBook Pro で）読み取れるようになるのか、ある読者が助言を求めている。(メッセージ数 3)
新 HP 2133 Mini-Notebook -- HP の新しいミニノートブック機は、MacBook Air と比べてどうなのか？ (メッセージ数 2)
新 HP 2133 Mini-Notebook -- 最新バージョンの QuickTime で、内蔵 Flash サポートが削除されたようだ。（Flash Player を使う以外に）.swf ファイルを手軽に読める方法はどんなものがあるか？ (メッセージ数 3)
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2008 TidBITS: 再使用は Creative Commons ライセンスによります。
, 
日本語版最終更新：2008年 5月 13日 火曜日, S. HOSOKAWA
Take Control 電子ブック日本語版好評発売中