Azure AIによるエージェント型運用の実験管理

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

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

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

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

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

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

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

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

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

• https://huggingface.co/blog/ibm-research/itbench-aa

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

エージェントには何を聞く 実行ではなく、調査・復旧の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

そこで「実験管理」に置き換える 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

モデルごとの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

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

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

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

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

次回：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

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

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

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

• https://dotnetlab.connpass.com/event/400124/