ServiceNowで項目が画面に出ないのはなぜ？ ビュー・UI Policy・ACLを順番に切り分ける
「さっきまであった項目が消えている」「他の人には出ているのに自分の画面には出ない」。この相談を受けたとき、原因の候補は1つではありません。フォームレイアウト・ACL・UI Policyなど、項目を消しうる仕組みは複数にまたがっていて、しかも管理画面がテーブルごとに分かれているため、1つずつ開いて確認するだけでも時間がかかります。Zurich PDIで各仕組みの設定件数を実機で数え、確認する順番を1本にまとめました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：項目が出ない原因は7つの仕組みのどれか
先に全体像です。
項目が画面から消える経路は7つの仕組みに分かれます。フォームレイアウト（sys_ui_element）・ACL（sys_security_acl）・セクション（sys_ui_section）・UI Policy Action（sys_ui_policy_action）・UI Policy（sys_ui_policy）・ビュー（sys_ui_view）・辞書の上書き（sys_dictionary_override）です。原因は必ずこのどれかにあります。
確認はコストの低い順に進めます。他のユーザーでも出ないかを最初に見て、そこから先はビュー・レイアウト・UI Policy・ACL・辞書の上書きへと進みます。いきなりACLの条件式を読みに行く必要はありません。
UI Policy Actionの約4割（5,102件中2,036件）が「Visible」を操作する設定でした。項目を意図的に隠す設定は、珍しいものではありません。内訳は明確でした。
他のユーザーでも同じ現象が起きているかどうかで、まず個人の権限側を疑うか、全体の設定側を疑うかが分かれます。全体側であれば、費用の小さい確認から始めるのが近道です。図の色は確認コストの大きさに対応しています。濃紺は最初に見る箇所、緑はすぐ直せる層です。橙は影響が広く慎重に扱う層、赤は原因が確定した状態を示します。
7つの仕組みの件数は上の表のとおりです。フォームレイアウトの67,342件が最大ですが、これは全テーブル・全項目の配置記録を合算した数です。1つのテーブルに絞れば数百件程度になります。
まず他のユーザーでも出ないかを確認する
最初に確認するのは、設定を開く前の1問です。同じレコードを別のユーザーが開いたとき、その項目は出ているでしょうか。
自分だけに出ないのであれば、原因は個人のロールやグループに寄っている可能性が高くなります。全員に出ないのであれば、フォーム側の設定を疑う番です。この1問だけで、確認すべき範囲がおよそ半分に絞れます。問い合わせを受けたときも、最初に聞くべき質問はこれです。
手間はかかりません。
別のビューを見ていないか（sys_ui_view）
全員に出ないと分かったら、次はビューです。ServiceNowでは同じレコードでも、開いているビューによって並ぶ項目が変わります。
sys_ui_viewには707件のビューが登録されていました。Default view・Mobile・Self Serviceのような一般的な名前だけでなく、accept_risk_dialog_form_viewのように特定の1画面専用のビューも混ざっています。URLの末尾にsysparm_view=が付いていないか、ナビゲーションのビュー切り替えメニューが既定と違う状態になっていないかは、レイアウトを開く前に見ておく価値があります。
ビューを疑う理由は単純です。管理者用のビューに出ている項目が、モバイル用やセルフサービス用のビューには存在しないという設計は、ServiceNowでよく見られます。公式のCreate a view ruleには、デバイスや条件によって表示するビューを自動で切り替える仕組みが説明されています。切り替えのルールを知らないまま項目を探すと、レイアウトをどれだけ調べても見つかりません。
そもそも項目はフォームに配置されているか（sys_ui_element）
ビューが正しいと分かったら、次はレイアウトです。項目がそのフォームに配置されていなければ、権限がどれだけ緩くても表示されません。
sys_ui_element（フォームのセクションに項目を並べる設定）は67,342件ありました。incidentテーブルに絞ると355件です。上の画面は「どのセクションに、どの項目が、何番目に並ぶか」を示す一覧で、Resolution・Cause・Related Recordsのようなセクション名ごとに項目がまとまっています。
セクションを管理するテーブルはsys_ui_sectionで、6,473件登録されていました。1つのセクションが複数の項目を抱える構造のため、セクション数よりレイアウト行数の方がはるかに多くなります。「項目が出ない」という相談の中には、レイアウトに一度も追加されていないという単純な理由も一定数含まれます。フォームのパーソナライズやレイアウトの編集画面を開き、項目が候補リストに残っているかを見るのが、この段階の確認です。
見落としやすいのが、辞書（sys_dictionary）に項目が存在することと、その項目がフォームに置かれていることは別だという点です。テーブルの設計時に項目だけ用意して、フォームへの追加を後回しにするケースは珍しくありません。「フィールドはあるのに画面に出ない」という相談を受けたら、まずこの区別を確認しておくと、レイアウトと辞書のどちらを直すべきかで迷わずに済みます。
UI Policyが項目を隠していないか
レイアウトに項目があるのに出ない場合、次に疑うのはUI Policyです。条件によって項目の表示・必須・読み取り専用を切り替える仕組みで、ノーコードで設定できます。
UI Policy Actionの「Visible」欄が何をするか
sys_ui_policy_actionのフォームには、Visible・Mandatory・Read onlyという3つのプルダウンが並びます。既定値は「Leave alone」で、これは何もしないという意味です。ここを「True」または「False」に変えると、そのUI Policyの条件が成立したときに、項目の表示状態が切り替わります。公式のUI policiesには、条件（Conditions）・On load・Reverse if falseの意味が説明されています。仕組みそのものは単純です。
実際にどれくらいの項目が隠されているか
Visibleをfalseに設定したUI Policy Actionを数えると2,036件でした。sys_ui_policy_action全体（5,102件）の4割に当たります。Read onlyやMandatoryを操作する設定より、Visibleを操作する設定の方が多いという結果です。項目を隠す設定は、フォームの作り方として広く使われている一般的な手法です。
sys_ui_policy本体は2,909件でした。1つのUI Policyが複数のUI Policy Actionを持てるため、UI Policy Actionの件数（5,102件）の方が多くなります。1つの条件に対して複数の項目のVisibleやMandatoryをまとめて切り替える設定が多いことが、この件数比から読み取れます。
UI PolicyのフォームにはOrderという項目もあります。同じ項目を複数のUI Policyが対象にしている場合、この番号が小さいものから順に評価される仕組みです。1つの項目に対して「表示する」設定と「非表示にする」設定が両方存在すると、最終的にどちらが勝つかはOrderの並びで決まります。項目が消えている原因を探すときは、対象のUI Policyが1件だけとは限らない前提で見た方が安全です。
ACLのreadで消えていないか
UI Policyに該当する設定が見当たらない場合、次はACLです。UI Policyがフォーム側の見た目を切り替える仕組みであるのに対して、ACLはサーバー側でデータそのものを渡すかどうかを決める仕組みです。ACLのreadが通っていなければ、UI PolicyのVisibleがどんな設定でも項目は出ません。
sys_security_aclは43,744件登録されていました。Operationでグループ化すると、readが8,029件、writeが8,095件、createが6,089件です。読み取りだけを対象にしたACLが8千件を超えており、フィールド単位のACLもここに含まれます。テーブル単位のACLが通っていても、フィールド単位のACLだけが個別に読み取りを制限している場合があり、この見分けにはACLのType列を見る必要があります。裏付けは件数でした。
ACLの新規作成フォームを開くと、Type・Operation・Decision Typeという3つの項目が並びます。Typeがrecord（テーブル単位）かfield（フィールド単位）かで、確認する対象が変わります。今回の43,744件のうち、Typeがrecordのものは41,497件でした。残りの2,247件がフィールド単位のACLで、特定の項目だけを狙って読み取りを制限できるのはこちらです。
フォームの下にはRequires roleという欄と、Security Attribute Conditionという欄が並んでいます。ロールだけで判定するACLもあれば、スクリプトによる条件（Script欄）やセキュリティ属性で判定するACLも存在します。「ロールは付いているのに読めない」という相談では、ロール以外のこの2つの条件を見落としがちです。
継承先のテーブルで辞書が上書きされていないか
ここまでの5段階で原因が見つからないときに残るのが、辞書の上書きです。頻度は高くありませんが、見落とすと長時間探すことになります。件数はわずかです。
sys_dictionary_overrideには404件登録されていました。ServiceNowのテーブルはtaskをincidentやproblemが継承するように親子関係を持っており、この仕組みを使うと、親テーブルの定義を子テーブルだけで上書きできます。Reference qualifierやDefault valueだけでなく、項目の属性を子テーブル側だけ変えることも可能です。公式のSystem Dictionaryに、辞書がテーブルとフィールドの定義そのものであることが説明されています。
件数は7つの仕組みの中で最も少ないものの、親テーブルの辞書だけを見て設定は合っていると判断すると、子テーブル側の上書きを見落とします。継承関係にあるテーブルで発生した現象は、最後にここを確認しておくと安心です。
実機で気づいたこと
sys_ui_elementの67,342件を見たとき、最初はフォーム1枚あたりの項目数がとても多い数字に見えました。実際にincidentテーブルだけで絞ると355件です。全テーブル分を合算した数字と、1つのフォームで目にする数字とでは、桁がまったく違います。件数だけを見て多すぎると判断する前に、対象を1テーブルに絞り込む作業が要ります。
答えは近くにありました。
もう1つ意外だったのが、UI Policy Actionの内訳です。Read onlyやMandatoryを操作する設定より、Visibleを操作する設定（2,036件）の方が多い結果でした。必須にする、読み取り専用にするという操作より、そもそも見せる・見せないを切り替える操作の方が、フォーム設計では頻繁に使われているようです。項目が消えているという相談を受けたとき、UI Policyをまず疑う理由はここにあります。
ACLの内訳も、想像していた形と少し違いました。Operation別ではcreateが6,089件、readが8,029件、writeが8,095件という並びです。read単独のACLより、write・createの方がわずかに多い結果でした。読み取りより書き込み・作成側の制御に、細かいACLが積み重なっている印象を持ちました。
もう1つ目に留まったのが、ACLフォームのAdmin overridesという項目です。新規作成の時点でチェックが入った状態が既定でした。管理者ロールならこのACLを無視してよい、という前提が最初から組み込まれていることになります。裏を返すと、このチェックを外したACLだけは管理者でも通れません。運用中の障害調査で「管理者でも見えない」という珍しい相談を受けたら、この項目を疑う価値があります。
ビューの一覧で目についたのが、UserとGroup列でした。707件のほとんどでこの2列が空欄です。特定の1人やグループのためだけに作られた専用ビューより、Name・Title・Hiddenだけで管理する共通のビューの方が主流だという状態でした。ビューを疑うときは、誰か1人のための特別なビューを探すより、そのテーブル全体で使われている名前をたどった方が早く見つかります。件数を数えるだけで、確認の勘所が見えてきます。
実務では何に使えるか：問い合わせを受けたときの確認順
「あの項目が見えないのですが」という問い合わせを受けたとき、自分は上の表の順に当たりを付けます。最後まで辿り着いても6ステップで収まります。
いきなりスクリプトやACLの条件式を読みに行くと、時間がかかります。ビューとレイアウトの確認はどちらもクリック数回で終わり、UI Policyの確認も対象のUI Policy Actionを1件開くだけです。ACLはフィールド単位の設定を探す分だけ手間が増え、辞書の上書きは継承関係を辿る分だけさらに手間が増えます。手前の段階で解決する相談の方が多いというのが、件数を見ての実感です。
チームに手順を引き継ぐときも、この6段階をそのままチェックリストにできます。ビューを見た、レイアウトを見たと1つずつ消していけば、どこまで調査したかが誰の目にも分かる状態になります。
さらに詳しく知りたい人へ
ロールを付けたのに見えない理由：ACL（sys_security_acl） — ACLの構造とテーブル単位・フィールド単位の違いを詳しく見る
同じレコードで見え方が変わる：ビュー（sys_ui_view） — ビューが切り替わる仕組みをsysrule_viewまで含めて追う
Client ScriptとUI Policyの違い（フォーム挙動） — UI Policyとよく比較されるClient Scriptとの使い分け
よくある質問
Q1. まずどこから確認すればいいですか
他のユーザーでも同じ項目が出ないかどうかです。自分だけに出ない現象であれば、原因は個人のロールやグループに寄っている可能性が高く、全体設定の調査に時間を使う前に権限の割り当てを確認した方が早く解決します。
Q2. 他のユーザーには出ているのに自分にだけ出ない場合は？
この場合は個人に紐づくロール・グループ・ACLの割り当てを疑う番です。フォーム側の設定を直しても解決しません。同じロールを持つ別のユーザーと比較し、グループ経由で付与されるロールに差がないかを確認します。この記事で扱った6段階の外側に原因がある状態です。
Q3. UI PolicyとACLはどちらを先に疑えばいいですか
UI Policyはフォームがすでにデータを受け取った後で、表示状態を切り替える仕組みです。ACLはそのデータをブラウザに渡すかどうかをサーバー側で決める仕組みです。ACLのreadが通っていなければ、UI PolicyのVisibleがどんな設定でも項目は出ません。設定を追加した順番ではなく、この役割の違いで先に確認する側を決めます。この記事の順番でUI Policyを先に置いているのは、確認にかかる手間がACLより小さいからで、優先度そのものが高いという意味ではありません。
Q4. ビューを切り替えても直らない場合は
ビューが原因ではなかったことになるので、次はフォームレイアウト（sys_ui_element）に進みます。パーソナライズやレイアウトの編集画面を開き、対象の項目が候補リストに残っているか、すでにフォームへ追加されているかを確認します。
Q5. 辞書の上書き（sys_dictionary_override）とは何が違うのですか
sys_dictionaryが項目そのものの定義で、sys_dictionary_overrideは継承先のテーブルだけでその定義を変える上書きです。親テーブルの辞書を見て設定は合っていると判断しても、子テーブル側の上書きで属性が変わっている場合があります。task・incident・problemのように継承関係が深いテーブルほど、この上書きを見落としやすくなります。404件という数の少なさが、かえって見落としの原因です。
まとめ
ServiceNowで項目が画面から消える経路は、結論で示した7つの仕組みのどれかです。件数は表で示したとおり、フォームレイアウトが最大でACL・セクションが続き、辞書の上書きが最少でした。規模の差はあっても、原因は必ずこの中にあります。
確認はここまで示した6段階の順で進めると、無駄なく絞り込めます。UI Policy Actionの4割がVisibleを操作する設定だったように、項目を隠す設定は珍しいものではありません。読み取りACLも8,029件あり、権限側で消えている可能性も低くありません。
原因を探す作業は、候補を1つずつ潰す地道な作業です。UI PolicyのOrder、ACLのRequires role、辞書の継承といった細部まで見る癖をつけておくと、次に同じ相談を受けたときも迷わず動けます。
迷ったら、まずこの図に戻ります。
用語
sys_ui_view … フォームの表示パターン（ビュー）を定義するテーブル
sys_ui_element … フォームのセクションに項目を並べる配置記録
sys_ui_section … フォームを区切るセクションの定義
sys_ui_policy / sys_ui_policy_action … 条件によって項目の表示・必須・読み取り専用を切り替える設定
sys_security_acl … テーブル・フィールド単位の読み書き権限を定義するルール
sys_dictionary_override … 継承先のテーブルだけで辞書の定義を上書きする設定
実機で調べるときに開いたURL
/sys_ui_view_list.do … ビュー一覧
/sys_ui_element_list.do?sysparm_query=sys_ui_section.name=incident … incidentのフォームレイアウト
/sys_ui_policy_action_list.do?sysparm_query=visible=false … Visibleがfalseの一覧
/sys_security_acl_list.do?sysparm_query=GROUPBYoperation … ACLのOperation別集計
/sys_dictionary_override_list.do … 辞書の上書き一覧
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で2026-08-08に確認したものです。一覧画面の件数表示と実レコードを突き合わせて数えており、推定やサンプリングではありません。本番環境やカスタマイズ済みの環境では数値が異なります。
実際に項目を隠して再現させる操作は行っていません。設定の件数と所在を確認するところまでにとどめています。ACLの評価順序や実行時の詳しい挙動、Client Scriptによる動的な出し分けは、今回の検証範囲の外です。Next Experience・Workspace系UIでの違いも扱っていません。
