ServiceNowのecc_queueはなぜ勝手に消える？ Table RotationとSystem Archivingを実機で使い分ける
ecc_queueやsys_flow_logの古いレコードが、削除した覚えがないのに気づくと減っています。この現象を見て「System Archivingが動いているのだろうか」と考えた担当者は多いはずです。結論は別物でした。System Archivingは条件に合うレコードを退避して残しますが、この現象の正体はTable Rotationという別の仕組みで、世代ごとテーブルを使い回して古いデータを消します。sys_table_rotation（40件）とsys_table_rotation_schedule（282件）をPDIで読み、実際にどのテーブルがどちらで管理されているかを確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：世代ごと消えるRotationと、条件で残すArchivingの境界
Table Rotationは物理テーブルを複数の世代（例: ecc_queue0000〜ecc_queue0006）に分け、周期ごとに書き込み先を切り替えます。一番古い世代は中身を空にして再利用されるため、そこにあったデータは戻せません
System Archivingは条件に合うレコードを1件ずつar_テーブルへ退避します。退避先にはそのまま残り、destroy_ruleが設定されていない限り消えません
実機のsys_table_rotationには40件のグループがあり、うち39件が周期で世代を回すRotation型、残り1件（sys_activity）だけがハッシュで固定分割するShard型でした
まず両者の違いを図にしました。読み方は単純で、Table Rotationの終着点は赤（消える）、System Archivingの終着点は緑（残る）になります。
実機でも同じ切り分けが確認できます。sys_table_rotationの一覧をType列でグループ化すると、Rotation型が39件、Shard型が1件という内訳がそのまま画面に出ます。
sys_table_rotationとは何か
定義はシンプルです。sys_table_rotationは、どのテーブルをどんな周期でいくつの世代に分けるかを定義するグループテーブルにあたります。主なフィールドはname（対象テーブル名）とtype（Rotation/Shard）、duration（周期）です。ほかにrotations（世代数）と、Shard型だけが使うshards・shard_by（分割数と分割キー）も持ちます。実測した40件のうち、周期は1時間から60日まで幅がありました。中でも1日ごとが17件、7日ごとが13件で、この2種類だけで39件中30件を占めています。世代数は7が19件、8が10件で、この2つが過半数を超えます。
対象テーブルを見ると性格がはっきりしています。ecc_queue・ecc_event・sys_outbound_http_logは外部連携やHTTP送信のログです。syslog・sysevent・syslog_transactionはプラットフォームの内部ログにあたります。sys_flow_logはFlow Designerの実行記録で、sys_replication_queueはレプリケーション用キューです。どれも動作するたびに機械的に増え、1件ずつを長期保存する価値が薄いテーブルという共通点を持ちます。
ecc_queueの世代はどう回っているか
一覧だけでは掴みにくいです。ecc_queueの中身を1件開いてみました。Typeは「Rotation」、Durationは1日、Rotationsは7です。関連リストの「Table Rotation Schedule」には8件のレコードが並びます。
内訳はecc_queue0000からecc_queue0006までの7つの世代テーブルと、世代番号の付かない「ecc_queue」という基準レコードの合計8件です。世代テーブルにはValid from・Valid toという有効期間が1日ずつずれて設定されていて、直近1週間分の枠があらかじめ用意されています。この並びを見ると、Table Rotationが「毎日新しい世代を作る」のではなく「あらかじめ用意した7つの箱を順番に使い回す」仕組みだと分かります。
実際の生成テーブルを日付ごとに並べると、7つの箱がリレー形式で書き込み先を引き継いでいく様子が分かります。Offline=trueになっている1件だけが輪から外れていて、次の周期で中身を空にしてから書き込み先に戻る番を待っています。
Offlineになった世代には何が起きるか
Offline=trueの世代（今回はecc_queue0006）は、Valid toの期限が過ぎたあと待機する状態です。次に書き込み先として選ばれるまでの間に、中身が空にされます。次の周期が来ると、この世代は新しい書き込み先として再利用されるという流れです。世代を再利用する操作そのものが、そこに残っていた古いレコードを消す操作を兼ねています。つまり選べません。Table Cleanerは条件に合うレコードだけを選んで消しますが、Table Rotationは世代テーブルを丸ごと入れ替えます。この違いがSystem Archivingとの最大の差になります。
世代番号なしの行（基準レコード）は何のためにあるか
8件のうち1件だけ、table_nameが世代番号を持たない「ecc_queue」そのものでした。Valid fromは1970-01-01、Valid toは2026-02-02という古い日付が入っています。sys_table_rotation_schedule全体を調べると、Valid fromが1970-01-01になっている行は全282件中ちょうど4件しかありませんでした。その4件は、ecc_queue・ecc_event・sys_flow_log・sys_outbound_http_logの4グループにそれぞれ1件ずつ対応していました。この4テーブルはTable Rotationが有効化される前から実データを持っていたテーブルとみられます。その「導入前のデータ」を指す基準レコードが、今も残っていると考えられます。ecc_queueのフォームには「Clean base rotation」という項目もあり、2026-08-17という先の日付が入っていました。名前から推測すると基準レコードの掃除予定日にあたりそうですが、正確な処理内容までは今回のドキュメント確認では追い切れません。検証範囲外として扱います。
sys_activityだけ仕組みが違う：Shard型は時間で回らない
Type=Shardのグループはsys_activityだけで、shard_byにdocument_id、shardsに16という値が入っていました。1件開いて中身を見ると、名前の付け方こそecc_queueの世代テーブルと似ていますが、性質はまったく違います。似て非なるものです。
sys_activity0000から0015までの16テーブルすべてで、Valid from・Valid toが1969年末から1970年初頭の日付に固定されています。ecc_queueの世代は「今週から来週」という実時間の枠で切り替わります。一方でsys_activityの16分割は、最初から固定されたまま動いていません。document_idという参照先のsys_idをハッシュ化し、16個のどのテーブルに書き込むかを振り分ける仕組みです。担当は固定です。時間が経っても書き込み先は変わりません。Rotationは「時間で交代する」方式であり、Shardは「値で振り分ける」方式にあたります。両方とも同じsys_table_rotationというテーブルで定義されていますが、動く原理は別物だと分かりました。
Table Rotationで管理されているテーブル一覧
実測した40グループのうち、代表的な10件をTable Cleaner（sys_auto_flush）との重複状況もあわせて一覧にしました。
発見が1つあります。sys_history_lineには、Table Cleanerのルールが存在しません。以前に別記事で確認した際、sys_history_lineは自動削除の仕組みを持たないテーブルとして扱っていました。実は今回の調査で、sys_history_lineは7日ごとに4世代を回すTable Rotationの対象になっていることが分かりました。Table Cleanerには規則が無くても、Table Rotationが別の方法で古いレコードを整理していたことになります。
Table Cleanerと重なっているテーブルもある
一覧の中には、Table CleanerとTable Rotationが両方設定されているテーブルもありました。内訳は3つです。組み合わせを見ると、パターンが分かれます。
syslogとsyslog_transactionは両方が有効なまま動いている
syslogはTable Cleanerの保持期間が90日（有効）、Table Rotationは7日ごと8世代で合計56日分の枠を持ちます。syslog_transactionはTable Cleanerが56日（有効）、Table Rotationも7日ごと8世代で合計56日と、こちらは数字がぴったり一致していました。偶然でしょうか。両方が有効なまま動いている以上、どちらが先にレコードを消しているかは設定値だけでは決められません。ここは未検証です。
ecc_queueとecc_eventはTable Cleanerが無効化されている
ecc_queueにはTable Cleanerのルール（30日・無効）がありました。ecc_eventにも別のルール（7日・無効）が存在しましたが、どちらもactiveはfalseでした。一方でTable Rotationは、両方とも1日ごと7世代で稼働しています。無効化されたTable Cleanerのルールが残っていることから、この2テーブルはTable Rotationへ管理方法を切り替えたとみられます。消さずに、止めてある。ルールを削除せず無効化だけして残すのは、後から経緯をたどれるようにするためだと読み取れました。
sys_flow_log・sys_outbound_http_log・sys_history_lineの3テーブルにはTable Cleanerのルールそのものがありませんでした。最初からTable Rotationだけで管理する前提で設計されていたとみられます。
System Archivingとの違いを並べる
ここまでの実測を、System Archivingとの対応表にまとめました。System Archiving自体の実測件数（有効な規則19件、対象テーブルの例など）は別記事で扱っているので、ここでは仕組みの違いに絞ります。
対象テーブルの傾向も対照的でした。狙いが違います。System Archivingの有効な規則19件を実機で開くと、対象はkb_use（ナレッジ閲覧記録）やcert_audit_result（監査結果）などが並びます。ml_predictor_results（予測結果）のように、業務の副産物として溜まる分析寄りのテーブルが目立っていました。
今回Table Rotationの対象として確認した40テーブルと、System Archivingの対象19テーブルを見比べると、名前が重複するテーブルは1つもありませんでした。Table Rotationはecc_queueやsyslogのような内部ログ・キュー系が中心です。System Archivingはkb_useやcert_audit_resultのような業務寄りの記録が中心になります。実機データからも、この住み分けが読み取れます。
自分が作ったテーブルはどちらを使うべきか
ここからは実測に基づく設計提案であり、断定ではなく判断材料として書きます。迷ったときは実物を見るのが確実です。
ログやキューのように「新しいレコードが増えるたびに古いレコードの価値がほぼ無くなる」性質のテーブルは、Table Rotationとの相性がよいです。世代数×周期を決めれば保持期間を機械的に固定でき、レコードごとに条件を書く手間もかかりません。一方で、世代を再利用した瞬間にデータは戻せなくなるため、後から「あの日のログを見たい」という要望が出るテーブルには向きません。
分析結果や監査記録、閲覧履歴のように「古くなっても1件ずつ参照される可能性が残る」テーブルは、System Archivingの方が扱いやすいです。条件で選んだレコードをar_テーブルへ動かすので、必要なら復元できます。destroy_ruleを付けなければ退避したまま保持もできるので、保存義務がある記録にも対応しやすくなります。
自分で追加したカスタムテーブルにTable Rotationを設定する場合は、sys_table_rotationへの新規登録に加えて世代テーブル群の準備が必要になります。既存のOOTBの構成を書き換える操作ではないため、標準機能として提供されているUIから設定できるかどうかは、今回のPDIでは確認できていません。この設定手順自体は検証範囲外とします。
実機で気づいたこと
気づきは3つありました。
sys_table_rotation_scheduleを全体で確認したとき、意外だったのはValid fromが1970-01-01になっている行がちょうど4件しかなかったことです。40グループもあるので「導入前のデータを表す基準レコード」がもっと多くのテーブルに残っていると予想していました。実際にはecc_queue・ecc_event・sys_flow_log・sys_outbound_http_logの4件だけでした。逆に言えば、残り36グループはTable Rotationが有効になった時点から世代テーブルだけで運用が始まっています。過去データを引き継ぐ基準レコードを、そもそも持たないことになります。
もう1つ意外だったのは、ecc_queueのフォームにある関連リンクの名前です。「Synchronize Shards」という操作リンクが、Type=Rotationのグループにも表示されていました。てっきりShard型専用の操作だと思っていましたが、実機ではRotation型のecc_queueにも同じリンクが出ます。この画面ではShardという言葉が、Rotation・Shardの区別なく「世代テーブル群」全般を指す内部的な呼び方として使われているとみられます。
3つ目は、syslogとsyslog_transactionでTable CleanerとTable Rotationの数字が近い、あるいは一致していた点です。syslog_transactionはTable Cleanerが56日、Table Rotationの合計期間も56日で完全に一致していました。同じテーブルに2つの削除の仕組みが同時に設定されていること自体は珍しくありません。ただし片方が無効化されずに両方稼働したまま、数字だけが揃っている状態には理由が見えませんでした。意図して合わせたのか、結果的に一致しただけなのか、実機の設定値からは判断がつきませんでした。
よくある質問
Q1. Table RotationとSystem Archivingは同じテーブルに両方設定できますか
今回確認した40テーブルと19テーブルの間に重複はありませんでしたが、設定上どちらか一方しか使えないという制約は見当たりません。ただし両方を同じテーブルに設定した場合の挙動は、今回のPDIでは実例が無く未確認です。
Q2. Table Rotationで消えたデータは復元できますか
復元する画面や機能は、今回確認した範囲では見当たりませんでした。世代テーブルが再利用されると中身が空になるため、System Archivingのように後から取り戻す前提の設計ではないとみられます。重要なログを長期保存したい場合は、Table Rotationに任せきりにせず、別途エクスポートやSystem Archivingへの切り替えを検討したほうがよいです。
Q3. Table Cleanerが無効(false)なのにログが増え続けないのはなぜですか
ecc_queueやecc_eventのように、Table Cleanerのルールがactive=falseの場合もあります。それでもTable Rotationが有効に動いていれば、そちらが古いデータの整理を引き受けています。無効なTable Cleanerのルールだけを見て「掃除されていない」と判断するのは早計です。sys_table_rotationとsys_table_rotation_scheduleも合わせて確認するとよいです。
Q4. sys_history_lineが重いときはどこを見ればよいですか
sys_history_lineにはTable Cleanerのルールがありませんが、Table Rotationで7日ごと4世代、合計28日分の枠が用意されています。28日を超える古いActivity表示用の明細は、Table Rotationの世代交代によって自動的に整理される計算になります。件数が多くて重いと感じる場合は、直近28日分の書き込み量そのものが多い可能性を疑うほうが有効です。
まとめ
境界は単純でした。Table RotationとSystem Archivingは、同じ「古いデータの整理」という目的を持ちながら、中身は正反対に近い仕組みでした。Table Rotationは世代テーブルを周期で使い回し、古い世代のデータを丸ごと消します。System Archivingは条件に合うレコードを1件ずつar_テーブルへ退避し、destroy_ruleが無ければ残し続けます。
実機のsys_table_rotationには40グループがあり、Rotation型が39件、Shard型が1件でした。ecc_queueは1日ごと7世代、sys_flow_logは7日ごと4世代というように、周期と世代数はテーブルごとに個別設定されています。Table Cleanerと重なって設定されているテーブルもあれば、Table Rotationだけで管理されているテーブルもありました。sys_history_lineのように、Table Cleanerには規則が無くてもTable Rotationで管理されているケースがある点は、この記事で確認できた一番の収穫です。
自分のテーブルがどちらに向くかを判断するときは、古いレコードを丸ごと捨ててよいか、それとも1件ずつ参照される可能性が残るかで考えるとよいです。住み分けは明快です。ログ・キュー系はTable Rotation、業務記録・分析結果はSystem Archivingという傾向が、今回の実測データからも見えてきました。
用語
sys_table_rotation（Table Rotation Group） … 対象テーブルごとに周期（duration）・世代数（rotations）・種別（type: Rotation/Shard）を定義するグループ
sys_table_rotation_schedule（Table Rotation Schedule） … グループに紐づく個々の世代テーブル（物理テーブル名・有効期間・Offlineフラグ）を管理する明細
Rotation型 … 周期ごとに書き込み先の世代テーブルを切り替え、一番古い世代を再利用する方式
Shard型 … document_idなどの値をハッシュ化し、固定数のテーブルへ常時振り分ける方式（時間による切り替えなし）
Offline … その世代テーブルが現在の書き込み対象ではないことを示すフラグ。trueの世代は次の周期で中身を空にして再利用されます
sys_archive / ar_テーブル … System Archivingの規則本体と、退避先のテーブル。詳細は関連記事を参照
destroy_rule … System Archivingで退避後に完全削除するまでの期間を決める規則。未設定なら退避先に残り続けます
実機で確認したURL
/sys_table_rotation_list.do?sysparm_query=GROUPBYtype … Table Rotationのtype別内訳
/sys_table_rotation.do?sys_id=... … Table Rotationグループ1件の設定（duration・rotations・type）
/sys_table_rotation_schedule_list.do?sysparm_query=name.name=ecc_queue … 特定テーブルの世代一覧とOffline状態
/sys_dictionary_list.do?sysparm_query=name=sys_table_rotation^elementISNOTEMPTY … sys_table_rotationの項目定義
/sys_auto_flush_list.do?sysparm_query=tablename=ecc_queue … Table Cleanerルールとの重複確認
/sys_archive_list.do?sysparm_query=active=true … System Archivingの有効な規則一覧
関連記事
ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — この記事の親記事。Table Cleanerを中心にした「消える・消えないの境界」全体像はこちらで確認できます
System Archiving（sys_archive）：古いデータを退避する仕組み — 「残す」側の仕組みを詳しく扱います。退避先ar_テーブルやdestroy_ruleの実測はこちら
連携トラブルはまずここ：ECC Queue（ecc_queue） — この記事で世代交代を追ったecc_queue自体の構造・state・トラブル調査はこちら
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で確認しました。対象はsys_table_rotationとsys_table_rotation_schedule、それにsys_auto_flush・sys_archiveの4テーブルです。これらをREST APIと実画面で突き合わせて数えており、推定やサンプリングではありません。sys_table_rotationの全40件、sys_table_rotation_scheduleの全282件を対象に集計しました。Table Cleanerとの重複確認は、Table Rotation対象テーブルのうち10件について個別に照合しています。
未確認の範囲もあります。Table CleanerとTable Rotationが同じテーブルに両方有効な場合、実行の順序までは確認できていません。どちらが先にレコードへ影響するかという内部的な優先順位は、今回のREST・実画面の確認だけでは分かりませんでした。ecc_queueのフォームにあった「Clean base rotation」という項目の正確な処理内容も確認できていません。カスタムテーブルへTable Rotationを新規設定する具体的な手順、Shard型（document_idのハッシュ分割）の振り分けアルゴリズムの詳細も、いずれも検証範囲外とします。本番環境やカスタマイズ済みの環境では、対象テーブルや周期・世代数の設定が異なります。
