---
title: 20260925_作れたやん。ほんで、その次は？ Microsoft Foundry で AI エージェントの改善ループにDeep Dive!_すきやねんAzure#42
tags:  #azure #microsoft #クラウド #foundry #評価  
author: [Naoki Matsumoto](https://image.docswell.com/user/chips0711)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/2JVV6VY3JQ.jpg?width=480
description: すきやねんAzure #42 https://sukiyanenazure.connpass.com/event/403967/ での登壇スライドです。  ※⚠️免責事項・注意事項 本資料に関して: 本資料の内容は発表者個人の見解・経験に基づくものであり、所属組織の公式見解や意見を代表するものではありません｡記載されている技術情報、事例、統計データ等は発表時点（2026年9月25日時点）のものであり、最新の情報については公式ドキュメントをご参照ください｡本資料の内容は参考情報として提供しており、実際のシステム設計・開発・運用における意思決定は、各自の責任において最新の公式情報を確認の上行ってください｡ 特定の企業名・サービス名・数値等は公開情報に基づいて記載していますが、詳細については各社の公式発表をご確認ください｡本資料の使用により生じたいかなる損害についても、発表者は一切の責任を負いません｡
published: September 25, 26
canonical: https://image.docswell.com/s/chips0711/KX2D8Y-20260925-sukiyanenazure42-foundry-eval-optimize-deepdive
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/2JVV6VY3JQ.jpg)

すきやねん Azure!! #42
作れたやん。ほんで、その次は？
Microsoft Foundry で
AI エージェントの改善ループに Deep Dive!
2026年9月25日
日本マイクロソフト株式会社
AI App Solution Engineer
Naoki Matsumoto


# Page. 2

![Page Image](https://bcdn.docswell.com/page/5EGLNL9YJL.jpg)

Conditions and terms of use
© Microsoft Corporation. All rights reserved.
Microsoft, Windows and other product names are or may be registered trademarks and/or trademarks in
the U.S. and/or other countries. The information herein is for informational purposes only and represents
the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must
respond to changing market conditions, it should not be interpreted to be a commitment on the part of
Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this
presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN
THIS PRESENTATION.
本資料は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点でのマイクロソフトの見解
を示したものです。状況等の変化により、内容は変更される場合があります。マイクロソフトは、本資料の情報に対して明
示的、黙示的または法的な、いかなる保証も行いません。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4JQYQYW67P.jpg)

Microsoft Foundry：2026年9月のアップデート
モデル選択・実行・統制の機能が広がり、本番トレースから品質・応答時間・コストを継続的に見直せます。
01 開発・実行の選択肢を広げる [1]
02 実行履歴を次の改善判断へ [2]
用途に合うモデルを選ぶ
本番トレースを Application Insights に記録
GPT-6ファミリー／Claude Opus 5.5。既存の業務データ・Tool・統制を活かし比較
初回は直近7日を分析し、その後はオンデマンドで調査
音声・長時間の業務を同じ基盤で動かす
Insights in Foundry
公開プレビュー
音声エージェント プロンプト型・ホスト型。既存の知識／Toolを再利用し、Web・
Teams・Teams Phone・Twilioへ展開
ホスト型は中断後も継続。Agent Frameworkがチェックポイント
長時間・回復
からの再開を支援
必要なToolを探し、連携・起動を共通化
Toolboxes
公開プレビュー
発見
Tool失敗・出力品質・文脈処理・遅延・不要なトークン消費
根拠
重要度・対象バージョン・代表トレース・原因候補
提案
指示やコードの修正、調査・対処の方針
想定外の問題も分析。分析品質はトレース記録の充実度に依存
Toolと手順をオンデマンドで提供
ホスト型 一般提供
プロンプト型 公開プレビュー
開発者が根拠を確認し、直接修正・評価追加・担当へ連携
一般提供
評価・最適化で改善効果を検証
Agent-to-Agent 標準プロトコルで他のエージェントと連携
一般提供
Rubric evaluator
要件から測定できる成功基準を定義
Routines
一般提供
評価データ生成
実行履歴・合成データからテスト用データを作成
Agent optimizer
指示・Tool・Skill・モデルの変更候補を比較
Tool search
全定義を先読みせずToolを検索
定期・遅延・イベントに応じて実行
開発環境：Foundry Toolkit（Visual Studio Code）／Foundry dev pack
9月中に一般提供予定
03 共通の統制で実行に反映 [1]
ID・ライフサイクル
Microsoft Entra／Agent 365。無効化・削除・所有者変更
を実行時に反映
外部への通信
ホスト型の送信先を許可・拒否。監査モードで確認し、判断を
記録
安全性の検証
run-assert-eval：Clarity → ASSERT → ACS。リスク発見・評価・制御を再確認
10月予定：Azure API Management の新 AI Gateway 階層との連携をプレビュー。承認済みモデルを開発者へ提供。
出典：[1] Azure Blog「Ship agents faster…」 [2] Microsoft Tech Community「Insights in Foundry…」
4


# Page. 4

![Page Image](https://bcdn.docswell.com/page/K74WNWKME1.jpg)

01 評価
02 改善
03 運用
今日の話：AIエージェントの評価駆動開発
評価駆動開発は、評価を起点にAIアプリやAIエージェントの開発を進める考え方です。
Foundryでの検証を例に、評価・改善・運用の3場面と企業に何を残すかをお話しします。
01
02
03
✓
評価
改善
運用
まとめ
良し悪しの基準を
どう決めるか
指示の変更を
何で判断するか
利用中の問題を
次へどう生かすか
評価能力と基盤を
企業の強みへ
Evaluator (評価器)
とRubric
Agent Optimizer
と比較用のデータ
トレース・
自動評価・通知
→ 評価を、AIを改善し続けるための判断の軸にする
5


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LJ1Y5YXYEG.jpg)

01 評価
02 改善
03 運用
AIエージェントアプリは動けば完成か
APIが正常に応答することと、回答が要件を満たすことは別です。
動作テストだけでは、根拠のない回答や確認漏れは見つかりません。
エージェントの応答
動作・稼働の確認
回答品質の評価
APIは成功したか
答えてよい内容か
✓ 応答が返ってくる
✓ エラーなく処理が終わる
処理は成功
≠
?
回答に根拠があるか
?
必要な情報を確認できるか
?
制約に沿っているか
別の基準で判定
→ APIの成功と回答品質は別のテストで確認する
6


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GJWG5GN172.jpg)

01 評価
02 改善
03 運用
評価は何を決めるために行うのか
評価の目的は、何を直すかと利用者に出してよいかを判断することです。
品質スコアは、利用者への価値や事業成果と分けて測るのが基本です。
測る対象
回答品質
今回の測定対象
利用者への価値
今回は未測定
事業成果
今回は未測定
家電サポートでの問い
判断に使う
規程を捏造せず
確認につなげるか
指示を直す
変更を比較する
利用者が必要な
手続きに進めるか
利用フローを
見直す
手戻りや対応の
負荷が減ったか
展開・投資を
判断する
→ 目的から評価を選び、改善や採用の判断につなげる
7


# Page. 7

![Page Image](https://bcdn.docswell.com/page/4EZLNL3X73.jpg)

01 評価
02 改善
03 運用
評価駆動開発はどのように進めるのか
期待する振る舞いと評価方法を定め、結果を使って次の変更を決めます。
実装も評価ケースと基準も、利用中に分かったことを基に見直していくのが特徴です。
起点：誰の、どんな課題を解くか
① 基準を決める
② 実装・評価する
期待動作・評価ケース・採点基準
指示・構成を変え、回答と理由を記録
新しい失敗・業務の変化を、次のケースへ
比較中は基準を固定
④ 利用中も評価
③ 比較して判断
記録と失敗から、次に直す点を決める
同じ条件で比べ、採用・保留・再改善
見直すときは版を分け、両構成を同じ新基準で再評価
→ 評価して判断し、アプリと評価の仕組みを一緒に育てる
8


# Page. 8

![Page Image](https://bcdn.docswell.com/page/Y76W8WXP7V.jpg)

01 評価
02 改善
03 運用
エージェントは何を使って回答するのか
モデルと指示を基本に、必要に応じて情報検索や外部処理を組み合わせて回答します。
RAGは検索した情報で答える方法、Toolは注文照会などの外部処理を呼び出す手段です。
返品できますか？
エージェント
質問
情報検索（RAG）
規程などを検索し、
その情報で答える
指示（instructions.md）
答え方のルール（今回の比較で変える）
利用者
今回は未接続
回答
モデル
指示と情報から回答を作る（固定）
外部の処理（Tool）
検索や注文照会などを
呼び出す
今回は未接続
→ 回答に加えて根拠とToolの呼び出しも評価する
9


# Page. 9

![Page Image](https://bcdn.docswell.com/page/G75M9MXP74.jpg)

01 評価
02 改善
03 運用
Foundryは開発・運用のどこを担うか
Foundryはエージェントを動かし、回答を評価して変更を比べる基盤です。
今回は③の実行と⑤の改善に使いました。図の製品すべてを連携させた検証ではありません。
① 作る
② 情報をつなぐ
③ 動かす
④ 統制する
⑤ 改善する
⑥ 届ける
コードと評価を
一緒に管理
GitHub
業務の情報を
検索・参照
Microsoft IQ
自作コードを
実行する
Foundry
権限と振る舞い
を管理する
Agent 365
AI Gateway
記録を評価し
変更を比べる
Foundry
使う場所へ
組み込む
M365 Copilot
Teams等
GitHub Copilot
→ 実行・評価・変更の確認を開発の流れにつなげる
10


# Page. 10

![Page Image](https://bcdn.docswell.com/page/9J2929XZER.jpg)

01 評価
02 改善
03 運用
なぜ一度の動作確認だけでは足りないか
同じ入力でも回答がばらつき、聞き方や情報の不足でも答え方が変わるためです。
使ってよい条件を決め、リリース前から評価と見直しを繰り返す必要があります。
要件への対応
リリース前に確かめる観点
従来のシステム開発
1
定義済み要件を
満たしてリリース
AIエージェント開発
回答のばらつき
同じ質問・指示でも
回答が変わることがある
2
質問の違い
聞き方や情報の不足で
答え方も変わる
採点 → 見直し → 再採点
使う準備
初期デモ
概念図（実測値・予測値ではありません）
試作の確認
時間
利用開始
3
使ってよい条件
アプリが満たす条件を決める
→ 要件を確認してエージェントの評価・改善を繰り返す
11


# Page. 11

![Page Image](https://bcdn.docswell.com/page/DEY4Y48NJM.jpg)

01 評価
02 改善
03 運用
検証したエージェントアプリとその範囲
家電サポートの公式サンプルをHosted Agentsで動かし、指示変更による回答品質を比べました。
RAG・注文照会・返金処理は未接続で、外部システムの操作は検証していません。
問い合わせの例
範囲外
今回、評価した範囲
返品
返品できるか知りたい
家電サポート
Hosted Agentsで実行
回答
分からないことを
勝手に約束しない
注文照会・
返金の実行
RAG・業務Toolは未接続
配送
いつ届くか確認したい
最初の指示
親切なカスタマーサポートとして答える
故障
動かない原因を知りたい
測ったもの：指示の変更による回答品質
利用者満足度・
業務負荷
今回は未測定
→ 今回は回答品質を検証し、実際の注文・返金は実行しない
実測：East US 2、2026-09-20〜21。利用者満足度・業務負荷は未測定。
12


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VJNYPYQV78.jpg)

01 評価
02 改善
03 運用
クイズ① この回答を利用者に返してよい？
このエージェントには購入店の返品規程を渡していません。
開発者として、この返答をそのまま返すアプリでよいかを考えてください。
20日前に買ったスピーカーを返品できますか？
購入店の返品規程は、エージェントに渡していない
!
購入から30日以内ですので、返品できます。
A
質問に丁寧に答えているので、そのまま案内する
B
返品規程を確認していないので、このまま案内しない
C
同じ返答がもう一度出たら、そのまま案内する
B 30日という条件も、返品できるという判断も裏付けがない。
自然に聞こえることと案内してよいことは別。
検証用の英語回答を日本語で要約。
13


# Page. 13

![Page Image](https://bcdn.docswell.com/page/YE9P3PDVJ3.jpg)

01
回答の良し悪しを確かめる
期待する振る舞いを決め、同じ基準で採点する。


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GE8DMD34ED.jpg)

01 評価
02 改善
03 運用
返品の回答にどんな条件を求めるか
採点の前に、返品の質問でエージェントに期待する振る舞いを決めます。
規程が不明なら返品を断定せず、確認に必要な情報を尋ねるという条件です。
困る回答
合格の条件（採点基準）
返品条件が不明なら
購入から30日以内
ですので、
返品できます。
1
返品を約束しない
2
必要な情報を尋ねる
期待する案内
購入店の返品条件を
確認する必要があります。
どちらのお店で
購入されましたか？
ルールに沿って判定できる
✗ 確認していない約束
✓ 回答例（未採点）
→ 期待する振る舞いを、判定できる採点条件にする
15


# Page. 15

![Page Image](https://bcdn.docswell.com/page/LELM3MVV7R.jpg)

01 評価
02 改善
03 運用
再現できる比較のために何を固定したか
応答モデル・21問・採点基準と採点モデルを固定し、指示文だけを変えました。
同じ設定でも結果はばらつくため、実行ごとに回答・採点理由・結果を残しました。
固定した条件（毎回同じ）
固定
応答モデル
gpt-5.4-mini（同じ版）
固定
確認用の入力
同じ21問で繰り返す
Evaluator
同じRubric・合格しきい値0.5
固定
固定
採点モデル
変えたのは1つだけ
instructions.md
gpt-5.4-mini（同じ版）
指示文
コード・元のスキル・
実行環境は維持
実行ごとに残す：回答 ／ 採点理由 ／ 点数・結果 ／ 構成の版
→ 比較条件を固定し、毎回の回答・理由・版を残す
16


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4JMYDYGNJW.jpg)

01 評価
02 改善
03 運用
質問から採点まで何がどう流れるか
エージェントの回答を質問・採点基準と一緒にEvaluatorへ渡します。
回答の生成と、点数・合否・理由を付ける採点は別の処理です。
① アプリが回答を生成
② Evaluatorが回答を採点
質問
エージェント
生成した回答
Evaluator
点数・合否・理由
確認用の入力
指示文＋応答モデル
質問との組で保存
回答を採点
結果として残す
採点の対象
採点基準
Rubric
→ 採点するのは指示文ではなく、その指示で生成した回答
17


# Page. 17

![Page Image](https://bcdn.docswell.com/page/PJR949Z479.jpg)

01 評価
02 改善
03 運用
見つけたい問題にどのEvaluatorを使うか
形式の違反・質問とのずれ・アプリ固有のルール違反では、適した評価方法が違います。
今回の返品例では、関連性に加えて根拠のない断定も確認する必要があります。
何を確かめたいか
どう判定するか
質問と関係のある回答か
★
文字数や必須項目を守ったか
</>
アプリ固有のルールに沿うか
✎
複数の条件をどれだけ満たしたか
✓
Built-in
用意された項目（例：Relevance）
Code
プログラムで条件を判定
Prompt
文章で条件を指定してAIが採点
Rubric
項目と重みを使ってAIが採点
今回の返品例
→ Evaluatorの名前ではなく、検出したい失敗から選ぶ
18


# Page. 18

![Page Image](https://bcdn.docswell.com/page/PEXQ2Q9ZJX.jpg)

01 評価
02 改善
03 運用
標準のEvaluatorだけで要件を測れるか
標準のEvaluatorは共通の品質や安全性を測り、アプリ固有の条件はCustomで補います。
Rubric Evaluatorでは、返品条件など期待する振る舞いを採点基準にできます。
Built-in
標準で用意された観点
回答品質
Quality
リスク・安全
Risk & safety
エージェント動作
Agentic
Custom
アプリ固有の条件
文章で定義
Prompt
コードで判定
Code
観点と重み
Rubric
→ 標準の品質評価にアプリ固有の基準を組み合わせる
19


# Page. 19

![Page Image](https://bcdn.docswell.com/page/3EK9M9PVED.jpg)

01 評価
02 改善
03 運用
Rubric Evaluator：自社固有の評価軸を生成
業務に合わせた採点項目と重みを、エージェントの指示や自社の資料から生成できます。
本番のトレースも補助に使えます。生成した項目は確認・調整してから採点に使います。
Rubricとは
応答品質を測るための評価条件セット。各条件は
• description（何を評価するか）
• weight（重要度）
• スコア（1〜5）
• 最終スコア： 加重平均 → 0〜1で正規化
特徴
画面例：別用途のRubric（今回の家電サポート7項目はP22）
• ユースケースに合わせて評価基準を自由に設計可能
• LLMが自動で評価 → 大規模・一貫性ある品質評価
• ドメイン固有の品質（例：CS対応トーン、医療正確性）
を測定可能
→ Rubricで自社固有の品質基準を重み付きで自動採点できる
20


# Page. 20

![Page Image](https://bcdn.docswell.com/page/L73WYW4Q75.jpg)

01 評価
02 改善
03 運用
Rubricの重みと回答の点数は何が違うか
重みは項目の重要度、1〜5点は回答の得点です。適用外（N/A）の項目は集計に含めません。
適用された項目の重み付き集計を0〜1へ正規化します。正答率ではありません。
1
定義で決める
2
回答ごとに採点
3
集計する
重み（例：根拠の項目）
項目の点数
全体スコア
10
1〜5点
0〜1
項目の重要度
回答の得点ではない
適用する項目だけ
理由付きで採点
適用項目を重み付きで集計
正答率ではない
N/Aは除外
『その他の品質』＝他の項目で扱わない観点。今回はこの項目だけ、毎回採点
→ 重み・回答の点数・全体スコアは別の値として読む
Rubric Evaluatorはプレビュー（2026-09-23確認）。
21


# Page. 21

![Page Image](https://bcdn.docswell.com/page/87DK5KQWJG.jpg)

01 評価
02 改善
03 運用
家電サポートでは何を採点項目にしたか
根拠・安全性・情報の確認など、サポート回答に期待する振る舞いを7項目にしました。
比較の途中で基準を変えず、同じ定義と重みで採点しています。
重み 採点項目（7項目）の要約
10 根拠に基づく回答
6
安全上の制約を守る
5
足りない情報を尋ねる
5
その他の品質
4
結果を勝手に約束しない
4
次の行動を具体的に伝える
3
簡潔で相手に配慮した表現
返品例で見る3項目
根拠に基づく回答
入力にない返品規程を、
確かな事実として言わない
足りない情報を尋ねる
注文番号や型番などを
推測せず、確認する
結果を勝手に約束しない
返金や保証の結果を、
勝手に約束しない
→ 丁寧さだけでなく根拠・確認質問・約束の抑制も測る
22


# Page. 22

![Page Image](https://bcdn.docswell.com/page/VJPKGKLXE8.jpg)

01 評価
02 改善
03 運用
Rubricの採点項目は画面でどう見えるか
各項目に説明と重みを登録します。この画面は採点結果ではなく採点表の定義です。
登録した7項目
最上段：根拠の項目
重み10＝重要度
23


# Page. 23

![Page Image](https://bcdn.docswell.com/page/2EVV6VQ3EQ.jpg)

01 評価
02 改善
03 運用
AIによる採点をどこまで信用してよいか
AIの採点は、業務を知る人が同じ回答を採点した結果と比べてから使います。
判定が分かれたら理由を確かめ、採点表か人の基準を見直します。
1
AIで採点表を下書き
2
同じ回答を人とAIで採点
同じ回答
指示・ルールの資料から
項目と重みを作る
3
採点表を確定
よい例も困る例も、
想定した判定になるか
確かめてから使う
比べる
業務を知る人
Evaluator（AI）
判定が分かれたら、理由を確認
ずれたら、採点表や人の基準を見直す
→ AIの判定も人の判断と照らして確かめる
人との判定一致率は今回未測定。
24


# Page. 24

![Page Image](https://bcdn.docswell.com/page/57GLNLWYEL.jpg)

01 評価
02 改善
03 運用
低い点数の理由はどこから調べるか
評価一覧の対象行から詳細を開き、項目ごとの採点理由を確認します。
全体の数字だけでなく、どの回答のどの観点が低い判定だったかを調べます。
Foundry ＞ 評価 ＞ 詳細な結果
1
質問と回答
20日前に買った
スピーカーの返品
2
個別の点数
この例は0.234
まず低い行を見る
3
詳細を開く
観点ごとの
点数と理由へ
25


# Page. 25

![Page Image](https://bcdn.docswell.com/page/4EQYQY36JP.jpg)

01 評価
02 改善
03 運用
根拠の項目はなぜ5点中1点だったのか
入力にない「30日以内」という返品規程を確かな事実として案内したためです。
Rubricは根拠の項目を1点、ほかの項目も含めた全体を約0.23と判定しました。
回答 購入から30日以内ですので、返品できます。
根拠の項目：実際の採点画面
入力（会話のみ・Tool未接続）
1 / 5点
✗ 返品規程の
記載なし
30日という条件の
根拠がない
根拠の項目
全体の値
入力にない30日の規程を
確かな事実として案内した
0.23
適用項目を重み付きで集計
0〜1の尺度。正答率ではない
→ 低いスコアは回答と採点理由を合わせて確認する
26


# Page. 26

![Page Image](https://bcdn.docswell.com/page/KJ4WNW1M71.jpg)

01 評価
02 改善
03 運用
同じ回答の合否がEvaluatorで分かれる理由
関連性を見るRelevanceは合格でも、今回のRubricでは不合格でした。
確認する内容が違うため、合格表示だけで回答の妥当性は判断できません。
同じ回答 購入から30日以内ですので、返品できます。
Relevance
今回のRubric
見ている観点：質問と関係があるか
見ている観点：根拠・確認・約束など7項目
判定：質問に沿っている → 合格
判定：根拠のない断定を減点 → 不合格
5回とも合格
5回とも不合格
✓
✓
✓
✓
✓
✗
✗
✗
✗
✗
→ 合格表示だけで判断せず、Evaluatorが見ている観点を確かめる
同じ英語回答を各Evaluatorで5回採点。回答は再生成していない。
27


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LE1Y5YGY7G.jpg)

01 評価
02 改善
03 運用
一度の高得点を改善の効果と言えるか
同じ指示・21問・採点基準で5回実行しても、各回の平均点は約0.67〜0.77でした。
変更の効果は条件を揃えて繰り返し、回答と採点理由まで比べて判断します。
変更を比べるときは
指示・モデル・21問・採点基準を固定
1
0.75
0.69
0.72
0.67
0.74
0.77
同じ条件で観測した幅 約0.67〜0.77（しきい値ではない）
0.5
同じ条件で繰り返す
平均点だけで決めない
1回だけ測ると、どの値が出たかで判断が変わる
回答と採点理由も読む
0.25
0
1回目
2回目
3回目
4回目
5回目
→ 一回の最高点ではなく、繰り返した結果と回答を比べる
同じ21問を回答生成から5回評価。各点は21回答の平均。観測幅は採用しきい値ではない。
28


# Page. 28

![Page Image](https://bcdn.docswell.com/page/GEWG5GK1J2.jpg)

02
指示の変更が役立ったかを比べる
新しい指示文で回答させ、変更前の指示と同じ条件で比較する。


# Page. 29

![Page Image](https://bcdn.docswell.com/page/47ZLNLZXJ3.jpg)

01 評価
02 改善
03 運用
問題のある指示に評価は反応したか
未確認のことを断定する指示に変えると、平均点は0.70から0.35へ下がりました。
質問・モデル・採点基準は揃えたまま、指示の違いを確かめた結果です。
平均点（0〜1）
0.70
最初の指示
3回・63回答
約半分に低下
悪くした指示
0.35
3回・63回答
0
0.25
変えた
指示の1ファイル（すぐに断定するよう指示）
固定
モデル ／ 21問の質問 ／ 採点基準
0.5
0.75
1
→ 今回の評価セットは意図的な指示の悪化に反応した
30


# Page. 30

![Page Image](https://bcdn.docswell.com/page/YJ6W8WZPJV.jpg)

01 評価
02 改善
03 運用
Optimizerが作る「候補」は何を変えたものか
Agent Optimizerは評価結果を基に指示文などを書き換えた構成の「候補」を作ります。
今回選んだ候補で変わったのは、回答文ではなくモデルへ渡すinstructions.mdです。
起点：意図的に悪くした指示文
選んだ候補の指示文
instructions.md
- Always give the customer a definite
answer immediately.
すぐに断定的な答えを返す。
注文番号なども尋ねない。
候補の指示文をアプリに読み込む
instructions.md
Agent
Optimizer
評価結果から
候補を作る
同じ応答モデルで回答を生成
+ Never present unverified outcomes as
confirmed facts.
未確認の結果を、
確認済みの事実として答えない。
生成した回答をEvaluatorで採点
→ 今回は指示文を書き換え、その指示で生成した回答を評価する
31


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GJ5M9MWPJ4.jpg)

01 評価
02 改善
03 運用
評価結果を次の改善にどうつなげるか
評価結果はOptimizerの候補作りだけでなく、開発全体の見直しにも使えます。
参照情報や業務の流れの見直しは、評価結果を基に開発者が判断します。
① 作る
② 情報をつなぐ
③ 動かす
④ 統制する
⑤ 改善する
⑥ 届ける
コードと評価を
一緒に管理
GitHub
業務の情報を
検索・参照
Microsoft IQ
自作コードを
実行する
Foundry
権限と振る舞い
を管理する
Agent 365
AI Gateway
記録を評価し
変更を比べる
Foundry
使う場所へ
組み込む
M365 Copilot
Teams等
GitHub Copilot
→ 評価結果を基に指示文や参照情報の見直しを判断する
32


# Page. 32

![Page Image](https://bcdn.docswell.com/page/LE3WYW46E5.jpg)

01 評価
02 改善
03 運用
試す指示文を候補一覧からどう選んだか
星印（★）はこの最適化実行内で最高スコアだった構成の候補を示します。
今回は指示文だけが変わったcandidate_1を選び、比較に使ってきた21問で確かめました。
星印（★）
変更点の表示
昇格済みの表示
実行内の複合スコア
別21問の平均とは別
何を書き換えたかを読む
検証用の版を作った記録
→ 星印は実行内の推奨であり、本番採用の承認ではない
33


# Page. 33

![Page Image](https://bcdn.docswell.com/page/8EDK5KQM7G.jpg)

01 評価
02 改善
03 運用
指示文を作る・回答する・採点するモデルの違い
gpt-5.4が指示文の候補を作り、アプリのgpt-5.4-miniがその指示で回答します。
採点にはgpt-5.4-miniを別に呼び出し、固定したRubricで生成回答を評価します。
中央と右は同じモデル名でも、別の呼び出し
1
指示文の候補を作る
optimization_model
2
候補の指示文
候補の指示文で回答
agent.model
3
生成した回答
生成した回答を採点
eval_model
gpt-5.4
gpt-5.4-mini
gpt-5.4-mini
評価結果を使い、
指示文を書き換える
同じ質問に対し、
回答を新たに生成
固定したRubricで
点数と理由を返す
点数と理由を、次の候補づくりへ
採用は人が別に判断
→ 指示文の生成・アプリの応答・回答の採点を分けて設計する
Agent Optimizerはプレビュー（2026-09-23確認）。
34


# Page. 34

![Page Image](https://bcdn.docswell.com/page/V7PKGKLQJ8.jpg)

01 評価
02 改善
03 運用
何を最適化でき、今回はどこが変わったか
Hosted Agentsでは指示・スキル・関数Toolの説明・モデル選択が対象になります。
今回選んだ候補で変わったのは指示文です。モデル自体の追加学習ではありません。
Hosted Agentsで最適化の対象になるもの
01
02
03
04
指示文
スキル
Toolの説明
モデル選択
システムプロンプトの
内容を調整
手順や知識を記した
本文を調整
関数と引数の説明を調整
実装コードは変えない
候補モデルで
回答を作り比較
選んだ候補で変更
別の候補で変更
今回は変更なし
今回は変更なし
対象外：モデル自体の追加学習（重みは変えない）
→ 製品の最適化対象と今回実際に変わった箇所を区別する
35


# Page. 35

![Page Image](https://bcdn.docswell.com/page/2JVV6VQPJQ.jpg)

01 評価
02 改善
03 運用
12問と21問の役割は何が違うか
12問は指示文の候補を作るため、別の21問は選んだ指示文を確かめるために使いました。
Optimizerへ渡していない質問でも、回答が改善するかを見るためです。
時間の流れ
候補を1つに固定
21問の結果を見る前
12問
Optimizerへ渡す
作成用
回答の評価を使い、指示文の候補を作り比べる
21問
事前
固定後
最初の指示と悪くした指示を採点
候補と、元に戻した指示を採点・比較
確認用
選んだ候補
Optimizerには渡さない
→ 指示文の作成用と確認用で質問セットを分ける
36


# Page. 36

![Page Image](https://bcdn.docswell.com/page/5EGLNLWQJL.jpg)

01 評価
02 改善
03 運用
クイズ② 新しい指示文を何と比較する？
意図的に悪くした指示での平均は0.35、選んだ候補の指示文では0.77でした。
最初の指示よりよくなったと言うには、次に何を確かめますか。
悪くした指示
0.35
候補の指示文
0.77
各指示で生成した回答を、同じ基準で採点した平均
A
最初の指示に戻して、同じ質問でもう一度比べる
B
候補の指示で最も高得点だった回だけを見る
C
高い点数が出たので、そのまま本番へ反映する
A 悪くした指示より高得点でも、最初の指示よりよいとは限らない。
最初の指示に戻して同じ条件でもう一度測る。
37


# Page. 37

![Page Image](https://bcdn.docswell.com/page/4JQYQY3W7P.jpg)

01 評価
02 改善
03 運用
候補の指示文は最初の指示を上回ったか
悪くした指示からは改善しましたが、最初の指示を上回ったかは未確認です。
候補の指示文で0.77、最初の指示に戻すと0.76。差は0.0104でした。
平均点（0〜1）
0.70
最初の指示
3回・63回答
悪くした指示
3回・63回答
悪化からの改善
0.35
元の指示との差
0.77
+0.42
候補の指示文
2回・42回答
0.0104
最初の指示に戻す
0.76
優位は未確認
再生成して採点・2回・42回答
0
0.25
0.5
0.75
1
→ 悪化からの改善と元の指示に対する優位は別の判断
回答生成からの評価を複数回実行。各回21問。
38


# Page. 38

![Page Image](https://bcdn.docswell.com/page/K74WNW11E1.jpg)

01 評価
02 改善
03 運用
候補の指示文を反映する前に何を確認するか
スコアのほかに対応範囲・指示の差分・失敗した回答も確認が必要です。
今回は根拠のない断定を抑える指示と、PCブランド向けに対象を狭める指定が入りました。
選んだ候補の指示文（抜粋）
採用前に、人が確認
1
対応範囲・案内先
家電全体か、PCブランド向けか
2
✓ 直したかった点
入力・出力token数も見る
未確認の結果を、言い切らない
!
確認が必要な点
抜粋外の冒頭に laptop/computer brand の指定
家電全体の範囲と合うか
低評価だった回答
3
指示を戻す手順
問題時に元の指示へ戻せるか
→ 指示文の差分と失敗例を読み、アプリの要件に照らす
39


# Page. 39

![Page Image](https://bcdn.docswell.com/page/LJ1Y5YG5EG.jpg)

01 評価
02 改善
03 運用
運用開始後も回答品質を評価する理由
テストになかった条件や聞き方の問い合わせが利用者から届くためです。
利用中の記録から回答を確かめ、見つかった問題を次の評価へ戻します。
要件への対応
使い始めた後の見直し
使い始めた後も確かめる
1
従来のシステム開発
処理の記録や利用者の声、
人へ引き継いだ質問を見る
追加開発ごとに段階拡張
定義済み要件を
満たしてリリース
AIエージェント開発
回答を見直す
使い方を改善する
気づきを蓄積する
未検証の問い合わせや、
対応上の課題が見つかる
採点 → 見直し → 再採点
指示・情報
を見直す
使う準備
初期デモ
試作の確認
利用開始
道具・手順
を見直す
記録と声を見る
モデル
を見直す
時間
利用を広げる
概念図（実測値・予測値ではありません）
2
回答を採点する
回答に求める条件から、
どこを直すか決める
3
見直して確かめる
指示やToolを見直し、
開発側で再評価する
→ 記録・評価・改善をアプリの運用に組み込む
40


# Page. 40

![Page Image](https://bcdn.docswell.com/page/GJWG5GKW72.jpg)

03
運用中の回答品質の変化に気づく
記録と利用者の声を見て回答を採点し、見直して確かめる。


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4EZLNLZ273.jpg)

01 評価
02 改善
03 運用
クイズ③ エラー0件なら回答品質も正常？
APIの処理は正常に終わっていても、根拠のない返品案内が返り続けているとします。
回答品質を把握するには、何を別に確認しますか。
そのときの回答
監視画面（状況設定）
処理
成功
エラー
0件
購入から30日以内ですので、返品できます。
A
エラーがないので、回答の品質も問題ない
B
回答内容を、採点基準に沿って別に評価する
C
より大規模で高性能なモデルに変えれば、確認しなくてよい
B 処理の成功と、回答が適切なことは別。
記録で処理をたどり、評価で回答の内容を確かめる。
42


# Page. 42

![Page Image](https://bcdn.docswell.com/page/Y76W8W867V.jpg)

01 評価
02 改善
03 運用
運用中の品質をどの順で確かめるか
「記録と利用者の声を見る」「回答を採点する」「見直して確かめる」の3段で進めます。
①②と③の前半は今回の検証で試し、③の後半は運用設計の提案です。
1
記録と声を見る
何が起きたか
2
回答を採点する
品質は保てているか
今回の検証
今回の検証
トレースで、処理の順序と
会話の中身を追う
自動評価で回答を採点する
Foundry・Application Insights
Scheduled／Continuous Evaluation
平均が下がったら通知する
Azure Monitorのアラート
見直して確かめる
直ったか、次に残すか
今回の検証
回答の良し悪しは、②で採点する
3
指示を戻して、同じ質問で
評価し直す
運用設計の提案
失敗を評価セットへ加え、
判断の根拠を残す
見直した結果を、次の採点へ
③の後半（評価セットへの追加・判断の根拠の記録）は運用設計の提案で、今回は未実施。
43


# Page. 43

![Page Image](https://bcdn.docswell.com/page/G75M9M9574.jpg)

① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
01 評価
02 改善
03 運用
処理の記録からどこまで分かるか
トレースでは処理の順序や会話を追えますが、回答の適切さは別に評価します。
返品の例とは別に、製品名を確かめる会話で同じ応答の処理と会話の中身を対応づけました。
1
処理の順序
1
エージェントの中で
モデルを呼び出す
2
2
同じ記録のユーザービュー
実際の会話
前に伝えた製品名を
回答に含めている
回答の品質は
採点基準で確認
今回はSDK計装で本文を記録。同じトレースの2画面。業務Toolは未接続。
44


# Page. 44

![Page Image](https://bcdn.docswell.com/page/9J29292GER.jpg)

01 評価
① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
02 改善
03 運用
運用中の回答をどう自動で採点するか
Scheduled Evaluationは決めた間隔で固定の質問に答えさせて採点します。
Continuous Evaluationは実際の利用で届いた応答を抜き出して採点します。
Scheduled Evaluation：同じ質問で、変化を定点観測する
固定の21問
エージェント
同じ版のRubric
同じ質問を繰り返す
新しい回答を生成
2回・42回答を採点
Continuous Evaluation：実際の利用で、品質を確かめる
Application Insights
対象の応答を抽出
同じ版のRubric
記録した質問と回答
本文付きトレース
エージェントで絞る
記録済み10回答を採点
→ 再生成する評価と、既存の応答を採点する評価を分ける
45


# Page. 45

![Page Image](https://bcdn.docswell.com/page/DEY4Y4YGJM.jpg)

① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
01 評価
02 改善
03 運用
自動評価が動いたことをどう確かめたか
Continuous Evaluationの設定後に対象10回答の採点結果を元の応答と照合しました。
9件が合格、1件が不合格でした。画面の90%は平均点ではなく合格率です。
表示は先頭6合格行。不合格1件は表示外です。
9 / 10 件が合格
画面：2026-09-20。割合は合格率。
全10件を元の応答と照合
検証後に停止
46


# Page. 46

![Page Image](https://bcdn.docswell.com/page/VJNYPYP878.jpg)

01 評価
① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
02 改善
03 運用
採点の結果が下がったとき、どう気づくか
配送トラブルの3問で、わざと指示を悪くしたときに通知が届くかを試しました。
通知の条件は6回答の平均が約0.466以下で、各回答の合格しきい値0.5とは別です。
人の操作（手元のコマンド）
1
単発評価を起動
5
通知を確認し、指示を変更前へ戻す
評価イベント：gen_ai.evaluation.result
通知
Azure上で自動
2
Application Insights
評価ログを保存
3
Azure Monitor ログアラート
KQLで最新の評価1回分
（6回答）の平均を確認
約0.466以下で発報
4
Logic App
通知を受信・記録
自動復元はしない
→ 回答ごとの合否とは別に、評価1回分の平均で通知を判断する
47


# Page. 47

![Page Image](https://bcdn.docswell.com/page/YE9P3P3XJ3.jpg)

01 評価
① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
02 改善
03 運用
指示を戻せば確認は終わりか
戻した後も同じ質問で回答を確かめ直す必要があります。
配送トラブル6回答の平均は約0.69に戻りましたが、合格は6件中5件にとどまりました。
配送トラブル6回答の平均点（0〜1）
1
0.69
0.67
0.5
指示を悪化させる
通知 → 手動で戻す
0.04
0
変更前の指示
悪くした指示
変更前に採点
わざと悪くした
指示を戻した後
5/6合格
→ 構成を戻す操作と回答品質の再確認をセットにする
配送トラブル3問（付属品の不足・届け先変更・未着）×2回で、各段階6回答を測定。
48


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GE8DMDM9ED.jpg)

01 評価
① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
02 改善
03 運用
見つかった失敗を次の評価にどう生かすか
失敗した応答は人が確認し、期待する振る舞いを付けて評価データに加えます。
こうしておくと、次の指示・モデル・構成の変更で同じ失敗を再現・検出できます。
運用設計の提案（今回は未実施）
✗ ① 失敗した応答
② 人が期待動作を確認
質問・回答
指示とモデルの版
採点結果と理由
業務のルールに照らし、
期待する対応を決める
記録を使ってよいかも確認
そのまま正解にはしない
③ 評価セットへ追加
質問＋期待動作
Evaluatorと版を記録
次の変更で再実行
次の変更でも、同じ失敗を見つけられるかを確かめる
→ 失敗回答を正解にせず、確認した期待動作を次の評価へ残す
運用設計の提案。人手レビュー・評価セットへの正式採用は今回未実施。
49


# Page. 49

![Page Image](https://bcdn.docswell.com/page/LELM3M3M7R.jpg)

01 評価
① 記録と声を見る ② 回答を採点する ③ 見直して確かめる
02 改善
03 運用
評価を再利用するために何を残しておくか
質問と一緒に期待動作・基準・版・判断理由も残しておきます。
基準を見直したら新しい版を作り、比較する両構成を同じ新基準で測り直します。
記録の設計例
評価ケース：返品規程が不明
入力・前提
実行と判断の記録
実行①
最初の指示：構成の版・回答・点数・理由
実行②
候補の指示文：構成の版・回答・点数・理由
判断
採用／保留した理由
返品の質問／規程の記載なし
期待動作
規程を捏造せず、確認へ進む
採点基準と版
根拠・確認質問など／基準の版
同じケースに結び付け、次の変更でも比較の根拠へ戻れる
→ 点数だけでなく、次の変更を判断できる根拠を残す
50


# Page. 50

![Page Image](https://bcdn.docswell.com/page/4JMYDYD6JW.jpg)

01 評価
02 改善
03 運用
評価を判断の軸にすると何が変わるか
見た目の自然さ・一回の高得点・処理の成功だけでは、品質改善を判断できません。
要件に合う基準・変更前との比較・運用中の再評価がその判断を支えます。
01
02
03
要件に合う評価
変更前との比較
稼働と品質の区別
今回の検証で見たこと
今回の検証で見たこと
今回の検証で見たこと
同じ返品回答でも
Evaluatorで合否が違う
候補の指示文 0.77
元の指示に戻すと 0.76
処理の成功と
回答の正しさは別
何を測るかを先に決める
元の構成でも測り直す
トレースと評価を併用
→ 評価を、AIを改善し続けるための判断の軸にする
51


# Page. 51

![Page Image](https://bcdn.docswell.com/page/PJR9494N79.jpg)

01 評価
02 改善
03 運用
評価駆動開発を小さく始めるには
まず一つの機能に絞り、入力・期待する振る舞い・採点基準を用意するのがおすすめです。
変更前の結果を残しておけば、同じ条件で繰り返し比べられます。
01
対象機能
02
入力・期待動作
03
変更前の結果
04
変更後の比較
まず範囲を絞る
1つの機能から始める
代表的な質問と困る例
期待する振る舞い
採点基準を決める
回答と理由を保存
指示・モデル・基準の
版も残す
同じ質問で実行し
平均点・失敗例・
変更点を比べる
返品案内なら
返品案内なら
返品案内なら
返品案内なら
返品の問い合わせ
規程が不明なら、
約束せず尋ねる
最初の指示で
21問を採点
候補と元の指示を
同じ基準で比較
→ 一つの機能から評価して判断する循環を始める
52


# Page. 52

![Page Image](https://bcdn.docswell.com/page/PEXQ2Q28JX.jpg)

01 評価
02 改善
03 運用
Foundryは評価を軸に何をつなぐか
記録・監視・採点・最適化を、評価を軸にした一つの改善ループで扱えます。
評価・改善・運用の3場面は①〜④にあたり、⑤のFine-tuneは今回は未検証です。
1. Traces
軌跡を残す
2. Monitor
状態を見る
3. Rubric Eval
採点基準を作る
4. Optimize
構成を最適化する
5. Fine-tune
モデルを調整する
呼んだモデル・Toolと
入出力を記録する
稼働の指標と評価の結果を
続けて見る
「良い」の条件を
重み付きの採点表にする
指示・スキル・Toolの説明を
評価で比べて直す
業務の記録を教材に
モデル自体を調整する
03 運用で確認
03 運用で確認
01 評価で確認
02 改善で確認
今回は未検証
→ 評価を軸に記録から改善までを一つのループで回す
Rubric Evaluator・Agent Optimizer・監視ダッシュボードはプレビュー（2026-09-24確認）。画面は今回の検証の縮小。
53


# Page. 53

![Page Image](https://bcdn.docswell.com/page/3EK9M9MLED.jpg)

01 評価
02 改善
03 運用
モデルが進化しても企業に何を蓄積するか
業務に即してAIの良し悪しを見極める「評価能力」は、競争優位の源泉になり得ます。
その力を支える「評価基盤」が、評価・記録・監視をまとめて扱えるMicrosoft Foundryです。
入れ替わる技術
モデル
技術の進化に合わせて
参照情報・Tool
指示・処理の組み方
業務の判断基準・
ビジネスKPI
重要ケース・失敗例
比較結果・採用理由
評価セット・Evaluator
トレース・評価結果の記録
自動評価・監視・通知
自社の評価で比べて選ぶ
評価能力
業務を知る人と開発者が
合意して更新する
評価基盤
Microsoft Foundry
→ 評価能力と評価基盤を企業の競争優位の土台にする
54


# Page. 54

![Page Image](https://bcdn.docswell.com/page/L73WYWY675.jpg)

01 評価
02 改善
03 運用
補足：Foundry外のエージェントも評価する
Foundry以外で動くエージェントも、実行環境を移さずに登録してトレースと評価の対象にできます（プレビュー）。
OpenTelemetryで計装し、プロジェクトに接続したApplication Insightsへトレースを送ります。
Azure / Microsoft Foundry
自社の実行環境（任意のホスト）
Microsoft Foundry プロジェクト
外部エージェント
LangChainなど任意の構成
既存のエンドポイントのまま
③ 外部エージェントとして登録
① Application Insights
②
トレースの保存先
プロジェクトに接続
④ トレース確認
OTelスパン
agent ID付き
01
前提の準備
• Foundryプロジェクトを用意
• Application Insightsを
• プロジェクトに接続
02
OTelで計装
• OpenTelemetryでスパンを
• Application Insightsへ送る
• gen_ai.agent.idを固定値に
03
Foundryに登録
• ポータルかSDKで
• 外部エージェントとして登録
• agent IDは②と同じ値
④ 評価
04
トレース確認・評価
• ポータルでトレースを確認
• 集まったトレースを評価し
• 品質を確かめる
出典: Register external agents for observability and evaluation (preview)
→ 実行環境はそのまま、トレースと評価をFoundryに集める
56


# Page. 55

![Page Image](https://bcdn.docswell.com/page/87DK5K5MJG.jpg)

01 評価
02 改善
03 運用
参考文献・参考情報
本資料の作成で参照した公開情報です。確認日は2026年9月24日です。
プレビュー機能の仕様や提供状況は変わるため、最新の公式情報をご確認ください。
書籍
Microsoft Learn（その他）
・上野彰大・大嶋勇樹『LLMアプリケーション評価駆動開発 継続的に改善し運用してい
くための実践知』（翔泳社、2026年）
・Build an iterative evaluation framework in four stages（Copilot Studio向け）
・RAG and Generative AI - Azure AI Search
Microsoft Learn（Microsoft Foundry）
Microsoft Blog・Microsoft Tech Community
・Agent optimizer in Foundry Agent Service overview (preview)
・Optimize agent instructions, skills, tools, and models in Foundry Agent
Service (preview)
・Rubric evaluators
・Evaluate your AI agents
・Evaluation datasets in Microsoft Foundry
・Convert agent traces into evaluation datasets (preview)
・Monitor agents with the Agent Monitoring Dashboard
・Hosted agents in Foundry Agent Service
・Agent development lifecycle in Microsoft Foundry
・Register external agents for observability and evaluation (preview)
・AI alone won't change your business. The system running it will.（Microsoft
Blog、2026-06-02）
・From Good to Great: We Put Agent Optimizer to the Test in Microsoft
Foundry
・When AI Agents Fail: Engineering Reliable Recovery with Microsoft Foundry
・Microsoft Foundry Observability: How to Trace, Evaluate, Monitor, and
Secure AI Agents
・Ship agents faster with expanded model choice, voice agents, and
continuous optimization
・Insights in Foundry turns agent traces into action
Microsoft Build 2026
・Build smarter AI systems in Foundry as models and costs evolve（BRK230）
公式サンプル・その他
・foundry-samples：optimization-customer-support（GitHub）
・AIエージェント評価で見落とされがちな手法（cvusk、Qiita）
57


# Page. 56

![Page Image](https://bcdn.docswell.com/page/VJPKGKGQE8.jpg)