導入：Dependent Choiceは「便利だけど、効かない時に原因が見えにくい」
ServiceNowを触っていると、選択肢（Choice）を「前の項目の選択に応じて絞り込みたい」場面がよく出てきます。
たとえば、以下のようなケースです。
- カタログ申請で「都道府県」を選ぶと「市区町村」を絞り込みたい
- 「カテゴリ」を選ぶと「サブカテゴリ」を切り替えたい
- インシデント登録で、項目の選び方に応じて入力ミスを減らしたい
このとき候補に上がるのが Dependent Choice（依存する選択肢）。
ただ、設定はシンプルに見える一方で「効かない」ときに原因が複数方向へ散らばりやすく、初学者ほど泥沼に入りがちです。
この記事では、暗記ではなく “なぜそうなるのか” を軸に、Dependent Choiceが
- 効くための条件（前提）
- 効かない典型パターン（落とし穴）
- 実務で壊れにくい設計
- 迷ったときの確認手順
を、具体例つきで整理します。CSA学習中の方が「依存制御の考え方」を掴む目的でも読みやすいようにまとめます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Dependent Choiceの仕組み：Choiceは「テーブル＋フィールド＋value」と「依存キー」で絞り込まれる
Dependent Choiceを理解する近道は、「Choiceがどこに保存され、何を条件に表示されるか」を押さえることです。
Choiceは“どの項目の選択肢か”が決まっている
Choiceは、ざっくり言うと次のセットで紐づきます。
- テーブル
- フィールド（要素）
- 選択肢のvalue / label
つまり「同じラベル（表示名）」があっても、テーブルやフィールドが違えば別物です。
Dependent Choiceのトラブルは、この“紐づきの単位”を見落としているところから始まることが多いです。
Dependent Choiceは「親の選択値」によって子の選択肢をフィルタする
Dependent Choiceは、子のChoice側に「このChoiceは、親がこの値の時だけ有効」という条件を持たせます。
ここで重要なのは、親を判定するときに見ているのは label（表示名）ではなく value（内部値） だという点です。
具体例（valueとlabelが違うパターン）
- 親（カテゴリ）
- value：
network - label：
ネットワーク
- value：
- 子（サブカテゴリ）
- value：
vpn - label：
VPN - dependent value：
network
- value：
この場合、親が「ネットワーク」と表示されていても、子は network というvalue を見て絞り込みます。
ここがズレると「設定しているのに効かない」が発生します。
依存が効くタイミングは“表示側のUI”にも左右される
Dependent Choiceはデータだけの話ではなく、画面側（フォームやカタログのUI）が依存制御を実装している必要があります。
- プラットフォーム標準のフォーム：基本的に対応していることが多い
- Service Catalog（標準UI / Portal）：標準ウィジェットなら対応していることが多い
- カスタムウィジェットや独自UI：依存制御が入っていないと効かないことがある
「設定は合っているのに動かない」の原因が、データではなくUI側にあるケースもある、という前提は持っておくと楽になります。
効く条件：Dependent Choiceが動作するための前提を“設定・データ・UI”で整理
ここでは「こうなっていれば基本的に動く」という前提条件を、実務で確認しやすい粒度でまとめます。
親と子の関係が成立していること
Dependent Choiceは、子が「何に依存するか」を決めて初めて成立します。代表的には以下。
- 同じフォーム上で 親フィールド（親変数）と子フィールド（子変数）が存在する
- 子側に「Dependent field（親）」の指定がある（または同等の設定がされている）
「親がどれか分からない」状態では、子のChoiceは絞り込まれません。
親の値が“単一の値”として取得できること
Dependent Choiceは親の選択値をキーにするため、親が次のような場合は注意が必要です。
- 複数選択（マルチセレクト）で値がカンマ区切りになる
- 表示上は1つに見えても、内部的には複数値扱いになる
この場合、子側のdependent valueと一致しづらくなります。
依存のキーが一意に決まる設計（親は単一選択）に寄せるのが無難です。
子のChoiceに「dependent value」が正しく入っていること
基本中の基本ですが、ここでズレやすいポイントは次の2つです。
- dependent valueが 親のlabel になってしまっている（本当はvalue）
- 親のvalueを後から変更して、子のdependent valueが 古いまま になっている
運用で“後から名称変更”が入る環境ほど、この事故が起きます。
ラベル変更ではなく value変更 を伴うと、依存が一気に崩れます。
Choiceが有効（Active）で、条件に合うものが存在していること
当たり前に見えて、意外と見落としがちです。
- 子のChoiceがInactiveになっている
- 親の値に合致する子Choiceが 1つも存在しない
- 「親が未選択のときに出すChoice」が用意されていない（必要なら）
特に「親を選ぶ前でも子を選べるようにしたい」場合は、親が空のとき用のChoice設計が必要になります（後述します）。
画面（UI）が依存制御に対応していること
データが完璧でも、UIが依存を反映してくれないと「効かない」に見えます。
- 標準フォーム：基本はOKになりやすい
- カタログ申請：標準の挙動ならOKになりやすい
- カスタムUI：要注意（特に独自の入力コンポーネント）
「どの画面で試しているか」を明確にすると、切り分けが速くなります。
効かない条件：ハマりやすい落とし穴と症状
ここからが本題です。Dependent Choiceが効かないとき、多くは次のどれかに当たります。
valueとlabelを取り違える
症状：
- 親を選んでも子が全く絞り込まれない
- ある値のときだけ効かない（表記揺れがある）
原因：
- dependent valueに label を入れている
- 親のvalueが
Networkなのに dependent valueがnetwork（大小文字や完全一致のズレ）
対策：
- 親の valueを正 として揃える
- 表示名（label）変更は比較的安全だが、value変更は影響が大きいので慎重に
親の値を“後から変更”して依存が壊れる
症状：
- 昨日まで動いていたのに急に動かない
- 一部の選択肢だけ消える
原因：
- 親Choiceのvalueを変更したが、子のdependent valueが追従していない
対策：
- valueは「プログラムが参照するID」だと割り切り、運用でむやみに変えない
- 変えるなら、影響範囲（依存先）を洗い出して一括更新する
同じ名前のフィールドに見えて、実は別テーブル／別項目を見ている
症状：
- 似た画面では動くのに、別画面では動かない
- 開発環境では動くのに本番で動かない
原因：
- Choiceが紐づく単位（テーブル＋フィールド）がズレている
- 継承（extends）の関係で「どのテーブルのChoiceを見ているか」が想定と違う
対策：
- 「この画面のこの項目」は、どのテーブルのどのフィールドか を言語化して確認する
- 継承が絡む場合、上位テーブルのChoiceを参照している可能性も疑う
依存の段数が増えて“連鎖”が途切れる
2段（A→B）なら動くのに、3段（A→B→C）でCが崩れることがあります。
症状：
- Bまでは絞り込まれるが、Cが更新されない
- Bを変えてもCが前の候補のまま残る
原因：
- UI側が「変更イベント」を拾えていない
- CのChoiceがBのvalueと一致していない
- Bの値がクリアされないまま残り、Cの絞り込み条件が崩れる
対策：
- 親が変わったら子をクリアする（UIポリシーやクライアント制御）
- 依存が深いほど「値のクリア」「初期化」の設計が効いてきます
ポータル／カスタムUIで“依存制御が実装されていない”
症状：
- Backend（標準UI）では動くのに、Service Portalでは動かない
- あるウィジェットだけ動かない
原因：
- そのUIコンポーネントがDependent Choiceの更新ロジックを持っていない
- カスタムウィジェットでchoiceの再取得をしていない
対策：
- まず標準の画面で同条件を再現し、データの問題かUIの問題か を切り分ける
- カスタムUIの場合は、仕様として対応していない可能性もあるので「実装が必要」と割り切る
キャッシュや反映タイミングで“変えたのに変わらない”
症状：
- Choiceを追加したのに画面に出ない
- 設定を直したのに挙動が変わらない
原因：
- 画面側で古い情報を掴んでいる
- ブラウザキャッシュ／プラットフォーム側のキャッシュが影響している
対策：
- 変更後は「別ブラウザ」「シークレット」などで再確認
- 反映の切り分けを丁寧に（いきなり複数変更しない）
設計とトラブルシュート：壊れにくい依存関係の作り方＋確認チェックリスト
Dependent Choiceは“設定できる”ことより、運用で壊れないことのほうが大事です。ここでは実務目線での設計と、困ったときの確認順をまとめます。
壊れにくい設計のコツ
valueは「機械が読むID」として固定し、labelで人間に優しくする
おすすめの考え方はこれです。
- value：
network,hardware,softwareのように ブレない短いID - label：
ネットワーク,ハードウェア,ソフトウェアのように表示用
こうしておくと、表示名を変えても依存が壊れにくくなります。
依存が深い場合は“値のクリア”までセットで設計する
A→B→Cのように段数が増えるほど、次が効きます。
- 親が変わったとき、子の値をクリアする
- 子をクリアしたら孫もクリアする
これをUIポリシーやクライアント制御で入れておくと、変な残り方が減ります。
「絞り込み自体は効いているのに、過去の値が残って登録できてしまう」系の事故も予防できます。
データ量が多い・変動が多いなら“Dependent Choice以外”も検討する
Dependent Choiceは手軽ですが、次のような場合は別解のほうが運用が楽なこともあります。
- 選択肢が数百〜数千で増減が多い
- 外部マスタ（拠点一覧など）と同期したい
- 条件が「単純な親子」ではなく、複数条件で絞り込みたい
この場合は、Reference（参照）＋絞り込み（Qualifier）や、動的取得（スクリプト）を検討する余地があります。
「Dependent Choiceで頑張りすぎない」判断も、設計力の一部です。
トラブルシュートの確認手順
下の表を上から順に見ると、最短で原因に当たりやすいです。
| 確認ポイント | よくあるNG | 直し方の方向性 |
|---|---|---|
| 親子が同じ画面に存在するか | 親の項目が実は別フォーム／別コンテナ | 同一UIで親子が揃う形にする |
| 子に依存先（親）が指定されているか | 親の指定ミス、別の項目を参照 | 依存先を正しい項目に |
| dependent valueは親のvalueと一致しているか | labelを入れている、大小文字違い | 親のvalueを正にして揃える |
| 親のvalueを最近変えていないか | value変更で依存が壊れる | 子側も一括で更新／value固定運用へ |
| 子ChoiceはActiveか | Inactiveで出ない | Active化、条件に合うChoiceを用意 |
| どの画面で試しているか | Portalだけ動かない | 標準UIで再現→UI起因か切り分け |
| 変更後の反映 | 直したのに変化なし | 別ブラウザ、キャッシュ影響の切り分け |
切り分けのコツ：まず“標準UI”で動くか試す
ポータルや独自UIで詰まったら、最初にやると効くのがこれです。
- 同じテーブル／同じ項目を、標準フォームで再現してみる
- 標準フォームで動く → UI側の問題の可能性が上がる
- 標準フォームでも動かない → データ／設定側の問題の可能性が高い
この順番にすると、無駄な修正を減らせます。
学習の補助として：体系的に理解したい人向けのUdemy活用
Dependent Choiceは、Choiceの基本、カタログ変数、クライアント側の挙動など、周辺知識とつながって理解が深まります。
もし「点で覚える」より「線で整理したい」なら、ServiceNowの基礎（テーブル・フォーム・カタログ・UI制御）を一通りなぞれる 体系的な教材 を1つ持っておくと効率が上がります。
Udemyにも、ServiceNowの基本操作から設定・カタログ周りまで段階的に扱う講座がいくつかあります。いきなりDependent Choiceだけに突っ込むより、周辺の前提（value/label、Choiceの持ち方、UIの違い）をまとめて復習できる構成のものを選ぶのが無難です。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ：Dependent Choiceは「value一致」「紐づき単位」「UI対応」の3点でほぼ決まる
Dependent Choiceが効く／効かないは、結局のところ次の3点に集約できます。
- 親子のキーはlabelではなくvalue：dependent valueは親のvalueと完全一致が基本
- Choiceはテーブル＋フィールドで管理される：同名でも別物になり得る（継承も含む）
- UIが依存制御に対応している必要がある：標準UIで切り分けると迷いにくい
そして、実務で壊れにくくするなら
- valueは固定IDとして運用し、表示名はlabelで調整する
- 依存が深いほど「値のクリア」「初期化」をセットで設計する
- データ量や条件が複雑なら、Dependent Choice以外の選択肢も検討する
このあたりを意識すると、ただの設定暗記ではなく「なぜそうなるか」を理解しながら進められます。CSA学習でも、選択肢制御の話は周辺トピック（フォーム、カタログ、クライアント挙動）とつながりやすいので、理解が積み上がる感覚が出てくるはずです。
