はじめに
Microsoft Fabric の Activator は、リアルタイムデータの変化を監視し、条件を満たしたときに自動でアラートやアクションを実行する機能です。非常に強力な機能ですが、設定を誤るとアラートが意図せず連発され、「アラート疲れ」を引き起こすという落とし穴があります。
実は、この問題の多くは「ルール条件内の『出現』設定」の理解不足から生じています。
私自身も初めてPower BIから Activator のアラートを作成したとき、「なぜか1時間ごとにチームスの通知が来てうるさい」という悩みに直面しました。その原因は、ポーリング頻度と『出現』パターンの組み合わせの理解不足だったのです。
この記事では、Activatorの3つの「出現」パターンについて、実務的な例とともに詳しく解説します。正しく使い分けることで、意図した粒度でのアラート設定が可能になります。
Activatorのルール条件とは
Activatorでアラートを作成するときの基本構成は以下の通りです。
┌─────────────────────────────────┐
│ Activatorルール │
├─────────────────────────────────┤
│ 条件（Condition） │
│ ↳ どの値をいつ監視するか │
│ │
│ + 出現（Occurrence） │
│ ↳ どのタイミングで発火するか │
│ │
│ アクション（Action） │
│ ↳ メール・Teams・パイプライン等 │
└─────────────────────────────────┘
ここで最も誤解しやすいのが、「出現」パラメータです。同じ条件を書いても、この「出現」の設定次第で、アラートの頻度が大きく変わります。
ルール条件における「出現」の3つのパターン
パターン1：「条件が満たされるたびに」
正式名称： Every time the condition is met
動作イメージ
監視する条件（例：温度 > 25℃）が満たされたすべてのタイミングで、毎回アラートを発火させます。
監視対象：温度 > 25℃
時系列（5分ごとのチェック）：
09:00 → 26℃（TRUE） → ✉️ アラート発火
09:05 → 27℃（TRUE） → ✉️ アラート発火
09:10 → 26℃（TRUE） → ✉️ アラート発火
09:15 → 20℃（FALSE） → アラート無し
09:20 → 25℃（TRUE） → ✉️ アラート発火
メリット・デメリット
| 側面 | 説明 |
|---|---|
| 使い所 | 異常の検知など、とにかく素早く反応する必要がある場合 |
| 注意点 | ⚠️ 頻繁に条件が満たされるなら、アラートが何度も来る（アラートスパムのリスク）。センサーが常に閾値を超えている状態では、チェックのたびにアラートが来て、最終的にアラート無視につながる |
パターン2：「次の回数これが true だった場合」
正式名称： When it has been true for N times
重要： このパターンでは、経過時間（10分などの設定）は使いません。代わりに「N回」の連続TRUEで判定します。
動作イメージ
条件が連続でN回 TRUE になった時点で、1回だけアラートを発火させます。その後、FALSE が出ると「リセット」され、また1回目からカウント開始します。
監視対象：温度 > 25℃、かつ「3回連続 TRUE」の場合
時系列（5分ごとのチェック）：
09:00 → 26℃（TRUE） ← 1回目のカウント開始
09:05 → 27℃（TRUE） ← 2回目
09:10 → 28℃（TRUE） ← 3回目 → ✉️ アラート発火！（ここで1回だけ）
09:15 → 29℃（TRUE） → アラートなし（既に発火済み、カウント継続）
09:20 → 20℃（FALSE）→ リセット
09:25 → 26℃（TRUE） ← また1回目からカウント開始
09:30 → 27℃（TRUE） ← 2回目
09:35 → 28℃（TRUE） ← 3回目 → ✉️ アラート発火！
メリット・デメリット
| 側面 | 説明 |
|---|---|
| 使い所 | 「一度の異常が発生したら知りたいが、ずっと続く場合は1回だけで十分」という用途 |
| メリット | ✅ アラートが1回で済むので、ノイズが少ない |
| デメリット | ❌ チェック頻度に依存。5分ごとなら15分後、1時間ごとなら3時間後に気づくかも |
| 例 | 在庫が不足している状況を3回連続で検知したら通知。ずっと不足していても1回だけ |
パターン3：「次の期間中 true だった場合」
正式名称： When it has been true for [duration]
重要： このパターンでは経過時間を指定します（例：10分）。ただし、実際の動作はデータソースのポーリング頻度に大きく影響を受けるため注意が必要です。
動作イメージ
条件が指定した時間（例：10分）連続して TRUE のままであり続けたとき、その時点でアラートを発火させます。
監視対象：温度 > 25℃、かつ「10分間連続 TRUE」の場合
時系列：
09:00 → 26℃（TRUE）← 10分間のカウント開始
09:05 → 27℃（TRUE）
09:10 → 28℃（TRUE）← ちょうど10分経過 → ✉️ アラート発火！
09:15 → 29℃（TRUE）← 状態が続いているが、既に発火済み
09:20 → 30℃（TRUE）
09:25 → 20℃（FALSE）← 条件が外れた（カウント終了）
09:30 → 26℃（TRUE）← また10分間のカウント開始
09:40 → 27℃（TRUE）← 10分経過 → ✉️ アラート発火！
メリット・デメリット
| 側面 | 説明 |
|---|---|
| 使い所 | 「一時的な異常ではなく、ある程度の時間続いた場合に知りたい」という用途 |
| メリット | 継続的な異常を捕捉しつつ、一度きりの通知で済む |
| デメリット | 実際の頻度はデータソースのポーリング頻度に依存 |
Power BI由来のアクティベーターのポーリング周期
Power BIから Activator のアラートを作成すると、デフォルトで「1時間ごとのポーリング」に設定されています。
つまり、パターン3の「次の期間中 true だった場合」を経過時間10分で設定しても、実際のデータ確認は1時間周期で行われるため、以下のようなことが起きます：
設定：温度 > 25℃、経過時間 10分
実際の動作：
09:00 → Power BI をポーリング → 温度は25℃以上か？ Yes
（1時間待つ）
10:00 → Power BI をポーリング → 温度はずっと25℃以上か？ Yes
→ ✉️ アラート発火！（1時間後）
（1時間待つ）
11:00 → Power BI をポーリング → 温度はずっと25℃以上か？ Yes
→ ✉️ アラート発火！（2時間後）
ポーリング周期を変更する
注意点
ポーリング周期を短くするほど、Fabric Capacity の使用量が増加します。
パターン別：推奨される用途一覧
最後に、3つのパターンをまとめておきます。
| パターン | 英語 | 設定 | 推奨される用途 | 注意点 |
|---|---|---|---|---|
| パターン1 | Every time the condition is met | 固定なし | アラートを見逃したくない重大事象 | アラートスパムのリスク |
| パターン2 | When it has been true for N times | 回数を指定 | 何度か確認してから通知 | 反応が遅れる可能性 |
| パターン3 | When it has been true for [duration] | 時間を指定 | 継続的な異常を捕捉 | ポーリング周期を意識する必要がある |
参考ドキュメント
FabricやDatabricksについて学べる勉強会を毎月開催！
次回イベント欄から直近のMicrosoft Data Analytics Day(Online) 勉強会 または OneLake Deep Dive ページ移動後、申し込み可能です！