ServiceNow Australia新機能触ってみた4 フィールドの新しいRead Only Option

Last updated at 2026-05-01Posted at 2026-05-01

AustraliaリリースからフィールドのRead-Onlyの設定方法が変わる

Australiaリリース記事の第4弾です。
今回は新機能というより設定箇所や概念っぽい話になるのですが、今後の設計にわりとかかわりそうなリリースを見つけたのでPDIで諸々確認、コミュニティ調査などしてみました。

新しい4種のRead-Onlyオプション

これまで、フィールドの設定（dictionaryテーブル）のRead-Only（読み取り専用）オプションは以下のスクリーンショットのような「Read Only」にチェックを入れるかどうかで設定していました。

Australiaリリース以降、以下のような4つ（厳密には3つ）の選択肢に変わります。

　1)Display Read Only
　2)Client Script Modifable
　3)Strict Read Only
　4)Instance Configured※

※Instance ConfiguredはAustralia以前のバージョンで作成されたフィールドにのみ存在するオプション

各設定値の内容はそれぞれ以下になります。

*公式のdocs の説明を一部引用しています。

1)Display Read Only

こちらはUI上ではフィールドを読み取り専用として表示しますが、クライアントスクリプトやTableAPI、GraphQL、GlideRecordSecure()などのサーバー側操作によって読み取り専用フィールドへの変更を許可する。とあります。一番シンプルというか、人間の見た目的に読み取り専用表示として、スクリプトなどでのアドミン作業は全般的にOK、という感じですね。

2)Client Script Modifable

UI上ではフィールドを読み取り専用として表示し、クライアントスクリプト経由の変更は許可しますが、 バックグラウンドスクリプトや Table API、GraphQL、GlideRecordSecure() といったサーバーサイドAPI経由の変更は禁止します。

とありますね。後者の部分が1)との違いで、フィールドの変更許可をクライアントサイドに限定しています。

3)Strict Read Only

UI上ではフィールドを読み取り専用として表示し、クライアントスクリプトとサーバーサイドAPIの両方からの変更を一切禁止します。とありますね。

1)~3)でわかることは「Read-Only」と1つにくくるのではなく、より厳密な設計や設定をしていこうという思想がうかがえますね。

4)Instance Configured

Australiaリリースの前に作成された読み取り専用フィールドに適用される、デフォルトのオプション値です。互換性の維持や、本番以外のインスタンスで読み取り専用の動作をテストするために使用されます。とあります。
つまり裏を返せば、本番運用に向けてはなるべく1)~3)のいずれかを設定するように、ということですね。

現に、このコミュニティ
New Read-only options Australia Release
にも記載がありますが、設定画面としては基本的に1)~3)しか選べないため、これはあくまで互換性維持の選択肢だよ～（設計時の選択肢に入れないでね）という意思も見えます。

「Instance Configured」が設定されているフィールドのふるまいはシステムプロパティ「glide.read_only.legacy_read_only_behavior」の値に依存するとのことです。Australia PDIではDefaultが「client_script_modifiable」になっておりました。

以上が新しい各設定値の説明です。

比較して整理するとこんな感じかなぁ

それぞれのオプションの比較用の表です。

Option	UI上の見え方	Client Scriptで変更	Server-Side API/Operationで変更	Optionの意味
Display Read Only	Read Only	可	可	画面上だけ固定したい
Client Script Modifiable	Read Only	可	不可	画面連動で自動入力するがServer-Sideでは値を変えたくない
Strict Read Only	Read Only	不可	不可	値確定後にあらゆる変更の余地を残したくない
Instance Configured	Read Only	デフォルトは可（プロパティ次第）	デフォルトは不可（プロパティ次第）	過去バージョンとの互換性維持と本番以外のインスタンスでの検証用

~~（表書いてから気づいたけど、Read-Onlyの話だから「UI上の見え方」って全部Read-Onlyじゃんか…）~~

Australiaアップグレード時にやったほうがいいこと

今回の変更を受けて、アップグレード時の注目ポイントととして下記2点考えられると思っています。

1）Instance Configuredになった／なる予定のフィールドの設定値設計

物量やスケジュールにもよりますが、公式の「（Instance Configuredは）本番以外のインスタンスで読み取り専用の動作をテストするために使用」という方針にのっとると、可能な限り「Instance Configured」になったフィールドについて、フィールドの設計として以下のどれを採用するかを決め、アップグレード作業として設定するのが必要かなと思いました。

　1)Display Read Only
　2)Client Script Modifable
　3)Strict Read Only

前述の通り「Instance Configured」になったフィールドはデフォルトで一律「Client Script Modifable」となるため、業務の用途に合わせて1),2),3)のどれが適切か当てはめて設定したほうが良いでしょう。特に、「Client Script Modifableだと困る」というものはStrict Read Onlyにする、などのセキュリティ的な強化部分は必要かなと思います。

※筆者のYokohamaからAustraliaにアップグレードしたPDIだと、「Instance Configured」になったフィールドは3817レコード。一気に全部見直すのは厳しいのでやるとしたら優先順位は決めたい。

（プラグインの有無やカスタムテーブル、フィールドの有無でレコード差出るのであくまで参考値としてください。特に筆者PDIはCMDB系のプラグイン（テーブル多め）が入ってるので、入ってないものと比べると結構多いかもです）

2)OOTB Read-Onlyフィールドに対してカスタムClient Scriptなどで値を変更していたフィールドへの影響確認とテスト

こちらのリリースノートと
ServiceNow AI Platform core feature release notes

こちらのKB（要NowSupportログイン）
KB2718122 - Remediation for strict read-only fields preventing client side updates

で案内されている影響確認です。ServiceNowのOOTBフィールドに対するカスタムのスクリプトの影響確認ですね。
これはインスタンス管理者目線では確認しておきたいものです。

Australiaアップグレード以降のフィールド設計で考えていったほうがよいこと

Australia以降はRead-Onlyフィールドを設計するうえでこれらのオプションをどのように使うかというフィールドの設計が必要になりますね。前半の表と少しかぶる内容もありますが、設計意図を軸に整理してみました。

考えた観点
　1.この値は人が入力するのか、システムが生成するのか。
　2.画面上だけ編集不可にしたいのか。
　3.Client Scriptで自動入力・再計算したいのか。
　4.Server-Side処理や連携で更新する必要があるのか。

上記観点をもとに、以下の意図で各種設定をしようとすると推奨Optionは以下のようになると思います。

設計意図	推奨Option	理由
画面では触らせたくないが、内部処理では更新したい	Display Read Only	UIでは固定しつつ、Client Script / Server-Side Operation を許容できる
画面では触らせたくないが、フォーム連動で自動入力したい	Client Script Modifiable	Client Script は許可しつつ、Server-Side 更新は制限できる
一度決まった値をどこからも変えさせたくない	Strict Read Only	Client/Server-Side両方からの変更を禁止できる

おまけ

Strict Read Onlyって具体的にどういうフィールドなんだろうか、ってのはちょっと思いまして、
OOTBでStrict Ready Onlyになってるフィールドを見てみると自動採番されるIDやレコードNumber系の値となるフィールドが多いなって印象です。（そりゃそうか、Strict Ready Onlyに設定したフィールドは人の手では入力できない）