CMDBデータ認証（cert_audit）：あるべき状態から外れたCIに、タスクを配る
CMDB を整えたあと、次に来る問題は「整った状態を保てるか」です。サーバのメモリが足りない。UPS のバッテリーが持たない。誰かが気づいて直さないかぎり、台帳は現実からずれていきます。
ServiceNow には、この見張りを自動化する仕組みがあります。データ認証（Certification / Audit） です。あるべき状態を条件として定義しておき、定期的に全CIを照らし合わせ、外れたものには担当者宛のタスクを自動で作ります。
実機を数えると、監査10件・結果3,540件・タスク2,517件が入っていました。今回はこの実データを追いながら、仕組みを読み解きます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-27）。本番環境では設定が異なります。
5つのテーブルで「定義 → 実行 → 是正」を回す
登場するテーブルは5系統です。
条件（cert_cond） … 「RAMは2048MB以上」といった判定。実測23件
テンプレート（cert_template） … 条件をまとめた「あるべき状態」の束。実測9件
フィルタ（cert_filter） … どのCIを対象にするか。実測9件
監査（cert_audit） … いつ・どのテーブルを・どう扱うか。実測10件
結果（cert_audit_result）とタスク（cert_follow_on_task） … 実測3,540件と2,517件
定義が3つ（条件・テンプレート・フィルタ）、実行が1つ（監査）、出力が2つ（結果・タスク）。役割がきれいに分かれています。
監査10件は何を見張っているか
対象は CMDB のCIクラスです。サーバ / データベース / UPS / コンピュータ / ゾーン / ビジネスサービスの6種類が並びます。
実行タイミングがばらばらなのが目を引きます。UPS の監査は Daily、ビジネスサービスは Weekly。データベースとゾーンは Monthly で、残りは On Demand でした。
この差は、変化の速さに対応しています。UPS のバッテリーは日々劣化するので毎日見る。データベースの構成はそう頻繁に変わらないので月次で足りる。見る頻度を対象の変化速度に合わせるのが設計の勘どころです。
タスクを作るかどうかも監査ごとに分かれていました。10件中7件が「する」、3件が「しない」。
種類は5つ、使われているのは2つ
audit_type の選択肢を実測すると5つありました。
実際に使われているのは Desired State が9件、Scripted が1件 だけです。残る3種類（Data Certification / Architecture Compliance / Compliance）は0件でした。
Desired State は「設定があるべき状態から外れていないか」を条件で判定します。機械が自動で判断できるので、定期実行に向きます。
いっぽう Data Certification は「台帳の内容が現実と合っているか」を人が確認する種類です。「このサーバ、本当にまだ動いていますか」と担当者に聞く。機械には判断できないので、人の確認が要ります。
標準データが Desired State に寄っているのは、自動で回せるほうから始めるのが現実的だからだと読めます。
監査1件を開く
Server Minimum Statistics を開きます。
説明には「All servers need to match the current minimum baseline」とありました。すべてのサーバが最低基準を満たすべき、という取り決めです。
設定値のうち、運用に効くものを並べます。
table … cmdb_ci_server（対象のCIクラス）
template … Server Minimum Statistics - 2（あるべき状態の束）
create_tasks … true（外れたらタスクを作る）
task_description … 「Update this server to match the conditions listed in the…」
assignment_type … User Field
assign_to … managed_by
assign_to_empty … Create Unassigned Task
run_type … On Demand
health_window … 7 Days
threshold_count … 5
stability_count … 1
担当者はCIのフィールドから決まる
assign_to が managed_by になっているのが実務的です。CIの「管理者」フィールドを見て、その人にタスクを割り当てます。
固定の担当グループに全部投げると、受け取った側が「これは誰の担当か」を調べ直すことになります。CIに管理者が入っているなら、そこから配るほうが早い。
管理者が空のCIには assign_to_empty が効きます。実測は Create Unassigned Task、つまり担当者なしのタスクを作る設定でした。捨てずに残すので、後から誰かが拾えます。
外れたCIを見つけることと、直す人に届けることは別の仕事です。データ認証は後者まで面倒を見ます。
3つの数値が「揺れ」を吸収する
フォームには意味の読み取りにくい数値が3つ並んでいました。health_window が 7 Days、threshold_count が 5、stability_count が 1。
名前から読めるのは、いずれも「一度外れただけで騒がない」ための仕組みだということです。監視の値は一時的に振れます。ある瞬間だけメモリが基準を割ったからといって、そのたびにタスクを作れば現場が疲弊します。
期間の窓を持ち、回数のしきい値を持ち、安定していると見なす回数を持つ。この3つで、本当に直すべきものだけを拾う設計に見えます。
ただし実際にどう効くかまでは確認していません。値の意味は名前からの読み取りです。自分の環境で使うなら、小さい値で試して挙動を見てください。
番号が重複している監査がある
実測で気づいた小さな点です。監査10件のうち、AUD0000901 という番号が2件ありました。Server Minimum Statistics と Unix Server Baseline です。
番号は本来ひとつずつ振られるものですが、標準データでは重複することがあります。デモデータの投入過程で起きたものと読めます。
実務上の教訓は単純です。監査を番号で参照しない。sys_id か名前で指すようにしておけば、重複があっても取り違えません。
条件は4種類に分かれている
「あるべき状態」の中身は、テンプレートにぶら下がる条件が持ちます。
基底の cert_cond は23件で、その内訳は属性条件18件、CI関連条件3件、関連リスト条件2件でした。グループ関連とユーザー関連は0件です。
いちばん多い属性条件を実際に見ます。
実測の2件はこうでした。
Unix Server Template - 1 … disk_space>80^EQ ＝「"Disk space (GB)" greater than "80"」
Server Minimum Statistics - 2 … ram>2048^EQ ＝「"RAM (MB)" greater than "2048"」
condition（エンコードクエリ）と condition_display（人が読む形）を両方持っているのが特徴です。機械が使う形と人が読む形を分けて保存しています。
テンプレート名の末尾には - 1 - 2 が付きます。版番号です。条件を変えたときに、過去の結果がどの版で判定されたかを追えます。
結果3,540件のうち9割が失敗
状態の内訳は Failed 3,228件 / Certified 312件 でした。9割以上が失敗しています。
監査別に見ると、偏りがはっきりします。
Critical Business Services … 1,380件すべて Failed
Database Audit … 230件すべて Failed
UPS Audit（3日・7日）… 各600件中500件が Failed
Data Center Zone Usage … 700件中600件が Failed
Data Center Zone Consumption … 30件中18件が Failed
全件失敗している監査が2つあります。これは条件が厳しすぎるか、対象データがそもそも基準を満たしていないかのどちらかです。
全件失敗する監査は、そのままでは機能しません。直す気のない基準で毎回2,000件のタスクを作れば、誰も見なくなります。条件を現実に合わせるか、段階的に厳しくするかの判断が要ります。
なお10件の監査のうち、結果が出ているのは6件だけでした。残る4件は On Demand で、一度も実行されていません。
失敗1件を読む
具体的な失敗を1件開きます。
読み取れることが、この1画面にすべて入っています。
Configuration item … UPS Austin
Audit … UPS Audit (7 days)
Template … UPS Battery Life - 1
State … Failed
Column name … Seconds on Battery
Desired value … greater than field Value 3,600
Discrepancy value … 2,000
Follow on task … TASK0020382
日本語にすると、こうなります。「UPS Austin のバッテリー稼働秒数は3,600秒より大きくあるべきだが、実際は2,000秒だった。だから失敗とし、TASK0020382 を作った」
Desired value（あるべき値）と Discrepancy value（実際の値）を並べて持つ設計が効いています。タスクを受け取った担当者は、この2つを見るだけで何をすればよいか分かります。
REST で追加のフィールドも確認しました。stability が Stable、threshold が Exceeded。安定して基準を超え続けている状態、と読めます。
タスクは2,517件
cert_follow_on_task は 2,517件 ありました。Failed 3,228件に対して711件少ない計算です。
差の大部分は説明できます。Data Center Zone Usage は Failed が600件ありますが、create_tasks が false です。タスクを作らない設定なので、その600件は結果だけが残ります。
3,228 − 600 = 2,628。実際のタスクは2,517件なので、まだ111件の差が残ります。この差の理由までは特定できませんでした。
「失敗の数」と「タスクの数」は一致しません。是正の進捗を報告するときは、どちらの数字を使っているかを明示しないと話が噛み合わなくなります。
Instance Scan との違い
設定を点検してリストを出す、という点で Instance Scan と似ています。ただし目的が違います。
Instance Scan が見るのは プラットフォームの設定 です。空のACL、古いストアアプリ、非推奨API。管理者が直す対象で、指摘は一覧として残ります。
データ認証が見るのは CMDBのデータ です。サーバのメモリ、UPSのバッテリー。CIの管理者が直す対象で、外れたものにはタスクが飛びます。
もうひとつの違いは、是正の届け先です。Instance Scan の指摘には担当者がいません。データ認証は managed_by から担当者を決めてタスクを配ります。
点検して終わりか、直す人に届けるところまでやるか。この差が、2つの機能の役割を分けています。
実務で気をつけるところ
全件失敗する監査を放置しない
実測では2つの監査が全件失敗していました。この状態でタスクを作り続けると、担当者の受信箱が埋まります。
新しい監査を作ったら、まず create_tasks をオフのまま走らせて結果を見る。失敗率が想定内なら、タスク作成をオンにする。この順番なら事故になりません。
実行タイミングは変化の速さに合わせる
Daily / Weekly / Monthly / On Demand の4通りが使われていました。毎日見る必要のないものを毎日見ると、結果テーブルが膨らむだけです。
逆に、日々変わるものを月次で見ると、気づいたときには手遅れになります。対象がどれくらいの速さで変わるかを先に決めます。
担当者フィールドを埋めておく
assign_to が managed_by を見る設定である以上、CIの管理者が空だとタスクが宙に浮きます。実測の設定では担当者なしのタスクが作られますが、それは誰も拾わない可能性があります。
データ認証を回す前に、対象CIの管理者フィールドがどれくらい埋まっているかを数えておくと安全です。
条件は版で管理されている
テンプレート名に - 1 - 2 の版番号が付きます。条件を変えると新しい版になり、過去の結果はその時点の版を指したままです。
「基準を変えたのに古い結果が残っている」と見えたときは、版が違うだけということがあります。結果を読むときは Template 欄の版番号も見ます。
結果は消さずに溜まる
3,540件の結果が残っていました。毎日走る監査があるので、放っておけば増え続けます。
古い結果をいつまで残すかは、運用で決める必要があります。アーカイブの対象として検討する価値があるテーブルです。
どこから触るか
/cert_audit_list.do … 監査10件
/cert_audit.do?sys_id=... … 1件の監査（対象・テンプレート・タスク設定）
/cert_template_list.do … テンプレート9件
/cert_attr_cond_list.do … 属性条件18件
/cert_filter_list.do … フィルタ9件
/cert_audit_result_list.do?sysparm_query=GROUPBYstate … 結果を状態別に
/cert_follow_on_task_list.do … フォローオンタスク
結果の一覧では Column name / Desired value / Discrepancy value を列に出すと、何がどう外れているかが一覧で読めます。
まとめ
データ認証は、CMDB の「あるべき状態」を条件として持ち、外れたCIにタスクを配る仕組みでした。
条件23件がテンプレート9件にまとまり、監査10件がそれを対象テーブルと実行タイミングに結びつけます。実行すると結果が残り、失敗のうちタスク作成が有効なものには担当者宛のタスクが作られます。
実測では結果3,540件のうち Failed が3,228件、タスクが2,517件。9割以上が失敗という状態は、基準と現実がずれていることを示しています。
UPS Austin の例（3,600秒あるべきところ2,000秒）のように、あるべき値と実際の値を並べて持つ設計が、是正を進めやすくしています。CMDB を整えたあとに保つ段階で、最初に検討する機能です。
用語
監査（cert_audit） … いつ・どのCIクラスを・どう扱うかの定義。タスクを作るかもここで決める
テンプレート（cert_template） … あるべき状態の束。名前の末尾に版番号が付く
条件（cert_cond） … 判定の1つずつ。属性・CI関連・関連リストなどの種類がある
フィルタ（cert_filter） … 対象のCIを絞り込む
結果（cert_audit_result） … 1CI × 1条件の判定結果。Failed / Certified
フォローオンタスク（cert_follow_on_task） … 失敗に対して作られる是正タスク
Desired State … 設定があるべき状態から外れていないかを機械が判定する種類
自分の環境で確認するときのURL
/cert_audit_list.do?sysparm_query=ORDERBYnumber（監査10件）
/cert_audit.do?sys_id=...（Server Minimum Statistics の設定）
/cert_audit_result_list.do?sysparm_query=GROUPBYstate（結果3,540件の状態別）
/cert_audit_result.do?sys_id=...（AUDR0001487 の失敗内容）
/cert_attr_cond_list.do?sysparm_query=ORDERBYcert_template（属性条件18件）
/cert_follow_on_task_list.do（タスク2,517件）
実測の要点（再掲）
cert_audit 10件（Desired State 9 / Scripted 1）。実行は Daily 3 / Weekly 1 / Monthly 2 / On Demand 4
cert_template 9件 / cert_filter 9件 / cert_cond 23件（属性18・CI関連3・関連リスト2）
cert_audit_result 3,540件＝Failed 3,228 / Certified 312
結果が出ている監査は10件中6件。Critical Business Services と Database Audit は全件 Failed
cert_follow_on_task 2,517件。Failed との差711件のうち600件は create_tasks=false の監査で説明できる
AUDR0001487: UPS Austin / Seconds on Battery / あるべき値 3,600超 / 実際 2,000 / TASK0020382 を生成
担当者は assign_to=managed_by（CIの管理者）。空なら担当者なしのタスクを作る
関連記事
ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える — cert_audit が監査する CMDB 本体の CI・関係・サービスの母数を実機で確認できます。
検証範囲とおことわり
件数・項目・値は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
監査は自分で実行していません。既存の結果3,540件を読み解いたものです。
Failed 3,228件とタスク2,517件の差のうち、111件ぶんの理由は特定できていません。
Scripted 監査のスクリプト本文は読んでいません。
audit_type のうち Data Certification / Architecture Compliance / Compliance は実データが無く未検証です。
threshold_count / stability_count / health_window が実際どう効くかは未検証です。
