承認（Approval）運用手順書

確認した環境：ServiceNow の PDI（Personal Developer Instance）、Zurich リリースの OOTB（初期設定）。2026-07-08 確認。

1. 目的・背景

この記事は、ServiceNow で Change Request を1件新規に起票した運用手順書です。Assess の承認 → Authorize の承認 → Scheduled 到達まで、実際に進めて確認しました。承認は手で作り込むものではなく、Change の state を更新するたびに承認グループと承認者が自動生成され、誰か1人が承認するとグループごと確定して次のステージへ進みます。この「自動生成と自動遷移の連鎖」を、実際に1件の Change を最後まで動かして確認しました。

承認まわりで迷いやすいのは、Assess の承認が済んだあとに何が起きるかです。今回いちばん確かめたかったのは、Assess の承認グループと Authorize の承認グループが、同じレコードの使い回しではなく、それぞれ別々に自動生成されるという点でした。Assess 側で7名の承認者が生成され、そのうち1名が承認すると残り6名は自動的に「不要（No Longer Required）」に切り替わり、Change は Authorize へ進みます。ここで新しく6名の承認者を持つ、Assess とは別の承認グループが生成されました。

今回実走した変更のフォームが次の画面です。進捗バーは New・Assess・Authorize にチェックが付き、Scheduled まで到達した状態が残っています。

想定読者

この記事は、ServiceNow で Change や Service Catalog の承認運用を担当する人を想定しています。承認待ちが止まって見えるときに何を確認すればよいか、手順として持っておきたい人も対象です。個別の承認レコードやグループ承認テーブルの構造そのものを先に理解したい場合は、以前の記事もあわせて読むと前提がつながります。

2. 前提整理・全体フロー

個別承認とグループ承認の関係

ServiceNow の承認は、2つのテーブルで表現されています。1人の承認者につき1レコードを持つ sysapproval_approver（個別承認） があります。複数の個別承認を束ねて1つの結果にまとめる sysapproval_group（グループ承認） もあります。個別承認1件1件がどんな構造を持つか、複数の承認者を束ねるグループ承認の仕組みは、それぞれ以前の記事で扱いました。この記事はその2つの構造を踏まえて、1件の Change を実際に起票し、Assess から Scheduled まで動かした運用の手順を確認します。

Change のライフサイクルには New・Assess・Authorize・Scheduled・Implement・Review・Closed・Canceled の8つの state があります。今回の承認運用が動くのは、このうち Assess と Authorize の2つの段階です。

個別承認とグループ承認の役割を、今回実走した件数とあわせて整理すると次のとおりです。

Changeの承認ライフサイクル全体図

New で起票した Change を Assess に進めると、承認グループと承認者が自動生成されます。そこから承認が確定するたびに、Change は次の state へ自動で前進します。今回実走した流れを1枚の図に整理すると次のとおりです。

この記事（無料部）で分かること

• 承認は手動で作るものではなく、Change の state 更新をきっかけに自動生成されること

• Assess 用の承認グループが、承認者7名を束ねて自動生成される実際の手順

• Change の承認ライフサイクル（New→Assess→Authorize→Scheduled）の全体像

3. 操作手順

ここからは操作を番号付きで並べます。各ステップは、実施者／画面への行き方／入力項目と値／押すボタン（または API）／成功条件／注意点の順です。今回はフォームと同じフィールドを REST API（Table API）で直接更新して確認しました。画面から同じ項目を入力する手順に読み替えて書いていますが、フォーム上のボタン固有の動作は検証範囲外です。

1) Change起票とAssess承認グループの自動生成確認

• 実施者：変更を起票する申請者、または代行入力する Change 管理者

• 画面への行き方：アプリケーションナビゲーターで「Change > Create New」から新規作成。作成後は Change フォームの上部タブ、および関連リスト「Approvers」から承認状況を確認する

• 入力項目と値：

• Short description（変更内容の要約）

• Type=Normal

• Assignment group（今回は Hardware）

• 押すボタン（または API）：フォームで入力して「Submit」（今回は Table API での作成と、state を Assess(-4) に更新する操作で確認）

• 成功条件：作成直後は state=New・approval=not requested で、承認レコードは1件も生成されない。state を Assess に更新すると、承認グループ1件と承認者7件が同時に自動生成され、approval が requested に変わること

• 注意点：New の間は承認レコードが1件も作られない。承認が動き出すのは Assess に進んだタイミングで、グループ作成や承認者の割り当てを手動で行う操作は不要

state を New から Assess に更新すると、承認グループ1件（配下に承認者7名）が同時に生成されました。生成された承認者は全員 requested（承認待ち）の状態で並びます。この時点でグループ側の approval も requested に変わり、承認待ちの一覧に載ってきます。

承認者を Change の document_id で絞り込むと、生成された承認者を一覧で確認できます。次の画面は、今回の Change に紐づく承認者を一覧化したものです（このあと有料部で進める Authorize 側の承認者も含めた最終的な内訳です）。

無料部はここまでです。有料部では、次を実測つきの手順として確認します。

• この Assess 用グループの承認を実際に1名進めたところから、Authorize 用グループの自動生成

• Change の Scheduled 到達

• 別の実例で確認した却下（reject）の連鎖

• Assess承認を1名進めると、残り6名が自動でNo Longer Requiredになり、Changeが自動でAuthorizeへ前進する実測

• Authorize用の承認グループが、Assessとは独立した別レコードとして自動生成される実測

• Changeが最終的にScheduledへ自動遷移する条件

• Service Catalogの申請（RITM）を却下すると、親リクエスト（REQ）までClosed Incompleteに連鎖する実例

• よくあるミスとリカバリ表