System Archiving（sys_archive）：古いデータを退避する仕組み
ServiceNow を長く使うと、テーブルの行がどんどん増えます。監査結果、通知の履歴、記事の閲覧記録。1件ずつは小さくても、数年で数十万件に膨らみ、一覧やレポートが重くなっていきます。かといって消してしまうと、後で「あの記録を見たい」となったとき困ります。
この「捨てたくないけれど、本番には置いておきたくない」という悩みに答えるのが System Archiving（アーカイブ） です。古い行を削除するのではなく、別の置き場へ「どかす」。本番テーブルは軽くなり、退避した行は必要なら戻せます。今回は、その仕組みを管理する sys_archive テーブルを、実機の規則とログで読み解きます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
アーカイブとは：捨てずに、どかす
まず言葉の整理から。アーカイブ（archive）は「保管庫にしまう」という意味です。ServiceNow のアーカイブは、本番テーブルの古い行を アーカイブ表 という別の置き場へ移す機能を指します。
これは「削除」ではありません。削除ならデータは消えてなくなります。アーカイブは、行を別の場所へ移すだけです。本番テーブルの一覧からは見えなくなりますが、データそのものは残っています。だから、後で必要になれば復元できます。
なぜ、わざわざ別の場所へ動かすのか。理由は本番テーブルを軽く保つためです。ユーザーが毎日開く一覧やレポートは、本番テーブルを検索します。ここに古い行が何十万件も混ざっていると、検索が遅くなる。使わない古い行を退避しておけば、日々の操作は軽いまま保てる、というわけです。
図にすると流れは単純です。本番テーブルの行を条件で選び、合うものをアーカイブ表へ移す。移した記録はログに残り、設定しだいで後から完全削除するか、退避したまま保持するかが分かれます。そして矢印は片方向ではありません。退避した行は、必要なら本番へ復元する道もあります。
まず一覧を見る：18本のアーカイブ規則
どの行を、いつ、どこへ退避するか。この取り決めを1件ずつ持つのが「アーカイブ規則（Archive Rule）」で、sys_archive テーブルに入っています。実機で一覧を開いてみました。
有効な規則（active=true）は 18件 ありました。全体では30件で、うち12件は無効です。一覧の列は Name（規則名）と Table（対象テーブル）、Active、Record estimate（対象件数の見積り）などが並びます。有効な18本は、この画面から数えられました。
対象テーブルを眺めると、性格がよく分かります。Knowledge Use（記事の閲覧記録）や Cert Audit Result（監査結果）が代表例です。ML Predictor Result（予測結果）や On-Call Escalation（オンコール通知）も対象でした。どれも「業務で毎日どんどん増えるが、1件ずつの価値は高くない」テーブルです。こういうデータこそ退避に向きます。逆に incident や problem のような主役テーブルには、初期状態では規則が用意されていません。
Record estimate 列が全行 0 なのも見どころです。これは「今すぐ退避すべき対象がゼロ」という意味で、規則が空振りしているわけではありません。過去に退避を済ませ、今は新しく条件に合う行が溜まるのを待っている状態、と読めます。
1つ開いてみる：kb_use の規則
一覧から、Knowledge Use の規則を開きます。名前は「Knowledge Use - Over a year old」。kb_use は、ナレッジ記事が閲覧されるたびに1行増える使用状況テーブルです。放っておくと際限なく膨らむので、退避の代表例になります。
フォームの上に赤い警告が出ています。「This is a High Risk file ...（これは高リスクな標準ファイル。必要がなければ変更するな）」。OOTB で用意された標準の規則は、ServiceNow のアップグレードで上書きされることがあります。だから標準規則はむやみに触らず、独自に足すなら新規に作るのが安全です。
項目を見ると、この規則の性格が読めます。Table は Knowledge Use [kb_use]。Active はオン。Retain references はオフ。Auto rearchive もオフ。右側の Estimate date は 2026-02-02、Next run date も同日で、定期的に実行される段取りです。画面右下の「Archive Run」タブには過去の実行回数が並び、この規則が繰り返し走ってきたことが分かります。
条件：「作成が1年より前」で古い行を選ぶ
規則の中心は Conditions（条件）です。kb_use の規則では、こう設定されていました。Created before One year ago。日本語にすれば「作成日が1年より前」。つまり、閲覧記録のうち1年以上前のものだけを退避の対象にします。
説明欄にも同じ趣旨が書かれています。「Archive Knowledge Use records that are created before this year（今年より前の行を退避する）」。条件の文と説明の文が、きちんと一致していました。直近1年ぶんは本番に残し、それより古い記録だけをどかす。日常の分析には最近のデータで足りることが多いので、理にかなった線引きです。
条件は規則ごとに違います。ある規則は「2年より前」、別の規則は「5年より前にクローズ」、オンコール系は「120日」。何を古いとみなすかは、そのデータをいつまで手元に置きたいかで決まります。監査結果のように長く保ちたいものは年単位、通知履歴のように短くてよいものは日単位。この条件の設計が、アーカイブ運用のいちばんの勘どころになります。
退避先は ar_ から始まる影のテーブル
条件に合った行の退避先は、元テーブルの名前に接頭辞 ar_ を付けた アーカイブ表 です。kb_use なら ar_kb_use、cert_audit_result なら ar_cert_audit_result。この「影のテーブル」が、本番と同じ構造で退避先を受け持ちます。
この命名は実機のログではっきり確認できました。次のログ画面で、退避元と退避先が並んで見えます。本番テーブルから ar_ 付きのテーブルへ、行がそっくり移る。元テーブルの一覧からは消えますが、ar_ 表の中には残り続けます。だから「見えないだけで、無くなってはいない」のがアーカイブの本質です。
アーカイブ表は本番と同じデータベースにあり、専用の画面から中身を確認できます。遠くのバックアップへ送るのとは違い、手元に置いたまま本番の一覧から外すイメージです。
実行ログ：どの行がどこへ移ったか
退避が走ると、その記録が sys_archive_log に1行ずつ残ります。「いつ、どのテーブルから、どのアーカイブ表へ、どの行を移したか」の台帳です。実機のログを開きました。
ログは全部で 759件 ありました。主な列は From table（退避元）と To table（退避先）、Created（実行日時）、Restored（復元日時）です。ID 列には元レコードへの参照が入ります。画面の行はすべて From table が cert_audit_result、To table が ar_cert_audit_result。監査結果が影のテーブルへ移った記録です。
内訳を数えると、cert_audit_result から 739 行、kb_use から 20 行で、合わせて759件。1行が1レコードの移動に対応します。Restored 列はすべて空でした。これは「まだ一度も本番へ戻していない」という意味です。退避しっぱなしで、復元の実績はまだ無い状態、と読み取れます。ログを見れば、どのテーブルの掃除がどれだけ進んだかが一目で分かります。
destroy_rule：いつ完全に消すか
アーカイブは削除ではない、と述べました。ただし、退避したまま永遠に持ち続けたいとは限りません。監査記録でも、法定の保存期間を過ぎたら消してよい、という運用は普通にあります。この「退避のあと、いつ完全に消すか」を受け持つのが destroy_rule（破棄規則）です。
実測した規則を見ると、破棄の設計が読めます。cert_audit_result は「7年」で完全削除、ml_predictor_results は退避から「1年」、catalog 系の分析データは「2年」。オンコール系は退避から60日で削除されます。一方、kb_use の規則には destroy_rule が設定されていませんでした。破棄規則が無ければ、退避した行は消されずに ar_ 表に残り続けます。
つまりデータの一生は二段階です。第一段階で本番からアーカイブ表へ退避し、第二段階で保存期間を過ぎたら完全削除する。この二段を分けているので、「本番は軽くしたいが、しばらくは戻せるようにしておきたい」という現実的な要望に応えられます。破棄規則を付けるかどうかは、そのデータをいつまで残す義務があるかで決めます。
規則の主な項目を表にまとめました。name と table と condition が「何を退避するか」を決め、destroy_rule が「いつ消すか」を決めます。retain_references と auto_rearchive は退避のふるまいを調整するスイッチ。record_estimate と total は件数の目安で、last_run_date と next_run_date が実行の段取りを示します。
retain_references：参照を壊さずに退避する
退避で気をつけたいのが、参照の整合です。ある行が別のテーブルの行を参照している場合、退避で参照先が見えなくなると、リンク切れが起きかねません。これを防ぐ設定が retain_references（参照の保持）です。
実測では、この設定は規則によって分かれていました。cert_audit_result、ml_predictor_results、cmdb_data_management_task の規則は retain_references がオン。一方、kb_use の規則はオフでした。参照を持つデータや、参照整合が大事なデータでは保持をオンにし、単純な使用ログのように参照の心配が薄いデータではオフのまま、という使い分けが見えます。
参照の保持をオンにすると、退避と復元のときに参照先との対応が保たれます。復元したときに「参照先が行方不明」という事故が起きにくい。この安心が、参照保持のいちばんの利点です。どのデータで参照を守るべきかは、そのテーブルの使われ方しだいで決まります。
auto_rearchive：戻した行をまた片づける
もう1つ、地味ですが便利なスイッチが auto_rearchive（自動再アーカイブ）です。これは「一度復元した行を、一定期間が過ぎたらまた自動で退避する」設定を指します。
たとえば古い監査結果を調査のために本番へ戻したとします。調査が終わっても、戻した行をそのまま放置すると、また本番に古いデータが居座ってしまう。auto_rearchive をオンにしておけば、指定した期間のあとに、その行を自動でアーカイブ表へ戻してくれます。手作業で片づけ直す手間が省ける、という発想です。
今回の PDI では、確認した規則すべてで auto_rearchive はオフでした。標準の規則では控えめな既定になっている、と読めます。復元をよく使う運用なら、この設定を検討する価値があります。
復元できる：退避は片道ではない
ここまで何度か触れたとおり、アーカイブの大きな安心材料は「戻せる」ことです。退避は片道の削除ではありません。必要になったら、アーカイブ表から本番テーブルへ復元できます。
規則のフォームには「Run Archive Now（今すぐ退避を実行）」や「Recalculate Archive Estimate（対象件数を再計算）」といった操作が並んでいました。退避を手動で走らせたり、対象件数を見積もり直したりできる仕組みです。復元も、アーカイブ表側の画面から行います。今回のログでは Restored 列がすべて空だったので、この環境では復元の実績はありませんでした。復元そのものの挙動確認は、今回の検証範囲の外です。
「消さずにどかす、必要なら戻す」。この性質があるからこそ、アーカイブは思い切って古いデータを片づける決断を後押しします。完全削除は取り返しがつきませんが、退避なら取り返しがつく。だから、まず退避で本番を軽くし、本当に不要と確信できたものだけ destroy_rule で消す、という二段構えが定石になります。
どんなテーブルが向くか
どんなテーブルがアーカイブに向くのか、実機で有効だった規則の対象を性格ごとにまとめました。
共通点は「増え続けるが、1件ずつの価値は低い」ことです。記事の閲覧記録や監査結果、予測結果、通知の履歴。どれも業務の副産物として自動で溜まり、古くなるほど参照されなくなります。こういうデータは、直近ぶんだけ本番に残し、古いものを退避するのが合理的です。
逆に、日々更新され、いつ参照されるか分からない主役データは、安易な退避に向きません。対象を選ぶときは「このテーブルは古い行がほとんど見られないか」「どのくらい前なら退避してよいか」を、業務の実態に照らして決めます。標準で用意された18本の規則は、その良いお手本になります。
なぜ本番を軽く保つのか
最後に、アーカイブが効く理由を性能の面から補います。データベースは、行が多いほど検索に時間がかかります。一覧を開く、レポートを集計する、条件で絞り込む。これらはすべてテーブルの走査を伴うので、行数が増えるほど遅くなっていきます。
アーカイブで古い行を別テーブルへ逃がすと、本番テーブルの行数が減ります。日常の操作が触るのは軽くなった本番テーブルだけ。古い行は ar_ 表で静かに眠り、必要なときだけ起こせばよい。この切り分けが、システム全体の反応を保ちます。数年ぶんのログが一箇所に積み上がって重い、と感じたら、まずアーカイブ規則の有無を確かめるのが定番の一手です。
削除との違いも、この文脈で腑に落ちます。削除は本番を軽くしますが、データを失います。アーカイブは本番を軽くしながら、データを失いません。「軽さ」と「安心」を両立させる折衷案が、退避という考え方です。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリックでの網羅確認は今回の範囲外です）。
アーカイブ規則の一覧 … sys_archive_list.do（Table 列で対象を確認）
アーカイブ規則1件 … sys_archive.do?sys_id=...（条件・破棄・保持を確認）
アーカイブ実行ログ … sys_archive_log_list.do（from / to / restored を確認）
まとめ
System Archiving は、古いデータを削除せずに退避し、本番テーブルを軽く保つ仕組みでした。取り決めは sys_archive の規則が持ち、有効な規則は18本。それぞれが「対象テーブル」「条件（何を古いとみなすか）」「破棄規則」を定めています。
退避した行は ar_<テーブル> の影の表へ移り、その記録が sys_archive_log に1行ずつ残ります。実機のログは759件で、監査結果と閲覧記録がアーカイブ表へ移っていました。destroy_rule を付ければ保存期間の後に完全削除、付けなければ退避したまま保持。そして必要なら復元できる。
「消さずにどかす。必要なら戻す」。この一点を押さえておくと、データが増えて重くなったときに、削除以外の選択肢が見えてきます。本番を軽くしたいけれど記録は失いたくない、という場面で、アーカイブは静かに効く仕組みです。
その他、実機で確認した記録
用語
アーカイブ規則（sys_archive） … 何を・いつ・どこへ退避するかの取り決め。1テーブルに1つ以上作れる
**アーカイブ表（ar_*）** … 退避先の影のテーブル。元テーブル名に接頭辞 ar_ が付く
アーカイブ実行ログ（sys_archive_log） … 退避した行の台帳。from / to / restored を記録
destroy_rule（破棄規則） … 退避のあと、いつ完全削除するか。空なら保持し続ける
retain_references … 退避・復元で参照整合を保つか
auto_rearchive … 復元した行を一定期間後にまた自動で退避するか
調べるときの入口URL（先頭に自分のインスタンスを付ける）
/sys_archive_list.do?sysparm_query=active=true（有効なアーカイブ規則）
/sys_archive.do?sys_id=...（1規則の条件・破棄・保持）
/sys_archive_log_list.do（退避の実行ログ）
実測の要点（再掲）
アーカイブ規則: active=18件（全30件）。対象は kb_use / cert_audit_result / ml_predictor_results など
kb_use の条件は「Created before One year ago（作成が1年より前）」、退避累計 total=20
実行ログ 759件（cert_audit_result=739、kb_use=20）。退避先は ar_ 付きの表、Restored はすべて空
destroy_rule は規則ごと（7年 / 2年 / 1年 / 60日 等）。kb_use には未設定
関連記事
ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — この記事のsys_archiveは、親記事で扱うアーカイブの詳細編。添付・履歴・ログまで含めたデータの溜まり方と消え方は、この親記事で確認できる。
検証範囲とおことわり
この記事の件数・項目・条件・退避先の名前は、PDI（Zurich / OOTB）の実測です。
「Run Archive Now」で新規に退避を走らせる／復元する挙動は、本記事では未実行（検証範囲外）。既存ログは過去の実行結果です。
destroy_rule の実際の破棄タイミングは、規則名と説明からの読み取りで、破棄の発火自体は未観測です。
標準の規則は「High Risk」の OOTB レコードで、実機では原則書き換えません。
