AndroidのDozeモードとは？Deep/Lightの違いと通知が遅れるときの解除方法

Dozeモード（ドーズ）は、Android 6.0（API 23）で入った端末全体の省電力機能です。充電せず、画面を消し、机に置いたままにしておくと、OSがアプリのネットワーク通信やジョブ、アラームをまとめて止めます。英語の doze は「うたた寝」の意味で、完全に眠るのではなく、ときどき目を覚まして溜まった処理を片付けます。

「LINEの通知が朝まとめて届く」「Galaxyでアプリがディープスリープにされた」といった現象では、Dozeやメーカー独自の省電力が原因の候補になります。この記事では、Deep DozeとLight Dozeの違いをAOSPのソースコードの既定値で示し、利用者向けの解除手順と、開発者向けのadbでの再現方法を分けて説明します。

まとめ：Dozeモードの要点と通知遅れへの対処

• Deep Dozeは「充電していない・画面オフ・静止」の3条件がそろうと入り、Light Dozeは静止していなくても入る。画面を点けるか充電器につなぐとどちらも解除されるが、端末を動かして解除されるのはDeep Dozeだけ。
• Android 7.0からは2段構えになった。ポケットの中のように動いていても入る浅い段階（Light Doze）と、静止が続いたときの深い段階（Deep Doze）がある。
• AOSP（android16-release）の既定値では、Light Dozeは画面オフから約4分、Deep Dozeは静止状態で1時間強で入る。待ち時間はAndroidの版や端末メーカーの設定で変わる。
• Doze自体をオフにする設定は、通常の設定画面にはない。通知が遅れるアプリだけを「制限なし」（Pixel）や「自動的にスリープ状態にしないアプリ」（Galaxy）に入れるのが正規の手段。
• 開発者は adb shell dumpsys deviceidle force-idle でDozeを再現できる。即時性が必要なユーザー向け通知にはFCMの高優先度メッセージを使う。ただし、即時配信を保証するものではない。

Dozeモードが発動する条件と止まる処理

公式ドキュメントは発動条件を「端末が電源に接続されず、静止し、画面がオフのまま一定時間置かれたとき」と定めています。Doze中の端末はアイドル状態と呼ばれ、AOSPでは DeviceIdleController というシステムサービスがこの状態を管理しています。ただし「アイドル状態」は一般的な未使用状態を指す場合もあり、Dozeに入っているかどうかは別途確認が必要です。

Doze中の処理制限とアラームの例外

公式ドキュメント「Doze とアプリ スタンバイ用に最適化する」が挙げる制限は次のとおりです。

目覚まし時計向けの setAlarmClock() だけは例外で、Dozeを抜けてから鳴ります。目覚ましアプリが setAlarmClock() 以外のAPIでアラームを登録している場合は、Dozeで遅れる可能性があります。一方、アプリの定期同期やWorkManagerの処理は止まるため、処理の遅延はWorkManager側の設計で吸収します（WorkManagerの遅延実行の仕組みと採用判断で扱っています）。

メンテナンス枠の間隔が伸びていく仕組み

Doze中もOSは定期的に短時間だけ目を覚まし、止めていた同期・ジョブ・アラームを実行して通信を許可します。これがメンテナンス枠です。公式ドキュメントは「時間が経つにつれ、メンテナンス枠の頻度を下げる」と説明しています。

具体的な間隔はAOSPのソース（android16-release の DeviceIdleController.java）に既定値があります。Deep Dozeの最初の眠りは60分で、枠を挟むたびに2倍になり、上限は6時間です。一晩置いた端末では、通常優先度のメッセージが次のメンテナンス枠まで数時間待たされることがあります。ただしこの値は眠りの長さの設定値で、通知の遅れの上限を保証するものではありません。

Deep DozeとLight Dozeの違い：Android 7.0で加わった2段構え

Android 6.0のDozeは「静止」が条件だったため、持ち歩いている間は一切効きませんでした。Android 7.0で、画面オフ・非充電であれば動いていても制限の一部を先にかける段階が加わりました。AOSPのコードではこの浅い段階を light、深い段階を deep と呼び分けており、adbの dumpsys deviceidle のヘルプにも「deep doze」という表記があります。Deep Doze・Light Dozeという呼び名はここから来ています。

Light DozeとDeep Dozeの制限対象の違い

Android 7.0の動作変更ページによると、画面オフからしばらく経つと、まずアプリのネットワーク通信を止め、ジョブと同期を延期します。これがLight Dozeです。その後も静止が続くと、ウェイクロック、AlarmManagerのアラーム、GPS、Wi-Fiスキャンにも制限をかけます。これがDeep Dozeです。

歩いている最中の通知遅延では、Light Dozeによる通信制限も原因の候補になります。アラームやタイマーの遅延もDeep Dozeだけに固有の症状ではありません。遅延時の端末状態と使用APIを確認して切り分けます。

Deep Dozeに入るまでの状態遷移とAOSP既定の待ち時間

Deep Dozeは画面オフから一足飛びに入るわけではありません。DeviceIdleController は次の状態を順に進みます。待ち時間は android16-release のソースにある既定値です。

途中で端末が動けばACTIVEまで戻ります。Light Dozeは別の状態機械で並行して動き、画面オフから4分でLight Dozeに入り、眠りの長さは5分から最大15分まで伸びます。Deep Dozeに入った時点でLight Dozeの状態は凍結されます。

この数字は目安であって保証ではありません。同じソースは、値を端末のリソース設定（オーバーレイ）とサーバー側の設定（DeviceConfig）で上書きできる作りになっています。電池容量の小さい端末向けには、INACTIVEの待ち時間を1分に縮める既定値も別に用意されています。そもそもAOSP本体の config.xml では自動省電力を有効にする config_enableAutoPowerModes の既定値が false で、メーカーが自社端末で有効化する前提です。「機種によってDozeの効き方が違う」のはこのためです。実機に設定されている値は、adb shell dumpsys deviceidle の出力にある Settings 欄で確認できます。

バッテリーセーバー中のQuick Doze

AOSPにはQuick Dozeという近道もあります。バッテリーセーバーのポリシーでQuick Dozeが有効な端末では、画面オフ後に動きや位置の確認を省き、既定で1分待ってからDeep Dozeに入ります。静止していなくてもDeep Dozeの制限がかかるので、バッテリーセーバー中の通知遅延の一因になりえます。

アプリスタンバイとスタンバイバケット：アプリ単位の制限

Dozeは端末全体の状態で決まる制限です。これとは別に、アプリごとの使用状況で決まる制限がアプリスタンバイです。ユーザーがしばらく触っておらず、フォアグラウンドのプロセスもロック画面の通知も持たないアプリは「アイドル」と判定され、バックグラウンドの通信を絞られます。端末が長く使われない場合でも、アイドル判定されたアプリの通信はおおむね1日1回に抑えられます。

Android 9ではスタンバイバケットが導入され、Android 12で追加された「制限」を含め、現在は次の5つの優先度バケットがあります。バケットごとの目安は次のとおりです（公式の電源管理のリソース制限ページより。保証値ではないと明記されています）。

アクティブバケットのジョブ実行時間の上限はAndroid 16で入った変更で、それ以前は上限がありませんでした。充電中は制限バケット以外のジョブに実行時間の制限がかからないため、「充電中のテストでは動くのに実機では動かない」という報告の原因になりやすい箇所です。

バッテリーセーバー・データセーバー・自動調整バッテリーとの違い

Androidの省電力機能は名前が似ていて混同されがちです。Dozeと隣接する機能を、誰が有効にするかで整理します。

Pixelの「自動調整バッテリー」は、ヘルプの説明では「使用頻度の低いアプリを使っていない間の実行回数を減らす」機能で、利用パターンの学習結果をアプリごとの制限に反映します。自動調整バッテリーをオフにしても、Doze自体は止まりません。「電池の最適化をオフにしたのに通知が遅れる」場合は、メーカー独自の省電力に加え、通知設定・通信状態・送信側の配信処理も確認します。

Dozeモードの解除方法とアプリ別の除外設定

Doze自体を端末全体でオフにする項目は、通常の設定画面にありません。できるのは、通知を急ぐアプリを最適化の対象から外すことです。除外されたアプリはDoze中も通信と部分的なウェイクロックを使えますが、通常のアラームの延期など他の制限は残ります。

Pixel（Android 14以降）の「制限なし」設定手順

Google Pixelヘルプの手順は、設定アプリの［アプリ］→［アプリをすべて表示］→対象アプリ→［アプリのバッテリー使用量］→［バックグラウンドでの使用を許可］です。ここで［最適化］ではなく［制限なし］を選びます。公式の説明では［制限なし］は「すべてのバックグラウンド処理を許可」する設定で、AOSPの設定アプリのソースでは電源の許可リスト（Dozeとアプリスタンバイの除外リスト）への登録を伴います。

除外はLINEやSlack、業務用のチャットなど、遅れると困る数本に絞ります。Pixelヘルプは全アプリで［最適化］をオンにしておくことを勧めています。

Galaxyのスリープ・ディープスリープ設定の解除手順

Galaxyには、Dozeとは別にサムスン独自のアプリ単位の制限があります。サムスン公式サポートの説明では、スリープ中のアプリは「バックグラウンドで特定の場合にのみ実行」され、ディープスリープ中のアプリは「バックグラウンドで実行されません。アプリを起動したときのみ、アプリの更新や通知を受信します」。名前は似ていますが、AOSPのDeep Dozeとは別物です。

通知が来ないアプリがあれば、［設定］→［デバイスケア］→［バッテリー］→［バックグラウンドでの使用を制限］で、スリープ中・ディープスリープ中の一覧から外します。同じ画面の［自動的にスリープ状態にしないアプリ］に追加すると、使っていない期間が長くても自動でスリープへ戻されなくなります。

除外しても通知が遅れるときの確認順

OS標準の除外リストに入れても直らない場合は、次の順で確認します。

1. バッテリーセーバー（省電力モード）がオンになっていないか。Quick Dozeが有効な端末では、静止を待たずにDeep Dozeへ入る場合がある。
2. メーカー独自の設定（Galaxyのスリープ、他社の自動起動管理など）で対象アプリが制限されていないか。
3. アプリ自身の通知設定と、アプリ内の同期設定がオフになっていないか。電波が弱い場所にいないか。

メーカーごとの設定画面の場所は、有志サイトの dontkillmyapp.com が機種別にまとめています。ただし公式情報ではないので、画面の名称はお使いの端末の表示を優先してください。

開発者向け：adbによるDozeとアプリスタンバイの再現手順

Dozeによる不具合は、端末を1時間以上放置しないと再現しないのが厄介な点です。adbを使えば数秒でDeep Dozeに入れられます。以下のコマンドはすべて android16-release のシェルコマンド定義で存在を確認しています。

Deep Dozeへの強制移行と状態の確認

# 充電していない状態を擬似的に作る
adb shell dumpsys battery unplug

# Deep Dozeへ直行（light を指定するとLight Doze）
adb shell dumpsys deviceidle force-idle deep

# 現在の状態を確認（IDLE ならDeep Doze中）
adb shell dumpsys deviceidle get deep
adb shell dumpsys deviceidle get light

# 強制を解除し、電池の擬似状態を戻す
adb shell dumpsys deviceidle unforce
adb shell dumpsys battery reset

強制ではなく自然な遷移を1段ずつ追いたい場合は、adb shell dumpsys deviceidle step deep を繰り返すと、INACTIVE から IDLE まで順に進みます。除外リストの中身は adb shell dumpsys deviceidle whitelist で表示できます。

なお adb shell dumpsys deviceidle disable でDoze自体を止めることもできますが、これは開発用です。有効・無効の状態はメモリ上にしか持たず、再起動すると端末の設定値に戻ります。

スタンバイバケットの指定とアプリ動作の確認

# com.example.app は検証対象アプリのパッケージ名に置換
# アプリを低頻度バケットへ移す
adb shell am set-standby-bucket com.example.app rare

# 現在のバケットを確認（10=アクティブ 20=ワーキングセット 30=高頻度 40=低頻度 45=制限）
adb shell am get-standby-bucket com.example.app

# 公式手順のアプリスタンバイ再現
adb shell dumpsys battery unplug
adb shell am set-inactive com.example.app true
adb shell am get-inactive com.example.app

# 検証終了後、バケット・アイドル指定・電池の擬似状態を戻す
adb shell am set-standby-bucket com.example.app active
adb shell am set-inactive com.example.app false
adb shell dumpsys battery reset

バケットを rare や restricted に落としたうえで通知とジョブが期待どおり動くかを見れば、使用頻度の低い利用者の端末で起きる遅延を事前に確認できます。adb自体の導入はAndroid CLIのインストールとコマンド一覧を参照してください。

Doze中でも処理を届ける実装：FCM高優先度・AllowWhileIdle・除外申請

アプリ側の対策は用途で選びます。サーバーからの通知にはFCM、端末内の時刻指定にはAllowWhileIdle系アラームを検討し、直接の除外要求は許容用途に限ります。電池への影響は実行頻度や処理内容によって異なり、直接の除外要求にはGoogle Playの用途制限があります。

FCM高優先度メッセージは「通知を出すときだけ」

公式ドキュメントは、リアルタイムの受信が要るアプリにFCM（Firebase Cloud Messaging）を強く勧めています。高優先度メッセージはDoze中でも配信され、アプリは一時的に通信と部分的なウェイクロックを使えます。通常優先度のメッセージはDoze中はメンテナンス枠まで待たされます。

注意点は高優先度の使い方です。Android 13以降、スタンバイバケットは高優先度メッセージの数を決めなくなった代わりに、通知につながらない高優先度メッセージを送り続けるアプリはシステムに優先度を下げられます。Firebaseのドキュメントによると、判定にはアプリインスタンスごとの直近7日間のメッセージの挙動が使われます。データ同期の合図は通常優先度で送り、ユーザーに見せる通知だけを高優先度にする、という使い分けが前提です。FCMの基本的な送り方はFCMのプッシュ通知の仕組みと使い方にまとめています。

AllowWhileIdleアラームの回数上限と公式資料の記載差

Doze中でも鳴らしたいアラームは setAndAllowWhileIdle() か setExactAndAllowWhileIdle() で登録します。回数の上限は、公式ドキュメントのページによって書き方が違います。Dozeのページは「1アプリにつき9分に1回まで」、電源管理制限のページの表は「1時間に7回まで」です。

AOSPの AlarmManagerService.java（android16-release）を見ると、上限は2系統あります。

ソースのコメントは7回枠を「以前の9分に1回と同等」と説明しており、2つの公式ページの数字は、このうち7回枠と一致します。正確なアラームの権限（SCHEDULE_EXACT_ALARM または USE_EXACT_ALARM）を持つアプリなら72回枠が使えますが、この値もサーバー側の設定で変わりうるため、上限ぎりぎりの設計は避けてください。

Android 17では、PendingIntent の代わりに OnAlarmListener を受け取るコールバック型の setExactAndAllowWhileIdle が追加されました。リリースノートは、Doze中やバッテリーセーバー中に正確なコールバックが要るアプリ（医療用モニターやメッセージングのソケット）で、長時間の部分ウェイクロックと消費電力を減らせると説明しています。Android 17の他の変更点はAndroid 17（API 37）の変更点まとめで扱っています。

除外リストへの登録要求がGoogle Playで認められる条件

アプリはユーザーに除外を求めることもできます。通常は ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS で設定画面を開き、ユーザーに操作してもらいます。必要な権限を宣言したアプリが、システムの確認ダイアログでユーザーに除外を求める ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS は、Google Playのポリシーで用途が限られます。

判断基準は「Dozeやアプリスタンバイでアプリの中核機能が壊れるか、FCM高優先度を技術的に使えないか」です。FCMで足りるチャットアプリが「通知を確実に届けるため」と除外を直接求めるのは、許容用途に当たりません。現在の除外状態は PowerManager.isIgnoringBatteryOptimizations() で確認できます。React Nativeで通知を実装している場合は、React Native Firebaseの導入と落とし穴も併せて確認してください。

よくある質問

Dozeモードは解除（オフ）できますか？

端末全体のDozeをオフにする項目は、通常の設定画面にはありません。通知を急ぐアプリだけを除外リストに入れるのが正規の方法で、Pixelなら［アプリのバッテリー使用量］で［制限なし］を選びます。画面を点けるか充電器につなぐとDozeは解除されます。端末を動かすとDeep Dozeは抜けますが、画面が消えたままならLight Dozeの制限は続きます。adbの dumpsys deviceidle disable は開発用で、再起動すると元に戻ります。

Deep DozeとLight Dozeの違いは何ですか？

Light Dozeは画面オフ・非充電なら動いていても入る浅い段階で、ネットワーク通信を止め、ジョブと同期を延期します。Deep Dozeは静止が続いたときに入る深い段階で、加えてウェイクロック、アラーム、GPS、Wi-Fiスキャンも制限します。AOSPの既定値ではLight Dozeは画面オフから約4分、Deep Dozeは静止状態で1時間強かかります。

Dozeモード中にLINEなどの通知が遅れるのはなぜですか？

Doze中はアプリのネットワーク通信が止まり、通常優先度のプッシュ通知はメンテナンス枠まで待たされるためです。メンテナンス枠の間隔は最長6時間まで伸びるので、一晩置いた端末では朝にまとめて届くことがあります。アプリを［制限なし］にするか、Galaxyならスリープ中・ディープスリープ中の一覧から外すと改善します。

電池の最適化をオフにすると逆効果になりますか？

電池の消費が増える可能性があります。Pixelヘルプは、最適化をオフにしたアプリは使っていない間の実行回数が増え、バッテリーが必要以上に消費される可能性があると注意しています。全アプリをオフにするのではなく、通知が遅れて困るアプリだけに絞って除外するのが妥当です。

Galaxyの「ディープスリープ」はDeep Dozeと同じですか？

別の機能です。Deep DozeはAndroid標準の端末全体の省電力状態で、画面を点ければ解除されます。Galaxyのディープスリープはサムスン独自のアプリ単位の設定で、対象アプリはバックグラウンドで一切動かず、アプリを起動したときだけ更新や通知を受け取ります。通知が来ない場合は、デバイスケアのバッテリー設定で一覧から外してください。

関連記事

• WorkManagerとは？Androidの遅延実行の仕組みと採用判断を解説
• FCM（Firebase Cloud Messaging）とは｜プッシュ通知の仕組みと使い方をわかりやすく解説
• Android 17（API 37）正式リリース｜いつ・対応機種・ART/新機能を総まとめ【2026年6月】
• Android CLIとは｜1.0のインストール・コマンド一覧・エージェント連携
• React Native Firebaseとは｜v26の新アーキ必須化とExpo・ベア別の導入と落とし穴【2026年8月時点】