LASSIC Media らしくメディア
アプリのジオフェンス実装、外注の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ジオフェンス（地理的境界の出入り検知）とバックグラウンド位置情報の実装を、iOSとAndroidそれぞれの仕組みから整理します。
- OS別の権限モデル・省電力制約・登録上限の違いが、内製開発のつまずきどころになりやすい点を説明します。
- 許可UX設計や省電力対応を含めた実装を外部パートナーに委託する際の判断材料を紹介します。
目次
アプリのジオフェンス・バックグラウンド位置情報実装とは
アプリのジオフェンス・バックグラウンド位置情報実装とは、端末の現在地があらかじめ設定した地理的境界（円形の仮想エリア）に出入りしたことを検知し、アプリがバックグラウンドで動いている間もその通知を受け取れるようにする実装を指します*1*2。来店検知や現場入退場管理、忘れ物防止など、ユーザー操作を介さずに位置ベースのアクションを起こす機能の中核になります。
iOSの実装基盤 — Core LocationとCLCircularRegion
iOSでは、Core Location（位置情報関連の機能をまとめたApple公式フレームワーク）が提供するリージョンモニタリング機能でジオフェンスを実装します*1。円形の地理的境界はCLCircularRegionクラスで定義し、中心座標・半径・一意な識別子を指定します*1。
CLCircularRegionにはnotifyOnEntry（入域時に通知するか）とnotifyOnExit（出域時に通知するか）の2つの真偽値プロパティがあり、用途に応じて片方または両方を有効にします*1。監視の開始後はOS側が省電力な仕組みで境界の出入りを判定するため、アプリが常時位置を取得し続ける必要はありません*1。
ただし、1つのiOSアプリが同時に監視できるリージョンは上限20件に制限されています*1。店舗数や現場数がこれを超える場合は、ユーザーの現在地に応じて監視対象を動的に入れ替える設計が必要になります。
Always権限とバックグラウンド更新の設定
リージョンモニタリングをバックグラウンドで機能させるには、位置情報の使用許可として「常に許可（Always）」をユーザーから取得する必要があります。Appleは許可のリクエストを段階的に行うことを推奨し、まず使用中のみの許可（When In Use）を求め、許可された後にAlwaysへのアップグレードを促す流れを案内しています*2。
継続的な位置更新をバックグラウンドで受け取る場合は、CLLocationManagerのallowsBackgroundLocationUpdatesプロパティをtrueに設定します*2。Always権限を持つ機能では、バックグラウンドで位置情報を使用していることをユーザーに知らせるインジケーター表示も併せて有効にする設計が求められます*2。Always許可は取得のハードルが高いため、機能の価値を明確に伝えるタイミングでリクエストする設計が欠かせません。
Androidの実装基盤 — Geofencing APIとフォアグラウンドサービス
AndroidではGoogle Play開発者サービスが提供するGeofencing APIを使ってジオフェンスを実装します*3。実体はLocationServicesから取得するGeofencingClientで、Geofenceオブジェクトの集合とPendingIntentを渡すことで境界の登録・解除を行います*3。1アプリあたり登録できるジオフェンスは、シングルユーザー端末で上限100件です*3。
ジオフェンスサービスは位置情報を継続的に問い合わせる方式ではなく、入域・出域の通知には数分程度の遅延が生じる場合があります*3。この省電力設計そのものは合理的ですが、精度と応答速度のバランスを取る設計判断が実装時に必要になります。
バックグラウンド位置情報許可の制約
Android 10（APIレベル29）以降では、バックグラウンドでの位置情報アクセスにACCESS_BACKGROUND_LOCATION権限が新設されました*4。アプリのActivityが画面に表示されておらず、位置情報タイプのフォアグラウンドサービスも動いていない状態は「バックグラウンド」と判定され、この権限がなければ位置情報を取得できません*4。
さらにAndroid 8.0（APIレベル26）以降は、バックグラウンド動作時の位置更新回数が1時間あたり数回程度に絞られる電池保護の仕組みも働きます*4。継続的な位置監視が必要な機能では、フォアグラウンドサービスとして動作させる設計が実質的に前提になります。
Android 14以降のフォアグラウンドサービス宣言義務
Android 14（APIレベル34）以降をターゲットにする場合、フォアグラウンドサービスには適切なサービスタイプの宣言が必須です*5。位置情報用途では、マニフェストへのタイプ宣言に加えてFOREGROUND_SERVICE_LOCATION権限の申請が必要で、ユーザーからACCESS_COARSE_LOCATIONまたはACCESS_FINE_LOCATIONの許可も得ていなければなりません*5。この宣言を怠ると、サービス起動時にSecurityExceptionが発生してサービス自体が起動できなくなります*5。
iOS・Androidの対応関係を比較する
両OSは同じ「ジオフェンス」という概念を提供しますが、APIの構造・権限モデル・上限値はそれぞれ独自です。実装を横断で見比べると、移行や同時対応の際に見落としやすい差分が浮かび上がります。
| 観点 | iOS（Core Location） | Android（Geofencing API） |
|---|---|---|
| 境界の定義 | CLCircularRegion（中心座標・半径・識別子）*1 | Geofenceオブジェクト（GeofencingRequestに集約）*3 |
| 登録上限 | 同時監視は上限20件*1 | 1アプリ上限100件（端末単位）*3 |
| バックグラウンド権限 | Always（常に許可）。When In Use経由の段階リクエストが前提*2 | ACCESS_BACKGROUND_LOCATION（Android 10以降必須）*4 |
| 継続動作の仕組み | allowsBackgroundLocationUpdates＋バックグラウンドインジケーター表示*2 | 位置情報タイプのフォアグラウンドサービス（Android 14以降は宣言必須）*5 |
| 検知の遅延・省電力 | OS側で省電力に境界判定。継続測位より遅延を許容する設計*1 | 通常2分未満の遅延を想定した省電力設計*3 |
内製で難所になる4つの論点
ジオフェンスの登録自体はAPIドキュメント通りに実装すれば動きますが、実運用に耐える品質にするには複数の論点を同時に扱う必要があります。ここを軽視すると、権限が得られず機能が動かない、電池消費でアンインストールされるといった事態につながります。
許可UX設計 — Always許可の取得率を左右する導線
Always許可は取得のハードルが高く、唐突にリクエストすると拒否されやすい許可区分です*2。機能の価値を先に説明する画面設計、When In Use許可後の適切なタイミングでのアップグレード導線など、OSのAPI仕様だけでは決まらないUX設計が必要になります。ここを誤ると、ジオフェンス機能自体が実質的に動作しないアプリになってしまいます。
省電力とのトレードオフ — 検知精度と電池消費の両立
ジオフェンス半径を小さくすれば検知精度は上がりますが、判定頻度や補足的な測位処理が増え電池消費が大きくなりやすい傾向があります。Androidでは通知の応答性（responsiveness）の値を調整して電力効率を高める設定も可能で*3、iOS・Android双方でアプリの用途に応じたチューニングが求められます。この調整には、両OSの内部挙動への理解と実機での検証工数が必要です。
OS別のバックグラウンド制限 — 権限モデルの非対称性への対応
iOSのAlways許可、AndroidのACCESS_BACKGROUND_LOCATIONとフォアグラウンドサービス宣言は、名称も判定基準も異なる別々の権限モデルです*2*4。両OSに対応するアプリでは、権限リクエストの分岐・エラーハンドリング・許可拒否時のフォールバック動作を個別に設計する必要があります。
OSバージョン差分の追随 — 仕様変更への継続対応
Android 14以降のフォアグラウンドサービスタイプ宣言義務のように、OSのメジャーバージョンアップでバックグラウンド位置情報の扱いが変わることがあります*5。この作業を内製で行うには、iOS・Androidそれぞれの位置情報APIの知識、権限UX設計の知見、そしてOSアップデートへの継続対応体制が必要です。専門知識を持つ人員を確保できない場合、リリース後の仕様変更対応が後手に回るリスクがあります。
外注で解決する進め方と依頼のポイント
ジオフェンス・バックグラウンド位置情報の実装を外部パートナーに依頼する場合、iOS・Android双方の権限モデルとバックグラウンド制限を踏まえた設計を任せられる点が価値になります。内製では許可UXの検証や電池消費の実機テストに時間がかかりやすく、外注によって開発速度と品質の両方を確保しやすくなります。
依頼するアプリに来店検知の機能があるという状況では、Always許可の取得率を高める画面遷移の設計から、Androidのフォアグラウンドサービス実装、リリース後のOSバージョン対応までを一括して相談できるパートナーを選ぶことが、運用の安定につながります。
まとめ：ジオフェンス実装で押さえる3つの判断軸
本稿では、アプリのジオフェンス・バックグラウンド位置情報実装をiOSのCore LocationとAndroidのGeofencing APIの両面から整理しました。要点を3つに集約すると、第一にiOSは上限20件・Androidは上限100件という登録上限の違いを踏まえた設計が必要です。第二に、iOSのAlways許可・AndroidのACCESS_BACKGROUND_LOCATIONという異なる権限モデルへの対応が欠かせません。第三に、省電力とのトレードオフやOSバージョンごとの仕様変更に、継続的に追随する体制が求められます。
よくある質問
ジオフェンスとバックグラウンド位置情報の実装には、どのくらいの期間がかかりますか。
既存アプリへの機能追加か新規アプリ全体の開発かで大きく変わるため、一概の期間はお答えできません。iOS・Android両対応かどうか、許可UX設計や実機での省電力検証をどこまで行うかによって工数が変動します。お問い合わせで要件を伺えれば、目安をご案内できます。
iOSのリージョン監視の上限20件を超える店舗数がある場合、どうすればよいですか。
ユーザーの現在地に応じて監視対象を動的に切り替える設計が必要です*1。近隣の店舗のみを常時監視し、大きく移動したタイミングで監視対象を入れ替えるロジックを組み込むことで、上限内での運用が可能になります。
Always許可を拒否されると、ジオフェンス機能は使えなくなりますか。
Always許可がない場合、バックグラウンドでの入退場検知は機能しません。アプリを起動中のみ動作する代替フローを用意するか、許可の価値を伝える画面設計を見直して取得率を高める対応が必要です*2。
Androidだけ先行して実装し、iOSは後から対応することは可能ですか。
可能です。ただし権限モデルや上限値がOSごとに異なるため、共通の設計方針を決めた上でOS別に実装を進めると、後からの対応追加がスムーズになります。
バックグラウンド位置情報の実装は、アプリ全体の開発と別に外注できますか。
既存アプリへの機能追加としての外注は可能です。既存のアーキテクチャやアプリストア審査の要件を確認した上で、ジオフェンス機能単体の実装・許可UX改善を委託する進め方が一般的です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple Developer Documentation「Monitoring the user’s proximity to geographic regions」
- *2 出典：Apple Developer Documentation「Handling location updates in the background」
- *3 出典：Android Developers「Create and monitor geofences」
- *4 出典：Android Developers「Access location in the background」（Android 10以降のACCESS_BACKGROUND_LOCATION）
- *5 出典：Android Developers「Foreground service types are required」（Android 14／APIレベル34以降）
