Referenceが選択できない時の原因チェックリスト｜ACL・Qualifier・設定を順番に切り分け

Referenceが選べない現象を「3パターン」に分ける

ServiceNowを触っていると、Referenceフィールドでこんな場面に出会います。

• 虫眼鏡（参照検索）を押しても候補が出ない
• 入力してもオートコンプリートで「候補ゼロ」になる
• 以前は選べたのに、ある日から特定ユーザーだけ選べなくなった

この手のトラブルは、闇雲に設定を触るほど沼ります。落ち着いて、まずは現象を次の3パターンに分けるのが近道です。

パターンA：絞り込みが強すぎて「候補が存在しない」

Reference Qualifier（参照先の絞り込み）や条件が原因で、候補がゼロになっている状態です。
一番多いのは「active=true を入れたつもりが、実データが inactive だった」「動的Qualifierが想定外の条件を返している」など、“設定は正しいように見える”ケースです。

パターンB：権限不足で「見えてはいけない」扱いになっている

参照先テーブルのRead ACL、表示フィールドのRead ACL、あるいはドメイン分離（Domain Separation）などが絡むと、ユーザーに候補を返せなくなります。
この場合、管理者で見ると問題ないのに、一般ユーザーだと再現するのが典型です。

パターンC：画面側の動作が壊している

UIポリシーやClient Scriptで値を消している、参照検索の設定（辞書属性やOverride）が別挙動になっている、キャッシュや設定反映のズレが起きている、といった類です。
“候補はあるはずなのに、UIが邪魔して選べない”タイプですね。

ここまで整理できたら、次は「絞り込み → 権限 → 画面」の順で潰していきます。順番が大事です。体感、絞り込みと権限で8割が片付きます。

まず疑うべきは「絞り込み」：Reference Qualifier／条件／表示値の罠

Referenceが選べないとき、最初に見るのは参照先テーブルではなく Referenceフィールド自身の定義 です。フォーム上のフィールドを右クリックして「辞書（Dictionary）」を開ける状態にしておくと、作業が速くなります。

Reference Qualifierが原因かを最速で見抜く

Reference Qualifierは「候補に出すレコードを絞る」仕組みです。便利な反面、強すぎると候補がゼロになります。

確認ポイントは次の通りです。

• Simple / Dynamic / Advanced のどれを使っているか
• 条件に「現在のレコードの値」を使っていないか（例：会社、部署、カテゴリなど）
• その“現在の値”が空のとき、Qualifierがどう振る舞うか
• Script Includeを呼び出している場合、戻り値が空になっていないか
• AND/ORの組み方が「思ったより厳しい」になっていないか

コツ：いきなり修正しないで、まずは「Qualifierを一時的に弱めたら候補が出るか」を試すと原因が一気に絞れます。
たとえば、条件をactive=trueだけにしてみる、あるいは一時的にQualifierを外してみる。これで候補が出たら、犯人は絞り込み側です。

“参照先は合ってる”と思い込まない

Referenceフィールドは「どのテーブルを参照するか」が決まっています。
意外とあるのが、参照先テーブルを途中で変えた／辞書Overrideで参照先が変わっていた／拡張テーブル想定なのにベーステーブル参照だった、などです。

チェックリスト：

• 参照先（Reference）が意図したテーブルか
• 参照先が拡張（extends）前提なら、どのクラス（sys_class_name）を想定しているか
• “そのフォームのビュー”だけ辞書Overrideで別定義になっていないか

表示値（Display value）の落とし穴

「候補は出てるはずなのに検索で出ない」ケースでは、表示フィールド（Display）や検索対象列の設定が絡むことがあります。

ありがちな現象：

• 参照検索の一覧では見えるが、入力検索だと見つからない
• display=true を付けたつもりでも、表示列が別に上書きされている
• 表示列自体がRead不可で、候補が返せない

ここは次の章のACLともつながるので、“絞り込みだけでは説明しきれない違和感”があるなら、早めに権限チェックへ進むのが正解です。

次に疑うべきは「権限」：参照先テーブルACL／表示フィールドACL／ドメイン分離

管理者では選べるのに、一般ユーザー（あるいは特定ロールの人）だと選べない。
この時点で、まず疑うのはACLです。

参照先テーブルのReadが通っているか

Referenceフィールドは、内部的には参照先テーブルに対して検索（Read）を発生させます。
つまり、参照先テーブルのRead ACLが通らないと、候補が出ません。

ここで大事なのは、「テーブルのReadだけ見ればOK」ではない点です。

• テーブルReadが通っても、表示フィールド（Display field）のReadが通らないと表示できない
• “条件に使っているフィールド”のReadが通らず、絞り込みが正しく動かないことがある
• 参照先が拡張テーブルの場合、どのレベルのACLが評価されているかが分かりにくい

現場のコツ：
「Debug Security（セキュリティデバッグ）」を使い、対象ユーザーをImpersonateして、参照検索を実行します。
“どのACLで落ちているか”が見えるだけで、トラブルはほぼ終わります。

フィールドACLで詰まる典型パターン

次のような場合、テーブルReadがOKでも候補が出ない／一部列が空になる、が起きます。

• 表示フィールドがフィールドACLでRead不可
• 参照検索の一覧に表示している列がRead不可
• ナビゲートドットウォーク（参照先.参照先…）の先のフィールドにACL制約がある

「候補が一瞬出たように見えて消える」「入力してもNo matches」みたいな挙動は、ACL起因のことが多いです。

ドメイン分離（Domain Separation）やUser Criteriaの影響

インスタンス設計によっては、同じテーブルでも“所属ドメインが違うから見えない”が発生します。
また、カタログやポータル側だとUser Criteriaで見える範囲が制限され、Referenceの候補が狭まることもあります。

ここはCSA学習でも混乱しやすいポイントですが、覚え方はシンプルで、

• データを見えるようにする仕組み（ACL/ドメイン）
• 機能やコンテンツを見せる仕組み（User Criteria/ロール）

が同時に効くことがある、という整理でOKです。
「テーブルは見えるのに、この画面だと見えない」は、だいたいこの二段構えが原因です。

それでもダメなら「画面側」：UIポリシー／Client Script／辞書Override／キャッシュ

絞り込みと権限で説明できないときは、“UIが壊してる”可能性を見に行きます。ここからは再現条件の切り分けが重要です。

UIポリシー／Client Scriptで値が消されていないか

よくあるのがこれです。

• onChangeで別フィールド変更時に reference をクリアしている
• 条件に合わないと reference をread-onlyにする／非表示にする
• g_form.setValue で想定外の値を入れてしまい、表示が崩れる

切り分け手順としては、

• 該当フィールド周辺のUIポリシーを確認
• Client Script（特にonChange / onLoad）を確認
• 一時的に無効化して挙動が変わるかを見る
  が王道です。

辞書Overrideで「そのビューだけ」別挙動になっていないか

“同じフィールドなのに、画面Aだと選べて画面Bだと選べない”は、辞書Overrideが怪しいです。
ビューや条件に応じて参照先や属性が上書きされていると、動作が変わります。

チェックリスト：

• Dictionary Entry Overridesが存在しないか
• 参照先テーブルやQualifierがOverrideで変わっていないか
• 属性（Attributes）がOverrideされていないか

参照オートコンプリート周りの設定・キャッシュ

参照検索やオートコンプリートは、体感より“設定の影響範囲が広い”です。列設定や属性変更後に、

• 反映が遅れている
• キャッシュの影響が残っている
• 特定の条件で検索がキャンセルされている

といったズレが出ることがあります。

対処としては、原因が分かった後に

• キャッシュクリア
• 対象フォームの再読み込み
• 該当ユーザーで再ログイン
  など、基本動作を丁寧にやるだけで直ることもあります。

現場で迷わない切り分け手順と、再発を減らす設計のコツ

最後に、実務でも学習でも使える「順番どおりのチェック手順」を置いておきます。
Referenceトラブルは、順番を守るだけで解決速度が上がります。

切り分け手順

現象の把握

• 管理者だと再現するか
• 特定ユーザーだけか、全員か
• 虫眼鏡検索だけダメか、入力検索もダメか
• ある条件（会社、カテゴリ等）を入れた時だけか

絞り込み（Qualifier）

• 辞書からReference Qualifierを確認
• 一時的にQualifierを弱める／外すと候補が出るか
• “現在レコードの値が空”のときの動作を疑う

権限（ACL/ドメイン）

• 対象ユーザーをImpersonate
• Debug Securityで参照検索を実行し、落ちているACLを特定
• 表示フィールドや検索列のフィールドACLも確認
• ドメイン分離やUser Criteriaの影響も確認

画面（UI/Override）

• UIポリシー、Client Script（onChange/onLoad）を確認
• Dictionary Overrideの有無を確認
• キャッシュ・反映ズレを疑い、クリアして再テスト

この手順で「どこで直ったか」をメモしておくと、次に似た現象が出たときに一気に楽になります。

再発を減らす設計のコツ

Referenceフィールド周りは、作り込みすぎるほど壊れやすいです。おすすめは次の考え方です。

• Qualifierは“必要最小限”から始め、後で強める
• 動的Qualifierは、戻り値が空のときの扱いを必ず決める（ゼロ件にするのか、広げるのか）
• 表示フィールドは、参照先のデータ設計とACL設計をセットで考える
• UIで無理に制御するより、まずはデータと権限で正しく制御する（UIは最後）

CSA学習としては、ここを「丸暗記」ではなく、

• Referenceは“参照先検索”をしている
• 候補が出る条件は「絞り込み × 権限 × UI」
• どれか1つでも欠けると“選べない”
  という因果関係で理解しておくと、応用が効きます。

体系的に学ぶなら

Referenceのトラブルシュートは、知識が点で増えると余計に迷いやすい分野です。
辞書、ACL、スクリプト、UI制御がつながっているので、管理・開発の基礎を一通りつなげて学べる教材があると効率が上がります。

Udemyには、ServiceNowの管理（辞書・フォーム・ACL）から、参照フィールドやQualifier、デバッグの考え方までを一連で扱う講座がいくつかあります。あなたの学習ペースに合わせて、「辞書とACLを触るハンズオンが多いもの」から選ぶのが失敗しにくいです（試験対策というより、仕組み理解の土台固めとしておすすめです）。

まとめ

Referenceが選択できないときは、原因が多そうに見えて、実は整理できます。ポイントは「現象を3パターンに分けて、順番どおりに潰す」ことです。

• 候補がゼロなら、まず絞り込み（Reference Qualifier）を疑う
• 管理者だけOKなら、次に権限（参照先テーブル／表示フィールドACL／ドメイン）を疑う
• それでも説明できないなら、UIポリシーやClient Script、辞書Overrideなど画面側を疑う

この順番で見れば、原因特定が早くなり、不要な設定変更も減らせます。
CSA学習でも同じで、「Referenceは参照先検索であり、候補表示は 絞り込み × 権限 × UI の掛け算」という理解ができると、問題を見たときに慌てなくなります。