ロック画面でのリアルタイム追跡は、これまでiOSだけの話でした。ライド、配達、注文が進行しているとき、iPhoneユーザーはLive Activityでその様子を確認できましたが、Androidユーザーには「確認済み」と「配達完了」の間に散発的なプッシュ通知が届くか、あるいは何も届かないかのどちらかでした。
Android 16はこの差を埋めます。新機能Live Updatesは、進行状況をライブで表示するトラッキングを、Androidのロック画面・通知ドロワー・ステータスバーにもたらします。ライフサイクル施策を運用するチームにとって、これは設計したリアルタイム体験がユーザーの半分にしか届いていなかった状態が終わることを意味します。日本市場はiOSユーザーの比率が高い市場ですが、だからこそAndroidユーザー向けの体験差はそのまま取りこぼしにつながっていました。1つのSDK・1つの管理画面で、プラットフォームを問わず同じリアルタイム体験を設計できるようになります。
この記事では、Android Live Updatesとは何か、どのようなシーンに適しているか、そしてPushwooshでAndroid Live Updatesの配信を始める方法をご紹介します。
Android Live Updatesとは
Android Live Updateは、進行中のアクティビティを表す通知で、システムがロック画面に昇格させ、通知ドロワーに保持し、ステータスバーにチップとして固定表示します。ユーザーはアプリを開かなくても、進行中の出来事を追い続けられます。
ライフサイクル全体はサーバー側で制御します。アクティビティ開始時に1件のプッシュを送り、進行に応じて追加のプッシュを送り、終了時に最後のプッシュを送ります。各プッシュは新規通知を積み上げるのではなく、同じ通知をその場で更新します。この仕組みを支えるのは3つの操作です：startが通知を表示し、updateがサイレントで内容を更新し、endが通知を消去します。
すでにiOS Live Activitiesを運用している場合、これはそのAndroid版にあたります。リアルタイムイベントを表す、自己更新型のライブカードという考え方は同じで、Android 16のプログレス中心の通知の仕組みの上に構築されています。設定の作り方は異なりますが、マーケティング上の役割は同一です：一歩ごとに通知を送りつけるのではなく、ユーザーに継続的に状況を伝え続けることです。
実際の例：ライド追跡を最初から最後まで 🚕
標準的な配車フローを例に見てみましょう。一連のプッシュ通知の代わりに、乗車全体を1つのLive Updateで表現します。
1. 開始 — ドライバーが割り当てられます。 ドライバーが依頼を承知した瞬間、バックエンドが開始プッシュを送信します。ロック画面にLive Updateが表示されます：「田中さんが向かっています — あと4分」。車両情報と到着予定時刻付きです。乗客はアプリを開かずにこれを確認できます。
2. 更新 — 乗車が進行します。 ドライバーが近づき、乗車が進むにつれて、バックエンドは同じアクティビティに対して更新プッシュを送信します。カードはその場で更新されます — 向かっています → まもなく到着 → 乗車中 — 到着予定時刻が再計算され、状況は車両の動きと常に同期します。バイブレーションも新規通知もなく、常に正確な現在の状態だけが表示され続けます。
3. 終了 — 乗車が完了します。 最終プッシュがLive Updateを終了させます：「到着しました。運賃：¥1,840。」 通知は自動的に消去されます。ループはこれで閉じます。
乗客の体験は、一連のプッシュ通知から、中断ゼロと高い可視性へと変わりました — 乗車開始から降車までロック画面上でライブに追跡できる体験は、点滅して消えるだけの通知よりも優れています。しかもカードが画面に残り続けるため、ロック画面は再訪の入口になります：アクティブなLive Updateを持つユーザーは、アプリを開く頻度が下がるどころか、むしろ上がる傾向があります。
年末年始やゴールデンウィークのような配送・移動が集中する繁忙期こそ、この可視性の差が顧客満足度に直結します。
Live Updatesが力を発揮する場面：アプリタイプ別
同じパターンは、明確な開始と終了を持つ「いま起きていること」をユーザーが追いたい場面であれば、どこでも機能します。
| アプリタイプ | 開始 | ライブで更新される内容 | 終了 |
|---|---|---|---|
| EC・宅配便 | 注文確定／発送 | 準備中 → 配送中 → 近くにいます → 到着予定時刻 | 配達完了 |
| ライドシェア・配車 | ドライバー割り当て | 現在地、到着予定時刻、走行状況 | 乗車完了 |
| モバイルゲーム | イベント開始 | スコア、進捗、残り時間 | 結果発表 |
| フィンテック | 送金・取引開始 | 本人確認、処理状況の各ステージ | 取引完了 |
| フィットネス | ワークアウト開始 | 経過時間、距離、進捗 | セッション終了 |
どの行も原則は同じです：アクティビティはユーザー起点で、時間の制約があり、継続中であることです。Live Updateは開始から終了までの状態を担い、プッシュ通知は本当に判断が必要な瞬間にだけ発火します。
プッシュ通知やLive Updatesと合わせて、LINE公式アカウントを組み合わせたオムニチャネル設計にすることで、Android・iOSを問わず一貫した再エンゲージメント導線を作れます。
Live Updatesを使うべきでない場面 🚫
Live Updatesには1つの絶対ルールがあり、Androidはこれを厳格に運用しています：Live Updatesは、ユーザー起点で時間の制約があり、実際に進行中のアクティビティのためのものであり、それ以外には使えません。
対象外となるのは次のケースです。
- プロモーション、オファー、キャンペーンメッセージ。 Live Updateはマーケティング面ではありません。これらはプッシュ通知、アプリ内メッセージ、メールに残してください。
- チャットメッセージや背景情報。 会話や、ライブアクティビティに該当しない「念のためのお知らせ」の通知は対象外です。
- ユーザーが消去したもの。 スワイプして消されたLive Updateを再表示しないでください。
これは制限ではなく保護と捉えてください。Live Updateがロック画面に恒常的な居場所を得られるのは、まさにユーザー自身が追跡を求めたものだけに限定されているからです。マーケティングで埋めてしまえば、その価値は失われ、Androidはそれを許容しなくなります。
Pushwooshでの設定方法 🛠️
Live Updatesを手動で送ることはありません。すでにアプリが追跡しているイベントがそのまま発火元になります。設定は開発チームによる一度限りの作業で、3つのステップに分かれます。
-
フローと3つの瞬間を選ぶ
1つのリアルタイムアクティビティ（注文、ライド、配達など）を選び、その開始、間の更新、終了を明確にします。これがLive Updateに必要な全体の設計図です。
-
既存のイベントと接続する
開発チームが、すでに追跡しているステータス変更を配線し、それぞれが対応する瞬間を送信するようにします：アクティビティ開始時に開始、ステータス変更ごとに更新、完了時に終了。
-
Pushwooshにレンダリングを任せる
SDKが通知を自動で描画します — プログレスバー、アイコン、ライブチップ — そして更新のたびにその場で再描画します。メッセージごとにデザインする必要はありません。
これで完了です。すでにプッシュ通知・メール・アプリ内メッセージで使っている同じPushwooshプロジェクト内での一度限りの連携であり、以降は実際のイベントに沿って自動で動作します。
PushwooshはSOC 2 Type IおよびISO 27001:2022の認証を取得済みで、GDPR・HIPAAに準拠し、EUと米国のデータセンターで運用しています。社内の情報システム部門による導入審査の際にも、この体制をそのままご説明いただけます。
