Email Client：メール作成画面の中身は誰が決めているか
ServiceNow のレコードを開くと、右上に封筒のアイコンがあります。押すとメール作成画面が開き、宛先や件名があらかじめ入っていることがあります。誰かが入れたわけではありません。設定が入れています。
その設定が Email Client Templates（sys_email_client_template）です。今回は、封筒アイコンの裏側にある3つのテーブルを実機で読みます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
封筒を押してから送信するまで
登場するテーブルは3つです。メール作成画面そのものの設定（sys_email_client_configuration）、当てはめる雛形（sys_email_client_template）です。そして宛先候補の絞り込み（sys_recipient_qualifier）もあります。
画面の枠組みを設定が決め、中身をテンプレートが埋め、宛先の選択肢を絞り込みが用意する。役割がきれいに分かれています。
テンプレートは8件入っている
sys_email_client_template を数えると 8件 でした。
名前を見ると規則性があります。reply、replyall、forward の3つの動作に、received と sent の2つの状態を掛けた6件。対象テーブルはすべて sys_email です。
残る2件は別のテーブル向けでした。1つは change_request 向けの「EMail to Requested by and Assigned to」です。もう1つは調査（asmt_metric_type）向けの「public_survey_template」です。
この2件の Subject を見ると、雛形の作り方が分かります。change_request のほうは ${number} - ${short_description}。変更要求の番号と概要が自動で入ります。調査のほうは ${name} だけでした。
いっぽう sys_email 向けの6件は、Subject がすべて subject という文字列です。これは元メールの件名フィールドを指します。返信なので、元の件名をそのまま引き継ぐ形になります。
同じ「件名を決める」機能でも、レコードから作るときは項目を組み立て、メールから作るときは元の値を引き継ぐ。対象テーブルによって書き方が変わる好例でした。
つまりテンプレートは、メールに対する操作だけのものではありません。任意のテーブルのレコードから書くメールにも当てられます。インシデントから顧客へ連絡するときの雛形も、ここに足せば使えます。
1件開いてみる：replyall-received
受信メールへの全員返信に当たるテンプレートを開きます。
上部に赤い警告が出ていました。
Warning: This is a High Risk file that might get updated again in later releases. Do not alter this file unless necessary.
標準レコードなので触るな、という注意です。必要なら複製して独自のテンプレートを作るのが安全です。
その下の青い案内には、このテーブルの目的がそのまま書いてありました。
Create email client templates to pre-determine the recipients, sender configuration, subject, and content of emails that you send from the email client.
宛先・差出人設定・件名・本文をあらかじめ決めておくもの、という説明です。続けて「指定したテーブル、条件、実行順にもとづいて自動的に適用される」とあります。
当てはめの条件は3つ
自動適用の判定に使われるのは、フォーム上部の3項目です。
Table … Email [sys_email]
Conditions … Type is received
Execution Order … 100
対象テーブルが合い、条件に合致したテンプレートが当たります。複数当たる場合は Execution Order の小さいものが優先されます。
replyall-received の条件は type=received^EQ。受信メールのときだけ当たる、という指定でした。同じ sys_email を対象にした replyall-sent とは、この条件だけで区別されています。
Include attachment from email というチェックもあり、実測ではオフでした。元メールの添付を引き継ぐかどうかの指定です。
タブは3つに分かれている
Content、Recipients、Sender Configuration の3タブでした。決める対象がはっきり分かれています。
Content タブには Subject、Content Type、Body HTML。実測では Content Type が HTML で、Body HTML に ${mail_script:insert_original_email_message} が入っていました。返信のときに元メールを引用する処理です。
画面右には「Select variables:」という Fields ツリーがあり、対象テーブルの項目を本文へ差し込めます。青い案内にも、current_user や URI_ref といった共通変数が使えると書かれていました。
Recipients タブは宛先の決め方です。実測の recipients フィールドには、JavaScript が入っていました。
javascript: new EmailClientTemplateEvaluator().getRecipients…固定のアドレスではなく、スクリプトで宛先を組み立てる作りです。「元メールの差出人と、CCに入っていた全員」といった動的な決め方をするために要ります。
Sender Configuration タブは差出人と返信先です。実測ではどれも空で、from_generation_type が None でした。差出人はシステムの既定に任せる、という設定になります。
script_from という項目もあります。差出人をスクリプトで決める口です。「担当グループごとに違う代表アドレスから送る」といった要件は、ここで実装します。標準では空なので、必要になったときに書く場所として覚えておけば足ります。
通知（Notification）とは別の仕組み
ここで混同しやすい点をひとつ。ServiceNow には自動でメールを送る Notification（sysevent_email_action）という仕組みもあります。名前も役割も似ていますが、別物です。
Notification は、レコードが更新されたりイベントが起きたときに、システムが勝手に送るメールです。人は関与しません。いっぽう Email Client は、人が封筒アイコンを押して書くメールの雛形です。
送る主体が違うので、テーブルも設定も分かれています。「担当者が割り当てられたら通知する」は Notification、「担当者が顧客へ状況を説明する」は Email Client。同じ相手に同じような文面が届くとしても、作られ方はまったく違います。
どちらで実装するかを間違えると、後から直しにくくなります。人の判断が挟まるなら Email Client、条件だけで決まるなら Notification。この切り分けが最初の分かれ道です。
3つ目のクイックメッセージも並べると、違いがはっきりします。自動で送るのが Notification、自動で雛形が入るのが Email Client Template、自分で選んで挿入するのがクイックメッセージ。自動の度合いが3段階に分かれている、と読むと整理しやすくなります。
現場でよくあるのは「同じ文面を毎回書いている」という状況です。それが決まった条件で発生するなら Notification、レコードを開いた時点で決まるなら Template、担当者の判断で選ぶならクイックメッセージ。どこで文面が確定するかを考えると、置き場所が決まります。
mail_script は本文の中で動く
Body HTML に入っていた ${mail_script:insert_original_email_message} は、本文の中でスクリプトを呼ぶ書き方です。${...} は差し込みで、mail_script: が付くと登録済みのスクリプトを実行します。
テキスト側の body フィールドには <mail_script> タグが直接書かれており、current.user や current.type を参照するコードが入っていました。同じテンプレートでも、HTML本文とテキスト本文で書き方が違います。
差し込みには3種類あります。フィールドの値（${number} など）、共通変数（current_user、URI_ref）、そしてスクリプト（mail_script）。単純な項目の差し込みで足りるなら、スクリプトは使わないほうが後から読みやすくなります。
画面そのものの設定は1件だけ
sys_email_client_configuration は 1件 でした。名前は Default です。
default_configuration が true で、既定として使われます。実測の値を読むと、画面の見え方がここで決まることが分かります。
display_from と display_reply_to はどちらも false でした。差出人欄と返信先欄を画面に出さない設定です。利用者が差出人を書き換えられないようにする、という意図が読めます。
to_optional も false で、宛先の入力が必須になります。宛先なしで送信ボタンを押せてしまう事故を防ぐ設定です。
attachment_send_action は Attach to Target Record でした。メールに付けた添付を、送信元のレコードにも残します。あとから「何を送ったか」を追えるようにする配慮と読めます。
宛先候補は2つの絞り込みで決まる
recipient_qualifiers には Active Users と Active Groups が設定されていました。この2つが sys_recipient_qualifier の実測2件です。
Active Users … sys_user が対象
Active Groups … sys_user_group が対象
宛先欄で候補を出すとき、この絞り込みが効きます。名前のとおり、有効なユーザーと有効なグループだけを出す指定です。
退職済みのユーザーが宛先候補に出ると、届かないメールを送ることになります。絞り込みを入れておけば、そもそも選べません。
独自の絞り込みを足せば、「同じ部署の人だけ」「特定のロールを持つ人だけ」といった制限もかけられます。
絞り込みの対象がユーザーとグループの2つに分かれているのも、実務では効きます。グループ宛に送れば、メンバーが入れ替わっても宛先を直す必要がありません。個人宛にすると、その人が異動した時点で届かなくなります。
長く運用するなら、なるべくグループを宛先にする。これは Email Client に限らず、ServiceNow の通知全般に共通する考え方です。絞り込みでグループを候補に出しておくのは、その運用を支える下準備にあたります。
なお絞り込みは「候補に出すかどうか」を決めるだけです。宛先欄に直接メールアドレスを打ち込む経路までは塞ぎません。外部の相手へ送る必要があるので、そこは開いています。
テンプレートとクイックメッセージは別物
フォームの青い案内に、もうひとつ大事なことが書いてありました。
Email Client templates are automatically applied in the email client. To provide users with pre-defined content that they can manually add in the email client, create a quick message.
テンプレートは自動で当たるもの。利用者が自分で選んで挿入する定型文が欲しければ、クイックメッセージを作れ、という案内です。
クイックメッセージは sys_email_canned_message にあたりますが、この PDI では 0件 でした。標準では用意されておらず、必要になったら自分で作る形です。
自動と手動で仕組みが分かれているのは理にかなっています。「返信なら必ず元メールを引用する」は自動でよい。「よくある問い合わせへの定型回答」は、場面によって選ぶものなので手動が向きます。
実データは空のテーブルが多い
数えてみると、この PDI では空のテーブルが目立ちました。
sys_email_canned_message（クイックメッセージ）… 0件
sys_email_draft（下書き）… 0件
sys_email_client_from_address（差出人アドレス）… 0件
下書きが0件なのは、メール作成画面をまだ使っていないからです。差出人アドレスが0件なのは、display_from が false で差出人を選ばせない設定と対応します。
設定の骨格だけが入っていて、運用で増える部分は空。この状態は、標準の設計を読むときにはむしろ好都合でした。何が最初から用意されていて、何が運用で足すものかがはっきり分かれます。
導入プロジェクトの立場で見ると、この空欄が作業項目になります。クイックメッセージをいくつ用意するか。差出人アドレスを何本立てるか。宛先の絞り込みを標準の2件のままにするか、部署単位のものを足すか。
標準で埋まっているのは、返信と転送という「メールソフトとして最低限」の部分だけでした。業務に合わせた雛形は、そこから先の仕事になります。
実務で気をつけるところ
条件が重なると order で決まる
同じテーブルに複数のテンプレートを作ると、条件が重なることがあります。そのときは Execution Order の小さいほうが当たります。
標準の6件はすべて order が同じ100でした。条件（received か sent か、reply か forward か）で棲み分けているので、重なりません。自分で足すときは、既存の条件とぶつからないかを先に確かめるのが確実です。
標準テンプレートは複製して使う
High Risk の警告が出ているとおり、標準の8件は書き換えないのが原則です。挙動を変えたいなら、複製して条件を絞った独自テンプレートを作り、order で優先させる形になります。
宛先スクリプトは動作確認が要る
recipients にスクリプトを書けるのは強力ですが、間違えると誰にも届かないか、意図しない相手に届きます。テンプレートを作ったら、実際に封筒アイコンから開いて宛先欄を確認するのが安全です。
テンプレートが当たらないときに見る順番
意図したテンプレートが当たらない場合、確認する順番があります。
まず対象テーブルです。テンプレートの Table が、いま開いているレコードのテーブルと一致しているか。継承関係があるテーブルでは、親で作ったつもりが子で効かないこともあります。
次に条件です。Conditions がそのレコードの値と合っているか。type=received のような条件は、送信済みメールから開いたときには当たりません。
最後に order です。同じ条件で当たる別のテンプレートが、より小さい order を持っていないか。標準の8件がすべて100なので、独自に足すなら90など小さい値にすると優先されます。
送ったメールは sys_email に残る
Email Client から送ったメールは、sys_email に1行として残ります。受信したメールも同じテーブルです。type フィールドで送信（sent）と受信（received）が分かれます。
標準テンプレートの6件が sys_email を対象テーブルにしていたのは、このためです。受信メールのレコードを開いて封筒アイコンを押すと、そのメールへの返信として扱われます。
つまり sys_email は「メールの台帳」であり、同時に「メールを書く画面の入口」でもあります。1つのテーブルが記録と操作の両方を受け持つ形です。
差出人欄を出すかは方針で決める
display_from を true にすると、利用者が差出人を選べるようになります。代表アドレスから送りたい場合はオフのまま、担当者個人のアドレスから送りたい場合はオンにする。運用方針しだいで変わる項目です。
どこから触るか
/sys_email_client_template_list.do … テンプレート8件
/sys_email_client_template.do?sys_id=... … 1件のテンプレート（3タブ）
/sys_email_client_configuration_list.do … メール作成UIの設定
/sys_recipient_qualifier_list.do … 宛先候補の絞り込み2件
/sys_email_canned_message_list.do … クイックメッセージ
/sys_email_list.do … 送受信したメールそのもの
テンプレートの一覧では Table 列と Conditions 列を出しておくと、どれがいつ当たるかを見比べやすくなります。
まとめ
封筒アイコンを押したときの画面は、3つの設定でできていました。
sys_email_client_configuration が画面の枠組みを決めます。sys_email_client_template が中身を埋め、sys_recipient_qualifier が宛先候補を絞ります。テンプレートは対象テーブルと条件と実行順で自動的に当たり、Content・Recipients・Sender Configuration の3タブで決めるものが分かれていました。
実測ではテンプレート8件、設定1件、絞り込み2件。クイックメッセージと下書きと差出人アドレスは0件でした。標準で入っているのは骨格だけで、業務に合わせた雛形は自分で足していく作りです。
用語
Email Client … レコードの封筒アイコンから開くメール作成画面
sys_email_client_template … 宛先・件名・本文の雛形。table と condition と order で自動適用
sys_email_client_configuration … 画面そのものの設定。差出人欄を出すか、宛先を必須にするか
sys_recipient_qualifier … 宛先候補に出す対象の絞り込み
クイックメッセージ（sys_email_canned_message） … 利用者が手で選んで挿入する定型文
Execution Order … 条件が重なったときの優先順。小さいほうが当たる
自分の環境で確認するときのURL
/sys_email_client_template_list.do?sysparm_query=ORDERBYname（テンプレート8件）
/sys_email_client_template.do?sys_id=...（replyall-received の中身）
/sys_email_client_configuration.do?sys_id=...（Default 設定）
/sys_recipient_qualifier_list.do（宛先候補の絞り込み2件）
実測の要点（再掲）
sys_email_client_template 8件（sys_email 向け6 / change_request 1 / asmt_metric_type 1）
replyall-received: condition=type=received^EQ、order=100、content_type=HTML
本文に ${mail_script:insert_original_email_message}、宛先は EmailClientTemplateEvaluator のスクリプト
sys_email_client_configuration 1件。display_from=false / to_optional=false / 添付は対象レコードにも保存
sys_recipient_qualifier 2件（Active Users / Active Groups）
sys_email_canned_message / sys_email_draft / sys_email_client_from_address はいずれも0件
検証範囲とおことわり
件数・項目・条件は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
実際に封筒アイコンからメールを作成し、テンプレートが当たる様子は確認していません。設定の読み取りまでです。
recipients に入っているスクリプト（EmailClientTemplateEvaluator）の中身は読んでいません。
クイックメッセージは0件のため、動作は未確認です。
