Microsoftの運用AI「Azure SRE Agent」：社内で9か月に35,000件超のインシデントを自律処理、数字の読み方と承認の仕組み

Microsoftが2026年4月5日、自社のクラウド運用で使っているAIエージェント「Azure SRE Agent」の効果を、公式のブログ（Customer Zeroシリーズ）で公開しました。

この事例の読みどころは、数字の大きさより、数字の「条件」と、人間の承認をどこに置いたかです。社内で直近9か月に35,000件超のインシデントを自律的に処理したとされる一方、「自律的に処理した」が何を指すのかは書かれていません。この記事では、公式に書かれていることと書かれていないことを分けて整理します。

この記事は2026年10月6日時点で、Microsoftの公式ブログと公式ドキュメントに書かれている内容だけをまとめています。推測した構成は含めていません。

何が動いているのか

Azure SRE Agent は、公式の説明では「エンジニアの常時稼働のSREパートナーとなる、AI運用エージェント」です。本番環境を継続的に観察してインシデントを検知・調査し、ログ、メトリクス、コードの変更、デプロイの記録を突き合わせて根本原因を分析します。切り分けから解決までを支援し、調査の補助から、対応案の提示まで、自律度を変えて使えるとされています。

一般提供（GA）は2026年3月10日です（同日のGA発表より）。Microsoft自身が運用に使い、そこで得た知見をCustomer Zeroシリーズとして公開しています。

公式に示された数字

• ▸直近9か月（2026年4月のブログ時点）で、35,000件超のインシデントを、Azure SRE Agentが自律的に処理した
• ▸50,000時間超の開発者の時間を節約した（手作業の調査・対応を減らしたことによる）
• ▸Azure App Serviceのライブサイトのインシデントで、緩和までの時間が3分になった。人手のみの平均は40.5時間だった
• ▸Azure Container Appsのエンジニアは、エージェントの根本原因分析の結果におおむね肯定的（89%）で、インシデントの90%超が対象になった
• ▸導入の効果として、オンコールの負担が減り、インシデント時の緩和が速くなったとされている

数字は、公式ブログの記述のままです。ただし、Microsoftの公式発表の中でも、時期によって数字と言葉が違います。
2026年3月10日のGA発表は、自社のサービスで「1,300超のエージェントを展開し、35,000件超のインシデントを緩和（mitigated）し、20,000時間超のエンジニアの時間を節約した」と書いています。
4月5日のCustomer Zeroブログは、35,000件超を「自律的に処理（handled autonomously）」、50,000時間超の節約と書いています。
件数は同じ「35,000+」のままで、時間が20,000+から50,000+に変わっています。集計の時点や範囲が違うのかどうかは、公式資料に説明がありません。

数字を読むときの注意（当サイトの見方）

• ▸「自律的に処理」の定義は書かれていません。解決まで完了した件数なのか、調査や対応案の提示までを自律で行った件数なのかは、公式ブログからは分かりません。同じ「35,000+」が、3月の発表では「緩和した（mitigated）」、4月のブログでは「自律的に処理した」と書かれているので、数えているものが同じかどうかも確認できません
• ▸「3分」と「40.5時間」の比較条件も書かれていません。同じ種類のインシデントか、平均なのか中央値か、「人手のみ」の期間がいつかは、記載がありません。「40.5時間→3分」を、導入すれば自社でも起きる改善と受け取るのは危険です
• ▸効果の範囲が広い数字と、特定の製品チームの数字が並んでいます。3分はApp Service、89%はContainer Appsという、製品ごとの個別の数字です
• ▸これはベンダー自身の運用の報告です。第三者の検証ではありません。自社で使うなら、自社のインシデントで測り直す必要があります

構成：確認できる範囲

Microsoftが公開しているのは、製品としての構成と使い方で、社内の具体的な実装（使っているモデル、内部の構成）は公表されていません。以下は、公式ブログと公式ドキュメントで確認できる範囲です。

5つの拡張点とつなぎ先

• ▸スキル：Runbook（運用手順）やAzure CLIのスクリプトで、エージェントの対応の幅を、コードを書かずに広げる
• ▸カスタムエージェント：運用の領域ごとの専用エージェント。いくつかは最初から用意され、自分で作ることもできる
• ▸Pythonツール：設定ではなく、コードが要る処理やAPI連携のためのもの
• ▸MCPサーバー：Datadog、Splunk、New Relic、Dynatrace、Elasticsearchなどの監視基盤や、Model Context Protocolに対応する任意のツールを接続する
• ▸エージェントフック：ツールを実行した後、エージェントが止まるときなど、ライフサイクルの節目で動く自動処理。ポリシーの適用、テレメトリの出力、外部の承認フローとの連携に使う
• ▸つなぎ先：Azure Monitor・Application Insights・Log Analytics、PagerDuty・ServiceNow、GitHub・Azure DevOps、Azure Data Explorer、Teams・Outlook など

エージェントが提案するツールの実行は、すべて、実行の前にガバナンス制御を通ります。完全に自動化した場合でも、境界は自分たちで決める、と公式は書いています。

人間の承認をどこに置いたか

• ▸自律度を段階で選べる：調査の補助から、対応案の提示、設定による自律的な対応まで。自動で緩和するか、承認を待つかは、設定した「実行モード」で決まる
• ▸レビューモード：管理者が、Runbookの文脈つきの調査の要約を見て、承認が要る操作を承認する
• ▸ツールごとの権限：各ツールを許可（allow）・確認（ask）・拒否（deny）に設定できる。管理者が全体の制限を決め、チームのリーダーがカスタムエージェントごとに調整し、利用者は自分の会話の中でツールを承認する
• ▸ID と権限：マネージドIDで認証し、Azureのロールベースのアクセス制御（RBAC）の範囲で動く
• ▸ネットワーク：仮想ネットワーク（VNet）統合で、エージェントの外向きの通信を自社の仮想ネットワーク経由にできる。2026年6月のBuild 2026でプレビューとして発表され、2026年8月25日に一般提供（GA）になった
• ▸Infrastructure as Code：エージェント、ネットワーク構成、ID、ツールのポリシーを、Bicepテンプレートで展開できる

Microsoft自身が書いている教訓も、承認とセットです。「自律性を、明確な承認の境界、ロールベースのアクセス、安全確認と釣り合わせる必要があった」。

「エージェントでエージェントを作る」という進め方

このブログは、Azure SRE Agent自体を「agentic workflow（エージェントを使った開発）」で作ったことも説明しています。ソフトウェア開発の各段階に、専門のエージェントを置いたとされています。

• ▸計画とコード：仕様を起点にした開発。要件の文書の下書きや、プロトタイプ、ステージングへのコードの登録を支える
• ▸検証・テスト・デプロイ：コード品質のレビュー、セキュリティ、評価、デプロイのエージェントが、品質とセキュリティの問題を前倒しで見つける
• ▸運用と最適化：Azure SRE Agentが、アラートの調査から、対応の支援、一部の自律的な解決までを担う。Azure SRE Agent自体を保守するための専用インスタンスも用意しているとされる

Microsoftが挙げる学び

• ▸エージェントでエージェントを作ることが、規模を出すために欠かせない。手作業の開発が早い段階で詰まりになった
• ▸汎用のエージェントに、豊富な文脈と記憶と学習を与えると、経験を積んで速く、効果的になる。同時に、定型化できる種類のインシデントには、専用のエージェントが、実績のある手順と安全策を組み込んで、再現性を出す
• ▸既存の仕組みに深く組み込む。既存のテレメトリ、ワークフロー、基盤を置き換えるのではなく、その上に知能を足す
• ▸人間の関与を保つ。自律性と、承認の境界・アクセス制御・安全確認の釣り合いが、信頼の鍵になった
• ▸継続的なフィードバックと評価を投資する。自動化が価値を足した場所と、人間の判断を中心に残すべき場所を測る

確認できなかったこと

• ▸使われているモデルや、社内の具体的な構成。公式ブログにも公式ドキュメントにも書かれていません
• ▸「自律的に処理」の定義、「3分」と「40.5時間」の比較条件、インシデントの種類別の内訳
• ▸2026年4月以降の数字の更新。Build 2026（6月）の発表は、「提供範囲が急速に広がった」と書くにとどまり、同じ指標の新しい数字は載せていません
• ▸導入の費用と、エージェント自体の運用の負担。公式の資料にはありません

この事例から持ち帰れること（当サイトの見方）

• ▸「自律」と「承認」を、同じ設計の中で決める。この事例では、実行の前にツールごとの許可・確認・拒否を通し、レビューモードで承認を挟むことができます。自動化の範囲を広げる話と、止める境界の話は、同時に設計されています
• ▸成果の数字は、条件ごと持ち帰る。「35,000件」「3分」を借りるなら、何を数えたのか、何と比べたのかを一緒に確認してください。公式ブログはそこまで書いていません
• ▸既存の運用ツールに差し込む。アラート、チケット、リポジトリ、監視基盤とつなぐ作りで、運用の手順を置き換えずに上へ足す考え方です
• ▸自社で測り直す。これはベンダー自身の報告です。自社の最初の1か月は、少数の種類のインシデントから、人手の時間と比べて測るほうが、実態に近づきます

根拠にしたページ