コーディングエージェントからクラウド自動化へ：Azure Functions におけるAIを活用した顧客インシデント対応
自分が MSの公式のブログとして、同僚の２人と一緒に書いたので、折角なので日本語にしておきました。
APPS ON AZURE BLOG | 約10分で読めます
著者: Tsuyoshi_Ushio (Microsoft)
公開日: 2026年5月20日 | 更新日: 2026年5月19日
原文: https://techcommunity.microsoft.com/blog/appsonazureblog/from-coding-agents-to-cloud-automation-ai-assisted-customer-related-incidents-in/4516112
タグ: azure functions, azure sre agent, customer zero
Microsoft の「Customer Zero」ブログシリーズでは、Microsoftが自社の信頼性の高いエンタープライズグレードのIQプラットフォームを使ってどのように構築・運営しているかを内側から紹介しています。エンジニアリングチームのベストプラクティス、実際の現場から得た教訓、アーキテクチャパターン、そしてAIアプリやエージェントフリートを組織全体で構築・運用・スケールするための実証済みソリューションの運用戦略を学んでください。
Azure Functions チームでは、AIが顧客から報告されたインシデントの調査、根本原因分析（RCA）、およびインシデントの軽減にどのように役立てられるかを探ってきました。この記事では、初期のRCAエージェントからコーディングエージェントを活用した調査、そしてクラウドホスト型自動化へと至る私たちの歩みと、その過程で得た教訓を共有します。Azure Functions のような Microsoft エンジニアリングチームは、顧客から報告された問題と並行して本番環境のライブサイト問題にも取り組んでおり、これらはこの仕事の中で最も重要でやりがいのある部分のひとつです。
Azure Functions チームでは、複雑な顧客インシデントには深い調査が必要です。エンジニアは Azure Data Explorer（Kusto）のクエリ結果、ソースコード、GitHub Issues、過去のインシデント、公開ドキュメント、社内のトラブルシューティングガイド、およびサービス固有の運用知識をレビューします。目標は常に、顧客への影響を迅速に軽減し、根本原因を特定し、そこから学んだことをプラットフォームにフィードバックし、必要に応じて改善作業のワークアイテムとして記録することです。
この作業は価値がありますが、時間もかかります。AI の能力が向上するにつれ、私たちは実践的な問いを立てるようになりました。AIはインシデント調査の運用負担を軽減しつつ、調査を有意義なものにしている学習とエンジニアリング上の判断を保持できるのでしょうか？
これは、私たちのアプローチが初期のRCAエージェントから、コーディングエージェントベースのワークフローへ、そして最終的にクラウドホスト型自動化へと進化した物語です。
AIを活用したRCAの始まり
2024年5月頃、私たちは Microsoft Research の同僚とともに社内RCAエージェントの実験を始めました。最初のバージョンは、正式なサービス開発に向けた非公式なアプローチでした。私たち自身の調査を支援するための個人的なツールでした。
初期の実験は非常に有益でした。エージェントにインシデントを渡し、数分間動作させ、その後分析結果をレビューするというプロセスです。常に完璧な根本原因を特定できたわけではありませんが、複数のクエリを実行し、さまざまな仮説を検証し、解決空間を十分に絞り込んで時間を節約することができました。
その後、Azure SRE Agent が正式な社内サービスとして登場しました。私たちは初期の実験から学んだことをもとにこれに貢献しました。その時点で、AIを使って顧客から報告されたインシデントを解決することがチームにとって主要なフォーカスになりました。
エージェントワークフローから学んだこと
AIを活用したインシデントワークフローの第一世代は、高度に構造化されていました。利用可能なモデルを使った初期実験では、特に複雑なKustoクエリの生成において慎重な設計が必要でした。多くの場合、固定されたKustoクエリをツールとして公開し、モデルが明確に定義されたパラメータを通じてそれらを呼び出せるようにする必要がありました。
図1 Kustoクエリツール
これにより実行の予測可能性と再現性が高まりましたが、同時に限界も明らかになりました。詳細なエージェントワークフローは、インシデントが事前定義されたパスに合致する場合にはうまく機能しました。しかしそのパスから外れると、柔軟性が低下しました。また、エンジニアはこうしたワークフローの定義と保守が負担であり、アウトプットがダッシュボードとほとんど変わらないと感じることもありました。
図2 エージェントワークフロー
この経験から重要な教訓を得ました。複雑な運用調査においては、構造と同様に柔軟性が重要であるということです。
コーディングエージェントへの転換
2025年末頃、私たちは GitHub Copilot とスキルを活用した社内ツールを使い始めました。このツールにより VS Code ワークスペースを定義・共有することが可能になりました。ワークスペースには、エージェント定義、指示、プロンプト、スキル、MCP設定、およびリポジトリを含めることができます。
図3 GitHub Copilot 社内ツール
品質の差は歴然としていました。新しいモデルと組み
合わせることで、コーディングエージェントははるかに柔軟にインシデントを調査できるようになりました。Kustoクエリの実行、コードの検査、CLIやMCPツールの使用、そして異なるアプローチを素早く試すことができます。
チームはこのモデルを迅速に採用しました。以前のワークフローベースのシステムでは、詳細なワークフローの定義に労力がかかり、見返りが限定的だったため、エンジニアはオンボーディングに消極的でした。この社内ツールでは、システムが拡張しやすいため、エンジニアがエージェント定義やスキルを積極的に貢献するようになりました。時間をかけて、Azure Functions チームはエージェント定義、スキル、MCPツール、指示、リポジトリからなるAIレディな資産を蓄積していきました。
そこからいくつかの重要な教訓が浮かび上がりました。
AIレディな資産構築から得た教訓
1. 詳細な仕様よりもガイダンスを優先する
現代のコーディングエージェントは、すべての手順を事細かに指定しなくても十分に機能します。むしろ、指示が多すぎるとシステムが脆くなったり陳腐化したりする可能性があります。大量の詳細をプロンプトに直接埋め込むよりも、簡潔なガイダンスを提供し、保守されている信頼できる情報源を指し示す方が効果的であることがわかりました。
2. コンテキストを意識的に管理する
指示、ツール定義、会話履歴、ツールの出力はすべてモデルのコンテキストを奪い合います。無関係または矛盾する情報は品質を低下させる可能性があります。ツールの設計も重要です。ツールが大量のデータを直接モデルに返すと、多くのトークンを消費してエージェントを混乱させる可能性があります。大きな出力については、結果をファイルに書き出し、簡潔なポインタを返す方が効果的です。
3. ファイルを永続的なメモリとして活用する
長期間の調査では、シンプルなパターンが有効です。計画とチェックリストのファイルを作成し、作業の進行に応じて更新し、必要に応じてエージェントが再読み込みできるようにします。これにより、エージェントはコンテキストの圧縮から回復でき、調査がワークスペース内で永続的な状態を持てるようになります。
4. 知識をインラインに埋め込むより参照を優先する
エージェント定義とスキルにはドメイン知識が含まれます。社内トラブルシューティングガイド、製品の動作、運用履歴、専門家の判断などです。これらの情報をすべてプロンプトに直接記述するのではなく、知識がどこにあるかへの参照と、それをいつ使うかのガイダンスを提供する方が効果的であることがわかりました。
5. 適切なリポジトリを見えるようにする
コーディングエージェントはコードの読み取りが得意です。私たちのシナリオでは、複数のリポジトリにまたがるワークスペースが特に強力でした。エージェントが関連するリポジトリをまとめて参照できる場合、コンポーネント間での動作を追跡し、依存関係を理解し、より優れた分析を生成できます。
6. ドメイン知識が最も重要
最良のエージェント資産は、AIの専門家ではなく、製品と運用の深い経験を持つエンジニアが作成することが多かったです。重要なスキルは、専門知識をエージェントが活用できる指示、参照、リポジトリレイアウトに変換することでした。
7. ドメイン知識の更新を促進・効率化する
エージェントが完全に対応できなかったインシデントは、すべて学習の機会です。コンテキストエンジニアリングのフライホイールを回し続けましょう。調査し、ギャップを見つけ、エージェントのガイダンスを更新し、再テストする。このサイクルを迅速かつ簡単に保つことが重要です。
クラウド自動化へ移行した理由
コーディングエージェントは非常に役立ちましたが、それでもインタラクティブなツールでした。エンジニアが調査を開始し、多くの場合それを誘導する必要がありました。
インシデント対応においては、さらに先へ進みたかったのです。インシデントが特定の機能領域に入ったとき、システムが自動的に調査を開始し、関連する分析を実行し、有用な結果をインシデントに返せるようにしたいと考えていました。分析が完璧でなくても、早い段階で問題空間を絞り込むことで軽減時間を短縮できます。一部のシナリオでは、最終的に自動軽減または適切なチームへの自動転送をサポートできるかもしれません。
ローカルのコーディングエージェントワークフローには、ユーザーとして認証できるという利点があります。しかし、信頼性の高い自動化の基盤としては、重要な制約もありました。
第一に、依然として人間の関与に依存していました。 AIは個人の生産性を劇的に向上させましたが、インシデント対応のボトルネックは多くの場合、人間の注意力と時間です。エージェントの起動が簡単であっても、エンジニアが実行を開始する必要があることは、コンテキストスイッチを引き起こし、希少なリソースを消費します。
第二に、ユーザーの資格情報に依存していました。 コーディングエージェントはユーザーの権限で実行されますが、これは自動化には広すぎる可能性があり、ブラウザベースの再認証などの人間向けフローを継承します。永続的な自動化のためには、マネージドIDのような無人実行に適したIDモデルが必要でした。
第三に、実行環境とセキュリティに関する懸念がありました。 ローカル環境は強力ですが、安全な自動化のために必要なサンドボックスを自然には提供しません。ユーザーアクセスで実行されるため、自動化されたインシデントワークフローに望ましい以上に広範なファイルやリソースにアクセスする可能性があります。ローカルおよびdev-box環境には運用上の欠点もあります。再起動が必要になったり、他のワークロードと競合したりすることがあり、永続的な実行、障害回復、またはフェイルオーバーには適していません。自動化のためには、エンジニアのマシンに依存しない専用の実行環境が必要でした。
最後に、トークン管理が運用上の懸念になりました。 ユーザーに紐付いたトークン消費は、制限に達すると不安定になる可能性があり、自動化によって1人のユーザーが不釣り合いな量のAI容量を消費しているように見える使用パターンが生じることがあります。これは運用分析にノイズを加え、ガバナンスを困難にします。
これらすべての理由から、クラウド実行が正しい方向性だと考えました。マネージドID、セキュアなサンドボックス、永続的な実行、そして誰かのローカルマシンに依存しないシステムが必要でした。
クラウド自動化への要件
私たちの多くはコーディングエージェントの強力な支持者となっており、引き続き使用したいと考えていました。同様に重要なのは、実績のある資産をすでに蓄積していたことです。エージェント定義、指示、プロンプト、スキル、MCP設定、そしてチームが徐々に構築・改良してきたリポジトリレイアウトです。
つまり、クラウド自動化への移行は、コーディングエージェントを完全に別のものに置き換えることを意味しませんでした。コーディングエージェントを成功させた資産を保持・再利用しながら、自動化に適した実行モデルに移行することが目標でした。
同時に、コーディングエージェントは高い品質基準を設定していました。実際にうまく機能していたため、クラウドサービスが自動的に同レベルの品質を提供できると仮定することはしませんでした。そこで、クラウドへの移行に向けて2つの具体的な目標を定めました。
- 集中した一回限りの調査として実行した場合に、既存のコーディングエージェントワークフローで見られていたのと同等の品質を達成すること。
- すでに構築した資産を引き続き使用・改善できるようにすること。
言い換えれば、単なる別のクラウドAIシステムを求めていたわけではありません。コーディングエージェントの強みを継承しながら、自動化に必要な運用特性を備えたクラウド自動化の道を探していました。
ヘッドレスコーディングエージェント実行サービスとAzure SRE Agent の比較
これらの要件を満たせるアプローチを評価するために、並列比較を実施しました。
一方のアプローチは、プロトタイプのヘッドレスコーディングエージェント実行サービスです。エンジニアがローカルで使用していた社内ツールのワークスペース定義を再利用しますが、人間のループなしに実行します。インシデントが対象ループに入ると、システムはエージェントワークスペースを作成し、リポジトリを準備し、初期プロンプトで GitHub Copilot CLI を起動し、分析を収集して、結果をインシデントに返します。また、エンジニアが後で調査をレビューまたは再開できるように、セッションアーティファクトを保持します。
図4 エージェント支援トレンド – コーディングエージェントの使用、ヘッドレスコーディングエージェント実行サービスとSREエージェントの導入により、有用性の割合が増加していることを示しています。
もう一方のアプローチは Azure SRE Agent を使用しました。以前の実験以来、プレビュー顧客のフィードバックにより改善され、一般提供（GA） に近づいていました。新しいモデル、より強力なカスタムエージェント動作、MCPおよび組み込みツール、リポジトリアクセス、インシデントトリガー実行をサポートするようになっていました。私たちはコーディングエージェントの資産から Azure SRE Agent の資産への一回限りの移行を実施しました。これは GitHub Copilot CLI と既存のコーディングエージェントを使用して1日で達成しました。
比較は意図的に実践的なものにしました。社内のコーディングエージェント環境がエンジニアから信頼され支持される結果を生み出すことはすでに知っていました。それが品質基準となりました。Azure SRE Agent がその基準を満たすか上回りながら、クラウド自動化の運用要件も満たせるなら、より強力な長期的な道となるでしょう。
結果とフィードバックループ
ヘッドレスコーディングエージェント実行サービスの最初の結果は非常に有望でした。最初のインシデントセットにおいて、エージェントが安全に処理できたケースでは、RCAがSME（Subject Matter Expert）の結論と一致しました。これは、ローカルのコーディングエージェント向けに構築した資産がヘッドレスシナリオに効果的に転用できることを示しました。
Azure SRE Agent も最初から強力なパフォーマンスを発揮しました。ヘッドレスコーディングエージェント実行サービスは一部の領域で当初わずかに優れた分析を示しましたが、Azure SRE Agent はすでに運用上十分に有用なレベルに達していました。
その後、以下を比較する評価フレームワークを構築しました。
- 各エージェントのRCA、信頼スコア、軽減手順
- 後に人間が提供したRCAと軽減理由
- 自動軽減推奨
- 自動軽減への道筋
- 自動転送推奨
- セッションレベルの実行上の問題
この評価がフィードバックループになりました。エンジニアが興味深いインシデントをレビューし、弱点を特定し、エージェント定義とスキルを改善し、プルリクエストを提出しました。また、比較レポートから改善PRを生成するためにエージェント支援も活用しました。
図5 LLM as Judge によるヘッドレスコーディングエージェント実行サービス（青）vs Azure SRE Agent（緑）の並列評価
数週間以内に、Azure SRE Agent の品質はヘッドレスコーディングエージェント実行サービスのベースラインを継続的に上回るようになりました。その時点で、ヘッドレスの結果をインシデントに返すことをやめ、Azure SRE Agent のパスの改善に集中しました。また、社内のコーディングエージェント資産からの同期を自動化し、改善がプルリクエストを通じて継続的に反映されるようにしました。
この転換は重要な意味を持ちました。Azure SRE Agent は単なる興味深い代替手段ではなく、コーディングエージェントで機能したものを継承しながら、自動化のためのより良い基盤を提供するクラウドへの道となったのです。
クラウドAIがうまく機能するようになった理由
コーディングエージェントに対する一般的な反応は、以前のクラウドAI体験より大幅に改善されているというものです。私たちの経験から、主に2つの理由があると考えられます。より強力なモデルと、適切なコンテキストへのアクセスの改善です。
コーディングエージェントはワークスペースを見ることができます。指示、スキル、ツール、リポジトリ、ファイルを使用できます。従来のクラウドAIシステムは、同じリソースへのアクセスを持っていないことが多かったです。Azure SRE Agent が同様の資産、つまり適切なリポジトリ、適切なツール、適切なドメイン固有の知識を参照できるようになると、同等またはそれ以上の品質に達することができました。
コンテキスト圧縮、ツール実行、オーケストレーションの詳細は重要です。しかし、核心的な原則はよりシンプルです。エージェントは、不要なコンテキストを常に抱え込まずに、適切なタイミングで適切な知識にアクセスする必要があります。
つまり、最も重要な作業はモデルを選択したりツールを構築したりするだけではありません。高品質なAIレディな資産を作成することです。簡潔な指示、有用なスキル、正確な参照、適切に構造化されたリポジトリアクセス、そしてかつて人々の頭の中にだけ存在していたドメイン知識です。
クラウドホスト型自動化パスは、即座に大きな利点をもたらしました。問題分析がクラウドに保存され、開発者のマシン上だけでなく誰でもアクセスできるようになったことです。つまり、結論と調査がいつでも参照できる形で保存され、チャットインターフェースを通じた人間との対話も可能になります。
図6 Azure SRE Agent のチャットインターフェースの例
まとめ
私たちの旅は個人的なRCAアシスタントから始まり、構造化されたエージェントワークフローを経て、コーディングエージェントで加速し、最終的にクラウドホスト型自動化という道に戻ってきました。
教訓はコーディングエージェントやクラウドエージェントが普遍的に優れているということではありません。エージェントの品質は、エージェントが何を参照できるか、どれだけ無関係なコンテキストを避けられるか、そしてドメイン専門家が自分たちの知識を使いやすい資産に変換しているかどうかに大きく依存するということです。
私たちにとっての鍵は、コーディングエージェントを捨てることではありませんでした。その強みを Azure SRE Agent と、自動化により適したクラウド実行モデルへと引き継ぐことでした。
現代のエージェントは、その取り組みを価値あるものにするのに十分な能力を持っています。インシデント対応においては、より迅速な調査、より安全な自動化、そして最終的には顧客のインシデント軽減時間の短縮への扉が開かれます。
Azure Functions チームは、この経験が複雑なエンジニアリング運用にAIを適用する方法を模索している他のチームにとって有益であることを願っています。
次の記事では、評価フレームワークとこれらの改善の背後にあるフィードバックループをどのように自動化したかについて、より深く掘り下げる予定です。