Unityエンジンにおけるモバイルゲーム開発のAdaptive Performanceシステムの詳細な分析
現代のモバイルゲーム開発エコシステムにおいて、ハードウェア容量の幾何学的な増加により、グラフィックの限界を押し広げるゲームをポータブルデバイス上で実行できるようになりました。しかし、モバイルプラットフォームは、デスクトップやコンソールシステムとは異なり、アクティブ冷却機構（ファンや水冷システム）を欠いています。System-on-Chip（SoC）アーキテクチャでは、中央演算処理装置（CPU）、グラフィックス処理装置（GPU）、メモリコントローラー、およびネットワークモジュールがミリ単位の領域内に共存しています。¹これらのコンポーネントを高クロック速度で継続的に動作させると、必然的に膨大な量の廃熱が発生します。
デバイスの温度がクリティカルな閾値に達すると、オペレーティングシステムは、ハードウェアを物理的損傷から保護し、バッテリーの化学構造の劣化を防ぐために、「Thermal Throttling（サーマルスロットリング）」と呼ばれる防御メカニズムを作動させます。²このメカニズムは、CPUとGPUのクロック周波数を突発的かつアグレッシブに低下させます。ゲーム開発者にとって、これは1秒あたりのフレーム数（FPS）の突然の低下、入力遅延（input lag）の増加、そしてプレイヤー体験の完全な崩壊を意味します。³まさにこの時点で、ソフトウェアとハードウェアの間の架け橋となり、ゲームエンジンがデバイスの熱力学にプロアクティブに適応することを目指すUnity Adaptive Performanceシステムが稼働します。本レポートは、開発プロセスにおいて頻繁に遭遇する設定警告の解剖から始まり、Adaptive Performanceパッケージの基本アーキテクチャ、スケーリングアルゴリズム、統合戦略、およびそれがもたらす最適化の利点を、学術的および専門的な深度で検証します。
「Adaptive Performance Settings」警告の根本原因と設定ソリューション
Unityゲームエンジンで新しいモバイルプロジェクトを開始するとき、または既存のプロジェクトをモバイルプラットフォーム（Android、iOS）向けにビルドするように設定するとき、コンソール画面には頻繁に次のような警告またはそれに類するメッセージが表示されます。「No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings」。⁴開発者の開発プロセスを停滞させるこの警告の背後にある根本的な理由は、Unityのモジュール式パッケージ管理システムとハードウェア抽象化レイヤー（Hardware Abstraction Layer）の動作原理です。
Unityは、特に「Mobile 2D」、「Mobile 3D」、「Universal Render Pipeline (URP)」などのテンプレートでプロジェクトを作成する場合、Adaptive Performanceの基本パッケージをプロジェクトにあらかじめインストールされた（pre-installed）状態で含めます。⁵しかし、基本パッケージ自体は、デバイスのハードウェアからデータを読み取ったり、オペレーティングシステムに干渉したりできるネイティブ（native）ライブラリを単体では持っていません。パッケージを機能させるためには、対象のオペレーティングシステム（Androidなど）やテスト環境に固有の「Provider（プロバイダー）」モジュールをプロジェクトに追加して設定する必要があります。⁶プロバイダーモジュールが欠落している場合、基本パッケージは実行時（runtime）にハードウェアセンサーにアクセスできず、この警告をスローして開発者に通知します。警告の解決策と設定手順は、開発対象のプラットフォームと使用しているUnityのバージョンによって、大きな方法論的違いを示します。
開発プロセスで遭遇するこの警告の解決策は、プラットフォームベースで対処する必要があります。オペレーティングシステムのハードウェアAPIへのアクセス許可が異なるため、Unityが提供するソリューションも異なります。
ターゲットプラットフォーム警告の技術的原因適用すべき解決方法論AndroidADPFまたはSamsung GameSDKと通信するネイティブプラグインがプロジェクトに存在しないこと。Unity Package Managerを介して、Adaptive Performance Android Provider、またはデバイス固有のターゲットがある場合はSamsung (Android) Providerパッケージをインストールする必要があります。⁶その後、Edit > Project Settings > Adaptive Performanceメニューから該当するプロバイダーを有効にする必要があります。iOS (Apple)iOSエコシステムにおいて、Adaptive Performance用のUnityがサポートする公式ハードウェアプロバイダー（provider）が存在しないこと。⁴プロジェクトにMobile機能セットを追加すると、Adaptive Performanceが依存関係（dependency）として含まれ、削除することはできません。iOSビルドの場合、この警告は無害であり、無視（ignore）するか、依存関係を断つためにパッケージマネージャーからMobileモジュールを削除することができます。⁴デスクトップエディター (PC/Mac)WindowsまたはmacOSオペレーティングシステムにおいて、モバイルデバイス特有のサーマルセンサーやSoCアーキテクチャが存在しないこと。開発用コンピュータでモバイル環境をシミュレートするために、Simulator (Desktop) Providerをインストールし、Device Simulatorウィンドウを使用して仮想的な熱環境を作成する必要があります。²Unity 6 (Build Profiles)Unity 6で導入されたビルドプロファイル（Build Profiles）において、メインプロジェクトのAdaptive Performance設定に加えて、プロファイル固有の設定が忘れられていること。File > Build Profilesメニューで選択されたプラットフォームに対し、Add Settings > Adaptive Performance Settingsボタンをクリックしてプロバイダーを割り当てる必要があります。Unity 6.000.xバージョンにおいてこれらの設定を追加しない場合、「No default loader found」エラーが発生します。⁹
この警告は、本質的にはコンパイル（compile）エラーではなく、最適化の欠如の通知です。開発者はこの警告を無視してゲームをデバイスで実行することができますが、その場合、ゲームはハードウェアの熱状態に関して完全に盲目（blind）な状態で動作し、必然的にオペレーティングシステムの容赦ないサーマルスロットリングの干渉にさらされます。
Adaptive Performanceシステムのアーキテクチャとプロバイダー（Provider）エコシステム
Adaptive Performanceは、ゲームエンジンの意思決定メカニズムと物理ハードウェアの間に双方向の通信ブリッジを確立します。このアーキテクチャのデータ収集レイヤーは、プロバイダー（providers）によって構成されます。Androidエコシステムは極めて断片化（fragmented）されているため、単一のハードウェアAPIであらゆるデバイスで動作させることが不可能です。Unityはこの問題を、異なるハードウェアフレームワーク（frameworks）に統合される特定のプロバイダーによって克服しています。
Android Dynamic Performance Framework (ADPF) の統合
Unityの基本「Android Provider」モジュールは、GoogleがAndroid 12オペレーティングシステム以降で導入したAndroid Dynamic Performance Framework (ADPF) アーキテクチャに基づいて構築されています。²ADPFは、ゲームとオペレーティングシステムの熱管理の間で直接的な対話の確立を可能にする画期的なAPIセットです。従来のアプローチでは、オペレーティングシステムはゲームのどのフレームがどれだけのプロセッサパワーを必要としているかを推測しようとしますが、これらの推測は多くの場合、不適切なCPUクロック速度の割り当てにつながります。
一方、Unity Adaptive Performance Androidプロバイダーは、「Performance Hint API」（パフォーマンスヒントインターフェース）を介してオペレーティングシステムに連続的なデータストリームを提供します。⁶エンジンは、各フレームがレンダリングされるたびに、そのフレームのターゲット時間（例えば60 FPSをターゲットとする場合は16.6ミリ秒）と、CPUおよびGPUがこのフレームを完了するのに費やした実際の時間（actual duration）をADPFシステムに報告します。⁶この精緻なフィードバックループのおかげで、Androidオペレーティングシステムは、ゲームが必要とする分だけのCPUコアの周波数を引き上げます。デバイスの温度が上昇し始めると、オペレーティングシステムは熱に関する警告をUnityに返送するため、ハードウェアレベルでスローダウンが発生する前にエンジン内のグラフィックステュースケーラーが作動します。⁶Android Providerの安定版である1.2以降のバージョン（Pixelデバイスの制限を超えるバージョン）は、Adaptive Performance 5.0およびUnity 2021.3以降でサポートされています。⁶
Samsung GameSDKと特定のハードウェア最適化
Samsungは、Androidエコシステムの中で最大の市場シェアの1つを持っているため、自社ハードウェアの限界を押し広げるためにGameSDKと呼ばれるカスタマイズされたハードウェアインターフェースを提供しています。UnityのAdaptive Performance Samsung (Android)プロバイダーは、標準のADPF機能を超えて、Samsung SoCの深部に直接踏み込んだメトリクスの取得を可能にします。²
Samsungプロバイダーは、Android 10以降のオペレーティングシステムを搭載し、GameSDK 3.2以降のバージョンをサポートする膨大な数のデバイスをカバーしています。このカバー範囲は、エントリーレベルからフラッグシップデバイスにまで及び、開発者に非常に幅広い最適化領域を提供します。
サポートされているSamsung Galaxyシリーズモデル (GameSDK 3.2+ / Android 10+)Galaxy SシリーズS9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Galaxy NoteシリーズNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Galaxy Z (折りたたみ) シリーズZ Fold2¹³Galaxy AシリーズA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Galaxy XcoverシリーズXcover 4s, Xcover Pro¹³
これらのデバイスが提供する最も重要なハードウェア的利点の1つは、「可変リフレッシュレート」（Variable Refresh Rate - VRR）テクノロジーです。¹³VRRのサポートは、現時点ではGalaxy S20、S21、S22、およびNote 20デバイスでアクティブに使用できます。¹³Adaptive Performanceは、デバイスが限界に達したことを検出し、ゲームのFPS値を例えば60から45に下げることを決定すると、Samsung VRR APIにコマンドを送信して、画面の物理的なリフレッシュレートも45 Hzに低下させます。¹⁶この同期は、画面のティアリング（screen tearing）を防ぐだけでなく、画面パネルの過剰な電力消費を防ぎ、デバイスのより迅速な冷却に大きく貢献します。さらに、Samsungプロバイダーは、GameSDK 3.5（Android 12）以降を搭載したデバイスにおいて、プロセッサのbig.LITTLEアーキテクチャにおけるビッグコアおよびリトルコアの負荷分散を示す「Cluster Info」データへのアクセスも提供します。¹³
サーマルメトリクスとボトルネック（Bottleneck）検出アルゴリズム
Adaptive Performanceがプロアクティブな最適化を提供できる背景にあるエンジニアリングは、継続的にデータを収集するセンサー分析システムに依存しています。ゲームの実行時に作成されるIAdaptivePerformanceインターフェース（interface）は、ハードウェアから2つの主要なカテゴリでデータセットを読み取ります：サーマル状態のフィードバック（Thermal State Feedback）とフレームタイミング（Frame Timing）です。これらのデータに基づき、システムのその時点のパフォーマンスを制限している主要な要素（ボトルネック）が何であるかが決定されます。
サーマルフィードバックと警告レベル
デバイスの熱状態は、単純な摂氏の読み取り値のみで評価されるわけではありません。熱力学は、正規化され、分析的に処理された3つの異なるメトリクスを通じて監視されます ²：
最初のメトリクスであるTemperatureLevel（温度レベル）は、0.0から1.0の間で正規化された（0.0は標準の室温/動作温度、1.0は絶対的な最大熱閾値）浮動小数点（float）値です。²開発者はこの値を使用して、デバイスの加熱状態をグラフィカルなバーとしてゲームのUI内でプレイヤーに提示したり、独自の最適化ロジックを構築したりすることができます。
2番目のより予測的なメトリクスであるTemperatureTrend（温度トレンド）は、-1.0から1.0の間で
変動し、温度の数学的微分、すなわち変化速度を表す値です。²値が1.0であることは、デバイスが非常に急速に加熱していることを示している一方、0の値は温度が一定に保たれていること、-1.0はアグレッシブな冷却期間に入ったことを示しています。システムがこれらのトレンドを検知して有効な平均を取得するには、通常約10秒の分析プロセスが必要です。²3番目で最もクリティカルなメトリクスは、WarningLevel（警告レベル）と呼ばれる、オペレーティングシステムの熱状態に対する応答を決定するカテゴリカルな分類です。²
警告レベル (WarningLevel)オペレーティングシステムの状態ゲームエンジンにおけるAdaptive Performanceの反応NoWarning (0)デバイスは最適な温度です。サーマルスロットリングは発生していません。ゲームは、ターゲットとする最高解像度、フレームレート、視覚品質でレンダリングすることが許可されます。²ThrottlingImminent (1)熱容量が満杯に近づいています。オペレーティングシステムはまだハードウェア周波数を低下させていませんが、危険が間近に迫っています。プロアクティブな介入が開始されます。視覚的影響の少ないスケーラーが作動し（例えば影の距離の短縮）、デバイスが次のフェーズに移行することが防止されます。²Throttling (2)ハードウェアがクリティカルな温度に達し、オペレーティングシステムは自らを守るためにCPU/GPUクロック周波数をアグレッシブに低下させました。最もアグレッシブな最適化のコストが支払われます。ターゲットフレームレート（Target FPS）が劇的に低下し、メインのレンダリング解像度が制限され、デバイスが通常の温度に戻るためのラディカルな妥協が行われます。²
フレームタイミングとボトルネックの検出
ゲームが毎秒60フレームの速度に到達できない場合、複数のハードウェアの非力さに起因している可能性があります。問題がグラフィックスプロセッサ（GPU）の非力さによるものか、それともメインプロセッサ（CPU）の計算能力の枯渇によるものかを見極めることが、最適化の第一歩です。Adaptive Performanceは、この分析を行うために、averageFrameTime（平均総フレーム時間）とaverageGpuFrameTime（平均GPU実行時間）のデータを毎フレーム追跡します。CPU時間には、Unityのメインスレッドがゲームロジックを実行し、レンダリングスレッドがデータをGPUへ送信するための準備（ドローコールバッチ処理など）を行うプロセスが含まれます。重要な詳細として、CPU時間の測定には、オペレーティングシステムレベルのブロックや、CPUがGPUの処理終了を待つためにアイドル状態で過ごした時間（アイドル/待機時間）は含まれません。これらの時間の分析結果に基づき、システムは現在のボトルネック（PerformanceBottleneck）を次の4つのカテゴリのいずれかに分類します： ● CPU：ゲーム内のAIアルゴリズム、複雑な物理計算、または過剰な数のオブジェクトインスタンス化がプロセッサに負担をかけています。
● GPU：多層の透明度エフェクト（オーバードロー）、高解像度テクスチャの読み込み、重いポストプロセッシングエフェクト（SSAOやBloomなど）がグラフィックスユニットを制限しています。
● TargetFrameRate（フィルレート）：システムはすでに目標フレームレートに達しており、ハードウェア的な詰まりはなく、ハードウェアの潜在能力を下回って動作している場合でも十分に対応できています。
● Unknown：遅延の原因が正確に特定できない中間的な状況です。
開発者は、PerformanceStatus.PerformanceBottleneckChangeEventイベントに登録する（デリゲートパターンを使用する）ことで、ゲーム中にボトルネックの状態が変化した瞬間を捉え、それに応じたアルゴリズム的な対応を行うことができます。例えば、ボトルネックが突然CPUに移行した場合、オープンワールド内のAIユニットの視線（レイキャスト）の走査頻度を毎秒60回から15回に下げることで、プロセッサにかかる数学的な負荷を瞬時に軽減できます。
意思決定および実行エンジン：インデクサーとスケーラー
Adaptive Performanceシステムが自律的に動作することを可能にするメカニズムは、「インデクサー」と呼ばれる頭脳と、「スケーラー」と呼ばれる実行機関という2つの主要なコンポーネントが完璧な調和のもとで連携することに基づいています。
インデクサーのメカニズム
インデクサーは、デバイスから取得した複雑な熱の傾向とボトルネックのデータを数学的フィルターに通し続け、その瞬間のゲームの「品質インデックス」を計算する中央コーディネーターです。インデクサーの主な役割は、ハードウェアのわずかな温度やFPSの変動ごとにゲームの品質を常に変更することで視覚的な不整合（発振現象）が生じるのを防ぐことです。この安定性を確保するために、Project Settings内でThermal Action Delay（サーマルアクション遅延）とPerformanceAction Delay（パフォーマンスアクション遅延）を秒単位で定義できます。システムはボトルネックを検知しても、定義されたこの遅延時間の間はその状態が永続的であることを確認し、その後アクションの決定を下し、接続されているスケーラーに品質を下げる（StateAction.Decrease）ようシグナルを送信します。
スケーラーの数学的および視覚的影響の分析
スケーラーは、Unityのレンダーパイプラインまたは物理エンジンの特定機能を実行時に変更するスクリプトです。各スケーラーのデフォルトレベルはゼロです。インデクサーからの「品質を下げる」シグナルごとにこのレベルが上昇し、レベルが上がるにつれてスケーラーが制御する機能の詳細が減少します。スケーラーがいつ、どの順序で稼働するかは、3次元の決定マトリックスによって決定されます：
1. ターゲットボトルネック（Targeting Bottleneck）：分析の結果、ボトルネックがGPUであることが判明した場合、インデクサーはCPUを最適化するスケーラーをスキップし、直接GPUをターゲットとする（解像度など）スケーラーを強制的に稼働させます。
2. 最低レベル（Lowest Level）：まだレベルが引き上げられていない（元の品質を維持している）機能が優先されます。
3. 視覚的影響（Visual Impact）：機能の品質が低下したときにプレイヤーがそれに気づく可能性です。低（Low）、中（Medium）、または高（High）として分類されます。システムは常に視覚的影響が低い機能から順番に削減を開始します。
システムは、標準レンダーパイプラインとUniversal Render Pipeline（URP）の両方に対して、非常に幅広いスケーラーの選択肢を提供します。以下の表は、これらのスケーラーのハードウェアターゲットとアプリケーション内での理論的な影響を詳細に説明しています。
スケーラークラス ボトルネックターゲット 視覚的影響 レンダーパイプラインにおける理論的および実践的影響 AdaptiveFramerat e CPU / GPU / Fillrate 高 ゲームのApplication.targetFr ameRate変数を制限内で変更します。特にVSyncが無効な場合に効果的です。60 FPSから30 FPSへの低下は、チップ上のすべてのコンポーネントのアイドル時間を増加させ、劇的な冷却期間を作り出します。 AdaptiveResolutio n GPU / Fillrate 高 画面処理解像度のスケール（Resolution Scale）を動的に低下させます。
URPプロジェクトではRender Scaleを介して動作します。ピクセルフィルレートを幾何学的な割合で減少させるため、GPUの熱負荷を打破するための最も強力な武器となりますが、画像の鮮明さを直接損ないます。 AdaptiveLOD CPU / GPU 中 シーン内の3Dモデルの詳細度（Level of Detail - LOD）の切り替え距離（LODバイアス）を操作します。カメラがモデルに近づいても低ポリゴンバージョンが画面に残るようにすることで、CPUドローコールとGPU頂点計算を削減します。 AdaptiveShadow mapResolution GPU 中/低 URPでシャドウマップのピクセル解像度を低下させます。画面上で多くの動きがある場合、影の輪郭のピクセル化は認知的に認識するのが困難な状況であるため、品質を犠牲にすることなくGPUのメモリ帯域幅を解放します。 AdaptiveShadowC ascade CPU / GPU 中 URPの方向性ライトのカスケード数を減らします。影のカスケードのそれぞれは、シーン内の影を落とするオブジェクトをもう一度レンダリングする（ドローコール）ことを必要とします。カスケード数の減少はCPUのボトルネックを直接軽減します。 AdaptiveViewDistance CPU / GPU 高 メインカメラのファークリップ面（far clip plane）を狭めることで、遠くのオブジェクトがレンダリングフローに一切含まれないようにします（視錐台カリング）。特にオープンワールドゲームにおいて最も重要な最適化ステップの1つです。 AdaptiveLayerCull ing CPU / GPU 中 一般的な視界を狭める代わりに、特定のUnityレイヤーの可視性距離を調整します。
例えば、環境詳細（草、小さな装飾品）レイヤーのレンダリング距離を制限することで、プレイヤー周辺の大きな構造物を保護しつつ、細かな詳細を削除してパフォーマンスを向上させます。 AdaptivePhysics CPU 高 Unityの物理エンジン（PhysXまたはBox2D）の更新ステップ（fixedDeltaTime）や反復回数を変更することで、CPUの負荷を軽減します。物理計算はCPUベースのボトルネックの最大の原因の一つです。 AdaptiveBatching CPU 低 動的バッチング（Dynamic Batching）プロセスを制御します。過剰な頂点計算を必要としない状況でCPUを楽にします。 AdaptiveDecals CPU / GPU 低 URPシステムにおいて、壁の弾痕や血痕などのデカールのレンダリング距離や数を制限し、マテリアル描画段階でのオーバードローの負荷を軽減します。
開発者はデフォルトのスケーラーにのみ依存する必要はありません。ゲームの特定のメカニクスに適した「カスタムスケーラー」を開発することは、強く推奨されるプラクティスです。カスタムスケーラーを書くには、AdaptivePerformanceScalerクラスを継承し、VisualImpact、Target、MaxLevelなどの基本プロパティに加え、OnLevel()メソッドをオーバーライドするだけで十分です。例えば、霧に包まれた環境を舞台にしたゲームでは、カスタムスケーラーを作成して熱の上昇とともに霧の密度を高めることができます（Adaptive Fog）。これにより、プレイヤーの視界が自然に狭まる一方で、バックグラウンドでカメラの描画距離が短縮され、深刻な最適化の錯覚が生み出されます。
パフォーマンスコントロールモードとクロック周波数管理
Adaptive Performanceは、ゲームエンジン内のグラフィックス機能を削減するだけでなく、オペレーティングシステムがCPUおよびGPUに供給する電力やクロック周波数に間接的または直接的に介入する能力も備えています。プロセッサを最大クロック速度で動作させると、漸近的な非効率性が生じます。つまり、得られるわずかな追加の処理能力の代償として、膨大な量のエネルギーが消費され、熱が生成されます。
このエネルギーバランスを管理するために、Adaptive Performanceインターフェースには3つの異なるコントロールモード（PerformanceControlMode）が用意されています：システム、手動、自動。
システムモード（System Performance Control）：Androidプロバイダー以外のシステム（デスクトップシミュレーションなど）で適用されるデフォルトのモードです。オペレーティングシステムが従来の方法でCPU/GPU周波数を独自に決定し、Adaptive Performanceはハードウェアに干渉せず、アプリ内のグラフィックスのみを削減します。
手動モード（Manual Performance Control）：開発者が
Instance.DevicePerformanceControl.CpuLevelおよびGpuLevelの変数を0から最大レベルの間で直接割り当てることができるモードです。このコントロールモードの使用は、非常に特殊なベンチマークテストを除いて決して推奨されません。モバイルハードウェアの熱的制約とバッテリー放電特性についての深い知識を持たない開発者が、CPUレベルを常に高く維持した場合、デバイスは急速に過熱し、オペレーティングシステムが防御メカニズムを発動してゲームを「スロットリング」フェーズに閉じ込め、バッテリーが無意味に消耗されます。自動モード（Automatic Performance Control）：最も安全で、最も効率的であり、使用が強く推奨されるコントロールモードです。開発者が行うべき唯一のことは、
Application.targetFrameRateでゲームの目標フレームレート（30や60など）を設定することです。自動モードは、バックグラウンドでデバイスの温度、レンダリング時間、および稼働環境（メニューにいるのかゲームプレイ中なのか）を分析します。ゲームが60 FPSの目標に非常に楽に到達している場合、プロセッサを不要にフル稼働させる代わりに、CPUとGPUのクロック速度を静かに引き下げます。フレームレートは60のまま維持されますが、ハードウェアの電力消費が大幅に削減され、ゲームが涼しく保たれ、バッテリーが何時間も持続する（Battery Life Preservation）ようになります。
一時的な電力負荷：ブーストモード
モバイルゲームの特定の瞬間においては、持続可能なパフォーマンスよりも、瞬間的に非常に大きな処理能力が必要とされます。このような特定のシナリオのために、Adaptive Performanceには「Boost」APIが組み込まれています。ブーストモードが呼び出されると、CPUまたはGPUの最小（minimum）動作周波数が一時的に最大（maximum）動作周波数に等しくなり、ハードウェアは最大ポテンシャルで動作するように強制されます。
ブーストモードを戦略的に使用すべき箇所は以下の通りです：
● ゲームやステージの開始時のロード画面（Loading Screens）において、メモリに読み込まれる重いモデルの読み込み時間（load time）を最小限に抑えるため。
● ネットワーク（Network）経由でダウンロードされた大きなパッケージの解凍や、非同期データ処理オペレーション中に発生する待ち時間を排除するため。
● シェーダーコンパイル（Shader Compilation）やプロシージャルコンテンツ生成の段階でプレイヤーが遭遇する可能性のある数秒間の小さなカクつき（hitches）を防ぐため。
しかし、ブーストモードの有効化はデバイスのバッテリーから膨大な電流を引き出し、SoCの温度を瞬時に上昇させます。オペレーティングシステムがすでにThrottling（ボトルネック）フェーズに入っている場合（デバイスが過熱している場合）、ハードウェアの損傷を防ぐために、Unityからのブースト要求や手動のCPU/GPUレベル調整コマンドはオペレーティングシステムによって直接拒否され、制御が「システムモード」に強制的に移行されます。開発者がこのインターフェースを、プレイヤーが受動的に待機しているロード画面や数秒間の時間内に限定して使用することが極めて重要です。
開発者インターフェース：C# APIの利用とビジュアルスクリプティング
Adaptive Performanceパッケージの柔軟性は、開発者がコードを1行も書かずに自律システムを使用することも、ゲームの核心に入り込む独自のロジックを構築することも可能にする点にあります。
C# APIを通じたイベント駆動（Event-Driven）プログラミング
システムの熱データにプログラムからアクセスしたい開発者は、パッケージと一緒に作成されるシングルトンオブジェクトである UnityEngine.AdaptivePerformance.Holder.Instance（または新しいバージョンの Mobile.AdaptivePerformance.Holder）を通じてデータにアクセスします。18 特に、デバイスがボトルネックに陥ろうとしていること（ThrottlingImminent）を検出するために、IThermalStatus.ThermalStatus.ThermalEvent イベント（delegate）をリッスンします。2
イベントがトリガーされたとき（例えば、発熱アラームが来たとき）、状態がスイッチケース（switch-case）構造で分析され、ゲームメカニクスに介入します。2 警告レベルが Throttling の場合、フレームレートは60から15または30に下げられます。警告がない場合は、再び60のターゲットに戻ります。2 同様に、ボトルネックがCPU側にある場合、特殊なスクリプト（script）によってマップ内のアクティブなAIエージェントの一部を非アクティブ化し、プロセッサの負荷を即座に軽減できます。2
ビジュアルスクリプティング（Visual Scripting）の統合
プログラマーではないテクニカルアーティスト（technical artists）やゲームデザイナー向けに、Unity 5.0以降のバージョンでは、Visual Scriptingパッケージを通じてC# APIへの完全なサポートが提供されています。29
プロジェクトにVisual Scriptingパッケージを含めた後、Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units の手順に従って、Adaptive Performanceノード（nodes）がFuzzy Finderインターフェースに追加されるようにする必要があります。27
この統合により、一連の特殊なノードにアクセスできるようになります 30：
● サーマルノード：On Thermal Metric ノードは、デバイスの熱警告レベル、温度パーセンテージ（Temperature Level）、および温度トレンド（Trend）が変化したときに即座にトリガーされます。このノードの出力端子は、シーン内の重い光源やパーティクルシステムを直接オフにするロジックに接続できます。
● パフォーマンスノード：On Bottleneck ノードは、ボトルネックがCPU、GPU、またはフィルレート（Fillrate）のどれであるかをシグナル伝達します。また、Frame Timing および FPS ノードは、ゲーム画面にリアルタイムのパフォーマンスデータを描画するのに最適です。Cluster Info ノードのおかげで、big.LITTLE アーキテクチャのコア負荷を読み取ることができます。
● ブーストおよびレベルノード：ビジュアルスクリプティンググラフのシーン読み込みブロックの先頭に Set Boost ノードを追加することで、コードを書かずに読み込み速度を最大化できます。また、Get Performance Level を使用して、現在のプロセッサ状態を読み取ることができます。
テスト、プロファイリング、および最適化のメソッド論
Adaptive Performanceシステムをプロジェクトに追加するだけでは、すべての問題が解決されるわけではありません。正しく設定されていないシステムは、ゲームのグラフィック品質を早々に損なうか、あるいは全く効果を発揮しない可能性があります。開発プロセスは、科学的な測定とベンチマークのメソッド論（profiling and benchmarking）に基づく必要があります。
ベースライン（Baseline）の作成とA/Bテスト
GoogleとUnityのエンジニアの共通の最適化プラクティスによると、最初に行うべきステップは、ADPFまたはAdaptive Performanceが有効になる前のゲームのパフォーマンスを測定すること（Baseline）です。6 ゲームは、ターゲットとする最低システム要件（min-spec）を満たした物理的なモバイルデバイスにインストールし、デバイスが熱くなるまで約20分間プレイする必要があります。21 このテスト中、Unity Profilerツールをワイヤレスネットワーク（Wi-Fi）経由でデバイスに接続し（Autoconnect Profiler）、FPSの低下が始まる時間や Frame Time の値を記録する必要があります。1
次に、Adaptive Performanceシステムがデフォルトのスケーラーでプロジェクト内で有効化され、同じテストシナリオが最初から実行されます。6 Profilerモジュールの新しい「Adaptive Performance」タブを通じて、デバイスがどのタイミングで ThrottlingImminent 警告を発したか、システムがどのスケーラー（例：AdaptiveResolution）を動作させたか、そしてそれがCPU/GPU時間にどのように影響したかを最初のテストと並べて検証する必要があります。2 開発者は、「ゲームは10分目でもまだ60 FPSを維持しているが、解像度が下がりすぎている」などの発見をした場合、Indexer内のスケーラーウェイトを調整し、ゲーム固有の微調整（fine-tuning）を行う必要があります。6
デスクトップ環境でのシミュレーション：Device Simulator
デバイスでのテストは不可欠ですが、物理的なスマートフォンの加熱と冷却を待つことは、コーディング段階でのイテレーション速度を低下させます。この状況を克服するために、Simulator (Desktop) Provider が開発されました。2 デスクトップ開発コンピュータで Window > General > Device Simulator ウィンドウを開くことで、仮想デバイスのバッテリー残量、サーマルトレンド、およびボトルネックを人工的（artificial bottlenecks）にトリガーできます。2 開発者はワンクリックで仮想デバイスの状態を Throttling フェーズに移行させ、自身が記述したカスタムスケーラー（Custom Scalers）がゲーム内の霧の密度やモデルの詳細度（LOD）をどのように変化させるかを、数秒でリアルタイムにテストできます。2
従来の最適化アプローチとのシナジー
Adaptive Performanceは魔法のアルゴリズムではありません。基礎が誤って構築されたゲームを単独で救うことはできません。このシステムは、従来のモバイル最適化プラクティスと組み合わせることで、巨大な乗数効果を生み出します。1
● ゲームのテクスチャ（textures）は2のべき乗（POT - Power of Two）のサイズで設計し、ASTCやETC2などのモバイルハードウェア圧縮フォーマットを使用する必要があります。8
● 実行時に変更されないモデルやテクスチャの Read/Write Enabled オプションを無効にし、CPUおよびGPUメモリに不要なコピーが保持されないようにする必要があります。31 メモリ消費量（memory bandwidth）は発熱の最大の原因の一つです。1
● モバイルハードウェア上の加速度計（accelerometer）センサーがゲームによって積極的に使用されていない場合（レーシングゲームではない場合など）、Player Settingsから加速度計のポーリング周波数を下げるか無効にすることで、オペレーティングシステムの大きな負担を取り除き、サーマルエンベロープ（thermal envelope）を広げることができます。31
● デバイスカメラのカリングマトリックス（Occlusion Culling）を慎重にベイク（baked）し、カメラの視界に入っていないが壁の背後にある何万ものポリゴンを持つモデルが、グラフィックプロセッサに送信される前（draw call）にCPU上でカリングされるようにする必要があります。3
これらすべての従来の対策によって発熱までの時間が15分に延長されたゲームが、最後の防衛線である Adaptive Performance の AdaptiveResolution または AdaptiveFramerate スケーラーによってサポートされるとき、それは何時間も持続し、60 FPSから45 FPSへの低下がプレイヤーに全く気づかれない、完璧で持続可能なモバイルの傑作へと変貌します。
モバイルハードウェアに冷却ファンがないことは、ゲーム開発者にシリコンの熱的限界とのチェスを強います。「Adaptive Performance Settings」のような単純なプロバイダーのセットアップ警告から始まるこの技術的旅路は、オペレーティングシステムの電力管理バルブへのアクセス、サーマル分析派生物の読み取り、およびレンダリングパイプライン内の品質アルゴリズムをリアルタイムで操作する習熟へと到達します。最適化プロセスは、ピークパフォーマンス（peak performance）に到達することではなく、滑らかなフレームレートの持続可能性（sustained performance)に焦点を当てたとき、プレイヤーの満足度を最大化し、モバイルプラットフォームでの長期的な成功の鍵を開くのです。
*情報 : 画像は Google Gemini によって生成されました。