Azure AI FoundryでAIエージェントを運用しているチームにとって、今回のポイントは「エージェントの良し悪しを、自社の業務ルールに合わせて採点しやすくなる」ことです。2026年6月4日ごろに公開・更新されたAzure Updatesでは、Microsoft FoundryにRubric evaluatorがパブリックプレビューとして追加され、単一ターンと複数ターンのエージェントフローの品質評価に使えることが示されています。(マイクロソフト Azure)
Rubric evaluatorは、一般的な文章品質だけでなく、「予約条件を守ったか」「必要な確認を省略していないか」「正しいツールを正しい引数で呼び出したか」といった、業務ごとの評価基準を重み付きで定義できる評価機能です。すぐ本番の合否判定に使うというより、まずは既存の評価データやトレースでスコアの妥当性を検証し、プロンプト改善・リリース判定・運用品質監視に段階的に組み込むのが現実的です。
Azure AI FoundryのRubric evaluatorは何が変わるのか
Rubric evaluatorは、LLMを評価者として使い、開発者が定義したカスタムの重み付き基準に対して、エージェントまたはモデルの応答をスコア付けする機能です。Microsoft Learnでは、ルーブリックを「応答を評価する方法を定義する一連の条件」と説明しており、各条件には測定内容を示す説明と重みを設定できます。各ディメンションは1〜5で採点され、全体スコアは加重平均として0〜1に正規化されます。(Microsoft Learn)
従来の評価では、Coherence、Fluency、Groundedness、Relevance、安全性、ツール呼び出し精度など、あらかじめ用意された評価指標を使う場面が中心でした。これらは汎用的な品質確認には有効ですが、実務では「この業務では何を守れば合格か」をそのまま表現しにくいことがあります。Microsoft Foundryには品質・安全性・信頼性を評価する組み込みエバリュエーターがあり、RAG、リスク、安全性、エージェント固有の評価などをカバーしています。(Microsoft Learn)
Rubric evaluatorの追加により、評価軸をチーム側で具体化できます。たとえば社内ヘルプデスクエージェントなら、「権限外の操作を案内しない」「社内規程に沿って回答する」「必要な確認事項を先に聞く」「利用者に次の操作を明確に示す」といった基準を作り、重要度の高いものに大きな重みを付けられます。
なお、Microsoftのドキュメントでは、AIプラットフォームの名称がAzure AI StudioからAzure AI Foundry、さらに現在のMicrosoft Foundryへ進化していると説明されています。Azure AI Foundry関連の記事や画面で名称が混在して見える場合がありますが、今回の更新はMicrosoft Foundryの評価・オブザーバビリティ領域の機能として理解すると整理しやすくなります。(Microsoft Learn)
Rubric evaluatorでできること
Rubric evaluatorで特に重要なのは、評価の観点を「抽象的な品質」から「業務上の合否」に近づけられる点です。
| できること | 実務での意味 | 例 |
|---|---|---|
| 評価基準をカスタム定義する | 自社の業務ルールや応対ポリシーを評価に反映できる | 「返品期限を超えた返品を承認しない」 |
| 各基準に重みを付ける | 重要な失敗を軽い文章ミスより重く扱える | 「法令・規程違反」を最重要にする |
| 単一ターンと複数ターンを評価する | FAQ型の1問1答だけでなく、対話型エージェントも評価できる | 予約、問い合わせ、申請受付の会話全体を評価 |
| 理由付きのスコアを返す | どの観点で失敗したかを改善に使える | 「必要な確認をせずツールを実行した」 |
| 継続評価に組み込む | 運用中の品質低下を検知しやすくなる | プロンプト更新後の品質回帰を検出 |
Microsoft Learnでは、Rubric evaluatorは汎用エバリュエーターでは捉えにくいドメイン固有・組織固有の品質基準に適していると説明されています。カスタマーサポートのトーン、医療の正確さ、法的コンプライアンスなど、チーム固有の基準を反映したスコアリングが必要な場合に有効です。(Microsoft Learn)
既存の評価機能との違い
Rubric evaluatorは、既存の組み込みエバリュエーターを置き換えるものではありません。むしろ、組み込み評価と組み合わせて使う機能です。
| 評価の種類 | 向いている確認 | Rubric evaluatorとの関係 |
|---|---|---|
| Coherence / Fluency | 文章の一貫性、自然さ、読みやすさ | 基本的な文章品質を補完 |
| Groundedness / Relevance | RAG回答が根拠に基づいているか、質問に合っているか | ナレッジ参照型エージェントで併用 |
| Safety evaluator | 有害表現、機密情報、禁止行為などのリスク | 安全性評価として別途必須に近い |
| Tool / Agent evaluator | ツール呼び出しやタスク完了度 | エージェントの動作確認に有効 |
| Rubric evaluator | 自社固有の合格基準、業務ルール、応対方針 | 「この業務で良い応答とは何か」を定義 |
たとえば、RAGを使った社内規程検索エージェントでは、Groundednessで「根拠に基づく回答か」を見ながら、Rubric evaluatorで「社内規程上、断定してよい内容か」「人事・法務へのエスカレーションが必要なケースを見逃していないか」を評価します。これにより、単に正しそうな回答ではなく、業務で使える回答かどうかを判断しやすくなります。
影響を受ける対象者
今回のPublic Previewで直接影響を受けるのは、Azure AI FoundryまたはMicrosoft Foundry上でエージェントや生成AIアプリの評価・監視を行うチームです。既存エージェントの実行結果が自動的に変わる機能ではありませんが、評価・改善・リリース判定の設計には影響します。
| 対象者 | 確認すべきこと |
|---|---|
| AIエージェント開発者 | 評価したい失敗パターンをルーブリックに落とし込めるか |
| プロンプトエンジニア | プロンプト変更前後でスコアを比較できる評価データがあるか |
| Azure管理者 | Foundryプロジェクト、RBAC、Application Insights、Log Analyticsの権限が足りているか |
| QA担当者 | 人間の評価とRubric evaluatorのスコアが大きくズレていないか |
| 業務部門 | 「合格応答」「不合格応答」の基準を具体化できているか |
| 運用担当者 | 継続評価の頻度、サンプリング、コスト上限を決めているか |
特に重要なのは、業務部門を早い段階で巻き込むことです。開発チームだけでルーブリックを作ると、文章の自然さや技術的な正しさに偏りがちです。実際には「問い合わせ履歴を確認せずに回答してはいけない」「本人確認が済むまで契約情報に触れない」「例外時は有人窓口へ誘導する」といった業務上の制約こそ、評価基準に入れるべきです。
管理者が確認すべき設定と権限
Rubric evaluatorを使う前に、管理者は評価そのものよりも、プロジェクト、権限、監視データの扱いを確認する必要があります。
Microsoft Learnの評価実行手順では、Foundryポータルから評価を実行する前提として、Azureサブスクリプション、Microsoft Foundryプロジェクト、評価対象に応じたエージェント・モデル・データセット、AI支援品質評価に使うGPTモデルのデプロイ、Foundryプロジェクト上のFoundry Userロールが挙げられています。(Microsoft Learn)
また、Foundryの権限はARMコントロールプレーンとFoundryデータプレーンに分かれており、OwnerやContributorだけではエージェント作成や操作などのデータプレーン権限を持たない場合があります。エージェント作成や操作にはFoundry User、Foundry Project Manager、Foundry OwnerなどのFoundry側ロールが必要です。(Microsoft Learn)
管理者向けチェックリスト
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| Foundryプロジェクト | 評価対象のエージェントやデータセットが同じプロジェクトで扱えるか | 評価対象を選べない、結果を集約できない |
| RBAC | 評価を作成・実行するユーザーにFoundry側の適切なロールがあるか | Azure Ownerなのに評価操作ができない |
| GPTモデル接続 | LLM-as-judgeに使うモデルが利用可能か | 評価実行時に失敗する |
| Application Insights | トレースや運用データを収集できているか | 実運用に基づく評価ができない |
| Log Analytics権限 | 評価機能や運用監視が必要なログを読めるか | トレース評価やダッシュボード確認が不十分になる |
| コスト管理 | 評価回数、対象件数、サンプリング率を決めているか | 評価用の推論コストが膨らむ |
| データ保護 | 参照ファイルやトレースに機密情報が含まれるか | 評価用データの取り扱いが曖昧になる |
Hosted agent関連の権限リファレンスでは、評価機能を使う場合、プロジェクトのマネージドIDにLog Analyticsワークスペースを読むための権限が必要になるケースが示されています。また、Application Insightsのトレースやログを見るには監視系の読み取り権限も関係します。(Microsoft Learn)
開発者が押さえるべきルーブリック設計のコツ
Rubric evaluatorは、評価基準を作れること自体が価値ですが、基準の書き方が曖昧だとスコアも曖昧になります。最初から完璧なルーブリックを作るのではなく、小さな評価セットで人間の判断と比較しながら調整するのが安全です。
Microsoft Learnでは、ルーブリックを自動生成する方法として、既存のFoundryエージェント、エージェントのシステムプロンプト、参照ファイルを入力にでき、さらに運用トレースを加えると実際の利用状況に基づいたルーブリックにしやすいと説明されています。ただし、トレース単独では使えず、エージェント、システムプロンプト、参照ファイルのいずれかと組み合わせる必要があります。(Microsoft Learn)
ルーブリック設計の実例
社内ITヘルプデスクエージェントを例にすると、次のようなディメンションが考えられます。
| ディメンション | 重みの例 | 合格に近い応答 | 失敗しやすい応答 |
|---|---|---|---|
| intent_recognition | 8 | パスワードリセット、端末故障、権限申請などの意図を正しく分類する | 「ログインできない」をすべてパスワード忘れとして扱う |
| policy_compliance | 9 | 本人確認や承認フローが必要な操作を勝手に進めない | 管理者権限付与を即時案内する |
| information_gathering | 6 | OS、端末種別、エラー表示、発生時刻など必要情報を聞く | 情報不足のまま解決策を断定する |
| tool_usage_accuracy | 7 | チケット作成やナレッジ検索を必要な場面で正しく使う | 不要なチケットを作る、検索せずに回答する |
| communication_clarity | 4 | 次に何をすればよいかを手順で示す | 専門用語だけで説明する |
| escalation_judgment | 8 | セキュリティ事故や権限変更は適切に有人対応へ回す | 危険なケースを自己解決させる |
このように、重みは「失敗したときの業務影響」で決めると実用的です。文章が少し硬いだけなら重みは低めでよい一方、セキュリティやコンプライアンスに関わる項目は高く設定します。
評価を始める手順
Rubric evaluatorを導入する際は、機能を有効化することよりも、評価設計を先に固めることが大切です。次の順序で進めると、評価結果を改善活動に使いやすくなります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | 評価したい失敗パターンを集める | 過去の問い合わせ、失敗会話、レビューコメント |
| 2 | 合格応答と不合格応答を定義する | 人間が見ても納得できる判定基準 |
| 3 | ルーブリックを自動生成または手動作成する | ディメンション、説明、重み |
| 4 | 小さなデータセットで試す | 20〜50件程度の初期評価結果 |
| 5 | 人間の評価とズレる項目を修正する | 説明文、重み、しきい値の調整 |
| 6 | プロンプトやツール定義の改善に使う | 改善前後の比較結果 |
| 7 | CI/CDや継続評価に段階展開する | リリース判定や運用品質監視 |
Microsoft Learnでは、生成または作成したルーブリックについて、id、description、weightを編集し、ディメンションの追加・削除、しきい値の調整、常に適用する条件の設定ができると説明されています。大規模に使う前に、小さな評価を実行してスコアが自分たちの判断と一致するか検証することも推奨されています。(Microsoft Learn)
しきい値とスコアの見方
Rubric evaluatorは、各ディメンションのスコア、全体スコア、合格・失敗ラベル、判定理由を返します。公式ドキュメントの例では、既定のパスしきい値は0.5で、しきい値以上のスコアが合格と見なされます。(Microsoft Learn)
ただし、0.5をそのまま本番の合否基準に使うのは避けた方がよいでしょう。社内FAQのようにリスクが低い用途では低めのしきい値でも運用できますが、法務、医療、金融、セキュリティ、個人情報を扱うエージェントでは、より厳しい基準が必要です。
| 用途 | しきい値設計の考え方 |
|---|---|
| 社内ナレッジ検索 | まずは0.5〜0.7程度で傾向を見る |
| カスタマーサポート | 誤案内の影響が大きい項目は高めに設定 |
| 申請・予約・業務処理 | ツール利用や業務ルール違反を重く見る |
| 法務・規制関連 | Rubricだけでなく人間レビューと安全性評価を併用 |
| セキュリティ関連 | 低スコア時の自動ブロックより、まずアラートとレビューで検証 |
しきい値は「高ければ高いほどよい」ものではありません。高すぎると、実務上問題ない応答まで失敗扱いになり、改善対象が増えすぎます。最初は人間のレビュー結果と突き合わせ、誤検知と見逃しのバランスを見ながら調整するのが現実的です。
LLM-as-judgeのコストと信頼性に注意する
Rubric evaluatorはLLM-as-judge方式で評価を行うため、評価呼び出しごとにモデル推論コストが発生します。Microsoft Learnでも、評価呼び出しごとにモデル推論コストが発生すること、応答が非常に短い場合はスコアリングの信頼性が異なる可能性があること、具体的で明確なルーブリック説明がスコアリングの一貫性向上に役立つことが示されています。(Microsoft Learn)
コストを抑えるには、すべての会話を常時評価するのではなく、まずは次のように対象を絞るとよいでしょう。
| コスト対策 | 実装イメージ |
|---|---|
| サンプリングする | 本番トラフィックの一部だけを評価する |
| 重要フローに限定する | 申請、予約、権限変更、購入前相談などを優先 |
| 失敗候補を優先する | 低評価フィードバック、長時間会話、ツール失敗後の会話を評価 |
| 定期バッチにする | 毎日または毎週、代表データで評価する |
| 評価モデルを見直す | 精度とコストのバランスを確認する |
モデル選択も重要です。公式ドキュメントでは、ルーブリックジャッジに使うモデルの推奨が示されており、gpt-4o-miniは推奨されず、コストとパフォーマンスのバランスにはgpt-5.4-miniを使う旨が記載されています。ただし、利用可能なモデルやリージョン、名称は変わる可能性があるため、実際の導入時には自社テナントのFoundryポータルと最新ドキュメントで確認してください。(Microsoft Learn)
継続評価に組み込むときの注意点
Rubric evaluatorは、単発のテストだけでなく継続評価にも使えます。Microsoft Learnでは、ルーブリックが品質基準を反映していることを確認した後、モニター設定で継続的またはスケジュールされた評価に構成できると説明されています。新しいエージェントトラフィックに対して自動的にルーブリックを実行し、手動実行なしで本番環境の品質回帰を検知する用途が想定されています。(Microsoft Learn)
ただし、Public Previewの段階では、継続評価をいきなり本番の自動停止やリリースブロックに使うのは慎重に判断すべきです。まずはアラート、ダッシュボード、週次レビューのような「観測」に使い、スコアの安定性を確認してから品質ゲートへ進める方が安全です。
移行・展開で失敗しやすいポイント
今回の機能は、既存エージェントの動作を直接変更するものではありません。そのため「移行作業」というより、評価設計と運用プロセスへの追加が中心です。ただし、評価をCI/CDや運用品質監視に組み込む場合は、実質的に開発フローが変わります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| ルーブリックが抽象的 | スコアが安定せず、改善に使えない | 「正確」「適切」だけでなく、何を満たせばよいかを書く |
| 重みが均等すぎる | 重大な業務違反と軽微な表現ミスが同列になる | 事業リスクに応じて重みを変える |
| サンプルデータが少ない | 実運用で想定外の低スコアが出る | 成功例、失敗例、境界例を混ぜる |
| 単一ターンだけで評価する | 複数ターンの確認漏れや文脈ミスを見逃す | 会話全体を評価対象にする |
| 組み込み安全性評価を外す | 有害表現や機密情報漏えいの検知が弱くなる | Safety evaluatorやRAG評価と併用する |
| 評価コストを見積もらない | 継続評価で想定外の費用が発生する | サンプリング率と評価頻度を決める |
| 権限設計を後回しにする | 開発者やQAが評価結果・トレースを見られない | Foundryロールと監視系権限を事前確認する |
特に避けたいのは、ルーブリックを「開発チームの主観メモ」にしてしまうことです。評価基準は、プロンプト、ツール定義、テストデータと同じくバージョン管理の対象にするべきです。エージェントのプロンプトを変更したら、同じ評価セットで前後比較し、どのディメンションが上がったか、どのディメンションが下がったかを確認します。
Public Previewとしての扱い
Rubric evaluatorはPublic Previewの機能です。Microsoft Learnでは、プレビュー機能はSLAなしで提供され、運用環境のワークロードには推奨されず、特定の機能がサポートされない、または制限される可能性があると説明されています。(Microsoft Learn)
そのため、現時点でのおすすめは次の使い方です。
| フェーズ | おすすめの使い方 |
|---|---|
| 検証初期 | 既存の会話ログやテストデータでスコアの妥当性を見る |
| 開発中 | プロンプト改善、ツール定義改善、モデル比較に使う |
| リリース前 | 代表シナリオで品質回帰がないか確認する |
| 本番運用初期 | サンプリング評価とダッシュボード監視に使う |
| 本格運用前 | SLA、制限、対応リージョン、社内リスク基準を確認する |
Previewだから使わない、ではなく「本番の最終判定に単独で使わない」と考えるのが現実的です。特にエージェント開発では、評価基準を早めに作るほど改善の方向性が明確になります。Public Previewの段階でも、評価データの整備やルーブリックの試作を進める価値はあります。
管理者・開発者が今すぐ確認すべきこと
最後に、Azure AI Foundryでエージェントを開発・運用しているチームが確認すべき項目を整理します。
| 優先度 | 確認項目 | 具体的なアクション |
|---|---|---|
| 高 | 評価対象のエージェント | 単一ターンか複数ターンか、ツール利用があるかを整理する |
| 高 | 業務上の合格基準 | 業務部門と「良い応答」「悪い応答」の例を集める |
| 高 | 権限 | Foundry Userなどのデータプレーン権限、監視ログ閲覧権限を確認する |
| 高 | 評価データ | 成功例、失敗例、境界例を含むデータセットを作る |
| 中 | ルーブリック | 自動生成をベースに、説明と重みを手動調整する |
| 中 | しきい値 | 既定値を鵜呑みにせず、人間の評価と比較して決める |
| 中 | コスト | 評価モデル、評価頻度、サンプリング率を決める |
| 中 | 継続評価 | まずは観測用途で開始し、安定後に品質ゲート化を検討する |
| 低 | 命名・ドキュメント | Azure AI Foundry / Microsoft Foundryの名称差分を社内手順に反映する |
Rubric evaluatorは、AIエージェントの評価を「なんとなく良い」から「この業務基準を満たしている」に近づける機能です。まずは既存エージェントの代表シナリオを選び、業務ルール、ツール利用、確認漏れ、回答の明確さをルーブリック化してください。そのうえで、小さなデータセットで人間の判断と照合し、スコアが納得できる状態になってから継続評価やリリース判定へ広げるのが安全です。
コメント