なぜ今「通知」と「イベント」を分けて考えるのか
通知って、つい「メールを飛ばす仕組み」くらいに見えがちです。ところが、運用していると必ず壁に当たります。
「誰に飛んだ？飛んでない？」「飛びすぎて読まれない」「ダイジェストにしたら何が含まれるのか分からない」「受信メールの処理が属人化する」など、通知が原因で現場がザワつく瞬間が出てきます。
Zurichでは、通知周りが“機能追加”というより「通知を運用できる形に整える」方向で強化されています。具体的には、メール配信の健全性を見える化するダッシュボード、通知の好み設定画面の見せ方制御、複数レコードをまとめるダイジェストの強化、そして受信メールを賢く扱う仕組みが入っています。
ここで大事なのが、通知とイベントを別物として捉えることです。
- イベント：システム内で「何が起きたか」を表す合図（記録・連携・後続処理の起点）
- 通知：その合図をもとに「誰に、どのチャネルで、どんな情報量で伝えるか」を決める表現
この分離ができると、実務ではトラブルが減り、学習では理解が安定します。CSAの勉強でも、通知やワークフロー、メール、イベントが混ざって覚えにくい人ほど、ここを整理するとスッと通ります。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
通知はメッセージ手段ではなく設計対象になった
Zurichのリリースノートは、通知アプリが「重要なイベント、アクション、アラート」に対してワークフロー内で通知を作成・管理・送信するものだと説明しています。さらにZurichで強化された点として、メール診断、好み設定の制御、ダイジェスト強化、受信メールの賢い処理などが並びます。
ここから読み取れるメッセージはシンプルです。
通知は「送ったら終わり」ではなく「運用して回すもの」
現場でよくある失敗は、通知を“作って満足”してしまうことです。数週間後にこうなります。
- メールが迷惑フォルダに入っていたが、誰も気づいていない
- SMTP送信ジョブが詰まって遅延していた
- 受信メールで起票できるはずが、担当者の手動対応に戻っていた
Zurichでは、メール診断ダッシュボードで「バウンス管理」「配信メトリクス」「送信/受信ジョブの健全性」などを追えることが明示されています。
つまり、通知運用を“見える化して保守できる”ことが重要になった、ということです。
通知設計の最小セット
初学者の方が通知を設計するときは、まずこれだけ押さえると破綇しにくいです。
- 何をトリガにするか（イベントか、条件か、フローか）
- 受信者は誰か（担当者、依頼者、関係者、グループ）
- 内容は何を最小にするか（リンク、要点、次の行動）
- どの頻度・粒度にするか（即時、集約、ダイジェスト）
- 運用で詰まった時にどこを見るか（診断・ログ・キュー）
Zurichで増えたのは、このうち **「集約」「好み設定」「運用監視」**の厚みです。
イベント駆動の基本：イベント登録と発火が理解の軸
通知・ワークフロー・連携を整理するとき、軸になるのがイベントです。
イベントは、いきなりスクリプトから発火する前に「登録」という手順があります。公式ドキュメントでも、イベントを作成する手順として System Policy → Events → Registry で新規作成する流れが示されています。
イベントを登録する理由
イベントは「名前」さえ決めれば自由に作れる、というものではなく、管理対象として登録されることで運用が成立します。
- どのテーブルに紐づくイベントか
- どのキューに積まれるか
- どんな用途のイベントか（説明文・命名規則）
この“管理される”という性質が、通知を設計可能にします。
イベントを発火する代表例
代表的な発火方法として、Business Rule内で gs.eventQueue を使ってイベントキューに入れる例が公式ドキュメントで説明されています。
ここでのポイントは、**イベントは「後続処理の起点」**であって、メール送信そのものではないということです。
さらに公式ドキュメントには、gs.EventQueue はバックエンドで動作し、gs.EventQueue() によって呼ばれるBusiness Ruleは呼び出されない、という趣旨の注意もあります。
つまり、イベントは「何でも呼べる魔法の呼び出し」ではなく、イベントキューを使った非同期・疎結合の仕組みだと理解しておくのが安全です。
実務での使い分けイメージ
- 条件通知：レコード更新時の軽い連絡（例：担当者変更のお知らせ）
- イベント駆動通知：処理の境界を明確にしたい（例：承認完了、SLA違反、状態遷移完了）
- フロー起点：承認や作業割り当てなど、複数ステップの自動化とセットで通知したい
イベントを軸にすると、通知が増えても設計が破綻しません。「どこで起きた出来事なのか」が追えるからです。
Zurichで強化された3つの実務ポイント
ここからはZurichで「通知・イベント周りの考え方」に効いてくる強化点を、実務の困りごとベースで整理します。
メール診断ダッシュボードで運用が回るようになった
Zurichの通知ハイライトに、メール診断ダッシュボードが明示されています。バウンス管理や配信メトリクス、送信/受信ジョブの健全性を監視できる、という位置づけです。
よくある事故は「通知設定は合ってるのに届かない」です。
そのとき原因はだいたい以下に寄ります。
- バウンス（宛先無効、拒否）
- 送信ジョブの滞留
- 受信ジョブやメールボックス接続の問題
- キューの詰まり
診断ダッシュボードは、こういう“運用の盲点”をつぶすためのものだと捉えると、価値が分かりやすいです。
通知設計は「作る」だけでなく「健康診断の導線までセット」になってきた、というのがZurichの空気感です。
通知の好み設定は「出せばよい」ではなく「見せ方を設計する」
Zurichでは「ユーザーの詳細な通知設定画面に表示する通知のリストを、管理者が制御できる」ことが変更点として挙げられています。
さらに、通知フィルタ設定により、ユーザー条件にもとづいて表示する通知を絞れる手順が示されています。具体的にはシステムプロパティを有効化し、Notification Filter Configurationでユーザー条件とフィルタ条件を作る流れです。
ここが地味に効きます。
なぜなら、通知が増える現場では「設定画面がノイズだらけ」になり、結果としてユーザーが通知を全部オフにするからです。
- 全社共通の重要通知だけは見せる
- 部門や役割で関係ない通知は見せない
- 学習者向けの検証環境でも、通知が増えたときの整理ができる
通知は“ユーザーに渡したら終わり”ではなく、ユーザーがコントロールできる形に整えるところまでが設計だ、と考えると理解が進みます。
ダイジェストが「1レコード前提」から進化した
Zurichの変更点として「メールダイジェストが単一または複数ターゲットレコードを、一定間隔でサポートする」と明記されています。
これで何が嬉しいかというと、通知の洪水を“設計で止めやすい”ことです。
例として、インシデントのコメント更新を都度メールするのではなく、
- 1時間ごとに、担当者別に、未読更新の一覧をまとめる
- 重要度が高いものだけ即時、その他はダイジェスト
という設計が取りやすくなります。
イベントが多発する環境ほど、即時通知と集約通知を混ぜるのが現実的です。
受信メールは人手ではなく、意図の解釈から始める
Zurichでは「受信メールを、意図の識別→アクション実行→返信文面の下書きまで含めて賢く扱う」Email agentic workflow が追加されたと説明されています。
また、このワークフローはServiceNow Storeからリクエストしてインストールする案内もあります。
ここでの学びは「通知＝送信」だけでなく、受信も含めてイベント処理だということです。
- メールで依頼が来る
- それがチケット起票か、状態変更か、質問かを判定
- 必要なら処理し、返信を整える
この一連は、イベント駆動の発想と相性が良いです。
「何が起きたか」をイベントとして記録し、通知や返信は“表現”として分離する。Zurichはその方向を後押ししています。
CSA学習に効く整理術：暗記よりも迷子にならない理解
CSA対策で通知やイベントを学ぶと、用語が似ていて混乱しがちです。ここでは、試験向けにも実務向けにも効く整理の仕方を置いておきます。断定的に「出る」とは言いませんが、理解していないと混乱しやすい前提になりやすい領域です。
まずは三層に分ける
- 出来事層：イベント、状態遷移、条件成立
- 処理層：Business Rule、Flow、Action、Queue、Job
- 伝達層：通知、ダイジェスト、好み設定、受信メール対応
Zurichで強化されたのは主に伝達層と運用の見える化です。
だからこそ学習でも「通知の作り方」より先に、「どう運用するか」「ユーザーにどう見せるか」をセットで理解しておくと、実務に出たときに強いです。
初学者がつまずきやすいポイントと回避策
- 通知が飛ばない
→ まず設定を疑う前に、配信の健康状態を見に行く癖をつける（診断ダッシュボードの発想） - 通知が多すぎる
→ 即時と集約を分ける。ダイジェストで“設計として止める” - ユーザーが通知設定を触れない、触っても意味がない
→ 好み設定画面の表示自体を管理者が制御できる発想を持つ - メール起票が属人化
→ 受信メールの処理を「人の判断」から「意図→アクション→返信下書き」へ寄せる発想を知る
学習の近道：手を動かすならこの順
検証環境でやるなら、次の順が理解しやすいです。
- イベントをRegistryに登録する
- Business Ruleでイベントをキューに入れる例を読む
- そのイベントを起点に通知を作る
- ダイジェスト化できる設計を考える
- 好み設定の見せ方を制御する
- 送受信の健全性をモニタできる導線を確認する
こうやって「出来事→処理→伝達」の順で積むと、暗記よりも理解が残ります。
教材の一例としてのUdemy活用
通知やイベントは、単語を覚えるより「どこで何が動いているか」をつかむ方が効果が出やすいです。体系立てて学ぶなら、UdemyでCSA向けのコースや演習つき講座を選び、
「イベント」「Business Rule」「Flow」「通知」「メール」あたりを横断して説明している教材を一つ持っておくと、学習の迷子を減らせます。
あくまで教材の一例ですが、独学のつまずきポイントを埋める用途としては相性が良いです。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
Zurichで強化された通知・イベント周りは、「派手な新機能」というより、通知を運用できる設計に寄せるアップデートだと捉えるのがコツです。
- メール診断ダッシュボードにより、配信の健康状態を追えるようになった
- 通知の好み設定は、ユーザー任せではなく“見せ方”を管理者が制御できる
- ダイジェストは複数ターゲットレコードに対応し、通知洪水を設計で抑えやすくなった
- 受信メールは意図の識別からアクション実行、返信下書きまで含めて賢く扱う方向に進んだ
そして根っこにある考え方は一つです。
イベントは出来事、通知は伝達。混ぜない。
この分離ができると、実務ではトラブル対応が早くなり、学習では用語が絡まっても解きほぐせるようになります。Zurich対応のタイミングで、通知を「メール設定」ではなく「設計と運用の仕組み」として捉え直すと、今後のバージョンでもブレにくいはずです。
