Azure AI Foundryの「Public Preview: Observability developer experience in Azure Developer CLI (azd)」で最初に押さえるべき点は、エージェントを作って終わりではなく、azdから評価データセット・評価ルーブリック・評価実行・結果確認までを回せる“品質確認ループ”が追加されたことです。特にHosted AgentをAzure Developer CLIで作成・プロビジョニング・デプロイしている開発チームは、リリース前の品質確認やプロンプト変更後の回帰確認をCLIベースで標準化しやすくなります。公式情報では、この機能はMicrosoft Foundryで作成したエージェントに測定可能な品質ループを追加するためのプレビュー機能として案内されています。(Microsoft Azure)
ただし、これは本番監視を丸ごと置き換える機能ではありません。Microsoft Learnでは、プレビュー機能はSLAなしで提供され、運用環境での利用は推奨されない場合があると説明されています。まずは検証環境で、評価対象のエージェント、評価データ、評価モデル、権限、外部API呼び出しの影響を確認してから、CI/CDやリリース判定に組み込むのが安全です。(Microsoft Learn)
Azure AI Foundryのazd Observabilityプレビューで何が変わるのか
今回の変更は、Azure AI Foundryにおけるエージェント開発の「観測性」を、単なるログ確認ではなく評価駆動の品質管理として扱いやすくするものです。
従来、AIエージェントの品質確認は、手元のテスト用プロンプトを投げる、Foundryポータルで動作を確認する、独自スクリプトで評価する、といった形になりがちでした。今回のazd CLI評価エクスペリエンスでは、エージェントのライフサイクルに評価コマンドを組み込み、eval.yamlを中心に評価条件を再利用できるようになります。公式ドキュメントでも、主要な評価エクスペリエンスはHosted Agentのライフサイクル向けに設計され、azd ai agent init、azd provision、azd deploy、azd ai agent eval init、azd ai agent eval run、azd ai agent eval updateという流れが示されています。(Microsoft Learn)
| 変更点 | できるようになること | 実務上の意味 |
|---|---|---|
azd ai agent eval initの利用 | 評価用のローカル資産を作成・修復できる | 最初の評価セットアップをCLIで始められる |
eval.yamlの生成・利用 | エージェント、データセット、エバリュエーター、生成オプションを記録できる | チーム内で同じ評価条件を再利用しやすい |
| データセットと評価ルーブリックの生成 | エージェントの用途に合わせた評価資産を作れる | 手作業の評価観点づくりを短縮できる |
eval run、eval list、eval show | 評価実行と結果確認をCLIで行える | CI/CDやリリース前チェックに組み込みやすい |
eval update | ローカル編集した評価資産を新しいサービスバージョンとして登録できる | 評価基準の変更履歴を管理しやすい |
optimize --config eval.yaml | 条件を満たせば評価レシピから最適化へ進める | 品質評価から改善候補の生成までつなげられる |
重要なのは、azd provisionだけでは評価データセット、エバリュエーター、スイート、最適化ジョブは作成されない点です。評価のセットアップは、明示的にazd ai agent eval initで開始する必要があります。(Microsoft Learn)
対象になるユーザーと影響範囲
このプレビューの主な対象は、Azure AI Foundryでエージェントを開発し、Azure Developer CLIを使って環境構築やデプロイを進めている開発者・MLOps担当者・管理者です。
特に影響が大きいのは、Hosted Agentをazdで管理しているチームです。公式ドキュメントでは、Hosted Agentの場合、既存のFoundryプロジェクトがなくてもazd ai agent initとazd provisionで必要なリソースを作成できるとされています。一方、プロンプトベースのエージェントも、Foundryプロジェクト内で評価ターゲットとして利用できる状態であれば評価できます。(Microsoft Learn)
| 立場 | 確認すべきポイント |
|---|---|
| エージェント開発者 | eval.yaml、データセット、評価ルーブリックを読み、評価結果が実際の業務品質を反映しているか確認する |
| DevOps / MLOps担当者 | eval runをCI/CDに組み込めるか、評価失敗時の扱いを決める |
| Azure管理者 | Foundryリソースへの権限、モデルデプロイ、サブスクリプション、クォータを確認する |
| セキュリティ担当者 | 評価データに個人情報や機密情報が混ざらないか、外部API呼び出しが発生しないか確認する |
| プロダクト責任者 | 評価スコアをリリース可否の判断に使う場合、しきい値と例外ルールを決める |
逆に、Azure AI Foundryのポータル上で手動検証だけを行っているチームや、まだazdを開発フローに入れていないチームにとっては、すぐに本番運用へ影響する変更ではありません。まずは小さなPoC用エージェントで、CLI評価の流れを試すのが現実的です。
まず確認すべき前提条件
azd CLIの評価機能を使う前に、環境・権限・対象エージェントが整っているかを確認します。Microsoft Learnでは、Microsoft FoundryにアクセスできるAzureサブスクリプション、Azure Developer CLI、azd ai agent拡張機能、認証済みのazdセッション、FoundryリソースのFoundry Userロール、チャット補完をサポートするモデルデプロイなどが前提として示されています。(Microsoft Learn)
実務では、次の順番で確認すると抜け漏れを減らせます。
| 確認項目 | 確認方法の例 | 見落としやすい点 |
|---|---|---|
| azdにログイン済みか | azd auth status | Azure CLIのaz loginだけではなく、azd側の認証も確認する |
| 拡張機能が利用できるか | azd extension install azure.ai.agents | スターターテンプレート初期化時に自動インストールされる場合もある |
| Foundryリソース権限 | Foundry Userロールの有無 | 管理者権限があっても、評価対象リソースに必要なロールが不足する場合がある |
| モデルデプロイ | Foundryプロジェクト内のデプロイ確認 | 評価や生成に使うモデルが同じプロジェクトで使えるか確認する |
| 評価対象エージェント | azd ai agent statusなど | Hosted Agentはデプロイ済みで呼び出し可能な状態が必要 |
| 評価データ | 生成データまたはJSONLデータセット | 業務上の代表例が含まれているかを人が確認する |
Hosted Agentでは、評価資産を初期化する前に、エージェントをデプロイし、呼び出し可能な状態にしておく必要があります。プロンプトベースのエージェントでは、Foundryプロジェクト内にエージェントが存在し、評価対象として利用できること、プロジェクトエンドポイントとエージェントターゲットへアクセスできることを確認します。(Microsoft Learn)
基本的な利用手順
azd CLI評価エクスペリエンスの基本は、エージェントをデプロイした後に評価資産を初期化し、評価を実行し、結果を確認する流れです。
azd ai agent init
azd provision
azd deploy
azd ai agent eval init
azd ai agent eval run
azd ai agent eval showazd ai agent eval initを実行すると、対話型ウィザードがazd環境からエージェントターゲットを検出し、どのようなエージェントで、どのシナリオをテストしたいかを説明する生成命令を求めます。生成後は、eval.yaml、データセット、エバリュエーターが作成され、次の手順としてazd ai agent eval runやazd ai agent eval updateが案内されます。(Microsoft Learn)
スクリプトやCIで使う場合は、生成命令、評価モデル、サンプル数を明示できます。
azd ai agent eval init \
--gen-instruction "This agent handles restaurant reservations. Test booking, modification, cancellation, and policy enforcement." \
--eval-model gpt-4o \
--max-samples 100既存のゴールデンデータセットを持っている場合は、ローカルファイルや登録済みデータセットを指定できます。
azd ai agent eval init \
--dataset ./tests/support-golden.jsonl \
--gen-instruction "Support quality, policy adherence, and escalation behavior" \
--max-samples 50 \
--evaluator builtin.intent_resolution \
--evaluator support-quality \
--output eval.yaml評価は次のように実行します。
azd ai agent eval run --config eval.yaml評価後は、最近の実行一覧を確認し、最新または特定の実行結果を表示します。
azd ai agent eval list
azd ai agent eval show
azd ai agent eval show --eval-id <run-id>評価結果では、評価されたエージェントのバージョン、解決されたデータセットと評価器のバージョン、実行ステータス、生成されたメトリックやスコア、トークン使用状況やエバリュエーターログに調査が必要かどうかを確認できます。(Microsoft Learn)
eval.yamlはチームで管理すべき重要ファイル
この機能を実務で使ううえで中心になるのがeval.yamlです。eval.yamlには、エージェントターゲット、データセット参照、エバリュエーター参照、生成オプションが記録されます。生成されたデータセットはdatasets/、エバリュエータールーブリックはevaluators/配下に置かれ、ローカルファイルとして編集できます。(Microsoft Learn)
ここで注意したいのは、ローカルファイルを編集しただけでは、評価実行で使われる登録済みバージョンに反映されないことです。ローカルのデータセットや評価ルーブリックを編集した場合は、azd ai agent eval updateでサービス上の新しいバージョンとして登録し、eval.yamlのバージョン参照を更新してから再評価します。(Microsoft Learn)
azd ai agent eval update
azd ai agent eval run --config eval.yamlチーム開発では、eval.yamlをソース管理に含めるべきです。評価条件が各開発者の手元で変わってしまうと、スコアの比較ができなくなります。Microsoft Learnでも、レビュー可能で再現可能な評価レシピが必要な場合はeval.yamlをソース管理し、必要に応じてdatasets/やevaluators/もソース管理することが推奨されています。(Microsoft Learn)
管理者・開発者が確認すべき設定ポイント
導入前に、次の設定を最低限チェックしておきましょう。
| 項目 | 確認する理由 | 推奨アクション |
|---|---|---|
| Foundryリソースのロール | 評価資産の作成や実行に権限が必要 | 開発者に必要最小限のFoundry Userロールを付与する |
| モデルデプロイ | 評価や生成にモデルが使われる | 評価用モデルを検証環境で明示する |
| 評価対象エージェント | デプロイ前だと評価できない | Hosted Agentはazd deploy後にazd ai agent statusで確認する |
| データセット | スコアの妥当性を左右する | 生成データだけに頼らず、業務代表例を追加する |
| エバリュエーター | 評価基準が曖昧だとスコアが使えない | ルーブリックを人がレビューし、必要に応じて編集する |
| 外部ツール呼び出し | 評価時に実APIやDBが呼ばれる可能性がある | モック、テストエンドポイント、読み取り専用環境を用意する |
| コスト・クォータ | 評価実行でモデル呼び出しやトークン消費が発生する | サンプル数を小さく始め、使用量を確認する |
特に外部ツール呼び出しは軽視できません。エージェント最適化のドキュメントでは、データセット内の全タスクに対してエージェントが呼び出され、外部API、データベース、サードパーティサービスなども評価実行時に呼び出される可能性があるため、意図しない料金、状態変更、レート制限を避けるにはテストエンドポイントやモック実装の利用が推奨されています。(Microsoft Learn)
移行・展開時の注意点
既存のAzure AI Foundryエージェント開発にこのプレビューを取り入れる場合、いきなり本番パイプラインへ入れるのではなく、段階的に展開するのが安全です。
まずは、代表的な1つのエージェントでeval initを実行し、生成されたデータセットと評価ルーブリックをレビューします。次に、既存のテスト観点や問い合わせログから、ゴールデンデータセットとして使えるシナリオを少量追加します。最初から大規模な評価にすると、スコアの意味を検証する前にコストや実行時間だけが増えやすくなります。
Microsoft Learnのベストプラクティスでも、小さな生成データセットまたはゴールデンデータセットの小さなサブセットから始めること、スコアを信頼する前に生成されたデータセットと評価者レビュー成果物を確認すること、エージェント変更後に同じeval.yamlを再実行して同じテストレシピで比較することが推奨されています。(Microsoft Learn)
| フェーズ | 実施内容 | 合格ラインの例 |
|---|---|---|
| 検証 | 1エージェントでeval initとeval runを試す | 評価が最後まで完了し、結果を説明できる |
| 評価基準の整備 | データセットとルーブリックをレビュー・編集する | 業務上重要な失敗パターンが含まれている |
| 再現性の確保 | eval.yamlをソース管理する | 誰が実行しても同じ評価条件になる |
| CI/CD連携 | PRやリリース前にeval runを実行する | しきい値未満ならレビュー対象にする |
| 最適化連携 | 必要に応じてazd ai agent optimize --config eval.yamlを試す | 候補を人が確認してから適用する |
azd ai agent optimize --config eval.yamlは、少なくとも1つの評価実行が成功し、エージェントとレシピが前提条件を満たした後に利用できます。ただし、最適化コマンドはジョブを送信するだけで、ソース変更を自動適用したり候補エージェントを自動再デプロイしたりするわけではありません。変更を適用する前に、出力内容を確認する必要があります。(Microsoft Learn)
よくある失敗と回避策
azdの評価機能は便利ですが、評価の前提を誤ると、スコアが形だけのものになってしまいます。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
デプロイ前にeval initする | 評価対象のエージェントが見つからない、または実行できない | Hosted Agentはデプロイ後、呼び出し可能な状態で初期化する |
| 生成データをそのまま信頼する | 実業務の失敗パターンを評価できない | 生成データをレビューし、実例に近いシナリオを追加する |
| ルーブリックを読まずに使う | 高スコアでもビジネス要件を満たさない | 評価軸、重み、合否条件をチームで確認する |
ローカル編集後にeval updateしない | 編集内容が評価に反映されない | データセットやルーブリック編集後は必ずeval updateする |
eval.yamlを共有しない | 開発者ごとに評価条件がズレる | eval.yamlをリポジトリに含め、レビュー対象にする |
| 本番APIを評価で呼ぶ | 料金発生、データ変更、レート制限が起きる | テスト環境、モック、読み取り専用キーを使う |
| プレビュー機能を本番前提で使う | SLAや機能制限で運用リスクが残る | リリースゲートの補助として使い、最終判断は人間のレビューも併用する |
また、--reset-defaultsはローカルのeval.yamlを上書きし、既定の評価資産を再生成しますが、既存のサービス登録済みデータセットやエバリュエーターバージョンは削除されません。評価をやり直す場合でも、どの資産が残り、どのローカル設定が置き換わるのかを把握してから実行しましょう。(Microsoft Learn)
本番監視との違いも理解しておく
このプレビューは「Observability」という名前ですが、一般的なアプリケーション監視のように、常時メトリックを監視してアラートを出す機能そのものではありません。Microsoft Learnの制限事項では、プライマリコマンドフローはHosted Agentとデプロイ後の評価ループ向けに最適化されており、スケジュールされた評価、継続的な評価、アラート、比較ワークフローは最初の評価パスには必要ないものとして整理されています。(Microsoft Learn)
そのため、実運用では次のように役割を分けると分かりやすくなります。
| 目的 | azd評価機能の役割 | 別途必要になりやすいもの |
|---|---|---|
| リリース前の品質確認 | 評価データセットに対する応答品質の確認 | レビュー承認、セキュリティチェック |
| プロンプト変更後の回帰確認 | 同じeval.yamlで再評価 | 差分比較ルール、合否しきい値 |
| 障害調査 | 評価結果やログから問題の傾向を確認 | アプリログ、トレース、Azure Monitorなど |
| 継続監視 | 補助的な評価ループ | 本番監視、アラート、利用者フィードバック収集 |
| 改善候補の検証 | 最適化への入力として利用 | 人による候補レビュー、段階的デプロイ |
つまり、この機能は「運用監視の代替」ではなく、エージェント品質をリリース前後で測れる形にするための開発者向け体験と捉えるのが適切です。
導入するなら何から始めるべきか
最初の一歩としては、既存または新規のHosted Agentを1つ選び、検証環境で次の流れを実行するのがおすすめです。
azd auth status
azd ai agent status
azd ai agent eval init
azd ai agent eval run --config eval.yaml
azd ai agent eval showその後、生成されたeval.yaml、datasets/、evaluators/を確認し、実際の業務シナリオに合っているかをレビューします。評価スコアが高いか低いかだけでなく、「なぜその評価になったのか」「業務上許容できる失敗なのか」「リリース判定に使える基準なのか」を確認することが重要です。
今回のPublic Previewは、Azure AI Foundryでエージェント開発を進めるチームにとって、品質評価を属人的な手作業からCLIで再現できるプロセスへ近づける更新です。まずは小さく試し、eval.yamlをチームの評価レシピとして整備し、CI/CDへ組み込むかどうかを判断しましょう。プレビュー段階であることを踏まえ、本番環境への直接適用ではなく、検証環境で評価データ・権限・外部呼び出し・コストを確認することが、もっとも安全で実務的な進め方です。
コメント