まず押さえる前提：通知のSend whenは複数ある
メール通知（Email Notification）の設定では、通知が「いつ送られるか」をSend whenで選びます。代表的には次のような選択肢があります。
- When a record is inserted or updated（レコードの登録・更新）
- When a particular event is fired（特定イベント）
- When Notification step in Flow Designer（Flowの通知ステップ）
この記事はこのうち、特に混乱しやすい 「レコード条件」 と 「イベント」 の違いに集中します。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
条件通知の考え方
条件通知とは何か
条件通知は、Send when を Record inserted or updated にして、
「いつ（Inserted/Updated）」「どんな条件のとき（Conditions）」を画面の条件ビルダー中心で組み立てる方式です。
例えば、インシデントで次のような要件があるとします。
- 優先度が Critical のとき
- 重要な更新が入ったときだけ
- 担当グループに通知したい
この場合、通知レコード側で Updated changes のような条件を含めて、発火を“レコードの変化”に寄せて作れます。公式ドキュメントにも、インシデントの条件例が載っています。
条件通知の強み
条件通知が得意なことは、次のとおりです。
- 単一テーブルのレコード変化に素直に追従できる
- GUI中心で作れるので、保守が読みやすい
- 「登録時だけ」「更新時だけ」が分かりやすい（Inserted/Updatedのチェックで表現できる）
条件通知の弱み
一方で、実務で詰まりやすいポイントもあります。
- 条件が複雑になると、通知レコードだけで表現しづらい
- 「ある処理の完了後に一度だけ通知したい」など、ビジネスプロセス起点の要件と相性が悪い
- レコード更新が複数回走る処理だと、意図せず通知が増えやすい（条件がゆるいと特に）
ここで登場するのがイベント駆動です。
イベント駆動通知の考え方
イベント駆動通知とは何か
イベント駆動通知は、Send when を Event is fired にして、Event name（イベント名）を指定して送る方式です。
重要なのは、イベントは「何かが起きた」という“合図”であり、レコード更新とは独立して扱える点です。
ServiceNowのイベントは Event Registry に登録されたイベントを使って、通知やスクリプトアクションなどを自動化できます。
イベントはどうやって発火させるのか
代表例はビジネスルール等から gs.eventQueue() を呼び出してイベントをキューに積む形です。
公式ドキュメントでも、イベント作成とビジネスルールからの発火（gs.eventQueue）という流れが説明されています。
イメージはこんな感じです。
- ある条件を満たしたら、ビジネスルールがイベントを発火
- イベントが記録される
- そのイベント名に紐づいた通知が処理される
また、イベントは通知だけでなく、イベントスクリプト等にもつなげられます。
イベント駆動通知の強み
イベント駆動の良さは、言い換えると「設計の部品化」です。
- 通知の発火タイミングを“イベント名”として共通化できる
- 同じイベントに対して複数の通知をぶら下げたり、逆に通知側の条件を薄くできる
- 複雑な条件判定をビジネスルール側に寄せられる
- 「レコード更新」以外のきっかけ（証明書期限、受信メールアクションなど）にもつながる
イベント駆動通知の弱み
ただし、イベント駆動は万能ではありません。
- Event Registry、発火元（ビジネスルール等）、通知の3点セットになり、構成が増える
- イベント名の設計が雑だと、後から誰も追えなくなる（命名規則が大事）
- 非同期的に処理される前提になりやすく、**「今この画面操作で即時に出したい」**の要件とは合わないことがある
このあたりは、イベントを「ログに記録される出来事」として捉えると理解が安定します。
どう使い分けるか：判断の軸を持つ
ここが一番大事です。実務でも試験でも、丸暗記より「選定理由」が問われやすいテーマです。
条件通知が向いているケース
次のようなときは、条件通知が自然です。
- 単純に「このテーブルのこの条件のとき送る」で完結する
- 発火タイミングが「登録時/更新時」で十分に表現できる
- 通知のルールがGUIの条件で読みやすく、運用も想像できる
例：
- インシデントが作成されたら担当グループへ通知
- 優先度がCriticalに変わったときだけ通知（更新条件で制御）
イベント駆動通知が向いているケース
次のようなときは、イベント駆動が効いてきます。
- 条件が複雑で、通知の条件ビルダーだけだと破綻しそう
- 「ある処理の完了」を1つの合図にして通知したい（処理起点）
- 1つの出来事に対して、通知先や通知内容の種類が複数ある
- 後から「この出来事が起きたら通知以外もしたい」可能性がある（拡張性）
例：
- 親インシデントがクローズしたら、子インシデントの担当者全員へ通知
- 変更要求の登録・更新時にイベントを発火して、イベント名を基点に複数の処理を連携する（サンプルでも change.inserted などのイベント発火例がある）
迷ったときの実務的なコツ
- 「通知がレコード更新に素直に乗る」なら条件通知から検討
- 「通知が業務イベントに乗る」ならイベント駆動を検討
- “通知の都合”でイベントを乱造しない。業務として意味のある出来事をイベント名にする
- 複雑化しそうなら、最初からイベント駆動で拡張余地を残すのも手
CSA学習にどう効くか：点を線にする勉強法
CSAを学んでいると、通知は「メールを送る設定」として覚えがちですが、理解が伸びるのはここからです。
- 通知には Send when があり、
- レコード起点（条件通知）
- イベント起点（イベント駆動通知）
- Flow起点（Flow Designer）
という入口がある
- イベント起点を選ぶと、Event Registry、イベント発火（gs.eventQueue）、通知がつながる
この「つながり」を理解していると、現場でも試験でも混乱が減ります。
暗記ではなく、「なぜイベントにするのか」「なぜ条件通知で足りるのか」を自分の言葉で説明できる状態を目指すのが近道です。
学習の進め方の一例
- まずは条件通知で、Inserted/Updated/Conditionsを触って全体像を掴む
- 次にイベント駆動で、Event Registry → gs.eventQueue → Notification の流れを一度作ってみる
- 最後に「同じ要件を2通りで作るとどう違うか」を比べる（設計の勘所が身につく）
Udemy講座を使うなら、「通知」「ビジネスルール」「イベント」「Flow Designer」をまとめて触れるカリキュラムのものを、体系的に学べる教材の一例として選ぶと効率が上がります。画面操作と用語が結びつくので、理解が“知識”から“技能”に変わりやすいです。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ：違いは発火の責任をどこに置くか
- 条件通知は、レコードの登録・更新という事実に対して、通知側の条件で送信判断をする
- イベント駆動通知は、業務上の出来事をイベントとして定義し、そのイベントが起きたことを合図に通知する
- 使い分けは「レコード変化に素直か」「業務イベントとして共通化したいか」で判断すると迷いにくい
- CSA学習では、通知単体ではなく、イベントやビジネスルール、Flowとのつながりで理解すると定着が早い
