サイレントプッシュ通知：仕組み、iOSおよびAndroidの設定、戦略的ユースケース

プッシュ通知に関するガイドの多くは、ユーザーが目にするメッセージに焦点を当てています。サイレントプッシュ通知は、ユーザーが決して見ることのない通知であり、まったく異なる役割を果たしています。

サイレントプッシュはバックグラウンドでアプリを起動し、タスクを実行してから再びスリープ状態に戻します。アラートも、通知音も、バッジも表示されません。ユーザーがアプリを開くと、新鮮なコンテンツがすでに読み込まれています。プッシュが行われたことにユーザーは気づきません。それがサイレントプッシュの目的です。

このガイドでは、iOSおよびAndroidにおけるサイレントプッシュ通知の仕組み、コードでの実装方法、そしてカスタマージャーニー自動化の一部として戦略的に活用する方法を解説します。また、Pushwooshがクロスプラットフォームのサイレントプッシュ配信を処理し、自動化ワークフローに統合する方法もご紹介します。

サイレントプッシュ通知とは何か？

サイレントプッシュ通知とは、ユーザーに何も表示せずにアプリをバックグラウンドで起動するサーバー主導のメッセージです。アラートも、通知音も、バッジもありません。OSがプッシュを受信すると、アプリを一時的に有効化し、アプリがバックグラウンドタスクを実行してから、再びスリープ状態に戻ります。

標準的なプッシュとの違いはシンプルです。視覚的なプッシュはユーザーへのメッセージであり、サイレントプッシュはアプリへの命令です。

バックグラウンドの数秒間に、アプリは何ができるのでしょうか？

• 新しいコンテンツの取得。 最新の記事、更新された商品カタログ、または更新されたソーシャルフィードを取得して、ユーザーがアプリを開いたときにすぐ表示できるようにします。
• データの同期。 サーバーまたは他のチャネルで発生した変更（ウェブサイトでの購入、バックエンドシステムでのステータス変更など）とローカル状態を同期します。
• 位置情報の評価。 視覚的な通知をトリガーとして使わずに、ユーザーがジオフェンスに入ったかどうかを確認します。
• ユーザータグやセグメントデータの更新。 最新の行動シグナルをCDPに送り返して、ターゲティングの精度を維持します。
• 次の視覚的通知のためのコンテンツのプリロード。 トリガーされた際に即座にレンダリングされるよう、アプリ内メッセージやリッチプッシュのペイロードを準備します。

実用的な価値：ユーザーはすでに最新状態になっているアプリを開きます。ローディングスピナーも、古いデータもありません。この速度と鮮度の感覚は、ユーザーがアプリの使い心地を言語化できない場合でも、リテンションに測定可能な効果をもたらします。

サイレントプッシュ通知の仕組み

配信の流れは通常のプッシュ通知と同じです。サーバーがペイロードをAPNs（iOS）またはFCM（Android）に送信し、そのサービスがデバイスに配信し、OSが処理を行います。異なるのはペイロードの構造と、到着時にOSが行う動作です。

配信フロー

1. サーバーがペイロードを送信する。 バックエンドまたはPushwooshが特別に作成されたメッセージをAPNsまたはFCMに送ります。
2. サービスがデバイスに配信する。 APNsまたはFCMは、保存されたデバイストークンを使用してペイロードを正しいデバイスにルーティングします。
3. OSがアプリを起動する。 ペイロード内のサイレントプッシュフラグを認識し、OSがアプリをバックグラウンドで一時的に有効化します。
4. アプリがバックグラウンドタスクを実行する。 コードが実行されます：データの取得、状態の同期、位置の確認、タグの更新。
5. アプリが完了を通知する。 iOSでは、アプリが完了ハンドラーを呼び出します。Androidでは、onMessageReceived()が返ります。OSがアプリを再びスリープ状態に戻します。

バックグラウンドウィンドウには制限があります。iOSでは約30秒です。Androidはデバイスと電力状態によって異なります。バックグラウンドタスクは素早く完了するか、これらの制約内で機能するよう設計する必要があります。

ペイロードの違い：iOS vs. Android

iOSで最もよくある間違いは、apns-push-type: backgroundと一緒にapns-priority: 5を設定し忘れることです。優先度が10（視覚的なプッシュのデフォルト）に設定されていると、Appleはメッセージを拒否したり、アラート本文がなくても視覚的に表示したりする場合があります。低優先度は、これがバックグラウンドタスクであり緊急通知ではないことをAPNsに示すシグナルです。

Androidでの重要なルールはよりシンプルです。FCMペイロードにnotificationオブジェクトを含めないことです。notificationオブジェクトが存在すると、Androidは通常のプッシュ通知として処理して表示します。サイレントプッシュ = データのみです。

iOS実装

Xcodeの設定

コードを書く前に、XcodeでBackground Modesを有効にしてください。

1. プロジェクトを開き、アプリのターゲットを選択します。
2. 「Signing & Capabilities」に移動し、「+ Capability」をクリックします。
3. 「Background Modes」を追加し、「Remote Notifications」にチェックを入れます。

Apple Developer PortalのApp IDでPush Notificationsが有効になっていることを確認してください。この変更後はプロビジョニングプロファイルを再生成してください。

リモート通知の登録

サイレントプッシュもAPNsへのデバイス登録が必要です。AppDelegateでこれを処理します。

import UIKit
import UserNotifications

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions:
            [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        UNUserNotificationCenter.current().delegate = self
        UNUserNotificationCenter.current().requestAuthorization(
            options: [.badge, .sound, .alert]
        ) { granted, _ in
            if granted {
                DispatchQueue.main.async {
                    application.registerForRemoteNotifications()
                }
            }
        }
        return true
    }

    func application(_ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
        let token = deviceToken.map {
            String(format: "%02.2hhx", $0) }.joined()
        // Pushwoosh iOS SDK handles token submission automatically
    }
}

サイレントプッシュのハンドリング

サイレントプッシュが到着したときにiOSが呼び出すメソッドは次のとおりです。

extension AppDelegate {

    func application(_ application: UIApplication,
        didReceiveRemoteNotification userInfo: [AnyHashable: Any],
        fetchCompletionHandler completionHandler:
            @escaping (UIBackgroundFetchResult) -> Void) {

        guard let aps = userInfo["aps"] as? [String: AnyObject],
              aps["content-available"] as? Int == 1 else {
            completionHandler(.noData)
            return
        }

        // Run your background task here
        fetchLatestContent { success in
            completionHandler(success ? .newData : .noData)
        }
    }
}

30秒のウィンドウが閉じる前に必ずcompletionHandlerを呼び出してください。呼び出さない場合、iOSはアプリを終了させ、将来のサイレントプッシュをスロットリングする可能性があります。何かを取得した場合は.newData、変更がなければ.noData、タスクがエラーになった場合は.failedを渡してください。

サイレントプッシュのAPNsペイロード

{
    "aps": {
        "content-available": 1
    },
    "update_type": "content_refresh",
    "content_id": "latest_feed"
}

このペイロードと合わせて必要なAPNsヘッダー。

• apns-push-type: background
• apns-priority: 5

Android実装

FCMのセットアップとマニフェスト

AndroidManifest.xmlにFirebaseMessagingServiceを追加します。

<service
    android:name=".MyFirebaseMessagingService"
    android:exported="false">
    <intent-filter>
        <action android:name="com.google.firebase.MESSAGING_EVENT" />
    </intent-filter>
</service>

Kotlinでのデータメッセージのハンドリング

FirebaseMessagingServiceを拡張してonMessageReceivedを実装します。

class MyFirebaseMessagingService : FirebaseMessagingService() {

    override fun onNewToken(token: String) {
        // Pushwoosh Android SDK handles token submission automatically
    }

    override fun onMessageReceived(remoteMessage: RemoteMessage) {
        // Silent push = data payload only, no notification object
        if (remoteMessage.data.isNotEmpty()
            && remoteMessage.notification == null) {
            handleSilentPush(remoteMessage.data)
        }
    }

    private fun handleSilentPush(data: Map<String, String>) {
        when (data["update_type"]) {
            "content_refresh" -> {
                // Fetch new content from your server
                refreshContentFeed(data["content_id"])
            }
            "segment_update" -> {
                // Push updated tags to Pushwoosh
                syncUserSegmentData()
            }
            "location_check" -> {
                // Evaluate current geofence status
                evaluateGeofences()
            }
        }
    }
}

サイレントプッシュのFCMペイロード

ペイロードにはdataオブジェクトが含まれ、notificationオブジェクトは含まれてはなりません。

{
    "to": "DEVICE_TOKEN",
    "data": {
        "update_type": "content_refresh",
        "content_id": "latest_news_feed"
    }
}

priorityを「high」に設定するのは、時間重要なバックグラウンドタスクの場合のみにしてください。ほとんどのコンテンツ更新のユースケースでは標準的なpriorityで十分であり、不必要なバッテリー消費を避けられます。

Pushwooshによるクロスプラットフォームのサイレントプッシュ

サイレントプッシュをiOSとAndroidで手動管理するということは、2つの異なるペイロード形式、2セットの配信ヘッダー、2セットのSDK統合を維持することを意味します。Pushwooshはそれを抽象化します。

PushwooshからサイレントプッシュをトリガーするとGUI経由でもAPI経由でも、プラットフォームは各ターゲットプラットフォームに対して正しいペイロードを自動的に生成します。APNsは適切なヘッダーとともにcontent-available: 1を受け取ります。FCMはデータのみのメッセージを受け取ります。キャンペーンは1回設定するだけです。

デバイストークンの管理は一元化されています。iOSトークン、Androidトークン、ウェブプッシュのサブスクリプションはすべて1か所に保存・更新されます。トークンが変更された場合（再インストール、OSアップグレード）、Pushwooshが更新を処理します。

技術者以外のチームメンバーのために、Pushwooshはペイロードを書かずにサイレントプッシュをスケジュールおよびトリガーするためのUIを提供しています。これにより、サイレントプッシュをカスタマージャーニービルダーのワークフローに、視覚的な通知やアプリ内メッセージと並べて統合することが実用的になります。

戦略的ユースケース

サイレントプッシュ通知は、可視性が実際には逆効果になる場合に最も価値を発揮します。標準的なプッシュよりもサイレントプッシュが適しているシナリオを以下にご紹介します。

ニュースおよびメディアアプリのコンテンツプリフェッチ

速報アラートを送信するニュースアプリは、30秒前に送信されたサイレントプッシュのメリットを活かせます。サイレントプッシュがアプリを起動し、アプリが記事を取得してローカルにキャッシュします。視覚的なアラートが発動したとき、タップすると記事が即座に開きます。記事の読み込みを待つ必要はありません。

パーソナライズされたフィードを持つアプリの場合、典型的な起床時間にサイレントプッシュを送ることで、ユーザーがアプリを開く前に朝のコンテンツをプリフェッチできます。データがすでに用意されているため、アプリが速く感じられます。

視覚的なトリガーなしのジオフェンス評価

ユーザーが店舗の近くを歩いています。標準的なアプローチ：位置情報ベースのプッシュ通知を送信します。問題点：ユーザーがオプトインしている必要があり、タイミングがずれる可能性があり、追跡されているように感じる場合があります。

サイレントプッシュアプローチ：ユーザーがある地域内にいるとき、サーバーがサイレントプッシュを送信します。アプリはクライアント側で正確なジオフェンスを確認します。条件が一致する場合、アプリは適切なタイミングでアプリ内メッセージまたはローカル通知を有効化します。視覚的なコミュニケーションは、ロジックが通過した場合のみ発生します――トリガーそのものとしてではなく。

アプリ外アクティビティ後のセグメントデータの正確性維持

ユーザーがウェブサイトで購入しました。RFMセグメントはすぐに更新されるべきです。しかしアプリは、ユーザーが開くまでそれを知ることができません。

ウェブ購入後に送信されたサイレントプッシュがバックグラウンドでアプリを起動し、最新の購入イベントをPushwooshに同期します。ユーザーはリアルタイムで正しいRFMセグメントに移動します。フォローアップキャンペーン（ロイヤリティ報酬、クロスセル、サンキューシーケンス）が正確なデータに基づいて発動します。

アプリ内メッセージ用のコンテンツのプリロード

レンダリングにサーバー取得が必要なアプリ内メッセージは、目立つ遅延が生じる可能性があります。ユーザーがアプリ内メッセージをトリガーする前に送信されるサイレントプッシュが、コンテンツをプリフェッチしてローカルに保存します。メッセージが発動すると、即座に表示されます。

このパターンは、コンテンツがパーソナライズされていてアプリバイナリにハードコードできないオンボーディングフロー、機能アナウンス、プロモーションオーバーレイに適しています。

ベストプラクティス

OSのスロットリング制限を尊重する

iOSは頻繁に届くサイレントプッシュをスロットリングします。Appleのガイダンスでは、1時間に約2〜3回、つまり最低でも約21分に1回が目安です。これを超えるアプリは、エラーなしにサイレントプッシュが遅延または削除される場合があります。

AndroidのDozemoodeとApp Standbyは、デバイスがアイドル状態のときにバックグラウンド実行を制限します。高優先度のFCMメッセージはDozemoode中にアプリを起動できますが、選択的に使用すべきです。標準優先度のメッセージは、デバイスがDozemoodeを終了するまで延期されます。

実用的なルール：バックグラウンドタスクが本当に時間重要である場合のみサイレントプッシュを送信してください。自然なリズム（朝、またはサーバー側の更新後）で一度コンテンツをプリフェッチすることは問題ありません。データを新鮮に保つために10分ごとに送信することは適切ではありません。

ペイロードを小さく、タスクを素早く保つ

サイレントプッシュのペイロードはシグナルであり、データ転送ではありません。アプリに何を取得してどこから取得するかを伝えるために必要な最小限のものを送信してください。実際のデータ取得は、プッシュ到着後にアプリ内で行われます。

バックグラウンドタスクは制限時間内に十分完了する必要があります。タスクに数秒以上かかる場合は、中断可能に設計してください。進捗を保存し、完了ハンドラーを呼び出し、次の機会に再開します。長時間のバックグラウンドタスクはOSによる終了のリスクがあり、ユーザーが気づくほどバッテリー寿命に影響を与える可能性があります。

電力状態とOEMバリアントにわたってテストする

サイレントプッシュの動作はAndroid OEMによって大きく異なります。Xiaomi、Huawei、OnePlusはすべて、ホワイトリストに載っていないアプリのバックグラウンド実行を完全に妨げる可能性のある積極的なバッテリー最適化を持っています。標準のAndroidエミュレーターだけでなく、これらのメーカーの実際のデバイスでテストしてください。

iOSでは、低電力モードとアプリが強制終了された状態でテストしてください。これらの状態でのサイレントプッシュ配信の信頼性は低く、バックグラウンドロジックはユーザーがアプリを開く前にタスクが実行されなかった場合を処理できるようにする必要があります。

ダウンストリームイベントを通じて効果を追跡する

サイレントプッシュはクリック指標を生成しません。それらが引き起こすべきイベントを通じて効果を追跡してください。content_refreshed、segment_updated、geofence_evaluatedなどです。サイレントプッシュキャンペーン後にこれらのイベントが期待される頻度で発生しなくなった場合、配信がスロットリングされているか、バックグラウンドハンドラーが失敗している可能性があります。

Pushwoosh Analyticsはキャンペーンデータとともにアプリイベントを表示します。バックグラウンドタスク完了イベントをサイレントプッシュ送信にマッピングして、パイプラインが機能していることを確認してください。

個別送信ではなく、ジャーニー自動化に統合する

単独で送信されたサイレントプッシュは技術的な操作です。カスタマージャーニーに組み込まれたサイレントプッシュは戦略的な操作です。最も有用なパターンは、下流でより良い視覚的インタラクションを可能にするステップとしてサイレントプッシュを使用します。プロモーションプッシュの前にセグメントを更新し、アプリ内メッセージの前にコンテンツをプリフェッチし、位置情報ベースのアラートの前にジオフェンスを評価します。

PushwooshのカスタマージャーニービルダーBlueは、視覚的な通知やアプリ内メッセージと並んで、ジャーニーステップとしてサイレントプッシュをサポートしています。

Pushwooshでアプリの鮮度とキャンペーンの精度を向上させる

サイレントプッシュ通知は、より良いユーザー体験の基盤となるインフラ層です。オープン時の新鮮なコンテンツ、正確なセグメントデータ、シームレスなジオフェンストリガーのインタラクション――これらのいずれも、バックグラウンドアプリの更新なしには確実に機能しません。

Pushwooshはクロスプラットフォームのサイレントプッシュ配信、ペイロード形式、トークン管理、カスタマージャーニー統合を処理します。開発者はクリーンなSDK抽象化を得られます。マーケティングチームは自動化ワークフローのファーストクラスのステップとしてサイレントプッシュを利用できます。