LASSIC Media らしくメディア
リッチ通知で開封率改善、プッシュ通知の実装と外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- リッチ通知は、テキストのみのプッシュ通知に画像・動画・操作ボタンを追加する通知拡張の実装です。
- iOSはNotification Service ExtensionとNotification Content Extensionという2つの拡張機能で内容変更と表示を担います*1*2。
- Androidはアプリ内のNotificationCompatが提供する表示スタイルとアクションでリッチ化します*5*6。
目次
リッチ通知とは、画像・操作ボタンでプッシュ通知を拡張する実装
アプリのリッチ通知とは、テキストだけのプッシュ通知に画像・動画・操作ボタンなどを追加し、表現力を高めた通知拡張の実装を指します。通知の配信そのものはFCM(Firebase Cloud Messaging。Googleが提供するプッシュ配信基盤)やAPNs(Apple Push Notification service。Apple製品向けのプッシュ配信基盤)が担いますが、受信したアプリ側で内容を拡張し表示を組み立てる処理が別に必要です。
iOSでは、通知を受信してから画面に表示するまでの間に処理を差し込むNotification Service Extensionと、通知の見た目そのものを作り込むNotification Content Extensionという2つの拡張機能が用意されています*1*2。Androidでは、NotificationCompat(通知の見た目を組み立てるAndroidJetpackのAPI)が提供する表示スタイルとアクションボタンの組み合わせでリッチ化を進めます*5*6。
いずれの仕組みも、通知を受信してから拡張処理を行い、最後にカスタムした内容を表示するという流れは共通しています。プラットフォームごとに使うAPIや制約が異なるため、次章以降ではiOSとAndroidを分けて整理します。
iOSの通知拡張——Notification ServiceとContent Extensionの役割分担
iOSでリッチ通知を実装する場合、まずAPNsに送るペイロードのaps辞書にmutable-content(通知サービス拡張機能を呼び出すためのAPNsペイロードのキー)を1に設定します。このキーが1のとき、システムは通知を配信する前にNotification Service Extensionへ処理を渡します*3。
Notification Service Extensionは専用のUIを持たず、didReceive(_:withContentHandler:)メソッドの中で通知内容を書き換えます*1。画像や動画といった添付コンテンツのダウンロード、暗号化されたデータの復号などをここで行います*1。処理には制限時間が設けられており、完了できない場合は変更前の内容がそのまま配信される仕組みです*1。
もう一つのNotification Content Extensionは、通知が表示された際のカスタムUIを担当します*2。UIViewControllerのサブクラスでUNNotificationContentExtensionプロトコルを実装し、Info.plistにUNNotificationExtensionCategoryとUNNotificationExtensionInitialContentSizeRatioを設定する必要があります*2。カテゴリIDが一致する通知が届いたときにだけ、このカスタムUIが呼び出される仕組みです*2。
この拡張機能では、メディア再生用のmediaPlay・mediaPauseメソッドや、通知内で選んだアクションへの応答処理も実装できます*2。ただしシステムはタッチイベントの配信を制限しており、ジェスチャー認識を組み込むことはできません*2。両者の役割を整理すると次の通りです。
| 項目 | Notification Service Extension | Notification Content Extension |
|---|---|---|
| 主な役割 | 配信前の通知内容の変更*1 | 通知表示時のカスタムUI*2 |
| 呼び出し条件 | aps.mutable-contentが1*1*3 | categoryが登録IDと一致*2 |
| できること | 添付のダウンロード・復号*1 | 専用レイアウト・メディア再生*2 |
| UIの有無 | なし*1 | UIViewControllerで構築*2 |
| 制約 | 制限時間内に処理を完了する必要がある*1 | タッチのジェスチャー認識は使えない*2 |
Androidの通知拡張——NotificationCompatの表示スタイルとアクション
Androidには、iOSのような別プロセスの拡張機能はありません。アプリ内でNotificationCompat.Builderに表示スタイルを設定してリッチ化するのが基本の流れです*5。大きな画像を見せたい場合はBigPictureStyle(展開時に大きな画像を表示するスタイル)を使い、bigPictureメソッドで画像を渡します*6。
折りたたみ時にサムネイルを維持したまま、展開時だけ大きな画像を見せたい場合は、setLargeIconとbigLargeIcon(null)を組み合わせます*6。長文を展開表示したいときはBigTextStyle、チャット形式のメッセージを並べたいときはMessagingStyleを使います*5*6。
MessagingStyleはaddMessageでメッセージを積み上げる形式です。setDataを使えば画像などのメディアメッセージも含められますが、setContentTitleやsetContentTextで指定した内容は表示に反映されません*6。
操作ボタンはaddActionメソッドで追加します。ボタンを押した際の処理はBroadcastReceiverなどに委ね、追加できるアクションボタンは3つまでです*5。Android 8.0以降では通知チャネルの作成も必須で、チャネルごとに重要度を設定する仕組みになっています*5。
どのスタイルを選ぶかは通知の目的で決まります。画像で興味を引きたいならBigPictureStyle、会話の続きを見せたいならMessagingStyleというように、狙いに応じて使い分けることが実装のポイントです。
配信基盤(FCM/APNs)との関係——画像URLとmutable-contentの受け渡し
リッチ通知の画像は、配信基盤側の設定と受信側の拡張機能が連携してはじめて表示されます。FCMでプラットフォームをまたいで画像付き通知を送る場合、Androidにはnotification.imageUrlフィールドを、iOSにはfcm_options.imageフィールドを指定します*4。
iOS向けに画像URLを指定する際は、headersに”mutable-content”:1を含める必要があります*4。これはAPNsのaps辞書に渡すmutable-contentキーに対応し、値が1の通知だけがNotification Service Extensionへ処理を渡される仕組みと連動しています*3*4。設定を忘れると、画像URLを送っていても拡張機能が呼ばれず、画像は表示されません。
画像自体のサイズにも制約があります。FCMの通知画像は1MBまでという制限があり、Androidの組み込み画像表示仕様に適合させる必要があります*4。配信基盤側のペイロード設計を含めたリッチ通知全体の構築は、配信基盤の選定やMA(マーケティングオートメーション。顧客への配信を自動化する仕組み)ツールとの連携まで踏み込む別テーマです。本稿では受信側アプリでの通知拡張の実装に絞って解説します。
実装で見落としやすい落とし穴——時間制限・権限・計測
Notification Service Extensionには処理を終えるまでの制限時間があります*1。画像のダウンロードや復号に時間がかかりすぎると、拡張前の元の内容がそのまま配信され、リッチ通知を実装した意図が届かない結果になりかねません*1。
Notification Content Extensionの側では、Info.plistの設定を1つ誤るだけでカスタムUIが呼び出されなくなります*2。UNNotificationExtensionCategoryが通知のcategoryと一致していないと、システムは標準の表示にフォールバックしてしまいます*2。
Android側でも、通知チャネルの設定漏れや、端末・OSバージョンによる表示差分の検証が抜けると、意図した見た目にならないことがあります*5。開封率やタップ率の変化を評価するには、通知の種類ごとに計測タグを分けて配信ログと突き合わせる運用も欠かせません。
この作業を内製で担うには、複数領域の知識が要ります。iOS側のアプリ拡張ターゲットの設定・プロビジョニング、Android側の表示スタイルとOEM差分の検証、配信基盤のペイロード設計などです*1*2*5*6。
内製と外注の分かれ目——通知拡張のスキル要件で判断する
リッチ通知の実装そのものはOSベンダーが手順を公開しているため、対応するプラットフォームが1つで通知パターンが少なければ、自社での対応も選択肢になります。判断が分かれるのは、iOSとAndroidの両方に同時対応し、画像・動画・アクションボタンなど複数パターンを運用する場合です。
専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目になります。アプリ拡張ターゲットの設計・実装から、FCM/APNs側のペイロード仕様との整合確認、端末差分の検証までを一括して依頼できるかを確認します*1*2*4。内製では既存の開発担当者が通常業務と並行して対応することになり、複数OSの検証に割ける時間が限られる場合があります。
。対応するプラットフォームの数や通知パターンの種類によって、必要な工数は変わってきます。現状のアプリ構成を診断したうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：リッチ通知の実装で押さえる3つの判断軸
本稿ではアプリのリッチ通知について、iOSとAndroidそれぞれの通知拡張の仕組みを公式情報をもとに整理しました。要点は3つに集約できます。第一に、iOSはNotification Service ExtensionとNotification Content Extensionという2つの拡張機能で、内容の変更と表示の両方を担います*1*2。第二に、Androidはアプリ内のNotificationCompatが提供する表示スタイルとアクションボタンでリッチ化を進めます*5*6。第三に、画像URLの指定とmutable-contentの設定は配信基盤側と受信側の両方が連動してはじめて機能し、対応プラットフォーム数や通知パターンの多さが内製と外注の判断材料になります*3*4。
よくある質問
iOSとAndroidの両方でリッチ通知を実装する場合、共通化できる部分はありますか。
画像URLの配信ペイロード設計など一部は共通化できますが、表示処理はプラットフォームごとに別実装が必要です*4。iOSはNotification Service/Content Extension、AndroidはNotificationCompatのスタイルというように、それぞれ専用のAPIで作り込みます*1*2*5。
mutable-contentを1に設定したのに画像が表示されないことがあるのはなぜですか。
mutable-contentはNotification Service Extensionを呼び出すためのフラグであり、画像のダウンロードや復号は拡張機能側の実装が担う処理です*3。設定だけでは不十分で、拡張機能内で添付データを正しく取得する処理が必要になります*1。
Notification Service Extensionの処理が終わらない場合はどうなりますか。
システムが定める制限時間内に処理を完了できないと、拡張前の元の通知内容がそのまま配信されます*1。画像のダウンロードや復号に時間がかかる実装ほど、この制約への配慮が欠かせません。
Androidの通知にアクションボタンを追加する場合、いくつまで設定できますか。
addActionメソッドで追加できるアクションボタンは3つまでです*5。ボタンごとの処理はBroadcastReceiverなどで受け取り、Android 8.0以降では通知チャネルの設定もあわせて必要になります*5。
リッチ通知の実装だけを外部に委託し、配信基盤は自社で運用することはできますか。
受信側アプリの通知拡張の実装範囲だけを切り分けて委託することは可能です。委託前には、既存のFCM/APNs側のペイロード仕様との整合確認や、テスト用配信環境の提供範囲を委託先とすり合わせておくことが大切です*4。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Apple「UNNotificationServiceExtension」（Apple Developer Documentation）
- *2 出典：Apple「UNNotificationContentExtension」（Apple Developer Documentation）
- *3 出典：Apple「Generating a Remote Notification」（Apple Developer Documentation）
- *4 出典：Firebase「Customize a message across platforms」（Firebase Cloud Messaging Documentation）
- *5 出典：Android Developers「Create a notification」（Android Developers）
- *6 出典：Android Developers「Create an expandable notification」（Android Developers）
