ここまでの第1〜3回で、Fabricの「集める→整える→可視化する」という王道の流れを一周しました。今回はそこから一歩進んで、少し毛色の違う2つのテーマを扱います。ひとつは「止まっているデータ」ではなく「今まさに流れているデータ」を扱うリアルタイム分析。もうひとつは、2026年のFabric最大のトピックであるAI連携——データに自然言語で質問する Data Agent です。オーナーの関心領域である「AI×クラウド」がFabric上でどう形になるか、ここで見えてきます。
リアルタイム分析ってKQL？聞いたことはあるけど身構える。あとFabricで「データに質問できるAI」って、あれRAGとは別物なの？
この記事は、Fabricシリーズの第4回として、次の2つを整理します。
- Real-Time Intelligence（Eventstream→KQLデータベース）を理解している
- Fabric の Data Agent（データに自然言語で問い合わせるAI）を理解している
Real-Time Intelligence｜流れているデータを分析する
これまで扱ってきたのは、レイクハウスやウェアハウスに「溜まった」データでした。しかし世の中には、IoTセンサーの測定値・アプリのログ・Webサイトのクリックのように、絶え間なく「流れ続けている」データがあります。これを止めて溜めてから分析するのでは遅く、流れているそばから分析したい——そのためのワークロードが Real-Time Intelligence です。
Real-Time Intelligenceとは、IoT・ログ・クリックストリームなど「動いているデータ（data in motion）」を、到着したそばから取り込み・分析・可視化・アクションまで行うためのワークロードです。
基本の流れは Eventstream（取り込み）→ KQLデータベース（格納）→ KQL（分析） の3段です。順に見ていきましょう。
【リアルタイム分析の基本フロー】
データソース Eventstream KQL Database
┌────────────┐ ┌──────────┐ ┌────────────┐
│ IoTセンサー │ ──► │ 取り込み │ ──► │ 格納 │
│ アプリログ │ │ ・変換 │ │ （高速検索） │
│ クリック │ │ ・振り分け │ └────────────┘
└────────────┘ └──────────┘ │
KQLで分析
リアルタイムダッシュボード- Eventstream（イベントストリーム）：流れてくるデータの入口。Azure Event Hubs・IoT Hub、各種DBの変更（CDC）などをノーコードで繋いで取り込み、必要なら変換して振り分けます。
- KQLデータベース：取り込んだデータの格納先。ログや時系列データの高速検索に特化したデータベースです。膨大なログから一瞬で必要な行を絞り込めます。
- KQL（Kusto Query Language）：KQLデータベースを問い合わせる言語。SQLに似た書き心地で、時間フィルタや時系列集計が得意です。Azure MonitorやApplication Insightsのログ分析でも使われる言語なので、ここで学ぶと監視のスキルにも直結します。
ポイントは、「溜めてから分析（バッチ）」ではなく「流しながら分析（ストリーム）」という発想の切り替えです。異常値を検知したら即アラートを飛ばす、といったリアルタイムのアクションまで繋げられるのがこのワークロードの強みです。なお、このKQLでの時系列・ログ分析の考え方は、そのままAzureの監視（KQL / Application Insights）にも通じます——監視の深掘りを課題に感じている方には、リアルタイム分析は一石二鳥の学習テーマです。
【ここが説明できればOK①】
「Real-Time Intelligenceは、Eventstreamで流れるデータを取り込み、KQLデータベースに格納し、KQLで時系列分析する。溜めてからではなく流しながら分析するワークロード」——これを説明できれば、1つ目のチェックはクリアです。
Fabric Data Agent｜データに「自然言語」で質問する
ここからが2026年の目玉です。これまで見てきたデータ分析は、SQLやDAX、KQLといったクエリを自分で書くことが前提でした。Data Agent は、その前提そのものを取り払います。
Fabric Data Agentとは、OneLake上のデータに対して「普通の言葉（自然言語）」で質問すると、AIが適切なクエリを自動生成して答えを返してくれる、会話型のQ&Aエージェントです。2026年時点で一般提供（GA）されています。
たとえば「今月、最も売上が伸びた地域はどこ？」と日本語（ベータ時点では英語推奨）で聞くと、Data Agentが対象データを判断し、裏でクエリを生成・実行して、表や要約で答えを返します。利用者はSQLもDAXもKQLも書く必要がありません。技術者でない人でも、データに直接問いかけられるようになる——これがData Agentの狙いです。
仕組みを、少しエンジニア目線で分解しておきましょう。Data Agentは内部で Azure OpenAIのAssistant API を使い、次のように動きます。
【Data Agentの内部動作】
ユーザーの質問（自然言語）
「今月いちばん売れた地域は？」
│
▼
① どのデータソースに聞くか判断
（最大5つ：レイクハウス/ウェアハウス/
KQL DB/Power BIセマンティックモデル 等）
│
▼
② 対象に応じてクエリを自動生成
・レイクハウス/ウェアハウス → NL2SQL（→ SQL）
・Power BIモデル → NL2DAX（→ DAX）
・KQLデータベース → NL2KQL（→ KQL）
│
▼
③ クエリを検証して「読み取り専用」で実行
│
▼
人が読める答え（表・要約）を返すここで押さえたい実務ポイントが3つあります。
- 読み取り専用：生成されるのは参照（SELECT系）クエリだけ。データを作成・更新・削除するクエリは原理的に生成されません。「AIが勝手にデータを書き換える」心配がない設計です。
- 権限とガバナンスを尊重：質問したユーザー自身の権限で動くため、その人が見られないデータは返しません。さらにPurviewの機密ラベルやDLPポリシーも効きます。「AIだから全部見えてしまう」という事故を防ぐ、最小権限の作りです。
- 設定と育成ができる：Power BIレポートを作るのと同じ感覚で、対象テーブルの指定・独自の指示・例示クエリを与えて精度を上げられます。「財務の質問はこのモデルに」「ログ分析はこのKQL DBに」といった振り分けルールも仕込めます。
「自然言語→SQL/DAX/KQLに翻訳して、読み取り専用で、ユーザー権限とPurviewを守って実行」。ガードレールがしっかりしてるのが実務で効くポイントだね。
Copilotとの違いも整理しておきましょう。CopilotはFabric内の作業補助（ノートブックのコード生成など）で、あらかじめ用意されたアシスタントです。一方 Data Agent は、自分で設定して育てる独立した成果物で、OneLake全体のデータを横断して問い合わせられます。しかもMicrosoft 365 CopilotやAzure AI Foundry、Teamsといった外部からも呼び出せるため、より大きなエージェント型アプリの「会話でデータに答える部品」として組み込めます。ここがオーナーの手がけるAI×クラウドの実装と直結する部分です。
なお、Data Agentは会話でのインサイト取得が目的のため、返す行数は最大25行×25列に制限されます（全件出力の道具ではない）。また現時点では英語が最適で、PDFなどの非構造化データは対象外、といった制約もあります。「完全なデータ抽出ツール」ではなく「データと会話する窓口」と捉えるのが正確です。
【ここが説明できればOK②】
「Data Agentは、OneLake上のデータに自然言語で質問するとAIがSQL/DAX/KQLを自動生成して答えるQ&Aエージェント（GA）。読み取り専用・ユーザー権限とPurviewを尊重し、最大5データソースを対象に設定・育成できる」——これを説明できれば、2つ目のチェックはクリアです。
まとめ
今回は「流れるデータ」と「データに問うAI」という、Fabricの発展的な2テーマを整理しました。
- Real-Time Intelligence：Eventstream→KQLデータベース→KQLで、流れているデータをリアルタイム分析（KQLは監視スキルにも直結）
- Data Agent：自然言語で質問→AIがSQL/DAX/KQLを自動生成、読み取り専用・権限とPurview準拠で答える会話型AI（GA）
- Data Agentは外部（M365 Copilot・AI Foundry等）からも呼べる、エージェント型アプリの「データ回答部品」
いよいよ次が最終回です。第5回では、ここまで作ってきた分析基盤を「安全に・継続的に・コストを管理して運用する」ための3テーマ——容量（F SKU）とコスト管理・Git統合とデプロイパイプライン・閉域とガバナンスを整理し、シリーズを締めくくります。
