Microsoftの「Evaluation」は、AIエージェントを作って終わりにせず、応答品質・安全性・正確性・ツール呼び出し・ワークフロー全体の成否を継続的に検証するための仕組みです。特にMicrosoft Agent Frameworkでは、開発中はローカルで素早くチェックし、本番相当の評価ではAzure AI Foundryのエバリュエーターを使う、という使い分けが現実的な運用になります。公式ドキュメントでは、Agent Frameworkに品質・安全性・正確性を測定する組み込み評価フレームワークが含まれ、ローカル評価とAzure AI Foundryのクラウド評価を単独または組み合わせて実行できると説明されています。(Microsoft Learn)
結論から言えば、管理者や開発者がまず確認すべきなのは「どのエージェントを、どのデータで、どの評価指標にかけるか」です。2026年5月26日に更新されたAgent Framework関連の公式情報では、Azure OpenAIのResponsesクライアント推奨、Assistants APIからの移行、Foundry Localの制約など、Evaluation設計に影響する周辺条件も明確になっています。(Microsoft Learn)
MicrosoftのEvaluationとは何か
MicrosoftのEvaluationは、単なる「AIの回答が良さそうか」を見るチェックではありません。AIエージェントがユーザーの意図を理解したか、必要なツールを正しく呼び出したか、ツールの結果を回答に正しく反映したか、危険な出力をしていないかまで確認するための評価プロセスです。
Microsoft Agent FrameworkのEvaluationでは、主に次の3つを扱います。
| 評価対象 | 何を見るか | 具体例 |
|---|---|---|
| 応答品質 | 回答が自然で、質問に合っているか | 関連性、流暢さ、完全性、根拠性 |
| エージェント動作 | 意図理解やツール利用が適切か | Tool Call Accuracy、Intent Resolution、Task Adherence |
| ワークフロー全体 | 複数エージェントや複数ステップの処理が成功したか | 旅行予約、問い合わせ対応、社内申請の自動処理 |
従来のチャットボット評価では「最終回答」だけを見がちでした。しかし、AIエージェントは途中で検索、API呼び出し、ファイル参照、他エージェントへの委譲などを行います。最終回答が一見正しくても、途中で不要なツールを呼んでいたり、誤った引数でAPIを呼んでいたりすれば、本番運用ではコスト増・誤処理・セキュリティ事故につながります。
MicrosoftのEvaluationで押さえるべき変更点
Microsoft Agent FrameworkのEvaluationで重要なのは、評価がフレームワーク外の後付け作業ではなく、エージェントやワークフローの開発・CI/CD・運用監視に組み込みやすい形で整理されている点です。
公式情報では、Evaluationの中核概念としてEvalItem、Evaluator、EvalResultsが示されています。EvalItemは評価する1件の会話、Evaluatorはスコア付けする評価プロバイダー、EvalResultsは成功・失敗数や項目別の詳細を含む評価結果です。(Microsoft Learn)
変更点を実務目線で整理
| 変更・注目点 | これまで起きやすかった課題 | これからの確認ポイント |
|---|---|---|
| ローカル評価を標準的に使える | 毎回クラウド評価を回し、時間やコストが増える | 開発中・CIの軽量チェックはLocalEvaluatorに寄せる |
| Azure AI Foundry評価と連携 | 評価結果が個人のログやスクリプトに散らばる | Foundryポータルで結果を比較・可視化する |
| カスタム評価を定義可能 | 業務固有の合格条件を測れない | 「社内規程名を含む」「必ず承認前に確認する」などを評価関数化する |
| エージェントだけでなくワークフローも評価可能 | 複数エージェント構成のどこで失敗したか分からない | 全体結果とサブエージェント別の結果を分けて確認する |
| ツール呼び出しも評価対象 | 最終回答だけ合っていて途中処理の誤りを見逃す | 期待するツール名、引数、実行順序をテストデータに含める |
対象者は誰か
MicrosoftのEvaluationは、AIエージェントを実装する開発者だけの話ではありません。運用設計、セキュリティ、コスト管理、品質保証にも関係します。
開発者
開発者は、エージェントの修正が品質を下げていないかを確認するためにEvaluationを使います。たとえば、プロンプトを変更した結果、回答は自然になったもののツール呼び出しが不安定になることがあります。このような退行を防ぐには、最低限の評価データセットを用意し、変更のたびにローカル評価やCI評価を実行するのが有効です。
Agent Frameworkでは、.NETではAIAgentやRunの拡張メソッド、Pythonではevaluate_agent()やevaluate_workflow()を使って評価を実行する構成が示されています。(Microsoft Learn)
管理者・運用担当者
管理者は、Azure AI Foundryプロジェクト、モデルデプロイ、権限、クォータ、コストを確認する必要があります。Azure AI Foundryのクラウド評価では、LLM-as-judgeのように評価用モデルを使うため、評価回数やデータ量が増えればコストやクォータにも影響します。
Microsoft Foundryの観測性ドキュメントでは、評価、監視、トレースを組み合わせてAIアプリケーションの品質・安全性・運用状態を把握する考え方が示されています。評価指標、ログ、トレース、モデル出力を使って、開発から本番監視まで可視性を高める位置付けです。(Microsoft Learn)
QA・セキュリティ担当者
QAやセキュリティ担当者は、評価データセットの妥当性とリスク評価を確認します。正常系だけでなく、曖昧な質問、権限外の依頼、プロンプトインジェクションに近い入力、機密情報を引き出そうとする入力なども評価対象に含めるべきです。
Microsoft Foundryでは、品質評価、RAG向け評価、安全性評価、エージェント固有の評価などが用意されています。エージェント向けには、タスク完了、タスク遵守、意図解決、ツール呼び出し精度などが整理されています。(Microsoft Learn)
LocalEvaluatorは開発中とCIの軽量チェックに向いている
LocalEvaluatorは、API呼び出しなしでローカルにチェックを実行するための仕組みです。公式ドキュメントでは、開発中の高速な反復、CIのスモークテスト、素早い確認に適していると説明されています。(Microsoft Learn)
たとえば、天気エージェントなら次のようなチェックをローカル評価に入れます。
| チェック内容 | 評価の例 | 失敗したときに疑う箇所 |
|---|---|---|
| 必須キーワードを含むか | 「weather」「temperature」を含む | プロンプト、出力形式、モデル変更 |
| 指定ツールを呼んだか | get_weatherを呼び出したか | ツール定義、関数名、プロンプト |
| 回答が長すぎないか | 500語未満か | システムプロンプト、要約指示 |
| 想定値を含むか | 期待する都市名を含む | データセット、引数マッピング |
ローカル評価は、すべての品質問題を検出するためのものではありません。役割は「明らかな壊れ方を早く見つけること」です。たとえば、関数名の変更でツール呼び出しが動かなくなった、必須の免責文が出なくなった、回答形式がJSONから自然文に崩れた、といった問題の検出に向いています。
Azure AI Foundry evaluatorsは本番相当の評価に使う
Azure AI Foundry evaluatorsは、クラウドベースで品質、安全性、タスク遵守、ツール呼び出しなどを評価するための仕組みです。Agent Frameworkの公式ドキュメントでは、FoundryEvalsがAzure AI Foundryの評価サービスに接続し、結果をFoundryポータルのダッシュボードや比較ビューで確認できると説明されています。(Microsoft Learn)
FoundryEvalsでは、関連性、整合性、タスク遵守などの評価に加え、ツール定義を含む項目ではTool Call Accuracyが自動的に追加される場合があるとされています。また、利用にはAzure AI FoundryプロジェクトとAIモデルのデプロイが必要です。(Microsoft Learn)
ローカル評価とFoundry評価の使い分け
| 目的 | 推奨する評価方法 | 理由 |
|---|---|---|
| 関数名や必須語句の確認 | LocalEvaluator | 速く、コストを抑えやすい |
| プルリクエスト時の最低限チェック | LocalEvaluator + 小規模データセット | 開発者がすぐ修正できる |
| リリース前の品質判定 | Azure AI Foundry evaluators | 品質・安全性・ツール利用を広く評価できる |
| 複数バージョンの比較 | FoundryポータルまたはCI評価 | 結果の比較と履歴管理がしやすい |
| 本番後の継続監視 | Foundry Observability + Azure Monitor | 品質低下や異常傾向を追える |
現場では、ローカル評価を「単体テスト」、Foundry評価を「結合テスト・リリース判定」に近い位置付けで扱うと設計しやすくなります。
評価データセットに含めるべき項目
Evaluationで失敗しやすいポイントは、評価機能そのものではなく、評価データセットの作り方です。良い評価データがなければ、どれだけ高機能なエバリュエーターを使っても、本番で起きる問題を検出できません。
最低限用意したい評価データ
| 項目 | 内容 | 例 |
|---|---|---|
query | ユーザー入力 | 「来週月曜の大阪出張を申請して」 |
response | エージェントの回答 | 「申請内容を確認しました」 |
expected_output | 期待する回答や要素 | 「日付、目的地、承認者確認を含む」 |
expected_tool_calls | 呼ぶべきツール | create_travel_request |
tool_definitions | 利用可能なツール定義 | ツール名、説明、引数 |
ground_truth | 正解データ | 正しい承認フロー、正しい金額 |
context | RAGなどで使う根拠情報 | 社内規程、FAQ、契約条項 |
Foundryのエージェント評価では、評価器ごとに必要な入力が異なります。たとえば、Task Completionはqueryとresponse、Tool Call Accuracyはquery、responseまたはtool_calls、tool_definitionsなどを必要とします。複雑なツール呼び出しを含む会話では、OpenAI message schemaに沿った会話配列形式が使われます。(Microsoft Learn)
評価データの例
{
"query": "東京本社で使える会議室を明日10時から1時間予約して",
"expected_output": "予約対象、日時、場所、確認結果を含めて回答する",
"expected_tool_calls": [
{
"name": "search_meeting_room",
"arguments": {
"location": "東京本社",
"start_time": "10:00",
"duration_minutes": 60
}
}
]
}このように、単に「良い回答をしているか」ではなく、どのツールを、どの引数で、どの順序で使うべきかまで評価データに含めると、実運用に近い品質確認ができます。
エージェント評価で見るべき指標
AIエージェントでは、最終回答の自然さだけでは不十分です。特に業務システムと連携する場合、ツール呼び出しの正確性が重要になります。
| 評価指標 | 見るポイント | 向いている用途 |
|---|---|---|
| Intent Resolution | ユーザーの意図を正しく理解したか | FAQ、問い合わせ分類、サポート |
| Task Adherence | 指示や制約に従ったか | 規制業務、社内ルール遵守 |
| Task Completion | タスクを最後まで完了したか | 予約、申請、レポート作成 |
| Tool Call Accuracy | 正しいツールを正しい引数で呼んだか | API連携、業務自動化 |
| Tool Selection | 不要なツールを呼ばず、必要なツールを選んだか | 複数ツールを持つエージェント |
| Tool Input Accuracy | ツール引数の型、形式、必須項目が正しいか | 厳密なAPI連携 |
| Tool Output Utilization | ツール結果を回答に正しく使ったか | 検索、DB照会、RAG |
| Tool Call Success | ツール実行が成功したか | 運用監視、障害検知 |
Microsoft FoundryのAgent evaluatorsでは、System evaluationとProcess evaluationの2種類が示されています。System evaluationは最終的な成果を見ます。一方、Process evaluationはツール呼び出しなど途中ステップの品質と効率を見るための評価です。(Microsoft Learn)
評価できない、または注意が必要なツールもある
Evaluationを導入するときに見落としやすいのが、すべてのツールが同じ粒度で評価できるわけではない点です。
FoundryのAgent evaluatorsでは、File Search、ユーザー定義のFunction Tool、MCP、Knowledge-based MCPがサポート対象として示されています。一方で、Azure AI Search、Bing Grounding、Bing Custom Search、SharePoint Grounding、Code Interpreter、Fabric Data Agent、Web Searchを含む会話では、tool_call_accuracy、tool_input_accuracy、tool_output_utilization、tool_call_success、groundednessの利用を避けるよう注意されています。(Microsoft Learn)
これは、Web SearchやCode Interpreterを使ってはいけないという意味ではありません。評価設計上、ツールの種類によっては期待通りの評価ができない可能性があるため、別の指標や人手レビュー、ログ分析を組み合わせる必要があるという意味です。
2026年5月26日更新情報で特に注意したい移行・展開ポイント
2026年5月26日に更新されたAgent Framework関連の公式情報では、Evaluationそのものに加えて、評価対象となるエージェントの実装方式にも注意が必要です。特にAzure OpenAI、OpenAI互換クライアント、Foundry Localを使っている環境では、ツール対応や移行方針が評価結果に直結します。
Azure OpenAIではResponsesクライアントが推奨
Azure OpenAI Agentsの公式ドキュメントでは、Agent FrameworkがAzure OpenAI向けにResponsesとChat Completionの2種類のクライアントをサポートし、Responsesが推奨の主要クライアントとされています。ResponsesはCode Interpreter、File Search、Web Search、Hosted MCPなどのホスト型ツールを含むフル機能のエージェントに向く一方、Chat Completionはシンプルなエージェントや既存のChat Completions連携を維持したい場合に向くと説明されています。(Microsoft Learn)
さらに、Azure OpenAI Assistants APIは非推奨であり、新規コードではResponsesクライアントを使うよう案内されています。既存のAssistantsベースのアプリを評価対象にしている場合は、Evaluationを導入する前に、移行方針とツール対応を確認する必要があります。(Microsoft Learn)
| 利用中の構成 | 確認すべきこと | Evaluationへの影響 |
|---|---|---|
| Azure OpenAI Assistants API | Responsesクライアントへの移行計画 | ツール呼び出しログや評価データ形式の見直し |
| Azure OpenAI Chat Completion | 必要なツールが対応しているか | Code InterpreterやFile Search評価に制約が出る可能性 |
| Azure OpenAI Responses | ホスト型ツールの利用範囲 | Tool Call Accuracyなどの評価設計がしやすい |
| Pythonの旧Azure OpenAI互換クラス | agent_framework.openaiやFoundryChatClientへの移行 | import、環境変数、モデル指定の見直し |
公式情報では、Python Azure OpenAIのガイダンスがOpenAI providerページ側に移り、古いAzureOpenAI*互換クラスは現在のagent_framework.azure名前空間から削除されたとされています。新しいPythonソリューションでは、Microsoft Foundryにモデルをデプロイし、FoundryChatClientで接続することも推奨されています。(Microsoft Learn)
Foundry Localを使う場合の注意点
Foundry Localは、サポートされるMicrosoft Foundryモデルをローカルマシンで実行しつつ、Agent Framework Pythonの標準的なAgent体験を使うための機能です。ただし、公式ドキュメントではFoundry Localは現時点で.NETに対応していないとされています。(Microsoft Learn)
また、FoundryLocalClientはローカルチャットクライアントであり、Code Interpreter、File Search、Web Search、Hosted MCPなどのホスト型Foundryツールは利用できません。Function Toolsも、選択したローカルモデルが関数呼び出しをサポートしている場合に限られます。(Microsoft Learn)
Foundry Localで評価する際の実務ポイント
| 確認項目 | 理由 |
|---|---|
| .NETではなくPython前提か | Foundry Localは現時点で.NET非対応 |
| モデルがfunction callingに対応しているか | ツール呼び出し評価の前提になる |
| ホスト型ツールを使っていないか | ローカルではCode InterpreterやFile Searchなどが使えない |
| 本番環境のモデルと差がないか | ローカルで合格しても本番モデルで同じ挙動とは限らない |
| ローカル評価とクラウド評価を分けているか | 目的が異なるため、同じ合格基準にしない |
Foundry Localは、開発初期の試行や簡易検証には便利です。ただし、本番でAzure AI FoundryやAzure OpenAI Responsesを使う場合、最終的なリリース判定は本番に近いクライアント、モデル、ツール構成で評価するべきです。
Conversation split strategiesを理解する
複数ターンの会話を評価する場合、どこからどこまでを「質問」とし、どこからどこまでを「応答」とするかが重要です。Agent FrameworkのEvaluationでは、会話分割の考え方として、Last turn、Full、Per-turnなどの戦略が示されています。(Microsoft Learn)
| 分割方法 | 評価の考え方 | 向いているケース |
|---|---|---|
| Last turn | 最後のユーザーメッセージ以降を応答として評価 | 特定ターンの回答品質を見たい |
| Full | 最初のユーザーメッセージ以降の全体を応答として評価 | タスク完了や全体の流れを見たい |
| Per-turn | 各ユーザー・アシスタントのやり取りを個別評価 | どのターンで崩れたかを分析したい |
たとえば、旅行予約エージェントで「日程確認」「ホテル検索」「予約候補提示」「最終確認」という複数ターンがある場合、Last turnだけを見ると最終回答は合格に見えることがあります。しかし、途中でユーザーの予算条件を無視していれば、FullやPer-turnで評価しないと問題を検出しにくくなります。
ワークフロー評価ではサブエージェント別の失敗を見つける
Microsoft Agent Frameworkでは、単一エージェントだけでなく、複数エージェントや関数を組み合わせたワークフローも扱います。公式ドキュメントでは、ワークフロー評価で全体出力に加えてサブエージェント別の内訳を評価できると説明されています。(Microsoft Learn)
たとえば、問い合わせ対応ワークフローが次のように分かれているとします。
| エージェント | 役割 |
|---|---|
| IntentAgent | 問い合わせ種別を判定 |
| SearchAgent | ナレッジベースを検索 |
| PolicyAgent | 社内規程との整合性を確認 |
| ResponseAgent | 最終回答を生成 |
この構成で最終回答が不正確だった場合、全体評価だけでは原因が分かりません。IntentAgentが分類を誤ったのか、SearchAgentが古い文書を拾ったのか、ResponseAgentが根拠を誇張したのかを切り分ける必要があります。
ワークフロー評価は、こうした複数エージェント構成の品質改善に向いています。特に本番運用では、失敗原因を「モデルが悪い」で片付けず、どの工程で期待とズレたかを特定できる設計が重要です。
Foundryポータルで評価する場合の設定ポイント
Microsoft Foundryポータルから評価を実行する場合、評価対象、データソース、フィールドマッピング、評価指標の選択が重要です。
公式ドキュメントでは、エージェント評価時にシステムプロンプトやユーザープロンプトを調整でき、ユーザープロンプトは既定で{{item.query}}を使ってデータセットのqueryをエージェントに渡すと説明されています。エージェントが会話履歴や構造化入力を期待する場合は、{{item.messages}}やカスタムJSONを使う選択肢があります。(Microsoft Learn)
設定時に確認すること
| 設定箇所 | 確認ポイント | 失敗例 |
|---|---|---|
| データソース | 代表的な業務データとエッジケースを含むか | 正常系だけで合格率が高く見える |
| フィールドマッピング | query、response、tool_definitionsなどが割り当たっているか | Required field未割り当てで評価失敗 |
| 評価スコープ | conversation評価かturn評価か | 会話全体を見たいのに単一ターンだけ評価する |
| 評価指標 | 目的に合うEvaluatorを選んでいるか | 回答品質だけ見てツール誤用を見逃す |
| Judge model | 評価用モデルのデプロイとクォータ | 評価が遅い、または失敗する |
| コスト | データ件数と評価指標数 | 評価対象を増やしすぎて費用が膨らむ |
Foundryポータルでは、会話評価ではmessages、単一ターン評価ではqueryとresponseが必要になるなど、評価スコープごとに必須フィールドが異なります。フィールドが未割り当てのままだと評価が失敗します。(Microsoft Learn)
CI/CDに組み込むときの注意点
Evaluationは、手動でたまに実行するだけでは効果が限定的です。プロンプト、ツール定義、モデル、RAGの参照データ、ワークフローのルーティングを変更したタイミングで、回帰テストとして実行するのが理想です。
Microsoft FoundryのGitHub Actionでは、Foundry Agentsのオフライン評価をCI/CDパイプライン内で実行し、本番リリース前に潜在的な問題を見つけられると説明されています。入力としてテストクエリのデータセットと評価器リストを渡し、エージェントを呼び出して評価を実行し、サマリーレポートを生成します。(Microsoft Learn)
ただし、公式ドキュメントではコストを抑えるために、すべてのコミットで評価を実行しないよう注意されています。CI/CDでは、軽量なローカル評価を頻繁に実行し、Foundryを使った重い評価はmainブランチへのマージ前、リリース候補作成時、夜間バッチなどに絞るのが現実的です。(Microsoft Learn)
おすすめの実行タイミング
| タイミング | 実行する評価 | 目的 |
|---|---|---|
| 開発者のローカル実行 | LocalEvaluator | 形式崩れや必須ツール漏れを早期発見 |
| プルリクエスト | 小規模データセットのローカル評価 | 明らかな退行を防ぐ |
| mainブランチへのマージ前 | Foundry評価の一部 | リリース前の品質確認 |
| リリース候補作成時 | Foundry評価フルセット | 品質・安全性・ツール利用を総合判定 |
| 本番後の定期実行 | 代表データと本番ログのサンプル評価 | ドリフトや品質低下の検出 |
管理者が確認すべき設定チェックリスト
Evaluationを導入する前に、管理者はAzureリソース、権限、データ管理、コストの観点で準備を進める必要があります。
| 確認項目 | 確認内容 |
|---|---|
| Azure AI Foundryプロジェクト | 評価を実行するプロジェクトが用意されているか |
| モデルデプロイ | 評価用のモデルデプロイ名を指定できるか |
| 認証 | Microsoft Entra IDやManaged Identityで安全に接続できるか |
| クォータ | 評価実行に必要なモデルクォータがあるか |
| ログとトレース | ツール呼び出しや会話履歴を評価に使える形で保存しているか |
| データ保護 | 評価データに個人情報や機密情報が含まれていないか |
| コスト管理 | 評価回数、データ件数、評価指標数を制御しているか |
| 権限分離 | 開発者、評価実行者、結果閲覧者の権限を分けているか |
| リージョン・ネットワーク | 利用リージョン、ネットワーク分離、接続制約を確認しているか |
Agent Frameworkの概要ドキュメントでは、サードパーティのサーバー、エージェント、コード、非Azure Directモデルを使う場合、データ共有、保持、場所、コンプライアンス境界を確認する責任があるとされています。Evaluationでは会話ログやツール結果を扱うため、この注意点は特に重要です。(Microsoft Learn)
開発者が確認すべき実装チェックリスト
開発者は、Evaluationを後から追加するのではなく、エージェント設計の段階から評価しやすい構成にしておくべきです。
| 確認項目 | 実装上のポイント |
|---|---|
| ツール名 | 評価データと実装でツール名を一致させる |
| 引数スキーマ | 型、必須項目、日付形式などを明確にする |
| 会話ログ | user、assistant、toolの役割を区別して残す |
| 期待値 | expected outputやexpected tool callsをテストデータに含める |
| プロンプト | システム指示を評価データに含めるか判断する |
| エラー処理 | ツール失敗時の応答も評価対象にする |
| バージョン管理 | プロンプト、ツール、評価データを同じ変更単位で管理する |
| カスタム評価 | 業務固有の合格条件を関数化する |
| 再現性 | 同じ入力で複数回実行し、非決定的な揺れを確認する |
Agent Frameworkでは、同じクエリを複数回実行して非決定的な挙動を検出するための反復評価も示されています。AIエージェントは同じ入力でも異なる経路を取ることがあるため、重要な業務では1回の成功だけで合格にしない設計が必要です。(Microsoft Learn)
失敗しやすいポイントと対策
Evaluation導入でよくある失敗は、評価指標を増やすこと自体が目的になってしまうことです。大切なのは、業務上のリスクに対応した評価を選ぶことです。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| 正常系だけで評価する | 本番の例外入力に弱い | エッジケース、権限外依頼、曖昧な依頼を入れる |
| 最終回答だけ評価する | ツール誤用を見逃す | Tool Call系の評価を追加する |
| 評価データを更新しない | 実業務とのズレが広がる | 本番ログから定期的に評価データを見直す |
| すべてクラウド評価にする | コストと時間が増える | ローカル評価とFoundry評価を分ける |
| 評価結果を絶対視する | LLM-as-judgeの誤判定に気付けない | 重要ケースは人手レビューを併用する |
| ツール対応制約を見ない | 評価値が期待通り出ない | 対象ツールとEvaluatorの対応状況を確認する |
| プロンプト変更だけを追う | ツール定義やRAG更新の影響を見逃す | プロンプト、ツール、データをまとめてバージョン管理する |
特に、業務自動化エージェントでは「回答が自然か」よりも「実行してよい操作だけを正しい順序で行ったか」が重要です。経費精算、予約、顧客情報更新、チケット操作など、外部システムに影響する処理では、Tool Input AccuracyやTask Adherenceのような評価を優先して検討しましょう。
まず取り組むべき導入手順
MicrosoftのEvaluationを導入するなら、最初から大規模な評価基盤を作る必要はありません。まずは、壊れると困る代表的なシナリオを少数選び、ローカル評価から始めるのが現実的です。
| 手順 | やること | 成果物 |
|---|---|---|
| 1 | 評価したい業務シナリオを3〜5件選ぶ | 代表ユースケース一覧 |
| 2 | 正常系、異常系、曖昧な依頼を作る | 評価データセット |
| 3 | 必須ツール、期待出力、禁止事項を定義する | expected output / tool calls |
| 4 | LocalEvaluatorで軽量チェックを作る | 開発・CI用テスト |
| 5 | Azure AI Foundry evaluatorsで品質・安全性を確認する | リリース判定用評価 |
| 6 | 評価結果を見てプロンプト、ツール定義、ワークフローを修正する | 改善履歴 |
| 7 | 本番ログから評価データを定期更新する | 継続的な品質改善サイクル |
最初の評価データセットは大きくなくても構いません。むしろ、最初は「このエージェントが絶対に間違えてはいけない処理」に絞るべきです。たとえば、社内規程を答えるエージェントなら、古い規程を参照しない、根拠がない場合は断定しない、担当部署への確認を促す、といった評価条件が重要になります。
まとめ：MicrosoftのEvaluationは「AIエージェントを安全に運用するための品質ゲート」
MicrosoftのEvaluationは、AIエージェントの回答を後から眺めるための機能ではなく、開発、テスト、リリース、本番監視に組み込むべき品質ゲートです。
開発者は、LocalEvaluatorで素早く壊れ方を検出し、Azure AI Foundry evaluatorsで本番相当の品質・安全性・ツール利用を評価します。管理者は、Azure AI Foundryプロジェクト、モデルデプロイ、権限、クォータ、コスト、データ保護を確認します。QAやセキュリティ担当者は、正常系だけでなく、例外、曖昧な依頼、危険な入力、権限外操作を評価データに含める必要があります。
次に取るべき行動は明確です。まず、現在のエージェントで「失敗すると業務影響が大きいシナリオ」を3つ選び、query、期待する回答、期待するツール呼び出しを評価データとして書き出してください。そのうえで、ローカル評価をCIに組み込み、リリース前にAzure AI Foundryで品質・安全性・ツール利用を確認する流れを作ることが、Microsoft Agent Framework時代の現実的なEvaluation運用です。
コメント