APIやインポートにも効く必須制御（Data Policy）

ServiceNow で「この項目は必ず入れてほしい」を実現する方法は1つではありません。フォーム上で必須にする UI Policy は有名ですが、フォームを通さないインポートや API でデータが入ってくると、UI Policy は効きません。そこで登場するのが、サーバ側でデータを検証する Data Policy です。

この記事では、Data Policy を機能論だけで説明しません。実際の sys_data_policy2（Data Policy）と、その動作1行ぶんを保存する sys_data_policy_rule（Data Policy Rule）を起点にします。Data Policy が何を強制し、どこで効き、UI Policy と何が違うのかを、PDI（Zurich）の OOTB で確認した実測値とともに示します。

この記事は、ServiceNow の Incident や Problem は触ったことがあるが、フォームの裏側（必須・読み取りをどこで強制しているか）をこれから理解したい人を想定しています。実機で確認するときに見るべきポイントは4つです。テーブルの位置づけ、効く範囲、Data Policy Rule の制御項目、そして UI Policy との使い分けです。

この記事で分かること

• Data Policy が サーバ側で必須／読み取りを強制すること（保存時に検証）

• フォームだけでなくインポートセットや Web サービス（API）にも効くこと

• 動作が sys_data_policy_rule に1フィールド＝1レコードで保存されること

• Data Policy Rule が制御できるのは必須（mandatory）と読み取り（disabled）の2種だけで、UI Policy にある「非表示」が無いこと

• enforce_ui（Use as UI Policy on client）でクライアント側にも効かせられること

• 実機で確認するときに見るべき一覧URL

Data Policy とは

Data Policy は、レコードを保存するときにサーバ側で「このフィールドは必須」「このフィールドは読み取り専用」を強制する仕組みです。UI Policy がブラウザのフォーム上で動くのに対し、Data Policy はデータベースへ書き込む直前に検証します。入口がフォームでなくても効くのはそのためです。

• Data Policy（sys_data_policy2） … 「この条件のとき、この対象テーブルのレコードに対して検証する」という本体。対象テーブル（model_table）と適用条件（conditions）を持ちます。

• Data Policy Rule（sys_data_policy_rule） … 「どのフィールドを必須／読み取りにするか」という具体的な動作。1フィールド＝1レコードで、Data Policy にぶら下がります。

ポイントは、Data Policy が条件と対象を持ち、何を強制するかは Data Policy Rule 側に分かれるという分担です。UI Policy（sys_ui_policy）と UI Policy Action（sys_ui_policy_action）の関係とよく似た作りになっています。

2つのテーブルの位置づけ

Data Policy・Data Policy Rule は、いずれも業務データ（problem のようなレコード）ではなく、検証ルールを保存する「設定（メタデータ）」のテーブルです。

今回確認した PDI（Zurich / OOTB）では、2テーブルとも sys_metadata（ラベル: Application File）を直接継承 していました。それぞれの固有フィールド数は、sys_data_policy2 が15、sys_data_policy_rule が6 でした。

ポイントは分担です。Data Policy（sys_data_policy2）が「いつ・どのテーブルで動かすか」を持ちます。その「何をするか」は sys_data_policy_rule 側に sys_data_policy 参照でぶら下がります。1つの Data Policy が複数フィールドを制御する場合、その数だけ Data Policy Rule レコードが並びます。

テーブル定義は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_data_policy2^ORname=sys_data_policy_rule

どこで効くか（サーバ側・複数の入口）

Data Policy の一番の特徴は、効く入口が広いことです。フォーム入力だけを見張る UI Policy と違い、Data Policy はサーバへ届くデータをまとめて検証します。

今回確認した PDI（Zurich / OOTB）では、sys_data_policy2 に2つのフィールドがあります。apply_import_set（Apply to import sets）と apply_soap（Apply to SOAP）です。active な 121 件のうち、いずれも 121 件すべてが true でした。

• apply_import_set=true … インポートセット経由で入ってくるデータにも検証を効かせます。

• apply_soap=true … SOAP / Web サービス経由のデータにも検証を効かせます。

つまり少なくとも今回確認した PDI（Zurich / OOTB）では、Data Policy は「フォーム・インポート・Web サービス」のいずれの入口でも効く設定が標準でした。フォーム上の見た目だけを変える UI Policy では、ここはカバーできません。

https://<YourInstance>/sys_data_policy2_list.do?sysparm_query=active=true

Data Policy の「動作」は Data Policy Rule に保存される

Data Policy の本体（sys_data_policy2）は「いつ・どこで動くか」を持ちます。「何をするか」は Data Policy Rule（sys_data_policy_rule）に 1フィールド＝1レコードで保存されます。

Data Policy Rule の固有フィールドは、わずか6つです。動作を決めるのは mandatory（必須）／disabled（読み取り専用） の2つです。

注意したいのは、mandatory / disabled はどちらも3値（True / False / Leave alone）で、既定は「Leave alone（＝触らない）」という点です。そして、UI Policy Action にある visible（表示／非表示）が Data Policy Rule には無い点も押さえておきたいところです。サーバ側でデータを検証する仕組みなので、「項目を画面から隠す」という概念がそもそもありません。Data Policy が制御できるのは「必須」と「読み取り」の2種だけです。

次の実機画面は、problem の assigned_to を必須にする Data Policy Rule です。Field name が Assigned to、Mandatory が True、Read only は Leave alone。そして UI Policy Action と違い、Visible（表示）の欄が存在しないことが見て取れます。

この Rule の親 Data Policy が次の画面です。Table=Problem、Conditions（State が一致する条件）があります。加えて、Apply to import sets / Apply to SOAP / Use as UI Policy on client がすべて有効になっています。画面下の関連リスト「Data Policy Rules」に assigned_to の行が並んでいます。

画面下に「Convert this to UI Policy」という関連リンクがあるのも特徴で、Data Policy と UI Policy は相互に変換できる関係になっています。

https://<YourInstance>/sys_data_policy_rule_list.do?sysparm_query=sys_data_policy.model_table=problem

UI Policy との違い・使い分け

実機で「項目を必須／読み取りにしたい」とき、まず迷うのが「Data Policy と UI Policy のどちらでやるか」です。両者の違いは次のとおりです。

• Data Policy が向くこと … フォーム・インポート・API のどの入口でも必須／読み取りを強制したいとき。データの整合性を、入口に関係なく担保できます。

• UI Policy が向くこと … フォーム上で表示／非表示も含めて制御したいとき。Data Policy にできない「項目を隠す」は UI Policy の領域です。

両者は排他ではありません。今回確認した PDI（Zurich / OOTB）では、active な Data Policy 121 件がありました。そのうち enforce_ui（Use as UI Policy on client）=true が 108 件（約9割）でした。enforce_ui を有効にすると、その Data Policy はサーバ側に加えてクライアント側でも UI Policy のように動きます。つまり「フォームでも即座に必須表示し、保存時にもサーバで強制する」を1つの設定で両立できます。

なお、コミュニティでは Data Policy が UI Policy より優先される（必須やフィールド検証の強制で先に効く）とよく説明されます。本記事では実機での実行順序の計測まではしていません（詳細は末尾の公式・参考リンクを参照）。

公式の Data policy（Zurich） に、Data Policy がサーバ側でデータを検証し、インポートや Web サービス経由のデータにも適用される仕組みが説明されています。

OOTB の Data Policy はどのテーブルに多いか（実測）

実際に OOTB の Data Policy を数えると、フォームを通さない入口でのデータ整合性が広い範囲で守られていることが分かります。

今回確認した PDI（Zurich / OOTB・active 中心・2026-06-22 確認）では、次の件数でした。

• Data Policy（sys_data_policy2）… 123件（active 121件）。うち enforce_ui=true が 108件、reverse_if_false=true が 104件、inherit=true が 14件でした。

• Data Policy Rule（sys_data_policy_rule）… 252件。うち mandatory=true が 139件、disabled=true（読み取り）が 107件で、「必須にする」用途が「読み取りにする」用途より多い傾向でした。

• 対象テーブルは active 121件で 76 テーブルに分散していました。上位は pa_widgets 9件 / problem 8件 / problem_task 7件で、incident は 1件でした。少なくとも今回の PDI では、Data Policy は Problem 系プロセスでよく使われていました。

次の実機画面は、problem テーブルに紐づく Data Policy の一覧（8件）です。Apply to import sets / Apply to SOAP / Use as UI Policy on client がいずれも true で並んでいる様子が確認できます。

https://<YourInstance>/sys_data_policy2_list.do?sysparm_query=model_table=problem^active=true

参考として、UI Policy 側は active な sys_ui_policy が 2,842件でした。その動作を持つ sys_ui_policy_action は全体で 5,055件あり、うち visible=false（非表示）が 2,013件 ありました。この「非表示 2,013件」は Data Policy Rule では構造的に持てない（visible フィールドが無い）ため、両者の役割分担が件数からも見て取れます。

注意したいのは、ここで数えているのは OOTB の Data Policy だという点です。実環境では業務要件に応じて Data Policy が追加され、件数・対象テーブルは変わります。

ServiceNow の Data Policy のポイント

• Data Policy は サーバ側でデータを検証し、保存時に必須／読み取りを強制します。フォームだけを見張る UI Policy と、効く場所が違います。

• フォーム・インポートセット・Web サービス（API）のいずれの入口でも効くのが Data Policy の強みです。OOTB では apply_import_set / apply_soap が標準で有効でした。

• Data Policy の「何をするか」は sys_data_policy_rule に1フィールド＝1レコードで保存されます。mandatory / disabled（既定は Leave alone）で制御します。visible（非表示）は持てません。

• enforce_ui（Use as UI Policy on client）を有効にすると、サーバ側に加えてクライアント側でも UI Policy のように動きます。OOTB の active 121件中 108件が有効でした。

• 今回の PDI では Data Policy 123件・Data Policy Rule 252件があり、76テーブルに分散していました（Problem 系が中心）。

項目の必須・読み取りを設計するときは、まず「フォーム入力だけ守れば十分か、それともインポートや API も守りたいか」を切り分けます。入口を問わず守りたいなら Data Policy（必要なら enforce_ui でクライアントにも）、表示も含めてフォームを整えたいなら UI Policy、という順で考えると分かりやすくなります。

実機で気づいたこと

• apply_import_set と apply_soap は、今回の PDI で active な121件すべてが true でした。個別にオンオフできる設計なのに、実際には誰も外していません。フォームの必須制御を作るときにインポートや API 側だけ緩める、というような使い分けは、少なくとも今回の OOTB データでは見当たりませんでした。Data Policy を新規作成するとき、この2つのチェックボックスは触らずに標準のまま使うのが実質の既定の振る舞いなのだと分かりました。

• Data Policy が一番多く紐づいていたテーブルは incident ではなく pa_widgets（Performance Analytics のウィジェット）で9件、次いで problem が8件でした。最初は Incident の必須項目チェックが中心だろうと予想していたので、incident がわずか1件だったのは意外でした。ITSM のコア業務よりも、ダッシュボード部品の設定データを守る用途で Data Policy が使われている場面のほうが、今回の OOTB では目立っていました。

• Data Policy Rule 252件の内訳は、必須にする（mandatory）が139件、読み取り専用にする（disabled）が107件で、必須のほうが多いものの差はそれほど大きくありませんでした。フォーム側の UI Policy だと表示を切り替える使い方も多い印象がありますが、Data Policy には非表示という選択肢がそもそも無いぶん、必須と読み取りの2つにきれいに寄っている数字になったのだと思います。

次に読むなら

次に確認したいのは3点です。1つは Data Policy と UI Policy の実行順序（保存時にどちらが先に効き、どちらの指定が最終的に勝つか）です。もう1つは Convert this to UI Policy / Data Policy による相互変換の挙動、そして Data Policy がエラーを返したときのメッセージ表示です。とくに「フォームでは UI Policy、保存時には Data Policy のどちらの指定が効くか」は、実環境のトラブルで頻出します。これらは本記事の「使い分け」「enforce_ui」で触れた仕組みの先にあたり、別記事で扱う予定です。

用語

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

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

• Data Policy：保存時にサーバ側で必須／読み取りを強制する設定（sys_data_policy2）

• Data Policy Rule：Data Policy の具体的な動作1行（sys_data_policy_rule）

• enforce_ui（Use as UI Policy on client）：その Data Policy をクライアント側でも UI Policy のように効かせる設定

• Leave alone（ignore）：mandatory / disabled で「その制御は触らない」を表す既定値

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

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

テーブル定義     : sys_db_object_list.do?sysparm_query=name=sys_data_policy2^ORname=sys_data_policy_rule
Data Policy      : sys_data_policy2_list.do?sysparm_query=active=true
Data Policy（problem）: sys_data_policy2_list.do?sysparm_query=model_table=problem^active=true
Data Policy Rule : sys_data_policy_rule_list.do?sysparm_query=sys_data_policy.model_table=problem
固有フィールド    : sys_dictionary_list.do?sysparm_query=name=sys_data_policy_rule^elementISNOTEMPTY

テーブルの基本

• sys_data_policy2（Data Policy）… super_class=sys_metadata（Application File）／固有フィールド15

• sys_data_policy_rule（Data Policy Rule）… super_class=sys_metadata／固有フィールド6

Data Policy Rule の制御フィールド（値）

mandatory（必須）／ disabled（読み取り専用）… いずれも True / False / Leave alone（既定 Leave alone）。visible は存在しない（UI Policy Action との違い）。

件数（Data Policy・OOTB・2026-06-22確認）

• Data Policy（sys_data_policy2）… 123

• active=true 121 / enforce_ui=true 108 / reverse_if_false=true 104

• inherit=true 14 / apply_import_set=true 121 / apply_soap=true 121

• Data Policy Rule（sys_data_policy_rule）… 252（mandatory=true 139 / disabled=true 107）

• 対象テーブル（active 121件）… 76種に分散

• pa_widgets 9 / problem 8 / problem_task 7 / sys_app_template 5 / incident 1 など

件数（UI Policy 側・参考・2026-06-22確認）

• sys_ui_policy（active=true）… 2,842

• sys_ui_policy_action（全件）… 5,055（うち visible=false 2,013 … Data Policy Rule には visible が無い）

sys_data_policy2 / sys_data_policy_rule の固有フィールド（検索用）

• sys_data_policy2（1）：model_table, conditions, active, enforce_ui

• sys_data_policy2（2）：reverse_if_false, inherit, apply_import_set, apply_soap

• sys_data_policy2（3）：short_description, description, model_id, sys_overrides

• sys_data_policy2（4）：sys_domain, sys_domain_path, sys_id

• sys_data_policy_rule：sys_data_policy, field, mandatory, disabled, table, sys_id

関連テーブル（検索用）

• sys_metadata（Application File・基底）

• sys_ui_policy（UI Policy・クライアント側）

• sys_ui_policy_action（UI Policy Action・visible あり）

• sys_dictionary（フィールド定義）

• sys_choice（選択肢）

• sys_security_acl（権限・サーバ側のもう1つの制御）

検証範囲とおことわり

確認した範囲（すべて PDI／Zurich／2026-06-22 確認の OOTB で取得）:

• 2テーブルの継承（いずれも sys_metadata=Application File 直下）

• 固有フィールド数（sys_data_policy2 15 / sys_data_policy_rule 6）

• Data Policy Rule の制御2種（mandatory / disabled、visible が無いこと）

• mandatory / disabled の値（True / False / Leave alone）

• enforce_ui / apply_import_set / apply_soap / reverse_if_false / inherit の件数

• 対象テーブル分布

• Data Policy / Rule の総件数

• スクショ対象レコードの実値

確認していない範囲（断定しません。これらは別記事で扱います）:

• Data Policy と UI Policy の厳密な実行優先順位（コミュニティでは Data Policy 優先とされますが、実機計測はしていません）

• サーバ側でエラーになったときの実際のメッセージ表示

• Convert（UI Policy ⇄ Data Policy 相互変換）の挙動

• 各レコードの conditions が実際に評価される様子

• ドメイン分離環境での適用範囲