Azure MonitorでAIエージェントを監視するなら、まず確認すべきなのはApplication Insightsの「Agents（Preview）」ビューです。2026年5月30日に更新されたMicrosoft Learnの公式情報では、Microsoft Foundry、Copilot Studio、サードパーティー製エージェントなど複数のAIエージェントの実行状況を、Application Insights上でまとめて確認できる方針が示されています。(Microsoft Learn)
結論から言うと、今回のポイントは「AIエージェントの監視対象が、単なるアプリの例外や応答時間だけではなく、LLM呼び出し、ツール実行、トークン使用量、失敗トレース、コスト要因まで広がる」ことです。ただし、Azure Monitorを使っているだけで自動的にすべて見えるわけではありません。AIエージェント側のテレメトリ収集、OpenTelemetry/OTLPの送信設定、Application Insightsリソースの選定、機密データを含むプロンプト収集の扱いを事前に決める必要があります。
Azure MonitorのAIエージェント監視で何が変わるのか
Application InsightsのAgent details viewは、AIエージェント向けの監視画面として位置付けられています。公式ドキュメントでは、Microsoft Foundry、Copilot Studio、サードパーティー エージェントを含む複数ソースのAIエージェントを統合的に監視できるビューとして説明されています。(Microsoft Learn)
従来のアプリ監視では、HTTPリクエストの失敗、依存関係の遅延、例外、CPUやメモリなどを見ることが中心でした。一方、AIエージェントでは次のような問題が起きます。
- 回答は返るが、トークン消費が多すぎる
- どのツール呼び出しで失敗したのか分からない
- LLMの呼び出し回数が多く、応答が遅い
- Copilot Studio、Foundry、自前エージェントで監視画面が分かれている
- プロンプトや会話内容をどこまでログに残してよいか判断しにくい
Agent details viewは、こうしたAIエージェント特有の運用課題に対して、テレメトリと診断情報をまとめ、パフォーマンス、トークン使用量、コスト、エラー調査、エージェント動作の最適化を支援するものです。(Microsoft Learn)
2026年5月30日更新情報の要点
今回の公式情報で管理者・開発者が押さえるべき内容は、次のように整理できます。
| 観点 | 変更・整理されたポイント | 実務上の意味 |
|---|---|---|
| 監視画面 | Application InsightsにAIエージェント向けのAgents（Preview）ビューを用意 | AIエージェントの実行、失敗、モデル、ツール呼び出しを同じ文脈で追いやすくなる |
| 対象範囲 | Foundry、Copilot Studio、サードパーティー エージェントを横断 | Microsoft製サービスだけでなく、自前実装や外部フレームワークも監視設計の対象になる |
| トレース調査 | Agent Runs、Gen AI Errors、モデル、ツール呼び出しからトレースを絞り込み可能 | 「どの実行で、どのモデル・ツールが原因だったか」を運用担当者が追いやすくなる |
| コスト把握 | トークン使用量や高コスト操作を分析しやすい | 高額なモデル利用、大きすぎるプロンプト、不要な会話履歴投入を見直す材料になる |
| 詳細診断 | End-to-end transaction detailsにシンプルビューを用意 | エージェント、LLM、ツール実行の流れをストーリー形式で確認しやすくなる |
| 可視化 | Grafana連携と事前構成済みダッシュボードを利用可能 | 標準ビューで足りない場合に、チーム別・環境別・コスト別の監視画面を作れる |
公式ドキュメントでは、Agents（Preview）へのアクセスはAzure portalでApplication Insightsリソースを開き、ナビゲーションから「Agents（Preview）」を選択する流れとされています。また、Foundry側からはエージェントのMonitoringタブから「View in Azure Monitor」へ移動できると説明されています。(Microsoft Learn)
影響を受ける利用者と確認ポイント
Azure MonitorのAIエージェント監視は、開発者だけの話ではありません。監視運用、セキュリティ、FinOps、情シス、現場部門の管理者にも影響します。
| 立場 | 確認すべきこと | 見落としやすいポイント |
|---|---|---|
| Azure管理者 | Application Insightsリソース、RBAC、ログ保持、ダッシュボード保存先 | 監視データをどのサブスクリプション・リソースグループに集約するか |
| AIアプリ開発者 | OpenTelemetryの計装、エージェント名、モデル・ツールのスパン | エージェント名が曖昧だと、本番障害時に原因を切り分けにくい |
| Copilot Studio管理者 | Application Insightsへの接続設定、環境ごとの出力先 | 開発環境と本番環境のテレメトリが混在するリスク |
| Foundry利用者 | Foundry側のトレーシング設定、Azure Monitorへの導線 | Foundry上では見えていても、Application Insights側に期待通り流れているとは限らない |
| セキュリティ担当 | プロンプト、応答、ツール引数、コード内容の収集可否 | 機密情報や個人情報を含む会話ログを不用意に収集するリスク |
| FinOps担当 | トークン使用量、モデル別利用傾向、ログ取り込み量 | AI利用料だけでなくAzure Monitor側の取り込み・保存コストも確認が必要 |
特に重要なのは、AIエージェントの監視では「動いているか」だけでなく「なぜ高いのか」「どこで失敗したのか」「どのプロンプト設計が悪いのか」まで見る必要がある点です。Application InsightsのAgent details viewでは、トレースをトークン使用量で並べ替えたり、時間範囲で絞り込んだり、機密データのログ取得を有効にしている場合はプロンプト内容を検索したりできます。(Microsoft Learn)
利用前に確認すべき前提条件
AIエージェントのデータ収集を先に実装する
Agents（Preview）ビューは、テレメトリがApplication Insightsに流れて初めて意味を持ちます。公式ドキュメントでも、Agent details viewを使う前にAIエージェントのデータ収集を実装する必要があるとされています。(Microsoft Learn)
よくある誤解は、「Azure Monitorを有効にしているからAIエージェントも自動で見えるはず」というものです。実際には、エージェントの実装形態に応じて設定が変わります。
| エージェントの種類 | 代表的な設定方針 |
|---|---|
| Azure AI Foundry管理のエージェント | Foundry側のトレーシング設定を確認し、必要に応じてAzure Monitor OpenTelemetry DistroやFoundry SDK側の計装を検討する |
| Copilot Studioエージェント | Copilot Studioの組み込み設定でAzure Monitor/Application Insightsへテレメトリを送る |
| Microsoft Agent Frameworkで構築した自前エージェント | Agent Frameworkを使ってエージェントの実行やテレメトリ送信を設計する |
| LangChain、LangGraph、OpenAI Agents SDKなどのサードパーティー系 | Azure AI OpenTelemetry Tracerや各フレームワーク向けのトレーシング設定を確認する |
| GitHub Copilot、Claude Code、Codex、Gemini CLIなどのコーディングエージェント | OTLP信号をOpenTelemetry Collector経由でApplication Insightsへ送る構成を検討する |
MicrosoftのApplication Insights OpenTelemetry概要では、AI Agentsのデータ収集パスとして、Managed hostingとSelf-hostingに分けた設定方針が示されています。Foundry管理のエージェント、Copilot Studio、自前実装、サードパーティー エージェントで入口が異なるため、まず自社のエージェント一覧を作ることが実務上の第一歩です。(Microsoft Learn)
Application Insightsリソースを分けるか集約するか決める
AIエージェントの監視データを、既存アプリのApplication Insightsリソースに入れるか、AIエージェント専用のリソースに分けるかは重要です。
既存アプリとAIエージェントが密接に連携している場合は、同じApplication Insightsリソースに入れると、Web API、バックエンド、LLM呼び出し、ツール実行の関連を追いやすくなります。一方で、複数部門が異なるAIエージェントを運用している場合は、環境や権限、ログ保持、コスト管理の単位で分けたほうが安全です。
Microsoftの概要ドキュメントでも、エージェント型コンポーネントが大きなアプリケーションの一部である場合は、既存のApplication Insightsリソースへの送信を検討できるとされています。また、Agent details viewで区別しやすいように、各エージェントには明確に異なる名前を付けることが推奨されています。(Microsoft Learn)
管理者が確認すべき設定
RBACとダッシュボード保存権限
Agent details viewを見るだけでなく、Grafanaダッシュボードを保存・共有する場合は、Azure RBACの設計が必要です。Application InsightsのGrafana機能では、Application Insightsデータの読み取り権限に加え、保存先のサブスクリプションやリソースグループにリソースを作成する権限が必要です。保存したダッシュボードはAzureリソースとして管理され、RBACやARM/Bicepによる自動化の対象になります。(Microsoft Learn)
本番運用では、少なくとも次を分けて考えると安全です。
| 権限 | 主な対象者 | 注意点 |
|---|---|---|
| 閲覧権限 | 運用担当、開発者、プロダクトオーナー | プロンプトや会話内容が見える設定の場合、閲覧者を広げすぎない |
| ダッシュボード作成権限 | SRE、Azure管理者、監視設計担当 | 無秩序に作ると似たダッシュボードが増え、運用時に迷う |
| 設定変更権限 | Azure管理者、セキュリティ担当 | テレメトリ送信先や機密データ収集の変更は承認フローを通す |
Grafanaは「標準ビューの補完」として使う
Agent details viewは、AIエージェント監視の入口として使えます。一方、チーム別のKPI、モデル別のトークン推移、失敗率、応答時間、導入部門別の利用傾向を継続的に見るには、Grafanaダッシュボードが役立ちます。
Azure Monitorには、Gen AI監視向けの事前構成済みGrafanaダッシュボードとして、Agent Framework、Agent Framework workflow、Foundry、Coding agent dashboardsが用意されていると説明されています。これらは開始点として使い、必要に応じてパネルやクエリを編集し、Save asで自社環境向けのダッシュボードにできます。(Microsoft Learn)
ただし、Grafana体験そのものに追加料金がない場合でも、Azure Monitor、Azure Monitor managed service for Prometheus、Azure Data Explorerのクエリ実行やデータ保存には標準の課金が適用されます。監視ダッシュボードを増やすほど、データ保持量やクエリ頻度も確認が必要です。(Microsoft Learn)
外部で作ったダッシュボードはタグを確認する
Application Insights内のGrafanaギャラリーにダッシュボードを表示するには、対象ダッシュボードに特定のリソースタグが必要です。Application Insights内で作成したダッシュボードには自動でタグが付与されますが、外部で作成・インポートしたものを表示したい場合は、GrafanaDashboardResourceType=microsoft.insights/componentsのタグを手動で追加する必要があります。(Microsoft Learn)
「ダッシュボードを作ったのにApplication Insights側に出てこない」という場合は、権限不足だけでなくタグ不足も疑ってください。
開発者が確認すべき設定
OpenTelemetry/OTLPの送信経路を確認する
AIエージェント監視の基盤はOpenTelemetryです。公式ドキュメントでは、Azure Monitor Agent ObservabilityがOpenTelemetry Generative AI Semanticsに基づいていると説明されています。(Microsoft Learn)
コーディングエージェントの場合、エージェントやIDEでOTLP信号をエクスポートし、OpenTelemetry CollectorがOTLPデータを受け取り、Azure Monitorへ転送する流れが示されています。組織全体の環境変数、プロジェクト設定、共有リポジトリ設定でOTLPの送信先を統一することが推奨される場面もあります。(Microsoft Learn)
開発チームでは、次を確認してください。
| 確認項目 | 実務での判断基準 |
|---|---|
| OTLP endpoint | 開発・検証・本番で送信先が分かれているか |
| service.name | エージェントやIDEごとに識別できる命名になっているか |
| agent.name | Copilot、社内FAQエージェント、コード修正エージェントなど用途別に判別できるか |
| resource attributes | 部門、チーム、環境、アプリ名で絞り込めるか |
| Collector設定 | 認証、ネットワーク、再送、フィルタリングを考慮しているか |
| ローカル開発 | 開発者の個人情報や未公開コードが不用意に送信されないか |
特にservice.nameやエージェント名が曖昧だと、ダッシュボードでは「何かのAIエージェントが遅い」ことしか分かりません。あとから直すより、初期展開時に命名規則を決めるほうが運用コストを抑えられます。
プロンプトや会話内容の収集は慎重に扱う
Agent details viewでは、機密データのログ取得が有効な場合、プロンプト内容を検索できます。また、EnableSensitiveDataのような設定で完全なプロンプト情報を収集すると、SearchビューやTransaction Detailsビューで会話、アシスタントメッセージ、システムプロンプト、ツール利用を確認できると説明されています。(Microsoft Learn)
これは障害調査には便利ですが、セキュリティ面ではリスクがあります。プロンプトには、顧客情報、社内コード、設計情報、認証情報、未公開の仕様が含まれる可能性があります。
VS CodeのCopilot Chat向けOpenTelemetryドキュメントでは、既定ではプロンプト内容、応答、ツール引数は収集されず、モデル名、トークン数、所要時間などのメタデータのみが含まれると説明されています。完全な内容を収集する場合は明示的に設定を有効化する必要があり、コード、ファイル内容、ユーザープロンプトなどの機密情報を含む可能性があるため、信頼できる環境でのみ有効化すべきとされています。(Visual Studio Code)
本番環境では、次のようなルールを決めておくと安全です。
| 判断項目 | 推奨される考え方 |
|---|---|
| 通常運用 | プロンプト全文ではなく、メタデータ中心で監視する |
| 障害調査 | 期間・対象環境・閲覧者を限定して一時的に詳細収集する |
| 個人情報を扱う業務 | 原則として内容収集を避け、必要な場合はマスキングや承認を必須にする |
| ソースコードを扱う開発支援 | リポジトリURL、ブランチ、ファイルパス、ツール引数の扱いを事前に確認する |
| 監査対応 | 収集対象、保持期間、閲覧権限、削除方針を文書化する |
Agent details viewで見るべき実務ポイント
障害調査では「Gen AI Errors」から入る
AIエージェントで障害が起きたときは、まずAgent details viewから「View Traces with Gen AI Errors」を使い、失敗または問題のある実行に絞り込みます。公式ドキュメントでは、Agent Runs、Gen AI Errors、Tool CallsやModelsのタイルからSearch overlayを開き、該当するトレースを確認できると説明されています。(Microsoft Learn)
実務では、次の順で見ると原因に近づきやすくなります。
| 調査手順 | 見るポイント |
|---|---|
| 時間範囲を絞る | 問い合わせ発生時刻、リリース直後、外部API障害時間帯に絞る |
| Gen AI Errorsを見る | LLM呼び出し、ツール実行、認証、タイムアウトのどこで失敗したか確認する |
| End-to-end transaction detailsを開く | エージェント、LLM、ツール呼び出しの流れを時系列で追う |
| 直前の変更を照合する | プロンプト、モデル、ツール権限、外部API、環境変数の変更を確認する |
| 再発防止を決める | アラート、リトライ、タイムアウト、プロンプト短縮、ツール権限見直しを行う |
AIエージェントの障害では、アプリケーション例外だけを見ても原因が分からないことがあります。たとえば「回答生成に失敗した」と見えても、実際には検索ツールの権限不足、MCPサーバーの応答遅延、LLMの出力制限、過大なコンテキスト投入が原因の場合があります。
コスト調査では「Most tokens used」を見る
AIエージェントのコスト増加は、単に利用者数が増えた場合だけではありません。長すぎるプロンプト、不要な会話履歴、過剰なRAGコンテキスト、高価なモデルの固定利用、ループに近いツール呼び出しでも発生します。
Application InsightsのSearchでは、Most tokens usedなどのメトリックでトレースを並べ替え、高コストな操作を特定できると説明されています。公式ドキュメントの例でも、大きなプロンプトコンテキストと高価なモデルがトークン使用量とコストを押し上げるケースが示されています。(Microsoft Learn)
高トークンのトレースを見つけたら、次を確認してください。
| 確認項目 | 改善例 |
|---|---|
| 入力トークンが多い | RAGで渡す文書数を減らす、要約済みコンテキストを使う、履歴を短縮する |
| 出力トークンが多い | 回答形式を指定する、最大出力長を調整する、不要な説明を抑える |
| モデルが高価 | タスクごとに小型モデル・大型モデルを使い分ける |
| ツール呼び出しが多い | プロンプトで実行条件を明確化する、同じ検索を繰り返さない設計にする |
| 失敗後の再試行が多い | リトライ回数、タイムアウト、エラー時のフォールバックを見直す |
応答遅延ではLLMとツールのどちらが遅いか分ける
AIエージェントの応答遅延は、LLMそのものが遅い場合と、外部ツールや社内APIが遅い場合で対策が変わります。End-to-end transaction detailsのシンプルビューでは、呼び出されたエージェント、基盤となるLLM、実行されたツールなどを分かりやすい流れで確認できます。必要に応じて従来ビューに戻ることもできます。(Microsoft Learn)
遅延調査では、次のように切り分けます。
| 遅い箇所 | よくある原因 | 対策 |
|---|---|---|
| LLM呼び出し | 入力が長い、モデルが大きい、出力が長い | コンテキスト圧縮、モデル切り替え、出力形式の制限 |
| 検索ツール | 検索範囲が広い、インデックス不足 | 検索条件の明確化、検索対象の分割、キャッシュ |
| 外部API | API側の遅延、認証再試行、レート制限 | タイムアウト設計、リトライ制御、非同期化 |
| MCP/ツール実行 | ツール引数が大きい、処理が重い | 引数削減、ツール単位のメトリック化、処理分割 |
| エージェント制御 | LLMとツールの往復が多い | 手順の明確化、ツール利用条件の制限、終了条件の追加 |
移行時に注意すべきポイント
既存のApplication Insights SDKからの移行
既存のApplication Insights SDKを使っているアプリでは、Azure Monitor OpenTelemetryへの移行方針を確認する必要があります。MicrosoftのApplication Insights OpenTelemetry概要では、古いApplication Insights SDKから移行する場合はAzure Monitor OpenTelemetryへの移行情報を参照するよう案内されています。(Microsoft Learn)
移行時に避けたいのは、従来SDKとOpenTelemetryの両方から同じデータを二重送信してしまうことです。ログ量が増えるだけでなく、ダッシュボード上で件数が過大に見え、障害率や利用状況の判断を誤る可能性があります。
移行時は、次の順で進めると安全です。
| フェーズ | 作業内容 |
|---|---|
| 棚卸し | 既存のApplication Insights SDK、接続文字列、ログ出力先、カスタムイベントを確認する |
| 検証 | 開発環境でOpenTelemetry送信を有効化し、トレース構造と属性名を確認する |
| 並行稼働 | 短期間だけ旧方式と新方式を比較し、欠落・重複・コスト増を確認する |
| 切り替え | 本番の送信経路を整理し、不要な旧設定を削除する |
| 定着 | ダッシュボード、アラート、運用手順書を新しい属性・ビューに合わせる |
OpenTelemetry GenAI Semanticsは変化に備える
Azure MonitorのAIエージェント監視はOpenTelemetry Generative AI Semanticsを基盤にしていますが、OpenTelemetry側のGenerative AIセマンティック規約はDevelopmentステータスとして掲載されています。既存のGenAI計装については、既定で出力する規約バージョンを安易に変えないことや、OTEL_SEMCONV_STABILITY_OPT_INによる移行方針が示されています。(OpenTelemetry)
つまり、KQLクエリやGrafanaダッシュボードを作るときは、属性名の変更に備えた設計が必要です。
実務では、次の工夫が有効です。
- ダッシュボードのクエリを直接大量に複製せず、共通クエリやテンプレートで管理する
gen_ai.*系の属性に依存する箇所を一覧化する- 重要なダッシュボードは検証環境で先にアップデート確認する
- 計装ライブラリやエージェントのバージョンを本番で無計画に上げない
- 属性名変更に備え、旧キーと新キーの両方を一時的に扱えるクエリを検討する
特に、経営層向けのコストレポートやSLA報告に使うダッシュボードでは、属性変更による集計欠落が大きな問題になります。監視基盤は「見えれば終わり」ではなく、バージョン更新に耐えられる形で管理することが重要です。
展開前チェックリスト
本番環境に展開する前に、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| 監視対象の棚卸し | Foundry、Copilot Studio、自前エージェント、コーディングエージェントを一覧化したか |
| Application Insightsリソース | 既存集約か専用分離かを決めたか |
| エージェント名 | 用途・環境・チームが分かる命名にしたか |
| データ収集方式 | Foundry、Copilot Studio、OpenTelemetry、OTLP Collectorなどの経路を決めたか |
| 権限 | 閲覧、ダッシュボード作成、設定変更のRBACを分けたか |
| 機密データ | プロンプト、応答、ツール引数、コード内容を収集するか決めたか |
| ログ保持 | 調査に必要な期間とコストのバランスを決めたか |
| ダッシュボード | 標準ビュー、Grafana、部門別ビューの役割を分けたか |
| アラート | エラー率、応答遅延、トークン急増、ツール失敗を検知できるか |
| 移行計画 | 旧SDKや既存監視との重複・欠落を確認したか |
| 運用手順 | 障害時に誰がどのビューを見るか決めたか |
失敗しやすいポイント
監視データを集めすぎる
AIエージェント監視では、詳細に集めれば集めるほど調査は楽になります。しかし、プロンプト全文、応答全文、ツール引数、ファイルパス、コード断片まで収集すると、セキュリティリスクとコストが上がります。
最初からすべて収集するのではなく、通常運用ではメタデータ中心、障害調査時のみ詳細化する設計が現実的です。
エージェント名が曖昧で切り分けできない
agent、chatbot、copilotのような名前だけでは、本番障害時に役に立ちません。
たとえば、次のように用途と環境を含めると運用しやすくなります。
| 悪い例 | 改善例 |
|---|---|
agent | sales-faq-agent-prod |
copilot | dev-coding-copilot-team-a |
support-bot | support-rag-agent-stg |
test | hr-policy-agent-dev |
Preview機能を既存監視の完全代替にしてしまう
Agents（Preview）はAIエージェント監視の重要な入口ですが、既存のアプリ監視、ログ検索、アラート、SLA監視をすぐに置き換えるものとして扱うのは危険です。
本番では、従来のApplication InsightsのFailures、Performance、Logs、Alertsと組み合わせ、AIエージェント特有の原因分析をAgentsビューで補完する形が安全です。Application Insightsには、アプリケーションダッシュボード、アプリケーションマップ、ライブメトリック、Search、Failures、Performance、Logs、Workbooksなど複数の診断・監視機能が用意されています。(Microsoft Learn)
Grafanaダッシュボードを作りっぱなしにする
Grafanaは便利ですが、ダッシュボードを増やしすぎると、どれが正式な監視画面か分からなくなります。保存したGrafanaダッシュボードはAzureリソースとして管理できるため、正式版、検証版、個人用を分け、命名規則と所有者を明確にしておくべきです。(Microsoft Learn)
管理者・開発者が次に取るべき行動
Azure MonitorでAIエージェントを監視するには、Application InsightsのAgents（Preview）を見るだけでなく、テレメトリ設計、権限、データ収集範囲、ダッシュボード、移行計画をセットで考える必要があります。
まずは、自社で使っているAIエージェントを「Foundry」「Copilot Studio」「自前実装」「コーディングエージェント」「サードパーティー フレームワーク」に分けて棚卸ししてください。次に、どのApplication Insightsリソースへ送るか、プロンプト内容を収集するか、誰が閲覧できるかを決めます。
そのうえで、検証環境で1つのエージェントからテレメトリを流し、Agent details viewで次を確認すると導入判断がしやすくなります。
- Agent Runsに実行履歴が表示されるか
- Gen AI Errorsで失敗トレースを絞り込めるか
- End-to-end transaction detailsでLLMとツール呼び出しの流れを追えるか
- Most tokens usedで高トークンの実行を特定できるか
- Grafanaダッシュボードでチームが見たい指標を表現できるか
- プロンプトやツール引数など、機密データの扱いが社内ルールに合っているか
AIエージェントの運用では、精度改善、コスト削減、障害対応、セキュリティが密接につながります。Azure MonitorとApplication InsightsのAgentsビューは、その共通の観測基盤になります。まずは小さく検証し、命名・権限・収集範囲を固めてから、本番エージェントへ段階的に展開するのが安全です。
コメント