操作エージェントの作成と構成

Fabric Real-Time Intelligence の運用エージェントは、組織がリアルタイム データを即時かつ実用的な意思決定に変えるのに役立ちます。 エージェントを使用して、手動による監視と介入に依存するのではなく、キー メトリックを継続的に追跡し、分析情報を表示し、対象となるアクションを推奨します。 チームは迅速に対応し、大規模な運用を最適化できます。 各運用エージェントは、特定のビジネス プロセス用に設計された専用の Fabric 項目です。

明確な指示とデータ ソースを使用してエージェントを構成することで、複数のエージェントを組織全体の仮想エキスパートとしてデプロイできます。 このモジュール式アプローチは、すべての重要なプロセスを監視し、継続的に改善し、推奨されるアクションを戦略的目標に合わせて維持します。

この記事では、Real-Time Intelligence で AI 運用エージェントを作成して使用する方法について説明します。 運用エージェントは、リアルタイム データを監視し、実行可能な決定を提案します。

[前提条件]

  • Microsoft Fabric 対応の 容量を持つ ワークスペース。 試用版の容量はサポートされていません。

  • ワークスペース内の イベントハウス または オントロジ

  • イベントハウスを使用している場合は、イベントハウス内の KQL データベース

  • Microsoft Teams アカウント。

  • operations agent、Microsoft Copilot、Azure OpenAI に対して、Fabric の管理者権限が有効になりました。

  • データ エージェントのテナント設定の説明に従って、AI のクロス geo 処理とストレージを有効にします。 この前提条件は、Fabric容量が米国または EU リージョンでプロビジョニングされていない場合にのみ適用されます。

    アクセス許可を有効にする管理ポータルのスクリーンショット。

Note

サンプル データに対して操作エージェントを試すには、 Real-Time Intelligence のエンド ツー エンド サンプルを設定します。 オペレーション エージェントは、含まれているイベントハウスを監視できます。

操作エージェントを作成する

  1. Fabric ホーム ページで、省略記号 (...) アイコンを選択し、[ 作成] を選択します。

    省略記号アイコンと [作成] オプションのスクリーンショット。

  2. [作成] で、[Real-Time インテリジェンス] セクションに移動し、[Operations Agent] を選択します。

    操作エージェントを作成するためのオプションのスクリーンショット。

  3. 新しい Operations エージェントで、エージェントの名前を入力し、作成するワークスペースを選択します。

    新しい操作エージェントのペインのスクリーンショット。

  4. [ 作成] を選択して操作エージェントを作成します。

操作エージェントを構成する

エージェントのセットアップ時に、操作エージェントを構成し、次の情報を指定してデータに合わせて調整します。

  1. エージェントの動作と意思決定プロセスをガイドするための具体的な指示を提供します。 たとえば、ビジネス目標に一致する条件が検出されたときにアラートを送信するようにエージェントに指示できます。

    セットアップ ページの手順セクションのスクリーンショット。

  2. エージェントが分析および監視できる関連するデータ ソースを選択します。 この選択により、エージェントはインサイトを生成するために、正確で最新の情報にアクセスできます。

    セットアップ ページのナレッジ ソース セクションのスクリーンショット。

  3. 既定では、オペレーション エージェントは、監視する条件が満たされたときに Teams でメッセージを送信できます。 必要に応じて、推奨および実行できる追加のアクションを構成できます。 詳細については、「 Operations Agent アクション」を参照してください。

構成が完了したら、エージェントを保存し、[ プレイブックの生成] を選択します。 プレイブックには、定義した目標、指示、データ、アクションの概要が示されているため、エージェントはそのタスクを理解します。

基になるデータで、プロパティとマップされるフィールドを確認できます。 ルールを確認すると、基になる列ではなくプロパティの名前を参照するルールが表示されることがあります。 モデルとルールが要件と一致することを確認します。

プレイブックとそのプロパティのスクリーンショット。

プレイブックには、エージェントが監視する概念と、エージェントが評価するルールまたは条件が表示されます。

Copilot チャットを使用して、オペレーション エージェントの指示とルールを構成する

すべての目標、ルール、しきい値を手動で構成する代わりに、組み込みのCopilot チャットを使用してエージェントを会話形式で設定できます。 リボンからチャットを開きます。

リボンと [チャットを開く] ボタンのスクリーンショット。

まず、「タービンを監視し、モーターの温度が高くなりすぎる場合に警告する」など、エージェントが自然言語で行うことを説明します。チャットは意図を解釈し、選択したデータ ソースに対して根拠を付け、エージェントのプレイブックを構成する目標、指示、ルールに変換するのに役立ちます。 チャットを手動構成と共に使用できるため、指示を直接入力したり、Copilotに下書きしたり絞り込んだりすることができます。

チャットは、指示を絞り込んで監視ロジックに変換するのに最も役立ちます。 条件を記述する際に、Copilotはそれらをサポートするルールとクエリを提案し、指示が不明確な場合や、使用できないデータを参照したり、サポートされていない条件やアクションを要求したりするときに注意が必要な場合に通知します。 このフィードバック ループは、実行時にギャップを検出するのではなく、エージェントを開始する前にコースを修正するのに役立ちます。 各ルールは明示的なクエリに基づいているため、Copilot が生成した内容を確認し、ロジックを自分で検証できます。

構成は反復的です。 Copilotがルール、クエリ、アクションを提案したら、フォローアップの質問をして指示を絞り込んだり、しきい値を調整したり、監視スコープを絞り込んだりできます。 プレイブックは、移動中に更新されます。 エージェントに何を監視させ、どのように応答させるかがプレイブックに反映されるまで、この提案・明確化・改善のループを続けます。 満足したら、結果の目標、ルール、データ ソース、アクションを確認します。 次に、エージェントを保存して起動します。

エージェントを起動する

エージェントの動作を調整するには、目標または指示を更新し、エージェントをもう一度保存します。 構成に問題がなければ、ツール バーの [開始 ] を選択してエージェントを起動します。 [停止] を選択して停止します。

オペレーションエージェントの識別子

各オペレーションエージェントはMicrosoft Entraで独自のアイデンティティを持ち、Microsoft Entra エージェント IDによって駆動されます。 エージェントを作成する際、Fabricは専用のエージェントID(専門的なサービスプリンシパル)をプロビジョニングし、エージェントは匿名ユーザーセッションではなく、Entra管理センターでファーストクラスで管理可能なエンティティとして表示されます。 このアイデンティティにより、組織全体でエージェントの存在をテナント全体で把握でき、監査時にエージェントの行動を人間の行動と区別し、エージェントを作成したアカウントのライフサイクルから切り離します。 オペレーションエージェントは 委任 モードで動作します。作成者の認証をOn-Behalf-Of(OBO)フローを通じて使用するため、作成者がアクセスできるのと同じワークスペースやアイテムにアクセスでき、アクションはエージェントのアイデンティティに帰属されます。 Entra エージェント IDは、オペレーションエージェントアイテムのステータスバーで確認できます。

エージェント設定画面のEntra エージェント IDのスクリーンショットです。

Important

エージェントは、その作成者の委任された ID とアクセス許可で動作します。 受信者が推奨事項を承認すると、エージェントは作成者のアクセス許可を使用して作成者に代わってアクションを実行します。

操作エージェントの規則を理解する

エージェントは、データ ソースに対してルールごとにクエリを実行します。 このクエリを表示すると、ルールが基になる列、プロパティ、およびロジックにどのようにマップされるかを正確に確認できます。 クエリを確認すると、エージェントが適切なプロパティを評価し、目的の条件を適用し、正しいデータを読み取っていることを検証するのに役立ちます。 この方法で、エージェントが開始する前に適切なものを探すのを確認します。

クエリを表示するように展開されたルールのスクリーンショット。

[コードのコピー] オプションを使用して、KQL クエリセット項目または Ontology グラフ クエリ エディターに貼り付けて、データに対してテストできます。 KQL の場合、 startTime パラメーターと endTime パラメーターを最新のタイムスタンプ (または KQL now() 関数) に置き換えて、データに対して検証する必要があります。

操作エージェントは、ルールのクエリを 5 分ごとに実行し、ルールが満たされる タイミング を定義する条件に対して結果を追跡します。 条件は 2 つのカテゴリに分類され、違いによってルールがシグナルを送信する頻度が決まります。

  • 状態条件 は、プロパティの現在の値が条件を満たす たびに 満たされます。 値がその状態に留まる限り満足し続けるので、条件が維持されている間は繰り返し通知できます。 "温度が 80 を超える" などの 状態であることを気 にする場合は、状態条件を使用します。
  • 遷移条件 は、プロパティが条件を満たしていない状態から満たすまで変化した 時点でのみ 満たされます(null 値からの変更を含む)。 遷移ごとに 1 回信号を送信し、値が条件を終了して再入力するまで、もう一度通知しません。 "温度が 80 より大きくなる" など、 変化を気にする場合は、遷移条件を使用します。

たとえば、値がしきい値を超えている間は評価ごとに 上記 が満たされますが、 上記のクロス は、値がしきい値の下から上に移動した場合にのみ満たされます。 進行中の状態に応答するか、状態の変化に応答するかに一致する条件を選択します。

次の表では、使用可能な条件について説明します。

状態 タイプ 満たされた場合
上記 状態 プロパティがその値を上回っていれば満たされます。
上の十字 Transition プロパティがその値を下回る状態から上回る状態に変化した場合(または null からその値を上回る状態に変化した場合)に成立します。
以下です 状態 プロパティがその値を下回っている場合に満たされます。
以下のクロス Transition プロパティが値の上から下 (または null から値の下) に変更されたときに満たされます。
範囲を入力します Transition プロパティの値が範囲外から範囲内に変わるたびに条件を満たします。
範囲外に出る Transition プロパティが範囲内から範囲外に変わるたびに条件が満たされます。
等しい 状態 プロパティが値と一致するたびに満たされます。
変換後 Transition プロパティが別の値または null からその値に変更されたときに満たされます。

エージェントのアクティビティを監視する

エージェントのアクティビティ ログには、評価された条件、行った推奨事項、受信した応答など、アクションの詳細な記録が表示されます。 この情報は、エージェントの意思決定プロセスを理解し、改善の領域を特定するのに役立ちます。

アクティビティ ログにアクセスするには、サイド ナビゲーション ウィンドウで [アクティビティ ログ ] を選択します。 ログには、タイムスタンプ、イベントの種類、関連する詳細など、イベントの時系列リストが表示されます。 イベントを選択すると、イベントに関する詳細情報が表示されます。

アクティビティ ログのスクリーンショット。

[ 操作の詳細] ページ で、操作の詳細と状態を表示できます。

操作の詳細ページのスクリーンショット。