CSAの「インスタンス設定（Instance Configuration）」は、用語の数が多くて丸暗記しづらい領域です。System Properties、Branding、Personalize Form、Update Set、plugin……名前を覚えても、試験では「どれを使う場面か」を問われるため、用語の対応表だけでは点が伸びません。
このドメインを安定して取るコツは、ひとつだけあります。変更を「誰に影響するか」で並べ替えることです。ServiceNowの設定は、自分一人にしか効かないものから、全ユーザーに効くもの、さらにインスタンスをまたいで本番に届くものまで、影響の半径が違います。半径の内側と外側を取り違えると、本来は安全な操作で本番を壊したり、逆にいくら設定しても他の人に反映されなかったりします。
そこでこの記事では、インスタンス設定を「影響範囲の同心円」として描き直します。中心に個人設定、その外側に全体設定、いちばん外側に本番への移送（Update Set）を置き、間に configuration と customization の境界、通知の設計を挟みます。試験で問われるのは結局この同心円のどの層の話なのか——そこを見抜けるようになるのがゴールです。
- インスタンス設定は「影響範囲」で考えると間違えない
- 一番内側：個人設定（Personalize Form / User Preferences）——自分だけに効く
- 外側：全体設定（System Properties / Branding / Theme）——全ユーザーに効く
- configuration と customization の境界（plugin / Store app / baseline）
- 通知（Notification / Email Template）——飛ばない・飛びすぎるを防ぐ
- 一番外側：本番への移送（Update Set：Preview → Commit）——直接変更しない
- 試験で問われる判断パターン（個人か全体か・構成かデータか）
- PDIでUpdate Setを作って移送を体験する手順
- まとめ
- よくある質問
インスタンス設定は「影響範囲」で考えると間違えない
まず全体像です。ServiceNowの設定変更は、影響の届く範囲で次の3つの層に分けられます。
- 個人の層：操作している自分のアカウントにだけ効く。他の人の画面は何も変わらない。
- 全体（インスタンス）の層：そのインスタンスを使う全ユーザーに効く。会社のロゴ、システムの既定動作、通知の飛び方など。
- インスタンス間の層：開発インスタンスで作った設定を、検証・本番へ「移送」する。ここを通さずに本番を直接いじるのが事故の元になる。
CSAの設問は、ほぼ必ずこの3層のどこかに位置します。たとえば「あるユーザーのフォームの並びを変えたら全員に反映されたか？」という問いは、個人の層と全体の層の区別を試しています。「開発で作ったUI Policyを本番に出すには？」はインスタンス間の層の話です。設問文に出てくる主語が「a user（あるユーザー）」なのか「all users（全ユーザー）」なのか、舞台が「this instance（このインスタンス）」なのか「production（本番）」なのかを最初に拾うだけで、選ぶべき機能の候補が一気に絞られます。
以降、内側の層から順に降りていきます。
一番内側：個人設定（Personalize Form / User Preferences）——自分だけに効く
同心円の中心は、操作している本人にしか影響しない設定です。ここはCSAで最も誤答を誘う層なので、丁寧に押さえます。
代表格が Personalize Form です。フォームを開いた状態で、表示するフィールドを自分の見やすいように足したり外したりできます。重要なのは、この操作は自分のビューだけを変えるもので、他のユーザーのフォームには一切影響しないという点です。同様にリスト側にも個人単位の調整があり、自分が見るリストの列の出し入れができます。
加えて、お気に入り（Favorites）の並び替え、最近見たレコードの履歴、自分の画面表示にまつわる好みなどは、まとめて User Preferences として本人単位で保持されます。これらはすべて「自分専用のカスタマイズ」であり、隣の席の同僚の画面には反映されません。
この内側の層を、次に出てくる全体の層と取り違えるのが定番の罠です。判断の基準はシンプルで、「個人の好みなら personalization、インスタンスの既定動作なら全体設定」。設問が「特定の一人の見え方」を扱っているなら、答えは個人の層の機能になります。
外側：全体設定（System Properties / Branding / Theme）——全ユーザーに効く
ひとつ外側の円は、そのインスタンスを使う全員に効く設定です。ここには性質の違う3種類が同居しているので、分けて理解します。
System Properties（システムプロパティ）
System Properties は、インスタンスの挙動や既定値を制御する設定です。「このインスタンスでは標準でどう振る舞うか」を決めるもので、個人の好みではなくインスタンス全体の既定動作を変えます。
実体は sys_properties テーブルに格納されており、フォーム経由で変更できるものもあれば、sys_properties から直接編集するものもあります。プロパティ名の多くは glide. で始まる名前空間を持ち、プラットフォームの基盤的な動作を司ります。ポイントは、System Properties をひとつ変えると、その影響は全ユーザーに及ぶことです。だからこそ個人設定とは明確に層が違います。
判断の軸は先ほどと同じで、「個人の好みなら personalization、インスタンスの既定動作なら System Properties」。設問が「全員に共通する既定の振る舞い」を変えたいなら、答えはこちらに寄ります。
Branding（ブランディング）と Theme（テーマ）
Branding は、組織としての見た目（ビジュアルアイデンティティ）を全体に適用する設定です。会社ロゴ、配色（カラー）、テーマ（Theme）、画面の基本的な既定の見え方などが含まれ、インスタンスやポータルをまたいで統一的に効きます。
ここで Personalize Form との違いがはっきりします。Branding は組織全体の見た目を一括で変えるもので、Personalize Form は個人の見え方だけを変えるものです。「ロゴ・色・テーマ」が出てきたら branding（全体）、「自分のフォームの列・表示の好み」が出てきたら personalization（個人）——この対応は試験で頻繁に問われます。
Company Profile（会社プロファイル）
全体設定の入口として、Company Profile も押さえます。ここでは会社名、ロゴ、タイムゾーンといった組織共通の情報を設定します。Branding／Theme による外観の調整と合わせて、「この会社のインスタンスはこう見える・こう呼ばれる」という全員共通の土台を作る場所だと捉えてください。
外側の層をまとめると、System Properties は「動作の既定値」、Branding／Theme は「見た目」、Company Profile は「組織情報」。いずれも全ユーザーに効くという一点で内側の層と区別されます。
configuration と customization の境界（plugin / Store app / baseline）
同心円の話に入る前に、もうひとつ重要な軸があります。その変更が configuration なのか customization なのかです。これは影響範囲とは別の「重さ」の軸で、CSAでは判断問題として頻出します。
baseline（標準状態）という基準点
すべての出発点は baseline（out-of-the-box、標準実装の状態）です。baseline は「ServiceNowが最初から備えている状態」であり、ある変更がどれだけそこから離れているかを測る基準点になります。設問が「標準機能でできるのか、独自改修が要るのか」を問うとき、頭の中に置くべき物差しがこの baseline です。
configuration と customization の違い
configuration（構成） は、ServiceNowの標準設定・標準機能の範囲内で行う調整です。フォームレイアウトの調整、UIの設定、System Properties の変更、標準機能の有効化などが該当します。特徴は、速く・低コストで・実装しやすいこと。標準の枠の中で完結するため、保守の負担も軽く済みます。
customization（カスタマイズ） は、標準状態（baseline）を超えて手を入れる変更です。組織固有の要件で標準の範囲では足りないときに行うもので、より深い改修を伴います。その分、複雑さ・保守コスト・所要時間が増えます。
判断の原則は明確で、「まず configuration、必要なときだけ customization」。CSAでは「この要件は標準設定で実現できるか？」と問われたとき、安易に customization を選ばず、まず configuration で届く範囲かを評価する姿勢が問われます。どこからが「重い改修」なのか——baseline を超えて深い手入れが必要になった地点が、その境界線です。
plugin と Store app の違い
configuration の代表的な手段が plugin（プラグイン） の有効化です。plugin は、インストール済みのアプリケーションに機能を追加し、プラットフォームの能力を拡張するために導入します。位置づけは「既存のプラットフォームやアプリの機能を有効化・拡張するもの」です。
これと混同しやすいのが Store app（ServiceNow Store のアプリ） です。Store app は ServiceNow Store から導入する追加のアプリケーションで、プラットフォームに新しいアプリそのものを足す形になります。
両者の違いを一言でいえば、plugin は既存の機能を有効化・拡張する／Store app は新しいアプリを追加する。「機能の拡張」なら plugin、「新規アプリの導入」なら Store app、と振り分けます。
なお、plugin や Store app を入れる前には事前確認が要ります。依存関係（dependency）のレビュー、そして有効化後に戻せるか（rollback の手順）を、導入前に確認しておくのが安全運用の基本です。plugin は一度有効化すると影響が全体に及ぶため、内側の層の個人設定とは扱いの慎重さが違います。
通知（Notification / Email Template）——飛ばない・飛びすぎるを防ぐ
全体設定の一種でありながら、独立して問われやすいのが通知です。CSAでは「通知が飛ばない」「逆に飛びすぎる」をどう設計で防ぐか、という観点で出ます。
通知（Notification）は、3つの要素で組み立てます。
- Condition（条件）：いつ・どのレコードで通知を発火させるか。
- Recipients（受信者）：誰に届けるか。
- Message body（本文）：何を伝えるか。
本文や件名の体裁を標準化する役割を担うのが Email Template（メールテンプレート） です。条件が満たされると通知が発火し、テンプレートが本文を整形して送られる、という流れになります。
そして送信が成功したかどうかは Email Logs（メールログ） で確認します。「通知が届かない」というトラブルの切り分けは、まずログで送信記録の有無を見るのが定石です。条件の設計ミスで発火していないのか、発火はしているが送信段階で止まっているのか——ログを見れば、原因が条件側にあるのか送信側にあるのかを分けられます。
通知設計の判断軸は、「条件で誰に何を、どんな体裁で届けるか」。発火条件が緩すぎれば飛びすぎ、厳しすぎたり受信者設定を誤れば飛ばない、という両方向の失敗を、Condition と Recipients と Template の3点で制御します。
一番外側：本番への移送（Update Set：Preview → Commit）——直接変更しない
同心円のいちばん外側は、ひとつのインスタンスの中の話ではなく、インスタンスをまたぐ層です。ここを担うのが Update Set です。
Update Set が運ぶもの・運ばないもの
Update Set は、構成（configuration／customization）の変更を記録して、別のインスタンスへ安全に移送する仕組みです。記録される代表例は、Business Rule、UI Policy、フォーム設定などの「設定・改修の変更」です。移送の経路は 開発 → 検証 → 本番（Development → Test → Production） が基本形になります。
ここで決定的に重要なのが、Update Set が運ぶのは「構成」であって「業務データ」ではないという線引きです。インシデントやユーザーといった実レコード（業務データ）を移すのは Update Set の仕事ではありません。データの移送は Import Set が担い、フィールドの対応づけは Transform Map、レコードの突合（重複判定）は Coalesce で行います。
つまり判断の原則は 「構成は Update Set、データは Import Set」。設問が「設定・改修を別環境へ出す」話なら Update Set、「レコードそのものを取り込む・移す」話なら Import Set + Transform Map です。この config か data かの軸は、CSAで非常によく問われます。
Update Set のライフサイクルと Preview → Commit
Update Set には状態があります。変更を記録している間は In Progress、移送の準備が整って閉じた後が Complete、そして移送時に取り込まない変更を Ignore（スキップ）として扱えます。
移送の核心は、Preview → Commit の2段階です。
- Preview は、対象インスタンスに適用する前に衝突（collision）を検出する検証ステップです。移送先で同じ部品が変わっていると衝突が起き、Preview がそれを洗い出します。
- Commit は、Preview で問題がないことを確認したうえで、実際に変更を対象インスタンスへ適用します。
ここで強調したいのが、「本番を直接いじらない」という原則です。本番で直接設定を変えるのではなく、開発で変更し、Update Set に記録し、Preview で衝突を確認してから Commit する。この経路を通すことで、いつ・何を・どの順で本番に入れたかが追えるようになり、衝突に気づかないまま本番を壊す事故を防げます。Commit 前に Preview を飛ばすのは、CSAでも典型的な誤りとして問われます。
外側の層をまとめると、Update Set は「構成を、Preview で衝突を見てから Commit で本番へ運ぶ」もの。内側の個人設定が「自分の画面を今すぐ変える」だったのに対し、この層は「全体に効く変更を、検証を挟んで段階的に届ける」ところに本質があります。
試験で問われる判断パターン（個人か全体か・構成かデータか）
ここまでの同心円を、CSAの設問が突いてくる「判断の分岐」として整理します。設問を読んだら、次の問いを順に当てはめてください。
- 影響は全体に及ぶか？ → 及ぶなら System Properties / Branding / Company Profile（全体の層）。
- 特定の一人の見え方だけか？ → そうなら User Preferences / Personalize Form / Personalize List（個人の層）。
- 条件に応じて誰かに知らせたいか？ → Notification ＋ Email Template。届かないときは Email Logs で切り分け。
- 構成（設定・改修）を別環境へ出すのか？ → Update Set（Preview → Commit）。
- 業務データを移す・取り込むのか？ → Import Set ＋ Transform Map（突合は Coalesce）。
- 標準の範囲で足りるか？ → まず configuration、超えるなら customization。機能拡張は plugin、新規アプリは Store app。
そして、得点を落としやすい代表的な引っかけはこの3つです。
- Personalize Form と Form Layout の混同。前者は個人（自分の見え方）、後者は管理者がフォームの項目配置を全体向けに整える設定。「個人の Personalize Form＝個人／管理者の Form Layout＝全体」と、層で覚える。
- 何でも Update Set で運ぼうとする。構成は Update Set、データは Import Set。レコードを Update Set で運ぼうとする選択肢は誤り。
- Commit の前に Preview を飛ばす。衝突検出を省くと本番で事故る。Preview → Commit の順は必ず守る。
設問の主語（a user か all users か）と舞台（this instance か production か）を最初に拾い、上の分岐に流し込む——この読み方が身につくと、用語を丸暗記していなくても正解の層にたどり着けます。
PDIでUpdate Setを作って移送を体験する手順
ここは読むだけでなく、必ず手を動かしてほしいパートです。Personal Developer Instance（PDI）で、実際に Update Set を作り、変更を記録し、Preview → Commit の流れを体験します。1つのPDIしか持っていなくても、Update Set が「変更を記録する箱」であることと、Preview が何を見るのかは十分に体感できます。
ステップ1：自分専用の Update Set を作る
アプリケーションナビゲーターで「Update Sets」を検索し、Local Update Sets（sys_update_set テーブル）を開きます。「New」から新しい Update Set を作成し、名前を付けて保存します。作成直後の状態が In Progress であることを確認してください。次に、画面上部の更新セット切替（gear / 更新セット選択）で、作った Update Set を current（現在の作業対象） に切り替えます。ここを切り替えないと、以降の変更が Default update set に記録されてしまうので注意します。
ステップ2：記録される変更を1つ作る
current にした状態で、追跡される構成変更を1つ行います。たとえば Incident フォームに対して Form Layout で項目の並びを少し変える、あるいは小さな UI Policy を1つ作ります（個人専用の Personalize Form ではなく、全体に効く Form Layout 側で行うのがポイント。Personalize Form は個人設定なので Update Set には乗りません）。
ステップ3：Update Set に変更が記録されたか確認する
作った Update Set を開き、関連リスト「Customer Updates（sys_update_xml）」を見ます。さきほどの変更が1行として記録されていれば成功です。ここで「個人設定（Personalize Form / User Preferences）は記録されず、全体に効く構成変更だけが記録される」ことを目で確認してください。これが内側の層と外側の層の違いの実物です。
ステップ4：Update Set を閉じて Complete にする
変更が揃ったら、Update Set のレコードで State を Complete に変更して保存します。これで「移送の準備ができた箱」になります。
ステップ5：Preview で衝突を確認する
本来は別インスタンスへ「Retrieved Update Set」として取り込んでから Preview しますが、PDIが1つの場合でも、Update Set レコードの「Preview Update Set」操作で何が適用されようとしているかと衝突の有無を確認できます。Preview の結果に collision（衝突）が出ていないか、出ているなら何と衝突しているかを読み取ります。Commit はこの Preview を通してから、という順序を体に入れるのがこのステップの目的です。
ステップ6：Commit する（または挙動を確認する）
Preview で問題がなければ Commit を実行します。Commit 後、対象側で変更が反映されていること、そして Update Set が適用済みの状態になっていることを確認します。
この一連を一度でも自分の手で通すと、「本番を直接いじらず、Update Set に記録し、Preview で衝突を見てから Commit する」という外側の層の作法が、言葉ではなく動作として残ります。試験でUpdate Setの状態（In Progress / Complete / Ignore）や Preview → Commit の順を問われたとき、画面の記憶から即答できるようになります。
まとめ
インスタンス設定は、用語を平面に並べると覚えきれませんが、「影響範囲の同心円」に置き換えると一気に見通せます。
- 個人の層：Personalize Form / Personalize List / User Preferences。自分の見え方だけを変え、他人には影響しない。
- 全体の層：System Properties（
sys_properties・既定動作）、Branding / Theme（見た目）、Company Profile（組織情報）。全ユーザーに効く。 - 重さの軸：baseline を基準に、標準の範囲なら configuration、超えるなら customization。機能拡張は plugin、新規アプリは Store app。
- 通知：Condition・Recipients・Email Template で「飛ばない・飛びすぎる」を制御し、Email Logs で切り分ける。
- インスタンス間の層：構成は Update Set（Preview → Commit、本番直接変更はしない）、データは Import Set + Transform Map。
CSAの設問は、この同心円のどの層を問うているのかを見抜けるかどうかで決まります。主語が「個人か全体か」、扱うものが「構成かデータか」——その2つを最初に判定すれば、選ぶべき機能はおのずと定まります。最後にPDIで Update Set を一度通しておけば、知識が判断と操作の両方で定着します。
よくある質問
Q1. Personalize Form と Form Layout は何が違うのですか？ 影響範囲が違います。Personalize Form は個人設定で、操作した本人のフォームの見え方だけを変え、他のユーザーには反映されません。一方 Form Layout は管理者がフォームの項目配置を整える全体向けの設定で、そのインスタンスを使う全員に効きます。Personalize Form の変更は Update Set に記録されませんが、Form Layout の変更は構成として記録されます。「個人か全体か」で見分けてください。
Q2. Update Set で業務データ（インシデントやユーザーのレコード）も移送できますか？ できません。Update Set が運ぶのは Business Rule・UI Policy・フォーム設定などの「構成」であり、業務データは対象外です。レコードそのものを移す・取り込むときは Import Set を使い、フィールドの対応づけは Transform Map、重複判定は Coalesce で行います。「構成は Update Set、データは Import Set」と覚えると取り違えません。
Q3. configuration と customization は、どこで線を引けばよいですか？ 基準は baseline（標準状態）です。ServiceNowの標準設定・標準機能の範囲内で済む調整（フォームレイアウト、System Properties、plugin の有効化など）は configuration で、速く低コストに実装できます。標準の範囲を超えて深い改修が必要になった時点から customization で、複雑さと保守コストが上がります。原則は「まず configuration、必要なときだけ customization」。設問では、安易に customization を選ぶ前に、標準設定で届く範囲かを評価する姿勢が問われます。
