Azure AI Foundryで本番トレースを使った評価を運用している場合、今回の「Evaluations with Intelligent Trace Sampling」の要点は、すべての本番トレースを評価対象にするのではなく、代表性のあるトレースだけを賢く抽出して評価できるようになることです。評価コストを抑えながら、よくある問い合わせだけでなく、エッジケースや失敗しやすい会話も拾いやすくするための変更と考えると分かりやすいです。
特に確認すべきなのは、Application Insightsとの接続、OpenTelemetryトレースの出力内容、評価ジョブのサンプリング設定、RBAC、個人情報を含むトレースの扱いです。Public Previewのため、いきなり本番の品質判定を全面的に置き換えるのではなく、既存の固定評価データセットや手動レビューと並行して検証するのが安全です。
Azure AI FoundryのIntelligent Trace Samplingで何が変わるのか
2026年6月4日付のAzure Updatesで案内された「Public Preview: Evaluations with Intelligent Trace Sampling」は、Microsoft FoundryのObservabilityに、評価向けのインテリジェントなトレースフィルタリングとサンプリングを導入するものです。Microsoftの説明では、本番トレース全件を評価する代わりに、代表性のあるサブセットを選んで評価する考え方が示されています。(マイクロソフト Azure)
従来の課題は明確です。AIエージェントやRAGアプリを本番運用すると、似たような問い合わせ、短すぎる入力、途中で壊れたセッション、ノイズの多い会話が大量に発生します。これらをすべて評価するとコストが膨らみます。一方で、評価をほとんど行わないと、実ユーザーの失敗パターンを見逃します。
Intelligent Trace Samplingは、この中間を狙う機能です。評価に使うべきトレースを自動で絞り込み、重複や低品質なトレースを除外しながら、多様な会話パターンを含む評価セットを作りやすくします。
| 観点 | これまで起きやすかった問題 | Intelligent Trace Samplingで期待できる変化 |
|---|---|---|
| 評価対象 | 本番トレース全件評価、または手動・ランダム抽出になりがち | 代表性のあるトレースを自動抽出しやすくなる |
| コスト | 評価対象が増えるほど評価コストが増えやすい | 全件評価を避け、評価対象数を制御しやすい |
| 評価品質 | 頻出する似た問い合わせに偏りやすい | 多様なプロンプト、失敗経路、エッジケースを含めやすい |
| 運用負荷 | 評価前の重複排除やノイズ除去を人手で行う必要がある | 重複排除や不適切なトレース除外をサービス側で処理 |
| 注意点 | 全件評価ではないため、すべての問題を検出できるわけではない | 固定テスト、重要ケースの手動指定、アラート連携との併用が必要 |
Azure Updates上の「In preview」は、Azure利用者が非本番用途やテスト用途で利用できる段階を指します。つまり、正式な本番運用品質の機能として前提にするのではなく、既存の品質保証プロセスに追加して検証する位置づけです。(マイクロソフト Azure)
Intelligent Trace Samplingの仕組み
Microsoft Learnでは、Trace evaluationが「取得済みのすべてのトレースを評価する代わりに、代表的なサブセットを選ぶ」Intelligent samplingをサポートすると説明されています。FoundryポータルではTrace evaluation runの設定時にIntelligent samplingトグルを有効化し、SDKではサンプリング戦略としてsmart_filteringを指定する流れです。(Microsoft Learn)
アルゴリズムは、単純なランダム抽出ではありません。Microsoftの説明では、複数段階のMinHash farthest-first diversityアプローチが使われ、重複排除、ハードフィルター、集約、MinHashによる多様性重視の選択が行われます。(Microsoft Learn)
| 処理段階 | 役割 | 実務上の意味 |
|---|---|---|
| Exact deduplication | 重複トレースを除外 | 同じ問い合わせや再送による評価の偏りを減らす |
| Hard filters | 壊れたセッション、途中で切れたトレース、不正なツール呼び出しなどを除外 | 評価不能なデータでスコアが乱れるのを防ぐ |
| Aggregation | トレース単位の信号を統合 | 会話や実行単位として評価しやすい形に整える |
| MinHash farthest-first selection | ユーザーテキストの類似度を推定し、既に選ばれたものと異なるトレースを優先 | 似た問い合わせばかりでなく、珍しいケースや新しいパターンを拾いやすくする |
MinHashは、テキストの完全一致ではなく「似ているかどうか」を効率よく推定するための手法です。これにより、よくある定型質問だけで評価セットが埋まることを避け、語彙や会話パターンの広がりを確保しやすくなります。Microsoft Learnでも、ランダムサンプリングより高い語彙的多様性と広いカバレッジが得られ、珍しいケースや難しいケース、未知のケースを含めやすいと説明されています。(Microsoft Learn)
ただし、ここで重要なのは、Intelligent Trace Samplingが「品質を自動で改善する機能」ではないことです。あくまで評価に使うトレースを選びやすくする仕組みです。評価結果を見て、プロンプト、ツール、検索設定、ガードレール、ナレッジソースを改善する作業は引き続き必要です。
影響を受ける対象者
今回の変更は、Azure AI FoundryでAIエージェントを作っている開発者だけでなく、運用管理者、セキュリティ担当、QA担当にも関係します。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| 開発者 | トレース評価の対象がサンプリングされる | OpenTelemetry属性、agent ID、input/output messagesが正しく出ているか |
| Azure管理者 | Application Insights、Log Analytics、RBAC、コスト管理が関係する | 接続先、権限、保持期間、予算アラート |
| QA・テスト担当 | 評価対象が固定ではなく本番トレース由来になる | 固定回帰テストとサンプリング評価の役割分担 |
| セキュリティ・法務担当 | トレースにユーザー入力や出力、ツール引数が含まれる可能性がある | 個人情報、機密情報、アクセス権、保持ポリシー |
| プロダクト責任者 | 実ユーザーの利用実態に近い品質監視がしやすくなる | 品質KPI、合格基準、リリース判断への使い方 |
特に注意したいのは、トレースにはユーザー入力、モデル出力、ツール呼び出し、中間ステップ、レイテンシ、トークン使用量、エラーなどが記録される可能性がある点です。Microsoft Learnでは、App Insightsが有効なプロジェクトでは、Log Analytics Readerロールを持つメンバーが個人データやCustomer Contentを含む可能性のあるトレースを閲覧できるため、収集内容と閲覧権限の確認が必要だと説明されています。(Microsoft Learn)
管理者が最初に確認すべき設定
Intelligent Trace Samplingを試す前に、まず「評価以前の観測基盤」が正しく構成されているかを確認します。トレースが不完全な状態でサンプリングを有効にしても、評価結果は信頼できません。
| 確認項目 | 見る場所・観点 | 判断基準 |
|---|---|---|
| Application Insights接続 | Foundryプロジェクトの接続済みリソース | 評価対象のエージェントと同じプロジェクト・同じ監視基盤に接続されているか |
| トレース有効化 | FoundryのTraces、Application Insights | 必要な本番・検証環境だけで有効化されているか |
| RBAC | Foundryプロジェクト、Application Insights、Log Analytics workspace | 開発者全員に広く閲覧権限を付けず、必要最小限になっているか |
| Log Analytics Reader | Application Insightsと連携するLog Analytics workspace | 評価実行やトレース閲覧に必要なIDへ付与されているか |
| 保持期間 | Application Insights / Log Analytics設定 | 監査要件、コスト、個人情報保持ポリシーと一致しているか |
| サンプリング設定 | Trace evaluation run、SDKのfilter_strategy | ランダム抽出かsmart_filteringかを意図的に選んでいるか |
| 最大トレース数 | max_tracesなど | 評価コストと検出したい品質粒度のバランスが取れているか |
| 評価対象期間 | start_time、end_time、lookback | 障害発生時間帯、リリース後時間帯、通常利用時間帯を切り分けられているか |
Trace evaluationでは、Application Insightsに取得済みのエージェントインタラクションを評価できます。Foundry Agent Service以外で作られたLangChainやカスタムフレームワークのエージェントでも、GenAIのOpenTelemetryセマンティック規約に従ってApplication Insightsへスパンを送っていれば評価対象にできます。(Microsoft Learn)
開発者が確認すべきOpenTelemetry属性
Intelligent Trace Samplingは、トレースの中身をもとに評価対象を選びます。そのため、トレースが取れているだけでは不十分です。評価に必要な属性が不足していると、評価スコアがNoneになったり、期待したエージェントだけを抽出できなかったりします。
Microsoft Learnでは、Trace evaluationがinvoke_agentスパンを読み取り、Application Insightsから会話データを抽出すると説明されています。主にgen_ai.operation.name、gen_ai.agent.id、gen_ai.agent.name、gen_ai.input.messages、gen_ai.output.messages、gen_ai.tool.definitions、gen_ai.conversation.idなどが使われます。(Microsoft Learn)
| 属性 | 重要度 | 確認ポイント |
|---|---|---|
gen_ai.operation.name | 必須 | invoke_agentになっているか |
gen_ai.agent.id | 高 | agent filterで使う場合、agent-name:version形式で識別できるか |
gen_ai.agent.name | 高 | ポータルや評価ジョブで対象エージェントを見分けられるか |
gen_ai.input.messages | 高 | ユーザー入力やシステム入力が評価用のqueryとして解釈できるか |
gen_ai.output.messages | 高 | assistantやtoolの出力がresponseとして評価可能か |
gen_ai.tool.definitions | 中 | ツール呼び出しの意味を評価・分析しやすいか |
gen_ai.conversation.id | 中 | マルチターン会話や障害分析とひも付けられるか |
特に失敗しやすいのは、独自フレームワークや独自ラッパーでエージェントを実装しているケースです。トレースは送れていても、input.messagesやoutput.messagesが空だったり、agent IDの形式が統一されていなかったりすると、評価対象の抽出やスコアリングが不安定になります。
SDKで指定する場合の設定例
SDKでTrace evaluationを構成する場合、サンプリング戦略にsmart_filteringを指定することで、Intelligent samplingに相当する選択を行えます。Microsoft Learnの例でも、trace_sourceにfilter_strategy: "smart_filtering"を含める形が示されています。(Microsoft Learn)
trace_source = {
"type": "agent_filter",
"agent_name": "my-support-agent",
"agent_version": "1",
"start_time": start_time,
"end_time": end_time,
"max_traces": 100,
"filter_strategy": "smart_filtering"
}この設定で重要なのは、max_tracesを大きくしすぎないことだけではありません。逆に小さすぎても評価が偏ります。たとえば、問い合わせ種別が20種類以上あるカスタマーサポートエージェントでmax_tracesを10にすると、代表性が不足する可能性があります。最初は「通常時」「リリース直後」「障害発生時間帯」など時間帯を分け、同じ評価基準でスコアのばらつきを見るのが現実的です。
移行・展開時の進め方
Intelligent Trace Samplingは、既存の評価運用をいきなり置き換えるより、段階的に追加するのが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 現状把握 | 現在の評価ジョブ、評価対象件数、評価コスト、手動レビュー件数を棚卸しする | 何を減らしたいのか、何を見逃したくないのかが明確になる |
| 検証環境で試す | 同じ期間のトレースをランダム抽出とsmart_filteringで比較する | サンプルの多様性、評価スコア、検出できた問題の差を説明できる |
| 小規模本番で併用 | 低リスクなエージェントや一部時間帯で使う | 既存の監視や手動レビューと矛盾しないか確認できる |
| 運用ルール化 | max_traces、評価頻度、対象期間、評価基準、通知先を決める | 誰が結果を見て、何を直すかが決まっている |
| 展開 | 主要エージェントへ広げる | コスト、品質、プライバシーのレビューが通っている |
おすすめは、リリース判定には固定データセット、リリース後監視にはIntelligent Trace Samplingという分担です。固定データセットは再現性が高く、バージョン間比較に向いています。一方、Intelligent Trace Samplingは実ユーザーの変化や想定外の使われ方を拾うのに向いています。
Microsoft Learnでも、Intelligent samplingは評価・ベンチマーク、rubric generation、fine-tuning dataset curationに有効と説明されています。つまり、単なる運用監視だけでなく、評価基準の改善や学習用データの整理にも使える可能性があります。(Microsoft Learn)
コスト面での注意点
Intelligent Trace Samplingは、全件評価を避けることで評価コストを抑えやすくします。ただし、「有効にすれば必ず安くなる」と考えるのは危険です。
コストに効く要素は、少なくとも次の4つです。
- 評価対象のトレース数
- 使うEvaluatorの種類と数
- Judge modelや評価用モデルのトークン使用量
- Application Insights / Log Analyticsの取り込み量と保持期間
Microsoft Learnでは、Intelligent samplingのアルゴリズム自体はローカルコンピュート上で動作し、評価そのもの以外に追加のモデル推論コストは発生しないと説明されています。(Microsoft Learn) ただし、評価を実行すればEvaluatorによるトークン消費は発生し得ます。評価結果にはモデル別のトークン使用量も含まれるため、定期実行する場合はCost Managementや予算アラートと組み合わせて監視しましょう。(Microsoft Learn)
実務では、最初から毎時評価にするより、次の順で広げると失敗しにくくなります。
| 運用段階 | 評価頻度の例 | 目的 |
|---|---|---|
| 初期検証 | 手動実行、週1回 | サンプルの妥当性と費用感を確認 |
| 本番試験 | 1日1回 | リリース後の品質変化を把握 |
| 安定運用 | 重要エージェントのみ定期実行 | 品質劣化や安全性リスクの早期発見 |
| 高リスク領域 | 障害・低評価フィードバック発生時に追加評価 | 重要な失敗ケースを深掘り |
プライバシーとセキュリティの注意点
トレースは便利ですが、AIアプリでは機密情報が混ざりやすいデータでもあります。ユーザーの問い合わせ本文、社内文書から取得した回答、ツール呼び出しの引数、検索結果、エラー内容などが含まれる可能性があります。
Microsoft Learnでは、トレースのベストプラクティスとして、シークレット、資格情報、トークンをログに記録しないこと、個人データをマスクまたは最小化すること、アクセス制御と保持ポリシーを適用することが示されています。(Microsoft Learn)
管理者は、少なくとも以下を確認してください。
| リスク | 確認ポイント | 対策例 |
|---|---|---|
| 個人情報の混入 | 氏名、メールアドレス、電話番号、住所がプロンプトや出力に含まれるか | ログ前のマスキング、保持期間の短縮 |
| 秘密情報の混入 | APIキー、接続文字列、認証トークンがtool argumentsに出ていないか | シークレットをプロンプトや属性に入れない |
| 権限過多 | 開発者全員がLog Analytics Readerを持っていないか | グループ単位で最小権限にする |
| 目的外利用 | 評価用トレースを別用途に使っていないか | データ利用目的とレビュー手順を明文化 |
| 長期保持 | 不要なトレースが長期間残っていないか | Log Analyticsの保持期間を見直す |
よくある誤解と失敗しやすいポイント
Intelligent samplingは全件評価の完全な代替ではない
代表性を高める仕組みであって、すべての不具合を検出する保証ではありません。法務、医療、金融、セキュリティなど高リスクな応答パターンは、固定の回帰テストや明示的なtrace ID指定による評価も残すべきです。
ランダムサンプリングとの違いを確認せずに採用しない
smart_filteringは「面白そうなトレース」を拾いやすくするため、通常利用の平均的な体験だけを測りたい場合はランダム抽出との比較が必要です。品質劣化検知には有効でも、SLA的な平均品質の推定には別の設計が向くことがあります。
max_tracesをコストだけで決めない
サンプル数を小さくすれば費用は抑えやすくなりますが、評価の信頼性は下がります。問い合わせカテゴリ、対応言語、エージェントの機能数、ツール呼び出しの種類を考慮して、最低限カバーしたいパターン数から逆算しましょう。
トレースの中身が足りないと評価できない
gen_ai.input.messagesやgen_ai.output.messagesが不足している場合、品質Evaluatorのスコアが意味を持たないことがあります。Microsoft Learnでも、入力・出力メッセージが空または欠落していると、coherence、fluency、relevance、intent resolutionなどの品質Evaluatorがscore=Noneを返すと説明されています。(Microsoft Learn)
プレビュー機能を本番の唯一の判断軸にしない
Public Preview段階の機能は、仕様やUI、SDKの挙動が変わる可能性があります。正式運用に組み込む場合も、リリース判定、監査、障害対応に必要な証跡は、安定した仕組みで別途確保しておくべきです。
どのような場面で使うべきか
Intelligent Trace Samplingは、実ユーザーのトレースが一定量あり、評価コストや手動レビュー工数を抑えながら品質監視を強化したい場面に向いています。
| 向いているケース | 理由 |
|---|---|
| 本番リリース後の品質監視 | 実ユーザーの問い合わせから多様な評価対象を作れる |
| AIエージェントの継続改善 | よくある失敗や珍しい失敗を見つけやすい |
| RAGやツール呼び出しの評価 | 入出力だけでなく、ツール経路や中間ステップも確認しやすい |
| Rubric evaluatorの改善 | 多様な会話パターンをもとに評価観点を見直しやすい |
| Fine-tuning候補データの整理 | ノイズや重複を減らしたトレース選定に役立つ |
一方で、次のような場面では単独利用を避けるべきです。
| 単独利用を避けたいケース | 併用すべき方法 |
|---|---|
| リリース前の合否判定 | 固定評価データセット、CI/CDの品質ゲート |
| 重大インシデントの再現確認 | 該当trace IDを指定した評価、Trace Replay |
| まだ本番トレースが少ない新規エージェント | 合成データ、手作りテストケース |
| 法令・社内規程で網羅テストが必要な領域 | 明示的なテストケース管理、レビュー証跡 |
| 平均的なユーザー体験を統計的に測りたい場合 | ランダムサンプリングや層化サンプリングとの比較 |
まず実施すべきチェックリスト
導入を検討する場合は、次の順に確認するとスムーズです。
| 順番 | やること | 完了の目安 |
|---|---|---|
| 1 | 対象エージェントを1つ選ぶ | 高リスクすぎず、一定の本番トレースがある |
| 2 | Application Insights接続を確認 | 対象エージェントのトレースが見える |
| 3 | OpenTelemetry属性を確認 | invoke_agent、agent ID、input/output messagesがそろっている |
| 4 | 直近24時間など短い期間で試す | サンプル内容を人が見て妥当性を判断できる |
| 5 | ランダム抽出とsmart_filteringを比較 | 検出できる問題やスコア傾向の違いを説明できる |
| 6 | max_tracesと評価頻度を決める | 月次コストの上限に収まる |
| 7 | RBACと保持期間を見直す | 必要な人だけがトレースを閲覧できる |
| 8 | 運用ルールを文書化する | スコア低下時の担当者と対応手順が決まっている |
まとめ：評価コスト削減ではなく、評価の質を上げる機能として使う
Azure AI Foundryの「Evaluations with Intelligent Trace Sampling」は、単に評価件数を減らすための機能ではありません。本番トレースから、評価に使う価値の高いサンプルを選びやすくし、AIエージェントの品質監視を現実的なコストで続けるための機能です。
管理者はApplication Insights、RBAC、保持期間、コスト監視を確認し、開発者はOpenTelemetry属性と評価対象のマッピングを整える必要があります。QA担当は、固定データセットによる回帰テストと、Intelligent Trace Samplingによる本番トレース評価を分けて設計しましょう。
次に取るべき行動は、対象エージェントを1つ選び、短い期間のトレースでsmart_filteringを試すことです。その結果をランダムサンプリングや既存の手動レビューと比較し、評価コスト、検出できた問題、サンプルの多様性を確認してから、本格展開するのが安全です。
コメント