テンプレートの定型値は1本の文字列で保存される（sys_template）

2026年6月25日 00:25

ServiceNow で同じような Change や Incident を何度も起票していると、毎回ほぼ同じ値を手で入れることになります。「Server Reboot の Change はいつも assignment_group と category と type が同じ」といった定型もあります。これをボタン一つで流し込むのがテンプレート（Template）です。その実体は sys_template というテーブルに1件1レコードとして保存されています。

この記事では、テンプレートを画面の使い方だけで説明しません。sys_template のフィールドが何を持ち、定型値がどんな形式で保存されるかを見ます。誰が使えるか（global / group / 個人）をどう決めているかも、PDI（Zurich）の OOTB で確認した実測値とともに示します。

対象は、ServiceNow の Incident や Change は触ったことがあるが、テンプレートの裏側のテーブル構造をこれから把握したい管理者・開発者です。sys_template の継承、template フィールドの中身、共有範囲、適用先テーブルの分布を扱います。

この記事で分かること

テンプレートの実体が sys_template（1テンプレート＝1レコード）に保存されること
sys_template が task ではなく sys_metadata（Application File）を継承し、構成データとして扱われること
定型値がフィールド=値^フィールド=値^EQ というエンコード済みクエリ形式で template 列に入ること
global / group / groups / user で共有範囲が決まること（今回の PDI では active 36 件中、共有13・個人23）
適用先テーブルが change_request だけでなく incident・ウィザード・接続別名など多様なこと
標準変更（Standard Change）は sys_template ではなく別テーブルで定型を持つこと

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、テンプレートの件数・フィールド・適用先が異なる場合があります。

テンプレート（Template）とは

テンプレートとは、あるテーブルのレコードを新規作成するとき、決まった複数フィールドにあらかじめ値を流し込む定型入力です。フォーム下部のテンプレートバーから選ぶと、その値が一括でセットされます。

その定型を格納する中心テーブルが sys_template（画面ラベルは Template）です。1つの定型につき1レコードが作られ、「どのテーブルに（table）」「どんな値を（template）」「誰が使えるか（global / group / user）」を1行で保持します。

実際のテンプレートレコードを開くと、適用先テーブル（Table）と、流し込む値をまとめた Template 欄が並びます。

この Server Reboot は、Change Request を「定型で即起票する」ためのテンプレートです。assignment_group・category・type が固定され、利用者は差分だけ埋めれば済みます。

sys_template の構造と継承

sys_template は task 系のテーブルではありません。sys_metadata（Application File）を継承する構成データ側のテーブルです。

今回の PDI（Zurich / OOTB）では、sys_template の super_class は sys_metadata（Application File） でした。その sys_metadata は super_class が空のルート基底です。固有フィールドは 19 でした。

ここが Incident や Change（task 継承）と違う点です。テンプレートは業務レコードではなく「設定の一種」として置かれ、sys_metadata 配下なので Update Set に乗せて別インスタンスへ移送できます。だから開発インスタンスで作った定型を、構成物としてテスト・本番へ運べます。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。公式の Form templates（Zurich）に、テンプレートの概念と作成・適用の流れが説明されています。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_template

定型値はどんな形式で保存されるか

テンプレートの中身は、template フィールドにエンコード済みクエリと同じフィールド=値^フィールド=値^EQ 形式で入っています。フィルタ条件と同じ書き方で「セットする値」を並べた文字列です。

今回の PDI（Zurich / OOTB）で実レコードの template を読むと、次のような値でした。

Server Reboot（change_request）：assignment_group=...^category=Server Reboot^type=Emergency^EQ
Major Incident（incident）：short_description=...^caller_id=javascript:gs.getUserID();^impact=1^urgency=1^EQ
Reset Password（incident）：short_description=Reset my password^active=true^contact_type=self-service^EQ

注目したいのは、値に javascript: を書くと適用時に評価される点です。Major Incident の caller_id に javascript:gs.getUserID(); が入っているため、テンプレートを当てた人自身が caller としてセットされます。なぜ固定値でなくスクリプトかというと、「誰が当てても、その人を入れる」といった動的な既定を1つのテンプレートで表せるからです。reference 型のフィールドは sys_id で保持されます。

主なフィールドは役割で4つに分かれます。適用先（table / view）と値（template）が中心です。共有は global / group / groups / user / roles、連鎖は next / next_child が担います。

全フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_template^elementISNOTEMPTY

誰が使えるか（共有範囲）

テンプレートは「自分だけのメモ」にも「全員の共通定型」にもできます。それを決めるのが global / group / groups / user です。

今回確認した PDI（Zurich / OOTB）では、active=true のテンプレートは 36 件でした。うち global=true（全員が使える共有）が13件、global=false（個人など）が23件です。global を立てると誰でもバーから選べ、立てなければ作成者（user）の個人テンプレートになります。group / groups を指定すれば、そのグループのメンバーに限定できます。roles を入れると使用可能ロールでさらに絞れます。

共有範囲が分かれる理由は、テンプレートが「業務の標準作業」と「個人の手抜き定型」の両方に使われるからです。Server Reboot のような標準作業は global にして全員へ配り、自分用の下書きは個人に留める、という使い分けになります。Qiita の ServiceNowでテンプレート(定型入力)を適用するでも、テンプレートバーからの作成と global / Groups / 個人の共有区分が紹介されています。

どのテーブルに使われているか

テンプレートは Change 専用ではありません。table フィールドが適用先を指し、業務テーブルにも内部設定テーブルにも付きます。

active 36 件の適用先を集計すると、change_request 10・sys_wizard_answer 9・sys_alias_templates 7 が上位でした。続いて incident 3・incident_task 3 です。残りは sys_impex_entry 2・sys_script_include 1・pwd_enrollment 1 でした。使い道は ITSM の定型起票（Change / Incident / Incident Task）だけではありません。ウィザードの回答（sys_wizard_answer）や接続別名の認証設定（sys_alias_templates の OAuth / API Key / Basic 認証）も同じです。これらも sys_template を共用しています。

global の change_request テンプレートには、Server Reboot / Database Restore / SAN Storage Change / Reboot Windows Server / Decommission local office Domain Controller / Change VLAN on a Cisco switchport / Clear BGP sessions on a Cisco router などが揃っていました。いずれも「よくある定型作業の Change を即起票する」用途です。

テンプレート一覧は、次のURLで開けます。

https://<YourInstance>/sys_template_list.do?sysparm_query=active=true^ORDERBYtable

標準変更（Standard Change）は別テーブル

「標準変更も定型じゃないか」と思うところですが、Standard Change は sys_template を直接使いません。専用の std_change_proposal / std_change_producer_version で定型を持ちます。

今回の PDI（Zurich / OOTB）では、std_change_proposal に template_value というフィールドがありました。画面ラベルは Change Request values です。これは sys_template.template と同じ template_value 形式の文字列を持ちますが、保存先テーブルが別です。さらに std_change_record_producer の current_version は std_change_producer_version を指していました。ここで標準変更テンプレートのバージョンを管理します。

系統が分かれている理由は、標準変更が「承認済みの定型 Change をカタログとして提示し、版を管理する」業務だからです。フォーム入力補助の sys_template とは目的が違うため、別テーブルになっています。公式の Propose a standard change template（Zurich）に、標準変更テンプレートの提案と承認の流れが説明されています。なお、内部処理の詳細は今回の検証範囲外です（フィールドの存在のみ確認）。

sys_template に関わる周辺機能

テンプレートの動きも、フィールド定義だけでは決まりません。保存時の処理や権限が組み合わさります。今回確認した PDI（Zurich / OOTB・active 中心・2026-06-22 確認）では、次の件数でした。

特徴は、Notification が 0 件であることです。テンプレートは入力補助であり、承認のような「依頼が飛ぶ」仕組みを伴いません。だから通知が無いのは妥当です。一方で Access Controls はテーブル19・フィールド15と多めでした。共有範囲（global / group / roles）や所有者（user）を保護し、他人の個人テンプレートを勝手に書き換えさせないためと考えられます。

自分のインスタンスでは、次のURLで各一覧を開けます。

Business Rules : https://<YourInstance>/sys_script_list.do?sysparm_query=collection=sys_template^active=true
UI Actions     : https://<YourInstance>/sys_ui_action_list.do?sysparm_query=table=sys_template
Access Controls: https://<YourInstance>/sys_security_acl_list.do?sysparm_query=nameSTARTSWITHsys_template

テンプレートはこうした新規 change_request フォームに対して値を流し込みます。適用先の Change フォームには Category・Priority・Risk・Assignment group など、テンプレートでプリセットできる項目が並びます。

ServiceNow におけるテンプレートのポイント

テンプレートの実体は sys_template（Template）に「1定型＝1レコード」で保存されます。今回の PDI では全58件、active 36件でした。
sys_template は sys_metadata（Application File）を継承する構成データ側のテーブルです（task 系ではありません）。固有フィールドは19で、Update Set で移送できます。
定型値は template 列にフィールド=値^...^EQ 形式で入り、javascript: を書くと適用時に評価されます。
共有範囲は global / group / groups / user / roles で決まり、今回は active 36件中共有13・個人23でした。
適用先は change_request だけではありません。incident・incident_task・sys_wizard_answer・sys_alias_templates など多様でした。
標準変更は sys_template ではなく std_change_proposal / std_change_producer_version で定型と版を管理します。

テンプレートを調べるときは、まず「どのテーブルに（table）・どんな値を（template）・誰に（global / group / user）当てるか」を読みます。sys_template 単体ではなく、適用先テーブル側の設定（必須・既定値・UI Policy）とセットで見てください。そうすると適用後の挙動まで追えます。

実機で気づいたこと

固有フィールドを並べていて目についたのが show_on_template_bar という列でした。名前から読み取ると、レコードとして存在していてもテンプレートバーに表示するかどうかを別に制御できる作りのようです。今回はフィールドの存在を確認しただけで実際に false にしたときの挙動までは試していませんが、下書き段階のテンプレートや、スクリプト経由でだけ適用したいテンプレートを画面から隠しておく使い道がありそうだと感じました。
change_request のテンプレートを調べるつもりで一覧を開いたら、上位に sys_wizard_answer や sys_alias_templates が並んでいて面食らいました。フォームの定型入力という機能が、ウィザードの回答保存や認証設定の初期値にまで転用されているとは思っていませんでした。「フィールド＝値の組を1本の文字列で持ち、あとから流し込む」という仕組みそのものが汎用的なので、業務データに限らず設定データの初期値付けにも同じテーブルが使い回されているようです。
テンプレートの template 列に javascript: の式をそのまま書けると知って、便利さと同時に少し身構えました。誰でもテンプレートを作れる権限を持っていたら、任意のサーバサイドコードを値として実行させる入口にもなり得ます。Access Control がテーブル19・フィールド15とかなり手厚かったのは、単に個人テンプレートを守るためだけでなく、この javascript: 評価の入口を権限で絞る狙いも兼ねているのではないかと感じました。

次に読むなら

次に見るなら、テンプレート適用のサーバ処理（GlideTemplate）です。next / next_child による連鎖適用や、標準変更カタログ（std_change_proposal の提案・承認・版管理）も残っています。「フォームの入力補助としての sys_template」と「承認済み定型を配る標準変更」を分けて理解すると、どちらで定型を作るべきか迷わなくなります。これらは本記事の「定型値の形式」「標準変更は別テーブル」で示した仕組みの先にあたり、別記事で扱う予定です。

承認の仕組みは、ServiceNow の承認エンジンを実機で読み解くも参考になります。sysapproval_approver を扱った記事です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
Template（sys_template）：フォームの定型入力レコード（1定型＝1件）
template（フィールド）：プリセット値をフィールド=値^...^EQ で持つ列
global / group / user：共有範囲（全員 / グループ / 個人）
std_change_proposal：標準変更の定型を持つ別テーブル

自分の環境で確認するときのURL

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

テーブル定義       : sys_db_object_list.do?sysparm_query=name=sys_template
フィールド一覧      : sys_dictionary_list.do?sysparm_query=name=sys_template^elementISNOTEMPTY
テンプレート一覧     : sys_template_list.do?sysparm_query=active=true^ORDERBYtable
共有（global）一覧   : sys_template_list.do?sysparm_query=active=true^global=true
標準変更の定型      : std_change_proposal_list.do

テーブルの基本

sys_template … Label：Template ／ Extends：sys_metadata（Application File）／固有フィールド 19
レコード件数：全58 ／ active 36（global=true 13 ／ global=false 23）

template フィールドの形式（実測）

形式：フィールド=値^フィールド=値^EQ（エンコード済みクエリと同形）
例（change_request / Server Reboot）：assignment_group=...^category=Server Reboot^type=Emergency^EQ
例（incident / Major Incident）：short_description=...^caller_id=javascript:gs.getUserID();^impact=1^urgency=1^EQ
javascript: 値は適用時に評価。reference は sys_id で保持。

適用先テーブル分布（active 36件）

change_request 10 ／ sys_wizard_answer 9 ／ sys_alias_templates 7 ／ incident 3 ／ incident_task 3 ／ sys_impex_entry 2 ／ sys_script_include 1 ／ pwd_enrollment 1

周辺設定の件数（sys_template・OOTB・active 中心）

Business Rules（sys_script）… 2
Client Scripts（sys_script_client）… 2
UI Policies（sys_ui_policy）… 0
UI Actions（sys_ui_action）… 7
Notifications（sysevent_email_action）… 0
Access Controls（sys_security_acl）… テーブル 19 ＋フィールド 15
Dictionary Entries（sys_dictionary）… 19（固有）

sys_template の主な固有フィールド（検索用）

name, table, template, short_description, active, global, group, groups, user, roles, view, show_on_template_bar, stand_alone, link_element, next, next_child, sys_domain

検証範囲とおことわり

確認した範囲：sys_template の階層（sys_metadata 継承）、固有フィールド数（19）、主要フィールドと参照先、template の保存形式（実レコード）、レコード件数（全58 / active36 / global13 / 個人23）、適用先テーブル分布、共有範囲の区分、標準変更の別テーブル存在、周辺設定件数。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。
確認していない範囲（断定しません）：適用時のサーバ処理（GlideTemplate）の内部挙動、テンプレートバー UI の細かな権限制御、next / next_child の連鎖適用の実動作、各 Business Rule / UI Action のスクリプト内容、std_change_proposal の内部処理、ドメイン分離環境での挙動。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、テンプレートの構造を確認しました。実環境では、既存のカスタマイズによってテンプレートの件数・適用先・共有設定が変わります。