OneSignalからPushwooshへの移行完全ガイド

OneSignalが無料プランに厳格な上限を設けます。近日中に、月間アクティブユーザー（MAU）が1,000人を超えると、モバイルプッシュ通知とアプリ内メッセージは無料ではなくなります。新規アカウントは2026年9月1日から、既存アカウントは10月1日からこの上限が適用されます。アプリの月間アクティブユーザーが1,000人を超えている場合、選択肢は3つです。そのまま料金を払い続けるか、対象ユーザー数を絞るか、他のプラットフォームへ移行するかです。

何がいつ変わるのか

Source: OneSignal

• 無料プランは1,000 MAU未満であれば引き続き利用できます。それを超えると、モバイルプッシュとアプリ内メッセージは有料ティアへ移行します。
• 適用時期: OneSignalの課金FAQによると、新規アカウントは2026年9月1日、既存アカウントは2026年10月1日からこの上限が適用されます。
• しきい値: モバイルプッシュとアプリ内メッセージで1,000 MAU未満であれば影響はありません。超えると、アップグレードするまでこれらのチャネルは配信を停止します。
• 変わらない部分: Webプッシュ、メール、SMSは従来と同じプラン上限のまま利用できます。今回の変更はモバイルのみが対象です。
• ジャーニーにも影響します: プッシュ通知やアプリ内メッセージを送信するジャーニーのステップは、モバイルの購読を単純にスキップするようになります。
• 購読者の削除は解決策になりません。 過去30日以内にアクティブだったモバイルの購読を削除しても、プランが再び有効になるのは削除から30日後で、しかもその期間ずっと上限を下回っている場合に限られます。

移行はどのように進むか

移行を決めた場合、計画の立て方が変わる重要なポイントがあります。移行作業そのものはPushwooshが代行します。お客様側で必要な作業は3つだけです。エクスポートファイル、プッシュ用の認証情報、そして次回のアプリリリースでのSDK差し替えです。それ以外の作業（データのクリーニング、プラットフォームのマッピング、タグの再構築、オーディエンスのインポート、配信可否の検証）はすべてPushwoosh側で行います。

切り替えは2つのトラックが同時に進みます。1回限りのインポートで既存のオーディエンス基盤を移行するため、1人もアプリを更新していない初日から配信可能な状態を維持できます。その後、各デバイスの所有者が新しいビルドをインストールするタイミングで、SDKがそのデバイスを引き継ぎます。両方が必要で、どちらも互いをブロックしません。

1. 移行できるもの・できないもの

この棚卸しをお客様自身で行う必要はありません。移行の途中で驚くことがないよう、全体像を先にお伝えします。

所要時間

SDKの差し替えとクリーンなテスト送信は、開発者1人であれば1日の作業です。インポートはPushwoosh側で並行して進み、これが初日からリーチを維持する仕組みです。インポートされたデバイスは、誰もアプリを更新する前から配信可能になります。その後、お客様のアプリのオーディエンスは、ユーザーが新しいビルドをインストールするペースでPushwoosh SDKへと移行していきますが、これには数週間かかり、最後の1台まで届くことはありません。だからこそインポートが必要なのです。

この順序が重要です。

1. オーディエンスをエクスポートする。 OneSignalのapp_idとApp APIキーを送っていただければPushwoosh側でエクスポートを取得します。もしくはCSVをご自身でエクスポートしていただくことも可能です。詳細は後述します。
2. プッシュ用の認証情報を送る。 OneSignalが現在送信に使用しているのと同じ鍵です。インポート前にアップロードすることで、インポートされたすべてのデバイスが配信可能な状態になります。
3. SDKを差し替える。 OneSignal SDKを削除し、Pushwoosh SDKを追加して、Pushwooshのアプリケーションコードとデバイス用APIトークンで初期化します。プラットフォームごとの手順はバージョンA〜Cに記載しています。
4. 配信を確認する。 本番トラフィックに手を付ける前に、テストデバイスを登録し、自分宛てにプッシュを送信してみてください。
5. タグシートを承認する。 エクスポートデータをもとにPushwoosh側で作成します。お客様は不要なタグに線を引き、複数値を持つタグに印を付けるだけです。セグメントについてはPushwoosh側でインポート・再構築します。
6. 送信を切り替える。 テスト配信に問題がなく、インポートも確認できたら、キャンペーンの送信先をPushwooshに切り替え、OneSignalからの送信を停止します。

2. オーディエンスをエクスポートする

方法A（推奨）：Pushwooshが代行します。 OneSignalのapp_idとApp APIキーを送っていただければ、Pushwoosh側でエクスポートを取得します。お客様側の作業はここで完了です。

方法B：ご自身で行う。 OneSignalの管理画面でAudience > Subscriptionsに進み、CSVをエクスポートするか、以下のエクスポート用エンドポイントを呼び出します。

curl -X POST 'https://api.onesignal.com/players/csv_export?app_id=YOUR_APP_ID' \
  -H 'Authorization: Key YOUR_APP_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"extra_fields":["external_user_id","timezone_id","notification_types"]}'

レスポンスにはcsv_file_urlが返され、gzip圧縮されたCSVは3日間ダウンロード可能な状態が保たれます。

Source: OneSignal

以下のカラムはファイルに必須です。それ以外は任意で、あっても無視されます。

注: external_user_idとtimezone_idはデフォルトのエクスポートには含まれません。上記のextra_fieldsパラメータで明示的にリクエストするか、ダッシュボードのカラム選択機能から指定してください。

3. プッシュ用の認証情報を送る

これらはOneSignalが現在お客様に代わって送信するために使用しているのと同じ認証情報のため、新たに何かを作成する必要はありません。Pushwoosh側でOneSignalから取得することはできません。一度アップロードされた鍵は二度とダウンロードできないため、この作業はお客様側で行っていただく必要があります。

認証情報は、インポート開始前にお客様のPushwooshアプリケーションへアップロードします。この順序は重要です。認証情報のないままインポートすると、配信できないデバイスだけが並んだデータベースができあがってしまいます。

4. タグとセグメントを確認する

Source: OneSignal

タグは移行対象で、棚卸しをお客様自身で行う必要はありません。 OneSignalではタグは型を持たない単純なキー/バリューの文字列です。Pushwooshでは各タグはアプリケーションごとに1度、型（String、Integer、Boolean、Date、List、Price）を宣言してから値を持つ仕組みになっています。

エクスポートデータを受け取り次第、そのファイルから作成したタグレビューシートをお送りします。見つかったすべてのタグが一覧化されており、サンプル値、値を持つデバイス数、Pushwoosh側で提案する型があらかじめ記入されています。お客様に確認していただくのは2つの列だけです。使わなくなったタグに線を引くことと、複数値を持ちうるタグに印を付けることです。それ以外は提案どおり承認していただいて構いません。

推測ではなく確認をお願いする理由は、タグの型は作成後に固定されるためです。複数値を持つタグをStringとして作成してしまうと、削除して再インポートする必要が生じます。エクスポートデータ上では単一値に見えるタグこそ、データだけからは判別できないケースです。ご回答がない場合は、推測した型ですべてのタグをインポートし、どのタグを推測で処理したかをお伝えします。

セグメントは再構築します。 OneSignalのAPIはエクスポートをセグメントでフィルターしたり、セグメント名を一覧表示したりできますが、その背後にあるフィルター条件は返しません。そのためインポートできるものがなく、2つの進め方があります。

1. 条件を再構築する（推奨）。 フィルター条件付きのセグメント一覧を送ってください。スクリーンショットで構いません。インポート済みのタグをもとに再構築します。再構築したセグメントは動的で、オーディエンスの変化に応じて更新され続けます。
2. メンバーシップを固定する。 セグメントごとに1回エクスポートを取得し、各ファイルにos_segment = vip_usersのようなマーカータグを付与します。作業は速いですが、結果は自動更新されないスナップショットになります。

OneSignal独自の行動データ（セッション数、プレイ時間、「Active Users」「Engaged Users」など）に基づくセグメントは、その履歴がOneSignal側に残るため、インポート時点では再現できません。Pushwoosh版の同等セグメントは、SDKがアプリに組み込まれた時点からデータが蓄積され始めます。

5. Pushwoosh側で行うこと

1. Pushwooshアプリケーションを作成・設定し、手順3で受け取った認証情報をアップロードします。
2. エクスポートデータをクリーニングします。配信解除済みの行とトークンが空の行を除外し、OneSignalのプラットフォームコードをPushwoosh側にマッピングし、タグを変換し、external_user_idをPushwoosh側のUser IDにマッピングします。
3. タグスキーマを作成し、オーディエンスをバッチ単位でインポートしながら、各バッチを検証します。
4. 小規模なコントロールグループにテストプッシュを送信し、想定どおりの結果になっているか確認します。
5. ファイルに含まれていた購読数、インポートできた数、スキップした行それぞれの理由をご報告します。

6. 次回のアプリリリースでPushwoosh SDKを組み込む

インポートによって既存のオーディエンスへすぐに配信できるようになりますが、これはあくまで橋渡しであり、最終形ではありません。OSがトークンをローテーションした際（再インストール、復元、OSアップグレード）に新しいトークンを取得したり、移行後にインストールしたユーザーを登録したり、開封・アプリ内メッセージ・アンインストールを計測したりできるのは、アプリ内に組み込まれたPushwoosh SDKだけです。

同じリリースでOneSignal SDKを削除してください。1つのビルドに2つのプッシュSDKが入っていると、同じ通知コールバックを取り合うことになり、この組み合わせはPushwooshとしてテストしていません。新しいビルドが展開されている間、OneSignal側で送信し続けるのは問題なく、想定どおりの状態です。しかし2つのSDKを1つのビルドの中に同居させるのは避けてください。プラットフォームごとの手順は以下のバージョンA〜Cに記載しています。

7. Webプッシュ：購読者はどう戻ってくるのか

Webプッシュはインポートできません。これはPushwooshの方針ではなく、技術的な制約です。Webプッシュの購読は、それを作成した側のVAPID鍵ペアで署名されており、OneSignalの秘密鍵はOneSignalの外に出ることはありません。OneSignal自身のドキュメントでも、Web購読の鍵はOneSignalのSDKのみが利用できるものと明記されています。どのプロバイダーであっても、他社のWeb購読情報をインポートすることはできません。代わりに機能するのが、サイレント再購読です。

1. OneSignalのスニペットを削除し、そのService Workerを明示的に登録解除します。古いWorkerを残したままにすると、同一ドメイン上で2つのWorkerが競合します。
2. Pushwoosh Web Push SDKを導入し、Service Workerをドメインのルートに配置します。
3. アプリケーションコードとデバイス用APIトークン（apiToken）を使って初期化し、自動購読を有効にします（autoSubscribe: true、またはPushwoosh.subscribe()を呼び出します）。トークンがないと、SDKの呼び出しは401で返ってきます。

その後、再訪問したユーザーはサイレントに再購読されます。ブラウザが保持する通知許可は以前のプロバイダーではなくお客様のドメインに紐づいているため、2度目の許可プロンプトは表示されず、ユーザーは何も気づきません。ベースの回復速度は、ユーザーがどれだけ早く戻ってくるかに左右されます。多くの場合、オーディエンスの大部分は1週間以内に戻り、残りは翌月にかけて回復していきます。

注意すべき3つのケースがあります。

• 通知をブロックしたユーザーは再購読できません。ブラウザが拒否し、再度プロンプトを表示することもありません。こうしたユーザーが対象外のままなのは正しい結果です。
• サイト上で配信を停止したものの、ブラウザの許可自体は残ったままのユーザーは、サイレントに再購読されてしまいます。技術的には正しい動作ですが、意図的に離脱したユーザーを呼び戻すことになります。抑制リスト（お客様独自のユーザーIDやメールアドレスによるもの）があれば送っていただければ、すべてのキャンペーンからそれらのユーザーを除外します。ない場合は、自動購読ではなく、ベルアイコンやプロンプトなど明示的なクリックによる購読をおすすめします。
• 以前のベンダーが提供するサブドメイン上でWebプッシュを運用していた場合、許可はそのサブドメインに紐づいています。こうした購読者は回復できず、サイト上で改めてオプトインしてもらう必要があります。切り替えを計画する前に、自社がどちらの構成かを確認してください。

8. インポート後に想定されること

• 一時的に1台のデバイスが2件表示されることがあります。 インポートされたレコードはOneSignalの識別子を持ちますが、同じデバイスでPushwooshのSDKが動作すると、独自の識別子で登録されます。古いレコードはアンインストール検知、または90日間の非アクティブによる自動クリーンアップで削除されます。その間、external_user_idを指定しておけば、両方のレコードを1つのユーザープロフィールにまとめられます。
• 無効なトークンは最初のキャンペーンで除去されます。 AppleとGoogleはメッセージを実際に送信して初めてトークンが無効かどうかを教えてくれるため、移行後の最初の送信がベースのクリーニングも兼ねることになります。
• インポート件数はOneSignal上の件数より少なくなります。 配信解除済みの行、トークンが空の行、Webプッシュの行は仕様として除外されます。それぞれ何件が該当したかは、Pushwooshからのレポートで正確にお伝えします。

9. 操作場所の一覧

お客様側で必要な作業の正確な操作パスです。ダッシュボードをあちこち探し回らずに済むようにまとめました。

10月1日までのチェックリスト

作業を進める際にこのリストを開いたままにしておいてください。ダウンロードが必要なフォームはありません。

バージョンA：ネイティブiOSとAndroid

iOS。 Pushwoosh iOS SDKを追加し、Info.plistに2つのキーを設定します。PushwooshのアプリケーションコードをPushwoosh_APPIDに、デバイス用APIトークンをPW_API_TOKENに設定します。現在OneSignalのプロンプトを表示している箇所でregisterForPushNotifications()を呼び出し、SDKバージョンに応じた正確な初期化コードはiOSクイックスタートを参照してください。両方のSDKがトークンをリクエストしないよう、OneSignal SDKとその登録呼び出しは削除してください。

Android。 com.pushwoosh:pushwoosh-firebase依存関係を追加し、AndroidManifest.xmlの<application>タグ内に2つのmeta-dataエントリを追加します。アプリケーションコードをcom.pushwoosh.appidに、デバイス用APIトークンをcom.pushwoosh.apitokenに設定します。初期化ロジックからPushwoosh.getInstance().registerForPushNotifications()を呼び出します。Firebaseの設定はそのままで、google-services.jsonもプロジェクトに残します。FCMの認証情報はControl PanelのAndroidプラットフォーム設定に登録します。

OneSignalの同等の呼び出しを行っていた箇所と同じタイミングで、setTags()でタグを、setUserId()でユーザー識別子を設定してください。これにより、差し替え後もセグメンテーションが機能し続けます。

バージョンB：FlutterとFlutterFlow

FlutterFlowはPushwoosh Flutter SDKをラップしているため、移行作業の大半はコードではなく設定作業になります。

1. Pushwoosh Flutterパッケージをプロジェクトのカスタム依存関係として追加します。
2. カスタムアクション内で、アプリケーションコードを使ってSDKを初期化し、プッシュ通知を登録します。現行の初期化APIについてはFlutterクイックスタートを参照してください。
3. 他のFlutterアプリと同様にネイティブ側の認証情報を設定します。iOSではInfo.plistにPushwoosh_APPIDとPW_API_TOKEN、AndroidではAndroidManifest.xmlにcom.pushwoosh.appidとcom.pushwoosh.apitokenを設定します。
4. 両方のSDKが同時に登録しないよう、OneSignalの連携を削除します。
5. カスタムアクション内で、setTags()とsetUserId()を使ってタグとユーザーIDをマッピングします。

バージョンC：React Native

1. プラグインをインストールします。npm install pushwoosh-react-native-plugin --saveを実行し、iOSでは続けてpod installを実行します。
2. ルートコンポーネントで初期化と登録を行います。

import Pushwoosh from 'pushwoosh-react-native-plugin';

Pushwoosh.init({ pw_appid: "YOUR_APPLICATION_CODE" });
Pushwoosh.register();

3. デバイス用APIトークンはネイティブ側で追加します。iOSではInfo.plistにPW_API_TOKEN、AndroidではAndroidManifest.xmlのmeta-dataとしてcom.pushwoosh.apitokenを設定します。Androidではgoogle-services.jsonをそのままプロジェクトに残してください。FCMの認証情報自体はControl Panelで管理します。
4. OneSignalのReact Nativeパッケージとその初期化呼び出しを削除します。
5. プラグインのAPIにあるsetTags()とsetUserId()を使って、タグとユーザーIDを引き継ぎます。

よくある質問

ご不明な点があれば、いつでもPushwooshのオンボーディング担当までお問い合わせください。インポート後に数字のつじつまを合わせるよりも、事前にお答えする方がずっと良いと考えています。