ECのメール通知を「送ったつもり」で終わらせない｜配信証跡・テンプレート変更・復元を管理する実務台帳

注文完了や配送完了の通知、問い合わせへの個別返信、メルマガは、いずれも顧客との重要な接点です。一方で、送信後に「どの文面が、いつ、誰に送られたのか」を再現できなければ、問い合わせ対応や誤記の調査に時間がかかります。

ここで扱うのは、開封率やクリック率を上げるためのメール施策ではありません。送信した事実、確定した文面、変更した経緯、復元できる原本を残すためのEC メール 配信履歴 管理です。

確認日：2026年8月28日。画面や機能は契約プラン、導入アプリ、カスタマイズ、バージョンによって異なるため、実際の管理画面と契約内容でも確認してください。

最初に決めるべきことは「メールを3種類に分ける」こと

メールを一律に「配信履歴」として管理すると、必要な確認項目が混ざります。まず、以下の3種類に分けます。

同じ「配送についてのメール」でも、自動通知か担当者の個別連絡かで、確認場所と保存方法は異なります。台帳の先頭に区分を設けると、CS、運用、マーケティング、制作担当の間で確認範囲を揃えやすくなります。

カートの履歴で確認できる範囲を先に切り分ける

標準機能の画面だけで、すべてのメールを追えるとは限りません。運用を作る前に、「画面で確認できるもの」と「別途証跡を残すもの」を切り分けます。

makeshop：注文詳細のメール履歴は任意送信が対象

makeshopの公式マニュアルでは、注文詳細で確認できるメール送信履歴として、任意送信の「注文完了メール再送」「テンプレートメール送信」が案内されています。一方、自動送信設定による注文完了メール、配送完了メールなどは、その履歴に表示されないと明記されています。

したがって、makeshopでの確認設計は次のように分けるのが安全です。

• 担当者が任意送信したメール：注文詳細のメール送信履歴を、一次確認箇所にする
• 自動送信の注文・配送通知：注文詳細の履歴だけで送信内容を証明できる前提にしない
• 自動通知の文面変更：変更前後のテンプレート原本、変更日時、承認者、テスト受信結果を外部台帳に残す

「注文があるので通知も送られたはず」と、注文ステータスから推測する運用は避けます。送信の成否、実際の受信、迷惑メール振り分けなどは別の論点です。本記事の台帳では、少なくともどの設定・どの文面を送る設計だったかを説明できる状態を確保します。

makeshop：販促メールは利用機能と契約条件を確認する

makeshopの「メール配信プラス」では、作成したメールの送信状況を確認できます。ただし、同機能の利用にはオプションの申し込みが必要です。販促メールの証跡を管理画面で確認する設計にする前に、利用中の契約・機能で対象画面を使えるかを確認してください。

配信状況を見られる場合でも、運用台帳には最終確定版のHTMLまたはテキスト、件名、配信対象の抽出条件、配信日時を残します。管理画面の表示期間、担当者の権限変更、配信設定の上書きがあっても、当時の配信を説明しやすくするためです。

EC-CUBE：メール設定の編集を「ファイル管理」として扱う

EC-CUBE公式の4.2から4.3系への更新ドキュメントでは、変更対象にメールテンプレートを含めて確認し、管理画面の店舗設定にあるメール設定から編集する手順が示されています。メールテンプレートは、日常の文言修正だけでなく、バージョンアップや改修時の影響確認対象です。

EC-CUBEは構成やプラグイン、個別カスタマイズによって確認手順が変わり得ます。画面上で編集できることと、変更履歴や復元元が自動的に残ることは別です。更新や改修を行う場合は、作業前にテンプレート原本を退避し、反映後はテスト受信までを変更作業に含めます。

配信証跡は「送った記録」ではなく6点セットで残す

問い合わせや障害対応で必要なのは、「メールを送った」というメモだけではありません。通知種別を問わず、次の6点を基本単位にします。

1. 対象：注文番号、配信リスト名、セグメント条件、対象件数など
2. 確定文面：件名、差出人、本文、リンク先、添付の有無
3. 日時：予約日時、実配信日時、変更日時。分かる範囲で記録する
4. 根拠画面：注文詳細、配信結果画面、テスト受信メールなどの確認場所
5. 承認・実施者：依頼者、確認者、公開・送信を実施した担当者
6. 復元元：変更前テンプレート、保存先、版番号、ロールバック手順

確定文面の保存形式は、チームが復元・閲覧しやすいものに統一します。例えば、HTMLメールはHTMLファイルとテキスト版、画面表示の確認用スクリーンショット、テスト用受信箱に届いたメールを組み合わせます。画像だけではコピー可能な本文やリンク先が分かりにくく、HTMLだけでは受信時の崩れを見落とす可能性があります。

個人情報を含む注文情報や宛先を保管する場合は、共有範囲、保管場所、削除・保存期間を自社の情報管理ルールに合わせて決めてください。台帳には、必要以上に顧客の氏名・メールアドレスを転記せず、注文番号や配信IDで参照できる設計が扱いやすくなります。

1枚で運用するメール管理台帳の項目

スプレッドシート、チケット管理ツール、社内ドキュメントのいずれでも構いません。重要なのは、メール本文を別の場所に保存した場合にも、台帳から確実にたどれることです。

以下は、通知テンプレートと販促メールの両方に使える項目例です。

台帳を増やしすぎないための基準

すべての個別返信を、テンプレート変更と同じ粒度で承認する必要はありません。たとえば、注文に紐づく定型の個別連絡は、注文詳細の履歴と担当者名を確認できるなら、台帳には例外対応だけを記録する設計も選べます。

反対に、顧客への影響が大きい次の変更は、台帳への記録と承認を省略しないほうがよい対象です。

• 注文、決済、配送、返品・キャンセルに関する自動通知
• 差出人名、返信先、問い合わせ先、リンク先の変更
• クーポン、価格、条件、期限を含む販促メール
• 外部委託先や複数部署が編集・配信に関わるメール

テンプレート変更を公開まで管理する5ステップ

メールの誤りは、本文だけでなく、差出人、差し込み項目、リンク、送信タイミングでも起こります。変更依頼から公開後確認までを分けます。

1. 変更依頼を文章で確定する

依頼には「何を変えるか」だけでなく、「変えない箇所」を書きます。たとえば注文完了メールの問い合わせ先だけを更新するなら、件名、差し込み項目、注文情報、フッターは変更対象外と明記します。

依頼票には、対象テンプレート名、目的、希望反映日時、影響する通知、文面案、確認担当を含めます。口頭やチャットだけで進めると、後から変更意図を確認しにくくなります。

2. 変更前の原本を退避して版番号を付ける

管理画面で直接上書きする前に、現行版の本文と設定値を保存します。保存ファイル名には、テンプレート名、版番号、保存日を含めると参照しやすくなります。

例：order-confirmation_v03_20260828.html

テンプレート本文のほか、件名、差出人名、返信先、利用している差し込み項目も同じ記録に残します。本文だけを戻しても、返信先設定などが変わっていれば、完全な復元にはなりません。

3. テスト送信で内容と表示を確認する

テスト用の受信先を用意し、可能ならPCとスマートフォンの両方で確認します。確認項目は次のとおりです。

• 件名、差出人名、返信先が意図どおりか
• 注文番号や氏名などの差し込み項目が想定どおりに表示されるか
• リンク先、リンクパラメータ、画像が正しいか
• テキストとHTMLで内容が矛盾していないか
• 変更対象外とした箇所が変わっていないか

自動通知では、本番の顧客注文をテストに使わない方法を、利用中の環境に合わせて定めます。検証環境がない、または本番でしか確認できない場合は、テスト方法そのものを台帳に残し、実施できない確認項目を明示します。

4. 承認後に公開し、公開版を改めて保存する

承認者は、依頼票とテスト受信結果を見て、公開する版を特定できる状態で承認します。「確認済み」だけでは、どの本文を承認したか曖昧です。管理IDまたは版番号を承認記録に含めます。

公開後は、管理画面の設定値または公開後のテスト受信を確認し、保存した確定文面と一致するかを照合します。この照合で、別の担当者による同時編集や、反映漏れに気づけます。

5. 復元条件と担当を決める

復元手順は、「問題が起きたら戻す」といった抽象的な記載では機能しません。少なくとも以下を台帳に書きます。

• 戻す原本の保存先と版番号
• 復元操作を行える担当・権限者
• 復元後に実施するテスト送信と確認者
• 顧客への追加連絡が必要になった場合の判断者

EC-CUBEのように改修やバージョンアップでメールテンプレートも確認対象となる環境では、公開前退避を定例化すると、更新作業時の確認漏れを減らせます。

問い合わせ・誤配信時に台帳をどう使うか

証跡は保管自体が目的ではなく、短時間で事実関係を切り分けるために使います。問い合わせを受けたら、次の順で確認します。

1. 問い合わせ対象の注文番号、メールアドレス、受信日時、件名を聞き取る
2. 対象メールが自動通知・個別送信・販促メールのどれかを判定する
3. 注文詳細や配信画面で確認可能な履歴を確認する
4. 台帳から該当日時の確定文面、版番号、変更履歴、テスト結果を参照する
5. 実際に案内した内容、設定されていた内容、確認できない事項を分けて回答方針を決める

makeshopでは、自動送信の注文完了メールや配送完了メールが注文詳細の履歴に表示されないため、自動通知について注文詳細だけで結論を出さないことが重要です。該当時点のテンプレート版と、公開後確認として保存した受信控え・画面記録を確認します。

販促メールで対象者の確認が必要な場合は、配信対象を抽出した条件、除外条件、配信日時を台帳からたどります。配信後に顧客情報やセグメント条件が変わっている場合、現在の検索結果を当時の対象者とみなさないよう注意します。

月次で見直すチェックリスト

台帳は作成直後より、運用変更や担当交代の後に抜けが出やすいものです。月次または大きなキャンペーン前に、次を確認します。

• 自動通知、個別送信、販促メールの一覧に漏れがない
• 各メールに、責任部署・担当者・承認者が定義されている
• 変更前原本と公開版の保存先に、担当者がアクセスできる
• テスト用受信先が有効で、必要な確認ができる
• makeshopの利用機能・契約条件に照らして、配信状況の確認方法が現状と合っている
• EC-CUBEの改修・更新予定に、メールテンプレートの退避とテストが含まれている
• 復元手順を、実際に権限を持つ担当者が実行できる

メール運用を整える際、最初から全通知の履歴を完全に集約しようとすると、現場の負荷が上がります。まずは注文・配送・決済に関わる自動通知と、配信規模の大きい販促メールから台帳化し、問い合わせ時に確認頻度が高いものを優先して広げてください。

「画面で見られる履歴」と「自社で残すべき証跡」を分けることで、カートの標準機能の範囲に依存しすぎず、変更・照合・復元を継続できる運用になります。

参考情報

• makeshop オンラインマニュアル：注文詳細
• makeshop オンラインマニュアル：メール配信プラス：配信の確認
• EC-CUBE 4 開発者向けドキュメント：4.2から4.3本体バージョンアップ
• EC-CUBE GitHub Issue #7053：メールテンプレート保存後デフォルトシステムテンプレートも削除可能になってしまいます。
• ITreview：makeshopの評判・口コミ 全76件