Azure AI Foundryの「Cloud Evaluation with the Microsoft Foundry SDK」は、生成AIアプリケーションの評価をローカル実行や手動確認に閉じず、クラウド上でスケール実行し、CI/CDやデプロイ前テストに組み込むための仕組みです。結論から言うと、管理者はRBAC・リージョン・モデル容量・Application Insights連携を、開発者は評価データのスキーマ、data_mapping、評価しきい値、非同期実行の扱いを確認する必要があります。公式ドキュメントでは、このクラウド評価はプレビューとして扱われ、スケールテスト、CI/CD統合、デプロイ前評価に向くと説明されています。(Microsoft Learn)
なお、日付については注意が必要です。Microsoft Learnの該当ページは、2026年5月18日時点で「Last updated on 2026-05-07」と表示されています。一方、関連するクラウド版AI Red Teamingページは2026年5月15日更新です。2026年5月16日公開・更新情報として社内展開する場合でも、実際の確認対象はこの5月上旬〜中旬に更新された公式ドキュメント群として扱うのが安全です。(Microsoft Learn)
Azure AI FoundryのCloud Evaluationは何が変わるのか
Azure AI FoundryのCloud Evaluationで大きく変わるのは、生成AIアプリの評価を「開発者の手元で一度だけ実行するテスト」から、「Foundryプロジェクト上で管理・再実行・自動化できる評価プロセス」に移せる点です。
公式ドキュメントでは、評価定義にデータスキーマとテスト条件、つまりエバリュエーターを指定し、その後に評価実行を作成する流れが示されています。実行結果はスコア付きで返され、完了状態をポーリングできます。結果はFoundryプロジェクトに保存され、ポータル、SDK、接続済みのApplication Insightsから確認できます。(Microsoft Learn)
実務上の変更点は、次の3つです。
| 変更点 | これまで起きがちな課題 | Cloud Evaluationでの整理 |
|---|---|---|
| 評価の実行場所 | ローカル環境や個別スクリプトに依存し、再現性が低い | Foundryプロジェクト上で評価実行を管理 |
| 評価対象 | モデル出力、エージェント出力、ログが別々に扱われやすい | データセット、モデル、エージェント、レスポンスID、トレースをシナリオ別に評価 |
| 運用への組み込み | リリース前の目視確認に偏りやすい | CI/CD、スケジュール評価、継続評価に接続しやすい |
ただし、「すべての既存評価を直ちに置き換える必須移行」と見るべきではありません。小規模なプロンプト検証やPoCではローカル評価やポータル評価が向く場合もあります。Cloud Evaluationは、評価件数が増える、複数人で評価結果を共有したい、リリース判定に使いたい、運用ログから品質を追いたい、といった段階で効果が出ます。
対象者と確認すべきポイント
Cloud Evaluationは、AIアプリ開発者だけでなく、Azure管理者、DevOps担当、セキュリティ担当にも影響します。特に、評価の実行がクラウド側に移ることで、権限、リージョン、クォータ、ログ連携の確認が重要になります。
| 対象者 | 確認すべきこと | 実務での判断基準 |
|---|---|---|
| Azure管理者 | Foundryプロジェクト、RBAC、リージョン、モデルデプロイ | 評価用のサービスプリンシパルやユーザーに必要最小限の権限を付与できているか |
| AIアプリ開発者 | 評価データ、エバリュエーター、data_mapping、しきい値 | 評価したい品質指標が、入力データの列やJSONフィールドと正しく対応しているか |
| DevOps担当 | CI/CDへの組み込み、非同期実行、失敗条件 | 評価完了まで待機し、pass_rateや安全性スコアでデプロイ可否を判定できるか |
| SRE・運用担当 | Application Insights、トレース、継続評価 | 本番トラフィックから評価対象をサンプリングし、劣化を検知できるか |
| セキュリティ担当 | 安全性評価、Red Teaming、データ取り扱い | 有害出力、機密情報漏えい、禁止操作などをリリース前に検査できるか |
Microsoftのドキュメントでは、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project ManagerというRBAC名への変更も説明されています。旧称のAzure AI Userなどが一部画面に残る可能性はありますが、ロールIDと主要な権限は変わらないとされています。(Microsoft Learn)
対応する評価シナリオ
Cloud Evaluationは、単に「CSVを読み込んでスコアを出す機能」ではありません。モデル、エージェント、既存レスポンス、本番トレース、合成データ、Red Teamingまで、複数の評価シナリオが整理されています。公式ドキュメントでは、以下のシナリオとデータソース種別が示されています。(Microsoft Learn)
| シナリオ | 使う場面 | データソース種別 | 主な注意点 |
|---|---|---|---|
| Dataset evaluation | すでに生成済みの回答をJSONLで評価する | jsonl | query、response、ground_truthなどのフィールド名を固定する |
| CSV dataset evaluation | 表形式データを使って評価する | csv | Excel由来のCSVでは列名、改行、文字コードに注意する |
| Model target evaluation | クエリをモデルに送信し、その場で回答を生成して評価する | azure_ai_target_completions | モデル呼び出し分のクォータとコストを考慮する |
| Agent target evaluation | Foundryエージェントの応答を評価する | azure_ai_target_completions | ツール呼び出しを評価する場合は構造化出力も確認する |
| Agent response evaluation | 既存のレスポンスIDを指定して評価する | azure_ai_responses | 評価対象レスポンスのID収集フローを用意する |
| Trace evaluation | Application Insightsに記録済みのやり取りを評価する | azure_ai_traces | OpenTelemetry属性とLog Analytics権限が重要 |
| Synthetic data evaluation | テストデータが不足している場合に合成クエリを生成して評価する | azure_ai_synthetic_data_gen_preview | プレビュー機能として扱い、合成データを人間が確認する |
| Red team evaluation | 敵対的テストで安全性やセキュリティリスクを探す | azure_ai_red_team | 攻撃戦略、リスクカテゴリ、対象エージェントを明確にする |
選び方の目安はシンプルです。すでに回答ログがあるならDataset evaluation、モデルやエージェントの最新挙動を見たいならTarget evaluation、本番運用後の品質を追いたいならTrace evaluation、テストケースが足りないならSynthetic data evaluation、悪用耐性を見たいならRed Teamingを検討します。
導入前に確認すべき前提条件
Cloud Evaluationを試す前に、最低限の前提条件を確認します。公式ドキュメントでは、Foundryプロジェクト、チャット補完をサポートするGPTモデルのAzure OpenAIデプロイ、Foundryプロジェクト上のFoundry Userロール、必要に応じた独自ストレージアカウントが前提として挙げられています。また、一部の評価機能にはリージョン制限があります。(Microsoft Learn)
まず、SDKは次のようにインストールします。
pip install "azure-ai-projects>=2.0.0"環境変数としては、少なくともプロジェクトエンドポイントと評価用モデルのデプロイ名を用意します。
export AZURE_AI_PROJECT_ENDPOINT="https://<account_name>.services.ai.azure.com/api/projects/<project_name>"
export AZURE_AI_MODEL_DEPLOYMENT_NAME="<model_deployment_name>"開発端末から実行する場合はDefaultAzureCredentialを使うため、Azure CLIで認証しておきます。
az login管理者が特に確認すべきなのは、次の4点です。
| 確認項目 | 確認内容 | 見落とした場合の影響 |
|---|---|---|
| RBAC | 実行ユーザーまたはサービスプリンシパルにFoundry User相当の権限があるか | 401 Unauthorizedや403 Forbiddenで評価を作成できない |
| リージョン | Foundryプロジェクト、モデル、評価機能が対象リージョンで利用可能か | 評価機能や対象モデルが使えない |
| クォータ・容量 | 評価で呼び出すモデルのTPMや容量が十分か | 実行が長時間Runningのままになる、または429エラーが出る |
| データ保管 | 評価データ、出力、ログの保管先が社内ポリシーに合うか | 機密データや顧客データの取り扱いで問題になる |
Microsoft Foundryのリージョン対応は機能ごとに異なります。公式のリージョンページでも、すべてのモデルと機能の組み合わせを単一のリアルタイム表で示すものではなく、導入前に機能別ページ、クォータ、ポータル上の実利用可否を確認するよう案内されています。(Microsoft Learn)
開発者が押さえるべき実装の流れ
Cloud Evaluationの実装は、評価定義を作ってから評価実行を作る、という2段階で考えると理解しやすくなります。
| 手順 | 作業内容 | 実務上のポイント |
|---|---|---|
| 評価目的を決める | 正確性、関連性、安全性、ツール利用、タスク達成などを決める | 「何となく品質を見る」ではなく、リリース判定に使う指標を決める |
| 入力データを準備する | JSONL、CSV、インラインデータ、トレースなどを用意する | 本番に近い問い合わせ、失敗しやすいケース、禁止したい応答を含める |
| スキーマを定義する | data_source_configとitem_schemaを設定する | フィールド名の大小文字まで一致させる |
| エバリュエーターを選ぶ | builtin.coherence、builtin.violence、builtin.f1_scoreなどを選ぶ | 品質評価と安全性評価を分けて設計する |
| マッピングする | data_mappingでデータ項目と評価入力をつなぐ | モデル生成結果は{{sample.output_text}}、既存回答は{{item.response}}などを使い分ける |
| 評価を実行する | client.evals.create()後、client.evals.runs.create()を呼ぶ | 実行は非同期なので完了までポーリングする |
| 結果を判定する | label、score、threshold、pass_rateを見る | CI/CDでは合格率や安全性スコアで失敗条件を明文化する |
たとえば、JSONLで既存回答を評価する場合は、次のようなデータから始めると管理しやすくなります。
{"query":"返品期限を教えてください","response":"購入から30日以内であれば返品できます。","ground_truth":"返品期限は購入日から30日以内です。"}
{"query":"パスワードを忘れました","response":"ログイン画面のパスワード再設定から手続きできます。","ground_truth":"ログイン画面のパスワード再設定リンクから再発行できます。"}この場合、responseを評価対象、ground_truthを正解データとして使えます。一方、モデルやエージェントにその場で回答を生成させる場合は、生成された出力を{{sample.output_text}}で参照する点が異なります。公式ドキュメントでも、モデルターゲット評価では{{sample.output_text}}を使ってモデル出力をエバリュエーターに渡す例が示されています。(Microsoft Learn)
data_mappingのミスが最も起きやすい
Cloud Evaluationで失敗しやすいのは、エバリュエーターそのものよりも、データの列名やマッピングです。公式ドキュメントでも、JSONLファイルのフィールド名とdata_mappingのフィールド名を一致させる必要があると説明されています。たとえばデータ側がquestionなのに、マッピングで{{item.query}}を指定すると、意図した評価入力になりません。(Microsoft Learn)
特に注意したいパターンは次の通りです。
| 評価対象 | よくある誤り | 正しい考え方 |
|---|---|---|
| 事前生成済み回答 | モデル生成時と同じ{{sample.output_text}}を使ってしまう | データセット内の回答なので{{item.response}}を使う |
| モデルターゲット評価 | response列がないのに{{item.response}}を参照する | 実行時に生成されるため{{sample.output_text}}を参照する |
| エージェントのツール利用 | テキスト回答だけを評価する | ツール呼び出し評価では{{sample.output_items}}やツール関連フィールドを検討する |
| CSV評価 | Excel上の列名変更に気づかない | CI/CDで使うCSVは列名を固定し、差分管理する |
| 安全性評価 | 品質評価と同じしきい値で扱う | 安全性は合格率だけでなく、重大ケースを個別確認する |
評価データは、最初から大規模に作る必要はありません。まずは20〜50件程度の代表ケースで、正常系、境界値、禁止事項、曖昧な質問、業務上の重要質問を含める方が効果的です。その後、失敗例を追加して評価データセットを育てていきます。
エージェント評価ではプロトコルと出力形式に注意する
Foundryエージェントを評価する場合、単純なモデル評価よりも確認点が増えます。公式ドキュメントでは、Agent target evaluationはプロンプトエージェントとホスト型エージェントの両方に対応し、エージェントのプレーンテキスト応答には{{sample.output_text}}、ツール呼び出しを含む構造化出力には{{sample.output_items}}を使う説明があります。(Microsoft Learn)
特にホスト型エージェントでは、ResponsesプロトコルとInvocationsプロトコルの違いに注意が必要です。Invocationsプロトコルを使うホスト型エージェントでは、構造化テンプレートではなく、/invocationsのリクエスト本文に対応する自由形式のinput_messagesを渡す必要があります。両方のプロトコルをサポートする場合、サービス側はInvocationsプロトコルを既定で使うと説明されています。(Microsoft Learn)
開発者は、評価対象のエージェントについて次の点を確認してください。
- 評価対象のエージェント名とバージョンを固定する
- ツール呼び出しを評価する場合、テキスト応答だけでなく構造化出力を残す
- タスク達成、ツール呼び出し精度、安全性を別々の観点で評価する
- プロンプト変更、ツール変更、モデル変更ごとに同じ評価データで再評価する
エージェント評価の結果が悪い場合、すぐにモデルを変えるのではなく、まず「指示が曖昧なのか」「ツール選択を誤っているのか」「検索・RAGの入力が足りないのか」「安全性の拒否が過剰なのか」を分けて確認するのが実務では有効です。
Trace evaluationは本番運用後の品質確認に効く
Trace evaluationは、すでにApplication Insightsに記録されたエージェントのやり取りを評価するシナリオです。公式ドキュメントでは、Foundry Agent Service以外で作ったLangChainやカスタムフレームワークのエージェントでも、OpenTelemetryのGenAIセマンティック規約に沿ったスパンをApplication Insightsへ出力していれば、同じエバリュエーターで評価できると説明されています。(Microsoft Learn)
ただし、Trace evaluationは「ログがあれば何でも評価できる」わけではありません。gen_ai.operation.nameがinvoke_agentであること、gen_ai.input.messagesやgen_ai.output.messagesが記録されていること、ツール評価ではgen_ai.tool.definitionsやツール呼び出し情報が必要になる場合があります。入力・出力メッセージが空または欠落していると、品質評価のスコアがNoneになる可能性もあります。(Microsoft Learn)
管理者側では、Application InsightsをFoundryプロジェクトに接続し、プロジェクトのマネージドIDにApplication Insightsリソースと連携先Log AnalyticsワークスペースのLog Analytics Readerロールを付与する必要があります。(Microsoft Learn)
本番運用でTrace evaluationを使う場合は、次の流れが現実的です。
| フェーズ | 実施内容 |
|---|---|
| リリース直後 | 重要シナリオのトレースを手動で抽出して評価 |
| 安定運用 | エージェントIDや時間範囲で定期的にトレース評価 |
| 障害・苦情発生時 | 問題のあったoperation_Idを指定して重点評価 |
| 改善後 | 同じ条件で再評価し、品質指標と安全性指標の改善を確認 |
Synthetic data evaluationはテスト不足を補うが、過信しない
Synthetic data evaluationは、テストデータが不足している場合に合成クエリを生成し、そのクエリをモデルまたはエージェントに送信して応答を評価する仕組みです。公式ドキュメントでは、プロンプトや任意のシードデータをもとに合成クエリを生成し、生成されたクエリをFoundryプロジェクト内のデータセットとして再利用できると説明されています。(Microsoft Learn)
便利な一方で、合成データは業務上の正解そのものではありません。たとえばカスタマーサポート用エージェントで「返品に関する質問」を合成した場合でも、実際の返品規約、例外条件、国・地域ごとの違い、社内承認が必要なケースまでは自動で保証されません。
実務では、次のように使うのが安全です。
| 使い方 | 推奨度 | 理由 |
|---|---|---|
| 初期テストケースのたたき台にする | 高 | 評価データ作成の初速を上げられる |
| エッジケース探索に使う | 高 | 人間が思いつきにくい質問を補える |
| そのままリリース判定の唯一の根拠にする | 低 | 業務ルールや正解性の人手確認が必要 |
| 生成されたデータをレビュー後に固定データセット化する | 高 | CI/CDで再利用しやすい |
Synthetic data evaluationはプレビュー扱いのため、本番リリース判定に使う場合は、人間がレビューした固定データセットと組み合わせるべきです。
Red Teamingは高リスクなエージェントで必ず検討する
Cloud Evaluationの関連領域として、AI Red Teaming Agentのクラウド実行も重要です。公式ドキュメントでは、クラウドで実行することで、より大きな攻撃戦略とリスクカテゴリの組み合わせによるデプロイ前Red Teaming、スケジュールされた継続的Red Teaming、エージェント固有リスクの検査に対応できると説明されています。(Microsoft Learn)
Red Teamingで確認すべき観点は、通常の品質評価とは異なります。たとえば、次のような観点です。
| 観点 | 例 |
|---|---|
| 禁止操作 | エージェントが本来許可されていない操作を実行しないか |
| 機密情報漏えい | ユーザー情報、内部プロンプト、接続先情報を出力しないか |
| 間接プロンプトインジェクション | 外部コンテンツに含まれる悪意ある指示に従わないか |
| 多ターン攻撃 | 会話を重ねることで制約を回避されないか |
| ツール悪用 | APIや社内システム連携が不正な文脈で呼び出されないか |
公式例では、Prohibited Actions、Task Adherence、Sensitive Data Leakageなどの組み込みエバリュエーターや、Flip、Base64、IndirectJailbreakといった攻撃戦略を使ったRed Teaming実行が示されています。(Microsoft Learn)
顧客対応、社内データ検索、コード生成、外部API実行、購入・予約・申請などの操作を行うエージェントでは、通常評価だけでなくRed Teamingをリリース前チェックに含めるべきです。
CI/CDに組み込むときの実装方針
Cloud Evaluationの価値は、CI/CDに組み込んだときに大きくなります。公式ドキュメントでも、スケールテスト、CI/CDパイプラインへの評価統合、デプロイ前テストが主な利用シナリオとして説明されています。(Microsoft Learn)
CI/CDでは、次のように設計します。
| ステップ | 内容 | 判定例 |
|---|---|---|
| 変更を検知 | プロンプト、モデル、エージェント設定、RAG設定の変更をトリガーにする | mainブランチへのマージ前に実行 |
| 評価データを固定 | バージョン管理済みJSONLまたはCSVを使う | dataset_nameとdataset_versionを指定 |
| 評価を実行 | SDKから評価定義と評価実行を作成 | 非同期実行のためポーリングする |
| 結果を取得 | output_itemsや集計結果を取得 | report_urlを成果物として保存 |
| デプロイ判定 | 合格率、安全性、重大失敗件数で判定 | 例：安全性failが1件でもあれば停止 |
| 改善に戻す | 失敗ケースをデータセットに追加 | 同じ失敗を再発させない |
公式ドキュメントでは、評価結果の各項目としてlabel、score、threshold、reason、必要に応じたdetailsが返ると説明されています。また、集計結果ではテスト条件ごとのpass_rateを確認できます。(Microsoft Learn)
CI/CDで特に避けたいのは、平均点だけで合否を決めることです。生成AIアプリでは、平均スコアが高くても、1件の重大な安全性違反や機密情報漏えいがリリース停止理由になる場合があります。品質系は合格率、安全性系は重大度、業務系は必須シナリオの個別合格を組み合わせて判定しましょう。
トラブルシューティングで見るべきポイント
Cloud Evaluationで問題が起きた場合は、エラー種別ごとに原因を切り分けます。公式ドキュメントでは、長時間Running、認証エラー、データ形式エラー、レート制限、エージェント評価のツールエラーに対する確認項目が示されています。(Microsoft Learn)
| 症状 | 主な原因 | 対応 |
|---|---|---|
| 評価ジョブが長時間Runningのまま | Azure OpenAIモデルデプロイの容量不足 | 実行をキャンセルし、モデル容量を増やして再実行 |
401または403が出る | 認証設定、RBAC、エンドポイント指定の問題 | az login、Foundry User権限、プロジェクトURLを確認 |
| スキーマエラーが出る | JSONL形式不備、列名不一致、data_mappingミス | 1行1JSON、大小文字、item_schemaを確認 |
429 Too Many Requestsが出る | テナント、サブスクリプション、プロジェクト、モデル容量の制限 | retry-after確認、指数バックオフ、データ分割、TPM増強 |
| エージェント評価でツールエラー | 評価対象ツールが未対応 | 対応ツールを確認し、必要ならユーザー定義関数ツールとしてラップ |
開発初期は、いきなり大きなデータセットを流さず、数件のfile_contentまたは小さなJSONLで疎通確認するのが近道です。疎通確認後にデータ件数を増やすことで、スキーマ不備とクォータ問題を分けて発見できます。
管理者・開発者向けの最終チェックリスト
本番展開やCI/CD組み込み前に、以下を確認してください。
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| Foundryプロジェクトが作成済み | はい | |
| 評価用モデルデプロイが利用可能 | はい | はい |
| Foundry User相当の権限が付与済み | はい | |
azure-ai-projects>=2.0.0を使用 | はい | |
| 評価データのJSONLまたはCSVをバージョン管理 | はい | |
data_source_configとdata_mappingを確認 | はい | |
| モデル評価とエージェント評価の出力参照を使い分け | はい | |
| Application Insights連携とLog Analytics権限を確認 | はい | はい |
| リージョン、クォータ、TPMを確認 | はい | |
| CI/CDの合否条件を数値で定義 | はい | はい |
| プレビュー機能を本番SLA前提で扱っていない | はい | はい |
まず何から始めるべきか
最初にやるべきことは、既存の生成AIアプリやエージェントについて「リリース前に落としたい失敗」を10〜20件の評価データにすることです。たとえば、誤回答してはいけないFAQ、回答拒否すべき危険な質問、RAGで根拠が必要な質問、ツール呼び出しが必要な業務手続きなどです。
次に、小さなJSONLまたはCSVをFoundryプロジェクトにアップロードし、Cloud Evaluationで品質評価と安全性評価を1回実行します。その結果を見て、しきい値、データ項目、エバリュエーターを調整します。最後に、同じ評価をCI/CDへ組み込み、プロンプトやエージェント設定を変更するたびに再評価する流れを作ります。
Azure AI FoundryのCloud Evaluationは、生成AIアプリの品質管理を「リリース直前の感覚的な確認」から「継続的に測定できる開発プロセス」へ移すための機能です。管理者は権限・リージョン・容量・ログ連携を整え、開発者は評価データとマッピングを正確に設計することで、モデルやエージェントの変更を安全に展開しやすくなります。
コメント