OneSignalから移行するなら: 大規模アプリのプッシュSDKを安全に移行する9つのツール

小規模なアプリなら、OneSignal SDKの移行は初期化の呼び出し1つとクリックハンドラーを差し替えるだけで済みます。しかし大規模なアプリでは、OneSignalはあちこちに入り込んでいます。プロフィールモジュールで設定するタグ、認証まわりの外部ユーザーID、ナビゲーションのクリックハンドラー、チェックアウトのどこかにあるアプリ内メッセージのトリガー。

そのうち1つでも呼び出しを見落としても、アプリはクラッシュしません。セグメントが静かにずれ、ディープリンクはホーム画面を開き、ユーザーを呼び戻していたプッシュ通知が届かなくなります。

本記事では、OneSignalからの移行を安全に進めるための9つのツールを、移行の5ステップ別に紹介します。洗い出し、置き換え、テスト、リリース、監視の5つです。

プッシュ通知プラットフォーム側の手順については、OneSignalからPushwooshへの移行ガイドをご覧ください。

大規模アプリでプッシュSDKの移行が失敗する理由

プッシュSDKは、多くのサードパーティライブラリよりもコードベースの広い範囲に関わります。よくある失敗は次の4つです。

• 呼び出しの散在。 タグ、外部ユーザーID、クリックハンドラーは別々のモジュール、ときには別々のリポジトリにあります。「OneSignal」でテキスト検索しても、わかりやすい呼び出しは見つかりますが、ラッパーは見落とします。
• 隠れた依存関係。 分析イベント、ディープリンク、A/BテストはSDKのコールバックにぶら下がっていることがよくあります。コールバックを外すと、その先のダッシュボードが平らになります。
• 1つのビルドに2つのSDK。 1つのアプリに2つのプッシュSDKがあると、同じ通知コールバックを奪い合います。そのためPushwooshの移行ガイドでは、新しいSDKを追加するのと同じリリースでOneSignal SDKを削除するよう案内しています。
• 気づかれない失敗。 届かなかったプッシュ通知はエラーを出しません。クラッシュレポートもきれいなままです。

移行の手順をステップごとに

ステップごとに、固有の失敗パターンと、それに対応するツールがあります。

OneSignal SDKを安全に移行するための9つのツール

ステップ1. OneSignalの呼び出しをすべて洗い出す

1. CodeAlive: 大規模かつ複数リポジトリのコードベースでSDKの呼び出しを洗い出すのに最適

CodeAliveは、AIコーディングエージェントにコードベース全体の正確なコンテキストを提供し、エージェントがそれを探すために消費するトークンを削減します。100万行以上のコードベース向けに作られたコンテキストエンジンで、セマンティック検索に加えて、ファイル、シンボル、呼び出し、依存関係、テストの関係グラフを、MCPとAPIで提供します。

移行での役割: 誰かがコードを編集する前に、OneSignalがどこで使われ、何がそれに依存しているかをCodeAliveに尋ねます。関係グラフは、わかりやすい呼び出し以外も示します。ラッパー、分析がぶら下がっているコールバック、SDKをモックしているテストなどです。同じコンテキストが、置き換えを行うAIエージェントにも渡されます。

主な機能:

• ハイブリッド検索: セマンティック検索、字句マッチング、グラフ探索を1回のクエリで
• pushのたびにインデックスを更新するため、移行ブランチが進んでも洗い出し結果が最新のまま
• MCPツール（semantic_search、grep_search、chatなど）をCursor、Claude Code、Codex、Windsurf、Zed、Continue、Clineで利用可能
• システム全体を考慮したAIによるプルリクエストレビュー
• Gitプロバイダー: GitHub、GitLab、Bitbucket、Azure DevOps、Gitea。IDE: VS CodeとJetBrains

メリット:

ステップ2. SDKを置き換え、オーディエンスを移す

2. Pushwoosh: オーディエンスのインポートに対応した移行先プラットフォームとして最適

Pushwooshは、プッシュ通知、アプリ内メッセージ、メール、SMS、WhatsAppに対応したカスタマーエンゲージメントプラットフォームです。移行では、開発者が新しいSDKをリリースしている間に、Pushwooshのチームがオーディエンスをインポートします。SOC 2 Type IIとISO 27001:2022の認証を取得しているため、移行先の選定で情シス審査を通す際の説明材料にもなります。

移行での役割: iOS、Android、Huaweiのプッシュトークンはインポートされ、そのまま使えます。トークンはアプリとそのキーに紐づくものだからです。メールとSMSの購読者もインポートで移行します。external_user_idはPushwooshのUser IDに対応します（OneSignalのエクスポートではデフォルトで含まれないため、この列を指定して依頼してください）。タグはエクスポートデータから再作成されます。例外はWebプッシュです。ブラウザの購読はどのプロバイダーでも移行できないため、PushwooshのWeb SDKが訪問者をサイレントに再購読させます。

主な機能:

• iOSとAndroidのほか、React Native、Flutter、Unity、Capacitor、Cordova、MAUI、Expoなどに対応したSDK
• SDKのリリースと並行して進むオーディエンスのインポート。ユーザーがアプリを更新する前からデバイスに届く
• 送信前に実機でプッシュ通知をプレビューできるテストデバイス

メリット:

料金: Push onlyプランは1,000 MAUあたり$7で、最初の1,000 MAUは無料です。現在の請求額はOneSignalコスト計算ツールで比較できます。

ステップ3. 登録と配信をテストする

3. Apple Push Notifications Console: APNs経由のiOS配信テストに最適

Push Notifications Consoleは、APNs経由でテスト通知を送るためのAppleのWebツールです。iOSのプッシュ通知が届かないとき、原因がプロバイダー側かどうかをすばやく切り分けられます。iOSユーザーの比率が高い日本のアプリでは、特に最初に確認したいポイントです。

移行での役割: デバイストークンに直接プッシュ通知を送り、APNsが受け付けて配信したかを確認します。ここでは届くのに新しいプロバイダーからは届かない場合、まずプロバイダーの設定を確認しましょう。

主な機能:

• デバイスへのテスト通知。属性を変えて再送も可能
• 開発環境での、APNs内の通知の経路を示す配信ログ
• 特定の環境とプッシュタイプに対するトークンの検証
• テスト通知と本番通知の配信メトリクス

メリット:

4. Firebase Cloud Messaging: トークン指定でのAndroidのプッシュ通知テストに最適

Google Play開発者サービスが入ったデバイスでは、AndroidのプッシュはFirebase Cloud Messagingを経由します（GoogleサービスのないHuaweiデバイスでは、代わりにHMS Push Kitを使います）。Firebaseコンソールから1つの登録トークンにテストメッセージを送れるため、Androidビルド向けのシンプルなプッシュ通知テストツールとして使えます。

移行での役割: 新しいSDKがデバイスを登録したら、そのFCMトークンをコンソールに貼り付けてテストを送ります。届けば、トークンとFirebaseの設定は問題ありません。

主な機能:

• コンソールから特定のFCM登録トークンへテストメッセージを送信
• デバイスからトークンを読み取る以外、簡単な確認にコードは不要

メリット:

5. Proxyman: SDKの通信とペイロードの確認に最適

Proxymanは、macOS、Windows、Linuxで使えるHTTPデバッグプロキシです。プッシュSDKが実際に何を送っているか（登録の呼び出し、ユーザーIDの更新、タグのリクエスト）を確認できます。

移行での役割: 新しいSDKを入れたアプリを動かし、そのリクエストを観察します。タグがデバイスから送信されていなければ、セグメントが空になるずっと前にここで気づけます。

主な機能:

• 実機、シミュレーター、エミュレーター上のアプリからのHTTPS通信のキャプチャ
• 有料プランではiOSシミュレーターとAndroidエミュレーターをワンクリックでキャプチャ
• リクエストとレスポンスを編集できるブレークポイントとMap Local/Remote

ステップ4. 段階的にリリースする

6. fastlane: 段階的リリースの自動化に最適

fastlaneは、iOSとAndroidのデプロイを自動化するオープンソースのプラットフォームです。移行で役立つのは、リリース用のlaneにスクリプトとして組み込める2つのパラメーターです。

移行での役割: upload_to_app_storeはphased_release: trueを受け取り、アップデートを7日間かけてリリースします。upload_to_play_storeはrolloutの値を受け取ります。これはビルドを受け取るユーザーの割合で、0.1なら10%、1で公開完了です。移行のリリースが毎回同じ段階的な経路をたどるため、チェックボックスの付け忘れがなくなります。

主な機能:

• deliver / upload_to_app_storeのphased_release
• supply / upload_to_play_storeのrolloutとrelease_status（haltedを含む）
• 両ストアを1つのlaneで

メリット:

7. App Storeの段階的リリースとGoogle Playの段階的公開: 影響範囲を限定するのに最適

どちらのストアも、アップデートをまず一部のユーザーに届けることができます。どのリリースツールを使っていても、これがプッシュSDKを置き換える際のセーフティネットです。

移行での役割: Pushwooshを組み込んだ新しいビルドが、まず少数のユーザーに届きます。配信数やクラッシュ率がおかしければ、全員に届く前に公開を止められます。その間もOneSignalはアップデートしていないユーザーへの送信を続けるため、キャンペーンを受け取り損なうユーザーは出ません。

主な機能:

• App Store: 自動アップデートを有効にしているユーザーに対し、7日間かけて1%、2%、5%、10%、20%、50%、100%の順でリリースします。合計で最大30日間の一時停止や、任意のタイミングでの全員へのリリースも可能です
• Google Play: 割合を設定し、手動で引き上げます。公開の停止と再開ができ、すでにアップデートしたユーザーはそのビルドを使い続けます
• 両ストアとも、ユーザーはランダムに抽出されます

メリット:

ステップ5. クラッシュと配信を監視する

8. Firebase Crashlytics: 置き換え後のクラッシュの検知に最適

Firebase Crashlyticsは、Android、Apple、Flutter、Unityのアプリからクラッシュと非致命的エラーを報告します。公開期間を通じて動かし、新しいビルドと以前のビルドを比較しましょう。

移行での役割: 通知ハンドラーやSDKの初期化中のクラッシュは、まずここに表示されます。非致命的イベントは、より目立たない問題の発見に役立ちます。プッシュ通知の登録が失敗したときに非致命的イベントを記録すれば、ビルドごとに確認できます。

主な機能:

• issueにグループ化され、ビルドで絞り込めるクラッシュレポート
• デバイス上で記録され、次回のアプリ起動時に送信される非致命的イベント
• Android、Apple、Flutter、Unity向けの公式SDK

9. Pushwooshのメッセージ統計: 気づかれない配信数の低下を見つけるのに最適

クラッシュレポートは、プッシュ通知が届かなくなったことを教えてくれません。Pushwooshのプッシュ通知統計なら教えてくれます。

移行での役割: プッシュ通知ごとに、オーディエンスから送信、配信、開封までのファネルをプラットフォーム別に確認でき、エラーは別タブで確認できます。切り替え後の最初のキャンペーンを、移行前のOneSignalの数値と比較しましょう。iOSの配信数がAndroidより低ければ、コードの前に認証情報を確認してください。

大規模アプリのための5ステップの移行計画

コードに触れる前に、OneSignalの呼び出しをすべて棚卸しする

すべてのリポジトリにわたって、SDKの呼び出し、ラッパー、コールバック、テストをすべてリストアップします。このリストが、置き換えとコードレビューのチェックリストになります。

プッシュ通知を1つの社内インターフェースの裏にまとめる

ログイン、ログアウト、タグ、通知の処理など、すべてのプッシュ関連の呼び出しを1つの社内サービス経由にします。こうすれば移行で変更するのは50か所の呼び出し元ではなく1つの実装だけになり、次にプロバイダーを変えるときも楽になります。

protocol PushService {
    func login(userId: String)
    func setTags(_ tags: [String: Any])
    func handleNotificationOpen(_ payload: [AnyHashable: Any])
}

SDKは1回のリリースで入れ替える

同じビルドでPushwoosh SDKを追加し、OneSignal SDKを削除します。1つのアプリに2つのプッシュSDKがあると、通知コールバックを奪い合います。新しいビルドを公開している間は、旧バージョンのユーザーにはOneSignalからの送信を続けましょう。

段階的にリリースし、配信の指標を比較する

段階的リリースまたは段階的公開で、まず少数のユーザーから始めます。Crashlyticsでクラッシュを、Pushwooshの統計で配信を確認してから、公開範囲を広げます。

OneSignalからの送信は、配信を確認してから止める

OneSignalからの送信を止めるまでは、OneSignalからの送信を続けることがそのままロールバックになります。Pushwooshでの配信とオーディエンスのインポートの両方を確認できたら、OneSignalを停止しましょう。

よくある質問