最終更新: 2026-08-31

プッシュ通知の文字数制限 - iOS / Android 別の表示上限と開封率を高めるコツ

プッシュ通知で表示される文字数の目安は、iOS がタイトル約 50 文字・本文約 178 文字 (ロック画面。バナーは約 80 文字)、Android がタイトル 65 文字・本文約 45 文字 (折りたたみ時。展開時は 240 文字) です。OS や表示コンテキストによって大きく変わるため、確実に伝えたい情報はタイトル 20 文字以内・本文 40 文字以内に収めるのが安全です。

プッシュ通知はLINE メッセージと同様にモバイルコミュニケーションの主要チャネルですが、表示される文字数には厳しい文字数制限があります。この制限は OS やデバイスの表示領域だけでなく、APNs (Apple Push Notification service) や FCM (Firebase Cloud Messaging) のペイロードサイズに起因する技術的な制約でもあります。制限を正しく理解し、限られた文字数で最大限の効果を引き出すことが求められます。

APNs と FCM のペイロード制限 - 文字数制限の技術的背景

プッシュ通知の文字数が制限される根本的な理由は、通知データを運ぶペイロードのサイズ上限にあります。APNs のペイロード上限は 4 KB (4,096 バイト) で、これは現行の HTTP/2 API での値です。2021 年 3 月に停止した旧バイナリ接続では 2 KB でした。FCM を使う場合も、iOS 向けの通知は最終的に APNs を経由するため同じ上限が効きます。Android 向けにも同程度のペイロード上限がありますが、実務ではこの技術的上限より先に、次に述べる UI 側の表示上限に突き当たります。

ペイロードにはタイトルや本文だけでなく、サウンド指定、バッジ数、カスタムデータ (ディープリンク URL、キャンペーン ID など) も含まれます。JSON 形式でエンコードされるため、日本語のようなマルチバイト文字は UTF-8 で 1 文字あたり 3 バイトを消費します。つまり、4 KB のペイロードに日本語だけを詰め込んでも理論上は約 1,365 文字が上限ですが、メタデータやカスタムデータを差し引くと、実際にテキストに使える容量はその半分以下になります。

OS 別の文字数制限

ペイロードの技術的上限とは別に、各 OS の UI が表示できる文字数にも制限があります。ここで先に断っておくべき点があります。プラットフォームの公式ドキュメントは表示量を「行」で規定しており、文字数では規定していません。たとえば Android の公式ガイドは、折りたたみ表示の本文について「1 行に収まるよう切り詰められる」と説明するだけで、文字数には触れていません。以下の表は 2026 年 8 月時点で日本語・標準の文字サイズを前提にした実務上の目安であり、公式に明記されていない項目も含みます。端末の画面幅・文字サイズ設定・OS バージョンで前後するため、絶対値としてではなく「どの表示枠が厳しいか」の相対関係として読んでください。

注目すべきは、同じ iOS でもロック画面・バナー・通知センターで表示文字数が大きく異なる点です。バナー通知は画面上部に一瞬表示されるだけなので本文は約 80 文字に制限されますが、ロック画面では 4 行程度まで表示されるため約 178 文字まで読めます。通知センターでは長押し操作で全文を展開できるため、ペイロード上限までのテキストが閲覧可能です。

通知の種類ごとに文字数の配分を変える

「何文字が正解か」は業種で決まるものではなく、その通知がユーザーの何を代替しているかで決まります。文字数の配分は、通知を次の 2 種類に分けて考えると迷いません。

• 確認のための通知 (注文確認、入金、配送状況、認証コードなど): ユーザーは結果だけを知りたい状態です。「入金 50,000 円」のようにタイトルだけで用が済む形が理想で、本文に説明を足すほど読み飛ばされます。折りたたみ表示の 1 行に収まる長さを上限と考えます
• 誘導のための通知 (セール、新着、イベント告知など): タップされて初めて価値が生まれる状態です。タイトルで「何が・いつまで」を示し、本文には理由を 1 つだけ添えます。本文に条件を並べると、折りたたみ表示で条件の途中が切れて誤解を生みます

実務で最も多い失敗は、この 2 種類を同じテンプレートで書いてしまうことです。確認通知に販促の一文を混ぜると通知そのものが警戒され、逆に誘導通知を確認通知のように淡々と書くとタップされません。文字数の上限を決める前に、その通知がどちらなのかを決めるほうが先です。

本文はビジネスメールと同様に簡潔さが求められますが、メールよりもさらに短く、詳細は省略しても意味が通じる構成にする必要があります。折りたたみ表示では 1〜2 行しか見えないため、冒頭の 40 文字に最も伝えたい情報を凝縮することが重要です。

なぜ OS ごとに文字数が異なるのか

iOS のバナー通知が 2 行程度で切り詰められるのは、通知が「作業を中断させる割り込み」として設計されているためです。一瞬で内容が判断できる量に抑えることが優先され、表示面積は意図的に小さく保たれています。iOS 16 以降ではロック画面の通知表示が下部に集約され、壁紙の視認性を優先する設計に変更されたため、表示面積はさらに限定的になりました。

一方、Android の展開表示は、段階的開示 (progressive disclosure) という UI の考え方に沿ったものです。折りたたみ時は 1 行で概要を伝え、ユーザーが興味を持てば展開して詳細を読めるという 2 段階の設計です。Android 13 以降では通知の許可がオプトイン方式に変更され、iOS と同様にユーザーの明示的な許可が必要になりました。この変更により、Android でも通知許可率が低下する傾向にあり、許可を得た貴重なユーザーに対して質の高い通知を送ることの重要性が増しています。

リッチ通知の文字数制限と設計上の注意点

iOS 10 以降の Notification Content Extension と Android の BigPictureStyle / BigTextStyle を使ったリッチ通知では、画像・ボタン・カルーセルを含む高度な通知が可能です。ただし、リッチ通知にはテキスト通知とは異なる文字数の制約があります。

• 画像付き通知のテキスト領域縮小: 画像やサムネイルを添付すると、その分だけ本文に使える表示領域が狭くなります。縮小の度合いは端末と表示枠で変わるため固定値としては扱えません。画像を使う通知では、テキストのみの場合より早く本文が切れる前提で書き、画像が読み込めなかった場合にもテキストだけで意味が通るようにしておきます
• アクションボタンの影響: Android の公式ガイドは、アクションボタンを最大 3 つまでと定めています。iOS でも表示できる数は少数に限られます。ボタンラベルの文字数上限は公式には示されていませんが、表示幅が狭いため長いラベルは省略されます。「購入する」「詳細を見る」のように 5〜8 文字に収めるのが実用的です
• ペイロードへの影響: 画像 URL やアクションボタンの定義がペイロードを消費するため、テキストに使える容量が減少します。画像は URL 参照 (APNs の mutable-content + Notification Service Extension) で配信するのが一般的で、画像データ自体はペイロードに含めません

ウェアラブルデバイスでの表示 - 見落としがちな制約

Wear OS では通知カードとして表示され、スクロールで全文を閲覧できますが、最初に目に入るのはタイトルと本文の冒頭約 30 文字です。ウェアラブルデバイスのユーザーは移動中や運動中に通知を確認することが多いため、タイトルだけで内容が把握できる設計が求められます。ウェアラブル向けに通知を最適化する場合、タイトルは 20 文字以内、本文の冒頭 30 文字に核心情報を配置するのが効果的です。

Web プッシュ通知の制限

Web プッシュ通知はブラウザと OS の組み合わせによって表示が大きく異なります。Chrome、Firefox、Safari でそれぞれ表示可能な文字数や見た目が変わるため、最も制限の厳しい環境に合わせて設計するのが安全です。

Safari は macOS Ventura 以降で Web プッシュ通知に対応しましたが、iOS の Safari では iOS 16.4 以降かつ PWA (ホーム画面に追加したアプリ) でのみ対応しています。通常のブラウザタブからは Web プッシュを送信できないため、iOS ユーザーへのリーチには制約があります。

一般的に、タイトルは 30 文字以内、本文は 80 文字以内に収めれば、主要なブラウザと OS の組み合わせで省略されずに表示されます。アイコンやバッジ画像を設定すると、どのサイトからの通知かが一目で分かるようになります。Web プッシュは複数のサイトから同じ形式で届くため、送信元の識別しやすさはテキストの短さと同じくらい重要です。

A/B テストの設計方法 - 通知文の最適化プロセス

プッシュ通知の A/B テストは、メールマーケティングの A/B テストとは異なるアプローチが必要です。通知は一度送信すると取り消せず、ユーザーの反応が数分以内に集中するため、テスト設計には以下の点を考慮します。

• テスト対象の分離: 1 回のテストで変更する要素は 1 つに限定します。タイトルの文字数をテストするなら、本文・送信時間・画像は固定します。複数要素を同時に変更すると、どの要素が結果に影響したか判別できません
• サンプルサイズの確保: 統計的に有意な結果を得るには、各バリアントに最低 1,000〜2,000 ユーザーを割り当てるのが目安です。ユーザー数が少ないアプリでは、複数回のテストを積み重ねて傾向を把握します
• 時間帯の統制: A/B の両グループに同じ時間帯で送信します。朝と夜では開封率が大きく異なるため、送信時間のずれがテスト結果を歪めます
• 測定指標の選定: 開封率 (タップ率) だけでなく、通知経由のコンバージョン率、アプリ内滞在時間、通知オフ率も追跡します。開封率が高くても通知オフ率が上昇していれば、長期的にはマイナスです

パーソナライズ通知の文字数戦略

パーソナライズ通知では、ユーザー名や動的データを挿入するため、固定テキストの文字数を事前に計算しておく必要があります。たとえば「{ユーザー名}さん、カートに商品が残っています」というテンプレートでは、ユーザー名の長さによって全体の文字数が変動します。

日本語のユーザー名は数文字で収まることが多い一方、英語名やニックネームでは 10 文字を超えることもあります。テンプレート設計時は、最長のユーザー名を想定してもタイトルが省略されないよう、固定テキスト部分を短く保つことが重要です。具体的には、タイトルのテンプレートは固定部分を 15 文字以内に抑え、動的部分に 10 文字程度の余裕を持たせます。

パーソナライズで見落としやすいのは、差し込みが失敗したときの見え方です。ユーザー名が未登録なら「さん、カートに商品が残っています」という主語のない文が配信されてしまいます。代替文 (「お客様」など) を必ず用意し、テスト配信では最長の値と空文字の 2 パターンで実際の表示を確認します。文字数の設計と同時に、この 2 パターンの見え方を確認しておけば、配信後に取り消せない事故を防げます。

通知疲れを防ぐ - 配信頻度と文字数の関係

プッシュ通知は「送りすぎない」ことが極めて重要です。1 日に何度も通知を送ると、ユーザーが通知をオフにしたりアプリをアンインストールしたりするリスクが高まります。通知のオフは一度されると復帰が期待できない不可逆な離脱で、しかも送信側からは「届いていない」ことが分かりにくいという性質があります。開封率だけを見ていると、母数が静かに減っていることに気づけません。

配信頻度と文字数には相関があります。頻度が高い場合 (1 日 1 回以上)、各通知は極力短く (タイトル 15 文字以内、本文 30 文字以内) して情報密度を下げ、ユーザーの認知負荷を軽減すべきです。一方、週 1〜2 回の配信であれば、やや長めの本文 (60〜80 文字) で詳細な情報を伝えても通知疲れを招きにくくなります。

通知の種類によっても適切な頻度は異なります。取引通知 (注文確認、配送状況) はリアルタイム性が求められるため頻度制限の対象外ですが、プロモーション通知は週 2〜5 回が多くのアプリにとって適切な上限です。ユーザーごとに通知頻度の上限 (フリークエンシーキャップ) を設定し、一定期間内の送信数を制御する仕組みを導入することで、通知疲れを体系的に防止できます。

iOS と Android の通知許可率の違い

iOS はアプリの初回から通知を明示的に許可する方式でしたが、Android 12 以前ではデフォルトで通知が許可されていました。Android 13 以降は POST_NOTIFICATIONS 権限の明示的な許可が必要になり、両 OS で「許可を得たユーザーだけに届く」前提が揃いました。この変更以降、Android でも許可率は低下する傾向にあります。

iOS アプリでは、通知許可リクエストのタイミングと文言が極めて重要です。アプリ初回起動時にいきなり許可を求めるのではなく、ユーザーが通知の価値を理解した後 (初回購入後、お気に入り登録後など) にリクエストする「プリパーミッション」パターンが効果的です。許可リクエスト前にアプリ内ダイアログで通知のメリットを説明し、ユーザーが「通知を受け取る」を選択した場合にのみ OS の許可ダイアログを表示します。OS の許可ダイアログは一度拒否されると再表示できず、ユーザーを設定画面まで誘導しないと復帰できません。アプリ内ダイアログを前置きするのは、この 1 回きりの機会を「関心のあるユーザーに絞って使う」ためです。

よくある失敗パターン

• 深夜に通知を送信してユーザーの信頼を失う: 午後 10 時〜午前 7 時の通知は、ユーザーの睡眠を妨げるだけでなく、通知オフやアプリのアンインストールに直結します。タイムゾーンを考慮した送信スケジュールの設定は必須です。グローバル展開するアプリでは、ユーザーのローカルタイムゾーンを取得し、各地域の適切な時間帯に配信する仕組みが必要です
• 「お知らせ」「重要」など曖昧なタイトルで開封率が低迷する: 具体性のないタイトルは、ユーザーに「また宣伝か」と判断されてスルーされます。「本日 18 時まで 50% OFF」のように、具体的な数字と期限を含めれば、通知を見た時点で内容が判断できます
• 全ユーザーに同一の通知を一斉配信する: セグメンテーションなしの一斉配信は、関連性の低いユーザーにとってノイズでしかありません。ユーザーの属性 (購買履歴、アプリ利用頻度、地域) に基づいてセグメントを分け、各セグメントに最適化された通知を送ることで、開封率とコンバージョン率の両方が向上します
• ディープリンクを設定せずトップ画面に遷移させる: 通知タップ後にアプリのトップ画面が開くのは UX の失敗です。通知の内容に対応する具体的な画面 (商品詳細、キャンペーンページなど) へ直接遷移させます。通知で興味を持ったユーザーに、アプリ内で目的の画面を探し直させないことが要点です

プロが実践する通知テクニック

• リッチ通知は「テキストだけでも成立する」形で使う: 画像やサムネイルは一覧の中で目に留まりやすくなりますが、画像は端末の通信状況によって読み込まれないことがあります。画像が出なかった場合でもタイトルと本文だけで用が済む構成にし、画像に情報を載せきらないことが前提です
• 送信時間帯をユーザーごとに最適化する: 全ユーザーに同じ時間帯で送るのではなく、各ユーザーの過去のアプリ利用パターンから最もアクティブな時間帯を推定し、個別に配信時間を調整します。一般に反応が良いとされる時間帯はサービスの性質によって異なり、個人差も大きいため、自社の配信ログを時間帯別に見て判断するのが確実です
• 通知チャネルを活用して優先度を制御する: Android 8.0 以降の通知チャネル機能を使い、通知の種類 (取引、プロモーション、ニュースなど) ごとにチャネルを分離します。ユーザーはチャネル単位で通知のオン・オフを切り替えられるため、重要な取引通知がプロモーション通知と一緒にオフにされるリスクを回避できます

まとめ

プッシュ通知の文字数制限は、APNs・FCM のペイロード上限と各 OS の UI 設計の両方に起因します。iOS と Android で表示文字数が異なるだけでなく、ロック画面・バナー・通知センター・ウェアラブルデバイスなど表示コンテキストによっても大きく変わります。確実に伝えたい情報はタイトル 20 文字以内、本文 40 文字以内に収めるのが安全です。通知の種類 (確認のためか、誘導のためか) に応じた文字数の配分、A/B テストによる継続的な改善、差し込み失敗時まで想定したパーソナライズ設計が、通知の効果を左右します。通知文を作成する際は、文字数カウントスで文字数を確認してから配信しましょう。