Azure SQLとFabricを連携させたリアルタイムデータ異常検知の手法を解説

何が発表されたのか

Microsoft公式の技術動画配信番組「Data Exposed MVP Edition」において、Microsoft Data Platform MVPのMatt Gordon氏（Lean Techniques社 データ＆アナリティクス担当ディレクター）と、MicrosoftのAnna Hoffman氏が登壇し、Azure SQL DatabaseとMicrosoft Fabricを連携させた高度なリアルタイムデータ異常検知ソリューションの実装アーキテクチャを発表・解説しました。

本ソリューションは既存機能の高度な組み合わせによるもので、Azure SQL Databaseの機能である「Change Event Streaming」を用いてデータベースの更新ログ（トランザクションログ）を直接Microsoft FabricのEventstreamへ押し出し（Push）、KQL（Kusto Query Language）の時系列解析関数を活用して手動のしきい値設定なしで異常なデータスパイクを検出します。すでに提供中のプレビューおよび一般提供機能を活用した実用的な構成であり、今すぐ実務に導入可能なレベルで手順が示されています。

発表された機能・アップデートの全容

Azure SQL DatabaseにおけるChange Event Streamingの構成

動画では、Azure SQL Database Hyperscale上で動作するデータベース「GlobalGlassDB」を対象に、Change Event Streamingの設定手順がT-SQLコードを用いて説明されました。従来のChange Tracking（変更追跡）やChange Data Capture（CDC）と異なり、Change Event Streamingはトランザクションログから取得した変更イベントを、Polling処理なしで外部の宛先へ直接Pushするストリーミングメカニズムを提供します。

実演画面では、まずCREATE DATABASE SCOPED CREDENTIALコマンドを実行してManaged Identityを用いた認証情報を設定し、Azure SQL DatabaseからMicrosoft Fabricへのセキュリティで保護されたアクセス権限を付与しました。続けてシステムストアドプロシージャsys.sp_rx_create_event_stream_groupを実行し、Eventstreamの接続先URLやEvent Hubsの構成パラメータ（スキーマなしのRAWデータ、JSONフォーマット指定）を定義しました。最後にsys.sp_rx_add_table_to_event_stream_groupを用いて、チケット販売情報を保持するdbo.TicketSalesテーブルをストリームグループに追加することで、テーブル更新が即座に外部ストリームへ伝播する基盤を構築しました。

チケット販売シミュレーションと異常データの発生

異常検知の性能を実証するため、架空の国際サッカー大会「Global Glass 2026」の決勝戦チケット販売システムを模したシミュレーションデータが作成されました。リアルタイム検知アルゴリズムが正確に機能するには、事前に正常なデータパターンの「ベースライン」が存在している必要があります。

デモでは3つのフェーズでSQLクエリ（Query 1）が実行されました。フェーズ1では、一般の購入者による通常のチケット購入（正規の注文）のログを一定時間流し込み、システムの標準的な負荷と購入頻度のベースラインを形成しました。フェーズ2では、不正なBotプログラムによる買い占め攻撃（スキャルピング行為）を想定し、20秒間にわたり通常数値を大幅に逸脱する大量の購入リクエストを意図的に発生させました。そしてフェーズ3では再び通常の販売状態に戻す操作を行い、異常なデータスパイクが前後の正常データに挟まれた状態を作り出しました。このようにして、短時間で明確なスパイクを含むリアルタイムストリームを生成しました。

Fabric EventstreamとEventhouse（KQL Database）のリアルタイム連携

Azure SQL DatabaseからPushされた変更イベントは、Microsoft Fabricのリアルタイムインテリジェンス機能群によってシームレスに受信・蓄積されます。FabricのWebコンソール上では、グラフィカルなUIを用いてデータフローが可視化されました。

具体的には、Azure SQL側のChange Event Streamingからデータを受け取る「CustomEndpoint Source」ノードが配置され、そこからEventstreamノード「es-gg2026-sales」を経由して、最終的なデータストレージである「Eventhouse（KQL Database / Kusto Database）」へと自動接続されています。Eventhouseは時系列データの超高速な検索・分析に特化した分散データベースであり、ストリーミングデータに対してミリ秒単位の応答速度で分析クエリを実行できます。複雑なETLパイプラインやサードパーティのメッセージブローカーを一切挟むことなく、管理の行き届いたセキュリティ境界内でSQLログが時系列データベースへ流れ込む構成が示されました。

KQL関数「series_decompose_anomalies」による自動異常検知

本アーキテクチャの中核となるのが、FabricのKQL Queryset画面で実演された自動異常検知クエリです。従来のシステムでは「1分間の注文数が1,000件を超えたらアラート」といった固定のしきい値を人間が手動設定する必要がありましたが、本手法では機械学習アルゴリズムを数行のKQLで呼び出すことで完全自動化を実現しています。

使用された主要な関数はseries_decompose_anomaliesです。この関数は、時系列データに対して季節性（周期性）、トレンド、ノイズを自動的に分解（Decomposition）し、過去のパターンから統計的に大きく外れたデータポイントを検出します。デモ画面の「Anomaly Chart」タブでは、青い折れ線グラフで表示された正常値の推移の中に、Bot攻撃が発生した時刻（2026-06-16 20:11前後）において赤いマーカーで顕著なスパイク（Anomaly scoreが高いポイント）が自動強調表示されました。スコアは「標準偏差からどれだけ離れているか」を数値化したものであり、人間がルールを厳密に書くことなく、数分前の正常値と比較して異常と判定されたログ行（Anomaly Rows）のみが正確に抽出されました。

Fabric Activatorを活用した自動アラートと後続アクションの自動化

検知された異常データに対して、即座に運用上のアクションを起こすための仕組みとして「Fabric Activator（旧称Reflex）」が統合されています。KQL QuerysetのUI上にある「More -> Set Alert」ボタンをクリックすることで、クエリ結果を直接Activatorのルールの入力ソースとしてバインドする設定画面が開かれました。

Activatorの設定パネルでは、チェック間隔（例：5分ごと）と発火条件（イベント検出時）を定義でき、アクションの選択肢として多角的な自動化ルールが提示されました。単にチケット販売担当者のMicrosoft TeamsチャネルやEメールへ通知を発行するだけでなく、不正アクセスIPアドレスをファイアウォールで遮断する「Custom Action」の実行、データ補正処理を行う「Run Fabric Pipeline」「Run Dataflow」、あるいは「Run Notebook（PySpark/Pythonスクリプト）」を直接起動させることが可能です。これにより、人間がダッシュボードを監視し続ける必要がなく、データ面での異常検知からシステム的な自己修復や隔離処理までを完全自動化する一連のデータループが完成します。