[Brazil調査] Compliance dynamic schemaの仕組み：変更申請に2フィールドで規制項目を持つ

2026年10月10日 11:49

検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認

監査証跡の要否、停止の有無、影響ユーザー数、切り戻しにかかる時間。規制の厳しい業界では、こうした項目を変更ごとに記録します。変更申請のテーブルに列を足すと、項目が変わるたびにカスタマイズが増えます。

Brazil で追加された Compliance dynamic schema は、これらの項目を1つのフィールドに名前と値の組（JSON）として保存します。列は増やしません。Brazil に上げた PDI で、定義の中身を確認し、テスト用の変更に値を入れて読み戻しました。

この記事で分かること

変更申請に追加された2つのフィールドと、それを支える定義の置き場所
初期状態で入っている14個の属性と3つのカテゴリ
保存される JSON の形と、スクリプトで読むときの癖
実務で使うときの進め方

Australia の場合

変更申請の規制対応項目は、これまで列の追加で持つのが普通でした。項目が増えるたびに change_request へ列を足し、フォームにも載せます。列は更新セットで運ぶため、環境ごとの差も出ます。

今回の公式ドキュメントを調べると、Australia 版のドキュメントには Compliance dynamic schema のページがありませんでした。Brazil の差分ノートが、変更管理の新機能として扱っています。

差分ノートの説明は次のとおりです。

Store risk and compliance details on change requests without adding columns to the Change Request table.

（訳：Change Request テーブルに列を追加せず、変更申請にリスクとコンプライアンスの詳細を保存します。）

引用元：https://www.servicenow.com/docs/r/delta-australia-brazil/brazil-australia-changemanagement-release-notes.html

基盤となるプラットフォームの Dynamic Schema は、変更管理に限らず、任意のテーブルで使える機能です。その仕組みを変更申請に当てはめたのが、今回の機能です。他の業務テーブルでも、同じ考え方で属性を持たせられます。

この機能で使う用語

用語を整理します。

動的属性（Dynamic Attribute）：名前と値の組。「監査証跡が必要か」「影響ユーザー数」のような1項目
属性の保存フィールド（Dynamic Attribute Store）：動的属性を JSON で持つフィールド。変更申請では Risk and compliance attributes
名前空間（Dynamic Namespace）：属性とカテゴリをまとめる入れ物。テーブルの名前がカラムをまとめるのに近い
動的カテゴリ（Dynamic Category）：属性をまとめる分類。親を持てる
選択肢セット（Dynamic Choice Set）：String 型の属性が選べる値の一覧。Rollback Time が使う

変更申請に追加された2フィールド

公式ドキュメントは、この機能を次のように説明しています。

Compliance dynamic schema stores the risk and compliance details of a change as name and value pairs in a single field. This avoids adding a column to the Change Request table for each detail.

（訳：Compliance dynamic schema は、変更のリスクとコンプライアンスの詳細を、1つのフィールドに名前と値の組として保存します。詳細ごとに Change Request テーブルへ列を追加せずに済みます。）

引用元：https://www.servicenow.com/docs/r/it-service-management/change-management/compliance-dynamic-schema.html

構成要素は次のとおりです。

名前空間（Dynamic Namespace）：change_request/risk_and_compliance_attributes。属性とカテゴリの入れ物
属性の保存フィールド：Risk and compliance attributes。値を JSON で持つ
カテゴリの参照フィールド：Risk and compliance category。変更に適用するカテゴリを指す

実機のディクショナリで確かめると、change_request に該当するのは2行だけでした。

①の2行が追加分です。更新日時は2026-10-08で、Brazil へのアップグレード中に入った時刻でした。Brazil の差分ノート（Australia との違い）にも、変更管理の新機能として載っています。

標準の属性とカテゴリ

名前空間のレコードを開くと、下のタブに属性・カテゴリ・選択肢・選択肢の上書きが並びます。

属性は型を持っています。内訳は次のとおりです。

True/False：9個（Audit Trail Required、Downtime Required、Personal/Sensitive Data Involved、GDPR、ISO 27001、PCI-DSS、SOx など）
Integer：2個（Estimated Users Impacted、Potential Financial Loss (USD)）
Decimal：1個（Lead Time）
String（選択肢つき）：2個（Rollback Time、Financial Close Period Impact）

Rollback Time の選択肢は「30分未満」「30分〜2時間」「2〜8時間」「8時間超」の4段階です。自由入力でなく、決まった値から選ぶ作りになっています。

標準の属性の意味

属性には、それぞれ説明文が付いています。実機の記述から、主なものを日本語で整理します。

Audit Trail Required：誰が、何を、いつ、なぜ変更したかを記録する詳細ログが必要かを示す
Downtime Required：実装中にシステム停止やサービス不可が発生するかを示す
Estimated Users Impacted：機能の変更で直接影響を受けるエンドユーザーの人数
Lead Time：承認から実装予定までの日数。短いほどレビューとテストが減り、実行のリスクが上がるという説明が付く
Rollback Time：失敗したときに完全に元へ戻すまでの見積り時間。バックアップの復元、再起動、確認の時間を含む
Financial Close Period Impact：決算の凍結期間に重なるかどうか。SOX の IT 全般統制は、決算・監査の期間中、総勘定元帳に影響する変更を制限するのが一般的、という説明が付く
Potential Financial Loss (USD)：失敗や切り戻しで失うおそれのある金額。承認や CAB へのエスカレーション段階を左右する、という説明が付く

説明文のとおり、これらは項目の定義というより、変更のリスクを判断する材料です。リスクを数値化して承認の厳しさを変える運用なら、そのまま使える項目が揃っています。

カテゴリは階層です。

Risk and Compliance（親、7属性：停止、リードタイム、切り戻し時間、影響ユーザー数、個人情報、監査証跡、外部ベンダー）
Financial Risk and Compliance（子、4属性：PCI-DSS、SOx、決算期の影響、想定損失額）
SaaS/Cloud Security Compliance（子、3属性：ISO 27001、GDPR、セキュリティレビュー完了）

設定の手順を説明する公式ページには、子カテゴリが親の属性を引き継ぐとあります。

Set the Parent field to place a category below a broader category, so that the category inherits the attributes of its parent.

（訳：Parent を設定すると、広い意味のカテゴリの下にカテゴリを置けます。子は親の属性を引き継ぎます。）

引用元：https://www.servicenow.com/docs/r/it-service-management/change-management/configure-compliance-dynamic-schema.html

公式はこれらを「例」と位置づけています。使わないものは無効にして、自社の規制に合う属性とカテゴリを足す前提です。

標準フォームでの表示

公式ドキュメントのとおり、2つのフィールドは標準のフォームに載っていません。既定ビューのレイアウトに両フィールドが含まれていないことも、実機で確認しました。

見るために、一時的なビューを作って4つのフィールドだけを並べました。既定ビューは変更していません。確認後、一時ビューは削除しています。

②の属性欄は、JSON を直接編集するテキスト領域です。属性名と値を手で書く作りのため、運用に載せるときはフォームの置き場所と入力ルールを決める必要があります。

一時ビューで表示を確認し、検証後に削除しました。作成したのはビュー1件、そのセクション1件、フィールドの要素4件で、削除後の再検索で0件になったことを確かめています。既定ビューのレイアウトには手を入れていません。本番で運用するなら、規制対応の担当者向けのビューだけに2つのフィールドを足す方法が考えられます。

値の保存形式

テスト用の変更に、スクリプトで値を入れました。公式ドキュメントの例にならい、setValue('<保存フィールド>->属性名', 値) の形です。

gr.setValue('risk_and_compliance_category', 'change_request/risk_and_compliance_attributes/financial_risk_compliance');
gr.setValue('risk_and_compliance_attributes->audit_trail_required', 'true');
gr.setValue('risk_and_compliance_attributes->downtime_required', 'true');
gr.setValue('risk_and_compliance_attributes->estimated_users_impacted', '1200');
gr.setValue('risk_and_compliance_attributes->lead_time', '7.5');
gr.setValue('risk_and_compliance_attributes->rollback_time', 'between_30_min_and_2_hrs');
gr.setValue('risk_and_compliance_attributes->personal_sensitive_data_involved', 'true');
gr.setValue('risk_and_compliance_attributes->pci_dss_compliant', 'true');
gr.setValue('risk_and_compliance_attributes->lead_time_to_complete', 'true'); // 未定義の属性

標準の属性7個と未定義の属性1個を設定し、保存された値は次の JSON でした。

{"audit_trail_required":"true","downtime_required":"true","estimated_users_impacted":"1200",
 "lead_time":"7.5","pci_dss_compliant":"true","personal_sensitive_data_involved":"true",
 "rollback_time":"between_30_min_and_2_hrs","lead_time_to_complete":"true"}

数値も真偽値も、保存は文字列です。型は属性の定義が持ち、保存するときの値は文字列になります。

lead_time_to_complete は名前空間に定義が無い属性です。エラーにならず保存されました。公式ドキュメントは、定義のない属性を一時的（transient）な属性と呼び、その変更だけに有効で、値は文字列として保存されると説明しています。入力ミスの属性名もそのまま通るため、定義済みの名前だけを使う運用ルールが要ります。

スクリプトでの読み取り

保存した値を、スクリプトから読み戻しました。条件判定の例と検索も並べています。

var f = 'risk_and_compliance_attributes';
gr.getDynamicAttributeValue(f, 'audit_trail_required');   // "1"
var needsReview = gr.getDynamicAttributeValue(f, 'audit_trail_required') == '1'
  && parseInt(gr.getDynamicAttributeValue(f, 'estimated_users_impacted'), 10) >= 1000;
// 検索
q.addQuery('risk_and_compliance_attributes->audit_trail_required', 'true');

出力から分かったことは次の3点です。

True/False の属性は、保存が "true"、getValue と getDynamicAttributeValue の戻りが "1"
未定義（transient）の属性は "true" のまま
addQuery に 'true' を渡す検索は1件ヒットした

最初は == 'true' で比べて、条件が成立しませんでした。リスク条件スクリプトや Business Rule に書くときは、== '1' で比べます。定義済みの True/False と、未定義の文字列で戻りが違うため、定義を先に作ってから条件を書くほうが安全です。

実務で進めるなら

進め方を順に並べます。

記録したい規制項目を洗い出し、名前空間の属性として定義する。標準の14個で足りるものは流用する
使わない標準の属性とカテゴリは、削除せず Active を外す。公式は、すでに入力済みの値を読めるように残すことを勧めている
業界・規制ごとにカテゴリを作り、親カテゴリの下に置く
フォームの置き場所を決める。標準のフォームには出ないため、必要な利用者のビューにだけ足す
条件に使う属性は、スクリプトの戻りが "1" になる型（True/False）を前提に比較を書く

列を増やさない利点は、属性ごとの列追加を避けられることです。change_request のディクショナリには手を入れず、定義は名前空間の側に置きます。アップグレード時の影響は今回確かめていません。プラットフォームの Dynamic Schema は、同じ名前空間を複数のテーブルで共有する使い方も想定しています。

列を足す場合との違い

規制項目を列で持つ場合と、動的属性で持つ場合を並べます。どちらが合うかは、後の「この機能を選ぶ判断」で決めます。

項目を足すとき：列は変更申請テーブルの定義変更とフォーム修正。動的属性は名前空間への属性の追加
項目をやめるとき：列は削除かフォームから外す。動的属性は Active を外すだけで、入力済みの値は残る
入力値の制約：列は型と選択肢を辞書で持つ。動的属性も型と選択肢セットを持つが、JSON の欄は手入力
検索：列は通常の項目として検索できる。動的属性も -> 付きの指定で検索できる
画面：列はフォームに自然に載る。動的属性は標準で載らず、置き場所を決める必要がある
移送：列はテーブル定義ごと運ぶ。動的属性は名前空間の定義を運ぶ

動的属性に向いているのは、規制の見直しで項目がたびたび変わる場合です。固定で長く使う項目なら、従来どおり列で持つほうが画面の扱いは素直です。

管理と入力で必要な権限

公式の設定手順では、名前空間の確認と変更に admin ロールが必要です。値を入れる側は、変更申請テーブルへの書き込み権限があればよく、特別なロールは要りません。属性の定義を変える担当者と、値を入れる担当者を分けて設計できます。

型の変更

プラットフォームの説明では、属性の型は後から変えられ、すでに保存した値は変わりません。変わるのは、システムがその値を扱う方法です。今回の検証で、保存は文字列、取得は型に応じた値という動きを見たのと合致します。型を変える前に、その属性を条件に使っているスクリプトを洗い出しておきます。

決算期の変更に対する設計例

標準の属性を使って、どこまで運用に組めるかを考えます。次は設計の一例で、今回の検証で動かしたものではありません。

想定は、決算期の凍結期間に重なる変更だけ、追加のレビューを求める運用です。

カテゴリは Financial Risk and Compliance を選ぶ。親の Risk and Compliance の属性も、あわせて使える
起票者が Financial Close Period Impact に決算の種別（月次・四半期・年度・外部監査期間）を入れる。該当なしなら No Impact
Potential Financial Loss (USD) に想定の損失額を入れる
リスク条件スクリプトで、Financial Close Period Impact が No Impact でなく、かつ損失額が基準を超えたときにリスクを引き上げる

比較に使う属性は、スクリプトから getDynamicAttributeValue で読めます。選択肢セットの値は、画面の表示ラベルでなく year_end_close や no_impact のような保存値で比べてください。ラベルで比べると、翻訳や表記の変更で条件が崩れます。

基準になる損失額と、追加レビューを担当する人は、組織ごとに決める値です。標準の属性が持つのは判断の材料だけで、基準は持っていません。

リスク計算と組み合わせるときの注意

変更管理には、リスクを計算する既存の仕組みがあります。動的属性を読む条件を足すときは、既存の条件との優先順位を先に確認します。

属性が未入力の変更でも、条件が止まらない書き方にします。未入力のとき getDynamicAttributeValue が何を返すかは今回確かめていません。数値で比べるなら、未入力のときは判定を飛ばすか、入力を必須にする運用と組み合わせます。

運用に載せる前の確認項目

導入前に、次の点を決めておくと迷いません。

標準の14個のうち、使う属性と無効にする属性の仕分け
自社の規制に合わせて足す属性の名前と型。名前は後から変えにくいため、英小文字とアンダースコアで揃える
True/False を条件に使うスクリプトの比較ルール。'1' で比べると決めて、共通の書き方にする
2つのフィールドを載せるビューと、入力する担当者
属性が空のまま承認に進んでよいか。進めてはいけないなら、承認前に埋める手順を入れる

実機を見て気づいたこと

カテゴリの参照キーが sys_id でない

最初、カテゴリを sys_id で指定しました。値は入っても、画面には何も表示されません。ディクショナリの参照キーが namespaced_name だったためです。change_request/risk_and_compliance_attributes/financial_risk_compliance の形で指定すると表示されました。スクリプトでカテゴリを入れるときは、この名前を使います。

公式の API 名のまま呼んでも入らなかった

公式のプラットフォームのページには setDynamicAttributeValues が載っています。しかしオブジェクトを渡す形で呼んだところ、保存結果は {} でした。setValue('<保存フィールド>->属性名', 値) の形で入れると動きました。API 名の一覧と、動く呼び方は別に確かめる必要があります。

定義が無い属性もエラーにならない

存在しない属性名を書いても、エラーは出ません。規制対応の記録として使うなら、フォームに入力欄を用意するか、保存時に属性名を検証する仕組みが要ります。

引用した公式説明を実機で確認する方法

この記事で引用した説明文は、公式ドキュメントと、製品に同梱の属性の説明です。次の URL を自分のインスタンスで開くと、同じ記述を確認できます。

名前空間の一覧：/dynamic_namespace_list.do
属性の一覧：/dynamic_attribute_list.do?sysparm_query=namespace.name=change_request/risk_and_compliance_attributes
カテゴリの一覧：/dynamic_category_list.do?sysparm_query=namespace.name=change_request/risk_and_compliance_attributes
ディクショナリ：/sys_dictionary_list.do?sysparm_query=name=change_request^elementLIKErisk_and_compliance

この機能を選ぶ判断

Compliance dynamic schema を採用するかどうかは、次の問いで決めます。

規制や監査の要求が変わるたびに、変更申請の項目を直しているか。直しているなら、動的属性が向いている
項目ごとに集計や並べ替えを多用するか。プラットフォームの説明では、定義のない（transient）属性は文字列で保存され、検索と並べ替えの選択肢が限られる。定義済みの属性の検索性能や集計上の制約は、今回確かめていない
入力を画面で制御したいか。標準のフォームには出ず、JSON を直接編集する欄になるため、入力の作り込みが要る

上の制限の説明は、定義のない属性についてのものです。規制項目は、名前空間に定義して使うのが前提です。

検証範囲とおことわり

テスト用の変更1件で、標準の属性7個と未定義の属性1個を設定した。ワークフロー、承認、リスク計算との連動は動かしていない
属性の定義名は実機の dynamic_attribute で再照合した（PCI-DSS の定義名は pci_dss_compliant）。未入力の変更を読んだときの戻り値、アップグレード時の影響、定義済み属性の検索性能は確かめていない
一時ビューは削除し、既定ビューは変更していない。テスト用の変更も削除した
リスク条件や Business Rule は永続的には作っていない。条件の例は Scripts - Background での読み取りだけ
一時ビューのテキスト領域で、画面から JSON を直接入力する操作は行っていない
公式ドキュメントにある、Brazil で追加された他の機能がこの項目を読む動きは確認していない