OneSignalとBraze プッシュ二重送信防止とチャネル優先度の設計

モバイルアプリマーケティングにおいて、プッシュ通知は強力な武器ですが、一歩間違えるとユーザー離脱を招く諸刃の剣となります。特に、高度なCRM（顧客関係管理）を実現するためにBrazeを導入しながら、コスト最適化や特定用途でOneSignalを併用、あるいは移行を進めているフェーズでは、「同じ内容の通知が2通届く」という二重送信トラブルが頻発します。

本記事では、日本国内のエンタープライズ領域でも採用されるこれら2大ツールの仕様を深掘りし、システム構成レベルで二重送信を防ぎ、かつLINEやメールを含めたチャネル優先度を最適化するための実務的な設計指針を解説します。

OneSignalとBrazeの併用・移行で直面する「二重送信」の正体

なぜ二重送信が起きるのか。その根本的な原因は、「OS（iOS/Android）のデバイストークン管理の重複」にあります。

通常、アプリにBraze SDKとOneSignal SDKの両方が組み込まれている場合、それぞれのSDKが独立してApple Push Notification service (APNs) や Firebase Cloud Messaging (FCM) と通信し、デバイストークンを取得します。この結果、1つのデバイスに対して2つの「配信先ID」が発行され、それぞれの管理画面（ダッシュボード）からは「別の宛先」として認識されてしまいます。

• Braze側の視点： ユーザーA（Braze ID: xxx）に対して有効なトークンを保持。
• OneSignal側の視点： ユーザーA（OneSignal ID: yyy）に対して有効なトークンを保持。

この状態で、Brazeから「セール告知」を送り、OneSignalからも「セール告知」を送れば、OS側の通知センターには同じ内容が並びます。これは、単に「ツールを2つ入れているから」という単純な話ではなく、ユーザーの識別子（External ID）とトークンの紐付けを集中管理できていないことが本質的な課題です。

プッシュ通知二重送信を防止する3つの設計アプローチ

実務上、二重送信を確実に防ぐには以下の3つのいずれか、あるいは組み合わせによる制御が必要です。

1. SDKレベルでの初期化制御（フロントエンド実装）

アプリの起動時に、どちらか一方のSDKのみを有効化する方法です。例えば、ABテスト的にユーザーを切り分けたり、特定の属性（例：ヘビーユーザーはBraze、ライトユーザーはOneSignal）によって初期化するSDKを動的に変更します。

ただし、この方法は「過去に登録されたトークン」がプッシュサーバー側に残っている場合、サーバー側（管理画面側）からの配信を止めることはできません。あくまで「新しいトークンを発行させない」ための対症療法に留まります。

2. 外部ID（External ID）をキーにした配信除外リストの同期

最も現実的なのが、両ツールのExternal ID（外部ユーザーID）を共通化し、配信時に「もう一方のツールで配信済みか」をチェックする手法です。具体的には、Brazeの「Subscription Group」機能や、OneSignalの「Tags」機能を利用し、配信フラグをAPI経由で相互に書き換えます。

3. リバースETLを用いた配信フラグの集中管理

データウェアハウス（BigQueryやSnowflake）を真実のソース（Source of Truth）とし、そこから各ツールへ配信対象リストを流し込む構成です。例えば、BigQuery上で「昨日Brazeでプッシュを送ったユーザーには、今日はOneSignalから送らない」というクエリを叩き、その結果をOneSignalのTagに反映させます。

このアーキテクチャの詳細は、高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャの記事で解説しているLINE連携の考え方と共通しています。プッシュ通知も「データ基盤からの配信指示」として捉えるのが現代的な設計です。

チャネル優先度（Priority）の設計：LINE、メール、プッシュの最適解

二重送信防止の先にあるのが、「どのチャネルで送るのが最適か」という優先順位の設計です。メッセージの重要度とコスト、到達率を天秤にかける必要があります。

「最も安く、最も気づかれる」チャネルを優先するロジック

一般的な優先順位の設計例を以下に示します。

1. 第1優先：アプリプッシュ（コスト：極めて低い / 到達率：中 / 反応：速い）
2. 第2優先：LINE（コスト：従量課金 / 到達率：高 / 反応：非常に速い）
3. 第3優先：メール（コスト：低 / 到達率：中 / 反応：遅い）
4. 最終手段：SMS（コスト：高い / 到達率：極めて高 / 反応：非常に速い）

ここで重要なのは、「第1優先のアプリプッシュが届く（＝通知許可設定がON）なら、第2優先のLINEは送らない」というカスケード制御です。

LINE既読フックによるプッシュ通知の動的キャンセル

さらに高度な設計では、LINEでメッセージを送り、一定時間（例：15分）以内に既読にならない場合のみ、プッシュ通知を補完的に送る構成をとります。逆に、LINEで既に読まれているのにプッシュ通知が飛ぶのはユーザーにとってノイズでしかありません。

このリアルタイムな名寄せと制御については、WebトラッキングとID連携の実践ガイドで触れているID統合の仕組みが不可欠です。LINE IDとアプリのExternal IDが紐付いていなければ、この制御は不可能です。

【実務比較】OneSignal vs Braze：機能・コスト・責務分解

実務担当者が最も悩むのが「どっちをメインに据えるか」です。両ツールの特性を比較表にまとめました。

Brazeを「脳」にし、OneSignalを「手足」にする構成

予算が許すのであれば、Brazeを顧客体験のシナリオを設計する「脳」として使い、配信コストを抑えたい大量の「一斉お知らせ」系通知のみをOneSignalにオフロードする（手足として使う）切り分けが、エンタープライズ領域では賢い選択となります。

この際、BrazeのWebhook機能を使用してOneSignalのAPIを叩き、配信を実行させることで、Brazeのジャーニー機能（Canvas）の中でOneSignalからのプッシュ送信を管理できるようになります。

導入・設定のステップバイステップガイド

具体的に二重送信を防ぎながら設定を進める手順を解説します。

Step 1: ユーザー識別子（External ID）の完全一致

自社のデータベース（CRMや基幹システム）における「ユーザー主キー」を、両ツールのExternal ID（Brazeは changeUser('ID'), OneSignalは setExternalUserId('ID')）にセットします。これがズレていると、いかなる名寄せも不可能です。

Step 2: 配信除外属性（Attributes）の定義

OneSignal側のTagに opt_out_onesignal: true のようなフラグを用意します。Brazeで重要なパーソナライズ通知を送る際、Braze側のSDKまたはAPI経由で、OneSignal側のこのタグを true に書き換えます。

Step 3: Webhookを用いたリアルタイムステータス連携

Brazeの「Canvas」でメッセージを送る直前に、Webhookステップを挟みます。

OneSignal API（POST /notifications）を呼び出し、特定のユーザーをターゲットにします。この際、Braze側のログにも「OneSignal経由で送信」というイベントをカスタムイベントとして記録しておくことで、分析がBraze側に集約されます。

こうしたツール間の「責務分解」は、バックオフィス業務におけるSaaS連携の考え方と非常に似ています。詳細は受取SaaSと会計ソフトの正しい責務分解の記事が、アーキテクチャ設計の参考になります。

運用時によくあるエラーとトラブルシューティング

トークンの無効化（Expired Token）が同期されない

ユーザーがアプリをアンインストールした場合、OSから「このトークンは無効です」というレスポンスが返ります。Braze側で無効と判定されても、OneSignal側にはその情報が伝わりません。結果として、OneSignal側から「幽霊ユーザー」への無駄な配信試行が続き、エラー率の上昇やレートリミット（制限）に抵触する可能性があります。定期的に（月1回程度）、両ツールの無効トークンリストをエクスポートし、名寄せして一括削除するメンテナンスが必要です。

セグメント反映のタイムラグによる誤送信

特にリバースETL（BigQuery → OneSignal/Braze）を使用している場合、データの同期には15分〜1時間程度のラグが発生します。「さっきWebで購入した人に、アプリプッシュを送らない」という制御をしたい場合、このラグの間は二重送信のリスクが残ります。これを回避するには、データ基盤経由ではなく、アプリ内イベントから直接SDKの属性を書き換える「リアルタイムイベント連携」を優先してください。

まとめ：データ基盤を軸にした「静かなる」通知設計

OneSignalとBrazeの併用は、コストと機能のバランスを取るための有効な戦略ですが、その代償として複雑なID管理と二重送信リスクを背負うことになります。成功の鍵は、フロントエンドのSDK実装に頼りすぎず、サーバーサイドまたはデータ基盤（BigQuery等）側で「誰に・どのツールで・何を」送るかの決定権を一元化することです。

ユーザーにとって「自分に必要な情報が、最適な瞬間に1通だけ届く」という体験は、もはやおもてなしではなく、現代のアプリにおける最低限のマナーといえるでしょう。