
メール通知の本文と枠の分担(Email Template/Layout)
ServiceNow から飛ぶ通知メールは、たいてい「会社ロゴのヘッダ」「本文」「配信停止リンクのフッタ」という共通の見た目を持っています。この枠(ヘッダ/フッタ)と、中に入る本文は、別々のテーブルが担当します。本文を定義するのが Email Template(sysevent_email_template)、共通の枠を定義するのが Email Layout(sys_email_layout)です。
通知定義(Notification)は Email Template を参照し、Email Template は Email Layout を参照します。枠のどこに本文が差し込まれるか(${notification:body})も含め、PDI の OOTB で確認した実機の値で示します。
想定読者は、ServiceNow のメール通知(Notification)は触ったことがあるが、テンプレートとレイアウトの違いや、ロゴ入りの枠がどこで決まるかをまだ把握していない管理者・開発者です。「本文は出るのに枠が付かない/枠は出るのに本文が空」を切り分けるとき、どのテーブルのどの項目を見るかまで示します。
この記事で分かること
メール通知の「中身(本文)」と「枠(ヘッダ/フッタ)」を担当する 2 つのテーブルの違い
Notification → Email Template → Email Layout という二段の参照関係
共通の枠(Email Layout)のどこに本文が入るか(${notification:body} の役割)
Email Layout の advanced フラグ(HTMLエディタ/ソース直書き)の違い
OOTB の Template / Layout / 参照件数(83 / 13 / 304 など)
「枠が付かない/本文が空」を切り分けるとき、どのテーブルを見るか
この記事の内容は ServiceNow の PDI(Personal Developer Instance)Zurich(ズーリッヒ)リリースの OOTB(初期設定)で確認した個人メモです。本番環境やカスタマイズ済み環境では、テンプレート・レイアウト・フィールド・件数・選択肢の内容が異なる場合があります。実際の送信メールのレンダリング結果や mail script の評価には踏み込みません。
Email Template と Email Layout とは
Email Template はメールの中身(件名・本文)を、Email Layout はその中身を包む共通の枠(ヘッダ/フッタ)を持ちます。ServiceNow の通知メールは、本文だけを毎回書くのではなく、ロゴ入りのヘッダや配信停止リンクのフッタを共通の枠として用意しておき、その枠の中に本文を差し込んで完成させます。
枠と中身が別テーブルに分かれているため、ロゴやフッタを変えたいときはレイアウト 1 つを直し、本文を変えたいときはテンプレートを直す、という分業ができます。「ロゴが出ない」と「本文が出ない」は見るテーブルが違う、ということです。公式の概要は Email templates と Email layouts を参照してください。
Notification → Template → Layout の参照関係
まず全体像です。今回確認した PDI(Zurich / OOTB)では、通知メールは次の二段の参照でつながる構成でした。

Notification(sysevent_email_action) … 「いつ・誰に・何を」を持つ通知定義。template 項目で Email Template を指す。
Email Template(sysevent_email_template) … 件名・本文(中身)を持つ。email_layout 項目で Email Layout を指す。
Email Layout(sys_email_layout) … 共通の枠(ヘッダ/フッタ)を持つ。
枠(Layout)は Notification ではなく Email Template に紐づきます。「通知ごとに枠を変えたい」と思って Notification を探しても枠の指定は見つからず、枠はテンプレート側にあります。今回の PDI では、email_layout を参照する Template は 66 件、参照しない(枠なしの素の本文)Template は 17 件でした。
通知定義・テンプレート・レイアウトの役割分担は次の通りです。

共通の枠のどこに本文が入るか(${notification:body})
枠の中で本文が入る位置は、${notification:body} という変数で決まります。Email Layout は HTML の枠で、どこに本文を流し込むかを ${notification:body} プレースホルダで ServiceNow に指定します。

ヘッダ … ロゴやタイトル。枠の上部。
${notification:body} … ここに Email Template の本文(message_html)が差し込まれます。今回確認したレイアウトはすべてこの変数を持っていました。
フッタ … ${NOTIF_UNSUB}(配信停止)や ${NOTIF_PREFS}(通知設定)のリンク。枠の下部。
公式ドキュメントでも、レイアウト内のどこを本文に置き換えるかは ${notification:body} で指定すると説明されています。枠だけ表示されて本文が空なら、まず Layout に ${notification:body} があるかを確認します。逆に本文は出るのに枠が付かないなら、その Template の email_layout が空か、Notification がその Template を指していない可能性が高いです。(参考: Email layouts)
実機で「Demo Layout - Light」というレイアウトを開くと、ヘッダに ServiceNow ロゴがありました。中央に ${notification:body}、フッタに配信停止/設定リンクが並んでいました。まさにこの構造です。
https://<YourInstance>/sys_email_layout.do?sys_id=<レイアウトのsys_id>
Email Layout の advanced フラグ(HTML エディタ/ソース直書き)
Email Layout には本文欄が 2 種類あり、advanced(boolean)フラグでどちらを使うかが切り替わります。これを知らないと、枠を編集しているのに反映されない、という状態になります。

advanced = false … layout フィールド(HTML エディタ)を使う。画面上で見たまま編集する。今回の PDI では 7 件。
advanced = true … advanced_layout フィールド(ソース)を使う。HTML/XML を直書きする。今回の PDI では 6 件。
同じ「枠」でも編集する欄が違います。advanced=true のレイアウトを HTML エディタ側で直しても、実際に使われるのは advanced_layout のほうなので反映されません。Email Layout の主なフィールドとプレースホルダは次の通りです。

いま新しく枠を 1 つ作るなら
ここまでのフィールドを使って、最小構成の Email Layout を新規に作る手順を示します。フォームは sys_email_layout_list.do の New から開きます。
Name に区別できる名前(例:Team Footer Layout)を入れる。
Advanced は false のまま(HTML エディタの layout で編集)。OOTB の Demo Layout - Light と同じ側です。
Layout(HTML エディタ)に、ロゴ等のヘッダ → ${notification:body} → フッタの順で組む。本文を入れたい位置に ${notification:body} を 1 つ置くことが要点で、これを忘れると枠だけ出て本文が空になります。
フッタの配信停止/設定リンクは ${NOTIF_UNSUB} と ${NOTIF_PREFS} を置く(+link_text="配信停止" でリンク文言を指定できる)。
作った枠は、Email Template 側の email_layout でこのレイアウトを選んで初めて効きます。レイアウトを作っただけでは、どのメールの枠も変わりません。
Email Template の中身(件名・本文・変数)
Email Template 側は「中身」を持ちます。主なフィールドは name(名前)・collection(対象テーブル)・subject(件名)・message_html(本文 HTML)・email_layout(枠の参照)です。本文には ${number} のようなフィールド変数や、${mail_script:...} のようなスクリプト呼び出しを埋め込めます。
実機で「sc_task.itil.role」という OOTB テンプレートを開きました。Table が Catalog Task、Subject が Task ${number} notification です。Message には Short Description や Assigned to などのフィールド変数と ${mail_script:itsm_record_link} が並んでいました。この中身が、レイアウトの ${notification:body} の位置に差し込まれて1通のメールになります。
https://<YourInstance>/sysevent_email_template.do?sys_id=<テンプレートのsys_id>
テンプレートの一覧は、次のURLで確認できます(先頭の <YourInstance> は自分のインスタンスに置き換えてください)。
https://<YourInstance>/sysevent_email_template_list.do?sysparm_query=email_layoutISNOTEMPTY
「枠が付かない/本文が空」をどこで見るか
「ロゴ入りの枠が付かない/枠は出るが本文が空」は、これまでのテーブルを使うと次のように切り分けられます。

枠(ヘッダ/フッタ)が付かない:まず使われている Email Template の email_layout が空でないかを確認します。次に、その通知(Notification)が本当にその Template を template 項目に指定しているかを確認します。
枠は出るが本文が空:Email Layout に ${notification:body} があるかを確認します。次に、Email Template の message_html(本文)が空でないかを確認します。
中身(Email Template)と枠(Email Layout)を分けて見れば、どちらの段階で起きている問題かが決まり、見るべきテーブルが定まります。
テンプレート/レイアウト/通知の件数
参考として、テンプレート・レイアウト・通知の参照関係の件数を載せます。今回確認した PDI(Zurich / OOTB・2026-06-22確認)の値です。

OOTB の時点で Email Template が 83 件、Email Layout が 13 件用意されており、有効な通知のうち 283 件がテンプレートを参照していました。残りの82件はテンプレートを経由せず、通知定義(Notification)自身に本文を直書きしています。すべての通知が Email Template を使うわけではない、という点は切り分けの際に押さえておくとよいです。自分でメールの見た目を作る前に、まず既存のレイアウト(13 件)の中に流用できる枠がないかを探すと早く済みます。今回の PDI では旧来の Stationery(sysevent_email_style、style 項目)を参照する通知は 0 件で、枠は Email Layout 側に寄っていました。テンプレートの作り方は公式の Create an email template、レイアウトの作り方は Create an email layout で確認できます。
レイアウトの一覧は、次のURLで確認できます。
https://<YourInstance>/sys_email_layout_list.do
ServiceNow のメールテンプレート/レイアウトのポイント
メール通知の中身は Email Template(sysevent_email_template)、共通の枠は Email Layout(sys_email_layout)が担当する、別テーブルです。
参照は二段で、Notification →(template)→ Email Template →(email_layout)→ Email Layout とつながります。枠の指定は Notification ではなく Email Template にあります。
枠の中の本文位置は ${notification:body} で決まります。フッタの配信停止/設定リンクは ${NOTIF_UNSUB} / ${NOTIF_PREFS} です。
Email Layout は advanced フラグで layout(HTMLエディタ)と advanced_layout(ソース直書き)を切り替えます。編集する欄を間違えると反映されません。
OOTB では Template 83 件・Layout 13 件で、有効な通知の 283 件がテンプレートを参照していました。旧来の Stationery(style)参照は 0 件でした。
「枠が付かない」は Template の email_layout と Notification の template 指定を見ます。「本文が空」は Layout の ${notification:body} と Template の message_html を見ます。
メールの見た目を調べるときは、中身(Template)を見るのか枠(Layout)を見るのかを先に決めます。参照の二段(Notification → Template → Layout)のどこで切れているかを確認すると、早く特定できます。
実機で気づいたこと
Email Template は実はメール専用ではなかった
Email Template のフィールドを一通り洗い出していて意外だったのが、HTML本文の message_html やテキスト本文の message_text だけでなく、Push通知用の message_list と SMS用の sms_alternate というフィールドも同じテーブルにあったことです。「Email」という名前なので、てっきりメール専用のテーブルだと思っていましたが、実際には Push や SMS で配信する本文もここで管理されています。チャネルごとに別テーブルへ分ける設計を予想していたので、1つのレコードに複数チャネル分の本文を持たせる作りは意外でした。もう1つ気づいたのは、Email Template と Email Layout がどちらも super_class に Application File(sys_metadata系)を持っている点です。通知の見た目に関わるレコードも、他の業務アプリのファイルと同じ仕組みで Update Set に載って動く様子が実機で確認できました。余談ですが、参照元の Notification(sysevent_email_action)も super_class をたどると sysrule(Rule)を経由して sys_metadata に行き着き、Notification・Template・Layout の3テーブルはすべて「設定を格納する」系統でつながっていました。Email Layout の一覧では Description 列にも用途が一言で書かれていて、13件を見比べるときの目印になります。
レイアウト名を並べると、汎用ではなく用途別に分かれていた
13件の Email Layout の名前を並べてみると、Demo Layout - Light/Dark のような汎用の枠だけではありませんでした。Employee notification layout や CMDB Data Manager Layout のように、特定のアプリ・機能専用のレイアウトも混ざっていました。共通の枠を1〜2個だけ作って全社で使い回すイメージを持っていましたが、実機ではアプリ側が専用の枠を持ち込む場面もあるようです。一方で、Unsubscribe and Preferences という汎用レイアウトは、Catalog Task 向けの sc_task.itil.role をはじめ複数のテンプレートから共有されていました。App Intake Request - Advanced のように、App Engine - Advanced Layout という専用レイアウトを単独で使うテンプレートもあり、「共有する枠」と「専用の枠」が同じ画面の中に混在しています。同じ Demo Layout にも Light / Dark に加えて Go To Instance Button という3つ目の亜種があり、Unsubscribe and Preferences にも Helvetica フォント版の亜種がありました。同じ役割のレイアウトでも、フォントや導線違いのバリエーションを複数用意している場合があるということです。逆に、枠を持たない17件のテンプレート側には Password Reset - Autogenerated Password と Password Expiration Email & SMS Reminder という2つのパスワード関連テンプレートが並んでいました。即時性の高い通知は、ロゴ入りの装飾された見た目より、シンプルな本文を優先しているのかもしれません(推測です)。自分の環境で枠の設計を見直すなら、まず sysevent_email_template_list.do の Email layout 列を確認します。同じレイアウトが何件のテンプレートに使われているかが一覧で分かるので、共有すべき枠と専用にすべき枠の判断材料になります。
次に読むなら
通知が「いつ・誰に・何を」で動く全体像は、別記事「ServiceNow の Email Notification を実機で確認する:通知が飛ぶまでの流れをテーブルで追う」で扱っています。続けて読むテーマは4つあります。1つ目はテンプレート本文に埋め込む ${mail_script:...}(メールスクリプト)の書き方、2つ目は ${field} のドットウォークです。3つ目は HTML 本文とプレーンテキスト(message_html / message_text)の使い分け、4つ目は実際に送信されたメール(sys_email)の本文がどう組み上がるかです。本記事で「範囲外」とした送信時のレンダリング結果や mail script の評価は、別記事で扱う予定です。
用語
PDI:Personal Developer Instance(無料の検証用インスタンス)
OOTB:Out of the Box(初期設定のまま)
Email Template:sysevent_email_template テーブル(メールの件名・本文=中身)
Email Layout:sys_email_layout テーブル(共通の枠=ヘッダ/フッタ)
Notification:sysevent_email_action テーブルの通知定義(いつ・誰に・何を)
${notification:body}:レイアウト内で本文が差し込まれる位置を示す変数
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
テンプレート一覧 : sysevent_email_template_list.do
テンプレート(枠あり) : sysevent_email_template_list.do?sysparm_query=email_layoutISNOTEMPTY
レイアウト一覧 : sys_email_layout_list.do
通知定義(template参照): sysevent_email_action_list.do?sysparm_query=templateISNOTEMPTY
テンプレートのフィールド: sys_dictionary_list.do?sysparm_query=name=sysevent_email_template^elementISNOTEMPTY
レイアウトのフィールド : sys_dictionary_list.do?sysparm_query=name=sys_email_layout^elementISNOTEMPTY検証範囲とおことわり
確認した範囲(1/4):sysevent_email_template / sys_email_layout の super_class(Application File 系)。
確認した範囲(2/4):固有フィールド(テンプレートが email_layout を参照、レイアウトが advanced で layout/advanced_layout を切替)。
確認した範囲(3/4):Notification → Template → Layout の二段参照、レイアウト内の ${notification:body} ほかプレースホルダ。
確認した範囲(4/4):各件数(Template 83 / Layout 13 / template 参照 304・active 283 / style 参照 0)、代表 OOTB レコードの実名。すべて PDI(Zurich / 2026-06-22 確認)の OOTB で取得しています。
確認していない範囲(1/3):実際に送信されたメール(sys_email)の最終的なレンダリング結果(見た目)、${mail_script:...} などスクリプトの評価。
確認していない範囲(2/3):メール翻訳(sys_translated_text)連携、SMS / Push(message_list / sms_alternate)の実挙動。
確認していない範囲(3/3):ダイジェスト配信時の枠の適用、Stationery(style)を使う環境での優先順位。これらは別記事で扱います。
今回は PDI の OOTB(初期設定)を前提に、メールの「中身(Template)」と「枠(Layout)」のテーブル構造と参照関係を確認しました。実環境では、既存のカスタマイズによってテンプレートやレイアウトの数・内容が変わります。