Microsoft Foundry tracing は「とりあえず全部記録」をやめて、本番 telemetry の責任に戻す

要点

要点まとめ

Foundry の tracing は debug 用の私的ログではなく、Application Insights と Azure Monitor に入る production telemetry として扱われる。
最初の一歩は code 改修ではなく、Application Insights 接続と RBAC 整備だ。server-side tracing は接続後すぐ使え、Prompt agents、Host agents、workflows に対して過去 90 日の trace を持てる。
client-side tracing を足すなら OpenTelemetry と Azure SDK plugin を使うが、その前提として Entra ID か connection string の整理が必要になる。
trace には prompt、tool arguments、outputs が入りうるため、secret や個人情報の扱いをログと同じ厳しさで考えないと危ない。

続けて読む

読み終えたら次へ

この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。

同じ目的で読む まず知りたい

新しい言葉や発表の意味を、短時間でつかみたい人向け。

同じテーマで読む AIエージェント

ツール利用、MCP、Agent SDK、長時間タスク、実行責任の設計。

次の記事 AI SDK Telemetry は「全部ログに残す雑さ」をやめろと言っている

AI の挙動を見えるようにしたいなら、prompt と出力を何でもかんでも保存する前に、本当に必要な観測項目と残してはいけない内容を分ける必要がある。

読解

何が変わったのか

この docs は tracing の始め方を「SDK を入れる」から始めていません。まず Foundry project に Application Insights を接続し、server-side traces を使えと言っています。つまり、観測の中心を agent app のローカル実装ではなく、プロジェクト単位の監視基盤へ置いています。さらに、trace を見る権限として `Log Analytics Reader`、場合によっては `Privileged Monitoring Data Reader` を要求し、RBAC を明示しています。会話履歴も Conversation ID と Trace ID の対応で追えるので、debug と audit の橋渡しをしやすい構造です。

日本の文脈

なぜ重要か

日本語圏では AI observability が「便利な debug log」へ縮みやすく、誰でも prompt を見られる状態で残す危険があります。この資料は、trace を logs と同じ統制対象に戻しています。PM や運用担当にとっても、観測設計はモデル改善だけでなく、権限、保持期間、コスト、個人情報の責任に直結します。見えること自体より、誰にどこまで見せるかの統制が先です。

技術ポイント

技術的ポイント

server-side tracing は Application Insights を Foundry project に接続すると使え、Foundry-hosted agent の一般的な trace を code 変更なしで取れます。
client-side tracing を追加する場合は OpenTelemetry と `azure-core-tracing-opentelemetry` などを使います。自前アプリの処理まで追いたい時の二段目と考えるべきです。
trace の保存先は Azure Monitor / Application Insights で、retention と課金はその設定に従います。つまり tracing は無料のメモではありません。
portal では trace 単位で span を見られ、Conversation ID と Trace ID をひも付けて user-agent 間の入出力や tool call を追えます。
docs 自体が、prompt、tool arguments、outputs に sensitive data が入りうると注意しています。redaction と minimization を前処理に入れないと危険です。

用語

英日キーワード

英語	日本語	補足
tracing	トレーシング / 実行追跡	処理の流れを span 単位で追う観測方法。debug log より本番 telemetry に近い。
Application Insights	Application Insights	Azure の telemetry 保存先。agent trace を誰が読めるかと retention をここで管理する。
OpenTelemetry	OpenTelemetry	trace や span を標準化して扱う observability 基盤。AI の遅延や失敗を追えるが、中身の記録範囲は別途設計が要る。
RBAC	ロールベース権限制御	誰が trace や運用情報を見られるかを役割で制御する方式。observability でも必須。
retention	保持期間	telemetry をどれだけ残すかの設定。便利さだけでなく privacy と cost を一緒に決める必要がある。
Conversation ID	会話 ID	会話単位で trace と結果を追う識別子。trace ID と結びつけると user-agent 間の流れを追いやすい。

試す

試すなら

tracing を入れる前に、誰が trace を読むのか決めて RBAC を設計する。
Application Insights を接続し、server-side traces だけで足りるかを先に確認する。
prompt、tool arguments、outputs のうち、残してはいけない項目を洗い出して redaction ルールを作る。
retention とコストを確認し、debug 目的の無制限保存を避ける。

注意

注意点

workflow と external agents は preview と明記されています。docs の通り、production 前提で同じ保証を置くのは早いです。
trace が見えることと、安全に運用できることは別です。特に機密情報の混入は observability 導入時の典型的な事故点です。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。