この記事で得られること
ServiceNowのACLは、慣れないうちは「なぜ見えないのか」「なぜ更新できないのか」がブラックボックスに見えがちです。CSAの学習でも、用語だけ覚えても実感が湧かず、問題文の条件が少し変わっただけで手が止まることがあります。
この記事では、ACLでつまずく人にありがちな共通パターンを先に押さえ、そこから逆算して「どう考えれば迷いが減るか」を整理します。暗記ではなく、仕組みの理解を軸にするので、実務のトラブルシュートにもそのまま使えるはずです。
なお、ACLの基本は「ユーザーが対象のデータや操作にアクセスする前に、いくつかの要件チェックを通過する必要がある」という考え方です。公式ドキュメントでも、ACLはユーザーがデータに触れる前に要件を満たす必要がある仕組みとして説明されています。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
ACLでつまずく人の共通パターン 全体像
最初に結論から言うと、ACLでつまずく原因はだいたい次のどれかに集約されます。
仕組みをロールだけで説明しようとする
ACLはロールだけで完結しません。公式のACL作成手順でも、Requires roleだけでなく、条件やスクリプトを組み合わせて評価する前提が整理されています。
「ロール付けたのに通らない」場合、ロール以外の条件がどこかで落ちている可能性が高いです。
テーブルとフィールドのレベル感が曖昧
ACLは「テーブル」「フィールド」「レコード」など粒度があり、同じincidentでも、テーブル全体のreadと、incident.short_descriptionのreadは別物として扱われます。公式の解説でも、テーブルやフィールドなど対象を区別して定義する流れが示されています。
ここが曖昧だと、問題文の読み違いが起きやすいです。
ワイルドカードに逃げてしまう
「とりあえず . を触る」「とりあえず *.field を作る」みたいな雑な近道をすると、あとで原因不明の副作用が出ます。公式でも、Nameでアスタリスクを使える一方で、適用条件に制約があることなど、扱いの注意点が明示されています。
管理者で試してしまい、実際の失敗を再現できない
adminは強力です。公式の説明でも、Admin overridesを有効にするとadminが自動的にパスする一方、例外としてnobodyロールが優先されるなど、特別扱いがあることが示されています。
つまり、adminで動いたからOK、が成り立たない場面があります。
失敗時に何を見ればいいかの順番がない
ACLの沼は、原因が複数候補に見えることが怖さの正体です。順番さえ決まっていれば、落ち着いて切り分けできます。
ここから先は、この「あるある」をパターン別にほどいていきます。
パターン別に理解する ロール 条件 スクリプトの誤解
ロールは通行証ではなく、チェック項目のひとつ
ACLの設定項目を見ると分かりやすいです。Requires roleは「必要なロールを持っているか」を見るだけで、条件やスクリプトがあれば、それらも満たす必要があります。公式でも「条件とスクリプトの両方がtrueである必要がある」旨が明確に書かれています。
学習でよくある勘違いはこれです。
- ロールがあれば無条件に通る
- 条件はおまけ
- スクリプトは上級者だけの世界
実際は逆で、ロールは最初の入口、条件やスクリプトは最後の詰めになりがちです。
具体例
incidentテーブルのread ACLにitilを要求しつつ、「自分のグループに割り当てられたレコードだけ見せたい」なら、Requires roleにitil、Data Conditionにassignment_groupが自分のグループ、のように分担して設計します。
このとき、itilがあるだけでは通りません。条件がfalseなら落ちます。
Admin overridesの扱いを理解していない
学習時にハマる典型が「管理者で動くのにユーザーで動かない」です。公式のACL項目説明では、Admin overridesを有効にするとadminはスクリプトやロール制約に関係なくパスする一方、nobodyロールはそれより優先されるとされています。
なので、検証時はこう考えるのが安全です。
- まずは非adminのテストユーザーで再現する
- 管理者でしか試せない場合は、Admin overridesの影響を疑う
- 「nobody」絡みの例外がないかも意識する
Scriptの評価対象を取り違える
スクリプトACLで混乱しがちな点は、currentが何を指すかです。公式でも、関連リスト上の評価ではcurrentが「関連リストが載っている側」を指す場合がある、という注意が入っています。
このズレに気づかないと、「スクリプトは正しいはずなのに通らない」になりがちです。
具体例で腹落ちさせる テーブル フィールド ワイルドカード
ここはCSA学習でも混乱しやすいポイントです。用語だけで覚えると、設問の粒度を読み違えます。
テーブルACLとフィールドACLは別の話
公式のACLの解説では、対象のオブジェクトがテーブル、フィールド、レコードなどで識別されることが示されています。
同じincidentでも、次の2つは守っている対象が違います。
- incidentテーブル全体のread
- incident.short_descriptionフィールドのread
そして、現場でよくあるのがこれです。
- テーブルreadは通るのに、特定フィールドだけ空欄になる
- リストでは見えるのに、フォームで編集できない
- 関連リストだけ表示されない
この手の現象は、フィールドACLや別操作のACLに原因があることが多いです。
Nameの書き方を理解していない
ACL作成手順の公式説明に、Nameの書き方とワイルドカードの例が載っています。たとえば incident.* や .number のような書き方ができる一方で、inc のような曖昧な指定はできません。
ここを雑に理解すると、問題文の「どのフィールドを保護しているか」の読み取りが崩れます。
Applies Toを誤解している
Applies Toは「このACLを特定条件のレコードにだけ適用する」ためのフィルタです。公式でも、incidentでCritical priorityだけに適用する例が示されています。
ここでありがちな失敗は、Applies Toを「例外ルール」みたいに使ってしまい、意図せず対象が狭くなって落ちるケースです。
具体例
「incidentは読めるはずなのに、ある優先度のときだけ見えない」
このとき、Applies Toでpriorityを絞ったACLがどこかに入っていると、一気に説明がつきます。
新しめの論点としてQuery ACLの存在を知らない
近年はQuery ACLという種類も整理されています。公式ドキュメントでは、query_rangeとquery_matchという操作で、ユーザーのクエリをより細かく制御し、いわゆるブラインドなクエリ攻撃への対策にもなる、と説明されています。
学習段階で「readさえ守れば十分」と思い込むと、検索や条件指定の文脈で混乱しやすくなります。
ACLを疑う前に確認したいこととデバッグの進め方
ACLの問題は、いきなりACLレコードを開くより、切り分けの順番を固定した方が早いです。ここでは、実務でも学習でも使えるチェック順を置いておきます。
まず確認するチェック順
- 現象は「見えない」か「編集できない」か「作成できない」か
操作が違えば、必要なACLも変わります。 - 対象はテーブルかフィールドか
フィールドだけ症状が出るなら、フィールドACLを強く疑います。 - どのユーザーで再現しているか
adminでしか試していないなら、Admin overridesの影響をまず外します。 - 条件やスクリプトの評価が絡むか
ロールだけで説明できないなら、条件とスクリプトを同列に疑います。
security_adminの前提を落とすと学習がズレる
ACLを作成するには権限が必要で、公式手順でもsecurity_adminへ権限昇格が必要とされています。
学習環境で「ACLが編集できない」場合、単純に権限不足で止まっているだけのこともあります。
トラブル時にやりがちな悪手
- その場しのぎで . を広げる
- 条件やスクリプトを消して通す
- とにかくadminを付ける
短期的には動きますが、あとで「誰がどこまで見えるのか」が追えなくなります。特にCSA学習では、こうした思考だと設問の意図を読みづらくなるのでおすすめしません。
学習を体系化するコツとUdemy教材の使い方
ACLは、単発の暗記より「再現できる手順」を体に入れる方が強いです。
おすすめの学習ステップ
- ACLの設定項目を、ロール 条件 スクリプトの3つに分けて説明できるようにする
- テーブルACLとフィールドACLで、起きる症状の違いを言語化する
- ワイルドカードの使いどころと制約を把握する
- 管理者の挙動が特別扱いになる条件を理解する
- Query ACLという発想があることを知っておく
体系的に学べる教材の一例としてUdemy講座を使う
独学だと、どうしても「目の前の現象」ベースで知識が増えていき、穴が残りやすいです。UdemyのServiceNow管理者向け講座の中には、ユーザー ロール グループの基礎から、ACLの設計とトラブルシュートまで、順番に積み上げる構成のものがあります。
公式ドキュメントを軸にしつつ、手を動かす順番を補助する目的で使うと、理解が安定しやすいです。
選ぶときのコツは、次のどちらかが含まれている講座です。
- ACLの設計をロールだけで終わらせず、条件やスクリプトの考え方まで扱っている
- 「なぜ見えないのか」を切り分けるデモや演習がある
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
ACLでつまずく人の共通パターンは、突き詰めると「粒度」と「評価の見立て」のズレです。
- ACLはロールだけではなく、条件やスクリプトも含めて評価される
- 対象がテーブルなのかフィールドなのかを曖昧にすると、症状の説明がつかなくなる
- ワイルドカードは便利だが、制約や副作用を理解して使う
- adminは特別扱いされる場面があるので、検証ユーザーを分けて考える
- Query ACLのように、検索や条件指定まで含めて守る発想もある
暗記よりも、「何が起きたらどこを見るか」という順番を固定すると、学習でも実務でもブレにくくなります。まずは、ロール 条件 スクリプトの3点セットで説明できる状態を目指してみてください。
