ServiceNowの変更申請テンプレートには切り戻し手順まで入っている？ sttrm_base_templateを実機で読む
変更申請を書くたびに、実施手順とリスク分析と切り戻し手順を毎回ゼロから書いている。そんな運用になっていないでしょうか。ServiceNowには変更申請のテンプレートを保持する仕組みがあり、標準で入っているものを開いたところ、実施手順だけでなくリスク分析・切り戻し手順・テスト計画まで文章で埋まっていました。子タスクも計画から振り返りまで4段階が用意されています。
検証環境：Australia PDI / OOTB / 2026-08-10 確認
結論：親テンプレートが8項目を埋め、子タスクが4段階に分かれる
先に構造です。
図の色は意味を持たせています。紺が起点で、緑が変更申請そのもの。青が子タスク、橙が実行順を示します。灰色はこの環境で使われていない部分です。
sttrm_base_templateに7件。変更申請用と、タスク用が混在しています
sttrm_child_record_templateに4件。親テンプレートに紐づく子タスクです
親を選ぶと、申請の8項目が埋まり、子タスクが4件ぶら下がる構造になっています
埋まるのは概要だけではない
まず、変更申請用のテンプレートを開いてみます。
「Reboot Server」という名前のテンプレートがありました。データセンターのサーバーを再起動する、という内容です。
中身を見て意外だったのは、埋まる項目の多さでした。
概要と詳細だけではありません。埋まっていたのは次の5つです。
なぜ必要か（justification）
どう実施するか（implementation_plan）
どんなリスクがあるか（risk_impact_analysis）
失敗したらどう戻すか（backout_plan）
どう確認するか（test_plan）
変更管理で書くべき項目が、ひととおり文章で入っている状態でした。
切り戻し手順の具体性
なかでも目を引いたのが切り戻し手順です。サーバー再起動のテンプレートには、こう書かれていました。
サーバーが起動しない場合、あるいは必要なサービスが想定時間内に立ち上がらない場合の手順が書かれています。KVM-over-IPなどのリモートコンソールで接続する。強制的な電源循環を試す。それでも駄目ならハードウェアチームにエスカレーションする。
「切り戻す」の一言ではありません。どの手段で接続し、何を試し、駄目ならどこに引き継ぐかまで書いてあります。
リスク分析も同様でした。低〜中程度のリスクで、影響はサーバー上のサービスが5〜15分停止すること。主なリスクは再起動後に起動しないことで、その場合は停止が長引きます。時間の見積もりまで入っていました。
子タスクは計画から振り返りまで4段階
もうひとつのテンプレート「Replace LHR storage」には、子タスクが紐づいていました。ストレージアレイの故障したSSDを交換する、という内容です。
4件がparent_templateで親を指しています。順番はorderで決まっていて、100・200・300・400と100刻みでした。
計画では範囲と要員と日程を決め、交換部品の型番を確認し、作業窓を確保します。実装で物理的にホットスワップし、管理ソフトが新しいドライブを認識してリビルドが始まるのを確認。テストではリビルドの完了まで監視し、冗長状態への復帰とエラーログを確かめます。そしてレビューで変更をクローズし、資産台帳のシリアル番号まで更新する流れになっていました。
最後の「資産台帳の更新」まで入っているのが実務的です。作業が終わってから忘れがちな部分が、タスクとして残ります。資産側の台帳がどう作られているかは資産(alm_asset)とCMDB(cmdb_ci)を分ける理由で扱いました。
order が100刻みである理由
orderが1・2・3・4ではなく100・200・300・400になっているのは、間に差し込む余地を残すためでしょう。承認待ちや部門調整のタスクを150に入れれば、既存の番号を振り直さずに済みます。
これはServiceNowの他の設定でもよく見る作りです。実行順を数値で持つ仕組みは、たいてい間隔を空けてあります。同じ考え方はBusiness Ruleの実行順にも出てきます。
テーブルの構成を確認する
sttrm_で始まるテーブルは7件ありました。State Transition Template の略と読めます。
実際にデータが入っているのは2つだけです。親テンプレートと子テンプレート。分類を保持するsttrm_categoryは0件でした。
分類の仕組みは用意されているが、標準では使われていない。テンプレートが7件しかない現状では分類する必要がないので、数が増えてから使う想定なのでしょう。
テンプレートの中身はどう保存されているか
templateという列に、設定値がまとめて入っていました。形式はこうです。
assignment_group=26b8a93d...^category=System Software^short_description=Reboot a server...^EQキー=値を^で連結し、末尾に^EQが付きます。ServiceNowのクエリ文字列と同じ書き方です。
この持ち方には利点があります。項目を追加するたびにテーブルの列を増やす必要がありません。変更申請に新しいフィールドを作っても、テンプレート側は文字列に1組足すだけで対応できます。
一方で読みにくさもあります。1件の中身を確認するには文字列を目で分解することになるので、画面から編集する前提の作りだと分かります。
同じ形式は他でも使われている
この^区切りの形式は、ServiceNowのあちこちで見かけます。一覧のフィルタ条件、参照フィールドの絞り込み条件、そしてテンプレート。共通の書き方を使い回しているわけです。
覚えておくと、URLに条件を直接書いて画面を開くときにも役立ちます。この記事の末尾に載せているURLも同じ形式です。
変更申請を書く手間はどれだけ減るか
テンプレートを使わない場合、担当者は毎回8項目を書きます。そのうち実施手順・リスク分析・切り戻し・テスト計画の4つは、文章量が多い部分です。
サーバー再起動のように定型的な作業なら、内容はほぼ同じになります。それでも毎回書くと、次の問題が出ます。
書く人によって粒度がばらつきます。 切り戻し手順を「元に戻す」と1行で済ませる人と、接続手段まで書く人が混在します。承認する側は、粒度の違う申請を同じ基準で判断できません。
急いでいるときほど雑になります。 障害対応に付随する変更では、書く時間が惜しい。結果として、いちばんリスクの高い場面でいちばん薄い申請書が出てきます。
テンプレートは、この2つを同時に解決します。定型作業については、粒度の揃った文章が最初から入る。急いでいても品質が落ちません。
逆に注意したい点
ただし、テンプレートをそのまま出すだけでは意味がありません。中身を読まずに提出する運用になると、書かれている切り戻し手順が実態と合わなくなります。
たとえばサーバー再起動のテンプレートには「KVM-over-IPで接続」と書かれていますが、その環境にKVM-over-IPが無ければ実行できません。テンプレートは出発点であって、現場に合わせた調整が要ります。
導入するなら、テンプレートを適用したあとに必ず読み合わせるという手順まで含めて決めておくのがよさそうです。
実機を見て気づいたこと
いちばん引っかかったのは、同じ名前のテンプレートが親と子の両方にあることでした。
sttrm_base_templateの7件には、Planning task・Implementation task・Testing task・Review taskという名前のものが含まれています。そしてsttrm_child_record_templateにも、同じ4つの名前があります。
親側のこれらはtableがchange_taskになっていました。つまり単体のタスクテンプレートとしても登録されていて、同時に「Replace LHR storage」の子としても登録されている、という状態です。単独で使うときと、親から呼ばれるときの両方に対応しているのだと考えられます。ここは推測です。実際に画面から適用して確かめたわけではありません。
もうひとつ気になったのが、Reboot Serverが2件あることです。名前も内容もほぼ同じで、違いはshort_descriptionだけでした。片方には「Reboot a server in the datacenter」という説明文が、もう片方には「Reboot Server」という短い文字列が入っています。
意図的な使い分けなのか、デモデータを作る過程で重複したのかは分かりません。ただ、テンプレート一覧に同じ名前が2つ並ぶと、利用者はどちらを選べばよいか迷います。自分の環境で作るときは、名前で区別がつくようにしたほうがよさそうです。
そして、これらのテンプレートがAIで生成された文章に見える点も記録しておきます。文体が均質で、どの項目も同じ構成でした。断定はできませんが、標準データの作り方が変わってきている可能性はありそうです。
実務では何に使えるか
このテンプレートは、そのまま使うものというより書くべき項目の見本として価値があると思います。
自社の変更申請フォームに、切り戻し手順の欄はあるでしょうか。あったとして、そこに何を書くべきかが定義されているでしょうか。「異常時は元に戻す」としか書かれていない申請書は、実際に異常が起きたときに役に立ちません。
標準テンプレートの切り戻し手順は、接続手段・試すこと・エスカレーション先の3つが書かれていました。この粒度を自社の基準にする、という使い方ができます。
判断の材料としても使えます。承認者が申請書を見たとき、切り戻し手順がこの粒度で書かれていれば「実際に戻せる」と判断できます。逆に1行しか書かれていなければ、書いた本人も戻し方を考えていない可能性が高い。切り戻し手順の具体性は、その変更がどれだけ検討されたかの目安になります。
同じことは実施手順にも言えます。「パッチを適用する」だけの申請書を見たことはないでしょうか。標準テンプレートのほうは違いました。関係者への通知から始まり、SSHでの正常停止、電源循環の待機、OS起動の確認と続きます。どちらの申請書で当日を迎えるかで、作業の品質は変わってくるはずです。
子タスクの分け方を借りる
計画・実装・テスト・レビューという4分割も、そのまま参考にできます。
多くの現場では実装だけがタスクになりがちです。計画を独立したタスクにすると、作業窓の確保や部品の手配が誰の担当か明確になります。レビューを独立させると、資産台帳の更新のような後処理が漏れません。誰に割り当てるかを自動で決める仕組みは自動割り当ての2つの仕組みにまとめています。
テンプレートを増やす前に決めること
テンプレートが増えると、今度は選ぶのが難しくなります。sttrm_categoryという分類の仕組みが用意されているのは、そのためでしょう。
標準では0件でしたが、自社で10件を超えるあたりから分類が必要になるはずです。何件まで増やすか、どう分類するかを先に決めてから作り始めるほうが、後で整理する手間が省けます。同じ悩みはカタログでも起きます。増えすぎたときの扱いはカタログアイテムが見えない・申請できないでも触れました。
既存の仕組みとの関係
ServiceNowの変更管理には、以前からChange Modelという仕組みがあります。標準・通常・緊急の3ルートと、それぞれの承認ステップを定義するものです。詳しくはChange Requestのtypeで承認が変わる仕組みと変更の流れを決めるChange Modelで扱いました。
今回のテンプレートは、それとは別の層にあります。Change Modelがどういう順で承認を通すかを決めるのに対し、テンプレートは申請の中身に何を書くかを決めます。承認の流れと、記載内容。役割が違うので、両方を組み合わせて使うことになります。
ただし、両者がどう連携するのかまでは確認できていません。テンプレートを適用したときにChange Modelが自動で選ばれるのか、それとも別々に指定するのか。ここは実際に画面から作ってみないと分かりません。
変更管理の全体像は変更管理（Change）完全ガイドにまとめています。
この機能はZurichには無かった
sttrm_のテーブル群は、Zurichには存在しませんでした。新しいリリースで追加されたものです。
関連するプラグインとしてcom.snc.itsm.state_transition_model.flowsとcom.snc.change_management.flowsが有効になっていました。名前から見て、状態遷移のモデルとテンプレートが一体で導入されたようです。プラグインの有効・無効をどこで確認するかはプラグインの依存関係で扱っています。
既存の環境を上げた場合にどうなるかは確認していません。今回は別々に作成された2つのインスタンスを比較しただけなので、移行時の挙動については何も言えません。
標準の2件から読み取れる「想定される使い方」
用意されているテンプレートは、変更申請用が実質2種類でした。サーバー再起動と、ストレージのSSD交換です。
この2つが選ばれている理由を考えると、テンプレートに向く作業の条件が見えてきます。
手順が毎回同じであること。 サーバー再起動は、対象が違っても手順は変わりません。停止して、起動して、確認する。だからテンプレート化できます。
リスクが読めること。 5〜15分の停止、という見積もりが書けるのは、過去に何度もやっているからです。初めての作業ではリスク分析を事前に書けません。
頻度が高いこと。 年に1回の作業をテンプレートにしても、次に使うときには環境が変わっています。維持コストのほうが上回ります。
逆に言うと、一度きりの大規模な変更にはテンプレートが向きません。そういう変更は個別に設計するものだからです。テンプレートを作るべき対象を選ぶときは、この3条件で振り分けるとよさそうです。
子タスクが1件にしか付いていない理由
親テンプレート2件のうち、子タスクが紐づいているのはSSD交換のほうだけでした。サーバー再起動には子タスクがありません。
作業の複雑さの違いだと考えられます。再起動は1人が連続して実施できるもの。SSD交換は計画・実装・テスト・レビューで担当者が変わる可能性があります。物理作業なのでデータセンター側の要員も要るでしょう。
タスクに分ける必要があるかどうかは、担当者が分かれるかどうかで決める。 この使い分けは自社でテンプレートを作るときの目安になります。
変更管理の成熟度を測る材料としても使える
少し違う角度の話をします。
この標準テンプレートは、ServiceNowが考える「あるべき変更申請」の姿です。自社の申請書と並べてみると、足りない項目が見えます。
正当性（justification）の欄はあるでしょうか。「なぜ今やる必要があるのか」を書かせていない組織は少なくありません。承認者はこれが無いと、緊急性を判断できません。
テスト計画はどうでしょうか。実施手順は書いても、「終わったことをどう確認するか」は書いていない申請書をよく見ます。確認方法が決まっていないと、変更が成功したかどうかを誰も判定できません。
リスク影響分析に、時間の見積もりが入っているでしょうか。標準テンプレートには「5〜15分」と具体的な数字が書かれていました。この粒度で書けるかどうかが、変更管理が回っているかの目安になります。
自社の申請書に足りない欄があったとき、いきなり必須項目を増やすと現場の反発を招きます。まずテンプレートとして提供し、書きやすくしてから定着させる。この順序なら受け入れられやすいはずです。
導入するときに決めておきたいこと
実際にテンプレートを整備するなら、先に決めておく点があります。
誰がテンプレートを作るか。 変更管理のプロセス責任者が作るのか、各作業チームが自分で作るのか。後者だと数は増えますが品質がばらつきます。
どこまで埋めるか。 全項目を埋めたテンプレートは楽ですが、考えずに提出される危険があります。あえて一部を空欄にして、担当者に考えさせる設計もあり得ます。
いつ見直すか。 環境が変われば切り戻し手順も変わります。年に1回など、棚卸しの周期を決めておかないと、古い手順が残り続けます。
使われているかをどう測るか。 テンプレートを作っても使われなければ意味がありません。適用されたかどうかを追える仕組みが要ります。この観点はカタログアイテムが見えない・申請できないで扱った「作ったのに使われない」問題と同じ構図です。
標準で2件しか用意されていないのは、たくさん作ることが目的ではないという示唆にも読めます。よく使う作業から少しずつ、というのが現実的な進め方でしょう。
この記事で確かめたこと
最後に、今回やったことを整理します。
sttrm_で始まるテーブルを7件見つけ、そのうち実データがあるのは2件でした。親テンプレート7件と、子タスク4件です。親テンプレートには変更申請用と単体タスク用が混在していました。
変更申請用のテンプレートを開くと、8項目が文章で埋まっていました。実施手順だけでなく、正当性・リスク影響分析・切り戻し手順・テスト計画まで含まれます。切り戻し手順には接続手段とエスカレーション先が具体的に書かれていました。
子タスクは計画・実装・テスト・レビューの4段階で、orderが100刻みです。最後のレビューには資産台帳の更新まで含まれていました。
分からなかったこともあります。テンプレートを適用したときに画面がどう変わるか、既存のChange Modelとどう連携するか、同名の親子テンプレートがなぜ両方あるのか。これらは実際に適用してみないと確かめられません。次に触る機会があれば、そこから見ていくつもりです。
用語
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
ホットスワップ：機器を停止せずに部品を交換すること
リビルド：RAIDで冗長性を復旧する処理
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sttrm_base_template_list.do … 親テンプレートの一覧
/sttrm_child_record_template_list.do … 子タスクのテンプレート
/sttrm_base_template_list.do?sysparm_query=table%3Dchange_request … 変更申請用だけに絞る
/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsttrm … 関連テーブルの一覧
関連記事
ServiceNow 変更管理（Change）完全ガイド：3つのルートと6つのモデルを実機で追う — 変更管理の全体像から読む場合はこちらが入口です。
Change Request：typeで承認が変わる（change_request） — 承認の流れとテンプレートの違いを理解する前提になります。
変更の流れを決める Change Model（chg_model） — モデル側の仕組みを扱っています。
検証環境と未検証範囲
確認した範囲：Australia PDI（OOTB）におけるsttrm_系7テーブルの件数、sttrm_base_template7件とsttrm_child_record_template4件の中身、および各テーブルの一覧画面。すべてREST APIと画面の読み取りのみで、テンプレートの適用やレコードの作成は行っていません。
確認していない範囲（断定しません）：テンプレートを実際に適用して変更申請を1件作るところ、show_on_template_barが画面のどこに効くか、既存のChange Modelや標準変更テンプレートとの連携、sttrm_categoryを使った場合の変化、同名の親テンプレートと子テンプレートが両方ある理由。これらは別途の検証が必要です。
この機能はZurichには存在しませんでした。ただし本記事は2つの別々のPDIを比較した結果であり、既存環境をアップグレードした場合の挙動は確認していません。
