Access Analyzer：「見えない」の理由を層で切り分ける
「ロールを付けたのに、あの画面が見えないと言われました」。ServiceNow の運用で、いちばん時間を取られる相談のひとつです。
原因の候補は多いのです。ACLの条件、ロールの不足、データフィルタ。加えてアクセスハンドラや、ACLの中のスクリプトもあります。どれが効いているのかを人が追うのは骨が折れます。
Access Analyzer は、この切り分けを機械にやらせる管理ツールです。今回は実機で解析リクエストを作りながら、この機能が何を層に分けて見せてくれるのかを確認します。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・項目は REST と実画面で確認しました（確認日 2026-07-26）。本番環境では設定が異なります。
メニューの4つはすべてUXページ
アプリケーションメニュー「Access Analyzer」の下には、モジュールが4つあります。
実測すると、4つとも link_type が「URL (from Arguments)」でした。クラシックのテーブル一覧ではなく、now/access-analyzer/... という UX（Next Experience）のページ を指しています。
3つの名前には、外部を開くことを表す右上向きの矢印アイコンが付いています。別画面へ飛ぶ印で、従来のフォーム画面とは操作感が違うことを示しています。
画面を開く
/now/access-analyzer/home を開きました。
見出しは Analyze access and permissions。サブタイトルには「View permissions for a selected user, role, group, or compare access for two users」とあります。
上部のタブは3つでした。Analyze Permissions / Access Simulator / Settings。そして中のタブも3つ。Evaluate access / Compare user records / Compare user access。
Evaluate access の説明は「Evaluates permissions for a selected user, role, or a group」。ひとりの利用者、あるいはロールやグループの権限を評価する画面です。
入力欄は素直でした。Analyze by（既定は User）/ Select user / Rule type（既定は Table (record)）。続いて Select table / Select record / Select field / Short description。そして「Evaluate access」のボタンです。
右側には「How to evaluate access」というチュートリアル動画と、Helpful Resources のリンクが並びます。管理ツールとしては親切な作りです。
画面の下部には Previously searched criteria（過去の条件）という欄もありました。同じ調査を繰り返すときに、条件を選び直さずに済みます。
解析リクエストの中身を読む
画面で入力した内容は、sn_access_analyzer_request というテーブルに1件として残ります。フィールドを見ると、この機能がどこまで調べられるかが分かります。
analyze_by は3択。User / Group / Role。個人だけでなく、ロールやグループの単位でも調べられます。「このロールを持つと何ができるようになるか」を確認する使い方です。
resource_type は4択でした。record / client_callable_script_include / ui_page / rest_endpoint。
テーブルのレコードだけでなく、クライアントから呼べる Script Include、UIページ、REST エンドポイントまで対象になります。ACLはテーブルだけの話ではないので、この4つが揃っているのは実用的です。
operations は sys_security_operation への複数選択でした。read / write / create / delete のほかに、細かい操作も並びます。report_view / list_edit / add_to_list / personalize_choices など。
evaluated_using は2択。evaluate_access（評価）と compare_access_control（比較）。画面のタブと対応しています。
実際に1件作ってみる
REST でリクエストを作りました。Abel Tuter という利用者が incident テーブルに対して read / write / create / delete をできるか、という内容です。
作成は成功しました。ただし、この時点で結果テーブル（sn_access_analyzer_access_result）は 0件のまま です。
last_run フィールドも空でした。リクエストを作っただけでは解析は走りません。画面の「Evaluate access」ボタンを押して初めて実行される設計です。
条件を保存しておいて、必要なときに実行する。過去の条件が画面下部に並ぶのは、このリクエストのレコードが溜まるからでした。
結果は「層ごと」に記録される
この機能のいちばんの見どころが、結果テーブルのフィールド構成です。
sn_access_analyzer_access_result は、判定を1つの結論として持ちません。層ごとに分けて持ちます。
acl_result … ACL の判定
accesshandler_result … アクセスハンドラの判定
datafiltration_result … データフィルタの判定
script_execution … スクリプトの実行結果
record_available … そもそもそのレコードが届いているか
read_only_field … 読み取り専用フィールドかどうか
admin_override_applied … admin による上書きが効いたか
overall_access … 全体としての結論
この分け方が、調査の時間を大きく縮めます。
「見えない」という相談を受けたとき、原因は複数の層のどこかにあります。ACLで弾かれたのか、データフィルタで行が絞られたのか、ACLの中のスクリプトが false を返したのか。人が追うなら、それぞれを別々に確認する必要があります。
Access Analyzer は1回の実行で、すべての層の判定を並べて返します。どこで止まったかが一目で分かる形です。 これが「解析ツール」と呼ばれる理由です。
admin で試すと通る問題
admin_override_applied というフィールドがあるのも実務的です。
調査のとき、admin 権限で試すと問題なく見えてしまう。よくある落とし穴です。admin はほとんどのACLを飛び越えるので、利用者と同じ結果になりません。
このフィールドがあれば、「admin の上書きが効いた結果である」ことが記録に残ります。判定を読むときに、それが本当の権限なのか admin の特権なのかを区別できます。
操作ごとに1行
結果は operation フィールドを持ち、操作ごとに1行になります。read はできるが write はできない、という状態が行ごとに分かれて記録されます。
「一覧には出るが編集できない」という相談は、read が通って write が止まっている状態です。操作を分けて記録するからこそ、この違いが見えます。
3つのタブの使い分け
画面の3つのタブは、調査の種類で分かれていました。
Evaluate access は、ひとりの権限を調べます。「この人はこれができるか」。いちばん基本の使い方です。
Compare user records は、同じ人が複数のレコードにアクセスできるかを比べる画面。「同じテーブルなのに、このレコードだけ見えない」という相談に使えます。データフィルタや条件つきACLの影響を見分けられます。
Compare user access は、2人の利用者を比べます。「同僚は見えるのに自分だけ見えない」という相談に、これが効きます。ロールの差なのか、グループの差なのか、条件の差なのか。2人の判定を並べれば、違いが浮かびます。
比較用のテーブル（sn_access_analyzer_access_comparison_request）が別に用意されているのも、この機能が独立していることの表れです。評価と比較で保存する内容が違うため、テーブルを分けたと読めます。
3つの使い分けは、相談の言い方でだいたい決まります。「これができない」なら Evaluate access。「このレコードだけ見えない」なら Compare user records。「あの人はできるのに」なら Compare user access。相談者の言葉をそのままタブの選択に使えます。
過去の条件は別画面で見る
モジュールの2つめ「Access Analyzer Queries」は、now/access-analyzer/queries を指します。
保存された解析条件の一覧です。実体は sn_access_analyzer_request テーブルなので、クラシックの一覧からも同じものが見られます。
同じ調査を何度もするなら、この一覧が効いてきます。「先月と同じ条件で、ロールを付けた後の状態を確認する」といった使い方です。条件を再入力せずに済むので、確認の手間が減ります。
Access Simulator は「もし」を試す
上部タブの Access Simulator は、この記事では中身を確認していません。名前から読めるのは、「ロールを追加したらどうなるか」を実際に付与せずに試す機能だということです。
権限の相談で難しいのは、解決策の検証です。「このロールを足せば見えるはず」と思っても、付けてみるまで分かりません。付けて間違っていれば、外す手間と、その間に見えてしまったデータの問題が残ります。
付けずに試せるなら、この危険を避けられます。実測では未確認ですが、設計の意図としては筋が通っています。
ACLの一覧と行き来する
Access Analyzer はどこで止まったかを教えてくれますが、直すのは元のACLです。
sys_security_acl を対象テーブルで絞ると、そのテーブルに効いているACLが並びます。operation ごとに複数のACLが定義されていて、それぞれが必要なロールと条件を持ちます。
ACLの評価は、テーブル単位・フィールド単位・レコード単位が重なって効きます。「テーブルのreadは通るが、あるフィールドのreadで止まる」という状態も起こります。この重なりを人が読み解くのが難しいからこそ、解析ツールが用意されているわけです。
調査の流れとしては、Access Analyzer で層を特定し、ACLの一覧で該当するルールを見つけ、条件やロールを直す。直したらもう一度 Access Analyzer で確認する。この往復で完結します。
ロールを足す前に考える
「見えないならロールを足せばいい」は、いちばん安易な解決です。ただしロールは、そのテーブルだけでなく他の多くのACLにも効きます。1つの相談を解決するために付けたロールが、意図しない範囲まで開けてしまうことがあります。
Access Analyzer で原因を層まで特定できていれば、別の解き方も見えてきます。条件を直す、グループに入れる、データフィルタを調整する。ロールを足すのは、それらで解けないときの選択肢にします。そのほうが後始末が軽く済みます。
analyze_by に Role を選べるのは、この判断のためでもあります。「このロールを付けると何ができるようになるか」を先に確認してから付ける。順番を守れば、後始末が減ります。
なぜ層に分けるのか
ServiceNow のアクセス制御が層になっているのは、それぞれが別の目的を持つからです。
ACL は「このロールを持つ人に、この操作を許す」という基本の取り決めです。テーブル・フィールド・レコードの単位で定義でき、条件やスクリプトも書けます。実務で触る機会がいちばん多いのがこの層です。
データフィルタは行を絞ります。「自分の部署のレコードだけ見える」といった制限は、ACLの条件でも書けますが、データフィルタのほうが宣言的に書けます。
アクセスハンドラは、独自の判定処理を差し込む口です。標準の仕組みで表せない要件に使います。
スクリプト実行は、ACLの中に書いたスクリプトの結果です。条件では表せない判定を書けますが、読みにくくなりがちです。
4つが重なると、どこで止まったのか分からなくなります。だから Access Analyzer は、結論を1つ返すのではなく、層ごとの判定を並べて返す。「見えない」ではなく「どの層で止まった」まで返すのが、このツールの価値です。
実務で気をつけるところ
まず overall_access、次に層を見る
結果を読む順番は決まっています。最初に overall_access で結論を確認し、それが期待と違うなら層のフィールドを順に見る。
層を先に読むと、どれが決め手だったのかを見失います。結論から入って、原因へ降りていくのが早道です。
admin で調査しない
繰り返しになりますが、admin で画面を開いても利用者の見え方は分かりません。Access Analyzer なら、対象の利用者を指定して調べられます。
admin_override_applied を確認する習慣をつけておけば、誤った結論を出さずに済みます。
対象はテーブル以外にもある
ACLの調査というとテーブルとフィールドに目が行きますが、resource_type には UI ページ、REST エンドポイント、Script Include も含まれます。
「APIを叩くと403が返る」という相談は、テーブルのACLではなく REST エンドポイント側の問題であることがあります。対象の種類を選べることを覚えておくと、調査の当てが増えます。
相談を受けたら、まず対象を特定する
Access Analyzer を使うには、誰が・何に・どの操作を、を決める必要があります。この3つが曖昧なままでは実行できません。
実は、ここが調査でいちばん大事な工程です。「見えない」という相談は、たいてい曖昧です。どの画面か、どのレコードか、閲覧なのか編集なのか。聞き取りの段階で3つを確定させれば、あとはツールが答えを出します。
逆に言えば、Access Analyzer の入力欄そのものが聞き取りのチェックリストになります。Analyze by / Select user / Rule type。続けて Select table / Select record / Select field。この順に埋められれば、相談は調査可能な形になっています。
現場では「とりあえず admin に聞いてみる」で止まることが多いものです。入力欄を埋める形で聞き取れば、相談者自身も状況を整理できます。調査の道具が、そのまま会話の型としても使えるわけです。
結果は保存される
解析リクエストがテーブルに残るので、過去の調査を再現できます。同じ相談が繰り返し来る場合、条件を保存しておけば毎回入力し直さずに済みます。
「Previously searched criteria」の欄は、そのための入口でした。監査で「この時点でこの人は何が見えたか」を示す必要があるとき、記録が残っていれば説明が早くなります。
どこから触るか
/now/access-analyzer/home … 権限の評価・比較（UXページ）
/now/access-analyzer/queries … 過去の解析条件
/sn_access_analyzer_request_list.do … 解析リクエストのテーブル
/sn_access_analyzer_access_result_list.do … 結果のテーブル
/sys_security_acl_list.do?sysparm_query=name=incident … 対象テーブルのACL一覧
Access Analyzer で原因の層が分かったら、ACLの一覧に戻って現物を確認する。この往復で調査が完結します。
まとめ
Access Analyzer は、権限の「見えない」を層で切り分けるツールでした。
メニューの4つはすべてUXページを指し、実際の操作は /now/access-analyzer/home で行います。調べる対象は User / Group / Role の3種類、対象の種類は record / Script Include / UIページ / REST エンドポイントの4種類。
結果は ACL / アクセスハンドラ / データフィルタ / スクリプト実行の層ごとに記録されます。そのうえで overall_access に全体の判定が出る。admin の上書きが効いたかどうかも別フィールドで残ります。
リクエストを作っただけでは解析が走らず、画面のボタンで実行する設計でした。条件がテーブルに残るので、繰り返す調査ほど楽になります。
用語
Access Analyzer … 権限の判定を層ごとに分解して見せる管理ツール
analyze_by … 誰の権限を見るか。User / Group / Role
resource_type … 何に対する権限か。record / Script Include / UIページ / REST エンドポイント
overall_access … 全体としての判定結果
acl_result / accesshandler_result / datafiltration_result … 層ごとの判定
admin_override_applied … admin の特権で通ってしまったかどうか
Access Simulator … ロールを付けずに「もし付けたら」を試す画面
自分の環境で確認するときのURL
/now/access-analyzer/home（評価画面・3つのタブ）
/now/access-analyzer/queries（過去の解析条件）
/sn_access_analyzer_request.do?sys_id=...（作成した解析リクエスト）
/sn_access_analyzer_request_list.do（リクエスト一覧）
/sys_security_acl_list.do?sysparm_query=name=incident（incident のACL）
実測の要点（再掲）
メニューのモジュール4つは、すべて now/access-analyzer/... のUXページを指す
関連テーブルは4つで、いずれも標準では0件
analyze_by は User / Group / Role、resource_type は4種類、evaluated_using は2種類
解析リクエストを1件作成したが、結果テーブルは0件のまま。last_run も空
結果は ACL / アクセスハンドラ / データフィルタ / スクリプト実行 の層ごとに分かれて記録される
admin_override_applied があり、admin の特権で通った場合が区別できる
検証範囲とおことわり
件数・項目・選択肢は PDI（Zurich / OOTB）の実測です。本番環境の設定とは異なります。
画面の「Evaluate access」ボタンは押していません。結果テーブルは0件のまま、フィールド構成の確認までです。
Access Simulator と Settings タブの中身は未確認です。名前からの読み取りを含みます。
sn_access_analyzer_debug_log は0件で、デバッグログの中身は未検証です。
この記事のために解析リクエストを1件作成しました。デモ用のレコードです。
