プレビューにコメントは付いたものの、どのテンプレートの修正を再確認すべきか分からない状態ですか。
最短の解決策は、レビュー対象の版を固定し、問題を記録して担当者を割り当て、修正版を再テストしたうえで、必要な場合は実際の受信も別に確認することです。 Mailgun Inspectのコメントやマークは協業を助けますが、修正完了や配信成功の証明にはなりません。
メールQA担当者は、スクリーンショットやチャットと対象テンプレートの食い違いを防ぎたい場合に役立ちます。
メール開発者は、指摘に沿った修正と、その変更が再確認された証拠を結び付けたい場合に役立ちます。
小規模チームの責任者は、問題ごとの担当者と検収記録を残したい場合に読み進めてください。
最終更新：2026年10月31日。Mailgunの公式更新ログと公開ドキュメントを確認しています。協業機能は公式更新ログで2026年10月20日の提供開始が確認できます。実際の画面や使える操作は、利用時点の公式資料も確認してください（Mailgun公式更新ログ）。
レビュー開始前に、対象メールと版を固定します
まず、誰がどのメールを確認するのかを明確にします。登録確認、パスワード再設定、購入通知など、レビュー対象のテンプレート名とテスト環境を決め、コミットIDやテンプレートの版など、後から対象を特定できる情報を記録してください。版を残さないままレビューを始めると、コメントが別のプレビューに対するものなのか、修正前のものなのか判別しにくくなります。
次に、確認するクライアントとプレビューの前提条件をそろえます。Inspectのプレビュー画面で表示を確認し、必要に応じてメールプレビューAPIの公式ドキュメントを参照します。プレビューを作成した日時や対象データが分かるようにしておくと、後で新旧の結果を取り違えるリスクを抑えられます。
レビュー前に、チーム内で次の項目を共有しておきます。
- 対象となるメールの用途とテンプレート名
- テスト環境と、レビューするプレビュー
- テンプレートの版、コミットIDなど変更を特定する情報
- 今回の合格条件と、実際の受信確認まで必要かどうか
コメントと問題マークを、再現できる指摘にします
Mailgunの公式更新ログでは、Inspectのウェブアプリにコメント、問題へのマーク、担当者の割り当てが追加されたことが案内されています。マークされたメールの絞り込みや、修正後の再テストにも触れられています。つまり、レビューコメントをプレビューに関連付けて共有する用途には使えますが、マークや担当者の設定だけで問題が解決したとは判断できません（公式更新ログの機能案内）。
コメントには、画面の見た目だけでなく、再現に必要な情報を含めます。たとえば「受信画面でボタンが下にずれている」だけでは、開発者が問題の場所や期待値を特定できないことがあります。対象クライアント、表示箇所、実際の状態、期待する状態をそろえて記録します。
- 対象クライアントと確認環境
- 問題が見える箇所（件名、本文、リンク、画像など）
- 実際に確認した表示や動作
- 期待する表示や動作
- 再現に必要な入力条件やデータ
このように書けば、Mailgun Inspectのコメントと問題マークを使ったレビューでも、指摘を修正作業に結び付けやすくなります。マークは「要確認」の目印として扱い、解決済みの判断は、修正後の確認を終えた人が行う運用にします。
担当者を決め、対応状況をチームで管理します
メールのプレビュー上の問題は、内容によって判断する人が異なります。文言やリンク先は製品担当者、レイアウトやテンプレートの不具合は開発者、合格条件に関わる問題はQA担当者が確認する、といった形で責任範囲を定めます。Inspectの指名機能で担当を割り当てる場合も、誰が何を確認するのかをコメントに残してください。
チーム内の状況は、少なくとも「修正待ち」「判断待ち」「修正後の確認待ち」「確認済み」のように区別すると、未解決の論点が見えやすくなります。これは運用上の提案であり、Inspectが自動で不具合票や承認状態を作るという意味ではありません。
修正担当者は、変更したテンプレートや実装箇所を指摘に関連付けます。QA担当者は、担当者が割り当てられたことやコメントが増えたことではなく、修正内容と再テスト結果を根拠に状態を更新します。問題と修正対象のつながりが切れると、後から同じ指摘を再確認する際に、どの変更が効いたのか追いにくくなります。
修正後は、最新のテンプレートで再テストします
修正を反映したら、該当するプレビューや検査を改めて実行します。確認前に、再テストの対象が最新のテンプレートまたは変更後のコミットであることを確かめてください。古いプレビューを開いたまま見比べると、修正が反映されていない状態を誤って合格とする可能性があります。
再テストでは、元の指摘を確認するだけでなく、その変更で別の表示やリンクに影響が出ていないかも見ます。Mailgunの更新案内には編集やバージョン記録、再テストに関する説明がありますが、表示や利用できる操作は現行の公式ヘルプと実際の画面で確認してください。再テストを実行した事実だけでなく、対象の版と結果を記録するのが重要です。
プレビュー合格後、実際の受信確認が必要か判断します
プレビューは表示やテンプレートの確認に使えますが、それだけでメールが送信されたことや、受信箱に届いたことは証明できません。SMTPでは、受信側サーバーがメッセージを受け入れた段階で、その後の扱いは受信側の責任範囲になります。したがって、送信処理の結果と受信箱での見え方は、別の確認項目として扱います（RFC 5321のSMTP受信責任に関する説明）。
受信確認が合格条件に含まれる場合に限り、自社製品からテストメールを送信し、管理されたテスト用アドレスで本文、リンク、対象環境を確認します。テストモードを使う場合は、Mailgunのテストモードの説明を読み、実際の配信を確認する試験と混同しないでください。テスト用の応答やプレビュー結果は、受信箱で読めることの代わりにはなりません。
実際に受信できた場合も、それはその試験条件における確認結果です。すべての受信サービスやクライアントで同じように届く保証にはなりません。受信できない場合は、送信処理、受信側の判定、迷惑メール扱いなどを切り分けます。届かない場合に確認する項目は、メールの確認コードが届かないときの手順も参考になります。
承認前に、レビューと受信の記録をそろえます
最終確認では、次の項目を埋めてから承認します。このチェック項目はチーム運用のための提案です。Inspect上のコメント数やマーク状態を、自動の品質ゲートとして扱わないでください。
- [ ] 対象メール、環境、テンプレートの版またはコミットIDを記録した
- [ ] 指摘に再現条件、実際の状態、期待する状態がある
- [ ] 各問題の担当者と対応状況を明確にした
- [ ] 修正後、最新のテンプレートで再テストした
- [ ] 受信確認が必要な場合、テストメールの実際の受信結果を記録した
- [ ] コメントやテストメールに不要な個人情報が含まれていない
記録には、対応した問題、修正対象、再テスト結果、実際の受信確認を実施したかを残します。承認は、あらかじめ決めた合格条件と確認記録に基づいて行い、コメントや指名の状態だけで公開可否を決めないようにします。テストデータに含める個人情報を見直す際は、テストデータとプライバシーに関する案内も確認できます。
実際の受信確認まで必要なメールでは、プレビュー確認と受信テストを別工程として記録するのが確実です。自社製品のメールを管理された受信先で確かめたい場合は、試験内容に合うテスト用アドレスを選び、利用条件を確認してください。登録方法や受信の仕様は、利用前にInboxCloakの案内で確認できます。受信確認の結果は、そのアドレスでの試験結果として扱い、すべての環境への到達保証とは区別してください。
必要な手がかりだけを持って、ツールに戻る
受信トレイに戻って実際のメールを確認してください。まだ届いていない場合は、個別の診断チェックリストを順に確認すれば十分です。画面全体を再び撮影する必要はありません。