iOS 27では、多くのユーザーがマーケターの書いたプッシュ通知そのものを読まなくなっています。読んでいるのは、Apple Intelligenceが書き換えた後の文章です。以前のロック画面は、送信した通知をほぼそのまま表示していました。今では、モデルが通知を読み、重要度を判断し、一行に要約し、時には表示しないという判断まで下します。プッシュ文面はこのモデルへの入力にすぎず、ユーザーが実際に目にするものとは限りません。
名称について補足します。報道ではこの2つが混同されがちです。通知を書き換えるAI機能の正式名称はApple公式のNotification Summariesです(「Notify Me」ダイジェストとして検索されることもありますが、実際のNotify Meはこれとは別の、iOS 27のSafariのツールです)。本記事が扱うのは、名称に関わらずこの要約レイヤーそのものと、それがプッシュ通知の文面に与える影響です。
これらの機能自体は目新しいものではありません。Notification SummariesとFocusの「通知を減らす」モードは、Apple Intelligenceとともに既にiOS 18で導入されていました。iOS 27で変わったのは、モデルの精度と確信度です。より高性能になったSiriはより積極的に要約し、表示するか隠すかの判断を下す頻度も上がりました。そのため、以前は問題なく届いていた文面も、平板化されたりフィルタリングされたりするようになっています。本記事は、この層を乗り越えるプッシュ通知文面の書き方を解説するガイドです。Pushwoosh はカスタマーエンゲージメントプラットフォームであり、提供するAIコピーツールとペイロード制御は、以下で紹介するレバーに直接対応しています。
AIレイヤーが実際にメッセージに対して行うこと
ユーザーが意識的に読む前に、通知には3つのことが起こります。それぞれがプッシュ文面にとって異なる課題です。
要約される。 Apple Intelligence対応デバイスでは、iOSが通知をAI生成の一行に書き換えることがあります。明確で自己完結した文面を渡せば、要約は忠実な内容になります。曖昧だったり文脈依存の内容を渡すと、モデルは推測でギャップを埋めてしまい、ユーザーは本来書かれていない内容を読むことになります。要約内容そのものを指定することはできません。誤読されにくい文面を渡すことしかできません。
グループ化される。 iOSは関連する通知を1つのスレッドにまとめ、そのセットを要約します。これはペイロードのthread-idキーで制御します。意図的にグループ化すれば、モデルはまとまりのある関連セットを要約します。これを偶然に任せると、無関係な通知同士がつなぎ合わされ、まさにそこで意味がぼやけてしまいます。
フィルタリングされる。 Focusの「通知を減らす」モードは、メッセージの順序を変えるものではありません。ユーザーがそもそも通知を見るかどうかを決定します。ここが注視すべきポイントです。iOS 27ではより高性能なモデルがこの判断を下す頻度が上がり、汎用的なプロモーション文面が真っ先に保留されます。
要するに、ロック画面はもはや情報が欠落しうる、AIを介した表示面になったということです。そのつもりで対応してください。
最初の数語のために書く ― それだけが生き残るから
要約がメッセージを圧縮する際は、冒頭から処理していきます。書き出しの言葉こそが残る意味を担い、それ以降はすべて圧縮されて消える可能性があります。具体的な情報を前面に出し、要点を前置きの後ろに隠さないでください。
同じプロモーションを2通りに書いてみましょう。「今週はあなたに嬉しいお知らせがあります。アプリを開いて何が待っているか確認してください」は、モデルが保持できる具体的な事実が何もないため、要約すると単なるノイズになります。一方「15ドルの特典が今夜の深夜に失効します」は、どんな書き換えを経ても生き残ります。詳細そのものがメッセージだからです。
テストはシンプルです。プッシュ通知の最初の5〜6語だけを読んでみてください。実際の価値が伝わっていなければ、伝わるまで書き直してください。
実際にコントロールできるペイロードのレバー
モデルが書く要約そのものを編集することはできません。しかし、通知ペイロードの3つのフィールドが、その扱われ方を左右します。多くのマーケターは、これらを意図的に設定したことがありません。これは開発チームと一度だけ行う設定であり、配信のたびに調整するものではありません。
| レバー | 機能 | 用途 |
|---|---|---|
Interruption level (time-sensitive) | FocusとスケジュールされたSummaryを突破する | 本当に緊急のメッセージのみに使用。ユーザーはアプリ単位でオフにできるため、多用するとアプリ自体がミュートされます。 |
| Relevance score (0〜1) | Summaryのスタック内での通知の位置を決める | 複数の通知が同時に届いた際、最も重要なメッセージを浮上させる |
Thread ID (thread-id) | 関連する通知をiOSがどのようにグループ化するかを制御する | 意図的にグループ化し、モデルが無関係な通知を1行に混同させず、整理されたセットを要約できるようにする |
time-sensitive)thread-id)これらを一度正しく設定しておけば、以降のすべてのキャンペーンは、モデルの推測に委ねることなく、ロック画面上で妥当な挙動を引き継ぎます。
AI耐性のあるコピーチェックリスト
グループ化と突破はペイロードが担います。文面には、Summaryが実際に読み取る情報すべてを盛り込む必要があります。キャンペーンを配信する前に、次のチェックリストで確認してください。
- 具体性を先頭に置く。 数字、名前、期限、ステータス。ユーザーが必要とする事実は最初の一節に置き、最後には置かない。
- 各通知を自己完結させる。 前後の通知から切り離され、単独で読まれることを前提にする。連続した文脈でのみ意味を持つ文面は、要約で失われる。
- 前置きを削る。 「嬉しいお知らせがあります」や「お見逃しなく」は情報を持たず、圧縮されて消えてしまう。モデルが保持するのは事実であり、熱意ではない。
- 詳細はトーンではなく文面そのものに置く。 数字、名前、時刻は書き換えを生き残るが、雰囲気は生き残らない。
- ロック画面を唯一の機会にしない。 重要なメッセージであれば、アプリ内にも届くようにし、適切な場面ではメールにも展開する。アプリ内コンテンツを更新するサイレントプッシュは、アプリ内メッセージと組み合わせれば、要約を乗り越える必要自体がない。
Focusフィルターは文面だけでなくセグメンテーションの課題でもある
ここには、多くのコピーに関するアドバイスが見落としている、もう一つの視点があります。ユーザーがアプリをFocusフィルターの背後に置けるようになると、通知を突破させ続けるユーザーはあるメッセージを送っています。つまり「このアプリからの情報を求めている」ということです。逆にフィルタリングするユーザーはその逆を伝えており、多くの場合、直近のメッセージが通知に値しなかったことが理由です。
これはセグメンテーションのシグナルであり、見た目以上に価値があります。全員に同じ一斉配信を送り続ければ、最もフィルタリングしやすいユーザーに沈黙を教え込むことになり、望んでいなかった相手に突破予算を浪費することになります。ある事例では、数値を維持するために配信量を増やし続けたアプリがありましたが、最終的にOSが静かにそのプロモーションを「割り込み」と判断し、それでも数値は下落しました。各メッセージがその表示に値するだけの関連性を持つよう、より精緻にセグメンテーションすることが、このフィルターの正しい側にとどまる方法です。これはダイナミックコンテンツによって各メッセージをユーザーに合わせて調整し、行動ベースのセグメントによってプロモーションが本当に適したユーザー層にのみ届くようにすることで実現できます。
厳しい現実として、AIレイヤーは関連性を評価し、配信量を抑制します。しかもこれは今、OSレベルで、ダッシュボードの外側で自動的に行われています。絶対数を伸ばすために配信量を増やすという従来の手法は、ここでは不利に働きます。配信量を減らしても、各メッセージを確実に届けることは、iOS 27における単なるベストプラクティスにとどまらず、そもそも可視性を保つための条件です。
Pushwooshでプッシュ通知文面をより効果的に
数百万規模のユーザーベースに対して、自己完結し具体性を前面に出した文面を、ユーザーごと・セグメントごとにパーソナライズして手作業で用意するのは現実的ではありません。Pushwooshは、AI活用のコピー作成ツール、ダイナミックコンテンツ、そしてメッセージをオーディエンスに適合させるセグメンテーション機能を提供し、配信内容がより多く要約を乗り越えてユーザーに届くよう支援します。SOC 2 Type IおよびISO 27001:2022認証を取得し、GDPRにも準拠しており、お客様のデータはエンタープライズグレードのセキュリティで保護されます。
