Azure AIの公式ドキュメント更新「Eval dockit test 7」を見たときに、まず確認すべきなのは「新機能が追加されたか」ではなく、生成AIアプリやAIエージェントの評価運用に影響する前提条件・権限・データマッピング・結果確認手順が変わっていないかです。今回の更新は、Microsoft Foundry関連の評価ドキュメントに対する修正で、開発者、クラウド管理者、ソリューションアーキテクトが評価パイプラインや運用手順を見直すきっかけになります。
特に注意したいのは、評価に必要なロール、AI-assisted quality evaluationsで使うモデル例、マルチモーダル評価での音声形式、評価結果画面で確認できるトークン情報、AIエージェント評価時のinitialization_parametersの指定です。すでにAzure AI／Microsoft Foundryで評価機能を運用している場合は、ドキュメント差分をそのまま読むだけでなく、自社の手順書、CI/CD、権限設計、評価データセットに反映すべきかを確認しましょう。
今回の更新は「評価まわりの運用確認」が中心
「Eval dockit test 7」は、MicrosoftDocsのazure-ai-docsリポジトリに含まれる公式ドキュメント更新のコミット件名です。該当コミットでは4ファイルが変更され、45行の追加と31行の削除が行われています。対象は主にMicrosoft Foundryの評価機能に関するドキュメントで、クラウド評価、生成AIアプリ評価、評価結果の確認、AIエージェント評価が含まれます。(GitHub)
コミット日時は米国太平洋時間で2026年4月29日19:15:12です。日本時間では2026年4月30日に相当するため、日本語圏の運用担当者が「2026-04-30のAzure AI公式ドキュメント更新」として確認する文脈に合います。(GitHub)
ここで重要なのは、コミット名だけを見て「Eval dockit test 7」という新しい製品機能が追加されたと判断しないことです。今回の差分は、評価機能そのものの大規模リリースというより、既存の評価手順をより正確に運用できるようにするためのドキュメント修正と見るのが自然です。
変更対象のドキュメントと確認ポイント
今回の更新で確認すべき対象は、評価の作成、実行、結果確認、エージェント評価にまたがっています。実務では、どのページが自社の運用フローに関係するかを先に切り分けると効率的です。
| 対象ドキュメント | 主な変更の方向性 | 影響を受けやすい担当者 |
|---|---|---|
cloud-evaluation.md | クラウド評価の関連リンクや記述の整理 | 開発者、MLOps担当者 |
evaluate-generative-ai-app.md | 評価作成時の前提条件、データマッピング、マルチモーダル評価の説明を明確化 | 開発者、評価設計担当者 |
evaluate-results.md | 評価結果画面で確認する項目や手順を具体化 | 運用担当者、クラウド管理者、意思決定者 |
evaluate-agent.md | AIエージェント評価の前提条件とjudge model指定を明確化 | エージェント開発者、アーキテクト |
評価機能は、単にスコアを出すための機能ではありません。モデル変更、プロンプト変更、RAG構成変更、エージェントのツール利用変更が本番品質に影響していないかを判断するための運用基盤です。そのため、公式ドキュメントの小さな表現変更でも、手順書や自動化スクリプトの前提に影響する場合があります。
Azure AI Userロールの確認を後回しにしない
今回の差分で特に実務影響が出やすいのが、Azure AI Userロールに関する記述です。生成AIアプリ評価の前提条件に、Foundryプロジェクト上のAzure AI Userロールが追加されています。また、評価結果を見るための前提条件にもAzure AI Userロールと完了済みの評価実行が明記されています。(GitHub)
これは、評価を作成できる人、結果を確認できる人、評価データをダウンロードできる人を整理するうえで重要です。特にエンタープライズ環境では、開発者、クラウド管理者、セキュリティ担当、業務部門の閲覧者が同じ権限を持つとは限りません。
実務で確認すべきこと
| 確認項目 | 見落とした場合のリスク | 対応の目安 |
|---|---|---|
| FoundryプロジェクトでAzure AI Userロールが付与されているか | 評価作成や結果確認ができず、検証が止まる | 評価担当者と閲覧担当者のロールを棚卸しする |
| 評価結果を誰が見られるか | 評価データや出力内容の取り扱いが曖昧になる | 最小権限の原則でアクセス範囲を決める |
| 本番前レビュー担当者に閲覧権限があるか | リリース判定時にスコアを確認できない | リリースゲートの担当者を権限設計に含める |
| 外部委託先や一時参加者の権限 | 不要なデータ閲覧につながる | 期限付きアクセスや定期レビューを設定する |
評価結果には、クエリ、レスポンス、ground truth、スコア説明などが含まれる場合があります。個人情報、顧客情報、社内ナレッジが評価データに含まれる可能性があるなら、評価機能の権限は「開発環境だから緩くてよい」と考えない方が安全です。
AI-assisted quality evaluationsのモデル例変更は「自社環境で使えるか」を確認する
生成AIアプリ評価の前提条件では、AI-assisted quality evaluationsに必要なAzure OpenAI接続について、チャット補完をサポートするデプロイ済みGPTモデルの例がgpt-4o-miniからgpt-5-miniに変更されています。(GitHub)
ここで注意したいのは、ドキュメント上の例示モデルが変わったからといって、すべての環境で同じモデルをすぐ使えるとは限らない点です。Azure OpenAIやMicrosoft Foundryのモデル提供状況は、リージョン、サブスクリプション、承認状況、組織ポリシーによって変わる可能性があります。
判断基準
すでに評価用のjudge modelを固定している場合は、次の順に確認すると実務上の手戻りを減らせます。
| 確認順 | 確認内容 | 判断のポイント |
|---|---|---|
| 1 | 現在の評価で使っているモデル名 | ドキュメント例と違っても、評価が正常に動き、基準が一貫していれば即変更は不要 |
| 2 | 利用リージョンでの提供状況 | 新しい例示モデルが自社リージョンで使えるか確認する |
| 3 | 評価スコアの継続性 | judge modelを変えると過去スコアとの比較がずれる可能性がある |
| 4 | コストとレイテンシ | 高精度化だけでなく、評価実行時間と費用も見る |
| 5 | 本番判定ルール | モデル変更後に合格ラインを再調整すべきか検討する |
評価用モデルを変更する場合は、既存の評価データセットで旧モデルと新モデルを並行実行し、スコア差分を見てから切り替えるのが安全です。特に、品質評価をリリース判定に使っている場合、judge modelの変更は評価基準そのものの変更に近い意味を持ちます。
マルチモーダル評価では音声形式に注意する
生成AIアプリ評価のドキュメントでは、マルチモーダルコンテンツの見出しが整理され、音声コンテンツについて「現在サポートされる音声形式はWAVのみ」という注記が追加されています。対象は、Agent、Model、Dataset、Tracesの評価ターゲットで、画像や音声コンテンツをJSONLスキーマで扱う説明です。(GitHub)
音声を含む評価データセットを作る場合、ここは実務上かなり重要です。MP3、M4A、AACなどの形式をそのまま評価データに入れると、評価が失敗したり、想定通りに処理されなかったりする可能性があります。
音声評価データを用意するときのチェックリスト
| 項目 | 推奨対応 |
|---|---|
| 音声形式 | WAVに統一する |
| データURI | data:audio/wav;base64,...の形式を守る |
| expected | 音声に対して期待される内容をテキストで明確に書く |
| ファイル変換 | 変換後に音質、サンプリングレート、無音区間を確認する |
| 評価対象 | 音声そのものを評価するのか、音声から得た応答を評価するのかを分ける |
たとえば、コールセンター向けAIエージェントの評価では、音声ファイルを入力として扱うケースがあります。この場合、音声形式の不備で評価が失敗すると、モデル品質ではなくデータ準備の問題で検証が止まります。評価前に小さなサンプルで形式チェックを通す工程を入れておくと、後続の大規模評価での失敗を減らせます。
データマッピングの「Unassigned」は評価失敗の原因になる
今回の更新では、評価ポータルがデータセットのフィールドを各Evaluatorが期待するフィールドへ自動マッピングする一方、自動マッピングできないフィールドはUnassignedとして表示されること、必須フィールドにはアスタリスクが付くこと、必須フィールドが未割り当てのままだとEvaluatorが失敗することが明確化されています。(GitHub)
これは、Azure AIの評価運用でよく起きる失敗を防ぐための重要な情報です。評価データセットの列名がquestion、answer、context、ground_truthのようにチームごとに異なると、自動マッピングが期待通りに動かないことがあります。
よくある失敗例
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 評価実行後に一部メトリックが出ない | 必須フィールドが未割り当て | Submit前にUnassignedを確認する |
| Groundednessが極端に低い | context列が正しく割り当てられていない | RAGの検索結果列とEvaluatorの要求フィールドを対応させる |
| Relevanceの結果が不自然 | queryとresponseの対応がずれている | JSONLやCSVの列順・列名・値を確認する |
| Safety系の評価が期待通りに動かない | 対象Evaluatorが必要とする入力を満たしていない | Built-in evaluatorsの要求フィールドを確認する |
| 評価が失敗する | 必須項目を空欄のまま実行した | 小規模データで事前実行する |
評価データセットは、モデルに入力するための単なるテストデータではありません。Evaluatorが正しく判断するための材料です。列名、値の型、空欄、ground truthの粒度が不十分だと、評価結果の信頼性が下がります。
評価結果画面ではトークン情報と行単位の結果を見る
評価結果の確認手順も具体化されています。Foundryポータルでプロジェクトを開き、左ペインからEvaluationを選択し、評価実行を選ぶ流れが記載されています。評価実行が進行中の場合はRunningと表示され、完了時に更新されることも説明されています。(GitHub)
評価結果の詳細画面では、Name、Target、Dataset、Status、Evaluation tokens、Target tokens、Scoresなどの項目が示されます。さらに、スコアセルにホバーするとトークン使用量の詳細や追加コンテキストを確認でき、評価実行名を選ぶと行単位の結果としてquery、response、ground truth、Evaluator score、score explanationを確認できます。(GitHub)
結果確認で見るべき項目
| 項目 | 見る理由 | 実務での使い方 |
|---|---|---|
| Status | 評価が完了したか、失敗したかを判断する | Failedならデータマッピングや権限を確認する |
| Evaluation tokens | Evaluator側で消費したトークンを把握する | 評価コストの見積もりに使う |
| Target tokens | 評価対象のモデルやエージェントが消費したトークンを把握する | プロンプトやコンテキスト量の改善に使う |
| Scores | 品質、安全性、関連性などの集計結果を見る | リリース可否の判断材料にする |
| Row-level results | 個別の失敗例を確認する | プロンプト、RAG、ツール呼び出しの改善に使う |
| Score explanation | なぜそのスコアになったかを理解する | 関係者への説明や改善方針の整理に使う |
スコアの平均だけを見ると、失敗の原因を見誤ることがあります。たとえば平均スコアが合格ラインを超えていても、特定カテゴリの問い合わせだけでGroundednessが低い場合、検索インデックスやプロンプトの条件分岐に問題があるかもしれません。評価結果は、集計値と行単位の両方を見るのが基本です。
AIエージェント評価ではPythonバージョンとjudge model指定を確認する
AIエージェント評価のドキュメントでは、前提条件としてPython 3.8以降が追加されています。また、Task AdherenceやCoherenceのようなAI-assisted evaluatorsでは、initialization_parametersにモデルデプロイ名が必要であり、その値はプロジェクト内のGPTデプロイ名と一致していなければならないことが明確化されています。これは、応答を採点するjudge modelとして使われるモデルです。(GitHub)
この変更は、SDKを使って評価を自動化しているチームにとって重要です。モデル名とデプロイ名を混同すると、評価が失敗したり、想定と違うモデルで評価されたりする可能性があります。
モデル名とデプロイ名を混同しない
Azure OpenAIやMicrosoft Foundryでは、モデルそのものの名称と、自社環境で作成したデプロイ名が一致しているとは限りません。たとえば、モデルはgpt-4o-miniでも、デプロイ名をjudge-prod-miniのようにしている場合があります。このときinitialization_parametersにモデル名を入れるのではなく、ドキュメントの説明どおり、プロジェクト内のGPTデプロイ名と一致する値を指定する必要があります。
| 用語 | 意味 | 例 |
|---|---|---|
| モデル名 | Microsoftが提供するモデルの種類 | gpt-4o-miniなど |
| デプロイ名 | 自社プロジェクト内で作成したデプロイの名前 | judge-prod-mini、eval-quality-01など |
| judge model | 応答を採点するために使う評価用モデル | Task AdherenceやCoherenceの採点に使う |
CI/CDでAIエージェント評価を実行している場合は、環境変数や設定ファイルに入っているデプロイ名を確認しましょう。開発環境、検証環境、本番環境でデプロイ名が異なる場合、同じコードでも評価結果や実行可否が変わることがあります。
継続評価のリンク変更は運用設計の見直しポイント
クラウド評価の関連コンテンツでは、継続評価に関するリンクが、従来の「Evaluate your AI agents continuously」から「Set up continuous evaluation」に変更されています。(GitHub)
リンク変更だけを見ると小さな修正に見えますが、運用設計では意味があります。継続評価は、モデルやエージェントを一度評価して終わりにするのではなく、リリース前後や定期実行で品質・安全性を監視する考え方です。
継続評価を入れるべきタイミング
| タイミング | 評価すべき内容 |
|---|---|
| プロンプトを変更したとき | 応答品質、トーン、禁止事項の順守 |
| RAGの検索対象を更新したとき | Groundedness、回答の根拠、検索漏れ |
| モデルを変更したとき | 過去評価とのスコア差分、コスト、レイテンシ |
| エージェントのツールを追加したとき | Task Adherence、ツール呼び出しの妥当性、安全性 |
| 本番リリース前 | 合格ラインを満たすか、重大な失敗例がないか |
| 本番運用中 | 品質劣化、利用傾向の変化、異常な失敗パターン |
特にAIエージェントは、単純なチャットボットよりも失敗の種類が増えます。ツール呼び出し、外部API連携、メモリ、検索、権限などが絡むため、評価を一回きりの検証ではなく、変更管理の一部として扱うことが重要です。
開発者・管理者・意思決定者別の確認ポイント
今回のAzure AI公式ドキュメント更新は、読む人によって注目すべき点が変わります。全員が同じ差分を同じ深さで読むより、役割別に確認範囲を決めた方が早く実務に反映できます。
| 役割 | 優先して確認すること | 次に取るべき行動 |
|---|---|---|
| 開発者 | データマッピング、音声形式、initialization_parametersのデプロイ名 | 評価スクリプトとサンプルデータを見直す |
| クラウド管理者 | Azure AI Userロール、評価結果の閲覧権限 | FoundryプロジェクトのRBACを棚卸しする |
| ソリューションアーキテクト | 継続評価、judge model、評価基準の一貫性 | リリース判定フローに評価結果を組み込む |
| 技術意思決定者 | 評価コスト、トークン使用量、品質指標 | 評価を運用KPIやリスク管理に接続する |
意思決定者にとっては、個別の設定値よりも「評価結果をどう使ってリリース判断をするか」が重要です。たとえば、Task Adherenceが一定値を下回ったら本番反映を止める、Safety評価で重大な失敗が出たら再設計する、といった判断基準を事前に決めておく必要があります。
既存環境で行うべき点検手順
すでにAzure AIやMicrosoft Foundryで評価を使っている場合は、次の順序で確認すると効率的です。
| 手順 | 作業 | 完了基準 |
|---|---|---|
| 1 | 評価対象ドキュメントの差分を確認する | 自社運用に関係する変更点を一覧化する |
| 2 | Foundryプロジェクトのロールを確認する | 評価作成者・閲覧者に必要な権限がある |
| 3 | 評価用モデルとデプロイ名を確認する | judge modelの指定がプロジェクト内のデプロイ名と一致している |
| 4 | 評価データセットの列を確認する | 必須フィールドがUnassignedにならない |
| 5 | マルチモーダル入力を確認する | 音声データを使う場合はWAV形式になっている |
| 6 | 小規模データで評価を再実行する | Status、Scores、token情報、行単位結果を確認できる |
| 7 | 手順書とCI/CD設定を更新する | 属人化せず、再現可能な評価フローになっている |
大切なのは、いきなり本番相当の大きなデータセットで評価を回さないことです。まず10件から50件程度の代表データで、権限、マッピング、モデル指定、結果表示が問題なく動くかを確認しましょう。その後、評価件数を増やしてスコアの傾向やコストを見ます。
移行準備で失敗しやすいポイント
今回の更新をきっかけに評価運用を見直す場合、次のような失敗に注意してください。
| 失敗しやすいポイント | なぜ問題になるか | 回避策 |
|---|---|---|
| ドキュメント例のモデル名をそのまま本番に入れる | 自社環境のデプロイ名と一致しない可能性がある | モデル名ではなくデプロイ名を確認する |
| 評価スコアだけで判断する | 個別の重大失敗を見落とす | Row-level resultsとscore explanationを見る |
Unassignedを見落とす | 必須フィールド不足でEvaluatorが失敗する | Submit前にマッピングを確認する |
| 音声形式を変換せずに使う | WAV以外では評価できない可能性がある | 評価前に形式変換と検証を行う |
| 権限を広く付けすぎる | 評価データや出力内容が不要な人に見える | Azure AI Userロールの付与対象を整理する |
| judge modelを途中で変えて履歴比較する | 過去スコアとの連続性が崩れる | 切り替え前後で並行評価する |
評価は、AIシステムの品質を保証するための仕組みですが、評価設定そのものが曖昧だと誤った判断につながります。特にjudge model、評価データ、Evaluator、合格ラインの4つはセットで管理する必要があります。
この記事の結論
2026年4月30日相当のAzure AI公式ドキュメント更新「Eval dockit test 7」は、派手な新機能追加というより、Microsoft Foundryの評価運用をより正確に行うためのドキュメント修正です。確認すべき中心は、Azure AI Userロール、AI-assisted evaluationsで使うモデル例、WAV音声形式、データマッピングのUnassigned、評価結果画面のトークン情報、AIエージェント評価でのデプロイ名指定です。
次に取るべき行動は明確です。自社の評価手順書、SDKコード、CI/CD設定、RBAC、評価データセットを見直し、公式ドキュメントの新しい前提とずれていないか確認してください。特に本番リリース判定に評価結果を使っている場合は、小規模な再評価を実行し、スコア、行単位結果、トークン使用量、失敗パターンを確認してから運用に反映するのが安全です。
コメント