LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

プッシュ通知実装とMAU改善——FCM・APNsが担う再エンゲージメントの仕組み

アプリのプッシュ通知実装とは、スマートフォンアプリがユーザーのホーム画面やロック画面にメッセージを届ける機能を、GoogleのFCM（Firebase Cloud Messaging）やAppleのAPNs（Apple Push Notification service）を通じて組み込む開発作業を指します。

プッシュ通知が再エンゲージメントを生む仕組み

スマートフォンアプリを一度インストールしたユーザーが、その後アプリを起動しなくなることは、MAU（Monthly Active Users、月間アクティブユーザー数）低下の主要な要因のひとつです。プッシュ通知は、アプリが閉じている状態でもユーザーに情報を届けられるため、離脱しかけているユーザーへの再接触手段として機能します。

ただし、通知を送ること自体が目的ではありません。ユーザーにとって価値ある内容・タイミング・頻度で届けられた場合にのみ、アプリへの復帰行動につながります。無関係な通知を頻繁に送ると、ユーザーが通知をオフにする原因になるため、設計の質がMAUへの波及効果を大きく左右します。

FCMとAPNsの役割——AndroidはGoogle、iOSはAppleが配送する

Androidアプリへのプッシュ通知は、GoogleのFCM（Firebase Cloud Messaging）を経由して配送されます。FCMは「信頼できるサーバー環境（アプリサーバーまたはCloud Functions）」と「Apple・Android・Webのクライアントアプリ」の2コンポーネントで成立する仕組みです^*1。

iOSアプリへのプッシュ通知は、AppleのAPNs（Apple Push Notification service）を通じて配信されます。APNsはAppleのサーバーを経由して各デバイスへ通知を届ける仕組みです。AndroidとiOSでは使用するプラットフォームが異なるため、両OS対応のアプリでは両方の実装が必要になります。

FCM・APNsの実装工程——外注前に知っておくべき技術要件

Android実装の要件——FCMとAndroid 6.0以上・Google Playストア前提

FCMによるAndroidプッシュ通知を実装するには、対象デバイスがAndroid 6.0（Marshmallow）以上であり、かつGoogle Playストアアプリがインストールされている必要があります^*3。この前提を満たさないデバイスでは通知が届きません。

実装の主な工程は次の通りです。まずFirebase SDKをAndroidプロジェクトに追加します。次にAndroidManifest.xmlに`FirebaseMessagingService`を継承したサービスを登録します。Android 13以上の端末では実行時に`POST_NOTIFICATIONS`権限をユーザーに求める必要があり、許可を得る前に通知の価値を説明するUI（教育的UI）を表示することがGoogleの公式ドキュメントで推奨されています^*3。

端末ごとの識別には「登録トークン」を使います。`FirebaseMessaging.getInstance.getToken`で取得したトークンをアプリサーバーに送信し、以後はそのトークン宛てに通知を送る設計です。トークンはデバイス再設定やアプリ再インストール時に更新されるため、`onNewToken`メソッドで変更を検知してサーバー側を更新する処理も合わせて実装します^*3。

iOS実装の要件——APNsへの登録・証明書とトークン認証

iOSアプリでプッシュ通知を受け取るには、アプリをAPNsに登録する手順が必要です。Apple Developerポータルでアプリケーションの識別子（App ID）を登録し、プッシュ通知機能を有効化します。その後、APNsとの通信に使う認証情報を生成します^*4。

認証方式には「証明書ベース」と「トークンベース（.p8キーファイル）」の2種類があります。Appleの現行ドキュメントではトークンベースの接続が推奨されており、1つの署名キーで複数のアプリに対応できる点が利点とされています^*5。XcodeでSigning & Capabilitiesの設定を行い、アプリ起動時に`UIApplication.shared.registerForRemoteNotifications`を呼び出してデバイストークンを取得する実装が基本的な流れです。

通知許可の取得にはUser Notificationsフレームワークを使用し、ユーザーに対して「アラート」「サウンド」「バッジ」の各権限を明示的に要求します^*2。ユーザーが一度「許可しない」を選ぶと、OS設定から手動で変更しない限り通知は届かなくなるため、許可を求めるタイミングと説明文の設計が重要です。

通知許可率を高めるオプトイン設計

プッシュ通知実装で見落としやすいのが、通知許可率の設計です。Androidはアプリインストール後に自動で通知が有効になる機能もありますが、Android 13以降はiOS同様に実行時の許可取得が必要になりました。iOSでは従来から許可ダイアログへの同意率がアプリの成否を左右するとされています。

許可率を高めるために有効とされているのが「プレ許可ダイアログ（ソフトオプトイン）」の設計です。OS標準の許可ダイアログを表示する前に、アプリ専用のUIで通知の価値（クーポン情報・在庫通知など）を説明し、ユーザーが「受け取る」を選んだ場合にだけOSダイアログを出す設計です。OSの許可ダイアログはユーザーが「許可しない」を押すと再表示できないため、この前置き設計はリスク低減につながります。

また、アプリのオンボーディング画面（初回起動直後）で通知を求めるより、アプリの価値をユーザーが理解した後のタイミングで許可を求めるほうが同意率が上がる傾向があります。どのタイミングで許可を求めるかは、外注先のUI/UX設計力が問われる部分です。

セグメント配信設計——MAU改善に直結する活用戦略

セグメント配信とパーソナライズの考え方

FCMはデバイスグループ・トピック登録・個別デバイスの3種類の宛先指定方法に対応しています^*1。全ユーザーに同じ内容を一斉配信するだけでなく、ユーザーの属性・行動履歴・利用状況に応じてメッセージ内容と宛先を切り分けるセグメント配信が、MAU改善につながる活用設計の中心です。

セグメントの軸は大きく3種類に分けて考えられます。第一は「最終起動日」で、30日以上起動していないユーザーを「休眠層」として再エンゲージメント通知の対象にします。第二は「アプリ内行動」で、購入完了・お気に入り登録などのイベントを起点に関連するキャンペーン情報を送ります。第三は「通知受信後の行動」で、開封したユーザーと無視し続けたユーザーを分けてフォローの内容を変えます。

パーソナライズの精度は、アプリサーバー側でどのユーザー属性をどのように管理しているかに依存します。実装段階でセグメント設計に必要なデータをどう取得・保持するかを設計しておかないと、後から対応する際に大きな改修コストがかかります。

配信タイミングとメッセージ設計

通知の開封率はメッセージの内容だけでなく、配信タイミングに大きく左右されます。ユーザーがアプリを使いやすい時間帯（通勤時間帯・昼休みなど）に合わせた配信は、開封につながりやすい傾向があります。一方で深夜や早朝の通知はユーザー体験を損ない、通知オフの原因になります。

メッセージ設計では「何を・誰に・なぜ今」の3要素を明確にすることが重要です。「セール開始」という通知より「あなたがお気に入りした商品が20%オフになりました」という通知のほうが、行動を促しやすくなります。このようなメッセージのパーソナライズはFCMのデータメッセージ（4,096バイトまでのペイロードを送信できる機能）と組み合わせることで実現できます^*1。

また、通知頻度の管理も欠かせません。同じユーザーに短期間で複数の通知を送りすぎると、通知をオフにされるリスクが高まります。ユーザーごとの通知受信上限をサーバー側で管理し、頻度を適切に絞ることもシステム設計の一部です。

外注で得られるメリットと費用の目安

外注で解決できる3つの課題——実装・設計・継続改善

プッシュ通知の実装を内製しようとすると、FCM・APNsの双方に対応するための知識が必要です。具体的には、AndroidはFirebase SDK・Kotlin/Java、iOSはXcode・Swift・User Notificationsフレームワークの習熟に加え、アプリサーバー側のトークン管理・API設計の知識が求められます。エンジニア1名が両OSに対応できるケースは少なく、実質的にAndroidとiOSそれぞれの専任者が必要です。

さらに、セグメント配信設計とMAU改善のPDCAを回すためには、フロントエンド実装とバックエンド設計の両方を理解したメンバーが継続的に関与する必要があります。外注を選択することで、これらの専門知識をすでに持つチームに一括して任せられます。

また、通知許可率の改善やセグメント設計の見直しといった「実装後の継続改善」は、一度きりのシステム開発とは異なるサイクルで動きます。外注先に継続改善フェーズも含めて依頼できる体制を確認しておくことが、MAU改善につながる継続的な成果を得るうえで重要です。

外注費用の目安（市場参考値・一次資料ではない）

プッシュ通知機能の実装費用は、対象OSの数・既存アプリへの追加か新規開発か・セグメント配信機能の複雑さによって幅があります。以下は市場で見かける参考値であり、一次資料に基づく数値ではありません。実際の費用は要件定義を経た見積もりで確認してください。

上記はあくまでも市場で見られる参考レンジです。要件の複雑さ・既存コードベースの状態・テスト工数によって大きく変動します。複数社から見積もりを取り、作業範囲の定義を揃えたうえで比較することをおすすめします。

外注先の選び方——実装力・設計力・継続改善力の3軸で確認する

外注先の選定では「実装できる」だけでなく、「MAU改善につながる設計ができるか」「実装後も継続的に改善を支援できるか」の3軸で評価することが重要です。

実装力の確認では、AndroidとiOSの両OS実績・FCMとAPNs双方の対応可否・既存アプリへの追加実装経験を確認します。設計力の確認では、オプトイン設計の提案事例・セグメント配信設計の経験・アプリサーバー側のAPI設計力を聞きます。継続改善力では、実装後のMAU・開封率モニタリング体制と改善提案の実績を確認してください。

また、開発を一括受注できる元請（プライムベンダー）かどうかも確認ポイントです。実装を別の下請け会社に丸投げする会社では、仕様変更や問題発生時の連絡ルートが複雑になり、対応に時間がかかるリスクがあります。元請として責任を持って設計から実装・改善まで一貫して対応できるかを確認してください。

まとめ——プッシュ通知外注で押さえるべき3つの判断軸

本稿ではアプリのプッシュ通知実装をMAU改善につなげるための全体像を整理しました。要点を3つに集約すると次の通りです。

第一に、技術要件の把握です。AndroidはFCM（Android 6.0以上・Google Playストア必須）、iOSはAPNs（トークンベース認証が推奨）と、OSごとに異なる実装工程があります。両OS対応には双方の技術知識が必要になります。

第二に、設計の質がMAUへの波及効果を左右します。通知許可率を高めるオプトイン設計、セグメント配信によるパーソナライズ、配信タイミングの最適化という3つの設計要素が、実装後の再エンゲージメント率に影響します。実装技術だけでなく、これらの設計力を持つ外注先を選ぶことが重要です。

第三に、継続改善フェーズの体制確認です。プッシュ通知は一度実装して終わりではなく、開封率・MAUのモニタリングと定期的な配信設計の見直しが必要です。外注先が継続改善フェーズも受け持てるか、あるいは社内でその体制を持てるかを、外注前に確認しておいてください。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Firebase Cloud Messaging — 概要」（2026年6月19日更新確認）
2. *2　出典：Apple「Notifications Overview — Apple Developer」（2026年6月確認）
3. *3　出典：Google「Firebase Cloud Messaging — Set up an Android client app」（2026年6月確認）
4. *4　出典：Apple「Registering your app with APNs — Apple Developer Documentation」（2026年6月確認）
5. *5　出典：Apple「Establishing a token-based connection to APNs — Apple Developer Documentation」（2026年6月確認）

Tweet