Azure AI FoundryでAIエージェントや社内Copilotを本番展開する場合、今回押さえるべき結論は「回答の良し悪しを感覚で判断せず、品質・安全性・ツール利用を評価データと組み込み評価器で継続的に測る」ことです。Microsoft Learnの「Evaluate your AI agents」では、Foundry agentやhosted agentを対象に、Task Adherence、Coherence、Violenceなどの評価器を使って、開発中・展開前・運用中に評価を回す流れが整理されています。(Microsoft Learn)
特に管理者は、Foundry Userロール、リージョン制約、Application Insights連携、マネージドIDの権限を確認する必要があります。開発者は、評価データセット、data_mapping、評価対象のエージェントバージョン、合格基準を明確にして、CI/CDや継続評価に組み込むのが実務上のポイントです。
Azure AI FoundryのAIエージェント評価で何が変わるのか
今回の公式情報は、単に「評価機能がある」と説明するものではありません。Azure AI Foundry上で作成したAIエージェントを、リリース前にどのように検証し、運用後にどう改善サイクルへつなげるかを示しています。
これまでAIエージェントの評価は、担当者が何度か質問して「だいたい問題なさそう」と判断しがちでした。しかし、業務で使うエージェントでは、以下のような失敗が起こります。
- 指示には従っているように見えるが、禁止された操作をしてしまう
- 回答は自然だが、ユーザーの目的を完了していない
- ツール呼び出しの引数が間違っている
- 安全性に問題のある回答を一部の条件で返す
- 新しいバージョンにしたら、以前より成功率が下がる
「Evaluate your AI agents」は、こうした問題を評価器とテストデータで可視化するための手順です。公式ドキュメントでは、開発中に評価を実行してベースラインを作り、たとえばTask Adherenceの合格率のような受け入れ基準を設定してからユーザーへ公開する考え方が示されています。(Microsoft Learn)
今回の更新で確認すべき主なポイント
Azure AI Foundryの管理者・開発者が確認すべき点を整理すると、以下のようになります。
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| 評価対象 | Foundry agentまたはhosted agent | モデル単体ではなく、エージェントとしての振る舞いを評価できる |
| 評価器 | 品質、安全性、エージェント固有動作の組み込み評価器 | 手動レビューだけに頼らず、評価観点を標準化できる |
| SDK | azure-ai-projects>=2.0.0を利用 | 既存の検証スクリプトはSDKバージョン確認が必要 |
| 権限 | Foundry project上のFoundry Userロールが前提 | 管理者はRBAC名の変更と割り当てを確認する |
| 結果確認 | Foundry portalのEvaluationsタブ、集計結果、行単位の出力 | 失敗したテストケースを個別に追跡しやすくなる |
| 運用連携 | CI/CD、継続評価、本番監視への統合 | リリース判定や品質劣化検知に使える |
公式手順では、Python 3.8以降、Foundry project、チャット補完に対応するAzure OpenAIのGPTモデルデプロイ、Foundry Userロールが前提条件として示されています。また、評価機能にはリージョン制約があるため、利用中のプロジェクトのリージョン確認も必要です。(Microsoft Learn)
評価器は「品質」「安全性」「エージェント動作」で選ぶ
Azure AI FoundryのAIエージェント評価では、評価器を目的別に選ぶことが重要です。公式例では、Task Adherence、Coherence、Violenceの組み合わせが紹介されています。Task Adherenceはシステム指示に従っているか、Coherenceは回答が論理的で構造化されているか、Violenceは暴力的な内容を含むかを測る評価器です。(Microsoft Learn)
ただし、実務ではこの3つだけで十分とは限りません。業務エージェントの種類に応じて、評価観点を増やす必要があります。
| 利用シーン | 優先して使いたい評価観点 | 理由 |
|---|---|---|
| 社内FAQ・問い合わせ対応 | Coherence、Intent Resolution、Groundedness | 質問意図を正しく理解し、根拠のある回答を返す必要がある |
| ワークフロー自動化 | Task Completion、Task Adherence | 依頼されたタスクを完了し、業務ルールを守る必要がある |
| APIや業務システム連携 | Tool Call Accuracy、Tool Selection、Tool Input Accuracy | 正しいツールを選び、正しい引数で呼び出す必要がある |
| 顧客対応チャット | Hate/Unfairness、Self-harm、Sexual、Violence | 不適切・危険な応答を避ける必要がある |
| 機密情報を扱うエージェント | Sensitive Data Leakage、Prohibited Actions | 情報漏えいや禁止操作の検出が必要になる |
Agent evaluatorsには、最終結果を見るSystem evaluationと、ツール呼び出しなどの途中過程を見るProcess evaluationがあります。Task Completion、Task Adherence、Intent Resolutionなどは結果の良し悪しを見る用途に向き、Tool Call Accuracy、Tool Selection、Tool Input Accuracy、Tool Output Utilization、Tool Call Successはツール利用の妥当性を見る用途に向きます。(Microsoft Learn)
管理者がまず確認すべき設定
Foundry Userロールの割り当てを確認する
今回の情報で見落としやすいのが、RBACロール名の変更です。Microsoft Learnでは、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerから名称変更されたと説明されています。ロールIDと主要な権限は変更されていませんが、移行中は旧名称が一部に表示される可能性があります。(Microsoft Learn)
管理者は、以下を確認してください。
- 評価を実行するユーザーまたはサービスプリンシパルにFoundry Userロールがあるか
- 旧名称のAzure AI Userを前提にした運用手順書が残っていないか
- CI/CDで使うIDに必要なデータプレーン権限があるか
- 継続評価や監視で使うプロジェクトのマネージドIDにFoundry Userロールがあるか
特に、AzureのOwnerやContributorを持っていても、Foundryのデータプレーン操作に必要なロールが不足するケースがあります。権限エラーが出た場合は、AzureリソースのIAMだけでなく、Foundry project側のロールも確認する必要があります。
リージョン制約を事前に確認する
評価機能はすべてのリージョンで同じように使えるとは限りません。公式情報では、リスク・安全性評価器やAI red teaming、agent playground evaluation、batch evaluation、Azure OpenAI gradersなどにリージョン制約があることが示されています。たとえば、batch evaluationがサポートされないリージョンや、Azure OpenAI gradersが使えないリージョンがあります。(Microsoft Learn)
本番展開前に、次の観点で確認すると失敗を減らせます。
| 確認項目 | 判断基準 |
|---|---|
| プロジェクトのリージョン | 使いたい評価器がそのリージョンでサポートされているか |
| 既存環境の移行 | 評価機能を使うために新規リージョンへプロジェクトを作る必要がないか |
| セキュリティ要件 | データ所在地や社内ポリシーと評価機能の対応リージョンが合うか |
| CI/CD実行 | 自動評価で使うリージョンとモデルデプロイの配置が整合しているか |
特に日本リージョンを中心に設計している環境では、必要な評価機能が対象リージョンで使えるかを早めに確認してください。使えない場合は、検証用プロジェクトを別リージョンに作るか、評価方法を分ける設計が必要になることがあります。
Application InsightsとLog Analyticsの権限を確認する
運用中のエージェントを監視する場合、Agent Monitoring Dashboardの設定も重要です。公式ドキュメントでは、Agent Monitoring Dashboardでトークン使用量、レイテンシ、成功率、評価結果を確認でき、Application InsightsリソースがFoundry projectに接続されていることが前提とされています。ログベースのビューでは、関連するLog Analytics workspaceへのアクセス権も必要です。(Microsoft Learn)
継続評価を使う場合は、プロジェクトのマネージドIDにFoundry Userロールを割り当てる必要があります。設定漏れがあると、ポータル上ではエージェントが動いていても、評価結果が出ない、継続評価ルールが失敗する、といった問題につながります。(Microsoft Learn)
開発者が確認すべき実装ポイント
テストデータはJSONLで小さく始める
公式手順では、各行にqueryフィールドを持つJSONLファイルを作成し、Foundry projectのデータセットとしてアップロードする流れが示されています。評価実行時には、サービスが各テストクエリをエージェントに送り、返答を取得して、選択した評価器でスコアリングします。(Microsoft Learn)
最初から大量のデータを作る必要はありません。まずは次のようなテストケースを30〜50件程度用意すると、実務で使える評価に近づきます。
- 通常の成功パターン
- 曖昧な依頼
- 権限が必要な依頼
- 禁止操作を誘導する依頼
- ツール呼び出しが必要な依頼
- 入力値が不足している依頼
- 日本語・英語・略語が混ざる依頼
- 社内用語や部署名を含む依頼
たとえば、経費精算エージェントなら「先月の交通費を申請して」だけでなく、「領収書がない場合の交通費を申請して」「承認者を飛ばして申請して」「別部署の予算コードで申請して」のように、実際に起こりやすい失敗条件を入れるべきです。
sample.output_itemsとsample.output_textを使い分ける
評価で失敗しやすいのが、data_mappingの指定です。公式手順では、{{item.X}}はテストデータのフィールド、{{sample.output_items}}はツール呼び出しを含むエージェント応答全体、{{sample.output_text}}は最終的な応答テキストを参照すると説明されています。(Microsoft Learn)
判断基準はシンプルです。
| 評価したい内容 | 使うべきマッピング |
|---|---|
| 最終回答の文章品質 | {{sample.output_text}} |
| 暴力・性的・ヘイトなどの安全性 | {{sample.output_text}} |
| システム指示に従ったか | {{sample.output_items}} |
| ツール呼び出しの流れ | {{sample.output_items}} |
| ツールの引数や結果の利用 | {{sample.output_items}}または評価器が要求するフィールド |
たとえば、Task Adherenceではツール呼び出しを含む文脈が必要になるため、responseに{{sample.output_items}}を渡すほうが適しています。一方、CoherenceやViolenceのように最終テキストを見る評価では、{{sample.output_text}}を使うほうが分かりやすくなります。
LLM-as-judgeのモデルデプロイ名を確認する
Task AdherenceやCoherenceのようなAI支援型の評価器では、initialization_parametersにモデルデプロイ名を指定します。この値は、プロジェクト内のGPTモデルデプロイ名と一致している必要があります。(Microsoft Learn)
ここでよくあるミスは、モデル名とデプロイ名を混同することです。たとえば、モデルとしてgpt-4o-miniを使っていても、Azure上のデプロイ名がeval-gpt4o-miniであれば、指定するのはデプロイ名です。
また、CoherenceやFluencyのような一般目的評価器はLLM-as-judgeとして動作し、評価呼び出しごとにモデル推論コストが発生します。公式情報では、非常に短い応答ではスコア信頼性が変動する可能性があり、これらの評価器は現在英語応答をサポートすると説明されています。日本語応答を評価する場合は、社内の期待値に合うかを小規模データで検証してから本番の合格基準に使うのが安全です。(Microsoft Learn)
Safety evaluatorsはモデルデプロイ指定が不要な場合がある
Risk and safety evaluatorsは、暴力、性的、自傷、ヘイト、不公平表現、保護された素材、コード脆弱性などのリスクを評価するための評価器です。公式情報では、リスク・安全性評価器はFoundry Evaluation serviceのホストされた評価言語モデルを使い、CoherenceやFluencyのようなLLM-as-judge評価器とは異なり、deployment_nameの初期化パラメータを必要としないと説明されています。(Microsoft Learn)
エージェント固有の安全性では、Prohibited ActionsやSensitive Data Leakageも用意されています。ただし、これらはプレビューで、agent targets向けであり、ツール呼び出し情報が必要です。禁止操作や機密情報漏えいを見たい場合は、テストデータとログにツール呼び出しの情報が含まれているかを確認してください。(Microsoft Learn)
評価結果は「集計」と「行単位」の両方を見る
評価を実行すると、全体の合格・不合格件数、モデルごとのトークン使用量、評価器ごとの結果を確認できます。さらに、各テスト行ごとに、元のクエリ、エージェントの応答、個別評価器のスコアや理由、トークン使用量が返されます。(Microsoft Learn)
実務では、集計結果だけでリリース判断をしないことが重要です。たとえば、全体の合格率が90%でも、残り10%が「機密情報の漏えい」「禁止されたツール操作」「顧客への不適切回答」であれば、本番公開は危険です。
評価結果を見るときは、次の順番がおすすめです。
- 評価器ごとの失敗率を見る
- 失敗した行を確認する
- 失敗理由を分類する
- プロンプト、ツール定義、権限、データソースのどれが原因か切り分ける
- 修正後に同じデータセットで再評価する
特にバージョン比較では、毎回テストデータや評価器を変えないことが重要です。評価定義を同じにしておくと、エージェントの改善・劣化を比較しやすくなります。
CI/CDと本番監視にどう組み込むべきか
公式情報では、評価をCI/CDパイプラインの品質ゲートとして使うこと、また継続評価によって本番環境のエージェントを監視することが示されています。さらに、評価を繰り返し実行し、弱点を特定し、指示やツールを調整し、再評価して改善を測る流れも推奨されています。(Microsoft Learn)
開発チームで使うなら、次のような流れが現実的です。
| フェーズ | 実施内容 | 合格基準の例 |
|---|---|---|
| 開発中 | 少数のJSONLで手動評価 | 重大な安全性失敗がない |
| リリース前 | CI/CDで自動評価 | Task AdherenceやTool Call Accuracyが基準値以上 |
| 本番初期 | Application InsightsとMonitorで確認 | レイテンシ、失敗率、評価スコアが許容範囲 |
| 運用中 | 継続評価と定期評価 | 品質劣化や安全性リスクを検出したら改善タスク化 |
| バージョン更新時 | 旧版と新版を比較 | 主要評価指標が悪化していない |
GitHub Actions連携では、テストクエリと評価器リストを指定してエージェントを呼び出し、評価結果のサマリーレポートを生成できます。公式ドキュメントでは、このGitHub Actionはプレビューとして説明され、CI/CD内で本番公開前に問題を見つける用途が示されています。(Microsoft Learn)
移行・展開前のチェックリスト
本番展開前には、以下を確認してください。
| チェック項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| RBAC | Foundry Userロールが評価実行者、CI/CDのID、必要なマネージドIDに付与されているか | 評価実行や継続評価が失敗する |
| ロール名変更 | 旧Azure AI User表記の手順書をFoundry Userに更新したか | 運用担当者が誤った権限確認をする |
| SDK | azure-ai-projects>=2.0.0を使っているか | サンプルコードや評価APIが動かない |
| モデルデプロイ | LLM-as-judge用のデプロイ名が正しいか | 評価器の初期化で失敗する |
| リージョン | 使う評価器がプロジェクトのリージョンでサポートされているか | 本番直前に評価機能が使えない |
| データセット | JSONLのフィールド名とdata_mappingが一致しているか | 評価器が入力を読めず、結果が不正確になる |
| エージェントバージョン | 評価対象のバージョンを明示しているか | 最新版が自動的に評価され、比較不能になる |
| ツール定義 | ツール評価に必要なtool_definitionsやtool callsがあるか | ツール利用の品質を評価できない |
| 監視 | Application InsightsとLog Analytics権限が整っているか | 本番運用中の品質劣化を検出しにくい |
| コスト | 評価回数、テスト件数、judge modelの使用量を見積もったか | CI/CDや定期評価で予期しないコストが発生する |
評価ランには制限もあります。公式情報では、評価行ごとの最大サイズやバッチ評価の最大行数、レート制限時のretry-afterヘッダー、指数バックオフの利用が説明されています。大量の評価をCI/CDや夜間バッチで回す場合は、再試行設計とコスト見積もりを先に入れておくべきです。(Microsoft Learn)
よくある失敗と対策
手動テストだけで本番公開してしまう
数回のチャットで問題がなかったとしても、業務エージェントの品質は保証できません。曖昧な依頼、禁止操作、権限外の操作、ツール引数の不足など、失敗しやすいケースをテストデータに入れて評価してください。
合格率だけを見て重大リスクを見逃す
全体のスコアが高くても、安全性や機密情報の失敗が1件でもある場合は重大です。合格率だけでなく、評価器ごとの失敗内容を確認してください。
latest相当の評価でバージョン比較してしまう
評価対象のversionを省略すると最新バージョンが使われる場合があります。リリース判定や比較を目的にするなら、評価対象バージョンを明示し、旧版と新版を同じ条件で比較するのが安全です。公式サンプルでも、エージェントターゲットにnameと任意のversionを指定する形が示されています。(Microsoft Learn)
hosted agentのプロトコル差分を見落とす
公式情報では、responses protocolを使うprompt agentsとhosted agentsではサンプルが利用できる一方、invocations protocolを使うhosted agentsではinput_messages形式が異なり、構造化テンプレートではなくfreeform JSON objectを渡す必要があると説明されています。hosted agentを評価する場合は、評価対象のプロトコルを先に確認してください。(Microsoft Learn)
日本語エージェントで評価器の特性を確認しない
英語中心の評価器やサンプルをそのまま日本語業務に適用すると、期待通りの判定にならないことがあります。日本語FAQ、社内用語、敬語、曖昧な表現、略語を含むテストデータを用意し、評価結果が人間のレビューと大きくずれないかを確認してください。
管理者と開発者の役割分担
Azure AI FoundryのAIエージェント評価は、開発者だけで完結するものではありません。評価を継続的に回すには、管理者側の設定が必要です。
| 役割 | 主な担当 |
|---|---|
| 管理者 | RBAC、リージョン、Application Insights、Log Analytics、ネットワーク、ストレージ、コスト管理 |
| 開発者 | 評価データ、評価器選定、SDK実装、data_mapping、エージェント修正、CI/CD連携 |
| セキュリティ担当 | 禁止操作、機密情報漏えい、安全性評価、red teamingの基準作成 |
| 業務部門 | 期待する回答、NG操作、業務ルール、合格基準の定義 |
ネットワーク分離が必要な環境では、評価用の仮想ネットワーク構成やBring your own storageも検討対象になります。公式情報では、評価向けの仮想ネットワークサポート、Application Insightsへ評価データが送信される点、評価やred teamingの失敗を防ぐためにプロジェクトのマネージドIDへFoundry Userロールを割り当てる点が説明されています。(Microsoft Learn)
まず実行すべき次のアクション
最初にやるべきことは、評価環境を完璧に作ることではありません。まず、現在のエージェントに対して小さな評価セットを作り、公式手順の流れで1回評価を実行することです。
おすすめの進め方は次の通りです。
- 代表的な業務クエリを30件程度JSONL化する
- Task Adherence、Coherence、Violenceを最初の評価器として設定する
- ツール連携がある場合は、Tool SelectionやTool Input Accuracyの追加を検討する
- Foundry Userロール、モデルデプロイ名、リージョン対応を確認する
- 評価結果の失敗行を読み、プロンプトやツール定義を修正する
- 同じデータセットで再評価し、改善したかを比較する
- リリース前評価をCI/CDに組み込み、運用後は継続評価へ広げる
Azure AI FoundryのAIエージェント評価は、単なる品質チェックではなく、エージェントを安全に運用するためのリリース管理です。管理者は権限・リージョン・監視基盤を整え、開発者は評価データと評価器を継続的に改善してください。これにより、AIエージェントや社内Copilotを「動くデモ」から「業務で使える本番システム」へ近づけられます。
コメント