Azure AI Foundryでエージェントを開発していると、「なぜこのツールを呼んだのか」「どのステップで遅くなったのか」「想定外の回答はどこで発生したのか」を追うのに時間がかかります。今回の「Trace Replay and trace visualizations for Foundry agents」は、その調査を速くするためのプレビュー機能です。
結論から言うと、Azure AI Foundryのエージェント実行トレースをステップごとに再生し、モデル呼び出し、ツール実行、サブエージェントの流れ、入出力、トークン消費、遅延のボトルネックを確認しやすくなります。既存エージェントの動作を直接変える更新というより、開発・検証・運用監視で使う「可観測性」の強化として捉えると分かりやすいです。Microsoft Learnの該当ドキュメントは2026年6月3日に更新されており、Trace Replayはパブリックプレビューとして案内されています。(Microsoft Learn)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回の更新では、Microsoft Foundryの可観測性機能に、Trace Replayと新しいトレース可視化が追加されました。Azure Updatesでは、複数ステップのエージェント実行をより速くデバッグするためのパブリックプレビューとして紹介されています。(マイクロソフトアジュール)
従来のログ確認では、エージェントの応答、ツール呼び出し、モデル処理、評価結果、エラー情報が別々に見えやすく、問題箇所を特定するまでに時間がかかることがありました。Trace Replayでは、取得済みのトレースを会話の流れに沿って確認できます。
特に大きな変更点は次の3つです。
| 変更点 | 何が便利になるか | 実務での使いどころ |
|---|---|---|
| Trace Replayの追加 | エージェント実行をステップごとに再生できる | 失敗した問い合わせの再現、ツール呼び出し順序の確認 |
| 新しいトレース可視化 | スパン階層、処理時間、トークンコストを見やすく整理できる | 遅延原因や高コストな処理の発見 |
| ユーザー視点と軌跡ビューの切り替え | ユーザー体験と内部処理の両方から確認できる | 問い合わせ対応、品質レビュー、開発者デバッグ |
この更新は、AIエージェントを「作る」段階だけでなく、「運用しながら改善する」段階で効いてきます。たとえば、Copilot型の社内問い合わせエージェントで誤回答が発生した場合、最終回答だけを見ても原因は分かりません。検索クエリが悪かったのか、取得した文書が古かったのか、ツールの戻り値を読み違えたのか、モデル選択やプロンプトが合っていなかったのかを切り分ける必要があります。Trace Replayは、この切り分けを画面上で進めやすくする機能です。
Trace Replayでできること
Trace Replayは、エージェント実行で生成された会話トレースを調査、ナビゲート、分析するための機能です。会話IDまたはトレースIDを参照するページからアクセスでき、ユーザー視点のビューと、スパン階層やタイミングを確認するビューを切り替えられます。(Microsoft Learn)
エージェントの処理をステップごとに追える
Trace Replayでは、LLM呼び出し、ツール実行、ユーザープロンプト、サブエージェントのオーケストレーション、応答など、エージェントループ内の各ステップを確認できます。各スパンを選択すると、生のメタデータをJSONで確認したり、会話に関連する評価結果を見たりできます。(Microsoft Learn)
たとえば、次のような確認がしやすくなります。
- ユーザーの質問に対して、どのモデルが呼ばれたか
- どのツールやナレッジソースが使われたか
- ツールの入力と出力が期待どおりだったか
- サブエージェントがどの順番で動いたか
- どのステップで待ち時間やトークン消費が増えたか
- 評価スコアが低い応答の直前に何が起きたか
エージェントは、単純なチャットボットよりも処理が複雑になりがちです。RAG、外部API、業務システム連携、複数エージェントの呼び出しが入ると、問題は最終回答だけでは判断できません。Trace Replayは、こうした複雑な実行経路を「時系列で見直せる」点に価値があります。
軌跡ビューでボトルネックを見つけやすい
軌跡ビューでは、トレースが階層ツリーとして表示されます。エージェントの推論、ツール呼び出し、会話ターンなどがスパンとして並び、各スパンには期間またはトークンコストで測定できるウォーターフォールバーが表示されます。公式ドキュメントでは、このビューはエラー、幻覚、異常に長い処理、高コストなやり取りの特定に役立つと説明されています。(Microsoft Learn)
実務では、次のような調査に向いています。
| 見たい問題 | 軌跡ビューで確認するポイント |
|---|---|
| 応答が遅い | どのスパンの処理時間が長いか |
| コストが高い | どのモデル呼び出しやプロンプトでトークンが多いか |
| ツール選択が不自然 | どの判断の後にツールが呼ばれたか |
| 誤回答が出た | 取得結果、ツール結果、最終応答のどこでズレたか |
| 複数エージェントの流れが複雑 | サブエージェント呼び出しの順序と入出力 |
特にトークンコストを見られる点は重要です。AIエージェントの運用コストは、単純な実行回数だけでなく、プロンプトの長さ、検索結果の詰め込み、不要なツール呼び出し、会話履歴の持たせ方で大きく変わります。Trace Replayで高コストなスパンを見つければ、プロンプト短縮、検索結果数の調整、ツール呼び出し条件の見直しにつなげられます。
ユーザービューで実際の会話体験を確認できる
ユーザービューでは、エンドユーザーが体験した内容に近い形で、ユーザーとエージェントのやり取りをチャットベースで確認できます。さらに、折りたたみ可能なスパンツリーも参照できるため、会話内容と内部処理を行き来しながら調査できます。(Microsoft Learn)
これは、問い合わせ対応や品質レビューで役立ちます。たとえば、利用者から「回答が変だった」と報告されたとき、開発者は内部ログを見ますが、業務部門の担当者は会話の流れを見たいはずです。ユーザービューがあることで、開発者だけでなく、プロダクトオーナー、業務担当者、レビュー担当者も問題を共有しやすくなります。
影響範囲：誰が確認すべきか
今回の更新で最も影響を受けるのは、Azure AI Foundryでエージェントを開発・検証・運用しているチームです。エンドユーザーが直接操作する機能というより、開発者、管理者、運用担当者、品質評価担当者向けの更新です。
| 対象者 | 確認すべきこと |
|---|---|
| エージェント開発者 | トレースが取得できているか、Replayで失敗ケースを追えるか |
| Azure管理者 | Application Insights接続、RBAC、Log Analytics閲覧権限 |
| セキュリティ担当者 | トレースに個人情報、認証情報、業務機密が含まれないか |
| 運用担当者 | 遅延、失敗率、トークン使用量、コスト増の兆候 |
| 品質評価担当者 | 評価結果と実行トレースを組み合わせて改善できるか |
注意したいのは、Trace Replayは「有効にすれば自動で全ての問題が分かる」機能ではないことです。前提として、トレースが収集されている必要があります。また、権限が不足していると、トレース、分析情報、可視化を見られません。公式ドキュメントでは、対象エージェントのトレースデータ、プロジェクトに接続されたApplication Insightsリソース、Log Analytics閲覧者ロールが前提条件として示されています。(Microsoft Learn)
利用前に確認すべき前提条件
Trace Replayを使うには、まずAzure AI Foundry側でトレースが見える状態になっている必要があります。Microsoft Foundryのトレース設定ドキュメントでは、Foundryプロジェクト、Azure Monitor Application Insightsリソース、接続先Application Insightsへのアクセス、Log Analytics Readerロールが前提として挙げられています。(Microsoft Learn)
Application Insightsが接続されているか
Foundryは、トレースをAzure Monitor Application Insightsに保存します。トレース設定では、Foundryプロジェクトのエージェント画面からトレースを開き、Application Insightsリソースを作成または接続します。接続が完了すると、プロジェクトでトレースを利用する準備が整います。(Microsoft Learn)
管理者は、まず次を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| Application Insights接続 | Foundryプロジェクトに接続済みか |
| リソースの配置 | 運用方針に合うサブスクリプション、リソースグループか |
| 権限 | 開発者・運用者に必要最小限の閲覧権限があるか |
| 保持期間 | 調査に必要な期間とコストのバランスが取れているか |
| ログの扱い | 機密情報を含む可能性を前提に管理されているか |
新規プロジェクトでは、Application Insightsが自動で用意されているとは限りません。トレースが見えない場合は、まず接続状態を確認するのが近道です。
Log Analytics Readerロールが付与されているか
Trace Replayやトレース可視化を使う担当者には、接続されたApplication Insightsリソースや関連するLog Analyticsワークスペースへのアクセスが必要です。公式ドキュメントでも、ログベースのクエリにはLog Analytics閲覧者ロールの割り当てが必要とされています。(Microsoft Learn)
よくある失敗は、Foundryプロジェクトにはアクセスできるのに、Application InsightsやLog Analytics側の権限が足りないケースです。この場合、画面は開けてもトレースが表示されない、クエリで承認エラーが出る、といった状態になります。
権限付与は個人単位ではなく、Microsoft Entraグループで管理するのがおすすめです。開発者、運用者、監査担当者で見られる範囲を分けると、機密データを含む可能性があるトレースを過剰に開放せずに済みます。
対象エージェントの種類を確認する
Microsoftのドキュメントでは、トレースはプロンプトエージェントでは一般提供、ホステッドエージェント、ワークフローエージェント、外部エージェントではプレビューと説明されています。(Microsoft Learn)
そのため、すべてのエージェント種別で同じ安定性やサポート範囲を期待するのは避けるべきです。特に本番運用中のホステッドエージェントや外部フレームワーク連携では、まず検証環境でトレースの出方、表示遅延、スパンの粒度、機密データの扱いを確認してください。
開発者が見るべきデバッグポイント
Trace Replayを導入したら、単に「見えるようになった」で終わらせず、デバッグの観点を決めておくことが重要です。おすすめは、失敗ケースを次の順番で見ることです。
| 手順 | 確認すること | 改善アクションの例 |
|---|---|---|
| ユーザー入力を見る | 質問が曖昧か、必要情報が不足しているか | 確認質問を入れる、入力フォームを改善する |
| モデル呼び出しを見る | 想定したモデルが使われているか | モデル選択ルールやルーティングを見直す |
| ツール呼び出しを見る | 不要なツール、誤った引数がないか | ツール定義、説明文、呼び出し条件を修正する |
| 検索・取得結果を見る | 古い文書や関係ない情報を取っていないか | インデックス、フィルター、ランキングを調整する |
| 最終応答を見る | 根拠と回答がずれていないか | プロンプト、ガードレール、評価基準を見直す |
| トークンと遅延を見る | 高コスト・低速なスパンがないか | コンテキスト量、検索件数、履歴保持を調整する |
重要なのは、Trace Replayを「障害発生後に見る画面」だけにしないことです。プロンプト変更、ツール追加、ナレッジ更新、モデル変更のたびに、代表的な会話パターンをReplayで確認すると、品質低下を早めに検知できます。
トークン使用量の確認はコスト対策にもなる
Trace Replayでは、トークン使用量によるフィルターも用意されています。公式ドキュメントでは、Lowは500未満、Mediumは500〜2,000、高いレベルは2,000超のトークンとして説明されています。(Microsoft Learn)
エージェントのコストが増えている場合は、まず高トークンのスパンを見ます。よくある原因は次の通りです。
| 原因 | 起きやすい問題 | 見直しポイント |
|---|---|---|
| 会話履歴を長く渡しすぎる | 毎回のモデル呼び出しが重くなる | 要約、履歴上限、重要情報の抽出 |
| 検索結果を詰め込みすぎる | 回答精度が上がらずコストだけ増える | 上位件数、チャンクサイズ、フィルター |
| ツールの戻り値が大きすぎる | 不要なJSONや全文をモデルに渡す | 返却項目の絞り込み、整形 |
| プロンプトが冗長 | 小さな問い合わせでもトークンを消費する | 共通指示の短縮、役割分担 |
| サブエージェントが多段化 | 呼び出し回数と待ち時間が増える | エージェント分割の妥当性確認 |
コスト削減だけを狙って情報量を削りすぎると、回答品質が落ちます。Trace Replayで「どの情報が使われていないか」を見ながら減らすのが安全です。
管理者が確認すべき設定と運用ルール
管理者にとって重要なのは、Trace Replayを使える状態にすることだけではありません。トレースデータは、通常のアプリケーションログよりも機密性が高くなる可能性があります。ユーザー入力、モデル出力、ツール引数、ツール結果が含まれる場合があるためです。
Microsoftのトレース設定ドキュメントでも、トレースにはユーザー入力、モデル出力、ツール引数や結果などの機密情報が含まれる可能性があるため、シークレットや資格情報をプロンプト、ツール引数、スパン属性に保存しないこと、個人データや機密コンテンツを最小化すること、ログやメトリックと同様のアクセス制御と保持ポリシーを適用することが推奨されています。(Microsoft Learn)
最低限決めておきたい運用ルール
| ルール | 決める内容 |
|---|---|
| 閲覧権限 | 誰がトレースを見られるか、どの環境まで見られるか |
| データ保持 | 何日分を保持するか、長期保管が必要か |
| 機密情報 | プロンプト、ツール引数、出力に含めてよい情報の範囲 |
| 本番利用 | プレビュー機能を本番調査でどこまで使うか |
| 監査 | 誰が閲覧したか、問い合わせ対応記録とどう紐づけるか |
| コスト | Application InsightsとLog Analyticsの取り込み量、保持期間の監視 |
特に、社内データや顧客情報を扱うCopilot型エージェントでは、Trace Replayの導入前にセキュリティ担当者と確認しておくべきです。デバッグしやすさを優先してメッセージ本文を広く記録すると、後からアクセス制御や監査で困ることがあります。
移行・展開時の注意点
今回の更新は、既存エージェントをすぐに作り直すタイプの変更ではありません。むしろ、既存のトレース設定とApplication Insights連携の上に、調査しやすい再生・可視化体験が加わる更新と考えるのが実務的です。
ただし、展開時にはいくつか注意点があります。
パブリックプレビューであることを前提にする
Trace Replayはプレビューとして提供されています。Microsoft Learnでは、プレビュー項目はサービスレベルアグリーメントなしで提供され、運用環境ワークロードには推奨されず、一部機能が制限される可能性があると説明されています。(Microsoft Learn)
つまり、Trace Replayを本番障害調査の唯一の手段にしないことが重要です。既存のAzure Monitor、Application Insights、アプリケーションログ、評価ダッシュボードと組み合わせて使うべきです。
おすすめの展開順序は次の通りです。
| フェーズ | 実施内容 |
|---|---|
| 検証 | 開発環境でApplication Insights接続とトレース表示を確認 |
| パイロット | 代表的なエージェントを選び、失敗ケースをTrace Replayで分析 |
| ルール整備 | 権限、保持期間、機密情報の扱い、調査手順を決める |
| 限定展開 | 開発者・運用者に使い方を共有し、改善サイクルに組み込む |
| 継続改善 | 高トークン、高遅延、低評価ケースを定期的に見直す |
トレースが表示されない場合の切り分け
Trace Replayを使おうとしても、最初につまずきやすいのが「トレースが出ない」「スパンが表示されない」「再生できない」という問題です。公式ドキュメントでも、会話IDやトレースIDが表示されない場合、再生パネルにスパンが表示されない場合、再生コントロールが使えない場合などのトラブルシューティングが示されています。(Microsoft Learn)
よくある原因と対処を整理すると、次の通りです。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| トレースが表示されない | Application Insights未接続、最近の実行がない、取り込み遅延 | 接続状態を確認し、エージェントを実行して数分後に更新 |
| 承認エラーが出る | Application InsightsまたはLog Analyticsの権限不足 | IAMで権限を確認し、Log Analytics Readerを付与 |
| スパンが表示されない | トレース処理中、対象の処理が記録されていない | 時間を置いて更新、トレース設定を再確認 |
| 再生できない | 単一スパンなど、順次再生できる情報が不足 | 複数ステップの実行で再確認 |
| フィルター後に空になる | 選択したスパン種別が該当トレースに存在しない | フィルターを解除し、広い条件で確認 |
初回導入時は、まず小さなテスト会話を1つ作り、トレース一覧、Trace Replay、ユーザービュー、軌跡ビュー、スパン詳細まで一通り確認するのがおすすめです。
どのような場面で使うべきか
Trace Replayは、すべての問い合わせを毎回人が見るための機能ではありません。効果が出やすいのは、問題が起きた会話、代表的なテストケース、品質評価で低スコアになった実行、高コスト・高遅延の実行です。
誤回答の原因調査
社内規程を回答するエージェントが古いルールを案内した場合、Trace Replayで次を確認します。
- どのナレッジソースを参照したか
- 検索結果に古い文書が含まれていたか
- 新しい文書を取得したのに、モデルが古い情報を優先したのか
- 最終回答の生成プロンプトに根拠確認の指示があるか
この場合、改善策はプロンプト修正だけとは限りません。インデックスの更新、文書の有効期限メタデータ、検索フィルター、回答時の引用ルールなど、複数の対策が考えられます。
ツール呼び出しの失敗調査
業務システムを呼び出すエージェントで、API引数が間違っていた場合は、ツール実行スパンを確認します。
- ユーザー入力から必要なパラメーターを正しく抽出したか
- ツール定義の説明が曖昧ではないか
- エラー時に再試行したか
- ツール結果を最終回答で正しく扱ったか
ツール定義に似た名前の関数が多い場合、エージェントが誤ったツールを選ぶことがあります。Trace Replayで誤選択の直前の推論や入力を確認できれば、ツール名、説明、呼び出し条件を改善しやすくなります。
レイテンシとコストの最適化
「回答品質は悪くないが遅い」「月次コストが増えている」という場合は、軌跡ビューで長いスパンや高トークンのスパンを見ます。
改善例は次の通りです。
| 課題 | 改善例 |
|---|---|
| 検索結果が多すぎる | 上位件数を絞る、チャンクを短くする |
| 会話履歴が長すぎる | 履歴要約を使う、保持ターン数を制限する |
| ツール呼び出しが多い | 事前判定を入れる、ツールを統合する |
| サブエージェントが深すぎる | 役割分担を見直す、単一エージェントで処理する |
| 高性能モデルを常に使う | タスクに応じてモデル選択を分ける |
ここで大切なのは、速度やコストだけで判断しないことです。安く速くしても、正答率や安全性が落ちれば意味がありません。Trace Replayで変更前後の実行を比較し、評価結果とあわせて判断しましょう。
導入時のチェックリスト
最後に、管理者と開発者が確認すべき項目をチェックリスト化します。
| 区分 | チェック項目 |
|---|---|
| 基本設定 | FoundryプロジェクトにApplication Insightsが接続されている |
| 権限 | 開発者・運用者に必要なRBACとLog Analytics Readerが付与されている |
| 対象範囲 | どのエージェントでTrace Replayを使うか決めている |
| データ保護 | プロンプト、ツール引数、出力に機密情報を含めない設計になっている |
| 保持とコスト | Application InsightsとLog Analyticsの保持期間、取り込み量を確認している |
| 検証 | 代表的な正常系・異常系の会話でReplay表示を確認している |
| 運用 | 低評価、高遅延、高トークン、エラー発生時の確認手順を決めている |
| プレビュー対応 | 本番運用の唯一の監視手段にせず、既存監視と併用している |
Trace Replay and trace visualizations for Foundry agentsは、Azure AI Foundryのエージェント開発を「ログを探す作業」から「実行の流れを見て改善する作業」に近づける更新です。まずは検証環境でApplication Insights接続と権限を確認し、失敗ケースを1つReplayで追ってみると効果を実感しやすいでしょう。
本番展開では、プレビュー機能であること、トレースに機密情報が含まれる可能性があること、保持期間とコストがApplication InsightsやLog Analyticsの設定に左右されることを忘れずに、開発・運用・セキュリティの3者でルールをそろえてから利用範囲を広げるのが安全です。
コメント