ServiceNow Zurichのユーザー管理運用ガイド：最小権限とグループ設計の基本

Zurichのユーザー管理を難しくする正体

ServiceNowのユーザー管理は、最初は「ユーザーを追加して、グループに入れて、ロールを付けるだけ」に見えます。ところが運用が始まると、次のような悩みが一気に出てきます。

• 異動のたびに権限調整が発生し、誰が何を持っているか追えなくなる
• 例外対応が増えて「一時的なロール」が常態化する
• 退職者の権限剥奪が遅れて監査で指摘される
• “画面で見える権限”と“データに対する権限”が一致しない

この難しさの正体は、ユーザー管理が「設定作業」ではなく「運用の設計」だからです。
Users・Groups・Rolesは、単体で完結する部品ではありません。認証（ログイン）・プロビジョニング（作成/更新/停止）・権限（ロール）・データ保護（ACL）まで、全部つながっています。公式ドキュメントでも、ユーザー・グループ・ロールを組み合わせて適切なアクセスを実現する、という前提で整理されています。

CSAを目指す人にとっても、ここは大事なポイントです。試験は用語の暗記だけでなく、「なぜその設計が望ましいのか」「どういう事故が起きやすいのか」を理解していると、選択肢の判断がブレにくくなります。

このあと、実務でも学習でも使えるように、ユーザー管理を**“設計図”として**組み立て直します。

---

Users・Groups・Rolesを設計として理解する

Usersは人、Groupsは仕事の箱、Rolesは鍵

まずイメージを揃えます。

• User：個人アカウント。だれがログインするか
• Group：仕事の単位。チームや担当のまとまり
• Role：できることの権限。アプリや機能、データへのアクセスを開く鍵

ここで運用をラクにする鉄則がひとつあります。

ロールはユーザーに直付けしない

例外はゼロにはできませんが、基本はこう考えます。

• ロールはグループに付ける
• ユーザーはグループに所属させる
• 結果としてユーザーは、所属グループ経由でロールを持つ

こうすると、監査・棚卸し・異動対応が一気に楽になります。
「Aさんが何をできるか」は、Aさん個人の設定ではなく “どの仕事の箱に入っているか” で説明できるからです。

具体例：社内ヘルプデスク

• グループ：Service Desk
• グループに付くロール：ITSMの担当者系ロール、必要な閲覧/更新ロール
• ユーザー：Aさん、Bさん
• Aさんが異動したら「グループを抜く」だけで権限が整理される

グループ設計は「部署」より「職務」で切る

ありがちな失敗は、組織図どおりにグループを切ってしまうことです。
部署名はよく変わりますし、部署と職務は一致しません。

おすすめは、次の2層で考えるやり方です。

• 職務グループ：やる仕事で決まる（例：一次受け、変更管理、資産管理）
• 所属グループ：組織の都合で必要（例：部門別の通知・承認・レポート）

権限（Roles）は基本的に職務グループへ。所属グループは、通知や承認、分類など“運用上の都合”に寄せる。これだけで、権限の肥大化が起きにくくなります。

ロール設計は「最小権限」と「積み上げ」

ロールは「とりあえず admin 付ける」が一番危険です。
代わりに、次の2点で組み立てます。

• 最小権限：必要な操作だけができる状態をゴールにする
• 積み上げ：小さなロールの組み合わせで職務を表現する

この考え方は、実務だけでなく、CSA学習でも効きます。
「この人に必要なのはどの権限か」を、ロールの粒度で説明できるようになるからです。

---

入社・異動・退職を回す運用フロー

ユーザー管理は、日常運用で必ず発生するイベントに耐える必要があります。ポイントは、ユーザーのライフサイクルを3つの流れに分けて設計することです。

• Joiner：入社・追加
• Mover：異動・兼務・職務変更
• Leaver：退職・停止

まず「誰が正なのか」を決める

ユーザー情報の正本はどこか。これが曖昧だと、同期ズレが永遠に直りません。

• 人事システムが正
• ID基盤（Entra IDなど）が正
• LDAPが正
• ServiceNowが正（小規模ではあり得る）

大規模だと、ServiceNowは“正本”というより、業務の実行基盤として、正本から供給されるのが自然です。

SSOとプロビジョニングを切り分ける

ここも混乱しやすいところです。

• SSO：ログインを誰が認証するか
• プロビジョニング：ユーザーを作る・更新する・止める

ServiceNowでは、SAML環境でユーザーが存在しない場合に自動作成する「SAML user provisioning」も整理されています。
また、LDAP統合はディレクトリを主要なユーザーデータ源として扱い、ユーザー作成やロール付与の自動化に使う、という位置づけです。

ここで大事なのは、「ログインできる」＝「必要な権限が揃っている」ではないこと。
プロビジョニングで作成された直後のユーザーは、最低限のグループ所属しか持たない設計が安全です。

異動対応は「グループ差し替え」で完結させる

Mover対応が重い組織ほど、設計で差が出ます。

• 旧職務グループを外す
• 新職務グループを入れる
• 所属グループは必要なら残す
• 例外ロールがある場合は期限付きで扱う

ここが「ロール直付け」運用だと、異動のたびに“手作業でロール探し”が始まります。
逆に「職務グループ中心」だと、作業が箱の入れ替えで終わります。

退職は「無効化」だけで終わらせない

Leaver対応はスピードが命ですが、運用としては2段階が安全です。

• 即時：ログイン不能（無効化）
• 後日：所有物の引き継ぎ、割当の解消、例外ロールの棚卸し

“止めたからOK”にすると、承認待ち・割当待ち・個人依存の作業が残り、業務が詰まります。ユーザー管理は、業務運用にも直結しています。

---

委任とガバナンスで破綻を防ぐ

ユーザー管理は管理者だけで回すと必ず詰まります。
そこで必要になるのが「委任」と「ガバナンス」です。

管理者を増やさずに運用を回す発想

やりたいことはこうです。

• 現場のマネージャーがメンバーをグループに入れ替えできる
• ただし、何でもできてはいけない
• 監査で追える必要がある

ServiceNowには、グループ内でロールを割り当てられるようにする「Delegating roles」の考え方が整理されています。ロールを委任するユーザーは、自分が持っているロールの範囲でしか割り当てできない、という制約がポイントです。
この“制約つき委任”があると、現場運用のスピードと統制を両立しやすくなります。

例外ロールは「期限」「理由」「戻し先」をセットにする

実務で避けにくいのが例外対応です。たとえば障害対応で一時的に強い権限が必要、など。

このときの作法はシンプルで、

• 期限：いつまでか
• 理由：なぜ必要か
• 戻し先：期限後にどのグループへ戻すか

この3点がない例外は、ほぼ確実に“残骸ロール”になります。
残骸が積み上がると、どんなに綺麗なグループ設計でも崩れます。

監査しやすさは「説明できること」

ガバナンスというと堅く聞こえますが、要するに

このユーザーがこの権限を持つ理由を、グループと職務で説明できるか

これがYESなら、棚卸しも、引き継ぎも、教育も楽になります。
逆にNOなら、運用は属人化していきます。

---

権限はACLとセットで考える

ロール設計だけで「安全」にはなりません。
なぜなら、データアクセスは最終的にACLで評価されるからです。

ロールは入口、ACLは最後の関門

ざっくり言うと、

• ロール：アプリや機能へアクセスするための条件
• ACL：テーブル/レコード/フィールドに対する操作を許すかの最終判定

この関係を理解していないと、次のようなズレが起きます。

• 画面は見えるのに、レコードが読めない
• 一覧は見えるのに、詳細が開けない
• 更新できるはずなのに、保存で弾かれる

公式側でも、アクセス制御を戦略的に設計する重要性が強調されています（ACLの種類、評価の考え方、階層など）。

ユーザー管理運用で押さえるACLの勘所

ユーザー管理と絡めて、最低限ここだけ押さえると混乱が減ります。

• ロールを付けたら終わりではない：データの読み書きはACL次第
• グループ設計はACL設計を楽にする：職務＝必要データが揃うとACL条件も揃う
• 例外権限はACLにも波及する：強いロールを一時付与すると、想定外のデータへ触れられる可能性が出る

実務でよくある“事故の芽”

• 「参照できるべきユーザー」ではなく「ロールを持つユーザー」で判断してしまう
• 個別対応を積み重ね、ACLがスパゲッティ化する
• 監査で「なぜこの人がこのデータにアクセスできるのか」を説明できない

ユーザー管理運用は、権限モデルを綺麗に保つための土台です。
ACLの考え方とセットで捉えると、設計が急に“地に足のついたもの”になります。

---

まとめ：Zurichのユーザー管理は「設計」で勝てる

ServiceNow Zurichのユーザー管理運用は、単なる登録作業ではなく、業務と権限を結びつける設計そのものです。ポイントを最後に整理します。

• Users・Groups・Rolesは部品ではなく、認証・プロビジョニング・権限・ACLまでつながる運用の土台
• 基本は「ロールはグループに、ユーザーはグループへ」で、異動と棚卸しに強い形を作る
• グループは部署ではなく職務で切り、権限は最小権限の積み上げで表現する
• Joiner/Mover/Leaverの流れを前提に、正本と同期方式を決め、SSOとプロビジョニングを混同しない
• 委任は“制約つき”で設計し、例外対応は期限・理由・戻し先までセットで運用する
• ロール設計はACLとセット。入口と最終判定のズレを理解すると、トラブル対応が速くなる

CSA学習の観点でも、ここを「仕組み」と「判断の軸」で理解しておくと、暗記に頼らずに選択肢を比較しやすくなります。もし独学で全体像がつながりにくいと感じたら、体系的に学べる教材の一例として、UdemyのServiceNow管理者入門やCSA対策講座を1本持っておくのも手です。動画で“ユーザー管理→権限→ACL”を一連で確認すると、点が線になりやすいです。