システムプロパティ（sys_properties）は設定値の置き場

ServiceNow を触っていると、「この挙動を変えるにはシステムプロパティ glide.〜 を設定してください」という案内に何度も出会います。日付フォーマット、製品名、セキュリティのオン／オフ。これらの「システム全体の設定値」は、実は1つのテーブル sys_properties（System Property） にレコードとして格納されています。

この記事では、システムプロパティをドキュメントの手順論だけで説明しません。実際の sys_properties テーブルを起点に、次を PDI 実機で確認した数値とともに確認します。

• name / value / type という基本構造

• type にどんな種別があるか

• glide.* で始まるプロパティの位置づけ

• read_roles / write_roles による権限

この記事は、ServiceNow の Incident などの画面は触ったことがある管理者・開発者を想定しています。「システムプロパティ」が裏でどんなテーブルとして管理されているかをこれから理解したい人向けです。実機で確認するときに見るべきポイントは次です。

• sys_properties の構造

• type の分布

• glide.* の規模

• 権限フィールド

この記事で分かること

• システムプロパティが sys_properties という1つのテーブルにレコードとして入っていること

• 1レコードの中心が name / value / type であること

• type にどんな種別があり、PDI ではどう分布しているか

• glide.* プロパティがどれくらいの規模を占めるか

• read_roles / write_roles・is_private・ignore_cache が何を制御するか

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

システムプロパティ（sys_properties）とは

システムプロパティとは、ServiceNow のインスタンス全体やアプリケーションの挙動を決める「設定値」です。たとえば製品名、UI の日付フォーマット、セキュリティ機能のオン／オフなどが、「名前（name）と値（value）のペア」として管理されます。

ServiceNow では、この設定値を格納する中心テーブルが sys_properties（System Property）です。コードのあちこちに設定値を散らすのではなく、プロパティとして一元的に持ち、サーバ側スクリプトからは gs.getProperty('プロパティ名') のような形で読み出す、という設計です。

App Navigator では System Definition ＞ System Properties から、または全プロパティの一覧を開けます。フィルターナビゲータに sys_properties.list と入力しても開けます。今回確認した PDI（Zurich / OOTB）では、sys_properties の総レコード数は 3,557 件で、Scope（アプリケーションスコープ）は Global でした。Global はどのアプリケーションスコープからも参照できる既定のスコープで、テーブル定義そのものがプラットフォーム共通の資産として扱われていることが分かります。

sys_properties は「設定値」でありながらメタデータ

sys_properties の継承関係を見ると、このテーブルが単なるデータテーブルではないことが分かります。

今回確認した PDI（Zurich / OOTB）では、sys_properties は sys_metadata（Application File）を継承していました。sys_metadata は、Business Rule（sys_script）や Dictionary（sys_dictionary）などが属する基底です。「Update Set で移送されるメタデータ」の基底といえます。

つまりシステムプロパティは「設定値レコード」でありながら、テーブル定義やスクリプトと同じ Application File の仲間として扱われます。これが、プロパティの追加・変更が Update Set に乗って別インスタンスへ移送され得る理由です。後述の is_private は、この移送をプロパティ単位で止めるためのフラグです。

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

https://<YourInstance>/sys_db_object_list.do?sysparm_query=name=sys_properties

1レコードの構造（name / value / type が中心）

sys_properties の1レコードは、どんなプロパティでも共通の固有フィールドを持ちます。今回確認した PDI（Zurich / OOTB）では、固有フィールドは11件でした。役割で分けると、識別・値、権限、運用フラグに整理できます。

中心になるのは name（プロパティ名）・value（設定値）・type（値の種別） の3つです。注意したいのは、value は内部的には文字列として保持され、type に応じて解釈される点です。たとえば type が boolean のプロパティでも、value 列には "true" / "false" という文字列が入ります。

主なフィールド一覧

主な固有フィールドは次のとおりです。ラベルは画面上の表示名で、実機どおり記載します。

実機のフォームを開くと、これらのフィールドが1画面に並びます。次は、セキュリティ関連のプロパティ glide.security.use_csrf_token を開いた例です。Type が「true | false」、Value が「true」、Read roles が admin、Write roles が security_admin と表示されているのが読み取れます。

全フィールドは、次のURLで一覧できます。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sys_properties^elementISNOTEMPTY

公式ドキュメントに、System Properties リストからプロパティを追加する手順が説明されています。name / value / type / read roles / write roles / ignore cache / private 各フィールドの意味もあります。

type にはどんな種別があるか

type は、value をどう扱い、フォーム上でどんな入力欄として表示するかを決めます。今回確認した PDI（Zurich / OOTB）では、type の選択肢は13種ありました。string / integer / boolean のような基本型に加え、choice list（選択肢）や color（色）、image（画像）があります。ほかに用意されているのが date format / time format（書式）、password / password2（秘匿値）、timezone です。uploaded_image（アップロード画像）や short_string（40文字以内の短い文字列）も含まれます。件数で見ると、この残り10種はいずれも一桁〜数十件どまりです。内訳は password 4／date_format 3／password2 3／uploaded_image 3／timezone 2／short_string 1です。実際に使われているのはごく少数でした。

分布は boolean・string・integer が中心

実レコードを type でグルーピングすると、分布がはっきり分かります。今回の PDI では、boolean が最多で 1,341 件、次いで string 1,272 件、integer 697 件でした。

ここから読み取れるのは、システムプロパティの多くが「オン／オフのスイッチ（boolean）」と「文字列・数値の設定値」だということです。boolean だけで全体の約4割を占めます。実機でグルーピング表示すると、画面上部に「3557 total System Properties」と出て、上の表の件数と一致します。

type の選択肢の確認には、辞書（sys_dictionary）の type 列の choice を参照します。なお type は内部的に short_string や true（短縮形）など細かなグループも持ち、PDI では (empty) 4 件なども観測されました。本記事では代表的な13種に絞って扱います。

glide.* プロパティの位置づけ

システムプロパティを眺めると、名前が glide. で始まるものが多いことに気づきます。glide は ServiceNow のプラットフォーム本体（Glide）を指し、glide.* はプラットフォームの標準挙動を制御するプロパティです。後述のとおり全体の半数超を占めます。

今回確認した PDI（Zurich / OOTB）では、name が glide. で始まるプロパティは 1,909 件で、全 3,557 件の半数以上を占めていました。例には製品名（glide.product.name = "ServiceNow"）があります。製品説明（glide.product.description = "Service Management"）もあります。CSRF トークン利用（glide.security.use_csrf_token = "true"）などもあります。UI からセキュリティまで広い範囲をカバーします。

代表的な glide.* の実測値

代表的な glide.* プロパティの実測値は次のとおりです。

注意したいのは、glide.* だからといって自由に変更してよいわけではない点です。先ほどのフォーム例（glide.security.use_csrf_token）には警告が表示されていました。「High Risk」「Do not alter this file unless necessary」です。プラットフォーム挙動を直接左右するため、変更前に影響範囲とロールバック手段を確認する必要があります。

glide.* のプロパティは、次のURLで一覧できます。

https://<YourInstance>/sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.^ORDERBYname

公式ドキュメントに、用途別に整理された利用可能なシステムプロパティの一覧があります。

権限と運用フラグ（read_roles / write_roles / is_private / ignore_cache）

システムプロパティの値は、誰でも読み書きできるわけではありません。sys_properties には、read_roles（読み取り可能ロール）と write_roles（書き込み可能ロール） という権限フィールドがあります。

今回確認した PDI（Zurich / OOTB）では、read_roles が設定されたプロパティは 738 件、write_roles が設定されたものは 937 件でした。たとえば glide.security.use_csrf_token は read=admin / write=security_admin です。「admin なら読めるが、書き換えは security_admin が必要」という非対称な保護がかかっていました。glide.security.3des.encryption.allow のように read/write とも maint（メンテナンス用の上位ロール）に限定されたものもあります。

is_private と ignore_cache

さらに、運用上の挙動を変える2つのフラグがあります。

• is_private（Private） … true にすると、そのプロパティを Update Set による移送から除外します。今回の PDI では 146 件が is_private=true でした。インスタンス固有の値（接続先など）を、他環境に上書きさせないために使います。

• ignore_cache（Ignore cache） … 通常プロパティ値はキャッシュされますが、true にするとキャッシュせず都度 DB を参照します。先のフォーム例には「Ignore cache を外すとキャッシュフラッシュで性能影響が出得る」旨の注意も表示されていました。

なお、ここでの read_roles / write_roles は sys_properties レコード自体の項目による制御です。実環境では、これに加えて ACL（sys_security_acl）による制御も関係し得ます。本記事ではレコード上のフィールドに絞って確認しています。

プロパティとカテゴリの関係

「Self-Service」「Security」のように、設定ページではプロパティがカテゴリ単位でまとめて表示されます。このグルーピングは sys_properties テーブルの中ではなく、専用の関連テーブルで管理されています。

今回確認した PDI（Zurich / OOTB）では、次の件数を確認しました。カテゴリ（sys_properties_category）が 193 件、プロパティとカテゴリを結ぶリンク（sys_properties_category_m2m）が 1,351 件です。1つのプロパティが複数のカテゴリに属することもできます。逆に1つのカテゴリが多数のプロパティを束ねることもできます。多対多の関係です。

カテゴリは、次のURLで確認できます。

https://<YourInstance>/sys_properties_category_list.do?sysparm_query=ORDERBYname

ServiceNow におけるシステムプロパティのポイント

• システムプロパティは sys_properties（System Property）という1つのテーブルに、name / value / type を中心としたレコードとして格納されます。今回の PDI では総数 3,557 件でした。

• sys_properties は sys_metadata（Application File）を継承するメタデータで、変更は Update Set に乗って移送され得ます。インスタンス固有の値は is_private で移送を止めます（今回 146 件）。

• value は内部的に文字列で保持され、type（PDI で13種）に応じて解釈されます。分布は boolean 1,341 / string 1,272 / integer 697 が中心で、boolean が約4割を占めました。

• **glide.* は 1,909 件**で全体の半数超。プラットフォーム本体の挙動を制御するため、High Risk 表示のあるものは変更前に影響範囲を確認します。

• 権限は read_roles（738件）/ write_roles（937件）で制御され、読み取りと書き込みで別ロールを要求する非対称な保護もあります。

• プロパティのカテゴリ表示は sys_properties_category（193件）と多対多リンク（1,351件）で管理されます。

システムプロパティを調べるときは、「このプロパティの type は何で、value はどう解釈されるか」を意識します。sys_properties 単体ではなく、上の sys_metadata（移送の仕組み）、横の read_roles / write_roles（権限）、カテゴリ関連をセットで確認するとよいです。

実機を見て気づいたこと

• type の内訳を見ると、boolean・string・integer の3種だけで全体の92%を占めていました。残り10種（choicelist・color・image・date_format など）は合わせても1割に届かず、フォーム上は多彩でも実際に使われる型は絞られている印象です。

• is_private=true は146件で、全体のわずか4%でした。最初は「環境固有の値はもっと多いはず」と予想していましたが、実際には大半のプロパティが Update Set での移送を前提に作られていると分かります。

• write_roles が設定されたプロパティ（937件）は read_roles（738件）より多く、「誰でも読めるが、書き換えは特定ロールに絞る」という非対称な保護のかけ方が主流でした。読み取り制限より書き込み制限を優先する設計思想が透けて見えます。

次に読むなら

次に確認するなら、次のテーマです。

• サーバ側スクリプトからの読み出し（gs.getProperty()）の挙動と既定値の扱い

• 独自アプリで設定ページ（カテゴリ）を作る方法

• ACL（sys_security_acl）と read_roles / write_roles の関係

特に「インスタンス固有値（is_private）と移送対象値をどう設計で分けるか」は、複数環境を運用するうえで判断が分かれるポイントです。これらは本記事の「権限と運用フラグ」「プロパティとカテゴリの関係」で触れた仕組みの先にあたり、別記事で解説する予定です。

用語

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

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

• プロパティ（System Property）：システム全体やアプリの設定値レコード（sys_properties）

• glide.*：ServiceNow プラットフォーム本体（Glide）の挙動を制御するプロパティ

• Update Set：変更を別インスタンスへ移送する仕組み（メタデータが対象）

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

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

テーブル定義       : sys_db_object_list.do?sysparm_query=name=sys_properties
全プロパティ一覧    : sys_properties_list.do
glide.* 一覧       : sys_properties_list.do?sysparm_query=nameSTARTSWITHglide.^ORDERBYname
type でグループ化   : sys_properties_list.do?sysparm_query=GROUPBYtype
フィールド一覧      : sys_dictionary_list.do?sysparm_query=name=sys_properties^elementISNOTEMPTY
カテゴリ一覧        : sys_properties_category_list.do?sysparm_query=ORDERBYname

検証範囲とおことわり

• 確認した範囲：sys_properties の継承（sys_metadata系）、固有フィールド11、type の選択肢13種と件数分布、総数3,557

• glide.* 1,909、read_roles 738 / write_roles 937 / is_private 146

• 代表的な glide.* プロパティの実値、カテゴリ関連テーブル（193 / 1,351）。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています

• 確認していない範囲（断定しません）：各プロパティが内部でどう参照されるか（gs.getProperty() 等の実行時挙動）、キャッシュフラッシュの内部実装

• 各プロパティ変更が機能に与える具体的影響、ACL（sys_security_acl）による追加の権限制御、本番でのカスタムプロパティ運用方針。これらは別記事で扱います