プラグイン（v_plugin/sys_plugins）の有効・無効と依存
ServiceNow を触っていると「このプラグインを有効化してください」「Incident プラグインが入っていれば〜」といった言葉に出会います。System Definition ＞ Plugins を開くと、見たことのない名前がずらりと並びます。何が有効で何が無効なのか、全部でいくつあるのか、戸惑った人もいるはずです。
この記事では、ServiceNow の「プラグイン」の仕組みを、概念だけでなく実際のビュー・テーブルから確認します。起点は3つです。利用可能なプラグインを見る v_plugin（System Plugin）、その物理側にあたる sys_plugins、ストア由来アプリの sys_store_app です。ここから「何が入っているか」「active か inactive か」「どの依存関係（requires）を持つか」を、今回の PDI の実数で読み解きます。
この記事は、ServiceNow の Incident などは触ったことがある管理者・開発者を想定しています。プラグインの構造、つまり v_plugin と sys_plugins の違い、有効/無効、依存をこれから理解したい人向けです。読者のよくある疑問は「プラグインは全部でいくつあって、いくつ有効なのか」「依存関係はどこに書かれているのか」です。
この記事で分かること
プラグインのビュー v_plugin と、物理側 sys_plugins / ストア側 sys_store_app の関係
v_plugin が持つ id / active / state / requires などの固有フィールド
今回の PDI でのプラグイン総数・active 数・inactive 数の内訳
com.snc.（業務系）と com.glide.（基盤系）という id プレフィックスの傾向
依存関係（requires）がどのフィールドに、どう保持されているか
実機で確認するときに見るべき一覧URL
この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、プラグイン構成・件数・active 状態の内容が異なる場合があります。
プラグインとは
プラグインとは「機能パック」です。ServiceNow の各機能（Incident、Change、AI Search など）を 有効化（active）／無効化（inactive）の単位で束ねたものを指します。
ServiceNow の機能の多くは、最初からすべて使える状態ではなく、プラグインとして区切られています。そのプラグインを有効化すると、関連するテーブル・フォーム・スクリプト・デモデータなどがまとめて導入されます。 PDI では多くのプラグインを自分で有効化できます。詳しくは公式ドキュメントの Activate a plugin on a personal developer instance を参照してください。
そして「いま何が有効化されているか」「自分で有効化できるプラグインは何か」を見るのが、System Definition ＞ Plugins に対応するビュー v_plugin です。この記事では、プラグイン定義がどのビュー・テーブルに、どのフィールドで保持されているかを実機で確認します。
https://<YourInstance>/v_plugin_list.do
プラグインのテーブル構造（v_plugin / sys_plugins / sys_store_app）
まず、プラグイン関連のテーブルがどうつながっているかを見ます。
今回確認した PDI（Zurich / OOTB）では、次の関係でした（sys_db_object で確認）。
v_plugin（System Plugin） … ラベルは「System Plugin」。利用可能なプラグインを見るためのビューで、id / active / requires などの固有フィールドを持ちます。本記事の主役です。
sys_plugins（Sys Plugins） … super_class は sys_package（Package）。プラグインの物理側にあたり、Package 系の土台を継承します。
sys_store_app（Store Application） … super_class は sys_scope（Application）。ストア由来アプリを表すテーブルで、スコープ（アプリ）系の継承に属します。
つまり 「プラグイン（機能パック）」と「ストアアプリ」は別系統でした。v_plugin はプラグインを見るビュー、sys_store_app はスコープアプリ側という住み分けです。ServiceNow コミュニティでも、v_plugin はセルフサービスで有効化できるプラグインを見るビューと説明されています。sys_plugins はインスタンス上の active なプラグインを含むテーブルです。
https://<YourInstance>/sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_pluginなお、sys_store_app のレコード件数は今回の PDI では API レベルの ACL（HTTP 403）で取得できませんでした。件数は確認範囲外とし、捏造はしません。
v_plugin の主なフィールド
プラグイン定義の中身を見ると、識別子・状態・依存を決めるフィールドが並びます。
Field Label Type 説明
-----------------------------------------------
id ID String プラグイン識別子（例 com.snc.incident）
name Name Translated text 表示名（例 Incident）
active Status String 有効/無効（値の例 active / inactive）
state State String 公開状態（例 published）
version Version String 導入バージョン
provider Provider String 提供元（ほぼ ServiceNow）
requires Requires Glide list → v_plugin 依存プラグイン（id のカンマ区切り）今回の PDI で v_plugin の固有フィールドは30でした。代表的なのは id（プラグイン識別子）、name（表示名）、active（Status＝有効/無効）、state（公開状態）の4つです。ほかに version、provider、そして依存を表す requires があります。
固有フィールドの中身（ライセンス・ロールバック関連も含む）
表に挙げた7つ以外にも、v_plugin には少なくとも次の16個の固有フィールドがあります（残りは今回確認していません）。
available_version（利用可能なバージョン）・scope（スコープ）
has_demo_data（デモデータの有無）・supports_rollback（ロールバック対応）・trackable
licensable・license_category・license_model（ライセンス関連）・entitled
definition・path・help・guided_setup_guid（→ gsw_content、ガイド付きセットアップへの参照）
indicators・type・block_install
has_demo_data=true のプラグインは176件あり、デモデータの有無もこのビューから直接確認できます。licensable や license_model のようなライセンス関連フィールドが複数あることから、プラグインには有効/無効のスイッチだけでなく、エンタイトルメント（利用権）を管理する仕組みも組み込まれているとうかがえます。
active は文字列で管理される
ここで注意したいのは、active は boolean ではなく文字列（"active" / "inactive"） だという点です。実際、active=true で検索すると0件で、active=active で絞り込む必要がありました。「Status」というラベルの通り、有効/無効を文字列の状態値として持っています。
全フィールドは、次のURLで一覧できます。
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=v_plugin^elementISNOTEMPTY
何がいくつ入っているか（active / inactive の内訳）
今回の PDI では、プラグインは全1418件でした。うち active が925件、inactive が493件です。「全部でいくつあって、いくつ有効なのか」という疑問に、実数で答えます。
active / inactive の内訳
今回確認した PDI（Zurich / OOTB）の内訳は次のとおりです。
プラグイン全体 … 1418件（すべて state=published）。
active（有効） … 925件。すでに有効化され、機能が使える状態のプラグインです。
inactive（無効） … 493件（925＋493＝1418で整合）。導入はされているが有効化されていないプラグインです。
id プレフィックスの傾向（com.snc. / com.glide.）
id のプレフィックスにも傾向があります。com.snc.（業務アプリ系）が491件、com.glide.（プラットフォーム基盤系）が490件と、ほぼ二分されていました。さらに active に絞ると、com.snc. は197件、com.glide. は377件でした。基盤系（com.glide.）の方が active 比率が高いという結果です。プラットフォームの土台として最初から有効になっているものが多いため、と読めます（あくまで今回の PDI / OOTB での観察です）。実務でプラグイン構成を棚卸しするときは、まず com.glide. 系の active 一覧を確認すると、そのインスタンスの基盤側の構成がおおよそ把握できます。
提供元（provider）は、1418件中1354件が ServiceNow で、残りも Glidesoft / Service-now.com といった ServiceNow 系の旧称表記でした。今回の PDI では顧客（サードパーティ）作成のプラグインは観察されませんでした。
観点 ビュー / クエリ 件数
------------------------------------------------------------------------------
プラグイン全体 v_plugin 1418
有効（active） v_plugin active=active 925
無効（inactive） v_plugin active=inactive 493
com.snc. 系（全体） v_plugin idSTARTSWITHcom.snc. 491
com.glide. 系（全体） v_plugin idSTARTSWITHcom.glide. 490
うち active な com.snc. v_plugin active=active^idSTARTSWITHcom.snc. 197
うち active な com.glide. v_plugin active=active^idSTARTSWITHcom.glide. 377
依存を宣言する v_plugin requiresISNOTEMPTY 1117
デモデータを持つ v_plugin has_demo_data=true 176有効なプラグインだけを一覧したいときは、Status で絞り込みます。
https://<YourInstance>/v_plugin_list.do?sysparm_query=active=active^ORDERBYname
依存関係（requires）はどこに書かれているか
プラグインの依存関係は、v_plugin の requires フィールド（Glide list → v_plugin） に、依存先プラグインの id をカンマ区切りで保持しています。
Incident プラグインを例に依存を追う
今回の PDI で、馴染みのある Incident プラグイン（id: com.snc.incident）の詳細を見ると、次のようになっていました。
id：com.snc.incident ／ name：Incident ／ Status：active ／ version：1.0.0 ／ scope：global。
requires（値）：com.snc.service,com.snc.incident_notification。
requires（表示）：com.snc.service, Incident Management Notification。
Incident プラグインは、com.snc.service と com.snc.incident_notification の2つに依存しています。 後者の表示名は Incident Management Notification です。この依存は requires から読み取れます。表示時には依存先の id が name に解決されるため、一覧画面では依存プラグインの「名前」で確認できます。
依存を宣言するプラグインは過半数
依存を宣言するプラグインは、全1418件中1117件ありました。過半数のプラグインが何らかの依存を持つことになります。公式ドキュメントの Activate a plugin でも同じ説明があります。依存プラグインは有効化のUIに列挙され、必要に応じて一緒に有効化されます。requires は、その「一緒に有効化されるもの」の定義そのものにあたります。
ID Name Status 依存（requires）
-------------------------------------------------------------------------------------
com.snc.incident Incident active com.snc.service / Incident Management Notification
com.snc.adaptive_authentication Adaptive Authentication active com.glide.decision_table ほか
com.snc.ai_search_assist AI Search Assist active com.glide.search
com.snc.apps System Applications Core active com.snc.apps_picker
@devsnc/fuzzy-search （UXコンポーネント系） inactive －特定プラグインの詳細は、id で絞り込むと確認できます。
https://<YourInstance>/v_plugin_list.do?sysparm_query=id=com.snc.incident
ServiceNow のプラグインのポイント
プラグイン（機能パック）を見るビューが v_plugin（System Plugin）で、物理側の sys_plugins は sys_package を継承します。ストア由来アプリの sys_store_app は sys_scope を継承する別系統で、プラグインとは住み分けられていました。
v_plugin の固有フィールドは30です。id（識別子）・name（表示名）・active（Status＝有効/無効、文字列）・state・version・provider・requires（依存）などを持ちます。active は boolean ではなく active / inactive の文字列です。
今回の PDI ではプラグインは全1418件、active 925件・inactive 493件でした。id は com.snc.（業務系）491件・com.glide.（基盤系）490件にほぼ二分され、active 比率は基盤系（377/490）の方が高めでした。
依存関係は requires（Glide list → v_plugin）に id のカンマ区切りで保持されます。全1418中1117件が依存を宣言し、例として Incident は com.snc.service と Incident Management Notification に依存していました。
sys_store_app の件数、プラグイン有効化の実処理（裏で何が読み込まれるか）は本記事では確認していません。「プラグインがビュー・テーブルとしてどう表現され、active／依存をどこに持つか」までを扱います。
プラグインを調べるときは、まず「このプラグインの active は何か」「requires に何が並んでいるか」を意識します。v_plugin（ビュー）で active と依存を確認するのが第一歩です。
実機で気づいたこと
active=true で検索して0件だったときは、てっきりクエリを間違えたのかと思いました。実機では active は boolean ではなく文字列で管理されており、Status というラベルどおり状態値として持たれています。REST やスクリプトで active を条件にするときは、この文字列比較を忘れると空振りします。
id プレフィックスが com.snc.（491件）と com.glide.（490件）でほぼ同数だったのも意外でした。業務系プラグインの方が数が多いだろうと思い込んでいましたが、実機ではプラットフォーム基盤側とほぼ拮抗しています。しかも active の比率で見ると基盤系（377/490）の方が業務系（197/491）より高く、土台となる基盤機能から先に有効化されている作りだと読み取れます。
provider を全1418件見渡しても、サードパーティ（顧客）作成のプラグインは1件も見当たりませんでした。PDI は OOTB の検証環境なので当然ではありますが、自社で作ったカスタムプラグインが本番環境でこのビューにどう現れるかは今回確認できておらず、気になるところです。
v_plugin に licensable・license_category・license_model といったライセンス関連の固有フィールドが複数あるのも、フィールド一覧を眺めて初めて気づきました。個別の機能をON/OFFする単位だと思っていたプラグインに、利用権（エンタイトルメント）を管理する項目まで用意されているとは想像していませんでした。
sys_store_app だけ件数が取得できなかったのも印象に残りました。同じプラグイン関連のテーブルでも、v_plugin は API から自由に読めるのに、sys_store_app は 403 で弾かれます。テーブルごとに ACL の掛かり方が違うことを、実際にクエリを投げてみて初めて体感しました。調査の途中で「読めるはずなのに読めない」テーブルに出会ったら、まず ACL を疑うのがよさそうです。
次に読むなら
次に確認するなら、プラグイン有効化のログ（sys_plugin_log / sys_progress_worker）で有効化の成否を追う方法です。プラグインとスコープアプリ（sys_store_app / sys_scope）の結びつきも残っています。さらに Application Manager（All Available Applications）からの有効化フローも追いたいところです。特に「依存プラグインが連鎖的に有効化される」挙動の実体は、本記事の「依存関係（requires）」の先にあたり、別記事で扱う予定です。アプリ／スコープの土台は、関連記事「ServiceNow のアプリとスコープを実機で確認する」（sys_app / sys_scope / sys_metadata）も参照してください。
用語まとめ
PDI：Personal Developer Instance（無料の検証用インスタンス）
OOTB：Out of the Box（初期設定のまま）
プラグイン：機能パック。有効化（active）／無効化（inactive）の単位
v_plugin：利用可能なプラグインを見るビュー（System Definition ＞ Plugins）
sys_plugins：プラグインの物理側テーブル（sys_package を継承）
requires：依存プラグイン。依存先 id のカンマ区切り（Glide list → v_plugin）
com.snc.：業務アプリ系のプラグイン id プレフィックス
com.glide.：プラットフォーム基盤系のプラグイン id プレフィックス
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
プラグイン一覧 : v_plugin_list.do?sysparm_query=ORDERBYname
有効なプラグイン : v_plugin_list.do?sysparm_query=active=active^ORDERBYname
Incident プラグイン詳細 : v_plugin_list.do?sysparm_query=id=com.snc.incident
v_plugin フィールド : sys_dictionary_list.do?sysparm_query=name=v_plugin^elementISNOTEMPTY
プラグイン系テーブル : sys_db_object_list.do?sysparm_query=nameSTARTSWITHsys_plugin検証範囲とおことわり
確認した範囲：v_plugin / sys_plugins / sys_store_app の super_class、v_plugin の固有フィールド30とその意味（特に active が文字列であること、requires が Glide list → v_plugin であること）、v_plugin の全件1418・active 925・inactive 493、id プレフィックス（com.snc. 491 / com.glide. 490）と active 内訳（197 / 377）、provider の内訳、requires を宣言するプラグイン1117件と Incident（com.snc.incident）の依存内容、has_demo_data の件数。すべて PDI（Zurich / 2026-06-22 確認）の OOTB で取得しています。
確認していない範囲：sys_store_app のレコード件数（API レベルの ACL 403 で取得不能）、プラグイン有効化の実処理・ログ（sys_plugin_log / sys_progress_worker）、有効化時に裏で何が読み込まれるか（sys_update 等）の実体、依存プラグインの連鎖的な有効化の挙動、サードパーティ（顧客）プラグインの扱い、v_plugin と sys_store_app の実データ上の結合。これらは別記事で扱います。
今回は PDI の OOTB（初期設定）を前提に、プラグインのビュー・テーブル構造と active／依存を確認しました。実環境では、有効化済みプラグインによって件数・active 状態・依存の内容が変わります。
