Azure AI Foundryで生成AIアプリの品質を確認したい場合、Local Evaluation with the Azure AI Evaluation SDK (classic) は「ローカル環境で評価データを実行し、必要に応じてFoundryプロジェクトへ結果を記録する」ための手順です。結論から言うと、今回押さえるべきポイントは、単なるSDKの使い方ではなく、classicポータル向けの手順であること、JSONLデータと列マッピングが重要であること、AI支援評価では権限・モデル・トークン消費・ストレージ設定まで確認が必要であることです。公式ドキュメント上、この手順はFoundry classicポータルに適用され、新しいFoundryポータル向けの記事ではないと明記されています。(Microsoft Learn)
生成AIやCopilot系アプリでは、「回答がそれらしい」だけではリリース判断ができません。根拠に沿っているか、危険な出力をしていないか、ツール呼び出しが正しいかを、テストデータで継続的に測る必要があります。Azure AI Evaluation SDKを使うと、1件の入出力でスポットチェックした後、より大きなデータセットに対して複数のエバリュエーターをまとめて実行できます。(Microsoft Learn)
Azure AI FoundryのAI評価更新で何が変わるのか
今回の「Local Evaluation with the Azure AI Evaluation SDK (classic)」で管理者・開発者が見るべき変更点は、評価機能そのものの全面刷新というより、Foundryにおける評価・可観測性の運用整理が進んでいる点です。
GitHub上の公式ドキュメント履歴では、2026年5月18日のコミットで、該当ファイルを含む複数のFoundry評価関連ドキュメントに ms.subservice: foundry-observability が追加されています。差分としてはメタデータ追加が中心で、evaluate-sdk.md でも本文APIの大きな破壊的変更ではなく、評価機能をFoundryの可観測性領域として扱う整理と見るのが妥当です。(GitHub)
実務上の影響は次のとおりです。
| 確認ポイント | 内容 | 影響を受ける人 |
|---|---|---|
| 対象ポータル | classicポータル向けの手順。新しいFoundryポータル向けではない | 管理者、開発リーダー |
| 評価の位置づけ | 生成AIアプリの品質・安全性・RAG・Agentic評価をローカルで実行 | 開発者、QA担当 |
| 結果の記録 | Foundryプロジェクトへ評価結果やログを追跡可能 | 管理者、MLOps担当 |
| データ形式 | classic手順ではJSONLと列マッピングが重要 | 開発者、データ担当 |
| 権限とストレージ | Azure OpenAI権限、Foundryプロジェクト、ストレージ接続を確認 | 管理者 |
つまり、開発者は「SDKを入れて実行する」だけでなく、どのポータルを使っているか、どの評価結果をUIに表示したいか、どの列名でデータを渡すかまで設計する必要があります。
classicポータル向け手順と新しいFoundryポータルの違い
このドキュメントは、Foundry classicポータル向けです。公式ページには「この記事は新しいFoundryポータルでは使用できない」と記載されています。リンク先の一部が新しいMicrosoft Foundryドキュメントに遷移する場合がある点も注意が必要です。(Microsoft Learn)
新しいFoundryポータルでは、ポータル上で評価を作成し、モデル・エージェント・データセット・トレースを評価対象にできます。新ポータル側の評価手順では、CSVまたはJSONLのテストデータ、チャット補完をサポートするAzure OpenAIのGPTモデル、FoundryプロジェクトのFoundry Userロールなどが前提として示されています。(Microsoft Learn)
| 利用状況 | 推奨する見方 |
|---|---|
| 既存のclassicポータル運用を継続している | Azure AI Evaluation SDK classic手順を確認する |
| 新しいFoundryポータルへ移行済み | 新ポータル向けの評価作成・クラウド評価手順を確認する |
| CI/CDや大規模評価に組み込みたい | ローカル評価だけでなく、クラウド評価や継続評価も検討する |
| 既存記事のリンクを社内手順書に使っている | classic向けか新ポータル向けかを明記しておく |
特に移行中の組織では、社内Wikiに「Azure AI Foundryの評価手順」とだけ書くと混乱します。classic用、new portal用、SDK用、ポータル操作用を分けて管理するのが安全です。
Azure AI Evaluation SDKでできること
Azure AI Evaluation SDKは、生成AIアプリケーションの出力を、数値ベースのメトリックやAI支援の品質・安全性エバリュエーターで測定するためのPython SDKです。公式手順では、まず次のコマンドで評価パッケージをインストールします。(Microsoft Learn)
pip install azure-ai-evaluationPyPI上では azure-ai-evaluation パッケージの要件としてPython 3.9以上が示されており、バージョンは時期によって更新されます。運用環境やCI/CDで使う場合は、単に最新版を入れるのではなく、requirements.txt や pyproject.toml でバージョンを固定して検証するのが基本です。(PyPI)
SDKの主な使い方は次の3つです。
| 使い方 | 目的 | 具体例 |
|---|---|---|
| 1行データの評価 | 評価ロジックの動作確認 | 1つの質問と回答で RelevanceEvaluator を試す |
| データセット評価 | 複数ケースをまとめて検証 | JSONLファイルを evaluate() に渡す |
| ターゲット評価 | アプリを呼び出して回答を生成し、その場で評価 | Pythonのcallableな関数やクラスを target に指定する |
開発初期は1行評価で十分ですが、本番前の判断にはデータセット評価が必要です。1件の成功例だけでは、RAGの根拠不足、危険な回答、長文入力時の劣化、ツール呼び出しミスを見落としやすいためです。
組み込みエバリュエーターの選び方
Azure AI Evaluation SDKには、品質、安全性、RAG、Agentic、Azure OpenAI Graderなど複数カテゴリの組み込みエバリュエーターがあります。公式ドキュメントでは、汎用評価として CoherenceEvaluator、FluencyEvaluator、RAG向けに GroundednessEvaluator や RetrievalEvaluator、安全性向けに ViolenceEvaluator、SelfHarmEvaluator、HateUnfairnessEvaluator、Agentic向けに IntentResolutionEvaluator、ToolCallAccuracyEvaluator、TaskAdherenceEvaluator などが示されています。(Microsoft Learn)
実務では、エバリュエーターを「たくさん入れる」より、アプリのリスクに合わせて選ぶことが重要です。
| 評価したい観点 | 使う候補 | 向いているケース |
|---|---|---|
| 回答が自然で読みやすいか | FluencyEvaluator、CoherenceEvaluator | FAQボット、社内ナレッジ検索 |
| 質問に関係ある回答か | RelevanceEvaluator | 問い合わせ対応、検索拡張チャット |
| 根拠に基づいているか | GroundednessEvaluator | RAG、社内文書回答、規程検索 |
| 正解データと近いか | F1ScoreEvaluator、SimilarityEvaluator | 定型回答、分類、既知FAQ |
| 危険・不適切な出力がないか | ContentSafetyEvaluator、各種Safety Evaluator | 外部公開チャット、教育、医療・金融周辺の問い合わせ |
| エージェントが意図やタスクを守るか | TaskAdherenceEvaluator、ToolCallAccuracyEvaluator | Copilot、業務エージェント、ツール実行型AI |
RAGアプリでは、最低でも「回答の関連性」と「根拠性」を分けて見るべきです。回答が質問に合っていても、参照文書にない内容を補っている場合があります。逆に、根拠文書には沿っていても、ユーザーの質問には十分答えていない場合もあります。
評価データはJSONLと列マッピングで設計する
classic手順では、バッチ評価にJSON Lines形式のデータセットを使います。公式ドキュメントでは、query、response、context、ground_truth などの要素が、エバリュエーターの要件に応じて使われると説明されています。(Microsoft Learn)
RAG評価用のJSONLは、たとえば次のように設計します。
{"query":"社内VPNに接続できない場合の初期対応は？","context":"VPN接続エラー時は、ネットワーク接続、認証情報、端末証明書の有効期限を確認する。","response":"まずネットワーク接続、認証情報、端末証明書の有効期限を確認してください。","ground_truth":"ネットワーク、認証情報、端末証明書を確認する。"}
{"query":"経費精算の締め日はいつですか？","context":"経費精算は毎月25日締め、翌月10日支払い。","response":"経費精算は毎月25日締めです。","ground_truth":"毎月25日締め。"}ここで失敗しやすいのは、データセットの列名と evaluator_config の列マッピングがずれることです。evaluate() APIがデータを正しく解析するには、データセットの列をエバリュエーターが受け取るキーワードへ明示的にマッピングする必要があります。(Microsoft Learn)
from azure.ai.evaluation import evaluate
result = evaluate(
data="data.jsonl",
evaluators={
"groundedness": groundedness_eval
},
evaluator_config={
"groundedness": {
"column_mapping": {
"query": "${data.query}",
"context": "${data.context}",
"response": "${data.response}"
}
}
},
output_path="./myevalresults.json"
)データ列を question、answer のように独自名にしている場合は、マッピング側もそれに合わせます。列名の統一ルールを決めずに各チームが自由に作ると、評価が失敗したり、結果がFoundry上で見えにくくなったりします。
Foundryプロジェクトへ結果を記録する前に確認する設定
ローカル評価の結果をFoundryプロジェクトに記録する場合、開発者のPCだけで完結しません。公式手順では、初めて評価を実行してFoundryプロジェクトへログを記録する場合、ストレージアカウントの作成・接続、接続済みストレージアカウントのプロジェクトアクセス、Microsoft Entra ID接続時の Storage Blob Data Owner 権限付与が必要になる場合があると説明されています。(Microsoft Learn)
管理者は、次の項目を事前に確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Foundryプロジェクト | 評価結果を記録する対象プロジェクトが正しいか |
| ストレージアカウント | Foundryプロジェクトに接続されているか |
| Entra ID権限 | ユーザーとFoundryプロジェクトリソースの双方に必要な権限があるか |
| Azure OpenAI権限 | 評価用モデルを呼び出せるロールがあるか |
| ネットワーク制限 | ローカル環境から必要なAzureリソースへ到達できるか |
| ログの扱い | 評価データに個人情報や機密情報が含まれていないか |
APIキーでAzure OpenAIの推論呼び出しを行う場合、Azure OpenAIリソースに対して少なくとも Cognitive Services OpenAI User ロールが必要とされています。また、リスク・安全性エバリュエーターや GroundednessProEvaluator では、GPTデプロイメントの model_config ではなく azure_ai_project 情報を使う点にも注意が必要です。(Microsoft Learn)
AI支援評価ではトークン消費とモデル選定に注意する
AI支援型の評価は、LLMを「採点者」として使います。そのため、評価品質は高めやすい一方で、トークン消費とコストが増えます。公式ドキュメントでは、SimilarityEvaluator を除くAI支援品質エバリュエーターには理由フィールドが含まれ、評価品質向上のためにより多くのトークンを消費すると説明されています。具体的には、多くのAI支援エバリュエーターで max_token が800、RetrievalEvaluator で1600、ToolCallAccuracyEvaluator で3000に設定されます。(Microsoft Learn)
コストを抑えるには、次の順序で進めると失敗しにくくなります。
- まず10〜30件程度の小さなJSONLで評価データと列マッピングを検証する
- 期待するスコアや理由フィールドが出るか確認する
- エバリュエーターを必要最小限に絞る
- CI/CD用の小規模スモーク評価と、定期実行用の大規模評価を分ける
- 評価モデルやSDKバージョンを固定して、スコアのブレを追跡する
特にAgentic評価では、ツール呼び出しや長い入力を扱うため、評価1件あたりのコストが想定より大きくなる場合があります。リリース前評価では必要な投資ですが、開発中の全コミットで大規模評価を回す設計は避けた方が現実的です。
会話・マルチモーダル評価で失敗しやすいポイント
会話形式の評価では、conversation に messages の一覧を渡します。各メッセージには content、role、必要に応じて context を含めます。公式ドキュメントでは、会話はターンごとに評価され、全ターンの結果が会話スコアとして集計されると説明されています。(Microsoft Learn)
注意すべきなのは、context が null またはキー欠落の場合です。この場合、エバリュエーターはエラーで失敗せず、空文字列として解釈する可能性があり、誤解を招く結果につながるとされています。(Microsoft Learn)
これは実務ではかなり危険です。たとえばRAG評価で context が空のままでも評価処理が走ると、「根拠がない回答」ではなく「根拠データが渡っていない評価」として扱うべきケースを見落とします。評価前に、JSONLの必須項目チェックをスクリプトで行いましょう。
import json
required = ["query", "response", "context"]
with open("data.jsonl", encoding="utf-8") as f:
for line_no, line in enumerate(f, start=1):
row = json.loads(line)
missing = [key for key in required if not row.get(key)]
if missing:
raise ValueError(f"{line_no}行目で必須項目が不足: {missing}")画像やマルチモーダル評価を使う場合も制限があります。classic手順では、画像URLまたはBase64エンコード画像を conversation に渡せますが、画像・マルチモーダル評価では単一ターンのみ、会話ペイロードは画像を含めて10MB未満、URLは絶対URL、対応形式はJPG/JPEG、PNG、GIFなどの条件が示されています。(Microsoft Learn)
新しいFoundryポータルやクラウド評価へ移行する判断基準
ローカル評価は、開発者が手元で素早く検証するには便利です。一方で、チーム運用・監査・CI/CD・大規模データセットを考えると、クラウド評価の方が向いている場合があります。
新しいMicrosoft Foundry SDKのクラウド評価ドキュメントでは、クラウド評価はスケールしたテスト、CI/CD連携、リリース前テストに向いており、結果はFoundryプロジェクトに保存され、ポータルやSDKから確認できると説明されています。(Microsoft Learn)
| 判断基準 | ローカル評価が向く | クラウド評価が向く |
|---|---|---|
| 開発初期の試行錯誤 | 向いている | やや過剰 |
| 小規模な評価データ | 向いている | どちらでも可 |
| CI/CDでの自動判定 | 可能だが管理が必要 | 向いている |
| 大規模評価 | ローカル環境に依存 | 向いている |
| チームで結果を共有 | Foundry記録が必要 | 向いている |
| 本番エージェントの継続評価 | 不向き | 向いている |
移行時に注意したいのは、SDKの種類と書き方が変わる点です。新しいクラウド評価手順では azure-ai-projects>=2.0.0 をインストールし、AIProjectClient からOpenAIクライアントを取得する流れが示されています。classicの azure-ai-evaluation を使ったローカル評価コードを、そのまま新しいクラウド評価へ移せるとは考えない方が安全です。(Microsoft Learn)
管理者と開発者が今すぐ確認すべきチェックリスト
Azure AI Foundryで評価機能を使うチームは、次のチェックリストを確認してください。
| 役割 | 確認すべきこと |
|---|---|
| 管理者 | 利用中のポータルがclassicか新Foundryポータルかを明記する |
| 管理者 | Foundryプロジェクト、ストレージ、Entra ID権限を確認する |
| 管理者 | Azure OpenAIリソースのロールと評価用モデルの利用可否を確認する |
| 開発者 | JSONLの列名、column_mapping、エバリュエーター名を統一する |
| 開発者 | AI支援評価のトークン消費を見積もる |
| 開発者 | context や ground_truth の欠落を事前検証する |
| 開発リーダー | ローカル評価、クラウド評価、ポータル評価の使い分けを決める |
| QA/MLOps | スコアのしきい値、失敗時の対応、再評価のタイミングを決める |
評価は、導入しただけでは品質保証になりません。たとえば「groundedness が3未満ならリリース不可」「安全性評価でfailが1件でもあればレビュー」「FAQカテゴリごとに最低20件のテストデータを用意する」のように、チームで判断基準を決める必要があります。
まずは小さく始めて、評価をリリース判定に組み込む
Azure AI Evaluation SDKのローカル評価は、Azure AI Foundry上で生成AIアプリを改善するための実践的な入口です。ただし、今回の対象はclassicポータル向けであり、新しいFoundryポータルやクラウド評価とは手順が異なります。
まず行うべきことは、1件の評価コードを書くことではなく、評価対象、評価データ、評価基準、結果の保存先を決めることです。RAGアプリなら query、response、context、必要に応じて ground_truth を含むJSONLを作り、関連性・根拠性・安全性を最小セットで評価します。その後、Foundryプロジェクトへの記録、CI/CD連携、クラウド評価への移行を段階的に進めると、評価が単発の検証ではなく、リリース品質を守る仕組みになります。
コメント