一覧画面で複数レコードをまとめて更新する方法（List Editor）
ServiceNowでレコードを直すとき、多くの人はまずフォームを開きます。1件ずつ開いて、値を変えて、保存する。件数が少なければ、これでも困りません。直したいレコードが数十件、数百件になると、この繰り返しがそのまま作業時間になります。時間はレコードの数だけ増えます。
一覧画面を開いたまま、フォームを1件も開かずに値を直す方法があります。ServiceNowの一覧（List View）には、セルを直接編集する機能と、右クリックメニューからの一括更新機能の2種類が用意されていました。使い方が変われば、直せる範囲も、裏で動く処理も変わってきます。
この記事では、一覧画面から複数レコードを更新する3つの方法と、それぞれの注意点をまとめます。なかでもUpdate Allは、画面に見えている行だけでなく、条件に合う全レコードが対象になる操作です。使い方を誤ると、被害が大きくなります。
想定読者は、一覧画面の基本操作はできるが、複数レコードをまとめて直す方法や、その落とし穴はまだ確認していない人です。
この記事の内容は、ServiceNowのPDI（Personal Developer Instance）Zurichリリースの初期設定（OOTB）で確認しています。実環境では権限やカスタマイズにより、結果が変わることがあります。
この記事で分かること
一覧画面から複数レコードを更新する3つの方法
List EditorとUpdate Selected、Update Allの対象範囲の違い
一括更新で動く処理と、動かない処理の違い
一括更新メニューを表示・非表示にする権限
List Editor自体を止める設定の探し方
Update Allを安全に使うための事前確認の手順
一覧画面から更新する3つの方法（全体像）
一覧画面から複数レコードを直す方法は、大きく3つに分かれます。
公式ドキュメントでは、セルの直接編集を「list editor」、右クリックからの更新を「Update Selected」「Update All」というコンテキストメニュー項目として説明しています。前者はEdit multiple records using the list editorに、後者はContext menusにまとまっています。
List Editor ― セルを直接編集する
セルをダブルクリックすると、その場で編集できる状態になります。対象は自分が選んだセル、または選んだ複数行です。フォームを開く手間がかかりません。操作はこれだけです。
Update Selected ― チェックした行だけ
行のチェックボックスにチェックを入れ、右クリックから選びます。対象はチェックを入れた行に限られます。複数の項目を1回でまとめて設定できました。範囲は明確です。
Update All ― フィルタに合う全件
チェックの有無に関係なく、いま表示しているフィルタ条件に合致する全レコードが対象になります。画面に見えている行は、その一部にすぎません。見えない分も対象です。
3つの違いを一枚にまとめました。
セルをダブルクリックして直接編集する
一覧のセルをダブルクリックすると、その場で編集できる状態になります。これがList Editorです。文字列ならテキスト欄が、選択肢ならプルダウンが、参照項目なら検索欄が出ます。値を変えてセルの外をクリックすれば、そのまま保存されました。公式ドキュメントのInline edit one or multiple cells in a listに、この編集モードの基本操作がまとまっています。
フォームを開いてから閉じるまでの手間がなく、1件だけ直したいときに向いた方法です。優先度を1段階上げる、担当グループを変える。そういった単純な変更に適しています。
複数行を選んでからダブルクリックすると、選んだ行すべてに同じ値が入ります。行の左端のチェックボックスで複数行を選び、Ctrlキーを押しながらクリックすれば、離れた行も一緒に選べました。10件の担当者をまとめて同じ人に変えたいときなど、同じ値を複数レコードへ一気に入れたい場面で使う操作です。この動きはEdit multiple records using the list editorで説明されている機能そのものです。操作の見た目は1件のときと同じセル編集ですが、選択した行の数だけ更新が走ります。
Update Selectedでチェックした行だけまとめて更新する
チェックを入れた行の上で右クリックすると、コンテキストメニューが出ます。ここから「Update Selected」を選ぶと、ポップアップ画面が開きました。
この画面では、複数の項目を1回の操作でまとめて設定できます。優先度と担当グループとカテゴリを、同時に変えるといった使い方です。セルのダブルクリックが1項目ずつの操作なのに対し、Update Selectedは複数項目を1回で処理できます。対象はチェックを入れた行だけで、それ以外のレコードには影響しません。
Update Allは画面の外まで対象にする
同じ右クリックメニューには「Update All」もあります。名前はUpdate Selectedと似ていますが、対象がまったく違いました。Update Allは、チェックの有無に関係なく、いま表示しているフィルタ条件に合致する全レコードを更新します。
一覧の1ページに出ているのは、多くても数十件です。フィルタ条件に合うレコードが数千件あれば、画面に見えているのはそのごく一部にすぎません。Update Allは、その見えていない分も含めて全部を更新します。フィルタの条件を絞り忘れたまま実行すると、想定より多いレコードが書き換わりました。
環境によっては「Update All (Preview)」という選択肢もあります。実行前に対象レコードを確認できるプレビュー機能で、内容を見てから確定できました。この選択肢がある場合は、いきなりUpdate Allを実行するより安全です。
一括更新の裏で何が起きているか
一覧からの更新には、フォーム操作と違う点が2つあります。対象1件ごとにupdate処理が走る点と、UI PolicyとClient Scriptが実行されない点です。件数が多いほど、この2点の影響は大きくなります。
動くもの：Business RuleとWorkflow
Business RuleとWorkflowは、サーバー側でレコードの更新イベントに反応する仕組みです。一覧からの更新でも、この反応は変わりません。レコードが保存された瞬間にサーバー側の処理が走るため、通知メールも普段どおり届きます。対象が100件あれば、条件に合うBusiness Ruleは100回走る計算です。1件のつもりで見ていた操作が、通知メールを100通送る操作に化けることもあります。PDIの実測では、有効なBusiness Ruleが5,641件ありました。
動かないもの：UI PolicyとClient Script
UI PolicyとClient Scriptは、ブラウザ側でフォームの表示や入力を制御する仕組みです。一覧からの更新はフォーム画面を開かず、この制御を素通りします。必須項目のチェックや、入力に応じた自動計算が働かないまま保存されるということです。PDIの実測では、有効なClient Scriptが2,585件、UI Policyが2,909件、合わせて5,494件ありました。フォームでは当たり前に効いていた制御が、Update SelectedやUpdate Allでは動きません。UI PolicyとClient Scriptの役割の違いは、Client ScriptとUI Policyの違い（フォーム挙動）で扱っています。
List Editorと一括更新メニューを制御する設定
list_updaterロールがメニューの表示を決める
Update SelectedとUpdate Allのメニューは、誰にでも見えるわけではありません。表示を制御しているのはlist_updaterロールです。このロールを持たないユーザーには、一括更新のメニュー項目自体が出ませんでした。右クリックメニューの定義はsys_ui_context_menuという1枚のテーブルにまとまっており、条件式でロールごとの出し分けをしています。この仕組みは、右クリックメニューは86件のレコードでできているで扱った内容と同じです。標準の設定では、list_updaterロールは特定のテーブルに絞られておらず、全テーブルの一覧に対して有効でした。
テーブル・列単位で編集を止める設定
List Editorそのものを止めたい場合や、特定の列だけ編集できないようにしたい場合は、一覧ごとのList Control設定を使います。公式ドキュメントのConfigure list control settings for the list editorに、設定できる項目の説明がありました。具体的なプロパティ名や既定値は、リリースや列の型によって変わるため、この記事では断定しません。自分の環境の一覧設定で、実際にどう効くか確かめてください。列がグレーアウトして編集できないときは、その項目の辞書定義でRead onlyが有効になっている可能性もあります。列の並びや表示自体は、一覧の列の並びは2テーブルで決まるで扱ったsys_ui_listとsys_ui_list_elementが管理しています。
実務での使い分け
数件から数十件を直すだけなら、List EditorかUpdate Selectedで十分です。フォームを何度も開閉する手間がなく、その場で完結します。早いです。
対象が数百件、数千件になると話は変わります。Update Allで一度に処理できたとしても、UI PolicyとClient Scriptが動かないまま値だけが書き換わるため、フォーム経由の更新と同じ結果になるとは限りません。大量データを整合性を保ったまま直すなら、Import Setやスクリプトによる更新のほうが、条件分岐や検証ロジックを挟める分だけ安全です。
もう一つ意識したいのは、一覧からの更新に「元に戻す」操作がない点です。フォームの下書き保存のような一時退避もありません。実行した時点で、対象レコードの値は書き換わります。取り消したいときは、監査ログを頼りに手動で戻すか、更新前に取得しておいたデータから再投入するしかありません。
具体例：担当グループが変わった50件をまとめて直す
たとえば、組織変更で担当グループの名前が変わり、旧グループのままのincidentが50件残っているとします。件数が50件なら、Update Allよりも一手間かかりますが、Update Selectedのほうが安全な選択です。手順は次のとおりです。まずフィルタで旧グループのincidentだけに絞り込み、件数表示で50件と一致するかを確認します。一覧の左端で全件にチェックを入れたら、右クリックから「Update Selected」を選びました。開いたポップアップでAssignment Groupを新グループに変更し、確定すれば完了です。
ここでUpdate Allを選ばない理由は、フィルタの条件を確認する手間を惜しまないためです。同じ操作でも、Update Selectedならチェックを入れた50件という範囲が画面上で見えます。Update Allだと、フィルタの条件式そのものを信じるしかありません。少ない手間の差で事故のリスクが下がるなら、その差は選ぶ価値があります。
つまずきやすい点
編集できない列がある … 計算項目や一部の参照項目は、ダブルクリックしても入力欄が出ません。項目の型と、List Editor向けの設定の両方が、編集できる列とできない列を分けています。灰色に見える列は、多くの場合そのテーブルでは編集の対象外です。
必須項目やUI Policyの制御が効かない … フォームなら赤枠で必須を示したり、条件に応じて項目を隠したりするUI Policyが、一覧編集や一括更新では働きません。値を入れずに保存できてしまい、あとから必須項目が空のレコードが見つかることがあります。
同時編集が競合する … 同じレコードを別の人が一覧編集中に、自分もUpdate Allで上書きすると、後から保存した側の値が残ります。対象件数が多い操作は、他の作業と重ならない時間帯に行うほうが安全です。
Update SelectedとUpdate Allを間違えやすい … 名前が似ているため、チェックを外し忘れた状態でUpdate Allを選ぶと、意図しない範囲まで更新されます。メニューを選ぶ前に、どちらを選んだか指差し確認する習慣が効きます。
事故を防ぐ手順（Update All実行前に）
Update Allは、条件を間違えたときの被害が一番大きい操作です。実行する前に、次の順番で確認します。
件数を確認する … フィルタを組んだ状態で、一覧の右上に出る件数表示を見ます。想定した件数と合っているかを、実行前に確かめます。
まず1件で試す … 同じ条件のまま対象を1件に絞り、Update Selectedで意図した値が入るか確認します。
監査ログで戻せるか確認する … 対象テーブルで監査（Audit）が有効かどうかを確認します。有効ならsys_auditに更新前の値が残り、間違えたときの手がかりになります。PDIのsys_auditには56,277件の記録がありました。sys_auditの仕組みは、Incidentの「誰が何を変えたか」はどこに残るかで扱っています。
この3つを済ませておけば、フィルタの条件を誤っても、被害の範囲に早く気づけます。
よくある質問
List EditorとUpdate Selectedは何が違いますか
List Editorは列単位でセルを直接編集する機能で、対象は自分が選んだセルや行です。Update Selectedは右クリックメニューから開くポップアップ画面で、チェックを入れた行に対して複数項目を1回でまとめて設定します。1項目だけ直すならList Editor、複数項目を同時に変えるならUpdate Selectedという使い分けです。
Update Allを実行すると通知メールは届きますか
届きます。Business RuleとWorkflowは一覧からの更新でも通常どおり動くため、レコードの更新をきっかけに送られる通知は、フォームでの更新と同じように動作しました。動かないのはUI PolicyとClient Scriptで、こちらはフォーム側の表示制御を担う仕組みです。
一括更新した内容を元に戻せますか
一覧からの更新自体には、取り消し操作がありません。対象テーブルで監査（Audit）が有効になっていれば、sys_auditに更新前の値が残るため、手がかりにはなります。値を自動で戻す機能ではなく、記録を見ながら手動で直す前提の仕組みです。
List Editorが使えない列があるのはなぜですか
計算項目や、一部の参照項目、List Editor向けの設定で編集を止めている列は、ダブルクリックしても入力欄が出ません。原因は項目の型と、一覧ごとのList Control設定の両方が考えられます。編集できない理由を切り分けたい場合は、辞書定義とList Control設定の両方を確認してください。
list_updaterロールがなくても一覧のセルは編集できますか
List Editorによるセルの直接編集と、Update Selected・Update Allのメニュー表示は、別の権限で制御されています。list_updaterロールが関わるのは、右クリックメニューにUpdate SelectedとUpdate Allを表示するかどうかです。セル単体を編集できるかどうかは、対象テーブルへの書き込み権限と、List Control側の設定で決まります。
検証範囲とおことわり
List Editor・Update Selected・Update AllがFlow Designerのトリガーに対してどう動くかは確認していません
ACLによって一括更新が個別に制限される挙動は、今回の検証範囲外です
Client Scriptのうち、どの種類（onLoad / onChange / onSubmit）が一括更新で動かないかまでは切り分けていません
Next Experience（UI16以降）以外のUIでの挙動は確認していません
List Control設定の具体的なプロパティ名や既定値は、リリースや環境によって異なるため断定していません
まとめ
一覧画面からの更新には、List Editor・Update Selected・Update Allの3つがある
対象範囲はList Editorが選んだセルや行、Update Selectedがチェックした行、Update Allがフィルタ条件に合う全レコード
一括更新ではBusiness RuleとWorkflowが動き、UI PolicyとClient Scriptは動かない
Update SelectedとUpdate Allのメニュー表示はlist_updaterロールで制御されている
List Editor自体の可否は、一覧ごとのList Control設定で管理されている
Update Allの実行前は、件数確認・1件での試行・監査ログの有無を順に確かめると安全
用語
List Editor … 一覧のセルをダブルクリックして、その場で値を編集する機能
Update Selected … チェックを入れた行に対して、複数項目を1回でまとめて更新するメニュー
Update All … チェックの有無に関係なく、フィルタ条件に合う全レコードを更新するメニュー
list_updaterロール … 一覧の右クリックメニューにUpdate SelectedとUpdate Allを表示するかどうかを決めるロール
List Control … 一覧ごとにList Editorの動作を設定する仕組み
自分の環境で確認するときのURL
/incident_list.do（一覧画面。List Editorと右クリックメニューを確認）
/sys_ui_list_list.do?sysparm_query=name=incident（一覧に出す列の定義）
/sys_script_list.do?sysparm_query=collection=incident（Business Ruleの一覧）
/sys_ui_policy_list.do?sysparm_query=table=incident（UI Policyの一覧）
/sys_audit_list.do?sysparm_query=tablename=incident^ORDERBYDESCsys_created_on（監査ログ）
