#1520: Apple にバグを報告、tvOS 14 と HomeKit で次に登場するもの、HEIC を解説、死去した家族の Apple アカウントにアクセス

モバイルデバイスの中に写真やビデオをもっとたくさん保存しておくためには、より多くのストレージを購入するか、または画像の圧縮率を増やすしかない。そこで Apple は両方とも可能にすることにした。まず、最大ストレージ容量を拡大して、256 GB の iPhone でも馬鹿げたほど高価にならないようにした。でもそれだけでは目標の半分しか達成されない。

2017 年に、Apple はそれまで画像で使っていた JPEG と、ビデオで使っていた H.264 との双方に対して、後継フォーマットへの対応を追加した：

• HEIF (High Efficiency Image File Format) はコンテナのフォーマットで、豊富なメタデータ、複数の静止画像、シーケンス (バーストや Live Photos など) が一つのファイルと共存できるようにする。
• HEVC (High Efficiency Video Coding) は H.265 という名前でも知られているが、同じ画質を保ちつつ H.264 に比べて 40-50% も少ないデータを使ってビデオをエンコードする。

(技術的な詳細については 2017 年 6 月 30 日の記事“HEVC と HEIF でビデオと写真がもっと効率的に”をご覧頂きたい。)

もう 3 年近くも前にこれらのことが起こったにもかかわらず、私たち TidBITS スタッフでさえ今もまだ HEIF や HEVC について困って頭を掻く状態が続いている。Apple は HEIF や HEVC という用語を使っているのに、それらを用いて作成されたファイルには .heic や .mov という拡張子を付けて保存している。(これが注目されたのは College Board が iPhone 画像を手荒く扱ったことがニュースになったからだ。2020 年 5 月 21 日の記事“HEIC の扱い：AP や他のテストに iPhone や iPad から確実にアップロードする”参照。)

前者の拡張子である HEIC は、どうやら High Efficiency Image Container の略語らしいが、これについてはこの下で議論する。とりわけ混乱の元となると思われるのが後者の拡張子で、MOV ファイルはもう何十年も前から一般に使われてきた。MOV はビデオ用のコンテナのフォーマットで、さまざまの異なる方法でエンコードされたメディアを収納することができ、その方法の一つが HEVC だ。

Apple はさまざまの場所で HEIF と HEVC について説明している。Settings > Camera > Formats では、High Efficiency を選べば新しいフォーマットになり、Most Compatible を選べば JPEG か H.264 になると書いてある。ただし H.264 は MOV コンテナにも含まれる。けれども Apple はこの画面では HEIC の名前を出していないし、HEVC の保存に MOV を使うとも書いていない。そのことは HEIF と HEVC について説明したサポート記事においてさえも言える。

自分たちが日々これらのものに囲まれて生きているにもかかわらず、私たちがこれらの用語を簡単に切り分けることさえできないのは嘆かわしい。そういう訳で、ちょっと時間をかけてこれら個々の用語について調べてみた。

HEVC

H.265 というのは HEVC の別名に過ぎないが、個々のフレームの解析に従来より巧みで融通が利く方法を使い、それに加えて隣り合うフレームの差異を保存するためにも賢い手法を使うことで、圧縮率の大幅な向上を提供する。HEVC は、静止画像やビデオのシーケンスも圧縮できる。

HEIF

HEIF は Moving Picture Experts Group が開発したコンテナフォーマットだが、このグループは過去にもオーディオやビデオに数多くのライセンス付きフォーマットを作り出してきた。HEIF は静止画像に使われる。画像それ自体のみを含むことにも対応しているが、画像編集プログラムが作成した変更レイヤーや、アルファマスク、深度レイヤーなどをそこに追加することもできる。また、(例えばバーストモードのように) 複数個の画像をシーケンスとして含めることも、(例えば Live Photos のように) シンプルなアニメーションにすることもできる。

コンテナのフォーマットは、一つのファイルの内部に一種のフォルダのようなものが含まれていると思えばよい。GIF、JPEG、PNG、TIFF のような旧来の画像フォーマットは画像ファイルの内部にメタデータを詰め込んでおり、それは通常、ファイルを作成する時点で起こる。はるか昔に GIF に施された変更によって複数のフレームを内的に保存してアニメーションを作ることができるようになり、TIFF は一つのファイルの中に複数のページを含む機能に対応した。けれども実際的に、これらのオプションにはファイル全体を開かなければならないという制約があった。それに対して HEIF はコンテナなので、その中に含まれる個々の画像やシーケンスはそれぞれがコンテナ内に存在する独自のファイルであり、メタデータでさえもコンテナの中で別ファイルとして保存されている。こうして、より堅牢な、より互換なやり方でデータが保存され、異なるシステムの上でも、さらには将来を見据えても、ファイルが正しく読まれることを保証する。

HEIC

HEIC ファイルというのは、HEIF を使用する、一つの特定の方法だ。ここでは、HEIF コンテナが HEVC のみに依存して画像をエンコードする。他のオペレーティングシステムや、カメラ用ソフトウェアや、画像編集アプリなどは、HEIF のいろいろな変種を作り出し、それらをサポートする。例えば AVCI は AVC (Advanced Video Coding) エンコーダを使って HEIF 内部にデータを保存する。

iCloud Photos を有効にすると、iPhone から同期されて macOS 上の Photos に取り込まれた画像に .heic という拡張子が付いているのが分かる。ただし書き出しの際には iOS が注意深く挙動して、もしも受け取る側のデバイスが HEIC を表示できないと iOS が判断すれば、HEIC ファイルを (静止画像では) JPEG 画像に、(Live Photos では) H.264 MOV ファイル上の JPEG に変換することがある。

MOV

HEVC ビデオは MOV コンテナの中にパッケージされる。中身を調べない限り、そこに H.265 データが含まれているか否かを知る方法はない。H.265 データを処理するためには iOS 11 またはそれ以降、あるいは macOS 10.13 High Sierra またはそれ以降が必要だ。H.265 データが含まれず H.264 エンコードされたビデオのみならば、古いデバイスでも再生できる。HEIC と同様に、iOS は書き出しの際に、受け取る側が HEVC/H.265 を読めると判断できない場合には H.264 エンコードの MOV ファイルに変換することがある。

MOV ファイルの内部にあるエンコードのフォーマットを知りたければ、macOS の QuickTime Player で開いて、Window > Show Movie Inspector を選ぶ。すると、Format の欄にエンコードされているビデオとオーディオのフォーマットが表示されるし、他にも寸法やその他の詳細情報も表示される。

以上の説明で、少しは混乱がすっきりすることを願いたい。ごく簡単に要約すれば、HEIC とは Apple 流の味付けによる HEIF の一種で、静止画像の圧縮に HEVC のみを使うものだ。HEVC で圧縮されたビデオには、Apple は従来と変わらず MOV コンテナを使っている。

討論に参加

Apple は 2020 WWDC キーノートにおいて tvOS 14 や HomeKit について余り触れなかったが、今年後半には、双方に対して幾つかの素晴らしい機能がやってくる。Apple TV と Apple のホームオートメーションプラットフォームの間には、これ迄以上に重なり合う所があるので、ここでは一緒に取り上げることとした。私は、今年の仕事の時間を Take Control of Apple TV と Take Control of Apple Home Automation をアップデートするのに割り当てようと思っている。そして、Glenn Fleishman もきっと Take Control of Home Security Cameras をアップデートするのに多忙となるであろう。

tvOS 14 で来るべきもの

ここ数年間がそうであった様に、tvOS 14 も Apple TV に何か革新的なものをもたらすことはないであろう。それでも、追加されるものは少なくない：Home アプリ、セキュリティカメラの統合の改善、Apple TV アプリに拘束されないピクチャーインピクチャー、4K サポートの拡大、AirPods に対するオーディオ共有、そしてより広範なゲームコントローラーのサポートが含まれる。

問題は Apple が新しい Aerial スクリーンセーバービデオを導入するかどうかである - 多くの人にとって、ここ数年の tvOS リリースの中で、これらは最も目に見える改善であった。

Home アプリ

tvOS 14 における最大のニュースは Home アプリの追加である。Apple TV 上で Siri を使って HomeKit アクセサリーを制御することは何年も前から出来ていたが、当事者からのグラフィカルインターフェースは何もなかった。それが tvOS 14 で変わる。この Home アプリが実際にどれ程有用なものとなるかは未だ分からないが、あったら便利であることは間違いないであろう、とりわけ、家に一緒に住む人が他のことでは Apple 製品を使わない状況の場合は。.

Apple TV 上の Home に関して興味を引くのは、それがどの様に手持ちの HomeKit カメラと統合出来るかであろう。iOS でと同様、Control Center から、自分で設定したカメラからのビューを含んで好きなものへアクセス出来る。一つを選んで全画面で見ることも出来る。

tvOS 14 は HomeKit ビデオ呼び鈴をもっと面白いものにする。誰かが呼び鈴を鳴らすと、Apple TV で今見ているビデオが何であれ、その上にプレビューウィンドウが現れ、カメラからのビューを表示する。

改善された 4K サポート

Apple は Apple TV の卓越した画像品質を誇示することが好きだが、未だ後れを取っている点は幾つかある。Apple TV ユーザーの一部にとってとりわけ気になっていたのは、YouTube における 4K ビデオサポートの欠如であった。これは TidBITS Talk での最近の話題でもある。

それは Apple と Google がフォーマットについて角を突き合わせる典型的な事例でもあった。Google は 4K YouTube ビデオをオープンソースの VP9 コーデックでしかサポートしない。一方、Apple は頑として H.264 と H.265 しかサポートしない。両者がどの様な妥協点を見いだしたかについての憶測は出ていたが、彼らの対立を解決したことを窺い知るには十分である。

他の 4K 改善には、iOS 14 の Photos アプリから tvOS 14 の Apple TV へビデオを 4K の素晴らしさを全開して AirPlay 出来ることが含まれる。

改善された Picture in Picture

Apple は Picture in Picture (PiP) を Apple TV 用に昨年発表した。これは、私の欲しいものリストに長年載っていたものである。しかし、私は、ベータサイクルのある時点で、Apple が PiP に制限をかけて Apple TV アプリの内部でしか動作しないようにした時に失望した ("tvOS 13 の Picture in Picture の使い方" 5 October 2019 参照)。私の推測は、Apple が不具合の修正に時間が掛かっているのではないかと言うことであった。そして初期の機能はベータでは実際にバグっぽかった。

良い知らせは Apple が今や PiP をシステム全般に展開するに十分な自信を持っているように見えることで、そしてそれは HomeKit カメラの統合への鍵となりそうである。私は、YouTube が PiP を Apple TV 上で許すかどうかに興味がある。これは iPad ではダメである (回避策については、"TipBITS: YouTube ビデオを Picture in Picture で視聴" 19 July 2019 を参照)。

AirPod オーディオ共有

tvOS 14 では、Apple TV に対して２組の AirPods を接続出来、そして同時に聞くことが可能であり、子供が寝た所で配偶者と二人で映画を楽しむことも出来る。Apple はどのバージョンの AirPods がサポートされるか言っていなかいが、全てが対象であることを望みたい。

ゲームでの改善

Apple はマルチユーザーサポートを tvOS 13 で限定的に追加し、家族の複数ユーザーが彼ら独自のプロファイルを持つことを許した、少なくとも Apple TV の様な内蔵アプリに対しては。これが tvOS 14 では拡大し、ゲーム進行、リーダーボード、個別のユーザーに対する招待が加えられた。

tvOS 14 はまた、Apple が tvOS 13 で導入したサードパーティゲームコントローラーに対するサポートも拡大し、Xbox Elite Wireless Control Series 2 及び Xbox Adaptive Controller が付け加えられた。後者はとりわけアクセシビリティの必要性を持つ人々には良い知らせである。 (私は、この Xbox Adaptive Controller は昨年の tvOS 及び iOS 改定でサポートされたと勘違いしていた。もし、私の進言でこれを既に購入された人がいたならば、平身低頭お詫びする。"Xbox や PlayStation 用ゲームコントローラを Apple Arcade で使う： FAQ" 25 October 2019) を参照のこと。

興味深いことだが、Apple はこれら二つのコントローラーを "含んで" と表現していた。tvOS 14 は他にどんなコントローラーをサポートするのであろうか？ 発表されていないものが他にあるのであろうか？

tvOS 14 に関してはそんな所である：大地を揺るがす様なものは何もないが、Apple TV ファンにとっては嬉しい改善もある。そして、我々は新しいスクリーンセーバーにも期待している - Aerial ビデオは美しいが、それでもやはり古くなりつつある。

HomeKit に来るべきもの

tvOS の場合と同様、Apple は HomeKit の未来について形勢を一変させるものは何も明かさなかった、昨年形成された業界団体の売り込み以外は。しかし、有用な新規改善は幾つか見られる。とりわけ、HomeKit セキュリティカメラ向けのものはそうである。

Project Connected Home Over IP

HomeKit に関する一大ニュースは、本当に新しいとは言えない類いのものではあるが、Apple がホームオートメーション機器のための単一の、標準化された標準を作ろうと Amazon, Google, そして他のホームオートメーション業者と手を組んだということである。Project Connected Home over IP は昨年発表されたものであり、そして Apple もキーノートで何ら新しい詳細を提供しなかったが、同社はキーノートの視聴者にこの提携関係を知って貰うことは重要だと感じた ("Apple、ライバル各社と協力してオープンな Smart Home 規格を策定へ" 18 December 2019 参照)。望む所は、この提携が実を結ぶことで、そうすれば、我々は間もなく好みの機器から、それが何であれ、スマートホームの機器を制御出来るようになる。

Home アプリに対する改善

一般的な HomeKit ユーザーにとっての最大の難関は、彼らのハードウェアを最大限利用する方法を知ることである。照明をオンオフするやり方は知っていても、シーンやオートメーションのことは知らなかったり、忘れたりしているかも知れない。iOS 14 では、Home アプリは、新しいアクセサリーを付け加えた時、オートメーションを進言してくる。

これは HomeKit ユーザーに力を与える手助けにはなるかも知れないが、新米のユーザーが漠然とオートメーションを有効にし、それから忘れてしまい、そして私が Take Control of Apple Home Automation で "お化け屋敷症候群" と呼ぶものに取り付かれてしまうことを私は心配する。それは、厄介なホームオートメーションが勝手に照明をオンオフし、それがなぜか誰にも分からないと言う事態である。

間違いなく歓迎出来る改善は Home の状態表示の見直しである。アクセサリーの状態の単なる羅列に代わって、それは今やアイコンを表示し、そこから各種のアクセサリーを操作させてくれる。

適応型照明

適応型照明 (Adaptive lighting) は長いこと色を変えられるスマート照明の、Philips Hue の様な、一般的な機能であり、そして今や Home アプリがそれを直接サポートする。適応型照明は一日を通して変化する。夜には、より眠りにつきやすくするためにブルーライトを減らす。私は、それが調整可能かどうか、或いは、照明についての Apple の意見に従わなければならないのか、さもなくばその機能を完全に不能にしてしまわなければならないのか、知りたいと思う。

セキュリティカメラの改善

最も重要な HomeKit アップデートはセキュリティカメラに関してである。第一は、 Activity Zones で、カメラの視野の中で侵入警報を起動する範囲を規定する境界線を描ける。もし誰かが玄関に向かって歩いてきたら教えて欲しいだろうが、家の前の道路を車が通る度にではないであろう。

HomeKit カメラに対してのもう一つのスマート機能は、顔認識である。Photos アプリのデータを使って、HomeKit はカメラ上の人を認識出来る。この機能は、主としてビデオ呼び鈴向けである。従って、iOS が認識出来る誰かが呼び鈴を鳴らすと、カスタム警報を iPhone, iPad, Apple TV, そして HomePod 上ですら、受けられる。

と言うことで、これが tvOS 14 と HomeKit に来るべきものである、少なくとも Apple が今共有しているものからは。使ってみたいと思ったり、ホームオートメーションに加えてみたいと思う機能はありますか？ コメント経由で教えて欲しい。

討論に参加

WWDC がやって来ては去り、あとにはたくさんの新しいオペレーティングシステムのベータ版が残った。macOS 11 Big Sur、iOS 14、iPadOS 14、watchOS 7、それに tvOS 14 だ。

もしあなたに勇敢な気持ちがあって、ご自分の時間のいくらかを提供してこれらのオペレーティングシステムを Apple がすべての人たちのためにより良いものとする手伝いをしようと思われるなら、あなたもこれらのベータ版をテストできる。既に Apple Developer プログラムの会員である人は即座にできるし、そうでない人はもう少し待って Apple が公開ベータ版をリリースした後に参加できる。いったんベータ版をインストールすれば (もちろん、あなたの主たるデバイスにインストールしてはいけない、それは無謀すぎる！)、すぐにバグに遭遇することだろう。何しろこれはベータ版なのだから。もしもそれがちゃんとしたものであったなら、出荷されているはずだ。

Apple がこれらのベータ版を主として PR のためにリリースしているのだと思ってしまいがちかもしれないが、それは真実とかけ離れている。Apple は開発者からもユーザーからも届くバグ報告を本当に大切にしている。けれども、想像して頂けるとは思うが、何十万人もの開発者からバグ報告が殺到すればたとえ Apple のリソースをもってしても追い付かないことがある。

では、Apple が実際にバグを修正できるようにバグ報告をするには、どうすればよいのだろうか？

Feedback Assistant を使う

Apple はユーザーやサードパーティの開発者からのバグ報告を Feedback Assistant を通してしてもらうようお願いしている。これはインストール済みのアプリとしても、またウェブサイトとしても提供されている(訳注：閲覧には Apple Developer アカウントが必要)。バグを報告するには、アプリの方を使うことをお勧めする。アプリ版は報告されるバグの種類に基づいて具体的な質問であなたを手引きして行き、自動的にシステム診断ファイルを生成し、その種類のバグに関係あるログや報告をあなたに求める。iOS 版の Feedback Assistant は、接続された Apple TV、Apple Watch、および HomePod デバイスについてのバグも報告できる。

この Feedback Assistant アプリは macOS 10.15 Catalina およびそれ以降で、また iOS 12.4 およびそれ以降でインストールされている。ベータ版のオペレーティングシステムでは、Feedback Assistant アプリが Dock (macOS) あるいは Home 画面 (iOS) に現われる。Mac で Dock 上に表示したくない場合には、/System/Library/CoreServices/Applications/Feedback Assistant から Feedback Assistant を起動できる。Spotlight から起動するのがたぶん最も手軽だろう。また、Safari から、あるいはどのデバイスからでも applefeedback:// へナビゲートすれば Feedback Assistant が開く。

Feedback Assistant で送られた個々のバグ報告は、Apple Developer Support の誰かが調べる。簡単な問題ならばその人が自分で答えることもあるし、重要な情報が明らかに欠落している場合にはそのまま送り返すこともある。もしもしっかりしたバグ報告だと思えれば、それを Feedback Assistant からコピーして、Apple の社内バグ追跡システム Radar に入れる。すると Radar はその報告を適切なエンジニアリングチームに送る。エンジニアリングチームはバグを修正することも修正しないこともあるし、さらに言えばそれを読むことも読まないこともあり得る。

Apple は効果的なバグ報告にするための指針を公表しているが、以下もどうぞお読み頂きたい。あなたのバグが修正される可能性を最大限にするための方法を、私なりに説明してみたい。

良いバグ報告を書く

WWDC が開催される 6 月と iPhone がリリースされる 9 月との間に、Apple のオペレーティングシステム担当のエンジニアたちは毎日 12 時間働き、週に 6 日あるいは 7 日働くことさえある。彼らは、上司に仕上げろと言われた機能を仕上げているのだが、それはその上司が次の上司に既に完成したと報告してある仕事なのだ。(おっと！) 彼らは、Apple Quality Assurance (QA) エンジニアから報告されたバグも修正している。ただ、Apple の副社長が時々報告して来るバグを修正するために他のすべてのバグを放り捨てなければならないこともある。(その通り、Apple の経営陣はリリース前の製品を使っていて、彼らもバグを報告するのだ。) それらすべてを済ませた後で、サードパーティの開発者たちや、公開ベータ版のユーザーたちから報告されたバグも修正しなければならない。

私が Apple のソフトウェアエンジニアだった頃は、それが私の仕事だった。私は毎日外部から何十もの新しいバグ報告を受け取っていたが、そのうち一部しか対処できる時間がなかった。多くの開発者たちは素晴らしいバグ報告を書いてくれたが、ADHD の薬を飲み忘れた小学三年生が書いたんじゃないかと思えるようなものもあった。そのどちらに注目が行くかはお察し頂けるだろう。そこで、以下に良いバグ報告に必要な事柄をまとめておこう。そのいくつかは開発者にしか当てはまらないが、ほとんどはすべての人に当てはまる：

• 内容の分かるタイトルにする。 良いバグ報告は、良いタイトルで始まる。明確で簡潔なタイトルにしよう。バグ・ミーティングの長時間にわたる過酷な作業を通じて、エンジニアたちと製品マネージャーたちは何百とある新しいバグに優先順位をつける。バグはタイトルでリストされるので、あなたのバグのタイトルは、非常に長いリストの中のたった一つの項目に過ぎない。内容の分かるタイトルなら、エンジニアたちもそのバグ報告を開けて説明を読まずともどういう内容かが分かる。漠然とした、または短過ぎるタイトルは、あとで見ようというぼんやりした約束とともに見過ごされてしまう可能性が高い。
• 問題を説明する。 実際に何が起こるかを説明し、本当は何が起こるべきだと思うのかを書く。どこがおかしいか書かなくても明らかだろうと思ってはならない。もし Apple の開発者向け資料に何が起こるべきかが書いてあれば、そこにリンクしよう。私があらゆる Apple 資料書類を暗記しているなどと思わないで頂きたい。
• バグを再現するための明確な手順を書く。 初期条件をリストすることも忘れてはいけないし、手順は一つも省略してはいけない。もしもそのバグが必ず起こるものでなければ、起こる頻度を書き添えておこう。
• 簡潔に書こう。 あなたのバグを修正した後にも、私にはたくさん他のバグが控えている。どうか私の時間を効率的に使って頂きたい。あなたのバグが簡単に再現できるものであればあるほど、私がそれを修正できる可能性が高まる。
• スクリーンショットかビデオを含めよう。 可能ならば、そのバグを再現させる手順を示したスクリーンショットかビデオを添えよう。実際にバグが起こっているところの画像も良い。写真で示されれば問題がよく分かる。また、エンジニアがその問題を無視しにくくなる。見えないものは、忘れ去られる。
• 状況を明確化する。 そのバグはデバイス上で起こるのか、それともシミュレータ上で起こるのか、それともその両方か？ デバッグ用ビルドとリリース用ビルドの両方で起こるのか？ 別のデバイスモデルでも試したか？ そういった情報をすべて書き込んでおこう。
• コードも含める。 そのバグを見るためにコードが必要ならば、コードを含める。最低限、バグを実証するコード数行は含めよう。もしも可能ならば、バグを実証できるサンプルの Xcode プロジェクトを添付しよう。あなたのアプリを丸ごと含めてはいけない。その中をかき分け探すなんてしたくない。新規に空白のアプリを Xcode で作成し、バグを示すために必要なコードだけを追加する。そこに、一目で分かるように大きく“バグはここで起こる！”というコメントを追加して、私がソースファイル全部を読み通す必要がないようにして頂きたい。Xcode プロジェクトを追加することにはもう一つ利点があって、それは、あなたのビルド設定がすべて記録されていることだ。バグによっては特定のビルド設定の下でしか起こらないものもあるからだ。
• ビルド番号を明記する。 オペレーティングシステムのバージョンの話をする際には、そのオペレーティングシステムのバージョンだけでなくビルド番号 (例えば 17E262) も含めよう。(macOS でビルド番号を知るには、Apple メニューから About This Mac を選び、macOS バージョン番号の上でクリックする。iOS では Settings > General > About でバージョン番号をタップする。) Apple 社内では、オペレーティングシステムのビルドはビルド番号によって区別されている。Apple のエンジニアたちは、どのビルド番号が外部的にどのベータ版あるいはリリースに対応しているのかを必ずしも知っている訳ではない。もちろん調べれば分かるのだが、彼らにとって時間の節約になれば、それだけそのバグが修正される可能性が高まる。
  
• 該当するならばシステム診断やログを含める。 Feedback Assistant アプリを使えばシステム診断が自動的に含まれ、バグの種類に応じたログを含めるようプロンプトが出る。システム診断 (sysdiagnose) とは、あなたのシステムで何が走っているかについての膨大な量の情報を含んだレポートだ。どう読み取るべきかを知っている人にとっては、極めて有益な情報だ。Feedback Assistant ウェブサイトを使う場合には手で sysdiagnose を生成する必要があるが、それほど難しい作業ではない。必ず、関係あるコンソールログと、関係ある情報を含んでいると思われる他のログも添付するようにしよう。Apple は sysdiagnose の生成方法と(訳注：閲覧には Apple Developer アカウントが必要)、具体的なバグの種類に応じて特化したさまざまの種類のログについての説明を記した記事を提供している。
• Xcode のバージョンを明記する。 オペレーティングシステムのそれぞれのベータ版リリースには、たいていそれに対応する Xcode のベータ版リリースも含まれているので、必ず最新版の Xcode を使うようにしなければならない。バグがオペレーティングシステム自体にでなく Xcode に含まれているフレームワークのどれかの中にあるかもしれないからだ。あなたが古いバージョンの Xcode を使ったせいで既に修正済みのバグを報告する羽目に陥ることは避けたいだろう。

バグは迅速に報告する

Apple は毎晩新しい社内用オペレーティングシステムのビルドを作成して、それを daily build と呼ぶ。Apple のエンジニアたちは毎朝その daily build をインストールする。中にはかなり安定した daily build もあるけれども、そうでないものもある。WWDC と出荷の間には数週間に一度ずつ、安定したビルドが選ばれてベータ候補となる。それはさらなるテストを受けてすべての側面が安定していることが確認される。もしテストを通過すれば、ベータ番号が付与されて、開発者たちと公開ベータテストに参加するユーザーたちに向けてリリースされる。

そのベータ版がリリースされる頃には、Apple のエンジニアたちは既にそれを古いものと考えている。それより後に、もう何度も daily build をインストールし続けてきたからだ。あなたがベータ版をダウンロードし、インストールし、テストし、バグ報告を書き、そのバグ報告が Feedback Assistant から Radar へコピーされ、Apple エンジニアの誰かがそれを読む頃には、そのベータ版は既に大昔のものとなっている。あなたがバグ報告を書くまでに長い時間をかければかけるほど、エンジニアたちにとってあなたが目にしている状況を再現することの困難が増す。

だから、新しいベータ版が出たら、即座にそれをテストしてバグ報告を提出すべきだ。Apple エンジニアがそれを読む時点で、あなたのバグ報告が可能な限り現行に近いものであるようにしよう。

その後に出たオペレーティングシステムのリリースを毎回チェックする

あなたのバグが修正されたことを Apple があなたに報告することができたなら、どんなに素敵だろうか。歯の妖精が本当にいたなら、同じくらい素敵だったろう。Apple は個々の問題点ごとに何十も、時には何百ものバグ報告を社外から受け取っている。社内の Apple エンジニアたちも同じバグについて書いているかもしれない。通常それらの中で問題の最も明確な説明のあるものが、オリジナルと指名される。それ以外のものは重複 (dup) とマークされ、少なくとも理論的には、そのバグが修正されればバグを報告した全員が通知を受けるべきだ。でも、もしあなたの説明がオリジナルの説明とはっきり同じ内容だと分からなければ、あなたの報告は dup とは判断されず、バグが修正されてもあなたに通知が届かないかもしれない。

結果として、新たにリリースされる個々のベータ版ごとに、報告したバグが修正されているか否かをあなたが自分でテストすることが望ましい。もしもまだ修正されていなければ、その新しいリリースに対して新たにバグ報告を書くことを考慮して頂きたい。そうすることでそのバグが再び Apple の注目を得て、エンジニアたちもそれが最新のリリースでもまだ修正されていないと知ることができる。

たとえこのバグ報告がきっと重複とマークされるだろうと思えたとしても、とにかく報告はしよう。あなたの報告が、バグが修正されることに向けた一票の投票だと考えよう。エンジニアたちがバグ・ミーティングの席に座ってどのバグを優先するか決断する際に、100 個の dup があるバグの方が、3 個の dup しかないバグよりも多くの考慮の対象となる。そちらの方がより多くの人々に影響を与えていると考えられるからだ。

たとえあなたのバグが修正されても、Feedback Assistant の中でそれが修正済みとマークされるのは、その修正を盛り込んだバージョンのオペレーティングシステムが（ベータ版であれ最終版であれ）出荷された後になってからだ。Apple は、出荷される前に修正を発表することを好まない。

開発者の皆さん、もしもバグがあなたの製品の重要な機能をブロックしていて、そのバグがなかなか修正されないと思われたなら、Developer Support に電子メールを送って、状況の更新はないのか、何か回避策はないのか、と尋ねて頂きたい。時には車輪が軋み出さないと油をさしてもらえないこともあるから。

もしもあなたの知り合いが Apple エンジニアリングで働いていたなら、その人に頼んでそのバグを Radar で検索してもらうとよいかもしれない。それで、そのバグが修正される見込みがあるか否かが分かるかもしれないからだ。それを妨げるかもしれない事柄がいくつかある。そのバグは Feedback Assistant から Radar へまだコピーされていないかもしれない。セキュリティ上の理由から、必ずしもエンジニアたちの全員が Radar にあるバグのすべてを見ることができるとは限らない。それにまた、あなたの友人はそういうことをするのは気が進まないかもしれない。その気になれば、一般的な情報なら貰えるかもしれない。例えば「順調に行けば次のリリースで修正されるかもしれないよ」という感じだ。そうと知るだけでも役に立つことはある。ただ、Apple に強く言ってこのバグを修正させろよと友人に頼んではいけない。あなたの友人はそのバグを扱う部門とは違うところで働いていて、そのバグを担当するエンジニアとは一面識もないことも十分あり得るのだから。Apple は何千人ものエンジニアを雇っている。そもそも彼らはバグの状況を部外者と議論してはならないことになっているのだから、友人を困った立場に追い込んではいけない。

最後にもう一言。Feedback Assistant と Radar は別々の番号付けシステムを使っている。Apple エンジニアはそれらを相互に翻訳できる。Radar という名前は頭字語ではない。これは、もう 30 年間も Apple のバグ報告システムであり続けている。かつて開発者たちは RadarWeb という名前のウェブポータルを持っていて直接 Radar データベースにアクセスできたが、それは自分が報告したバグに関する情報に限られていた。けれどもその後 Feedback Assistant が RadarWeb に取って代わり、サードパーティの開発者やユーザーから報告されたバグを追跡するための別個のデータベースを提供するようになった。

Apple の問い合わせにはすぐに返事する

時には、Apple のエンジニアがさらなる詳細やログを求めることがある。それなしに済ませるため、できる限り最初からバグ報告に関係あるログを含めておくようにして頂きたい。時として、Apple の方から追加のデータを求めたり、特殊なログファイルを生成するためのプロファイルを送って来たりすることもある。その際には、できる限りすぐに反応して頂きたい。バグが長い間バグのまま留まっていればいるほど、エンジニアが次の仕事に移ってしまう可能性が高まる。まだオープンな状態にあるバグは、定期的にチェックしよう。

時には、まるでただ問題を引き延ばすためだけに Apple エンジニアが余計な情報を求めてくるように思えるかもしれない。Apple で働いていた頃に、私はその戦術が他の Apple エンジニアやサードパーティの開発者が書いたコードのバグに対して用いられるところを目にしたことがある。エンジニアが何かもっともらしい追加情報を求めると、その返事が届くまでに時間がかかる。およそ半数の開発者は返事をよこさないので、エンジニアは「追加情報待ち」という理由でそのバグを無視することができる。

バグ報告の発信方法は他にもある

Apple の Crash Reporter は、クラッシュを引き起こしたバグを自動的に探知して報告する。自分たちのコードの中にどの程度の数のアクティブなクラッシュがあったかによって、チームのランク付けがなされる。Apple は、技術的にも手続き的にも、クラッシュを起こすバグを修正することに向けた良いシステムを持っている。だからと言ってクラッシュを起こしたバグをあなたが報告しなくてよいということではない。バグ報告が集まれば、やはり修正の緊急度が高まるだろうからだ。

クラッシュするバグや、カーネルパニック、ハードウェアのバグ、または Mac で起こる印刷の際の問題を報告する際には、System Information 報告を添える必要がある。Utilities フォルダにある System Information アプリを使えばこの報告を生成できる。(File > Save を選べばよい。)

Apple エンジニアたちは実際、いくつかの開発者フォーラム、ブログ、ポッドキャストなどに注意を払っている。そういったところに頻繁に出る苦情が Radar の中にバグとして書き込まれることもある。実際、私は開発者フォーラムに投稿された記事が Radar のバグ報告としてコピーされたものを見たことがある。けれども、Apple エンジニアが開発者フォーラムに投稿することは稀だ。会社がそれを阻止しようとするからだ。あるいは少なくとも、かつてはそうであった。Apple がデザインを新たにした開発者フォーラム では開発者の参加を促している。(2020 年 6 月 11 日の記事 Apple、WWDC 2020 のスケジュールを発表 参照。) 公式にそうと認めることはまずないけれども、Apple エンジニアリングは開発者たちの意見に耳を傾けている。

バグの優先度を理解する

Apple はすべてのバグに P1 から P5 までの優先度を割り当てる。P1 はクラッシュまたはデータ喪失を招くバグで、一般的に言ってこの種のバグは必ず修正しなければならない。P2 は機能が働かないバグで、Apple はほとんど常にこの種の問題を修正している。P3 は機能が正しく働かない問題で、Apple は P3 バグを修正したいと思ってはいるけれども、中には修正を延期するものもある。P4 はユーザーインターフェイスの問題やその他の細かなバグだが、この種のものは延期されてしまうことが多い。P5 は拡張に対する要望で、この種の要望は大体において無視される。

Apple エンジニアたちの中には、自分に割り当てられたバグを修正することだけに専念して、その中で優先度の高いものから低いものへと順番にこなして行く人たちもいる。そうすると優先度の低いバグには全く手が付かないことが多い。けれども経験を積んだ Apple エンジニアたちは優先度の低いバグにもつまみ食いのように手を付けて、ユーザーを悩ませると分かっているバグは必ず修正しようと努める。Apple エンジニアたちも Apple 製品を使っているので、うまく働くようにしたいと願っているからだ。部門によっては、割り当てられたバグの大多数を修正したエンジニアに賞を与えているところもある。

出荷日がずっと先にあるうちは、Apple エンジニアたちは事実上どんなものでも好きなコードにチェックインすることを許される。けれどもアルファ版、ベータ版、そして最後にゴールデンマスター版へと近づくにつれて、次第に制約が増える。まず、P1 または P2 のバグしか修正を許されなくなる。そのうちに、認められるもののリストには P1 バグだけが並ぶようになる。個々のバグとその修正には、バグの深刻度や、修正におけるリスクに応じてランク付けがなされる。リリース日が近付くと、深刻なバグでさえも延期されることがある。悪いバグだけれども稀にしか起こらず、しかもその性質がよく理解されているバグが残る方が、テストする時間がなくてよく理解されないままの修正が施されて世に出るよりも良い。その修正は、もっと厳密なテストを経た上で、最初のパッチリリースにおいて追加されることになる。

Apple の開発サイクル

あなたのバグが修正される可能性を最大化するためには、Apple の開発サイクルを理解することも役立つ。iOS や macOS のメジャーな X.0 リリースが出荷された後、たいていそれは 9 月のことだが、次の年に予定されるそれぞれの X+1 リリースに向けた仕事がスタートする。その開発作業は年末までずっと続き、2 月か 3 月までには QA がビルドのテストとバグの報告を本格的に開始する。時を経て開発バージョンは安定性を増し、かろうじて使える程度のものから、それほど悪くないと思えるものに変わる。5 月までに、daily build がかなりまともに見えるものになる。そうして、WWDC 用のベータ版を組み立てるための必死の作業の時期に突入する。この時期に、依然として未完成の機能や無視されてきたバグが、突然注目を集めるようになる。

WWDC に持ち込まれる Beta 1 は、初めて (必ずテスト用デバイスに！) インストールすると結構荒削りに見えるけれども、それでも膨大な仕事の結果であることに変わりはない。そう、この時点にこそ、皆さんはバグの報告を始めるべきだ！ Apple エンジニアたちはこの時点で、バグ報告を読んで問題を修正する仕事を割り当てられる。そうやって注目を得ているこの機会を利用して、お気付きになったバグを何でも報告して頂きたい。

7 月と 8 月にはさらなるベータ版リリースが出る。皆さんはその一つ一つをテストして、報告したバグが修正されているか確かめ、不具合、つまり以前はうまく働いていた機能が働かなくなってしまったことがないかを探して頂きたい。繰り返して言うが、もし以前のベータ版で報告したバグがまだ修正されていなければ、遠慮なくもう一度バグとして報告して頂きたい。

9 月が近付くと、ベータ版はますます安定性を増すが、その一方で Apple が施す変更点は少なくなる。マイナーなバグが 8 月までに修正されていなければ、おそらくそれはゴールデンマスターでも修正されないだろう。それでもバグ報告はして頂きたい。そうすれば、Apple がいずれ早いうちにパッチリリースで修正する望みがある。

通常、新しいオペレーティングシステムは 9 月にバージョン X.0.0 として出荷される。その後すぐいくつかのパッチリリースが出されるが、X.0.1、加えて時には X.0.2 も、既に X.0.0 が出荷されるよりも以前から予定されている。X.0.1 には、X.0.0 リリースに盛り込まれなかったいくつかの重要なバグ修正が含まれる。X.0.2 にはそれほど重要度の高くない、しかし X.0.0 には間に合わなかったバグ修正が含まれる。バグに取り憑かれた運の悪い年には X.0.3 リリースさえあり得る。

これら当初のパッチリリースが片付けば、Apple エンジニアたちは次期メジャーリリース X+1 に向けた仕事を始める。だから、彼らにはもはや、現行の出荷バージョンのオペレーティングシステムのバグを修正する仕事ができる余地はあまりない。バグ報告は引き続き送って頂きたいが、それが修正される可能性は既に劇的に低下している。

(余談だが、Apple 社内のチームは通常、分野や機能に応じて分かれているのであって、メインリリースとパッチリリースでチームが分かれることはない。例えば電源管理を担当するエンジニアは、当初の X.0 でもその後のどのパッチリリースでも電源管理の仕事をする。なぜなら、一人のエンジニアが当初のコードを書いて、その後別のエンジニアがやって来てバグを修正するというのは非効率だからだ。あとで来たエンジニアはそのコードにそれほど深く馴染んでいる訳ではなく、なぜこのように設計したのか、どんなアイデアを試しては捨て去ったのかも知らないからだ。一人のエンジニアが特定の分野のコードに責任を持ち、すべてのリリースでその仕事を担当する方が良い。)

おそらく X.1 や X.2 のリリースもあるだろうが、通常それらは新しい機能を導入するためのもの、例えば Catalina に iCloud フォルダを追加したり、バッテリー状態管理機能を加えたりといったものだ。そういうリリースにもいくつかのバグ修正はあるが、それが主要な目的とはならない。この時期にもどうぞバグ報告をして頂きたいが、飛び抜けて悪いバグでない限り、早くても次期メジャーリリースになるまで対処が施されることはないと思った方がよい。

結びにまとめておこう。あなたが見つけたバグを (そう、バグを見つけない人などいるだろうか？) Apple に修正させたいと思われるなら、いくつかのシンプルなルールに従って頂きたい。明快な、完結したバグ報告を書いて、可能ならばスクリーンショット、ビデオ、サンプルコードを添えること。できる限り早い時点でバグを報告すること。Apple の開発サイクルを知った上で取り組むことだ。

そして最も重要な一点を言うならば、報告を送り続けることだ。報告されないバグは、修正されないのだから。

討論に参加

死と税、これら二つの人生において避けられないものの内、死は今年の見出しを支配してきた。世界の中では、税は先延ばしされた所もあるが、これ迄の所、世界中では 500,000 の人々が COVID-19 のために亡くなり、その内 125,000 人は米国の人達で、そして 22,000 以上の人は、我々が住む所から４時間のドライブで行ける New York City の人達であった。更に、George Floyd, Breonna Taylor, Ahmaud Arbery と言った注目を集めた殺人もあったし、余りの多くの有色人種の人が殺された。

従って、我々全てが直面する更なる社会学的そして疫学的危機に言及する迄もなく、死は最近の私の心を離れない。

そんな中で、私が属している私的なメーリングリスト上で一つのメッセージが目にとまった。それは、その人の知人の家族の一人がボート事故で突然亡くなってしまった後での助けを求めるものであった。その亡くなった人は、その家族の Family Sharing アカウントの唯一人の管理者で、共有パスワードも共有セキュリティ文言も残しておらず、残された家族はそのアカウントの管理部分にアクセス出来なくなった。そこには課金情報も含まれ、アップデート出来ないと、支払いが滞りアカウントは閉鎖されてしまうことになってしまう。

厄介なことに、彼らが Apple サポートに連絡した時、その係員は手助けとなることは出来ず、そのパスワードを何らかの方法で解き明かすか、或いは他の方法で自らアクセスを手にするか出来ない限り、そのアカウントは停止状態に入ってしまうであろうと告げた。彼らは、もしそうなってしまったら、彼らの家族共有のデータ全てを失ってしまうのではないかと心配した。この様な状況になるのはきっとそう多くないのだろう、そうでなければサポート係員も Apple にそれに対する規定があることを知っていただろうにと私は思う。私個人的にはこの規定についてこれ迄聞いたことがないので、今後誰かがその情報を必要とする不幸な事態に遭遇した場合に備えて、もっと広く共有しておくのは意味があることだと考えた。

Apple のサポート書類 "死亡した家族の Apple アカウントへのアクセスをリクエストする方法" には、その方法と必要書類が示されている。鍵となるのは、以下が明記されている裁判所命令である：

• 故人の氏名と Apple ID
• 故人のアカウントへのアクセスを求めている最近親者の氏名
• 故人が、Apple ID に関連付けられているすべてのアカウントの使用者であったこと
• 依頼人が故人の法定代理人 (legal personal representative)、代理人 (agent)、または相続人であり (heir)、その承認内容が「lawful consent」(法的に正当な同意) に相当すること
• 故人のアカウントの情報にアクセスする権利を提供するよう Apple が裁判所に命じられていること

その様な裁判所命令を得ることは時間のかかる話で、かつ法律家の手を借りるのが最も手っ取り早い方法であろうと思われる。入手した所で、Apple サポートに連絡を取り、何を必要とするのか、裁判所命令は貰っていること、そしてこのサポート書類に基づいて作業を進めていることをはっきりと伝えよう。

上記の具体例では、その家族は、２週間前に出した裁判所命令請求に対して州が対応するのを未だ待っている状態である。その理由の一つは、公式の死亡証明を得るのに思いのほか時間がかかったことである。ただ、幸いにして、彼らはこの問題に対する回避策を見つけることが出来た。それは、それぞれの家族構成員が自分の機器上で自分自身を家族プランから除去することであった。その後で、彼らは新たな家族プランを作成し、そして全ての人をそこに戻すことが出来た。

他に２つの注意点を挙げておく。第一に、FBI が犯罪者のロックされた iPhone に入る手助けを求める時、Apple は、同社が何故パスコード暗号化を破れないかについて極めて明快にしており、次の様に言っている：

ただ、パスコードでロックされているデバイスは暗号化されていますので、最近親者の方がデバイスのパスコードをご存じない場合、デバイスを消去しない限りはパスコードロックを解除することはできませんのでご注意ください。

従って、Apple が十分にお手伝い出来たとしても、それは故人の機器を消去することでしかなく、その機器上にあった情報にアクセスする方法は全くない。理屈の上では、故人の Apple ID を入手した後に、新しい、或いは消去した機器に iCloud バックアップを復元することも可能と思えるが、それが本当に可能なのかどうか私には分からない。

第二に、ボート事故で死ぬのは極めて珍しいことではあるが (全米では、死亡の 0.02% に当たる)、同様の偶発事故に備えて計画しておくのは賢明な話である。数年前に、Joe Kissell はこの話題についてとても有益な本を書き、Take Control of Your Digital Legacy、そして TidBITS にも "Aunt Agatha Ponders Her Digital Legacy" (30 January 2017) として紹介した。この本の中で、Joe は、あなたのオンラインアカウント、購入済みメディア、ソフトウェア、個人データ、そして暗号通貨 (仮想通貨) のデジタル棚卸し台帳を作成するために必要な思考過程を解説している。この様なデジタル棚卸し台帳を作っておけば、あなたが突然死亡した場合にも家族に余分な仕事させなくても済むことが分かっており安心出来るというものである。

討論に参加