なぜReferenceは混乱しやすいのか
ServiceNowを学び始めたころ、Referenceフィールド（参照フィールド）で最初に引っかかりやすいのがここです。
「画面に見えている文字」と「テーブルに保存されている値」が一致していないことがよくあります。
たとえばIncidentの「Assigned to（担当者）」に「Taro Yamada」と表示されていたとします。
見た目はただの名前ですが、データベース的には“名前”を保存しているわけではありません。Referenceフィールドが保存しているのは、参照先レコードを一意に特定するためのID（sys_id）です。
- 保存されるのは sys_id（実体の値）
- 画面に出るのは Display Value（人が読める表示名）
この2層構造を理解すると、次のような疑問が一気に整理できます。
- 「なぜCSVで見ると担当者が英数字の長い値（sys_id）になるの？」
- 「APIで取得したら sys_id だけ返ってきた。画面の名前はどこ？」
- 「参照候補の検索で出てくる列と、選択後にフィールドに入る文字が違うのはなぜ？」
CSA対策としても、この“値と表示の分離”を前提にして学ぶと、ACLやフォーム、インポート、Flowなどの理解がスムーズになります。
この先は、「じゃあ、そのDisplay Valueってどこで決まっているの？」を、設定箇所と動きの順番でほどいていきます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Display Valueの決まり方｜参照先テーブルの「Display Field」が本体
結論から言うと、Referenceフィールドに表示される文字（Display Value）は、参照先テーブル側で決まります。
つまり、Incident側の「Assigned to」フィールドが“何を表示するか”を持っているのではなく、**sys_user（ユーザーテーブル）の「どの列を代表表示にするか」**が効いてきます。
参照先テーブルには「代表して表示する列」がある
ServiceNowでは、各テーブルに対して Display Field（表示フィールド） を設定できます。
このDisplay Fieldが、そのテーブルのレコードを参照したときに画面へ出す“顔”になります。
例：
- sys_user のDisplay Fieldが「name」なら、担当者は “山田 太郎” のように表示される
- cmn_location のDisplay Fieldが「name」なら、場所は “Tokyo HQ” のように表示される
- incident のDisplay Fieldが「number」なら、関連インシデントは “INC0012345” のように表示される
どこで設定する？
初学者が迷いやすいので、探し方を“手順として”押さえておくのが安心です。
- 参照先テーブルのフォームを開く（例：ユーザーを1件開く）
- フォームのヘッダやフィールドを右クリックして 「Configure Dictionary」 へ進む（権限により表現は多少変わります）
- 対象テーブルの辞書（sys_dictionary）で、どのフィールドが Display=true になっているか確認する
ここでポイントなのは、**Display Fieldは基本的に「そのテーブルで1つ」**ということです。
なので、もしsys_userのDisplay Fieldを別の列に変えると、Assigned toだけではなく、sys_userを参照する全フィールドの表示がまとめて変わることになります。
（実務ではこの影響範囲が大きいので、むやみに変えるより“別のやり方”で解決するケースが多いです）
Displayが未設定ならどうなる？
環境やテーブル定義によっては、Display=trueが明示されていない場合があります。
そのときはプラットフォームが“それっぽい列”を探して表示します。典型的には number や name のような列です。
ここは暗記よりも、「表示に使う列が見つからないと困るから、プラットフォームが代わりを探すんだな」くらいの理解でOKです。
ただし、意図しない列が表示に採用されると、後から「なんでこんな表示？」となりやすいので、テーブル設計やカスタムテーブル作成時は早めにDisplay Fieldを意識すると事故が減ります。
“候補リストに見える列”と“実際の表示値”は別物
Referenceフィールドで混乱が続く理由のひとつが、ここです。
候補リスト（虫眼鏡やオートコンプリート）に表示される列と、選択後にフィールドに入る表示値は、同じとは限りません。
フィールドに入るのは「Display Value」＝参照先テーブルのDisplay Field
これは第2章の通りで、基本は一本筋です。
選択後にフォーム上のReferenceフィールドに表示されるのは、参照先テーブルのDisplay Fieldの値です。
でも候補リストは「見やすいように」複数列を出せる
たとえばユーザー検索で、名前だけだと同姓同名が多くて困ることがあります。
このとき候補リストに「email」「department」などを並べたくなるのは自然です。
ここで大事なのは、候補リストを見やすくする設定をしても、Display Valueそのものは変わらないということです。
- 候補リスト：名前＋メール＋部門…みたいに複数列で表示できる
- フィールド本体：最終的に入る表示値はDisplay Fieldの値（通常は1列）
この差を理解していないと、
「候補リストでメール見えてるのに、選んだら名前しか入らない。バグ？」
となりますが、仕様としては自然な動きです。
“検索できる項目”も、見えている列と一致しないことがある
もう一段ややこしいのが、候補リストに列として見えていても、その列で検索が効くとは限らない点です。
たとえば候補リストに部門が出ていても、検索ボックスで部門名を入れてもヒットしない…というケースがあります。
これは「検索対象」と「表示列」が別設定であるためで、表示を増やすだけで“検索性”まで改善するとは限りません。
実務だと「同姓同名の見分け」だけが目的なら表示列追加で十分、
「メールで検索したい」なら検索対象の設計まで踏み込む、という判断になります。
CSAの段階では、ここを細かい属性名まで暗記する必要はありません。
ただ、“表示（見せ方）”“検索（探し方）”“保存（sys_id）”が別レイヤーだと理解しておくと、問題文の意図を読み違えにくくなります。
表示が想定と違う時の確認手順
ここからは実務寄りに、「Referenceの表示が変／思ったのと違う」時に、どこを見ると早いかを整理します。
CSA学習としても、丸暗記より“原因の当たり”を付けられるようになるのが強いです。
参照先テーブルのDisplay Fieldはどれか
まずは基本に戻って、参照先テーブルのDisplay Fieldを確認します。
- 参照先が sys_user なら、sys_userのDisplay設定
- 参照先が cmn_location なら、cmn_locationのDisplay設定
ここが変わっていると、参照している全フィールドに影響します。
「昨日まで表示がこうだったのに、今日変わった」系は、まずここを疑うのが筋が良いです。
同じ表示名が多すぎないか
Display Fieldに指定した列が、重複しやすい値だと運用が苦しくなります。
例：
- ユーザーのDisplayが「first_name」だけ（同名が大量発生）
- カスタムテーブルのDisplayが「状態」みたいな選択肢（全件ほぼ同じ表示）
この状態だと、参照候補で選び間違いが増えます。
実務では「一意に近い」「人間が見て区別しやすい」列をDisplayに選ぶのが定石です。
表示は正しいのに、候補リストが見づらい
「表示値はOK。でも検索候補が見づらい」なら、Display Fieldを変えるより、候補リストの見せ方を調整する方向が安全です。
Display Fieldを変えると影響範囲が大きいので、まずは“見せ方の改善”で解決できないかを検討します。
Portal / Workspaceだけおかしい
同じ参照フィールドでも、Classic UIとPortal、Workspaceなどで挙動が違って見えることがあります。
この場合、Display Fieldの問題ではなく、コンポーネント側の設定・属性・表示列が原因のことが多いです。
「どの画面でも同じ表示がおかしい」のか
「特定の画面だけおかしい」のか
を切り分けるだけで、調査コストがかなり下がります。
スクリプト／インポートでセットした値が“sys_idか表示値か”を混同していないか
インポートやスクリプトでReferenceをセットするときに、事故りやすいのがここです。
- setValue でsys_idを入れる（正攻法）
- 表示名で入れたいなら setDisplayValue を使う（状況により）
「表示名を入れたつもりなのに別人が入った」
「空になった」
といった場合は、そもそも“何を入れたか”がズレていることがあります。
設計のコツ＆学習の進め方
最後に、Reference表示値の理解を“設計と学習”に落とします。
ここを押さえると、CSAの範囲を超えて、開発・運用の判断がラクになります。
Display Fieldを変える前に考える3つのこと
Display Fieldは強力ですが、変更は慎重にした方がいいです。理由は単純で、影響範囲が広いからです。
変更前に、最低でも次を考えると失敗しにくいです。
- 影響範囲：そのテーブルを参照する全フィールドに影響する
- 一意性：同じ表示が大量発生しないか（検索・選択ミスが増える）
- 運用目線：現場が“この表示で選べる”状態になるか
「候補リストで見分けたい」だけなら、Display Fieldを変えずに、候補リストの列や並び順で解決できることがよくあります。
カスタムテーブルを作るときは“番号＋名称”の発想が強い
実務で迷いにくい形として、よくあるのが次です。
- number（自動採番・ユニーク）
- name / short_description（人間が読む名称）
Display Fieldはnumberにすることが多いですが、運用によってはnameの方が分かりやすいケースもあります。
大切なのは「あとから検索して、迷わず特定できるか」。ここを基準に選ぶとブレません。
API・連携で困る人は“display_valueの返し方”も押さえる
画面ではDisplay Valueが見えるのに、APIで取るとsys_idだけで困る…は、かなり典型です。
RESTやSOAPには表示値を一緒に返すためのオプションがあります（環境・用途で使い分け）。
CSAの段階では「そういう仕組みがある」まで理解しておくと、学習が実務につながりやすいです。
学習の進め方：辞書（Dictionary）→参照→フォームの順で積む
おすすめの学び順はこれです。
- Dictionary（sys_dictionary）：フィールド定義が“どこにあるか”
- Referenceの原理：保存はsys_id、表示はDisplay Field
- フォーム／リスト：見せ方（候補リストの列、検索性）の話
ここがつながると、ACLやImport Set、Flow Designerの理解も一段ラクになります。
体系的に学びたい人へ
独学だと、Reference・Dictionary・UIの話がバラバラに入ってきて、どこかで「あれ、結局どこが原因？」となりがちです。
そういうときは、テーブル設計・Dictionary・Referenceを“順番に”扱ってくれる教材を1つ挟むと、理解が安定します。
Udemyには、ServiceNowの管理基礎（テーブル／フィールド／参照／フォーム設定）を一通りなぞれる講座がいくつかあります。
「辞書 → 参照 → フォーム」の流れで復習できるものを選ぶと、このテーマは特に回収しやすいです。
（講座選びの基準は、画面操作が多く、DictionaryとReferenceをセットで説明しているか、を目安にすると外しにくいです）
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
Referenceフィールドで表示される値は、Incident側の設定で決まるというより、参照先テーブルの“代表表示（Display Field）”で決まるのが基本です。Referenceが保存している実体はsys_idで、画面に見えるのはDisplay Value。この分離を理解すると、CSVやAPI、インポート、フォーム挙動の「なんで？」が整理されます。
また、候補リストに出る列（見やすさのための表示）と、フィールドに入る表示値（Display Field）は別物になり得ます。表示が想定と違うときは、まず参照先テーブルのDisplay Fieldを確認し、次に重複しやすい設計になっていないか、特定画面だけの問題ではないか、スクリプトやインポートで“sys_idと表示値を混同していないか”を順に切り分けると早いです。
CSAの学習としては、属性名を丸暗記するより、「保存（sys_id）／表示（Display Value）／見せ方（候補リスト）／検索（探し方）」が別レイヤーだと腹落ちさせるのが近道です。必要なら、Udemyなどの講座でDictionary→Reference→フォームの順に通しで復習すると、知識が線になって定着しやすくなります。
