2026 テスト用メールのプレーンテキスト版をどう検収する？

「HTMLの見た目は整ったのに、テキスト版が空かどうか分からない」という症状が残っていませんか。
今週は、実際に届いたメールのtext/plainを確認し、HTML版と重要な情報・操作意図が一致するか検収してください。ローカル生成や送信関数の成功だけでは、受信の証拠になりません。

自社サービスのHTMLメールに、読めるテキスト版が含まれるか確認したい開発者向けです。
テンプレートを検収し、実際の受信まで証拠を残したいQA担当者にも役立ちます。
登録、通知、トランザクションメールを保守する個人開発者も対象です。

検収対象と証拠の境界を先に決める

まず、確かめたいことを分けます。メールの生成、MIME構造、送信処理の結果、テスト受信先での実際の可読性は、それぞれ異なる証拠です。アプリのログに本文が表示されても、受信側に届いたことや、受信メールにテキスト版が含まれることまでは示しません。

検証対象は、自社製品または明確に許可された環境から送るメールに限定します。テスト用の名前やアドレスには実在する個人の情報を使わず、確認したいメールの種類、実行環境、今回のテストと結び付けられる識別情報を決めておきます。識別情報は件名や本文のテスト用文字列など、個人情報を含まない形にします。

テストメールにtext/plainが含まれるかは、どう確認しますか。
アプリのテンプレート定義だけで判断せず、送信対象として組み立てられたメールのMIMEソースを確認します。本文がmultipart/alternativeで構成されている場合は、各パートのContent-Typeを見て、text/plainのパートがあるかを確かめます。MIMEのメディアタイプとパートの扱いは、RFC 2045の仕様およびRFC 2046の仕様で確認できます。

生成時は本文パートと順序を照合する

自社アプリから、対象の登録確認メールや通知メールを実際に生成します。テスト実行と結び付けられる識別情報を付け、生成されたメールのMIMEソースを取得してください。テンプレート上にテキスト用の変数があっても、送信処理で空になったり、本文に組み込まれなかったりする可能性があります。

multipart/alternativeは、同じ内容を異なる形式で表す本文パートをまとめる構造です。RFC 2046では、代替パートを表現の忠実度が低いものから高いものへ並べ、最後のパートを受信側が最も望ましい形式として扱えるようにする意味が定められています。これはMIME構造の意味であり、特定のメールクライアントが常に同じ表示をするという保証ではありません。RFC 2046の該当節を基準に、構造の検査と画面上の表示確認を混同しないようにします。

確認時は、text/plainの有無に加え、本文パートの内容が空でないか、文字コード情報と実際の文字列に不整合がないかを確認します。文字化けがある場合は、テンプレートの文字列だけでなく、メールを組み立てる過程の文字コードと転送エンコーディングも調べます。UTF-8の符号化方式はRFC 3629で定義されています。

テキスト版を単独で読んで意味を確認する

HTML版から装飾やタグを取り除いただけでは、テキスト版として十分とは限りません。メールの目的、必要な説明、リンク先を判別できる表記、受信者が行う操作が、テキストだけで理解できるかを確認します。HTMLの断片、テンプレート変数、意味のない空白だけが残っていないことも見ます。

テキスト版とHTML版の内容が異なる場合は、どう検収しますか。
文面を逐語的に一致させる必要はありません。重要なのは、期限や条件、操作手順、リンク先など、利用者の判断や次の操作を変える情報が両方にあることです。HTML側だけに重要な説明がある、リンクの目的がテキスト側から分からない、操作手順が変わっている場合は修正対象にします。

送信処理の後にテスト受信先を確認する

続いて、許可されたテスト用受信先で、今回送ったメールを確認します。アプリの送信ログや送信関数の戻り値は、処理が行われたことの記録にはなりますが、受信先で読める状態になった証明とは別です。受信メールが見つかったら、件名やテスト用識別情報を照合し、対象の実行と対応付けます。

テスト受信先で実際のテキスト版を見るには、何をしますか。
受信メールを開いてプレーンテキスト表示、または確認可能なMIMEソースを調べます。ソースを取得できる環境では、multipart/alternativeの構造とtext/plainパートの内容を記録します。画面上のテキスト表示しか見られない場合、確認できたのはその受信環境での見え方です。MIMEの構造そのものを確認できたとは記録しません。

メール形式の基本構造では、ヘッダーと本文が空行で区切られます。RFC 5322を参照すると、MIMEソースのどこを見ているのか整理しやすくなります。ただし、仕様の確認だけでは個別の受信環境への到達や表示結果は立証できません。

不一致と未着を分けて再検証する

multipart/alternativeの検査では、どこまで見ればよいですか。
構造上の存在確認、テキスト単体での可読性、HTML版との重要情報の照合、実際の受信を分けて確認します。構造だけを見れば、テキストの文章が適切かどうかは分かりません。受信画面だけを見れば、元のMIMEパート構成を確認できない場合があります。

不具合が見つかったときは、内容の問題と受信の問題を分けます。

• 受信メールにtext/plainがない場合は、メール生成処理とMIME組み立てを見直し、修正後に再送します。
• テキスト版が空、文字化け、または読めない場合は、本文の生成と文字コード・エンコーディングの処理を調べます。
• HTML版とテキスト版で重要な説明や操作が異なる場合は、テンプレートの内容をそろえて再検収します。
• テスト受信先に届かない場合は「受信未確認」と記録します。ローカルの本文確認を、実際の受信成功として扱いません。

たとえば、登録確認メールを送るテストで、アプリのログには本文が残っているのに受信箱にメールがないことがあります。この場合、テキスト本文の生成確認と受信確認は別々の判定です。まず受信を確認できる状態にし、その後で実メールの内容を再検査します。

条件に応じて検収方法を選ぶ

以下の判定リストで、必要な証拠に合う方法を選びます。該当する項目を確認し、条件を満たさない場合は判定を広げず、確認できた範囲に戻して記録してください。

• [ ] MIMEソースを取得できる：multipart/alternativeとtext/plainの有無、本文の内容を確認します。取得できない場合は、MIME構造の合否を出さず、表示内容だけを検収します。
• [ ] テスト受信先にメールが届いている：受信後の読みやすさを確認します。届いていない場合は、内容の合否ではなく「受信未確認」とします。
• [ ] プレーンテキスト表示しか確認できない：読める内容とHTML版との重要情報の一致を確認します。MIME構造まで検証済みとは扱いません。
• [ ] 短期の登録・通知テストで個人の受信箱を使いたくない：一時受信先を選択肢にします。継続的な連絡やアカウント復旧には、長期管理できる専用アドレスを使います。
• [ ] 重要な説明や操作手順が片方の形式にしかない：合格にせずテンプレートを修正して再送します。意味が変わらない装飾や言い回しの違いには、逐語一致を求めません。

テスト用受信先の選び方は、一時受信アドレスの使いどころをまとめた案内も参考になります。テストに実データを持ち込まない方針は、メール利用時のプライバシー情報と合わせて確認できます。

検収記録は今回確認した範囲に限定する

記録には、対象にしたメールの種類、実行環境、受信の有無、テキスト版で確認できた内容、照合に使った証拠を残します。MIMEソースを確認できたか、利用者に見える表示だけを確認したかも明記してください。未確認の受信環境や、テストしていないメール種別は、結果の適用範囲に含めません。

判定は「今回のテストメールについて、指定した受信環境で確認できた」と表現します。すべてのメールクライアントで同じ表示になる、すべての受信先に届く、といった結論へ広げないことが重要です。

テキスト版の検収では、主メールアドレスをテストデータに使わず、受信確認とMIME確認を別の証拠として扱うことが重要です。短期の登録・通知テストで受信先を分けたい場合は、PostTmpの一時受信先も選択肢になります。継続利用や返信、重要アカウントの復旧に使うアドレスとは分け、今回のテストで実際に確認できた範囲だけを記録してください。