CA.unityはサイバーエージェントが運営するUnityをテーマにした勉強会です。サイバーエージェントのサービス開発者と社外の開発者を交えて、Unityに関する知見を共有する場となります。CA.unity #9では、ユニティ・テクノロジーズ・ジャパン株式会社様とサイバーエージェントが登壇いたします。
※CA.unityは、Unity Technologiesまたはその関連会社がスポンサーとなっているものでも、提携しているものでもありません。Unityは、米国およびその他の国におけるUnity Technologiesまたはその関連会社の商標または登録商標です。
本記事は、2025年01月08(水)に開催した「CA.unity #9」において発表された「Unity6 の Android周辺のアップデートについて」に対して、社内の生成AI議事録ツール「コエログ」を活用して書き起こし、登壇者本人が監修役として加筆修正しました。
向井 祐一郎（株式会社 サイバーエージェント Lead Developer Experience）
株式会社サイバーエージェント2015年新卒入社。横断組織Lead Developer Experienceを立ち上げ、主にクライアントサイドの基盤開発やプロジェクトサポートに従事しています。
GitHub：https://github.com/yucchiy
「Unity6 の Android 周辺のアップデートについて」と題して発表させていただきます。よろしくお願いします。
発表でお話ししたいことですが、タイトルの通り、主要なアップデートの中でも、個人的に重要だと感じたものについてご紹介したいと思います。普段、Androidをメインで扱っている方はそれほど多くないかもしれませんので、今回の発表では、細かい技術的な部分を掘り下げるというよりも、概要や対応の背景を私なりの解釈を交えながら、広く浅くご説明できればと考えています。
はい、まずはじめに自己紹介させてください。向井 祐一郎と申します。サイバーエージェントでUnityエンジニアをしています。 役職はDeveloper Experienceで、システム系の基盤開発などを担当しています。また、プラットフォーム周りのサポートも行っており、今回の発表を担当することになりました。
個人の活動としては、右のアイコンでSNSを運用しているほか、「Unity Weekly」という、毎週のUnity関連ニュースをまとめるブログも運営しています。
アップデートのまとめに入る前に、まずはアップデートの追い方について、軽く触れておきたいと思います。
Unityのメジャーバージョンのアップデート情報は、Unity 6に限らず、公式ドキュメントでまとめられています。今回のAndroidに関するアップデートも、このように項目ごとに整理されているので、詳細が気になる方は、まずここを確認してみるのが良いかと思います。
さらに詳細を知りたい場合は、リリースノートを確認することになります。個人的におすすめなのが、Unityの公式が提供している Unity Release Notes です。これを使うと、左側のようにバージョンの差分を指定することで、その差分のリリースノートを簡単に確認できます。アップデートの詳細を追いたいときに非常に便利なので、ぜひ活用してみてください。
前置きはこのあたりにして、ここからは主要なアップデートについてお話ししていきたいと思います。
改めて、この4つのアップデートについて順番にお話ししていきたいと思います。
まずは、Android Game Development Kitの対応についてお話しします。
まず、その前にAndroid Game Development Kitについて簡単に説明します。これは、Android上でゲーム開発を行う際に、開発や最適化を補助するためのツールおよびライブラリのセットです。 少し小さくて見づらいかもしれませんが、含まれている内容としては、ライブラリ、最適化、そして後ほど説明する適応性に関するツールやライブラリが用意されています。
それでは、詳しく見ていきましょう。
今回、Unity 6での対応としては、Androidのアクティビティのゲーム特化版であるGameActivity、ゲーム用のコントローラーやテキスト入力を取得するための仕組み、メモリ情報を取得するためのAPIが追加されています。また、GameModeやState APIもUnity 6で対応されました。
緑の枠で囲まれている部分については後ほど詳しくお話ししますが、Adaptive Performanceというライブラリも含めた対応が可能になっています。
GameActivityについてお話しします。これはゲームに特化したアクティビティで、Unity 6からアクティビティのデフォルトがGameActivityに置き換わっています。では、なぜこれを導入したのかというと、Unityのディスカッションでも言及されているように、スレッドのサポートによってパフォーマンスが向上する点が大きな理由です。
また、GameActivityを導入することで、ANR（アプリの応答なし）が減少し、クラッシュが低下するといったユースケースがGoogleの公式情報として紹介されていました。これが主要な導入目的の一つと考えられます。さらに、今回追加された入力関連の対応において、イベントを取得するためのブリッジコードを記述できるという点もポイントです。
なお、デフォルトはGameActivityに置き換わっていますが、既存の通常のアクティビティも引き続き利用可能です。これは Player Settings の Other Settings の Configuration から、右下に示されている形で設定することができます。
次に、GameMode APIについてお話しします。これは何かというと、ゲームを遊んでいるユーザーが、ゲームに対してモードを設定できるAPIです。対応すると、左下に表示されているAndroidのダッシュボードのように、ユーザーが直接モードを設定できるようになります。
設定項目としては、標準モードのほか、パフォーマンス重視のモード（多少端末が熱くなっても良いからゲームを快適に動かす設定）、電力重視のモード（バッテリーを節約するためにパフォーマンスを抑える設定）などが選べるようになります。
つまり、これを実装することで、ゲーム側としては選択されたモードに応じた挙動をすることが期待されるAPIになっています。
次に、Game State APIについてお話しします。先ほどのGameMode APIはユーザーがゲームの設定を変更するものでしたが、Game State APIはゲーム側からOSに対して、現在のゲームの状態を伝えるためのAPIです。
このAPIの目的は、システム側がリソースや電力の最適化を行う際に、ゲームの状態を把握できるようにすることです。システムが適切な最適化を行うためには、ゲームの状況をある程度知る必要があるため、それを伝えるための仕組みになっています。
API自体はシンプルで、例えば「現在ローディング中」といった状態を設定することができます。これにより、システムが最適なリソース管理を行えるようになります。
このAPIはUnity 6からサポートされ、デフォルトで呼び出せるようになったのが今回のアップデートのポイントです。新しく AndroidGame というクラスが追加されており、そのメソッドやプロパティを通じてアクセスできるようになっています。
先ほど「適応性」の部分で触れましたが、Unity 6からの新機能ではないものの、Adaptive Performance というパッケージがあります。これは、端末の状態に応じて最適なアプリの動作に適応するためのフレームワーク、もしくはライブラリといえます。
ここでいう「端末の状態」とは、例えば 現在のフレームレート や 端末の温度 などを指します。これらの情報を基に、アプリ側の設定、例えば 描画解像度の調整 や パーティクル数の増減 などを動的に調整し、快適なゲーム体験を維持するための仕組みになっています。
Android側の意図としては、Androidデバイスはスペックの幅が広いため、その中でゲームを安定して動作させるには、こうした適応的な設計が必要になるという考えがあるのだと思います。そのため、このライブラリが提供されているのではないかと推測されます。
また、先ほど紹介したThermal API（温度取得API） や GameMode API も、このAdaptive Performanceの枠組みの中でサポートされています。
次に、少し話が変わりますが、Addressables の Play Asset Delivery 対応 についてお話しします。
まずPlay Asset Deliveryについてですが、これは簡単に説明すると、Android App Bundle 通称AABという、今のAndroidの配布形式を介して、Google Play上でアセットを配信する仕組みになっています。この仕組みには3つのモードがあり、後ほど詳しく説明しますが、そのモードに基づいてアセット配信が行われます。
この仕組みの一番のメリットは、適切に対応すると、デフォルトでは200メガまでしかアプリ配信できないところを、上限としては4GBまでアプリのサイズを大きくすることができる点です。
配信モードには大きく3つの種類があります。一つ目は install-time で、これはアプリに組み込むアセットを設定するものです。残りの2つはダウンロードされるアセットで、fast-follow と on-demand というモードがあります。
一応、このPlay Asset Deliveryの対応自体は、実は従来のUnityでもサポートされていました。下の「アセットパックの作成」に関するドキュメントにも記載されていますが、端的に言うと、一定のサイズ未満のアセットはinstall-time（埋め込みアセット）として設定し、それを超える部分をfast-followで配信する、という形になっています。
しかし、従来の仕組みでは、アセットパックの設定が柔軟に行えないというデメリットがありました。そこで、この問題を解決するために、AddressablesのPlay Asset Delivery対応が実装されました。
AddressablesのPlay Asset Delivery対応についてですが、AddressablesにはAsset Group という単位があり、各Asset Groupごとに設定を行います。今回の対応では、その枠組みにPlay Asset Deliveryの設定が追加された形になっています。
設定は非常に簡単で、Addressablesを導入すると「アセットマネジメント」という項目が表示されます。ここで設定を作成すると、Asset Group に設定を追加できるようになります。その中で、緑の枠のようにPlay Asset Delivery の項目を設定することで、アセットの配信が可能になり、アセットパックの作成が確認できるようになります。
このように、Addressablesのインテグレーションに沿った形でPlay Asset Deliveryが利用できる 仕組みになっています。
次に、少し話が変わりますが、Texture Compression Targeting についてお話しします。
Texture Compression Targeting とは、デバイスがサポートしているテクスチャの圧縮形式の中から、最適なものを選択して配信する仕組みです。
基本的には、ASTC がパフォーマンス面で最も優れているため、まずASTCを優先して配信します。ただし、ASTCに対応していない場合。とはいえ、対応していないのはかなり古い端末に限られますが、ETC2またはETC1 にフォールバックする形になります。
この仕組みのポイントは、「選択された圧縮形式のみのアセットが配信される」点です。通常、フォールバックを考慮する場合、すべての圧縮形式のアセットを含める必要がありますが、Google Play側で自動的に最適な形式を選択し、必要なものだけを配信してくれるため、アプリやアセットのサイズを小さくできる というメリットがあります。
また、この機能は Android App Bundle の一部として提供されています。
この設定は、Unity 6から簡単に行えるようになりました。まず、ビルド設定 の中にある Asset Import Overrides を無効にし、その上で Player Settings の Texture Compression Formats でサポートする圧縮形式を設定します。
基本的には、これだけの設定で対応が完了するため、非常に手軽に利用できる仕組みになっています。
最後に、Android Project Configuration Manager についてお話しします。
Android Project Configuration Manager とは、Gradleプロジェクトの設定を変更するためのAPIや機能を提供するものです。 これまでも、UnityにはGradleテンプレートを書き換える方法や、iPostGenerateGradleAndroidProject を使用する方法がありましたが、今回のConfiguration Managerは、それらの仕組みをブラッシュアップしたバージョンのAPIとなっています。
次に、このConfiguration Managerを実装しているコードの例を見ていきましょう。
この AndroidProjectFilesModifier を継承し、その中に実装を書くことで、Gradleプロジェクトの設定を変更できます。この方法を使うことで、C#上で比較的わかりやすく設定を記述できるため、従来のGradleテンプレートの書き換えよりも直感的に扱えるのが特徴です。
このAndroid Project Configuration Manager が導入された背景を考察すると、Gradle Templateに関する課題が関係していると考えられます。まず、メンテナンスコストの高さ です。Android向けに新しい機能が追加されるたびに、Gradleテンプレートを更新する必要がある場合があります。しかし、テンプレートが更新されても、それを適用するには手動で変更を再適用しなければならないため、追従が大変という問題があります。
また、プロジェクト側でテンプレートを自由に編集できるため、ライブラリ側での対応が難しくなるという課題もあります。これにより、開発者やライブラリ提供者にとってのメンテナンスの負担が大きい という問題が発生していました。
こうした課題を解決するために、より柔軟でメンテナンスしやすい形でGradleの設定を変更できるAndroid Project Configuration Manager が導入されたのではないかと考えられます。
もう一つの課題として、iPostGenerateGradleAndroidProject という既存のAPIが挙げられます。このAPIを使えば、ほとんど同じことができますが、GradleやXMLを更新する際に、自分でパーサーを書かなければならない という点が大変だと感じる部分です。手動でXMLやGradleの構造を解析し、適切な編集を行うのは煩雑で、誤りが発生しやすい作業になります。そのため、より使いやすい方法としてAndroid Project Configuration Manager が導入されたのではないかと考えられます。
具体的には、このインターフェースのメソッドにAndroidプロジェクトのルートパス が直接渡されるため、編集を行う際は自分でファイルを開いて更新する必要があります。そのため、パーサーを自前で実装しなければならず、手間がかかるという課題があります。
Android Project Configuration Managerの使い道について。個人的には、Unity 6以降は基本的にAndroid Project Configuration Managerを使用するのが良い と思います。これは iPostGenerateGradleAndroidProjectの高レベル版API という立ち位置なので、これを活用することでよりシンプルにGradleプロジェクトの設定が行えます。
もし、それでも対応が難しい場合や、特殊なカスタマイズが必要な場合は、テンプレートの更新を検討する のが良いのではないかと考えています。
今回は、主要なアップデートについて紹介しました。かなり駆け足での説明になりましたし、内容も比較的ニッチな領域だったので、分かりにくい部分もあったかもしれません。 もし質問があれば、ぜひこの後の懇親会や質疑応答の時間に聞いていただければと思います。
それでは、ご静聴ありがとうございました。