HTMLメール開発 2026 — Maizzle / MJML / react-email / Postmark Templates / Foundation for Emails / Cerberus 徹底ガイド

プロローグ — 1998年の`table`がいまだに生きている

モダンなHTMLしか書いてこなかった人がはじめてメールテンプレートを開いたときの衝撃は、なかなか消えない。CSS Gridは安全ではない。Flexboxも安全ではない。divベースのレイアウトすら安全ではない。Outlook(特にMicrosoft 365のデスクトップ版でWordレンダリングエンジンを使う構成)を一度でも触れば嫌でも理解する — 1998年に固まったtableベースのレイアウトが、今もなお事実上唯一の互換手法だ。

それなのに、その化石の上で2024年から2026年にかけて起きていることは興味深い。Resendが作ったreact-emailはインディースタートアップの事実上の標準になり、MaizzleはTailwind CSSのワークフローをメールに持ち込んだ。MJMLはオープンソースのコンポーネント標準として安定の地位を保ち、Postmarkのサーバーサイドテンプレートは1行のMustache変数でマーケティングとエンジニアリングの境目を曖昧にした。同時にStripo、BEE、Stensul、Unlayerといったドラッグアンドドロップ系SaaSは、マーケティング部門の作業を着々と取り込んでいる。

本稿はこの4分類 — コード(Maizzle、Cerberus)、コンポーネントDSL(MJML、react-email、Foundation for Emails、HEML)、サーバーサイドテンプレート(Postmark、HubSpot)、ドラッグアンドドロップSaaS(Stripo、BEE、Stensul、Unlayer、mosaico、Email-Builder.js、Tabular) — を一度に整理する。さらにダークモード、アクセシビリティ、MIME multipart、AMP for Email、そして韓国 / 日本の実例まで取り扱う。

1章 · 2026年HTMLメール地図 — コード / コンポーネント / ドラッグアンドドロップ / SaaS

ツール群は大まかに4つに分かれる。

分類	代表ツール	主なユーザー	強み
コード優先	Maizzle、Cerberus、ZURB Foundation 旧版	フロントエンドエンジニア	生HTML / Tailwind
コンポーネントDSL	MJML、react-email、HEML、Foundation for Emails	フルスタックエンジニア	コンポーネント抽象化
サーバーサイドテンプレート	Postmark、HubSpot、SendGrid Dynamic Templates	バックエンド+マーケ	変数置換 / 多言語
ドラッグアンドドロップSaaS	Stripo、BEE、Stensul、Unlayer、mosaico、Email-Builder.js、Tabular	マーケ / デザイナー	非エンジニアでも可

境界はあいまいだ。Maizzleはコード優先だがコンポーネント的にも使えるし、react-emailはコンポーネントだが結局はコード優先。Stripoはドラッグアンドドロップだがコードを直接編集できる。表は出発点にすぎない。

2026年5月時点で意味のある5つのトレンド:

react-email(Resend)の独走 — 非公式推定でインディー / スタートアップ採用率8割超。
Maizzleの静かな伸び — Tailwindチームが自然に選ぶ。
MJMLの安定期 — 大型機能より統合とAI支援に注力。
マーケ部門を吸収するドラッグアンドドロップSaaS — Stripo / BEE / Stensulがそれぞれの座を確保。
AMP for Emailの事実上の死 — 公開から6年、ほぼ全ての導入企業が撤退。

2章 · なぜメールは依然として難しいのか — クライアントの分断

2026年のクライアントシェア、ざっくり:

Apple Mail(iOS / macOS) — 約55%。CSS対応が最良。ダークモードは自動で反転。
Gmail(Web / アプリ) — 約28%。<style>タグを許容(2016年以降)。ただしclip-pathやmix-blend-modeは不安定。
Outlook(Microsoft 365デスクトップ、Outlook.com、Outlookモバイル) — 約10%。全ての問題の根源。 デスクトップ版はWordのレンダリングエンジン(MSO)を使い、Web / モバイル / Mac版はそれぞれ別エンジンなので、同じメールが3通りに見える。
その他(Yahoo、AOL、Samsung Mail、日本のK-9、韓国のDaumメール等) — 合計約7%。

問題はOutlookデスクトップだ。Microsoftは2024年に「New Outlook」を推進したが、2026年でも企業環境の約60%はいまだにWordエンジンを使う。Wordエンジンは:

CSS Grid / Flexbox非対応。
background-image非対応(VMLで回避)。
一部のmarginを無視。
border-radius非対応。
フォントフォールバックがTimes New Romanに落ちる。

そのため2026年でもメールテンプレートはtable+td+align="center"の1998年パターンに依存する。Maizzle、MJML、react-emailはすべてそこに落ち着く。

<!-- 2026年も基準はこれ -->
<table role="presentation" cellspacing="0" cellpadding="0" border="0" width="100%">
  <tr>
    <td align="center">
      <table role="presentation" cellspacing="0" cellpadding="0" border="0" width="600">
        <tr>
          <td style="padding: 20px;">
            本文ここに
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

肝はrole="presentation" — スクリーンリーダーにこの表はデータ表ではなくレイアウト用だと伝える。アクセシビリティは13章で再度扱う。

3章 · Maizzle — TailwindCSS駆動のワークフロー

3.1 出発点

Maizzleはルーマニアの開発者Cosmin Popoviciが2018年に始めた。中核アイデアは**「メールにTailwindを使う」**。Tailwindは元々Webページ向けのユーティリティクラスフレームワークだが、同じDXをメールでも実現するために作られたのがMaizzleだ。2024年のMaizzle 5でVite基盤に書き直され、2026年現在は6.x系。

npx create-maizzle
# Maizzle Starter? Default
# Project name? my-emails
cd my-emails
npm install
npm run dev

既定構成:

my-emails/
  src/
    components/    # 再利用コンポーネント
    layouts/       # レイアウト(main.html等)
    templates/     # 実際のメール(welcome.html等)
  tailwind.config.js
  config.js
  package.json

3.2 何をしてくれるか

ビルド時にMaizzleは:

Tailwindクラスをインラインスタイルに変換。
<style>ブロックに残せないクラスをインライン化。
メディアクエリは<style>ブロックに残す(Outlookが無視してもOK)。
HTMLをminify。
オプションでplain-text版を生成。

書き手はこう書く:

<table class="w-full max-w-[600px] mx-auto bg-white">
  <tr>
    <td class="p-6 text-base font-sans text-slate-800">
      <h1 class="text-2xl font-bold mb-4">ようこそ</h1>
      <p>ご登録ありがとうございます。下のボタンから始めましょう。</p>
    </td>
  </tr>
</table>

ビルド後はこうなる:

<table style="width: 100%; max-width: 600px; margin: 0 auto; background-color: #ffffff;">
  <tr>
    <td style="padding: 24px; font-size: 16px; font-family: ui-sans-serif, system-ui; color: #1e293b;">
      <h1 style="font-size: 24px; font-weight: 700; margin-bottom: 16px;">ようこそ</h1>
      <p>ご登録ありがとうございます。下のボタンから始めましょう。</p>
    </td>
  </tr>
</table>

3.3 強み

Tailwindをそのまま使える。 Webチームに新規学習がほぼ不要。
x-component によるヘッダー / フッターの再利用。
環境別ビルド — dev / staging / productionで別データを差し込み。
MJML経由ビルド対応 — 必要ならMJMLを経由可能。
plain-text自動生成 — juiceベース。

3.4 弱み

Tailwind未経験チームには学習曲線がある。
ドラッグアンドドロップが必要なマーケチームには不向き。
コンポーネントモデルはReactより単純。JSX並みの表現力はない。

Maizzleが最も輝くのは「フロントエンドチームがメールを直接所有する」場合だ。

4章 · MJML — Mailjet製のコンポーネントDSL

4.1 沿革

Mailjet(現 Sinch Email)が2015年にMJMLをオープンソース化。読み方は「エム・ジェイ・エム・エル」。メール専用のマークアップ言語と、それを1998年互換HTMLに変換するコンパイラの組み合わせだ。

<mjml>
  <mj-head>
    <mj-title>ようこそ</mj-title>
    <mj-preview>ご登録ありがとうございます。さっそく始めましょう。</mj-preview>
    <mj-attributes>
      <mj-all font-family="Inter, Arial, sans-serif" />
      <mj-text color="#1e293b" line-height="1.5" />
    </mj-attributes>
  </mj-head>
  <mj-body background-color="#f8fafc" width="600px">
    <mj-section background-color="#ffffff" padding="24px">
      <mj-column>
        <mj-text font-size="24px" font-weight="700">ようこそ</mj-text>
        <mj-text>ご登録ありがとうございます。下のボタンから始めてください。</mj-text>
        <mj-button background-color="#3b82f6" href="https://example.com">
          始める
        </mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

4.2 良いところ

セマンティックなコンポーネント: mj-section、mj-column、mj-button、mj-image、mj-divider。
既定でレスポンシブ — mj-columnはモバイルで自動的に1列に積み上がる。
VS Code拡張でリアルタイムプレビュー。
CLI — mjml input.mjml -o output.html。
Nodeライブラリ — サーバーでmjml2html()変換。

import mjml2html from 'mjml'

const { html, errors } = mjml2html(mjmlSource, {
  minify: true,
  keepComments: false,
})

4.3 弱み

MJML文法の学習が必要。デザイナーには参入障壁。
変数置換は別物 — Handlebars / Mustache / Liquidを上に載せる。
多言語対応は付属せず — i18nレイヤーは自前で。
AIツール周辺はreact-emailより薄い — MJML AIはあるがReact側の動きが速い。

MJMLは「オープン標準を使いたいがReactは導入したくない」チームに今でも妥当だ。

5章 · react-email(Resend) — JSXネイティブの定着組

5.1 立ち上がり

Resend創業者Zeno Roccaが2023年にreact-emailを公開。出発点はシンプル — 「メールもコンポーネントで、JSXで書きたい」。Resendの成長に乗って2024年にはインディー / スタートアップの事実上の標準になり、2026年1月に4.x系がリリースされた。

npm install react-email @react-email/components -D
npx react-email dev    # ローカルプレビューサーバ

// emails/welcome.jsx
import {
  Body,
  Button,
  Container,
  Head,
  Heading,
  Html,
  Preview,
  Section,
  Text,
} from '@react-email/components'

export default function Welcome({ name = 'お客様' }) {
  return (
    <Html lang="ja">
      <Head />
      <Preview>ご登録ありがとうございます。さっそく始めましょう。</Preview>
      <Body style={main}>
        <Container style={container}>
          <Heading style={h1}>ようこそ、{name}さん</Heading>
          <Section>
            <Text>ご登録ありがとうございます。下のボタンから始めてください。</Text>
            <Button href="https://example.com" style={btn}>
              始める
            </Button>
          </Section>
        </Container>
      </Body>
    </Html>
  )
}

const main = { backgroundColor: '#f8fafc', fontFamily: 'Inter, Arial, sans-serif' }
const container = { maxWidth: 600, margin: '0 auto', backgroundColor: '#fff', padding: 24 }
const h1 = { fontSize: 24, fontWeight: 700, color: '#1e293b' }
const btn = { backgroundColor: '#3b82f6', color: '#fff', padding: '12px 24px', borderRadius: 6 }

(注: 上のJSXの中括弧はコードブロック内なので問題ない。本文では中括弧+識別子をむき出しにしないこと。)

5.2 強み

Reactチームには学習コストゼロ。
@react-email/components ライブラリ — Button、Container、Section、Heading、Img、Hr、Link等。
ローカルプレビューサーバ(npx react-email dev) はこの分野で最良のDX。
HTMLとplain-textを1回で生成 — render(<Welcome />)、render(<Welcome />, { plainText: true })。
Resendとの一体感 — Resend SDKにreactオプションを渡すと自動レンダリング。

import { Resend } from 'resend'
import Welcome from '../emails/welcome'

const resend = new Resend(process.env.RESEND_API_KEY)
await resend.emails.send({
  from: 'Acme <hello@mail.acme.com>',
  to: ['user@example.com'],
  subject: 'ようこそ',
  react: <Welcome name="ヨンジュ" />,
})

5.3 弱み

React依存。 PHP / Ruby / Goチームでは相性が落ちる(SSRサービスで回避可能だが複雑)。
OutlookのWordエンジン互換はやはり自己責任 — コンポーネントが綺麗でも、込み入ったレイアウトは個別検証が必要。
ダークモード / 色トークンは自前管理 — Tailwindほど整ったトークン体系は無い。

5.4 react-email vs MJML

同じコンポーネントモデルだが決定的差異がある。

MJML: 独自DSL → HTML。Reactと無関係。
react-email: JSX → HTML。Reactコンポーネントとして再利用 / テスト / Storybook可能。

Reactチームならreact-email、そうでなければMJML。

6章 · Postmark Templates — サーバーサイド変数置換

6.1 ポジション

Postmarkはトランザクショナル特化型のESP。MJMLとMustachio(Mustache派生)に基づく強力なテンプレートシステムを持つ。2024年にActiveCampaignに買収されたが、2026年現在も独立プロダクトとして運営されている。

<!-- Postmark テンプレート本文 -->
<table>
  <tr>
    <td>
      <h1>こんにちは {{name}}さん</h1>
      <p>ご注文 #{{order_id}} を承りました。</p>
      {{#each items}}
        <p>{{name}} x {{quantity}} = {{total_jpy}}円</p>
      {{/each}}
      <a href="{{tracking_url}}">配送状況を確認</a>
    </td>
  </tr>
</table>

このようにMustachio構文で変数を埋め込み、送信時にAPIからデータを注入する。

import { ServerClient } from 'postmark'

const client = new ServerClient(process.env.POSTMARK_TOKEN)

await client.sendEmailWithTemplate({
  From: 'orders@example.com',
  To: 'user@example.com',
  TemplateAlias: 'order-confirmation',
  TemplateModel: {
    name: 'ヨンジュ',
    order_id: 'A-1234',
    items: [
      { name: '本', quantity: 1, total_jpy: '2,000' },
      { name: 'コーヒー', quantity: 2, total_jpy: '1,200' },
    ],
    tracking_url: 'https://example.com/track/A-1234',
  },
})

6.2 強み

マーケチームが直接編集 — 送信コードを触らずに本文修正可能。
多言語処理が綺麗 — 同テンプレートのKO / EN / JA派生をaliasで管理。
MJMLベースのエディタ — ビジュアル編集とコード編集を併用可能。
A/Bテスト、バージョン管理 が製品に組込み。

6.3 弱み

Postmarkロックイン — 他ESPに移ると全テンプレ移植。
開発ワークフロー(Git、コードレビュー)から切り離される — テンプレ変更がPRに乗らない。
複雑な制御(分岐、ループ)が弱い — Liquidより表現力に劣る。

サーバーサイドテンプレートは「マーケはコピーを頻繁に変えるが構造はあまり変えない」という前提で最もよく機能する。

6.4 比較 — SendGrid Dynamic Templates / HubSpot

SendGrid Dynamic Templates — Handlebars。Postmark類似だがエディタUXは劣る。
HubSpotテンプレート — 独自言語HubL。HubSpotのマーケティング自動化と深く統合されるがトランザクショナル用途には重い。

7章 · Foundation for Emails(ZURB) — クラシックなフレームワーク

7.1 ZURBの遺産

ZURBは2010年代にFoundationというCSSフレームワーク(Bootstrapのライバル)で有名だった。2015年にメール特化派生のFoundation for Emails(コードネーム Ink)を公開。2017年にv2が出てから大型更新はないが、現在もメンテされている。

<!-- Foundation for Emails - Inky マークアップ -->
<container>
  <row>
    <columns small="12" large="6">
      <h1>ようこそ</h1>
      <p>ご登録ありがとうございます。</p>
      <button href="https://example.com">始める</button>
    </columns>
    <columns small="12" large="6">
      <img src="https://example.com/welcome.png" alt="Welcome" />
    </columns>
  </row>
</container>

Inkyマークアップではcontainer、row、columns、buttonといったセマンティックタグを書き、コンパイラが1998年互換のtableベースHTMLに変換する。MJMLの精神的祖先である。

7.2 2026年に使う価値はあるか

新規プロジェクトには概ね非推奨。MJMLとreact-emailがほぼ全側面で上回る。ただし:

既存のZURB / Foundation資産があるチーム。
Ruby on Railsのショップ — foundation_emails-sass gemの整備が手厚い。
MJMLの**mj-プレフィックス**を生理的に好まない人。

これらに対しては今でも合理的だ。

8章 · Cerberus テンプレート(Ted Goas)

8.1 何者か

Cerberusはデザイナー兼開発者Ted Goasが2013年頃に公開した素のHTMLメールテンプレート集。ビルドツール無し、HTMLファイルをコピーして編集するだけ。2026年でもGitHubリポジトリは維持されており、約8.5kスター。

3つの核テンプレート:

cerberus-fluid.html — 1カラム、モバイルファースト。
cerberus-responsive.html — メディアクエリベースのレスポンシブ。
cerberus-hybrid.html — Outlook用条件付きコメント+モバイルメディアクエリ。

<!--[if (gte mso 9)|(IE)]>
<table align="center" border="0" cellspacing="0" cellpadding="0" width="600">
<tr>
<td align="center" valign="top" width="600">
<![endif]-->
<table align="center" border="0" cellpadding="0" cellspacing="0"
       style="max-width: 600px; margin: auto;" class="email-container">
  <tr>
    <td>本文</td>
  </tr>
</table>
<!--[if (gte mso 9)|(IE)]>
</td>
</tr>
</table>
<![endif]-->

これが有名なOutlook条件付きコメント(MSO conditional comments) パターン。Outlookは<!--[if (gte mso 9)|(IE)]>内のマークアップだけを読む。Outlookはmax-widthを無視するので、固定幅600pxのtableを別途与える必要がある。

8.2 なぜ今も使うのか

ビルドツール不要 — ファイル1個コピーで完了。
検証済みパターン — 10年以上の実戦経験。
学習用に最適 — なぜそのようなtable構造が必要なのかを最も明快に示す。

メールを始めるエンジニアの最短経路は、Cerberusを一度読んでから、Maizzle / MJML / react-emailに移ること。

9章 · HEML / mosaico — その他のOSS

9.1 HEML

SparkPost(現MessageBird)が2018年に公開した別のセマンティックマークアップ。

<heml>
  <head>
    <subject>こんにちは</subject>
  </head>
  <body>
    <container>
      <h1>ようこそ</h1>
      <p>ご登録ありがとうございます。</p>
      <button href="https://example.com">始める</button>
    </container>
  </body>
</heml>

MJMLとほぼ同じコンセプトだが、2020年以降の更新がほぼ無い。2026年現在、事実上メンテナンスモード。

9.2 mosaico

Vox Media系列が作ったOSSドラッグアンドドロップエディタ。セルフホストしてマーケチームに提供できる。

長所: 無料、セルフホスト可。
短所: 2010年代風のUI、テンプレートライブラリが小さい。

社内マーケ用ツールが必要だがSaaSコストが厳しい現場で稀に採用される。

10章 · Stripo / BEE / Stensul / Unlayer — ドラッグアンドドロップSaaS

10.1 4ツールの立ち位置

ツール	親会社	価格帯(2026)	主顧客
Stripo	Stripo(独立)	無料~`$95/月`	中小マーケチーム
BEE	BEE Content Design	無料~`$150/月`	大企業、埋め込みSDKに強み
Stensul	Stensul	エンタープライズのみ	大企業、ブランドガバナンス
Unlayer	Unlayer	無料~`$200/月`	SaaS埋め込み優先

10.2 Stripo

最も親しみやすい汎用エディタ。セルフホスト / ダウンロード / 直接ESPへ送信のすべてに対応。モジュールライブラリ(Shutterstock画像統合等)が豊富。

10.3 BEE

元はMailUpのBEE Freeエディタ。最大の差別化要素は埋め込みSDK — 自社SaaSにBEEエディタを統合できる。HubSpot、ClickFunnelsなど数多くのツールがOEM採用。

10.4 Stensul

エンタープライズ専用。単なるエディタというよりメール協業ワークフロー(ブランドガイドライン強制、承認ルーティング、多言語翻訳パイプライン)に強み。大手の金融 / 製薬 / 通信社が主顧客。

10.5 Unlayer

SaaS埋め込み特化。react-email-editorというReactコンポーネントで自社プロダクトに5分でメールエディタを組み込める。

import EmailEditor from 'react-email-editor'

export default function Editor() {
  return (
    <EmailEditor
      projectId={12345}
      onLoad={(unlayer) => {
        // ready
      }}
      onReady={(unlayer) => {
        unlayer.exportHtml((data) => {
          console.log(data.html)
        })
      }}
    />
  )
}

(上のJSX中括弧もコードブロック内。)

10.6 mosaico vs SaaS — トレードオフ

SaaS — 即利用可、優れたテンプレートライブラリ。ただし月額費用とデータ外部化。
mosaicoセルフホスト — 無料、データ内製。ただし運用コストと古いUI。

11章 · Email-Builder.js(Microsoft) / Tabular — 新興勢

11.1 Email-Builder.js

Microsoftが2024年にOSS化したReactベースのメールビルダーライブラリ。Outlookを作っている会社が直接出している点に意味がある。

import { Reader } from '@usewaypoint/email-builder'

const document = {
  root: {
    type: 'EmailLayout',
    data: {
      backdropColor: '#F5F5F5',
      canvasColor: '#FFFFFF',
      children: ['block-1', 'block-2'],
    },
  },
  'block-1': {
    type: 'Heading',
    data: { props: { text: 'ようこそ', level: 'h1' } },
  },
  'block-2': {
    type: 'Text',
    data: { props: { text: 'ご登録ありがとうございます。' } },
  },
}

export default function Preview() {
  return <Reader document={document} rootBlockId="root" />
}

長所: Microsoft側のOutlook互換性へのコミットメント。
短所: 生態系がまだ小さい。コミュニティコンポーネントはreact-emailほど多くない。

11.2 Tabular

2024年登場の新参ドラッグアンドドロップSaaS。差別化点はAI優先 — GPT等のLLMでコピー / 画像 / レイアウトを一緒に生成する。インディーマーケで話題。

12章 · Litmus / Email on Acid — テスト

12.1 2ツールの沿革

メールクライアントは100種類以上あり、実際に開いてみないとどこで壊れるか分からない。LitmusとEmail on Acidはそのために登場した。

Litmus — 2005年英国で創業。2022年にCisionが買収。
Email on Acid — 2010年コロラドで創業。2022年にAWeber親会社のVolaris Groupが買収。

両ツールとも機能は本質的に同等:

クライアントプレビュー — 90~100以上のクライアントでどう見えるかのスクリーンショット。
スパム分析 — SpamAssassin、Microsoft等のフィルタでどう評価されるか。
リンク / 画像チェック — 壊れたリンク、欠落画像。
アクセシビリティ検査 — altテキスト、色コントラスト、フォントサイズ。
分析 / トラッキング — 開封 / クリック分析。

12.2 使い方

典型的なワークフロー:

Maizzle / MJML / react-emailでHTML生成。
Litmus / EoAにアップロード(直接 or ESP統合経由)。
クライアント別プレビュー確認。
壊れている箇所を修正 → 再アップロード。
通ったらESPで送信。

// Litmus API でプレビュー要請(仮想例)
import fetch from 'node-fetch'

const res = await fetch('https://api.litmus.com/v1/emails', {
  method: 'POST',
  headers: {
    Authorization: 'Bearer ' + process.env.LITMUS_TOKEN,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    html: htmlSource,
    subject: 'テスト',
    clients: ['outlook2021', 'gmail-web', 'ios-mail-17', 'samsung-mail'],
  }),
})

12.3 価格

2026年時点で両方とも高い。スタート価格は月$99程度、本格利用で$199~$400/月。インディー開発者には負担なので、代替でMailtrap、HTML Email Check、PutsMail(Litmusの無料ツール) 等を使う。

13章 · ダークモード+アクセシビリティ+MIME multipart+AMP for Email

13.1 ダークモード — Outlookの新しい地獄

2024年以降、主要全クライアントがダークモードに対応。だが処理方法が3通りに分かれる。

Apple Mail(iOS / macOS) — prefers-color-scheme: darkメディアクエリを正直に守る。きれいなケース。
Outlookデスクトップ / モバイル — 勝手に色を反転。白背景を黒に変えるが、一部の色だけ反転して企業ロゴが崩れる。
Gmail — 部分的反転。クライアントとOS設定の組合せで挙動が変わる。

対応パターン:

<head>
<style>
  /* カラースキームメタ */
  :root {
    color-scheme: light dark;
    supported-color-schemes: light dark;
  }

  @media (prefers-color-scheme: dark) {
    .body-bg { background-color: #0f172a !important; }
    .text { color: #e2e8f0 !important; }
  }

  /* Outlook 強制反転を抑制(クライアントに依存) */
  [data-ogsc] .body-bg { background-color: #0f172a !important; }
  [data-ogsc] .text { color: #e2e8f0 !important; }
</style>
</head>

肝はロゴ / アイコンはPNGではなくSVG、もしくはダーク / ライト両版を用意 — 色が反転しても壊れないように。

13.2 アクセシビリティ — メール版のWCAG

メールにもWCAG 2.2 AAが適用される。要チェックリスト:

role="presentation" を全てのレイアウト用tableに付与。
画像の**alt属性必須**。装飾用ならalt=""。
本文の色コントラスト4.5:1以上 — #666を#fffの上に置くのは不可。
本文フォント最低14px、可能なら16px。
リンクは色だけでなく下線でも区別。
lang属性 を<html lang="ja">または<html lang="ko">に。
prefers-reduced-motion — GIFは一時停止オプションが無いなら控えめに。

<table role="presentation" aria-hidden="false">
  <tr>
    <td>
      <img src="logo.png" alt="Acme ロゴ" width="120" height="40" />
    </td>
  </tr>
</table>

13.3 MIME multipart — plain-textの義務

実質的に全マーケティングメールはmultipart/alternativeで送るべき。理由は2つ。

plain-textが無いとスパムスコアが上がる — SpamAssassin等はHTML-onlyを疑う。
Apple Watch、テキストベースクライアント、スクリーンリーダーはplain-textを使う。

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=utf-8

ようこそ。

ご登録ありがとうございます。下のリンクから始めてください:
https://example.com/start

--boundary42
Content-Type: text/html; charset=utf-8

<html>...</html>
--boundary42--

react-emailはrender(<Welcome />, { plainText: true })で、Maizzleはjuiceベース変換で自動生成。

13.4 AMP for Email — 死にかけだがまだ

Googleが2019年に発表したメール内動的コンテンツ標準。受信箱内でフォーム送信 / カルーセル / リアルタイムデータ更新を可能にする夢だった。

<!-- AMP for Email -->
<!DOCTYPE html>
<html amp4email data-css-strict>
<head>
  <meta charset="utf-8">
  <script async src="https://cdn.ampproject.org/v0.js"></script>
  <style amp4email-boilerplate>body{visibility:hidden}</style>
  <style amp-custom>
    .container { padding: 16px; }
  </style>
</head>
<body>
  <amp-form method="post" action-xhr="https://example.com/subscribe">
    <input type="email" name="email" required />
    <input type="submit" value="登録" />
  </amp-form>
</body>
</html>

2026年現在、事実上の死。理由:

Gmail、Yahoo、Mail.ruのみ対応 — Outlook、Apple Mailは非対応。
送信者登録手続きが煩雑 — Googleに別途登録。
保守コストがリターンを上回る — HTML版もどうせフォールバックで作る必要がある。

Booking.com、Pinterest等の初期採用組も2024年頃にほぼ撤退。新規に始めるならAMPは無視。

14章 · メールにおけるAI — MJML AI、Maizzle AI?、ChatGPTでデザイン

14.1 MJML AI

Mailjetが2024年に発表したツール。自然言語で「ウェルカムメール、青基調、CTAボタン1つ」のように入力するとMJMLコードを生成する。

[入力]
登録ウェルカムメールを作って。青基調、上部に会社ロゴ、挨拶、CTA「始める」ボタン、下部にSNSリンク。

[出力]
<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-image src="logo.png" width="120px" />
      </mj-column>
    </mj-section>
    ...
  </mj-body>
</mjml>

品質は平均以上。デザインが少々凡庸なので、最終の磨きは人間がやる。

14.2 Maizzle / react-email + ChatGPT

専用ツールなしでも、ChatGPT / Claudeに「Maizzleコンポーネントで~を書いて」と投げれば結果がよく出る。2026年のLLMはメールマークアップを十分理解している。

効果的なプロンプトのコツ:

Outlook互換を明示 — 「OutlookデスクトップのWordエンジン互換で」
table基盤を明示 — 「Flexboxは使わずtable基盤で」
レスポンシブを明示 — 「モバイル幅480px未満で1カラム」
ダークモードを明示 — 「ダークモードメディアクエリ込みで」

14.3 TabularのAI統合

Tabularは「メール本文をLLMが自動生成」を一級機能としている。マーケがブランドトーンだけ決めれば、毎週のニュースレター本文を自動で書く流れ。2026年のインディーマーケで急速に採用が進む。

15章 · 韓国 / 日本 — トス、カカオ、メルカリ、クックパッド

15.1 韓国

トス(Toss)メール — トスのトランザクショナル / マーケティングメールは自社インフラ(SESベースと推定)で送信。デザインはトスのデザインシステムと整合し、react-emailスタイルのコンポーネントベースに見える。plain-textが常に同梱されている。
カカオ(Kakao)メールマーケ — カカオはKakaoTalk Bizメッセージが主要チャネルで、メール比率は小さい。ただしKakaoEnterprise、KakaoWorksなどB2Bは今もメール中心。自社テンプレートシステムを運営。
ネイバーメールの受信側 — ネイバーは韓国で圧倒的シェア。SPF / DKIM / DMARCが揃わないと容赦なくスパムへ。HTML-onlyへのペナルティも大きく、plain-text必須。

15.2 日本

メルカリ(Mercari)メール — メルカリは約1億会員規模で送信量が巨大。過去の発表からSendGridを主力で利用していると見られる。テンプレートは自社デザインシステムの上に、MJMLまたは類似コンポーネントで実装されている様子。
クックパッド — レシピサービス。毎日のおすすめレシピメールが中核チャネル。多言語(JA / EN / ES / AR)対応がしっかり整備されている。
日本のキャリアメール — docomo.ne.jp、softbank.ne.jp、ezweb.ne.jp等のキャリアメールは今も一部利用者が使う。iモードの遺産でHTML処理が独特、画像サイズ / 本文長に制限がある。日本市場固有の事情。

15.3 韓国 / 日本に共通 — レビューと送信時刻

保守的なレビュー — マーケ本文は法務 / コンプライアンスのレビューを通す比率が米国より高い。そのためPostmark / Stensulのような協業ワークフローが整ったツールが歓迎される。
送信時刻 — 韓国 / 日本は平日午前9時~10時送信が開封率最良(2025年SendGridレポート)。

16章 · ツール選定ガイド — 2026年5月時点

状況別の推奨:

インディースタートアップ / Next.js / Resendスタック — react-email + Resend。議論の余地なし。
Tailwindチーム / Vue / バニラ — Maizzle。
PHP / Ruby / Goバックエンド — MJML CLI + 自前変数置換。
マーケチームが直接編集 — Postmark Templates、または Stripo / BEE。
大企業 / ガバナンス必要 — Stensul、またはSalesforce Marketing Cloud Email Studio。
OEM / SaaS埋め込み — Unlayer(react-email-editor)またはBEE SDK。
AI駆動の実験 — Tabular。
Outlook互換性最優先 — Email-Builder.js(Microsoft)。

どの道を選ぶにせよ、テストはLitmusまたはEmail on Acid。インディーなら無料のPutsMailから始める。

ダークモード / アクセシビリティ / MIME multipartは全ケース共通で必須。そしてAMP for Emailは無視して安全な時期である。

参考 · References

Maizzle 公式 — https://maizzle.com
MJML 公式 — https://mjml.io
react-email — https://react.email
Resend — https://resend.com
Postmark Templates — https://postmarkapp.com/email-templates
Foundation for Emails — https://get.foundation/emails.html
Cerberus(Ted Goas) — https://tedgoas.github.io/Cerberus/
HEML — https://heml.io
mosaico — https://mosaico.io
Stripo — https://stripo.email
BEE — https://beefree.io
Stensul — https://stensul.com
Unlayer — https://unlayer.com
Email-Builder.js(Microsoft) — https://github.com/usewaypoint/email-builder-js
Tabular — https://tabular.email
Litmus — https://litmus.com
Email on Acid — https://www.emailonacid.com
AMP for Email — https://amp.dev/about/email
Email Geeks Slack — https://email.geeks.chat
Really Good Emails(参考) — https://reallygoodemails.com

プロローグ — 1998年のtableがいまだに生きている