Amazon Pinpointが2026年10月30日にサービス終了:プッシュ通知とアプリ内メッセージの移行ガイド

自社アプリのプッシュ通知とアプリ内メッセージをAmazon Pinpointに依存している場合、猶予のない締め切りと厄介な移行作業が待っています。2026年10月30日、AWSはAmazon Pinpointのサポートを終了します。以降、コンソールおよびその中に構築したもの(エンドポイント、セグメント、キャンペーン、ジャーニー、分析ダッシュボード)には一切アクセスできなくなります。

Pinpointは2025年5月20日の時点ですでに新規登録の受付を停止しており、サービス終了は既定路線でした。AWSは公式の移行ガイドで全体のタイムラインを示しています。

サービス終了そのものは理解しやすい話です。難しいのは、AWSが次にどこへ誘導するかです。単一の後継製品は存在しません。Pinpointの用途によって、業務は4つの異なるAWSサービスへ分割されます。そして多くのモバイルチームが最も気にかけているプッシュ通知とアプリ内メッセージの2つに関しては、推奨される移行パスがそのまま引き継げる設計になっていません。

本記事では、何が終了するのか、AWSが各機能をどこへ振り分け、それがなぜ単純な置き換えにならないのか、そしてPushwooshへプッシュ通知とアプリ内メッセージの運用を移行する4ステップを解説します。実際の料金も示すので、移行の予算感がつかめます。

実際に終了するもの

メッセージングチャネルのAPI自体がなくなるわけではありません。消えるのは、マーケティングやプロダクトチームがログインして操作する「エンゲージメント層」です。

2026年10月30日以降、Pinpointのリソース(エンドポイント=保存されたユーザー・デバイス情報、セグメント=動的なオーディエンス、キャンペーン=スケジュール配信、ジャーニー=複数ステップの自動化ビルダー、そして配信・開封・ジャーニーのエンゲージメントを追跡していた分析ダッシュボード)へのアクセスが失われます。

名前を変えて生き残るのは、生のチャネル層です。SMS、音声、モバイルプッシュ、OTP、電話番号の検証は、AWS End User Messaging(2024年第3四半期にPinpointのチャネルAPIをAWSが改称したもの)で引き続き動作します。自社バックエンドがロジックを持ち、APIを呼び出してトランザクション通知やSMSを送るだけの使い方をしていたなら、影響は限定的です。API呼び出し先を切り替えれば済みます。

しかし、Pinpointの画面上でオーディエンス・キャンペーン・ジャーニーを組み立てていたチームにとっては、このワークフローそのものが失われます。AWS内で再構築するところから、本当の作業が始まります。

AWSの移行先はどこか、なぜ1対1の置き換えにならないのか

AWS自身の移行ガイドは、後継製品を1つ提示するのではなく、機能ごとに4つの製品を割り当てています。

• エンゲージメント(エンドポイント、セグメント、キャンペーン、ジャーニー) → Amazon Connectのアウトバウンドキャンペーン + Customer Profiles
• イベントとモバイル分析 → Amazon Kinesis
• メール → Amazon SES(Simple Email Service)
• SMS、プッシュ通知、音声、OTP → AWS End User Messaging

同じAWSというベンダー内ではありますが、実態は4つの別製品、4つの管理コンソール、4種類のドキュメントが、これまで1つのシステムで完結していた業務の代わりを務めることになります。専任のプラットフォームエンジニアリング組織を持たないチームにとって、これは「別ツールへの乗り換え」という言葉が通常想定するより、はるかに重い作業です。

モバイルチームにとって特に厄介なのは、そのエンゲージメントの移行先であるAmazon Connectに存在するギャップです。移行の途中で初めて気づくケースが少なくありません。

• アプリ内メッセージはConnectにまったく存在しません。 AWS自身の移行ドキュメントが、対応していない機能として明記しています。オンボーディング表示、機能訴求、ペイウォールなどをアプリ内メッセージで運用している場合、推奨パス上に受け皿がありません。
• プッシュ通知はネイティブなキャンペーンチャネルではありません。 GCM・APNS・Baiduなどのプッシュ通知は、Connectのキャンペーンでネイティブにはサポートされていません。AWSのガイドによれば、ジャーニー経由でLambdaアクションをConnectのプッシュテンプレートに接続すれば送信は可能とのことですが、実質的にはPinpointが標準機能として提供していたことを再現するために、自分たちでコードを書いて保守することになります。
• Custom Channelは片手落ちです。 ジャーニーでは使えますが、キャンペーンでは使えません。Connectが自力での補完を求めてくる、もう1つの継ぎ目です。
• テンプレートのエンジンは共通でも記法は異なります。 ConnectのテンプレートはPinpointと同じHandlebarsエンジンを使うため、ロジックの移植自体は可能です。ただし属性プレースホルダーの書き方が変わります。Pinpointで{{User.UserAttributes.PurchaseHistory}}と書いていたものは、Connectでは{{Attributes.Customer.Attributes.PurchaseHistory}}になります。すべてのテンプレートを1つずつ取り出して書き換える必要があります。
• エンドポイントの移行はスクリプト作業です。 ユーザーを移すには、AWSの手順に従ってフィルタなしのセグメントをS3へエクスポートし、Pythonスクリプトでそのエンドポイントを Customer Profiles の形式に変換します。1プロファイルあたりメールアドレスは3件、電話番号は4件までという上限もあります。動作はしますが、自分たちで書き、テストし、保守するコードであることに変わりありません。

これはAWSの移行パスが誤りだという話ではありません。すでにコンタクトセンター用途でConnectに全面移行しているなら、まさに正解かもしれません。しかし、そもそもPinpointを選んだ理由がプッシュ通知とアプリ内メッセージだったのなら、推奨される移行パスはこの2つのチャネルの再構築をエンジニアチームにそのまま委ねることになります。これは着手前に知っておくべきことで、3スプリント目に気づくことではありません。

Pushwooshへプッシュ通知とアプリ内メッセージを移行する4ステップ

Pushwooshはモバイルファーストのカスタマーエンゲージメントプラットフォームです。プッシュ通知、アプリ内メッセージ、Webプッシュを中核チャネルとし、メールとSMSをその周辺に備えます。4つのAWSサービスに業務を分割するのではなく、1か所でまとめて再構築します。移行の流れは次の通りです。

AWS側との違いは、地味な部分にこそ表れます。AWSの手順ではPythonスクリプトを書いてエンドポイントをCustomer Profilesに変換する必要がありますが、Pushwooshは画面またはAPIからユーザーをインポートするだけで、スクリプトの作成・保守は不要です。Connectではプッシュ通知をLambda経由のジャーニーで送る必要がありますが、Pushwooshではプッシュ通知は単に選択するチャネルの1つです。AWS側で見込んでいた開発工数の大半はここで消えます。

情シス審査を見据えた移行判断

日本のエンタープライズ導入では、意思決定者の合意だけでなく、情報システム部門やセキュリティ部門による審査を通すことが実質的な前提条件です。移行先を選ぶ段階でこの論点を先回りしておくと、後戻りが減ります。

プッシュ通知とアプリ内メッセージに加えてLINE公式アカウントとの併用導線も同じ基盤上で設計できるため、日本のユーザー接点をオムニチャネルでまとめて管理できる点も、Connectベースの構成にはない利点です。

費用はどれくらいかかるのか

移行に関する記事の多くは料金をぼかしがちですが、ここでは率直に示します。Pushwooshは月間アクティブユーザー数(MAU)課金で、詳細は料金ページにまとめています。プッシュ通知とアプリ内メッセージが中心のワークロードであれば、エントリー価格は意図的に低く設定されています。

• Push Only ── 1,000 MAUあたり7米ドル。 参考までに1ドル150円換算では、1,000 MAUあたり月額およそ1,050円です(為替レートは変動するため目安としてご参照ください)。プッシュ通知とアプリ内メッセージだけで完結するなら、オムニチャネルの余剰機能を持たないこのプランが最も適しています。
• Omnichannel ── 1,000 MAUあたり13米ドル。 メール、SMSなど他チャネルもまとめて1つの基盤で使いたい場合はこちらです。
• Custom ── 月額2,000米ドルから。 大規模配信向けのボリューム課金、専任サポート、エンタープライズ向けの契約条件です。

Pinpointのプッシュ通知とアプリ内メッセージの置き換えが主目的のチームにとって、この7ドルというエントリー価格は、フルスペックのマーケティングオートメーションスイートに全面移行するよりもはるかに小さな摩擦です。Braze、Customer.io、Iterableのような価格帯を選ぶかどうかは、まさにこのトレードオフにかかっています。

10月を待たずに動き出す

移行の中身自体は見通しの立つ作業です。エクスポート、接続先の切り替え、再構築、テスト。難しいのはカレンダーという制約のほうです。2026年10月30日は動かせない締め切りで、実際に時間のかかる工程(SDKの切り替え、イベントのマッピング、ドメインと送信元の設定)は、締め切りが近づいても短縮できません。

1,000 MAUまで無料の枠から、実際のデータで始められます。実データのセグメントをインポートし、ジャーニーを1つ再構築して、本格移行の前にパイロット配信で同等性を自分の目で確認するには十分な規模です。移行が遅れがちなケースを数多く見てきた立場からの助言としては、Pinpointのコンソールがまだエクスポートできるうちに、実際のMAUとスケジュールに照らして規模感を早めに把握しておくことをおすすめします。9月になってから着手するチームほど、電源が落ちる3週間前にギャップへ気づくことになります。