メールが崩れて届く原因と対策｜端末差を前提に作る

社内で回覧したときは問題なかった。ところが配信の翌日、顧客から「レイアウトが崩れて読めない」と連絡が来る。HTMLメールの運用でよく起きる事故です。原因は作り方が雑だったからではなく、受け取る側のソフトが違うことにあります。Webページはブラウザが表示しますが、メールは相手のメールソフトが表示します。そしてWindows版のOutlookは、ブラウザではなくWordのHTML解析・描画エンジンでメール本文を表示すると、Microsoftが公式に説明しています。Wordのエンジンが対応するのはHTML 4.01とCSS Level 1の一部にとどまり、非対応のプロパティは公式に一覧化されています。つまり崩れは偶然ではなく、どの指定が無視されるかは事前に調べられる。本記事では原因を描画エンジンとCSSの対応差から整理し、ダークモードでの色の反転、画像がブロックされる前提の作り方、スマホでの1カラム設計、そして配信前の確認手順までを、実装と検証に絞って扱います。

症状から原因を切り分ける

最初にやるべきは、崩れの再現です。社内の検証で差が出ないのは、検証環境が揃いすぎているからです。同じOS、同じバージョンのメールソフト、同じ表示設定、同じ画面幅。一方、受け取る側の環境は分散しています。誰の環境で崩れたのかを特定できなければ、修正のしようがありません。

問い合わせを受けたら、聞くべき項目は4つです。使っているメールソフトの名前、PCかスマホか、OS、そして画面の配色がダークモードかどうか。あわせてスクリーンショットをもらいます。「表示が変です」という報告だけでは、文字の大きさの話なのか、レイアウトの話なのか、色の話なのかも判別できません。

症状	考えられる原因	先に確認する場所
背景の画像やグラデーションが消える	background-image が非対応の環境	Windows版Outlookでの表示
要素が横並びにならず縦に積まれる	float や position が効いていない	テーブルで組んであるか
本文の幅がPCで横に伸びきる	max-width が非対応	テーブルに固定幅の指定があるか
文字だけ異様に大きい・小さい	スマホ側の自動拡大、フォントの置き換え	本文の文字サイズ指定
ロゴや一部の画像が見えない	ダークモードでの色の反転、画像のブロック	受信者の配色設定
ボタンが押せない・枠だけになる	button要素やCSSの角丸が非対応	リンクの実装方法

この表の右列を見ると分かるとおり、確認先はほぼ2つに集約されます。Windows版Outlookでの表示と、受信者側の設定です。まずこの2点を潰してから細部に入ってください。

なお、すべてのメールソフトに対応させるのは不可能だとされています。実務では対象を絞り、Gmail・Yahoo!メール・Outlookを優先する整理が一般的です。BtoBの配信であれば、宛先の多くが業務用のOutlookである前提で作るほうが実態に合います。

崩れの正体は描画エンジンの違い

Microsoftの公式ドキュメントは、Outlook 2007がHTML形式の本文を表示する際にWord 2007のHTML解析・描画エンジンを使うと明記しています。つまりメール本文は、ブラウザではなくワープロの機能で描画されます。この設計は以降のWindows版Outlookにも引き継がれてきました。

同じ資料によると、Word 2007が対応するのはHTML 4.01仕様とInternet Explorer 6.0のHTML仕様の一部、そしてCSS Level 1仕様の一部です。ブラウザが毎年新しい仕様に追随するのに対し、こちらは追随しません。だからHTMLメールの議論に、flexboxやgridが出てこないのです。

さらに細かい落とし穴があります。公式の一覧では、CSSの対応度が要素ごとに3段階で示されています。もっとも広いのがFULL、divとpは中間のCOREEXTENDED、そしてspanはCOREという最も狭い範囲にとどまります。spanに書いた余白や幅の指定が効かないのは、この差が原因です。

実装上の結論は単純です。文字の大きさや色、余白の指定は、spanやdivではなくtdに直接書く。この一手だけで、Outlookでの崩れは目に見えて減ります。既存のテンプレートを直すときも、まずspan頼みになっている箇所を探すのが効率的です。

Outlookで使えないCSSは公式に一覧化されている

ここが本記事でもっとも実用的な部分です。何が効かないかを推測する必要はありません。Microsoftの公式ドキュメントに、Wordのエンジンが非対応とするCSSプロパティが列挙されています。

Word の描画エンジンが非対応とされる主なCSS（Microsoft の公式一覧より抜粋）
  background-attachment / background-image / background-position / background-repeat
  float / clear / position / top / left / right / bottom / z-index
  max-width / min-width / max-height / min-height
  overflow / visibility / text-shadow / text-transform / word-spacing
  table-layout / border-spacing / list-style-image / list-style-position

この一覧の意味を、実務の言葉に翻訳します。background-imageが非対応なので、背景画像を前提にしたデザインはOutlookで背景が消えます。対処は、背景色を必ず併記しておくこと。画像が出なくても文字が読める配色にしておけば、崩れではなく地味な表示で済みます。

floatとpositionが非対応なので、要素の横並びも重ね合わせも作れません。max-widthが非対応なので、幅の上限をCSSで抑えることもできません。幅はテーブルのwidth属性で固定値として持つのが確実です。ウィンドウを広げたときに本文が横に伸びきるのは、この指定が抜けているときに起きます。

見落とされやすいのがアニメーションGIFです。公式には、GIFの静止した1コマ目だけが表示されると記載されています。動きで伝える設計はそもそも成立しないため、1コマ目に伝えたい情報を置いておく必要があります。あわせてbutton・form・input・iframe・scriptといった要素も非対応とされており、ボタンはリンクに背景色を付けたtdで作るのが定石です。

Gmail側は広く対応する。だから差が開く

一方のGmailは、対応範囲がかなり広いことを公式リファレンスで公開しています。メール内のstyleブロックと標準的なCSSに対応し、クラス・要素・IDの3種類のセレクタが使えます。対応プロパティは150以上が列挙されています。

メディアクエリも使えます。公式には、タイプとしてallとscreen、条件としてmin-widthとmax-width、min-device-widthとmax-device-width、orientation、min-resolutionとmax-resolution、キーワードとしてandとonlyが対応と示されています。スマホ向けのレイアウト切り替えは、Gmailでは成立するということです。

問題はこの非対称性です。Gmailで確認して問題がなかったことは、Outlookでの表示を何も保証しません。逆もまた同じです。対応範囲が広いクライアントでの確認は、崩れを見逃す方向に働く——ここを理解しないまま「Gmailで見たので大丈夫」と判断すると、事故が繰り返されます。

加えて、Gmailであっても常にCSSが効くとは限らないという指摘があります。スマートフォンのブラウザからGmailを開いた場合など、一部の状況ではCSSがまったく適用されなくなるとされています。レイアウトに関わる指定は、クラスに頼らずインラインに置くのが安全側の選択です。

テーブルレイアウトが今も使われる理由

HTMLメールでtable要素を使ってレイアウトを組むのは、古い習慣が残っているからではありません。前述のとおりfloat・position・flexが使えない環境が現役で存在するため、横並びを実現する手段がtableしかないからです。

組み方の定石は、外側に幅を固定した大枠のテーブルを1つ置き、その内側に行ごとの小さなテーブルを入れ子にする形です。テーブルを細かく分けておくと崩れが局所化し、1か所の不具合が全体に波及しません。逆に1つの巨大なテーブルにまとめると、どこか1つのセルが破綻したときに全体が壊れます。

実装時に忘れやすいのが属性の明示です。border、cellpadding、cellspacingは既定値がクライアントによって違うため、すべて0を明示してから必要な余白を作るのが基本です。またpaddingとmarginはOutlookの一部バージョンで不具合が起きる可能性があるとされており、余白を高さ指定した空のセルで作る手法が今も使われています。

CSSはインラインで書く

メールでは外部CSSファイルの読み込みができません。使えるのはhead内のstyleブロックか、各要素に直接書くインラインの指定です。そしてstyleブロックを削除してしまうクライアントも存在するため、二重構造にしておくのが実務の解になります。

具体的には、レイアウトと配色に関わる指定はすべてインラインに書き、インラインに書けないものだけをstyleブロックに置くという分担です。インラインに書けないものとは、メディアクエリと、後述するダークモード用の指定です。styleブロックが消えても本文は成立する、という状態を作ります。

手作業でこれをやると、修正漏れが必ず出ます。1つの文字色を変えたいだけで数十か所のtdを書き換えることになるためです。配信ツールにインライン化の機能が付いている場合は使い、なければCSSをインラインへ展開するツールを工程に組み込んでください。手で全セルに書く運用は、更新のたびに崩れを再生産するからです。

ダークモードは3つの型で考える

ダークモードは「対応するかしないか」の二択ではありません。受信側のクライアントが色をどう扱うかで、挙動が3つに分かれると整理されています。この分類を前提にしないと、対策の方向を誤ります。

挙動の型	何が起きるか	代表例とされる環境	設計上の対処
部分的な色の反転	明るい背景を暗くし、暗い文字を明るくする。すでに暗い背景は変えない	Gmail（Android）、各種Outlook	背景と文字のコントラストを十分に取る
全体の色の反転	背景の明暗を問わず反転する。暗い前提で作ると逆に明るくされる	Gmail（iOS）、Outlook 2019（Windows）	反転しても意味が壊れない配色にする
色を変換しない	作ったままの配色で表示される	iOSのメール、macOSのApple Mail	通常の配色をそのまま最適化する

制御できる範囲は限られています。prefers-color-schemeのメディアクエリが機能するのはiOSのメール、macOSのメール、iOS版Outlookとされ、完全に制御できるのはiOSのメールだけという整理もあります。macOSのメールでは背景色の指定は効かず、画像の差し替えと文字色の変更にとどまるとされています。

/* ダークモードで画像を差し替える例。効くのは対応するクライアントに限られる */
@media (prefers-color-scheme: dark) {
  .logo-on-light { display: none; }
  .logo-on-dark  { display: block; }
}

Outlookの環境向けには、data-ogsc属性やdata-ogsb属性に対してスタイルを当てる方法が知られています。またhead内でmeta要素のcolor-schemeにlightとdarkの両方を宣言しておくと、表示が自動で調整されるとされています。ただし、どの手段も全環境を覆えません。目標は完全な制御ではなく、反転されても壊れない配色にすることです。

壊れるのは純白と透過

ダークモードで実際に事故が起きるのは、限られたパターンです。もっとも多いのが白抜きのロゴやアイコンです。背景が暗くなった瞬間、白い図形が背景と同化して消えます。SNSのアイコンなど真っ白な画像は、ほぼ確実に見えなくなります。

対処は3つあります。ロゴの背景を完全な白ではなく少し濃い色にする、図形に薄い枠線を付ける、ダークモード用の画像に差し替える。透過PNGで黒い文字のロゴを置いている場合は特に危険です。背景の透過部分が暗くなると、黒い文字がそのまま見えなくなります。ロゴは背景色を持った画像として書き出すほうが安全です。

配色の面では、純白と純黒を避けるのが定石です。ある解説では、背景に完全な白、文字に完全な黒を指定していると、Outlookの描画側がそれを検出して背景を濃い灰色、文字をオフホワイトに動的に置き換えるとされています。反転の対象になりやすい値をあえて使わないという考え方です。

見落とされやすいのが区切り線と影です。薄いグレーの罫線、淡い影、白から白へのグラデーション。いずれも反転後に消えます。区切りは線の色をやや濃くする、影に依存せず余白でブロックを分ける。装飾の役割を色の濃淡だけに担わせないことが、配色の反転に強い設計になります。

画像は表示されない前提で作る

画像は必ず表示されるものではありません。GmailやYahoo!メールなどでは、初期設定でHTMLメールの画像を非表示にする場合があるとされています。受信者が「画像を表示」を押すまで、そこには何もありません。

この前提から導かれる原則が2つあります。第一に、見出しと本文とリンクの文言はテキストで持つこと。デザインを1枚の画像で作り込むと、ブロックされた瞬間に何も伝わらないメールになります。第二に、alt属性を必ず書くこと。alt属性は要素が表示できないときに代わりに描画されるテキストで、設定していれば画像がブロックされても文言は表示されます。

alt属性の中身は、ファイル名でも「画像」でもありません。その画像が伝えている内容を書きます。ボタン画像なら「資料をダウンロードする」、製品写真なら製品名と特徴。alt属性が未設定だと、何の画像なのか分からないまま読み込みの失敗と受け取られるとされています。あわせてalt表示時の文字色とサイズを指定しておくと、ブロック時の見え方が整います。

画像とテキストの比率にも配慮が必要です。画像だけで構成したメールは受信側のフィルタで不利に働くとされており、加えて読み手にとっても内容が分からない状態になります。実務の目安は、画像を全部外しても意味が通るかを確認すること。テスト送信で画像の読み込みを止め、その状態で読んでみるのが最も確実な検証です。

スマホは1カラム、文字は大きめに

スマートフォンでの表示について、実装コストの観点から推奨されているのは、PC用のデザインをそのまま縮小して見せる形です。PC用とスマホ用で別のデザインを作る方法は、メディアクエリが機能しない環境があるため避けたほうがよいとされています。

したがって設計の起点は1カラムです。本文の幅は600px前後の固定値で持ち、要素を横に並べません。2列のレイアウトはPCでは成立してもスマホでは窮屈になり、しかも切り替えの手段が全環境で使えるとは限りません。最初から1カラムで作れば、切り替えそのものが不要になるという判断です。

文字サイズは、最初から大きめに指定してください。小さい文字を検出して自動的に拡大するクライアントがあり、その拡大がレイアウトの崩れを招きます。本文は読める大きさで書いておき、拡大の判定が働かない状態にするほうが安定します。日本語は改行位置の制御が難しいため、1文を短く保つことも見た目の安定につながります。

ボタンの作り方にも注意が必要です。リンクを文字だけにするとスマホで押しにくく、画像ボタンにするとブロック時に消えます。tdに背景色を付け、上下に余白を持たせた中にテキストリンクを置く形が、両方の問題を回避します。角丸はクライアントによって非対応とされているため、角が四角くなっても成立するデザインにしておいてください。

フォント指定は置き換わる前提で

Webフォントの読み込みは、メールでは対応が限られます。基本的には受信者の端末にあるフォントで表示されるため、フォント指定は「希望を並べる」作業になります。指定した書体で表示される保証はありません。

font-familyには候補を複数並べ、末尾に総称のsans-serifを置きます。日本語のフォント名を英字名と併記しておくと、環境によって解決される確率が上がります。候補が1つしかない指定は、その環境にフォントがなければ既定の書体になるため、意図した見え方から最も遠くなります。

Outlookでの行間には固有の対処があります。mso-line-height-rule: exactlyという独自プロパティを併記することで、指定した行の高さを効かせる手法が知られています。行間が想定より詰まる、あるいは開くという症状が出たときは、まずこの記述の有無を確認してください。

フォントが置き換わると文字の幅が変わり、想定した位置で改行されなくなります。したがってレイアウトの幅を文字数に依存させないのが原則です。テーブルの幅は固定値で持ち、文字が増えたら折り返して縦に伸びる設計にしておく。見出しの1行に収める前提で幅を決めると、環境によって2行になった瞬間に崩れます。

配信前の確認手順

ここまでの内容を、配信前のチェック工程としてまとめます。すべてを毎回やるのは現実的ではないため、テンプレートを変更したときは全工程、文面だけを差し替えたときは4番目以降だけ、という運用が回しやすい形です。

6番目を軽視しないでください。配信ツールは差し込みタグの処理やリンクの計測用の書き換えを行うため、手元のHTMLと実際に届くHTMLは同一ではありません。ツールを経由しない確認だけで通してしまうと、本番でだけ崩れるという厄介な事故になります。

生成AIにコードとaltを点検させる

この領域で生成AIが役に立つのは、判断ではなく点検です。何が非対応かは公式に一覧化されているため、その一覧と自社のHTMLを突き合わせる作業は機械的に処理できます。

実用的な使い方は4つあります。第一に、非対応プロパティの洗い出し。公式の一覧を渡した上でHTMLを読ませ、該当する記述と行を挙げさせます。第二に、alt属性の文案作り。画像の役割を説明すれば、ボタンや図版に応じた文言の候補が出ます。第三に、HTMLからテキスト版を作る作業。第四に、1枚画像で作られていた内容から、テキストにすべき見出しを抽出する作業です。

逆に任せてはいけないのが、実際の見え方の判定です。生成AIはOutlookで描画したわけではないため、崩れるかどうかを実測していません。「Outlookで問題ないと言われた」は根拠になりません。判定は必ずプレビューツールと実機で行ってください。

もう1つの落とし穴が、Web用のコードが混ざることです。HTMLメールを書かせると、flexboxやposition、rem単位、外部CSSの読み込みといったWebページの作法が入ってきます。テーブルレイアウトで組む、CSSはインライン、単位はpx固定、非対応プロパティは使わないという前提を毎回明示してから渡してください。前提を書かずに依頼した出力は、そのままでは使えないと考えたほうが早いです。

よくある失敗

実際に起きた崩れの型を並べます。いずれも設計の段階で避けられるものです。

• デザインを1枚の画像で作り、画像がブロックされると何も伝わらない
• 背景画像でデザインを組み、背景色を併記していないためOutlookで文字が読めなくなる
• spanに文字サイズと余白を指定し、Outlookで一切効いていない
• テーブルに幅の指定がなく、PCの広い画面で本文が横に伸びきる
• 白抜きのロゴを透過画像で置き、ダークモードで消える
• Gmailだけで確認して配信し、Outlook利用者から崩れの連絡を受ける
• img要素のalt属性が空のまま、ブロック時に何の画像か分からない

2つ目は特に発見が遅れます。作った本人の環境で背景画像が表示されていれば、問題に気づく機会がありません。背景画像を使うときは、必ず同じ系統の背景色を併記するのを実装のルールにしてください。画像が出れば意図どおり、出なくても読める状態になります。

6つ目については、確認の順序を変えるだけで防げます。Gmailで見て問題がないことは前提条件であり、確認の完了ではありません。対応範囲の狭い環境から先に確認する——Outlookのアプリ版で開いて成立していれば、他の環境では大きく崩れないという順序です。

テンプレートを資産にする

崩れの対策を毎回やり直すのは非効率です。一度検証を通した骨組みをテンプレートとして保存し、文面だけを差し替える運用にすると、確認の負荷が大きく下がります。

• 外枠のテーブルは幅を固定値で持ち、行ごとに小さなテーブルを入れ子にする
• レイアウトと配色の指定はインラインに書き、メディアクエリだけstyleブロックに置く
• 背景画像には必ず同系色の背景色を併記する
• 純白と純黒を避け、ロゴはダークモードで消えない形で書き出す
• img要素にはalt属性と幅、alt表示時の文字色を必ず指定する
• 文字サイズと余白はtdに直接書く。spanには頼らない
• テンプレートを変更したときは、確認工程を全て通してから本番に使う

運用のうえで効くのは、最後の1行です。テンプレートに手を入れた回は、文面差し替えの回と同じ確認では足りません。骨組みを触った変更こそ、全環境での再確認が必要です。変更履歴を残し、いつ何を直したかを追えるようにしておいてください。

よくある質問

テキストメールに戻したほうが安全ですか

崩れのリスクだけを見ればそうなりますが、それは表示の問題を回避するために伝え方の選択肢を捨てる判断になります。現実的な折衷は、HTML形式とテキスト形式の両方を含めて送り、HTMLの側は装飾を抑えて作ることです。凝ったレイアウトを避けるほど、環境差の影響は小さくなります。

どのメールソフトまで確認すればよいですか

すべてに対応することは不可能だとされているため、優先順位を決めます。最低限はWindows版Outlookのアプリ、Gmail、スマホのメールアプリの3系統です。BtoBの配信ならOutlookの比重を高く見てください。前述のとおり、実際に届いた崩れの報告を記録していけば、自社が備えるべき環境は絞り込めます。

ダークモード用のデザインを別に作るべきですか

別デザインを完全に制御できる環境は限られており、投資に対して見返りが小さくなります。優先すべきは、反転されても壊れない配色にすることです。純白と純黒を避け、ロゴを消えない形にし、区切りの線を濃くする。この3点で大半の事故は防げます。

画像を1枚にまとめるのはだめですか

画像の中に画像を重ねる作りは、positionが使えないため避けたほうがよいとされ、複数の画像を1枚に統合する方法が推奨される場面もあります。ただし、見出しや本文まで画像に含めると、ブロックされた瞬間に伝わらなくなります。図版の内部は1枚に統合し、文字情報はテキストで持つという切り分けが現実的です。

まとめ

HTMLメールの崩れは、作り方の粗さではなく受け取る側のソフトの違いから生じます。Windows版OutlookはWordのHTML解析・描画エンジンでメール本文を表示するとMicrosoftが公式に説明しており、対応するのはHTML 4.01とCSS Level 1の一部です。background-image、float、position、max-width、overflowなどが非対応として公式に列挙されており、アニメーションGIFは1コマ目だけが表示されます。一方Gmailは150以上のプロパティとメディアクエリに対応しているため、両者の間には大きな非対称が生まれます。だからテーブルレイアウトで組み、CSSはインラインに書き、幅は固定値で持ちます。ダークモードは部分反転・全体反転・変換なしの3つの型で考え、完全な制御ではなく反転されても壊れない配色を目標にします。画像はブロックされる前提で、見出しと本文をテキストで持ち、altには画像が伝えている内容を書く。そして配信前には、テキスト版の用意、コードの点検、プレビュー、実機、画像ブロック状態、本番ツール経由のテスト配信までを通します。まずはOutlookのアプリ版・Gmail・スマホのメールの3アカウントを常設のテスト宛先として登録するところから始めてください。

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