ServiceNowの入力欄で使えるスラッシュコマンドは？ sys_ui_text_commandの4件を実機で読む

同じような返信を1日に何度も書くのは手間です。ServiceNow には、入力欄で1文字打つだけで定型文を呼び出す仕組みがあります。チャットツールのスラッシュコマンドに近い操作で、メール本文にも作業メモにも使えます。何ができる仕組みなのかを押さえたうえで、素の環境で実際に何が出るのかを数えました。

問い合わせ対応で本当に短縮したいところ

サービスデスクの1件あたりの時間を削るとき、狙い目は決まっています。

同じ文面を繰り返し書いている場所です。詳細情報の依頼、打ち合わせの提案、進捗の連絡。どれも毎回ほぼ同じ内容を打ち直しています。

欲しいのは、手を止めずに定型文を入れられることです。マウスに持ち替えてメニューから選ぶのでは、打つのと大差ありません。キーボードだけで完結する必要があります。

テンプレート機能との位置づけ

ServiceNow には前からテンプレートの仕組みがありました。メールテンプレートも応答テンプレートも、この機能より先に存在しています。

新しいのは呼び出し方です。これまでは画面のボタンやメニューから選ぶ形でした。テキストコマンドは、入力欄に文字を打つと候補が出ます。

つまり中身を作る仕組みではなく、既にあるものを速く呼ぶための入口です。テンプレートが1件も無ければ、コマンドを打っても何も起きません。ここが評価するときの分かれ目になります。

メールテンプレートの構造そのものはメール通知の本文と枠の分担（Email Template/Layout）で扱いました。

何のためのテーブルなのか

コマンドの定義は sys_ui_text_command に入ります。画面上の名前は UI Text Command でした。

このテーブルが持つのは4つの情報です。どの文字で呼び出すか。何をするか（挿入か置換か）。どこで使えるか（メール本文かジャーナル入力か）。そして実際の処理です。

処理はスクリプトとして持ちます。1文字のコマンドに対して、候補の検索・絞り込み・候補が0件のときの分岐まで書かれていました。利用者から見れば1文字でも、裏側は普通のアプリケーションです。

Application File を継承しているので、自分で作ったコマンドは更新セットで他の環境へ運べます。

応答テンプレート側の公式説明

呼び出される側にも公式の説明が付いていました。sn_templated_snip_note_template（画面上は Response Template）の項目です。

html_script_body は「Note template body」。本文そのものです。name は「Note template name」。

group_visibility の説明が実務的でした。「Response visible to listed Groups or all Groups when list is empty」。グループを挙げればそのグループにだけ見せ、空欄なら全グループに見せる、と書かれています。部署ごとに定型文を出し分けられるということです。

素の環境ではこの項目が空でした。運用が始まってから使う側の設定になります。

結論：コマンドは4件あるが、中身があるのは2つだけ

実機を読んで分かったのは次の3点です。

登録されているコマンドは4件。文字としては r d e の3種類で、r だけメール本文用とジャーナル入力用の2件に分かれています。

動作は2種類でした。カーソル位置に挿入するものと、入力欄の内容を置き換えるもの。テンプレートの性格で使い分けています。

そして素の環境で実際に候補が出るのは、r が2件、e が83件。d は0件で何も出ません。

4件のコマンドを読む

まず一覧を開きます。

4件とも active は true。table は global で、特定のテーブルに限定していません。order はすべて100で同じです。

required_roles は4件とも空でした。ロールによる制限はかかっていません。入力欄が使える人なら誰でも打てます。

r が2件ある理由

command_name が r のものが2件登録されていました。同じ文字なのに別レコードです。

違いは applies_to にあります。1件は Email、もう1件は Field Type です。

Field Type のほうは field_type に Journal Input が入っていました。ジャーナル入力とは、作業メモやコメントのような追記型のフィールドを指します。

つまりメールを書くときも、作業メモを書くときも、同じ r で応答テンプレートを呼べるということです。使う場所ごとにレコードを分けて、同じ文字を割り当てています。

挿入と置換の2種類

action_type を見ると2種類ありました。Insert Content と Replace Content です。

応答テンプレートは挿入。カーソルのある位置に文章を差し込みます。すでに書いた文の途中に足せます。

下書きとメールテンプレートは置換。入力欄の内容を丸ごと入れ替えます。テンプレートで書き始める使い方になります。

この使い分けは理にかなっています。応答テンプレートは「よく使う一文」なので挿入。メールテンプレートは「メール1通ぶん」なので置換です。

使われていない3つ目の動作

action_type の選択肢を確認すると、実は3つありました。insert_content、replace_content、そして custom_event です。

custom_event を使っているレコードは1件もありません。独自の処理を呼ぶための枠だと考えられますが、標準では例がないので使い方が分かりません。

選択肢はあるのに実機で使われていない、という状態です。自分で作るときに選べる余地があります。

呼び出す先に中身はあるのか

コマンドが動くかどうかは、呼び出す先にデータがあるかで決まります。3つとも数えました。

応答テンプレートは2件だけ

r が呼ぶのは sn_templated_snip_note_template というテーブルでした。

2件です。Need more information（詳細情報が必要）と Schedule a meeting（打ち合わせの設定）。

どちらも table が incident で、インシデント向けに作られています。本文には ${caller_id.name} のような変数が入っていて、レコードの値で置き換わる仕組みです。

short_name という列もあり、more info と meeting request が入っていました。一覧に出すときの短い名前でしょう。

正式名称と短縮名の2つを持つ設計です。選ぶ画面には短い名前を出し、管理画面では正式名称を使う。同じレコードを場面で呼び分けられます。

2件は見本という位置づけです。実運用では自分たちの定型文を足すことになります。

チャネルとの紐付けは6件

応答テンプレートには、どのチャネルで使うかの紐付けがありました。m2m_response_template_to_channel に6件です。

2件のテンプレート × 3チャネル（Chat / Form / Email）で6件。両方とも3チャネルすべてに紐づいています。

チャネルを分けられる作りになっているので、チャットでは使うがメールでは使わない、といった設定ができます。標準の2件は全部に開いている状態です。

下書きは0件

d が呼ぶのは sys_email_draft です。0件でした。

下書きは利用者が自分で保存するものなので、素の環境に無いのは当然です。誰かが書きかけのメールを保存すれば増えます。

つまり d は、機能としては動くものの、使い始めるまで何も出ません。コマンドが効かないと勘違いしやすい場所です。

メールテンプレートは83件

e が呼ぶのは sysevent_email_template で、83件ありました。

スコープ別に見ると12グループに分かれます。Global が56件で最多。Change Management のCABワークベンチが5件、Application Intake と CMDB Workspace と Security Center が各4件と続きます。

3つのコマンドのなかで、素の環境でいちばん使えるのがこれです。83件から選べます。

メールテンプレートの構造そのものはメール通知の本文と枠の分担（Email Template/Layout）で扱いました。本文と枠が別々に管理されています。

83件のメールテンプレートを分類する

e で呼べる83件は、素の環境でいちばん実用になる資産です。中身を見ておきます。

Global が56件で大半

スコープ別に見ると Global が56件でした。全体の3分の2です。

残る27件は、アプリケーションごとのスコープに分かれています。CAB ワークベンチが5件、Application Intake が4件、CMDB Workspace が4件、Security Center が4件。

ここに1〜2件だけ持つスコープもありました。App Engine Studio、Creator Studio、Pipeline、Targeted Communications。機能を入れると、その機能が使うテンプレートも一緒に入ってきます。

作成者から出どころが読める

作成者を数えると admin が54件、glide.maint が22件、maint が4件でした。残る2件は別のアカウントです。

glide.maint は製品の保守処理で使われるアカウントです。22件がこの名義ということは、プラグインのインストールで入ったものだと考えられます。

受信メールでチケットを立てる仕組みにもテンプレートが関わります。受信メールでチケットが立つ仕組み（Inbound Email Action）で扱った経路と、送信側のテンプレートは別管理です。混同しないよう分けて考えます。

自分たちで作ったテンプレートを探すなら、この違いが手がかりになります。ただし admin は標準にも使われているので、作成日と併用する必要があります。

数だけ多くても選べない

83件から選ぶのは、実は大変です。1文字打って一覧が出ても、そこから探す手間が残ります。

名前の付け方が効いてくる場面でしょう。用途が名前から分かるようにしておくと、選ぶ時間が減ります。

自分たちで足すときは、頭に用途を付けるといった規則を決めておく価値があります。

Global の56件を開くと、change.itil.role や incident.ess.resolve のように用途が名前に出ているものが並びます。命名が揃っていると、一覧から選ぶときに助かります。

ジャーナル入力で使える意味

4件のうち1件だけ applies_to が Field Type でした。field_type に Journal Input が入っています。

ジャーナル入力は、作業メモやコメントのように追記していくフィールドです。インシデントの対応記録を書く場所がこれにあたります。

メールより使う頻度が高い

対応記録は、1件のインシデントで何度も書きます。メールを送る回数より多いはずです。

そこでテンプレートが使えるのは効きます。「一次切り分けを実施」「利用者に連絡済み」といった定型の記録を、打ち込まずに入れられます。

インシデント1件がどのテーブルに書かれるかはServiceNowのインシデント1件は何テーブルに書かれる？で数えました。対応記録もそのひとつです。

挿入型なのが合っている

ジャーナル入力用の r は Insert Content でした。置換ではありません。

対応記録は、自分で書いた文とテンプレートを混ぜて使います。「10:30 一次対応開始」と書いてから、テンプレートで定型部分を足す。挿入型でないと成り立たない使い方です。

メールが置換型で、記録が挿入型。同じコマンドでも、使う場所によって動きを変えているのは、実際の書き方に合わせた結果でしょう。

応答テンプレートの中身を読む

2件しかないので、両方の構造を見ておきます。使い方の見本になります。

変数で値を差し込む

html_script_body には HTML が入っていました。冒頭は <p>Hi ${caller_id.name}</p> という形です。

${caller_id.name} の部分が、レコードの値で置き換わります。インシデントの報告者名が入る仕組みです。

この書き方はメール通知でも使われています。テンプレートの世界では共通の記法なので、片方を覚えれば両方に使えます。

table で対象を絞る

2件とも table が incident でした。インシデントのフォームで使うテンプレートという意味です。

${caller_id.name} はインシデント固有の列を参照しています。リクエストで使うなら別の列名になるので、テーブルごとにテンプレートを分ける必要があります。

変数を使うと、テーブルを跨いで共有できなくなる。 ここが設計の分かれ目です。変数を使わない汎用の文面なら、複数テーブルで使い回せます。

使わなかった3つの列

language、group_visibility、condition はどちらのレコードでも空でした。

language は多言語対応でしょう。言語ごとに別のテンプレートを用意する使い方です。素の環境は英語だけなので空になっています。

group_visibility は、特定のグループにだけ見せる設定だと考えられます。部署ごとに定型文を分けたいときに使えます。

condition は表示条件です。優先度が高いときだけ出す、といった絞り込みができるはずです。

3つとも空ということは、標準の2件は誰にでも常に出るということになります。運用が始まると、この3列を使う場面が出てきます。

この仕組みと従来のテンプレート機能

ServiceNow には前からテンプレートの仕組みがありました。今回のコマンドは、それを呼び出す入口です。

何が新しいのか

テンプレート自体は新しくありません。メールテンプレートは83件が以前から入っていました。

新しいのは sys_ui_text_command のほうです。入力欄で文字を打って呼ぶ、という操作方法が足されました。

これまでは画面のボタンやメニューから選ぶ形でした。手を止めてマウスに持ち替える必要があります。キーボードだけで完結するほうが速い。

画面基盤との関係

applies_to に Field Type や Email という値があることから、この仕組みは新しい画面基盤に紐づくものだと読めます。従来のフォームで動くかは確認していません。

自分の環境がどちらの画面を使っているかで、使えるかどうかが変わります。切り分けはServiceNowのワークスペースは従来のフォームと何が違う？にまとめました。

独自画面では使えるのか

自分で作った画面で使えるかも、確認していません。table が global なので制限は緩そうですが、入力欄の実装によるでしょう。

画面を自作する従来の手段は独自画面は3つのフィールドでできている（sys_ui_page）で扱いました。作り方が違うと、こうした仕組みが効くかどうかも変わります。

導入するかを判断する材料

この機能を使うかどうかは、対応件数で決まります。

効果が出る条件

1日に何十件も対応する現場なら、1件あたり数十秒の短縮でも積み上がります。

逆に件数が少ないなら、テンプレートを整備する手間のほうが大きくなります。2件の見本を増やす作業が先に発生するためです。

判断の目安は、同じ文面を書く回数でしょう。週に何度も同じことを書いているなら、テンプレート化する価値があります。

準備に必要なもの

テンプレート本体、チャネルの紐付け、対象テーブルの指定。この3つを決めれば動きます。

コマンド側は標準の4件をそのまま使えます。触る必要はありません。

手を入れるのはデータ側だけなので、導入の敷居は低いほうです。設定変更というより、コンテンツの追加に近い作業になります。

1文字にした設計をどう見るか

command_name に入っているのは r d e の1文字でした。

短いほど打つのは速い。一方で、覚えていないと使えません。ヘルプを見ないと何が使えるか分からない状態になります。

3つに絞ったのは妥当か

用意されたのは3種類だけです。応答テンプレート、下書き、メールテンプレート。

メール作成の場面で必要なものが揃っています。増やしすぎると覚えられないので、この数は妥当でしょう。

自分で足すなら、既存の3文字と重ならない文字を選ぶことになります。t や s あたりが空いています。

同じ文字で違う場所という設計

r がメールとジャーナル入力の両方に割り当てられているのは、利用者にとって分かりやすい形です。

「応答テンプレートは r」と1つ覚えれば、どこでも使えます。場所ごとに違う文字だと、覚える量が倍になります。

裏側でレコードが2件に分かれているのは、利用者には見えません。見た目を単純にするために、定義側で複雑さを引き受けている構造です。

打ち間違いはどうなるのか

r で始まる普通の単語を打ったときに反応するのか、という疑問が残ります。

スクリプトを見ると query.trim() === "r" のような判定がありました。何らかの条件で発動を制御しているようです。詳しくは追っていません。

実際に打ってみないと分からない部分です。導入前に試す価値があります。

呼び出し先が空のときに何が起きるか

d の下書きが0件だったので、この状態を考えておきます。

スクリプトには、候補が0件のときの分岐が書かれていました。何らかのメッセージを返す作りになっています。

エラーで止まるのではなく、案内を出す。そういう設計だと読めます。ただし実際の表示は確認していません。

利用者への説明が要る

導入するなら、何が使えるかを伝える必要があります。「e を打つとメールテンプレートが出る」と知らなければ、機能があっても使われません。

応答テンプレートが2件しか無い状態で案内すると、期待外れになります。先に中身を用意してから告知する順番が大事でしょう。

段階的に増やす

最初から完璧な定型文集を作る必要はありません。よく使うものを3つか4つ作って、運用しながら足していく形が現実的です。

標準の2件は、その出発点として使えます。書き方の見本があるので、真似すれば作れます。

動作種別で分けると、挿入2件と置換2件でちょうど半分ずつでした。3つ目の選択肢である独自イベントは、ここに現れません。

用語

テキストコマンド：入力欄で文字を打つとテンプレートなどを呼び出す仕組み。実体は sys_ui_text_command。

応答テンプレート：問い合わせ対応でよく使う定型文。sn_templated_snip_note_template に入る。

ジャーナル入力：作業メモやコメントのような、追記していくタイプのフィールド。

挿入と置換：カーソル位置に差し込むか、入力欄の中身を入れ替えるか。action_type で決まる。

チャネル：やりとりの経路。Chat / Form / Email の3つが紐付けの対象になっている。

実機を見て気づいたこと

同じ文字を2レコードに分けている

r が2件あるのを見て、最初は重複だと思いました。

applies_to を見ると別物です。メール用とジャーナル入力用。同じ文字を、使う場所ごとに別レコードで定義しています。

1レコードに複数の場所を持たせる作りもできたはずです。分けたのは、場所ごとに動きを変える余地を残したかったからでしょう。実際に action_script は別々に持っています。

同じ名前のレコードが並んでいたら、まず違う列を探す。 重複と決めつけずに済む考え方です。

スクリプトが5,000文字近くあった

View response templates の action_script は4,978文字ありました。1文字のコマンドに対して、この分量です。

中身を覗くと sn_templated_snippets.ResponseTemplate() という API を呼んでいます。テンプレートの検索、絞り込み、候補が0件のときの分岐まで書かれていました。

利用者から見れば r と打つだけの機能です。裏側にこれだけのコードがあることは見えません。単純な操作ほど、支える仕組みは厚くなります。

0件のコマンドは「壊れている」に見える

d を打っても何も出ない状態は、機能が動いていないように見えます。実際には下書きが1件も無いだけです。

同じことが応答テンプレートでも起きます。2件しか無いので、探しているものが見つからない。コマンドの問題だと思ってしまいます。

新機能を評価するときは、機能の有無とデータの有無を分けて見る必要があります。プラグインが有効でも、中身が空なら何も起きません。

実務では何に使えるか

応答テンプレートを整備する順番

この仕組みを使うなら、先にテンプレートを用意します。コマンドだけあっても意味がありません。

まず既存の2件を読みます。変数の書き方と HTML の構造が分かるはずです。それを真似して自分たちの定型文を作ります。

次にチャネルの紐付けです。どこで使うかを決めて、m2m_response_template_to_channel に行を作ります。Chat だけ、Email だけ、といった設定ができます。

最後に table を決めます。標準の2件は incident 向けでした。リクエスト用や変更用が必要なら、テーブルごとに作ることになります。

サービスデスクの応答時間に効く

対応の多くは似た内容です。詳細情報の依頼、打ち合わせの提案、進捗の連絡。標準の2件はこの種類にあたります。

r と打って選ぶだけで本文が入るなら、1件あたり数十秒は変わります。件数が多い現場では効いてきます。

問い合わせをどこでチケットにするかの判断も、対応の速さに関わります。ServiceNowの問い合わせはいつチケットにする？で扱った流れと組み合わせると効果が出ます。

独自のコマンドを足せる

action_script があるので、自分でコマンドを作れます。custom_event という選択肢も用意されています。

ただし標準に例が無いので、作るなら既存の4件を読み解くところから始まります。5,000文字近いスクリプトを理解する必要があるので、簡単ではありません。

まずは応答テンプレートを増やすだけで十分でしょう。コマンド自体を増やすのは、それでも足りないと分かってからで間に合います。

メールまわりの全体像を押さえる

e が呼ぶメールテンプレートは、通知の仕組みの一部です。テンプレートだけ整えても、通知が飛ばなければ意味がありません。

通知が届くまでの流れはメール通知が飛ぶまでの4段階（Notification）にまとめました。止まったメールの追い方は送信待ちで止まったメールを追う（sys_email）で扱っています。

テンプレートは入口です。出口まで見ておくと、トラブルのときに切り分けが速くなります。

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

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

• テキストコマンドの一覧：/sys_ui_text_command_list.do?sysparm_query=ORDERBYcommand_name

• 応答テンプレート：/sn_templated_snip_note_template_list.do

• テンプレートとチャネルの紐付け：/m2m_response_template_to_channel_list.do

• メールテンプレートをスコープ別に見る：/sysevent_email_template_list.do?sysparm_query=GROUPBYsys_scope

• メールの下書き：/sys_email_draft_list.do

引用した公式説明を自分で開く

この記事で引用した説明文は、ServiceNow が製品に同梱しているフィールドのドキュメントです。次のURLを自分のインスタンスで開けば、引用元の原文にあたれます。

• フィールドの公式説明（引用元）：/sys_documentation_list.do?sysparm_query=nameINsys_ui_text_command,sn_templated_snip_note_template^hintISNOTEMPTY

検証範囲とおことわり

Australia の PDI（OOTB）で 2026-08-10 に確認しました。件数はこの環境の実測値です。

確認していないことがあります。実際に入力欄でコマンドを打っていません。テーブルのレコードから仕組みを読み取った内容で、画面での動きは見ていません。

独自のコマンドも追加していません。action_script の全文も読んでいません。先頭部分を見て、どの API を呼んでいるかを確認しただけです。

custom_event という動作タイプの使い方も分かりません。実機に例が1件も無いためです。

sys_ui_text_command は Australia の新規テーブル一覧に入っていました。応答テンプレートやメールテンプレートのテーブルは、新規リストにありません。コマンドの仕組みだけが後から足されたと考えられます。

関連記事

• メール通知の本文と枠の分担（Email Template/Layout） — e が呼ぶテンプレートの構造

• メール通知が飛ぶまでの4段階（Notification） — テンプレートの先にある仕組み

• ServiceNowの問い合わせはいつチケットにする？ — 応答テンプレートを使う場面