Azure AI Foundryで生成AIモデルやエージェントを評価する場合、今後は「Microsoft Foundryポータルで評価を作成し、結果を確認する」流れを押さえておくことが重要です。結論から言うと、管理者はRBACロール名の変更、評価に使うAzure OpenAI接続、プレビュー機能の扱いを確認し、開発者は評価対象、テストデータ、評価指標、データマッピングをリリース前のチェック項目に組み込むべきです。
Microsoft Learnの「Run evaluations from the Microsoft Foundry portal」は、生成AIモデルやエージェントをテストデータに対して実行し、組み込み評価器やカスタム評価器で性能・安全性を測る手順を整理した公式ドキュメントです。公式ページ下部の更新日は「2026-05-15」と表示されており、本稿では2026年5月16日時点で確認すべき内容として、Azure AI Foundry利用者向けに変更点と実務上の注意点をまとめます。(Microsoft Learn)
Azure AI Foundry利用者がまず押さえるべき変更点
今回のポイントは、単に「評価機能がある」という説明ではありません。Azure AI FoundryからMicrosoft Foundryへ用語やポータル体験が整理される中で、評価の入口、対象、データ形式、RBAC、プレビュー機能の扱いを見直す必要があります。
Microsoft Foundryは、エージェント、モデル、ツール、トレース、監視、評価などを統合するAzure上のプラットフォームとして説明されています。従来のAzure AI Studio/Azure AI Foundryは、現在のMicrosoft Foundryというブランドに対応する形で整理されています。(Microsoft Learn)
| 確認ポイント | 何が変わる・何を確認するか | 実務上の影響 |
|---|---|---|
| ポータル名・体験 | Microsoft Foundryポータルで評価を作成・確認する | 旧ポータルやクラシック環境を使っているチームは画面遷移を再確認する |
| RBACロール | Foundry Userなどの名称へ変更 | 権限棚卸し時に旧称と新称を混同しない |
| 評価対象 | Agent、Model、Dataset、Tracesから選択 | モデル単体だけでなく、エージェントや既存トレースも評価対象にできる |
| データ形式 | CSV、JSONL、合成データ生成、マルチモーダルプレビューに対応 | テストデータ設計と列名の標準化が重要になる |
| 評価器 | Agent、Quality、Safety、Custom evaluatorsを選択 | 本番前の品質・安全性チェックを定量化しやすくなる |
| プレビュー機能 | preview表記の機能はSLAなし、本番推奨ではない | 画像・音声評価や一部評価器は検証環境で扱うべき |
公式ドキュメントでは、プレビュー表記のある機能はパブリックプレビューであり、SLAがなく、本番ワークロードでは推奨されないと明記されています。評価機能をリリース判定に使う場合でも、プレビュー機能だけに依存した合否判断は避けるべきです。(Microsoft Learn)
Microsoft Foundryポータルでの評価実行とは
Microsoft Foundryポータルの評価機能は、生成AIアプリケーションの出力をテストデータに対して実行し、品質や安全性をスコアとして確認するための仕組みです。評価は、モデルやエージェントを本番公開する前の検証、プロンプト変更後の回帰テスト、RAGの回答品質チェック、安全性レビューなどに使えます。
評価の作成は、ポータル左側の「Evaluation」だけでなく、Modelsページ、Agentsページ、Agent playgroundからも開始できます。Agent playgroundでは、Metricsからフル評価を実行する導線が用意されています。(Microsoft Learn)
評価対象はAgent、Model、Dataset、Tracesの4種類
評価を作成する際は、最初に評価対象を選びます。ここでの選択を間違えると、必要なテストデータや評価指標が変わるため、評価の目的から逆算することが大切です。
| 評価対象 | 使う場面 | 具体例 |
|---|---|---|
| Agent | エージェントの出力やツール利用を評価したい | 社内FAQエージェントが適切なツールを呼び出すか確認する |
| Model | モデル単体の応答品質を評価したい | モデル変更前後で回答の自然さや一貫性を比較する |
| Dataset | 既にある入出力データを評価したい | 過去の回答ログを使って品質スコアを確認する |
| Traces | Application Insightsに記録済みのやり取りを評価したい | 本番・検証環境のエージェント実行履歴から問題傾向を確認する |
公式情報では、Agentはprompt agentsとhosted agentsの両方に対応し、TracesはApplication Insightsに取得済みのエージェント対話を評価対象にできます。(Microsoft Learn)
管理者が確認すべき設定
管理者やプラットフォーム担当者が最初に確認すべきなのは、権限、接続、ポータル移行、コストの4点です。評価機能は開発者向けの画面に見えますが、実際にはモデルデプロイ、Azure OpenAI接続、Application Insights、RBAC、課金に関係します。
Foundry Userロールと旧ロール名の対応を確認する
評価を実行するには、Foundryプロジェクトに対するFoundry Userロールが必要です。公式ドキュメントでは、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などの旧称が運用手順書やIAM一覧に残っていないか |
| 最小権限 | 評価実行だけが目的のユーザーに過剰なOwner権限を付けていないか |
| 監査対応 | 誰が評価を作成し、どのモデルやエージェントを評価したか追跡できるか |
特に大規模組織では、名称変更そのものよりも「申請フロー・手順書・監査証跡の表記ずれ」が問題になりやすいです。Azureポータル、Microsoft Foundryポータル、社内台帳でロール名の対応表を作っておくと、問い合わせ対応が楽になります。
AI支援の品質評価にはAzure OpenAI接続が必要
AI-assisted quality evaluationsを使う場合は、チャット補完をサポートするGPTモデルがデプロイされたAzure OpenAI接続が必要です。一方、Safety evaluatorsは、利用者側で判定用モデルデプロイを用意しなくても使えると説明されています。(Microsoft Learn)
ここで注意したいのは、評価対象のモデルと、評価に使う判定用モデルを混同しないことです。たとえば、社内FAQボットの回答を評価する場合、FAQボット本体のモデルとは別に、品質評価用のAzure OpenAI接続が必要になるケースがあります。接続先、デプロイ名、リージョン、利用可能なモデルを事前に確認しておきましょう。
New Foundryトグルとクラシックポータルの扱いを確認する
Microsoft Foundryポータルでは、プロジェクト管理、モデルデプロイ、エージェント構築、AI資産の監視を行えます。公式の日本語ページでは、現在のバージョンを使うには「New Foundry」トグルがオンになっていることを確認するよう案内されています。(Microsoft Learn)
ハブベースのプロジェクトを使っている場合は、Foundryクラシックポータル側にアクセスする場面が残る可能性があります。新しい投資は新しいポータルのFoundryプロジェクトに重点が置かれると説明されているため、今後の運用設計では新ポータル前提で手順を整理するのが現実的です。(Microsoft Learn)
開発者が確認すべき評価データと評価器
開発者にとって最も重要なのは、「どの評価器を選ぶか」より先に、「何を良い回答とみなすか」を決めることです。評価データの設計が曖昧なままスコアだけを見ても、リリース判断には使えません。
CSVまたはJSONLでテストデータを用意する
評価には、CSVまたはJSON Lines（JSONL）形式のテストデータを使えます。データがない場合は合成データ生成も選択できますが、合成データ生成にはResponses API capabilityを持つモデルが必要です。(Microsoft Learn)
実務では、次のようにアプリの種類ごとにデータ列を分けると扱いやすくなります。
| アプリの種類 | 用意したい列の例 | 評価で見たいこと |
|---|---|---|
| チャットボット | question、response、ground_truth | 正答に近いか、自然に回答しているか |
| RAGアプリ | query、context、response、ground_truth | 検索された文脈に基づいて回答しているか |
| エージェント | user_input、tool_calls、response、expected_steps | 適切なツールを選び、手順通りに完了したか |
| 安全性評価 | prompt、response、risk_category | 有害・不適切・権利侵害の可能性がないか |
列名は自由に設計できますが、後述するデータマッピングで評価器が必要とするフィールドに割り当てる必要があります。チームで列名を標準化しておくと、評価の再実行やSDK連携がしやすくなります。
マルチモーダル評価はプレビューとして扱う
公式ドキュメントでは、Agent、Model、Dataset、Tracesの全評価対象で画像と音声コンテンツをサポートすると説明されています。ただし、このマルチモーダルコンテンツはプレビュー扱いです。画像はimage_urlとcaption、音声はaudio_dataとexpectedを使うスキーマが示されており、音声形式は現時点でWAVのみとされています。(Microsoft Learn)
画像や音声を含むエージェントを評価する場合は、まず検証環境でデータ形式、再生確認、結果画面でのプレビューを確認してください。本番の合否判定に使うなら、テキスト評価や人手レビューと組み合わせるのが安全です。
評価器は目的別に組み合わせる
Microsoft Foundryの組み込み評価器は、品質、安全性、信頼性を開発ライフサイクル全体で評価するためのものです。一般的な品質評価、RAG評価、リスク・安全性評価、エージェント評価、Azure OpenAI graders、カスタム評価器などが用意されています。(Microsoft Learn)
| 目的 | 使いたい評価器の例 | 判断のポイント |
|---|---|---|
| 文章品質を見たい | Coherence、Fluency | 読みやすさや論理の流れを確認する |
| 正解データとの近さを見たい | Similarity、F1、BLEU、ROUGE、METEOR | ground truthがあるテストに向く |
| RAGの品質を見たい | Retrieval、Groundedness、Relevance | 検索結果に基づいた回答かを見る |
| 安全性を見たい | Hate and Unfairness、Sexual、Violence、Self-Harm、Protected Materials | 有害性や権利侵害リスクを見る |
| エージェントを見たい | Tool Call Accuracy、Tool Selection、Task Completion、Intent Resolution | ツール選択やタスク完了を確認する |
| 独自基準で見たい | Custom evaluators | 社内ルールや業務固有の合格基準を反映する |
公式ドキュメントでも、RAGアプリではRetrieval、Groundedness、Relevance、Content Safety、エージェントアプリではTool Call Accuracy、Task Adherence、Intent Resolution、Content Safetyのように、複数の評価器を組み合わせる例が示されています。(Microsoft Learn)
データマッピングで失敗しやすいポイント
評価作成時には、評価器が必要とする入力フィールドに対して、データセットの列を割り当てます。ポータルは自動マッピングを行いますが、割り当てられない項目はUnassignedと表示されます。必須フィールドが未割り当てのままだと評価器は失敗します。(Microsoft Learn)
失敗を防ぐには、評価前に次の3点を確認してください。
| よくある失敗 | 原因 | 対策 |
|---|---|---|
| 評価が失敗する | 必須フィールドがUnassignedのまま | Submit前に必須項目の割り当てを確認する |
| スコアが期待と合わない | responseとground_truthの列を逆に割り当てている | 小さなデータセットで試験実行する |
| RAG評価が不安定 | context列に検索結果ではなく質問文を入れている | query、context、responseを明確に分ける |
| エージェント評価が浅い | ツール呼び出しや手順情報が不足している | tool callや期待手順をログ・データに残す |
| 日本語評価で解釈がずれる | 判定基準が曖昧、または英語前提の評価に頼っている | 日本語の正解例、禁止例、レビュー観点を追加する |
評価データは「大量に作る」よりも、まず失敗パターンを含む小さなセットを作る方が有効です。たとえば、通常質問、曖昧な質問、権限外の質問、誤った前提を含む質問、プロンプトインジェクション風の質問を各10件ずつ用意すると、初回評価で問題の傾向が見えやすくなります。
評価結果の見方とリリース判断への使い方
評価結果は、FoundryポータルのEvaluationから評価実行を開いて確認できます。結果画面では、評価名、対象、データセット、ステータス、評価器が消費したトークン、評価対象のモデルやエージェントが消費したトークン、各評価器の集計スコアを確認できます。(Microsoft Learn)
さらに、行単位の詳細では、クエリ、レスポンス、ground truth、評価器スコア、スコア説明を確認できます。複数の評価実行を比較する場合はCompareを使い、統計的t検定を含む比較結果を見られます。(Microsoft Learn)
リリース判断では、平均スコアだけを見るのは危険です。次のように、集計値と個別失敗例をセットで確認してください。
| 見るべき項目 | 判断基準の例 |
|---|---|
| 集計スコア | 前回リリース候補より主要指標が下がっていないか |
| 失敗サンプル | 失敗が軽微な表現差か、業務上の重大ミスか |
| 安全性スコア | 有害回答や権限外回答が増えていないか |
| トークン使用量 | 品質改善のためにコストが過度に増えていないか |
| 比較結果 | 改善・劣化が統計的に意味のある差か |
| 説明文 | なぜ低スコアになったかを人間が確認できるか |
特にプロンプト変更やモデル変更では、1回の評価だけで判断せず、前回の安定版をベースラインとして比較する運用が有効です。スコアが上がっていても、安全性やコストが悪化していればリリースを止める判断が必要です。
安全性評価は人間のレビューと組み合わせる
Foundryの安全性評価は、ヘイト・不公平表現、性的コンテンツ、暴力、自傷、保護された素材、直接・間接的なジェイルブレイク脆弱性などのリスク評価に使えます。公式のTransparency Noteでは、Azureから直接販売されるモデルか非Microsoft製品かにかかわらず、顧客自身がリスクと安全性評価を行うべきだと説明されています。(Microsoft Learn)
ただし、安全性評価は万能ではありません。公式情報では、人間を含めたレビューを行うべきこと、手動のレッドチーミングを置き換えるものではないこと、現時点では英語領域のテキスト生成での利用が最適であることが示されています。日本語の生成AIアプリで使う場合は、Foundryの自動評価に加えて、日本語の業務文脈を理解したレビュー担当者による確認を必ず組み合わせてください。(Microsoft Learn)
また、安全性評価の結果は、最終判断を自動化するものではありません。公式情報でも、評価結果は本番展開前に人間の意思決定者が確認すべきものと説明されています。(Microsoft Learn)
SDK・CI/CDへの展開を見据えた運用設計
ポータルでの評価は、最初の導入や結果確認に向いています。一方で、継続的にモデルやプロンプトを改善するチームでは、SDKやクラウド評価を使った自動化も検討すべきです。
Microsoft Foundryのクラウド評価は、スケールしたテスト、CI/CDへの統合、デプロイ前テストに向くと説明されています。結果はFoundryプロジェクトに保存され、ポータルで確認したり、SDKで取得したり、Application Insightsへ連携したりできます。(Microsoft Learn)
おすすめの進め方は、次の順序です。
| 段階 | やること | 目的 |
|---|---|---|
| 初期検証 | ポータルで小さな評価データを使って手動実行 | 評価対象、列マッピング、評価器の妥当性を確認する |
| 基準作成 | 安定版モデル・プロンプトでベースラインを作る | 以後の比較基準を固定する |
| 改善検証 | 新しいモデル、プロンプト、RAG設定を評価する | 品質・安全性・コストの変化を見る |
| リリース判定 | Compareと失敗サンプルを確認する | 数値と人間レビューの両方で判断する |
| 自動化 | SDKやクラウド評価をCI/CDに組み込む | 回帰テストを継続運用する |
| 本番監視 | Application Insightsや継続評価を検討する | リリース後の劣化やリスクを検出する |
最初から自動化に飛びつくより、ポータルで「どの評価がリリース判断に効くか」を見極めてからSDK化する方が失敗しにくいです。評価器を増やしすぎると、コストや確認工数が増え、どの指標を優先すべきか分からなくなります。まずは品質、安全性、業務固有基準の3本柱で始めるのがおすすめです。
移行・展開時のチェックリスト
Azure AI Foundry環境でMicrosoft Foundryポータルの評価機能を使う前に、次の項目を確認してください。
| 分類 | チェック項目 |
|---|---|
| ポータル | New Foundryトグルがオンになっているか |
| プロジェクト | 評価対象のモデル・エージェントが正しいプロジェクトにあるか |
| 権限 | 評価実行者にFoundry User相当の権限があるか |
| 接続 | AI支援品質評価に使うAzure OpenAI接続とモデルデプロイがあるか |
| データ | CSVまたはJSONLの列構成が評価器に合っているか |
| マッピング | 必須フィールドがUnassignedになっていないか |
| 評価器 | 品質、安全性、エージェント固有、RAG固有のどれを使うか決めているか |
| プレビュー | preview機能を本番判定の唯一の根拠にしていないか |
| 結果確認 | 集計スコアだけでなく行単位の失敗例を確認しているか |
| コスト | 評価トークンと対象トークンの増加を確認しているか |
| 監査 | 評価結果を関係者や監査担当に共有できる状態か |
| 日本語対応 | 日本語の正解例、禁止例、人手レビュー基準を用意しているか |
このチェックリストをリリース手順書に組み込むと、プロンプト変更やモデル差し替えのたびに品質確認が属人化するのを防げます。
Azure AI Foundryの評価機能を実務で活かす次の行動
Azure AI Foundry、現在のMicrosoft Foundry環境で評価機能を使うなら、まずは既存の生成AIアプリを1つ選び、20〜50件程度のテストデータでポータル評価を実行するところから始めるのが現実的です。最初の目的は完璧なスコアを出すことではなく、評価対象、データ形式、評価器、失敗例の見え方をチームで理解することです。
そのうえで、ベースライン評価を作成し、プロンプト変更やモデル変更のたびに比較できる状態を整えましょう。管理者はRBAC、接続、ポータル移行、コストを確認し、開発者はデータマッピング、評価器選定、失敗サンプルの分析を担当します。安全性評価については、自動評価だけで判断せず、日本語の業務文脈に詳しい人間のレビューを組み合わせることが重要です。
Microsoft Foundryポータルの評価機能は、生成AIアプリを「動いたから公開する」状態から、「品質・安全性・コストを確認して公開する」状態へ引き上げるための仕組みです。まずは小さく評価を回し、リリース判定と継続改善のプロセスに組み込んでください。
コメント