グループ承認：N人を1つに束ねる仕組み（sysapproval_group）

ServiceNow で Change Request を上げると、CAB のメンバーなど複数人に承認依頼が一斉に飛ぶことがあります。このとき決めることは3つあります。「誰か1人が承認すれば通るのか」「全員の承認が必要なのか」「1人でも却下したら即否決か」です。この3つに従って複数の承認をまとめ、1つの結論にするのが sysapproval_group（画面ラベルは Group approval） です。

個別承認 sysapproval_approver は1承認者＝1レコードで記録します。これは以前の記事「ServiceNow の承認エンジンを実機で読み解く（sysapproval_approver）」で扱いました。この記事はその1つ上、複数の sysapproval_approver を束ねる 親テーブル sysapproval_group が主役です。PDI（Zurich / OOTB）で実際に開いて確認したのは3点です。1グループ：N承認者の構造、グループとしての集約結果（approval）、集計ルール（wait_for / reject_handling）を、実測値とともに示します。

この記事で分かること

• グループ承認が sysapproval_group の1行＝1つの承認ステップで、複数の個別承認を束ねること。

• sysapproval_group が task を継承し、parent / state / approval を task から受け継ぐこと。

• グループの集約結果 approval（PDI 実機 127 件の内訳：承認待ち64 / 承認済み61 / 不要2）。

• 集計ルール wait_for（any/all…）と reject_handling（reject/wait）の意味。

• 1グループに平均約5.8人の承認者がぶら下がり、1人承認で残りが「不要」になる実例。

• 個々の承認（sysapproval_approver）とグループ承認（sysapproval_group）の役割分担。

グループ承認（sysapproval_group）とは

グループ承認とは、1つの承認ステップに複数の承認者がいるとき、その全員の回答をまとめて「グループとして承認された／否決された」を1件で表す仕組みです。承認待ち一覧で、1つの Change に複数人がぶら下がっているとき、その「束ね役」がこの sysapproval_group です。

下の画面は、PDI（Zurich / OOTB）の sysapproval_group を approval（集約結果）でグループ化したものです。承認待ち・承認済み・不要といった結果ごとに、グループ承認のレコードがまとまって並びます。

今回の PDI では、sysapproval_group に 127 件 のグループ承認がありました。approval の内訳は、承認待ち（requested）64 件・承認済み（approved）61 件・不要（not_required）2 件です。1件1件が「複数の承認者を束ねた1ステップ」を表しています。

sysapproval_group はどんなテーブルか

名前は承認専用に見えますが、継承元を確認すると意外と素直でした。今回の PDI（Zurich / OOTB）では、sysapproval_group の super_class（継承元）は task でした。Incident や Change と同じ task 系のテーブルです。だから parent（対象レコード）・state（状態）・approval（承認結果）といった task 標準フィールドをそのまま持ちます。

これは、個別承認 sysapproval_approver が super_class 空のルート基底テーブルだったのと対照的です。個々の承認はルート基底で、それを束ねるグループは task の一種です。この性格の違う2枚が組み合わさって承認が表現されています。

固有フィールド（task 継承分を除く独自項目）は 5 つだけです。実質は approval_user / reject_handling / wait_for / admin_override の4項目になります。集計に使う parent・state・approval は task から継承しています。フィールド定義は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sysapproval_group^elementISNOTEMPTY

主なフィールドを役割で整理すると次のようになります。

中心になるのは、承認対象を指す parent、グループとしての結果を表す approval、そして集計ルールの wait_for / reject_handling です。

1グループに複数の承認者がぶら下がる

グループ承認の構造は 1 group : N approver です。1件のグループの下に、複数の個別承認がぶら下がります。実際のレコードで確認しました。

承認待ちのグループ（parent が CHG0000058）の下には、6名の承認者が並んでいました。名前は Bernard Laboy / Howard Johnson / Luke Wilson の3名です。残りは Christen Mitchell / Ron Kettering / cab approver の3名でした。状態は6名ともすべて requested（承認待ち）です。

このグループに属する個別承認だけを sysapproval_approver で絞り込むと、同じグループに束ねられた承認者が一覧で読み取れます。

PDI 全体では、グループに属する個別承認が 736 件（全 751 承認中）ありました。127 グループで割ると、1グループあたり平均約5.8人の承認者が束ねられている計算です。承認者1人1人の中身（誰が Approved/Rejected したか）は別記事で扱っています。承認エンジンの記事（sysapproval_approver）を参照してください。

グループとしての集約結果（approval）

個々の承認者の回答は、グループとして1つの結論にまとまります。その結果を表すのが approval フィールドです。task の approval を継承しており、PDI では7つの選択肢を持っていました。not requested / requested / approved / rejected / cancelled / No Longer Required / duplicate です。

注目したいのが、1人が承認した時点でグループ全体がどう動くかです。承認済み（approval=Approved）のグループ（parent が CHG0000090）の下を実際に見てみました。Beth Anglin=approved に対し、Fred Luddy と ITIL User は not_required（No Longer Required）に変わっていました。

つまり、誰か1人が承認した瞬間にグループは Approved に確定するという動きです。残りの承認者は「もう承認しなくてよい（No Longer Required）」に切り替わります。これが実データから観察できました。個々の回答がバラバラのまま残るのではなく、グループ側で1つの結果に集約されます。

なお、グループの state（task の状態）と approval は連動しています。PDI 実測での対応は次のとおりです。state=Open が承認待ち64件、state=Closed Complete が承認済み61件、state=Closed Skipped が不要2件と、きれいに対応していました。

集計ルール（wait_for / reject_handling）

グループの結論を「個別承認の単純多数決」ではなく、明示的なルールで決めるのが wait_for と reject_handling です。

• wait_for（Wait for） … 何をもって承認とみなすか。any（Anyone to approve＝誰か1人で承認）／ all（Everyone to approve＝全員必要）／ workflow ／ process_flow の4つです。

• reject_handling（Handle a rejection by） … 却下されたときの扱い。reject（Rejecting group approval＝1人の却下で全体を否決）／ wait（他の回答を待ってから判断）の2つです。

集約結果と集計ルールの対応は次のとおりです。

ここで実機ならではの発見がありました。今回の PDI（Zurich / OOTB）では、127 グループすべてが wait_for=Process Flow でした。reject_handling も全件 Rejecting group approval です。any / all / workflow や wait は選択肢としては存在しますが、現データには1件も出てきません。これらのグループ承認を生成しているのは、Change Request の承認ポリシーです。Flow Designer も生成元になります。どちらも集約の判断をプロセスフロー側に委ねているため、と読めます。「実際にどの値が使われているか」は、選択肢の一覧ではなく実データで確認するのが確実です。

個々の承認とグループ承認の役割分担

個々の承認（sysapproval_approver）とグループ承認は混同されがちですが、役割ははっきり分かれています。

• sysapproval_approver（Approval / SN-APPR-001） … 「誰が Approved / Rejected したか」を記録します。1承認者＝1レコードで、ルート基底テーブルです。

• sysapproval_group（Group approval / 本記事） … その個別承認を束ねます。グループとして通ったか否決かを1つにまとめ、結果を parent（対象 task）へ返します。task を継承します。

ざっくり言えば、sysapproval_approver は「個人の回答」、sysapproval_group は「チームとしての結論」 です。承認が止まったときは、まず「どの approver が未回答か」を sysapproval_approver で見ます。次に「グループとしてどう集計される設定か」を sysapproval_group の wait_for / reject_handling で確認します。この2段で切り分けられます。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# グループ承認を集約結果でグループ化
https://<YourInstance>/sysapproval_group_list.do?sysparm_query=GROUPBYapproval

# 承認待ちのグループだけ絞る
https://<YourInstance>/sysapproval_group_list.do?sysparm_query=approval=requested

# あるグループに属する個別承認（group= は対象グループの sys_id）
https://<YourInstance>/sysapproval_approver_list.do?sysparm_query=group=<group_sys_id>

# sysapproval_group の固有フィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sysapproval_group^elementISNOTEMPTY

まとめ

• グループ承認は sysapproval_group（Group approval）の1行＝1つの承認ステップで、複数の個別承認を束ねる。PDI では 127 件。

• sysapproval_group は task を継承し、parent / state / approval を受け継ぐ。固有フィールドは5つ（wait_for / reject_handling など）。

• approval（集約結果）は PDI 実測で承認待ち64 / 承認済み61 / 不要2。state（Open/Closed Complete/Closed Skipped）と連動する。

• 1グループに平均約5.8人の承認者がぶら下がる。1人が承認するとグループは Approved になり、残りは No Longer Required に変わる。

• 結論は wait_for（any/all…）と reject_handling（reject/wait）で決まる。PDI の現データは全件 Process Flow / Rejecting group approval。

• sysapproval_approver は「誰が答えたか」、sysapproval_group は「グループの結論」。役割が違う。

グループ承認が分かると、承認まわりの記事が1本の流れでつながって見えてきます。個々の承認 sysapproval_approverは、承認者1人ずつの回答を扱った記事です。Change Request・Flow Designer と並べて読むと、「対象レコード → グループ承認で束ねる → 個々の承認者へ → 結果を集約して返す」という流れが見えてきます。

関連記事

• ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか — グループ承認は承認全体の経路の一部です。申請がどこで誰に回るかの全体像は完全ガイドで確認できます。

検証範囲とおことわり

• 確認した範囲：sysapproval_group の継承（task）と固有フィールド。approval/state/wait_for/reject_handling の選択肢と実測分布。レコード件数（127）、1グループあたりの承認者数、承認済みグループでの集約挙動（1人承認→残り not_required）。すべて PDI（Zurich / 2026-06-29 確認）の OOTB で取得しています。

• 確認していない範囲（断定しません）：wait_for を all / any / workflow に切り替えたときの集約挙動（現データは全件 process_flow）。reject_handling=wait の挙動。グループ承認を生成するフロー（Ask For Approval / Change Approval Policy）の内部ロジック。admin_override / approval_user の実運用。rejected / cancelled / duplicate の実レコード（現データに出現せず）。