【Microsoft Fabric】Real-Time Intelligenceとは？機能や料金体系を徹底解説

Microsoft FabricのReal-Time Intelligence（リアルタイムインテリジェンス）は、IoTセンサー、アプリログ、業務イベントなどの「動いているデータ」を取り込み、即座に分析・可視化・アクション実行までを行うエンドツーエンドのリアルタイム分析基盤です。

本記事では、Eventhouse・Eventstream・KQLデータベースといった主要コンポーネントの役割から、Azure Data Explorerなど既存サービスとの違い、基本的な使い方、Fabric容量ユニット（CU）ベースの料金体系、導入時の注意点までを2026年3月時点の最新情報をもとに体系的に解説します。

✅Microsoft 365 Copilotの最新エージェント機能「Copilot Cowork」については、以下の記事をご覧ください。
Copilot Coworkとは？機能や料金、Claude Coworkとの違いを解説

Fabric Real-Time Intelligenceとは？

Real-Time Intelligence（リアルタイムインテリジェンス）は、Microsoft Fabricに統合されたリアルタイム分析のためのエンドツーエンド基盤です。

IoTセンサーのテレメトリ、アプリケーションログ、データベースの変更イベント、セキュリティログなど、絶え間なく流れ続ける「動いているデータ（data in motion）」を対象に、取り込み・変換・保存・クエリ・可視化・アラート発火までをFabric上で一貫して実行できます。

「リアルタイム」という名称ですが、毎秒数百万イベントの高速ストリームだけが対象ではありません。1日に数十件のイベントしか発生しないケースでも、「スケジュール実行（バッチ）ではなくイベント駆動で即座に処理したい」という要件があればReal-Time Intelligenceの適用範囲です。

リブランドの経緯

以前は「Real-Time Analytics」という名称で提供されていましたが、2024年中頃にReal-Time Intelligenceへリブランドされました。名称変更の背景には、単なるクエリ分析だけでなく、データの検出（Real-Time Hub）、可視化（リアルタイムダッシュボード）、アクション実行（Activator）までを含む包括的な機能群としての位置づけを明確にする意図があります。

2025年Q4には、Forrester Wave「Streaming Data Platforms」カテゴリで**リーダーに認定**されており、メッセージング、分析、ガバナンス、ビジネスユーザー体験の統合力が高く評価されています。

Fabricエコシステムの中での位置づけ

Microsoft Fabricは複数のワークロード（機能群）で構成されています。Real-Time Intelligenceがどの領域を担っているかを把握しておくと、他のワークロードとの使い分けが明確になります。

以下の表で、主要ワークロードの役割を整理しました。

つまり、Real-Time Intelligenceは**「動いているデータ」をリアルタイムに処理する専門ワークロード**です。蓄積済みデータのバッチ分析はLakehouseやData Warehouseが担い、Real-Time Intelligenceはストリーミングデータのイベント駆動処理を担当します。両者は排他ではなく、Eventhouseに取り込んだデータは、OneLake availabilityを有効にすることでOneLake経由でLakehouseやPower BIなど他のFabricワークロードからも参照できる設計になっています。

Fabric Real-Time Intelligenceの主要コンポーネント

Real-Time Intelligenceは、データの検出→取り込み→保存・分析→可視化→アクション実行という一連の流れを、以下のコンポーネントで実現しています。ここでは、各コンポーネントの役割と相互の関係を解説します。

Real-Time Hub

Real-Time Hubは、組織内のストリーミングデータを一元的に検出・管理するためのカタログです。

Real-Time Hubが管理する情報は、大きく3つに分かれます。

• データストリーム
  Fabric上でアクティブに実行されているすべてのストリーミングデータの一覧です。組織内の誰がどのようなリアルタイムデータを扱っているかを可視化できます。
  
  
• Microsoftソース
  Azure Event Hubs、Azure IoT Hub、Azure SQL DBのCDC（Change Data Capture：データベース変更のリアルタイム追跡）、Azure Cosmos DB CDC、PostgreSQL DB CDCなど、Microsoftのサービスからストリーミングデータを取り込むためのコネクタ群です。
  
  
• Fabricイベント
  Fabricワークスペース内のアイテムイベント（ジョブ完了やファイル変更など）やAzure Blob Storageイベントを監視できます。これらのイベントをトリガーとして、パイプラインの呼び出しや通知の送信といったアクションを起動できます。
  
  

Real-Time Hubのポイントは、データを「使える状態」にするだけでなく、権限のあるユーザーが参照できるテナント全体の論理ハブとして機能する点です。各ユーザーはアクセス権を持つイベントやストリームを発見・利用でき、データエンジニアが取り込みを設定すれば、適切な権限を付与されたビジネスアナリストがそのストリームを分析に活用できる、という協業が可能になります。

Eventstream

Eventstreamは、外部ソースからリアルタイムデータを取り込み、変換し、任意の宛先に送信するノーコードのデータパイプラインです。

対応ソースは以下のとおりです。

• クラウドメッセージングサービス
  Azure Event Hubs、Apache Kafka（Confluent含む）、Amazon Kinesis、Google Cloud Pub/Sub
  
  
• データベースCDC
  Azure SQL DB、Azure Cosmos DB、PostgreSQL、MySQL
  
  
• IoTプロトコル
  Azure IoT Hub、MQTT v3.1/v3.1.1対応ブローカー
  
  
• その他
  カスタムエンドポイント（接続文字列/Kafkaクライアント経由）、HTTPソース、サンプルデータ、Fabricワークスペースイベント
  
  

Eventstreamでは、取り込んだデータに対してフィルタリング、クレンジング、ウィンドウ集計、重複検出などの変換処理をノーコードで適用できます。さらに、コンテンツベースのルーティング機能で条件に応じて異なる宛先にデータを振り分けることも可能です。「派生ストリーム（Derived Stream）」機能を使えば、変換・集計の結果を新しいストリームとしてReal-Time Hubに公開し、他のユーザーと共有できます。

Eventstreamの内部にはAzure Event Hubsの名前空間が自動的にプロビジョニングされるため、Kafkaプロトコルを使った外部システムとの連携もそのまま利用できます。

Eventhouse

Eventhouseは、Real-Time Intelligenceにおけるストリーミングデータの分析エンジンです。Azure Data Explorer（ADX）と同じKustoエンジン上に構築されており、時系列データ・ログデータ・半構造化データの高速クエリに特化しています。

Eventhouseの特徴は以下のとおりです。

• KQLデータベースのコンテナ
  Eventhouseは1つ以上のKQLデータベースを格納するコンテナです。プロジェクト単位でEventhouseを作成し、その中に目的別のKQLデータベースを配置する構造になっています。
  
  
• オートスケール
  利用パターンに基づいて自動的にコンピュートサイズを調整します。負荷が低い時間帯にはリソースを縮小し、急増時には拡張するため、コストとパフォーマンスの最適化が自動で行われます。
  
  
• Auto-Stop
  一定時間アクティビティがないと自動的にサービスを停止し、CU消費を抑えます。再アクティベーション時には5〜10秒程度のレイテンシ（遅延）が発生します。
  
  
• OneLake連携（One Logical Copy）
  EventhouseのOneLake availabilityを有効にすると、格納データの論理コピー（logical copy）がOneLake上に作成され、LakehouseやPower BIなど他のFabricワークロードから参照可能になります。常時自動反映ではなく、明示的にOneLake availabilityを有効化する必要がある点に留意してください。
  
  
• ショートカット
  OneLake上の他のデータソース（LakehouseのDeltaテーブル、外部ストレージなど）をEventhouseからショートカット経由でクエリできます。データを物理的にコピーせずに、Eventhouseのクエリエンジンで外部データを分析できる仕組みです。
  
  

Eventhouseは、到着日時に基づく自動インデックスとパーティショニングにより、ペタバイト規模のデータに対しても秒単位のクエリ応答を実現します。

KQLデータベースとKusto Query Language

KQLデータベースは、Eventhouse内に配置されるデータの実体を保持する単位です。各KQLデータベースには複数のテーブルを格納でき、テーブルにはストリーミングイベントが蓄積されます。

データのクエリにはKQL（Kusto Query Language）を使用します。KQLは、時系列データや半構造化データの分析に最適化された直感的なクエリ言語です。

以下にKQLの基本的な構文例を示します。

// 直近1時間のエラーイベントを集計
Events
| where Timestamp > ago(1h)
| where Level == "Error"
| summarize ErrorCount = count() by Source
| order by ErrorCount desc

KQLに加えて、KQLデータベースではT-SQL（Transact-SQL）も利用可能です。ただし、KQLのほうが対応する機能が多く、パフォーマンスも優れているため、分析用途ではKQLの使用が推奨されています。

さらに、Kusto Copilot（AIアシスト）を使えば、自然言語で質問を入力するだけでKQLクエリを自動生成できます。KQLの経験がないビジネスユーザーでも、データ探索を始められるようになっています。

リアルタイムダッシュボード

リアルタイムダッシュボードは、Eventhouseに格納されたデータをKQLクエリベースで可視化するダッシュボードです。

Power BIレポートとは異なり、KQLクエリの結果をリアルタイムに反映するよう設計されており、自動更新間隔の設定やドリルダウン操作に対応しています。棒グラフ、折れ線グラフ、マップ、テーブルなど複数の可視化タイプが用意されており、フィルターやパラメータを組み込んだインタラクティブなダッシュボードを構築できます。

2026年時点では、Microsoft FabricのMap機能としてKQLクエリの結果を地理空間上にプロットする動的な地図表示が利用可能です。バブル、ヒートマップ、ポリゴン、3D浮き出し（extrusion）など複数のレイヤーに対応しており、物流やIoTの位置情報可視化に適しています。

なお、KQLクエリの結果はPower BIレポートのデータソースとしても利用できるため、リアルタイムダッシュボードで速報的な監視を行い、Power BIで詳細なビジネス分析を行う、という使い分けが可能です。

Fabric Activator

Fabric Activator（旧称Data Activator）は、データの変化をリアルタイムに監視し、条件に一致したときに自動的にアクションを実行するノーコードのイベント検知エンジンです。

Activatorは、Eventstream経由のストリーミングデータ、KQLクエリの結果、Power BIレポートの値など、さまざまなデータソースを監視対象にできます。特定のしきい値への到達、一定期間内のパターン繰り返し、KQLクエリで定義した複雑なロジックのいずれかを条件として設定し、条件成立時にMicrosoft Teams通知、メール送信、Power Automateフローの起動、Fabricパイプラインの実行などのアクションを発火させます。

Fabric内ではReflexアイテムとして管理され、定義・プロパティ・構成がReflexオブジェクトに格納されます。

Activatorの詳細な機能やアーキテクチャについては、今後公開予定の別記事で解説する予定です。本記事では、Real-Time Intelligenceの一部として「検知→アクション」を自動化するコンポーネントであるという位置づけを押さえておいてください。

Fabric Real-Time IntelligenceとAzureサービスの違い

Real-Time Intelligenceと同等の機能は、Azure Data Explorer（ADX）やAzure Stream Analyticsなど個別のAzure PaaSサービスを組み合わせて構築することもできます。ここでは、両者の違いを整理し、どちらを選ぶべきかの判断基準を解説します。

Azure PaaS構成との機能比較

以下の表で、Azure PaaS構成とReal-Time Intelligence構成の違いを整理しました。

ここで注目すべきは、Real-Time Intelligenceがノーコードでエンドツーエンドのリアルタイム分析基盤を構築できる点です。Azure PaaS構成では、Event Hubs → Stream Analytics → ADX → Power BIといった複数サービスの連携を個別に設計・実装する必要がありますが、Real-Time IntelligenceではEventstream → Eventhouse → リアルタイムダッシュボードをFabricポータル上でシームレスに接続できます。

Azure Data Explorer（ADX）との関係

EventhouseはADXと同じKustoエンジンを基盤としています。KQLの構文やデータ管理のポリシー（キャッシュポリシー、リテンションポリシーなど）はADXと共通しており、ADXの知識はそのままEventhouseでも活用できます。

一方で、以下の違いがあります。

• 課金モデル
  ADXは専用クラスターの時間課金（仮想マシンベース）です。Real-Time IntelligenceはFabric CUの共有課金であり、他のFabricワークロードとCUを共有できます。
  
  
• 統合範囲
  ADXは分析エンジン単体です。Real-Time IntelligenceはEventstream（取り込み）、Real-Time Hub（検出）、ダッシュボード（可視化）、Activator（アクション）を含む統合基盤です。
  
  
• Python UDF
  ADXではPython UDF（ユーザー定義関数）のインライン実行がネイティブにサポートされています。Fabric Eventhouseでもpythonプラグインは利用可能ですが、既定では無効であり、有効化には追加CUコストとサンドボックス制約が伴います。頻繁なPython実行が必要な場合はADXのほうが制約が少ないです。
  
  

ADXからFabric Eventhouseへの移行ガイドが公式に提供されており、段階的な移行が可能です。既存のADXクラスターをショートカット経由でEventhouseから参照し、並行運用しながら段階的にデータを移行する方法も選択できます。

AI導入でお悩みの方へ

AI総合研究所が最適なAI選定をサポート

どのAIツールを選べばいいかわからない、導入コストが心配など、AI導入に関するあらゆるお悩みを専門家が解決します。

▶ 無料で相談する

Fabric Real-Time Intelligenceの使い方

Real-Time Intelligenceの基本的な利用の流れは、Eventhouseの作成 → Eventstreamによるデータ取り込み → KQLクエリでの分析 → リアルタイムダッシュボードでの可視化という4ステップです。ここでは、各ステップの手順と操作のポイントを解説します。

Eventhouseの作成

まず、データの格納先となるEventhouseを作成します。

Fabricポータルで、ワークスペース内から「新しいアイテム」→「Eventhouse」を選択し、名前を指定して作成します。Eventhouseを作成すると、同名のKQLデータベースが自動的に1つ作成されます。

作成後のシステム概要ページでは、以下の情報を確認できます。

• Eventhouseの詳細（ストレージ使用量、システムリソース、コンピュート使用量）
• インジェストレート（取り込み速度）
• 上位クエリデータベース（最もクエリが多いデータベース）
• 上位取り込みデータベース（最もデータ取り込みが多いデータベース）

Eventstreamでのデータ取り込み

次に、Eventstreamを作成してデータソースを接続します。

Fabricポータルで「新しいアイテム」→「Eventstream」を選択して作成した後、ソースの追加を行います。主な操作手順は以下のとおりです。

• ソースの選択
  Azure Event Hubs、Kafka、IoT Hub、カスタムエンドポイントなどからデータソースを選択します。サンプルデータソースを使えば、テストデータで動作確認ができます。
  
  
• 変換の適用（任意）
  必要に応じて、フィルター・集計・重複除去などの処理ノードを追加します。ドラッグ&ドロップのビジュアルエディタで操作でき、コーディングは不要です。
  
  
• 宛先の設定
  Eventhouse（KQLデータベース）を宛先として指定します。Lakehouse、カスタムエンドポイントなども宛先に選択できます。
  
  

Eventstreamでは、取り込みの状態がリアルタイムで確認できるモニタリング画面が用意されています。スループット（処理速度）やイベント数の推移をグラフで把握できるため、取り込みが正常に動作しているかを即座に判断できます。

KQLクエリの実行

データがEventhouseに取り込まれたら、KQLクエリセットを使ってデータを分析します。

KQLデータベースを選択すると、ブラウザ上のクエリエディタが開きます。以下は基本的なクエリのパターンです。

// テーブル内のデータ件数を確認
MyTable
| count

// 直近24時間のデータを時系列でグラフ化
MyTable
| where ingestion_time() > ago(24h)
| summarize EventCount = count() by bin(Timestamp, 5m)
| render timechart

// 異常検知（組み込み関数）
MyTable
| where ingestion_time() > ago(7d)
| make-series Value = avg(SensorValue) on Timestamp step 1h
| extend anomalies = series_decompose_anomalies(Value)

KQLに不慣れな場合は、Kusto Copilotを活用できます。「直近1時間でエラー率が最も高いサービスを教えて」のような自然言語の質問を入力すると、AIがKQLクエリを自動生成してくれます。

リアルタイムダッシュボードの構築

最後に、KQLクエリの結果をリアルタイムダッシュボードで可視化します。

KQLクエリセットからクエリ結果を「ダッシュボードにピン留め」する操作で、視覚化タイルをダッシュボードに追加できます。主な操作ポイントは以下のとおりです。

• 自動更新間隔の設定
  ダッシュボードの自動更新間隔を最短10秒から設定できます。
  
  
• パラメータとフィルター
  日時範囲やカテゴリなど、ユーザーが動的に切り替えられるフィルターを追加できます。
  
  
• 共有
  ダッシュボードはワークスペース内の他のユーザーと共有でき、閲覧権限の管理が可能です。
  
  

リアルタイムダッシュボードはEventhouseのデータに対してKQLクエリを実行するため、データの遅延が最小限に抑えられます。ストリーミングデータの監視・運用モニタリングには、Power BIよりもリアルタイムダッシュボードが適しています。

Fabric Real-Time Intelligenceの活用シーン

Real-Time Intelligenceは、イベント駆動のリアルタイム処理が求められるあらゆる業界・業務で活用できます。ここでは、代表的なユースケースとバッチ処理との使い分けの考え方を解説します。

業界別のユースケース

以下の表で、主要な活用シーンを業界別に整理しました。

これらのシナリオに共通するのは、「データの発生から分析結果の取得までの時間（レイテンシ）を最小化したい」という要件です。バッチ処理では数分〜数時間かかる分析を、Real-Time Intelligenceではイベント発生から数秒〜数十秒で実行できます。

バッチ処理との使い分け

Real-Time Intelligenceは万能ではなく、バッチ処理のほうが適しているケースもあります。

以下の表で、使い分けの判断基準をまとめました。

実務では、ストリーミングデータをEventhouseでリアルタイム監視しつつ、同じデータをOneLake経由でLakehouseに蓄積し、長期的な傾向分析はバッチ処理で行う、というハイブリッド構成が一般的です。Real-Time IntelligenceのOne Logical Copy機能により、データを二重に持つ必要がないため、このハイブリッド構成のコストと管理負荷は最小限に抑えられます。

【関連記事】
Microsoft Fabric導入事例6選！国内企業の成果と導入パターンを解説

Fabric Real-Time Intelligenceの料金体系

Real-Time Intelligenceの料金は、Microsoft Fabricの容量ユニット（CU：Capacity Unit）ベースの統一課金モデルに従います。ここでは、Eventhouseのコンピュート課金、Eventstreamの課金、ストレージ課金の3つの軸で料金の仕組みを解説します。

Eventhouseのコンピュート課金（Eventhouse UpTime）

Eventhouseのコンピュート消費は、Eventhouse UpTimeと呼ばれる指標で計測されます。

Eventhouse UpTimeの計算式は以下のとおりです。

Eventhouse UpTime（CU秒） = 仮想コア数 × アクティブ秒数

たとえば、4つの仮想コアを使用するEventhouseが30秒間アクティブだった場合、消費されるCUは120 CU秒になります。

重要なポイントは以下のとおりです。

• オートスケール
  仮想コア数は利用パターンに基づいて自動的に調整されます。CPU使用率やキャッシュ利用量に応じてスケールアップ/ダウンするため、手動でのサイズ管理は不要です。
  
  
• Auto-Stop（デフォルト動作）
  一定期間アクティビティがないとEventhouseは自動停止し、UpTimeの課金が止まります。再起動時に5〜10秒のレイテンシが発生します。
  
  
• Always-On
  時間に敏感なシステムではAlways-Onを有効にすることで、サービスを常時稼働させられます。Always-On有効時は100%のUpTime課金になりますが、OneLake Cache Storage（キャッシュストレージ）の課金が免除されるため、キャッシュ使用量が多い場合はトータルコストが下がる可能性があります。
  
  
• Minimum Consumption（最小容量設定）
  Always-Onのサブ設定として、オートスケールの下限を固定できます。急な負荷増大に備えて最低限のコンピュートリソースを確保しておく用途に使います。
  
  

以下の表で、Minimum Consumption設定ごとの無料SSD容量を整理しました。

この表から分かるとおり、CU数が大きいほど無料で利用できるSSD容量が増えます。キャッシュに格納するデータ量に応じてMinimum Consumptionを設定することで、ストレージコストとコンピュートコストのバランスを最適化できます。

Eventstreamの課金

Eventstreamは、以下の4つのメーターでCU消費が計測されます（2026年3月時点）。

• Eventstream Per Hour
  Eventstreamが稼働している時間に対する基本課金です。0.222 CU時間/時が課金されます。
  
  
• Eventstream Data Traffic Per GB
  ストリームの入出力データ量に対する課金です。0.342 CU時間/GBが課金されます。24時間のデータ保持が含まれます。
  
  
• Eventstream Processor Per Hour
  変換処理やルーティング処理に対する課金です。0.778 CU時間/時から開始し、スループットに応じて最大2倍までオートスケールします。
  
  
• Eventstream Connectors Per vCore Hour
  Azure SQL DBやCosmos DBなどのコネクタベースのソースに対する課金です。0.611 CU時間/vCoreが課金されます。
  
  

実際のコスト感として、パススルー（変換なし）で1日1GBのデータを取り込む場合は約0.25 CU/時間、コネクタ＋ルーティング処理で1日1GBの場合は約2.42 CU/時間が目安です。

ストレージ課金

Eventhouseのストレージは、Fabric CUとは別枠で課金されます。2階層のストレージで構成されています。

• OneLake Cache Storage（キャッシュストレージ）
  高速クエリ応答を実現するプレミアムストレージです。キャッシュポリシーで保持期間を設定し、「直近7日間のデータをキャッシュに置く」といった運用が可能です。Azure Data Lake Storage（ADLS）のプレミアム層に相当します。
  
  
• OneLake Standard Storage（標準ストレージ）
  全クエリ対象データを永続化するストレージです。リテンションポリシー（データ保持期間）で保存期間を管理します。ADLS Hotに相当します。
  
  

Always-Onを有効にすると、キャッシュストレージの課金が免除され、コンピュートのUpTime課金に含まれる形になります。大量のキャッシュデータを保持する場合は、Always-Onの有効化がコスト面で有利になるケースがあります。

具体的な料金単価はFabric Capacity Estimatorで確認できます。

【関連記事】
Microsoft Fabricとは？使い方や価格体系、できることを徹底解説！

AI導入でお悩みの方へ

AI総合研究所が最適なAI選定をサポート

どのAIツールを選べばいいかわからない、導入コストが心配など、AI導入に関するあらゆるお悩みを専門家が解決します。

▶ 無料で相談する

Fabric Real-Time Intelligenceの注意点と制限事項

Real-Time Intelligenceを導入する際に事前に把握しておくべき注意点と制限事項をまとめます。

KQLの学習コスト

Eventhouseの分析能力を最大限に活用するには、KQL（Kusto Query Language）の習得が必要です。SQLに似た宣言型の言語ですが、パイプ演算子（|）を軸にした独自の構文体系を持っており、SQL経験者でも一定の学習期間が求められます。

ただし、以下の手段で学習負荷を軽減できます。

• Kusto Copilot
  自然言語からKQLクエリを生成するAIアシスタントがネイティブに利用可能です。
  
  
• T-SQLサポート
  KQLデータベースではT-SQLも利用可能です。完全なKQLの機能には及びませんが、SQL経験者が段階的にKQLに移行する際の橋渡しとして機能します。
  
  
• ノーコードの可視化ツール
  データプロファイリングビューやドラッグ&ドロップの探索機能で、クエリを書かずにデータの概要を把握できます。
  
  

Python UDFの制限

Fabric EventhouseでもPythonプラグインは利用可能ですが、既定では無効になっており、有効化には追加のCUコストが発生します。また、SSDキャッシュの再読み込みやサンドボックス環境の制約があるため、ADXのPython UDFと完全に同等ではありません。Pythonベースの高度な異常検知モデルやカスタム分析をKQLクエリ内で頻繁に実行する要件がある場合は、コストと制約を踏まえたうえで有効化するか、ADXの併用を検討してください。

スロットリング（処理制限）

Fabricの容量上限に到達すると、Eventhouseにスロットリングが適用されます。3段階のレベルがあります。

• Proactive（予防的制限）
  クエリが制限されますが、データの取り込みは継続します。
  
  
• Reactive（対応的制限）
  取り込みとクエリの両方が一時停止しますが、データの欠損は発生しません。
  
  
• Extreme Reactive（緊急制限）
  取り込みとクエリが停止し、一定期間後にデータが失われる可能性があります。
  
  

スロットリングが頻発する場合は、Fabric容量のSKUアップグレード（F2→F4→F8…）が必要です。Fabric Capacity MetricアプリでCU使用率を常時モニタリングし、100%に近づく前に対処することが推奨されます。

Activatorとの棲み分け

Real-Time Intelligence内のActivator機能は、リアルタイムダッシュボードやKQLクエリの結果からアラートを発火する用途に適しています。一方で、Activator自体は単独のFabricアイテムとしても利用でき、Power BIセマンティックモデルの監視やFabricワークスペースイベントへの反応など、RTI以外のシナリオでも活用されます。

RTI記事としては「Eventhouseのデータに対するアラート」にフォーカスし、Activator全体の詳細は別記事で解説する予定です。

デジタルツインビルダー（プレビュー）

2026年3月時点でプレビュー段階の機能として、デジタルツインビルダーが提供されています。物理環境のデジタルツイン（デジタル上の再現モデル）をローコード/ノーコードで構築し、さまざまなデータソースからオントロジー（概念の関係性モデル）にマッピングできます。製造業のプラントや物流の拠点管理など、物理資産のリアルタイム最適化を目指す機能ですが、プレビューのため本番運用には制約がある点に留意してください。

【関連記事】
Fabric IQとは？AI連携を強化する新機能を徹底解説

データ基盤構築のご相談はAI総合研究所へ

Microsoft Fabricをはじめとするデータ基盤の構築・移行を検討中の方に、AI総合研究所ではデータ収集から可視化・AI活用・運用まで一気通貫で支援しています。

• マルチプラットフォーム対応
  Microsoft Fabric、Snowflake、Databricks、AWS、GCPなど、ビジネス要件に最適なデータプラットフォームを選定・構築
  
  
• データパイプライン・ETL構築
  Azure Data Factory、dbt、Airflowを用いたETL/ELTパイプラインの設計・実装。データの収集・変換・統合を自動化
  
  
• AI-Ready Data構築
  AIモデルの学習・推論に最適化されたデータ形式への変換、品質管理、特徴量エンジニアリングまで対応
  
  
• 運用・ガバナンス整備
  Microsoft Purviewによるデータカタログ・系譜管理、監視体制の構築、継続的なパフォーマンス改善をサポート

まずは無料相談で、貴社のデータ基盤についてお気軽にご相談ください。

データ基盤構築の無料相談はこちら

まとめ

Fabric Real-Time Intelligenceは、Microsoft Fabricに統合されたイベント駆動型のリアルタイム分析基盤です。IoTテレメトリ、アプリケーションログ、データベースCDCなど、あらゆるストリーミングデータを対象に、取り込みから分析・可視化・アクション実行までをFabric上で一貫して処理できます。

本記事で解説した内容のポイントは以下のとおりです。

• 主要コンポーネント（Real-Time Hub、Eventstream、Eventhouse、KQLデータベース、リアルタイムダッシュボード、Activator）が連携し、データの検出→取り込み→分析→可視化→アクションの一連のフローを実現
• EventhouseはAzure Data Explorerと同じKustoエンジンを基盤とし、ペタバイト規模のデータに対する秒単位のクエリ応答を提供
• Azure PaaS構成と比較して、ノーコードでの構築、マルチクラウドコネクタ、統一課金モデルが差別化ポイント
• 料金はFabric CUベースで、Eventhouse UpTime（コンピュート）とOneLakeストレージの2軸で課金。Always-On設定でキャッシュストレージを免除できる
• 製造業・金融・小売・セキュリティなど幅広い業界で活用でき、Forrester Wave 2025でリーダーに認定

まずはFabric Trial容量でEventhouseを作成し、サンプルデータを使ったKQLクエリの実行とリアルタイムダッシュボードの構築を試してみることをお勧めします。ストリーミングデータを活用したリアルタイム分析が、既存のバッチ分析にどのような付加価値をもたらすかを実際に体感できます。

AI総合研究所は企業のMicrosoft Fabric導入支援を手がけており、Real-Time Intelligenceの活用に関するご相談も承っております。ぜひお気軽にお問い合わせください。

お問い合わせはこちら