ServiceNow CSAのインスタンス設定対策｜Company Profile・通知・Update Setの判断ガイド

ServiceNow CSAのインスタンス設定では、Company Profile・System Properties・通知（Notification）・Update Set といった設定が次々に出てきます。設定項目の名前は分かっても、「どれが誰に効くのか、変更をどう安全に移すのか、試験でどう判断するのか」が掴みにくい——そう感じている方は多いはずです。

この記事は、CSAで問われるインスタンス設定を、①各設定が何に効くか → ②影響範囲を取り違えると現場で何が起きるか → ③やりたいことから選ぶ早見表の順で理解するための記事です。用語の暗記ではなく、模試で迷わない判断軸を持ち帰ることをゴールにします。

▶ この分野の模擬試験を無料・登録不要で解く
CMDB・データ移行など分野別に分けた、AI生成のCSA模試です

そもそもインスタンス設定は「影響範囲」で考える

インスタンス設定は、「誰に効くか」「いつ・どこへ反映するか」で整理すると迷いません。

• 全体設定：System Properties・Company Profile・共通フォームレイアウトなど、全ユーザーに影響する
• 個人設定：User Preferences・Personalize Form / List など、自分の表示だけに効く
• 通知：Notification・Email Template で、条件に応じてメールを送る
• 構成移送：Update Set で、設定変更を開発→テスト→本番へ移す（業務データ移行ではない）

CSAで繰り返し問われる本質は、「その変更は全体か個人か」「設定変更か、データ移行か」を見分けられるかです。次の事故を見ると、影響範囲の取り違えが地味に怖いことが分かります。

これがないとどうなる ——「自分の一覧だけ直すつもりが、全ユーザーの画面を変えた話」

ある担当者が「自分のIncident一覧の列を少し変えたい」と思い、リストのコンテキストメニューからConfigure（List Layout）を開いて列を編集しました。すると翌日、全ユーザーのIncident一覧の列が変わってしまい、「画面が勝手に変わった」と問い合わせが殺到しました。本来は個人向けのPersonalize List（自分の表示だけ）を使うべきでした。

これは影響範囲を取り違えると起きることの典型です。同じ「列を変える」操作でも、全体（List Layout）か個人（Personalize List）かでまったく結果が違います。インスタンス設定は「誰に効くか」を意識しないと、よかれと思った変更が全員に波及します。

だからCSAは「影響範囲と移送」を問う ——鍵は「全体か個人か・構成かデータか」

こうした事故を避けられるかを確認するため、CSAの試験範囲にはCompany Profile・System Properties・通知・Update Set が含まれています。問われるのは設定手順の暗記ではなく、「その変更は誰に効くのか」「設定変更はどう本番へ移すのか」を正しく判断できるかです。

この先は、(1)迷ったとき立ち返る判断早見表、(2)主要な設定を「事故 → 放置するとどうなる → どう設定して防ぐ → 改善後」で、の順に、模試で迷わない判断軸を作っていきます。

インスタンス設定 判断早見表（迷ったらここに戻る）

インスタンス設定の問題は、やりたいこと（問題文）と使う設定を結べれば解けます。次の早見表が、この記事全体の地図です。各設定は後の章で事故付きで深掘りします。

ここからは、主要な設定を「実際に起きがちな事故」から見ていきます。事故の形を知っていると、選択肢の言い換えに惑わされなくなります。

全体設定 vs 個人設定：影響範囲を取り違える

現場で起きる事故：冒頭で紹介した「自分の一覧だけのつもりが全ユーザーの画面を変えた」事故がこれです。個人設定のつもりで全体設定（List Layout）を触ってしまいました。

放置するとどうなる：影響範囲を意識しないと、個人のつもりの変更が全員に波及したり、逆に全体に効かせたい設定が自分だけになったりします。原因切り分けにも時間がかかります。

CSAでこう使う：全体に効かせるならSystem Properties・Company Profile・共通Form/List Layout、自分の表示だけならUser Preferences・Personalize Form / Personalize Listを使います。「この設定は誰に効くか」を先に確認します。

改善後：変更前に影響範囲が分かり、想定外の全社波及や「自分だけ直らない」が起きなくなります。

早見表の該当行：「自分の表示だけ変える」→ User Preferences / Personalize。「全体の挙動を変える」→ System Properties。

Company Profile・Theme・レイアウト：見た目と配置を整える

現場で起きる事故：会社名・ロゴ・タイムゾーンが初期値のままで、通知やレポートの表記が実態と合わない。フォームも項目が雑然として入力ミスが起きていた。

放置するとどうなる：会社情報や見た目・配置が整っていないと、利用者の混乱や入力ミスが増え、ブランドの一貫性も損なわれます。

CSAでこう使う：会社情報はCompany Profile、見た目・ロゴ・色はTheme / Branding、フォームの項目配置はForm Layout / Form Designer、リストの列はList Layoutで整えます（選択肢の値はChoice List、項目定義はDictionary）。

改善後：表記・見た目・入力導線が整い、利用者が迷わず正しく操作できます。

早見表の該当行：「会社情報・ロゴを変える」→ Company Profile / Theme。「フォーム項目の配置」→ Form Layout。

通知：飛ばない・飛びすぎるを防ぐ

現場で起きる事故：「担当変更時に通知が来ない」「逆に大量の通知が飛ぶ」といった声が出た。誰も条件・宛先・送信状況を把握していなかった。

放置するとどうなる：通知の条件・宛先・送信履歴を管理しないと、必要な連絡が届かなかったり、無関係な人へ大量送信されたりして、運用の信頼が下がります。

CSAでこう使う：通知はNotificationで条件・宛先・本文を定義し、本文や件名はEmail Templateで整えます。送られたかはEmail Logsで確認し、不具合は「条件・宛先・イベント・ログ」を切り分けます。

改善後：必要な人に必要な通知が届き、過剰送信も防げます。トラブル時も原因を追えます。

早見表の該当行：「条件で通知メールを送る」→ Notification。送信確認＝Email Logs。

Update Set：本番へ「直接変更」せず安全に移送する

現場で起きる事故：急ぎの修正で、本番インスタンスのBusiness Ruleや設定を直接変更した。動いたものの、後で問題が出たときに戻せず、何を変えたのかも追えなくなった。

放置するとどうなる：本番を直接いじると、影響確認も切り戻しもできず、変更履歴も残りません。障害時に復旧が困難になります。

CSAでこう使う：構成変更（Business Rule・UI Policy・フォーム設定など）はUpdate Setに記録し、開発→テスト→本番へ移送します。本番へ適用する前にPreviewで衝突を確認し、Commitで適用します。なお業務データの移行はUpdate SetではなくImport Setを使います。Pluginは有効化前に依存関係と戻し方を確認します。

改善後：変更が記録・確認・切り戻し可能になり、本番障害のリスクが大きく下がります。

早見表の該当行：「構成変更を本番へ移す」→ Update Set（Preview→Commit）。データ移行＝Import Set。

「個人と全体・構成とデータ」を取り違える罠

インスタンス設定の判断問題は、影響範囲や移送手段を取り違えないかが問われます。具体シナリオに翻訳して違いを見ます。

「最も適切なのは？」と問われたら、「全体か個人か」「構成変更かデータ移行か」の軸で選びます。これが迷わないための判断軸です。

インスタンス設定の運用ベストプラクティス

設定変更を安全に回すために、現場で押さえておきたい運用のベストプラクティスは次の5つです。

1. 変更前に影響範囲を確認する。「全体か個人か」を見極めてから設定を選びます。
2. 本番を直接いじらない。構成変更はUpdate Setに記録し、開発・テストで確認してから移送します。
3. Commit前にPreviewする。衝突や問題を適用前に確認します。
4. 構成とデータを分ける。設定はUpdate Set、業務データはImport Setと使い分けます。
5. Pluginは事前確認してから有効化する。依存関係・影響・戻し方を確認します。

PDIで手を動かして確認する場所

Personal Developer Instance（PDI）で実際の画面を触ると、早見表が記憶に定着します。

• Company Profile / Theme・Branding：会社情報と見た目を確認する
• System Properties / User Preferences：全体設定と個人設定の違いを見る
• Form Layout・List Layout / Personalize Form・List：全体と個人の配置変更を比べる
• Notification / Email Template / Email Logs：通知の条件・本文・送信履歴を見る
• Update Set（Preview・Commit）/ Plugin：構成移送と機能有効化の流れを確認する

まとめ：影響範囲で選べると、判断問題に強くなる

• インスタンス設定は「全体か個人か・通知・構成移送」で考える
• 全体＝System Properties / Company Profile、個人＝User Preferences / Personalize
• 通知はNotificationで条件・宛先・本文、送信確認はEmail Logs
• 構成変更はUpdate Setで移送（Preview→Commit）、データ移行はImport Set
• 本番直接変更を避け、Pluginは有効化前に依存・戻し方を確認

インスタンス設定は、CSAでも「影響範囲と移送」を突く判断問題が多いテーマです。事故の形と早見表が頭に入ったら、実際の問題で手を動かして判断軸を固めましょう。