Agent observabilityは、Microsoft Agent 365で動くAIエージェントの「呼び出し」「ツール実行」「推論」「出力」を追跡し、管理者がMicrosoft 365管理センター、Microsoft Defender、Microsoft Purviewで監査・調査しやすくするための仕組みです。今回の公式情報で特に重要なのは、開発者はMicrosoft OpenTelemetry Distroを使った実装を優先し、既存実装を更新する場合はAgent365.Observability.OtelWrite権限やトークン解決、tenant ID / agent IDの伝播を必ず確認する必要がある点です。(Microsoft Learn)
AIエージェントは、ユーザーの質問に答えるだけでなく、メール検索、ファイル参照、外部API呼び出し、他エージェントとの連携まで行うようになっています。つまり、障害調査では「エラーが出たか」だけでなく、「どのエージェントが、誰の依頼で、どのツールを、どのテナント権限で、どのモデルに対して使ったか」を追えることが重要になります。Agent observabilityは、この追跡性をMicrosoft 365の管理・監査の文脈に乗せるための実装ポイントです。
MicrosoftのAgent observabilityで何が変わるのか
Microsoftの公式情報では、Agent 365 ObservabilityはOpenTelemetryを土台にし、Agent 365、Microsoft Foundry、Azure Monitorなどをまたいでテレメトリを扱う方向に整理されています。特に「Microsoft OpenTelemetry Distro」が推奨されており、従来の個別パッケージや個別設定をまとめ、1つの導入体験でトレース、メトリック、ログを収集できる構成になっています。既存のAgent 365 Observability SDKによる実装は破壊的変更なしに継続利用できるとされていますが、新規実装や将来の標準化を考えるなら、Microsoft OpenTelemetry Distroへの移行方針を確認しておくべきです。(Microsoft Learn)
実務上の変更点は、次の3つに集約できます。
| 観点 | これまで起きやすかった課題 | 今回確認すべきこと |
|---|---|---|
| 実装方式 | 言語やフレームワークごとに監視実装が分散しやすい | Microsoft OpenTelemetry Distroで統一できるか確認する |
| 管理者の可視化 | エージェントの実行履歴、ツール呼び出し、推論の追跡が不足しやすい | Microsoft 365管理センターでActivityにセッションやツール呼び出しが出るか確認する |
| 認証・権限 | トークン、スコープ、Entra権限の不足でエクスポートが失敗しやすい | Agent365.Observability.OtelWrite、token resolver、管理者同意を確認する |
ここで重要なのは、Agent observabilityが単なるログ出力ではないことです。アプリケーションログのように「処理が成功した」「例外が出た」を記録するだけでは、AIエージェントのガバナンスには足りません。エージェントの呼び出し、ツールの引数と結果、モデル推論、トークン使用量、最終出力を、同じリクエストの文脈でつなげて見る必要があります。
影響を受けるエージェントと対象範囲
公式ドキュメントでは、Agent 365 observabilityの対象として、Microsoft Agent 365-enabled agents、Custom engine agents、Declarative agentsが示されています。Microsoft Agent 365-enabled agentsとCustom engine agentsではSDKによるインストルメンテーションが必要で、Declarative agentsは標準で可観測性がサポートされ、SDK実装は不要とされています。(Microsoft Learn)
| エージェント種別 | 開発者の対応 | 管理者の確認ポイント |
|---|---|---|
| Microsoft Agent 365-enabled agents | SDKまたはMicrosoft OpenTelemetry Distroで実装 | 管理センター上でアクティビティが確認できるか |
| Custom engine agents | 呼び出し、ツール、推論、出力を明示的に計測 | tenant ID / agent IDが正しく付与されているか |
| Declarative agents | SDK実装は不要 | 組織の監査・管理要件に合う形で可視化されているか |
特に注意したいのは、カスタムエンジン型のエージェントです。独自ランタイムや外部フレームワークを使っている場合、「動作はしているが管理センターに何も出ない」という状態になりやすくなります。この場合、アプリケーション側のログだけを見ても原因が分からず、Agent 365 exporterの有効化、token resolver、BaggageBuilderによるID伝播を順番に確認する必要があります。
開発者が最初に確認すべき実装方針
新規開発なら、まずMicrosoft OpenTelemetry Distroを検討します。Distroは.NET、Node.js、Pythonをサポートし、Agent 365、Azure Monitor、OTLP互換バックエンドにテレメトリを送れる構成です。Pythonではmicrosoft-opentelemetry、Node.jsでは@microsoft/opentelemetry、.NETではMicrosoft.OpenTelemetryを利用する形で説明されています。(Microsoft Learn)
既存エージェントを運用中の場合は、いきなり全面移行するより、次の順で棚卸しすると安全です。
| 確認項目 | 判断基準 | 対応の目安 |
|---|---|---|
| 現在の実装 | 既存のAgent 365 Observability SDKを使っているか | 破壊的変更はないため、まず動作継続を確認 |
| 対象言語 | Python、Node.js、.NETのどれか | Distroの対応状況に合わせて移行計画を作る |
| 利用フレームワーク | Semantic Kernel、OpenAI、Agent Framework、LangChainなど | 自動インストルメンテーション対応可否を確認 |
| 監査要件 | Defender / Purviewで見たいか | Purview監査、Defender Advanced Huntingの準備も確認 |
| ストア公開 | Agent 365 Store公開を想定するか | 必須スコープの実装漏れを事前検証 |
Distroを使う場合でも、エージェント固有の操作をすべて自動で推測できるわけではありません。HTTPやAzure SDKのような一般的なアプリケーション計測は自動化しやすい一方、エージェントの呼び出し、ツール実行、推論、非同期出力の意味付けは、必要に応じて手動スコープで補う必要があります。(Microsoft Learn)
必須になる4つのスコープを理解する
Agent observabilityの実装では、何をどの粒度で記録するかが重要です。公式ドキュメントでは、手動インストルメンテーション用にInvokeAgentScope、ExecuteToolScope、InferenceScope、OutputScopeが示されています。(Microsoft Learn)
| スコープ | 記録する内容 | 実務での使いどころ |
|---|---|---|
InvokeAgentScope | エージェント呼び出し、入力、出力、ユーザー、会話ID | ユーザーがエージェントを呼び出した入口を追跡する |
ExecuteToolScope | ツール名、ツール種別、引数、結果 | メール検索、CRM更新、SharePoint参照などの外部操作を監査する |
InferenceScope | モデル名、プロバイダー、入力・出力、トークン使用量 | Azure OpenAIなどの推論呼び出しを分析する |
OutputScope | 非同期処理後の最終出力 | 親スコープ終了後に結果が返るワークフローを補足する |
ストア公開を想定する場合、InvokeAgentScope、InferenceScope、ExecuteToolScopeの実装が必要とされています。公開前には、コンソールログで必須属性が揃っているかを確認し、エージェントのログと属性一覧を突き合わせる必要があります。(Microsoft Learn)
たとえば、メール整理エージェントなら次のように考えると分かりやすくなります。
| 処理 | 対応するスコープ | 記録したい情報 |
|---|---|---|
| ユーザーが「上司からの重要メールを整理して」と依頼 | InvokeAgentScope | ユーザー、会話ID、入力メッセージ、エージェントID |
| メール検索ツールを呼び出す | ExecuteToolScope | ツール名、検索条件、ツール呼び出しID、結果 |
| 取得したメールを要約する | InferenceScope | モデル名、入力・出力トークン、応答理由 |
| 整理結果を後からTeamsへ投稿 | OutputScope | 最終出力メッセージ、親スパンとの関連 |
この整理をしないまま「とりあえずログだけ出す」と、障害調査時に「どのツール呼び出しが問題だったのか」「モデル推論の前後で何が変わったのか」が追えません。AIエージェントでは、処理の成功・失敗だけでなく、意思決定に関係する操作の流れを再現できることが重要です。
自動インストルメンテーションの対応範囲
Agent observabilityでは、対応フレームワークを使っている場合、自動インストルメンテーションでテレメトリ収集を簡略化できます。公式情報では、.NETはSemantic Kernel、OpenAI、Agent Framework、PythonはSemantic Kernel、OpenAI、Agent Framework、LangChain、Node.jsはOpenAI、LangChainに対応する形で説明されています。対応状況は言語やSDKの実装により異なるため、利用中のフレームワークごとに確認が必要です。(Microsoft Learn)
| 言語 | 主な対応フレームワーク | 注意点 |
|---|---|---|
| Python | Semantic Kernel、OpenAI Agents SDK、Agent Framework、LangChain | 対応範囲が広いが、BaggageBuilderでIDを設定する必要がある |
| Node.js | OpenAI、LangChain | Semantic KernelやAgent Frameworkは対象外として示されている箇所がある |
| .NET | Semantic Kernel、OpenAI、Agent Framework | LangChainは対象外として扱われている |
自動インストルメンテーションを使っても、tenant IDとagent IDの設定を省略してはいけません。公式ドキュメントでは、サポート対象フレームワークでもBaggageBuilderを使ってagent IDとtenant IDを設定する必要があると説明されています。IDがないスパンはエクスポート前に除外され、管理センターに表示されない原因になります。(Microsoft Learn)
管理者が確認すべき設定と権限
管理者が最初に確認すべきなのは、「エージェントが動いているか」ではなく、「組織の管理画面・監査基盤にテレメトリが届く状態になっているか」です。
Agent 365 exporterを使う場合、token resolverが認証トークンを返す必要があります。Microsoft OpenTelemetry Distroでも、Agent 365 exporterは接続文字列ではなく、tenantに基づいてエンドポイントを検出し、agent IDとtenant IDに対してアクセストークンを返すtoken resolverを使います。(Microsoft Learn)
| 確認項目 | 確認する場所 | 失敗した場合に起きること |
|---|---|---|
| Agent 365 exporterが有効か | 環境変数、コード、appsettings | コンソール出力だけになり、サービスへ送信されない |
| token resolverが実装済みか | アプリケーションコード | エクスポートがスキップ、または401になる |
| tenant ID / agent IDが付与されるか | BaggageBuilder、TurnContext | スパンが送信前に破棄される |
Agent365.Observability.OtelWrite権限があるか | Managed Identityまたはアプリ登録 | HTTP 403でエクスポート失敗 |
| Purview監査が有効か | Microsoft Purview | エクスポート成功後も監査ログで見えない |
| Defender Advanced Huntingが使えるか | Microsoft Defender | CloudAppEventsで調査できない |
Microsoft Purviewでエージェントテレメトリを見るには組織で監査が有効である必要があり、Microsoft DefenderではAdvanced HuntingでCloudAppEventsテーブルへアクセスできる構成が必要です。エクスポート自体が成功していても、これらの前提が整っていないとDefenderやPurview側で見えないことがあります。(Microsoft Learn)
既存エージェント更新時の移行注意点
既存エージェントを更新する場合、最も見落としやすいのはAgent365.Observability.OtelWrite権限です。公式ドキュメントでは、既存エージェントを.NET 0.3-beta、Node.js 0.2.0-preview.1、Python 0.3.0以上へアップグレードする場合、Managed Identityまたはアプリ登録に新しいAgent365.Observability.OtelWrite権限を付与しないとHTTP 403でテレメトリのエクスポートに失敗すると説明されています。(Microsoft Learn)
| プラットフォーム | 追加確認が必要な最小バージョン | 必要な対応 |
|---|---|---|
| .NET | 0.3-beta | Agent365.Observability.OtelWriteを付与 |
| Node.js | 0.2.0-preview.1 | Agent365.Observability.OtelWriteを付与 |
| Python | 0.3.0 | Agent365.Observability.OtelWriteを付与 |
権限付与は、Agent 365 CLIまたはMicrosoft Entra管理センターから行う方法が示されています。CLIを使う場合は、構成ディレクトリにa365.config.jsonとa365.generated.config.jsonがあり、Global AdministratorアカウントとAgent 365 CLI v1.1.139-preview以降が必要とされています。Entra管理センターで行う場合は、Blueprint app registrationに対してDelegated permissionsとApplication permissionsの両方でAgent365.Observability.OtelWriteを追加し、管理者同意を付与します。(Microsoft Learn)
実務では、次の順番で移行作業を進めると失敗を減らせます。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 事前確認 | 現在のSDKバージョン、実行環境、認証方式を確認 | 影響を受けるエージェント一覧がある |
| 権限確認 | Managed Identityまたはアプリ登録の権限を確認 | Agent365.Observability.OtelWriteが付与されている |
| ローカル検証 | exporterを無効化し、コンソールへスパンを出す | 必須属性がログに出ている |
| ステージング検証 | exporterを有効化し、401/403/429/5xxを確認 | 管理センターでActivityが見える |
| 本番展開 | 段階的にロールアウト | エラー率、欠落スパン、遅延を監視できる |
移行時に「権限だけ追加すればよい」と考えるのは危険です。tenant IDやagent IDがBaggageBuilderで正しく設定されていない場合、権限があってもスパンは送信対象になりません。逆に、BaggageBuilderが正しくてもtoken resolverが誤ったaudienceのトークンや期限切れトークンを返すと、401で失敗します。
Agent 365 CLIを使う場合の設定注意点
2026年5月13日に更新された関連公式情報では、Agent 365 CLIがMicrosoft Entra IDテナント内のカスタムクライアントアプリ登録を必要とすること、アプリ登録、リダイレクトURI、Application client ID、API権限、widsロールクレームの設定が整理されています。CLIでエージェントIDブループリントを扱う場合、開発者だけで完結せず、管理者ロールを持つ担当者との連携が必要になる場面があります。(Microsoft Learn)
CLI設定で特に重要なのは、Delegated permissionsを使う点です。公式ドキュメントでは、CLIは対話的にサインインし、ユーザーの代理として動作するため、Application permissionsではなくDelegated permissionsを使用する必要があると説明されています。(Microsoft Learn)
| 設定項目 | 注意点 |
|---|---|
| アプリ登録名 | Agent 365 CLIにすると、config-freeのa365 setup all --agent-nameで解決しやすい |
| アカウント種別 | Single tenantを使う |
| リダイレクトURI | http://localhost:8400/、http://localhost、WAM用URIが必要 |
| API権限 | Delegated permissionsを使う |
| beta権限 | Entra管理センターに表示されない場合がある |
widsクレーム | CLIが管理者ロールを判定するために使う |
beta権限がMicrosoft Entra管理センターに表示されない場合、Graph APIで権限を追加する方法が示されています。この場合、Graph APIのconsentType: "AllPrincipals"で管理者同意が付与されるため、その後にEntra管理センターの「Grant admin consent」を押すと、表示されないbeta権限が削除される可能性があります。これは設定ミスとして非常に起きやすいため、管理者向け手順書に明記しておくべきです。(Microsoft Learn)
ローカル検証と本番確認の流れ
Agent observabilityの実装後は、いきなり本番で管理センター表示だけを見るのではなく、まずローカルでスパンが生成されているか確認します。公式ドキュメントでは、ENABLE_A365_OBSERVABILITY_EXPORTERをfalseにするとスパンをコンソールへ出力でき、エクスポート失敗の調査では詳細ログを有効化してtoken解決、送信件数、HTTPステータス、correlation IDなどを見る流れが示されています。(Microsoft Learn)
検証の順番は次のとおりです。
| 段階 | 目的 | 見るべきポイント |
|---|---|---|
| ローカル | スパン生成の確認 | 入力、出力、tool call、model、tenant ID、agent IDが出ているか |
| ステージング | エクスポートの確認 | HTTP 200、correlation ID、スキップされたスパン数 |
| 管理センター | 管理者視点の確認 | エージェントのActivityにsessionsとtool callsが出るか |
| Defender / Purview | セキュリティ・監査確認 | Purview監査、Defender Advanced Huntingの前提が満たされているか |
Microsoft 365管理センターでは、エージェント一覧から対象エージェントを選び、Activityでsessionsとtool callsが見えることが確認ポイントとして示されています。(Microsoft Learn)
よくある失敗と対処法
Agent observabilityのトラブルは、実装ミスよりも「認証・ID伝播・前提設定」の抜けで起きることが多いです。代表的な症状と確認順を整理します。
| 症状 | 主な原因 | 最初に確認すること |
|---|---|---|
| 管理センターにデータが出ない | exporter未有効、設定ミス、token resolver不備 | Agent 365 exporterが明示的に有効か |
| スパンが送られない | tenant IDまたはagent IDがない | BaggageBuilderがスパン作成前に設定されているか |
| 401 Unauthorized | token audience不一致、期限切れ、誤ったトークン | token resolverが正しいBearer tokenを返すか |
| 403 Forbidden | ライセンス不足、権限不足 | Agent365.Observability.OtelWriteと管理者同意 |
| 429 / 5xx | 一時的なサービス・負荷問題 | リトライ、バッチ間隔、サービス正常性 |
| Defender / Purviewに出ない | 表示側の前提不足 | Purview監査、Defender Advanced Hunting |
HTTP 429や5xxについては、PythonとJavaScript SDKではHTTP 408、429、5xxに対して最大3回の指数バックオフリトライが行われる一方、.NET SDKでは自動リトライしないと説明されています。大量のツール呼び出しや推論を短時間に送信するエージェントでは、バッチ間隔や最大バッチサイズの調整も検討します。(Microsoft Learn)
なお、HTTP 403が出た場合は、ライセンス不足と権限不足を切り分けます。公式ドキュメントでは、Test – Microsoft 365 E7、Microsoft 365 E7、Microsoft Agent 365 Frontierのいずれかが必要なライセンスとして示されています。実際の契約や提供状況は時期やテナントにより変わる可能性があるため、導入前にMicrosoft 365管理センターや契約担当者で確認してください。(Microsoft Learn)
管理者と開発者で分担すべきこと
Agent observabilityは、開発者だけで完結する機能ではありません。開発者はスコープ実装やID伝播を担い、管理者はEntra権限、ライセンス、Purview、Defender、管理センター表示を確認する必要があります。
| 役割 | 主な担当 | 成果物 |
|---|---|---|
| 開発者 | SDK / Distro導入、スコープ実装、token resolver、ローカル検証 | スパンが生成され、必須属性が揃っている状態 |
| Microsoft 365管理者 | ライセンス、Agent 365管理センター確認、管理者同意 | Activityでセッションとツール呼び出しが見える状態 |
| Entra管理者 | アプリ登録、Managed Identity、API permissions、widsクレーム | 認証・権限エラーが出ない状態 |
| セキュリティ担当 | Defender、Purview、監査要件、ログ保持ポリシー | 監査・調査に使えるクエリと運用手順 |
| 運用担当 | 障害対応、429/5xx、タイムアウト、サービス正常性確認 | エクスポート失敗時の切り分け手順 |
導入プロジェクトでは、「エージェントを作る」タスクと「エージェントを観測できる状態にする」タスクを分けて管理すると失敗しにくくなります。特に本番展開前のチェックリストには、次の項目を入れてください。
InvokeAgentScope、ExecuteToolScope、InferenceScopeが必要な箇所に入っている- 非同期出力がある場合は
OutputScopeで最終出力を補足している - tenant ID、agent ID、conversation IDがスパンに付与されている
- token resolverが正しいスコープのBearer tokenを返す
Agent365.Observability.OtelWriteが必要なIDに付与されている- Purview監査とDefender Advanced Huntingの前提が確認済み
- Microsoft 365管理センターでActivityを確認済み
- 401、403、429、5xx、timeout時の一次対応手順がある
まず取るべき次のアクション
Microsoft Agent 365のAgent observability対応では、最初からすべてを作り込むより、対象エージェントを1つ選び、呼び出し、ツール実行、推論、出力の4点を小さく検証するのが現実的です。管理センターにActivityが出るところまで確認できれば、次にDefenderやPurviewでの監査、バッチ設定、ストア公開要件へ進めます。
既存エージェントを運用している場合は、まずSDKバージョンとAgent365.Observability.OtelWrite権限を確認してください。新規開発の場合は、Microsoft OpenTelemetry Distroを前提に、使用言語、フレームワーク、自動インストルメンテーションの対応範囲を決めます。開発者、Entra管理者、Microsoft 365管理者、セキュリティ担当が同じチェックリストを使い、「動くエージェント」ではなく「監査できるエージェント」として展開することが、今回のAgent observability対応で最も重要なポイントです。
コメント