WWDC26のラボでApple Performanceチームが語ったこと

WWDC26でAppleは、自社のPower & Performanceエンジニア5名をカメラの前に立たせ、1時間にわたる開発者とのライブQ&Aを実施しました。そこで取り上げられたのは、開発者が実際に提出している疑問です。アイドル状態のSwiftUI画面がなぜバッテリーを消耗させ続けるのか、所有していない古いデバイスをどう疑似的に再現するのか、出荷済みアプリにおける最大の電力消費ミスとは本当のところ何なのか。洗練されたセッションは、フレームワークがどう動くかを教えてくれます。一方でGroup Labが教えてくれたのは、Apple自身のチームがそれをどう使っているかでした。本記事では、覚えておく価値のある実践的な指針をまとめます。

出典についての注記：Appleはこのラボの動画をキャプションなしで公開しました。そこでローカル環境のWhisperで文字起こしを行ったため、以下のラボ引用はすべてその文字起こしを言い換えたものであり、Appleの逐語的なトランスクリプトではありません。話者は、ラボの冒頭で紹介された名前と役割に基づき、会話の文脈から推測して帰属させています。パフォーマンス担当のTerry、MetricKit担当のYanni、Instruments担当のKaspar、CoreOS Power担当のKunal、レンダーパイプライン担当のMarco、そして司会のColeです。¹ ラボの指針がAppleの正式なドキュメントに関わる箇所では、そのドキュメントまたは対応するセッションを引用し、その旨を明記しています。

ラボの助言の多くを支える、ケーブルレスのパワートレース・ワークフローは11:42あたりから始まります。

TL;DR

• 旧来のObjective-C版MetricKitは廃止に向かっています。MXMetricManagerは27.0で正式に非推奨となり、新しいメトリックおよび診断の型は新しいSwift APIにのみ提供されます。²³
• Xcode OrganizerはMetric Goalsを提供するようになりました。これは自身の履歴と、Appleが自分のアプリと類似していると判断したアプリから導き出されるベースラインで、起動、ハング率、ディスク書き込み、バッテリー、ストレージ、ヒッチをカバーします。⁴
• チームが推奨する電力ワークフローは、Performance TraceのPower Profilerモードです。デバイス上でケーブルレスの.aarトレースを記録し、それをMacに共有して、Instrumentsでcpu、GPU、ディスプレイ、ネットワークの各電力レーンを読み取ります。この機能はiOS 27ではなく、iOS 26で登場しました。⁵
• Apple Intelligenceの処理は主にNeural EngineとPrivate Cloud Computeで実行されるため、CPUに依存するアプリの処理は競合せずに並行して動作できることが多いです。バックグラウンドタスクをチャンクに分割し、システムが一時停止と再開をできるようにしましょう。¹
• チームが目にする最大の電力消費ミスは、テレメトリの不足です。正しいものを一度も測定しなかったために、開発者は誤ったものを最適化してしまうのです。¹

なぜラボは文字起こしする価値があるのか

Appleの収録済みセッションは、台本があり、リハーサルを経て、編集されています。Group Labはそのいずれでもありません。実際に開発に携わる開発者からの質問にエンジニアがリアルタイムで応える場であり、その回答には現場経験の手触りが宿っています。武勇伝、「これはしょっちゅう見かけます」というパターン認識、何が難しいかについての小さな告白。その手触りこそ、洗練されたセッションが削ぎ落としてしまうものなのです。

問題は、Appleがこのラボをキャプションなしで公開した点にあります。引用するためにはローカルの音声認識で動画を処理する必要があり、その結果、固有名詞やAPIの綴りは近似値で出てきます。私はすべての技術的な主張を事実として述べる前に、Appleのドキュメントまたは対応するWWDCセッションと突き合わせて確認し、ラボそのものの言葉は明確に言い換えとして示しています。エンジニアの語る意図と優先順位については権威ある見解として扱い、具体的な仕様については引用を記録上の出典として扱ってください。

現場データの話：MetricKitは作り直されている

MetricKitに携わるYanniは、今年はこのフレームワークにとって非常に大きな年だと述べ、新しいSwiftファーストのAPIを軸とした抜本的な作り直しについて説明しました。彼が挙げた動機はこうです。このSwift APIはSwift concurrency向けに構築されており、新しいデータの粒度を念頭に設計されている。つまり開発者は日次のメトリックレポートだけでなく、より短い間隔での細かな内訳も得られるのです。とりわけ重要な点として、彼は新しい診断とメトリックの型が新しいAPIにのみ提供されることに触れ、これこそが移行すべき本当の理由だと位置づけました。¹

Appleのドキュメントは、その主張のより厳しい側面を裏づけています。MetricKitの登場以来、開発者がエントリーポイントとして使ってきたMXMetricManagerは、現在では正式に非推奨です。Appleのリファレンスページは27.0で非推奨と記し、代わりにMetricManagerを使うよう開発者を誘導しています。² WWDC26のセッション222は、その排他性を明示しています。新しいメトリックおよび診断の型は新しいSwift APIに存在し、旧来のAPIには遡及して提供されません。³ まだMXMetricManagerを呼び出しているなら、単に古いスタイルでいるというだけではありません。Appleが今後追加していくすべてのものから切り離されているのです。

ラボではまた、現場データがどこから来てどう読むのかについての根強い混同も浮き彫りになりました。KunalとYanniはその線引きを明確にしました。Instrumentsは机上の1台のデバイスで深いローカルプロファイリングを提供する一方、Xcode OrganizerとMetricKitは実際のデバイス上の実ユーザーから集約された現場テレメトリを提供します。この2つはしばしば食い違い、その食い違いこそが要点です。Kunalは、Instrumentsで再現できるハングを追いかける一方で、Organizerはハングの実際の最大原因がまったく別のもの、机上では決して再現しないものだと示している、という開発者の姿を描写しました。¹

Organizer側における新たなレバーがMetric Goalsです。Kunalは、WWDCを去る前に開発者に最も試してほしい機能としてこれを挙げました。セッション258は、その正体を詳しく説明しています。「自分のアプリと他のアプリとの技術的・機能的な類似性に基づいて」Organizerが導き出す推奨目標値で、自身の過去のベースラインと組み合わせられ、起動時間、ハング率、ディスク書き込み、バッテリー、ストレージ、ヒッチにわたります。⁴ ラボはその価値を人間的な言葉で表現しました。Coleが描いたのは、ある動画アプリを掲げて、その高い電力消費が問題なのか、それとも一日中動画を再生することのコストにすぎないのかと問う開発者の姿です。Metric Goals以前は、誰もそれに答えられませんでした。今ではOrganizerが類似アプリと比較し、判断の拠りどころとなるベースラインを示してくれます。¹

現場データの衛生管理に関する話題がもう1つ出てきました。これははっきり述べておく価値があります。開発者が繰り返し間違えるからです。それは、起動タイマーを自前で作るな、ということです。ラボでは、プロセス生成時刻を取得するためにカーネルAPIを調べ、それを起動の基準点として使う開発者の話が紹介されました。Yanniの応答はこうでした。MetricKitとOrganizerは意図的に起動をそのように測定しない。ユーザーが実際に体感する区間を測定するのだ、と。Appleのドキュメントはその定義を裏づけています。起動時間とは「ユーザーがアイコンをタップしてから最初の画面が描画されるまでのミリ秒数」であり、静的なスプラッシュ画面の後で測定されます。⁶ 自前のタイマーはタップの瞬間を捉えられません。その時点ではまだプロセスが存在しないからです。Appleのツールはそれを捉えられ、しかもアプリに測定のオーバーヘッドを一切加えません。

チームが実際に推奨する電力ワークフロー

ラボで最も有用な手続き上の助言は、机上では決して現れない電力問題をどう捉えるかについてのものでした。KasparとKunalは1つのワークフローに繰り返し立ち返りました。ケーブルレスのトレースです。

その仕組みは、Kasparの表現によれば、Instrumentsから切断し、デバイス上で数時間にわたって動作しうるトレースを記録し、そのファイルをMacに共有してInstrumentsで開き、後から分析するというものです。その利点は実世界の条件にあります。動き回り、実際のセルラーハンドオフを経験し、デバイスを温まるに任せ、管理された机上のセッションで起こることではなく、実際に起こることを捉えるのです。Kunalはこれを、特定のバグの種類、すなわち本来スケジュールされるべきでないときにスケジュールされたバックグラウンドタスクを捉える方法として挙げました。ケーブルでつないで観察している間は見えないものです。¹

このワークフローはPerformance TraceのPower Profilerモードであり、その由来を正確にしておく価値があります。これはiOS 27の新機能ではなく、WWDC25のiOS 26の機能です。Appleはこれを「Power Profilerによるアプリの電力使用量の測定」として文書化しています。設定 > デベロッパ > Performance Traceで有効化し、コントロールセンターのコントロールでトリガーし、生成された.aarファイルをMacに共有して、Instrumentsで電力をCPU、GPU、ディスプレイ、ネットワークの各レーンにサブシステム単位で分解して読み取ります。⁵ ラボはこれを、27の目玉ではなく、推奨される定番手段として提示しました。（今年の本当に新しい兄弟分は、lookbackコレクション・ワークフローとmetalperftraceというmacOS CLIで、これらはMetalの機械学習の記事で取り上げました。これらは別の仕事のための別のツールです。混同しないでください。）

電力の議論からは、覚えておく価値のある技法があと2つあります。

• 低電力モードを貧弱なデバイスの代用として。 Terryは、新しいハードウェアしか持っていないが、古いハードウェアでアプリがどう感じられるかを知る必要がある開発者向けに、ある裏技を提示しました。低電力モードをオンにするのです。これはバッテリーを節約するためにCPUを減速させ、本来なら古いデバイスでしか見られない問題を表面化させます。彼はさらに、これは一般的な最適化の良い習慣も兼ねると付け加えました。多くのユーザーが自らの選択で低電力モードを使っており、その状態でもアプリは快適に感じられるべきだからです。¹
• サーマルとネットワークのシミュレーションにDevice Conditionsを。 ラボでは、アプリを高いサーマル状態や劣化したネットワークリンクへと強制的に追い込む「condition inducer」が繰り返し言及されました。この機能のAppleの正式名称はDevice Conditionsです。話者自身も、Xcode 27のどこにあるのか確信が持てませんでした。これは従来Devicesウィンドウにあり、Device Hubに統合される可能性があります。ラボの話者は、それが何をして何をしないかについて慎重でした。これは熱いデバイスのスロットリング挙動を人為的に誘発するもので、実際にハードウェアを加熱するわけではありません。ですから、電話を焼くことなく、サーマル圧力下でアプリがどう振る舞うか、つまりヒッチが増え、ハングが増える様子を観察できます。¹

そして、何度も出てきた揺るぎないルールがあります。Simulatorで決してプロファイリングするな、ということです。Kasparは、SimulatorはMac上で動作するため、どのデバイスを選んでもそのパフォーマンスは実機のパフォーマンスについて何も教えてくれない、と指摘しました。プロファイリングには実機を使い、買い揃えられないデバイスの多様性をカバーするためにMetricKitとOrganizerの現場データに頼りましょう。¹

パフォーマンスのトリアージ：サーマル、AIの競合、チャンク化された処理

質問がトリアージ戦略に移ると、3つの指針が際立ちました。

サーマルのプレイブック。 ある開発者が、直射日光の下、屋外で使われ、デバイスが常に熱くなるARKitとMetalのアプリについて質問しました。Kunalの回答はAPIから始まりました。ProcessInfo.thermalStateをリッスンし、それが上昇したら体験を抑制するのです。¹ パネルが提示した具体的なレバーはこうです。より軽量なネットワークリソースを要求してデバイスがデコードと解析に費やす時間を減らす、リッチなアニメーションをよりシンプルなものに差し替える、そして圧力下ではフレームレートやレンダリング解像度を下げる。Kunalは、システムは高いサーマル状態ではすでにアニメーションとディスプレイのフレームレートをスロットリングしているので、一部の緩和は自動的であり、その上に自前のものを重ねるのだと指摘しました。Marcoの締めくくりの一言はこうです。押し出すピクセルが少ないほど処理は軽くなり、「熱力学からは逃れられない」。自分のアプリの計算は制御できますが、物理は制御できません。だからこそ、自分が握っている部分を徹底的に最適化するのです。¹

Apple Intelligenceの競合モデル。 ある鋭い質問が、システムがApple Intelligenceの処理で忙しいとき、iOS 27はアプリのバックグラウンドタスクをどう優先するのかを問いました。Terryの回答は安心させるものであり、かつ具体的でした。Apple Intelligenceの多くの機能はNeural EngineやPrivate Cloud Computeで実行されるため、アプリがCPUを使っている間にAIワークロードがNeural Engineを使っているなら、両者は同じリソースを奪い合うことなく並行して動作できることが多いのです。彼が推奨した防御的な一手は構造的なものでした。バックグラウンドタスクを小さなチャンクに構成し、システムが一時停止と再開をできるようにするのです。中断されるたびにゼロからやり直さなければならない1つの巨大なジョブにしてはいけません。チャンク化された処理は、スケジューラが望むほど頻繁に動かしてくれないときでも前進します。¹

StateReportingのカーディナリティ。 新しいMetricKitのStateReporting機能では、メトリックをアプリケーションの状態でスライスできます。これは強力でありながら、誤用も容易です。ラボはカーディナリティについて明確なルールを示しました。リスト内の項目数の正確な値のような、頻繁に変化する厳密な値を報告してはいけない、ということです。代わりにバケットに分けましょう。小、中、大、というように。そうすれば後で「このサイズ範囲でパフォーマンスは悪化したか」と問えます。あらゆる個別のカウントを記録するコストを払うことなくです。Yanniの例はこうです。1,000項目のリストと1,001項目のリストには意味のある差はないので、正確な数を記録するのは純粋なオーバーヘッドなのです。分析にとって重要な境界を定義し、バケットを報告しましょう。

起動については特に、パネルはトリアージの助言を結びつける1つのメンタルモデルに収束しました。最初のフレームを描画するために必要な最小限のデータを見極め、それだけを読み込み、ほかはすべて後回しにする、というものです。Terryは、よくある失敗に対して警告しました。大量のバックグラウンド処理を切り出しておきながら、そのすべてが終わるまでメインスレッドをブロックしてしまうという失敗です。これは起動中にアプリ全体を凍りつかせます。それが自分の問題かどうかを確かめるには、KasparはSystem Traceテンプレートのメインスレッドビューを挙げました。そこではブロックされたメインスレッドが直接表れます。パネルはまた、System Traceがスレッドの優先度、プリエンプション、コンテキストスイッチのヒストグラムを表面化させるとも説明しましたが、それらをドキュメント化されたInstruments 27の機能として確認することはできていません。ですから、これは仕様というより、ツールについてのラボの説明として受け取ってください。

ツールに関するメモ：Foundation Modelsのインストルメントと初心者の入り口

ラボを締めくくるツール関連の項目が2つあります。

Foundation Modelsの機能を出荷する開発者に向けて、Kasparは、このInstrumentsのツールが昨年の基本的なトークン数のメトリックから、プロンプトとレスポンスを捕捉し、いくつのトークンがキャッシュされているかを示す本格的なデバッグ用インストルメントへと成長したと説明しました。¹ WWDC26の各セッションを横断した正確な姿はこうです。Foundation Modelsのインストルメントは、トレースの実行中にデバイスからプロンプトとレスポンスのデータを捕捉します（セッション243。なお、捕捉には機微な情報が含まれうるため、本番環境ではオフになっている点も指摘しています）。⁷ キャッシュされたトークン数は、モデルのレスポンスに対するusage APIを通じて得られます（セッション241）。⁸ 2つの異なる仕組み、すなわちトレースのタイムライン用のものとレスポンス単位の集計用のもので、数字を読むときに区別しておく価値があります。

初心者向けに、パネルはどこから始めるべきかについて一貫していました。Marcoは、最初のひと当たりとしてフレームグラフ・ビューでのTime Profilerを推奨しました。フレームグラフは、アウトライン形式の数字を読ませる代わりに、コールスタックがどれだけコストになっているかを視覚的に示してくれるからです。Kasparは次のステップとしてTop Functionsモードを付け加えました。最も重い関数のフラットなリストで、深くネストしたコールツリーをたどることなく、ひと目で問題児を見つけられます。¹ そしてパネルが最も繰り返したメタな助言はこうです。最適化する前に測定せよ。Kunalの言い方では、最も多い落とし穴はテレメトリの不足であり、それが開発者を、実質的な成果を生まない領域の最適化へと導きます。起動とバックグラウンド処理に関するTerryの当然の帰結はこうです。半分の頻度で送られるネットワークリクエストは、ただで得られる電力の勝ちなのだ、と。どれか1つのサブシステムに飛び込む前に、全体像を見ましょう。

重要なポイント

今日アプリを出荷するiOS開発者へ： - MXMetricManagerから新しいMetricManagerのSwift APIへ移行しましょう。旧来のものは27.0で非推奨であり、新しいメトリックと診断の型は新しいAPI専用です。²³ - Xcode Organizerを開き、起動、ハング、バッテリー、ヒッチ、ディスク書き込み、ストレージについて、類似アプリのベースラインと自分のMetric Goalsを照らし合わせましょう。⁴ - 起動を自前のタイマーで測るのはやめましょう。MetricKitとOrganizerはアイコンのタップから測定しており、それは自分のプロセスには見えないものです。⁶

パフォーマンスと電力のトリアージへ： - Power Profilerのケーブルレストレース（iOS 26、設定 > デベロッパ > Performance Trace）を使って、机上では決して再現しないバックグラウンドタスクと実世界の電力問題を捉えましょう。⁵ - Simulatorではなく実機でプロファイリングし、所有していない古いハードウェアの代わりとして低電力モードを使いましょう。¹ - ProcessInfo.thermalStateをリッスンし、圧力下ではフレームレート、解像度、アニメーションのリッチさ、ネットワークの負荷を抑えましょう。¹

AI機能を構築するチームへ： - バックグラウンド処理をチャンクに分割し、スケジューラが一時停止と再開をできるようにしましょう。CPUの処理は、Neural EngineやPrivate Cloud ComputeのAIワークロードと競合せずに並行して動作できることが多いです。¹ - StateReportingの値はバケットに分けましょう（小、中、大）。速く変化する正確なカウントは決して報告しないでください。¹ - Foundation Modelsについては、プロンプトとレスポンスの捕捉のためにInstrumentsのツールを読み（セッション243）、レスポンスのusage APIからキャッシュされたトークン数を取得しましょう（セッション241）。⁷⁸

このラボは、シリーズの掘り下げた記事と自然に対になります。メトリックをアプリの状態でスライスすることについてのiOS 27のMetricKitとStateReporting、新しい差分とハング検出のワークフローについてのInstruments 27とアプリの応答性、そして現場データと机上のプロファイリングがなぜ食い違うのかについてのパフォーマンスの盲点です。シリーズ全体のハブはApple Ecosystem Seriesです。

参考文献