Zurich時代のServiceNow承認フロー設計入門　迷わない考え方と落とし穴

承認は暗記より設計で理解すると強い

ServiceNowの承認は、画面上は「承認依頼を出して、承認されたら次へ進む」という単純な話に見えます。ところが、実装が増えてくると「なぜか二重に承認が作られる」「承認待ちで止まったまま」「グループ承認の挙動が想像と違う」みたいな混乱が起きがちです。

CSA学習でも、承認は“機能名の暗記”より、どういう設計だと安定するかを理解しているほうが、シナリオ問題で迷いません。この記事ではZurich環境を前提に、承認フロー設計の考え方を整理します。

---

承認はどの仕組みで動かすか

最初に決めるべきは、承認を「どのエンジン」で動かすかです。ここが曖昧だと、後から必ず歪みが出ます。

承認エンジンの基本を押さえる

Task系テーブルでは、テーブルごとに承認を管理する“承認エンジン”の選択肢があります。加えて、古い仕組みとしてApproval RulesやProcess Guidesが存在します。公式ドキュメント上でも、従来の承認ルールはWorkflow StudioのAsk for Approvalで置き換えられていること、そしてProcess Guidesは非推奨であることが明確に書かれています。

ここで重要なのは次の意思決定です。

• これから新規に作るなら、基本はWorkflow Studio中心
• 既存資産の都合で古い仕組みが残る場合は、混在による事故を避ける線引きをする

混在事故を避けるコツ

承認が絡むテーブルに対して、ワークフローエンジンと承認エンジンの両方が“承認を作る”状態だと、挙動が読みづらくなります。公式ドキュメントでも、ワークフローで承認プロセスを管理しているなら、そのテーブルの承認エンジンはオフにするのが一般的とされています。

実務でありがちな事故はこれです。

• 既存：Approval Rulesで承認が作られている
• 追加：Flow DesignerでもAsk for Approvalを入れた
• 結果：承認レコードが二重に生成、承認状態の更新も二重、どこが正か分からない

まずは「このテーブルの承認は誰が責任を持つか」を設計で固定しましょう。

---

Ask for Approvalを設計の中心に置く考え方

Zurich時代の“基本形”として、承認フロー設計はAsk for Approvalを中心に組み立てるのが分かりやすいです。

Ask for Approvalが前提としているもの

Ask for Approvalでは、承認対象レコード、関連テーブル、承認理由、承認結果を書き込むフィールドなどを入力として扱います。ポイントは、承認対象のテーブルは承認状態フィールドを持っている必要があるという点です。例としてTaskやその拡張が挙げられています。

つまり、設計の最初に確認するのはここです。

• 承認対象レコードは何か
• そのテーブルは承認状態を持つか
• どのフィールドに承認結果を反映させるか

「承認を出すこと」だけ先に考えると、後で整合が取れなくなります。

ルール設計は人間の意思決定に寄せる

Ask for Approvalには、誰が承認できるか、どんな条件で承認完了とみなすか、といった“ルール”がまとまっています。例えば「誰か1人が承認したらOK」「全員承認が必要」「一定割合で承認」などの考え方が用意されています。

ここは暗記より、業務の意思決定の形に合わせるのがコツです。

• 稟議っぽい承認：全員承認が必要になりやすい
• 緊急対応っぽい承認：誰か1人の承認で先へ進めたい
• 合議っぽい承認：一定割合が現実的

承認理由は後から効いてくる

Ask for Approvalには「Approval Reason」があり、監査や説明責任のための文章を保持でき、内容はsysapproval_approverに格納されます。
これ、最初は軽く見られがちですが、運用が回り始めると効きます。

• 「なぜこの人に承認が飛んだのか」を説明できる
• 後から監査で追われたときに、記録が残っている
• 学習者目線でも、承認の“意図”を言語化できる

おすすめはテンプレ化です。
例：「金額が閾値を超えるため部門長承認が必要」「影響範囲が広いためCAB承認」など。

休眠ユーザーや無効グループで止まる問題

公式ドキュメントには、Ask for Approvalはデフォルトで非アクティブなユーザーやグループに対しても承認レコードを生成する挙動であること、そして挙動はシステムプロパティで変更できることが書かれています。

ここは設計の落とし穴になりやすいです。人事異動・退職・組織改編の現場では、承認者が“存在している前提”が崩れます。
どこまでをシステムで吸収し、どこからを運用で吸収するかを、承認フローの設計時点で決めておくと事故が減ります。

---

グループ承認と個人承認を使い分ける設計軸

承認の設計で迷いやすいのが「グループに投げるべきか」「個人に投げるべきか」です。ここは“責任の置き方”で決めるとブレません。

グループ承認は内部的に個人承認に分解される

ワークフローのApproval – Groupアクティビティは、指定グループの各メンバーに対して個別の承認レコードを作ると説明されています。
つまり、グループ承認＝グループ宛の箱が1個できる、ではなく「メンバー分の承認が生まれる」設計です。

ここを理解していないと、次のような混乱が起きます。

• メンバーが多いグループに投げて、承認レコードが大量発生
• 異動でメンバーが変わり、誰も承認できない
• 「誰か1人でよかったのに全員分作られている」状態になる

グループ承認の完了条件を言語化する

Approval – GroupにはWait forとして、完了判定のロジックが複数あります。例えば「各グループから誰か1人」「どれかのグループから誰か1人」「全員」など、業務に合わせた選択ができます。

設計でやることは単純で、完了条件を人間の言葉に落とすことです。

• 「部門Aか部門Bのどちらかが承認すれば進める」
• 「部門Aと部門Bの両方から承認が必要」
• 「このグループは最初に反応した人の判断を採用する」

この文章が書けない状態で実装に入ると、後で仕様が揺れます。

個人承認が向いているケース

個人承認が向くのは、責任が“役割”ではなく“人”に紐づくときです。

• プロジェクトオーナー
• 申請者の上長が明確に1人
• 監査担当者など、任命された担当者

逆に、役割が変動する組織では個人固定は弱いです。ここは「その承認は誰の責任か」で決めるのが一番ラクです。

---

止まりやすいポイントと運用で詰むパターン

設計が甘いと、承認フローは“動かない”というより“止まる”形で問題が出ます。よくある詰みポイントを設計観点で整理します。

承認を作る仕組みが二重になっている

前半でも触れた通り、ワークフローと承認エンジンが混在すると、挙動も性能も読みづらくなります。公式にも、混在による衝突があり得ることが明記されています。

対策はシンプルです。

• 新規はWorkflow Studio中心に寄せる
• 既存が残るなら、テーブル単位で責任境界を決める
• どちらかに寄せられない場合でも、承認生成ポイントを一か所に寄せる

承認対象テーブルの前提が満たされていない

Ask for Approvalは、承認状態フィールドをサポートするテーブルが前提です。
カスタムテーブルや独自プロセスで承認を作る場合、ここが抜けると「承認は作れたのに状態が反映されない」みたいな現象が起きやすいです。

設計時点でチェックすること：

• 承認状態を保持するフィールド
• 承認結果を反映させるフィールド
• どの状態遷移で次の処理に進むか

承認理由と監査ログが薄い

承認は後から「誰が、なぜ、何を根拠に」承認したかを問われます。Ask for ApprovalのApproval Reasonがsysapproval_approverに格納されることは、設計上かなり重要です。
承認理由が空のまま運用すると、問い合わせ対応が地獄になります。

おすすめは、フロー側で承認理由を組み立てることです。

• 申請種別
• 影響範囲
• 金額やリスク判定
• 承認が必要になった条件

これを文章にして残すだけで、後のトラブル対応が軽くなります。

人の入れ替わりで止まる

非アクティブユーザーや無効グループをどう扱うかは、運用実態に直結します。Ask for Approvalのデフォルト挙動や、プロパティで挙動を変えられる点は公式にもあります。

設計としては、どちらかに寄せると安定します。

• 運用吸収型：承認者が無効なら、手動で差し替える運用を用意
• 仕組み吸収型：承認者を動的に決める、または“役割ベース”に寄せる

両方を中途半端にすると、止まった時に誰も直せなくなります。

---

設計テンプレ　代表的な承認パターンを組み立てる

ここからは、実務でよくある承認パターンを、Zurichの考え方で組み立てるテンプレとして紹介します。暗記というより「こう分解すると迷わない」という整理です。

パターンA　上長承認だけのシンプル稟議

設計の分解：

• 承認対象：申請レコード
• 承認者：申請者の上長
• 完了条件：承認で次へ、却下で差し戻し

実装の考え方：

• Ask for Approvalを中心にする
• 承認理由に、承認が必要な条件と申請要点を入れる
• 承認後に自動処理を続ける

ここで大事なのは、承認を“人”に寄せるときは、その人が変わる可能性も含めて設計することです。

パターンB　部門内の誰かが見ればいいグループ承認

設計の分解：

• 承認対象：部門で処理するタスク
• 承認者：部門グループ
• 完了条件：グループ内の誰か1人でOK

グループ承認は内部的にメンバー分の承認が作られるため、メンバー数が多すぎるグループは避けたいです。Approval – GroupのWait forの選択肢を、業務に合わせて選びます。

ポイント：

• 「誰か1人」が本当に要件に合っているか
• 監査上、承認者個人を特定できる形になっているか
• 異動・退職で止まるリスクをどう吸収するか

パターンC　複数部署の合議

設計の分解：

• 承認対象：影響範囲が広い変更や依頼
• 承認者：複数グループ
• 完了条件：全グループから承認が必要

このとき、承認をどこで束ねるかが設計の肝です。Approval – Groupのロジックや、必要であればスクリプト条件での判定も視野に入ります。

落とし穴：

• どれかが却下したときの扱いが曖昧
• 「却下＝終了」なのか「差し戻して再申請」なのか決めないまま実装する
• 承認理由が薄くて、後で揉める

パターンD　途中で専門家を追加できる承認

現場では「承認待ちの途中で、セキュリティの人も見てほしい」みたいなことが起きます。Ask for Approvalでは、手動で承認者を追加できる考え方が用意されています。

設計のポイント：

• 追加できるのは誰か
• 追加のトリガーは何か
• 追加された承認者の扱いをどうするか

これを“運用ルール”として文章化しておくと、仕組みも運用も安定します。

---

体系的に学べる教材の一例としてUdemyの活用

承認は、ドキュメントを読んで理解したつもりでも、実際にフローを組んで「どこで止まるか」を体験すると一気に腹落ちします。

体系的に手を動かしながら整理したいなら、UdemyのServiceNow管理者向け講座で「Flow Designerと承認、通知」まで通しで触れるのも一案です。公式ドキュメントで原理を押さえつつ、演習で理解を固める、という組み合わせがやりやすいです。

---

まとめ

Zurich環境での承認フロー設計は、機能を暗記するよりも「どの仕組みで承認を動かすか」「責任の置き方に合わせて個人承認とグループ承認を分けるか」を先に決めるのが近道です。

特に大事なのは次のポイントです。

• 承認を管理する仕組みを混在させない
• Ask for Approvalを中心に据え、承認対象テーブルの前提と承認結果の反映先を明確にする
• ワークフローで承認を管理するなら、承認エンジン側の扱いも含めて設計する
• グループ承認はメンバー分の承認が作られる前提で、完了条件を人間の言葉で定義する
• 承認理由を残し、異動や無効ユーザーなど現実の運用で止まるポイントを先に潰す

この整理ができると、CSA学習でも「承認の仕組みがどう動くか」をシナリオで追えるようになり、迷いが減ります。次に学ぶなら、承認が絡む通知やイベント設計、差し戻し時の状態遷移まで合わせて見ると、さらに理解がつながっていきます。