ServiceNow Zurichで迷わない データ管理と監査の考え方

はじめに

ServiceNowを触り始めると、すぐに現実の壁に当たります。
「データが増えて遅くなる」「監査のために履歴は必要」「でも全部残すと運用が破綻する」――このあたりは、管理者として避けて通れません。

Zurichでは、データの増え方を把握して手を打つためのData Managementが整理され、見える化・運用導線が強化されています。
一方で、監査（Auditing）は昔からある機能ですが、sys_audit と History Sets の違いや、監査対象を増やしすぎた時の副作用は、初学者がつまずきやすいポイントです。

この記事では「暗記」ではなく、なぜその設計になるのかを軸に、Zurichの“データ管理と監査”を一本の線でつなげて整理します。CSA学習の前提知識としても、実務の判断軸としても使えるように具体例を交えて説明します。

---

Zurichで強化された データ管理の入り口

まず把握するべきは データは勝手に増えるという前提

ServiceNowは運用が回り始めるほど、チケット、添付、ログ、履歴、連携データなどが積み上がります。増えること自体は悪ではありません。問題は、増え方を把握しないまま放置すると、検索・レポート・バッチが重くなり、結果的に“現場が使いづらい”になります。

ZurichのData Managementは、この「把握」の部分を強化しています。Data Management Consoleで、インスタンスのストレージ使用状況や、どのテーブルが容量を食っているかを把握し、対策へつなげる導線が用意されています。

Data Management Consoleで見るべき観点

Data Management Consoleは「管理者が迷子にならない」ための地図です。見るべきはだいたいこの3つです。

• どのテーブルが重いか
  テーブル別にサイズやレコード数を確認し、影響の大きいところから手を打つ。
• 関連テーブルも含めた影響
  “単体テーブルだけ”を見て判断するとズレます。関連テーブル込みで確認できるのがポイントです。
• そのテーブルにどんなデータ管理ルールがぶら下がっているか
  ルールの要約・詳細をテーブル単位で追えるので、「結局このデータはいつ消えるの？」が説明しやすくなります。

この段階では、細かい設定手順よりも「データの増加を観測 → 方針決め → ルール化」という流れを掴むのが大切です。

---

監査の基本は sys_audit と Historyの役割分担で決まる

監査で何が記録されるのか

監査（Auditing）は、テーブルで監査を有効化すると、レコードの変更（作成・更新・削除）を追跡します。監査ログには、どのレコードのどのフィールドが、いつ、誰によって、どう変わったかといった情報が含まれます。

ただし、ここで大事なのは「監査ログは無限に増える」という点です。だからこそ、後述のデータ管理や保管戦略とセットで考える必要があります。

sys_audit と History Sets は同じデータでも目的が違う

初学者が混乱しがちなのがここです。

• Audit（sys_audit）
  監査の“元データ”。監査対象テーブルの変更履歴が蓄積されます。
• History Set（sys_history_set）/ History（sys_history_line）
  ユーザーが履歴を見た時に使いやすい形にした“ビュー用の仕組み”。必要になったタイミングで sys_audit から生成され、保存期間も限定されます。

ポイントは、ユーザーが画面で見る「履歴」は、常に sys_audit を直接読んでいるわけではないということです。
履歴を表示するための History 系テーブルは、一定期間で削除・ローテーションされますが、必要になれば sys_audit から再生成できる、という考え方です。

CSAの学習では、「監査＝履歴が見える機能」くらいの理解で止まると、運用設計の問題（重い・増える・見えない）で詰まります。sys_audit は長期の監査証跡、History は閲覧のための仕組みと分けて捉えると整理しやすいです。

監査対象は 全部ではなく 意図して絞る

ServiceNow公式でも、トラフィックの多いテーブルを丸ごと監査すると性能に影響し得るため、必要なフィールドに絞ることが推奨されます。
現場感としても、監査は「安心」のために入れるのに、入れすぎると「遅い」という不安を生みます。

よくある具体例で考えます。

例：Incidentで監査したいもの

• priority、state、assigned_to：説明責任が必要になりやすい
• description：頻繁に編集されるなら監査ログが膨れやすい
• work_notes / comments（ジャーナル系）：運用上は必要だが、監査の目的と混ぜると設計が崩れやすい（監査の“変更履歴”と、作業記録の“時系列”は別の意味を持つ）

監査を「全部の真実を残す装置」にするより、後から問われた時に説明できる最低限を残すくらいから始めるのが安全です。

---

データライフサイクル設計は 監査のために残す と 運用のために軽くする の両立

データ管理は削除より先に アーカイブという選択肢を持つ

「古いデータを消したい、でも監査や参照のために残したい」
この矛盾を解くのがアーカイブです。

ServiceNowのデータアーカイブは、古いデータをアーカイブテーブルへ移して、日常の検索対象から外し、性能と保管の両立を狙います。
公式の流れもシンプルで、まずアーカイブルールを作り、必要なら一定期間後に破棄する（destroy）ルールを組み合わせます。

アーカイブすると何が変わるのか

アーカイブは「同じデータを別の場所に置く」だけではありません。挙動を押さえておくと事故が減ります。

• アーカイブ有効化時に、対象テーブルに対応した ar_ プレフィックスのアーカイブテーブルが作られる
• 参照フィールドは、アーカイブ後に表示値として文字列化される（参照先の sys_id を保持し続ける設計とは違う）
• ACLは基本的に元テーブルのものが使われるが、アーカイブテーブル用ACLを有効にする設定もある

つまり、「後で参照先を辿りたい」「参照整合性が必要」という要件が強い場合は、アーカイブを適用する範囲やタイミングを慎重に決める必要があります。

Data Management Policyで ルールを持たせて運用する

アーカイブを“思いつき作業”にすると、属人化します。Data Managementでは、**ポリシー（方針）→ ルール（実装）**に落とせるのが良いところです。

ここでの考え方はこうです。

• 「このテーブルのデータは、いつまで“日常運用”で使うか」
• 「いつから“監査・参照用”になるか」
• 「“監査・参照用”はいつまで必要か」

たとえばIncidentなら、現場での検索は直近数か月が中心でも、監査要件で年単位の保管が必要な場合があります。
このギャップを、日常運用＝現役テーブル、保管＝アーカイブ、最終的に削除＝destroyのように分解して考えると、説明もしやすく、運用も回ります。

---

監査を信頼できる状態にするための 権限と運用の設計

監査があるだけでは不十分で 誰が見られるかがセット

監査は“証跡”なので、閲覧権限がガバガバだと逆にリスクになります。
この話はACLの領域にもつながりますが、まずは原則を押さえます。

• 監査ログや履歴は「説明責任のための情報」
• だから「必要な人だけが見られる」ことが重要
• さらに「監査対象のテーブル／フィールド」を絞る設計が、閲覧権限の設計を楽にする

アーカイブについても同様で、アーカイブテーブルのアクセスは元テーブルのACLが基本になる一方、アーカイブテーブル専用ACLを使う設定もあります。
「アーカイブは別テーブルだから安全」とは限らないので、運用設計ではここを見落としがちです。

監査が増えすぎると起こること

監査を手厚くすると安心感は増えますが、無限に増えるログは運用コストになります。公式でも、大量トラフィックのテーブルで監査を広げると性能に影響し得る点が明記されています。

なので、現実的な落としどころはこうです。

• 監査は「重要フィールド中心」
• 大量更新が起きる領域は「必要ならフィールド単位」
• “監査が必要な期間”と“運用上検索したい期間”を分け、古いものはアーカイブへ

このセットで考えると、データ管理と監査が一体になります。

監査と製品の Audit Management は混同しない

Zurichには、IRM領域のAudit Managementのリリースノートもありますが、これは監査業務（監査計画・証跡収集など）を支援する製品側の話です。
CSAで扱う監査（Auditing）とは層が違うので、学習時はまずプラットフォームの監査の仕組み（sys_audit / History）を固め、その後にIRMの監査管理へ広げるのが理解しやすいです。

---

CSA学習につながる 仕組み理解のためのチェックリスト

ここまでの内容を、学習の手触りに落とします。暗記カードではなく「説明できるか」で確認してみてください。

データ管理で説明できるようにしたいこと

• Data Management Consoleで「容量を食っているテーブル」を説明できる
• あるテーブルについて「どんなルールがあるか」を辿れる
• “削除”以外に“アーカイブ→destroy”という段階設計が語れる

監査で説明できるようにしたいこと

• sys_audit と History Sets の役割の違いを説明できる
• 監査対象はテーブル単位・フィールド単位で設計でき、絞る理由（性能・運用）を説明できる
• 「履歴が見える＝全部永久に残っている」とは限らないことを説明できる

ハンズオンのおすすめ練習

• Incidentで監査を有効にし、priority/state/assigned_toだけを監査する設計を考える
• 「descriptionまで監査する場合の副作用」を言語化する
• アーカイブ対象にしたいテーブルを1つ選び、
  「現役期間」「保管期間」「破棄のタイミング」を文章で決める（ここが設計力）

この練習をやると、問題文で“要件があいまいな監査・データ保持”が出てきても、選択肢の意図を読みやすくなります。結果として、理解が浅いと混乱しやすい領域を、筋道立てて捌けるようになります。

体系的に学べる教材の一例

独学だと、監査（Auditing）とデータ管理（Data Management / アーカイブ）を別々に覚えてしまいがちです。
もし「管理者目線でつなげて理解したい」なら、UdemyのServiceNow管理者向け講座やCSA対策講座で、データの扱い・権限・運用設計を一連で扱うものを選ぶと学習効率が上がります。特にハンズオン中心の講座は、設定の意味が腹落ちしやすいです。

---

まとめ

Zurichの「データ管理と監査」を理解するコツは、機能を別々に覚えないことです。

• データは増える前提で、Data Management Consoleで観測し、方針をルールへ落とす
• 監査は sys_audit と History の役割分担で整理し、目的に合わせて監査範囲を絞る
• “残す”と“軽くする”の両立は、アーカイブとdestroyを使ったライフサイクル設計で作る

この3点を一本の線で説明できるようになると、CSA学習でも実務でも「なんとなく設定した」が減り、判断が安定します。
まずは、身近なテーブル（Incidentなど）で「監査する項目」「現役期間」「保管期間」を言葉にしてみる。そこから一気に理解が進みます。