ServiceNow 承認（Approval）完全ガイド：申請はどこで誰に回り、なぜ止まるのか
申請を出したあと、承認が誰の画面で止まっているのか分からず、進捗を聞かれても答えられないことがあります。ServiceNowの承認はChangeでもカタログでもsysapproval_approverという1つのテーブルに集まる仕組みで、たどる場所は基本的に同じです。Zurich PDIで771件の承認レコードを実機で数え、どこで生成され、どこで止まりやすいかを確認しました。
検証環境：Zurich PDI / OOTB / 2026-08-08 確認
結論：承認は1本の線を、状態と分岐が横切る
承認は申請の種類を問わずsysapproval_approverという1つのテーブルに集約されます。今回は771件のうち750件（97%）がChange Requestに紐づいていました
承認レコードを作るのは、Flow Designerの「Ask For Approval」というアクション側です。申請した本人の操作で決まるわけではありません。51件のアクション配置がこの役割を担っていました
承認が止まって見える場所は主に2つあります。半数近くがrequestedのまま滞留する場所と、rejectedで明確に止まる場所（2件）です。代理承認は承認レコードを増やさず、一覧を読み取るときだけ承認者を差し替える仕組みでした
申請元のレコードから承認レコードが生まれ、必要に応じてグループでまとめられ、状態が確定してから履行に進みます。代理承認は別の線です。承認レコードそのものには触れずに、一覧表示だけを差し替える立ち位置になります。ここから先は、この図の各段を実画面で1つずつ裏付けていきます。
承認は誰が作るのか：Ask For Approvalが生成する
承認レコードは、申請者がボタンを押して作るものだと考えがちです。実際に配置を数えると、その考えは半分しか合っていませんでした。
Action typeにAsk For Approvalを含むアクションの配置は51件ありました。名前を見ると「Requested Item Dept Head Approval」「Service Fulfillment Steps - Manager Approval」のようなものが並びます。いずれもカタログ系の複数のフローに分散して配置されていました。承認を生むかどうかはフロー側にあらかじめ組み込まれた条件が決めていて、申請者本人が意識して呼び出す操作ではありません。レガシーのwf_workflow（旧Workflow定義）は今回0件で、この環境の承認生成はFlow Designerに一本化されていました。
公式のAsk for Approval action（Zurich）に、このアクションが承認レコードをどう生成し誰に割り当てるかがまとまっています。
この構造を知っておくと、「承認が付かない」という問い合わせへの向き合い方が変わります。原因を申請フォームの入力ミスに求める前に、対象のフローにAsk For Approvalが本当に配置されているかを確認したほうが早いことが多いからです。フローの条件分岐で対象外になっているだけ、というケースも珍しくありません。
承認は1人1レコード：sysapproval_approver（771件）
生成された承認は、承認者1人につき1件のレコードとして記録されます。
sysapproval_approverは承認者・承認対象・状態を持つテーブルで、承認する人の数だけ行が増えます。1件の申請に承認者が7人いれば、7行できる計算です。
フォームを開くと、項目数はそれほど多くありません。誰が承認するかを表すApprover、何を承認しているかを表すApproving、状態を表すState、そしてApproval ReasonとCommentsという理由・コメント欄です。承認という機能の複雑さのわりに、1件のレコードが持つ情報自体はシンプルです。複雑になる原因は、このシンプルなレコードがsysapproval_groupや委任と組み合わさる場面のほうにあります。
状態は6種類、実際に動いていたのは4種類
状態の選択肢はnot requested・requested・approved・rejected・cancelled・not_requiredの6種類定義されています。実データに現れていたのは4種類だけでした。requestedが390件で全体の51%、not_requiredが302件で39%、approvedが77件で10%、rejectedはわずか2件です。半数近くがrequestedのまま止まっている点は、あとの節で詳しく触れます。
承認先の97%はChange Requestだった
承認対象の親レコードをsource_tableで分けると、change_requestが750件で全体の97%を占めていました。残りはstd_change_proposal4件、sc_req_item3件、task2件、kb_knowledge1件です。カタログ申請やナレッジ承認もこの仕組みに乗っています。ただし件数としては、Changeの承認が圧倒的多数派でした。この環境で承認を語るとき、実質的にはChangeの承認を語っているのに近い比率です。
公式のClassic approvals（Zurich）に承認の基本的な考え方がまとまっています。個別承認とグループ承認をどちらで管理するかの選び方は、Select an approval table（Zurich）にあります。
複数人の承認をどうまとめるか：sysapproval_group（131件）
承認者が2人以上いる場合、個々のsysapproval_approverをどう束ねて1つの判断にするかを決めるテーブルがあります。
sysapproval_groupは131件で、approved65件・requested64件・not_required2件という内訳でした。1つのグループに複数の承認者がぶら下がる構造で、グループ全体の可否をどう決めるかはwait_forとreject_handlingという2つのフィールドで制御します。
wait_forとreject_handlingは131件すべて同じ設定だった
wait_forには「誰か1人の承認で確定」「全員の承認が必要」などの選択肢がありますが、実データを集計すると131件すべてがprocess_flowでした。reject_handlingも同様に、131件すべてが「1人でも却下したらグループを却下扱いにする」rejectでした。選択肢としては他の値も定義されていますが、実運用ではこの1パターンに偏っているのがこの環境の実態です。
公式のApproval rules（Zurich）に、承認ルールの設定項目がまとまっています。
代理承認は承認レコードを増やさない
自分が休みのあいだ、誰かに承認を代わってもらいたいという要望はよくあります。ServiceNowにはこの仕組みが標準で用意されていますが、動き方は少し独特です。
sys_user_delegateは、委任元・委任先・期間・対象範囲（承認/割り当て/通知など）を持つテーブルです。今回の環境では0件でした。委任の実体は、一覧を読み取るときに「このユーザーの委任先も含めて表示する」という差し替えです。新しく承認レコードを作る仕組みではありません。委任を設定しても、sysapproval_approverの件数自体は増えないということです。
標準の代理承認は0件、条件付きは1件だけ動いていた
部署や金額といった条件を付けて委任を絞り込む「Granular Delegation」という追加機能もあります。ルールを保存するsys_delegation_ruleと、適用結果を保持するsys_granular_delegateは、いずれも1件ずつでした。標準の委任がゼロ、条件付きの委任も検証用の1件のみという状態です。委任は使われて初めて意味を持つ機能なので、この数字自体は環境の使用実績を表しているだけで、機能に問題があるわけではありません。
公式のDelegate approvals and tasks to another user（Zurich）に利用者側の設定手順がまとまっています。条件付き委任の概要はGranular delegation（Zurich）にあります。
個別承認・グループ承認・代理承認、混同しやすい3つの違い
似た名前が並ぶので、実務では取り違えが起きやすいところです。3つを短く区別しておきます。
個別承認（sysapproval_approver）… 承認者1人につき1件のレコードです。承認の最小単位に当たります
グループ承認（sysapproval_group）… 複数の個別承認を束ね、全体としての可否を決める集約役です。レコードは増えますが、承認者の数が増えるわけではありません
代理承認（sys_user_delegate・Granular Delegation）… 承認者そのものを増減させず、一覧に表示する承認者を読み取り時に差し替える機能です
3つとも「承認」という言葉が付きますが、担っている役割はまったく別です。個別承認とグループ承認はレコードとして存在する実体で、代理承認は表示だけを変える仕組みだと考えると整理しやすくなります。
通知はどこから飛んでくるのか
承認者に「承認待ちです」と知らせるメールも、sysapproval_approverに紐づく設定として存在します。
有効な通知定義は14件ありました。この数字は検証のたびに多少前後します。Approval Request・Approval Rejected・Catalog Approval Request・Request approval assignedのような通知が並びます。Change向けとカタログ向けが別々に用意されている作りです。一方でグループ承認のsysapproval_groupそのものに紐づく有効な通知は0件でした。グループの結果は、配下の個別承認や親タスク側の通知に委ねられている作りです。
公式のEmail and SMS notifications（Zurich）に、通知定義の基本がまとまっています。
ここまでの数字を役割ごとに整理すると、上の表のようになります。承認そのもの・まとめる仕組み・差し替える仕組み・生成する仕組み・知らせる仕組みという5つの役割に、それぞれ担当するテーブルが対応しています。
実務では何に使えるか：承認が止まったときに開く順番
承認がらみの問い合わせを受けたとき、自分は次の順番で画面を開きます。
対象レコードのsource_tableとsysapprovalを確認し、sysapproval_approverをその値で絞り込みます
stateがrequestedのまま残っている行をapproverの列で確認し、誰の承認待ちかを特定します
承認者がグループに所属している場合はsysapproval_group側のwait_forとreject_handlingを見て、1人の承認で全体が動くのか全員必要なのかを判断します
承認者が長期不在の可能性があるときは、sys_user_delegateにその人の委任設定があるかを確認します
この4段階を踏むと、承認が止まっている理由の大半は画面を数回開くだけで切り分けられます。手順を丸暗記するより、sysapproval_approverが起点であることさえ押さえておけば、あとは対象を絞り込んでいくだけです。
実機で気づいたこと
数字を数えているうちに、思い込みと違う点がいくつも見つかりました。3つ挙げます。
承認を作っているのは申請側ではなくルール側だった
最初は、申請者がフォームを提出した瞬間に承認が始まると考えていました。実際にAsk For Approvalのアクション配置を数えると、承認を生むかどうかはフロー側の条件設定が決めていて、申請者はその条件に当てはまっただけです。障害調査で「なぜこの申請だけ承認が付かないのか」を聞かれたときは、申請フォームより先に対象のフロー定義を見るほうが早く答えにたどり着けます。
グループの集約ルールが1種類しかなかった
wait_forには複数の選択肢が用意されているので、環境ごとにいろいろな組み合わせが混在していると想定していました。実際には131件すべてが同じprocess_flow・rejectの組み合わせで、ばらつきはありませんでした。選択肢が用意されていても実際に使われる値は狭い、というのは他の承認まわりのフィールドでも見られた傾向です。設計を検討するときは、選択肢の多さよりも自社でどの値を採用するかを先に決めたほうが、あとで見返しやすくなります。
委任がゼロでも承認の仕組み自体は動いていた
sys_user_delegateが0件だったのを見て、最初は委任機能が使われていないのか壊れているのか判断がつきませんでした。実際にはテーブルが空でも承認自体は問題なく回っており、委任はあくまで追加の利便機能という位置づけです。導入直後の環境で委任テーブルが空でも、それ自体は異常ではありません。
どこで詰まったらどれを読むか
ここまでで承認の全体像は掴めましたが、実際に手を動かすときは目的に応じて掘り下げる先が変わります。
承認レコード1件の中身をもっと詳しく知りたいときは、承認は1人1レコード（sysapproval_approver）で個々のフィールドと参照関係を扱っています。承認者が複数人いて「誰の承認で通ったのか」が追いにくいと感じたときは、グループ承認：N人を1つに束ねる仕組み（sysapproval_group）で今回触れた集約ルールをさらに掘り下げています。
代理承認そのものの仕組みを理解したいときは、代理承認は承認レコードを増やさない（sys_user_delegate）【前編】が読み取り時に承認者を差し替える動きを詳しく説明しています。部署や金額といった条件で委任を絞り込みたいときは、条件付き代理承認を実機で通す：Granular Delegation（後編）が実際にルールを組んで動かした記録です。
半数近くがrequestedのまま止まって見える状況を設計として見直したいときは、承認を滞留させないための運用設計書で状態設計と委任ポリシーの具体案をまとめています。Change承認をAssessからAuthorizeまで実際に1件動かした手順がほしいときは、承認（Approval）運用手順書がそのまま再現できる形になっています。承認のルーティングや却下時の扱い、通知やKPIまで含めて運用ルールを自社向けに設計したいときは、承認（Approval）運用設計書がRACIやパラメータ表まで踏み込んだ内容です。
つまずきやすい点
細かい部分ですが、知らないと時間を取られる点を挙げておきます。
stateの値にはnot requested（スペース区切り）とnot_required（アンダースコア）という似た文字列があります。見た目がほぼ同じなので、クエリを書くときに取り違えやすい箇所です
sysapproval_groupの件数だけを見ても、配下に何人の承認者がいるかは分かりません。個別のsysapproval_approver側をgroupで絞り込む必要があります
委任を設定してもsysapproval_approverの件数は増えません。承認待ちの総量を把握したいときは、委任先を数えず元の承認者数で数えます
Ask For Approvalのアクション配置数（51件）は、実際に生成される承認レコードの件数とは別の数字です。1つのアクション定義から複数件の承認が生まれることもあります
source_tableが空欄の承認レコードも11件ありました。承認対象が削除された、または多態参照が正しく解決できていない可能性があり、調査時は除外せず件数に含めておくのが安全です
よくある質問
Q1. 承認が止まっているとき、まずどこを見ればいいですか
対象レコードからsysapproval_approverをdocument_idまたはsysapprovalで絞り込み、stateがrequestedのまま残っている行のapproverを確認します。グループ承認の場合はsysapproval_group側のapprovalも合わせて見ると、誰の判断待ちかが分かります。
Q2. sysapproval_approverとsysapproval_groupはどちらを見ればいいですか
承認者個人の状況を知りたいときはsysapproval_approver、グループ全体としての可否を知りたいときはsysapproval_groupです。1つのグループに複数のsysapproval_approverがぶら下がる1対N構造なので、両方を突き合わせて初めて全体像が分かります。
Q3. 代理承認を設定すれば承認は自動で進みますか
進みません。代理承認は一覧表示のときに承認者を差し替えるだけの仕組みで、承認そのものを自動的に完了させる機能ではありません。委任先のユーザーが実際に承認または却下の操作をする必要があります。
Q4. カタログ申請の承認もこの記事の対象ですか
対象です。source_tableの内訳を見るとsc_req_item（カタログの申請アイテム）は3件と少数ですが、仕組みとしてはsysapproval_approverに集約されます。件数が少ないのは今回の環境の実データの偏りで、機能として対象外というわけではありません。
Q5. Flow Designerを使っていない環境でも同じ構造ですか
sysapproval_approverとsysapproval_groupというテーブル構造自体は共通です。ただし承認レコードを生成する仕組みは環境によって異なり、レガシーのWorkflowで組まれている場合もあります。今回のPDIではレガシーWorkflow定義が0件だったため、Flow Designer側の仕組みだけを確認しました。
Q6. 承認をすべて自動化してしまうことはできますか
仕組みの上ではできます。stateを直接更新すれば承認済みとして扱われます。ただし監査や責任の所在という観点では推奨されません。誰が何を承認したかという記録自体が、承認機能の存在意義の一部だからです。自動化を検討するなら、条件を絞ったうえで一部のケースだけに適用するほうが現実的です。
まとめ
ServiceNowの承認は、申請の種類を問わずsysapproval_approverという1本の線に集約されます。今回の実測では771件のうち97%がChange Requestに紐づき、承認レコードを作っているのはFlow Designer側の設定でした。
止まって見える場所は状態のrequested（390件・51%）とrejected（2件）の2箇所で、代理承認は承認レコードそのものには触れず読み取り時に承認者を差し替えるだけです。グループ承認の集約ルールは131件すべてが同じ組み合わせでした。選択肢の幅は広くても、実際に使われている値は狭いという傾向は、承認まわりのあちこちで繰り返し見られました。地図はシンプルです。複雑に見えるのは、この単純な線がChange・カタログ・ナレッジという複数の入口から同時に流れ込んでくるからです。
全体の地図が掴めたら、あとは自分が今どこで困っているかに応じて子記事を選んで読み進めてください。
用語
sysapproval_approver … 承認者1人につき1件の承認レコード。状態・承認対象・コメントを持つ
sysapproval_group … 複数の承認者をまとめる集約レコード。wait_forとreject_handlingで確定条件を決める
sys_user_delegate … 標準の代理承認設定。読み取り時に承認者を差し替える
Granular Delegation … 条件を付けて委任を絞り込む追加機能。sys_delegation_ruleとsys_granular_delegateを使う
Ask For Approval … Flow Designerで承認レコードを生成するアクション
実機で調べるときに開いたURL
/sysapproval_approver_list.do?sysparm_query=GROUPBYstate … 状態ごとの件数
/sysapproval_approver_list.do?sysparm_query=GROUPBYsource_table … 承認対象の種類別件数
/sysapproval_group_list.do?sysparm_query=GROUPBYapproval … グループ承認の可否別件数
/sys_user_delegate_list.do … 代理承認の設定一覧
/sys_hub_action_instance_list.do?sysparm_query=action_type.nameLIKEApproval … 承認を生成するフローアクションの一覧
/sysevent_email_action_list.do?sysparm_query=collection=sysapproval_approver^active=true … 有効な通知定義
参考リンク
検証環境と未検証範囲
件数・画面はZurich PDI（OOTB）で確認したものです。一覧画面の件数表示と実レコードを突き合わせて数えており、推定やサンプリングではありません。子記事とは検証日が異なるため件数がわずかに前後しますが、本記事は今回の実測値を採用しています。
Business RuleやNotificationの内部スクリプトの中身までは読んでいません。実際に承認や却下の操作をしてどう遷移するかは、その手順を扱う子記事の範囲です。Granular Delegationの適用条件やタイミングの詳細も、条件付き代理承認を扱う子記事に譲ります。本番環境やカスタマイズ済みの環境では、テーブル構造は共通でも件数や生成元の内訳が変わってきます。
