HTMLプレビューだけでは合格にならない：
トランザクションメールの証跡を残す

2026年、テンプレートの更新は速くなった。それでもスクリーンショットだけでは不十分

登録確認メールには、複数のバージョンがあることも珍しくありません。文面が変わり、対応言語が増え、コンポーネントも更新されます。2026年のテンプレート更新では、ボタン、変数、有効期限の案内を同じ日に変更することもあります。「問題なく見える」受信画面のスクリーンショットだけでは、どのビルドで、どんな入力を使ったのか分かりません。

問題が引き継がれる頃には、テスト用アドレスがすでに期限切れで、開発担当者もあの長いユーザー名を再現できないかもしれません。メールテストの証跡パックは、スクリーンショットをたくさん保存することではありません。今回の確認を再現するために必要な最小限の情報を残すことです。先に入力値とバージョンを記録してから結果を保存すれば、後から確認し直すより時間を節約できます。

まず3つの確認レベルを分ける

トランザクションメールのテストでは、次の3点を分けて記録しましょう。「メールが届いた」だけでは「内容が正しい」とは言えず、「Web上で正常に見える」だけでは「対象クライアントで問題ない」とは限りません。

たとえば「ステージング環境のビルドAで中国語の確認メールが到着。Webプレビューではボタンを確認。デスクトップのメールクライアントでは未確認」と記録できます。「メールは正常」だけよりも正確です。

最小限の証跡パック：まずは5項目

テストごとにケース番号のフォルダーを作り、実際のメールアドレスや認証コードをファイル名に使わないようにします。最低限、次の情報を残しましょう。

• テンプレートのバージョン：テンプレートID、コミットまたはビルド番号、言語バージョン。
• テスト変数：ユーザー名、製品名、未設定時の値など、個人情報を伏せた入力。元の長さとデータ型は維持します。
• リクエスト記録：実行時刻、タイムゾーン、リクエストID、テスト環境、レスポンス。
• メールの内容：個人情報を伏せたHTML、取得可能なプレーンテキスト、必要なメタ情報。
• 確認結果：期待値、実際の結果、スクリーンショット、確認環境、未テストの範囲。

テンプレートのバージョンは、送信システムまたはリリース記録から確認してください。受信画面にバージョンが表示されていなくても、メールの見た目から確実に特定できるわけではありません。取得できない場合は「不明」と記録し、推測で埋めないでください。

登録確認メールを使って記録する

入力を固定し、内容と表示を分けて確認する

たとえば、case signup-zh-longnameでは、ステージング環境で意図的に長いユーザー名を使い、使い捨てメールアドレスをコピーして登録を実行し、リクエストIDと時刻を記録します。送信後すぐにテンプレートを変更すると、届いたメールがどのバージョンのものか分からなくなるため、変更は控えてください。

メールが届いたら、まず変数が正しく置き換わっているかを確認し、次に表示を確認します。本文に {{display_name}}が残っている場合は、変数の受け渡しやテンプレートのコンパイルを優先して調べます。名前は正しいもののボタンが押し出されている場合は、幅、折り返し、レイアウトを確認します。両方の問題が同時に起きることもありますが、別々に記録しましょう。

次に同じテンプレートバージョンを使い、短いユーザー名で再テストします。入力を一つだけ変えると、長いテキストが原因なのか、すべてのメールで起きる問題なのかを判断しやすくなります。認証コードが業務システムで受け付けられるかは、管理されたテストアカウントで別途確認してください。スクリーンショットだけでは判断できません。

スクリーンショットに加えて本文と必要なメタ情報も保存する

スクリーンショットでは見た目は残せますが、非表示のテキスト、実際のリンク、プレーンテキスト部分は確認できません。受信画面からHTMLソースを保存し、送信側またはエクスポートに対応したメールクライアントから、プレーンテキストや元のメールを取得できます。プレビューで生成されたページのDOMを、元のMIMEメールとして扱わないでください。

メタ情報には、件名、個人情報を伏せた宛先、送信元アドレス、受信を確認した時刻、取得できる場合は実際のMessage-IDを記録します。メールヘッダーのDateと、手元で確認した時刻は意味が異なります。それぞれの時刻の出所とタイムゾーンを記し、エンドツーエンドの遅延として単純に扱わないでください。

画像が表示されないときは、まず原因を分類する

同じように画像が空白でも、対処方法は異なる場合があります。まず画像のURL形式を確認し、読み込み時の条件を記録しましょう。

• 外部リソース：HTTPSのURL、レスポンスの状態、アクセス権、リソースがまだ存在するかを確認します。メールクライアントでは外部画像が既定でブロックされることがあります。テストのために、認証情報を含む画像URLを外部ツールへアップロードしないでください。
• CID形式の埋め込み画像：cid: 参照先はメール内のMIME添付ファイルです。Tempcaseの使い捨てメールでは添付ファイルのデータを保存しないため、この種の画像は表示できません。画像が表示されないことだけを根拠に、テンプレートの不具合と判断しないでください。
• プレビューの制限：セキュリティポリシーにより、スクリプト、フォーム、危険なリソースが削除される場合があります。元の本文や対象クライアントでの結果と照らし合わせてください。「完全に表示する」ために隔離機能を無効にしてはいけません。

バグ報告では「CID画像が現在のプレビューで表示されない」と「外部画像の読み込みがエラーになる」を別の証跡として記録しましょう。まとめて「メールの画像が壊れている」としないでください。

リンクは確認し、むやみにクリックしない

認証、配信停止、パスワード再設定などのリンクは、一度だけ実行できる操作を伴う場合があります。クリックして確認すると副作用が生じることがあり、ページを開くだけでもトークンが消費されたり、状態が変わったりする可能性があります。

まずテキストでリンクを確認します。プレースホルダーが置き換わっているか、ドメインが現在の環境のものか、プロトコルが正しいか、パラメーターがそろっているか、有効期限が文面と一致しているかをチェックしてください。スクリーンショットに表示されたボタンの文言だけでは、実際のリンク先は分かりません。期限切れの時刻を確認する必要がある場合は、パラメーターの見た目から推測せず、業務ルールと送信記録を照合してください。

遷移の確認が必要な場合は、リセット可能なテストアカウントと許可された環境を使って個別に実行し、操作結果を記録します。添付ファイルを共有する前に機密パラメーターを削除し、一度しか使えない完全なリンクを公開バグ管理ツールに貼り付けないでください。

HTMLとプレーンテキスト：意味は同じ、構成は異なる

HTMLメールのテストでは、見栄えの良い部分だけを確認してはいけません。システムがマルチパートメールを送信する場合は、プレーンテキストでも必要な情報が伝わるようにします。受信環境によってはリッチテキストが表示されないこともあります。

プレーンテキストを取得できない場合は、「未取得。送信側からの提供待ち」と記録します。HTMLのタグを取り除いただけのものを、実際に送信されたプレーンテキストとして扱わないでください。

実際のメールクライアントで確認する前に、テスト環境を明記する

Webプレビューは、変数や基本的なレイアウトを手早く確認するのに適しています。正式な確認では、対象ユーザーに合わせて実際のメールクライアントを選びましょう。たとえば、チームでよく使うデスクトップクライアント、スマートフォンのメールアプリ、Webメールなどです。すべての組み合わせをむやみに網羅する必要はありません。

各結果について、OS、クライアント名とバージョン、ライトモードまたはダークモード、外部画像の設定、表示幅、拡大率を記録します。ブラウザーの狭い画面でのプレビューは、スマートフォンのメールアプリと同じではありません。フォントの代替、CSSの対応状況、自動調整は環境によって異なります。

メールクライアント間で比較する場合は、同じバージョンと入力を使って送った、条件をそろえたテストメールを使います。変数の処理が異なる2通のメールを、単純にクライアントの違いとして扱わないでください。

テンプレートを比較するときは、条件を一つずつ変える

目的に合わせて4種類の入力を用意します。長いテキスト、未設定値、言語による長さの違い、狭い画面です。まず基準の入力で旧版と新版をテストし、その後、一度に一種類ずつ切り替えます。スクリーンショットの幅と拡大率を固定し、画面サイズの変化をテンプレートの不具合と取り違えないようにしましょう。

• 長いテキスト：ユーザー名、製品名、注文IDによって、コンテナーが広がったり操作を妨げたりしないか。
• 未設定値：任意項目が空のとき、句読点や余白だけが残らないか。
• 言語による長さの違い：フランス語やポルトガル語などの長い文でボタンが圧迫されないか。日本語の改行で意味が変わらないか。
• 狭い画面：本文やコードが横にはみ出さず、重要な操作が見分けられるか。

差分が見つかったら、入力と本文の差分を保存します。ピクセル差分だけではフォントのアンチエイリアスに左右されやすく、内容の意味の確認を代替できません。

引き継ぎに使えるバグ報告

担当者があなたの使い捨てメールボックスにアクセスしなくても、同じ確認を再現できるようにします。次のような簡潔な記録は、長いやり取りのスクリーンショットより役立ちます。

バグをクローズするときは、元の失敗時の証跡を上書きせず、再テストしたバージョンと結果を追記します。再現のために個人情報を伏せた値へ置き換えた場合は、その方法と、置き換え後も再現するかを記録してください。

使い捨てアドレスの期限が切れる前に、証跡を整理する

Tempcaseの使い捨てアドレスの有効期限は初期設定で3時間です。有効期限内に延長すると、リクエストごとに3時間追加され、1つのアドレスで最長24時間まで使えます。上限は変わらないため、何度も延長して無期限に保管することはできません。

引き継ぎに必要な内容は、期限が切れる前にチームの方針に従って安全に保存してください。延長しても、現在のテストに使える時間が増えるだけで、アーカイブが保証されるわけではありません。期限が切れるとアドレスとメールは削除され、復元できません。別のアドレスに切り替えると以前のアドレスは破棄されるため、添付ファイルを整理する前に切り替えないでください。

数日にわたってメールを受信するには、パスワードなしでログインして長期転送エイリアスを作成し、受信メールを実際のメールアドレスに転送できます。ただし、長期転送や限られた期間のアーカイブも、自分で作成するバグ記録や保管方針の代わりにはなりません。

次のステップ：確認結果を次のテストに活かす

メールが届いたら、メールテンプレートプレビューのワークベンチで入力を固定して再テストし、結果を同じ証跡パックに追加しましょう。メールがまだ届いていない場合は、まず認証コードが届かないときの確認を開き、アドレス、リクエスト、配信記録を確認してください。「スクリーンショットがない」から「テンプレートの不具合」と決めつけてはいけません。

再送の繰り返しやメールの順序が前後するケースでは、認証コード再送テストもご覧ください。証跡パックの価値は添付ファイルの数ではなく、一つひとつの結論を対応する入力と確認結果までたどれることにあります。