ServiceNowでadminを配らずに開発させるには？ Delegated Developmentで権限を絞る
「このアプリだけ触らせたいのに、adminを渡すしかない」という相談はよく聞きます。adminは全スコープ・全テーブルに届くため、退職時の回収漏れや誤操作の範囲まで考えると渡しづらい相手です。ServiceNowにはDelegated Developmentという仕組みがあります。delegated_developerロールと26種類のDevelopment Permission Setを組み合わせ、誰にどの作業を許すかをアプリ単位・作業単位で絞り込めます。Zurich PDIで実際のロールとPermission Setを開いて確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-09 確認
結論：委譲はロールとPermission Setの掛け算で決まる
先に全体像です。
ServiceNowにはdelegated_developerという開発委譲専用のロールがOOTBで用意されています。ただしこのロールを付与しただけでは何も起きません。
実際に何をさせるかは、Development Permission Set（sys_development_permission_set）という26種類の許可単位で決まります。Script Edit、Source Control、Manage Update Setのように、作業の種類ごとに分かれています。
「そのスコープの中で何をしてよいか」と「そのスコープのコードが他のスコープを呼んでよいか」は別の仕組みです。後者はCross scope privilege（sys_scope_privilege）が管理しており、今回のPDIで922件、すべてAllowedでした。
公式ドキュメントにもDelegated Developmentという独立した章があります。Delegated development and deployment（Zurich）を起点に、有効化・権限設定・管理者向け操作・リファレンスの4段階に分かれる構成です。まずはPDI側の実データから、この仕組みがどう組まれているかを追います。
図の色は状態の違いを示します。濃紺は設定の起点になるadmin、水色はadminが行う2つの設定（ロール付与とPermission Set割り当て）です。緑は許可された範囲、赤は許可されていない操作、灰はそもそも対象外になる範囲を表します。この後の節で、それぞれのレコードを実機で1つずつ見ていきます。
なぜadminをそのまま配ると困るのか
開発を任せたい相手は、たいてい「このアプリのスクリプトを直したい」「このアプリのUpdate Setを作りたい」という限定的な要望を持っています。ところがadminロールには範囲という概念がありません。付与した瞬間から、関係のない他のアプリやシステムプロパティ、ユーザー管理まで手が届きます。
小規模な組織では「信頼できる人だから」で済ませてしまうこともありますが、退職や異動でロールを外し忘れると、権限だけが残り続けます。監査のときに「なぜこの人がadminを持っているのか」を説明できない状態は、それ自体がリスクです。開発を任せる範囲と、そのために本当に必要な権限を、最初から一致させておく方が後で楽になります。
delegated_developerというロールがすでに用意されている
ServiceNowには、この目的のためにdelegated_developerというロールがOOTBで存在します。
フォームで確認できる値は次のとおりです。
Application: Global（特定のスコープに属さない、共通のロール）
Elevated privilege: false（昇格なしの通常セッションで有効）
grantable: true（管理者以外にも付与できる）
can_delegate: true（このロールを持つ人が他人にロールを配ってよいかという、汎用の委任フラグ）
scoped_admin: false（特定スコープの管理者ではない）
このロールを保有しているユーザー数はこのPDIで0人でした。ロール自体はOOTBに入っていても、実際に配られてはいない状態です。
can_delegateという項目名を見て、Delegated Developmentのオンオフだと勘違いしそうになりましたが、これは別機能です。詳しくは次の節で触れます。
似た名前のロールが他に2つある
「delegate」という単語を含むロールを検索すると、delegated_developer以外に2件見つかりました。
delegation_admin（Can manage granular delegation, including delegation rules）… 承認などのレコードを別の人に委任する機能（Granular Delegation）の管理者ロールです。開発権限とは無関係です。
role_delegator（Can delegate roles to group members）… グループのメンバーへロールを配る権限です。これも開発とは別の話です。
同じ検索条件で、scoped_admin（Application Administrator）がtrueのロールも4件見つかりました。sn_employee.adminのように「特定アプリだけの管理者」を表すロールで、こちらはDelegated Developmentよりも古くからある仕組みです。Permission Setで作業を絞るDelegated Developmentと、アプリ単位で管理者権限そのものを切り出すscoped_adminは、目的が近いようで設計は別物だと分かります。
何を許すかはDevelopment Permission Setが26種類に分けている
delegated_developerロールに実質を与えるのが、Development Permission Set（sys_development_permission_set）です。
このPDIには26件登録されていました。typeで分類すると、Permission Restricted（15件）が最も多く、Deployment（5件）、Application Management（3件）と続きます。残りのScript Editing・Security Management・All Metadata・Delegated Adminは、それぞれ1件ずつでした。名前を見るだけでも、Script EditやSource Control、Manage Update SetやDelete Applicationのように、作業の単位で分かれていることが伝わります。
Application-specific permissions（Zurich）は、このPermission Setの考え方を扱うページです。
Script Editを開くと、許可される中身が見える
Permission Set 1件をクリックすると、その中身がさらに細かいレコードへ展開されます。
Script Editを開くと、Development Permissionsという関連リストに11件のレコードがありました。resource_pathはmodule/<sys_id>のような形式です。descriptionには「Studio Module」や、System DiagnosticsやSystem Logs配下のモジュール名がそのまま入っていました。Script Editという1つの許可は、スクリプトエディタを開けるかどうかだけの話ではありません。関連する診断・ログ系のモジュールまで含めた単位で管理されています。Development Permission全体は654件あり、26個のPermission Setに振り分けられていました。
「Delegated Admin」という特別な枠もある
26件のうち1件は、そのままDelegated Adminという名前でした。typeも専用のDelegated Adminです。他の25件が「Script編集」「ソース管理」のように作業を絞っているのに対して、この1件だけは名前からして「そのスコープの中では管理者に近い権限を渡す」枠だと読み取れます。委譲する相手の信頼度に応じて、細かい作業単位の許可と、この広い枠を使い分ける設計だと考えられます。
誰にどのアプリを許すかは、この1件のレコードで決まる（はず）
ロールとPermission Setをつなぐのが、Scope Permission Set Role Assignment（sys_scope_permission_set_role_assignment）です。フィールドはscope（→sys_scope）・role（→sys_user_role）・permission_set（→sys_development_permission_set）の3つです。ユーザーへの参照は持っていません。
このPDIでは0件でした。OOTBのまま何もしなければ、どのスコープにもこの対応表は存在しません。フィールド構成から読み取れる設計は「スコープSでロールRを持つ人には、Permission Set Pを与える」という3項の対応で、個人名は登場しません。ここから逆算すると、委譲開発者にするユーザーには、まずロールを付与します。そのうえで対象スコープにおいて、ロール×Permission Setの組をこの表に登録するという2段階が必要になりそうです。実際のクリック手順まではレコードを書き換える検証が必要になるため、今回は確認していません。手順そのものはDelegating development permissions（Zurich）にまとまっているようです。
機能自体もデフォルトでは有効になっていない可能性があります。公式ドキュメントにはActivate Delegated Development（Zurich）という有効化専用のページがあり、今回の0件という結果とも符合します。
スコープをまたぐ呼び出しは別の仕組みが管理する
Permission Setで許可されるのは「そのスコープの中でできること」です。委譲された開発者が書いたコードが別のスコープのテーブルやAPIを呼びたいときは、別の許可が必要です。
Cross scope privilege（sys_scope_privilege）は5つの項目で構成されています。source_scope（呼び出す側）・target_scope（呼ばれる側）・target_name（対象のテーブルやAPI名）の3つで、呼び出し先を特定します。operationはread/write/create/delete/executeのいずれか、statusはrequested/denied/allowedのいずれかです。今回のPDIには922件登録されており、statusはすべてallowedでした。requested（未承認）やdenied（却下）は1件もありません。ServiceNow製の標準アプリ同士では、必要なクロススコープ呼び出しがあらかじめ承認済みの状態で出荷されているようです。
アプリのレコード自体（sys_scope）にも、Application administrationというチェック（scoped_adminと同じ意味の項目）があります。委譲された開発者に強い権限を渡しても、この2つの壁（Permission Setの範囲とCross scope privilegeの許可）は別々に存在し続けます。1つを緩めても、もう1つが自動的に緩むことはありません。
委譲された開発者にできること・できないこと
ここまでの内容を、admin・委譲された開発者・一般ユーザーで並べます。
委譲された開発者は、割り当てられたPermission Setの分だけ動けます。Script Editを持っていればスクリプトを直せますが、Delete Applicationを持っていなければアプリの削除はできません。システム全体のプロパティ変更のように、スコープという概念自体が存在しない設定は、Permission Setをいくら積んでも対象外です。
実機で気づいたこと
delegated_developerロールを付与しただけでは、何も開発できるようにならないという点が最初の驚きでした。Scope Permission Set Role Assignmentが0件のままなら、ロールは名前だけの状態です。ロール単体で機能が完結するsys_user_has_roleの世界とは、権限の効き方が違います。
「delegate」を含むロールが3つあり、それぞれ別の機能を指している点も紛らわしいと感じました。delegated_developerは開発権限の委譲、delegation_adminは承認などのレコード委任の管理、role_delegatorはグループメンバーへのロール委任です。英語のdelegateという単語をServiceNowが複数の機能で使い回しているため、ロール名だけで検索すると意図しないロールにたどり着く危険があります。
Script Editのようなシンプルな名前のPermission Setが、内部では11件ものリソースパスに展開されていたのも意外でした。単に「スクリプトエディタを開けるか」ではなく、System Diagnosticsの関連モジュールまで含めた単位で管理されています。名前から想像する範囲より、実際の許可範囲は広めに設計されているようです。
Cross scope privilegeが922件、すべてAllowedだったことにも気づきがありました。ゼロから承認する仕組みだと思っていましたが、ServiceNow製アプリ同士のやり取りはあらかじめ承認済みの状態で配布されています。新しく承認が必要になるのは、カスタムアプリが標準アプリの機能を呼びたいときだけのようです。
実務での使い方
委譲する相手が固まったら、まず「その人が本当に必要とする作業」をPermission Setの単位で洗い出します。Script Editだけで足りるのか、Update Setの公開まで任せたいのかで、渡すPermission Setの数は変わります。最初は少なめに渡して、足りない操作が出るたびに追加する方が、後から回収するより安全です。
Delegated Adminという広い枠は、信頼できる少数の相手に限定した方がよさそうです。個々のPermission Setを積み上げる代わりにこの1件を渡すと、実質的にそのスコープの管理者になるためです。
複数のアプリを1人に任せたい場合は、アプリごとにScope Permission Set Role Assignmentを作る必要がある点も踏まえておきます。1つのアプリで許可した内容が、別のアプリに自動的に引き継がれることはありません。
つまずきやすい点
delegated_developerロールを付与しただけで安心してしまい、Permission Setの割り当てを忘れる。ロールだけでは何も起きません。
delegation_adminやrole_delegatorと名前が似ているため、目的と違うロールを付与してしまう。
Permission Setはスコープごとの個別設定です。あるアプリで許可した内容は、別のアプリには引き継がれません。
委譲された開発者が別スコープのAPIを呼ぼうとして失敗したとき、原因をPermission Set側だけで探してしまう。実際にはCross scope privilegeの承認が別途必要です。
Delegated Adminのような広い枠を、細かい単位のPermission Setと同じ感覚で複数人に配ってしまう。
まとめ
adminを配る以外の選択肢として、Delegated Developmentという仕組みがOOTBに用意されています。delegated_developerロールとDevelopment Permission Setの組み合わせで、開発を任せる範囲を作業単位まで絞り込めます。スコープの中でできることと、スコープをまたいでできることは別々の仕組みで管理されているため、委譲する際は両方を意識しておくと迷いません。
用語
Delegated Development: adminロールを渡さずに、特定スコープ内の開発作業だけを許可する仕組み
delegated_developer: 委譲開発者向けに用意されたOOTBロール（単体では機能しない）
Development Permission Set（sys_development_permission_set）: 開発作業を種類別に束ねた許可の単位。26種類
Development Permission（sys_development_permission）: Permission Set 1件が展開される個々のリソースパス
Scope Permission Set Role Assignment（sys_scope_permission_set_role_assignment）: スコープ×ロール×Permission Setの対応レコード
Cross scope privilege（sys_scope_privilege）: 別スコープのテーブル・APIを呼ぶための許可
Application Administrator（scoped_admin）: ロールに付く、特定スコープの管理者フラグ
実機で調べるときに開いたURL
/sys_user_role.do?sys_id=<delegated_developerのsys_id> … delegated_developerロールのフォーム
/sys_user_role_list.do?sysparm_query=nameLIKEdelegat^ORscoped_admin=true … delegate系・scoped_admin系ロールの一覧
/sys_development_permission_set_list.do … Development Permission Setの一覧（26件）
/sys_development_permission_set.do?sys_id=<Script Editのsys_id> … Script Editの中身（Development Permissions関連リスト）
/sys_scope_permission_set_role_assignment_list.do … スコープ×ロール×Permission Setの割り当て一覧
/sys_scope_privilege_list.do?sysparm_query=source_scope.name=Clone Admin Console … Cross scope privilegeの実例
/sys_scope.do?sys_id=<Process Automation Contentのsys_id> … Application（Store Application）フォーム
よくある質問
Q1. delegated_developerロールを付与すれば、それだけで開発できるようになりますか
いいえ。今回のPDIでは、このロールに紐づくScope Permission Set Role Assignmentが0件でした。ロールを付与しただけでは何も開けるようになりません。対象スコープでロールとPermission Setの組を登録する作業が別途必要です。
Q2. Application Administrator（scoped_admin）とDelegated Developmentはどう違いますか
scoped_adminはロール自体に付くフラグで、「そのスコープの管理者かどうか」という静的な区分です。今回のPDIでは4件見つかりました。Delegated Developmentは同じ管理者的な立場でも、Script EditやSource Controlのように作業単位でPermission Setを選べる、より細かい仕組みです。
Q3. 委譲された開発者は他のアプリのテーブルを読み書きできますか
直接はできません。別スコープのテーブルやAPIを呼ぶコードには、Cross scope privilege（sys_scope_privilege）でのAllowedが別途必要です。今回のPDIでは922件が登録され、すべてAllowedでした。委譲された開発者のPermission Setがどれだけ広くても、この許可がなければ他スコープには届きません。
Q4. delegated_developer、delegation_admin、role_delegatorは同じ機能ですか
いいえ、名前は似ていますが別の機能です。delegated_developerは開発権限の委譲、delegation_adminは承認などのレコード委任（Granular Delegation）の管理を指します。role_delegatorはグループメンバーへのロール委任で、この3つは対象がそれぞれ違います。付与するときはdescriptionまで確認しておくと安全です。
Q5. Permission Setを1つ選ぶと、何が許可されますか
Permission Set 1件は、複数のリソースパス（モジュールやレコード）に展開されます。たとえばScript Editは11件のリソースパスに紐づいており、System Diagnostics関連のモジュールなども含まれていました。Development Permission全体では654件あり、26個のPermission Setに振り分けられています。
さらに詳しく知りたい人へ
アプリとスコープ：Globalとx_の違い（sys_app） — スコープそのものの構造を詳しく見る
ServiceNowの権限は誰が持っている？ ユーザー・グループ・ロールを中間表からたどる — ロール付与の基本の仕組み
ロールを付けたのに見えない理由：ACL（sys_security_acl） — Permission Setで許可した後もACLが評価される
参考リンク
検証環境と未検証範囲
件数はZurich PDI（OOTB）で2026-08-09に確認したものです。本番環境やカスタマイズ済み環境では、登録されているPermission Setの数やCross scope privilegeの件数が異なります。書き込み（レコード作成・更新）は一切行っていません。
確認した範囲は次のとおりです。
delegated_developerロールのフィールド値と、保有ユーザー数（0人）
「delegate」を含む・scoped_adminなロール7件の一覧と、それぞれの役割の違い
Development Permission Set 26件の内訳、Development Permission 654件（Script Editの11件を実例確認）
Scope Permission Set Role Assignmentが0件であること
Cross scope privilege 922件（すべてAllowed、うち71件をClone Admin Console起点で実例確認）
sys_scope 725件、can_edit_in_studio=true 85件
確認していない範囲は次のとおりです。
Studio内で実際にユーザーを委譲開発者として追加する操作手順（レコード作成を伴うため未実施）
delegated_developerロールとPermission Setを実際に紐づけた状態でのStudio上の表示
ACLとの評価順序、Permission Setを与えた後にACLで弾かれるケースの詳細
App Collaboration（Editor/Owner）など、ストア公開時の別のコラボレーター機能
本番環境でのカスタムロール設計、ドメイン分離環境での挙動
