Microsoft FabricのOperations Agentsは、Real-Time Intelligence上でリアルタイムデータを監視し、Teams経由で推奨アクションを提示するプレビュー機能です。結論から言うと、2026年5月18日の公式更新は「すぐ本番移行すべき新機能の正式リリース」ではなく、作成・設定手順とUI案内を確認し直すべき更新と捉えるのが安全です。管理者はCopilot/Azure OpenAI関連のテナント設定、容量、リージョン、権限、Power Automate連携を確認し、開発者はEventhouseやOntologyのデータ設計とプレイブック検証を必ず行う必要があります。(Microsoft Learn)
Microsoft Fabric Operations Agentsとは
Microsoft Fabric Operations Agentsは、Fabric Real-Time Intelligenceで使うAIベースの運用エージェントです。EventhouseやOntologyなどのデータソースをもとに、在庫不足、設備異常、遅延、しきい値超過などの状態を継続的に監視し、必要に応じてTeamsで要約と推奨アクションを通知します。各Operations Agentは、特定の業務プロセス向けに作成するFabricアイテムとして扱われます。(Microsoft Learn)
重要なのは、Operations Agentsが単なるアラート機能ではない点です。管理者や作成者が「業務目標」「指示」「データソース」「実行可能なアクション」を設定すると、エージェントはそれらをもとにプレイブックを生成し、監視対象の概念、データ項目、ルール、条件を整理します。つまり、KQLクエリやルールを人が一から書くだけでなく、AIが運用ルール作成を支援する仕組みです。(Microsoft Learn)
ただし、現時点ではプレビュー機能です。Microsoft Fabricのプレビュー機能は、正式な本番利用を前提にしたSLA付き機能ではなく、機能制限や地域制限がある可能性があります。本番業務に近い用途で試す場合は、検証環境、承認フロー、手動監視との併走を前提にするべきです。(Microsoft Learn)
2026年5月18日の公式更新で何が変わるのか
公式Learnページ「Create and configure operations agents」は、2026年5月18日に更新されています。GitHub上の該当履歴を見ると、同日の更新は「Operations Agent – Fixed images」を含むPRで、本文の大幅な仕様変更というより、スクリーンショットやUI表記の修正が中心です。したがって、今回の更新を「機能がGAになった」「権限モデルが変わった」と解釈するのは避けるべきです。(Microsoft Learn)
一方で、2026年4月から5月にかけて、Ontology利用時の前提、KQL databaseがEventhouse利用時に必要であること、Teams通知は追加アクションを定義しなくても使えることなど、運用判断に関わる説明も整理されています。管理者や開発者は、UIの場所だけでなく「どのデータソースを使えるのか」「どの権限で実行されるのか」「通知後の承認は誰が担うのか」を見直す必要があります。(GitHub)
| 確認項目 | 公式情報で押さえる点 | 実務への影響 |
|---|---|---|
| 更新日 | Learnページは2026年5月18日に更新 | 最新UIで作成手順を再確認する |
| 機能状態 | Operations Agentsはプレビュー | 本番全面展開ではなく段階導入が前提 |
| データソース | EventhouseまたはOntologyを利用 | KQL databaseやOntology配置を事前確認する |
| 通知先 | Teamsアプリで推奨アクションを受信 | 現場担当者のTeams利用と権限が必要 |
| 実行権限 | 作成者の委任IDと権限で動作 | 作成者アカウントの権限管理が重要 |
| アクション | Power Automate連携が可能 | 外部システム連携はフロー設計が必要 |
利用前に満たすべき前提条件
Operations Agentsを作成する前に、まず環境要件を確認します。公式ドキュメントでは、Fabric対応容量を持つワークスペース、EventhouseまたはOntology、Eventhouseを使う場合のKQL database、Microsoft Teamsアカウント、Operations AgentプレビューとMicrosoft Copilot/Azure OpenAIに関する管理者権限が前提として示されています。Trial容量はサポート対象外です。(Microsoft Learn)
特に見落としやすいのは、AI関連のテナント設定です。Fabric data agent関連の設定では、CopilotとAzure OpenAI Serviceを利用するためのテナントスイッチ、Copilot容量の指定、リージョン外での処理や保存に関する設定が必要になる場合があります。設定を有効にしても反映まで最大1時間かかる可能性があるため、検証当日に初めて有効化する運用は避けたほうが安全です。(Microsoft Learn)
| 担当者 | 事前に確認すべきこと |
|---|---|
| Fabric管理者 | プレビュー機能、Copilot/Azure OpenAI、クロスジオ処理・保存のテナント設定 |
| 容量管理者 | Fabric対応容量、Trial容量ではないこと、容量のリージョン |
| ワークスペース管理者 | Eventhouse、KQL database、Ontologyの配置とアクセス権 |
| 開発者 | Power Automateフロー、Activator、外部システム連携の設計 |
| 運用担当者 | Teamsアプリの利用、通知先、承認・却下の運用ルール |
Operations Agentsの作成と設定の流れ
Operations Agentの作成は、Fabricホームから「Create」を開き、Real-Time Intelligenceセクションで「Operations agent」を選択し、名前と作成先ワークスペースを指定する流れです。作成後はAgent setupで業務目標、具体的な指示、データソース、アクションを設定します。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 作成 | FabricのCreateからOperations agentを作成 | 検証用ワークスペースから始める |
| 業務目標の設定 | エージェントが達成すべき目的を書く | 「欠品を防ぐ」「遅延を検知する」など業務目的を明確にする |
| 指示の設定 | 判断条件や優先順位を記述 | 曖昧な表現ではなく数値条件を使う |
| データソース選択 | EventhouseまたはOntologyを指定 | 監視対象のテーブル・エンティティが適切か確認する |
| アクション定義 | Teams通知やPower Automate連携を設定 | 承認者、入力パラメーター、失敗時対応を決める |
| プレイブック確認 | 保存後に生成されたルールを確認 | 列名・プロパティ名・条件が意図どおりか確認する |
| 開始 | Startで監視を開始 | 初期期間は人手監視と併走する |
設定後に保存するとプレイブックが生成されます。プレイブックには、エージェントが監視する概念、データ項目、ルール、条件が表示されます。ここで必ず確認したいのが、元データの列と表示されるプロパティの対応です。公式ドキュメントでも、ルール確認時にプロパティ名が表示され、基になる列名とは異なる場合があるため、モデルとルールが要件に合っているか確認する必要があると説明されています。(Microsoft Learn)
指示文は「英語」「数値条件」「分離」が基本
Operations AgentsはLLMを利用してプレイブックや推奨アクションを生成します。そのため、指示が曖昧だと、現場が期待する監視条件とずれる可能性があります。公式の制限事項では、現時点でGoalsとInstructionsは英語のみ対応とされています。日本語環境で使う場合でも、エージェントへの指示自体は英語で書く前提で設計しましょう。(Microsoft Learn)
悪い例は「在庫が少ないときに通知する」のような表現です。この指示では、何個未満なら少ないのか、どの倉庫を対象にするのか、通知だけでよいのか、補充依頼まで行うのかが不明です。
より実務向けには、次のように書きます。
Operational goal:
Maintain enough inventory for each warehouse.
Rules:
1. Notify the operations team when available_stock is less than 20 for any SKU.
2. Recommend a replenishment action when available_stock is less than 10 and incoming_stock is 0.
3. Prioritize warehouse_id, sku_id, available_stock, and last_updated_time in the notification.
Semantic instructions:
- Each inventory item is identified by sku_id.
- Each warehouse is identified by warehouse_id.
- available_stock represents the current sellable quantity.
- incoming_stock represents the quantity expected to arrive within the next 24 hours.このように、業務ルールとデータ項目の意味を分けて書くと、エージェントが監視対象を解釈しやすくなります。公式のベストプラクティスでも、定性的な表現ではなく数値しきい値を使うこと、複数ルールを別行に分けること、優先度の高いルールを先に書くことが推奨されています。(Microsoft Learn)
EventhouseとOntology利用時の注意点
EventhouseをOperations Agentsのデータソースにする場合は、テーブル設計が結果の品質に直結します。JSONのような入れ子列がある場合は、事前にフラット化しておくのが基本です。列名だけで意味が分かりにくい場合は、KQLテーブルスキーマのdescriptionフィールドで平易な説明を追加すると、エージェントが値の意味を解釈しやすくなります。(Microsoft Learn)
また、監視対象となる業務オブジェクトを一意に識別する列を明確にする必要があります。たとえば、センサー監視ならSensorID、設備監視ならMachineID、在庫監視ならSKUやWarehouseIDが該当します。列名にアンダースコアやハイフンなどの特殊文字が含まれる場合は、ルール内で引用符を使って明示することも重要です。(Microsoft Learn)
Ontologyを使う場合は、Operations Agentと同じワークスペースに配置する必要があります。さらに、監視対象のOntologyエンティティには識別子として使える静的プロパティが少なくとも1つ必要です。Ontology監視は基本的なプロパティ値に限られ、平均、最小、最大などの集計や、複雑なAND条件を必要とする監視には制限があります。(Microsoft Learn)
Teams通知とPower Automate連携で確認すべきこと
Operations Agentが条件に一致するデータを見つけると、Teamsにメッセージを送信できます。利用者はFabric Operations Agent Teamsアプリをインストールし、Teams上で推奨アクションの内容、発生条件、パラメーターを確認したうえで、YesまたはNoで承認・却下できます。(Microsoft Learn)
通知先はエージェントの設定で変更できますが、受信者は組織内ユーザーであり、Fabric上のエージェントアイテムに対する書き込み権限を持っている必要があります。ここで注意すべきなのは、通知先を変えても実行権限は変わらない点です。Operations Agentは作成者の委任IDと権限を使って動作し、受信者が推奨アクションを承認した場合でも、作成者の権限でアクションが実行されます。(Microsoft Learn)
Power Automateフローを連携する場合は、Activatorのカスタムアクションを通じて外部システムを呼び出せます。たとえば、Teams以外への通知、チケット作成、業務アプリの呼び出しなどが想定されます。接続文字列をPower Automateのフローに貼り付け、必要に応じて動的コンテンツや入力フィールドをフロー内で利用します。(Microsoft Learn)
管理者が確認すべき影響範囲
Operations Agentsは、AI、データ、Teams、Power Automate、Fabric容量を横断する機能です。導入判断を開発者だけに任せると、あとから権限、コスト、リージョン、承認フローの問題が出やすくなります。
| 影響範囲 | 確認すべき内容 | 見落とした場合のリスク |
|---|---|---|
| テナント設定 | Copilot/Azure OpenAI、クロスジオ処理・保存 | 作成できない、またはAI機能が動作しない |
| 容量 | Fabric対応容量、利用量、課金 | 予想外のCU消費や停止 |
| リージョン | 容量とテナントの地域、対応リージョン | Power Automateアクション設定エラーや利用不可 |
| 権限 | 作成者、通知先、ワークスペース権限 | 承認者と実行者の責任がずれる |
| データ設計 | Eventhouseテーブル、Ontology、識別子 | 誤検知、未検知、誤った推奨アクション |
| 監査 | Query insights、承認履歴、フロー実行履歴 | 何が実行されたか追跡しにくい |
Operations Agentがアクティブな状態では、データクエリが5分ごとに実行されます。また、条件に一致した推奨アクションに対してユーザーが3日以内に承認または却下しない場合、その操作は自動的にキャンセルされます。運用チームは「誰が何時間以内に確認するのか」を明文化しておくべきです。(Microsoft Learn)
コストと容量は事前に監視設計をする
Operations Agentsの利用では、FabricのCapacity Units、AI処理、Eventhouseへのクエリ、OneLakeストレージ、Power Automate連携など、複数のコスト要素が関係します。公式ドキュメントでは、Operations Agentの使用状況はMicrosoft Fabric Capacity Metrics appやAzure billingで確認できると説明されています。(Microsoft Learn)
導入初期は、エージェント数を増やしすぎないことが重要です。業務プロセスごとに専用エージェントを作れる利点はありますが、すべての監視をAIエージェント化すると、クエリ実行、LLMによる推奨生成、通知、外部フロー実行が増えます。まずは「人手での判断負荷が高く、条件が数値化でき、承認フローを定義しやすい」業務から始めるのが現実的です。
たとえば、最初の候補としては次のような業務が向いています。
| 向いている業務 | 理由 |
|---|---|
| 在庫しきい値監視 | 数値条件を定義しやすく、補充判断につなげやすい |
| IoTセンサー異常検知 | 時系列データとしきい値監視の相性がよい |
| 配送・運行遅延検知 | 遅延秒数やステータスで条件化しやすい |
| パイプライン実行監視 | 失敗・遅延・再実行判断を運用に組み込みやすい |
逆に、判断基準があいまいな業務、責任者が決まっていない業務、個人情報や機密情報を含むデータを十分に分類できていない業務は、最初の導入対象にしないほうが安全です。
移行・展開時に失敗しやすいポイント
既存のアラート、KQLクエリ、Power Automateフロー、手動監視をOperations Agentsに置き換える場合は、いきなり完全移行しないことが重要です。Operations AgentsはLLMを利用するため、生成されたプレイブックや推奨アクションを人が確認し、意図したルールになっているかを検証する必要があります。公式の制限事項でも、LLMベースのAIサービスは確率的で誤る可能性があるため、結果と推奨内容を慎重にレビューする必要があると説明されています。(Microsoft Learn)
特に注意したい失敗例は次のとおりです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 通知が多すぎる | しきい値が低すぎる、ルールが広すぎる | 初期は通知専用にして、発生件数を見ながら調整する |
| 誤った列を監視する | 列名やプロパティ名の意味が曖昧 | description追加、識別子列の明示、プレイブック確認 |
| 承認者が実行権限を誤解する | 通知先と実行IDが一致しない | 作成者権限で動くことを運用手順に明記する |
| Power Automateが失敗する | 接続文字列、入力フィールド、ライセンスの確認不足 | テスト用フローで入力値と失敗時処理を検証する |
| 日本語指示で精度が落ちる | 現時点では英語指示が前提 | GoalsとInstructionsは英語で標準化する |
| 本番でコストが膨らむ | エージェント数や監視条件を増やしすぎる | Capacity Metrics appで定期確認する |
まず実施すべき導入ステップ
Operations Agentsを安全に試すなら、次の順序で進めると失敗しにくくなります。
| ステップ | 実施内容 |
|---|---|
| 用途を1つに絞る | 在庫、遅延、設備、パイプラインなど、数値条件に落とせる業務を選ぶ |
| 管理設定を確認する | プレビュー、Copilot/Azure OpenAI、クロスジオ、容量、リージョンを確認する |
| データを整える | Eventhouseテーブルをフラット化し、識別子列と説明を用意する |
| 英語の指示文を作る | 業務目標、ルール、項目定義、優先順位を明文化する |
| 通知だけで検証する | 最初はTeams通知中心にし、自動実行は避ける |
| プレイブックを確認する | 監視項目、条件、列の対応、推奨内容をレビューする |
| Power Automateを段階連携する | 承認後にチケット作成など低リスクなアクションから始める |
| 容量と結果を監視する | Query insights、Capacity Metrics app、Teams応答を定期確認する |
最初の導入では、「AIで運用を完全自動化する」よりも「現場が見逃しやすい状態を早く見つけ、人が承認して確実に動く」ことを目標にするのが現実的です。Microsoft Fabric Operations Agentsは、業務ルールが明確で、データが整理され、承認責任が決まっている環境ほど効果を出しやすい機能です。まずは1つの業務プロセスで検証し、プレイブック、通知精度、コスト、権限設計を確認してから展開範囲を広げましょう。
コメント