Azure AI FoundryでAIエージェントを開発しているチームにとって、今回のポイントは「評価・トレース・改善の作業を、VS CodeとCopilot Chatの中で回しやすくなる」ことです。2026年6月3日に公開または更新されたAzure Updatesでは、Foundry Agents向けのCode-first observabilityがPublic Previewとして案内され、Foundry Plugin for VS Code Copilot Chat内のobserve skillとして提供されることが示されています。(Microsoft Azure)
ただし、これは本番監視を丸ごと置き換える機能ではありません。Azure Updates上の「In preview」は、すべてのAzure顧客が非本番用途のテストに利用できる段階と説明されており、Microsoft Learnでもプレビュー機能はSLAなしで、本番ワークロードには推奨されない場合があるとされています。(Microsoft Azure)
そのため、管理者と開発者は「開発効率化のためにどこまで使うか」「どのデータをトレースや評価に流すか」「既存のAzure MonitorやApplication Insightsとどう役割分担するか」を先に決めておく必要があります。
Azure AI FoundryのVS Code向け可観測性プレビューで何が変わるのか
今回の「Code-first observability for Foundry Agents in VS Code」は、Azure AI Foundryのエージェント開発を、ポータル中心の確認作業から、よりエディター中心の改善サイクルへ寄せるアップデートです。
Microsoft Foundryの可観測性は、評価、監視、トレースの3要素で構成されます。評価では応答品質や安全性、RAGの接地性、エージェントのツール呼び出し精度などを測定し、監視ではApplication Insightsと連携してトークン消費、レイテンシ、エラー率、品質スコアなどを追跡できます。トレースではLLM呼び出し、ツール呼び出し、エージェントの判断、サービス間依存関係を可視化できます。(Microsoft Learn)
今回のプレビューは、この可観測性の考え方をVS Codeの開発体験に近づけるものです。開発者は、エージェントのコードを書き、評価を実行し、失敗傾向を見て、プロンプトや設定を改善し、再評価する流れを、より短いサイクルで回しやすくなります。
| 観点 | これまで起きやすかったこと | 今回のプレビューで期待できること |
|---|---|---|
| 開発場所 | コードはVS Code、確認はポータルやログ基盤に分散 | VS Code内で評価・トレース・改善の流れを扱いやすくなる |
| 品質改善 | 手動テストや個別ログ確認に偏りやすい | 評価データセット、評価実行、失敗分析を開発ループに組み込みやすい |
| 問題発見 | デプロイ後にレイテンシ、ツール誤呼び出し、応答品質低下に気づく | 開発中からスモーク評価や回帰評価を走らせやすい |
| チーム運用 | 評価結果や改善履歴が属人化しやすい | .foundry配下の成果物や評価結果を使い、バージョン比較しやすい |
重要なのは、単に「ログが見やすくなる」だけではない点です。エージェント開発では、通常のアプリケーションのようにエラーコードだけを見れば原因が分かるとは限りません。回答が曖昧、ツール選択がずれる、検索結果をうまく使えない、安全性評価に落ちる、といった品質問題を継続的に検出する必要があります。今回のアップデートは、この改善サイクルを開発者の手元に近づける意味があります。
observe skillで実行できる評価駆動の改善サイクル
observe skillの中核は、評価駆動の最適化ループです。Microsoftのazure-skillsリポジトリでは、observe skillがFoundry agent向けに評価スイートの生成、データセットとルーブリック評価器のキャッシュ、バッチ評価、失敗クラスタリング、プロンプト最適化、再デプロイ、バージョン比較までを扱うものとして説明されています。(GitHub)
実務では、次のような流れを想定すると分かりやすいです。
| ステップ | 実施内容 | 見るべきポイント |
|---|---|---|
| 評価スイート作成 | 代表的な質問、期待動作、評価器を用意する | 業務上よくある質問と失敗しやすい境界条件が含まれているか |
| スモーク評価 | 小さなテストセットで基本動作を確認する | 起動、認証、ツール呼び出し、基本回答が壊れていないか |
| バッチ評価 | 複数の質問・シナリオをまとめて実行する | 関連性、タスク遵守、ツール呼び出し精度に偏りがないか |
| 失敗分析 | 低スコアの原因を分類する | プロンプト不足、検索データ不足、ツール定義の曖昧さ、モデル選定ミスを分ける |
| 最適化 | プロンプト、ツール説明、評価データ、モデル設定を調整する | 変更前後の差分を残し、感覚ではなく評価結果で判断する |
| 再評価・比較 | 同じ評価条件で再実行する | 改善した項目と悪化した項目を両方確認する |
例えば、社内FAQエージェントで「出張精算の期限」を答えさせる場合、単に正解文を1つ用意するだけでは不十分です。規程改定前の情報を参照していないか、関連する承認フローも説明できるか、根拠となる文書を示せるか、期限を断定できないケースで確認を促せるかまで評価対象にします。
このような評価をVS Code上の開発ループに近づけられると、エージェントの改善が「なんとなくプロンプトを直す作業」から「失敗パターンを見て、評価で再確認する作業」に変わります。
影響範囲：対象になるチームと、すぐには影響しにくいチーム
今回のアップデートで直接恩恵を受けやすいのは、Azure AI FoundryでFoundry Agentsを開発し、VS CodeとGitHub Copilot Chatを日常的に使っている開発チームです。
Foundry Agent Serviceは、AIエージェントを構築、デプロイ、スケールするためのマネージド基盤です。Prompt agentsではポータルやSDK/RESTで定義したエージェントをFoundry側で実行でき、Hosted agentsでは独自コードや各種フレームワークをコンテナ化して、マネージドエンドポイント、スケーリング、ID、可観測性を利用できます。(Microsoft Learn)
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| AIエージェント開発者 | VS Code内で評価・トレース・改善を回しやすくなる | Foundry Toolkit、Copilot Chat、評価データ、ローカルトレース設定 |
| Azure管理者 | 開発者が扱う拡張機能、権限、テレメトリの管理が必要になる | VS Code拡張機能の利用ポリシー、RBAC、Application Insights、Log Analytics |
| セキュリティ担当者 | プロンプト、入力、出力、ツール引数がトレースに含まれる可能性を確認する必要がある | 個人情報、機密情報、秘密情報、保持期間、アクセス制御 |
| DevOps担当者 | 評価をCI/CDやリリース判定に組み込みやすくなる | スモーク評価、回帰評価、評価結果の保存先、失敗時の扱い |
| 業務部門のレビュー担当者 | 回答品質を評価指標で確認しやすくなる | 期待動作、NG例、業務ルール変更時の評価データ更新 |
一方で、Azure AI Foundryを使っていないチーム、VS Codeを標準開発環境にしていないチーム、AIエージェントをまだ検証段階でしか使っていないチームでは、短期的な影響は限定的です。ただし、今後エージェントを本番利用に近づけるなら、評価データセットとトレース設計は早めに準備しておく価値があります。
管理者が確認すべき設定と運用上の注意点
プレビュー機能として利用範囲を限定する
最初に決めるべきなのは、利用範囲です。Public Previewは検証や非本番利用に向いた段階です。いきなり本番リリースの必須プロセスに組み込むのではなく、開発環境またはステージング環境で、1つの代表的なエージェントから試すのが安全です。
管理者は、少なくとも次の方針を決めておきましょう。
| 項目 | 推奨方針 |
|---|---|
| 利用環境 | まずは開発環境、次にステージング環境。本番への適用は運用実績を見て判断 |
| 対象エージェント | 重要度が高すぎず、評価しやすい業務シナリオから開始 |
| 利用者 | AIエージェント開発者、DevOps担当者、レビュー担当者に限定 |
| 成果物管理 | 評価データ、評価結果、最適化ログを保存するルールを決める |
| 本番判定 | プレビュー機能だけをリリース判定の唯一の根拠にしない |
VS Code拡張機能とCopilot Chatの利用条件を確認する
Foundry Toolkit Copilot toolsを使うには、VS Code、GitHub Copilot Chat拡張機能、Foundry Toolkit拡張機能が前提として案内されています。(Visual Studio Code)
また、Copilot ChatのAgentモードで利用可能なツールを確認し、必要に応じて選択・解除できます。(Visual Studio Code)
企業環境では、開発者が自由に拡張機能を追加できないことがあります。管理者は次を確認してください。
| 確認項目 | なぜ重要か |
|---|---|
| VS Code拡張機能の許可ポリシー | Foundry ToolkitやCopilot Chatを組織として許可する必要がある |
| GitHub Copilotのライセンス | Copilot Chatを使う開発者に適切なライセンスが必要 |
| サインイン先テナント | 個人アカウントや別テナントに誤接続すると、データ管理が崩れる |
| 拡張機能の更新タイミング | プレビュー機能は仕様変更があり得るため、更新管理が重要 |
| 開発端末のセキュリティ | ローカルで評価データやトレースを扱う場合、端末管理も必要 |
特に注意したいのは、開発者のローカル環境に業務データを置くケースです。評価用データセットに実顧客情報や社内機密が含まれるなら、匿名化、マスキング、アクセス制御を事前に決めておく必要があります。
Application InsightsとLog Analyticsの権限を確認する
Foundryのトレースでは、Application Insightsとの接続が重要です。Microsoft Learnでは、Foundryプロジェクト、Application Insightsリソース、接続済みApplication Insightsへのアクセス、テレメトリ照会に必要なLog Analytics Readerロールが前提として示されています。(Microsoft Learn)
また、FoundryプロジェクトのAgentsからTracesを開き、Application Insightsリソースを作成または接続する手順が案内されています。権限不足があると、トレースの閲覧やクエリでエラーになるため、Log Analytics Readerロールの割り当てやMicrosoft Entraグループでの管理を確認しておくべきです。(Microsoft Learn)
管理者向けの確認ポイントは次の通りです。
- 開発者がApplication Insightsに過剰な権限を持っていないか
- 評価担当者が必要なトレースだけを見られるか
- 本番テレメトリと検証テレメトリを同じ場所に混在させていないか
- Log Analyticsの保持期間とコスト設定が妥当か
- エージェントごと、環境ごとにログの見分けがつく命名になっているか
トレースに含まれる機密情報を制御する
トレースは非常に便利ですが、扱いを誤るとリスクになります。Microsoft Learnでは、トレースにユーザー入力、モデル出力、ツール引数、ツール結果などの機密情報が含まれる可能性があるため、プロンプトやスパン属性にシークレット、資格情報、トークンを保存しないこと、個人データなどを最小化・編集すること、ログやメトリックと同じアクセス制御・保持ポリシーを適用することが推奨されています。(Microsoft Learn)
実務では、次の失敗が起きがちです。
| 失敗例 | 対策 |
|---|---|
| APIキーや接続文字列をプロンプトやツール引数に含める | Key Vaultや環境変数で管理し、トレース対象に含めない |
| 実顧客データをそのまま評価データセットに入れる | 匿名化、サンプル化、合成データ化を行う |
| 開発環境のログ保持期間を確認しない | Application InsightsとLog Analyticsの保持期間・課金を確認する |
| 全開発者に広い閲覧権限を付ける | Entraグループ単位で最小権限を設定する |
| 失敗分析のためにデータをローカルへ散在させる | 保存場所、削除ルール、Git管理可否を明確にする |
開発者が確認すべき使い方
まず小さなスモーク評価から始める
observe skillの説明では、広範な回帰評価より先に、tier=smokeの評価スイートを実行するルールが示されています。(GitHub)
これは実務でも有効です。最初から大量の評価データを流すと、問題が多すぎて何を直すべきか分からなくなります。
最初のスモーク評価では、次のような10〜20件程度のデータから始めると扱いやすいです。
| 評価データの種類 | 例 |
|---|---|
| 正常系 | 「出張申請の締切を教えて」「経費精算の承認者を教えて」 |
| 不足情報あり | 「申請したい」だけの曖昧な依頼 |
| ツール呼び出しが必要 | 社内規程検索、チケット作成、CRM照会が必要な質問 |
| 禁止動作 | 権限外の個人情報を出そうとする質問 |
| 境界条件 | 古い規程、例外ルール、部署ごとの差異がある質問 |
この段階で見るべきなのは、完璧なスコアではありません。エージェントが正しいツールを呼ぶか、根拠を取り違えないか、分からないときに確認質問を返せるかを確認します。
評価指標は業務シナリオに合わせて選ぶ
Foundry Toolkitでは、プロンプトやエージェントをデータセットに対して実行し、F1 score、relevance、coherence、similarityなどの組み込み評価器を追加して評価できます。エージェント向けにはIntent Resolution、Task Adherence、Tool Call Accuracyなども示されています。(Visual Studio Code)
ただし、評価指標を増やせば品質が上がるわけではありません。業務に合わない指標を使うと、改善の方向を間違えます。
| シナリオ | 優先したい評価観点 |
|---|---|
| 社内FAQ・ナレッジ検索 | 関連性、接地性、根拠提示、古い情報の排除 |
| 業務申請エージェント | タスク遵守、確認質問、権限チェック、手順の正確性 |
| API操作エージェント | ツール呼び出し精度、引数の正確性、失敗時のリカバリー |
| カスタマーサポート | 応答の一貫性、安全性、トーン、エスカレーション判断 |
| 開発支援エージェント | コード生成の正確性、セキュリティ、実行可能性、変更範囲の妥当性 |
評価が低い場合も、すぐにプロンプトだけを直すのは避けましょう。原因は、プロンプト、ツール説明、検索データ、モデル選定、権限、ネットワーク、評価データのどれかにあります。失敗を分類してから修正する方が、結果的に早く改善できます。
ローカルトレースとクラウドトレースを使い分ける
Foundry ToolkitのTracingでは、ローカルのHTTP/gRPCサーバーがOTLP形式のトレースデータを収集し、VS Code内で可視化できます。OpenTelemetryの生成AI向けセマンティック規約に従うSDKやフレームワークを対象にでき、Azure AI Inference、Foundry Agent Service、LangChain、OpenAI SDKなどの互換性も案内されています。(Visual Studio Code)
開発中はローカルトレースで、1回の実行にどのモデル呼び出しやツール呼び出しが発生したかを見ると効率的です。一方、ステージングや本番に近い検証では、Application Insightsに送られるサーバーサイドトレースやAzure Monitorとの連携を確認します。
| 用途 | 向いているトレース |
|---|---|
| 開発中のデバッグ | VS Code内のローカルトレース |
| カスタムロジックの確認 | クライアント側のOpenTelemetry計装 |
| Foundry上の実行確認 | FoundryポータルのTraces |
| 運用監視 | Application Insights、Azure Monitor |
| 障害調査 | Trace ID、Conversation ID、ツール呼び出し履歴の突き合わせ |
ローカルで見えていたトレースがクラウド側で見えない場合は、Application Insights接続、RBAC、計装パッケージ、OTLPエンドポイント、実行トラフィックの有無を順に確認します。Microsoft Learnでも、トレースが見えない場合の原因として、接続未設定、最近のトラフィックなし、取り込み遅延、権限不足、クライアント側計装の不備などが挙げられています。(Microsoft Learn)
移行・展開時に注意すべきポイント
既存の監視基盤をすぐに置き換えない
今回のプレビューは、開発者の内側のループを速くする機能として捉えるべきです。Application InsightsやAzure Monitorでの本番監視、アラート、監査ログ、インシデント管理をすぐに置き換えるものではありません。
特に本番運用では、次の観点が必要です。
- SLOやSLAに関わるメトリック
- 障害時の通知先
- テレメトリの保持期間
- 監査証跡
- 個人情報・機密情報の扱い
- モデルやプロンプト変更時の承認フロー
- コスト監視
VS Code内で評価が改善しても、本番環境の実トラフィックで品質が維持されるとは限りません。開発中の評価、ステージング評価、本番監視を分けて設計しましょう。
評価データと評価器をバージョン管理する
AIエージェントの品質改善では、「どのプロンプトで、どの評価データに対して、どの評価器で、どのスコアだったか」を残すことが重要です。observe skillでは、評価スイート、評価器、データセット、評価結果を.foundry配下に保存する考え方が示されています。(GitHub)
ただし、すべてを無条件にGitへ入れるのは危険です。評価データに機密情報が含まれる場合は、リポジトリ管理の対象から外すか、匿名化したデータだけを管理します。
推奨される運用は次の通りです。
| 成果物 | 管理方針 |
|---|---|
| 評価スイート定義 | Git管理し、レビュー対象にする |
| 匿名化済み評価データ | Git管理可。ただし内容レビューを行う |
| 実データ由来の評価データ | Git管理しない。安全なストレージに保存 |
| 評価結果 | チームで参照できる場所に保存。機密情報の有無を確認 |
| 最適化ログ | 変更理由と評価結果を残す |
| プロンプト差分 | Pull Requestでレビューする |
リアルタイム情報を扱うエージェントでは評価の誤判定に注意する
Web検索、Bing Grounding、ライブAPIなどを使うエージェントでは、評価側のLLMが最新情報を検証できず、正しい回答を誤って「幻覚」と判定することがあります。observe skillの説明でも、リアルタイムデータソースを使う場合、LLM judgeの知識カットオフにより、実際には正しい最新情報が偽陽性として失敗扱いされる可能性があると注意されています。(GitHub)
対策としては、正確な日付や金額をLLMに判定させるのではなく、「根拠URLや取得元を示しているか」「取得できない場合に断定を避けているか」「回答形式が期待通りか」など、期待動作ベースのルーブリックを使う方法があります。
例えば、為替レートや在庫数のように変動する情報を扱う場合は、評価データに固定の正解値だけを入れるのではなく、次のような期待動作を書きます。
最新情報は接続先APIまたは検索結果から取得し、取得時刻または参照元を示す。取得できない場合は推測で数値を答えず、再試行または確認を促す。
このようにすると、事実の新旧による誤判定を減らし、エージェントのふるまいを評価しやすくなります。
すぐに確認すべきチェックリスト
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| Public Previewの利用範囲を開発・検証環境に限定したか | はい | 共有を受ける |
| VS Code、GitHub Copilot Chat、Foundry Toolkitの利用可否を確認したか | はい | はい |
| 対象テナント、サブスクリプション、Foundryプロジェクトを明確にしたか | はい | はい |
| Application Insights接続とLog Analytics Reader権限を確認したか | はい | 必要に応じて確認 |
| 評価データに個人情報や秘密情報が含まれていないか | はい | はい |
| スモーク評価用の小さなデータセットを用意したか | レビュー | はい |
| 評価指標が業務目的に合っているか | レビュー | はい |
| トレースの保持期間とコストを確認したか | はい | 共有を受ける |
| 評価結果とプロンプト変更の履歴を残す運用にしたか | はい | はい |
| 本番監視との役割分担を決めたか | はい | 共有を受ける |
まずは1つのエージェントで評価ループを試す
Azure AI FoundryのVS Code向けCode-first observabilityは、エージェント開発を「作って試す」から「評価しながら改善する」流れへ近づけるアップデートです。特に、VS CodeとCopilot Chatを中心に開発しているチームでは、observe skillを使うことで、評価、失敗分析、プロンプト最適化、再評価、バージョン比較のサイクルを短くできます。
一方で、Public Previewである以上、最初から本番運用の中核に置くのは避けるべきです。まずは開発環境の代表的なFoundry Agentを1つ選び、スモーク評価、ローカルトレース、Application Insights連携、評価結果の保存ルールを確認しましょう。
次に取るべき行動は明確です。既存のエージェントから「業務価値があり、評価しやすく、機密データを避けやすい」ものを1つ選び、10〜20件の評価データでobserve skillを試してください。その結果をもとに、チーム標準の評価データ形式、権限設計、トレース方針、リリース前チェックへ広げていくのが現実的です。
コメント