Azure AIによるエージェント型運用の計画と実行を評価しよう

Azure AIによるエージェント型運用の計画と実行を評価しよう .NETラボ 勉強会 2026年10月 1

自己紹介 山田顕人（Kento.Yamada） @ymd65536 By the wayの人、404ニキなど呼び方はさまざま 仕事：DevSecOps、クラウドインテグレーション コミュニティ運営：.NETラボ、AI運用、AI駆動開発 受賞歴（10個、継続中の称号を掲載） ● 初代PagerDutyアンバサダー 2

前回のおさらい：Planningを評価する ● インシデント対応を Planning と Execution に分離 ● 良い計画はToDoリストではない ● 仮説 → 観測 → 分岐 → 最小限の変更 ● 評価軸：正確性・効率性・安全性・関連性・分岐・検証 前回は「何を、なぜ、どの順番で行うか」を確認した 3

いつもの：PagerDutyさんを見てみよう 4

補足：PD Labsとは（Paige = SRE Agent） 5

PagerDuty SRE Workbench：調査から判断まで 調査を支援 判断を支援 改善につなぐ 証拠と状況 インシデントの文脈 原因仮説 人間の確認 対応の振り返り 運用知識 ● Deep Investigation ● Topology ● Evidence・Findings・Diagnosis 出典：PagerDuty Docs｜SRE Workbench Overview（PD Labs） 6

• https://docs.pagerduty.com/ai-automation/pd-labs/workbench-overview

今回の流れ：サービスから実験管理へ PagerDuty / Azure GitHub Copilot 問いを立てる 実験で確かめる 判断は正しい？ 安全に動く？ Trace / Scoring 比較・改善 動くエージェントを信頼できるエージェントへ 参照先： PagerDuty Docs ｜ Microsoft Learn ｜ GitHub Docs 7

• https://docs.pagerduty.com/ai-automation/pd-labs/workbench-overview
• https://learn.microsoft.com/ja-jp/azure/sre-agent/overview
• https://docs.github.com/en/copilot/concepts/customizations/custom-agents

信頼できるエージェントとは 正確性 安全性 効率性 原因を特定？ 根拠は十分？ 不要な変更なし？ 承認を守った？ 適切なツール？ 時間・コストは？ 同じ条件で繰り返し検証する必要がある。※つまり実験管理につながる 参考：Microsoft Learn｜Azure SRE Agent の運用・承認モデル 8

• https://learn.microsoft.com/en-us/azure/sre-agent/overview

Azure SRE Agent：Azure運用を支援 観測 調査 対応 Azureリソース ログ・メトリクス 原因候補 関連情報の分析 提案と確認 権限・承認 インシデントの観測、インフラの調査とインフラの変更は分けて考える 出典：Microsoft Learn｜Azure SRE Agent の概要 9

• https://learn.microsoft.com/ja-jp/azure/sre-agent/overview

GitHub CopilotとSREの接点 開発の文脈 調査の文脈 注意点 コード・PR 変更履歴 変更の影響 原因仮説 Copilotの機能と SRE製品を区別 SRE製品ではない。開発の文脈をもったうえでSREの製品としても振る舞える。 出典：GitHub Docs｜Custom agents（GitHub Copilot） 10

• https://docs.github.com/en/copilot/concepts/customizations/custom-agents

エージェントの実験管理とは何か インシデント発生から実際の対応までをスコアリングして保存する。 Scenario Agent Run Trace Scoring Compare 実行を記録し、同じ条件で比較・改善する。 モデルとツールの組み合わせ管理 11

手順（計画）通りも大事 一方で実行結果の評価も大事 観測 計画 実行 評価 判断 評価結果をもとに再試行・再計画・承認要求を判断する 12

なぜ、実行結果の評価が必要なのか ● 計画が妥当でも、実行結果が正しいとは限らない ● 404エラーに対して、調査せずVMを再起動していないか ● 本番環境では「直った」だけでなく手順と承認が重要 ● 余計なMCP呼び出し、ループ、トークン消費も観測する 計画→実行→実行後の状態評価が大事（次のスライド） 13

今回の評価対象：計画・実行・整合性 Planning Execution Alignment 計画の妥当性 安全性・優先順位 ツールと結果 成功・失敗 計画との整合 許可された変更 計画・実行・整合性をそれぞれ評価する 14

まずはやってみる Databricks / MLflowで実験を管理する Dataset Agent Run Trace Scorer Experiment Databricks / MLflowでトレースと評価を実験単位に保存する 15

実際に実験してみた（Azure Databricks） GPT、Gemma、Llama 4で実験 16

3モデル共通の実験条件 SYSTEM PROMPT INC-001 / Kubernetes SREインシデント調査エージェ ント 観測情報に基づいて原因を分析 根拠不足なら断定しない 復旧操作は実行しない Podが繰り返し再起動 終了理由：OOMKilled Memory Limit：512Mi 再起動直前は上限付近 直近でアプリケーションを更新 同じ SYSTEM_PROMPT と incident を3モデルへ入力 17

共通の出力形式と期待回答 JSONのみで回答 期待する評価上のポイント root_cause recommended_action requires_approval: true OOM-Killerはメモリ上限到達 コード更新との因果は未確定 使用量と変更内容の調査が必要 比較対象は推論内容・応答時間。実行評価ではない 18

3モデルの推論結果を比較する GPT-OSS-20B｜2.69秒 プロファイル取得・リーク調査まで具体化 Databricks Gemma（Google Gemma）｜1.71秒（再実行） 正確性・関連性・承認チェックが合格 Llama 4 Maverick｜2.75秒 簡潔に原因と対応の要点を提示 3モデルとも requires_approval = true。速度だけでは品質を決められない ※人間の承認を必要する結果になった 19

GPT-OSS-20B：調査手順が具体的 原因分析 推奨アクション 更新後のメモリ使用量増大 512Miに達しOOMKilled 新バージョンのプロファイル取得 リーク・高負荷箇所を調査 2.69秒｜承認要否 true｜リミット増加やコード最適化も提案 20

GPT-OSS-20Bの実験結果 21

Gemma：再実行で3項目すべて合格 原因分析 推奨アクション 更新後のメモリ増加を疑う 旧バージョンと比較して検証 メモリ調査・プロファイリング ロールバックで切り分け 1.71秒｜承認要否 true｜正確性・関連性とも合格 22

Gemmaの実験結果（再実行：MLflowの評価結果） 評価対象は1件／実行時間 1.71秒 「100%」は今回の1件の結果であり、モデルの汎用性能ではない 23

Llama 4 Maverick：簡潔な推論 原因分析 推奨アクション メモリ使用量の増加による OOMKilled メモリ使用量の調査 リミット見直し・コード最適化 2.75秒｜承認要否 true｜簡潔さと調査粒度の違いを比較する 24

Llama 4 Maverickの実験結果 25

Microsoft Foundryで評価するには？ 計画と制約 ツール利用 完了と安全 タスク遵守 Custom Evaluator ツール選択 ツール呼び出し成功率 タスク達成 Custom Evaluator 評価機能の紹介のみ。今回はFoundryで実行・採点しない。 公式資料：Microsoft Learn｜Agent Evaluators 26

• https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators

Foundryの評価手順（今回は実演なし） ① 評価データを準備 ② 評価対象を用意 ③ Evaluatorを選ぶ Incidentと期待回答 ツール履歴・応答 評価基準を決める 既存の応答・Trace またはAgentを実行 モデルと条件を記 録 Task Adherence Tool Selectionなど 結果と根拠を確認 操作手順：Microsoft Learn｜Run evaluations from Foundry portal 27

• https://learn.microsoft.com/en-us/azure/foundry/how-to/evaluate-generative-ai-app

Databricks実測とFoundryの方法を整理 Databricks / MLflow 推論比較 Scorer / Trace 評価Runと実測結果 Microsoft Foundry 評価設計の共通点 ※今回は手順のみ Dataset / Evaluator Trace とRunの考え方 条件・期待結果を固定 根拠と安全性を評価 履歴を残して比較 公式資料：Microsoft Learn｜Evaluation in Microsoft Foundry 28

• https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-overview

実験管理で残すべきレコード 入力と条件 計画と実行 評価と成果 Incident ID 環境・ツール Prompt Version Plan Steps Tool Trace 出力のチェック Score / Gate Latency / Cost 成果のチェック Foundryでも記録したい項目（今回は設計のみ） 29

まとめ 実測はDatabricks。Foundryは評価手順を紹介 1. 計画・実行・整合性 2. Databricksで実測 3. Foundryは手順を紹介 判断根拠と安全性を評 価軸に分ける。ツール 実行の評価は今後の課 題 同じインシデントで3 モデルの推論を比較 し、MLflowに評価を 記録 Dataset・Evaluator ・Traceの使い方を整 理。Foundryでの実行 は行わない 「直ったか」だけでなく 「なぜ、その判断に至ったか」を測る 30

次回予告 GitHub UNIVERSEとMicrosoft IgniteのRecapやります。 ※11月のラボは行けたら行くの精神です。 31