---
title: Azure AIによるエージェント型運用の計画と実行を評価しよう
tags:  #生成ai #azure #aiエージェント  
author: [Kento Yamada](https://docswell.com/user/ymd65536)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/DEY466Z8JM.jpg?width=480
description: .NETラボ 勉強会 2026年10月 の登壇資料です。 https://dotnetlab.connpass.com/event/400124/
published: October 24, 26
canonical: https://docswell.com/s/ymd65536/ZDM4PV-2026-10-24
---
# Page. 1

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

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


# Page. 2

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

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


# Page. 3

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

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


# Page. 4

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

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


# Page. 5

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

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


# Page. 6

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

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


# Page. 7

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

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


# Page. 8

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

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


# Page. 9

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

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


# Page. 10

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

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


# Page. 11

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

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


# Page. 12

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

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


# Page. 13

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

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


# Page. 14

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

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


# Page. 15

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

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


# Page. 16

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

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


# Page. 17

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

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


# Page. 18

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

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


# Page. 19

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

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


# Page. 20

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

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


# Page. 21

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

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


# Page. 22

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

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


# Page. 23

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

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


# Page. 24

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

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


# Page. 25

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

Llama 4 Maverickの実験結果
25


# Page. 26

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

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


# Page. 27

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

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


# Page. 28

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

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


# Page. 29

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

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


# Page. 30

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

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


# Page. 31

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

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