Business Ruleの「いつ動く？」が重要な理由
ServiceNowを触り始めると、同じ「自動化」でも選択肢が多いことに気づきます。Business Rule、Client Script、UI Policy、Flow Designer、（環境によっては）Workflow……。この中でBusiness Ruleは、サーバ側でデータが保存される瞬間に密接に関わるため、タイミングの理解が曖昧だと挙動がブレやすいです。
たとえば、こんな経験はありませんか？
- レコードを保存したはずなのに、値が思った通りにならない
- 保存後に別のフィールドが勝手に書き換わる
- 通知が二重に飛ぶ、または飛ばない
- 更新が重くなった／原因が追いづらい
この手の“謎挙動”は、だいたい次のどれかに分類できます。
- Before / After / Async の選び方がズレている
- Business Ruleの実行順（Order）や条件の組み合わせが複雑化している
- 他の仕組み（FlowやScript Include、クライアント側）と責務がかぶっている
CSAを目指す学習でも、暗記より「仕組みの理解」が効いてきます。Business Ruleの種類（Before/After/Async）を、単に言葉で覚えるのではなく、**“どの瞬間に、何が確定していて、何がまだ変わるのか”**を掴むと、実務でも試験学習でも迷いが減ります。
この記事では、Before/After/Asyncを「やれること・やってはいけないこと・判断基準」の形で整理します。コードは最小限にしつつ、初学者でもイメージできる例で説明していきます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
Before Business Rule：保存前にできること／やるべきこと
Before Business Ruleは、ざっくり言うと 「DBに書き込まれる前」 に動くルールです。ここが腑に落ちると、Beforeに置くべき処理が自然に決まります。
Beforeが得意なこと
Beforeで強いのは、次のような“保存前に整えておきたい”処理です。
- 入力値の正規化（空白除去、表記ゆれ修正、フォーマット統一）
- 初期値・自動採番の補助（条件によってフィールドを埋める）
- 保存を止める系のバリデーション（不正ならエラーを出して更新しない）
- 値の整合性を取る（AがこうならBはこう、のような制約）
例：短い説明文が空なら自動で補完する
「short_descriptionが空のまま保存されると困る」ケースを想像してみます。保存後に直すより、保存前に埋めた方が自然です。
- 条件：short_descriptionが空
- 処理：categoryやcallerをもとに仮の文言を入れる
こういうのはBefore向きです。
Beforeの注意点
Beforeは便利ですが、なんでも置くと事故ります。典型的な注意点はこれです。
- 重い処理を詰め込みすぎない
保存前に重い検索や外部連携をやると、ユーザー体験が悪化しやすいです（保存が遅い＝不満）。 - “通知”のような結果依存の処理は慎重に
保存前の状態は、まだ確定していない前提で考えると安全です。
Beforeに置くと安定する判断基準
迷ったら、この質問を自分に投げてみてください。
- 「この処理は、保存される値そのものを整えるため？」
→ YesならBeforeが第一候補。
After Business Rule：保存後にできること／注意点
After Business Ruleは 「DBに書き込まれた後」 に動きます。ここでのポイントは、保存が完了しているため、“確定したレコード”を前提に次の処理へ進めることができる点です。
Afterが得意なこと
Afterは、保存の結果に基づいて動く処理と相性が良いです。
- 関連レコードの更新（子→親へ集計、ステータス連動など）
- 履歴や監査に近い処理（変更結果に応じてログやコメントを追加）
- 保存後に発火してよい自動処理（ただし負荷に注意）
例：子レコード更新後に親のカウントを更新する
たとえば、Incidentに紐づくTaskを管理していて、子が増減したら親の「子件数」を更新したい、など。これは保存後に“確定した変更”を見て動いた方が安全です。
Afterでよくある落とし穴：自分で自分を更新してループ
Afterでやりがちな失敗が、Afterでcurrentを更新して、またBusiness Ruleが走るパターンです。
- Afterで current.update() を呼ぶ
- その更新がさらにAfter/Beforeを呼ぶ
- 気づかないうちに処理が重くなる／二重実行になる
対策の方向性は次の通りです。
- そもそもAfterでupdateしない設計にできないか（Beforeで済むならBeforeへ）
- 条件を厳密にする（「このときだけ」動くようにする）
- 再実行を防ぐフラグ設計（必要な場合のみ）
「Afterに置いたのに二重で動く」「通知が2回飛ぶ」などは、ここが原因のことが多いです。
Afterに置くと安定する判断基準
- 「この処理は、保存が完了したことを前提にしたい？」
→ YesならAfterが第一候補。
Async Business Rule：非同期の意味、向いている処理、落とし穴
Async Business Ruleは、言葉の通り 非同期（ユーザーの保存処理と切り離して後で実行） されます。体感としては「保存ボタンを押した瞬間の待ち時間に影響しにくい」方向です。
Asyncが向いている処理
Asyncを考えたくなるのは、だいたい次のようなケースです。
- 通知・連携など時間が読めない処理
- 重い集計や検索（ただし設計次第）
- ユーザー操作のレスポンスを優先したい処理
例：更新をトリガに通知したい（ただし二重送信に注意）
「状態がResolvedになったら関係者に通知」といった要件はよくあります。ユーザーが保存した瞬間にメール送信処理で待たされるのは嫌なので、Asyncで切り離したくなります。
ただし、ここにも落とし穴があります。
Asyncの落とし穴：その瞬間のcurrentを“確定情報”として扱いすぎる
Asyncは“あとで動く”ので、極端に言うと、実行までの間にレコードがさらに更新されている可能性があります。
- 状態をA→Bに更新した直後にAsyncが走る想定
- でもその間に別の更新でB→Cになっていた
- 結果として「Bになった通知」を送るつもりが、Cの内容で送られる／条件を満たさない など
対策はシンプルで、設計の時点で次を意識します。
- “何を基準に処理するか”を明確にする
変更前後（previous/current）に依存するなら、扱いを丁寧にする。 - イベント駆動（Event + Notification）も選択肢に入れる
通知をBusiness Rule直書きにせず、イベント設計に寄せると整理しやすいことがあります。
Asyncに置くと安定する判断基準
- 「この処理は、ユーザーの保存を遅くしたくない／時間がかかる可能性がある？」
→ YesならAsyncが候補。
ただし「あとで動く＝状態が変わり得る」前提で設計するのがコツです。
迷ったときの判断基準とデバッグ手順（順序・競合・再現性）
Before/After/Asyncを理解しても、現場や学習環境では“複数の仕組みが同時に動く”ので混乱しがちです。ここでは、迷ったときの判断基準と、最小の手順で原因を切り分ける方法をまとめます。
まずは判断基準を固定する（迷いを減らす3問）
- 保存される値を整える処理か？
→ Yes：Before - 保存完了を前提に、関連レコードへ影響させたい処理か？
→ Yes：After - 時間がかかる／ユーザー操作を遅くしたくない処理か？
→ Yes：Async（ただし状態変化を前提に）
この3問で8割は整理できます。
Business Rule同士の“順序”で崩れることがある
Business Ruleは1つだけなら分かりやすいですが、増えると次の問題が出ます。
- 同じテーブルに複数のBusiness Ruleがある
- 似た条件で動いてしまう
- Orderの違いで結果が変わる
- さらに他の仕組み（Flowなど）も絡む
この状態で「なんとなく動かない」を追うと沼ります。おすすめは、再現性のある最短ルートを作って、順番に潰すやり方です。
デバッグ手順（初心者でもやりやすい現実的な流れ）
- 対象テーブルのBusiness Ruleを一覧で確認する
“同じタイミング（Before/After）で同じフィールドを触っていないか”を見るだけで、原因が見えることがあります。 - 条件を言語化する（日本語で書けるか）
「どの状態で、何が変わったら、何をする」を一文で書く。書けない場合、条件が曖昧で二重実行の温床になりがちです。 - ログを仕込んで“どれが動いたか”を先に確定する
いきなり正解を当てにいかず、「動いてる／動いてない」を確定させるのが近道です。 - 一時的に条件を絞る（対象ユーザー、特定番号など）
全体に影響させず、自分のテストデータだけで再現できるようにすると安全です。
Business RuleとFlow Designerの役割分担で詰まる場合
最近はFlow Designerを併用する機会も増えています。ここで重要なのは「どちらが正しい」ではなく、責務が重なっていないかです。
- Business Rule：保存に密接な整形・制約・整合性
- Flow：プロセス（承認、通知、タスク作成など）を見通しよく構成したい領域
もちろん例外はありますが、「同じ目的を両方でやっていないか？」を疑うだけで、挙動のブレが減ります。
学習を体系化したい人へ
Business Ruleは“なんとなく書ける”段階から、“設計の意図を説明できる”段階に上がると一気に楽になります。独学だと、Before/After/Asyncの使い分けを自分の経験だけで補うのが難しいこともあります。
そこで、体系的に学べる教材の一例として、UdemyのServiceNow入門〜スクリプティング基礎（Business Ruleやサーバサイドの考え方を扱う講座）を1本持っておくと、知識の穴が埋まりやすいです。講座選びのコツは、最新リリースに完全一致しているかよりも、「なぜそのタイミングに置くのか」まで説明しているかを見ること。そこが分かる講座は、応用が効きます。
本番形式で慣れるのが合格への近道。UdemyのServiceNow模擬問題集を人気順で一覧比較できます👇
まとめ
Business RuleのBefore/After/Asyncは、言葉だけ覚えると混乱しやすいのですが、ポイントはシンプルです。
- Before：保存される値を整える（正規化、初期値、バリデーション）
- After：保存完了後の結果を使って処理する（関連更新、結果に基づく処理）
- Async：重い処理や通知など、保存のレスポンスを優先して切り離す（ただし“あとで状態が変わる”前提で設計）
そして、挙動が不安定なときは「タイミング」だけでなく、Business Rule同士の順序・条件の重なり・他の仕組み（Flow等）との責務の重複を疑うのが近道です。
CSAの学習でも、実務でも、ここを理解していると「なぜこの設計にするのか」を自分の言葉で説明できるようになります。暗記に寄せるより、仕組みとして掴んでおくと、応用問題や現場の“謎挙動”に強くなります。
