LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

バッテリー消費の多いアプリ — ユーザーレビューで指摘される問題の核心

モバイルアプリのバッテリー消費最適化とは、アプリがスマートフォンの電力を必要以上に消費しないよう、バックグラウンド処理・wakelock・位置情報取得・ネットワーク通信などの実装を見直す取り組みを指します^*1。

「電池の減りが早い」という指摘は、アプリのユーザーレビューで頻繁に見られます。アプリを使っていない時間にもバッテリーが減っていると感じるユーザーは、そのアプリをアンインストールする可能性があります。

バッテリー消費の問題は、機能要件に追われる開発フェーズでは見落とされがちです。しかしリリース後にストアレビューや問い合わせとして顕在化し、継続率や評価に影響します。原因を正確に把握して設計から見直すことが、問題解消への近道です。

wakelock・バックグラウンド・位置情報 — 電池を食う3つの原因

アプリがバッテリーを多く消費する原因は、大きく「wakelock」「バックグラウンド処理」「位置情報・センサーの常時取得」の3つに分類できます^*1。

wakelock：CPUを起こし続ける処理

wakelock（ウェイクロック）とは、Androidがデバイスをスリープ状態に移行しないよう保持するための仕組みです^*1。本来は音楽再生やナビゲーションなど、画面オフ中にも処理を継続する必要がある場面で使います。

しかし取得したwakelockを適切に解放しないと、CPUが常に稼働し続けます。「バグによって解放されないwakelock」はバッテリー消費の代表的な原因の一つです。画面をオフにしても電池が急速に減る場合、不要なwakelockの保持が原因である可能性があります。

バックグラウンド処理：スリープ中の不要な実行

アプリがフォアグラウンドにない状態でも、同期・データ取得・ログ送信などの処理が定期的に実行されることがあります。処理の頻度が高いほど、CPUとネットワークが稼働する時間が増えます。

とくにスリープ中も一定間隔でサーバーへアクセスする処理は、バッテリー消費を増やす主要因です。FCM（Firebase Cloud Messaging）の高優先度メッセージを多用する実装も、端末をスリープから頻繁に起こすため同様の影響があります^*1。

位置情報・センサーの常時取得

GPS（位置情報）は電力消費が特に大きいセンサーです。高精度モードで常時取得し続けると、バッテリーへの負荷は無視できない水準になります。地図アプリや物流アプリなど、位置情報を活用するアプリでは、取得精度と頻度のチューニングが設計の重点項目です。

加速度センサーや気圧センサーも、高頻度で取得し続けると累積的な電力消費につながります。アプリの用途に照らして「本当に必要な精度と頻度はどこか」を見直すことが出発点になります。

Android Dozeの仕組み：画面オフで何が起こるか

Androidは画面がオフになり、端末が静止した状態が続くとDoze（ディープスリープ）モードへ移行します^*1。Dozeは端末の電力消費を抑えるためのOSレベルの仕組みで、アプリ側の挙動に大きく影響します。

Dozeが有効になると起こること

Dozeモードに入ると、アプリのwakelockは無視されます^*1。アプリがCPUを保持しようとしても、OSが上書きしてスリープを維持します。アラームもDoze中は遅延し、指定した時刻通りには発火しません。

Wi-Fiスキャンは停止し、アプリのネットワーク通信も制限されます。JobSchedulerやWorkManagerによる同期ジョブも、Doze中はメンテナンス窓（端末がDozeから一時的に復帰するタイミング）まで遅延されます^*1。

Doze対応が設計で意味すること

Dozeの仕組みを理解せずに「〇分おきにサーバーと同期する」実装をすると、Doze中は期待どおりに動きません。それと同時に、Dozeを抜けようとして過剰にwakelockを取得するとバッテリーを消耗します。

Doze対応の基本は「処理をメンテナンス窓に集約させる」設計です。WorkManager（ワークマネージャー）はDozeを考慮した上でジョブをスケジューリングしてくれるため、独自のタイマー処理をWorkManagerへ移行することがAndroidの省電力設計の第一歩です^*1。

省電力設計の勘どころ：処理の集約・遅延実行・常時取得の見直し

省電力設計には、実装パターンをいくつか見直すことが効果的です。Androidの公式ドキュメントが推奨する定石をまとめます^*1。

不要なwakelockを避けて適切に解放する

wakelockを使う場面を「本当に画面オフ中も処理を続ける必要がある機能」に限定します。取得したwakelockは処理完了後に漏れなくリリースする実装にします。try-finallyブロックを使い、例外が発生した場合でもリリースが漏れない構造にすることが大切です。

wakelockに依存しないアーキテクチャへの移行が難しい場合は、タイムアウトを設定して一定時間後に自動解放する方法も選択肢の一つです。

バックグラウンド処理はWorkManager・JobSchedulerで集約する

データ同期・ログ送信・キャッシュ更新などの処理は、独自のタイマーやAlarmManagerではなくWorkManager（Android Jetpackのコンポーネント）またはJobSchedulerで管理します^*1。これらはOSと協調してバッテリー効率のよいタイミングで処理を実行します。

「充電中に実行する」「Wi-Fi接続時のみ実行する」といった条件を指定できるため、ユーザーが充電していない時間帯の負荷を抑えられます。メンテナンス窓に処理をまとめることで、CPUやネットワークの起動回数を減らせます。

位置情報取得の精度・頻度を最小限に絞る

位置情報は「必要な精度の中で最も電力消費の少いモード」を選びます。Android APIではLOW_POWER（低電力）やPASSIVE（他アプリの位置情報取得に便乗）といったリクエスト優先度があります^*1。

取得頻度も見直します。リアルタイムで追跡が必要な場面に限り高頻度取得を使い、それ以外は取得間隔を長めに設定するか、ジオフェンスを活用して特定エリアへの入退場時のみ位置を取得する設計にすると、電力消費を抑えられます。

FCM高優先度メッセージは必要な場面に限定する

FCM（Firebase Cloud Messaging）の高優先度メッセージは、Doze中でも端末を起こしてメッセージを届けられます。しかしこれはバッテリーへの負荷が高く、Googleはこの機能の使用を限定的にするよう推奨しています^*1。

チャットの受信通知など「即時性が必須」の場面に絞り、バックグラウンドでの定期データ取得などには使わないことが電力消費を抑えるポイントです。通常優先度メッセージでメンテナンス窓まで遅延する設計が多くのユースケースで適切です。

Battery Historianで計測して改善サイクルを回す

設計の見直しが正しく機能しているかを確認するには、計測ツールを使った検証が欠かせません。GoogleはAndroidのバッテリー消費を分析するためのツールとして、Battery Historianを提供しています^*2。

Battery Historianでわかること

Battery Historian（バッテリーヒストリアン）はAndroidのbugreportから電力消費の履歴を可視化するツールです^*2。どのアプリ・どのコンポーネントが、いつwakelockを取得したか、ジョブがどのタイミングで動いたかを時系列で確認できます。

「画面オフ後も特定のwakelockが長時間保持されている」「予期しない頻度でジョブが実行されている」といった問題を特定するのに役立ちます。修正の前後で計測を行い、消費パターンが変化したかを確認するサイクルを組み込むことが重要です。

改善サイクルの組み方

計測→分析→実装修正→再計測というサイクルを回します。一度に複数の修正を加えると、どの変更が効果を出したかが判断できなくなります。変更を1点ずつ適用して計測する進め方が、原因の切り分けを容易にします。

Googleは過剰なバッテリー消費に関する新しい指標（Excessive battery usage metrics）をAndroidに導入しており、Google Playのデベロッパーコンソールでも電力消費の状態を確認できる仕組みが整備されつつあります^*1。これらの指標を活用して継続的にモニタリングする体制を持つことが、リリース後の品質維持につながります。

iOSの省電力アプローチ：バックグラウンド制限と効率的なネットワーク

iOSにもバックグラウンド実行を制限する仕組みがあり、Androidと同様にアプリ側の設計が電力消費に影響します。

バックグラウンド実行の最小化

iOSはバックグラウンドでのアプリ実行を厳しく制限しています。Background Fetch（バックグラウンドフェッチ）やBackground Processing Taskを使う場合、OSが許可したタイミングでのみ処理が実行されます。

バックグラウンドで行う処理は「本当に必要な最小限」に絞ることが、iOSの省電力設計の基本です。不必要なBackground App Refresh（バックグラウンドアプリ更新）を有効にしたままにしておくと、ユーザーの設定アプリに「バッテリーを多く使用」と表示される原因になります。

位置情報取得の精度とネットワーク効率

iOSでも位置情報の取得精度は用途に合わせた設定にします。常時取得（Always authorization）が必要でない場合は、アプリ使用中のみの許可（When In Use authorization）に留めることが推奨されます。

ネットワーク通信は、複数の小さなリクエストをまとめて1回の通信に集約することが電力効率を高めます。URLSessionの構成でdiscretionary（任意タイミング実行）フラグを活用すると、OSが効率のよいタイミングで通信を行います。Wi-Fi接続時にまとめて同期する設計も有効な手法の一つです。

外注でバッテリー省電力対応を進める場合の進め方

バッテリー消費の最適化を外注する場合、「何が問題か」の診断フェーズと「どう修正するか」の実装フェーズをはっきり区分することが手戻りを防ぐ鍵です。

外注前に整理しておくこと

依頼前に以下の点を整理しておくと、外注先との認識ずれを防げます。

• 問題が顕在化しているプラットフォームはAndroid・iOSのどちら（または両方）か
• 現状の計測データ（Battery Historianのレポートやストアの電力消費指摘など）があるか
• バックグラウンドで行っている処理の一覧と、それぞれの業務上の必要性は整理されているか
• 修正の優先度をどう決めるか（ユーザーへの影響度順か、実装コスト順か）

計測データなしで「バッテリー消費を減らしてほしい」と依頼するだけでは、外注先も手探りになります。Battery Historianのレポートや再現手順を共有できると、診断の精度が上がります。

発注時に確認すべきこと

外注先を選ぶ際の確認ポイントは3点です。

第一に、Android Doze・WorkManager・wakelockの実装経験があるか。公式ドキュメントへの理解度を確認できるとよいです。第二に、Battery Historianなどの計測ツールを使ったデバッグの経験があるか。診断フェーズを外注先が担えるかに直結します。第三に、iOS・Android両プラットフォームへの対応が可能かどうかです。両OS対応の省電力改修を一社に依頼できると、プラットフォーム間での設計方針の整合が取りやすくなります。

内製と外注の比較：スキル要件・工数・リスク

バッテリー消費の最適化を内製で対応するか外注するかは、チームの経験・診断ツールの習熟度・改善を継続的に回せる体制があるかによって変わります。

内製と外注の組み合わせも実務では有効です。診断と初回改修を外注し、再発防止のためのモニタリング設計と継続改善は内製チームが担うという進め方で、知識の移転を図りながら対応できます。

注意点：機能とのトレードオフをどう判断するか

省電力化はアプリの機能と電力消費のバランスを取る作業です。バッテリー消費を抑えるために機能を削りすぎると、ユーザー体験が損なわれます。

リアルタイム性が必要な機能は別途判断する

チャットアプリやライブ配信アプリなど、リアルタイム性がプロダクトの中核にある機能では、バックグラウンド処理の制限によって通知遅延やデータ欠損が生じる可能性があります。「省電力」と「即時性」はトレードオフの関係にあるため、機能ごとに許容できる遅延を整理することが設計判断の出発点です。

Doze中のアラームには`setAndAllowWhileIdle`や`setExactAndAllowWhileIdle`のAPIが用意されており、緊急性の高い通知のみに絞って使うことが推奨されています^*1。全ての通知に使うとDozeの効果が損なわれます。

位置情報の精度と電力消費の関係を把握する

高精度の位置情報が必要なナビゲーションや配達追跡では、GPS常時取得はユーザーが許容する前提で設計されています。しかし「位置情報を活用した機能は一部だけ」というアプリで全機能に高精度モードを適用すると、電力消費が必要以上に高くなります。

機能ごとに「どの精度が最低限必要か」を定義し、それに合った取得設定を選ぶことが重要です。位置情報の取得を「アプリがフォアグラウンドにある間だけ」に限定するだけでも、バッテリーへの負荷を大きく下げられます。

外注先への仕様伝達で注意すること

省電力改修を外注する場合、「バッテリーを減らしたい」という目的と「この機能は動作を変えたくない」という制約の両方を明示することが重要です。制約が伝わらないまま進むと、機能の挙動を変えた修正が入ることがあります。変更してよい処理・変えてはいけない処理のリストを作成して共有することで、発注側と外注先のすり合わせがしやすくなります。

まとめ：バッテリー消費を抑えるための3つの判断軸

本稿では、バッテリー消費の多いアプリが指摘される原因の分析から始まり、wakelock・バックグラウンド処理・位置情報取得という3つの主要因、Android Dozeの仕組みと省電力設計の定石、Battery Historianによる計測サイクル、iOSの考え方、外注の進め方と内製との比較、機能とのトレードオフまでを整理しました。要点を3つに集約します。

第一に、wakelockを適切に管理してバックグラウンド処理をWorkManager・JobSchedulerに集約することがAndroid省電力設計の基本です。Dozeの仕組みを理解した上で、処理をメンテナンス窓に寄せる設計にすることで、CPUとネットワークの不要な起動を減らせます^*1。

第二に、Battery Historianなどのツールで現状を計測してから修正を加えることが、効果的な改善の前提です。問題の箇所を特定せずに実装を変えても、バッテリー消費が改善しているかどうかを判断できません。計測→修正→再計測のサイクルを組み込むことが重要です^*2。

第三に、外注で対応する場合はスコープと機能の制約を事前に合意しておくことで手戻りを防げます。診断フェーズと実装フェーズを区分し、変更してよい処理と変えてはいけない処理のリストを共有することが、外注先との認識ずれを抑えるポイントです。

よくある質問

Android Dozeの状態でも動作させたい処理はどう実装すればよいですか。

Doze中でも即時性が必要な処理（緊急アラームなど）には、`setAndAllowWhileIdle`や`setExactAndAllowWhileIdle`のAlarmManager APIを使います^*1。ただしこれらは使用頻度を低く保つことが推奨されており、全ての通知に使うとDozeの省電力効果が損なわれます。FCMの高優先度メッセージもDoze中の起動に使えますが、同様に限定的な利用が求められます。データ同期など即時性が不要な処理はWorkManagerに移行して、メンテナンス窓での実行に任せることが実務上の基本です。

Battery Historianを使うにはどのような準備が必要ですか。

Battery Historianを使うには、まずAndroid端末でbugreportを取得します^*2。コマンドラインで`adb bugreport`を実行するか、開発者向けオプションからバグレポートを作成します。取得したファイルをBattery Historianのウェブインターフェースにアップロードすると、wakelockの取得状況・ジョブの実行タイミング・ネットワーク通信のパターンが時系列グラフで表示されます。Dockerを使ってローカル環境にBattery Historianを立ち上げる方法もあり、オフライン環境でも利用できます。

iOSアプリのバッテリー消費を診断するツールはありますか。

iOSのバッテリー消費診断にはXcode付属のInstruments（インストゥルメンツ）が利用できます。Energy Log（エネルギーログ）ではアプリのCPU使用率・ネットワーク通信・位置情報取得の頻度を時系列で確認できます。実機でXcodeをつないだ状態でプロファイリングすることで、どのコードパスが電力消費を引き起こしているかを特定しやすくなります。また、iOSのバッテリー設定からアプリごとの消費割合を確認する方法もあり、ユーザーが見ている画面を確認することで問題の規模感を把握する手がかりになります。

省電力対応の改修でアプリがストアに再審査されることはありますか。

バッテリー消費の改善を目的とした実装変更（wakelockの解放・WorkManagerへの移行・位置情報取得頻度の変更など）は、アプリの機能的な変更を伴うためストアへの再提出が必要です。App StoreはiOSの全バージョンアップデートに審査が必要です。Google Playも同様にアップデート提出が必要ですが、内部テストトラックや段階的公開を活用することで、リリースリスクを抑えながら変更を展開できます。外注先に審査対応の経験があるかも確認しておくと進行がスムーズです。

バッテリー消費の改善を外注する場合、どのくらいの期間がかかりますか。

期間はスコープと問題の複雑さによって変わります。Battery Historianによる診断と特定の処理の修正に絞った場合と、アプリ全体のバックグラウンド処理をWorkManagerへ移行する場合では工数が大きく異なります。外注先に現状の計測データと修正対象の処理一覧を提供できると、見積もりの精度が上がります。外注先と初期スコープを絞って合意し、成果を確認しながら追加対応へ拡大する進め方が手戻りを減らしやすいです。具体的な期間については外注先への個別相談をお勧めします。

出典

1. *1　出典：Android Developers「Optimize for Doze and App Standby」（2026年8月確認）
2. *2　出典：Android Developers「Analyze power use with Battery Historian」（2026年8月確認）