Azure AI FoundryでAIエージェントや社内Copilot型アプリを運用している場合、まず確認すべきことは明確です。トレースを有効化し、Application Insightsへの接続、権限、機密情報対策、コスト管理までセットで見直すことです。
Microsoft Learnの公式情報では、トレースはAIエージェントの遅延、例外、プロンプト内容、検索処理などを取得し、FoundryポータルやAzure Monitorで分析できる仕組みとして説明されています。障害調査だけでなく、回答品質、ツール呼び出し、ユーザー入力に対する挙動を確認するための運用基盤と考えるべきです。(Microsoft Learn)
なお、参照した公式ページではページ下部の最終更新日は2026年4月16日と表示されています。本記事では、2026年5月19日時点で確認できる公式内容をもとに、管理者・開発者が実務で確認すべきポイントを整理します。(Microsoft Learn)
Azure AI Foundryのトレース設定で何が重要になったのか
Azure AI Foundryにおけるトレースは、単なるデバッグ用ログではありません。AIエージェントの実行過程を、リクエスト単位・処理単位で追跡し、どこで遅延したのか、どのツールを呼び出したのか、どの入力や出力が問題につながったのかを確認するための可観測性機能です。
特に重要なのは、トレースの保存先がAzure Monitor Application Insightsである点です。Foundryポータル上で見える情報であっても、実体としては接続されたApplication Insightsリソースに保存されます。そのため、Azure管理者は「AI機能の設定」だけでなく、「監視リソース」「RBAC」「Log Analytics」「保持期間」「課金」まで含めて設計する必要があります。(Microsoft Learn)
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| Application Insights接続 | FoundryプロジェクトにApplication Insightsを接続してトレースを保存する | 接続しないと本格的なトレース確認ができない |
| 対象エージェント | Prompt agentsのトレースは一般提供、Workflow・hosted・custom agentsはプレビュー扱い | 本番適用の可否判断が必要 |
| サーバー側トレース | 一部の一般的なエージェント／ワークフローではコード変更なしでトレース可能 | まず運用側で切り分けしやすい |
| クライアント側トレース | Python SDKとOpenTelemetry関連パッケージでアプリ側の処理も追跡可能 | 独自アプリや外部フレームワークでは開発者の対応が必要 |
| VS Codeローカルトレース | Foundry ToolkitでローカルのOTLP互換コレクターを使った確認が可能 | 本番環境に送る前に開発環境で検証できる |
| セキュリティ | プロンプト、モデル出力、ツール引数、ツール結果などが記録される可能性がある | 個人情報・認証情報・業務機密の混入対策が必須 |
| コストと保持期間 | Application InsightsとLog Analyticsの設定に従う | 取り込み量・保持期間・検索頻度によって費用が変わる |
影響を受ける利用者と担当範囲
Azure AI Foundryのトレース設定は、開発者だけの作業では完結しません。Application Insights、Azure Monitor、Microsoft Entra ID、RBAC、ログ保持、セキュリティレビューが関係するため、複数の担当者で確認する必要があります。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| Azure管理者 | Application Insights接続、権限、Log Analytics連携を管理する | Foundryプロジェクトに正しいApplication Insightsが接続されているか |
| 開発者 | SDKやOpenTelemetryでアプリ側のトレースを実装する | サーバー側トレースだけで足りるか、クライアント側計測が必要か |
| セキュリティ担当 | プロンプトや出力に含まれる機密情報を評価する | トレースに個人情報、トークン、認証情報が残らない設計になっているか |
| 運用・SRE担当 | 障害調査、遅延分析、失敗率の確認に使う | トレースの検索・閲覧権限が付与されているか |
| プロジェクト責任者 | プレビュー機能の本番利用可否を判断する | Workflow、hosted、custom agentsを本番に使う場合のリスクを文書化しているか |
公式情報では、プレビュー項目はSLAなしで提供され、本番ワークロードには推奨されないと説明されています。また、Prompt agentsのトレースは一般提供である一方、Workflow、hosted、custom agentsはプレビュー扱いです。(Microsoft Learn)
管理者が確認すべき設定
Application InsightsがFoundryプロジェクトに接続されているか
最初に確認すべき設定は、FoundryプロジェクトとApplication Insightsの接続です。公式手順では、Microsoft Foundryにサインインし、New Foundryトグルを有効にした状態でプロジェクトを開き、AgentsからTracesを選択してApplication Insightsを接続します。既存リソースを選ぶことも、新規作成することもできます。(Microsoft Learn)
管理者は、次の点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 接続先リソース | 本番・検証・開発でApplication Insightsを分けているか |
| サブスクリプション | 運用チームが管理できるサブスクリプション配下にあるか |
| リソースグループ | Foundryプロジェクトと監視リソースの管理責任が明確か |
| リージョン | 組織のデータ管理ポリシーに合っているか |
| 命名規則 | どのAIエージェントのトレースか判別できる名前になっているか |
Traces画面に接続ボタンやメッセージバーが表示されない場合は、Project detailsからConnected resourcesに進み、Add connectionでApplication Insightsを追加する代替手順も示されています。(Microsoft Learn)
RBACとLog Analytics Reader権限を確認する
トレースを保存できても、閲覧・検索できなければ運用では使えません。公式情報では、ログベースのクエリを使う場合はLog Analytics Readerロールから始めること、権限管理を大規模に行う場合はMicrosoft Entraグループを使うことが案内されています。(Microsoft Learn)
権限設計では、次のような分け方が現実的です。
| ロール設計 | 付与対象の例 | 注意点 |
|---|---|---|
| 閲覧のみ | 運用監視チーム、QA担当 | 機密情報を含む可能性があるため最小人数にする |
| クエリ実行 | SRE、開発リード | Log Analytics Reader相当の権限を確認する |
| リソース管理 | Azure管理者 | Application Insightsや保持期間を変更できるため厳格に管理する |
| セキュリティレビュー | セキュリティ担当 | 監査目的で必要最小限の閲覧権限を付与する |
「エージェントの担当者だから全員に閲覧権限を付ける」という設計は避けるべきです。トレースにはユーザー入力やモデル出力が含まれる可能性があるため、通常のアプリケーションログよりも慎重に扱う必要があります。
保持期間と課金を見直す
トレースデータの保持期間と課金は、接続先のApplication InsightsとLog Analyticsの構成に従います。つまり、Foundry側だけを見てもコスト管理は完結しません。(Microsoft Learn)
本番展開前に、少なくとも次の3点を決めておきましょう。
| 項目 | 決めること |
|---|---|
| 保持期間 | 障害調査、監査、改善分析に必要な期間 |
| 取り込み量 | すべての会話を追跡するのか、サンプリングするのか |
| 環境分離 | 開発・検証・本番で監視リソースを分けるか |
AIエージェントは、1回のユーザー要求で複数のモデル呼び出し、検索、ツール実行を行うことがあります。そのため、通常のWeb APIよりもトレース量が増えやすい点に注意してください。
開発者が確認すべき実装ポイント
まずサーバー側トレースで切り分ける
最初からアプリケーションコードを大きく変更する必要はありません。公式情報では、Foundryプロジェクトでトレースを有効にすると、Prompt agents、Host agents、workflowsの一般的なシナリオでサーバー側トレースが自動的に記録されると説明されています。Foundryポータルでは、直近90日分のトレースを検索、フィルター、並べ替えできます。(Microsoft Learn)
サーバー側トレースで確認しやすいのは、次のような問題です。
| よくある問題 | トレースで見るポイント |
|---|---|
| 回答が遅い | どのspanで時間がかかっているか |
| ツール呼び出しが失敗する | どのツールが呼ばれ、どこで例外が出たか |
| RAGの回答が不自然 | 検索処理や取得結果が期待通りか |
| 同じ質問で結果がばらつく | 実行ステップや会話コンテキストが変化していないか |
まずはサーバー側トレースで大枠を把握し、それでも原因が分からない場合にクライアント側トレースを追加する流れが現実的です。
クライアント側トレースはSDKとOpenTelemetryで実装する
独自アプリケーションからAIエージェントを呼び出している場合や、アプリ側の前処理・後処理まで追跡したい場合は、クライアント側トレースが必要です。公式手順では、Python向けに次のパッケージをインストールする例が示されています。(Microsoft Learn)
pip install azure-ai-projects azure-identity opentelemetry-sdk azure-core-tracing-opentelemetryまた、アプリケーションでプロジェクトのエンドポイントを使う場合はMicrosoft Entra IDの構成が必要です。Entra IDを構成しない場合は、Application Insightsの接続文字列を使う案内がされています。(Microsoft Learn)
本番コードに組み込む際は、次の点を確認してください。
| 確認項目 | 注意点 |
|---|---|
| 認証方式 | 本番では接続文字列やシークレットの直書きを避ける |
| 環境変数 | 開発・検証・本番で接続先を分ける |
| span名 | どの処理を表すのか分かる名前にする |
| 機密情報 | プロンプト、ツール引数、属性値に認証情報を入れない |
| 例外処理 | 失敗時にも追跡できるようにする |
LangChainやOpenAI Agents SDKを使う場合は統合方式を確認する
Azure AI Foundryは、Microsoft Agent Framework、LangChain、LangGraph、OpenAI Agents SDKなどのエージェントフレームワーク向けにトレース統合を提供しています。特にLangChainやLangGraphでは、Python環境やlangchain-azure-aiパッケージの要件、callback設定の有無がトレース表示に影響します。(Microsoft Learn)
フレームワークを使う場合に失敗しやすいのは、「モデル呼び出しは見えているが、ツール呼び出しやグラフ遷移が見えない」という状態です。この場合、トレーサーをcallbackに渡しているか、ツールがモデルに正しくバインドされているか、対象処理にspanが作られているかを確認してください。
VS Codeでローカルトレースを使い、クラウド送信前に検証する
Foundry Toolkitを使うと、VS Code上でローカルのOTLP互換コレクターを使ったトレース確認ができます。公式情報では、Foundry Agents Service、OpenAI、Anthropic、LangChainなどをOpenTelemetry経由でサポートし、クラウドアクセスなしで即時にトレースを確認できるとされています。(Microsoft Learn)
開発時は、次の順序で進めると安全です。
| 手順 | 作業内容 |
|---|---|
| ローカル確認 | VS Codeでトレースが出るか確認する |
| 検証環境送信 | 検証用Application Insightsに送信する |
| 機密情報確認 | プロンプトやツール引数に不要な情報が入っていないか見る |
| 本番反映 | RBAC、保持期間、監視手順を整えてから展開する |
セキュリティとプライバシーの注意点
Azure AI Foundryのトレースで最も見落としやすいのは、取得される情報の粒度です。公式情報では、トレースにはユーザー入力、モデル出力、ツール引数、ツール結果などの機密情報が含まれる可能性があると説明されています。(Microsoft Learn)
特に避けるべきなのは、次のような実装です。
| 危険な例 | なぜ問題か | 対策 |
|---|---|---|
| APIキーをプロンプトに含める | トレースに認証情報が残る可能性がある | Key Vaultや環境変数で管理する |
| 顧客の個人情報をそのままツール引数に渡す | Application Insightsに保存される可能性がある | マスキング、最小化、匿名化を行う |
| 社内文書の全文をspan属性に入れる | 閲覧権限を持つ人に内容が見える | 必要な識別子だけを記録する |
| 本番で詳細な内容記録を常時有効にする | 監査・漏えいリスクとコストが増える | 本番では記録範囲を制限する |
トレースは「開発者向けの便利なログ」ではなく、本番テレメトリとして扱うべきです。アクセス制御、保持期間、監査、削除方針を通常のログやメトリックと同じ水準で管理してください。
移行・展開時に見落としやすいポイント
Foundryの新ポータルとクラシック向け手順を混在させない
今回のトレース設定手順は、New Foundryトグルを有効にしたFoundryの新しい画面を前提としています。一方、Microsoft LearnにはFoundry classic向けの記事も存在し、classic向けページには「新しいFoundryポータルでは使用できない」と明記されています。(Microsoft Learn)
既存環境から移行する場合は、次の点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 参照しているドキュメント | new Foundry向けか、classic向けか |
| ポータルの画面 | Agents、Traces、Connected resourcesの位置が一致しているか |
| SDKパッケージ | 古いサンプルのパッケージ構成をそのまま使っていないか |
| 接続方式 | Application Insights接続が新しいFoundryプロジェクトに対して行われているか |
| 権限 | 旧環境のロール設定をコピーしただけになっていないか |
特に、古い手順で「Tracing」や「Agents playground」を探していると、現在の画面構成と一致せず、接続済みかどうかを誤認することがあります。
本番環境ではプレビュー機能の扱いを明文化する
Workflow、hosted、custom agentsのトレースはプレビュー扱いです。プレビュー機能は本番ワークロードに推奨されないため、利用する場合はリスクを明文化しておく必要があります。(Microsoft Learn)
社内で判断する際は、次のような基準を使うと整理しやすくなります。
| 判断項目 | 本番利用前の確認 |
|---|---|
| SLA | 監視機能が一時的に使えない場合の運用手順があるか |
| 障害対応 | トレース以外のログやメトリックで代替確認できるか |
| セキュリティ | プレビュー機能で取得されるデータ範囲を確認しているか |
| 変更耐性 | APIや画面仕様が変わった場合に追随できる体制があるか |
| 利用範囲 | 重要業務ではなく限定的な用途から始めているか |
トレースが表示されない場合の確認ポイント
トレース設定後にすぐデータが表示されない場合でも、設定ミスとは限りません。公式情報では、トレースが表示されない原因として、接続未完了、最近のトラフィックがない、取り込み遅延、権限不足、クライアント側計測の未設定などが挙げられています。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Foundryポータルにトレースが出ない | Application Insights未接続、最近の実行がない、取り込み遅延 | 接続を確認し、エージェントを実行して数分後に更新する |
| テレメトリ閲覧時に認可エラーが出る | Application InsightsまたはLog AnalyticsのRBAC不足 | IAMを確認し、Log Analytics Readerなど必要なロールを付与する |
| クライアント側トレースだけ表示されない | パッケージ未導入、OpenTelemetry設定不足 | SDKとトレーシング設定を確認する |
| 一部のspanが欠ける | 計測対象外の処理がある、callback未設定 | 手動spanやフレームワークのcallback設定を見直す |
| 機密情報が見えてしまう | プロンプト、ツール引数、出力に機密情報が含まれている | トレースに入る前にマスキング・最小化する |
確認の基本手順はシンプルです。Application Insights接続を確認し、エージェントまたはワークフローを少なくとも1回実行し、FoundryプロジェクトのTraces画面で新しいトレースが表示されるか確認します。正常に動作している場合は、時刻、所要時間、ステータスなどを含むトレース一覧が表示されます。(Microsoft Learn)
Agent Monitoring Dashboardまで使う場合の注意点
トレース設定は、Agent Monitoring Dashboardを使ううえでも前提になります。公式情報では、Agent Monitoring Dashboardは接続されたApplication Insightsリソースからテレメトリを読み取り、トークン使用量、レイテンシ、成功率、評価結果などを確認できると説明されています。(Microsoft Learn)
つまり、ダッシュボードを有効活用したい場合も、最初に見るべきなのはApplication Insights接続です。ダッシュボードだけを開いて「データがない」と判断するのではなく、次の順番で確認してください。
| 順番 | 確認内容 |
|---|---|
| 1 | FoundryプロジェクトにApplication Insightsが接続されているか |
| 2 | エージェントに最近の実行トラフィックがあるか |
| 3 | 閲覧者にApplication InsightsとLog Analyticsの権限があるか |
| 4 | ダッシュボードの時間範囲が適切か |
| 5 | 評価やアラートなど、必要な監視設定が有効か |
運用チームは、トレースとダッシュボードを分けて考えないほうがよいでしょう。トレースは個別の実行調査、ダッシュボードは傾向把握や異常検知に向いています。両方を組み合わせることで、「全体として遅くなっているのか」「特定のツール呼び出しだけが失敗しているのか」を切り分けやすくなります。
本番展開前のチェックリスト
Azure AI FoundryのAIエージェントを本番展開する前に、次の項目を確認してください。
| チェック項目 | 合格基準 |
|---|---|
| Application Insights接続 | FoundryプロジェクトのTraces画面で接続済みになっている |
| トレース確認 | エージェント実行後に新しいトレースが表示される |
| 権限 | 運用担当者が必要な範囲で閲覧・検索できる |
| 最小権限 | 開発者全員に広すぎる監視権限を付与していない |
| 機密情報対策 | プロンプト、出力、ツール引数に秘密情報が残らない |
| 保持期間 | Application InsightsとLog Analyticsの保持設定を確認している |
| コスト | 取り込み量と保持期間による費用増を見込んでいる |
| プレビュー機能 | 本番利用する場合のリスクと代替手段を文書化している |
| 移行確認 | classic向け手順とnew Foundry向け手順を混在させていない |
| 障害時手順 | トレースが出ない場合の確認手順を運用Runbookに入れている |
まず何から始めるべきか
Azure AI Foundryのトレース設定で最初にやるべきことは、難しいSDK実装ではありません。まず、FoundryプロジェクトにApplication Insightsが接続されているかを確認し、エージェントを1回実行して、Traces画面に記録が出るかを見てください。
そのうえで、管理者はRBAC、Log Analytics、保持期間、課金を確認します。開発者は、サーバー側トレースだけで十分か、アプリケーション側のOpenTelemetry計測が必要かを判断します。セキュリティ担当は、プロンプト、モデル出力、ツール引数に機密情報が残らない設計になっているかを確認します。
AIエージェントは、通常のアプリケーションよりも「なぜその回答になったのか」を説明しにくい領域です。トレースを早い段階で標準化しておくことで、障害対応、品質改善、コスト最適化、セキュリティ監査のすべてが進めやすくなります。
コメント