readは通るのにwriteが通らない？ServiceNowでハマりがちな原因パターン完全整理

ServiceNowを学習していると、必ず一度はこう思います。

「readは通ってるのに、なぜかwriteだけ失敗する…」

画面表示は問題ないのに、更新しようとすると保存できない。
FlowやBusiness Ruleではエラーが出る。
試験問題でも実務でも、この挙動は非常によく狙われます。

この記事では、
**ServiceNow資格（CSA / CAD）を目指す人が必ず理解すべき「readは通るのにwriteが通らない原因パターン」**を、体系的に整理します。

原因① write ACLがそもそも存在しない

readは通るのにwriteが通らない原因で、一番多いパターンです。

何が起きている？

• tableに read ACLは定義されている
• しかし write ACLが1つも存在しない

ServiceNowのACL評価は、

該当するACLが存在しない場合 → 原則「拒否」

になります。

試験的な重要ポイント

• read ACLがあっても
• write ACLが無ければ writeは失敗

実務での見分け方

• フォームが表示される
• フィールドがグレーアウト、または保存時に失敗
• エラーメッセージが分かりにくい

「readは通る＝ACLは問題ない」と判断するのは危険です。

原因② write ACLにrole条件が追加されている

read ACLは通るが、write ACLで role制御がかかっている パターンです。

典型例

• read ACL：role指定なし
• write ACL：itil や admin が指定されている

この場合、

• 表示：OK
• 更新：NG

になります。

試験で狙われる考え方

• 「roleが足りないのはどこか？」
• readではなく write ACLを見る

実務での対策

• 対象テーブルの write ACLを必ず確認
• role継承（親ロール）にも注意

特に itil を持っていないユーザーで検証すると、原因がはっきりします。

原因③ Field ACLでwriteがブロックされている

table ACLが通っていても、
Field ACLがwriteを拒否しているケースは非常に多いです。

仕組みのポイント

ServiceNowのACL評価は、

1. Table ACL
2. Field ACL

の順で評価されます。

つまり

• Table write ACL：OK
• Field write ACL：NG

この場合、
そのフィールドだけ更新不可になります。

試験での引っかけポイント

• 「テーブルは更新できるが、特定フィールドだけ更新できない」
• → Field ACLが原因

実務でありがちな例

• state
• assigned_to
• approval

など、重要フィールドほどField ACLが設定されていることが多いです。

原因④ write ACLにScript条件がある

write ACLに Scriptが設定されている場合、
条件次第でreadは通ってもwriteだけ失敗します。

よくあるScript例

• current.state == 1 のときのみ許可
• gs.hasRole() を使った複雑な条件
• レコードの値に依存する判定

試験対策ポイント

• 「roleはあるのに更新できない」
• → Script条件を疑う

実務の落とし穴

• Scriptの中で current が想定と違う
• insert/updateで評価されるタイミングの誤解

write ACLのScriptは 非常に強力かつ危険です。

原因⑤ UIポリシーやClient Scriptと混同している

ACLではなく、UI側制御が原因なのに、
「write ACLが通らない」と勘違いするケースもあります。

代表例

• UI Policyで read-only にしている
• Client Scriptで setReadOnly(true)
• Catalog UI Policyによる制御

見分け方

• API更新：通る
• 画面更新：通らない

この場合、ACLではありません。

試験での考え方

• UI制御は セキュリティではない
• write可否は ACLが最優先

この切り分けができると、問題を一気に解きやすくなります。

writeが通らない時のチェック順まとめ

実務でも試験でも、この順番で考えると迷いません。

1. write ACLは存在するか
2. write ACLにrole条件はあるか
3. Field write ACLで止められていないか
4. write ACL Script条件は満たしているか
5. UI制御と混同していないか

readは通る、writeだけ失敗という状況は、
ほぼこの中のどれかに必ず当てはまります。

試験対策としての学習方法

このテーマは、
文章だけで理解するのが難しい分野です。

おすすめなのは、

• ACL評価順序を図で確認
• read / write / field の挙動を実機で確認

Udemyをおすすめする理由

• ACLの評価順を 画面操作で確認できる
• write失敗時の ログや挙動が分かる
• CSA試験で狙われる考え方が整理されている

特に、

• 「なぜreadは通るのか」
• 「なぜwriteだけ失敗するのか」

を 実演ベースで学べる講座は、
独学よりも圧倒的に理解が早いです。

まとめ

readは通るのにwriteが通らない――
これはServiceNow学習者が必ず通る壁です。

しかし、

• readとwriteは別判定
• write ACLは厳しく評価される
• Field ACLやScript条件が絡む

この構造を理解すれば、
試験でも実務でも迷わなくなります。

「ACLはなんとなく分かった」から
「ACLは説明できる」状態へ。

その一歩として、
この記事の内容を 必ず自分の言葉で整理してみてください。

そして、理解を一気に深めたいなら
Udemyのハンズオン講座を併用するのが最短ルートです。