Google Playは2027年2月から、Androidアプリとゲームにメモリ使用量とコード最適化の新しい品質基準を適用します。
開発チームに必要なのは、目立つメモリ不足だけを直すことではなく、端末のRAM帯とアプリ状態ごとの実測値を基に、改修の優先順位を決めることです。
Googleの公式発表とPlay Consoleの技術品質要件を基に、対象となる指標と実務上の準備を整理します。
新しい品質基準の対象
今回の基準は、メモリ使用量、Bitmapメモリ使用量、DEXコード最適化の三つに分かれます。
メモリ使用量
メモリ使用量（Anonymous RSS + Swap）は、JavaやKotlinのヒープ、ネイティブ割り当て、匿名メモリマッピングなど、アプリが直接確保するメモリとzRAMへ移された分を合わせて捉える指標です。
Google Playは、ユーザーが許可した端末から匿名化して集計した直近28日間のデータを使い、90パーセンタイル値を基準と比較します。
90パーセンタイルが1.7GBなら、測定値の90％は1.7GB以下で、残る10％はそれを超えたという意味です。
一部の平均値が良好でも、メモリを多く使う利用場面や端末群が判定に表れるため、平均値だけでは状況を判断できません。
Bitmapメモリ使用量
Bitmapメモリ使用量は、画像データが占めるメモリをアプリ状態別に評価する指標です。
アプリとゲームに共通して、ユーザーが認識できるサービスとバックグラウンドでは200MB超、キャッシュ状態では400MB超が不良動作の基準として示されています。
画面が見えない状態で大きな画像を保持し続ける設計は、ライフサイクル遷移後にメモリを解放できているかを点検する必要があります。
DEXコード最適化
DEXコードが10MBを超えるアプリと50MBを超えるゲームには、最適化、難読化、縮小の各項目で最低25％という基準が設けられます。
GoogleはR8など任意のアプリ縮小ツールを利用できると説明していますが、設定を有効にするだけで品質が確定するわけではありません。
リフレクション、シリアライズ、JNI、動的に参照するクラスがあるアプリでは、リリースビルドを使った回帰試験までが対応範囲です。
一般アプリのメモリ基準値
一般アプリのAnonymous RSS + Swapには、端末の総メモリ範囲とアプリ状態に応じた基準が設定されています。
| 端末の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 |
ここでいうRAM帯は端末に表示された公称値そのものではなく、Androidがアプリに利用できる総メモリ範囲で分類されます。
ゲームには別の基準値があり、値が未設定のRAM帯もあるため、対象製品の区分とAndroid vitalsの最新表を照合してください。
Playの審査とAndroid 17の制限は別の仕組み
今回のGoogle Play要件を「Android 17端末だけで動く強制終了機能」と解釈するのは正確ではありません。
Playのメモリ品質要件は、データを取得できるAndroid 13以降のアプリ版を評価対象とし、スマートフォンとタブレットに適用されます。
一方、Android 17のアプリ別メモリ制限はOS側の実行時制御であり、上限付近ではzRAMへの退避による処理負荷やプロセス終了が起こり得ます。
両者はメモリ効率を改善するという方向は共通していますが、Play上の品質評価とOS上の実行制御は分けて検証する必要があります。
Androidのメモリ管理に関する公式解説は、匿名メモリとファイルに裏付けられたメモリの違い、zRAMを含めて測る理由を説明しています。
開発チームが進める五つの作業
- 基準値を確定する：Play ConsoleのAndroid vitalsで、アプリ版、Androidバージョン、端末RAM帯、フォアグラウンドやバックグラウンドなどの状態別に直近28日間の90パーセンタイルを記録します。
- 利用場面と結び付ける：起動、一覧スクロール、画像編集、動画再生、バックグラウンド同期など、メモリが増える操作を再現し、どの状態遷移で解放が遅れるかを特定します。
- 保持元を調べる：Android Studio Memory Profilerとヒープダンプで、解放されないActivity、Context、リスナー、キャッシュ、大きなBitmap、ネイティブ割り当ての保持経路を確認します。
- 影響の大きい順に直す：利用者数の多い操作、低RAM端末で基準に近い処理、バックグラウンドに移っても残るBitmap、継続的に増えるヒープを優先します。
- リリース判定に組み込む：改修後は同じ端末条件と操作で再計測し、リリースビルドの機能試験、クラッシュ、ANR、起動時間への影響も合わせて確認します。
端末上の切り分けには、adb shell dumpsys meminfo <package_name>でプロセスの内訳を確認する方法もあります。
単発のヒープダンプは原因候補を探す資料であり、実利用環境の28日間の分布をそのまま再現するものではありません。
開発環境の詳細計測とAndroid vitalsの集計値を往復し、改修が利用者の多い条件で効いたかを確認してください。
基準超過が事業に与える影響
Googleは、基準を超えるアプリやゲームについて、Play上の表示機会や公開機能が制限される可能性を示しています。
ただし、基準を一度超えた瞬間にアプリが削除されると公式資料が説明しているわけではありません。
評価は直近28日間の集計に基づくため、改修の着手が遅いほど、改善版のデータを蓄積して効果を確認できる期間が短くなります。
性能改善をストア対応だけの作業に閉じず、低RAM端末での操作の安定、画像の多い画面の応答、バックグラウンド復帰時の継続利用を守る品質管理として扱うと、投資判断を説明しやすくなります。
よくある質問
基準値を下回ればメモリ問題はなくなりますか
基準値はPlay上の不良動作判定を避ける目安であり、すべての端末と操作でメモリ不足が起きないことを保証する値ではありません。
クラッシュ、ANR、低メモリ終了、操作の遅延も別に監視してください。
フォアグラウンドだけを軽くすれば十分ですか
十分ではありません。
今回の指標は、ユーザーが認識できるサービス、バックグラウンド、キャッシュ状態も区別して評価するため、画面を閉じた後の解放処理や長時間動くサービスも対象です。
R8を有効にすればDEX要件に対応できますか
R8は有力な手段ですが、Play Consoleで最適化、難読化、縮小の各割合を確認し、リリースビルドで機能が保たれることまで検証する必要があります。
参照した一次情報
- Android Developers Blog「Elevating app quality: Reducing memory usage and improving device migration」
- Google Play Console ヘルプ「技術品質要件」
- Android Developers「Android vitals」
- Android Developers「メモリ管理の基本概念」
この記事に関連する株式会社greedenの取り組み
メモリ基準への対応は、実機計測と改修を継続的なリリース工程へ組み込むことが要点です。株式会社greedenは、iOSとAndroidアプリの企画、実装、運用を一貫して支援しています。