[Brazil調査] アプリケーションサービスのロール：app_service_owner は PDI に無く、作成は app_service_admin

検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認
公式の差分ノートより：Use the app_service_owner role to grant create, read, update, and delete access to Service Instance records without granting the broader itil role.（訳：app_service_owner を使うと、広い itil ロールを付けずに Service Instance レコードの作成・参照・更新・削除を許可できます）

Brazil の公式差分ノートには、アプリケーションサービスのロールに関する記述が2つ載っています。変更（Changes）として app_service_owner が追加されること、廃止予定（Deprecations）として app_service_admin から itil が外れることです。アップグレードした PDI で確かめると、app_service_owner はロールとして存在せず、app_service_admin も itil を含んだままでした。試したロールの組み合わせの中でサービスを作成できたのは、この PDI では app_service_admin だけです。

画面で確かめた要点

• 公式の差分ノートは、app_service_owner の追加（変更）と、app_service_admin からの itil の削除（廃止予定）を載せています

• この PDI には app_service_owner のロール自体がありません

• app_service_admin は itil を含んだままです

• 作成と削除の ACL は、app_service_admin 本人に付いています

①が説明欄、②が含むロールです。説明欄は、作成と更新の対象が cmdb_ci_service_discovered（Mapped Application Service）だと示しています。②の含むロールは itil だけです。

アプリケーションサービスとは何か

公式は Service instances (Application services) で、アプリケーションサービスを「サービスを提供するために構成された、相互に接続されたアプリケーションとホストの集まり」と説明しています。同じページに、アプリケーションサービスは Service instance（サービスインスタンス）へ改称中で、両方の用語が併用されているとも書かれています。

構成する CI と CI 間の関係は CMDB に保存され、各サービスにはクライアントが入る地点である entry point（クライアントが到達する最上位の CI）があります。

サービスの種類と保存先

公式が挙げるサービスの種類は、保存先のテーブルと対応しています。

• Discovered：Service Mapping がパターンやトラフィックから発見する。保存先は Mapped Application Service［cmdb_ci_service_discovered］

• Dynamic CI Group：CMDB グループのメンバーでサービスを埋める。保存先は Dynamic CI Group［cmdb_ci_query_based_service］

• Tag-based：クラウドのタグから作る。保存先は Tag-based Application Service［cmdb_ci_service_by_tags］

• Dynamic Service：CI 間の関係の変化に合わせて自動で更新される。保存先は Calculated Application Services［cmdb_ci_service_calculated］

• Manual：entry point の CI を選び、CI を手で追加する。保存先は cmdb_ci_service_discovered

PDI のテーブル定義では、cmdb_ci_service_auto が Service Instance、cmdb_ci_service_discovered が Mapped Application Service、cmdb_ci_query_based_service が Dynamic CI Group でした。

作成方法ごとのロール

作成手順は Create a Service instance (application service) にあります。公式の記述では、必要なロールは方法ごとに次のとおりです。

• Manual（手順）：app_service_admin

• Dynamic Service（手順）：app_service_admin

• Dynamic CI Group（手順）：app_service_admin

• Top-Down Discovery（手順）：sm_admin

• Tags（手順）：sm_admin

メニューの場所は、公式の2つの手順に書かれています。既存サービスの変換手順は「All > Configuration > Application Services > Application Services」、マップの閲覧手順は「CSDM > Manage Technology Management Services > Application Service」です。

公式が書いているロールの変更点

Brazil 版の CMDB の差分ノート は、変更（Changes）に冒頭で引用した app_service_owner の追加を載せています。app_service_admin の itil の削除は、廃止予定（Deprecations）の Brazil の行に載っています。原文は次のとおりです。

（訳：app_service_admin ロールの中で、itil の代わりに sn_cmdb_editor と app_service_user が使われます。Service Instance の参照と Unified Map は引き続き使えますが、CI に紐づくインシデントや変更などの関連項目を見るには、引き続き itil が必要です）

公式のロール一覧

Control user access to application services は、標準で用意されるロールを次のように説明しています。

• app_service_admin：サービスインスタンスの作成と変更、サービスグループの作成、マップの閲覧と編集

• app_service_user：運用中のサービスインスタンスのマップの閲覧と、REST API でのコンテンツ取得。itil ロールがこのロールを含む

• service_mapping_admin：Service Mapping のセットアップと、サービスインスタンスのマッピングと保守

• service_mapping_user：運用中のサービスインスタンスのマップの閲覧

• sm_app_owner：サービスインスタンスのマッピングに必要な情報を提供し、結果を承認する

同じページの注記は、すべてのサービスインスタンスを参照できるのは sn_cmdb_editor か itil を持つユーザーだけ、としています。このページのロール一覧に、app_service_owner は載っていません。

マップの閲覧手順 には、app_service_user は表示モード、app_service_admin は編集モード、itil はマップ上のインシデント・問題・変更データの閲覧に必要とあります。この3つの役割分担が、itil を外す変更の影響範囲です。

この PDI のロール

ロールの一覧を見ると、app_service_admin と app_service_user はありますが、app_service_owner はありません。

①の2行が、このインスタンスにある app_service 系ロールです。②は絞り込み条件で、名前に app_serv を含むロールを探しています。

関連するロールは次のとおりです。

• app_service_admin：This role can create and modify application service maps (cmdb_ci_service_discovered)

• app_service_user：This role can view and retrieve information using API from application service maps (cmdb_ci_service_discovered)

• sn_cmdb_editor：CRUD access to CMDB records but not allowed to change policies such as data manager, class manager etc..

• sn_cmdb_user：Read-only access to the CMDB data and basic UIs

• sn_cmdb_admin：Highest level role for CMDB privileges

• sm_admin、service_mapping_admin、service_mapping_user、sm_app_owner：ロール名で検索しても見つかりませんでした

2つのロールの作成日はどちらも 2017-11-21、更新日は 2018-03-05 で、アップグレード後も変わっていません。含むロールは次のとおりです。

• app_service_admin：itil のみ

• app_service_user：dependency_views、cmdb_read、cmdb_query_builder_read

• sn_cmdb_editor：sn_cmdb_user などを含み、sn_cmdb_user が app_service_user を含む

差分ノートには、新規インスタンスだけの変更とは書かれていません。この PDI に変更が現れない理由は、公式の記述からは分かりませんでした。

app_service_admin を参照している ACL

app_service_admin を条件に持つ有効な ACL は113件あり、主なものは次のとおりです。

• 作成：cmdb_ci_service_discovered、cmdb_ci_service_auto、cmdb_ci_query_based_service、cmdb_ci_service_group

• 削除：cmdb_ci_service_discovered、cmdb_ci_query_based_service、cmdb_ci_service_group

• 更新：cmdb_ci_service_discovered の全項目、sa_notification、svc_ci_assoc、svc_rel_assoc

• 実行：Application service maps admin、CSDM Application Service External REST API、api/now/csdm_app_service

作成と削除は、サービス本体のテーブルでも app_service_admin だけが対象でした。参照は広く、cmdb_ci_service_discovered では dependency_views、app_service_user、sn_cmdb_user、itil も対象です。

実際に誰が何をできるか

ロールの包含関係と ACL だけでは、実際の可否は分かりません。そこでテスト用ユーザーにロールを付け、切り替えたうえで、テーブル単位の作成・更新・削除を GlideRecordSecure で調べました。試したのは、ロールなし、app_service_user、app_service_admin、sn_cmdb_editor と app_service_user の組み合わせの4通りです。

表の内容を文字でも書き出します。

• なし：サービス系テーブルは参照も含めて操作できない（インシデントの作成だけは可能）

• app_service_user：参照だけ。作成・更新・削除はできない

• app_service_admin：Mapped Application Service と Service Instance の作成・更新・削除ができる。itil 経由でインシデントと変更の更新もできる

• sn_cmdb_editor＋app_service_user：Mapped Application Service は更新だけ、Service Instance は更新と削除ができ、どちらも作成はできない。インシデントと変更は更新できない

• app_service_owner：ロールが存在せず付与できないため、テストできなかった

サービスの編集だけなら sn_cmdb_editor でも足ります。試した組み合わせでは、作成できたのは app_service_admin だけでした。公式どおり itil が sn_cmdb_editor と app_service_user に置き換わっても、作成と削除の ACL は app_service_admin 本人に付いています。このため作成権限は残ると考えられます。ただし ACL を読んだ結果からの推測で、itil を外した状態では確認していません。

自分のインスタンスで確かめる方法

次の3点は、読み取りだけで確認できます。

• app_service_owner があるか：/sys_user_role_list.do?sysparm_query=nameLIKEapp_service

• 各ロールが含むロール：/sys_user_role_contains_list.do?sysparm_query=role.nameLIKEapp_service

• 作成・削除の ACL に付いているロール：/sys_security_acl_role_list.do?sysparm_query=sys_user_role.name=app_service_admin

Scripts - Background で、1回で確かめることもできます。このスクリプトはレコードを変更しません。

var names = ['app_service_owner', 'app_service_admin', 'app_service_user'];
for (var i = 0; i < names.length; i++) {
  var r = new GlideRecord('sys_user_role');
  r.addQuery('name', names[i]);
  r.query();
  if (!r.next()) { gs.print(names[i] + ' : 存在しない'); continue; }
  var c = new GlideRecord('sys_user_role_contains');
  c.addQuery('role', r.getUniqueValue());
  c.query();
  var inc = [];
  while (c.next()) inc.push(c.contains.name + '');
  gs.print(names[i] + ' が含むロール = ' + inc.join(', '));
}

app_service_admin の含むロールに itil が出るなら、itil の置き換えはまだ適用されていません。app_service_owner が「存在しない」と出た場合は、公式どおりのロール構成にはなっていません。

実務でどのロールを付けるか

観察した結果と公式の記述を分けて、操作ごとにまとめます。

参照だけの担当者

• 観察：app_service_user で5つのサービス系テーブルを参照できました。書き込みはできません

• 公式：マップの表示モードに必要なロールとされています

既存サービスを編集する担当者

• 観察：sn_cmdb_editor と app_service_user の組み合わせで、更新ができました。作成はできません

• 公式：Brazil では app_service_owner が Service Instance の作成・参照・更新・削除を担う、とされています。この PDI にはロールがなく確認できません

サービスを新しく作る担当者

• 観察：試した組み合わせの中で作成できたのは app_service_admin だけです。このロールは itil を含み、インシデントや変更の更新権限まで広がります

• 公式：Manual、Dynamic Service、Dynamic CI Group は app_service_admin が必要です。Top-Down と Tags は sm_admin が必要で、この PDI にはそのロールがありません

動的サービスを編集する担当者

動的サービスは直接編集できず、CI を削除しても再計算で戻ります。恒久的に変えるなら cmdb_rel_ci の関係を更新する、というのが公式の説明です。編集権限を渡す前に対象が動的サービスかを確認すると、編集できない原因を切り分けやすくなります。

itil を外す変更への備え

公式どおりにロールが変わった環境では、app_service_admin から itil が外れます。インシデントや変更の関連項目をマップで見る担当者には、itil の追加付与が必要になります。

①の itil が、公式の変更で置き換わる行です。②は app_service_user が含む3つのロールです。移行前に、①の itil を経由して権限を得ている担当者を棚卸ししておくと、変更後に権限が足りなくなる範囲を確認できます。

実機を見て気づいたこと

公式の変更がそのまま現れるとは限らない

差分ノートに載っている app_service_owner は、アップグレードした PDI には存在しません。ロール変更の計画を立てる前に、自分のインスタンスの sys_user_role で名前を検索してください。

サービス担当者への権限が広がりやすい

app_service_admin を1つ付けただけで、itil に連なる多数のロールが自動で追加されました。サービス担当者に渡したつもりの権限が、インシデントや変更の更新まで広がります。公式の廃止予定は、この広がりを抑える方向のものと読めます。

用語

• アプリケーションサービス（Service instance）：サービスを提供する CI と関係の集まり。公式は改称中で、両方の呼び名が使われる

• entry point：クライアントがサービスへ到達する最上位の CI。URL か IP アドレスとポートの組み合わせが一般的

• ACL：テーブルや項目への操作を許可する条件。ロールを条件に持つものが多い

• ロールの包含：上位のロールを付けると、含まれるロールが自動で付く仕組み。sys_user_role_contains で確認できる

• GlideRecordSecure：ACL を適用したうえでレコードを扱う API。canCreate などで操作の可否を調べられる

参照した公式ページ

• CMDB の差分ノート（Australia から Brazil）：2つのロール変更の出典

• Service instances (Application services)：サービスの種類と保存先

• Control user access to application services：標準ロールの説明

• View an application service map in base system：マップ閲覧に必要なロール

• Convert legacy manual services to dynamic application services：メニューの場所と、動的サービスを直接編集できない点

検証範囲とおことわり

• 検証は、Australia から Brazil へアップグレードした PDI 1つで行いました。新規のインスタンスは確認していません

• ロールの包含関係と ACL は読み取りだけで、設定は変更していません

• 権限テストは、メールアドレスを設定していないテスト用ユーザーを5名作成して確認し、終了後に削除しました。作成時に通知デバイスが自動で作られるため、削除後に sys_user、sys_user_has_role、cmn_notif_device へ残りがないことも確認しています

• 権限の可否は、空の GlideRecordSecure に対するテーブル単位の canCreate などで評価しました。個々のレコードの可否は確かめていません

• 試したロールの組み合わせは、ロールなし、app_service_user、app_service_admin、sn_cmdb_editor と app_service_user の4通りです

• 確認したテーブルは cmdb_ci_service_discovered、cmdb_ci_service_auto、cmdb_ci_query_based_service、cmdb_ci_service_group、cmdb_rel_ci、incident、change_request です。画面操作の可否は確かめていません

• Service Mapping 系のロールはこの PDI で見つからず、Top-Down と Tags の作成権限は確認していません

• app_service_owner は存在しないため、動作は未確認です

• itil を外した app_service_admin の挙動は未確認です

関連記事

• サービスもCIになる（cmdb_ci_service）

• ServiceNowのCMDBは何がどこに入っている？ CI・関係・サービスを実機で数える