ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認
「このIncidentに付けた添付ファイルはいつまで残るのか」「間違って消したレコードは戻せるのか」。ServiceNowを使っていると、1件のレコードの周りにどんどんデータが増えていくのに、掃除の仕組みは画面のどこにも見えません。結論はシンプルです。自動で消えるデータもあれば、規則が無く増え続けるデータもあります。Zurich PDIでTable Cleaner（sys_auto_flush）の設定を1件ずつ実機で確認し、何が・どこに・何日で消えるかを対応表にしました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：消えるデータと消えないデータの境界
自動で消えるのはsyslog・syslog_transaction・sysevent・sys_history_set（本体）・sys_rollback_context（Expiredになった記録のみ）の5系統です。添付ファイル・監査ログ（sys_audit）・Comments/Work notes（sys_journal_field）・送受信メール（sys_email）には、自動削除の規則そのものがありませんでした
消える保持期間はテーブルごとに固定です。実測ではsyslogが90日、syslog_transactionが56日、syseventが7日、sys_history_set（本体）が30日、sys_rollback_context（Expired後）が365日でした
「消えない」を放置した場合の逃げ道もあります。System Archiving（sys_archive）で退避すれば、規則の多くには完全削除（destroy_rule）まで用意されていますが、規則が無いテーブルはそのまま増え続けます
何のデータが、どこに溜まり、自動で消えるかどうかをまとめたのが次の対応表です。自分が気にしているデータがどの行に当たるかで、そのまま答えになります。
表だけでは全体の流れが分かりにくいので、1件のレコードが生まれてから付随データが増え、掃除・退避され、環境をまたぐまでの流れも図にしました。
起点は1件のレコードが生まれることです。採番されたその瞬間から、添付ファイル・監査ログ・Comments/Work notesが付随データとして積み上がっていきます。並行して会社や拠点といったマスタに紐づき、操作のたびにシステムログが溜まります。ここから先が本記事の核心です。溜まったログのうち一部はTable Cleanerで自動的に消え、一部は規則が無いまま残り続けます。さらにアーカイブやロールバックという退避・巻き戻しの仕組みがあり、クローンやアップグレードで環境をまたぐと何が残るかも変わります。
1. レコードに付いてくるもの：添付・監査ログ・採番
新しいレコードが作られた瞬間に最初に起きるのが採番です。sys_numberには147件のルールがあり、テーブルごとにprefixと桁数を管理しています。
レコードができると、そこに添付ファイル・変更履歴・追記が積み重なっていきます。この3種類はどれも自動では消えません。添付ファイルの実体を持つsys_attachmentは2,999件で、table_name別に見るとincidentは11件でした。上位を占めるのはZZ_YYや invisible.といった接頭辞が付くシステム内部の隠し添付で、業務レコードの添付は全体から見るとごく一部です。
フィールドが変更されるたびに記録されるのがsys_audit（監査ログ）です。実測で56,746件あり、217種類ものテーブルにまたがっていました。上位はsys_coalesce_strategy_deferredやsys_update_xmlといったプラットフォーム内部の同期・アプリ管理系テーブルです。incidentのような業務テーブルは上位には出てきません。
Comments・Work notesの実体であるsys_journal_fieldは1,399件でした。element別に見ると、内訳はcomments 104件・work_notes 36件に対し、approval_history が1,259件と大半を占めます。承認のたびに残るコメントが、ジャーナル型フィールドの主な使い道になっていました。
Activity欄に表示される履歴は、sys_audit・sys_journal_fieldをそのまま出しているわけではありません。sys_history_set（7件）・sys_history_line（67件）という別の集約キャッシュ層を経由して表示されます。件数がひとケタ・二桁と極端に少ないのは、レコードのActivityを実際に開いたときだけ生成される仕組みだからです。この2つは扱いが分かれていて、集約本体のsys_history_setは30日（更新日基準）で自動的に消えますが、配下の明細行にあたるsys_history_lineには規則が無く、残り続けます。
このグループの詳しい構造は6本の子記事にまとめています。添付・監査・履歴・採番のどれか1つを詳しく知りたいときに読んでください。
2. マスタ：会社・拠点・通貨はどこにある
マスタは脇役です。レコードそのものではなく、レコードから参照される側のデータもあります。組織を表すcore_company（会社）は177件、cmn_department（部署）は7件、business_unit（ビジネスユニット）は6件でした。会社と部署の間に立つ中間層として、ビジネスユニットが少数だけ登録されています。
拠点を表すcmn_locationは427件と、組織系のテーブルの中では最も件数が多いマスタでした。ユーザーやCI（構成アイテム）はこの拠点に紐づきます。
金額を扱うフィールドは、実は本体テーブルの列に直接値が入っているわけではありません。fx_currency（通貨マスタ）が138件、金額フィールドの実値を持つfx_currency_instanceが8,232件という規模で、1つの金額フィールドごとに参照レコードが作られる作りでした。
マスタ系は4本の子記事に分かれています。組織構造や拠点、通貨換算の設計を詰めたいときに読んでください。
3. ログはどう溜まっていくか
ログは操作のたびに増えていきますが、放置されているわけではありません。溜まった分はTable Cleanerが後から自動的に削っています。増える量の実例として、システムログ（syslog）は677,667件でした。level別の内訳はInformation 426,466件・Warning 246,437件・Error 4,759件・Debug 5件です。
処理時間を記録するsyslog_transactionは48,101件、イベントキューのsyseventは12,220件です。どちらもsyslogほどの規模ではありませんが、日々の運用の中で自動的に積み上がっていく点は同じでした。処理が遅いトランザクションを特定したいときは、この後の「掃除される・されない」の章と合わせて、子記事の実践的な調査手順を読むのが早道です。
4. 掃除される仕組みとされない仕組み
核心はここです。今回のPDIには421件のルール（active 403・inactive 18）があり、対象テーブルを絞り込むとくっきりとした違いが見えました。
秒数を日数に直すと次のとおりです。syslogは90日、syslog_transactionは56日、sysventは7日、sys_history_setは30日（更新日基準）で自動的に削除の対象になります。ecc_queueにも30日のルールが用意されていましたが、こちらはactiveがfalseで無効化されたままでした。
sys_attachmentにも6件のルールがありますが、条件を見るとすべてtable_nameを個別に指定しています。対象はnode_log_download_info・ml_model_artifact・sys_sg_incremental_resultなど6テーブルです。いずれもプラットフォーム内部のテーブルで、業務テーブルは含まれません。incidentやcaseに付けた添付ファイルを自動で消すルールは、このOOTB環境には1つもありません。
一方でsys_audit・sys_journal_field・sys_history_lineなど5テーブルには、Table Cleanerのルールが1件もありませんでした。増え続ける前提で作られているか、あるいは別の仕組み（Archive・カスタムのScheduled Script）で管理する前提のどちらかです。掃除規則が無いテーブルを溜め続けたくない場合は、System Archivingを使うのが標準的な選択肢になります。
ロールバックの記録（sys_rollback_context）にも、対象テーブルを絞り込んで確認するとルールが1件見つかりました。条件はactive=false^state=expiredで、すでにExpiredになった記録だけが対象です。作成日から365日経過すると完全に削除されます。ただし「Finished recordingからExpiredへ状態が変わる期限」を決めるルールはTable Cleaner側には見当たりませんでした。
5. 消えたデータを戻す：アーカイブとロールバック
古いデータを退避する仕組みがSystem Archivingです。sys_archiveは31件のアーカイブ規則を持ち、19件がactiveでした。
規則名を見ると、Cert Audit ResultsやCMDB Data Management Tasksなど、分析系・ログ系のテーブルが対象に選ばれています。「増え続けるが個々の価値が低いデータ」を条件で退避する仕組みで、実行結果はsys_archive_logに759件残っていました。アーカイブされたレコードは、元テーブル名の前にar_を付けたテーブル（例: ar_cert_audit_result）に移動します。退避と削除は別工程です。多くの規則には、退避したあとさらに「完全削除」まで設定されています。実測ではactiveな19件のうち16件にdestroy_ruleが紐づいていて、完全削除までの期間は規則ごとに60日〜7年とばらつきがありました。残り3件はdestroy_ruleが未設定で、アーカイブ後もそのままar_テーブルに残り続けます。
一括でエクスポートしたいときに使うExport Setは、OOTBでは0件から始まります。必要になった都度、Export Definitionを作って使うテーブルです。
変更やスクリプト実行を丸ごと戻したいときに使うのがsys_rollback_contextです。422件のうち、実際に使える状態を示すFinished recordingは21件、すでに戻せなくなったExpiredは400件でした。
type別ではapp_install（アプリのインストール）159件とdelete（削除操作）133件が大半を占めます。残りはtest_execution（ATFのテスト実行）77件・scripts_bg（バックグラウンドスクリプト）52件・upgrade 1件でした。Expiredのまま放置されるわけでもなく、作成から365日経過したExpired記録はTable Cleanerが完全に削除します。
6. 環境をまたぐと何が残るか：クローンとアップグレード
全部はコピーされません。サブ本番へのクローンでは、保持する定義（clone_data_preserver）が208件、除外する定義（clone_data_exclude）が242件登録されていました。
クローン完了後に走る後始末スクリプト（clone_cleanup_script）は22件、クローンプロファイル自体は1件（clone_profile）です。プロファイルに実際に紐づいている保持・除外・後始末の数（185・218・17）は、定義の総数（208・242・22）とは一致しません。定義があっても、そのプロファイルで使われるとは限らない作りでした。
アップグレードをまたぐ場合は、sys_upgrade_historyに94件の履歴が残ります。設定が消えたかどうかを追う起点になるテーブルです。Instance Scanのscan_findingは1,039件で、クローンやアップグレードの前後に設定の「よくない状態」を機械的に洗い出す仕組みが別に用意されています。
実機で気づいたこと
sys_journal_fieldの内訳を見て、想定と違っていたのがapproval_historyの多さです。Comments・Work notesの追記だと思い込んでいましたが、実測では違いました。1,399件中1,259件がapproval_historyで、Comments・Work notesを合わせても140件でした。承認プロセスが動くたびにジャーナル型フィールドへ記録が残る作りだと分かると、ジャーナル系のテーブルが重いときにまず疑う先が変わります。
sys_attachmentのTable Cleanerルールを1件ずつ開いたときも意外でした。6件あるルールはすべて特定のtable_nameを条件に指定しており、対象はどれもプラットフォーム内部のテーブルです。業務レコードに付けた添付ファイルを自動で消す仕組みは、このOOTB環境には最初から用意されていません。添付ファイルの容量が気になる現場では、Table Cleanerに頼らず、自分でArchiveやカスタムのクリーンアップを組む前提だと理解しておいたほうがよさそうです。
sys_rollback_contextを最初に見たときは、Table Cleanerのルールが無いテーブルだと思い込んでいました。違ったのはここです。対象テーブルを絞り込んで確認し直すと、実際にはactive=false^state=expiredという条件のルールが1件ありました。もう戻せなくなった記録だけを狙って、作成から365日で完全に消す仕組みです。裏を返すと、まだExpiredになっていないFinished recordingはこのルールの対象外で、いつExpiredに切り替わるかを決める設定はTable Cleanerには見当たりません。「戻せなくなった後もしばらくは記録が残る」という状態が、テーブルを分けて確認して初めて見えてきました。
clone関連のテーブル名を調べていたときは、命名規則でつまずきました。System Cloneの関連テーブルにはsys_接頭辞が付きません。clone_data_preserverやclone_profileが正しいテーブル名で、sys_clone_data_preserverのような名前で問い合わせると存在しないテーブルとして扱われます。似た名前のテーブルを横断で調べるときは、命名規則を先に1件確認しておくと手戻りが減ります。
どこで詰まったらどれを読むか
18本の子記事は、レコードに付いてくるもの・マスタ・溜まるもの・消す退避する・環境をまたぐの5グループに束ねると探しやすくなります。
レコードに付いてくるもの（添付・履歴・採番を詳しく知りたいとき）は次の6本です。
添付ファイルの内部構造を知りたい → ServiceNowの添付ファイルはDBのどこに保存される？ sys_attachmentの内部構造
添付の実体がどう分割保存されるか知りたい → 添付の実体（sys_attachment_doc）はbase64で分割保存
誰が何を変えたかを追いたい → ServiceNowの変更履歴はどこに残る？ sys_auditと監査対象フィールドを実機で確認
Activity欄の表示の仕組みを知りたい → 履歴セット（sys_history_set）はActivity表示のキャッシュ
Comments/Work notesの実体を知りたい → Comments/Work notes（sys_journal_field）は1追記1行
採番ルールやprefixの決まり方を知りたい → レコード採番（sys_number）：INC番号の決まり方
マスタ（組織・拠点・通貨の設計を詰めたいとき）は次の4本です。
金額フィールドの裏側を知りたい → 金額は本体の列に入らない（fx_currency_instance）
会社・部署・原価センターの関係を知りたい → 組織テーブル：会社・部署・原価の3枚（core_company）
ビジネスユニットの位置づけを知りたい → ビジネスユニット（business_unit）は会社と部署の間
拠点マスタの住所・階層構造を知りたい → 拠点マスタ（cmn_location）の住所と階層
溜まるもの（ログが重い・遅いとき）は次の2本です。
syslogのlevel別の読み方や溜まり方を知りたい → システムログ（syslog）の読み方と溜まり方
処理が遅いincidentを特定したい → 遅い処理を特定する手順（syslog_transaction）（有料）。実際に使うクエリと読み方が手に入ります
消す・退避する（消えたデータを戻したい・整理したいとき）は次の3本です。
古いデータを退避する仕組みを知りたい → System Archiving（sys_archive）：古いデータを退避する仕組み
一括エクスポートの仕組みを知りたい → System Export Sets は標準で0件（sys_export_set）
変更やスクリプト実行を丸ごと戻したい → Rollback & Recovery（sys_rollback_context）：変更を丸ごと戻す
環境をまたぐ（クローン・アップグレードの前後に確認したいとき）は次の3本です。
クローンで何が残り何が消えるか知りたい → System Clone：クローンで何が残り、何が消えるか
アップグレード後に設定が消えていないか確認したい → アップグレードで設定が消えない運用レシピ：Upgrade Historyの読み方（有料）。確認手順と使うクエリが手に入ります
設定の危険信号を機械的に洗い出したい → Instance Scan：設定の「よくない状態」を機械に探させる（有料）。チェックの実行方法と指摘の読み方が手に入ります
つまずきやすい点
sys_auto_flushのage列は秒単位です。日数に直すには86400で割る一手間がいります
sys_attachmentのTable Cleanerルールは6件ありますが、対象はすべてプラットフォーム内部テーブル向けです。業務レコードの添付ファイルは対象に含まれません
sys_rollback_contextはstateがExpiredになっても、作成から365日はまだ一覧に残ります。件数だけを見て「戻せる記録の数」と勘違いしないよう、state列を必ず確認します
sys_archiveのdestroy_ruleは規則ごとに個別設定です。「アーカイブした＝いずれ消える」とは限らず、destroy_ruleが無い規則はアーカイブ後もar_テーブルに残り続けます
sys_journal_fieldの中心はapproval_historyで、Comments・Work notesは少数派です。ジャーナル系テーブルが重いときは承認プロセスの動きも疑います
System Clone関連のテーブルにはsys_接頭辞が付きません。clone_data_preserverのような名前が正しいテーブル名です
よくある質問
Q1. Incidentに付けた添付ファイルは放っておくと自動で消えますか
消えません。sys_attachmentのTable Cleanerルールは6件ありますが、いずれもプラットフォーム内部のテーブルが条件です。incidentのような業務テーブルの添付は対象外です。容量を抑えたい場合は、System Archivingやカスタムのクリーンアップを別途用意する必要があります。詳しくはServiceNowの添付ファイルはDBのどこに保存される？で扱っています。
Q2. syslogが重くなってきました。何日分残る設定ですか
実測では90日です。syslog_transaction（処理時間ログ）は56日、sysevent（イベントキュー）は7日で、いずれもTable Cleanerで自動的に削除されます。level別の内訳やmessageの読み方はシステムログ（syslog）の読み方と溜まり方にまとめました。
Q3. 間違って更新・削除したレコードは戻せますか
戻せる場合があります。sys_rollback_contextに記録が残っていて、stateがFinished recordingであれば戻せます。ただしExpiredになると戻せません。今回のPDIでは大半の記録がすでにExpiredでした。さらにExpiredのまま作成から365日経つと、記録そのものも自動的に削除されます。気づいたらできるだけ早く確認するのが安全です。仕組みの詳細はRollback & Recovery（sys_rollback_context）：変更を丸ごと戻すで扱っています。
Q4. クローンすると添付ファイルや監査ログはコピーされますか
クローンプロファイルの設定次第です。今回のPDIのプロファイルではExclude Audit And Log DataとExclude Attachment Dataがどちらもオンでした。監査ログと添付ファイルは、クローン時に除外される設定です。保持・除外の定義は合計450件（preserver 208・exclude 242）にのぼります。詳しくはSystem Clone：クローンで何が残り、何が消えるかで扱っています。
Q5. アップグレードで自分が作った設定は消えますか
消えません。sys_upgrade_historyに履歴が残り、何が上書き・スキップされたかを追えます。アップグレード後に確認すべき具体的なクエリはアップグレードで設定が消えない運用レシピ：Upgrade Historyの読み方にまとめました。
まとめ
地図は5段階です。1件のレコードの周りでは、生まれた瞬間の採番から始まり、添付ファイル・監査ログ・Comments/Work notesが付随データとして増えていきます。操作のたびにシステムログも溜まりますが、Table Cleanerで自動的に消えるのはその一部だけです。syslogは90日・syslog_transactionは56日・sysventは7日・sys_history_set（本体）は30日という保持期間でした。sys_rollback_contextはExpiredになった記録だけを対象に365日です。sys_audit・sys_journal_field・sys_attachment・sys_attachment_doc・sys_emailには、自動クリーンアップの規則がありませんでした。
消したデータはアーカイブで退避でき、変更やスクリプト実行はロールバックで戻せます。ただし戻せる状態には期限があり、Expiredになった記録も作成から365日で自動的に消える点に注意が必要です。アーカイブ後も、規則にdestroy_ruleが設定されていれば60日〜7年でさらに完全削除されます。クローンやアップグレードで環境をまたぐときは、保持・除外の設定次第で何が残るかが変わります。
18本の子記事は、この地図のどこで詰まったかによって選べます。今回の実測値は環境ごとに変わりますが、生まれる・付随データが増える・ログが溜まる・掃除される・環境をまたぐという5段階の構造そのものは共通です。
用語
sys_auto_flush（Table Cleaner） … テーブルごとに保持期間（age）を設定し、古いレコードを自動的に削除する仕組み
sys_attachment / sys_attachment_doc … 添付ファイルのメタ情報と、base64で分割された実体データ
sys_audit / sys_journal_field … フィールド単位の変更ログと、Comments/Work notesなどジャーナル型フィールドの追記
sys_history_set / sys_history_line … Activity欄の表示用に変更履歴を集約するキャッシュ層
sys_archive / sys_archive_log … 古いデータを退避するアーカイブ規則と、その実行記録。退避先は元テーブル名にar_を付けたテーブル。destroy_ruleが紐づいていれば、退避後さらに一定期間で完全削除される
sys_rollback_context … 変更・削除・スクリプト実行を丸ごと戻すための記録。期限を過ぎるとExpiredになり、Expiredのまま作成から365日経つとTable Cleanerが完全に削除する
clone_data_preserver / clone_data_exclude … クローン時にコピー先で保持する・除外するデータの定義
実機で確認したURL
/sys_number_list.do?sysparm_query=ORDERBYcategory … 採番ルールの一覧
/sys_auto_flush_list.do?sysparm_query=tablenameINsyslog,syslog_transaction,sysevent,sys_history_set,sys_attachment,ecc_queue^ORDERBYtablename … Table Cleanerルールの絞り込み一覧
/syslog_list.do?sysparm_query=GROUPBYlevel … システムログのlevel別件数
/sys_attachment_list.do?sysparm_query=GROUPBYtable_name … 添付ファイルのtable_name別件数
/sys_audit_list.do?sysparm_query=GROUPBYtablename … 監査ログのtablename別件数
/sys_journal_field_list.do?sysparm_query=GROUPBYelement … ジャーナルフィールドのelement別件数
/sys_archive_list.do … アーカイブ規則の一覧
/sys_archive_destroy_list.do?sysparm_query=active=true … アーカイブ後の完全削除ルール一覧
/sys_auto_flush_list.do?sysparm_query=tablename=sys_rollback_context … ロールバック記録のTable Cleanerルール
/sys_rollback_context_list.do?sysparm_query=GROUPBYstate … ロールバック記録のstate別件数
/clone_data_preserver_list.do … クローン時の保持定義一覧
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認したものです。一覧画面の表示件数とREST集計を突き合わせて数えており、推定やサンプリングではありません。総件数（count total）と特定条件に紐づく件数（GROUPBY内訳）は本文中で区別して記載しています。子記事とは検証日が異なるため件数がわずかに前後しますが、本記事は今回の実測値を採用しています。
未読の範囲もあります。sys_auto_flushにはclean_audit・clean_peripheralという「監査ログやジャーナルも連動して消す」オプションがあります。今回確認した範囲では、いずれのルールでもfalseでした。sys_rollback_contextにはExpiredになった記録を365日で削除するTable Cleanerルールがありました。ただしFinished recordingからExpiredへ状態が変わる期限自体を決める設定は見当たらず、プラットフォーム内部のロジックと見られます。断定はしていません。sys_archiveのdestroy_ruleは設定の有無と期間までは確認しましたが、実際に完全削除が発火する挙動そのものや、Instance Scanの各チェック項目の中身は検証範囲外です。本番環境やカスタマイズ済みの環境では、Table Cleanerの設定やクローンプロファイルの内容が変わります。数字は環境ごとに違っても、生まれる・付随データが増える・ログが溜まる・掃除される・環境をまたぐという5段階の構造そのものは共通です。
