判断の出発点

CRM移行で最初に決めるのは「誰がいつから配信するか」です。同じ顧客が二つのツールに同時登録される期間も、同じ業務メッセージを送る責任は片側だけが持つ必要があります。

本稿では、顧客識別が正しく、受信可否の判断が保たれ、キャンペーンごとの配信責任と停止・復帰条件が確認された状態を切り替え完了の基準として提案します。取り込んだ行数が一致しただけでキャンペーンを有効にしません。移行するデータと実際に送れる対象を分け、小さな試験集団から責任を移します。

対象は営業パイプラインや相談記録全体ではなく、プッシュ・メール・SMSと自動キャンペーンを運用するCRM・メッセージング環境です。具体的な機能差は、既存アプリを維持してBrazeからOneSignalへ移る場合で説明します。特定製品の推奨や実際の顧客移行事例ではありません。製品文書は2026年9月26日時点で確認しました。

継続利用・アップグレード・移行の選択が残っているなら、OneSignal有料プラン移行ガイドの判断項目を先に検討します。ここでは移行を決めた後の技術的な切り替えを扱います。

移行対象を八つに分けます

OneSignalは顧客を表すUserと、チャネル接点を表すSubscriptionを区別します。一人の顧客に複数の端末・チャネルの購読が紐付きます。自社顧客IDのexternal_id、OneSignalが発行するユーザーID、個別のSubscription IDを同じ値として扱ってはいけません。OneSignal Users[1]・Subscriptions[2]。

次の表は移行作業を分けるための設計例です。「維持」は元の値や意味を保つことであり、元ファイルをそのまま投入すればよいという意味ではありません。

移行対象移行元で確認すること移行先での処理完了を判断する証拠
顧客識別内部顧客ID、Braze ID、匿名ID、端末との紐付け維持・変換。 内部顧客IDを基準に移行先IDとの対応表を作成別人が統合されず、一人の端末が意図どおりに紐付く
チャネル別購読・トークンアプリ・プラットフォーム・端末別トークン、メール、電話番号条件付き維持・再登録。 モバイルとWebの経路を分離アドレスやトークンの存在だけでなく、そのチャネルの配信準備を確認
権限・同意・受信拒否端末権限、チャネル状態、目的別同意・拒否と変更根拠意味を保存。 異なる状態を別フィールドで維持取り込みの既定値によって拒否・未確認が許可に変わらない
イベント・顧客属性イベント名、型、単位、タイムゾーン、最新変更時刻変換。 必要な属性と今後のイベント入力経路を再定義同じ業務事実を同じ意味で解釈し、過去イベントが新規配信を起こさない
セグメント条件式、除外条件、顧客・端末のどちらを評価するか再構築。 現在の名簿と今後適用する条件式を別々に検証同時点の対象集合と以後の参加・離脱条件を説明できる
キャンペーン規則メッセージ、日程、待機段階、再参加、頻度制限、終了条件再構築。 進行中の対象の継続方法を別途決定処理済み段階を繰り返さず、残る段階の担当ツールが決まる
履歴・成果データ提供される出力範囲、集計定義、保存条件可能な範囲で保存。 新ツールの実行状態へ直接移せると仮定しない元履歴の保存場所と限界、移行前後の指標を比較できる範囲を記録
運用権限・認証情報管理者、API権限、アプリ・送信者設定、予約処理再設定。 必要な権限だけを付与し、終了対象を区別担当者が配信・停止・調査でき、旧経路の無断配信が遮断される

識別基準には、ツールが変わっても維持できる内部顧客IDを推奨します。メールアドレスや電話番号が同じという理由だけで人を統合しません。匿名ユーザーを紐付ける根拠がなければ匿名のままにするか、配信を保留します。空のIDをすべて同じ代替値で埋める方法も避けます。

特に共有端末では、AがログアウトしてBがログインする状況を試験します。OneSignalのログイン処理で、購読に紐付くユーザーが変わる場合があるためです。「初回ログインで紐付いた」だけでなく、アカウント切り替え後の所有者と属性も確認します。OneSignal Users[1]。

サービスの仕組み

機能と受信同意を確認して切替え — 利用中のキャンペーンを新環境で検証し、購読者の移行と並行運用で切替え条件を確認します。

「受信可能」という一つのフィールドだけでは不十分です

OS・ブラウザー権限は、その端末で通知を許可する状態です。技術的なチャネル購読は、特定のトークン・アドレスでチャネルを利用できる状態です。マーケティング同意と受信拒否は、どの目的・チャネルのメッセージを受けるかという意思の記録です。移行設計ではこの三軸を統合しません。

Brazeでも、端末のプッシュ有効状態とユーザープロファイルのプッシュ購読状態は区別されます。プロファイルのSubscribedは既定状態で、Opted-InはOS通知権限を受け入れる流れで設定される場合があります。その値一つを目的別マーケティング同意の証拠として解釈してはいけません。Braze Push subscription states[3]。

メール・SMSの購読グループも個別に確認します。Brazeの購読グループ照会APIは状態変更履歴のあるグループを返すため、応答にグループがないことを受信許可と読み替えません。また、OneSignalのプッシュ購読解除は全チャネルの解除と同じ動作ではありません。Braze購読グループ照会[4]・OneSignal Subscriptions[2]。

推奨する設計は、顧客ID・チャネル・目的ごとに、状態、変更時刻、出所、バージョンを残す基準記録を設けることです。両ツールの値が衝突する、根拠が欠ける場合は自動配信を保留します。検証可能な後日の再同意は別途反映できますが、CSVの再投入やSDK初期化を再同意とは扱いません。これは状態を維持する技術設計であり、個々のメッセージの法的な配信要件を確定する基準ではありません。

例えば、昨日の出力ファイルでは「許可」でも、今日ユーザーが拒否した状況を試験できます。設計例として、明日そのファイルを再投入し、アプリが新しい購読を登録しても、今日の拒否が配信遮断に残る必要があります。削除済み顧客が古いファイルから復活することも同様に防ぎます。

同意記録を無条件に永久保存するという意味ではありません。必要最小限の情報、アクセス権限、保存・削除方針を先に決め、その範囲で移行中の状態逆転を防ぎます。

トークンを移せる条件はチャネルごとに異なります

モバイルではアプリと配信資格を併せて確認します

AppleのAPNsトークンは端末とアプリの組み合わせに対応します。別アプリのトークンとして再利用できません。アプリ識別、開発・本番環境、APNs認証設定の一致を確認します。Firebaseも、認証済み送信者とトークンの送信者条件が一致しなければSENDER_ID_MISMATCHを返します。トークン文字列のコピーだけで配信経路が継続すると判断できない理由です。Apple APNs登録[5]・APNs接続条件（Appleアーカイブ）[6]・FCMエラーコード[7]。

OneSignalへの取り込みにも差があります。条件が合う有効なiOS購読はSDK有効化前でもプッシュを受けられますが、受信確認とクリック追跡には有効なSDKが必要です。Androidでは、端末でOneSignal SDKが有効になって初めて通常の受信経路が成立します。iOSの生のAPNsトークンとFCM登録トークンも区別します。OneSignal移行ガイド[8]。

同じアプリのメッセージングツール交換と、アプリ識別・Firebaseプロジェクトの変更を一つの作業にまとめない方が適切です。条件が変わる集団は、トークン再収集やアプリ配布が必要な別の切り替え対象として分けます。

SDKの並行導入を既定の方針にしません

OneSignalは、一回のアプリリリースで既存SDKを交換する方法を優先して案内しています。やむを得ず二つを併存させるなら、トークンのライフサイクル管理と通知ハンドラーの衝突を防ぎます。端末内のトークン管理責任とサーバー側のキャンペーン配信責任は別々に決めます。OneSignal移行ガイド[8]。

アプリバージョンで新旧対象を分けても、実際の配信対象が境界を守るか確認します。ユーザー単位のジャーニーに複数端末が紐付いているなら、一台の更新だけで顧客全体の配信責任を移してよいか、別途判断が必要です。

Webでは権限の維持と購読の移行を区別します

OneSignalは既存Webプッシュ購読の直接取り込みに対応していません。同じHTTPS originで通知権限が許可されている場合、ユーザーの再訪時に新しい購読を登録する経路を案内しています。再訪していないユーザーを移行完了として数えてはいけません。OneSignal移行ガイド[8]。

Webプッシュではorigin、購読endpointとキー、Service Workerの配置を併せて確認します。既存のプッシュ用ワーカーを交換するとき、PWAキャッシュやオフライン機能も担うワーカーを無条件ですべて解除しません。originが変わる場合、既存権限が引き継がれると仮定せず、新環境の権限・購読手順を検討します。W3C Push API Working Draft[9]。

メールとSMSも、受信アドレスの移行と送信環境の準備を分けます。CSVでメール・電話番号と関連状態を対応付けても、メール送信ドメイン設定やSMS送信者の切り替えまで完了したことにはなりません。その範囲を確認できていなければ、当該チャネルは未開通として扱います。OneSignal Import[10]・Email setup[11]・SMS setup[12]。

エクスポートファイルは現在の状態の一部かもしれません

Brazeのユーザー出力APIは識別子、購読状態、プッシュトークン、属性を提供しますが、プロファイルのcustom_events・purchasesは直近90日の要約情報です。完全な生イベントログや進行中Canvasの実行位置として扱いません。保存できるものと再構築が必要なものを先に分けます。Brazeユーザー出力[13]。

移行先では、モバイル購読をCreate user APIモデルに変換し、CSVは文書が対応する識別子・アドレス・属性・状態に合わせて使用します。特に購読状態を変えるCSV処理には、該当購読を識別するメール・電話番号・Subscription IDなどが必要です。external_idだけで全チャネルの状態を変更できると仮定しません。Create user[14]・Import[10]。

後でOneSignalから再出力したり切り替え結果を検査したりする場合にも注意点があります。購読CSVをセグメントに限定すると、既定では受信中の購読だけが含まれます。拒否状態も確認するにはinclude_unsubscribed=trueを確認します。このオプションはセグメント指定のない要求では効果がありません。出力のidはSubscription IDなので顧客IDとも区別します。Export subscriptions CSV[15]。

推奨する方法は、基準時点の全状態と、その後の変更を別々に管理することです。初回出力後の受信拒否、削除、アカウント紐付け変更、新規購読を最終切り替えまで反映します。APIが「最近活動したユーザー」を選べても、全状態変更を漏れなく捕捉するとは限りません。OneSignalのlast_active_sinceも活動時刻のフィルターであり、完全な変更履歴の出力を約束するものではありません。Export subscriptions CSV[15]。

変更分を確実に確保できなければ、無理なリアルタイム並行運用より、制御可能な変更凍結期間と最終照合を設計する方が適切です。ただし、受信拒否の受付自体を止めてはいけません。受けた変更を基準記録に残し、両側の配信遮断に反映する経路が必要です。

切り替え手順では開始条件と停止条件を同時に決めます

以下は特定製品の自動機能ではなく、複数の公式文書の制約を反映した切り替え手順（Runbook）の設計例です。実際のコホート規模と観察期間は、キャンペーン待機時間、アプリ更新の分布、メッセージ有効期間に合わせて決めます。

段階開始条件完了基準と担当即時停止条件
1. 試験コホートID・状態対応、アプリ・送信資格、試験アカウントと端末が準備済み。新しい自動キャンペーンは無効開発担当がログイン切り替え・端末別購読を確認し、CRM担当が許可・拒否・保留結果とメッセージ動作を確認別顧客への紐付け、拒否から許可への変化、想定外の自動配信
2. 対応・整合性照合基準時点と元データの抽出範囲を記録。変更分取得または最終再照合の経路を確保データ担当が対象別結果と欠落理由を分類。拒否・削除変更が配信遮断に反映された時点まで確認説明できない欠落・統合、古い状態の上書き、許容範囲を超える反映遅延
3. キャンペーン配信権の移転元側の新規参加・予約・待機対象の処理方針、単一の配信責任、停止権限を確保切り替え責任者が元側遮断と先側許可の順序を承認。同じ業務メッセージを両側が送れる状態がないことを確認同じ配信を両ツールが所有、処理結果不明の旧要求を新ツールが再送しようとする
4. 対象拡大前段階を通過し復帰条件を維持。旧バージョン・未訪問・未確認を別集団で管理開発・CRM担当が集団別の受信経路、拒否反映、段階・頻度・指標を確認して次を承認新集団で識別・拒否・所有権問題を発見、合意した失敗・遅延基準を超過
5. 元システム終了残る顧客・端末・待機メッセージの処理を決定。必要履歴を保存し復帰可能期間の終了を承認運用責任者が予約・連携・アカウントを整理し未使用権限を回収。契約終了は別担当が確認旧バージョン利用者や未処理キャンペーンが担当不在で残る、共有認証情報への影響が不明

「両側の顧客数が近い」ではなく、集合が一致するかを照合します。同じ基準で正規化した配信単位について、元側と先側の担当が重なるか、どちらにも属さない対象があるか確認します。複数端末すべてへの配信を意図するキャンペーンなら、端末別配信を最初から想定範囲に含めます。

数値による設計例。 顧客ごとに同じキャンペーン段階のプッシュを一回送る候補が1,000件あるとします。拒否80件を除外し、SDK未準備100件と識別未確認20件を保留すると、配信可能集合は800件です。

全候補1,000 = 拒否による除外80 + 保留120 + 配信可能800

元側担当500 + 先側担当310 - 両側重複10 = 異なる配信単位800

800件すべてを含んでも重複10件があれば合格ではありません。その10件の移行先配信権を外すと、元側500件、先側300件、重複0件になります。これは実際の移行成果ではなく、検算できる集合照合の例です。実際の判定では合計だけでなく、配信単位ごとの識別子を比較します。

サービスの仕組み

キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。

進行中のキャンペーンを「再び有効化する」だけで引き継ぎません

セグメントと自動ジャーニーは顧客名簿のコピーだけでは継続しません。OneSignalのセグメントには購読単位・ユーザー単位の評価があり、ユーザー単位の条件はそのユーザーの複数購読を対象にできます。そのため、アプリバージョンで端末を分けても、両側でユーザー単位のジャーニーを動かすと意図した境界を越える場合があります。OneSignal Segments[16]。

移行計画では、顧客・キャンペーン・チャネル・段階ごとに、配信を所有するツールを一つに固定する記録を設けます。どの購入や登録から生じたメッセージかを識別する業務イベントID、キャンペーン版、段階も記録します。顧客単位の頻度制限と端末単位の配信は別項目で管理します。

配信権の移転は、元側の新規配信を遮断 → 処理中・結果不明の要求を照合 → 最新受信状態を反映 → 配信権バージョンを更新 → 先側配信を許可の順で設計します。表の担当ツール名を変えるだけでは不十分です。自社配信サーバーの経路は送信直前に現在の配信権と処理記録を確認し、ツール内部で直接動く経路は予約・ジャーニー・権限設定で境界を適用します。同じ配信を両側が同時処理できる隙間が残るなら、移行先を有効化しません。

進行中ジャーニーの整理方法は二つあります。既存ジャーニーを最後まで処理する方式では、元側の新規参加を閉じ、残る対象・段階は元側が担当し、先側では除外します。移行先で残る段階を再構築する方式では、元側の予約・待機を整理した後、最終処理段階、次回予定時刻、頻度制限、有効期間を根拠に未処理部分だけを作ります。どちらが可能かは実際の出力・停止・照会機能で確認します。

分析用に過去イベントを保存する経路と、新キャンペーンを開始する経路も分けます。過去の購入履歴を新規購入イベントとして投入したり、過去のウェルカムキャンペーンを新環境で全員に再開したりしません。

OneSignalの再参加・終了設定も、コピーしただけで完了ではありません。Custom EventベースのJourneyは同じユーザーの複数インスタンスを許容する場合があり、参加・終了条件を同時に満たしても最初の段階が先に実行される場合があります。送ってはいけない対象は終了条件だけに頼らず、参加前の除外条件も確認します。Journey settings[17]。

サーバーの配信記録に重複防止キーがあっても、担当者が元ダッシュボードで直接配信したり、既定Journeyが迂回実行したりすれば機能しません。API、自動ジャーニー、予約配信、手動配信をすべて同じ責任境界に収める必要があります。 難しければ、両ツールを有効にしたままにするより、明示的な配信停止期間を設けます。

OneSignalの通知作成APIには再試行用のidempotency_keyがあり、通知要求キーは30日間保持されます。ただし、これは同じツール内の要求再処理を制御する機能です。Brazeで別途送ったメッセージまで防ぐ共通の重複防止機構ではありません。Idempotent API requests[18]。

元キャンペーンを止めても、配信サービスが既に受け付けて待機させている通知を消したとは断定できません。FCMは端末が未接続の間メッセージを保存し、有効期間内に配信できます。過去の要求の結果が不明なら、新ツールで直ちに再送するより、照会・期限切れ待ち・保留のどれにするかを決めます。FCMメッセージ寿命[19]。

Go/No-goは件数比較より先に適用します

推奨する停止基準は明確です。誤った顧客統合、拒否対象への配信許可、同一配信の二重所有のいずれかを発見したら、該当範囲の新規配信を両側で先に遮断し、拡大を止めます。理由を説明できない欠落や最新拒否の反映が不明な状態も、次段階へ進めません。ここで「0件」は検査の合格条件であり、移行中の無損失を保証する数値ではありません。

次に実際の受信経路とキャンペーン結果を確認します。OneSignalのDeliveredはAPNs・FCMへの引き渡し、Confirmedは対応条件下の端末受信を表します。受信確認には有料プラン・対応プラットフォーム・SDK設定が必要で、Safari Webプッシュなど非対応の場合もあります。値がないだけで未受信と判定しません。どちらも購入やメッセージ閲覧の完了と同じ意味ではありません。Confirmed receipt[20]。

失敗率・遅延・観察期間はアプリとキャンペーンごとに試験前に合意します。端末・アプリ版・チャネル・同意状態の異なる集団を混ぜた平均一つで判断しません。以前成功した試験コホートが、新しく拡大する集団まで検証するわけではありません。

復帰できる範囲は段階ごとに異なります。

現在の段階可能な対応戻せると仮定してはいけないもの
元側を維持しつつ出力・対応付け・無効キャンペーンを準備移行先作業を停止し、誤対応を修正して元側運用を維持誤った識別統合が別データへ伝播済みなら、単なるファイル再投入では解決しない
一部の配信責任を移行先に移転元経路が機能し、最新拒否・配信履歴が反映されている場合のみ限定的に責任を戻す送信済みメッセージ、結果不明の要求、端末に導入済みのアプリ版をサーバー設定だけで戻すこと
旧SDK・購読経路を削除、または権限・契約を終了新環境の配信を止め、修正版配布・再登録など前進する復旧経路を検討解除済みWeb購読、失った元側アクセス権、終了契約の即時復元

復帰時にも、新環境で発生した受信拒否と処理済み段階を失ってはいけません。古い元状態に戻し「まだ送っていない顧客」と再分類すると、復帰そのものが二重配信の原因になります。コード・設定・DBの復帰条件はロールバック可能なデプロイのガイドと併せて検討します。

残る対象まで説明できて初めて移行完了です

アプリが一つで、安定した顧客IDと少数キャンペーンを運用し、開発・CRM担当が共同検査できるなら、専用移行製品を最初に導入する必要はありません。必要な出力、明示的な対応付け、配信遮断、小規模検査で手順を構成できるか確認します。

複数アプリ・アカウントが混在し、共有端末の識別問題があり、長い待機ジャーニーと複数チャネルを同時に移すなら、データ担当・アプリ開発・CRM運用・権限管理者の共同作業が必要です。ファイル変換だけを委託し、キャンペーン責任者を空席にしてはいけません。

最後に残る旧バージョン利用者、Web未訪問者、同意未確認の対象を隠さず説明します。元側が継続担当する、明示的に保留する、移行範囲から除外するかを決め、責任者を残します。「すべて取り込んだ」より、「誰に何を送れ、誰が責任を持ち、まだ移せない対象をどう扱うか説明できる」方が、完了の判断に有用です。

既存のメッセージング環境からOneSignalへ移る際、移行範囲と維持するキャンペーンを外部と点検する必要があれば、IXCのCRM移行・切り替え支援範囲を確認できます。