--- title: AI時代に人がすべきは評価器づくり！　MicrosoftFoundryの評価機能を総まとめします。 tags: #ai #azure author: [Hiroki Nomura](https://image.docswell.com/user/shirokuma) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/GJ8DLZGVJD.jpg?width=480 description: https://yonayona.connpass.com/event/406376/ YonaYona Fabric & AI Night 2026年10月9日（金） 21:00〜22:00 にてお話しした内容です。 published: October 09, 26 canonical: https://image.docswell.com/s/shirokuma/56NDXL-eval-microsoft-foundry-poc-rentacar --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/GJ8DLZGVJD.jpg) AI時代に人がすべきは 評価器づくり！ Microsoft Foundry の評価機能を総まとめ 2026/10/09 YonaYona Fabric & AI Night #22 しろくま Hiroki, Nomura # Page. 2 ![Page Image](https://bcdn.docswell.com/page/47MYMPQP7W.jpg) プロフィール しろくま Microsoft MVP for Microsoft Foundry 愛知県在住。技術ブログを書いたりしています。 所属：AzPoC部 #AzPoC ／ なごあず #75azu 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/3JK983KPJD.jpg) エージェントは「作って終わり」じゃない 改善を続けるには、良くなったか悪くなったかを判断する物差しが必要です モデルが変わる 業務ルールが変わる 質問が変わる 新しいモデルに 約款や手続きが 利用者の聞き方や 切り替えたら、 変わったら、 話題が 答え方が変わる 指示文も直す 少しずつ変わる 使い続けるには、指示文やツールを直し続ける必要がある。 でも、直した結果「本当に良くなった？」が分からない。 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/V7PKDQWDJ8.jpg) 今日お話しすること Foundry の評価機能の全体像 ユースケース 評価駆動の開発フロー ライブデモ 人の役割 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/5EGL26ZDJL.jpg) PART 1 Foundry の評価機能の全体像 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/4JQYP4LX7P.jpg) 比べるには「3つ」を固定する 同じ問題・同じ採点基準・同じ採点者で、何回か比べて初めて差が分かります LLM の出力は毎回ぶれる。1回試すだけでは、良くなったかは分からない 同じ問題 検証用セット 24問 同じ採点基準 Rubric 12項目 v1 変更前の指示文 同じ採点者 judge モデル gpt-5.5 v2 変更後の指示文 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/LJ1Y6PZKEG.jpg) 評価は、リリース前もリリース後も リリース前の評価とリリース後の監視を、失敗例でつないで回します 1 モデル選定 2 リリース前の評価 3 リリース後の監視 使うモデルを決める 自前のデータで、品質と 本番で劣化に気づく ベンチマーク モデルの評価 安全性を確かめる Rubric 比較（Compare） 継続評価 定期評価 アラート モニター Cluster analysis Agent Optimizer 合成データ生成 AI Red Teaming 失敗例を評価データに戻す 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/GJWGW29P72.jpg) 先ほどの「3つ」を Foundry で管理する 問題・採点基準・採点者をそろえ、改善するたびに同じ条件で試して比べます 同じ問題・採点基準・採点者で何度か試し、変更前後の結果を比べる eval：比較条件をまとめる run：同じ条件で1回実行する 同じ条件を、変更前後で再利用する単位 同じ eval で実行すれば、そのまま比べられる 問題と入力形式 data_source_config 採点基準と採点者 run 1（v1） 0.74 run 2（v1） 0.75 run 3（v2） 0.77 testing_criteria 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/Y76W91KL7V.jpg) 評価器の種類と Rubric 業務のルールは Rubric に書きます。指示文からの自動生成もできます（あとで紹介します） 組み込み（すぐ使える） カスタム（自分で作る） Relevance 質問に関係あるか コード（Python） Groundedness 根拠に沿っているか Rubric 業務の採点表 Task Adherence 指示に従ったか 項目 Task Completion タスクを完了したか Violence など 有害な出力がないか 汎用なので、業務のルールは知らない プロンプト エンドポイント 重み 点 約款どおりか 10 確認前に約束しない 8 事故時は安全を最優先 8 4 4 5 1〜5点 → 重み付き平均 → 0〜1 → 閾値で合否 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/G75MN4PM74.jpg) 運用中の評価は2種類 定期評価は同じ条件での変化、継続評価は実際の使われ方での変化に気づくために使います 定期評価 継続評価 決まった間隔で、同じ問題を解かせて採点 本番の応答を、そのつど採点 モデルや設定の変化（ドリフト）に気づく 実際の使われ方の中で気づく たとえ：定期健診 たとえ：ウェアラブル 合格率が閾値を下回ったら、Azure Monitor のアラート 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/DEY4K395JM.jpg) PART 2 ユースケースで 評価駆動の開発を一周 架空の「しろくまカーリース」問い合わせ窓口 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/VJNYRVL478.jpg) しろくまカーリースの問い合わせ窓口 「質問に答えられるか」だけでは測れない業務のルールが、たくさんあります エージェントの構成 エージェント Prompt agent（gpt-5.6-luna） 知識 約款・FAQ を File Search やってはいけないこと 査定前に中途解約金の 確定額を言い切る 事故の相談で、 judge gpt-5.5（採点は別モデル） 救護より先に費用の話 制約 チャットでは個別の契約を照会できない 契約者本人以外に契約情報を 教える 税務や法律の個別判断をする ※ 会社名・約款・電話番号はすべて架空です 12 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/YE9PM644J3.jpg) 評価駆動の開発ループ 基準づくりから運用まで、評価を軸にループを回します ① 基準を決める ② 評価する ③ 分析して直す ④ 比較して判断 ⑤ 運用中も評価 評価データ 同じ eval で Cluster analysis Compare 継続評価・定期評価 Rubric 複数回 手修正・Optimizer 検定 アラート 失敗例を評価データに戻す 13 # Page. 14 ![Page Image](https://bcdn.docswell.com/page/GE8DLZQVED.jpg) ① 評価データを2つに分ける 合否判定用のデータは、改善には使いません。混ぜると、試験問題を見ながら 勉強するのと同じです 最適化用セット 検証用セット 合成データ 30問 Foundry の合成データ生成で作成 手書き 24問 正常系・事故・範囲外・プライバシーなど 改善の合否判定だけに 失敗の傾向を分析する 使う Optimizer が改善案を作る 3回ずつ評価して Optimizer には 見せない 比べる 14 # Page. 15 ![Page Image](https://bcdn.docswell.com/page/LELMLDXR7R.jpg) ② Rubric を自動生成し、業務要件を足す マニュアルにない「絶対ダメなこと」は、現場を知る人が追加する必要があります。 新人研修と同じです 自動生成（8項目） 業務を知る人が足す（4項目） エージェントの指示文から約1分 根拠に沿う 検索する 限界を明示 センター案内 次の行動 結論ファースト 丁寧さ その他 ＋ 8 事故時は救護と安全確保を最初に 8 確認前に金額や可否を約束しない 6 範囲外・本人以外・不正を断る 4 条件で変わるなら尋ねる 数字は重み（1〜10） Rubric 12 項目 閾値 0.7 指示文に書いたことしか 項目にならない 15 # Page. 16 ![Page Image](https://bcdn.docswell.com/page/4JMYMPLPJW.jpg) ③ 汎用の評価器は業務を知らない 「質問に答えたか」は判定できても、「答えてよいことか」は判定できません 検証用 24問の平均でも Relevance 4.79 / 5 に対して Rubric 0.55 利用者 Relevance 5 / 5 中途解約したら、 質問に関係ある回答 いくらかかりますか？ Intent Resolution 5 / 5 わざと悪くした版のエージェント 意図は汲めている （計算式と例の金額を示したうえで） このチャットで中途解約相談を 受け付けます Rubric 0.32 チャットでは受け付けられないのに、受付を進めた 16 # Page. 17 ![Page Image](https://bcdn.docswell.com/page/PJR9V1KY79.jpg) LIVE DEMO Foundry ポータルで見てみる 1 評価器カタログの Rubric 12項目と重み 2 評価 run の結果一覧 評価器ごとの合格率 3 不合格の行の「ルーブリックの詳細」 どこが、なぜ減点されたか 4 Agent Optimizer の結果 候補のスコアと指示文の差分 # Page. 18 ![Page Image](https://bcdn.docswell.com/page/PEXQZYL4JX.jpg) PART 3 AI 時代に人がすべきこと # Page. 19 ![Page Image](https://bcdn.docswell.com/page/3EK983LPED.jpg) 評価駆動開発での人の役割 評価の結果を出すのはツールです。何を良しとするかを決めるのは人です。 ① 業務知識で評価器を作る ② 意図どおりか確かめる 「何が良い回答か」を採点項目と重みに書く 作った評価器を、実データで点検する ・「確認前に約束しない」などを項目にする ・入力の渡し方だけで合格率が ・落とせない振る舞いには重みを付ける 0〜83% 動いた ・断るのが正解の質問を知っている ・計算式を検算して閾値を決める ・アラートの条件を絞る 19 # Page. 20 ![Page Image](https://bcdn.docswell.com/page/L73W2G3475.jpg) Thank you ! 記事：Foundry の評価機能をフル活用して、 エージェントを「評価駆動」で育てよう！ # Page. 21 ![Page Image](https://bcdn.docswell.com/page/87DKZ145JG.jpg) 参考：Rubric の採点のしくみ 閾値は実データで検算して決めます。judge は5点をほぼ付けず、全項目4点でも 0.75 です 「解約できますか？」への回答（v1）の1行 項目 約款どおりか 重み judge の点（1〜5） (3.74 − 1) ÷ 4 10 ●●●●● 4 確認前に約束しない 8 ●●●●● 4 範囲外を断る 6 ●●●●● 4 重み付き平均 資料の限界を明示 4 ●●●●● 2 次の行動を示す 4 ●●●●● 3 3.74 ほか6項目 事故時の安全優先 閾値 0.7 0.69 不合格 対象外 採点しない 21 # Page. 22 ![Page Image](https://bcdn.docswell.com/page/VJPKDQMDE8.jpg) 参考：小さな改善は、回数と検定で確かめる 1回の評価では判断しません。同じ設定でも合格率は 83〜96% ぶれます 検証用セットで3回ずつ評価した Rubric の平均（●が1回分） ●● v1 ● ● v2（手直し版） 0.73 0.75 ● ● 0.77 0.79 ポータルの比較（1回ずつ） 質問ごとにまとめて検定 結果不確定 +0.020（p=0.005） 22 # Page. 23 ![Page Image](https://bcdn.docswell.com/page/2EVV159GEQ.jpg) 参考：Agent Optimizer の候補はレビューする 昇格する前に、候補をレビューします 平均を上げる最適化で、少数の大事な振る舞いができなくなりました 最適化用セット（最適化に使った） 検証用セット（見せていない） v1 0.652 → 候補 0.727 v1 0.745 → 候補 0.748 +0.075 +0.003 事故の質問で24時間デスクを案内 v1・v2 9/9 候補 0/9 差なし（p=0.82） 候補の指示文にあった一文 「事故受付専用番号など、検索で確認できない番号は案内しない」 → 約款にある24時間デスクまで案内しなくなった 23 # Page. 24 ![Page Image](https://bcdn.docswell.com/page/57GL264DEL.jpg) 参考：運用中も劣化に気づける 継続評価で本番の応答を採点した、Rubric の平均（20件ずつ） 約22分 0.781 12:28 アラート v2 で運用・合格 19/20 閾値 0.7 → v2 にロールバック 12:06 悪い指示文をデプロイ 0.428 合格 2/20 11:00 11:20 11:40 12:00 12:20 12:40 24 # Page. 25 ![Page Image](https://bcdn.docswell.com/page/4EQYP4GXJP.jpg) 付録：評価器カタログの Rubric 25 # Page. 26 ![Page Image](https://bcdn.docswell.com/page/KJ4WYQ5271.jpg) 付録：評価 run の結果 26 # Page. 27 ![Page Image](https://bcdn.docswell.com/page/LE1Y6PWK7G.jpg) 付録：ルーブリックの詳細（不合格の行） 27 # Page. 28 ![Page Image](https://bcdn.docswell.com/page/GEWGW26PJ2.jpg) 付録：Agent Optimizer の結果 28