Azure Stream Analyticsとは？主な機能や料金、Fabricとの違いを解説

Azure Stream Analyticsとは、ミリ秒未満のレイテンシでストリーミングデータをリアルタイム分析する、Azure上のフルマネージドなストリーム処理エンジンです。
2026年時点では、Fabric Real-Time Intelligenceの登場によって「no-codeのFabric側」と「SQL細粒度制御のAzure側」に住み分けが進み、両者を使い分ける前提での再評価が必要な局面に入っています。

本記事では、主要機能・Azure Portalでの始め方・クエリと処理パターン・Fabric Real-Time Intelligenceとの違い・V2料金体系・活用シーン・導入で詰まりやすい論点までを、2026年7月時点の最新情報で体系的に解説します。

Azure Stream Analyticsとは？ミリ秒未満のストリーム処理エンジン

Azure Stream Analytics（略称ASA）とは、Microsoft Azure上で稼働する、ミリ秒未満のレイテンシでストリーミングデータを分析・処理するフルマネージドのストリーム処理エンジンです。

内部エンジンはMicrosoft Researchが開発したTrill——メモリ内で動作するストリーミング分析エンジン——で、SQLを拡張した独自のクエリ言語で処理を記述します。ハードウェア調達もOSやランタイムのアップデートも不要で、状態管理・チェックポイント・スケーリングまで含めてマネージドの領域として扱われます。

2026年現在、Azureのストリーム処理サービスとしてASAが唯一の選択肢だった時代は終わり、Microsoft Fabric側に「Real-Time Intelligence（RTI）」というno-codeとSaaS消費モデルを前面に出したサービスが登場しています。

その結果、ASAは「Fabricエコシステムに乗せない、SQLでの細粒度制御と既存Azure PaaSの組み合わせが要件になる領域」を担う、pro dev向けの位置づけに整理されつつあります。

Azureのデータサービスにおける位置づけ

ASAは、Azure上でデータを扱うワークロードを3層——収集・処理・保存——に分けたとき、中央の「ストリーム処理層」を担当するサービスです。

• 入力側
  Azure Event Hubs、Azure IoT Hub、Azure Blob Storage、Azure Data Lake Storage Gen2 からデータストリームを受け取る
  
  

• 出力側
  Azure SQL Database、Azure Cosmos DB、Blob Storage、Azure Synapse Analytics、Power BI 等にリアルタイムでルーティング
  
  

• 実行環境
  Azureクラウド、またはAzure IoT Edgeランタイム上のエッジデバイス（同じクエリ言語で両対応）

この位置づけの理解が、後述のFabric Real-Time Intelligenceとの使い分けを考える際の土台になります。

Azure Stream Analyticsの主な機能

ASAの機能は、「ストリーミングデータをSQLで扱えるようにする」ための一連の要素で構成されます。ここでは、実装や設計判断に直結する7つの機能領域を整理します。

SQLベースのストリームクエリ言語

ASAのクエリは、SQLを時間軸拡張したストリーム分析用言語で書きます。標準SQLのSELECT・GROUP BY・JOIN・WHERE等の構文をほぼそのまま使えるため、T-SQLやBigQueryを触ったことのあるデータエンジニアなら数時間で書き始められます。

追加要素として、時間ウィンドウ（Tumbling / Hopping / Sliding / Session）、時間結合（「DATEDIFF」関数を伴う JOIN）、時間分析関数（「ISFIRST」、「LAST」、「LAG」）といった、ストリーム特有の演算子が組み込みで用意されています。

参照データ（Azure Blob Storage / Azure SQL Database に保存された静的または低頻度更新のテーブル）をストリームと結合するルックアップも標準機能です。

ウィンドウ関数と時間演算

ストリームデータの分析でほぼ必ず使うのがウィンドウ関数です。

ASAでは以下の5種類が公式ドキュメントで提供されています。

• Tumbling window（タンブリング）
  固定サイズで重複しない時間バケット。「1分ごとの合計」のような集計に使う
  
  

• Hopping window（ホッピング）
  固定サイズで重複ありの時間バケット。「1分ウィンドウを10秒ずつずらして計算」のような重複計算に使う
  
  

• Sliding window（スライディング）
  イベントの前後を可変にした時間範囲。「直近5分の平均値をイベントごとに再計算」に使う
  
  

• Session window（セッション）
  アクセスが途切れたら区切る動的ウィンドウ。「ユーザーの1操作セッション内の合計」に使う
  
  

• Snapshot window（スナップショット）
  同一タイムスタンプで到着したイベントをまとめるウィンドウ。他ウィンドウと違い明示的な関数呼び出しなしで「System.Timestamp()」を GROUP BY 句に使うだけで動作する

実装で使うのは主にTumbling / Hopping / Sliding / Sessionの4つで、Snapshotは同時刻イベントの集約が要件になった場面での選択肢という位置づけです。集計対象がイベントベースか時間ベースか、重複を許容するかどうかで使い分けが決まります。

豊富な入出力コネクタ

入力ソースと出力シンクの組み合わせが柔軟なのがASAの実務的な強みです。

入力側は、Azure Event Hubs（Kafka互換の受け口を含む）、Azure IoT Hub、Blob Storage、Data Lake Storage Gen2、Apache Kafka クラスターへの直接接続に対応します。

出力側は、Blob Storage / Azure Data Lake Storage Gen2、Azure SQL Database、Azure Cosmos DB、Event Hubs（後段パイプラインへの再送）、Azure Data Explorer、Synapse Analytics、Power BIリアルタイムダッシュボード、Azure Functions、Service Bus、PostgreSQL等が公式サポートされており、単一クエリの結果を複数シンクに同時ルーティングできます。

Azure ML／UDFによる拡張性

組み込み関数だけで足りない場合、ユーザー定義関数（UDF）とユーザー定義集計（UDA）、およびAzure Machine Learning UDFによる外部モデル呼び出しでクエリを拡張できます。

現時点で使えるUDF/UDAはJavaScript版のみです。C# UDFはロードマップから廃止されており、2024年9月30日以降は新規実装の選択肢に含めないのが安全です。

Azure ML連携は、Azure Machine Learning側でモデルをWebサービスとしてデプロイし、Swagger仕様に基づいてASA側で関数として登録、SQLクエリから呼び出す流れになります。ノーコードエディターはUDF・UDA・ML UDFいずれも扱えないため、拡張が必要になった段階でSQLエディターに切り替える設計が前提です。

ノーコードエディター

ASAには、Azure PortalまたはEvent Hubs Portalから利用できるノーコードエディターが用意されています。

ドラッグアンドドロップで入力・変換・出力を組み合わせられ、SQLを書かなくてもストリーム処理ジョブを構築できます。データエンジニアではないビジネスユーザーがプロトタイプを作る場面や、Event Hubsに流れてきたデータをそのまま Power BI に接続したい場面で有効です。

ただし、複雑な時間ウィンドウ演算やUDF連携が必要な場面は SQL エディター側での記述が現実的で、ノーコードエディターは軽量な変換パイプラインの構築に向いた選択肢と割り切って使うのが実務的です。

IoT Edgeでのエッジ実行

ASAは、Azure IoT Edgeランタイム上でも同じクエリ言語のジョブを実行できます。
クラウドとエッジで同じクエリ・同じ開発ツールを使えるのがASAの特徴で、クラウドで開発したロジックをエッジに配布する「ハイブリッド構成」が組みやすくなっています。

工場やビル管理のように、ネットワーク接続が不安定な現場でリアルタイム処理を求められる場面では、この機能が実質的な要件になります。

後述のFabric Real-Time Intelligenceにはこの選択肢がないため、エッジ実行が要件に含まれる案件ではASAが第一候補になります。

開発者ツールとCI/CD

Azure Portalだけでなく、Visual Studio Code拡張機能、Visual Studio、Azure CLI、Azure PowerShell、Bicep、Azure Resource Manager テンプレート、Terraform に対応しています。

ローカルでクエリをオフライン開発してGit管理し、CI/CDパイプラインでAzureにジョブをデプロイする——一般的なアプリケーション開発と同じワークフローに乗せられる点が、Azure DevOpsユーザーには馴染みやすい設計です。

Azure Stream Analyticsの始め方（Azure Portalでのジョブ作成手順）

ここからは、Azure Portalで実際にASAのジョブを作成する手順を整理します。初回セットアップは慣れれば10〜15分で完了する範囲で、はじめての方でも既存のAzure環境があれば当日中に動作確認まで到達できます。

前提条件

ASAを利用開始する前に、以下の3点を確認してください。

• Azureサブスクリプション
  無料アカウントでも試せますが、Event Hubs / IoT Hub 側の料金が別途発生する
  
  

• 入力ソース
  検証用に Event Hubs か IoT Hub のインスタンスを1つ用意する（Blob Storageから静的データを流す構成でもよい）
  
  

• SUクォータ
  サブスクリプション単位で1リージョンあたりの上限SU数が設定されている。試験用途なら初期上限で足りるが、本番運用でSU数を大きく確保する場合は Microsoft サポート経由で上限緩和申請が必要になる

これらが揃った上で、Azure Portalにサインインし、リソースの作成メニューから「Stream Analyticsジョブ」を検索して開始します。

基本操作の手順（5ステップ）

ASAジョブの作成〜起動までは、Azure Portal 上で5ステップに整理できます。以下、各ステップで表示される画面と、そこで押さえておくべき設定項目を順に見ていきます。

Step 1: ジョブを新規作成する

Azure Portal のリソース作成画面で「Stream Analytics ジョブ」を検索し、「基本」タブでリソース名・サブスクリプション・リソースグループ・リージョン・SU数・ホスティング環境（クラウド or エッジ）を入力します。最後に「確認と作成」タブに進むと、以下の画面で設定内容が一覧表示されるので、内容を確認してから「作成」をクリックしてジョブを立ち上げます。

ここでの選択は後から変更が難しい項目（リージョン・ホスティング環境）と、あとから変更できる項目（SU数）が混在します。特にリージョンは Event Hubs / IoT Hub と同一リージョンを揃えないと、リージョン間トラフィック料金と遅延が発生するため、入力側のリソースに合わせて選ぶのが基本です。

作成が完了すると、ジョブの概要ページが開きます。

概要ページには、ジョブの状態・入出力・SU利用率・稼働メトリクスへの導線がまとまっており、以降の各ステップは、左メニューの「入力」「出力」「クエリ」から順に設定していきます。

Step 2: 入力（Input）を設定する

「入力」メニューを開き、Event Hubs / IoT Hub / Blob Storage 等の入力ソースを追加します。

上の画面は IoT Hub 入力を追加するフォームで、IoT Hub 名前空間・共有アクセスポリシー名・ポリシーキー・コンシューマーグループ・エンドポイントを指定するUIになっています。

ここで詰まりやすいのが認証方式で、ASA の入力側のマネージドID対応表によれば、Event Hubs / Blob / ADLS Gen2 入力ではマネージドIDが使えますが、IoT Hub 入力は現時点でマネージドID非対応で、共有アクセスポリシー名とキーで認証するのが基本です（マネージドIDで統一したい場合は Event Hubs 経由でルーティングするのが公式の回避策）。

そのほか、コンシューマーグループ（他のコンシューマーとの分離のため、ASA 専用のグループを切るのが安全）、シリアライズ形式（JSON / Avro / CSV）も詰まりやすい項目です。JSON を選ぶ場合は、入力サンプルをアップロードすると次のクエリ画面でスキーマ推論が効きます。

Step 3: 出力（Output）を設定する

「出力」メニューから、Cosmos DB / SQL Database / Blob / Power BI 等の出力先を追加します。

出力側では、パーティション設計がスケーラビリティを決める中核の設定です。たとえば Cosmos DB を出力にする場合、パーティションキーの選び方次第で書き込みスループットが数倍変わることがあります。後の「詰まりやすい論点」でも触れるとおり、出力側の設計は本番投入前の見直し対象になることが多い項目です。

Step 4: クエリを書く

「クエリ」メニューでは、左右のパネルで入力・出力を参照しながら、中央のエディターで SQL クエリを記述します。

ライブストリームからのサンプリング、またはローカルの JSON / CSV ファイルをアップロードしてテストデータを流し込み、実行結果を画面右下でリアルタイム確認できます。書きながら動作確認できるため、時間ウィンドウの挙動や 「PARTITION BY」 の効き方を本番投入前に検証する用途で必須の画面です。

Step 5: ジョブを開始する

クエリの動作確認が済んだら、「概要」ページから「開始」を選び、開始ダイアログで出力開始時刻を指定します。出力開始時刻は「今すぐ」「カスタム時刻」「最後に停止した時刻」の3択で、既存ジョブを停止・再開する場合の巻き戻し処理も「最後に停止した時刻」を選べば自動で組み立てられます。

開始処理が走ると、上の画面のように概要ページの状態表示が「開始中」→「開始済み」に切り替わり、「ジョブの停止」ボタンが有効化されます。ここまでの手順で、リアルタイムでイベントを取り込み、SQL で処理し、結果を出力するパイプラインが1本立ち上がります。

ノーコードエディターでの構築（応用パターン）

SQL を書かずに構築したい場合は、Event Hubs Portal または Azure Portal からノーコードエディターを起動できます。

上の画面のように、入力ソース・変換ブロック（フィルター・集計・ジョイン）・出力シンクをドラッグアンドドロップで組み合わせて、「Event Hubs入力 → フィルター → 集計 → Power BI出力」のようなパイプラインを組み立てます。各ステップの中間結果はライブプレビューで確認できます。

ノーコードエディターは、社内のビジネスユーザーがPoCを回す場面や、既存の Event Hubs データを軽く整形して Power BI に流したい場面で使いやすい選択肢です。ただし、複雑な時間ウィンドウやUDF呼び出しが必要になった時点で、標準の SQL エディター側に切り替えるのが現実的です。

Azure Stream Analyticsのクエリと処理パターン

ASAの実装で成否を分けるのが、クエリの書き方です。SQLに似ているために書き始めやすい一方、時間軸の扱いを誤ると意図しない結果が出続けたり、SU利用率が急上昇して詰まったりします。

このセクションでは、実装で押さえておくべき4つの処理パターンを整理します。

ウィンドウ関数の使い分け

先ほど機能一覧で触れた代表的な4種類のウィンドウ関数（Snapshotを除く）は、それぞれ「時間の切り方」が異なります。以下の表で、実務での使い分けを整理しました。

使い分けの実務ポイントは、「重複計算を許すか」と「集計トリガーが時間か・イベントか」の2軸で決まります。Tumblingは重複なし・時間トリガー、Slidingはイベントトリガー・重複あり、というふうに整理すると迷いが減ります。

異常検出関数の使いどころ

ASAには、機械学習モデルを組み込まずに時系列の異常を検出できる関数が用意されています。代表的なのが以下の2つです。

• 「AnomalyDetection_SpikeAndDip」
  想定範囲を大きく外れた「スパイク（急上昇）」「ディップ（急減）」を検出する。センサー値の急変検知に向く
  
  

• 「AnomalyDetection_ChangePoint」
  平均値の緩やかなシフト（トレンド変化）を検出する。緩慢な機器劣化やユーザー行動の緩やかな変化に向く

実際に使う際は、以下のようにクエリエディター内で通常のSQL関数として呼び出します。

両者は「異常のスコア」と「異常フラグ」を返すため、閾値を書き換えるだけで感度を調整できます。まず組み込み関数で当たりをつけ、精度が不足する場合にAzure Machine Learning側でカスタムモデルを呼び出す設計が実務的です。

パターンマッチングとイベントシーケンス

「MATCH_RECOGNIZE」に相当するパターンマッチング機能を使うと、「イベントAの後に3回イベントBが続いたらアラート」のような複雑イベント処理（CEP: Complex Event Processing）を書けます。

不正取引の疑い検知、IoT機器の「起動→エラー→再起動」の連鎖検出、Webアプリの操作ステップ完遂率測定など、単純な閾値では捉えられないユースケースで威力を発揮します。

PARTITION BYと並列化

大容量トラフィックの本番運用でSU利用率が跳ね上がる主要因は、GROUP BYやJOINで扱う「グループのカーディナリティ（集約対象の一意ID数）」の高さです。

対策の基本は、Event HubsのパーティションキーとASAの 「PARTITION BY」 を揃えて、パーティションごとに独立に並列処理させる設計です。以下のクエリ例では、「clusterid」 別集計を Event Hubsパーティションごとに分割して実行しています。

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

このアプローチの利点は複数あります。1つは、各ストリーミングノードが担当する 「clusterid」 数が減ることで、GROUP BY の状態サイズがノード当たり小さくなる点。もう1つは、SUの追加によって処理能力が線形に伸びる「完全並列」構成に持ち込めるため、負荷増に対して SU 追加でリニアに対応できる点です。

Event Hubs側のパーティション数と揃えずに 「PARTITION BY」 を書くと、シャッフルが発生してかえって遅くなるため、入力側のパーティション設計とセットで考えるのが鉄則です。

上の画面のように、Azure Portal のクエリエディターにはテストデータを流して結果をリアルタイム確認できる機能が組み込まれています。

「PARTITION BY」 の効き方や集計値のカーディナリティを本番投入前に検証しておくと、SU利用率スパイクによる事故を避けられます。パーティション数と SU の関係の詳細は、公式のストリーミングユニットの説明に整理されています。

Azure Stream AnalyticsとFabric Real-Time Intelligenceの違い

2024年以降のAzureデータプラットフォーム界隈で最も混乱を招いているのが、ASAとMicrosoft FabricのReal-Time Intelligenceの使い分けです。

「SQL vs no-code」でだけ整理すると全体像を取り違えます。

ここでは、Microsoft公式が公開しているReal-Time Intelligenceと類似Azureソリューションの比較ドキュメントを土台に、実務判断に効く違いを整理します。

全体比較表

以下の表で、ASAとFabric RTIの主要な違いを整理しました。位置づけの違いを理解すれば、後の使い分け判断がしやすくなります。

ASAは「Azure PaaS上でSQLベースの柔軟な処理を細粒度で組みたい pro dev 向け」の位置づけ、RTIは「Fabric内でno-code UIとKQL・Eventhouseの長期分析基盤まで含めてSaaS的に完結させたい組織向け」の位置づけです。

つまり、SQLかno-codeかという表面的な違いよりも、「Fabricエコシステムの中で完結させるか、Azure PaaSの組み合わせで組むか」が本質的な選択軸になります。

なお、Fabric Eventstreamsには SQL operator preview や DeltaFlow preview が追加されており、「RTIは完全にno-codeとKQLのみ」というわけではありません。

ただしSQL operatorはpreview段階で機能範囲も限定的なため、SQL細粒度制御が要件になる案件では引き続きASAが有力な候補です。

ユースケース別の使い分け

以下のケースでは、ASAとRTIのどちらを選ぶかの判断軸が明確です。

• 新規のリアルタイム分析基盤を組む・Fabric導入済み・Power BIやKQLで長期分析したい
  Fabric RTIが第一候補。Eventstream で no-code に組み、Eventhouse で KQL クエリまで一気通貫にできる
  
  

• 既存のASAジョブが安定稼働している・Fabric導入計画がない・SQLでの細粒度制御が要件
  ASAを継続。移行の技術的必要性はない
  
  

• IoT Edgeでのローカル実行が要件
  ASAが有力。Fabric RTIにはエッジ実行の提供がない
  
  

• Kinesis / Google Pub/Sub / CDC / MQTT を含め、多様なストリームソースをネイティブに扱いたい
  Fabric RTIが有力。Apache Kafka 自体は ASA でも直接接続の入力構成があるため単独要件なら ASA でも対応できるが、Kinesis / Pub/Sub / CDC / MQTT まで広くネイティブ入力で扱うなら Fabric RTI の Eventstream が優位
  
  

• SQLを書けるデータエンジニアが中心・組織にKQLのスキルが薄い
  ASAが第一候補。RTIのメインクエリ言語はKQLで、SQL経験者にとっては学習コストがかかる

実務的には、「Fabricエコシステムをどこまで導入しているか」で線を引くと判断が早くなります。

Fabric導入予定がなければASAが有力、Fabric導入前提ならRTIが有力、という前提を置いたうえで、上記の例外条件（IoT Edge・SQL細粒度制御・Kafka系接続の要否）で個別に判断するのが実務的です。

移行判断のシグナル

ASAからRTIへの「移行必須」の局面は、2026年7月時点では存在しません。ASA自体は廃止予定なく現役継続で、V2 pricingで最大80%のコスト削減も進んでいます。

ただし、以下のシグナルが揃ってきた場合は、次期システムでRTIへの切り替えを検討する価値があります。

• Fabric導入プロジェクトが並行で進んでおり、Power BI・OneLake・Fabric Data Warehouseと連携する要件が増えている
• KQLでの長期分析・アドホッククエリのニーズが業務側から出てきている
• 既存ASAジョブのメンテナンスが特定エンジニアに属人化しており、no-code UIで運用移管したい

これらが2つ以上該当するなら、Fabric RTIへの移行を「次期システム更改のタイミング」に組み込む判断が有力です。

なお、既存ASAの出力をFabric側に転送する運用（ASAの Event Hubs 出力 → Eventstream の custom endpoint で受ける）も公式にサポートされており、段階的な併存も現実的です。

Azure Stream Analyticsの料金体系（V2 pricing）

ASAの料金は、Microsoft公式pricingページによれば、V2 pricing（推奨）と V1 pricing（旧・非推奨）の2種類があります。

公式pricingページには明確な V1 廃止日は掲載されていませんが、SU consumption ドキュメントでは「SU V1（to be deprecated）」と非推奨扱いが明示されています。ここではV2 pricingを中心に、実務での試算まで含めて整理します。

V2 pricingの構造

V2 pricingは、2023年7月に導入されたASAの新料金モデルで、V1と比べて最大80%のコスト削減が可能な設計です。

V1は「6 SU = 1ストリーミングノード」だったのに対し、V2は「1 SU V2 = 1ストリーミングノード」にシンプル化されました。

V2ではさらに「1/3 SU V2」「2/3 SU V2」というフラクショナル容量が用意されており、小規模ジョブやPoCで最低構成を軽くできます。

段階割引の仕組み

V2 pricingの最大の特徴は、月次のSU時間集計に対して段階的な単価が適用される点です。US East（USD）をAzure Retail Prices APIで確認した実単価は以下のとおりです。

この段階割引が効果的に働くのは、24時間365日稼働する常時ジョブを運用する場合です。1 SU V2 を24時間稼働で1ヶ月動かすと約730 SU時間で第1段の上限に届き、以降のSU増加分は $0.144474 の単価に切り替わります。

さらに複数SUを積み上げて 5,840 SU時間超に達すれば $0.120318 まで下がるため、「本番運用を想定した長時間ジョブ」ほど実効単価が低くなる料金構造になっています。単価はリージョンによって差があり、Japan Eastは US East比でやや上振れる傾向のため、正確な見積もりはAzure料金計算ツールを使ってください。

専用クラスター（Dedicated V2）

より大規模なワークロードや、仮想ネットワーク内での完結運用、追加のワークロード分離が要件になる場合は、専用クラスター（Dedicated V2）が選択肢に入ります。

• 最小12 SU V2 から利用開始
• 段階単価は Standard V2 と同一構造（US East・USDで $0.33 / $0.144474 / $0.120318）
• 仮想ネットワークサポート、組み込みカスタム関数対応
• 公式pricingページの機能表では可用性ゾーンが「Yes」と示されているが、後述の信頼性ドキュメントではリージョン全体のゾーン冗長挙動に関する記述と揺れがあるため、可用性ゾーンを条件にする案件では公式サポートに現時点の挙動を確認するのが安全

正確な見積もりはAzure料金計算ツールで自社のリージョン・SU数・稼働時間を入力して算出してください。

実試算例（Standard V2・US East基準）

具体的なイメージのため、Standard V2 での代表的な運用パターンを Azure Retail Prices API のUS East単価に基づいて試算しました。参考値として使ってください。

この表から読み取れるのは、SU数が増えるほど1SUあたりの実効単価が下がるという段階割引の効き方です。

1 SU 構成では第1段（$0.33）だけで完結する一方、6 SU では第2段まで、12 SU では第3段まで一部が届くため、SUを積むほど単価改善が効きます。

なお、上記は Standard V2 の目安であり、Dedicated V2 の実額は仮想ネットワーク統合など追加要件のオプションを含めて Azure料金計算ツールで見積もる必要があります。

V1→V2移行

まだ V1 pricing で運用している既存ジョブがある場合、V2への移行はコスト削減効果が大きいため、優先度の高い作業になります。

移行手順は、まず検証環境で SKU 変更の可否と停止・再開時の挙動を確認するのが安全です。

ジョブによっては SKU 直接切り替えでは扱えないケースや、状態管理・チェックポイントの引き継ぎに追加検討が必要なケースが想定されるため、必要に応じてジョブ定義のエクスポート・再作成も含めた移行計画を組みます。

Microsoft公表値では V1→V2 で最大80%のコスト削減が期待できるとされているため、本番投入前に検証環境で V2 単価と実際のワークロードを突き合わせて試算しておくのが実務的です。

Azure Stream Analyticsの活用シーン

Microsoft公式のStream Analytics概要ドキュメントでは、ASAが強みを発揮する5つのシナリオが例示されています。

ここでは、各シナリオの実務での使われ方を整理します。

IoTセンサーの異常検出

工場設備や建物設備、輸送機器などに取り付けたセンサーからのデータをASAに流し込み、組み込みの 「AnomalyDetection_SpikeAndDip」 / 「AnomalyDetection_ChangePoint」 で異常を検出するパターンです。

「温度が急上昇したらアラート」「振動値が緩やかに変化したら整備担当へ通知」といった監視ロジックを、機械学習モデルなしで書けるのが強みです。より高精度な異常判定が必要になったら、Azure MLで独自モデルを呼び出す形に発展できます。

車両・地理空間分析

車両管理や自動運転車両向けの位置情報ストリームを、リアルタイムに集計・可視化するパターンです。GPSデータをEvent Hubs経由で受け取り、ASAで地理空間関数を使って「特定エリア内の車両数」「配送遅延の予測」を算出、Power BIのマップにリアルタイム表示する構成が典型的です。

高価値資産のリモート監視と予測メンテナンス

タービン、機器、プラント設備といった高価値資産のリモート監視で、稼働ログをASAで処理して劣化トレンドを検出するパターンです。

「AnomalyDetection_ChangePoint」 で平均値の緩やかな変化を捉えれば、故障前の予兆を早期に検出でき、計画外停止のコストを削減できます。

クリックストリーム分析

Webサイトやアプリの操作ログを Event Hubs に流し、ASAで「直近5分のCV率」「ページ遷移パターン」をリアルタイムに集計するパターンです。マーケティング施策の効果をリアルタイムに可視化したい場面や、キャンペーン中の負荷監視で使われます。

アプリケーション・IoTテレメトリログの分析

アプリケーションや大量のIoTデバイスから発生するテレメトリログを ASA に集約し、監視ダッシュボードとアラート発報の基盤にするパターンです。

Azure Monitorと組み合わせて、「エラーレートが閾値を超えたら Teams に通知」「特定イベントの発生頻度で自動スケール」といった運用に接続できます。

IoT Edgeでのローカル実行

前述のとおり、ASA は IoT Edge 上でも同じクエリを実行できます。工場やビル管理で「クラウド接続が切れても現場でリアルタイム処理を継続したい」「機微データはクラウドに送らずエッジで完結させたい」といった要件がある場合、IoT Edge 対応が意思決定の分かれ目になります。

Fabric RTI には IoT Edge 対応がないため、この要件が明確なら ASA を第一候補として置く前提で設計が進みます。

Azure Stream Analytics導入で押さえる論点

ASAは触り始めのハードルは低い一方、本番運用に持ち込むと「なぜか SU 利用率が高い」「なぜか遅延が積み上がる」といった詰まりが発生しがちです。

ここでは、実装フェーズと運用フェーズで押さえておくべき論点を5つ整理します。

SU数の初期選定

一番よくある詰まりは、初期SUを過小に見積もることです。Microsoft公式のSUの説明ドキュメントによれば、「まず 1 SU V2 から開始し、代表的なデータ量を流したうえで SU% Utilization メトリクスを見て調整する」のが推奨アプローチです。

上の画面は Azure Portal 上で SU (Memory) % Utilization を単独グラフで表示している例です。実運用では、同じ画面から Input Events / Output Events / Watermark Delay 等の主要メトリクスを追加して同じ時間軸で比較し、以下の判断ラインに照らして SU 数の妥当性を決めていきます。

• SU% Utilization が 80%を超えたら SU 増強（急なスパイクへの耐性を残すため）
• 反対に、10〜20% 台で安定しているならオーバースペック（SU削減余地あり）
• 状態を持つクエリ（ウィンドウ集計・時間結合）は入力が減っても SU% が下がりにくい点に注意

本番投入前に、SU 利用率と backlogged events メトリクスに 80% のアラートを設定しておくと、突発的な負荷増でジョブが落ちる事故を防げます。

パーティション設計

クエリと処理パターンのセクションでも触れたとおり、大容量トラフィックでは Event Hubs のパーティション数と ASA の 「PARTITION BY」 を揃えることが必須です。

Event Hubs 側のパーティション数を少なめに設定してしまうと、ASA でいくら SU を増やしても並列化されず、パフォーマンスが頭打ちになります。設計フェーズで **Event Hubs のパーティション数を「想定最大 SU 数と揃える」**判断をしておくと、後から必要になる作業を減らせます。

Event Hubsのパーティション数変更ルールは Tier ごとに違います。

Standard 以下では作成後に変更できません。Premium / Dedicated では追加可能ですが減らせず、追加後にパーティションキーによるハッシュ配分が変わってクライアント側の順序性・再認識が影響を受けるため、後から増やすのはあくまで最終手段として設計を進めるのが実務的です。

ウォーターマーク遅延

遅れて到着するイベント（out-of-order events）の扱いは、リアルタイムクエリで最も見落とされがちな論点です。

ASAでは「遅延許容時間」を設定でき、この時間内に到着したイベントはウィンドウ集計に含めますが、超過したイベントは破棄またはエラールートに回されます。

センサー・IoTのように送信タイミングが不揃いなワークロードでは、この設定を短くしすぎると集計値が実態と乖離します。実装初期は「あえて長め」に設定して実運用でのイベント到着パターンを観察し、そこから最適値に絞り込む運用が現実的です。

状態サイズとメモリ

ウィンドウ集計や時間結合が入るクエリでは、内部で保持する「状態サイズ」がメモリ消費の主要因になります。GROUP BY 対象のカーディナリティ（一意ID数）が大きいと、状態サイズも比例して大きくなります。

対処策は、「PARTITION BY」 で並列化してノードあたりのカーディナリティを下げること。もう1つは、時間ウィンドウを不必要に長くしないこと。最大ウィンドウサイズ7日という上限も念頭に置いて設計します。

可用性ゾーンとリカバリー

本番運用では、可用性ゾーンとリージョン障害への耐性をどこまで設計するかを早い段階で決めておく必要があります。

Azure信頼性ドキュメントでは、可用性ゾーン対応リージョンでStream Analyticsが自動的にゾーン冗長になり、追加の構成やコストなしでゾーン障害から保護されると説明されています。一方、価格ページの機能表ではStandard V2の可用性ゾーン欄が「No」と残っており、両者に揺れがあります。

そのため、可用性ゾーンを条件に SKU 判断をする案件では、Microsoft サポート経由で現時点のリージョン別のゾーン冗長挙動を確認するのが安全です。「Standard V2 は可用性ゾーン非対応」と決め打ちで設計しないほうがよい状況です。

リージョン全体のインシデントに耐えるには、別リージョンに同一ジョブを配置するカスタムDR設計が別途必要になります。ASAはマネージドサービスとして99.9%の可用性が保証されていますが、これは「サービス全体としての稼働率」であって「単一リージョン障害での完全継続」を保証するものではありません。マルチリージョンでのフェイルオーバー手順、状態同期、入力側（Event Hubs / IoT Hub）の Geo-DR 設計も含めて、ジョブレベルの障害耐性を組む必要があります。

リアルタイム分析結果を業務アクションまで届けるなら

Azure Stream Analyticsでミリ秒レイテンシの検知・集計を組んでも、その結果をTeams上の承認・通知・顧客対応・チケット起票まで届けないと、「検知はしたが業務は動かない」構造で止まりがちです。ここには、業務エージェントの実行導線と権限・監査を一体で運用する基盤が要ります。

ここで効いてくるのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤 AI Agent Hub です。ASAやFabric RTIが生成したリアルタイム分析結果を、Teamsから呼び出す業務Agentに橋渡しし、権限・実行ログ・監査までを1つのプラットフォームで完結させます。

• ASAのリアルタイム分析結果をTeamsから業務アクションに接続
  ミリ秒レイテンシで検知した異常・閾値超過を、Teamsから呼び出す業務Agent(承認・通知・対応記録・チケット起票)に橋渡しします。「検知はしたが動かない」ギャップを業務Agentの実行導線として埋める設計です。
  
  
• Fabric RTI・ASA併用時のガバナンスを管理ダッシュボードで一元化
  Fabric側のno-code処理とASA側のSQL細粒度制御を組み合わせた構成でも、Agent単位のアクセス権限・不変の実行ログ・セキュリティスキャンを1画面に集約します。段階移行や並行運用のガバナンスを構造化できます。
  
  
• IoT Edge側の現場データを自社Azureテナント内Agentで受ける
  IoT Edge上のASAが返した現場の異常検知を、そのままAzureテナント内のAI Agent Hubへ流し、Teams上の担当者に即時通知と対応記録を残す設計です。設備データを社外に出さない前提を保ちながら業務側の自動化まで拡張できます。

AI総合研究所の専任チームが、Microsoft MVP・Solution Partner認定の実績をもとに、ASA・Fabric RTIとAgent Hubを組み合わせた業務設計から運用まで伴走支援します。AI Agent HubのLPで、リアルタイム分析結果を業務アクションまで届ける進め方をご確認ください。

リアルタイム検知を業務アクションへ

Teamsから承認・通知・監査までを一体運用

Azure Stream AnalyticsやFabric RTIが生成したリアルタイム分析結果を、Teams実行基盤・9種の業務Agent・管理ダッシュボードと組み合わせ、承認・通知・監査までを自社Azureテナント内で運用できるエンタープライズAIエージェント基盤です。

▶ ▶ AI Agent Hubの詳細を見る

まとめ｜Azure Stream Analyticsをどう選び、どう組み込むか

本記事では、Azure Stream Analyticsの位置づけ・主な機能・使い方・クエリ設計・Fabric Real-Time Intelligenceとの違い・V2料金体系・活用シーン・導入で押さえる論点を整理しました。

2026年時点のASA選定で押さえておくべきポイントは次の3つです。

• ASAはSQL細粒度制御とIoT Edge対応が残る強み — Trillベースのフルマネージド基盤で、SQL拡張クエリとPARTITION BYによる並列化がミリ秒運用の要になる
• 選定軸は「Azure PaaS単体 vs Fabricエコシステム」 — Fabric導入前提の新規基盤ならRTI、SQL細粒度制御やIoT Edgeが要件ならASAが第一候補
• V2 pricingは常時稼働ジョブほど有利 — 730／5840 SU時間の2段割引が効き、SU利用率80%以下の維持が実効単価を安定させる基本ライン
  
  

判断で迷うときは、まず「Fabricを主基盤にしていくか」を先に決めるのが実務的な順序です。Fabric導入プロジェクトが並走するならRTIへ寄せ、既存ASAは継続で問題ありません。SQL細粒度制御・IoT Edge・既存Azure PaaS統合が要件で残るなら、ASAを選び切ってV2の段階割引を活かす方向で組み立てます。

Azure Stream Analyticsは、Fabric時代でも「SQL細粒度制御」と「IoT Edge」に強みを残すAzureネイティブの選択肢です。用途を絞り込んで採用すれば、2026年後半以降も現役で戦えるストリーム処理サービスと言えます。