LASSIC Media らしくメディア
Androidのバックグラウンド処理（WorkManager/Foreground Service）を実装する外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Androidのバックグラウンド処理はOSバージョンごとに制限が強化されており、要件に応じたAPI選択が開発品質を左右します
- WorkManager・Foreground Service・JobScheduler・AlarmManagerの使い分け基準と最新OS制限への対応ポイントを整理しています
- 外注で進める際の手順・費用感・委託先の選び方を具体的に解説します
目次
Androidバックグラウンド処理が難しい理由
Androidのバックグラウンド処理外注とは、WorkManagerやForeground Serviceといったバックグラウンド実行APIを活用するAndroidアプリ開発を、専門知識を持つ外部パートナーに委託する開発形態です。
Androidはバージョンアップのたびにバックグラウンド処理の制限が強化されており、同じコードが新しいOSで動作しなくなるケースが継続的に発生しています。Android 8.0（Oreo）でのバックグラウンドサービス制限を皮切りに、Android 12・14・15と制限は段階的に厳格化されています。
iOSと異なりAndroidはメーカーによるカスタマイズが加わるため、Google Pixelでは動作するコードがSamsung Galaxy端末で止まる、という事象も珍しくありません。バッテリ最適化機能（Doze・App Standby）の挙動もメーカーにより異なります。
内製で対応しようとすると、Androidの公式ドキュメントとメーカー固有の挙動の両方を追い続ける必要があります。OSごとの制限対応が後手に回り、リリース後に処理が止まるトラブルに発展するリスクがあります。こうしたリスクを抑えるために、専門ベンダーへの外注を検討する企業が増えています。
WorkManager・Foreground Service・JobScheduler・AlarmManager — 要件別の使い分け
バックグラウンド処理のAPIは複数あり、「どの処理をどのAPIで実装するか」の判断がアプリ品質の根幹を左右します。要件を整理しないまま外注に出すと、後から仕様変更が発生しやすくなります。
| API | 主な用途 | 特徴・制約 | 推奨OS |
|---|---|---|---|
| WorkManager | 遅延実行・定期実行・べき等な処理（ログ送信、データ同期、画像圧縮など） | ネットワーク接続・充電中・ストレージ空き等の制約を指定可能。 FGSとして実行も可。WorkManager 2.10.0でSDK 35対応。 |
Android 5.0以上 |
| Foreground Service（FGS） | ユーザーが認識できる継続処理（音楽再生、位置情報追跡、ナビゲーション） | 通知バー常駐が必須。Android 14+はwhile-in-use権限が要るFGSをバックグラウンドから起動すると例外が発生。 FGSタイプ宣言が必要（Android 14+）。 |
Android 9以上で積極活用 |
| JobScheduler | 条件付きバックグラウンドジョブ（Android標準・WorkManagerの下位互換） | WorkManagerがJobSchedulerをラップして使用するため、直接使用は非推奨。 API 21以上のみ。 |
Android 5.0以上（WorkManager推奨） |
| AlarmManager | 精確な時刻トリガー（アラーム、リマインダー） | Android 12+で正確なアラームにSCHEDULE_EXACT_ALARM権限が必要。 遅延実行・定期処理にはWorkManagerを推奨。 |
時刻トリガー用途に限定 |
Google公式のAndroid開発者ドキュメントでは、「延期できる処理はWorkManager、即時かつ継続的な処理はForeground Service」という使い分け方針が示されています*1。
外注依頼時には「処理を延期できるか否か」「ユーザーへの通知提示が許容されるか」「正確な時刻トリガーが必要か」の3点を事前に整理しておくと、RFP（提案依頼書）の精度が上がります。
Android 12/14/15の制限強化と対応の要点
Androidの各バージョンが導入した制限を把握していない外注先に依頼すると、リリース後に処理が止まるか、Googleによるアプリ審査で却下されるリスクがあります。以下に主要な制限変更をまとめます。
Android 12（API 31）：バックグラウンドからのFGS起動制限
Android 12では、アプリがバックグラウンド状態にある場合、原則としてForeground Serviceを新たに起動できなくなりました*1。特例として許可される状況（高優先度プッシュ通知からの起動など）は限定的です。
延期可能な処理・保証実行が必要な処理はWorkManagerへの移行が推奨されます。既存アプリの改修を外注する場合、この制限への対応コストを見積もりに含めることが大切です。
Android 14（API 34）：FGSタイプ宣言と権限の厳格化
Android 14では、Foreground Serviceを使う場合にFGSタイプ（foregroundServiceType属性）をマニフェストに宣言することが必須になりました*1。宣言なしでは起動時に例外が発生します。
またwhile-in-use権限（位置情報・マイクなど、アプリが前面にある間だけ有効な権限）を使うFGSをバックグラウンドから起動しようとすると、SecurityExceptionが発生します。外注先がAndroid 14の変更に対応した実装経験を持っているか、事前に確認が必要です。
Android 15（API 35）：dataSync/mediaProcessing型FGSのタイムアウト制限
Android 15では、dataSync型およびmediaProcessing型のForeground Serviceに新たなタイムアウト制限が導入されました*1。24時間以内で合計6時間を超えると、システムによりサービスが停止されます。
長時間のバックグラウンド処理が必要なアプリ（大容量データ同期・動画処理など）では、このタイムアウトを考慮した処理分割設計が求められます。WorkManagerのチェーン実行を組み合わせることで、制限を受けにくい設計が可能です。
Doze・バッテリ最適化・ANR回避の基礎知識
Doze（低電力モード）とApp Standby（スタンバイバケット）は、バックグラウンドでのネットワークアクセスやアラームを制限します。WorkManagerはDoze考慮済みの制約システムを内包しているため、個別対応の工数を削減できます。
バックグラウンド処理でメインスレッドをブロックするとANR（Application Not Responding）が発生します。ANR対策としてはCoroutines（コルーチン）やRxJavaを使った非同期処理実装が標準的です。外注先の非同期処理実装スキルも確認ポイントになります。
外注で進める手順 — 要件定義から納品まで
バックグラウンド処理の外注は、通常のアプリ開発外注と比べてOS仕様の把握と検証工程が重要になります。以下の手順で進めると、手戻りを抑えられます。
手順1：処理要件の洗い出しとAPI選定方針の確認
どの処理をバックグラウンドで実行したいかを機能単位でリストアップします。「遅延可能か」「継続通知を出せるか」「精確なタイミングが必要か」を各処理に対して確認します。この段階でWorkManager・FGSのどちらを採用するか方針を決めておくと、見積もりのブレが減ります。
手順2：対応OSバージョン範囲の明示
min SDK（最低対応バージョン）とtarget SDK（対象バージョン）をRFPに明記します。Android 12以上の制限対応が必要な場合はその旨を記載し、Android 15対応も要件に含めるかを事前に決定します。対応範囲が広いほど検証コストが増えるため、ユーザー層の分析と合わせて決定します。
手順3：テスト要件の定義
実機テストを行う端末メーカー・OS範囲を指定します。Google Pixel（標準Android）とSamsungは動作差異が出やすいため、最低限この2種類を含めるよう仕様に盛り込みます。Doze状態でのテスト、バッテリ最適化有効時の動作確認も要件に加えます。
手順4：WorkManager 2.10.0（SDK 35対応）の採用確認
WorkManagerを採用する場合は、バージョン2.10.0以上を使用することをRFPに明記します。SDK 35（Android 15）への対応が含まれており、最新のGoogle Playポリシーへの準拠を維持するうえで大切です。
手順5：納品物・保守範囲の取り決め
ソースコード一式・テスト仕様書・実機テスト結果レポートを納品物に含めます。OSアップデート後の動作保証期間も契約に定めておくと、リリース後の追加費用トラブルを防げます。
費用が変わる要素と依頼前の確認ポイント
Androidバックグラウンド処理の実装を外注する際の費用は、処理の複雑さ・対応OS範囲・テスト工数によって大きく変わります。以下の要素を整理してから相見積もりを取ると、比較が容易になります。
- 処理種別と数：WorkManagerの遅延処理のみか、FGSを伴う継続処理も含むか
- 対応OSバージョン幅：Android 12のみか、Android 14・15の最新制限対応まで含むか
- テスト端末種類：実機テストの対象メーカー・バージョン数が増えると検証コストが増加します
- 既存コードの改修か新規実装か：レガシーコードの調査・リファクタリングが必要な場合は工数が増えます
- 保守・アップデート対応の有無：Googleの年次OSアップデートへの継続対応を含めるか否か
費用の参考値は開発会社の規模・所在地・技術スタックにより幅があります。市場参考値として、中規模のバックグラウンド処理実装（WorkManager＋FGS、OS3バージョン対応）は数十万〜数百万円規模となる場合がありますが、これは市場参考値であり一次資料に基づく数値ではありません。正確な費用は複数社への見積もりで確認してください。
依頼前の確認ポイントとして、以下を担当者に確認することをお勧めします。
- Android 14以降のFGSタイプ宣言・権限対応の実装経験があるか
- WorkManager 2.10.0（SDK 35対応）の使用実績があるか
- Doze・バッテリ最適化を考慮した実機テスト体制を持っているか
- 納品後のOSアップデート追従に対応しているか（保守契約の有無）
外注先の選び方 — Android OS制限対応の実績で見極める
バックグラウンド処理は「動いた」から「リリース後も安定して動き続ける」までの品質保証が難しい領域です。外注先を選ぶ際は、以下の観点で絞り込むと失敗リスクを抑えられます。
Android専門エンジニアの在籍確認
Androidの専門エンジニアがいない会社では、OS制限の変更への追従が後手になりがちです。担当エンジニアのAndroid開発年数、Google公式サンプルコードへの理解度を確認します。技術ブログや登壇実績があれば、最新の制限変更に追随しているかの参考になります。
テスト体制の具体性
Doze状態のシミュレーションと実機テストの両方を実施できる体制か確認します。「複数端末での実機テスト済み」と述べる会社でも、対象端末の種類や台数は会社によって異なります。テスト仕様書のサンプルを提示してもらうと実態が見えやすくなります。
元請（プライムベンダー）として対応できるか
バックグラウンド処理の設計はアプリ全体のアーキテクチャと密接に関わります。下請け構造では設計判断の遅延や責任の曖昧さが生まれやすくなります。元請（プライムベンダー）として直接受託し、アーキテクチャ設計から携わる体制を持つベンダーを選ぶと、品質管理の一貫性が保ちやすくなります。
OSアップデート後の保守対応方針
Googleは年1回程度、APIの仕様変更を含むOSアップデートをリリースします。リリース後にアプリが正常動作しなくなるリスクを抑えるために、保守契約によるOSアップデート追従対応が含まれているかを確認します。
まとめ：外注成功の3つの判断軸
本記事では、Androidバックグラウンド処理の外注について整理してきました。要点を3つに集約します。
第一に、WorkManager・FGS・AlarmManagerのAPI選定は要件定義段階で確定させることが大切です。遅延可能な処理はWorkManager、ユーザーが認識できる継続処理はFGSという使い分け原則を押さえた外注先を選ぶことが重要です。
第二に、Android 12・14・15の制限変更への対応経験を持つ外注先を選ぶことで、リリース後の突発的なバグや審査却下リスクを大幅に抑えられます。FGSタイプ宣言・SDK 35対応WorkManagerの使用実績を事前確認することが有効です。
第三に、OS仕様変更は毎年発生するため、リリースで終わらない保守体制の取り決めが、長期的なアプリ品質維持の前提条件になります。元請（プライムベンダー）として直接受託する体制を持つベンダーへの依頼が、品質一貫性の観点から適しています。
よくある質問
WorkManagerとForeground Serviceはどちらを選べばよいですか？
処理を「遅延できるか否か」で判断するのが基本です。ログ送信・データ同期・画像処理など、今すぐ実行しなくてよい処理はWorkManagerが適しています。一方、音楽再生・位置情報追跡など、ユーザーが認識できる状態で継続する処理はForeground Serviceを使います。Android公式ドキュメントでも同様の使い分け方針が示されています*1。
Android 15対応は必須ですか？外注費用は上がりますか？
Google Playの対象APIレベルポリシーにより、新規アプリ・既存アプリともに一定期間内に最新target SDKへの対応が求められます。Android 15（API 35）への対応はdataSync/mediaProcessing型FGSを使う場合に特に影響が大きく、タイムアウト制限への設計対応が必要です。対応OSバージョン幅が広いほど検証コストが増加するため、費用への影響は外注先への見積もり段階で確認することをお勧めします。
既存のAndroidアプリを最新OS制限に対応させる改修は外注できますか？
改修外注は可能です。ただし既存コードの調査・理解から始まるため、新規開発よりも工数の見積もりが難しくなります。FGSタイプ宣言の追加やWorkManagerへの処理移行など、変更範囲によって工数は大きく異なります。既存コードのドキュメントや設計書を事前に準備しておくと、正確な見積もりを得やすくなります。
外注先を選ぶときに確認すべきポイントは何ですか？
Android 14以降のFGSタイプ宣言・権限対応の実装経験と、WorkManager 2.10.0（SDK 35対応）の使用実績を確認することをお勧めします。テスト体制についてはDoze状態・実機複数端末での検証実績を確認します。また、年次OSアップデートへの追従を含む保守契約を提供しているかも大切な確認ポイントです。
Dozeモードでバックグラウンド処理が止まる問題は外注で解決できますか？
Doze（低電力モード）によるバックグラウンド処理の停止は、WorkManagerを使うことで大幅に緩和できます。WorkManagerはDozeを考慮した制約システムを内包しており、指定した制約（ネットワーク接続・充電中など）が満たされたタイミングで処理を再実行します。外注先にDoze状態での実機テストを要件として明示することで、リリース後の不具合リスクを抑えられます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google「Background work overview — Android Developers」（2024年更新）
