ビューは2段構えで決まる（sysrule_view）
ServiceNow のフォームを開くと、状況によって項目の並びが違うことがあります。同じ incident でも、担当者が開くときと、モバイルで開くときで、見える項目が変わる。この「見え方の型」を ビュー（View） と呼びます。そして、そのビューを状況に応じて自動で選ぶ仕組みが、今回の主役 View Rule（ビュールール、テーブル名 sysrule_view） です。
ビューそのものについては、別記事「同じレコードで見え方が変わる：ビュー（sys_ui_view）」で扱いました。ビューが「並びの型」なら、View Rule は「どの型を出すか」を決める交通整理の役です。管理者が毎回ビューを切り替えなくても、条件に合えば適切なビューが自動で選ばれる。地味ですが、フォームの使い勝手に直結する設定です。
この記事では、PDI（無料の個人検証環境）に最初から入っている 156 件の View Rule を実測し、「何を材料に、どうビューを選んでいるのか」を読み解きます。設定を1つも変えず、読み取りだけで、仕組みの骨格が見えてきます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-20）。本番環境では設定が異なります。
ビューと View Rule は別物
まず、よく混同される2つを分けておきます。ビュー（sys_ui_view） は、フォームやリストに並ぶ項目の集合と順番、いわば「レイアウトの型紙」です。Default、ESS、Self Service など、名前を付けて複数持てます。
一方の View Rule（sysrule_view） は、その型紙のどれを使うかを、状況に応じて自動で決めるルールです。レイアウトそのものは持ちません。あくまで「この状況ならこのビュー」という対応づけを保持しています。
この分担を押さえると、後の話が読みやすくなります。ビューが名詞なら、View Rule は動詞に近い。型紙を用意するのがビューの仕事で、その型紙を選び出すのが View Rule の仕事、という関係です。
なぜ自動で切り替えたいのか
手動でビューを切り替えることもできます。フォーム右上のメニューから View を選べば、その場で並びが変わる。ただ、それを利用者全員に毎回お願いするのは現実的ではありません。
たとえばモバイルで開いたときは、画面が狭いので項目を絞りたい。特定のタイプのレコードだけ、専用の並びで見せたい。こうした要望を、利用者の操作に頼らず、システム側で吸収するのが View Rule です。開いた瞬間に、状況を見て、ふさわしいビューへ寄せてくれます。
結果として、利用者は「自分が何のビューを選ぶか」を意識しなくて済みます。正しい並びが最初から出てくる。その判定を担っているのが View Rule です。
身近な例で考えます。あるチームは、簡易な入力画面で新規登録したい。別のチームは、同じテーブルを全項目そろった詳細画面で扱いたい。ビューを2つ用意し、それぞれに合う条件で View Rule を書けば、開く人や状況ごとに、ふさわしい画面が出ます。1つのテーブルを、複数の見せ方で運用できる。この土台を支えているのが View Rule です。
判定に使う3つの材料
View Rule が「どのビューを出すか」を決めるとき、主に3つの材料を見ます。対象テーブル（table）、条件（condition）、デバイス種別（device_type）の3つです。
対象テーブルは「どのテーブルのフォームやリストに効かせるか」。条件は「どんな中身のレコードのときに効かせるか」を条件ビルダーで書きます。デバイス種別は Browser / Mobile / Tablet の3択で、開いている端末の種類に応じて出し分けられます。
この3つの掛け合わせで、1本のルールが成立します。たとえば「asmt_metric テーブルを、評価方式が assessment のとき、Mobile で開いたら、assessment ビューにする」といった具合です。主な項目を早見表にまとめました。
条件欄には、参照先の項目までたどって書けます。実測したルールの中には、category.qb_evaluation_method=assessment のように、ドット記法で参照先テーブルの値を見ているものがありました。つまり「このレコードの参照先が、こういう値のとき」という一段深い条件も書けます。単純なフラグだけでなく、関連レコードの状態でビューを選べる、という柔軟さです。
補足として Match conditions があります。条件を複数書いたとき、その全部に合致（All）で発火するか、どれか1つ（Any）で発火するかの切り替えです。PDI の有効な 155 件は、すべて All でした。Any の既製ルールは1件もありません。複数条件を「かつ」でつなぐのが標準の作り、と読み取れます。
実機の一覧を開く
実際の一覧を見てみます。System UI の View Rules（sysrule_view_list.do）を、有効なものだけ、テーブル順で並べた画面です。
Name、Conditions、Device type、Table といった列が並びます。たとえば「AIS dictionary autocomplete」という行を見てみます。Conditions は type=AUTOCOMPLETE^derived=true、Device type は Browser、Table は AI Search Dictionary（ais_dictionary）です。1行が1つの「状況とビューの対応」を表しています。読み方さえ分かれば、一覧を眺めるだけで、そのインスタンスがどんな出し分けを持っているかが見えてきます。
数を実測すると、有効な View Rule は 155 件（無効が1件で総数 156 件）ありました。対象になっているテーブルは 65 種類。ITSM の incident のような業務テーブルだけでなく、辞書やアセスメント指標といった裏側のテーブルにも、細かくビューの出し分けが設定されています。OOTB の時点で、これだけの数が動いているわけです。
デバイス種別の内訳も見えました。Browser が 115 件、Tablet が 23 件、Mobile が 17 件。多くはブラウザ向けですが、モバイルやタブレット専用のルールも一定数あります。端末ごとに見せ方を変える発想が、標準設定にも織り込まれています。
65 種類という対象テーブルの広がりも、少し立ち止まる価値があります。1つのテーブルに何本ものルールがぶら下がっているものもあれば、1本だけのものもある。たとえば辞書系（ais_dictionary）は種類ごとに複数、アセスメント指標（asmt_metric）はデバイスごとに複数、という具合です。View Rule の総数がテーブル数より多いのは、こうして1テーブルに複数のルールが重なっているからです。どのルールが先に合致するか、という順序も、実務では効いてきます。
判定の流れを1枚で
材料が分かったところで、開いてから表示までの流れを1枚にまとめます。
利用者がレコードを開くと、まず「そのテーブルに View Rule があるか」を見ます。無ければ Default ビューでそのまま表示。あれば、条件とデバイス種別に合致するかを判定します。合致すれば、ルールの view に指定されたビューを選び、その並びでフォームを描く。合致しなければ、やはり Default に戻ります。
つまり View Rule は「合致したときだけ差し込まれる」仕組みです。普段は Default が出て、特定の状況でだけ別のビューへ寄せる。この控えめな効き方が、利用者に余計な混乱を与えない工夫になっています。
具体例1：辞書の種類でビューを切り替える
抽象論だけでは掴みにくいので、実測した具体例を見ます。AI Search の辞書テーブル（ais_dictionary）には、条件でビューを切り替えるルールが複数ありました。
type=AUTOCOMPLETE のとき → Autocomplete ビュー
type=SPELLCHECK のとき → Spellcheck ビュー
type=SYNONYM のとき → Synonym ビュー
同じ ais_dictionary というテーブルでも、レコードの type の値に応じて、出すビューが変わります。オートコンプリート用の辞書エントリと、スペルチェック用の辞書エントリでは、編集したい項目が違う。だから、種類ごとに専用の並びを用意し、条件で振り分けています。
sys_dictionary（辞書＝各テーブルの項目定義）にも似た例があります。「Advanced dictionary entries」というルールは、仮想項目などの条件に合うレコードを advanced ビューで開きます。普通の項目定義より詳しい設定を触るときだけ、詳細な並びに切り替わる、という設計です。条件に「レコードの中身」を書けるからこそ、こういう細やかな出し分けができます。
具体例2：同じ画面をデバイスで分ける
もう1つ、デバイス種別を使う例です。アセスメント指標（asmt_metric）には、同じビュー名でもデバイス違いのルールがそろっていました。
表の中ほど、「Assessment metric - browser」と「Assessment metric - mobile」を見てください。どちらも assessment というビューを出しますが、片方は Browser 用、もう片方は Mobile 用です。同じ並びをそれぞれの端末に効かせるために、デバイスごとに1本ずつルールを分けています。attestation ビューには Tablet 用のルールもありました。
なぜ分けるのか。デバイス種別は1本のルールにつき1つしか指定できないからです。Browser と Mobile の両方で効かせたいなら、条件が同じでもルールを2本用意します。一見すると冗長ですが、「この端末のときだけ効かせる／効かせない」を後から細かく調整しやすい、という利点があります。端末ごとに独立して有効・無効を切り替えられるわけです。
条件式とスクリプト、2通りの書き方
ここまでは条件ビルダー（Conditions 欄）でビューを選ぶ話でした。View Rule には、もう1つの書き方があります。Advanced というチェックボックスをオンにすると、条件式の代わりに スクリプト でビューを決められます。
実測すると、有効な 155 件のうち 23 件が Advanced（スクリプト式）でした。残りの 132 件は条件ビルダー式です。スクリプト式のルールを開くと、こんな雛形が入っています。
(function overrideView(view, is_list) {
// Add your code here
answer = null; // set the new view to answer
})(view, is_list);answer という変数に、出したいビューの Name を代入すると、そのビューへ切り替わります。条件ビルダーでは書けない複雑なロジック（複数テーブルをまたぐ判定や、動的な組み立て）が必要なときに使う逃げ道です。「ML View(browser)」のような機械学習系のルールが、この方式で作られていました。
普段の出し分けは条件ビルダーでほぼ足ります。条件式で表現しきれない場面だけ、Advanced に切り替えてスクリプトを書く。まずは条件ビルダー、難しければスクリプト、という順で考えると迷いません。
ユーザーの好みを上書きするか
もう1つ、実務で効いてくる項目があります。Overrides user preference（ユーザーの好みを上書き） です。
利用者が手動でビューを切り替えると、その選択は「好み」として保存されます。次に同じフォームを開くと、前に選んだビューが出る。ここで View Rule が発火したとき、その保存済みの好みを上書きしてルールのビューを強制するか、それとも利用者の好みを尊重するかを、この項目が決めます。
実測では、有効な 155 件のうち 145 件が「上書きする（オン）」でした。オフは 10 件だけ。標準の考え方は「ルールが条件に合致したら、利用者の好みより優先する」と読み取れます。裏を返せば、View Rule で強制したビューは、利用者が個別に選んだ並びよりも基本は強い、ということです。もし「利用者が選んだビューを残したい」場面があれば、この項目をオフにして例外を作れます。
View Rule が無いとどうなるか
逆に、あるテーブルに合致する View Rule が1つも無いとどうなるか。答えはシンプルで、Default ビューがそのまま出ます。
View Rule は「合致したときだけ差し込まれる」ので、該当が無ければ何も起きません。フォームは既定の並びで表示され、利用者が手動で別のビューを選んでいれば、その好みが使われます。つまり View Rule は、既定の動きを壊さずに、特定の状況だけを上書きする追加レイヤーだと捉えると分かりやすい。
この性質のおかげで、View Rule を1本足しても、他の画面には影響しません。効かせたいテーブルと条件を絞って書けば、その範囲だけが変わる。副作用の小ささが、こまめな出し分けを支えています。
フォームだけでなくリストにも
View Rule は、フォームだけの仕組みではありません。リスト（一覧画面）にも同じ考え方が効きます。スクリプト式の雛形は overrideView(view, is_list) という形でした。この is_list が、いま判定しようとしているのがフォームなのかリストなのかを示す目印です。
つまり同じ View Rule の枠組みで、「フォームを開いたときの並び」と「リストで一覧したときの列」を、状況に応じて選べます。フォームとリストでは見たい情報が違うことが多い。1件を詳しく見るフォームでは項目を厚く、たくさん並べるリストでは列を絞る、といった出し分けが、View Rule の同じ仕組みの上に乗っています。
実務では、フォームの見え方だけに気を取られがちです。狙ったビューがリストで出ないときは、リスト側の条件やデバイス種別も合わせて確認すると、原因にたどり着きやすくなります。フォームとリストは別々に判定される、と頭の片隅に置いておくと安心です。
実務での読み解き方
最後に、実務でこの一覧をどう使うかを添えておきます。「このフォーム、なぜこの並びで出るんだろう」と思ったら、まず対象テーブルの View Rule を疑うのが近道です。
sysrule_view_list.do を開き、Table 列で対象テーブルを絞る。合致するルールがあれば、その Conditions と Device type を読めば、どんな状況でそのビューが選ばれるかが分かります。逆に、狙ったビューが出ないときは、原因を順に確かめます。まず条件に合っているか。次にデバイス種別が一致しているか。最後に、別のルールが先に合致していないかを見ます。この3点を1つずつ潰していくと、たいていの「なぜこのビュー」は説明がつきます。ここで注意したいのは、ロールを持たない利用者には View Rule が効かない、という前提です。権限まわりの挙動は公式ドキュメントにも記載があります。
ビューを作っただけでは、それが自動で出るわけではありません。ビュー（型紙）を用意し、View Rule（選ぶルール）で状況に結びつける。この2段構えを知っていると、「見え方」まわりのトラブルを落ち着いて切り分けられます。
その他、実機で確認した記録
用語
ビュー（sys_ui_view） … フォーム/リストの項目の並びの型。Default など名前付きで複数持てる
View Rule（sysrule_view） … 状況に応じてどのビューを出すかを自動判定するルール
device_type … ルールを効かせる端末種別。Browser / Mobile / Tablet の3択
Match conditions … 条件の合致方式。All（全条件）/ Any（いずれか）
Advanced … 条件式の代わりにスクリプトでビューを決める書き方
Overrides user preference … 利用者が手動で選んだビューより、ルールを優先するか
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sysrule_view_list.do（View Rule の一覧）
/sysrule_view_list.do?sysparm_query=active=true^ORDERBYtable（有効のみ・テーブル順）
/sys_ui_view_list.do（ビュー本体の一覧）
実測の要点（再掲）
総数 156 件（有効 155 / 無効 1）、対象テーブルは 65 種類
デバイス種別: Browser 115 / Tablet 23 / Mobile 17（有効分）
Match conditions は全 155 件が All（Any は 0 件）
書き方: 条件ビルダー 132 件 / Advanced スクリプト 23 件
Overrides user preference: オン 145 / オフ 10
検証範囲とおことわり
件数・項目・選択肢・サンプルは REST と実画面で確認した OOTB の実測です。
「実際にフォームを開いてビューが切り替わる瞬間」のクリック再現は今回の範囲外です。
Advanced ルールのスクリプト本体は雛形の確認までで、個別ロジックは未精査です。
list.do のURL形式は規約に基づくもので、実クリック確認は範囲外です。
数値は確認日時点の初期設定です。本番やプラグイン追加で増減します。
まとめ
View Rule は、フォームやリストを開いたときに「どのビューを出すか」を、テーブル・条件・デバイス種別の3つを材料に自動で選ぶルールでした。合致したときだけ差し込まれ、該当が無ければ Default に戻る。だから副作用が小さく、こまめな出し分けに向いています。
PDI の実測では、有効 155 件が 65 テーブルに広がり、多くは条件ビルダー、一部はスクリプトで判定していました。利用者の好みを上書きするのが標準の効き方で、モバイルやタブレット専用のルールもそろっています。要は、状況とビューの対応表です。「ビューを作る」と「ビューを選ばせる」は別の作業だと分けて捉えると、見え方まわりの設計と切り分けが、ぐっと見通しよくなります。まずは自分のインスタンスで sysrule_view_list.do を開き、どんな出し分けが最初から入っているかを眺めてみてください。
参考リンク
ServiceNow 画面・フォーム完全ガイド：どこを直せば見た目が変わるのか — View Ruleはどのビュー（画面レイアウト）を出すかを決める仕組みです。画面まわり全体をどこから直せるかは、こちらの完全ガイドで確認できます。
ServiceNow View and View Rule Tutorial（ServiceNow Community）
How to create a Workspace Experience View Rule（ServiceNow Community）
