アプリとスコープ：Globalとx_の違い（sys_app）

2026年6月21日 11:50

ServiceNow を触っていると「Global」「Scoped」「アプリケーションスコープ」「x_ で始まる名前」といった言葉に出会います。設定を作ろうとして「このスコープでは編集できません」と言われた経験がある人もいます。

この記事では、ServiceNow の「アプリ」とスコープの仕組みを、概念だけでなく実際のテーブルから確認します。スコープ定義を保持する sys_scope（Application）、カスタムアプリを表す sys_app（Custom Application）、そしてすべての設定レコードの基底である sys_metadata（Application File）を起点に、これらがどう継承し、どう「どのアプリに属するか」を持つのかを確認します。

この記事は、ServiceNow の Incident などは触ったことがある管理者・開発者を想定しています。アプリ／スコープの構造（Global と Scoped の違い、x_ の意味）をこれから理解したい人が対象です。読者のよくある疑問は「global と x_ の違いは何か」「なぜ別アプリの設定をいじれないことがあるのか」です。本記事は、その土台にあたるテーブル構造を扱います。

この記事で分かること

アプリ定義が sys_package → sys_scope → sys_app という継承で成り立つこと
sys_scope（Application）が持つ scope / vendor_prefix などの固有フィールド
Global スコープと Scoped（個別スコープ）の違い、x_ と sn_ プレフィックスの意味
すべての設定レコードが sys_metadata を継承し、sys_scope フィールドで所属アプリを持つこと
今回の PDI でのスコープ件数・Application File 件数の内訳
実機で確認するときに見るべき一覧URL

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、スコープ構成・フィールド・件数の内容が異なる場合があります。

アプリケーションスコープとは

まず結論です。スコープとは「アプリの名前空間」で、Global と Scoped の2種類があります。

ServiceNow の「アプリケーション（アプリ）」は、テーブル・フォーム・Business Rule・ロールといった設定の集まりに名前を付けて束ねたものです。そして各アプリには「スコープ（scope）」という名前空間が割り当てられます。スコープは、そのアプリに属する設定を見分け、アプリの境界を決める役割を持ちます（公式ドキュメントの Application scope を参照）。

スコープには大きく Global と Scoped（個別スコープ）の2種類があります。Global は従来からある共有領域で、Scoped はアプリごとに区切られた領域です。Scoped アプリの設定は、原則としてそのスコープの中で完結し、他スコープの設定とは分けて扱われます。「別アプリの設定をいじれないことがある」という現象は、この区切りに関係します（実行時の挙動そのものは本記事の範囲外です）。公式ドキュメントの Global scope には、Global は Scoped のような境界を持たない領域だと書かれています。

この記事では、スコープ定義がどのテーブルに、どのフィールドで保持されているかを実機で確認します。

アプリ定義の継承（sys_package → sys_scope → sys_app）

まず、アプリ／スコープ定義のテーブルがどう継承でつながっているかを確認します。

今回確認した PDI（Zurich / OOTB）では、次の継承関係でした（sys_db_object の super_class で確認）。

sys_package（Package）… 基底。name / version / active などの土台フィールドを持つ。
sys_scope（Application）… sys_package を継承。scope / vendor_prefix などスコープ固有のフィールドを足す。
sys_app（Custom Application）… sys_scope を継承。menu / store_url などを足す。
sys_store_app（Store Application）… sys_scope を継承。ストア由来アプリ。

つまり「アプリ」として画面で扱う sys_app は、その実体としてスコープ定義（sys_scope）を継承しており、さらにその下地に Package（sys_package）があります。固有フィールド数は、今回の PDI で sys_package 18・sys_scope 16・sys_app 10 でした（dict の elementISNOTEMPTY で計測。name / version / active などは基底 sys_package 側にあり、継承して使われます）。

継承関係は、次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

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

sys_scope（Application）の主なフィールド

スコープ定義の中身を見ると、アプリの名前空間や見え方を決めるフィールドが並びます。

Field                    Label                           Type                         説明
------------------------------------------------------------------------------------------
scope                    Scope                           String                       スコープ名（例 global / sn_itsm_workspace）
vendor_prefix            Vendor prefix                   String                       ベンダープレフィックス（カスタムは x_ の後ろに付く）
vendor                   Vendor                          String                       ベンダー名
short_description        Short description               Translated text              アプリの説明
private                  Private                         Boolean                      スコープを非公開にするか
restrict_table_access    Restrict Table Choices          Boolean                      テーブル選択肢の制限
can_edit_in_studio       Can Edit Application in Studio  Boolean                      Studio で編集可能か
runtime_access_tracking  Restrict Runtime Access         String                       実行時アクセスの扱い
logo                     Logo                            User image                   アプリのロゴ
license                  Subscription                    Reference → license_details  サブスクリプション

今回の PDI で sys_scope の固有フィールドは16でした。代表的なのは scope（スコープ名そのもの）、vendor_prefix（ベンダープレフィックス）、vendor（ベンダー名）、private（非公開にするか）、restrict_table_access（Restrict Table Choices）、can_edit_in_studio（Studio で編集可能か）などです。

ポイントは、スコープ名（scope）がアプリの識別子そのものになっている点です。Global なら global、ServiceNow 発行のアプリなら sn_ で始まる名前です。顧客が作るカスタムアプリなら x_ に vendor_prefix が続く名前、という形でスコープ名が決まります。

sys_scope のフィールド一覧

固有フィールドを挙げると、scope, vendor_prefix, vendor, short_description, private, restrict_table_access, can_edit_in_studio, runtime_access_tracking, scoped_administration, js_level, template, logo, license, subscription_entitlement, guided_setup_guid です。

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

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

Global と Scoped の違い（x_ と sn_ プレフィックス）

global は共有スコープ、sn_ は ServiceNow 製アプリ、x_ は顧客カスタムアプリ用のプレフィックスです。「global と x_ の違いは何か」という疑問に、今回の PDI の件数で答えます。

今回確認した PDI（Zurich / OOTB）では、sys_scope は全部で722件ありました。その内訳は次のとおりです。

Global スコープ … 1件（scope=global、name は Global、説明は「Global application scope」）。プレフィックスのない共有スコープです。
sn_ プレフィックス … 691件。これは ServiceNow が発行するスコープアプリ（ストアやプラグイン由来）です。例としては sn_itsm_workspace（ITSM Workspace）と sn_nlu_studio（NLU Studio）があります。ほかに sn_appcreator（Scoped App Creator）などもありました。
x_ プレフィックス … 0件。x_ は顧客（カスタム）が開発したアプリ用のプレフィックスです。今回の PDI ではカスタムアプリを作っていないため0件でした。

つまり、今回の PDI で観察した範囲では「global」は共有の1スコープ、「sn_」は ServiceNow 製アプリ、「x_」は顧客カスタムアプリ、という命名の使い分けでした。x_ が0件なのは「カスタムアプリ未作成」を意味し、x_ プレフィックス自体は顧客アプリのために予約されている、と読めます。

件数の内訳（クエリと結果）

観点                               物理テーブル / クエリ                 件数
-----------------------------------------------------------------------------
アプリ／スコープ定義 全体          sys_scope                             722
Global スコープ                    sys_scope scope=global                1
global 以外のスコープ              sys_scope scope!=global               721
sn_ プレフィックス（SN発行）       sys_scope scopeSTARTSWITHsn_          691
x_ プレフィックス（顧客カスタム）  sys_scope scopeSTARTSWITHx_           0
Custom Application レコード        sys_app                               0
Application File 全件              sys_metadata                          616,479
うち global スコープ               sys_metadata sys_scope.scope=global   423,229
うち global 以外                   sys_metadata sys_scope.scope!=global  182,096

なお、Custom Application を表す sys_app の物理テーブルのレコードは、今回の PDI では0件でした（table 取得でも0行）。これも「この PDI にカスタムアプリが無い」ことと整合します。

スコープ一覧は、次のURLで確認できます。

https://<YourInstance>/sys_scope_list.do

すべての設定は sys_metadata を継承し、sys_scope を持つ

先に結論です。設定レコードは sys_metadata を継承し、その sys_scope フィールドで「どのアプリに属するか」を持ちます。ここがこの構造を理解するうえでいちばんのポイントです。

テーブルや Business Rule、Dictionary といった「設定レコード」は、共通の基底テーブル sys_metadata（Application File）を継承しています。そして sys_metadata は sys_scope フィールド（参照先 sys_scope・ラベルは Application）を持つため、すべての設定レコードが「どのアプリ（スコープ）に属するか」を保持できます。公式ドキュメントでも、こうした設定の構成要素を Application files としてアプリ／スコープに属するものと説明しています。

今回の PDI で、代表的な設定テーブルの super_class を確認すると、いずれも sys_metadata を継承していました。

sys_dictionary（フィールド定義）→ sys_metadata
sys_script（Business Rule）→ sys_metadata
sys_db_object（テーブル定義）→ sys_metadata
sys_ui_action（UI Action）→ sys_metadata

sys_metadata の固有フィールドは12で、その中に sys_scope（Application、→sys_scope）と sys_package（Package、→sys_package）があります。継承の仕組みにより、これらのフィールドは上記すべての設定テーブルにも現れます。だから「このフィールド定義はどのアプリのものか」「この Business Rule はどのスコープか」を、各レコードの sys_scope で判別できます。

テーブル      Field                    Label                     役割
---------------------------------------------------------------------
sys_app       menu                     Menu                      アプリのアプリケーションメニュー
sys_app       user_role                User role                 アプリの利用ロール
sys_app       store_correlation_id     Store correlation ID      ストア連携の識別子
sys_app       store_url                Store URL                 ストアのURL
sys_app       installed_as_dependency  Installed via Dependency  依存で導入されたか
sys_app       uninstall_blocked        Uninstall Blocked         アンインストール禁止か
sys_metadata  sys_scope                Application               どのアプリ（スコープ）に属するか → sys_scope
sys_metadata  sys_package              Package                   どのパッケージに属するか → sys_package
sys_metadata  sys_class_name           Class                     実際の設定テーブル名

sys_app のフィールド一覧

固有フィールドを挙げると、menu, user_role, license_definition, store_correlation_id, store_url, sys_code, hide_on_ui, installed_as_dependency, uninstall_blocked です。

sys_metadata のフィールド一覧

固有フィールドを挙げると、sys_class_name, sys_name, sys_update_name, sys_scope（→sys_scope）, sys_package（→sys_package）, sys_policy, sys_created_by/on, sys_updated_by/on, sys_mod_count です。sys_created_by や sys_mod_count のような監査系フィールドも、Application File として同じ基底に乗っています。

sys_metadata の全体像を件数で見ると、アプリ境界の意味がより具体的になります。

今回の PDI では、Application File（sys_metadata）は全部で616,479件ありました。そのうち sys_scope が global のものが423,229件、global 以外（個別スコープ）のものが182,096件でした（合計605,325件で、差分は sys_scope 参照が空または解決できないレコードと考えられます）。global が多いのは、OOTB の多くの基盤設定が Global スコープに属しているためと読めます。

Application File は、次のURLで確認できます。

https://<YourInstance>/sys_metadata_list.do

スコープ間のアクセス（cross-scope）について

Scoped アプリの設定は、原則としてそのスコープの中で識別・管理されます。sys_scope には restrict_table_access（Restrict Table Choices）や runtime_access_tracking（Restrict Runtime Access）といった、スコープ間のアクセスに関係しそうなフィールドが存在します。

ただし、これらのフィールドが実行時にどう効くか（別スコープのテーブルやスクリプトを呼べるか／呼べないか、Cross-Scope Access の許可レコードがどう作られるか）は、本記事の確認範囲外です。本記事はあくまで「スコープがテーブル構造としてどう表現されているか」（sys_scope のフィールド、sys_metadata の sys_scope による所属）までを扱います。「別アプリの設定をいじれないことがある」という現象の入口が、このスコープ境界にあること、という観察にとどめます。実行時挙動は別途の検証が必要です。

ServiceNow のアプリとスコープのポイント

アプリ定義は sys_package（基底）→ sys_scope（Application）→ sys_app（Custom Application） という継承で成り立ちます。sys_store_app（Store Application）も sys_scope を継承します。今回の PDI で固有フィールドは sys_package 18・sys_scope 16・sys_app 10 でした。
スコープ名（scope）がアプリの識別子です。今回の PDI では global が1件、sn_ プレフィックス（ServiceNow 発行）が691件、x_ プレフィックス（顧客カスタム）が0件で、sys_scope は全722件でした。
すべての設定レコードは sys_metadata（Application File）を継承し、sys_scope フィールドで所属アプリを持ちます。 sys_dictionary / sys_script / sys_db_object / sys_ui_action はいずれも sys_metadata を継承していました。
今回の PDI で Application File は616,479件、うち global 423,229件・global 以外 182,096件でした。Global に基盤設定が多く属していることが読み取れます。
cross-scope の実行時挙動（restrict_table_access / runtime_access_tracking の動作）は本記事では確認していません。スコープ境界の「入口」がテーブル構造にあること、までを扱います。

アプリ／スコープを調べるときは、まず「この設定レコードの sys_scope は何か」を意識し、sys_app（アプリ）単体ではなく、その下地の sys_scope（スコープ定義）と、設定側の基底である sys_metadata をセットで確認しましょう。

実機を見て気づいたこと

ライセンス関連のフィールドは、sys_scope 側に license（Subscription）、sys_app 側に license_definition と、似た名前のものが2つのテーブルに分かれて存在していました。継承関係にある2テーブルなのに、ライセンスの持ち方が微妙に違う点は紛らわしいポイントです。
sys_app には hide_on_ui という、アプリを UI 上から隠すためとみられるフラグがありました。ストア経由や内部利用のアプリなど、利用者に見せたくないアプリを想定した項目のようです。
sys_scope の固有フィールドには js_level（JavaScript 実行レベル）や template（テンプレート）といった、実行環境に関わるフィールドもありました。scope や vendor_prefix のような識別情報だけでなく、実行時の挙動に関わる設定もスコープ単位で持てる作りです。

次に読むなら

次に確認するなら、Cross-Scope Access（sys_scope_privilege など）の実行時の許可の仕組み、Application Repository / Update Set とスコープの関係、そして sys_app_module（アプリケーションメニュー）と sys_scope の結びつきです。特に「Scoped アプリから Global のテーブルをどう参照するか」は、本記事の「スコープ間のアクセス」で触れた境界の先にあたり、別記事で扱う予定です。

用語

PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
スコープ（scope）：アプリの名前空間。Global または個別スコープ
Global：プレフィックスのない共有スコープ（今回1件）
Scoped：個別スコープ。sn_（SN発行）/ x_（顧客カスタム）など
Application File：設定レコードの基底（sys_metadata）。sys_scope で所属アプリを持つ
vendor_prefix：ベンダープレフィックス。カスタムアプリの x_ の後ろに付く識別子

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

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

継承（sys_scope の子）  : sys_db_object_list.do?sysparm_query=super_class.name=sys_scope
sys_scope フィールド     : sys_dictionary_list.do?sysparm_query=name=sys_scope^elementISNOTEMPTY
スコープ一覧            : sys_scope_list.do
カスタムアプリ          : sys_app_list.do
Application File 一覧    : sys_metadata_list.do

検証範囲とおことわり

確認した範囲：sys_app / sys_store_app / sys_scope / sys_package / sys_metadata の super_class 連鎖、各テーブルの固有フィールド数とフィールド、sys_metadata の sys_scope / sys_package フィールド、設定テーブル（sys_dictionary / sys_script / sys_db_object / sys_ui_action）が sys_metadata を継承すること、sys_scope の件数と global / sn_ / x_ の内訳、sys_metadata の総件数と scope=global / !=global の内訳。すべて PDI（Zurich / 2026-06-20 確認）の OOTB で取得しています。
確認していない範囲：cross-scope アクセスの実行時挙動（restrict_table_access / runtime_access_tracking の動作）、Studio の編集挙動、アプリのインストール／パブリッシュの実処理、Update Set とスコープの関係。また sys_store_app / sys_package のレコード件数は API レベルの ACL（403）で取得できなかったため、件数は確認範囲外です。これらは別記事で扱います。

今回は PDI の OOTB（初期設定）を前提に、アプリとスコープのテーブル構造を確認しました。実環境では、導入済みアプリやカスタムアプリによってスコープ数・Application File 数・フィールドの内容が変わります。