これまでのAEO(Answer Engine Optimization)フロンティア連載では、AIが自社の情報に触れる「場面」を一つずつ広げてきました。「越境」「記憶」「速報」「定期実行」「滞在中」「相手の社内」「近くで探す」と続けてきたこのシリーズで、8本目に取り上げるのは「届いた後(インボックス)」です。
Webページの最適化はかなり進みました。しかし、企業がいちばん多く出している文章は、Webページではなくメールと通知です。メルマガ、注文確認、請求案内、セミナー招待、営業メール、アプリのプッシュ通知。これらはいま、受信者が本文を開く前に、GmailのGemini、OutlookのCopilot、スマートフォンOSの通知要約といったAIに先に読まれ、要約・仕分け・優先度判定されています。
受信者の多くは、AIの1行要約を見て「読む/後で/読まない」を決めます。つまり成果を決めるのは、件名のテクニックよりも「AIが1行に要約したときに何が残るか」です。本稿では、誤って要約されず、後回しにされず、開封と行動につながるメール・通知の設計を整理します。メルマガ1本から今日すぐ試せるため、中小企業こそ取り組みやすいテーマです。
- 目次
- はじめに——企業がいちばん多く書いている文章は「メール」
- 前提——受信箱で何が起きているか
- これまでのAEOとの違い
- 受信箱AIで「損をする」メールの5つの典型
- 設計原則1:「1行要約で残る文」を冒頭に置く
- 設計原則2:件名・プレヘッダー・冒頭3行を一致させる
- 設計原則3:日付・金額・期限・行動を「拾える形」で書く
- 設計原則4:1通1目的——詰め込みは優先度を下げる
- 設計原則5:送信者の信頼シグナルと「関係の継続」を整える
- プッシュ通知の設計——「要約の要約」に耐える
- メールの種類別のポイント
- 検証——「AIに要約させてみる」テストを配信前の工程にする
- 受信箱AEOチェックリスト
- よくある質問
- まとめ——「AIの1行」で用件が伝わるメールにする
- 関連記事
- 参考リンク
目次
- はじめに——企業がいちばん多く書いている文章は「メール」
- 前提——受信箱で何が起きているか
- これまでのAEOとの違い
- 受信箱AIで「損をする」メールの5つの典型
- 設計原則1:「1行要約で残る文」を冒頭に置く
- 設計原則2:件名・プレヘッダー・冒頭3行を一致させる
- 設計原則3:日付・金額・期限・行動を「拾える形」で書く
- 設計原則4:1通1目的——詰め込みは優先度を下げる
- 設計原則5:送信者の信頼シグナルと「関係の継続」を整える
- プッシュ通知の設計——「要約の要約」に耐える
- メールの種類別のポイント
- 検証——「AIに要約させてみる」テストを配信前の工程にする
- 受信箱AEOチェックリスト
- よくある質問
- まとめ
- 関連記事
- 参考リンク
はじめに——企業がいちばん多く書いている文章は「メール」
自社サイトの記事は月に数本でも、メールは毎日何十通、何百通と出ています。注文確認や予約リマインドのような自動送信メールまで含めれば、顧客が目にする自社の文章の大半はメールと通知だといっても大げさではありません。
そのメールの「読まれ方」が変わりました。以前は、件名と差出人を見て人が開封を判断していました。いまは次のような流れが増えています。
- 受信箱のAIが本文を読み、1〜3行の要約を作る
- AIが重要度・関連度を判定し、並び順や表示位置を決める
- 受信者は要約だけを見て、開く・後回しにする・アーカイブするを決める
この流れでは、本文の3段落目に書いた「締切は今週金曜」や、末尾に置いた「ご返信ください」は、要約に残らなければ存在しないのと同じです。受信箱AEOとは、この「AIの1行」に何が残るかを設計する取り組みです。
前提——受信箱で何が起きているか
メールクライアントが「本文の前に要約を見せる」ようになった
Googleは2025年5月、GmailのモバイルアプリでGeminiによる要約カード(summary cards)を自動表示する機能を展開しました。長いスレッドや返信の多いメールで、本文の上に要約が自動で表示されます。展開当初は英語メールが対象で、対象プランも限られていますが、「受信者が頼まなくても要約が先に出る」という方向ははっきりしています。
Microsoftも、Outlookの「受信トレイの優先順位付け(Prioritize my inbox)」をCopilotの機能として展開しています。Copilotが受信メールを高・通常・低の優先度に分け、メッセージ一覧の1行目を短い要約に置き換え、なぜその優先度にしたのかの説明も表示します。判定には、スレッドの参加者、その役職、メールの内容などが使われます。ユーザーは「上司からのメール」「〇〇案件に触れているもの」といった条件を自分で指示として追加できます。
「仕分け」と「並び順」もAIが決める
Gmailは2025年9月、プロモーションタブに「関連性の高い順(Most relevant)」の並び替えを追加しました。受信者がよく反応するブランドのメールが上に来て、期限の近いお得情報には目立つ表示が付きます。同時に、レシートや注文確認、配送通知を一か所にまとめる「購入(Purchases)」ビューも加わりました。
メルマガにとっては、「届いたかどうか」だけでなく、プロモーションタブの中で何番目に並ぶかが受信者との関係性で決まるようになった、ということです。
OSの通知そのものが要約される
AppleはApple Intelligenceで、iPhoneなどの通知を要約してまとめて表示する機能を提供しています。2025年1月のiOS 18.3では、ニュース見出しの誤要約が報道機関から批判されたことを受けて、ニュース・エンタメ系アプリの要約をいったん停止しました。その後iOS 26で、要約であることを示す表示を付けたうえで再開しています。
この経緯が示すのは、AIの要約は元の文意を変えてしまうことがあるという点です。自社のアプリ通知やSMSも、受信者の画面では「自社が書いた文」ではなく「AIが言い換えた文」で表示されることがあります。
受信箱AIが見ている3つの軸
| 軸 | AIが判断していること | 送り手が影響できること |
|---|---|---|
| 要約 | このメールは結局何の話か、受信者に何を求めているか | 冒頭の書き方、要点の位置、1通あたりの論点の数 |
| 仕分け | 宣伝か、取引か、個人宛ての連絡か | メールの種類の分離、送信元アドレスの使い分け、構造化データ |
| 優先度 | 今すぐ見るべきか、後回しでよいか | 期限・行動の明示、受信者との関係性(反応履歴)、送信者の信頼性 |
これまでのAEOとの違い
受信箱AEOは、これまでの連載と次の点で異なります。
| 観点 | これまでの連載 | 受信箱AEO(本稿) |
|---|---|---|
| AIが読む対象 | 公開Webページ、店舗情報、B2B資料など | 自社が送ったメール・通知そのもの |
| 誰が起点か | ユーザーがAIに質問する、ページを開く | こちらから届ける。受信者は何も聞いていない |
| AIの役割 | 回答・推薦・引用 | 要約・仕分け・優先度判定 |
| 失敗の形 | 引用されない、候補から落ちる | 誤って要約される、後回しにされる、読まれずアーカイブされる |
| 改善の単位 | サイト・データ・ドキュメント | 1通のメール(すぐ試せる) |
特に近い3本との違いを整理しておきます。
- 「相手の社内」編(10/2公開)は、B2B資料が購買側の社内AIに取り込まれる話でした。本稿は、個人の受信箱に毎日届くメールと通知を扱います。
- 「滞在中」編(9/29公開)は、ユーザーが自分からページを開いた後の話でした。本稿は、こちらから届けたものが、ユーザーより先にAIに読まれる場面です。
- 「定期実行」編(9/26公開)は、AIのブリーフィングに自社情報が引用される話でした。本稿は、自社が送るメッセージそのものがどう要約されるかを扱います。
受信箱AIで「損をする」メールの5つの典型
| 典型パターン | AI要約で起きること | よくある原因 |
|---|---|---|
| ① 前置きが長い | 「〇〇社からのご挨拶」と要約され、用件が消える | 時候の挨拶・近況報告が冒頭を占めている |
| ② 用件が画像の中 | 要約が空疎になる、または「キャンペーンのお知らせ」だけになる | バナー画像に日付・価格・条件を入れ、テキストにない |
| ③ 話題が多すぎる | 「複数のお知らせ」とまとめられ、どれも行動につながらない | 新商品・イベント・ブログ更新・採用を1通に詰め込む |
| ④ 期限と行動があいまい | 優先度が「低」になり、後回しにされる | 「お早めに」「ぜひご検討ください」で終わっている |
| ⑤ 煽り表現が強い | 宣伝として仕分けられる、要約で誇張が強調・誤解される | 「緊急」「最後のチャンス」「重要」の多用 |
いずれも、人が読めば最後まで読んで理解できるメールです。問題は、AIは「最後まで読んだうえで、短く言い直す」という点にあります。言い直しの材料になる文が冒頭にない、テキストにない、ひとつに絞れない。この3つが、誤要約と後回しの主な原因です。
設計原則1:「1行要約で残る文」を冒頭に置く
最も効果が大きく、今日から変えられるのがこれです。メールの冒頭1〜2文に、「誰に・何が・いつまでに・何をしてほしいか」をそのまま書きます。報告書でいう結論先行(BLUF:Bottom Line Up Front)を、メールに持ち込むイメージです。
改善前
いつも大変お世話になっております。〇〇株式会社の△△です。朝晩すっかり涼しくなってまいりましたが、皆さまいかがお過ごしでしょうか。さて、弊社では日頃のご愛顧に感謝を込めまして、このたび秋の特別企画をご用意いたしました。詳細は以下をご覧ください……(本文の後半に「10月20日まで全品15%オフ、クーポンコードAUTUMN15」)
改善後
【10月20日(火)まで】会員様限定で全品15%オフです。ご注文時にクーポンコード「AUTUMN15」を入力してください。
いつも〇〇をご利用いただきありがとうございます。今回は秋の新作を含む全商品が対象です……
改善後のメールは、AIがどう要約しても「10月20日まで全品15%オフ、コードAUTUMN15」が残ります。挨拶を削る必要はありません。順番を入れ替えるだけです。
冒頭の文を書くときは、次の問いに答えられるか確認します。
- この1文だけ読んだ受信者は、自分に関係があるとわかるか
- 期限(日付と曜日)が入っているか
- 受信者がとる行動が1つに特定できるか
設計原則2:件名・プレヘッダー・冒頭3行を一致させる
AIは件名だけでなく本文全体から要約を作ります。件名と本文の主張がずれていると、AIは本文側を優先して要約することが多く、件名で約束したことが要約から消える、あるいは「件名と内容が違うメール」として扱われる原因になります。
- 件名:用件と期限(例:「【10/20まで】会員限定 全品15%オフのご案内」)
- プレヘッダー(受信一覧に出る冒頭テキスト):件名の補足。条件や対象を書く(例:「コードAUTUMN15で秋の新作も対象」)
- 冒頭3行:件名とプレヘッダーの内容を文章で言い切る
この3点が同じ内容を指していれば、AIの要約も、AIを使わない受信者の目にも、同じメッセージが届きます。「開封させるために件名で情報を伏せる」手法は、AI要約が先に出る環境では逆効果になりやすいと考えたほうが安全です。
設計原則3:日付・金額・期限・行動を「拾える形」で書く
AIが要約や優先度判定で拾いやすいのは、テキストとして明示された具体的な事実です。
| 要素 | 拾われにくい書き方 | 拾われやすい書き方 |
|---|---|---|
| 期限 | 「今月中」「お早めに」 | 「10月20日(火)23:59まで」 |
| 金額 | バナー画像内の「最大50%OFF」 | 本文テキストで「対象商品が15%オフ(例:12,000円→10,200円)」 |
| 行動 | 「ぜひご検討ください」 | 「参加希望の方は10月17日までにこのメールに返信してください」 |
| 対象者 | 「皆さま」 | 「2025年以降にご購入いただいた会員様」 |
| 取引情報 | 表組みの画像 | 注文番号・金額・お届け予定日をテキストで記載 |
画像を使う場合も、画像に書いた重要な情報は必ず本文テキストにも書きます。代替テキスト(alt)にも内容を入れておくと、画像を表示しない環境でも意味が伝わります。
Gmailには、メール内に構造化データ(schema.org)を埋め込んで、プロモーションタブでの割引表示や、注文・予約情報の表示に使える仕組みがあります。利用には送信者側の条件や申請が必要なものもあるため、配信サービス(ESP)が対応しているかをまず確認するとよいでしょう。構造化データは補助であり、本文テキストで事実が明示されていることが前提です。
設計原則4:1通1目的——詰め込みは優先度を下げる
月刊ニュースレターに「新商品」「セミナー」「ブログ更新」「年末年始の営業日」「採用情報」を全部入れると、AIの要約は「〇〇社の10月のお知らせ(複数)」のようになりがちです。受信者にとっては自分に何が求められているかわからないメールになり、優先度も上がりません。
- 行動を求めるもの(申込・返信・支払い)は単独のメールにする
- ニュースレター形式を続ける場合は、冒頭に「今回いちばん伝えたい1件」を置き、他は「その他のお知らせ」として後半にまとめる
- 営業日変更・価格改定・規約変更など見落とされると困る情報は、宣伝メールに混ぜない
特に最後の点は重要です。宣伝メールの末尾に重要なお知らせを入れると、メール全体が宣伝として仕分けられ、重要なお知らせごと後回しにされるおそれがあります。
設計原則5:送信者の信頼シグナルと「関係の継続」を整える
どれだけ本文を整えても、受信箱に届かなければ要約もされません。また、Gmailの「関連性の高い順」のように、受信者がそのブランドにどれだけ反応してきたかが並び順に影響する仕組みも出てきています。
技術的な信頼シグナル
- SPF・DKIM・DMARCによる送信ドメイン認証を設定する(Gmailは2024年2月から、大量送信者に認証・ワンクリック登録解除・低い迷惑メール率を求めています)
- ワンクリックで配信停止できるようにする(List-Unsubscribeヘッダー)
- メルマガ用・取引通知用・個別連絡用で送信元アドレス(またはサブドメイン)を分ける。取引メールが宣伝と同じ扱いになるのを防げます
関係の継続
- 反応のない宛先に送り続けない。一定期間開封のない宛先は配信頻度を下げる、または確認メールを送る
- 配信頻度を上げすぎない。「よく届くが読まれない送信者」として学習されると、その後のメールも後回しにされやすくなります
- 返信を受け付ける。noreplyアドレスより、返信できるアドレスのほうが受信者との双方向の関係を作りやすくなります
プッシュ通知の設計——「要約の要約」に耐える
アプリの通知やSMSは、もともと短い文です。それでもOSの通知要約では、複数の通知がまとめて1〜2行に言い直されます。ここで誤解が生まれやすくなります。
- 1通知1事実:「新着3件・セール開始・ポイント付与」を1つの通知に入れない
- 主語と対象を省かない:「本日終了!」ではなく「〇〇ストアの秋セールは本日23:59終了」
- 否定・条件を後ろに置かない:「配送遅延はありません」が「配送遅延」に縮められるような書き方を避け、「通常どおりお届けします」と肯定形で書く
- 数字は単位と一緒に:「50」ではなく「50ポイント」「50%オフ」
- 送りすぎない:通知が多いアプリはまとめて要約される対象になり、個々の通知の意味が薄まります
Appleがニュース見出しの要約を一時停止した経緯が示すように、短い文ほど言い換えで意味が変わりやすいものです。誤解されると困る内容(料金、障害、安全に関わる案内)ほど、言い換えの余地が少ない具体的な文にしておきます。
メールの種類別のポイント
| 種類 | AIに判定されやすいこと | 特に整えたい点 |
|---|---|---|
| メルマガ・キャンペーン | 宣伝として仕分け、関連度で並び替え | 冒頭に特典・期限・コード。画像内の情報をテキスト化。1通1テーマ |
| 取引メール(注文・請求・予約) | 購入・取引として分類、要約カード化 | 注文番号・金額・日付をテキストで明記。宣伝を混ぜない。送信元を分ける |
| B2B営業・提案メール | 優先度の高・低判定 | 冒頭で用件と依頼事項。相手の業務との関係を1文で。返信期限を明記 |
| 重要なお知らせ(価格改定・規約変更・障害) | 宣伝と誤認、要約で条件が落ちる | 件名に「重要」を乱用しない。変更内容・適用日・影響範囲を冒頭に |
| アプリ通知・SMS | まとめて要約、言い換え | 1通知1事実。主語・数字の単位を省かない。肯定形で書く |
検証——「AIに要約させてみる」テストを配信前の工程にする
受信箱AEOの良いところは、配信前に自分で検証できることです。下書きを生成AI(Gemini、Copilot、ChatGPT、Claudeなど)に貼り付けて、次のように聞いてみてください。
以下は企業から顧客に送るメールです。
受信者の立場で、次の4点を答えてください。
1. このメールを1行(40字以内)で要約してください
2. 受信者がとるべき行動と、その期限は何ですか
3. このメールの優先度を「高・中・低」で判定し、理由を1文で述べてください
4. このメールは「宣伝」「取引連絡」「個別の連絡」のどれに分類されますか
---
(件名)
(本文)
結果を見て、次のいずれかに当てはまれば修正します。
- 1行要約に、いちばん伝えたい事実(特典・期限・依頼)が入っていない
- 行動や期限が「不明」「特になし」と答えられる
- 優先度が意図より低い、または分類が意図と違う(取引連絡なのに「宣伝」など)
可能であれば、Gmail・Outlookのテスト用アカウントに実際に送り、要約や分類の表示も確認します。件名のA/Bテストに加えて「要約のA/Bテスト」を配信工程に組み込むのが、受信箱AEOの基本の型です。
受信箱AEOチェックリスト
| 領域 | 確認項目 | 優先度 |
|---|---|---|
| 冒頭 | 冒頭1〜2文に「誰に・何が・いつまでに・何をしてほしいか」が書かれている | 高 |
| 冒頭 | 挨拶・近況が用件より前に来ていない | 高 |
| 一致 | 件名・プレヘッダー・冒頭3行が同じ用件を指している | 高 |
| 事実 | 期限が日付(曜日・時刻)で書かれている | 高 |
| 事実 | 画像内の重要情報(価格・条件・日付)が本文テキストにもある | 高 |
| 目的 | 行動を求める内容は1通につき1つに絞られている | 中 |
| 目的 | 重要なお知らせが宣伝メールに混ざっていない | 高 |
| 信頼 | SPF・DKIM・DMARCが設定されている | 高 |
| 信頼 | ワンクリックで配信停止できる | 高 |
| 信頼 | 宣伝用と取引用で送信元が分かれている | 中 |
| 関係 | 長期間反応のない宛先への配信を見直している | 中 |
| 通知 | プッシュ通知が1通知1事実で、主語と単位を省いていない | 中 |
| 検証 | 配信前にAIで1行要約・行動・優先度・分類をテストしている | 高 |
よくある質問
Q1. 日本語のメールでもAI要約はされていますか?
機能ごとに対応言語や提供範囲が異なり、順次拡大しています。たとえばGmailの要約カードは英語メールから展開されました。ただし、受信者が自分でAIに「このメールを要約して」と頼む使い方は言語を問わず広がっています。自動要約の対応状況を待つより、要約されても困らないメールに先に変えておくほうが確実です。
Q2. 件名の工夫(開封率対策)はもう意味がないのですか?
意味はあります。ただし、件名で情報を伏せて開封を促す手法は、本文の要約が先に表示される環境では効きにくくなります。件名は「用件と期限を正直に伝える」方向に寄せ、本文冒頭と一致させるのがおすすめです。
Q3. 要約で用件がわかってしまったら、開封されなくなりませんか?
開封率は下がる可能性があります。しかし、目的は開封ではなく行動(申込・購入・返信)です。用件が伝わったうえで行動してもらえれば成果になります。計測の軸を、開封率からクリック率・コンバージョン・返信率に移すことをおすすめします。
Q4. HTMLメールのデザインはやめたほうがよいですか?
やめる必要はありません。デザインは残したまま、重要な事実をテキストで冒頭に置くことが大切です。画像だけで構成されたメールは、AIにも、画像を表示しない受信環境にも内容が伝わりにくくなります。
Q5. 中小企業はまず何から始めればよいですか?
次に送るメルマガ1本で、①冒頭1文の書き換え、②画像内情報のテキスト化、③AIでの要約テストの3つを試してください。追加の費用はかからず、効果も比べやすい取り組みです。そのうえで、送信ドメイン認証や送信元の分離を、配信サービスの設定とあわせて見直します。
まとめ——「AIの1行」で用件が伝わるメールにする
受信箱AEOは、AEOのフロンティアの中でもっとも身近で、もっとも早く試せる面です。Webページと違い、毎日送っているメール1通から改善できます。
- 受信者は本文の前にAIの要約を見ている。成果を決めるのは件名のテクニックではなく、「AIが1行に要約したときに何が残るか」です。
- 冒頭・テキスト・1通1目的。用件を冒頭に置き、重要な事実をテキストで書き、1通で求める行動を1つに絞ることが、誤要約と後回しを防ぐ基本です。
- 配信前に「AIに要約させる」テストを。件名のA/Bテストと同じように、要約・優先度・分類を配信前に確認する工程を加えましょう。
AIに先に読まれることを前提に、「AIが言い直しても、用件と期限と行動が残るメール」を書く。それが、届いた後の受信箱で選ばれるための条件です。
関連記事
- AEOの”足もと”フロンティア(近くで探す・ローカル軸)
- AEOの”相手の社内”フロンティア(購買側の社内AI軸)
- AEOの”滞在中”フロンティア(滞在中軸)
- AEOの”定期実行”フロンティア(定期実行軸)
- AEOの”速報”フロンティア(速報軸)
- AEOの”記憶”フロンティア(記憶軸)
- AEOの”越境”フロンティア(越境・空間軸)
参考リンク
- Google Workspace Updates:Gemini summary cards in the Gmail app
- Microsoft サポート:Prioritize my inbox
- emailexpert:Gmail’s Promotions Tab Gets “Most Relevant” Sorting; New Purchases View Rolls Out
- 9to5Mac:Here’s what Apple Intelligence summarized news notifications look like on iOS 26
- AppleInsider:Apple brings back notification summaries for news in iOS 26
- Google:メール送信者のガイドライン
免責事項:本記事は2026年10月時点の公開情報に基づいて作成しています。各メールサービス・OSのAI機能は、提供範囲・対応言語・仕様が頻繁に変わります。導入や設定にあたっては、各社の公式情報と、ご利用の配信サービスの最新ドキュメントをご確認ください。本記事は法的助言を目的としたものではありません。

コメント