HTMLメールのデザインは、Webサイトのデザインとは前提が異なります。同じ感覚で設計すると、実装の段階で「この構成は再現できない」という問題が起こります。
この記事では、HTMLメール特有の制約を項目別に整理し、それを前提にした設計手順、デザインデータから実装へ渡す際の取り決めまでを解説します。
結論として、HTMLメールのデザインはWebデザインに機能を足すのではなく、制約を引き算して設計します。
Webページで使える表現の多くは、メールでは使えません。使えないものを把握したうえで、残った表現の中で成立する設計を組み立てる。この順序で進めないと、実装の段階で作り直しになります。
また、制約は「実装担当が知っていればよい」ものではありません。デザインの段階で制約を織り込んでおかないと、そもそも再現できない構成が生まれます。
最も大きな違いは、表示環境の統一性です。
| Webページ | HTMLメール | |
|---|---|---|
| 表示環境 | 主要ブラウザで仕様がほぼ統一 | メールクライアントごとに解釈が異なる |
| レイアウト | Flexbox・Gridが標準 | tableが基本 |
| CSSの記述 | 外部ファイルにまとめる | 各要素に直接書く |
| フォント | Webフォントが使える | 端末標準のフォントが基本 |
| 横幅 | 画面幅に応じて可変 | 600〜700px程度の固定が基本 |
| 確認方法 | ブラウザで確認できる | 実際に送信して確認する |
HTMLメールの横幅は600〜700px程度に設定されることが一般的です。これはPCのメールソフトのプレビュー領域が、ブラウザの表示領域より狭いためです。
Webページのように画面幅いっぱいに広げる設計は、メールでは成立しません。最初から限られた幅の中で情報を組み立てる必要があります。
具体的にどの表現が使えないのか、メールクライアント別のHTML／CSS対応表であるCan I Emailの値を参照して整理します（2026年9月5日参照）。
display:flexの対応状況は約78.05%（一部対応を含めると82.93%）です。
出典：Can I Email「display:flex」
https://www.caniemail.com/features/css-display-flex/
2割弱の環境では意図どおりに表示されません。横並びのレイアウトはtableのセル分割で組むのが確実です。
デザイン上の意味としては、要素を自由な位置に配置する設計ができないということです。重ね合わせ、絶対配置、複雑な回り込みは避け、上から順に積む構成を基本にします。
<style>要素の対応状況は約63.04%（一部対応を含めると78.26%）です。
出典：Can I Email「<style> element」
https://www.caniemail.com/features/html-style/
削除される環境があるため、崩れて困る指定は各要素に直接書きます。これは実装上の制約ですが、デザイン側にも影響します。擬似要素やホバー時の変化など、要素に直接書けない表現は使えません。
@font-faceによるWebフォントの対応状況は約21.95%（一部対応を含めると24.39%）です。
出典：Can I Email「@font-face」
https://www.caniemail.com/features/css-at-font-face/
大半の環境では読み込まれません。ブランド指定のフォントをそのまま使うことはできないと考えてください。
対応としては、端末に標準で入っているフォントを複数指定し、どれかが適用される形にします。デザインの段階では、どのフォントに置き換わっても成立する設計にしておく必要があります。
画像の表示をブロックしている環境があります。この場合、画像の領域は空白または代替テキストで表示されます。
デザイン上の対応は2点です。
以上を踏まえた設計の順序です。
限られた幅と、崩れる可能性のある環境を前提にすると、すべての情報を同じ強さで見せることはできません。
最初に、読者に必ず伝えたい要素を1つ決めます。次に、それを支える情報を2〜3点まで絞ります。この段階で情報量が多い場合は、リンク先に送る前提で整理します。
横並びのレイアウトは、環境によって縦積みに分解されます。分解されても意味が通る順序で組んでおけば、崩れても情報は伝わります。
逆に、左右の要素が対になっていて片方だけでは意味をなさない構成は、分解された時点で破綻します。
配色で注意するのは、背景色が反映されない環境を想定することです。背景色の上に白文字を置く設計は、背景が反映されないと白地に白文字になり読めなくなります。
特にCTAボタンは、この問題が起きると機能しません。背景色と文字色の組み合わせは、背景が失われた場合を想定して選びます。
CTAは画像ではなく、背景色を指定した領域にテキストリンクを置く形で実装します。デザインの段階から、画像で作らない前提で設計してください。
スマートフォンでのタップを考慮し、十分な大きさを確保します。
近年の受信環境では、ダークモードの利用が一般的になっています。この場合、指定した背景色と文字色が自動的に変換されることがあります。
| 問題 | 原因 |
|---|---|
| 濃色のロゴが見えなくなる | 白背景を前提にした透過画像が、暗い背景に置かれる |
| 薄いグレーの文字が読めない | 白背景前提の配色が、暗い背景では低コントラストになる |
| 意図しない色に変換される | 環境が自動的に色を反転させる |
| 枠線が消える | 背景との差がなくなる |
ダークモードでの見え方は、通常表示とは別に確認が必要です。同じ環境の通常表示とダークモードを対で確認してください。
デザインを実装担当に渡す際、データだけでは判断できない情報があります。次を明記してください。
| 項目 | 内容 |
|---|---|
| 全体の横幅 | 600px、700pxなど |
| 画像として書き出す範囲 | どこを画像にし、どこをテキストにするか |
| フォントの代替指定 | デザインで使ったフォントが使えない場合の代替 |
| リンク箇所 | クリックできる範囲と遷移先 |
| スマートフォンでの想定 | 縦積みになった際の順序 |
| ダークモードの想定 | 反転して困る箇所 |
最も判断が必要なのがこれです。デザインデータ上では区別がつかないため、明示的に指定します。
判断の基準は次のとおりです。
見出しを画像で作ると、画像がブロックされた環境で構造が失われます。また文字が画像内にあると、読者が拡大や選択をできません。
デザインデータのレイヤーは、実装の単位に合わせて整理しておくと渡しやすくなります。上から順に積む構造でまとめ、書き出す画像を明確にしておきます。
実装が完了したら、複数の環境で表示を確認します。デザインの意図が再現されているかは、実際に送信しなければ分かりません。
デザイン担当の手元にある環境は、通常1〜2種類です。そこで意図どおりに見えていても、それは全体のごく一部を見たにすぎません。
この工程を省くと、意図と異なる状態で配信されることになります。検証環境を持つ制作会社に依頼するか、検証サービスを利用する方法があります。
同じようには作れません。メールクライアントはHTMLとCSSの解釈が製品ごとに異なるため、Webページで使える表現の多くが使えません。レイアウトはtableが基本になり、Flexboxは対応が約78.05%にとどまります。またWebフォントは対応が約21.95%で大半の環境では読み込まれません。Webデザインに機能を足すのではなく、制約を引き算して設計する順序が必要です。
600〜700px程度が一般的です。PCのメールソフトのプレビュー領域がブラウザの表示領域より狭いためです。Webページのように画面幅いっぱいに広げる設計は成立しません。最初から限られた幅の中で情報を組み立てる必要があります。
そのまま使うことはできません。Can I Emailによれば@font-faceの対応状況は約21.95%（一部対応を含めると24.39%）で、大半の環境では読み込まれず代替フォントに置き換わります。端末に標準で入っているフォントを複数指定し、どれに置き換わっても成立するデザインにしておく必要があります。
設計の段階で、背景色と文字色が反転する可能性を想定してください。よく起きる問題は、白背景を前提にした透過ロゴが暗い背景で見えなくなること、薄いグレーの文字が読めなくなること、枠線が背景と同化することです。ロゴには背景色を持たせる、文字色は十分なコントラストを確保する、枠線に頼らず背景色の差で区切る、といった対応があります。確認は通常表示とダークモードを対で行ってください。
全体の横幅、画像として書き出す範囲、フォントの代替指定、リンク箇所と遷移先、スマートフォンで縦積みになった際の順序、ダークモードで反転して困る箇所を明記してください。特に画像とテキストの切り分けはデザインデータ上では区別がつかないため、明示的な指定が必要です。見出しやCTAの文言を画像で作ると、画像がブロックされた環境で情報が失われます。
HTMLメールのデザインにおける要点は次のとおりです。
HTMLメールの制作、プロに任せませんか
B.A.Dは約30通りのメーラー×OS環境で表示検証済みのHTMLメールを、
デザインからコーディング・配信・分析改善までワンストップで提供しています。