ServiceNowの操作でつまずく人の多くは、用語を一つずつ単語帳のように覚えようとして、画面と画面のつながりを見失っています。CSA（Certified System Administrator）試験も、用語の暗記そのものより「ある目的のデータに、どの経路でどう辿り着き、どう操作するか」を理解しているかを問う設問が中心です。
この記事では、ServiceNowの基本操作を「データに辿り着く一本の動線」として最初から最後まで通して扱います。インスタンスという土台に始まり、入口（Application Navigator・Global Search）、一覧（List）、詳細（Form）、レコード同士のつながり（Reference field と sys_id）、そして同じデータを別の形で見る Report と Dashboard まで、一続きの流れとして整理します。最後に、その流れをPDI（Personal Developer Instance）で実際になぞる手順を載せます。
- データに辿り着く一本の動線：入口 → 一覧 → 詳細 → つながり
- 前提：インスタンスと環境（dev / test / prod）の役割
- 入口：Application Navigator と Global Search で目的の機能へ
- 一覧：List で「絞る・並べる・再利用する」（Filter / Breadcrumb / Saved Filter）
- 詳細：Form で1件を確認・編集する（Related List / Personalize Form）
- つながり：Reference field は「表示値」でなく sys_id で結ぶ
- Report と Dashboard ——同じデータを別の形で見る
- 試験での判断：複数か1件か、表示値か内部IDか
- PDIで動線をひととおりなぞる手順
- よくある質問
データに辿り着く一本の動線：入口 → 一覧 → 詳細 → つながり
ServiceNowの画面操作は、バラバラの機能の寄せ集めではなく、一つの目的に向かって流れていく経路として捉えると一気に整理されます。
まず全体像を、データへ近づいていく順番で並べます。
- 土台：すべてのデータ・設定・アプリケーションが入っている箱が「インスタンス」。組織は用途別に dev / test / prod といった複数のインスタンスを使い分ける。
- 入口：目的の機能や画面へ移動する手段が Application Navigator。データそのものを横断的に探すのが Global Search。「どこへ行くか」と「何を探すか」で役割が分かれる。
- 一覧：目的のテーブルに着くと、複数のレコードが表形式で並ぶ List が開く。ここで絞り込み・並べ替え・条件の再利用を行う。
- 詳細：一覧から1件を開くと Form が開く。1件のレコードをじっくり確認・編集する場所。
- つながり：Form の中の項目には、別テーブルのレコードを指す Reference field がある。これは画面に見える名前ではなく、内部的には sys_id でレコードを結んでいる。
- 別の見え方：同じデータを集計・可視化したものが Report、複数のReportやウィジェットを1画面にまとめたものが Dashboard。
この6段の流れが頭に入っていると、後述する用語の一つひとつが「動線のどの位置にいる部品か」で理解できます。逆に言えば、CSA試験で問われるのは「この部品は動線のどこにあり、隣の部品と何が違うか」です。以降、各段を順に見ていきます。
前提：インスタンスと環境（dev / test / prod）の役割
動線の出発点である「インスタンス」を曖昧にしたまま操作を覚えると、後で必ず混乱します。ここを最初に固めます。
インスタンスとは「環境まるごと」
インスタンスとは、ある組織のためにデータ・設定・アプリケーション・ユーザー情報を、独立した実行空間として保持するServiceNowの環境一式です。重要なのは、インスタンスは単なるURLではなく、データベース・各種設定・アプリケーション・ユーザーデータを含む運用環境全体を指すという点です。「https://～.service-now.com というアドレスのこと」と誤解しがちですが、URLはあくまで入口で、その奥にある中身すべてがインスタンスです。
この区別はCSAの判断問題で効いてきます。「インスタンス＝メニュー構成のこと」ではありません。設定を変える、テーブルを足す、ユーザーを管理する——こうした操作の対象になる土台がインスタンスです。
なぜ環境を分けるのか：dev / test / prod
組織は通常、用途の異なる複数のインスタンスを並行して運用します。代表的な3つの役割は次の通りです。
横にスクロールできます
| 環境 | 位置づけ | 役割 |
|---|---|---|
| dev（開発） | 作る場所 | 設定・フォーム・テーブルなどを構築する |
| test（検証） | 確かめる場所 | 本番へ出す前に変更内容を確認する |
| prod（本番） | 動かす場所 | 日々の業務が回っている実環境 |
鉄則は「prod で直接試さない」ことです。変更は dev → test → prod の順で流していきます。CSAのシナリオ問題では、この環境の流れが明示されていなくても前提として隠れていることがよくあります。「本番でいきなり構成を変える」という選択肢が出てきたら、それは誤りを誘う選択肢だと判断できます。
そして学習・検証のためには、誰でも無料で取得できる Personal Developer Instance（PDI）が用意されています。この記事の最後で、PDIを使って動線を一通りなぞります。
入口：Application Navigator と Global Search で目的の機能へ
土台（インスタンス）に入ったら、次は目的の場所へ移動します。ここを担うのが Application Navigator と Global Search で、両者は役割が明確に違います。
Application Navigator：「どこへ行くか」の入口
Application Navigator（アプリケーションナビゲーター）は、利用可能なアプリケーションとモジュールを一覧表示し、UI上を移動するためのナビゲーション部品です。ここでいうモジュールとは、ナビゲーター内のメニュー項目、つまり「行き先」のことです。
主な機能は次の通りです。
- アプリケーションとモジュールへアクセスする
- 入力欄でフィルタ・検索して目的のモジュールを素早く絞り込む
- Favorites（お気に入り）タブ：よく使う行き先を固定して登録しておく
- History（履歴）タブ：最近開いた画面を辿る
- All：モジュールを網羅的に一覧表示する
ナビゲーションで毎回「あの機能はどこだっけ」と探していると、それだけで作業の着手が遅れます。よく使うモジュールは Favorites に登録するか、ナビゲーターの絞り込み入力を使って、探す時間をなくすのが定石です。
ポイントは、Application Navigator が探すのは「行き先（メニュー構成）」であって、業務データそのものではないことです。
Global Search：「何を探すか」のデータ検索
Global Search（グローバル検索）は、統一されたインターフェースから複数のレコードタイプを横断して検索する機能です。Unified Navigation（統一ナビゲーション）のヘッダーに配置されています。
特徴は次の通りです。
- 複数のレコードタイプを同時に検索する
- 例えば Incident・Knowledge・Catalog といった異なるカテゴリにまたがって結果を返す
- 検索対象は実際のデータであって、メニュー構成ではない
ここが Application Navigator との決定的な違いです。Application Navigator は「どこへ行くか（where）」を扱い、Global Search は「何を探すか（what）」を扱います。「あるインシデント番号のレコードを直接出したい」ときは Global Search、「インシデント一覧のモジュールを開きたい」ときは Application Navigator、という使い分けになります。
一覧：List で「絞る・並べる・再利用する」（Filter / Breadcrumb / Saved Filter）
入口を抜けて目的のテーブルに着くと、複数のレコードが表形式で並ぶ List（リスト）が開きます。List はテーブルの中身を複数件まとめて扱う場所です。
List の基本：複数レコードを比較・絞り込み・一括操作
List の役割は、レコードを表形式で表示し、絞り込み・並べ替え・比較を行うことです。1件をじっくり見るのではなく、多数のレコードを俯瞰して扱うための画面です。
Filter（フィルタ）と Saved Filter（保存フィルタ）
- Filter：条件を指定して、表示する行をその場で絞り込む。今のセッションに適用される一時的な絞り込み。
- Saved Filter：絞り込み条件を保存し、繰り返し再利用できるようにしたもの。
毎回手作業で同じ条件を組み直していると、非効率なうえに、条件の付け方がぶれて見落とし（可視性のギャップ）が生まれます。よく使う条件は Saved Filter として保存し、条件の組み直しをなくすのが正しい使い方です。
Breadcrumb（パンくず）フィルタ
リスト上部に表示される Breadcrumb は、いま効いている絞り込み条件を視覚的に示すものです。表示された条件をクリックして、条件の一部を外したり、絞り込みを段階的に緩めたりできます。「今このリストにどんな条件が掛かっているか」を一目で確認・修正できる部品だと理解してください。
列のカスタマイズと一括更新
- Personalize List（リストの個人設定）：表示する列を利用者個人の好みに合わせて調整する。
- 一括操作：権限の範囲内であれば、複数レコードをまとめて更新できる。
「多数のレコードをまとめて処理する」という発想ができるのが List の強みです。
詳細：Form で1件を確認・編集する（Related List / Personalize Form）
List で目的の1件を開くと、Form（フォーム）が開きます。Form は1件のレコードを深く確認・編集する場所です。
Form の基本：単一レコードの確認と編集
Form の役割は、1件のレコードの詳細を確認し、項目を編集することです。ワークノートを読む、項目を入力する、内容を精査する——いずれも1件に対する深掘りの操作です。
主な構成要素は次の通りです。
- Form section / Form Layout（フォームセクション／レイアウト）：項目の並びや組織化のされ方。
- Related List（関連リスト）：いま開いているレコードに紐づく、別テーブルのレコードを表示する領域。1件のレコードから、それに関係する他のレコード群へ視線を広げられる。
Personalize Form と Form Layout は「適用範囲」が違う
Form の見た目を変える操作には2種類あり、適用範囲が決定的に違います。ここはCSAで頻出の判断ポイントです。
- Personalize Form（フォームの個人設定）：Core UIでは、フォームに配置済みの項目を自分の画面で表示・非表示にする設定。項目の順序変更、未配置の項目追加、必須項目の非表示はできません。
- Form Layout（フォームレイアウト）：対象テーブルのView・セクションの構成を変更する設定。AvailableからSelectedへ表示項目を追加し、Selected内で順序を変えます。同じViewを使う利用者へ影響するため、個人設定とは分けて扱います。
「自分だけ既存項目を隠したい」ならPersonalize Form、「フォームへ項目を追加したい・並べ替えたい」ならForm Layoutを考えます。共有範囲だけでなく、変更したい操作そのものも選択の基準です。仕様の確認先：Personalize a form、Configuring the form layout。
Form LayoutのAvailableとSelectedを実フォームにつなぐ
先に考えてみましょう：フォームに表示する項目を構成するとき、AvailableとSelectedのどちらへ置けばよいでしょうか。
フォームの構成メニューからForm Layoutを開き、対象のテーブル・Viewを確認します。Availableは追加候補、Selectedはそのレイアウトに配置する項目です。保存して同じViewのフォームに戻り、選んだ項目がどこに表示されるかを照合します。
今回確認した結果：Change RequestのCHG0030001を使い、学習用Viewへ7項目を配置しました。保存直後は別のViewへ戻ったため、フォームのViewメニューで学習用Viewを選び直し、Watch listを含む7項目の表示を確認しました。保存先のViewと表示中のViewを一致させることが確認の要点です。
確認環境：ServiceNow PDI／Core UI、Change Request、学習用View「PDI Learning 20260910」、管理者ユーザー。確認日：2026-09-10。
判断のポイント：フォームの構成を編集するForm Layoutと、自分の見え方を調整するPersonalize Formを区別します。Form Layoutの変更は対象Viewなどの設定範囲で扱い、管理者1人の画面確認だけで全利用者の表示を断定しません。
Personalize Formで自分の表示を調整する
先に考えてみましょう：自分のフォームから項目を隠すと、そのフィールド自体や保存済みデータもなくなるのでしょうか。
Personalize FormでDescriptionを非表示にし、同じ利用者のフォームで変化を確認します。続いて再表示し、元の文章が戻るかを見ます。フィールドを削除する操作や、アクセス権を拒否するACLの設定とは分けて考えます。
今回確認した結果：同じCHG0030001・同じView・同じ利用者で、Descriptionを非表示にし、再表示すると元の文章が戻ることを確認しました。レコード内容をUpdate／Submitする操作は行っていません。これは今回の本人の表示調整を確認した結果です。
確認環境：ServiceNow PDI／Core UI、Change Request、学習用View「PDI Learning 20260910」、管理者ユーザー。確認日：2026-09-10。
判断のポイント：Personalize Formは自分の表示調整です。見えないことと、データが存在しないこと・参照権限がないことを同じ意味にしないようにします。
List と Form の使い分け
ここまでで List と Form の対比が見えてきます。整理すると次の通りです。
横にスクロールできます
| 画面 | 目的 | 対象レコード数 | 主な使いどころ |
|---|---|---|---|
| List | 表形式での表示・絞り込み・並べ替え | 複数 | 比較する・絞り込む・一括処理する |
| Form | 詳細表示・項目編集 | 1件 | 編集する・精査する・ワークノートを読む |
覚え方はシンプルで、「List は多数、Form は1件の深掘り」です。複数を扱いたいのに Form を開いて一件ずつ処理しようとしたり、1件をじっくり見たいのに List 上で済まそうとしたりすると、操作がかみ合いません。
なお、List の各行も Form の1件も、その背後にあるのは「テーブルの中の1レコード」です。テーブル（table）は複数のレコードを収める入れ物、レコード（record）はその中の1行を指します。List はテーブルの中身を複数件並べたもの、Form はその中の1件を詳細表示したもの——という関係を押さえておくと、次の Reference field の話がつながります。
つながり：Reference field は「表示値」でなく sys_id で結ぶ
ここまでで1件のレコードに辿り着きました。次は、レコードとレコードがどう結ばれているかです。これを担うのが Reference field で、CSAで最も誤解されやすい部分です。
表示値（Display value）と内部ID（sys_id）
ServiceNowの各レコードには、人が読む値と、システムが使う値の2つの顔があります。
- Display value（表示値）：画面に表示される、人が読むためのラベル（名前、タイトルなど）。
- sys_id：レコードごとに割り振られる一意の内部識別子。データの整合性や連携（インテグレーション）の基礎になる。
Reference field（参照項目）は、別テーブルのレコードを指し示す関連付けの項目です。画面上は相手レコードの「表示値（名前など）」が見えますが、ServiceNow内部ではその表示値ではなく sys_id を使って相手のレコードを結んでいます。
なぜ sys_id で結ぶことが重要なのか
Reference欄が通常sys_idを保存することと、インポート時の照合キーは別の話です。既存レコードを更新するImportでは、Coalesceに社員番号やExternal IDなど、一意で安定した項目を選べます。「インポートなら必ずsys_id」とは判断しません。今回のCoalesceの実演もExternal IDで既存行を照合しています。仕様の確認先：Display values、Updating records using coalesce。
CSVからReference欄へ値を入れるときも、取込元にsys_idが入っていることが必須とは限りません。Field Mapでは入力値を参照先の列と照合し、見つかったレコードのsys_idを保存できます。参照先の照合列を指定しない場合は表示値の列を使うため、名前による照合も仕組みとして存在します。ただし同名や表記ゆれで取り違えないよう、選ぶ照合列の一意性と入力値を確認します。仕様の確認先：Create a field map。
試験でも実務でも、「見えている名前」と「実体を指す sys_id」を切り分けて考えることが、Reference field を理解する核心です。
Report と Dashboard ——同じデータを別の形で見る
動線の最後は、辿り着いたデータを「別の形」で見る段です。List/Form が個々のレコードを扱うのに対し、Report と Dashboard は同じデータを集計・可視化して俯瞰します。
- Report（レポート）：特定の切り口でデータを集計した、1つの可視化。例えば「未解決インシデントを担当者別に集計した棒グラフ」のような単一のビュー。
- Dashboard（ダッシュボード）：複数のReportやウィジェットを1画面にまとめ、1つの画面で状況把握・意思決定を支援する入れ物。
押さえるべき本質は、ReportもDashboardも、元になっているデータは List/Form で扱っているのと同じレコードであるという点です。同じデータを、用途に応じて違う形で見せているにすぎません。List で個別に絞り込んで見るのか、Report で集計して傾向を見るのか、Dashboard で複数の指標を一望するのか——見せ方が違うだけで、土台のデータは一続きです。
この「同じデータの別の見え方」という関係が分かっていると、「Reportは1つの可視化、Dashboardはそれらをまとめた器」という違いも自然に区別できます。
試験での判断：複数か1件か、表示値か内部IDか
ここまでの動線を、CSA試験で問われる「判断の軸」として整理し直します。CSAは手順の丸暗記ではなく、役割の見分けを問います。設問に迷ったら、次の3つの軸のどれを問われているかを見極めてください。
軸1：複数か、1件か
- 複数のレコードを扱う → List
- 1件のレコードを深掘りする → Form
- 「一覧で絞り込む／並べ替える」は List、「1件を編集する／ワークノートを読む」は Form。
軸2：表示値か、内部IDか
- 画面に見える人間用のラベル → Display value
- レコードを一意に指す実体 → sys_id
- Reference欄の保存値を問うのか、Importの照合キーを問うのかを区別する。照合キーは一意性と入力データから選び、sys_idだけに限定しない。
軸3：自分の表示設定か、対象Viewのフォーム構成か
- 自分の画面だけ変える → Personalize Form / Personalize List
- 対象Viewのフォーム項目を追加・並べ替える → Form Layout
- 「適用範囲はどこまでか」を意識する。
さらに、入口の見分けも一つの軸です。
軸4：行き先（where）か、データ（what）か
- 機能・画面へ移動したい → Application Navigator
- レコード・データを横断検索したい → Global Search
そして全体の前提として、インスタンス＝メニュー構成ではなく運用環境全体であること、変更は dev → test → prod の順で流すことが、多くのシナリオ問題の土台に隠れています。選択肢に「本番で直接試す」が混ざっていたら誤答だと判断できます。
これらの軸は、別々の暗記項目ではなく、冒頭で示した「入口 → 一覧 → 詳細 → つながり → 別の見え方」という一本の動線の、それぞれの分岐点にあたります。動線で理解しておけば、設問が動線のどの位置の話をしているかで、問われている軸が見えてきます。
PDIで動線をひととおりなぞる手順
ここまでの動線は、読むだけでなく自分のPDI（Personal Developer Instance）で一度なぞると、一気に身につきます。PDIは無料で取得できる学習・検証用のインスタンスです。以下の順で、入口から別の見え方まで通して触ってください。
なお、ServiceNowは画面UIの世代によって細部の見た目が異なります。お手元のPDIの画面と照らし合わせながら進めてください。
手順1：インスタンスにログインし、環境であることを体感する 取得したPDIのURLからログインします。URLはあくまで入口で、ログインした先のデータ・設定・アプリすべてがこのインスタンスの中身であることを意識します。
手順2：Application Navigator で行き先を探す 左側（または上部）の Application Navigator の絞り込み入力に「incident」と打ち込み、表示されたモジュールから Incident の一覧（All など）を開きます。よく使う行き先として、その場で Favorites（お気に入り）に登録してみます。History タブに、今開いた画面が残ることも確認します。
手順3：Global Search でデータを直接探す ヘッダーの Global Search に、既存のインシデント番号やキーワードを入力し、複数のレコードタイプにまたがって結果が返ることを確認します。手順2が「行き先（where）」、手順3が「データ（what）」だという違いを体で覚えます。
手順4：List で絞る・並べる・保存する Incident の List で、状態（State）などを条件に Filter をかけます。上部の Breadcrumb に条件が表示されることを確認し、条件の一部をクリックして外してみます。次に、その条件を Saved Filter として保存します。さらに Personalize List で表示する列を1つ追加・削除してみます。
手順5：Form で1件を深掘りする List から1件のインシデントを開きます。Form のセクション構成と、下部の Related List（関連リスト）を確認します。Core UIのPersonalize Formで、配置済みの非必須項目を自分の画面で表示・非表示にしてみます。未配置項目の追加や順序変更とは違う操作で、他ユーザーの個人設定は変わりません。
手順6：Reference field の表示値と sys_id を切り分ける Form 上で、Assigned to や Caller などの Reference field を確認します。画面には相手の名前（表示値）が見えますが、これが内部では sys_id で結ばれていることを意識します。リストやフォームのコンテキストメニュー等から sys_id を確認できる場合は、表示値とは別物のIDが割り当てられていることを見ておきます。
手順7：同じデータを Report と Dashboard で見る 最後に、いま絞り込んでいたインシデントのデータを元に、簡単な Report（例：状態別の件数）を作ってみます。作った Report を Dashboard に配置し、複数の見せ方を1画面にまとめます。List/Form で見ていたのと同じデータが、集計・可視化という別の形で見えることを確認して、動線を一周します。
この一周を体験しておくと、CSAの設問が「動線のどの位置の話か」を即座に当てられるようになります。
よくある質問
Q1. この記事の内容はCSA試験対策に役立ちますか。 役立ちます。用語そのものの暗記ではなく、「入口 → 一覧 → 詳細 → つながり → 別の見え方」という動線と、その各分岐での判断軸（複数か1件か、表示値か sys_id か、個人か組織全体か、行き先かデータか）を整理しているためです。CSAはこの役割の見分けを問う設問が中心です。読了後は、CSA対策のハブ記事で全体像を確認し、模擬試験で弱点を特定すると定着が早まります。
Q2. List と Form、結局どちらをいつ使えばよいですか。 複数のレコードを比較・絞り込み・一括操作したいときは List、1件のレコードを編集・精査したいときは Form です。List はテーブルの中身を複数件並べたもの、Form はその中の1件を詳細表示したもので、背後にあるレコードは同じです。「多数か、1件の深掘りか」で選んでください。
Q3. Reference field で、名前とsys_idを区別するのはなぜですか。 通常、画面には参照先の表示値が見え、Reference欄にはそのレコードのsys_idが保存されるためです。一方、Importの照合にはExternal IDなど別の一意な項目も使えます。名前を使う場合も、照合対象の列や同名データの有無を確認します。保存値と照合キーを分けて考えることが要点です。
