テキストだけのメルマガはもったいない｜HTMLメールをAIで

「メルマガをHTML化したいが、デザインの知識がある社員がいない」「制作会社に頼むほどの予算はないし、崩れたメールを送るくらいなら今のテキストのままでいい」——メール担当者からよく聞く悩みです。しかしテキストのままでいることには、見た目以上に大きな見えないコストがあります。テキストメールでは開封率がほぼ計測できず、読まれているかどうか分からないまま送り続けることになるからです。生成AIがHTMLのコードを書けるようになった今、デザイン知識の壁はかつてより大きく下がりました。本記事では、デザイナー不在の少人数チームが、AIでHTMLメールを作り、表示崩れなく届けるまでの手順を解説します。

テキストだけのメルマガが「もったいない」本当の理由

テキストメールの弱点というと、文字だけで地味、ボタンが置けない、といった見た目の話を思い浮かべがちです。しかし本質的な問題は別にあります。開封率が計測できないことです。メールの開封計測は、HTMLメールに埋め込んだ極小の計測用画像（トラッキングピクセル）が読み込まれたかどうかで判定する仕組みのため、画像を埋め込めないテキストメールでは、原則として開封を測る手段がありません。

開封率が見えないと何が起きるか。件名を変えても効果が分からない、配信時間を変えても差が測れない、読まれていない層を特定できない——つまり改善のサイクルそのものが回せません。クリック率だけは本文中のURLで測れますが、その手前の「開封されたか」がブラックボックスのままでは、打ち手の検証は半分しかできないのです。テキストだけのメルマガが「もったいない」のは、装飾の問題ではなく、この計測とデータの問題です。

HTMLメールとテキストメールの違いを整理する

まず両者の違いを一覧で押さえておきましょう。どちらが優れているかではなく、それぞれの特性を知ったうえで使い分けるための整理です。

比較項目	HTMLメール	テキストメール
開封率の計測	計測できる	原則計測できない
装飾・画像	文字装飾・画像・ボタンを使える	文字と記号のみ
制作の手間	コーディングやエディタが必要	すぐに書ける
表示の安定性	受信環境によって崩れることがある	環境差がほとんどない
迷惑メール判定	作りが悪いと不利になることがある	比較的影響が少ない

なお、一般社団法人日本ビジネスメール協会の「ビジネスメール実態調査2023」によると、ビジネスメールでのテキスト形式の利用は6割程度とされています。日常の1対1のやり取りはテキストで十分ですが、マーケティング目的の一斉配信は、計測できることが改善の生命線になります。個人のメールはテキスト、マーケ配信はHTMLという役割分担で考えるのが実務的です。

効果の実像：HTMLにすれば必ず勝てるわけではない

誠実に書いておくと、HTMLメールにした瞬間に開封率やクリック率が跳ね上がる、という単純な話ではありません。BtoBメルマガの公開事例でも、HTMLメールとテキスト風のメールでクリック率を比較したところ、どちらが効果的とは言い切れない結果だったという報告があります。過度に装飾されたメールはかえって広告と認識され、読み飛ばされやすいという指摘もあります。

それでもHTML化をすすめる理由は、繰り返しになりますが計測です。開封率が測れるようになって初めて、件名・配信時間・セグメントの検証が可能になり、自社の読者にとっての正解を探せるようになります。デザインに凝る必要はありません。むしろBtoBでは、テキストメールのような見た目のシンプルなHTMLメール——ハイブリッド型と呼ばれる形——が現実解になることも多くあります。派手さではなく、データが取れる器に載せ替えることが目的だと考えてください。

数字が取れると、意思決定はこう変わります。たとえば開封率が20%から25%に上がれば、同じリストで読者との接点が1.25倍になったと定量的に言えます。経営層への報告も「メルマガを頑張っています」から「件名の改善で開封が5ポイント上がりました」に変わり、施策への投資判断や人員の確保を数字で交渉できるようになります。テキストメールのままでは、この会話がそもそも成立しません。メルマガを業務として続ける以上、成果を数字で語れる状態にしておくことは、施策のためだけでなく、担当者自身の評価を守る意味でも重要です。

生成AIでHTMLメール制作のハードルが下がった

これまでHTMLメールの内製を阻んできたのは、コーディングの専門性でした。ここが生成AIで大きく変わっています。チャット型のAIに要件を伝えてHTMLメールのコードを書かせ、コーディング知識なしで自作する方法が広く紹介されるようになり、メール配信ツール各社もAIによる文面生成やテンプレート作成の機能を相次いで打ち出しています。コードを書けない担当者でも、対話でHTMLメールを組み立てられる環境が整ってきました。

ただし、落とし穴もあります。AIは指示がなければWebサイト用のモダンなHTMLを書きがちで、それをそのままメールで送ると、受信環境によっては盛大に崩れます。メールのHTMLはWebのHTMLとは別物で、古い作法に合わせる必要があるからです。つまり成否を分けるのは、メール特有の制約をプロンプトで正しく指定できるかです。次のセクションから、その具体的な手順を追っていきます。

直近の動向として特徴的なのは、コードを書かせる以外の入り口も増えたことです。参考にしたいメールのスクリーンショットをAIに見せてレイアウトの構造を言語化させてから組み立てる方法や、メール配信ツール側に組み込まれたAIアシスタントで件名・本文・テンプレートを生成する方法が紹介されています。入り口は増えましたが、どの方法でも共通するのは、最後に必ず実機での表示確認を挟むことです。生成の速さに引っ張られて検証を省くと、この後説明する崩れの落とし穴にそのままはまります。速く作れるようになった分の時間を、確認に回すのが正しい配分です。

全体の流れ：AIでHTMLメールを作る5つの手順

作業の全体像を先に示します。この5ステップを毎号のルーティンにすれば、制作からチェックまでを少人数で回せます。

ポイントは、生成が全体の2割で、検証が8割ということです。AIのおかげで「作る」工程は数分になりましたが、「崩れずに届くか」の確認は人の仕事として残ります。以降、各手順を順に見ていきます。

手順1：目的と構成を先に固める

コードを書かせる前に、そのメールで達成したいことを1つに絞ります。セミナー申込、資料ダウンロード、新機能の告知——ゴールが複数あるとボタンが増え、デザインが複雑になり、崩れるリスクとクリックの分散を同時に招きます。1通1ゴール・ボタン1つが、内製HTMLメールの基本形です。

構成もシンプルが正解です。調査データでは、メルマガ購読者の約8割は1通を読むのにかける時間が1分未満とされています。ヘッダー（ロゴ）、見出し、リード文、ボタン、フッター（社名・住所・配信解除リンクなどの法定表示）という5ブロックで十分です。この段階でAIに「この目的でメールの構成案を3パターン出して」と相談し、たたき台を比較してから決めると、後工程の手戻りが減ります。

構成段階でもう一つ決めておきたいのが、プリヘッダー（プレヘッダー）です。受信ボックスで件名の隣や下に表示される短い導入文のことで、設定しないと「画像が表示されない場合はこちら」のような機械的な文言が最初に見えてしまうことがあります。件名で興味を引き、プリヘッダーで開封をあと押しする——この2つはセットで設計するものです。AIに件名案とプリヘッダー案をセットで複数出させ、組み合わせで選ぶやり方が効率的です。開封率が測れるようになれば、この組み合わせの良し悪しも次号から数字で検証できます。

手順2：AIにHTMLコードを書かせる

構成が決まったら、AIにコードを書かせます。ここで前述の「メール特有の制約」を必ず指定します。具体的には、幅600px程度・1カラム・テーブルレイアウト・CSSはインライン記述・画像に依存しない、という条件です。プロンプト例を示します。

あなたはHTMLメールのコーダーです。以下の条件でメルマガのHTMLを書いてください。
・目的：新機能セミナーの告知（ボタンのクリックでLPへ誘導）
・構成：ヘッダーロゴ／見出し／リード文／ボタン1つ／フッター（社名・住所・配信解除リンク）
・幅600px・1カラム・テーブルレイアウト・CSSはすべてインラインで記述
・画像に頼らず、本文は必ずテキストで組む
・フォントはデバイス標準のものを使い、背景色と文字色のコントラストを確保
・HTMLコードだけを出力してください

生成されたコードは、配信ツールのHTMLエディタに貼り付ければそのまま使えます。文言の差し替えや色の変更も「ボタンの文言を◯◯に変えて」「ブランドカラーの#◯◯◯◯◯◯に合わせて」と対話で指示すれば済みます。重要なのは、コードが読めなくても直せるということです。表示が崩れた場合も、どの環境でどう崩れたかをAIに伝えれば、修正版を出させることができます。

部品づくりで質問が多いのがボタンです。ボタンを画像で作ると、受信側で画像がブロックされたときに押し場所そのものが消えてしまいます。HTMLとインラインCSSの背景色で描く画像を使わないボタンにしておけば、画像がブロックされても表示され、文言も確実に読めます。AIへの指示に「ボタンは画像を使わずHTMLとインラインCSSで作る」という一文を加えておきましょう。あわせて、使う画像すべてにalt（代替テキスト）を指定させると、画像オフ環境でも内容が伝わり、後述する迷惑メール対策の観点でも有利になります。

手順3：メールHTML特有の制約を知っておく

なぜ先ほどの制約が必要なのか、背景を知っておくと応用が利きます。メールクライアントのHTML描画は、Webブラウザに比べて大きく遅れており、しかも環境ごとにばらばらです。CSSの一部が無視される環境や、独自の描画エンジンを使う環境があり、たとえばOutlookはメディアクエリを読み込まないと指摘されています。Webでは当たり前のレイアウト手法が通用しないため、古典的なテーブルレイアウトとインラインCSSが今なお定石とされているのです。

そして押さえておくべき現実は、絶対に崩れない作り方は存在しないということです。実務者の解説でも、こう設計すれば絶対崩れないという方法は現段階で確立されていないとされています。だからこそ、凝った多段レイアウトを避けてシンプルに作り、テスト送信で確認する工程が手順に組み込まれています。構造が単純であるほど、崩れる箇所そのものが減る——これが内製HTMLメールの最大の防御策です。

検証の助けになるのが、複数のメールクライアントでの表示を一括確認できるプレビューサービスや、配信ツールに内蔵されたプレビュー機能です。専用の確認ツールが実務で使われていると紹介されていますが、まずは自社の配信ツールのプレビューと、社内にある実環境——WindowsのOutlook、ブラウザのGmail、iPhoneの標準メール——への手動テスト送信だけでも、主要な崩れは検出できます。チェックする環境の組み合わせをあらかじめ固定しておけば、毎号の検証は数分で終わる定型作業になります。

手順4：スマホ表示を必ず確認する

表示確認の最優先はスマートフォンです。調査では、メルマガをスマートフォンで読む人の割合は5割前後にのぼるとされています。読者の半分がスマホ画面で見る以上、PCで整っていてもスマホで読みにくければ半分の読者を失います。幅600px・1カラムを守っていれば大枠は破綻しにくいものの、文字サイズとボタンの押しやすさは必ず実機で確かめたいポイントです。

確認は難しくありません。自分のスマホにテスト送信し、親指で操作してみるだけです。本文の文字が小さすぎないか、ボタンは指で押せる大きさか（高さの目安は44px程度）、リンク同士が近すぎて誤タップしないか、横スクロールが発生していないか。この4点をチェックリストにして毎号確認します。画像の幅が固定されていて画面からはみ出すのは典型的な崩れ方なので、画像には最大幅100%の指定を入れるようAIに指示しておくと安全です。

手順5：ダークモード表示を確認する

見落とされがちなのがダークモードです。海外のメール調査会社Pathwireの調査では、44%のマーケターがダークモードを考慮したメール作成を行っており、対応予定を含めると72%が注目しているとされています。受信側の設定次第で、メールの背景や文字色が自動反転されることがあり、その変換ロジックはメールクライアントごとにばらばらです。制作側で完全には制御できません。

典型的な事故は2つあります。1つは、白背景前提のJPEGロゴが、暗くなった背景の上で白い箱のまま浮いてしまうケース。もう1つは、色の自動反転で文字と背景のコントラストが崩れ、読めなくなるケースです。対策としては、ロゴを背景透過のPNGにする、極端に白・黒に依存した配色を避ける、そして自分の端末をダークモードに切り替えてテスト送信を確認する、という3点が現実的です。海外の解説では、メディアクエリを読まないOutlook向けの対策として、黒いロゴ文字に半透明の白い縁取りを加えておく手法も紹介されています。CSSでの制御に限界がある以上、画像側にあらかじめ工夫を仕込んでおくという発想です。ライトとダークの両方で読めることを合格ラインにすると覚えておきましょう。

表示崩れを招くNGパターン

ここまでの内容を裏返すと、やってはいけない作り方が見えてきます。制作前にチームで共有しておきたいNG集です。

• Webサイト用のモダンなHTMLをそのまま使う：CSSが無視される環境で全体のレイアウトが崩壊する
• 多段カラムや複雑なレイアウトを組む：環境差が出やすく、スマホでは読みにくくなる
• 本文全体を1枚の画像にする：画像非表示の設定では何も伝わらず、迷惑メール判定でも不利になる
• Webフォントや動画など対応環境の狭い要素を使う：表示されない受信者が一定数出る

共通する考え方は、メールは「いちばん古い環境に合わせて作る」ということです。最新のブラウザに合わせるWeb制作とは、発想が逆になります。また、どうしても崩れる環境への逃げ道として、メール冒頭に「表示が崩れる場合はこちら」というWebブラウザ表示用のリンクを用意しておく方法も、多くの配信ツールが標準機能として備えています。

迷惑メール判定を招く落とし穴

デザインがきれいでも、迷惑メールフォルダに入ってしまえば意味がありません。HTMLメールで特に注意すべきは、画像とテキストのバランスです。本文のほとんどを画像で構成したメールは、フィルタが内容を読み取れないため、内容を隠した怪しいメールとして警戒されやすいとされています。伝えたい内容は必ずテキストとして本文に入れ、画像は補助に徹させるのが鉄則です。

• HTMLメールは、テキスト版を同梱するマルチパート形式での配信が推奨される（多くの配信ツールが自動生成に対応）
• 本文の大半を画像にせず、伝えたい内容は必ずテキストとして本文に入れる
• 画像にはaltテキストを設定し、画像非表示でも内容が伝わるようにする
• 送信ドメイン認証など技術面の到達率対策は別領域として、専門の解説（メール到達率の改善）で確認する

もう一つの基本がマルチパート配信です。1通のメールにHTML版とテキスト版の両方を格納して送る方式で、受信環境がHTMLを表示できない場合はテキスト版が表示されます。テキスト版が同梱されていること自体が、フィルタへの信頼のシグナルになるという解説もあります。配信ツールの設定でマルチパートが有効になっているか、テキスト版の中身がHTML版と一致しているかを、配信前の確認項目に加えてください。

内容面の注意も添えておきます。煽り文句の乱発や記号の連打、極端な文字装飾は、受信者の印象を損なうだけでなく、フィルタにも警戒されやすいとされています。本文中のリンクに短縮URLを多用する構成も、リンク先を隠す手口と誤認されやすいため避けるのが無難です。判定基準の詳細は各社非公開のため断定はできませんが、受信者に誠実な作りは、フィルタにも好かれると考えておけば大きくは外しません。HTMLメールだからと装飾を盛るほど疑われやすくなる——この逆説を覚えておくと、シンプル設計の価値が腑に落ちるはずです。

配信前デザインチェックリスト

ここまでの確認ポイントを、毎号使えるチェックリストにまとめます。配信ボタンを押す前に、上から順に確認してください。

• スマホ実機で、文字サイズ・ボタンの押しやすさ・横スクロールの有無を確認した
• ダークモードで、ロゴの白浮きや文字のつぶれがないかを確認した
• 画像を非表示にしても内容が伝わる（altテキストとテキスト本文がある）
• テキスト版（マルチパート）が同梱され、内容がHTML版と一致している
• 配信解除リンクと送信者情報がフッターに入っている
• 主要なメールクライアントにテスト送信して崩れを確認した

チェックの一部はAIにも任せられます。生成したHTMLコードを渡して「メールクライアントで崩れやすい書き方が含まれていないか点検して」と依頼すれば、インライン化漏れや幅指定の抜けといった機械的な見落としを拾ってくれます。ただし最終判断は実機での見た目です。コードのチェックはAI、実表示のチェックは人、という分担が安定します。

テンプレート化して2通目以降を速くする

1通目が完成したら、それを使い捨てにせず、テンプレートとして整備します。ロゴ・配色・フッター（社名・住所・配信解除リンクといった法定表示を含む）を固定部分として確定し、見出し・本文・ボタンの文言だけを差し替える構造にしておけば、2通目以降の制作は文言の流し込みだけになります。固定部分は一度検証を通してあるため、毎号の表示確認も差し替え部分に集中でき、チェックの負担が大きく下がります。作るたびにゼロから生成するのではなく、検証済みの型を回す——内製を無理なく続ける最大のコツはこれです。

テンプレートの運用もAIと相性が良い領域です。ベースのHTMLを渡して「構造は変えずに、本文とボタン文言だけをこの内容に差し替えて」と指示すれば、レイアウトを壊さずに量産できます。プロンプトとテンプレートをセットで残しておけば、担当者が交代しても品質を保てるため、属人化の防止にもつながります。セミナー案内用、新機能のお知らせ用、月次ニュース用など、用途別に2〜3種類の型を育てていくと、デザインの一貫性が生まれ、読者にとっても「いつものメール」として認識されやすくなります。

配信後：数字で改善を回す

HTML化の果実を受け取るのはここからです。開封率で件名と配信時間を、クリック率で本文とボタンを検証できるようになります。前述のBtoB事例の結論も、どちらの形式が正解かではなく、読者にとって役立つ内容を自社のデータで検証し続けることが重要だというものでした。最初の数号は数字の絶対値に一喜一憂せず、自社の基準値づくりと考えるのがよいでしょう。

なお、開封率は万能の指標ではありません。近年は受信側のプライバシー保護機能の影響で開封判定に誤差が乗ることが知られており、絶対値よりも同条件での推移や比較で見るのが実務的です。件名のABテスト案の量産や、開封・クリックデータからの改善仮説の整理は、AIが得意とするところです。数字が取れる器に載せ替え、AIと一緒に検証を回す——テキストだけのメルマガからの卒業は、この循環を手に入れることを意味します。

検証を始めるときは、一度に変える要素を1つに絞るのが原則です。件名だけを変えた2パターンをリストの一部に送り、開封率の高いほうを残りに送る——多くの配信ツールが備えるABテスト機能で実現できます。判定を急ぎすぎないことも大切で、配信直後の数時間だけでなく翌日までの数字で比較すると、誤差に振り回されにくくなります。テスト対象のリストは無作為に分け、差が偶然でないと言える程度の件数を確保することも忘れずに。テスト結果は必ず記録に残し、「自社の読者は数字入りの件名に反応する」「火曜午前の開封が高い」といった知見を積み上げていく。この蓄積こそが、テンプレートと並ぶもう一つの資産になります。

導入時のつまずきと乗り越え方

最後に、社内でHTML化を進めるときにつまずきやすいポイントを押さえておきます。よくあるのが「うちの読者はテキスト派だから」という社内の声です。これは前のセクションで説明したマルチパート配信でほぼ解決します。HTML版とテキスト版を同梱すれば、受信環境や設定に応じて読める形が届くため、どちらかの読者を切り捨てる必要はありません。また「HTMLメールは迷惑がられるのでは」という不安に対しては、崩れない・重すぎない・解除しやすいという基本を守った公式配信であれば過度に恐れる必要はない、というのが各社の解説に共通する見解です。

もう一つのつまずきが、最初の1通に時間をかけすぎて息切れするパターンです。本記事の手順はあくまで最初の1通のためのもので、2通目からはテンプレートの差し替えに移行します。「初回だけ丁寧に、以降は型で回す」という時間配分をチームで共有しておくと、月1回の配信でも無理なく続きます。完璧なデザインを目指すより、計測できる状態で送り続けることを優先する。データが貯まれば、直すべき箇所はデータが教えてくれます。順番を間違えないことが、内製定着の分かれ目です。

まとめ

テキストだけのメルマガがもったいない理由は、装飾ではなく開封率という改善の基礎データを取り逃していることにあります。生成AIがコードを書ける今、HTMLメールの内製は現実的な選択肢になりました。成功の鍵は、幅600px・1カラム・テーブルレイアウト・インラインCSSというメール特有の制約を指定して生成し、スマホとダークモードで実機確認し、マルチパート配信で迷惑メール判定を避けるという手順を崩さないことです。デザインは凝らなくて構いません。まずは次号のメルマガを、この記事の手順でシンプルなHTML版に載せ替えるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。