Choiceは「見た目は簡単」なのに混乱しやすい
Choice（選択肢）って、画面ではただのプルダウンです。ところが実務では、同じ「プルダウン」に見えても、裏側の持ち方が違ったり、依存関係が絡んだり、ラベルと値が一致しなかったりして、途端に混乱します。
CSAの学習でも、Choiceは暗記科目というより「仕組みの前提」として扱われがちです。フォーム条件、Business Rule、Client Script、Flowの条件分岐など、あちこちでChoiceが絡むので、ここが曖昧だと別テーマまで一緒に崩れます。
この記事では、ZurichでChoice管理が混乱しやすい点を、仕組み→事故りやすいポイント→設計の考え方の順で整理します。公式ドキュメントの範囲をベースに、初学者でも手が動くレベルの具体例に落とし込みます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Choiceの正体はどこにある？辞書とsys_choiceの関係を腹落ちさせる
まず一番大事なのは、「Choiceはどこに保存されて、何が表示を決めているのか」です。
辞書は「フィールドの設計図」、Choiceは「選択肢の実体」
ServiceNowでは、フィールドの定義はシステム辞書（dictionary）にあります。Choiceフィールドの場合、辞書側で「Choiceの持ち方（タイプや、どのChoiceセットを参照するか）」が決まり、実際の選択肢はChoiceテーブル（代表的にはsys_choice）側に入ります。
ここを取り違えると、次のような勘違いが起きます。
- 「辞書のラベルを変えたのに選択肢が変わらない」
- 「別テーブルのフィールドを作ったのにChoiceが勝手に同じになった」
- 「移送したはずなのに本番でChoiceが出ない」
こういう現象は、たいてい「辞書の設定」と「Choice実体」のどちらを触っているかがズレています。
まず確認したい：そのChoiceは“その場で定義”なのか“再利用”なのか
Zurichのドキュメントでは、フォーム上でフィールドを右クリックして Configure Choices を使い、Choiceを追加・並び替えできる流れが示されています。依存Choiceなら、先に親フィールドの値を入れてから編集する、という手順まで明記されています。
ここで重要なのは、**「そのフィールド固有のChoice」**として管理しているのか、後述する **「別フィールドのChoiceを共有」**しているのかで、運用がガラッと変わることです。共有に入ると、直したつもりが別の画面まで変わる、という事故が起きます。
ラベルと値のズレで起きる事故：スクリプト・条件式・検索の混乱ポイント
Choiceの混乱で一番多いのが、**表示ラベル（人が見る文字）**と、**保存される値（DBに入る値）**の取り違えです。
例：Incidentのstateで「Active」と比較しても動かない
公式ドキュメントの例が分かりやすいです。見た目のラベルが「Active」でも、実際に保存されている値は整数「2」なので、スクリプトで "active" と比較しても一致しない、という話が書かれています。
この「ラベルと値のズレ」を理解していないと、次のような場面で混乱します。
- Business Ruleの条件で期待通りに分岐しない
- Flow Designerの条件が合っているのに動かない気がする
- フィルタ条件でラベルを入れているのに検索に引っかからない
- Importのマッピングで値がズレる
Typeが絡むと、さらにややこしい
Choiceフィールドは「Type（値の型）」によって、値が文字列なのか数値なのか、評価が変わります。さらにクセがあるのが -- None --（未選択）です。公式には、-- None -- はsys_choiceレコードがない場合があり、クライアントでは空文字、サーバ側では”0″文字列として評価されるケースがある、と説明されています。
ここを知らないと、例えばこうなります。
- Client Scriptでは空だと思っているのに、Business Rule側では”0″扱いで条件に入ってしまう
- 「未選択を許可しているつもり」なのに、後段の処理で未選択扱いにならない
- 画面上の見え方と、DB値の見え方が一致しない
実務での安全策：条件式は“ラベル”より“値”に寄せる
学習の段階ではラベルで覚えたくなりますが、実務の条件はできるだけ「値」に寄せておくとブレが減ります。理由はシンプルで、ラベルは翻訳や表記揺れで変わり得ますが、値は運用上なるべく変えない前提で設計されるからです（もちろん変更できないわけではないですが、変えると影響が広い）。
- 「人間が読む」部分：ラベル（UI、表示）
- 「システムが判定する」部分：値（条件、分岐、保存）
この役割分担で捉えると、Choice周りの理解が安定します。
Dependent（依存）Choiceが難しくなる理由：設定手順と“ハマりどころ”
Dependent Choiceは、見た目以上に混乱しやすいです。代表例が Incident の Category → Subcategory のような親子関係です。
公式手順のポイント：親を選んでからChoiceを編集する
Zurichドキュメントでは、依存Choiceを編集する場合、まずフォーム上で親フィールドの値を入れてから Configure Choices を開くように書かれています。つまり、同じ「Subcategory」でも、親の値によって編集対象のChoiceセットが変わる、ということです。
ここを知らずに編集すると、
- 「追加したはずなのに別の親カテゴリでは出ない」
- 「親A用のChoiceを、親Bのつもりで編集していた」
みたいな現象になります。
ハマりやすいポイント：運用で“親の種類”が増えると破綻しやすい
例えば、最初は親カテゴリが3つだったのに、運用で10個に増えた、とします。SubcategoryのChoiceを親ごとに管理する場合、Choiceの件数が増えるだけでなく、
- どの親にどの子が紐づくかが把握しづらい
- 似たラベルが量産されて誤選択が増える
- 廃止した親の子Choiceが残り続ける（掃除が難しい）
という運用課題が出ます。
設計の考え方：Choiceで頑張りすぎない
CSA学習の範囲でも、実務の観点でも、「全部Choiceで表現しよう」とすると、依存関係が複雑になりがちです。一定規模を超えると、Choiceよりも、
- 参照（Reference）＋条件（Reference qualifier）
- もしくはテーブル化してマスタ管理
などの方が「変更に強い」設計になることがあります。
Choiceの強みは、手軽で、フォーム上の体験が軽いこと。弱みは、増えると管理が重くなること。ここを押さえておくと、依存Choiceで無理をしなくなります。
Choiceの再利用・共有で混乱する点：Choice table/field、スコープ、移送
Choice管理の事故で“地味に多い”のが、**Choiceの再利用（共有）**です。
共有とは：別フィールドが同じChoiceセットを参照する状態
公式ドキュメントでは、あるフィールド（Field A）でChoiceを定義し、別テーブルのフィールド（Field B）で Configure Dictionary を開き、辞書の Choice table / Choice field を指定することで、Choiceセットを再利用できると説明されています。
便利なのですが、混乱ポイントもはっきりしています。
- Field Bを直したつもりでChoiceをいじったら、Field Aも変わった
- 共有元がどこか分からず、運用で「触ってはいけないChoice」を触る
- Update Setで移送したが、共有関係まで意識できておらず、本番で期待通りにならない
実務でのコツ：共有は“意図してやる”、意図しない共有を避ける
共有は悪ではないです。例えば、複数テーブルで同じステータス定義を使う、といった用途では効果があります。
ただし、意図しない共有は避けたい。現場の事故パターンはだいたい「知らないうちに共有していた」「共有の影響範囲を把握していなかった」です。
おすすめの運用はこんな感じです。
- 共有元のフィールドは“基準”として明確にする（命名・説明・運用ルール）
- 共有先のフィールドは、辞書でChoice参照していることが分かるようにしておく
- 「共有Choiceは誰が変更できるか」を決める（権限や手順）
無効化・配布・UI差分の注意点：inactive、公開、インストール、作成UIの変化
ZurichでChoice管理がややこしく見える理由のひとつが、「Choiceは作って終わり」ではなく、無効化・配布・UIの差分まで含めて運用になるからです。
inactiveの挙動：アプリ公開やインストール時に影響する
公式のシステムプロパティ一覧には、Choiceのinactiveに関する設定が明示されています。
- com.snc.apps.publish.include_inactive_choices
アプリを公開（publish）するときに、inactiveなChoice（sys_choiceのinactive=true）を含めるかどうか - glide.db.table.update_inactive_choices_enabled
アプリのインストール時に、inactiveなChoiceをクライアントDBへ読み込むかどうか
ここが分かっていないと、次のような混乱が起きます。
- 「本番ではChoiceが出ない（と思ったらinactiveだった）」
- 「移送したのにChoiceが消えた／復活した」
- 「アプリ配布でinactiveまで含めた結果、不要Choiceが混ざった」
Choiceを“削除”せずinactiveにする運用はよくあります。だからこそ、inactiveがどのフェーズで効くのか（公開・インストール・画面表示）を、プロパティの存在として把握しておくと整理しやすいです。
ReferenceをChoiceっぽく見せる設定も“Choice管理に見えてChoice管理じゃない”
もうひとつ混乱しやすいのが、「ReferenceフィールドをChoiceのように表示する」ケースです。公式には、ReferenceフィールドをChoice listとして表示する手順と、閾値を決めるプロパティが説明されています。
- 一定件数を超えると、ドロップダウンではなく参照アイコンに切り替わる
glide.ui.max_ref_dropdownや辞書属性max_ref_dropdownが絡むglide.xmlhttp.max_choicesが表示上限に影響することがある
見た目はプルダウンでも、裏はReferenceです。Choice（sys_choice）をいじっても直りません。この切り分けができるだけで、調査時間がかなり減ります。
Zurichで「Choiceを変えられない？」系の戸惑い
Zurichでは、作成・設定の導線がUIごとに違う場面があります。例えば、コミュニティ上では「Table Builder上でChoice listを変更できなくなったように見える」という話題が出ています（Yokohamaまではできた、という声）。
コミュニティ情報は環境差もあるので断定は避けますが、少なくとも学習者としては、
- 「どの画面（Table Builder / 辞書 / Configure Choices）で何を編集しているか」
- 「編集できないのが権限・UI制限・仕様差なのか」
を切り分けるクセがつくと、Choice周りの混乱が一段減ります。
まとめ：CSA目線での整理ポイントと、学習の進め方
Choice管理で混乱しやすい点は、結局この5つに集約されます。
- 辞書（フィールド定義）とChoice実体（選択肢データ）を混同しない
- ラベルではなく値で判定する発想を持つ（Type、
-- None --も含む） - Dependent Choiceは「親を入れてから編集」が基本
- 再利用（Choice table/field）は便利だが影響範囲が広いので“意図して”使う
- inactiveや配布・インストール・UI差分まで含めて運用になる
CSA対策としては、Choiceを「暗記対象」として追うより、フォーム条件やスクリプト条件で“なぜそう書くのか”が説明できる状態を目指すのが近道です。特にラベルと値のズレ、未選択の扱い、依存Choiceの編集手順は、理解していないと問題文の意図が掴みにくくなります。
もし独学で散らばりやすいなら、UdemyのServiceNow入門〜管理者向け講座で、辞書・フォーム・クライアント/サーバの条件分岐を一通りつなげて学ぶのが楽です。体系的に一周してから公式ドキュメントに戻ると、「このページは何のためにあるか」が分かるようになり、学習効率が上がります（講座はあくまで教材の一例として）。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
