ZurichとAustraliaを並べて数えたら何が変わっていたか テーブル・プラグイン・既定値を実機で突き合わせる

次のリリースに上げると何が変わるのか。リリースノートには「追加された機能」が並びますが、自分の環境で何が増えて何が消えるのかは、そこには書いてありません。ZurichのPDIとAustraliaのPDIを用意し、同じ方法でテーブルとプラグインを数えて突き合わせました。テーブルは6,283から6,419へ、プラグインは35件が新しく現れ、多要素認証の既定値が反転していました。

最初に断っておくこと：これは「アップグレードの前後」ではありません

先に、この記事の限界をはっきりさせます。

比較したのは別々に作成された2つのPDIです。アップグレードを試みて失敗したため、新しいPDIを作り直した、という経緯によるものです。同一インスタンスを上げた前後ではありません。

この違いは重要です。2つの環境にはデモデータの差があります。実際、インシデントは72件から67件、Performance Analyticsのジョブ実行ログは2,202件から330件へと減っていました。これらを「Australiaで減った」と書くのは誤りです。単に別の環境だからです。

そこで本記事では、製品の作りを示す差分だけを扱います。

読み替えかたも決めておきます。あるテーブルがAustralia側で見つからないとき、それは「廃止された」ではなく「このPDIでは既定で無効」と読みます。プラグインを有効にすればテーブルは作られるはずですが、今回は有効化しての確認まではしていません。

数の全体像：テーブルは136増え、プラグインは19減った

図の色には意味があります。緑は増えたもの、赤は無くなったもの、橙は既定値が変わったもの、灰色は器だけで中身が無いものです。

テーブル定義は136増えました。ただし内訳を見ると、増えたものが340件、無くなったものが204件あり、差し引きで136という数字です。入れ替わりのほうが大きい。

プラグインは総数では19減っています。新しく35件現れ、54件が消えました。

数え方でつまずいた話

最初に数えたときは「4,976から6,456へ」という結果が出ました。これは誤りでした。

一覧を取得するAPIには件数の上限があり、Zurich側でその上限に当たっていたのです。4,976という数字は、上限5,000のすぐ下でした。総数を知りたいときは集計用の関数を使います。一覧の件数で代用してはいけません。上限に近い数字が出たら、まず上限を疑ったほうが安全です。

増えた340件のうち、実際に読む価値があるのはどれか

340件をそのまま眺めても意味がありません。接頭辞で分類すると、性格の違いがはっきりします。

最多はts_で89件。中身はts_c_13_0からts_c_13_dfといった名前で、時系列データを分散して格納するための内部シャードです。機能ではなく器なので、数だけ押さえて先へ進みます。

追う価値があるのはdp_の15件でした。

データプライバシーは、定義が入った状態で届いている

dp_はデータプライバシー関連です。新しく有効になったプラグインcom.glide.data_privacy_coreと符合します。

このグループが他と違うのは、標準の定義が最初から入っている点です。

dp_techniqueには9件。個人情報をどう隠すかの技法です。固定文字への置換が2種類、先頭または末尾からの部分置換、ランダム置換。削除と、合成データによる匿名化も入っています。何もしないという選択肢が1件あるのが面白いところでした。

dp_data_patternには32件。こちらは「何を個人情報とみなすか」のパターン集です。中身が具体的でした。

クレジットカードはブランド別に5種類。さらにCVVと有効期限が独立して定義されています。国際的な識別番号も揃っています。IBAN と SWIFT/BIC。国別ではインドのAadhaar、フランスのINSEE、カナダのSIN。英国はNHS番号とNI番号の2種類。米国はEINとグリーンカード番号が入っていました。医療系ではICD-10の診断コードとMedical Beneficiary Identifier。技術系ではIPv4・IPv6アドレスとMACアドレス。

つまり、自分でパターンを定義しなくても、主要な個人情報はすぐ検出できる状態で届いているということです。

定義はあるが、まだ何も入っていないもの

同じ「新しく増えたテーブル」でも、性格が違うものがあります。

プロセスマイニングのpromin_process_modelは0件。クエリキャッシュのqc_configured_queryも0件でした。状態遷移テンプレートのsttrm_base_templateは7件入っていましたが、分類を持つsttrm_categoryは0件です。

器はあるが、まだ何も置かれていない。この状態は珍しくありません。データプライバシーのように定義まで届く機能と、枠だけ用意される機能があります。テーブルが増えたことと、その機能がすぐ使えることは別だと考えたほうが安全です。

新しく有効になった21件は、どこに効くのか

新しく現れたプラグイン35件のうち、有効な状態で入っていたのは21件でした。名前から役割を推し量ると、基盤に効くものが並びます。

com.glide.security.query_aclはクエリ単位のアクセス制御、com.glide.query_cacheは問い合わせ結果のキャッシュ。どちらもデータの読み取り経路そのものに関わります。権限は誰が持っているかで扱った中間表の仕組みに、もう1層乗る形になりそうです。

com.glide.error_frameworkはエラー処理の共通化、com.glide.sys.session_activityはセッション単位の活動記録。運用側から見ると、障害調査で見る場所が増える可能性があります。

com.glide.data_privacy_coreは前の節で見たデータプライバシーの土台です。プラグインとテーブル群が一致していました。

テーブル側にも痕跡がある

有効化されたプラグインは、テーブルの増え方にも現れます。sys_系76件を眺めると、sys_atf_code_coverageやsys_atf_suite_aggregate_coverageといった名前が見つかりました。無効から有効に変わったcom.glide.js.coverageと対応しています。ATFの3層構造を扱った記事の続きにあたる部分です。

sys_archive_restore_requestとsys_archive_restore_checkpointも新顔でした。アーカイブしたデータを戻す仕組みのようです。データがどこに溜まっていつ消えるかでは退避する側だけを扱いましたが、戻す側のテーブルが用意されたことになります。

sn_系58件は第2語で分類するとum_が9件、ex_とexperiment_が各6件、telemetry_が6件。スコープアプリ由来のものが中心で、個別に追うより「どのアプリが増えたか」で見たほうが早そうです。

無くなった204件の正体

減った側も接頭辞で見ると、ts_が119件で最多でした。増えた側と同じく内部シャードなので、機能が失われたわけではありません。

実質的に意味があるのは2つの群でした。

1つ目はオンコールの当番表です。cmn_rotaとその関連7テーブル、合わせて8件が取得できません。当番表そのものに加えて、メンバー・名簿・エスカレーション・連絡手段の設定まで一式で消えています。

2つ目は権限委任です。sys_delegation_rule系とsys_granular_delegate系の5件。誰の権限を誰にどこまで預けるか、を管理する仕組みです。

理由はプラグイン側にありました。com.snc.on_call_rotationとcom.glide.granular_service_delegationが、どちらもactiveからinactiveに変わっています。テーブルが消えたわけではありません。プラグインが入っていないので、そもそも作られていないという状態です。

逆方向の変化もあります。スクリプトのカバレッジ計測com.glide.js.coverageと、Performance Analyticsの機械学習com.snc.pa.mlbは、無効から有効になっていました。

消えたプラグイン54件のほうは追いにくい

テーブルと違い、プラグインが54件消えている点は解釈が難しいところです。名前を見るとcom.sn_で始まるスコープアプリ由来のものが多く、Zurich側の環境に固有のものが混じっている可能性があります。プラグイン一覧は環境の作られ方に左右されるので、ここは「54件差があった」という観測に留めます。プラグインの有効・無効と依存関係で扱ったとおり、依存関係で自動的に入るものもあるためです。

新機能が何を狙っているかは、プラグインの説明文に書いてある

ここまでは件数の話でした。では、増えた機能は何を目指しているのか。

これを知る方法があります。v_pluginのdescription列です。ここにServiceNow自身が書いた説明文が入っていました。リリースノートを探しに行かなくても、インスタンスの中から読めます。

21件の説明を読むと、方向性が見えてきました。

性能とデータ保護に手が入っている

Query Cacheの説明は「頻繁にアクセスされる結果をキャッシュし、データベース負荷を減らして応答時間を改善する」でした。読み取り経路そのものの改善です。

Data Privacy Coreは「機微データを検出し、匿名化する機能を提供する」。前の節で見たdp_テーブル群の土台がこれです。

この2つが同時に入っているのは示唆的です。データを速く返すことと、返してはいけないデータを守ること。読み取り経路の両側に手が入っています。

権限の粒度が細かくなっている

Events Granular Roleの説明は「システムイベントへのきめ細かいアクセス権を与えるための専用管理ロールを用意する」でした。

これまで管理者権限でまとめて扱っていた領域を、機能単位のロールに分ける方向です。Configuration Management (CMDB) Rolesも同じ流れで、CMDB関連のロールが独立したプラグインに切り出されています。説明には「先に読み込まれるようにするため」と理由まで書かれていました。

フローが3種類まとめて追加されている

Change Management - Flows、Provides flows for State Transition Models、ITSM Dynamic CI Flows。この3つはいずれもフローを提供するプラグインです。

最後のものは「Incident・Problem・Change で動的CIグループを処理するフロー」と説明されています。3つのプロセスにまたがる処理が、フローとして標準提供されるようになった、と読めます。

説明が無いものもある

Error Frameworkはdescriptionが空でした。名前からエラー処理の共通基盤と推測できますが、公式の説明が付いていません。

こういうものは、テーブルの増え方から推し量るしかありません。今回は該当しそうなテーブルを特定できていないので、分からないままにしておきます。

プラグインの説明文を読むという調べ方

この方法は、リリースのたびに使えます。手順は単純です。

新旧のプラグイン一覧を突き合わせて、増えたものを特定する。そのIDでv_pluginを引き、description列を読む。それだけです。

公式ドキュメントを探すより早い場面があります。製品に同梱されている説明なので、そのインスタンスに実際に入っているものと必ず一致するからです。ドキュメントは版がずれることがありますが、この方法ならずれません。

ただし限界もあります。説明文は1〜2行と短く、使い方までは書かれていません。「何をするものか」は分かっても「どう設定するか」は別途調べる必要があります。それに今回のように、説明が空のものもあります。

全体像を掴む段階で使う道具と考えるのがよさそうです。詳細に入るときは、そこから公式ドキュメントに進むことになります。

いちばん実務に効く1行：MFAの既定値が反転していた

プロパティの差分は2件だけでした。1件はビルド番号なので、実質1件です。

glide.authenticate.multifactorが、falseからtrueへ。多要素認証のマスタースイッチです。

Zurichでは基盤だけが入っていて、既定では動いていませんでした。認証手段の定義もポリシーも用意されているのに、大元のスイッチが切れている状態です。Australiaではこれが入っています。

新しく環境を作ったときの前提が変わる、という意味で影響が大きい変更です。なお、実際に認証画面が出るところまでは確認していません。値が変わっていた、という事実までが今回の範囲です。

実機を見て気づいたこと

いちばん意外だったのは、増減の大きさに比べて実質的な変化が小さかったことです。340件増えて204件減った、と聞くと大きな入れ替わりに見えます。しかし増えた側の89件と減った側の119件は同じts_系の内部シャードで、合わせて208件。全体の3分の1以上が「器の数え方の違い」でした。数字の大きさに引きずられると、見るべきものを見落とします。

もう1つは、消えた機能の見え方です。当番表のテーブルが8件まとめて取得できなくなったとき、最初は廃止されたのかと思いました。プラグインの状態を見て、単に入っていないだけだと分かりました。テーブルの有無だけで判断すると、機能の廃止と未導入を取り違えます。セットでプラグインを確認する癖をつけたほうがよさそうです。

3つ目は、既定値の変化が1件しか無かったことです。テーブルは340件増えているのに、今回チェックしたプロパティで値が変わっていたのはMFAだけでした。機能は増えても、既存環境の振る舞いを変える設定はほとんど動かさない。そういう方針に見えます。裏を返すと、その数少ない1件がいちばん影響が大きいということでもあります。数の多いところより、数の少ないところを先に見たほうがよさそうです。

データプライバシーの32パターンを眺めていて、設計の意図が見えた気もしました。クレジットカードをブランド別に分け、CVVと有効期限を独立させています。番号の桁数や形式が違うので当然といえば当然ですが、ここまで細かく分かれていると、自分でパターンを足す場面はかなり減りそうです。国別の識別番号が10種類以上入っている点も含めて、「まず標準で試してから足りない分を足す」順序で使う想定なのだと読み取れます。

実務では何に使えるか

新しいリリースを検証する際の手順として、次の順で見ると早いと思います。

まずプロパティの差分を見ます。件数は少なくても、既定値の変更は全社に効いてきます。今回のMFAがその例でした。たった1行が検証計画を左右します。

次にプラグインの有効・無効の変化です。テーブルの増減より先にこちらを見ると、原因と結果を取り違えません。当番表が消えたのではなく、プラグインが入っていないだけ、と判断できます。

最後にテーブルの増減を接頭辞で分類します。全件を追う必要はありません。内部シャードのように機械生成された器を除くと、実際に読むべきものは数分の1に減ります。今回は340件が実質40件程度でした。

この3段階なら、リリースノートを読む前に自分の環境で何が起きるかの見当がつきます。

順番には理由があります。プロパティは件数が少なく、影響が広い。プラグインは中くらいの件数で、テーブルの増減を説明してくれます。テーブルは件数が多いわりに、大半が器です。件数の少ないものから見ると、後の解釈が楽になります。 逆に340件のテーブル一覧から入ると、何が重要か分からないまま時間だけが過ぎます。今回はその遠回りをしてから、この順番に落ち着きました。

同じことを自分の環境でやる手順

この比較は特別な道具を使っていません。読み取り専用のAPIを3回叩くだけです。手順にしておきます。

手順1：テーブル定義の一覧を両方から取る

sys_db_objectのname列を全件取得して、集合として引き算します。ここで注意が要るのが件数の上限です。取得件数の指定を大きめにしないと、途中で打ち切られた一覧同士を比べることになります。実際に最初はこれで失敗しました。

取得できたら、増えた側と減った側をそれぞれファイルに書き出しておきます。あとで接頭辞ごとに数えるときに使います。

手順2：プラグインの一覧と有効・無効を取る

v_pluginからidとactiveを取ります。ここで見るのは3種類です。片方にしか無いもの、両方にあってactiveが変わったもの、そして総数の差。有効・無効の変化は件数が少ないわりに影響が大きいので、最初に目を通す価値があります。

手順3：気になるプロパティの値を取る

sys_propertiesから、自分の環境で効いている設定を名指しで取ります。全件を比べると差分が膨大になるので、認証・メール・検索など、影響範囲の広いものに絞ったほうが読みやすくなります。今回はここでMFAの反転が見つかりました。

手順4：接頭辞で分類してから読む

増えた340件をそのまま読むのは現実的ではありません。アンダースコアの前で切って数えるだけで、性格が分かれます。今回はts_が89件で最多でしたが、中身は内部シャードでした。数が多い接頭辞ほど機械生成の器である可能性が高い、という傾向は覚えておくと時間を節約できます。

手順5：気になった群だけ中身を見る

分類の結果、追う価値がありそうな群だけ実際にレコードを見ます。今回はdp_の15件を選び、そこで技法9件とパターン32件という中身にたどり着きました。340件を全部見ていたら、この発見までは届いていません。

この比較で分かることと、分からないこと

最後に線を引いておきます。

分かるのは製品として何が用意されたかです。テーブルの定義、プラグインの有無、標準で投入される定義の件数、既定のプロパティ値。これらはどの環境でも同じなので、自分の環境に当てはめて読めます。

分からないのはその機能が実務で使えるかどうかです。テーブルがあることと、動くことは別でした。プロセスマイニングもクエリキャッシュも、定義用のテーブルは用意されていますが中身は0件です。使うには設定が要ります。

もう1つ分からないのが移行そのものの挙動です。冒頭に書いたとおり、今回は別々に作られた環境同士の比較でした。実際にアップグレードを通した場合、既存の設定やカスタマイズがどうなるかは、この方法では分かりません。そこはアップグレードで設定が消えない運用レシピで扱ったsys_upgrade_historyの読み方が要ります。

数えて分かるのは輪郭までです。ただ、輪郭が先に見えていると、詳細を調べる順番を決められます。

状態遷移テンプレートという新顔

dp_の次に気になったのがsttrm_の7件でした。State Transition Template の略と読めます。

sttrm_base_templateには7件のレコードが入っていました。一方で分類を保持するsttrm_categoryは0件です。テンプレート本体だけが先に投入されていて、分類はこれから、という状態に見えます。

有効になったプラグインの中にcom.snc.itsm.state_transition_model.flowsとcom.snc.change_management.flowsがあり、名前から見て変更管理の状態遷移まわりと関係しそうです。ChangeのモデルとStateの関係はChange Requestのtypeで承認が変わる仕組みで扱いましたが、そこに新しい層が乗る可能性があります。ここは推測です。実際に画面から作れるのか、既存のChange Modelと何が違うのかまでは確認していません。

新しい接頭辞に気づいたら、こうしてテーブル定義の一覧を絞り込むところから始めると全体像が早く掴めます。

増えた機能を追うときの優先順位

340件の中から何を先に見るか。今回の作業を振り返ると、判断の材料は3つでした。

1つ目はレコードが入っているかどうかです。定義テーブルに標準データが投入されている機能は、設計者が「すぐ使ってほしい」と考えている可能性が高い。データプライバシーの技法9件とパターン32件がその例でした。逆に0件のものは、枠だけ先に用意された段階と読めます。

2つ目はプラグインとの対応です。新しいテーブル群の名前が、有効になったプラグインの名前と一致するかを見ます。一致していれば、その機能はこの環境で動く前提になっています。dp_とcom.glide.data_privacy_coreはきれいに対応していました。

3つ目は名前の機械らしさです。ts_c_13_0のような連番の名前は、人間が設計した機能ではなく内部の器です。数だけ多くて中身が無いので、後回しにして構いません。

この3つで340件を篩にかけると、実際に読むべきものは40件程度まで減りました。全部を追う必要はありません。

既存記事のどこが古くなるか

この媒体では260本以上の記事をZurichで検証してきました。今回の差分は、そのどこが古くなるかの地図でもあります。

影響が出るのは、無効化された機能を扱った記事です。オンコールの当番表と権限委任の2領域が該当します。Zurichでは動いていた機能が、新しく作った環境では既定で入っていません。記事の内容が間違いになったわけではありませんが、「同じ手順を試したらテーブルが無い」という読者が出る可能性があります。

影響が小さいのは、基盤テーブルを扱った記事です。sys_dictionaryやsys_security_aclのような土台は、件数こそ環境で変わるものの、構造そのものは変わっていませんでした。

そして新しく書くべき領域が、データプライバシーです。標準定義が32パターン入っていて、実画面も撮れます。既存記事のどれとも重ならない新領域なので、個別の記事として掘り下げる価値がありそうです。

用語

• PDI：Personal Developer Instance（無料の検証用インスタンス）

• OOTB：Out of the Box（初期設定のまま）

• シャード：1つの論理的なデータを複数のテーブルに分割して格納する仕組み

• マスタースイッチ：機能全体の有効・無効を決める大元の設定

自分の環境で確認するときのURL

自分のインスタンス名を先頭に付けると、同じ画面が開けます。

• /sys_db_object_list.do?sysparm_query=nameSTARTSWITHdp_ … データプライバシーのテーブル一覧

• /dp_technique_list.do … 匿名化の技法

• /dp_data_pattern_list.do … 個人情報の検出パターン

• /sys_properties_list.do?sysparm_query=name%3Dglide.authenticate.multifactor … MFAのマスタースイッチ

• /v_plugin_list.do?sysparm_query=active%3Dtrue … 有効なプラグイン一覧

関連記事

• ServiceNowで権限はどこで決まる？ ユーザーからACL・ドメインまで7つの層を実機でたどる完全ガイド — MFAの手前にある認可の仕組みを層で整理しています。

• ServiceNowの深夜の障害は誰が受ける？ On-Call Schedulingの当番表を実機で読む — 今回無効になっていたcmn_rotaを扱った記事です。

• ServiceNowのデータはどこに溜まっていつ消える？ 添付・履歴・ログ・アーカイブを実機で確認 — 増え続けるテーブルの管理という観点で続けて読めます。

検証環境と未検証範囲

• 確認した範囲：2つのPDI（Zurich / Australia）に対するsys_db_object・v_plugin・sys_propertiesの読み取り、および記事で引用している400テーブルの件数取得。すべてREST APIの読み取りのみで、書き込みは行っていません。

• 確認していない範囲（断定しません）：アップグレードそのものの挙動。今回は別々に作成された2つのPDIの比較であり、同一インスタンスを上げた結果ではありません。無効なプラグインを有効化した場合に何が作られるか、データプライバシーやプロセスマイニングを実際に動かした結果、MFAを有効にしたときの実際の認証画面、340件と204件のテーブル全件の内部構造。これらは別途の検証が必要です。

• デモデータの差（業務レコードの件数など）は環境固有のため、差分として扱っていません。