はじめに
「部門統合で命名規則が変わり、User IDを一括リネームしたい」——こういうケースは運用現場であります。
しかし「User IDを変えたら過去のインシデントの履歴やジャーナル、監査ログ、通知は壊れないのか?」を明確に答えられる資料は意外と見当たりません。
自作のServiceNow MCPサーバー(tedorigawa001/ServiceNow-MCP)を使って、実際にPDI上で「ユーザー作成→インシデント作成・アサイン→更新→User ID変更→影響確認」を一通りやってみました。
結論から言うと、表示は壊れないが、変更履歴の痕跡そのものが標準機能では一切残らないという、地味だが運用上重要な事実が分かりました。
PDIでの検証手順
- 新規ユーザー作成(
user_name=useridtest.769449) - インシデント作成 → 新規ユーザーにアサイン
- コメント追加・作業メモ追加・優先度更新
- ユーザーの User ID(
user_name) をrenamed.useridtest.769449に変更 - 履歴・ジャーナル・Created By/Updated By・通知(Outbox)・通知デバイステーブルへの影響を比較
結論: フィールドの型で運命が分かれる
ServiceNowのテーブルには、ユーザーを指す2つの異なる仕組みが混在しています。
| フィールド種別 | 実体 | User ID変更の影響 |
|---|---|---|
Reference型(sys_userへの参照、sys_id保持) |
assigned_to, opened_by, cmn_notif_device.user など |
影響なし。sys_idは不変なので、参照は常に「今のそのユーザー」を指し続ける |
| String型(実行時のuser_nameを文字列としてスナップショット) |
sys_created_by, sys_updated_by, sys_journal_field.sys_created_by, sys_audit.user など |
影響なし(だが更新もされない)。変更前に記録された値は文字列としてそのまま |
sys_dictionary で内部型を確認すると一目瞭然です。
sys_journal_field.sys_created_by → internal_type: String
sys_audit.user → internal_type: String
task.assigned_to → internal_type: Reference (sys_user)
task.opened_by → internal_type: Reference (sys_user)
cmn_notif_device.user → internal_type: Reference (sys_user)
実機での確認結果
1. Created By / Updated By — 変わらない(が更新もされない)
インシデントの sys_created_by/sys_updated_by は User ID変更前後で完全に同じ値のままでした。String型なので当然ですが、逆に言うと**「昔このインシデントを作った useridtest.769449 って誰?」と聞かれても、User ID変更後は sys_user を検索してもヒットしません**。
文字列は残るが、現在のユーザーとの紐付けは失われます。
2. ジャーナル(コメント・作業メモ) — 表示は壊れない
sys_journal_field の本文・sys_created_by も同様にString型のスナップショットで、User ID変更後も文字化けや欠落なく表示され続けました。
ただし①と同じ理由で「誰が書いたか」の名寄せはできなくなります。
3. assigned_to(担当者表示) — そもそも影響を受ける対象ではなかった
assigned_to はReference型なので参照自体は無傷ですが、画面に表示される名前は user_name ではなく name(氏名)フィールドから来ています。
つまり「User IDだけ変更」というシナリオでは、担当者欄の見た目は最初から一切変化しません。
4. 通知デバイステーブル(cmn_notif_device) — 影響なし
SMS/メール通知の宛先を管理する cmn_notif_device.user もReference型でした。
User ID変更後に新しくデバイスレコードを作成しても、user 参照は正しく現在のユーザー(sys_id基準)に解決され、表示名も正常に出ます。
ちなみにユーザー作成時に「Primary email」という通知デバイスが自動生成されている点も実機で確認できました(OOB仕様)。
5. Outbox(送信メール) — User IDとは無関係
インシデントのアサイン・作業メモ追加で「Incident INC0010014 has been assigned to you」等のメールが実際に sys_email (Outbox) に2件生成されました。
ただし宛先は email フィールドを見ており、user_name とは連動していません。User IDだけを変更する分には通知ルーティングに影響しません(email も一緒に変える場合は別途検証が必要です)。
6. ⚠️ User ID変更そのものが監査されない
一番地味で、一番実務に効いてくる発見です。
sys_dictionary: sys_user.user_name の audit フラグ → false
sys_audit (documentkey=対象ユーザー) → 0件
sys_history_line (対象ユーザー) → 0件
**「いつ・誰が・このユーザーのUser IDを変更したか」を追う手段が、標準機能には一切ありません。
** sys_user テーブルの多くのフィールドはデフォルトでAudit対象外になっており、user_name もその一つです。
棚卸しやセキュリティレビューで「User ID変更の証跡」を求められるなら、sys_dictionary で個別にAuditフラグを立てるか、Business Ruleで独自ログを仕込む必要があります。
7. 旧User IDでの検索 — 完全にヒットしなくなる
当然ですがハードリプレイスなので、変更前の user_name で sys_user を検索しても即座に0件になります。SSO/LDAP連携や外部システムが user_name をキーにしている場合、User ID変更と同時に接続が切れる点は要注意です。
(今回は未検証ですが、Reference型ではなく文字列キーで外部と連携している仕組み全般に共通するリスクです)。
8. カスタムでUserIDを検索している場合には要注意
ビジネスルールやスケジュールジョブなどを実装している場合、その処理の中でUserIDに対する操作している場合には、当然ながらチェックが必要になります。
まとめ
| 観点 | 結果 |
|---|---|
| 過去の履歴・ジャーナルの表示 | 壊れない(文字列スナップショットのまま） |
| Created By/Updated Byと現ユーザーの紐付け | 失われる(検索不能になる） |
| 担当者欄などの表示名 | 影響なし(そもそもname依存、user_nameとは無関係） |
| 通知デバイス・Outbox | 影響なし(Reference型 or emailフィールド依存） |
| User ID変更自体の監査証跡 | 標準では一切残らない(要個別対応） |
User ID変更は「システムを壊さない」という意味では安全ですが、「過去の行動記録と現在のユーザーの結びつきを切る」「変更履歴自体が追跡不能になる」という、見えにくいコンプライアンス上のリスクを伴います。
棚卸し目的でUser IDを一括変更する場合は、変更前に旧User ID⇔新User IDの対応表を別途保存しておくことを強く推奨します。
また、ビジネスルールやスケジュールジョブをカスタム開発している場合、その処理の中でUserIDに対して操作している場合はチェック必須です。