2026年5月5日に確認された「Microsoft Copilot documentation update: feat: add Tracing Insights API and FAOS optimization skill references」は、Copilotを使ったMicrosoft Foundryエージェント運用に関わるチームが確認すべきドキュメント更新です。
結論から言うと、今回のポイントは「エージェントの品質低下を見つける」だけでなく、「検出した問題をFAOSで最適化し、改善後のエージェントを検証する」流れがドキュメント上で整理されたことです。特に、Microsoft Foundryのプロンプトエージェントを運用し、Application Insightsや評価データを使って品質監視しているチームは、影響範囲と前提条件を確認しておく必要があります。
一方で、対象はMicrosoft 365 Copilotの一般ユーザー向け機能追加ではありません。GitHub Copilot for Azureリポジトリ内のMicrosoft Foundryスキル参照に関する更新として読むのが安全です。PRは本稿作成時点でOpen状態であり、CI上の指摘も残っているため、本番適用は正式マージ後の内容確認を前提に進めるべきです。(GitHub)
Microsoft Copilot documentation updateで何が変わったのか
今回の更新は、Microsoft Foundryエージェント向けに「Tracing Insights API」「FAOS Optimization」「Insights-to-Optimize Loop」の参照ファイルを追加し、既存のtraceとobserveワークフローからそれらに到達できるようにするものです。PR本文では、検証済みPOCを本番用スキルツリーへ移す更新として説明されています。(GitHub)
実務的には、次の3点が重要です。
| 変更点 | 内容 | 実務上の意味 |
|---|---|---|
| Tracing Insights API参照の追加 | 評価スコアの変化点検出、認証、レスポンス形式を整理 | 手動KQLや目視確認に頼らず、品質低下や異常を検出しやすくなる |
| FAOS Optimization参照の追加 | FAOSのエンドポイント、ワークスペース要件、リクエスト/レスポンス、ポーリングを整理 | 検出した品質課題を、プロンプト最適化の入力に変換しやすくなる |
| Insights-to-Optimize Loop参照の追加 | 検出、データセット化、最適化、改善確認までのE2E手順を整理 | 「監視して終わり」ではなく、改善サイクルまで運用に組み込める |
更新対象のスキルはmicrosoft-foundryで、Microsoft Learn上でもGitHub Copilotに専門知識を提供するAzure Skillとして説明されています。既存の説明では、Foundryエージェントのデプロイ、評価、バッチ評価、プロンプト最適化、システム指示の改善などが対象です。(Microsoft Learn)
対応すべき人と、今すぐ影響が小さい人
今回のMicrosoft Copilot documentation updateは、すべてのCopilot利用者に同じ影響があるわけではありません。特に確認すべきなのは、Microsoft Foundryでプロンプトエージェントを構築・評価・改善している開発者や運用担当者です。
| 対象者 | 対応優先度 | 理由 |
|---|---|---|
| Microsoft Foundryのプロンプトエージェントを運用しているチーム | 高 | 今回のスコープはPrompt agentsのみとされている |
| Application Insightsに評価データを蓄積しているチーム | 高 | Tracing Insights APIの前提に評価イベントが含まれる |
| エージェント品質を手動で調査している開発者 | 高 | 異常検知からFAOS最適化までの導線が追加される |
| Hosted agents中心のチーム | 低〜中 | Hosted agent supportは今回の範囲外として延期されている |
| Microsoft 365 Copilotの一般利用者・管理者 | 低 | 今回は一般的なMicrosoft 365 CopilotのUIや管理設定変更ではない |
| ドキュメント・スキルルーティングの保守担当者 | 高 | SKILL.mdや参照パスにCI指摘が出ている |
PR上では、対象範囲はPrompt agentsのみで、Hosted agents対応は延期とされています。また、Copilotによるレビューでは、Tracing Insights API、FAOS Optimization、Insights-to-Optimize workflowの3つの参照ファイルが追加されたことが整理されています。(GitHub)
Tracing Insights APIで確認すべき変更点
Tracing Insights APIは、エージェントの評価スコアに対して変化点検出を行い、品質低下や異常を見つけるための参照情報です。ドキュメント案では、App Insightsに保存された評価データを使い、task adherence、intent resolution、fluency、latency、token usageなどの評価軸に対して異常を検出する用途が示されています。(GitHub)
ここで重要なのは、単なるトレースでは不十分という点です。参照ファイルでは、FoundryプロジェクトにApplication Insightsが接続され、gen_ai.evaluation.resultのような評価イベントが存在することが前提として記載されています。つまり、トレースを取っているだけで評価データがない環境では、期待した検出結果が得られない可能性があります。(GitHub)
API利用前の確認ポイント
| 確認項目 | 見るべき場所 | 判断基準 |
|---|---|---|
| Application Insights接続 | FoundryポータルのTracing設定 | FoundryリソースにApp Insightsが関連付けられている |
| 評価イベント | App Insights / 評価ログ | 評価結果イベントが継続的に記録されている |
| 分析対象期間 | APIのstartDateTimeUtcとendDateTimeUtc | 比較に十分なデータ点がある |
| エージェント名 | APIクエリパラメーター | URLエンコードされている |
| projectId | Foundry projectのARMリソースID | スラッシュを含むためURLエンコードが必要 |
| リクエストボディ | POST本文 | 空のJSON {} を送る。本文なしは400になる可能性がある |
Microsoft LearnのTracing関連ドキュメントでも、FoundryのトレースはAzure Application InsightsにOpenTelemetryで保存され、新規リソースではApplication Insightsが自動でプロビジョニングされないため、Foundryリソースごとに関連付けが必要と説明されています。(Microsoft Learn)
Tracing Insights APIで誤解しやすい点
特に注意したいのは、meanBeforeとmeanAfterの読み方です。参照ファイルでは、これらは「過去の長期ベースラインとの比較」ではなく、指定した分析期間内で検出された変化点の前後平均を表すと説明されています。(GitHub)
たとえば、1月1日から1月18日までを分析した場合、meanBeforeは「過去数カ月の平均」ではなく、その期間内で検出された変化点より前の平均です。期間設定を雑にすると、実際には問題がないのに異常に見えたり、逆に本当の劣化を見逃したりします。
実務では、次のように使うと失敗しにくくなります。
| シーン | 推奨する使い方 |
|---|---|
| 新しいプロンプトを投入した直後 | 変更前後が同じ分析期間に入るように期間を設定する |
| 週次の品質監視 | 同じ曜日・同じ時間帯を含め、利用パターンの差を減らす |
| 評価データが少ない環境 | すぐに判断せず、代表的な問い合わせを追加してデータ点を増やす |
| トークン増加の調査 | token usageだけでなく、task adherenceやlatencyも併せて見る |
FAOS Optimizationで確認すべき変更点
FAOSはFoundry Agent Optimization Serviceの略で、エージェントのシステムプロンプトや指示を最適化するためのサービスとして参照されています。追加された参照ファイルでは、RUN → EVAL → REFLECTの反復ループにより、評価で見つかった品質低下を修正する方向にエージェント指示を書き換える流れが説明されています。(GitHub)
ただし、ここで最も重要なのはスコープです。参照ファイルではFAOSの対象はPrompt agentsのみで、Hosted agentsはこのワークフローではサポートされないとされています。Microsoft Foundryのプロンプトエージェントは、モデル、命令、ツール、自然言語プロンプトを組み合わせて動作を定義するエージェントです。(GitHub)
FAOS利用前に確認すべき前提条件
| 確認項目 | なぜ重要か | NG例 |
|---|---|---|
| エージェント種別 | Prompt agentのみが対象 | Hosted agentを同じ手順で最適化しようとする |
| ワークスペース種別 | MachineLearningServices/workspacesが必要 | CognitiveServicesアカウントを指定する |
| 評価データセット | FAOSが改善方向を判断する材料になる | 失敗パターンを含まない単調なテストだけを渡す |
| baselineスコア | FAOSが実際の現状を読めているか確認できる | baselineが現状の挙動と合わないまま採用する |
| バージョン管理 | 最適化後に戻せる状態を作る | 本番エージェントを直接上書きする |
参照ファイルでは、FAOSのワークスペース要件として登録済みのMachineLearningServices/workspacesが必要であり、CognitiveServicesアカウントでは動作しないこと、未登録ワークスペースでは404になることが注意点として書かれています。(GitHub)
最適化結果をそのまま本番反映しない
FAOSのレスポンス例では、baselineとbestが返り、best.config.systemPromptに最適化後のシステムプロンプトが含まれる形が示されています。参照ファイルでは、完了後にagent_update MCPツールまたはFoundry Agents APIで最適化後の指示を適用する流れが説明されています。(GitHub)
ただし、最適化されたプロンプトは「採用候補」であって、自動的に本番正解になるわけではありません。特に、以下のケースでは人間による確認が必要です。
| リスク | 具体例 | 対策 |
|---|---|---|
| 過剰な短文化 | トークンは減ったが、必要な説明まで削られる | pass rateと実回答の目視確認を両方行う |
| 評価データへの過適合 | テストでは高得点だが、実問い合わせに弱い | 本番に近い代表プロンプトを追加する |
| baseline不一致 | FAOSが既定の「helpful assistant」指示を読んでいる | baselineスコアと現行エージェントの挙動を照合する |
| ロールバック不能 | 更新後に品質が悪化して戻せない | v2エージェント作成または手動バージョン保存を行う |
Microsoft Foundry REST Referenceでは、Agentの更新時に変更がある場合は新しいバージョンを追加する動作や、Agent version作成APIが説明されています。FAOS結果を適用する場合も、既存の本番エージェントを直接置き換えるより、バージョンを分けて検証する運用が安全です。(Microsoft Learn)
Insights-to-Optimize Loopはどう使うべきか
Insights-to-Optimize Loopは、今回の更新で最も実務インパクトが大きい部分です。流れはシンプルで、Tracing Insights APIが評価スコアの異常を検出し、その内容をFAOS用データセットへ変換し、FAOSが指示を最適化し、最後に改善結果を検証します。(GitHub)
このワークフローは、手動でKQLを調べ、失敗ログを読み、プロンプトを人力で直す作業を減らしたい場合に向いています。ただし、完全自動化を急ぐより、最初は「検出と改善案の作成までを自動化し、採用判断は人間が行う」形で導入するのが現実的です。
InsightsからFAOSデータセットへ変換する考え方
参照ファイルでは、検出されたInsightをFAOSの評価条件に変換する例が示されています。実務では、以下のように「何が悪化したか」を「どのような振る舞いを期待するか」に変換します。(GitHub)
| 検出されたシグナル | FAOSに渡す評価観点の例 |
|---|---|
| TaskAdherenceの低下 | 指示に正確に従い、要求された項目を漏れなく完了する |
| Intent Resolutionの低下 | ユーザー意図を正しく解釈し、不明点があれば確認する |
| Token spike | 余計な説明を避け、簡潔で焦点の合った回答を返す |
| Latency spike | 不要なツール呼び出しを避け、効率よく応答する |
| Error rate increase | エッジケースでもエラーなく処理する |
ここでのコツは、評価条件だけでなく、代表プロンプトを具体的にすることです。「問い合わせ対応を改善する」では広すぎます。たとえば社内FAQエージェントなら、「社員が休暇申請の締切を聞く」「海外出張時の精算ルールを聞く」「該当規程がないケースで相談先を聞く」のように、業務シーンに即した入力を用意します。
移行・設定確認のチェックリスト
今回の更新は、既存アプリケーションをすぐに書き換えるタイプの変更ではありません。まずは、運用環境が新しいドキュメントの前提を満たしているか確認することが重要です。
| チェック項目 | 確認方法 | 合格ライン |
|---|---|---|
| 対象エージェントがPrompt agentか | Foundry Agent Serviceの構成確認 | Prompt agentとして作成・管理されている |
| Application Insightsが接続済みか | FoundryポータルのTracing画面 | App Insightsリソースが関連付けられている |
| 評価データが保存されているか | 評価実行結果・App Insightsログ | 評価イベントが継続的に記録されている |
| Tracing Insights APIに必要な識別子があるか | subscription、resource group、component、agent、projectIdを確認 | projectIdとagentを正しくURLエンコードできる |
| FAOS用ワークスペースが適切か | Azureリソース種別を確認 | MachineLearningServices/workspacesを使用している |
| 最適化前後の比較手順があるか | 評価設計を確認 | v1とv2で同じテストプロンプトを比較できる |
| ロールバック手段があるか | バージョン管理・デプロイ手順を確認 | 旧プロンプトまたは旧エージェントへ戻せる |
| PRの状態を確認したか | GitHub PRと公式ドキュメントを確認 | 正式マージ後の内容に基づいて運用する |
特に、PR上ではSKILL.mdの説明文が上限を超えていること、相対パスの誤りによりMarkdown References checkが失敗していることが指摘されています。これは機能の価値を否定するものではありませんが、公開前のドキュメントとして未確定要素があることを示します。(GitHub)
導入時に失敗しやすいポイント
今回の更新を実務に取り込む場合、失敗の多くはAPI仕様そのものよりも、前提データと運用設計にあります。
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| トレースだけで十分だと思い込む | Insightsが期待通り返らない | 評価イベントがApp Insightsに保存されているか確認する |
| データ点が少ないまま判断する | 偶然の揺れを品質劣化と誤認する | 代表的な問い合わせを増やし、期間を調整する |
| Hosted agentに適用しようとする | ワークフローの前提と合わない | Prompt agent対象であることを確認する |
| FAOSの結果を即本番反映する | 品質や回答方針が意図せず変わる | v2を作成して比較検証する |
| トークン削減だけを見る | 簡潔だが不親切な回答になる | pass rate、task adherence、回答品質を併せて見る |
| baselineを確認しない | 誤った初期プロンプトを基準に最適化する | baselineスコアと実際の現行挙動を突き合わせる |
| 権限・ワークスペース種別を後回しにする | 404や認証エラーで検証が止まる | Azure権限、App Insights、ML workspaceを先に確認する |
Microsoft Foundryの評価ドキュメントでも、エージェントは複雑な相互作用パターンを持つため可観測性が難しく、最終出力だけでなくワークフローの品質と効率も評価する必要があると説明されています。今回の更新は、まさにその評価結果を改善サイクルに接続するための動きと考えられます。(Microsoft Learn)
実務でのおすすめ対応手順
まずは本番反映ではなく、影響調査から始めます。おすすめの順序は次の通りです。
| 手順 | やること | 目的 |
|---|---|---|
| 1 | 対象エージェントを棚卸しする | Prompt agentかHosted agentかを切り分ける |
| 2 | App Insightsと評価イベントを確認する | Tracing Insights APIの前提を満たすか判断する |
| 3 | 直近の品質課題を1つ選ぶ | 最初の検証範囲を狭くする |
| 4 | Tracing Insights APIの結果を確認する | Warning/Criticalの検出精度を見る |
| 5 | FAOS用データセットに変換する | 検出結果を改善条件へ落とし込む |
| 6 | ステージングでFAOS最適化を試す | 本番影響なしで改善候補を作る |
| 7 | v1とv2を同じプロンプトで比較する | トークン数、pass rate、回答品質を評価する |
| 8 | 採用・破棄・再試行を決める | 自動化しすぎず、判断を明確にする |
最初から大規模に導入するより、「トークンが急増した」「TaskAdherenceが落ちた」など、1つの明確な課題で試すと判断しやすくなります。検証で効果が見えたら、対象エージェントや評価軸を広げるのが現実的です。
まとめ：まず確認すべきこと
今回のMicrosoft Copilot documentation updateは、Microsoft Foundryエージェントの運用品質を上げるための重要な更新です。ポイントは、Tracing Insights APIで異常を検出し、FAOSでプロンプトを最適化し、改善後のエージェントを検証する「insights → optimize」の流れが明文化されたことです。
ただし、現時点ではPRがOpenで、CI指摘も残っています。まずやるべきことは、正式マージ前に本番運用へ組み込むことではありません。自社のエージェントがPrompt agentなのか、Application Insightsと評価イベントが揃っているのか、FAOSを試せるワークスペースと権限があるのかを確認することです。
次に取るべき行動は明確です。対象エージェントを1つ選び、評価データの有無を確認し、Tracing Insights APIで検出できる課題を洗い出します。そのうえで、FAOSの最適化結果をv2エージェントとして検証し、トークン削減だけでなく、回答品質とタスク達成率まで見て採用判断を行いましょう。
コメント