承認（Approval）運用設計書

この記事は、PDI（Zurich、2026-07-08 確認）の OOTB（初期設定）構成をもとに、ServiceNowの承認（Approval）運用の設計判断を「なぜそう決めるか」まで整理した運用設計書です。承認経路の使い分けや却下時の業務影響への対応などの具体値は一例で、自社導入時のたたき台に使うことを想定しています。

1. 運用設計の目的と範囲

申請を止めるべき場面では確実に止め、通すべき場面では速やかに通せることを目的として、本設計書ではServiceNowの承認（Approval）運用の設計判断を一つずつ決める。誰の承認を、どの段階で、単独承認とグループ承認のどちらで求めるかを定める。複数人が絡む承認は、どう1つの結論に集約するかを設計する。却下されたときに関連レコードへどう影響させるかも決める。承認が止まっていることの検知方法も、あわせて設計に含める。あとから運用を変えるときに判断の背景までさかのぼれるよう、決定とその理由をあわせて記録する。

承認の実体であるsysapproval_approverの生成元やStateの読み方は「ServiceNow の承認エンジンを実機で読み解く：sysapproval_approver の生成元・State・グループ承認の見方」で確認済みだ。複数の承認者を束ねるsysapproval_groupの構造そのものは「ServiceNow のグループ承認 sysapproval_group を実機で読み解く」で確認済みである。本設計書は構造の説明ではなく、その構造の上で運用をどう決めるかに重心を置く。

承認運用の設計が達成すべきことを、次のように置く。

• 承認待ちが放置されないことを目的として、承認経路（個別承認/グループ承認）の使い分けを設計する。

• 複数人の回答を1つの結論に集約する挙動を明示することを目的として、グループ承認の集約ルール（wait_for/reject_handling）を設計する。

• 段階ごとに責任者を切り替える承認を正しく表現することを目的として、多段承認（Assess/Authorize等）の分離単位を設計する。

• 却下が関連レコードに与える影響を運用で吸収できることを目的として、却下時の業務影響（カスケード）を設計に含める。

• 承認の滞留を早期に検知できることを目的として、通知とKPIの設計項目を決める。

操作の「やり方」は、対になる運用手順書「ServiceNowのPDIをもとにしたOOTB承認（Approval）運用手順書」で扱っている。この手順書は、Changeの新規作成からAssess承認・Authorize承認、Service Catalogでの却下までを実機で回している。手順書は「どの画面で何を選び、どのボタンを押すか」を示す。本設計書は「どの経路を選び、何を基準に集約し、誰が責任を持つか」を決める。やり方を先に知りたい人は手順書が入口になる。

対象範囲は、sysapproval_approver（個別承認）とsysapproval_group（グループ承認）を中心とした承認運用とする。承認経路の使い分け・グループ承認の集約ルール・Change/Service Catalogにおける多段承認の分離・却下時の業務影響・通知とKPIの設計までを対象に含める。承認を生成するFlow/承認ポリシーの内部ロジックは対象外とする。各Notificationの本文・宛先条件の詳細、wait_for=any/all/workflowを実際に切り替えた場合の集約挙動も対象外とする。これらは今回の実機検証範囲外として末尾に明記する。

設計の起点はOOTBとする。ServiceNowの承認は、何も作らない初期状態でも最初から仕組みが組まれている。個別承認とグループ承認という性格の異なる2種類のテーブル、wait_for/reject_handlingという集約ルールの選択肢、承認元テーブルごとの通知定義がそれにあたる。OOTBの構成のうち、どこをそのまま使い、どこを自社の運用ルールへ落とし込むかを決めることを本設計書の方針とする。想定読者は、承認の遅延・形骸化に課題を感じている運用設計者と、Change/Service Catalogの承認フローに責任を持つプロセスオーナーです。承認待ちの現場対応を担うサービスデスク担当者も対象に含みます。

設計領域の全体像

承認運用設計で決めることを4つの領域に分け、この順で設計を進める。

• 承認経路の設計（3章）… 個別承認とグループ承認をどちらに寄せるか。

• グループ承認の設計（4章）… 複数人の回答をどう1つの結論に集約するか。多段承認をどう分離するか。

• 却下時の業務影響設計（5章）… 却下が関連レコードにどう波及するか。

• 通知・KPI設計（6章）… 滞留や却下をどう検知するか。

矢印の終点を通知・KPI設計から承認経路の設計へ戻しているのは、KPIで見つかった滞留や却下の偏りが、たいてい承認経路の選び方やグループの集約ルールの設定不足に行き着くためだ。この循環により、4つの領域が一巡して閉じる構造を設計の枠組みとする。

2. 現状把握（OOTBの承認構成）

設計の土台を確かめることを目的として、OOTBの承認構成をここで整理する。少なくとも今回確認したPDI（Zurich/OOTB）では、承認は2つのテーブルで構成されていた。性格の異なる個別承認（sysapproval_approver）とグループ承認（sysapproval_group）である。

2-1. 個別承認（sysapproval_approver）のState分布

個別承認sysapproval_approverのState分布を見ると、requested（承認待ち）が390件で最多だった。次いでnot_required（No Longer Required）が301件だった。

not_requiredが2番目に多い点は、グループ承認の集約設計（4章）に直結する。グループ内の誰かが承認・却下した時点で、残りの承認者が自動的に不要化される集約動作の積み上がりであり、却下（rejected）は2件のみと少数派だった。承認が止まって見える状態の大半はrequestedであり、not_requiredは集約の結果として増えていく値だと捉えて設計を進める。

2-2. 承認の生成元（source_table）分布

承認レコードをsource_table別に見ると、change_requestが749件で全体の97%以上を占めた。

標準変更提案（std_change_proposal）・Service Catalogの申請（sc_req_item・task）・ナレッジ記事の公開承認（kb_knowledge）は少数存在する。承認の仕組み自体はChangeに限らず複数のプロセスで共用されている。この分布の偏りは、承認経路の設計（3章）で個別承認とグループ承認をどちらに寄せるかを判断する材料になる。

2-3. グループ承認（sysapproval_group）の構造

グループ承認sysapproval_groupは131件あり、approvalの内訳はapproved65件・requested64件・not_required2件だった。super_classはtaskを継承し、固有フィールドは5つ（approval_user／reject_handling／wait_for／admin_override／sys_id）にとどまる。

集約条件を決めるwait_for・却下の扱いを決めるreject_handling・強制確定を許すadmin_override・承認者を直接指定するapproval_userで構成される。

このPDIの現行データは131件全件がwait_for=process_flow・reject_handling=rejectで統一されていた。実際に開いたグループ承認の実例では、Assess用グループ（Assignment group=Hardware）が使われていた。Authorize用グループ（Assignment group=CAB Approval）は同一のchange_requestに対する別レコードだった。承認者集合もほぼ別だった。

1つのグループが承認者を差し替えながら段階を進むのではなく、段階ごとに独立したsysapproval_groupが生成される。この構造は、多段承認の分離設計（3章）の根拠になる。なお、wait_for=process_flowのグループは、配下の承認者のうち1名が承認した時点でグループ全体がApprovedに確定する。残りの承認者はNo Longer Requiredに変わる。この動きをAssess用・Authorize用それぞれで観測した。これは背後のFlow/承認ポリシーが集約条件を決める設定である。今回観測できたのは、そのFlowが結果として単独承認で確定する挙動だったという点にとどめる（Flow定義自体の中身は検証範囲外）。

2-4. Changeの2段階承認：Assess→Authorize

change_requestのstateは、New→Assess→Authorize→Scheduled→Implement→Review→Closed/Canceledの順に選択肢が並ぶ。Assess状態に入った時点で承認グループが1件自動生成される。承認が成立するとAuthorize状態に自動遷移すると同時に、Authorize用の承認グループが別レコードとして新たに生成される構成だった。Authorize側の承認が成立すると、Scheduledへ自動遷移する。

chg_modelの固有フィールドにworkflowやstate_modelのような承認フロー定義への直接参照はなく、承認や状態遷移のロジックはchg_model単体では完結しない。今回確認できたAssess→Authorizeの2段階承認は、Create New画面に表示されるNormalモデル（type=normal）で確認できた構成である。Emergency/Standardでの承認段階数は検証範囲外とする。

2-5. Service Catalogの2段階承認

Service Catalogの承認は、REQ側とRITM側で別レコード・別段階になっていた。

REQ側の承認が済んでも、RITM側の部門長承認が別途必要という構成だった。2つの段階は承認対象（source_table）が異なるレコードとして扱われており、Changeの2段階（同一change_request配下で別グループ）とは別の分離軸になっている。

2-6. 通知設計の現状

sysapproval_approver向けのactiveな通知は11件あり、承認元テーブルごとに専用の通知が用意されている。

Change系はapproval.\*イベント、Catalogはrequest.approval.\*イベント、KM・契約・On-Callは個別イベントで分かれていた。一方、sysapproval_group自体にはactiveな通知は0件だった。グループの集約結果そのものへの通知は別経路（親task側の通知）に委ねられている構成であり、この非対称は通知・KPI設計（6章）で扱う。

この構成を土台に、ここから先は承認経路の使い分け・グループ承認の集約ルール・却下時の業務影響・通知とKPIの設計を、自社で決めるパラメータ一覧・RACI・代替案の採否まで含めて一つずつ確定していく。