ServiceNowで通知が重複送信される原因は何か まず見る場所と最短の切り分け手順

通知が二重三重に飛ぶと、利用者には「同じメールが何通も来るシステム」に見えます。
しかも実務では、単純に通知レコードが2件あるだけではなく、イベント、レコード更新、Flow Designer、受信者設計、グループ展開、委任設定などが重なって起きることが少なくありません。

ServiceNowの通知は、同じトリガーから複数通知が生まれたときに重複判定される仕組みがありますが、常に自動できれいに抑止されるわけではありません。通知の重複は「通知設定の問題」ではなく、「通知がどこで作られ、誰に、どの条件で送られるか」という設計全体の問題として見るのが近道です。

この記事では、ServiceNowで通知が重複送信されるときに、まず確認すべき場所、原因の全体構造、実務での切り分け順、そして再発防止の設計原則までまとめて整理します。
CSA学習者にとっても、通知の仕組みを断片ではなく流れで理解しやすい内容にしています。

まず確認すべきチェックリスト

通知重複の調査は、最初に広く見すぎると時間を失います。先に以下を確認すると、かなりの確率で原因の層が絞れます。

同じタイミングで sys_email が何件作られているかを見る

まず確認したいのは、利用者の受信箱ではなく sys_email です。
同じレコード更新の直後に、同一レコード向けの送信メールが複数作られているなら、ServiceNow内部で重複が発生しています。逆に sys_email が1件しかないのに利用者が2通受け取っているなら、転送、メーリングリスト、メール基盤側、委任や別アドレス展開も疑うべきです。ServiceNow公式のトラブルシュートでも、個別メールの成否確認は Sent System Mailbox や Failed System Mailbox、さらに個別メールの message log を見る流れが案内されています。

見る場所の例です。

• sys_email
• Sent System Mailbox
• Failed System Mailbox
• 対象メールの message log
• Error string

ここで見るべき状態例は次の通りです。

• 同じ subject が短時間に複数件ある
• 同じ target record に対して複数件ある
• mailbox や type が send-ready、sent、send-ignored、skipped などで分かれている
• message log に「なぜその受信者が含まれたか」が出ている

よくある誤解は、「重複送信だから通知レコードが必ず2つあるはず」と考えることです。実際には、1つの通知でも受信者展開で重複して見えたり、別トリガーから同内容メールが生まれたりします。

通知レコードの Send when と Weight を見る

通知レコードでは、Send when が Record inserted or updated なのか、Event is fired なのか、Flow Designer の Notification step なのかを最初に確認してください。ここが違うだけで、調査の入口が変わります。ServiceNow公式では、同じトリガーから複数通知が生成される場合、重複通知の扱いは Ignore Duplicates business rule と Weight によって制御されると説明されています。さらに、同じ target table と recipients を持つ通知は、Weight が異なれば重複と見なされ、同一 Weight の場合は subject と body でも判定されます。デフォルトの Weight 0 は、条件を満たせば常に送信されます。

確認するフィールドは主に以下です。

• Active
• Table
• Send when
• Weight
• Event name
• Conditions
• Advanced condition

状態例としては、

• 重複している2通知がどちらも Weight 0
• 片方が Record updated、もう片方が Event fired
• 条件が広すぎて同じ更新で両方通る

といったパターンが多いです。

よくある誤解は、「Weight を設定すれば全部の重複が止まる」というものです。Weight は万能ではなく、同じ target table と recipients という前提を外れると、期待通りに抑止されないことがあります。

受信者の展開元を確認する

通知は本文より先に受信者設計を見た方が早いです。
Who will receive では、Users、Users/groups in fields、Groups、Event parm 1 contains recipient、Event parm 2 contains recipient、Send to event creator、Exclude delegates などが重複の起点になります。公式でも、グループは Include members が有効なら個別通知され、委任を除外したい場合は Exclude delegates、イベント作成者を含める場合は Send to event creator、イベントパラメータを受信者として使う場合は専用チェックボックスを使う構成が示されています。

特に次は要注意です。

• 同じ人が Assigned to と Assignment group の両方から入る
• Groups と Users/groups in fields の両方で同一受信者を拾う
• イベントの parm1 にメールアドレスを入れているのに、別の受信者設定でも同じ人を指定している
• 委任ユーザーにも送られていて、本人と代理人の双方が同じメールボックスを見ている

よくある誤解は、「受信者が同じ人なら自動的に1通にまとまる」というものです。実際には通知の作られ方次第で、きれいにまとまらないことがあります。

原因の全体構造整理

通知重複は、次のように層で整理すると見失いません。

トリガーが重複している層

同じ業務事象に対して、複数の起点が同時に動く層です。
例としては、レコード更新で通知が飛ぶ設定に加えて、Business Rule から eventQueue を呼び、そのイベント通知も動いているケースです。さらに Flow Designer 側の Notification step まで重なると、利用者からは完全に「同じ通知が何度も来る」状態に見えます。公式でも通知の送信起点として、レコード挿入更新、イベント、Flow Designer の Notification step が明示されています。

通知レコードが重複している層

似た条件の通知レコードが複数あり、同じレコード更新で複数通る層です。
たとえば「Incident updated」と「High priority incident updated」の条件境界が曖昧で、優先度の高いインシデント更新時に両方発火するような形です。

受信者展開が重複している層

通知本体は1つでも、受信者の集め方が重複している層です。
ユーザー、グループ、フィールド参照、イベントパラメータ、委任などが重なりやすい場所です。

同期と非同期の流れが混在している層

画面更新、Business Rule、イベントキュー、Flow などの実行順や非同期処理のズレにより、設計者が「1回だけ」のつもりでも実際には複数経路で通知が作られる層です。

メール送信後の見え方で重複している層

ServiceNow内部では1通でも、配信先での転送、共有メールボックス、メーリングリスト、クライアントルール、委任閲覧により、利用者には重複に見える層です。
そのため、必ず sys_email と受信箱の両方で現象を切り分ける必要があります。

原因層ごとの詳細解説

ここからは、実務で多い原因を原因層ごとに見ていきます。

同じ業務イベントに対して通知起点が複数ある

最も多いのがこれです。
通知レコードは Record updated で送るようにしているのに、別の Business Rule でも gs.eventQueue() を呼び、そのイベントに紐づく通知も送っている。さらに Flow Designer でも同じ更新をトリガーに Notification step を実行している。この三重構造になると、設計者本人でも気づきにくくなります。

具体的な確認箇所は次の通りです。

• Notification の Send when
• Event name
• 対象テーブルの Business Rules
• Flow Designer の対象フロー
• Event Log
• sysevent
• sys_email

見るべき状態例は、

• 同一更新時刻付近に同一レコード向けイベントが複数ある
• sys_email に同内容メールが別通知名で生成されている
• Flow 実行履歴にも同時刻で送信処理がある

よくある誤解は、「Flow に通知があるなら通知レコードは関係ない」というものです。実際は両方が並行運用されている環境が少なくありません。

通知条件の設計が広すぎて重なっている

通知が多いインスタンスほど、条件の住み分けが曖昧になりやすいです。
「更新時に送る通知」と「コメント更新時に送る通知」が両方 Updated に乗っていて、条件がきれいに排他的になっていないと同時送信になります。

確認箇所は以下です。

• Conditions
• Advanced condition
• 更新対象フィールド
• 通知名と用途の対応表

状態例としては、

• 条件ビルダー上は違って見えるが、実際には同じ更新で両方 true
• Advanced condition 側で追加制御しておらず、境界がない
• 「作成用」「更新用」「コメント用」が全部 Updated に寄っている

よくある誤解は、「通知名が違うから用途も分かれているはず」というものです。名前ではなく、実際に通る条件で見ないと重複は見抜けません。公式でも、通知送信には Conditions と Advanced condition の両方が評価されるとされています。

Weight による重複抑止の前提を誤解している

Weight は便利ですが、雑に使うと逆に混乱します。
公式では、同じ target table と recipients を持つ通知は重複と見なされ、Weight が違えば高い方のみ送られ、他は Skipped mailbox に移されます。一方で Weight 0 は、条件を満たせば常に送信されます。つまり、全通知を Weight 0 のまま作ると、「抑止されるはず」と思っていた通知も普通に飛びます。

確認箇所は次の通りです。

• Weight
• Table
• 受信者
• sys_email の mailbox
• Skipped mailbox

状態例は、

• 似た通知がどちらも Weight 0
• 高優先通知を残したいのに Weight が逆転している
• 重複抑止されたつもりだが recipients が一致しておらず両方送られている

よくある誤解は、「本文が違えば別通知として両方送られる」「件名が違えば重複扱いされない」という理解です。実際には判定条件をきちんと押さえておく必要があります。

受信者の指定方法が重複している

Who will receive の設計ミスも非常に多いです。
Users/groups in fields で Assigned to を入れているのに、Groups にも同じ担当者が所属するグループを入れている。さらにイベント parm1 にも本人のアドレスを渡している。このように複数経路で同一人物を拾うと、通知の見え方が不安定になります。

確認箇所は以下です。

• Users
• Users/groups in fields
• Groups
• Event parm 1 contains recipient
• Event parm 2 contains recipient
• 対象 group の Include members
• Exclude delegates
• Send to event creator

状態例としては、

• グループ展開で本人が入る
• フィールド参照でも本人が入る
• イベント作成者も同一人物である
• 代理設定で実質同じ運用者に複数経路で届いている

よくある誤解は、「Groups を指定してもグループアドレスにだけ届く」というものです。公式では、Group members receive individual notifications only if Include members is selected とあるため、グループ設計次第で個別配信になります。

イベント設計で同じイベントを重ねて発火している

イベント通知は便利ですが、複数の Business Rule や Script Action から同一イベントを積み上げると重複が発生しやすくなります。
特に Before と After の両方で似た処理を書いていたり、更新のたびに毎回 eventQueue していたりすると、意図せず多重発火します。

確認箇所は以下です。

• Business Rules の When
• 条件式
• gs.eventQueue() 呼び出し箇所
• Event name
• sysevent
• 対象レコードの更新履歴

状態例は、

• 同一レコードに対して同イベント名が連続発火
• parm1 や parm2 は違うが、受信者が実質同じ
• 画面操作1回に対してイベントが複数記録される

よくある誤解は、「イベント通知は Record updated 通知より安全」というものです。安全かどうかはイベントの発火点設計次第です。

Flow Designer と従来通知が二重運用になっている

最近の環境では、従来型通知と Flow Designer の通知が並存していることがあります。
移行途中の環境で起きやすく、古い通知を止めずに新フローを足すと、現場では重複送信に見えます。公式でも通知の起点として Flow Designer の Notification step が示されています。

確認箇所は次の通りです。

• 対象テーブルのフロー
• フローのトリガー条件
• 通知レコードの Active
• レガシー Business Rule
• sys_email

状態例としては、

• 旧通知が Active のまま
• フローでも同件名の通知を送っている
• 本番でだけ両方有効

よくある誤解は、「フロー化したから旧通知は影響しない」というものです。Active のままなら当然残ります。

利用者からは重複に見えるが、実際は配信後の問題である

最後に見落としやすいのが、ServiceNow内部では1通なのに利用者は2通見ているケースです。
この場合は sys_email に1件しかなく、message log でも受信者理由が1回分しか出ません。ServiceNow公式でも、個別メールの確認には Sent System Mailbox と message log を見るよう案内しています。ここで1件なら、メール側の転送や共有ボックスルールを疑うべきです。

確認箇所は以下です。

• sys_email
• message log
• 実受信者のメールヘッダー
• メーリングリスト
• 自動転送設定

よくある誤解は、「受信箱で2通見えたら ServiceNow が2通送った」と断定することです。まず内部記録で確定させるのが先です。

実務での最短切り分けフロー

実務では、次の順番で切り分けると最短です。

まず sys_email で現象を確定させる

対象ユーザーが受け取った時刻で sys_email を検索し、同一subject、同一target record、近接時刻のメール件数を確認します。
ここで2件以上あれば、ServiceNow内部起因です。1件なら外部要因の可能性が高いです。Sent System Mailbox、Failed System Mailbox、message log を併せて見れば、送信の成否と受信者展開理由が追いやすくなります。

次に通知名と起点を特定する

sys_email から、どの通知で生成されたのかを追います。
同じ subject でも、別通知名・別起点で作られていることがあります。ここで Record updated なのか、Event fired なのか、Flow なのかを分けます。公式上、通知の起点は大きくこの3系統です。

受信者の重なりを確認する

通知レコードを開き、Who will receive の各設定を確認します。
特に Users/groups in fields と Groups の重なり、Send to event creator、Event parm 1 contains recipient、Event parm 2 contains recipient、Exclude delegates は優先的に見ます。グループレコード側の Include members も忘れず確認してください。

イベントとフローの二重化を確認する

通知が Event fired なら sysevent を見ます。
同イベントが1操作で複数行ないか、別Business Ruleからも同じイベントが積まれていないかを見ます。Flow Designer も使っているなら、同じ更新条件で通知処理がないか確認します。

最後に Weight と条件境界を調整する

原因が分かったら、最後に設計を整えます。
似た通知が並ぶなら、どれを主通知にするか決め、Weight と条件境界を整理します。ただし、Weight だけで片づけず、そもそも通知が複数経路で生まれない構造に寄せるのが本筋です。公式でも、Weight は重複通知に対する優先度であり、全ケースの設計ミスを救うものではありません。

設計観点からの再発防止

重複通知は、都度修正して終わりにすると再発します。
再発防止には「通知を送る責任をどこに置くか」を決めることが重要です。

通知の起点を一元化する

再発防止で最も効くのは、通知起点を混在させないことです。
同じ業務事象に対して、Record updated 通知で送るのか、イベント通知で送るのか、Flow Designer で送るのかを決め、原則を統一します。移行途中なら、旧通知の Active を残したままにしないことが大切です。

確認箇所は次の通りです。

• 対象機能の通知一覧
• Active な通知レコード
• 関連 Business Rules
• 関連 Flow

よくある誤解は、「複数経路を残した方が安全」という考え方です。通知では冗長化より責任分離の方が重要です。

受信者の定義を一か所に寄せる

誰に送るかは、複数の場所で決めない方が安定します。
たとえば担当者は Assigned to、承認者は承認エンジン、特定外部宛先だけ parm1、といったように責務を分けます。ユーザー、グループ、イベントパラメータを同時に足し算していく設計は、時間が経つほど事故率が上がります。公式でも受信者指定方法が複数用意されているため、便利さの反面、設計統制が必要です。

Weight は最後の安全弁として使う

Weight は主設計ではなく、競合時の整理用と考えた方が実務で安定します。
まず条件を排他的にし、それでも競合しうる通知だけ Weight で優先順位をつける。この順番にすると、後から見た人にも意図が伝わります。重複通知は Skipped mailbox に回ることがあるため、期待通りに抑止されたかどうかも観測しやすくなります。

可視化できる運用にしておく

通知は「たまにしか見ない設定」になりがちですが、運用で見えるようにすると再発を減らせます。
ServiceNowには Email notifications dashboard があり、通知の利用状況やトレンド、上位通知などを可視化できます。定期的に「よく飛んでいる通知」「使われていない通知」を見直すだけでも、放置された古い通知を整理しやすくなります。

まとめ

ServiceNowで通知が重複送信されるときは、まず sys_email を見て、ServiceNow内部で本当に複数メールが作られているかを確定させることが出発点です。
その上で、通知起点の重複、通知条件の重なり、Weight の誤解、受信者展開の重複、イベントの多重発火、Flow と従来通知の二重運用を順番に見ていくと、かなり高い確率で原因にたどり着けます。

実務で大事なのは、
「どの業務事象で」
「どの起点から」
「誰に送るか」
を一元的に設計することです。

通知の重複はメール機能の小さな不具合に見えますが、実際にはテーブル更新、イベント、非同期処理、受信者設計を横断して理解しているかどうかが問われるテーマです。CSA学習でも、このあたりを仕組みで捉えられるようになると理解がかなり深まります。

次に読むべき関連記事

通知の重複は単体で起きるより、前後の設計不備とつながっていることが多いです。次は以下のテーマも併せて確認すると、通知まわりの全体像がつながります。

関連して確認したいテーマ

• ServiceNow 通知 条件 動かない
• ServiceNow Event 発火しない
• ServiceNow メール ログ 確認方法
• ServiceNow sys_email readyのまま
• ServiceNow 通知 送信先が空になる
• ServiceNow メール通知 届かない

どれも「通知レコードだけを見ると迷うが、処理の流れで見ると整理できる」という点で共通しています。

体系的に学ぶ方法の一例

通知の重複のようなテーマは、個別トラブルとして覚えるより、通知、イベント、メールログ、Business Rule、Flow Designer のつながりで学ぶ方が実務では強いです。
独学で断片的に追うのが大変なら、体系的にまとまった教材を一つ持っておくのも進め方としては現実的です。たとえばUdemyのServiceNow講座のように、管理画面を実際に触りながら学べる教材は、通知設定と周辺機能の関係を整理する助けになります。

ただし、講座選びでは「通知だけ」に絞るより、イベント、メール、Flow、権限まわりまで含めて全体を学べるものを選ぶ方が、今回のような重複送信の切り分けには役立ちます。