---
title: Azure AIによるエージェント型運用の実験管理
tags:  #生成ai #azure #aiエージェント #システム運用  
author: [Kento Yamada](https://image.docswell.com/user/ymd65536)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/G78DMXQL7D.jpg?width=480
description: .NETラボ 勉強会 2026年9月 https://dotnetlab.connpass.com/event/399503/  Microsoft ignite 2026でCfPで採択されなかった内容について話しました。次回はさらに踏み込んで話します。
published: September 26, 26
canonical: https://image.docswell.com/s/ymd65536/5Y86NE-2026-09-26
---
# Page. 1

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

Azure AIによるエージェント型運用の実験管理
.NETラボ 勉強会 2026年9月
1


# Page. 2

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

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


# Page. 3

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

Microsoft ignite 2026、Speaker CfP 応募落ちました
3


# Page. 4

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

どんな内容（本日の話に直結）
タイトル：
Optimizing Inference Efficiency through Incident Response Experiments
（インシデント対応実験を通じた推論効率の最適化）
概要（このテーマで語る予定だったこと・問題提起）：
● エージェント型運用、エージェントによって運用されるサービスにおいて、エー
ジェントがどのような動きをするのかを管理して推論効率を最適化
● MLの実験管理を応用してエージェントの動きを記録、エージェントの動きを数値
ベースで観測
● 最終的にエージェントが適切な運用成果を挙げられているかを計測
4


# Page. 5

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

ちなみに反省点
実験管理の話をするんだったら、実験管理のプラットフォームについて言及しておく
べきだった。※なぜか、Foundryだけで挑もうとしていた。
我らがマブダチのAzure Databricksを呼ぶのが最善手だった気がしています！
※実験管理と来ているので心強い味方として呼ぶべきだった。すまんって。
5


# Page. 6

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

ということで前回の話から今回の話へ
自律型運用は「AIに全部任せる」ことではない
前回のテーマ
Azure AIエージェント
推論効率
切り分けが必要
クラウド運用を自律化
システム運用を自律化
● モデルを呼ぶ
● ルールベース
● 静観で処理
意思決定
AIエージェントの責任
範囲と人間・ルールに残
す範囲を設計
自律型運用では「どこでAIを使うか」が最初の設計になる。
● どのように使うかという点
● どのように使われたかという点
6


# Page. 7

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

インシデント対応を分解する
「復旧できたか」だけでは、どこが良かったのか・悪かったのか分からない
Incident
Planning
Execution
Verification
Recovery
今回はここにフォーカス
Planningを独立して評価することでモデルの「考え方」を比較できる
次回は作成したPlanに対してAgentが正しくExecutionできるかを評価する
7


# Page. 8

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

賢いモデルなら、インシデント対応もうまいのか？
ベンチマークではフロンティアモデルでも高い成功率を出せるとは限らなかった。
※前回紹介したHugging Faceのブログより
モデルの賢さ
Model Intelligence
LLM
インシデント対応の品質
Incident Response Quality
≠
IR
モデルの賢さ以外に、インシデント対応としての評価基準が必要
8


# Page. 9

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

引用：フロンティアモデルによるインシデント対応
引用：https://huggingface.co/blog/ibm-research/itbench-aa
フロンティアモデルによるインシデント対応は50%未満のベンチマーク
9


# Page. 10

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

インシデント対応では「仕事のやり方」を見る
成功・失敗だけでなく、どの手順を選び、どれだけ余計なことをしなかったかを見る
正しい手順
最短経路
Runbookや調査順序が妥当か
必要な調査だけで原因へ近づける
か
不要操作
利用量
再起動や変更をむやみに行わない
か
MCP・DB・Log scanなどの呼び出
し回数
「解決した」だけでは、良いインシデント対応だったとは言えない
10


# Page. 11

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

Planningを評価する
AIエージェントに本番VMを触らせる前に、まず「何を調べ、どう直すか」を評価する
Incident
Planning
Execution
今回
評価したいこと
同じIncident Definitionと同じ環境条件を与えたとき
モデルごとに妥当なインシデント対応計画を立てられるか
11


# Page. 12

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

こんな構成があるとする
Azure VM + nginx という単純な環境から始める
User
HTTP
Request
前提 • 通常はHTTP 200を返す
nginx
Azure VM
200 OK
通常時
404 Not
Found
• ある時点から404が発生
• 初期情報は最小限にする
• 実際の操作は行わない
12


# Page. 13

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

良いPlanは「TODOリスト」ではない
観測結果によって次の行動を変えられることが重要
404を確認
Access / Error
Log
Yes
location / root /
resourceを調査
No
上流Routingを調査
nginxに到達？
仮説 → 観測 → 分岐 → 最小限の変更、という構造を持てるか
13


# Page. 14

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

計画品質（Planning Quality）をどう評価するか
今回は「計画の品質」を複数の観点で採点する
Correctness
Efficiency
Safety
原因究明につながる手順か
余計な調査や重複が少ない
か
破壊的操作を早期に選ばな
いか
Relevance
Branching
Verification
404という事象に関係する
調査か
結果に応じて次の行動を変
えられるか
復旧確認まで計画に含める
か
14


# Page. 15

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

で、Azureではどうなん？Microsoft Foundryの話
←実はある！
引用：https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/agent-evaluators
Microsoft Foundry Agent evaluatorsより
15


# Page. 16

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

Microsoft Foundryによるエージェントの評価
おおむね3つの評価項目
● システム評価
● プロセス評価
● 品質評価（プレビュー）
16


# Page. 17

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

システム評価
評価項目
説明
インシデント対応例
タスク完了
依頼されたタスクを完全に完了したか
インシデントを解決できたか
顧客満足度
パフォーマンスにどの程度満足するか
運用担当者がその回答を実際の
障害対応に使えると判断できる
か
タスク遵守
指示書に記載された規則と制約事項に
従ったか
Runbookを守ったか。
タスクナビゲーション
の効率性
期待される手順を効率的に実行したか
ログ確認→設定確認→原因切り
分け、のように無駄なく原因へ
近づけたか
意図解決
ユーザーの意図を正しく識別して対応し
たか
「404を直したい」という依頼
を単なるHTTP説明ではなく復
旧すべきIncidentとして理解し
たか
17


# Page. 18

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

プロセス評価
評価項目
説明
例
ツール呼び出しの正確性
重複なく正しいパラメータを使用し curl やログ検索を必要な回数
て適切なツール呼び出しを行ったか だけ正しいパラメータで実行し
たか
ツールの選択
適切かつ必要なツールを選択したか 404調査なのにいきなりVM再
起動ではなく、まずnginxログ
や設定確認を選べたか
ツール入力の正確性
ツール呼び出しに正しいパラメータ 対象URL、VM、ログ期間、設
を提供したか
定ファイルの指定が正しいか
ツール出力の活用
推論および最終応答において、ツー nginx error logの内容を次の調
ル呼び出しの結果を正しく使用した 査・判断に正しく反映したか
か
ツール呼び出しの成功
ツール呼び出しは技術的なエラーな CLI / MCP / Log queryが技術
く成功したか
的エラーなく成功したか
18


# Page. 19

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

品質評価（プレビュー）
評価項目
説明
例
関連性
回答はユーザーの質問に関連し 404に関係するログ、route、
ているか
document root、upstream設
定などを優先しているか
棄権（キャンセル）
回答すべきでない場合、適切に 無理に修復せず追加調査や
棄権しているか
Human escalationを選べるか
回答の完全性
ユーザーの質問に完全に答えて 調査だけでなく、復旧方法と復
いるか
旧確認まで含んでいるか
根拠の明確さ
回答は提示された文脈に基づい 観測されたログや設定値を根拠
ているか
に判断しているか
文脈の網羅性
回答は文脈における関連情報を Incident情報、環境条件、
活用しているか
Runbook、過去事例など利用可
能な文脈を適切に使っているか
19


# Page. 20

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

Foundryの評価項目とインシデント対応エージェント
System
Evaluation
Process
Evaluation
Quality
Evaluation
System Evaluation = 効率良く仕事を完遂できたか
Process Evaluation = どう仕事を進めたか。何を使ったか。
Quality Evaluation = 判断はどうか回答はどうか
20


# Page. 21

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

インシデント対応の実験管理とは
21


# Page. 22

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

インシデント対応の実験管理とは
AIエージェントによる1回の対応をExperimentとして記録
● 判断・手順・利用したツール・推論コスト・結果を同じ条件で比較
● その結果を、モデル選択やRouting Policy、運用改善に反映
今回の範囲では1回のIncident Planningを1 Experimentとして扱い
モデルごとの計画品質・推論効率・安全性を比較する。
22


# Page. 23

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

前提：モデル比較では「スタート地点」を揃える
条件が違えば、結果を比較しても意味がない
Incident
Fixed Test Case
Model A
同じ条件を
すべてのモデルに投入
Model B
Environment
Prompt
Available Tools
Output Format
Model C
再現可能な比較
23


# Page. 24

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

エージェントには何を聞く
実行ではなく、調査・復旧のPlanを出力させる
Environment
- Azure VM
- nginx installed
- HTTP endpoint normally returns 200 OK
- Current response is 404 Not Found
- No other information is initially available
Question
You are responsible for incident response.
What would you investigate and in what order?
Do not perform any actions. Return an investigation and recovery plan.
同じPrompt / 同じ前提 / 同じ出力条件
24


# Page. 25

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

そこで「実験管理」に置き換える
Agentの1回のPlanningを、1つのExperimentとして記録する
Experiment #001
Model
GPT / Claude / Gemini / Small Model
Incident
nginx returns 404
Runbook / Prompt
v1.0
Plan Score
Correctness / Efficiency / Safety / ...
Latency
Planningに要した時間
Tokens / Cost
必要に応じて補助指標として記録
比較可能
再現可能
改善可能
25


# Page. 26

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

モデルごとのPlanを比較する
同じIncidentでも「仕事のやり方」はモデルによって変わる
Model A
Model B
Small Model
Correctness
92
94
86
Efficiency
88
82
90
Safety
96
95
91
Latency
3.8s
5.1s
1.6s
「一番賢いモデル」ではなく「この仕事に十分なモデル」を探す
26


# Page. 27

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

実験結果によってわかること
27


# Page. 28

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

実験結果からModel Routerへ
タスクごとに必要な能力が違うなら使うモデルも変えてよい
Log
Classification
Small Model
Runbook
Planning
Model Router
Root Cause
Analysis
Quality × Latency × Cost × Risk
Mid Model
Frontier Model
業務に合わせて、適切なLLMへルーティングする
28


# Page. 29

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

では、そのルーティングルールはどう決める？
「ルーターを探すためのルーター」ではなく、Evaluation Layerとして整理する
Experiments
Evaluation
Routing
Policy
Model Router
ポイント
実験結果をもとに「どのタスクをどのモデルへ流すか」という
Routing Policyを更新していく
29


# Page. 30

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

Agentic Operationsの評価ループ
Agentだけではなく、EvaluationとExperiment Managementを含めて設計する
Incident
Task
Model
Router
Agent
Tools / MCP
Policy
update
Plan / Result / Metrics
Experiment
Management
System
Evaluation
30


# Page. 31

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

次回：PlanからExecutionへ
Planningを評価した次は、その計画どおりAgentが行動できるかを見る
Planning Evaluation
Tool Execution
今回
次回
Can the agent make a
good plan?
Can the agent follow the
plan correctly?
Actual Recovery
Did the system
actually recover?
31


# Page. 32

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

まとめ
今回の焦点は「Agentの意思決定を測る」こと、Foundryでも可能
1. Planningを分離
2. 実験として記録
3. Routingへつなぐ
インシデント対応を
PlanningとExecution
に分け、まず計画その
ものを評価する
同じ条件で複数モデル
を比較し、計画品質や
推論効率を実験単位で
残す
一番賢いモデルではな
く、タスクに十分なモ
デルを選択する
モデルの賢さではなく、仕事との適合度を測る
32


# Page. 33

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

おまけ：実験管理は一般的な業務でも応用可能
今回の話：
自律型運用におけるAIエージェントの振る舞いを実験管理して保存する。
応用例：
何が得意なのかを把握（実験管理の内容を理解）したうえで仕事をしてもらう。
Agentic Operations → General Business Operations
33


# Page. 34

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

次回予告
● .NETラボ 勉強会 2026年10月
○ https://dotnetlab.connpass.com/event/400124/
虎ノ門ヒルズビジネスタワー、弊社のオフィスでやります！
34