この記事の対象: ShopifyでのEC構築・リニューアルを検討している事業者、既存ストアの運用担当者
読了時間: 約12分
Shopifyでストアを開いた直後、商品ページやトップの見た目は何度も直すのに、通知メールだけが初期設定のまま残っているケースはよくあります。購入後の顧客が一番よく見る自社発の画面は、実はサイトではなくメールです。注文確認、発送通知、キャンセル、アカウント作成——Shopifyが自動で送るメールは多数あり、そのすべてが自社名義で顧客の受信箱に届きます。この記事では、Shopifyの通知メールのテンプレート編集をどこから手を付けるべきか、どこまでが管理画面の共通設定で済んでどこからHTML編集が必要かを、制作と運用の両方の立場から整理します。
Shopifyの通知メールは何種類あり、どこで編集するのか
管理画面のどこにあるか
編集の入口は 設定 → 通知(Settings → Notifications) です。ここに顧客向け・スタッフ向けの通知が一覧で並んでいます。日本語ストアであれば、Shopifyが用意した日本語文面が最初から入っています。
通知は大きく次のグループに分かれます。
| グループ | 主な通知 | 顧客が見る頻度 |
|---|---|---|
| 注文 | 注文確認、注文編集、注文キャンセル、注文の返金 | 購入すれば必ず1通 |
| 配送 | 発送通知、追加の発送通知、配送状況の更新、配達完了 | 発送のたび |
| 受け取り・ローカル配送 | 店舗受け取りの準備完了、受け取り完了、ローカル配送 | 該当機能を使う場合のみ |
| 顧客アカウント | アカウント作成の招待、パスワード再設定、アカウントウェルカム | 会員機能を使う場合 |
| カート・見込み | 放棄されたチェックアウト、在庫入荷通知(機能・アプリ依存) | 設定次第 |
| 返品・交換 | 返品指示、返品ラベル、返品確認 | 該当時のみ |
| スタッフ向け | 新規注文、注文のキャンセル、ピッキングリスト | 顧客は見ない |
通知の種類と名称はShopify側の仕様変更で増減します。着手前に自分のストアの管理画面で一覧を開き、実際に並んでいるものを数えるところから始めてください。ここに挙げたグループ分けは、そのときの分類の目安として使えます。
最初に押さえておきたいのは、「顧客が見る通知」と「スタッフしか見ない通知」を分けて考えるという一点です。スタッフ向けの通知に時間をかけてブランドの体裁を整えても、外からは誰も見ません。逆にスタッフ向けは「必要な情報が抜けていないか」だけが論点になります。ピッキングリストであれば商品名とSKUとロケーション、新規注文通知であれば決済手段と配送方法。体裁ではなく、その情報だけを見ます。
テンプレートの実体はLiquid入りのHTML
各通知を開くと、HTMLエディタが現れます。中身はShopifyのテーマと同じくLiquidが埋め込まれたHTMLです。{{ shop.name }} や {{ order.name }} のような変数、{% if %} による条件分岐がそのまま使えます。
テーマファイルとは別管理で、テーマを差し替えても通知テンプレートは引き継がれます。ここは制作の現場でよく誤解される部分です。テーマを新しくしても通知メールは古いまま残るので、リニューアル案件では必ず別チェック項目として立てておく必要があります。
テーマ(オンラインストア)
- 商品ページ・トップ・カート
- テーマ切替で丸ごと入れ替わる
- Gitやテーマライブラリで管理できる
通知テンプレート(設定)
- 注文確認・発送通知など多数
- テーマを変えても残り続ける
- 管理画面のエディタが唯一の編集口
リニューアルで見た目を一新したのに、購入後に届くメールだけ旧ロゴのままだった——という事故は、この分離を知らないまま進めると普通に起こります。そして厄介なことに、事故が起きても制作側にはまず気づけません。届く先は顧客の受信箱で、制作側の手元には来ないからです。
通知メール編集の優先順位|全部やらずに3段階で分ける
種類が多いものを一度に整えようとすると、必ず途中で止まります。実際に運用してみると、手を入れる価値の大きさには明確な差があります。優先順位は「顧客が見る確率 × 見たときに困る度合い」で決めるのが実務的です。
第1段階:全通知に効く共通部分
ここだけは最初に必ずやります。所要時間は短く、効果は全通知に波及します。
- ロゴ画像(設定 → 通知 → 「ブランディングをカスタマイズ」相当の項目、またはテンプレート内の画像指定)
- アクセントカラー(ボタン・見出しの色)
- 送信元メールアドレス(Shopifyの既定ドメインからの自社ドメイン化)
- ストア名の表記ゆれ(「株式会社◯◯」なのか「◯◯オンラインストア」なのか)
送信元アドレスの自社ドメイン化は、見た目の問題ではなく到達率の問題です。Shopifyの既定ドメインから送られたままだと、受信側から見て「差出人は自社名だが送信ドメインは別」という状態になります。自社ドメインで送るにはDNSにSPF・DKIMのレコードを追加する必要があり、これは管理画面だけでは完結しません。ドメイン管理者との調整が要る作業なので、公開直前ではなく構築の早い段階でスケジュールに入れておきます。
表記ゆれは軽視されがちですが、差出人名は受信箱の一覧で最初に目に入る要素です。サイト上は「◯◯ストア」、メールの差出人は「株式会社◯◯」、決済の明細は「カブシキガイシャ◯◯」と3つに割れていると、顧客側では別の店に見えます。カード明細に出る名義まで含めて、どの表記に寄せるかを最初に1回決めておきます。
第2段階:注文確認と発送通知
顧客が確実に開く2通です。この2通だけは文面を最後まで読み直します。
注文確認メールで見るべきところ
- 注文番号の表示形式(
#1001のままか、接頭辞を入れるか) - 配送予定日・発送目安の記載(Shopify標準の文面には入っていない)
- 問い合わせ先(メールアドレスだけでなく、営業時間や返信目安)
- キャンセル・変更の可否と締切
- 領収書・請求書の扱い(別途発行が必要かどうか)
発送通知メールで見るべきところ
- 追跡番号のリンクが正しく機能するか(配送会社の設定と連動)
- 「発送しました」の後に何をすればいいかが書いてあるか
- 複数配送に分かれた場合の説明
標準の日本語文面は事務的には正しいのですが、「届かなかったらどうすればいいか」が書かれていません。ここに1行足すだけで問い合わせが減ります。運用している側から見ると、通知メールの改善はカスタマーサポートの工数削減として効いてくる部分が大きい。デザインの話に見えて、実際には業務設計の話です。
とくに効くのが、注文確認メールの「発送目安」です。「ご注文ありがとうございました」だけで終わっていると、翌日には「いつ届きますか」という問い合わせが来ます。「通常3〜5営業日以内に発送します。土日祝を挟む場合は翌営業日以降の対応となります」と書いてあれば、その問い合わせは発生しません。日数はストアごとに違うので、事業者に実際の運用を聞いて入れます。
第3段階:例外系の通知
キャンセル、返金、返品、パスワード再設定。頻度は低いものの、届く場面が「顧客が不安になっている瞬間」に集中しています。
ここで標準文面のまま放置していると、機械的で冷たい印象になります。かといって過剰に情感を込めると不自然です。実務では次の3点を満たしていれば十分です。
- 何が起きたのかが1行目でわかる
- 顧客側でやることがあるかないかが明記されている
- 想定される待ち時間(返金の着金まで何日か等)が書いてある
とくに返金通知は、「返金処理をしました」だけで終わっていると「いつ口座に戻るのか」の問い合わせが必ず来ます。クレジットカードの場合はカード会社の締め日の関係で反映まで時間がかかることを一文添えておくだけで、この問い合わせは大きく減ります。実際の日数は決済手段とカード会社によって変わるため、断定した日数を書くより「カード会社の締め日により、翌月または翌々月の明細での相殺となる場合があります」のように幅を持たせた書き方のほうが安全です。
パスワード再設定は不安の通知ではありませんが、別の理由で確認が要ります。この通知だけは、リンクの有効期限が切れていると顧客が先に進めません。文面に有効期限を明記しているか、期限切れのときに再送する導線があるかを見ておきます。
この順で進めると、途中で予算や時間が尽きても「一番効くところは終わっている」状態になります。逆順でやると、誰も読まないスタッフ向け通知の体裁を整えて力尽きます。
共通で変える部分と個別に直す部分の線引き
共通化できるものは3つ
Shopifyの通知テンプレートは、それぞれが独立したHTMLとして存在します。つまり「1か所直せば全部に反映される」構造ではありません。共通化できるのは次の3つに限られます。
| 変えたいもの | 共通で効くか | 方法 |
|---|---|---|
| ロゴ画像 | 効く | 通知設定のブランディング項目 |
| アクセントカラー | 効く | 同上 |
| 送信元アドレス | 効く | ストア設定+DNS |
| フッターの会社情報 | 効かない | 各テンプレートに個別記述 |
| 文面・見出し | 効かない | 各テンプレートを個別編集 |
| レイアウト構造 | 効かない | 各テンプレートのHTMLを個別編集 |
フッターが共通化できないのは、運用上いちばん厄介な点です。特定商取引法に基づく表記へのリンク、住所、問い合わせ先、SNSアカウント——これらを全通知に入れたい場合、テンプレートの数だけコピー&ペーストすることになります。
コピペ運用を前提に設計する
共通化の仕組みがない以上、「あとから全部を一括で直せない」前提でフッターを設計するのが現実的な判断です。
具体的には、フッターに入れる情報を最小限に絞ります。
<!-- 通知メールのフッター:変更頻度の低い情報だけに絞る -->
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr>
<td style="padding:24px 0; border-top:1px solid #e5e5e5; text-align:center;
font-size:12px; line-height:1.8; color:#777;">
<p style="margin:0 0 8px;">{{ shop.name }}</p>
<p style="margin:0 0 8px;">
<a href="{{ shop.url }}/pages/contact"
style="color:#777; text-decoration:underline;">お問い合わせ</a>
|
<a href="{{ shop.url }}/policies/legal-notice"
style="color:#777; text-decoration:underline;">特定商取引法に基づく表記</a>
</p>
<p style="margin:0;">このメールは注文に関する自動送信です。</p>
</td>
</tr>
</table>
なぜこう書くのか
- 住所・電話番号を直接書かず、
{{ shop.url }}経由でポリシーページへ飛ばしています。移転や電話番号変更のたびに全テンプレートを直すのは現実的ではないため、変わりうる情報はサイト側に置いて、メールにはリンクだけを残します {{ shop.name }}を使うことで、ストア名の変更に自動追従します<table>を使っているのは、Outlookなど一部のメールクライアントでdiv+flexのレイアウトが期待通りに解釈されないためです。メールHTMLでは現在もテーブルレイアウトが最も安全です- スタイルはすべてインライン記述です。
<style>タグ内のCSSは、一部のメールクライアントで削られることがあります
対応状況: 上記はGmail(Web/iOS/Android)、Apple Mail、Outlook(Windows デスクトップ/Web)を想定した書き方です。テーブルレイアウトとインラインCSSはメールHTMLの標準的な手法で、特定バージョン依存の記述は含んでいません。実際にどう見えるかは受信環境で変わるため、後述の実機確認は省けません。
つまずきやすい点
1. プレビューと実機で見え方が違う
管理画面のプレビューは実際の受信環境を再現しません。とくにダークモードの扱いは差が大きく、プレビューで問題なくても、ダークモード設定のメールアプリで白背景のロゴが背景と同化することがあります。透過PNGのロゴを使う場合は、ダークモードで文字が消えないか実機で確認します。背景色を持たせたロゴ(白地の余白を含むPNG)に差し替えるほうが、環境差に強くなります。
2. テスト送信の宛先が限られる
Shopifyの「テストメールを送信」は、管理画面にログインしているアカウントのメールアドレス宛に送られます。複数のメールクライアントで確認したい場合は、テスト用の注文を実際に作って送るほうが確実です。ステージング用のストア、あるいはテスト決済モードを使って、注文確認から発送通知までを一通り流します。
このとき、確認用のメールアドレスをGmail・キャリアメール・Outlookで最低3つ用意しておくと、1回のテスト注文で3環境ぶんの結果が取れます。顧客アカウントのメールアドレスを差し替えながら注文を作り直すより早く終わります。
3. 変数が空のときの見え方
{{ order.shipping_address.company }} のように、入力されないことのある変数をそのまま書くと、空行や不自然な余白が残ります。条件分岐で囲みます。
{% if order.shipping_address.company != blank %}
<p style="margin:0;">{{ order.shipping_address.company }}</p>
{% endif %}
blank は空文字とnilの両方を判定します。!= "" だとnilを拾えないため、Liquidでは blank を使うのが定石です。同じ扱いが要るのは、建物名(address2)、電話番号、注文メモ、ギフトメッセージあたりです。テスト注文を作るときに、これらを空にしたパターンを1件混ぜておくと一度に確認できます。
4. 元に戻す手段を先に確認する
各テンプレートの編集画面には「デフォルトに戻す」ボタンがあります。編集を始める前に、元のHTMLを丸ごとコピーしてテキストファイルに保存しておくことを勧めます。デフォルトに戻せば初期状態には戻りますが、「一度カスタマイズした後の、少し前の状態」には戻せません。バージョン管理の仕組みがないのが通知テンプレートの弱点です。
運用に乗せるなら、編集後のHTMLも同じ場所に保存しておきます。ファイル名を「notification-order-confirmation-2026-09-10.html」のように通知名と日付で揃えておけば、担当者が代わっても「今の本番はどれか」が分かります。Gitリポジトリの片隅に置いておくのがいちばん確実です。
アプリで足りる範囲と、テンプレート編集が必要な範囲
判断の分かれ目は「送るタイミングを変えたいかどうか」
通知メール関連のアプリは、大きく2種類あります。
メールテンプレートのデザインを整えるタイプは、GUIでレイアウトを組み立て、Shopifyの通知テンプレートに書き出します。HTMLを触りたくない、社内にコードを書ける人がいない場合の選択肢です。無料枠のあるものから月額課金のものまで幅があります(料金は変動するため、各アプリのページで最新を確認してください)。
マーケティング配信を担うタイプは、放棄カートの追い掛け、購入後のフォローアップ、レビュー依頼など、Shopify標準の通知にはないタイミングでメールを送ります。こちらは通知テンプレートの置き換えではなく、別レイヤーの機能です。
線引きはシンプルです。
テンプレート編集で足りる
- ロゴ・色・文面を自社に寄せたい
- フッターに情報を足したい
- Shopifyが送るタイミングのままでよい
- 月額を増やしたくない
アプリが必要
- Shopifyが送らないタイミングで送りたい
- 配信結果(開封・クリック)を測りたい
- セグメント別に内容を出し分けたい
- 非エンジニアが日常的に編集する
「ロゴを入れて文面を整えたい」だけであれば、アプリは要りません。標準機能とHTML編集で完結します。ここを最初にアプリで解こうとすると、月額が積み上がるうえに、解約したときにテンプレートがどう戻るかという問題を抱え込みます。
導入後に効いてくる論点
アプリを選ぶ局面では、機能一覧よりも次の4点を見ます。
月額の積み上がり
通知メール用に1本、レビュー依頼に1本、在庫入荷通知に1本——と積み上げると、単体では小さい金額が年間では無視できない額になります。Shopifyアプリの費用は運用フェーズの固定費です。制作費の話とは別枠で、年単位の維持費として見積もりに入れておく必要があります。判断するときは、月額をそのまま12倍して年額で並べ直すと比較しやすくなります。
解約時に何が残るか
テンプレートを書き出すタイプのアプリは、解約後もShopify側に書き出されたHTMLが残ることが多い一方、アプリ独自のタグやトラッキング用の画像が残ると、リンク切れや画像の読み込み失敗を起こします。導入前に「解約したらどうなるか」をサポートに確認しておくと、後の判断が楽になります。確認の返信はスクリーンショットで残しておくと、数年後に担当が代わっても根拠が追えます。
管理画面を触る人の負担
GUIエディタは「コードを書かなくていい」代わりに、操作を覚える対象がひとつ増えます。月に1回も触らない機能なら、そのたびに使い方を思い出すコストのほうが大きくなります。担当者が年に数回しか触らない前提なら、シンプルなHTMLをこちらで用意して置いておくほうが結果的に運用しやすいこともあります。
最終更新日とサポート体制
アプリストアのページで最終更新日を見ます。長期間更新が止まっているアプリは、Shopify側の仕様変更に追従していない可能性があります。あわせて、日本語対応の有無、サポートの返信言語、レビューの中身(星の数ではなく、直近のレビューに何が書かれているか)を確認します。
制作会社として通知メールをどう扱っているか
リニューアル案件では必ずチェック項目に立てる
冒頭で触れたとおり、テーマの入れ替えでは通知テンプレートは変わりません。デザインを刷新した案件で、公開後に旧ロゴのメールが届き続けるのは、単純に工程から抜け落ちた結果です。
自社でもShopifyストアを運営していて、Dawnをベースにカスタマイズしながらアプリに頼らず自前で実装している機能もあります。実際に運用してみると、通知メールは作ったあとに一番忘れられる場所だと感じます。サイトは毎日見るので気づきますが、メールは自分宛には届かない。だからこそ、公開前チェックリストに機械的に入れておくのが唯一の解決策になります。
具体的には、公開前チェックリストの「オンラインストア」項目とは別に「通知メール」の行を立て、テスト注文の実施日と確認した受信環境を記入させる形にしています。項目が独立していれば、埋まっていないことが一目で分かります。
Dawnテーマ側のカスタマイズ方針については、アップデートへの耐性を含めて別記事で整理しています。
文面は誰が書くのかを決めておく
制作側がHTMLの構造とデザインを整え、文面はクライアント側が書く——という分け方が多いのですが、これが曖昧なまま進むと、標準文面のまま公開されます。
実務では次のように分けています。
| 範囲 | 担当 | 理由 |
|---|---|---|
| HTML構造・レイアウト・ロゴ配置 | 制作側 | メールHTMLの制約知識が要る |
| 送信元ドメイン設定(SPF/DKIM) | 制作側+ドメイン管理者 | DNS操作が必要 |
| 問い合わせ先・営業時間・返信目安 | 事業者側 | 実際の運用体制を知っているのは事業者 |
| 返金・キャンセルの日数表記 | 事業者側 | 決済手段と社内フローに依存 |
| 特商法・ポリシーへのリンク先 | 事業者側 | 法務判断を含む |
「文面はお任せします」と言われた場合でも、返金までの日数や営業時間はこちらで決められません。空欄のまま出さず、仮の文言を入れて確認を取る形にしています。仮でも入っていれば「ここは3営業日ではなく5営業日です」と指摘が返ってきますが、空欄だと確認そのものが流れます。
コーポレートサイトと兼用している場合の注意
Shopifyを商品販売だけでなく会社の顔として使う構成では、通知メールの位置づけが変わります。BtoBの取引先が注文確認メールを受け取ることもあり、その場合は「ECらしい」トーンよりも、通常のビジネスメールに近い体裁のほうが収まります。装飾を減らし、宛名を法人名で出し、請求書の発行フローに触れておく——といった調整です。Shopifyをコーポレートサイトと兼用する考え方についてはShopifyでコーポレートサイトとネットショップを統合する構成で扱っていますが、この構成を採る場合は通知メールのトーンも合わせて設計しておくと、あとから直す手間が減ります。
アプリを使わずに実装する判断
お気に入り機能や予測検索のカスタマイズと同じで、通知メールも「アプリで解くか、自前で書くか」の判断が発生します。判断軸は共通しています。
- 更新頻度が低く、一度作れば触らないもの → 自前
- 事業者が日常的に内容を入れ替えるもの → アプリまたは管理しやすい仕組み
- 配信結果の計測が要るもの → アプリ
通知メールは前者に寄ります。一度整えれば、商品や価格の変更で書き換える必要はありません。だからこそHTMLで書いておくのが合理的です。
公開前に確認する項目

テンプレートを直したあと、実機で確認する項目を挙げます。プレビューだけで済ませないことが重要です。
受信環境
- Gmail(PCブラウザ/スマホアプリ)
- Apple Mail(iPhone)
- Outlook(Windows デスクトップ)
- キャリアメール(ドコモ・au・ソフトバンク)— HTMLメールの表示制限がある場合がある
確認内容
- ロゴが表示されるか(画像がブロックされた場合のalt属性も確認)
- ダークモードで文字やロゴが消えていないか
- リンクがすべて正しい先に飛ぶか(ステージング環境のURLが残っていないか)
- 差出人名が意図した表記になっているか
- 迷惑メールフォルダに入っていないか
- スマホでの文字サイズ(小さすぎて読みにくくないか)
送信テストの流れ
テスト注文を作って、注文確認 → 発送通知 → (必要なら)キャンセル・返金まで一通り流します。追跡番号のリンクは、実際に配送会社の番号を入れないと機能を確認できません。ここは公開直前ではなく、余裕を持ったタイミングで通しておきます。
複数商品・複数配送のパターンも1回は流しておきます。1商品の注文では気づかないレイアウト崩れが、商品リストが伸びたときに出ることがあります。長い商品名、オプション(バリエーション)が複数付いた商品、割引が乗った注文を混ぜたテストが1件あれば足ります。
計測を入れている場合は、メール内リンクにUTMパラメータを付けるかどうかも決めておきます。付ければメール経由の再訪が分離できますが、付けすぎるとURLが長くなり、テキストメール環境で折り返しが汚くなります。付けるなら注文確認・発送通知の主要導線に絞るのが扱いやすい落としどころです。
よくある質問
Shopifyの通知メールはHTMLの知識がなくても編集できますか
文面の書き換えだけなら可能です。テンプレートエディタ内の日本語部分を書き換えるだけであれば、HTMLタグに触れずに済みます。ただしレイアウトの変更や画像の追加はHTMLの編集が必要になるため、GUIで操作したい場合はテンプレート編集アプリを検討することになります。編集前には元のHTMLを必ず控えておいてください。
テーマを変更すると通知メールも初期化されますか
初期化されません。通知テンプレートはテーマとは別に保存されているため、テーマを切り替えても編集内容はそのまま残ります。これは利点でもあり落とし穴でもあり、リニューアルでデザインを一新した場合、通知メールだけ旧デザインのまま取り残されます。テーマ変更時は必ず通知メールの見た目も確認してください。
送信元を自社ドメインにするには何が必要ですか
DNSにSPFとDKIMのレコードを追加し、Shopifyの管理画面で送信元アドレスを設定します。DNS操作が必要なため、ドメインを管理している担当者や事業者との調整が発生します。設定が不完全なままだと認証エラーで到達率が下がるため、公開直前ではなく構築の早い段階で着手するのが安全です。
通知メールを全種類まとめて同じデザインにできますか
ロゴとアクセントカラーは通知設定から一括で反映できますが、フッターや文面は各テンプレートを個別に編集する必要があります。共通パーツを1か所で管理する仕組みは標準にはありません。そのため、フッターに入れる情報は最小限に絞り、変わりやすい情報はサイト内のページへリンクで逃がす設計にしておくと、後の修正が軽くなります。
注文確認メール以外で優先度が高いのはどれですか
発送通知です。顧客が注文後にもっとも待っているのがこの通知で、追跡番号のリンクが機能するかどうかが問い合わせ件数に直結します。次点はキャンセル・返金の通知で、顧客が不安な状態で受け取るため、「いつ着金するか」を明記しておくだけで問い合わせが減ります。
編集した通知テンプレートを元に戻すことはできますか
管理画面の「デフォルトに戻す」で初期状態には戻せますが、編集途中の状態には戻せません。バージョン管理の仕組みが用意されていないため、編集前の元のHTMLと、公開した時点のHTMLを自分でテキストファイルとして保存しておく運用が必要です。通知名と日付をファイル名に入れておくと、担当者が代わっても現行版が特定できます。
まとめ
Shopifyの通知メールは種類が多いものの、全部を同じ熱量で直す必要はありません。
- 共通で効くのはロゴ・色・送信元ドメインの3つだけ。まずここを固める
- 注文確認と発送通知は顧客が確実に読むので、文面を最後まで作り込む
- キャンセル・返金は「いつ・何が起きるか」を書けば問い合わせが減る
- フッターは共通化できないので、変わりやすい情報はサイト側へ逃がす
- テーマを変えても通知テンプレートは残る。リニューアル案件では独立したチェック項目に立てる
- アプリが要るのは「Shopifyが送らないタイミングで送りたい」「配信結果を測りたい」場合。デザインを整えるだけならHTML編集で足りる
- 編集前後のHTMLは自分で保存しておく。通知テンプレートにはバージョン管理がない
通知メールは、作っている間は誰も見ないのに、公開後は全顧客が目にする場所です。制作の工程表に載せておくかどうかで、公開後の問い合わせ件数が変わります。




