プッシュが「配信成功」なのに顧客に通知が表示されない理由

診断の出発点

配信画面は完了を示しているのに、テスト端末には何も表示されません。開発側はサーバー応答が正常、運用側は顧客が未受信と報告します。最初に確認するのは件数ではなく、その画面の「成功」がどの段階までを意味するかです。

OneSignalのDeliveredはFCM・APNsなどの事業者がメッセージを受け付けたことを意味します。FCMのメッセージIDも配信要求の受付であり、端末表示の証拠ではありません。サーバーの成功と顧客の未受信報告は両立します。^[1][3]

原因を絞るには、要求受理→対象決定・キュー→事業者受付→端末受信→画面表示→閲覧・操作を分けます。前段の成功から後段を推測せず、最後に確認した証拠から次へ進みます。以下の診断順序と記録様式は、この原則を適用した運用設計案です。

成功を六段階に分けると担当者も変わります

最初はAPIの要求受理です。正しいプロジェクト・アプリか、応答本文にエラーがないか、追跡IDがあるかを確認します。次は対象決定とキューです。予約時刻前、対象なし、制限による除外なら、端末設定から調べる理由はありません。OneSignalはScheduled、Queued、No Recipientsなどを区別し、メッセージ設定に対象・予約・制限条件を表示します。^[1]

三段目の事業者受付ではFCM・APNsの応答とエラーを確認します。端末受信はSDK記録や対応する確認機能、画面表示は通知センター・ロック画面・バナーを個別に確認します。最後の閲覧・操作では通知クリックとアプリ起動を分けます。クリックせずバナーを読んだ人の理解までクリック指標で証明できません。^[1][2]

六段階は診断用の論理モデルです。すべてのサービスが六イベントを提供し、同じIDを使い、全メッセージの一貫した記録を残すという意味ではありません。AppleのPush Notifications ConsoleにはAPNs配信ログがありますが、表示や閲覧確認とは同一視しません。^[14]

各段階を確認済み／未確認／この環境では観測不能に分けます。成功・失敗だけに圧縮すると、計測のない区間を障害と誤認しやすくなります。

DeliveredとConfirmed receiptは異なる証拠です

これはOneSignalプッシュレポートの定義です。他製品の似た名前の指標を同じ意味で合算しません。^[1][2]

現行名称はConfirmed receiptで、Confirmed Deliveryとも呼ばれます。有料プランと端末のOneSignal SDKが必要で、APIだけで作ったSubscriptionは対象外です。iOSではNotification Service ExtensionとApp Group、mutable-content: 1が必要です。Safariはこの受信確認機能に対応しません。^[2]

確認がない場合、配信だけでなく確認を返す経路の準備も調べます。iOS拡張やApp Groupの誤設定で受信しても確認が戻らない場合があります。逆に受信確認があっても、アプリコードや表示方針により見えない場合があります。^[2]

症状ごとに最初の確認箇所を絞ります

「全員が受け取れない」にも範囲が必要です。内部テスト端末二台か、キャンペーン対象全員の確認かを区別します。以下は公式トラブルシューティングと後述のOS条件を結ぶ診断設計案です。最初の確認点は原因の確定ではなく調査順です。^[13]

特定端末では会員IDより受信アドレスから確認します

OneSignalのUserはユーザー、Subscriptionは端末・ブラウザーなどチャネルの受信単位です。一人に複数のSubscriptionがあり得ます。アカウントが存在しても手元の端末が対象だったとは限りません。対象Subscriptionと現在のインストールを合わせ、最終同期と購読状態を確認します。^[4]

FCM直接連携では、利用中の登録方式に従ってクライアント識別子、サーバー保存値、更新時刻を照合します。登録トークン方式も同じです。UNREGISTEREDなどの無効登録応答は処理しますが、INVALID_ARGUMENTだけで直ちにトークンを削除しません。 payload不正でも起きるため、先にpayloadを検証します。^[5]

会員・プロファイル・受信対象の対応には、OneSignalユーザー識別・イベント仕様キットを使えます。ここでは全体モデルの再設計ではなく、問題のメッセージがどのインストールを対象にしたかの確認に使います。

AndroidとiOSでは表示の確認順が異なります

Android：権限・チャネル・payload・アプリ状態を確認

Android 13（API 33）以降では例外を除く通知に実行時通知権限が必要です。新規インストールは許可前には通知が既定で無効です。更新済みアプリも同じ状態だと考えず、実際の権限を確認します。^[6]

Android 8.0（API 26）以降の通知チャネルを使うアプリでは、アプリ全体の許可と個別チャネル設定を分けます。target SDK 26以上でチャネルなしの通知は表示されません。既存チャネルも利用者が無効化・重要度変更している可能性があるため、送信指定と端末側を照合します。^[7]

次はメッセージ種別です。FCMのnotificationは背景ではシステム通知領域、前景ではonMessageReceivedへ届きます。dataではアプリコードが重要です。両方を含む場合も背景では通知が表示され、開いた時にデータが渡る経路です。背景notificationでonMessageReceived記録がないだけでは未受信と判定できません。^[8]

iOS：APNs経路と表示方針を分けます

FCM経由でもiOSはAPNsを通ります。FCM成功だけでなくAPNs設定・エラー、端末権限、ロック画面・通知センター・バナー設定を確認します。Focusは通知を許すアプリと時点を制御します。Apple Watch併用時はどちらに表示されたかも確認します。^[9][10]

前景表示ではUNUserNotificationCenterDelegateとpresentation optionsを確認します。画面通知を期待しながら背景データ更新用プッシュだけを送っていないかも区別します。Appleの背景通知は確実な配信経路ではないため、画面通知の確実な代替として設計しません。^[9]

OneSignalでは前景リスナーや拡張コードが表示を抑止していないか確認します。他の受信ハンドラーとの関係を調べずにSDKやサービスを削除する修正は避けます。^[13]

ウェブプッシュにモバイルの点検表をそのまま適用しません。ブラウザー権限・購読に加え、OneSignal Service Workerの登録・動作、既存PWA Service Workerとの構成を確認します。受信確認の対応とウェブプッシュ自体の対応も別です。^[15]

遅延対策で最初に優先度やTTLを変えません

予約・配信制限・キューの待機と、事業者受付後の待機を分けます。FCMはオフライン中に保存し再接続後に届ける場合がありますが、TTLが切れると配信されません。同じ登録トークンとcollapse_keyの待機メッセージは新しいものに置き換わる場合もあります。全件が順番に蓄積・配信されるとは限りません。^[3]

Androidの通常優先度はDozeで遅延する場合があります。高優先度は即時配信を試みますが、すべてのプッシュの解決策ではありません。利用者に見える通知につながらない高優先度メッセージには降格などが適用される場合があります。配信優先度と通知チャネル重要度は別設定です。^[7][11]

TTLゼロは遅延解消そのものではありません。即時配信できなければ破棄するため、遅れても届くべき内容には不適切な場合があります。Android・ウェブのTTLとAPNs失効を同じ欄としてコピーせず、実経路の有効期間を記録します。^[3]

レポート遅延も区別します。FirebaseのReceivedはAndroid FCM SDK 18.0.1以降、ImpressionsはAndroidの背景notification表示が対象です。iOSの同等の表示確認とは扱いません。Analyticsなどの収集条件があり、集計は最大24時間遅れる場合があります。別の集計型FCM Data APIも全メッセージを漏れなく示す台帳ではありません。^[12]

リアルタイム再現は個別メッセージと端末の証拠、集計はOS・バージョン・期間別の傾向比較に使います。数字が直ちに増えないだけで同じ顧客へ再送しません。

再現記録には「届かない」より条件と観察を残します

所有または明示許可されたテストアプリ・端末と仮想ユーザーを固定します。全ユーザーセグメントや実顧客を試験対象にしません。生トークン・認証情報・個人情報は公開せず、必要な識別子は制限された内部記録だけで接続します。

最低限、アプリ・プロジェクト、メッセージ・対象ID、時刻・時間帯、OS・アプリ・SDK版、アプリ状態、権限・チャネル、payload、TTL・優先度、段階別観察を残します。プラットフォームIDとFCM・APNs IDは個別に保存し、同じ値だと考えません。これは前述の文書を結ぶ記録設計案です。

記入例：前景では見えず背景では見える

実配信・測定ではなく設計例です。 バージョン・時刻・各IDは記録方法を示し、特定SDKの新規採用を勧めるものではありません。

SDK 24.0.0のcompile SDK要件は公式リリースノートにあります。実記録には例の番号でなく、そのビルドで解決・組み込まれた正確な版を残します。^[16]

意図して変えた条件は前景・背景です。要求時刻とIDは各送信を識別するため異なります。この仮定の組合せはFCM notificationの処理経路で説明できます。Aは受信後の前景表示を調べ、Bはコールバックなしでもシステム表示があり得ます。^[8]

次の対応は認証キーの全再発行ではありません。前景表示が製品要件かを決め、必要なら実装した別ビルドで比較します。受信も表示も記録がなければ未確認として対象・受付・通信・失効へ戻ります。二回の試験を全ユーザーへの配信保証に拡張しません。

最後に確認した段階が次の対応を決めます

権限やチャネル設定一つで再現・解決するなら、新プラットフォームや別観測ツールの導入を先にする必要はありません。端末状態と既存ログで仮説を絞り、複数アプリ・SDK・事業者に設定と責任が分かれる場合に連携検討と運用支援範囲を決めます。

SDK連携とチャネル設定の支援範囲はIXCアプリプッシュ導入・オンボーディングにあります。

記録を「届かなかった」で終えず、どの対象へ送り、どこまで確認し、次に何を調べるかを残します。サーバー・アプリ・運用担当が同じ問題を調査できるようになります。