MJML vs React Email：メール開発の選び方を比較

どちらを先に検討するか

メールのレイアウトを表、列、ボタンなどの部品で組み立てたいならMJMLがわかりやすい選択肢です。HTMLを直接書くより短い記法でメールの意図を表せて、コンパイラがクライアントを意識したHTMLへ展開します。デザイン担当者がソースを読み、開発者がCLIと設定を管理するような分担にも向きます。既存のアプリがReactでなくても、Node.jsのコマンドや各言語から呼び出すビルド工程を置けます。

Reactを使うSaaSで通知データとコンポーネントを同じ規約に置きたいならReact Emailが自然です。注文、請求、招待などの入力をpropsで受け、共通ヘッダーやCTAを部品として共有できます。型を定義すれば、必須のURLや翻訳キーが抜けた状態をコードレビューで見つけやすくなります。Reactの知識を持たない編集者が頻繁に文面を変える場合は、コンポーネントの所有者と変更手順を先に決めます。

MJMLの構造とエディタ連携

MJMLでは、mj-bodyの中にmj-section、mj-columnを置き、mj-textやmj-buttonで内容を構成します。たとえば見出し、説明、CTAを同じ列にまとめ、画像を別列に置く構造をソースから読み取れます。共通の外枠をレイアウトとして持たせ、ブランド色や余白の変更を一か所に集約することも可能です。

<mj-section>
  <mj-column>
    <mj-text font-size="18px">{{ title }}</mj-text>
    <mj-button href="{{ url }}">詳細を見る</mj-button>
  </mj-column>
</mj-section>

エディタのプレビューは、余白、画像サイズ、文字の折り返しをすばやく見る場所です。保存するのはMJMLと設定、翻訳カタログで、生成されたHTMLはリリース成果物として記録します。コメントを残す場合は、ソース上で<!-- 補足 -->のように表示用にエスケープし、生成された本文に誤って命令が出ないようにします。

React Emailのコンポーネントとプレビュー

React Emailでは、Html、Text、Buttonなどの部品を組み合わせて、アプリの通知モデルからHTMLを生成します。請求メールなら明細の配列、合計、支払期限を入力にし、招待メールなら受信者名と一度だけ使うURLを入力にします。メール専用の部品を設計し、ウェブ画面のDOMやブラウザ向けのCSSをそのまま共有しないことが安全です。

ローカルプレビューには固定のサンプルデータを使います。日本語の長い件名、英語の長い単語、名前が空の場合、明細が複数行になる場合を用意すると、コンポーネントの境界が明確になります。サーバーで送信直前にレンダリングするか、CIでHTMLを作ってジョブが読み込むかは、障害時にどのバージョンを再送するかと合わせて決めます。

変数、テンプレート、i18n

両者で重要なのは、文面とデータの契約を分けることです。翻訳キーをテンプレートに散らさず、locale、タイムゾーン、通貨、日付形式を入力として扱います。MJMLではビルド前に言語別データを選び、React Emailではlocaleをpropsとして翻訳層から渡します。値のエスケープ、URLの許可リスト、未翻訳キーの検出を同じ工程に置くと、ツールをまたいでも運用がぶれません。

条件分岐が増える通知では、テンプレートに業務ルールを詰め込みすぎないことも大切です。購入状態や請求状態はアプリケーション側で決め、テンプレートには表示に必要な値だけを渡します。共通フッターの配信停止リンク、会社情報、問い合わせ先は一つの部品として管理し、言語ごとの法的文面を別の翻訳キーに分けます。

メールクライアントとビルドパイプライン

互換性はツール名だけで決まりません。テーブル構造、インラインCSS、画像の寸法、代替テキスト、リンクの絶対URL、ダークモードの配色を、対象にするメーラーの範囲に合わせて確認します。MJMLはコンパイル後のHTMLを確認し、React Emailはレンダリング後のHTMLを確認します。変数が残っていないこと、テキスト版も同じ内容であること、追跡パラメーターが意図した値であることを送信前の工程に入れます。

CIでは依存関係のバージョンを固定し、ソース、ビルド設定、翻訳、生成物の識別子を記録します。送信ジョブは宛先、件名、HTML、テキスト、タグ、イベントIDを受け取るだけにし、秘密鍵はテンプレートに置きません。APIのエラー時に再試行するか、重複送信を避けるキーをどう扱うかは、生成ツールではなく配送側の設計です。

送信APIと月額費用

MJMLとReact Emailは無料のオープンソースなので、予算は送信サービスと運用に分けます。Resend Proは月額$20で50,000通、100,000通の送信量では月額$35です。Postmark Proは月額$16.50で10,000通から始まり、50,000通では月額$60.50です。どちらも月の送信数を軸に見積もります。

Mailgun Scaleは最初の1か月以降に月額$90で100,000通を含みます。SendGrid Proは月額$89.95からで、100,000〜2,500,000通の範囲を扱い、専用IPが含まれます。SendGrid Essentialsは月額$19.95からで50,000〜100,000通の範囲です。価格を比べるときは、同じ月間通数にそろえ、超過単価、ログ保持、専用IP、ドメイン数も併記します。

たとえばトランザクション通知が月45,000通なら、Resend Proの50,000通枠とPostmark Proの10,000通開始枠を候補に置きます。マーケティング配信を同じアカウントで行う場合は、連絡先数で課金する商品が別に存在することがあります。テンプレートの作成費と配送費を一つの「フレームワーク料金」として扱わず、請求書で分かれる単位に合わせて比較してください。

MJMLからReact Emailへ移行

まず通知一覧、共通レイアウト、入力データ、翻訳キー、送信呼び出しを棚卸しします。次にヘッダー、ロゴ、本文、明細、CTA、フッターをReactコンポーネントに分け、MJMLの属性をpropsとスタイルへ置き換えます。同じサンプル入力で件名、HTML、テキスト、リンク、言語を比較し、生成物のバージョンを記録します。配送APIを変えずに一種類ずつ切り替えると、問題の範囲を絞れます。

React EmailからMJMLへ移行

逆方向では、Reactの条件分岐をデータ準備の処理へ移し、表示部分をMJMLのレイアウトと部品に落とします。propsの型にあった値をビルドデータとして用意し、共通部品はレイアウトやincludeにまとめます。React固有のロジックをテンプレートへ持ち込まず、同じ通知を一つのソースだけで編集できる状態にします。段階的に生成物を差し替え、旧HTMLへ戻す手順と担当者を決めてから切り替えます。

チームに合わせた決め方

HTMLの意味を短い専用タグで表し、エディタやCLIとの連携を重視する製品チームにはMJMLが合います。React、TypeScript、共有コンポーネントを日常的に使い、通知データの型をアプリとそろえたい開発チームにはReact Emailが向きます。どちらも送信サービスを別に選ぶ前提なので、最初に担当者、翻訳の所有者、生成物の保存場所、送信APIとの契約を文書化してください。