Googleは2026年8月26日、Google Playで配信するアプリとゲームに新しい技術品質要件を導入すると発表しました。
2027年2月から、メモリ使用量、ビットマップ使用量、DEXコード最適化が評価対象となり、基準を満たさないタイトルはストアでの表示や公開機能に影響を受ける可能性があります。
Androidアプリの開発チームは、端末で一度だけ計測するのではなく、実利用データをRAM帯、アプリ状態、リリース別に追い、改善を継続できる運用へ切り替える必要があります。
Google Playが発表した三つの品質基準
GoogleのAndroid Developers Blogによる公式発表は、動的なメモリ使用量、ビットマップ使用量、DEXコード最適化を新しい評価軸として示しています。
Googleは、基準超過が端末上の動作低下やアプリ終了と結び付く強い兆候になると説明しており、2027年2月から基準未達のタイトルではGoogle Play上の表示や公開機能が制限される可能性があるとしています。
ただし、今回の発表は「すべてのアプリに一律のメモリ上限を設ける」という内容ではありません。
アプリとゲームでは基準が異なり、動的なメモリ使用量は端末のRAM帯とアプリ状態ごとに評価されます。
メモリ使用量は28日間のP90で見る
メモリ使用量は、Anonymous RSSとSwapの合計を指します。
Anonymous RSSにはJavaまたはKotlinのヒープ、ネイティブメモリ、匿名メモリマッピングなどが含まれ、SwapはzRAMへ圧縮または退避されたメモリを表します。
Google Play Consoleの技術品質要件によると、Google Playは直近28日間のデータを使い、90パーセンタイル値で基準への適合を評価します。
90パーセンタイル値が1.7GBなら、収集した標本の90％は1.7GB未満、残る10％は1.7GBを上回ったという意味です。
平均値だけが低くても、一部の端末や利用場面で大きなメモリ消費が続けば問題を見落とします。
| 端末のRAM帯 | フォアグラウンド | ユーザーが認識するサービス | バックグラウンド |
|---|---|---|---|
| 4GB | 2.00GB | 1.00GB | 1.00GB |
| 6GB | 2.25GB | 1.25GB | 1.25GB |
| 8GB | 2.25GB | 1.50GB | 1.50GB |
| 12GB | 3.25GB | 1.75GB | 1.75GB |
| 16GB | 4.25GB | 2.00GB | 2.00GB |
この表は一般アプリ向けの90パーセンタイル基準であり、ゲームには別の値が設定されています。
0GB以上4GB未満の帯と16GB超の帯は、現行の公式表で基準値が示されていません。
基準値がないRAM帯も、メモリ消費を管理しなくてよいという意味ではありません。
画面が見えない状態でのビットマップ保持を減らす
ビットマップ使用量は、画像データが占めるメモリを対象とする指標です。
現行の基準では、ユーザーが認識するサービスとバックグラウンドで200MB超、キャッシュ状態で400MB超が不良動作の基準として示されています。
画面が見えていない状態では画像を描画できないため、表示に不要なビットマップを保持し続ける設計は見直す必要があります。
画像の表示寸法に合わせたダウンサンプリング、CoilやGlideのキャッシュ設定、onTrimMemory()での解放、BitmapやViewへの静的参照の除去が公式に挙げられた対策です。
DEXコードは三種類の最適化率が対象になる
DEXコード最適化では、縮小、論理最適化、難読化をそれぞれ25％以上にする基準が設けられます。
一般アプリはDEXコードが10MBを超える場合、ゲームは50MBを超える場合に適用され、R8以外の縮小ツールも利用できます。
開発端末のビルド結果だけで判断せず、Play ConsoleのApp Bundle Explorerで実際にアップロードしたバンドルのDEXサイズと最適化率を確認する必要があります。
Android 17だけの対応ではない
新基準をAndroid 17向けの作業だけと捉えると、評価範囲を誇張なく把握できません。
Googleの説明では、Google Playのメモリ使用量とビットマップ使用量は、データを取得できるAndroid 13以降のアプリ版を評価対象とします。
一方、Android 17では端末側にもアプリ単位のメモリ制限が導入され、上限に達するとzRAMへの退避による処理負荷が生じ、使用量が増え続ければプロセスが終了する場合があります。
Android Developersのメモリ制限に関する技術解説は、Android vitalsによる実利用の把握と、端末上の診断を組み合わせるよう案内しています。
Google Playの品質評価とAndroid 17の端末側制御は関連していますが、同じ仕組みではありません。
開発ロードマップでは、ストア要件への適合と端末上の安定動作を別の検証項目として管理するほうが、原因と対策を対応付けやすくなります。
開発チームが進めたい五段階の対応
1．Android vitalsで基準線を作る
最初に、Play ConsoleのAndroid vitalsで直近28日間の90パーセンタイル値を確認します。
フォアグラウンド、ユーザーが認識するサービス、バックグラウンド、キャッシュを分け、RAM帯、Android版、アプリ版でも絞り込みます。
全体値だけを見ると、特定の端末群やリリースに偏った退行が平均に隠れるためです。
2．実端末で増加箇所を特定する
Android StudioのMemory Profilerとヒープダンプを使い、解放されないActivity、重複した画像、保持経路を調べます。
ネイティブ領域を含む割り当ての山を追う場合はPerfettoを使い、簡易確認ではadb shell dumpsys meminfo <package_name>で内訳を取得できます。
監視値が高いという結果だけで改修を始めず、どの操作とライフサイクル遷移で増えるかを再現してから原因へ手を入れます。
3．ライフサイクルに沿って解放する
onTrimMemory()への応答、長時間動くバックグラウンド処理の削減、ライフサイクルを認識するコンポーネントへの移行を優先します。
画像は必要な表示寸法で読み込み、画面が隠れた後も大きなキャッシュや参照が残っていないかを確認します。
単発の最適化より、画面遷移、バックグラウンド移行、復帰を含むテストシナリオにするほうが、実利用に近い問題を捉えられます。
4．配布用バンドルでDEXを確認する
リリースビルドでR8などの縮小ツールを有効にし、不要コードの削減、最適化、難読化が意図どおり働くかを確認します。
CIで作成した配布用バンドルはローカルビルドと差が生じる場合があるため、Play Consoleにアップロードされた成果物を最終確認の対象にします。
機能追加でDEXサイズが増えたときに検知できるよう、リリースごとの値を残して比較します。
5．品質基準を発注要件と受け入れ条件に入れる
外部へ開発を委託する場合は、「動作が軽いこと」のような抽象表現では検収できません。
対象RAM帯、主要シナリオ、Android vitalsで見る指標、許容値、計測期間、配布用バンドルの最適化確認を要件に含めます。
既存アプリの保守契約でも、OS対応だけでなくメモリ退行の監視と改善を作業範囲に定めると、公開直前の修正集中を避けやすくなります。
Androidアプリの公開準備を広く見直す場合は、サイト内のAndroidアプリの品質と公開準備のチェックポイントも参照できます。
サインイン復元は別の期限で進める
同じ公式発表には、端末移行時のZero-Tap Sign-In復元も含まれています。
ユーザーサインインを任意または必須で提供するモバイルおよびタブレット向けアプリは、2027年4月からRestore Credentials APIによるサインイン状態の復元が求められます。
ゲーム、永続的な非公開アプリ、企業向け端末管理アプリなどには適用範囲や例外があり、規制上の要件がある金融または医療分野では免除申請の余地が示されています。
メモリ対策と認証移行は担当領域が異なるため、同じ作業としてまとめず、性能と認証の二本の計画として期限と検証責任を置くのが現実的です。
よくある質問
平均メモリ使用量が低ければ問題ありませんか
平均値だけでは判断できません。
Google Playは直近28日間の90パーセンタイル値を使うため、RAM帯とアプリ状態を分けて一部の重い利用場面を確認する必要があります。
すべての一般アプリでDEX最適化率25％が必要ですか
現行の公式要件では、一般アプリはDEXコードが10MBを超える場合に、縮小、論理最適化、難読化の各25％基準が適用されます。
小さいDEXでも最適化の利点はありますが、基準の適用条件とは分けて考えます。
Android 17を対象外にすれば対応を避けられますか
避けられません。
Google Playのメモリ指標は、データを取得できるAndroid 13以降のアプリ版を評価すると公式ヘルプに記載されています。
発注者は何を確認すればよいですか
開発会社に、Android vitalsの確認範囲、対象RAM帯、テストシナリオ、ビットマップ解放、配布用バンドルのDEX最適化結果を尋ねます。
公開後も同じ指標を追える担当者と確認頻度を決めておくと、機能追加による退行を早い段階で見つけやすくなります。
参考資料
- Android Developers Blog「Elevating app quality: Reducing memory usage and improving device migration」
- Google Play Console ヘルプ「Play Console technical quality requirements」
- Android Developers「Preparing your app for broader memory limits」
- 株式会社greeden公式サイト
この記事に関連する株式会社greedenの取り組み
品質基準への対応は、公開直前ではなく要件定義と継続運用に組み込む必要があります。株式会社greedenは、iOSおよびAndroidアプリの企画、実装、テスト、リリース後の改善まで一気通貫で支援します。