Azure AI FoundryでAIエージェントを運用している場合、今回まず確認すべきポイントはAgent Monitoring Dashboardで、エージェントのトークン使用量、レイテンシ、成功率、評価結果をFoundryポータル上から確認できるように整理されたことです。単なる画面追加ではなく、Application Insightsと連携した監視、継続評価、レッドチームスキャン、アラート設定までを運用フローに組み込める点が重要です。(Microsoft Learn)
特に管理者は、Application Insightsの接続、RBAC権限、Log Analyticsへのアクセス、プレビュー機能の扱いを確認する必要があります。開発者は、エージェントの応答品質や失敗率を「感覚」ではなく、評価ルールや実行結果で継続的に見られる状態にしておくことが重要です。(Microsoft Learn)
Azure AI FoundryのAgent Monitoring Dashboardで何が変わるのか
Agent Monitoring Dashboardは、Microsoft Foundry上でAIエージェントの運用状態を確認するための監視ダッシュボードです。対象は、Foundryプロジェクト内のエージェントだけでなく、条件を満たせばFoundry外で動作するカスタムエージェントの監視にも広げられます。(Microsoft Learn)
今回の要点は、AIエージェントの監視対象が「ログを見る」だけではなく、運用品質、コストの兆候、応答速度、評価結果、安全性チェックまで含む形に整理されたことです。
| 確認項目 | 何が分かるか | 実務上の使いどころ |
|---|---|---|
| Token usage | エージェント実行時のトークン使用量 | プロンプトや回答が冗長になっていないか、コスト増の兆候がないかを見る |
| Latency | エージェント実行の応答時間 | ユーザー体験の悪化、ツール呼び出し遅延、モデル側の制限を疑う |
| Run success rate | 実行が正常完了した割合 | 障害、例外、外部ツール連携失敗の早期発見に使う |
| Evaluation metrics | サンプリングされた応答の評価結果 | 品質、安全性、意図した振る舞いを継続的に確認する |
| Red teaming results | レッドチームスキャンの結果 | データ漏えい、禁止行為、悪用耐性などのリスク確認に使う |
従来のアプリケーション監視では、HTTPエラーやCPU、メモリ、レスポンスタイムを見ることが中心でした。しかしAIエージェントでは、「正常に返答したが、内容が不適切」「回答は正しいがトークンを使いすぎる」「ツール呼び出しが遅くユーザー体験が悪い」といった問題が起こります。Agent Monitoring Dashboardは、こうしたAIエージェント特有の運用課題を見つけるための入口になります。(Microsoft Learn)
影響範囲：既存のAIエージェント運用にどう関係するか
Agent Monitoring Dashboardは、すべてのAzure AI Foundry利用者に一律で大きな移行作業を求める変更というより、エージェント運用の監視・評価を強化するための仕組みと捉えると分かりやすいです。
影響を受けやすいのは、次のような環境です。
| 対象 | 影響 |
|---|---|
| Foundryプロジェクト内でエージェントを作成している環境 | Monitorタブから運用指標や評価結果を確認する運用に移行しやすい |
| Application Insightsをまだ接続していない環境 | ダッシュボードで必要なテレメトリを取得できないため、接続設定が必要 |
| Log Analyticsワークスペースを使ってログ分析している環境 | 閲覧者にLog Analytics Readerなど適切な権限が必要 |
| 継続評価を自動化したい開発チーム | Python SDKまたは.NET SDKで評価ルールを設定する必要がある |
| Foundry外でカスタムエージェントを動かしている環境 | AI GatewayへのオンボードとOpenTelemetryに沿った計装が検討対象になる |
既存のエージェントがすぐ動かなくなるような破壊的変更ではありません。ただし、監視ダッシュボードを実運用で使うには、Application Insights、RBAC、評価ルール、サンプリング設計を確認する必要があります。特に本番運用では、ダッシュボードを表示できるかどうかよりも、誰が見られるか、どのデータを保存するか、評価やアラートが運用に耐えるかを先に決めるべきです。
利用前に確認すべき前提条件
Agent Monitoring Dashboardを使うには、Foundryプロジェクト、エージェント、Application Insightsの接続が前提になります。SDKで継続評価を設定する場合は、Python 3.9以降などの開発環境も必要です。(Microsoft Learn)
| 前提条件 | 確認すべきポイント |
|---|---|
| Foundry project | 少なくとも1つのエージェントが存在すること |
| Application Insights | Foundryプロジェクトに接続されていること |
| Azure RBAC | Application Insightsリソースを閲覧できる権限があること |
| Log Analytics | ログベースの表示を使う場合、関連ワークスペースへのアクセス権があること |
| Python 3.9以降 | Python SDKで継続評価を設定する場合に必要 |
| プロジェクトのマネージドID | 継続評価ルールを使う場合、Foundry Userロールの割り当てを確認する |
注意したいのは、監視データの保存先です。Agent Monitoring Dashboardの監視データは、接続済みのApplication Insightsリソースに保存されます。そのため、保持期間や課金はApplication Insights側の構成に従います。監視を有効にする前に、データ保持、コスト、機密情報の扱いを管理者側で確認しておくべきです。(Microsoft Learn)
また、FoundryのRBACロール名は変更されています。Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当します。ロールIDや基本的な権限は変わらないとされていますが、移行期間中は旧名称が一部画面に残る可能性があります。(Microsoft Learn)
FoundryポータルでAgent Monitoring Dashboardを確認する手順
ポータルで確認する流れはシンプルです。まずMicrosoft Foundryにサインインし、New Foundryのトグルがオンになっていることを確認します。その後、上部ナビゲーションからBuildを選び、対象のエージェントを開いてMonitorタブを表示します。(Microsoft Learn)
実務では、次の順番で見ると問題を切り分けやすくなります。
| 順番 | 見る項目 | 判断のポイント |
|---|---|---|
| 1 | Run success rate | 失敗が増えていないかを先に確認する |
| 2 | Latency | ユーザー体験に影響する遅延がないかを見る |
| 3 | Token usage | コスト増や冗長なプロンプトの兆候を確認する |
| 4 | Evaluation metrics | 応答品質や安全性の評価結果を見る |
| 5 | Red teaming results | セキュリティ上の重大リスクがないか確認する |
公式ドキュメントでは、レイテンシが10秒を超える場合、モデルのスロットリング、複雑なツール呼び出し、ネットワーク問題などを疑う目安とされています。また、Run success rateが95%を下回る場合は、失敗した実行の調査が推奨されています。(Microsoft Learn)
この数値は、すべてのシステムにそのまま適用する絶対基準ではありません。社内FAQボットと顧客向けリアルタイムサポートでは、許容できる遅延や失敗率が違います。まずは自社の通常時の数値を記録し、そこから急な変化がないかを見る運用にすると、アラート疲れを避けやすくなります。
Monitor settingsで確認すべき設定
Monitorタブの歯車アイコンからMonitor settingsを開くと、テレメトリ、評価、セキュリティチェックに関する設定を確認できます。ここでの設定によって、ダッシュボードに表示されるチャートや、実行される評価が変わります。(Microsoft Learn)
| 設定 | 内容 | 管理者・開発者が確認すべきこと |
|---|---|---|
| Continuous evaluation | サンプリングしたエージェント応答を継続評価する | 有効化の有無、評価器、サンプルレートを確認する |
| Scheduled evaluations | ベンチマークに対して定期評価を実行する | 評価テンプレート、実行頻度、対象範囲を確認する |
| Red team scans | 攻撃的なテストでリスクを検出する | データ漏えい、禁止行為などの観点で実行計画を決める |
| Alerts | 異常や評価失敗、セキュリティリスクを検出する | レイテンシ、トークン使用量、評価スコア、Red team結果の通知条件を設計する |
ここで重要なのは、すべてを一度に有効化しないことです。特にScheduled evaluations、Red team scans、Alertsはプレビュー扱いの項目が含まれます。プレビュー機能はサービスレベルアグリーメントなしで提供され、本番ワークロードでは推奨されない場合があります。検証環境で動作、コスト、通知量を確認してから段階的に展開するのが安全です。(Microsoft Learn)
継続評価をSDKで設定する場合のポイント
継続評価は、エージェントの応答が完了したタイミングで評価ルールを実行し、品質や安全性の評価結果を蓄積する仕組みです。ポータルで結果を見るだけでなく、Python SDKまたは.NET SDKを使ってルールを作成できます。(Microsoft Learn)
Pythonの場合、公式ドキュメントでは次のパッケージインストール例が示されています。
pip install "azure-ai-projects>=2.0.0" python-dotenv.NETの場合は、Azure.AI.Projects、Azure.AI.Projects.Agents、Azure.AI.Extensions.OpenAI、Azure.Identityなどのパッケージを追加します。どちらの方法でも、プロジェクトエンドポイント、エージェント名、モデルデプロイ名を環境変数で指定する流れになります。(Microsoft Learn)
継続評価を設定するときは、次の4点を必ず確認してください。
| 確認項目 | 理由 |
|---|---|
| 評価対象のエージェント名 | ルールのfilterで対象エージェントを絞り込むため |
| 評価器の種類 | 暴力検出など、目的に合う評価器を選ぶ必要があるため |
| イベント種別 | 応答完了時に評価する場合はresponse completed系のイベントを使うため |
| 1時間あたりの実行上限 | 評価の実行数が多すぎるとコストや制限に影響するため |
公式サンプルでは、ContinuousEvaluationRuleActionに評価IDを指定し、max_hourly_runsを100に設定する例が示されています。トラブルシューティングでも、評価実行がスキップされる原因として1時間あたりの実行上限到達が挙げられています。(Microsoft Learn)
実運用では、最初から全トラフィックを評価するより、代表的な会話や重要フローを中心にサンプリングするほうが現実的です。たとえば、社内ヘルプデスク用途なら「権限申請」「障害報告」「個人情報を含む問い合わせ」など、リスクが高いカテゴリを優先して評価対象にすると、少ない実行数でも改善につながりやすくなります。
カスタムエージェントを監視対象にする場合の注意点
Foundry外で動作しているカスタムエージェントも、条件を満たせばFoundryを監視の集約場所として使えます。公式ドキュメントでは、AI Gateway経由でエージェントをオンボードし、OpenTelemetryの生成AI向けセマンティック規約に沿って計装し、Foundryプロジェクトと同じApplication Insightsインスタンスへテレメトリを送る流れが示されています。(Microsoft Learn)
この構成で失敗しやすいのは、次の3点です。
| 失敗しやすいポイント | 起こる問題 | 対策 |
|---|---|---|
| 別のApplication Insightsに送信している | FoundryのMonitorタブで期待したデータが見えない | Foundryプロジェクトと同じApplication Insightsを使う |
| OpenTelemetryの属性が不足している | エージェントの実行や評価対象を正しく関連付けられない | 生成AI向けセマンティック規約に沿って計装する |
| AI Gatewayへの登録だけで満足している | 監視や継続評価に必要なデータが不足する | 登録、計装、送信先、Monitor表示まで一連で確認する |
カスタムエージェントの監視は、複数のチームが独自に作ったAIアプリを横断的に管理したい場合に有効です。ただし、監視基盤を統一する分、命名規則、環境分離、権限設計を先に決めておかないと、ダッシュボード上で「どのエージェントのデータか分からない」状態になりやすいです。
管理者が確認すべき展開上の注意点
Agent Monitoring Dashboardを本格展開する前に、管理者は以下を確認しておきましょう。
| 確認項目 | 判断基準 |
|---|---|
| Application Insightsの保持期間 | 監査や障害調査に必要な期間を満たしているか |
| 課金影響 | テレメトリ量、評価実行数、ログ保持でコストが増えすぎないか |
| RBAC | 閲覧者、設定変更者、評価ルール作成者が分離されているか |
| Log Analyticsアクセス | ログベースの分析を行う担当者に必要な権限があるか |
| プレビュー機能の利用範囲 | 本番で使うか、検証環境に限定するかを明確にしているか |
| アラート設計 | 通知が多すぎて無視される状態にならないか |
| 機密情報の扱い | プロンプトや応答に個人情報・機密情報が含まれる場合の扱いを決めているか |
特に重要なのは、監視データの扱いです。AIエージェントのログには、ユーザーの質問、内部文書に関する内容、業務上の判断材料が含まれる可能性があります。Application Insightsに送信されるデータの範囲、マスキング方針、閲覧権限は、開発チームだけで決めず、セキュリティ担当や情報管理部門と確認しておくべきです。
開発者が確認すべき実装上の注意点
開発者側では、ダッシュボードに表示される数値を「後から見る」だけでなく、問題が起きたときに原因を追えるように実装しておくことが重要です。
| 確認項目 | 具体例 |
|---|---|
| エージェント名の一貫性 | dev、stg、prodで命名ルールを揃える |
| モデルデプロイ名の管理 | 環境変数で指定し、環境ごとの差異を明確にする |
| ツール呼び出しの計測 | 外部API、検索、DB参照の遅延を分けて確認できるようにする |
| 評価ルールの対象 | 全応答ではなく、重要フローから優先して評価する |
| エラー時の情報 | 失敗理由を後から追えるように例外や状態を記録する |
| 評価結果の確認 | Monitorタブだけでなく、必要に応じて評価実行一覧やレポートURLも確認する |
AIエージェントの品質改善では、失敗した会話だけを見ると判断を誤ることがあります。成功しているように見えるがトークンを使いすぎている、回答品質は高いがレイテンシが長い、安全性評価は良いが業務要件を満たしていない、といったケースがあるためです。運用指標と評価指標をセットで見ることが、改善の近道になります。
よくあるトラブルと対処法
Agent Monitoring Dashboardで問題が起きた場合、まずは公式ドキュメントのトラブルシューティングに沿って切り分けるのが効率的です。代表的な原因は、トラフィック不足、時間範囲の指定、権限不足、継続評価ルールの未設定、1時間あたりの評価実行上限です。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
| ダッシュボードのグラフが空 | 最近のトラフィックがない、時間範囲が合っていない、取り込み遅延がある | 新しいエージェント実行を発生させ、時間範囲を広げ、数分後に更新する |
| 認可エラーが出る | Application InsightsまたはLog AnalyticsのRBAC権限が不足している | Azure portalのAccess controlで権限を確認し、必要に応じてLog Analytics Readerを付与する |
| 継続評価の結果が表示されない | 継続評価が無効、ルール作成に失敗、トラフィックがない | ルールが有効か、対象エージェントにトラフィックがあるか、マネージドIDにFoundry Userロールがあるか確認する |
| 評価実行がスキップされる | 1時間あたりの実行上限に達している | max_hourly_runsを調整するか、次の時間枠まで待つ |
| カスタムエージェントの指標が出ない | AI Gateway登録、計装、Application Insights送信先のいずれかが不十分 | 登録状態、OpenTelemetry属性、送信先Application Insightsを確認する |
現場で特に多いのは、「エージェントを開いたのに何も表示されない」というケースです。この場合、ダッシュボード自体の不具合と決めつける前に、対象時間内に実行データがあるか、Application Insightsが正しく接続されているか、閲覧者に権限があるかを順番に確認してください。
導入を急ぐべきケースと慎重に進めるべきケース
Agent Monitoring Dashboardは、すでにAIエージェントを業務利用している組織ほど導入メリットが大きいです。特に、問い合わせ対応、社内ナレッジ検索、業務自動化、Copilot的なアシスタント機能を提供している場合、品質や安全性を定量的に見られる仕組みは早めに整えるべきです。
一方で、次のような環境では慎重に進める必要があります。
| 状況 | 理由 |
|---|---|
| プレビュー機能を本番で使えないルールがある | Scheduled evaluations、Red team scans、Alertsなどはプレビュー項目を含む |
| 機密データを多く扱う | テレメトリやログの保存範囲を慎重に設計する必要がある |
| Application Insightsのコスト管理が未整備 | ログ量や保持期間によってコストが増える可能性がある |
| RBAC設計が曖昧 | 評価結果や会話データに不要なアクセスが発生する可能性がある |
| 評価基準が決まっていない | ダッシュボードを見ても改善判断につながらない |
導入の目的は、画面を有効化することではありません。AIエージェントの品質、速度、コスト、安全性を継続的に改善できる運用を作ることです。まずは1つの重要エージェントを対象に、Application Insights接続、Monitor確認、継続評価、アラート設計までを小さく試すのが現実的です。
次に取るべき行動
Azure AI Foundryでエージェントを運用している場合、まずは対象プロジェクトにApplication Insightsが接続されているか確認してください。次に、Foundryポータルで対象エージェントのMonitorタブを開き、Token usage、Latency、Run success rate、Evaluation metricsが見える状態か確認します。
そのうえで、管理者はRBAC、Log Analyticsアクセス、データ保持、課金、プレビュー機能の利用範囲を整理します。開発者は、継続評価ルールの対象、評価器、サンプルレート、max_hourly_runsを設計し、検証環境で評価結果がCompletedになるか確認してください。
Agent Monitoring Dashboardは、AIエージェントを「作って終わり」にしないための監視基盤です。最初から完璧な評価設計を目指すより、まずは成功率、レイテンシ、トークン使用量の基準値を作り、そこに継続評価とレッドチーム結果を加えていくことで、運用改善につながるダッシュボードになります。
コメント