Google Play の技術的な品質要件は、Android アプリの品質の 4 つの柱の一環として、Google Play でアプリのユーザーに対して質の高いエクスペリエンスを提供できるようにすることを目的としています。
Google Play の技術的な品質要件は、次の 2 つのカテゴリに分類されます。
- 現在の要件: 現在適用されている要件。この基準を満たすことは、Google Play でのアプリの安定性、パフォーマンス、見つけやすさを確保するうえで不可欠です。
- 今後の要件: 事前に公表されている新たな基準。この基準はまだ必須とはなっていませんが、移行期間中にアプリを評価し、推奨されるツールと API を統合して、要件の適用開始前までに要件を満たすようにしてください。
今後の要件
2026 年 8 月 26 日にお知らせしたとおり、Google Play で公開されるアプリとゲームに新たな技術的な品質要件が適用されることになりました。このヘルプセンター記事では、技術的な基準について詳しく説明することで、新しい要件が適用される前に、要件を理解して準備ができるようにすることを目的としています。
メモリ使用量の削減
Google Play では、アプリの主な指標に対し、不正な動作のしきい値が定義されています。メモリ使用量は新たな主な指標として導入され、次の 2 つの指標が設けられます。
- メモリ使用量（匿名 RSS + スワップ）
- ビットマップ メモリ使用量
Google Play では、不正な動作のしきい値が設定されている既存の Android Vitals の指標と同様に、過去 28 日間のデータを使用してアプリの品質を評価します。
これらの指標は、[Android Vitals の概要] の [メモリ] 見出しの下、および Google Play Developer Reporting API で確認できます。
これらの指標では、アプリがストレージから読み込まれて実行され、フォアグラウンドからバックグラウンドに移行するまで、アプリのライフサイクル全体で使用されるメモリ量を測定します。
これらの指標の値は、オプトインしたユーザーのデバイスからサンプリングされ、匿名化されたうえで集計されます。Google Play Console には、さまざまなパーセンタイルが表示されます。例として、不正な動作のしきい値に対するアプリのパフォーマンス評価に使用される 90 パーセンタイルなどがあります。90 パーセンタイルの値とは、1 日に収集されたサンプルの 10% がその値よりも高いことを意味します。たとえば、P90 が 1.7 GB の場合、収集されたサンプルの 90% が 1.7 GB 未満で、10% が 1.7 GB を超えていることを示しています。
この要件は、モバイルとタブレットのフォーム ファクタにのみ適用されます。
メモリ使用量
匿名 Resident Set Size（匿名 RSS）は、アプリによって直接割り当てられたメモリ（Java / Kotlin ヒープ、ネイティブ メモリ割り当て、匿名メモリ マッピングなど）を表します。これはスワップがなければディスクにページアウトできません。スワップには圧縮されたメモリまたは zRAM にページアウトされたメモリが含まれます。
しきい値はアプリのカテゴリ（アプリまたはゲーム）とデバイスの RAM 階層に応じて異なり、さまざまなハードウェアの制約を反映しています。2027 年 2 月以降、Google Play のアプリとゲームが基準に準拠するには、次のしきい値を満たす必要があります。
アプリ
| アプリの状態 | フォアグラウンド | ユーザーが認識しているサービス | バックグラウンド | キャッシュ |
| 物理 RAM | 90 パーセンタイル | 90 パーセンタイル | 90 パーセンタイル | 90 パーセンタイル |
|
0～4 GB （合計メモリ 0 MB～3,200 MB） |
- | - | - | - |
|
4 GB （合計メモリ 3,200 MB～4,800 MB） |
2 GB | 1 GB | 1 GB | - |
|
6 GB （合計メモリ 4,800 MB～6,800 MB） |
2.25 GB | 1.25 GB | 1.25 GB | - |
|
8 GB （合計メモリ 6,800 MB～9,216 MB） |
2.25 GB | 1.5 GB | 1.5 GB | - |
|
12 GB （合計メモリ 9,216 MB～14,336 MB） |
3.25 GB | 1.75 GB | 1.75 GB | - |
|
16 GB （合計メモリ 14,336 MB～18,432 MB） |
4.25 GB | 2 GB | 2 GB | - |
|
16 GB 超 （合計メモリ 18,432 MB 超） |
- | - | - | - |
注: 各 RAM 階層にはその最小値が含まれます。合計メモリは、デバイスの公表されている物理 RAM よりも少ない場合があります。
ゲーム
| アプリの状態 | フォアグラウンド | ユーザーが認識しているサービス | バックグラウンド | キャッシュ |
| 物理 RAM | 90 パーセンタイル | 90 パーセンタイル | 90 パーセンタイル | 90 パーセンタイル |
|
0～4 GB （合計メモリ 0 MB～3,200 MB） |
- | - | - | - |
|
4 GB （合計メモリ 3,200 MB～4,800 MB） |
2.25 GB | 2.0 GB | 2.0 GB | - |
|
6 GB （合計メモリ 4,800 MB～6,800 MB） |
2.75 GB | 2.5 GB | 2.5 GB | - |
|
8 GB （合計メモリ 6,800 MB～9,216 MB） |
3.5 GB | 2.75 GB | 2.75 GB | - |
|
12 GB （合計メモリ 9,216 MB～14,336 MB） |
4 GB | 3.2 GB | 3.2 GB | - |
|
16 GB （合計メモリ 14,336 MB～18,432 MB） |
5 GB | 3.5 GB | 3.5 GB | - |
|
16 GB 超 （合計メモリ 18,432 MB 超） |
- | - | - | - |
注: 各 RAM 階層にはその最小値が含まれます。合計メモリは、デバイスの公表されている物理 RAM よりも少ない場合があります。
ビットマップ メモリ使用量
アプリの状態がフォアグラウンド以外のときにビットマップを長時間保持し続けると、メモリを過剰に消費する可能性があります。UI が表示されていなければ、ビットマップをレンダリングすることはできません。通常、フォアグラウンド以外の状態でビットマップを長時間保持することは避ける必要がありますが、状態が変わった直後で onTrimMemory に対応してビットマップ用のメモリを積極的に解放しているときに、アプリのサンプリングが行われるケースもあります。こうした状況を考慮し、このしきい値は 0 よりも高く設定されています。
| アプリの状態 | 90 パーセンタイル |
| フォアグラウンド | |
| ユーザーが認識しているサービス | 200 MB 超 |
| バックグラウンド | 200 MB 超 |
| キャッシュ | 400 MB 超 |
DEX コードの最適化
2027 年 2 月より、Google Play のアプリとゲームは、最適化の最小要件を満たす必要があります。Google Play Console にアップロードするアプリは、最適化、難読化、圧縮を 25% 以上行っている必要があります。すべてのアプリまたはゲームが DEX コードを多用しているわけではないため、この要件は無視できない DEX のサイズの場合にのみ適用されます。Google Play Console の App Bundle エクスプローラで、アップロードした各 App Bundle の DEX サイズと最適化率を確認できます。
この要件は、すべてのフォーム ファクタに適用されます。
| ゲーム | アプリ | |||
| コードの最適化 | DEX コードが 50 MB を超えるゲーム | DEX コードが 10 MB を超えるアプリ | ||
| 難読化 | 25% | 25% | ||
| 最適化 | 25% | 25% | ||
| 圧縮 | 25% | 25% | ||
25% 以上の削減を達成するために、R8 などのどのようなアプリ圧縮ツールを使用しても構いません。
R8 構成アナライザを使用すると、より細かな分析情報を取得でき、パフォーマンスをさらに改善できます。CI / CD パイプラインまたはエンタープライズ環境で公開する場合、ローカルビルドはユーザーへの配布用に Google Play Console にアップロードされるビルドと完全に一致しないことがあり、多少の違いが生じることが想定されます。
ゼロタップでのログインの復元
2027 年 4 月以降、ユーザー ログイン（任意または必須）に対応しているアプリは、ユーザーが以前の Android デバイスから新しいデバイスに移行し、デバイス間での移行またはクラウド バックアップによるデータの復元を選択した場合、ゼロタップでのログインの復元をサポートする必要があります。デバイスのセットアップ時の手動でのログインは、オンボーディングの障壁となり、ユーザー維持率が低下するだけでなく、セットアップ時にアプリがフィッシングや認証情報の窃取などの重大なセキュリティの脆弱性にさらされることになります。Android Restore Credentials API は、このような問題を解決し、この要件を満たす主要な方法で、Android 9 以降で利用できます。
- 2026 年 9 月 30 日までに Block Store と統合し、ユーザーのログイン ステータスを復元しているアプリは、この要件に準拠しているとみなされます。
- 永続的な限定公開アプリと企業向けデバイス管理アプリはこの要件の適用対象外です。
- ログイン機能の仕組みに影響する厳格な規制またはコンプライアンス要件の対象となるアプリ（金融サービスや医療など）は、適用を免除される場合があります。デベロッパーは適用日より前に、この要件の免除リクエストを Google Play Console から送信する必要があります。
- ゲームは現在この要件の対象外です。2027 年に、ゲーム認証の複雑なユースケースに特化したガイダンスと、カスタムのソリューションを提供する予定です。単一のユーザー アカウントをサポートするゲームでは、Restore Credentials API を使用してゼロタップ ログインに対応することを強くおすすめします。
この要件と例外の詳細については、今後数か月以内に公開する予定です。
統合とテスト
統合をテストして、ユーザーがシームレスに利用できることと、この要件を満たしていることを確認してください。最近公開された Restore Credentials の AI スキルを使用すると、より簡単に統合できます。
対象となるフォーム ファクタと Android のバージョン
この要件は、モバイルとタブレットのフォーム ファクタにのみ適用されます。Restore Credentials API は、現時点では他のフォーム ファクタではサポートされていません。Restore Credentials は Android 9 以降で利用できます。
今後の要件に関するよくある質問
メモリ要件
なぜ Google はメモリ指標を導入することにしたのですか？
RAM コストの高騰により、エコシステム全体でメモリ不足となる危機が目前に迫っています。あるアプリで制御不能なメモリリークが発生し、デバイスのメモリのほとんどを消費するなど、メモリが効率的に使用されていない場合、デバイスでスタッタリングが発生し、バックグラウンドで正常に動作している他のアプリが強制終了されます。Android はメモリ制限を厳格化することを発表しており、Google Play はアプリのメモリ使用量がこの制限内に収まり、デバイスがアプリを終了しなければならなくなる事態を最小限に抑えることを目指しています。
メモリ使用量を減らすにはどうすればよいですか？
ビットマップの割り当てを減らすにはどうすればよいですか？
表示ビューの正確なサイズに合わせて画像をダウンサンプリングしてデコードし、メモリ消費を抑えるようにキャッシュが設定された最新の画像読み込みライブラリ（Coil や Glide など）を使用します。また、UI が非表示になったら未使用のメモリ内ビットマップを解放し（onTrimMemory の TRIM_MEMORY_UI_HIDDEN 経由）、ビットマップまたはビューへの静的参照を保持しないようにします。
コードの最適化には R8 を使用する必要がありますか？
高度な最適化と分析情報が得られる R8 の使用を強くおすすめしますが、他の最適化ツールを使用してこの要件を満たすこともできます。
アプリとゲームで要件が異なるのはなぜですか？
ゲームは主にフォアグラウンドでスムーズなゲームプレイ エクスペリエンスを提供するために、アプリとは異なるメモリ使用パターンを採用しています。通常、ネイティブのゲームエンジンを利用しており、アプリとは異なる技術的な制約があります。ゲームの要件はユースケースに合わせてカスタマイズされています。
Google Play では、どのようにしてアプリとゲームを区別していますか？
Google Play Console の [ストアの設定] で指定されたカテゴリに基づいています。このカテゴリに基づき、アプリが Google Play ストアのどの部分に表示されるかが決まります。別の技術的なしきい値が適用されるようにするために、アプリのコア機能を正しく反映していないカテゴリに変更することは、ストアの掲載情報のメタデータに関するポリシーに違反しますのでご注意ください。
これらの要件はアプリ エクスペリエンス プログラムおよび Level Up プログラムとどのように関連していますか？
これらのメモリしきい値が適用されると、アプリとゲームは AEP および Level Up の資格を取得または維持するために、すべてのメモリしきい値を遵守する必要があります。
Android のメモリ制限は Android 17 以降に適用されていますが、Google Play の要件も Android 17 以降のみに適用されますか？
いいえ。Google Play は、データが利用可能なすべてのアプリのバージョンを評価します。これはメモリ使用量（匿名 RSS + スワップ）とビットマップ メモリ使用量に関する Android 13 以降の指標です。
匿名 RSS + スワップと各 RAM 階層でしきい値が異なるのはなぜですか？
RAM 階層別に分けているのは、過剰なメモリ使用量に対する許容レベルがデバイスによって異なることを反映しています。16 GB のデバイスでパフォーマンスが高くても、4 GB のデバイスでもパフォーマンスが高いとは限りません。すべての RAM 階層でアプリが過剰にメモリを使用しないようにする必要があります。
メモリ要件の対象となるフォーム ファクタはどれですか？
メモリ使用量（匿名 RSS + スワップ）指標とビットマップ メモリ使用量指標については、モバイルとタブレットのフォーム ファクタが対象となります。
メモリ使用量をより細かく把握する際に使用できるツールには何がありますか？
-
アプリまたはゲームのメモリ使用量を改善するには、メモリに関するガイダンスをご覧ください。
-
Google Play Console（Android Vitals）: メモリ使用量（匿名 RSS + スワップ）とビットマップ メモリ使用量の 28 日間の P90 指標をモニタリングできます。アプリの状態（フォアグラウンド、ユーザーが認識しているサービス、バックグラウンド、キャッシュ）、デバイスの RAM 階層（4～6 GB など）、Android のバージョン、アプリのリリースでフィルタできます。
-
Google Play Developer Reporting API: 指標をプログラムでクエリして、自動でのレポート作成、パフォーマンス低下の特定、Vitals データの内部ダッシュボードへの取り込みができます。
-
Android Studio の Memory Profiler とヒープダンプ: Java / Kotlin ヒープ、ネイティブ メモリ、グラフィックでのリアルタイムの割り当てを調査できます。ヒープダンプ（.
hprof）を取得して分析し、メモリリーク、解放されていない Activity、重複したビットマップ、保持しているパスを検出できます。 -
Perfetto と System Tracing: Perfetto（
heapprofd）を使用して、ネイティブ割り当てと Java 割り当ての低オーバーヘッドのサンプリングを行い、メモリの急増を引き起こしているコールスタックを特定できます。システム トレースを行うことで、ライフサイクル移行全体でのメモリ使用量をトラッキングし、ローメモリ キラー（lmkd）イベントと関連付けることができます。AI 分析スキル（Perfetto AI Skills など）を使用して、トレースとヒープダンプの分析を自動化することもできます。 -
オンデバイス診断ツール:
adb shell dumpsys meminfo <package_name>を使用して、PSS、Private Dirty（匿名 RSS）、Swap Dirty（zRAM）、ビットマップの内訳をリアルタイムで確認できます。また、ComponentCallbacks2.onTrimMemory()を計測して、カスタムのクライアント テレメトリーを収集できます。
コードの最適化の DEX サイズに関して、下限が設けられているのはなぜですか？
コードの最適化はパフォーマンス上多くのメリットがあるため、Google では常に推奨していますが、一方でアプリまたはゲームの再構築と最適化に必要な労力と、ユーザーにとってのメリットとのバランスも考慮しています。DEX のサイズが小さい（アプリの場合は 10 MB 未満、ゲームの場合は 50 MB 未満）場合、デバイスのメモリ使用量への影響は限定的であるため、コードの最適化を必須としていません。
ゼロタップでのログインの復元
同じデバイスでアプリをアンインストールして再インストールした場合、復元キーは保持されますか？
いいえ。アプリをアンインストールすると、復元キーは自動的に削除されます。
この要件はすべてのフォーム ファクタに適用されますか？
いいえ。ゼロタップでの認証情報の復元要件は、モバイルとタブレットのフォーム ファクタにのみ適用されます。
この要件はユーザーがログインしていない場合や、ユーザー アカウントのないアプリにも適用されますか？
いいえ。この要件はデバイスの移行時にアクティブなログイン ステータスを保持することを目的としたものです。
-
ユーザー ログインのないアプリ: ユーザー アカウントやログイン機能を提供していないアプリにはこの要件による影響はありません。
-
ログアウトしたユーザーまたはゲストユーザー: ユーザーがログアウトしていた場合、ゲストモードを使用していた場合、デバイスを切り替える前にログアウトした場合、アプリは新しいデバイスでも同じ未認証のステータスで起動する必要があります。
Restore Credentials はどの認証方法でも機能しますか？
はい。Restore Credentials API はアプリが復元キーを保存できるようにすることで、あらゆる認証方法で機能するように設計されています。
Restore Credentials は認可スコープやステップアップ認証（MFA など）に対応していますか？
-
いいえ。Restore Credentials API は認証（ユーザーの ID とセッションの復元）専用に設計されています。OAuth 権限の付与や多要素認証などの二次的な認可リクエストには対応していません。
-
次の 2 段階のアプローチを推奨します。
-
ID の復元: Restore Credentials を使用して、新しいデバイスでの初回起動時に、ユーザーのメインのログイン ステータスをバックグラウンドで再確立します。
-
コンテキストに応じた権限付与: 特定のリソース権限（Google ドライブへのアクセスなど）を、ユーザーがそれらを必要とする機能にアクセスしたときにジャストインタイムでリクエストします。必要に応じて、ステップアップ認証（MFA など）をリクエストすることもできます。
-
統合が要件を満たしているかどうかを確認するにはどうすればよいですか？
ユーザーのログインの復元が成功したかどうかは、復元キーの取得ができたかどうかで判断できます。この要件を満たしていないと判断されたアプリには、通知が届きます。
アプリが例外に該当するかどうかを確認するにはどうすればよいですか？
例外に関する詳細なガイダンスは後日お知らせします。
多要素認証（MFA）のユースケースに対応するにはどうすればよいですか？
Restore Credentials API は MFA に対応しておらず、アプリのセキュリティ ポリシーをバイパスすることを目的としたものでもありません。新しいデバイスで復元キーを取得する際、アプリで追加のステップアップ認証を求めるかどうかを判断する必要があります。この要件を満たすには、ユーザーの ID コンテキストを復元する（「おかえりなさい、アレックスさん」と表示するなど）だけで十分です。ただし、デバイス間での復元は所有者であることを示す大きな証拠であるため、追加の MFA ステップは必要ありません。
ゲームはなぜこの要件の対象外なのですか？
ゲームでは一般的な認証の複雑なユースケースに合わせたソリューションを開発中のため、現時点ではゲームは対象外となっています。単一のアカウントのログインをサポートするゲームでは、Restore Credentials API を使用してゼロタップ ログインに対応することを強くおすすめします。
新しいデバイスのオンボーディング要件を満たすために Block Store を使用してもよいですか？
はい。Block Store との統合は、2026 年 9 月 30 日以前に統合が完了して本番環境に移行しており、ユーザーのログイン ステータスを正常に復元できる場合に限り、要件に準拠しているとみなされます。他の統合のタイプの場合や、期限後に統合が完了した場合は、準拠しているとはみなされません。
Block Store の統合の期限が 2026 年 9 月 30 日に設定されているのはなぜですか？
2026 年 9 月 30 日という日付は、現在 Block Store の統合を進めているチームにとって明確なマイルストーンとなります。これにより、既存のゼロタップ ログインの実装の有効性を維持しつつ、今後の統合については推奨される認証情報マネージャー基準へと移行できます。
ユーザーがこれまでのデバイスでログアウトしたり、アカウントを削除したりするとどうなりますか？
アプリは能動的に復元キーを削除する必要があります。アプリがアンインストールされると、復元キーは自動的に削除されます。
ゲストモードのユーザーの場合はどうすればよいですか？
この要件はアプリの認証部分にのみ適用されます。ユーザーがこれまでの古いデバイスでゲストユーザーだった場合、新しいデバイスでもゲストモードでアプリを起動する必要があります。
同じデバイスで複数のアカウントを使用しているユーザーの場合はどうすればよいですか？
この要件を満たすには、移行元デバイスで現在アクティブなユーザー アカウント（または最後にアクティブだったアカウント）の復元キーをアプリが保存する必要があります。詳しくは、Restore Credentials に関するドキュメントをご覧ください。
認証情報を復元したユーザーに対して、通知権限を再度付与するよう求めることなく通知を送信できますか？
はい。バックアップと復元サービスは、通知権限を含め以前のデバイスからのアプリの権限を復元します。これにより一般的な通知をユーザーに送信できます。さらに、Restore Credentials と組み合わせて使用することで、ユーザーがアプリを開かなくても、新しいデバイスでパーソナライズされた通知を使用してユーザーのリエンゲージメントを促せます。
その他
これらの要件は任意ですか？
このページに記載されている要件はすべて必須です。要件を満たしていない場合、Google Play でのアプリの表示と公開機能に影響する可能性があります。
関連リソース
コードの最適化
- R8 を使用してアプリの最適化を有効にする | アプリの品質 | デベロッパー向け Android
- R8 をフルモードで使用する | アプリの品質 | デベロッパー向け Android
- R8 構成アナライザを使用する | アプリの品質 | デベロッパー向け Android
メモリ使用量（匿名 RSS + スワップ）
ビットマップ メモリ使用量
認証情報の復元
- Restore Credentials について
- 公式ガイド: Restore Credentials を実装する
- テスト資料: Android Studio で Restore Credentials をテストする
- 実際の効果に関する事例紹介: Uber は 1 年あたり 400 万回の手動ログインを削減
スキル
スキルとは、AI 用に最適化されたモジュール式の指示とリソースです。LLM が developer.android.com の Android 開発に関するベスト プラクティスとガイダンスに沿った特定のパターンをより深く理解して、実行できるようにします。スキルは Android CLI やその他の LLM ベースのツールで使用できます。
- R8 Analysis Skill: アプリの R8 構成と Keep ルールを分析します。
- Perfetto AI Skills: ヒープダンプを分析し、メモリ パフォーマンスを改善する実用的な提案を取得するために使用します。
- Android Profiler Skill: ヒープダンプとトレースを分析し、メモリ パフォーマンスを改善する実用的な提案を取得するために使用します。
- Restore Credentials Skill: Restore Credentials のセットアップの統合とテストのサポートに使用します。
現在の要件
Google Play の既存の技術要件には、一連の主な指標における不正な動作のしきい値や、Google Play Console にアップロードする App Bundle に関する要件などがあります。
主な指標と安定性
Google Play は主なパフォーマンス指標をモニタリングして、アプリが安定性の基準を満たしていることを確認しています。このようなしきい値を超過した場合、Google Play ストアでのアプリの見つけやすさに影響を及ぼす可能性があります。
- ユーザーが認識したクラッシュ発生率: しきい値は全体で 1.09%（デバイス全体の平均）、各スマートフォン モデルでは 8%、各スマートウォッチ モデルでは 4% です。詳細
- ユーザーが認識した ANR 発生率: しきい値は全体で 0.47%（デバイス全体の平均）、各スマートフォン モデルでは 8%、各スマートウォッチ モデルでは 5% です。詳細
- 過度の部分的な wake lock: 全体のしきい値（デバイス全体の平均）は 5% です。不必要にデバイスのスリープを解除したままにすると、バッテリーを消費します。wake lock を適切に使用し、バックグラウンド タスクには WorkManager の使用を検討してください。詳細
- 過度のバッテリー使用: 各スマートウォッチ モデルのしきい値は 1% です。詳細
技術要件
Google Play は、さまざまなハードウェア構成とアーキテクチャを持つ幅広いデバイスをサポートしています。一部のアーキテクチャは Android の未来にとって不可欠なものであるため、Google Play Console にアップロードされる新しい App Bundle はそのようなアーキテクチャに対応して、アプリのエクスペリエンスを確実に提供できるようにする必要があります。
- 64 ビットのサポート: ネイティブ コードを含むアプリは、64 ビット専用アーキテクチャをサポートしている必要があります。詳細
- 16 KB メモリのページサイズのサポート: ネイティブ コードを含むアプリは、16 KB メモリのページサイズのデバイスをサポートしている必要があります。Java / Kotlin のみのアプリは、デフォルトで互換性があります。詳細
- Wear OS の 64 ビットおよび 16 KB メモリのページサイズのサポート: 2026 年 9 月 15 日より必須となります。詳細
- TV の 64 ビットおよび 16 KB メモリのページサイズのサポート: 2026 年 8 月 1 日より必須になります。詳細