1. はじめに
この記事を作成する背景は、チャットボットの改善を主観だけで判断すると、効果やリグレッションを追いにくいことです。本記事の目的は、Microsoft Foundry で期待回答と実回答の差分を測り、改善を反復する手順を示すことです。
1.1 まず名称を整理する
Azure AI Studio は Azure AI Foundry を経て Microsoft Foundry へ改称されました。本記事では現行名の Foundry を使います。ポータルは https://ai.azure.com、ドキュメントは現行の /azure/foundry/ とクラシック系の /azure/foundry-classic/ に分かれます。[^foundry-overview]
1.2 評価は Observability（可観測性）の一部
Foundry の Observability は Evaluation、Monitoring、Tracing で構成されます。本記事は、想定 QA を使って主に本番前の品質を測る Evaluation を扱います。[^foundry-observability]
1.3 なぜ「想定 QA との差分」で測るのか
期待回答（ground truth）と実回答の差分をスコア化すると、プロンプト変更の効果と意図しない劣化を同じ基準で追えます。目視確認や run 比較にはポータル UI、CI/CD や定期実行には SDK が向きます。
2. 全体像：想定 QA 登録から差分確認・改善まで
先に改善ループの全体像を押さえます。想定 QA を登録して 1 回評価するだけでは終わりません。差分の大きい回答を特定し、原因を突き止め、直して再評価する 反復こそが品質を上げます。
本記事は、標準の Evaluation で Dataset を対象にし、想定 QA と実回答の差分を自動評価します。Human Evaluation と AI Red Teaming は別目的の補完ワークフローとして第 5 章で整理します。[^portal-evaluation]
各ステップの担当は次のとおりです。
- 登録（第 3 章）: 期待回答を含む JSONL を用意し、ポータルまたは SDK でアップロードします。
- 評価（第 6・7 章）: 差分を測る評価器を選んで実行します。
- 差分確認（第 6 章）: 行単位で実回答と期待回答、スコア、理由を見ます。
- 原因特定・改善・再評価（第 8 章）: Cluster Analysis などで弱点を診断し、直して比較します。
3. 想定 QA データセット（JSONL）の設計と登録
3.1 ground_truth が「想定回答」
評価用データセットは 1 行 1 JSON オブジェクトの JSONL 形式です。ground_truth が想定回答にあたります。[^textual-similarity]
| キー | 説明 | 主な用途 |
|---|---|---|
query | ユーザーの質問・プロンプト | ほぼ全評価器 |
response | 実回答（モデル/エージェントの出力） | ほぼ全評価器 |
context | RAG のグラウンディング文書（任意） | Groundedness, Retrieval |
ground_truth | 期待する正解＝想定回答（人手ラベル） | Similarity, F1, ROUGE などの差分比較 |
3.2 差分が見えるサンプル JSONL
正常、内容矛盾、情報欠落の 3 ケースを用意すると、評価器の違いを確認しやすくなります。
{"query":"What are your store hours?","context":"Mon-Fri 9-18, Sat 10-16, closed Sun.","response":"Mon-Fri 9-18, Sat 10-16, closed Sun.","ground_truth":"Mon-Fri 9-18, Sat 10-16, closed Sun."}
{"query":"Can I change my order?","context":"Orders can be changed within 1 hour.","response":"Orders cannot be changed.","ground_truth":"Orders can be changed within 1 hour."}
{"query":"What payments do you accept?","context":"Visa, Mastercard, PayPal, bank transfer.","response":"Visa, Mastercard, and PayPal.","ground_truth":"Visa, Mastercard, PayPal, and bank transfer."}
2 行目は内容が矛盾し、3 行目は銀行振込が欠落しています。同じ意味の言い換え、明確な誤り、部分的な欠落を混ぜると、Similarity と F1 の特性を比較できます。
3.3 実回答は「事前記載」か「実行時生成」か
評価対象によって、JSONL に response を入れるかが変わります。
| ターゲット | JSONL に response が必要 | response の取得元 |
|---|---|---|
| Dataset（既存出力を評価） | 必須 | JSONL に事前記載 |
| Model | 不要 | 実行時にモデルが生成 |
| Agent | 不要 | 実行時にエージェントが生成 |
| Traces | アップロード不要 | Application Insights に記録済みの対話 |
既存回答を比べるだけなら Dataset が最も簡単です。Model / Agent では、Foundry が query を送り、実行時に生成した回答を評価します。Traces は、すでに記録されたエージェントの対話を評価するときに使います。[^portal-evaluation]
3.4 データセットの登録手順
ポータルでは次の順に登録します。
- 左ペインの Evaluation → Create を開きます。
- 評価対象で Dataset を選びます。
- Existing dataset でプロジェクトに登録済みの CSV / JSONL を指定します。未登録なら、先にデータ資産として追加します。
- Configure field mapping で
query/responseを割り当て、Similarity や F1 を使う場合はground_truthも割り当てます。
SDK からのアップロードは第 7 章で扱います。ポータルの選択肢や表示名は更新されるため、公開前には公式手順も確認してください。[^portal-evaluation]
4. 実回答と想定回答の差分を測る評価器の選び方
4.1 差分比較の主役は ground_truth を取る評価器
差分測定には ground_truth を入力に取る評価器 を使います。
| 評価器 | 主に測るもの | 出力 | 判定モデル |
|---|---|---|---|
Similarity (builtin.similarity) | 言い換えを含む意味的類似度 | 1–5 | 必要 |
F1 (builtin.f1_score) | トークンの適合率・再現率 | 0–1 | 不要 |
| BLEU / GLEU / ROUGE / METEOR | n-gram、語幹、同義語などの一致 | 0–1（ROUGE は 3 指標） | 不要 |
| Response Completeness（プレビュー） | 想定回答に対する情報の欠落 | 1–5 をしきい値で Pass / Fail | 必要 |
Similarity と Response Completeness の既定しきい値は 3、NLP 系は 0.5 です。用途に応じて自分のデータで基準値を調整してください。ROUGE は rouge_type の指定が必要です。Similarity、F1、BLEU、GLEU、ROUGE、METEOR は GA、Response Completeness はプレビューです。[^textual-similarity][^rag-evaluators]
4.2 差分比較に「使わない」評価器
Groundedness は context への忠実性、Relevance は質問との関連性、Coherence / Fluency は文章品質、Retrieval は検索品質を測ります。いずれも想定回答との差分そのものではありません。複数観点をまとめる QAEvaluator は classic のローカル SDK（azure-ai-evaluation）にある合成評価器で、新しいクラウド評価の builtin.* カタログには含まれません。[^built-in-evaluators][^local-evaluation-sdk]
4.3 評価器の選択フロー
言い換えを許容するなら Similarity、字面の一致を重視するなら F1 などの NLP 系を選びます。
チャット QA では Similarity を主指標、F1 を低コストの補助指標 にする構成が扱いやすいです。
5. 評価手段の使い分け（Evaluation / Human Evaluation / AI Red Teaming）
現行の公式ドキュメントでは、モデル・エージェント・データセット・トレースを自動採点する標準フローを Evaluation と呼びます。Human Evaluation はエージェント回答への人手レビュー、AI Red Teaming は敵対的な安全性テストとして別に扱われます。3 つを同じ画面の固定タブとみなさず、目的別のワークフローとして使い分けます。[^portal-evaluation][^human-evaluation][^red-teaming-agent]
5.1 3 つのワークフローの役割
| ワークフロー | 主目的 | ground_truth との差分比較 | 本記事での位置づけ |
|---|---|---|---|
| Evaluation | 品質・安全・性能の自動採点 | Dataset + 対応評価器で可能 | 主に使用 |
| Human Evaluation | トーンや有用性などの人手評価 | なし | 必要に応じて補完 |
| AI Red Teaming | 敵対的入力による安全性・脆弱性検証 | なし | リリース前後に併用 |
Evaluation では Dataset / Model / Agent / Traces を対象にでき、Dataset なら CSV / JSONL の既存出力を評価できます。結果には行単位のスコアと理由が表示され、複数 run の比較も可能です。[^portal-evaluation][^evaluation-results]
5.2 目的別の選択
判断を図にすると次のとおりです。
- 想定回答との回帰比較: Evaluation
- トーン・共感性・正解が一意でない回答: Human Evaluation
- 脆弱性や安全性: AI Red Teaming
3 つは排他ではありません。実務では Evaluation で定点観測し、主観が必要な箇所を Human Evaluation で確認し、リリース前後に AI Red Teaming を重ねます。
6. ポータル UI で評価を実行して差分を見る
6.1 評価を作成するステップ
ポータル（ai.azure.com）での手順は次のとおりです。
- 左ペインの Evaluation → Create を開きます。
- 評価対象 を選びます。想定 QA 比較なら Dataset、実チャットを走らせて評価するなら Agent、記録済み対話なら Traces を選びます。
- スコープ を選びます。1 応答単位の QA なら Individual turns、複数ターン会話なら Full conversations（プレビュー） です。Model は Individual turns 固定です。
- データソース で JSONL / CSV を指定します。
- Configure field mapping を設定します。Individual turns の既存データでは
query/responseを割り当て、Similarity や F1 ではground_truthも割り当てます。Full conversations ではmessages/tool_definitionsを使うため、同じスキーマを流用できません。 - 評価器 を選びます。AI アシスト評価器では、利用可能な GPT デプロイまたは対応する judge model を指定します。
- Review and Submit で名前を付けて実行します。[^portal-evaluation]
6.2 行単位で「実回答 vs 想定回答」を見る
実行後、一覧から run を開くと詳細ページが表示され、Evaluation tokens（判定側）と Target tokens（対象側） が別々に確認できます。さらに run 名をクリックすると行単位の結果 が開きます。ここが差分を見る中心画面です。[^evaluation-results]
- 各行で
query/response/ground_truth/ 各評価器のスコア / スコア理由（reason）を確認できます。 - 第 3 章のサンプルなら、内容が矛盾する 2 件目と情報が欠落する 3 件目でスコアが下がり、差分の所在を確認できます。
6.3 複数 run を Compare で比較する
2 つ以上の run を選んで Compare すると、t 検定つきの並列比較が表示されます。基準（baseline）run を設定でき、改善・悪化が有意かどうかを凡例で判断できます。ただし 比較ビューは保存されない ため、離脱後は run を再選択して再生成します。[^evaluation-results]
7. SDK で評価する（クラウド／ローカル classic）
評価 SDK は 2 系統あり、列マッピング構文が異なります。クラウド評価は {{item.列名}}、classic のローカル評価は ${data.列名} を使います。[^cloud-evaluation-sdk][^local-evaluation-sdk]
7.1 クラウド評価（推奨: azure-ai-projects）
本番や CI/CD では、結果と report_url を Foundry プロジェクトに保存できるクラウド評価が向きます。
pip install "azure-ai-projects>=2.4.0,<3.0.0"
Similarity の設定で重要なのは、評価器名と列マッピングです。
from azure.ai.projects.models import TestingCriterionAzureAIEvaluator
similarity = TestingCriterionAzureAIEvaluator(
type="azure_ai_evaluator",
name="Similarity",
evaluator_name="builtin.similarity",
data_mapping={
"query": "{{item.query}}",
"response": "{{item.response}}",
"ground_truth": "{{item.ground_truth}}",
},
initialization_parameters={"model": "<judge-deployment>", "threshold": 3},
)
実行は、AIProjectClient でデータセットをアップロードし、evals.create()、evals.runs.create() の順に呼びます。F1 は evaluator_name="builtin.f1_score" とし、response と ground_truth を割り当てます。対象モデルの出力をその場で評価する場合、response は {{sample.output_text}} です。API は更新されるため、完全な実装は使用中の SDK バージョンに対応する公式サンプルを確認してください。[^cloud-evaluation-sdk]
7.2 ローカル評価（classic の azure-ai-evaluation）
classic 環境で手元の JSONL を評価する場合は azure-ai-evaluation の evaluate() を使います。Similarity は SimilarityEvaluator(model_config)、F1 は F1ScoreEvaluator() を指定し、入力列を ${data.query}、${data.response}、${data.ground_truth} へマッピングします。実行時生成した回答は ${outputs.response} です。この方式は新しいクラウド評価とは別系統です。[^local-evaluation-sdk]
pip install azure-ai-evaluation
7.3 どちらを使うか
| 観点 | クラウド azure-ai-projects | ローカル classic azure-ai-evaluation |
|---|---|---|
| 列マッピング構文 | {{item.列名}} / {{sample.output_text}} | ${data.列名} / ${outputs.response} |
| 結果の保存 | Foundry プロジェクトに保存・report_url | ローカル JSON、任意でポータルへログ |
| 向いている用途 | 本番・CI/CD・大規模テスト | classic 環境での手元検証・小規模評価 |
8. 差分を見ながら改善するループを回す
8.1 原因を特定する：Cluster Analysis
低スコアの行が分かったら、次は原因の特定です。Cluster Analysis は 1 件以上の完了済み run を選ぶと、埋め込みベースで回答やフィードバックを意味的にクラスタリングし、各クラスタに 推定原因（likely cause）と改善レコメンド を付けます。2026 年 8 月 15 日時点の公式ページでは、Cluster Analysis 自体に明示的な「プレビュー」表記はありません。[^cluster-analysis]
- 特定できる原因の例: プロンプトの指示不足・誤回答・検索失敗・ツールエラーなど。
- 結果は保存されない ため、離脱前に CSV エクスポートしてください。埋め込み生成にモデルを使うためトークンコストが発生します。[^cluster-analysis]
8.2 改善アクションに落とす
診断結果を具体的な打ち手に変えます。代表的な対応は次のとおりです。
| Cluster Analysis の診断例 | 改善アクション |
|---|---|
| プロンプトの指示不足 | システムプロンプトに制約・出力形式を追記 |
検索失敗（context 不足） | RAG の検索クエリ・チャンク・リランクを見直す |
| モデルの能力不足 | 上位モデルへ変更、パラメータを調整 |
| ツールエラー | ツール定義・認証・入力スキーマを修正 |
8.3 再評価して run 比較で改善を定量確認
改善を加えたら同じ想定 QA で再評価し、第 6.3 節の Compare で改善前後を比較します。t 検定つきなので、スコア上昇が偶然ではなく有意かどうかを判断できます。しきい値を満たすまで、この差分確認 → 改善 → 再評価を繰り返します。[^evaluation-results]
8.4 CI/CD に組み込む（GitHub Actions）
公式の microsoft/ai-agent-evals@v3-beta は、複数の agent-ids と任意のベースラインを比較できます。ベータ版であり、認証には Entra ID + OIDC を使います。判定モデルのコストを考慮し、毎コミットではなくプルリクエストやリリース前に実行する設計が現実的です。[^github-action-evaluation]
9. 前提条件・ロール・コストの注意
9.1 前提条件とロール
- Azure サブスクリプションと Microsoft Foundry プロジェクト
- 評価対象（agent・モデル・CSV/JSONL データセット・記録済み trace）
- AI アシスト評価には Azure OpenAI 接続と対応する GPT デプロイ（クラウド評価の公式例では
gpt-5-mini）[^cloud-evaluation-sdk] - Foundry User ロール（旧称 Azure AI User。表示名の変更でロール ID と中核権限は不変）[^rbac-foundry]
- Human Evaluation のテンプレート作成者は Foundry Project Manager 以上、レビュー担当者はプロジェクトの Foundry User とアカウントの Reader が必要[^human-evaluation]
9.2 判定モデルが要る評価器 / 要らない評価器
| 判定モデル（GPT デプロイ）が要る | 判定モデルが要らない |
|---|---|
| Similarity, Response Completeness, Coherence, Fluency, Groundedness, Relevance, Retrieval | NLP 系: F1 / BLEU / GLEU / ROUGE / METEOR、Groundedness Pro（Content Safety 使用） |
評価器ごとの必須入力とモデル要否は更新されるため、組み込み評価器リファレンスと各カテゴリの表を確認してください。[^built-in-evaluators][^textual-similarity][^rag-evaluators]
9.3 コストの考え方
- AI アシスト評価器はトークン課金 です。判定用 GPT デプロイの推論料金が評価呼び出しごとに発生します。[^observability-pricing]
- NLP 系（F1 / BLEU / GLEU / ROUGE / METEOR）は純粋計算 で、判定モデルのトークン消費はありません。コストを抑えたいときの選択肢になります。
- Risk & Safety 評価や Playground 評価は Foundry の Observability として従量課金です。具体的な金額は変動するため、必ず公式の料金ページ・料金計算ツールで確認してください（本記事では金額を断定しません）。[^observability-pricing]
- ポータルの run 詳細には Evaluation tokens（判定側） と Target tokens（対象モデル側） が別表示されるので、コスト内訳を追えます。[^evaluation-results]
- 評価機能にはリージョン制約があります。2026 年 8 月 15 日時点では、Groundedness Pro は East US 2 / Sweden Central、Protected Material は East US 2、AI Red Teaming は East US 2 / North Central US が対象です。利用前に最新のリージョン表を確認してください。[^evaluation-regions]
提供状態の注意（2026 年 8 月 15 日確認）: Full conversations、Response Completeness、Groundedness Pro は公式ページでプレビューと明記されています。GitHub Action は
v3-betaです。一方、Similarity を含むテキスト類似度評価器 6 種は GA で、Cluster Analysis の現行ページには同機能を指す明示的なプレビュー表記がありません。提供状態は変わるため、実装時に最新の公式ページを再確認してください。[^portal-evaluation][^textual-similarity][^rag-evaluators][^cluster-analysis]
10. まとめ
- 想定 QA の登録は
ground_truthを含む JSONL の用意 から始まります。Dataset を評価対象にすると、既存の実回答との差分を測れます。 - 差分比較の主役は
ground_truthを取る評価器 です。意味重視なら Similarity、厳密一致なら F1 など NLP 系を選び、Groundedness や Relevance とは役割を分けます。 - ポータル UI は行単位で差分を可視化 し、Compare で改善を有意差つきに比較できます。SDK はクラウド評価と classic のローカル評価を混同せずに使い分けます。
- 改善は「評価 → Cluster Analysis で原因特定 → 直す → 再評価 → run 比較」の反復 です。CI/CD には公式 GitHub Action を組み込めます。
まずは第 3 章のサンプル JSONL を使い、ポータルの Dataset 評価、またはクラウド SDK の builtin.similarity と builtin.f1_score で 1 回評価してみてください。差分が数値で見えると、改善の打ち手が具体的になります。
11. 参考情報
- What is Microsoft Foundry? — 現行名称、ポータル、classic との関係
- Built-in Evaluators Reference — 組み込み評価器の一覧
- Textual Similarity Evaluators for Generative AI — Similarity と NLP 系評価器
- Run evaluations from the Microsoft Foundry portal — ポータルでの評価作成手順
- See Evaluation Results in Microsoft Foundry portal — 行単位結果と run 比較
- Cloud Evaluation with the Microsoft Foundry SDK —
azure-ai-projectsによるクラウド評価 - Local Evaluation with the Azure AI Evaluation SDK (classic) — classic のローカル評価
- Evaluation Cluster Analysis — クラスタ分析と結果の保存上の注意
- How to run an evaluation in GitHub Action —
microsoft/ai-agent-evalsの設定 - 階層化された FAQ サイトをクロールして高精度 RAG を構築する方法 — RAG の評価対象となる検索・回答基盤の設計
この記事の執筆にあたり、AI の支援を受けています。
[^foundry-overview]: What is Microsoft Foundry? — Microsoft Learn（確認日: 2026-08-15）
[^foundry-observability]: Observability in Generative AI — Microsoft Learn（確認日: 2026-08-15）
[^portal-evaluation]: Run evaluations from the Microsoft Foundry portal — Microsoft Learn（確認日: 2026-08-15）
[^textual-similarity]: Textual Similarity Evaluators for Generative AI — Microsoft Learn（確認日: 2026-08-15）
[^rag-evaluators]: Retrieval-Augmented Generation (RAG) Evaluators for Generative AI — Microsoft Learn（確認日: 2026-08-15）
[^built-in-evaluators]: Built-in Evaluators Reference — Microsoft Learn（確認日: 2026-08-15）
[^local-evaluation-sdk]: Local Evaluation with the Azure AI Evaluation SDK (classic) — Microsoft Learn（確認日: 2026-08-15）
[^human-evaluation]: Human Evaluation for Microsoft Foundry Agents — Microsoft Learn（確認日: 2026-08-15）
[^red-teaming-agent]: AI Red Teaming Agent — Microsoft Learn（確認日: 2026-08-15）
[^evaluation-results]: See Evaluation Results in Microsoft Foundry portal — Microsoft Learn（確認日: 2026-08-15）
[^cloud-evaluation-sdk]: Cloud Evaluation with the Microsoft Foundry SDK — Microsoft Learn（確認日: 2026-08-15）
[^cluster-analysis]: Evaluation Cluster Analysis — Microsoft Learn（確認日: 2026-08-15）
[^github-action-evaluation]: How to run an evaluation in GitHub Action — Microsoft Learn（確認日: 2026-08-15）
[^rbac-foundry]: Role-based access control for Microsoft Foundry — Microsoft Learn（確認日: 2026-08-15）
[^evaluation-regions]: Rate limits, region support, and enterprise features for evaluation — Microsoft Learn（確認日: 2026-08-15）
[^observability-pricing]: Observability in Foundry Control Plane - Pricing — Microsoft Azure（確認日: 2026-08-15）
