Rollback & Recovery（sys_rollback_context）：変更を丸ごと戻す
ServiceNow を触っていると、「さっきの操作、まとめて無かったことにできたらいいのに」と思う瞬間があります。背景スクリプトを流したら想定より多くのレコードを書き換えてしまった、削除の一括処理をかけたら消しすぎた、といった場面です。こういう「操作のまとまり」を、丸ごと元に戻すための仕組みが Rollback & Recovery です。
その中心にいるのが sys_rollback_context というテーブルです。日本語では「ロールバックコンテキスト」と呼びます。1回の操作を1つの「見出し」として記録し、その操作で触れた行を明細としてぶら下げる。あとから見出しを選べば、その操作だけをまとめて取り消せる、という設計になっています。
この記事では、ロールバックの見出し（context）と明細（sequence）の2つのテーブルを、実機の件数つきで読み解きます。難しい復元操作の手順書ではありません。「どこに、何が、どうやって残っているのか」を落ち着いて確認する回です。仕組みの地図を持っておくと、いざというときに慌てずに済みます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
ロールバックとは：操作のまとまりを丸ごと戻す
ロールバックは、データベースの世界でよく使う言葉です。ServiceNow では「ある操作が触れたレコードを、その操作の前の状態にまとめて戻すこと」を指します。1行だけを戻すのではありません。「その操作が触れた全部」を、ひとまとまりで戻すのが特徴です。
たとえば背景スクリプトを1回実行したとしましょう。そのスクリプトが incident を3件作ったなら、ロールバックはその3件をまとめて消して、実行前の状態に戻します。アプリを1つインストールしたなら、そのインストールが持ち込んだ設定やテーブルを、ひとかたまりで巻き戻せます。「操作単位で戻せる」ことが、1行ずつ手で直すのとの大きな違いです。
ふつうの操作履歴（audit）との違いも、ここで押さえておくと混乱しません。audit は「このフィールドが、いつ、何から何へ変わったか」を1項目ずつ残す記録です。片やロールバックが扱うのは、「この操作が触れた行の集合」という、もっと大きな単位です。だから audit は「1つの値の変化」を追うのに向き、ロールバックは「1回の操作」をまるごと戻すのに向いています。目的の違う2つの仕組みだ、と分けて捉えると、それぞれの出番が見えてきます。
図にすると流れは素直です。操作を実行すると、ロールバックコンテキストが1件生まれる。その操作で触れた行ごとに、明細（sequence）が記録される。しばらくは「復元できる状態」で保たれ、必要なら丸ごと戻せます。時間が経つと期限切れになり、明細は残りません。この一本道を頭に入れておくと、後の話がすっと入ってきます。
見出しと明細：2つのテーブルの役割
ロールバックは、2つのテーブルの組み合わせで成り立っています。役割がはっきり分かれているので、まずここを押さえます。名前は似ていますが、片方は「操作の見出し」、もう片方は「行ごとの明細」と、担当がくっきり分かれた関係です。
sys_rollback_context（見出し）
sys_rollback_context は、1回の「戻せる操作」の見出しです。番号は BAK で始まります（例: BAK0001871）。1つの操作につき1件だけ作られる、いわば表紙のような存在です。実機には 396件 ありました。Type（操作の種類）、State（状態）、Created by（作成者）といった、操作の素性を表す列を持っています。
sys_rollback_sequence（明細）
sys_rollback_sequence は、その操作で触れた1行ごとの記録です。「どのテーブルの、どのレコードに、どんな操作をしたか」を1件ずつ残します。実機には 131件 ありました。見出しが396件に対して明細が131件と少ないのは、後で触れる「期限切れ」が理由です。1つの見出しに、複数の明細がぶら下がる親子関係になっています。
どんな操作が記録されるのか
ロールバックの対象になる操作を context の Type で集計すると、実機ではこの4種類に分かれていました。
一番多いのは App Installation（アプリのインストール）で155件です。次いで Deleted Record(s)（レコードの一括削除）が115件でした。Test Execution（自動テストの実行）が76件、Scripts - Background（背景スクリプトの実行）が50件と続きます。合計はちょうど396件になります。
選択肢としては、この4種類のほかにも用意がありました。Dist Upgrade（アップグレード）や Plugin Activation（プラグイン有効化）、Data Anonymization（データ匿名化）、Flow などです。全部で12種類がそろっていました。共通しているのは、どれも「一度にたくさんのレコードを動かす操作」だという点です。手作業で1件直すような操作は対象外で、まとめて動く操作にだけ、戻すための保険がかかります。「規模の大きい操作ほど、戻せる備えがある」という設計思想が読み取れます。
とくに実務で覚えておきたいのが Deleted Record(s) です。一括削除は、ミスに気づいたときの被害が大きい操作です。だからこそ削除には戻すための記録が残る、という設計は理にかなっています。実際、削除まわりの context が115件と多いのも、削除が「戻せると安心な操作」の代表だからだと読めます。
Test Execution が76件と多いのも、この仕組みの性格をよく表しています。自動テストは、走ったあとにテストデータを残さないのが理想です。テストのたびに incident を作ったり消したりして、その痕跡が本番相当のデータに混ざっては困ります。そこで、テストが触れた変更をまとめて巻き戻す。その後片付けに、ロールバックの仕組みが使われている、と読めます。つまりロールバックは「事故の復旧」だけでなく、「決まった処理をきれいに終える」ための下支えにもなっています。
状態と保持：recorded と expired
context には State（状態）があります。実機の396件を集計すると、状態はきれいに2つに割れていました。
recorded（復元できる状態）
State が「Finished recording（recorded）」のものが 17件 ありました。これは記録が済んで、まだ生きている状態です。この状態のあいだは、その操作を丸ごと戻せます。実機で recorded の中で一番古いのは、2026-07-10 に作られた BAK0001783 でした。
expired（期限切れ）
残りの 379件 は「Expired（期限切れ）」でした。こちらは有効期間を過ぎた状態です。実機で expired の中で一番新しいのは、2026-07-09 に作られた BAK0001778 でした。つまり境目は 07-09 と 07-10 のあいだにあり、確認日の 2026-07-20 から数えると、おおよそ直近10日ぶんだけが recorded として残っている計算になります。
ここに、見出しと明細の件数差の理由が隠れています。expired になった context の明細を調べると、行数はゼロでした。期限切れになると、見出し（BAK番号）は台帳として残る一方で、行ごとの明細は消えていきます。だから見出しは396件あっても、明細は生きている分の131件しか残らない、というわけです。「戻せるのは、あくまで新しい操作だけ」という前提は、運用で頭に入れておきたいところです。
この「約10日」という値は、あくまで実機の境目から見えた目安です。retention（保持期間）を決める設定はプラットフォーム側にあり、環境によって変わる余地があります。だから本番で「何日までなら戻せるか」を厳密に当てにするのは避けたほうが無難です。日数を暗記する必要はありません。「時間が経つほど戻せなくなる」という向きだけ、はっきり掴んでおくことです。おかしいと気づいたら、その日のうちに確認する。この習慣が、いちばん確実な備えになります。
実例：背景スクリプトの BAK0001866 を追う
抽象的な話が続いたので、1件の見出しを具体的に追ってみます。題材は BAK0001866。Scripts - Background（背景スクリプトの実行）で、2026-07-18 18:53 に作られた、recorded 状態の context です。
この見出しにぶら下がる明細を数えると、ちょうど3件ありました。3件とも Operation が「Delete」で、対象テーブルはすべて incident です。読み解くと、こういう話になります。背景スクリプトを1回流したら、incident が3件生まれた。その3件が明細として記録され、「戻すときはこの3件を消せばよい」と分かる状態で保たれている、というわけです。
なぜ背景スクリプトがロールバック対象になるのか。この点は、同じシリーズの開発編で確認済みです。スクリプトを流す画面（Scripts - Background）には「Record for rollback」という選択肢があります。これが既定でオンになっていて、実行するとこの rollback context が自動で作られます。うっかり大量更新しても、直後なら戻せる。開発者にとっての安全網が、実行のたびに静かに用意されている、と捉えると分かりやすいです。
同じ背景スクリプトでも、明細の数はまちまちでした。実測では、BAK0001865 の下に12件、BAK0001829 の下に8件ぶら下がっていました。先ほどの BAK0001866 は3件です。触れた行の数だけ、明細が並ぶわけです。つまり明細の件数は「その実行が何行に触れたか」をそのまま映します。見出しを1件開けば、その操作の規模が明細の数で分かる、という読み方もできます。
明細の中身を読む
明細テーブル（sys_rollback_sequence）の一覧を開くと、1行ずつの記録の細かさが見えてきます。
注目したいのは Document ID の列です。ここには sys_script_execution_history:（sys_id） のように、「どのテーブルの、どのレコードか」がそのまま入っています。隣の Operation には insert / update / delete のいずれかが記録されます。131件の内訳は、update が99件、insert が17件、delete が15件でした。つまり明細は「この1行に、この操作をした」という粒度で、戻すべき対象を1件ずつ指し示しています。
対象テーブルの内訳も見ておきます。131件のうち96件が sys_script_execution_history、つまりスクリプト実行の履歴でした。ほかに incident が8件、sysrule_escalate_history が10件などと続きます。Is metadata という列は「設定（メタデータ）か、業務データか」を区別するためのフラグで、実機の一覧では false が並んでいました。1件の見出しの下に、この粒度の明細がずらりと並ぶ。それがロールバックの「戻せる根拠」になっています。
もう1つ、明細には Context という列があります。ここには、その明細がどの見出し（BAK番号）に属するかが入ります。見出しから明細をたどることも、明細から見出しへ戻ることもできる、双方向の紐づけです。だから調査のときは、どちらの側から入っても迷いません。「この行は、どの操作で触られたのか」を知りたければ Context をたどり、「この操作は、どの行に触れたのか」を知りたければ見出しから明細を開く。同じ親子関係を、目的に応じて上からも下からも読める、という作りになっています。
context の一覧を見ると、これらの記録が「日々、自動で」積み上がっている様子が分かります。
Created by（作成者）で集計すると、admin が231件、system が162件でした。残りはごく少数です。system が多いのは、定期的な削除やクリーンアップのような、システム側の自動処理がロールバック対象になっているからだと読めます。人が明示的に「戻せるようにしよう」と設定しなくても、対象の操作をすれば記録は自動で残る、という点が大切です。
一覧の From Version / To Version という列には、操作元を表すラベルが入っていました。背景スクリプトなら「sys.scripts: admin（日時）」、削除の復元なら「Delete Recovery: admin（日時）」のように、どの操作から生まれた見出しかが読み取れます。BAK番号を眺めるだけで、「いつ、誰の、どの操作の記録か」が台帳のように追える。これが、あとから調査するときの入口になります。
実務での使いどころと注意
使いどころ
一番の使いどころは、「やってしまった直後」の復旧です。背景スクリプトや一括削除で想定外の変更をしてしまったとき、recorded のうちなら見出しを選んで丸ごと戻せます。1件ずつ手で直すより速く、抜け漏れも起きにくい。だから大きめの操作をする前には、「これは rollback 対象か」を意識しておくと安心です。もう1つの使いどころが、調査です。「いつ、どの操作が、どれだけのレコードを動かしたか」を、BAK番号の台帳から追えます。
初めて触る PDI で、まずやってみたいことも書いておきます。背景スクリプトを1回流し、sys_rollback_context_list.do を開いてみる。すると、たった今の実行が Scripts - Background の1件として増えているはずです。その1件を開けば、明細に「自分が触れた行」が並びます。実際に戻すかどうかは別として、「操作が記録に変わる瞬間」を目で見ておくと、仕組みへの納得感がまるで違います。読むだけより、1回動かすほうが早い、という典型です。
注意点
注意点も正直に書いておきます。第一に、戻せるのは新しい記録だけです。expired になった見出しからは、明細が消えていて復元できません。「気づいたら早めに」が鉄則になります。第二に、すべての操作が対象ではありません。ロールバック対象は、まとめて動く特定の操作に限られます。第三に、この記事は context と sequence の構造・件数の確認にとどめており、実際に「Roll back」を押して復元が走る様子までは試していません。本番で戻す操作は影響が大きいため、手順と影響範囲を確かめてから行うのが安全です。
その他、実機で確認した記録
用語
ロールバック（rollback） … ある操作が触れたレコードを、操作前の状態にまとめて戻すこと
rollback context（sys_rollback_context） … 1回の戻せる操作の見出し。番号は BAK で始まる
rollback sequence（sys_rollback_sequence） … その操作で触れた1行ごとの明細
recorded（Finished recording） … 記録済みで、まだ復元できる状態
expired … 有効期間を過ぎ、明細が残らない状態
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/sys_rollback_context_list.do（ロールバックコンテキストの一覧）
/sys_rollback_context_list.do?sysparm_query=state=recorded（復元できる状態だけに絞る）
/sys_rollback_sequence_list.do（明細の一覧）
/sys_rollback_context_list.do?sysparm_query=type=delete（一括削除の記録だけ）
実測の要点（再掲）
context 総数 396件 / sequence 総数 131件
Type: App Installation 155 / Deleted Record(s) 115 / Test Execution 76 / Scripts - Background 50
State: recorded 17 / expired 379（境目は 2026-07-09 と 07-10 のあいだ、直近およそ10日ぶんが recorded）
作成者: admin 231 / system 162 ほか少数
実例 BAK0001866（背景スクリプト）→ 明細3件、いずれも Delete / incident
関連記事
ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — ロールバックで戻せるのは記録が生きている期間だけ。データがどこにどれだけ溜まり、いつ消えるかを確認しておくと、rollbackの限界も見えやすい。
検証範囲とおことわり
件数・状態・Type の内訳は、PDI（Zurich / OOTB）の実測です。
実際に「Roll back」を押して復元が走る挙動は、今回は未実行（検証範囲外）です。
保持のおよそ10日は、recorded と expired の境目からの推定です。期限を決める設定値そのものは未確認です。
Operation（insert/update/delete）は「その行に記録された操作」として扱い、戻す向きの厳密な意味づけは範囲外としました。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
まとめ
Rollback & Recovery は、「操作のまとまりを丸ごと戻す」ための静かな安全網でした。見出しの sys_rollback_context（実機396件）が1回の操作を表し、明細の sys_rollback_sequence（実機131件）が触れた行を1件ずつ記録する。この親子構造が、戻せる根拠になっています。
状態は recorded と expired の2つに割れ、戻せるのは新しい recorded だけでした。背景スクリプトや一括削除のような「まとめて動く操作」をすると、記録は自動で積み上がります。覚えることは1つで十分です。「戻せるのは、今のうち」。だから普段は意識しなくても、いざというときに「あの操作、戻せるかも」と思い出せることが大切です。BAK番号の台帳がそこにある、と知っているだけで、大きな操作の前の心持ちが少し軽くなります。
