EnterpriseZine Day 2026 Summer レポート

イオンのDX推進に向けた「SRE×生成AI」　試して分かった課題と可能性、人間側に求められる変化

IaC管理、可観測性、インシデント復旧の現場で活用

2026/11/16 08:00

通知

IaC復旧・可観測性・インシデント対応で実践、AIを使いこなすための工夫

　イオンスマートテクノロジーにおけるSRE×AIの実践は、主に「IaCによるリソース管理」「可観測性とパフォーマンス分析」「インシデント対応」の3つの柱で展開された。それぞれのフェーズにおいて、直面した課題とAIを活用した克服のプロセスを見ていこう。

1. IaC×AI：検証環境全削除からのリカバリー

　同社は、主要なMicrosoft Azure環境の9割以上をTerraformによってIaC管理している。日常的なコード生成やプロビジョニングにはGitHub Copilotを活用し、プルリクエストに対する自動コードレビューを組み込むことで、高い品質を維持してきた。そんな中、同社SREチームの実行力が試される事態が発生。誤操作により検証環境上の1,000弱におよぶクラウドリソースが一括削除されるというアクシデントが起こったのである。

　幸いにも、Azureのセーフガード機能やMicrosoftの迅速なサポートにより、ストレージやデータベース、仮想マシンのディスクといったデータの実体は手動操作で論理復旧することができた。しかし、本当の困難はその後に待っていたという。

　手動で復旧した既存リソースはIaC側の管理下から外れてしまっているため、そのままTerraformを実行すると競合や上書き破壊が発生する。リソースを再びIaCの管理下に統合するには、Terraform importという高度かつ煩雑な取り込み作業を数百リソース分実行しなければならなかったのだ。そこで、従来の手作業であれば数日を要する復旧作業に対し、SREチームは生成AIをフル活用した。

　まず、「既存のコードにインポートするか、新規にコードを切り出すべきか」という復旧計画の立案段階からAIに相談。方針決定後、AIは数百行におよぶ取り込み用のインポートコードや、IaC管理外のリソースを一括処理するためのシェルスクリプトを生成した。さらに、削除前の状態管理ファイルと実環境のデータを、MCP経由でAIに参照させ、パラメータが削除前と完全に一致しているかの比較レビューまで自動化させた。

　人間とIaCとAIが三位一体となった結果、1日以上かかると予想された複雑な復旧作業が1時間未満で完了した。「AIがあるからIaCが不要になるのではなく、日頃からIaCでコード化していたからこそAIを活用できた」と林氏は語る。

2. 可観測性×AI：New RelicとSlackボットによる「AI窓口」の構築

　システム全体の可観測性向上には、New Relicを全社的に導入している。定期的なダッシュボード勉強会やSSO統合などの普及活動により、利用者は経営層やビジネス部門を含む数百名にまで拡大した。

　しかし、あらかじめ定義されたダッシュボードを見るだけでなく、「特定のAPIの過去1週間のレスポンスタイム推移を抽出する」といった高度なデータ抽出を行うには、専門的なNRQL（New Relic Query Language）の記述が必要。非エンジニア層には、依然として高い障壁があった。

　この課題を解決するため、SREチームはSlack上に可観測性の「AI窓口」となるチャットボットを独自実装した。たとえば、利用者が「iAEONが重い気がするけれど大丈夫？」と自然言語で質問を投げかけると、裏側でAIがシステム構成やドメイン知識を理解し、New Relicから必要なデータをNRQL経由で自動取得・分析して、平易な言葉で即座に要約回答を返す。

　AIのハルシネーション対策と信頼性確保のための工夫にも注目したい。ボットの回答の冒頭には、AIが内部で実際に生成・実行した生のNRQLクエリと、使用した内部ツールの一覧が必ず明記されるよう設計されている。これにより、エンジニアはAIの分析プロセスの正当性を即座に検証でき、人間が最終確認を行うための透明性が確保されている。さらに、GitHubやJira/ConfluenceのMCPとも連携させることで、コードやドキュメントの最新情報を横断的に検索できる総合窓口として機能しているという。

3. インシデント対応×AI：SRE Agent比較と将来像

　インシデント対応の領域では、既存のPagerDutyによる通知フローに加え、各ベンダーが提供している「SRE Agent」を小規模に試用しているという。前提として、昨今MicrosoftやNew Relic、PagerDutyなどの各ベンダーは「SRE Agent」という名称でソリューションを提供しはじめている。名称が似ているため用途などが混同されがちだが、そこには大きな違いがある。

　Azure SRE Agentはクラウド内部のログや構成を直接調査して自動復旧策を提案し、New Relic SRE Agentはアプリからインフラまでの可観測性データを分析。PagerDuty SRE Agentは、障害対応のメンバーの一人として過去の知見を整理し、指揮支援を行う。

　イオンスマートテクノロジーは、これらのエージェント群に対して単一の決定版を求めるのではなく、それぞれの強みに応じた部分採用と検証を継続するアプローチをとっている。「現時点では全面的な採用は難しいという感触だが、各AgentがそれぞれのMCPを活用できるため、可能性は広がりつづけている」と林氏。将来的には、MCPやA2A（Agent-to-Agent）プロトコルを通じてエージェント同士が自律的に連携し合い、人間がそのオーケストレーションを担う高度なインシデント対応体制が実現するかもしれない。