KDDI が実践する AWS DevOps Agent 活用：AWSサポートと連携したインシデント対応の効率化

本ブログは、KDDI 株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 アライアンスシステムグループ 中野 利彦 氏、久保田 剛史 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 マネージドサービスを組み合わせたサーバーレスアーキテクチャは開発・運用の効率化に大きく貢献する一方で、複数サービスにまたがる複合的なインシデントへの対応は依然として難しい課題です。今回は、KDDI株式会社（以下、KDDI）が AWS DevOps Agent を活用し、インシデント対応のリードタイムを大幅に短縮した取り組みをご紹介します。AWS DevOps Agent は、インシデント発生時に自律的にメトリクス・ログ・デプロイ履歴を横断分析し、根本原因の仮説と対応案を提示する AI エージェントです。AI を「答え合わせ」のパートナーとして位置づけることで、精度と速度を両立した新しいインシデント対応ワークフローの実践例をご紹介します。

導入背景

KDDI は通信事業を基盤としながら、au PAY・Pontaポイント・エンタメ・エネルギーなど、ユーザーの生活に密着した多彩なサービスを展開しています。今回ご紹介するのは、そのパーソナル事業を支えるシステムの一つ、Web サービス向けのビジネスロジックプラットフォームです。このシステムは、Webフロントシステムに対するポイントの集計や抽選などのリワードの提供・エンタメサービス連携など、多彩なサービスを提供しており、サーバーレスアーキテクチャを採用しています。AWS Lambda によるリクエスト処理、Amazon RDS Proxy を介したデータアクセス、データレイクへの蓄積を軸に、複数の外部システムと SFTP 連携による大量ファイル分析も行う大規模な構成です。

本プラットフォームで、Amazon API Gateway の 5XX エラーと AWS Lambda のスロットリングが複数の Lambda で同時発生するインシデントが起きました。オンラインリクエストの応答に支障をきたすインシデントです。リクエスト数は急増しておらず、スロットリング発生を起点に特定の Lambda の処理時間が高止まりするという挙動から、AWS Lambda / Amazon RDS Proxy / Amazon Aurora にまたがる複合的な問題が疑われました。

こうした複数のマネージドサービスが絡む問題は、ユーザー側では深いところまで把握できないため原因の特定が難しく、メトリクスやログのやり取りを繰り返しながら数週間を費やすことも珍しくありませんでした。たどり着いた対応策が暫定的なものにとどまり、再び同じ調査ループに入ってしまうケースも少なくありませんでした。

ソリューション：AWS DevOps Agent を「先行調査官」として活用する

この課題を打開するために、本プラットフォームの運用チームでは AWS DevOps Agent を試験的に導入しました。

AWS DevOps Agent は、2025年12月の AWS re:Invent でパブリックプレビューとして発表され、2026年3月31日に一般提供が開始されたサービスです。アラートが発生した瞬間から自律的に調査を開始し、Amazon CloudWatch をはじめ Datadog・Dynatrace・Grafana・New Relic・Splunk などのオブザーバビリティツール、CI/CD パイプラインのデプロイ履歴、ソースコードリポジトリなど複数の情報源を横断的に分析して根本原因の仮説と対応案を提示します。プレビュー期間中の実績では、MTTR を最大75%削減、調査時間を 80% 短縮、根本原因の特定精度 94% という効果が報告されています。

特徴的なのは、チャットで深掘りしながら精度を上げていける点です。AWS DevOps Agent は誤った推論をした場合もチャット上で指摘・修正できるため、一方的に出力を受け取るのではなく、対話を重ねながら仮説の精度を高めていくことができます。また、ソースコードや設定値、ログを統合的に分析できるため、AWS Lambda の autocommit 設定と Amazon RDS Proxy の挙動の関係など、単一のメトリクスだけでは見えにくい問題箇所も特定しやすくなりました。

重要なのは、AWS DevOps Agent の出力をそのまま正解として扱うのではなく、「AWS サポートへの問い合わせ前の仮説整理ツール」として位置づけた点です。AWS DevOps Agent が提示した対応案を持って AWS サポートに問い合わせ、「この提案の有効性を確認したい」「他に見落としている観点はないか」という形で対話することで、サポートとのコミュニケーションが格段にスムーズになりました。

AWS サポートとの連携が変わった

従来は、インシデント発生後に KDDI の運用チームが個別にメトリクス・ログを分析し、AWS サポートへ問い合わせ、追加情報の提供と原因調査を繰り返すサイクルに数週間を費やすこともありました。対応策の効果が限定的な場合は最初のステップに戻るループも発生していました。

AWS DevOps Agent の導入後は、このやり取りの質が大きく変わりました。従来は「何が起きているかを一から説明する」ところから始まっていたやり取りが、「AWS DevOps Agent からこういう提案が出ているが、この観点は正しいか」という形に変わりました。AWS DevOps Agent で原因調査・複数対応案の策定・初期有効性判断を先に行い、その結果をもとに AWS サポートへ「答え合わせ」的に問い合わせることで、双方が同じ情報・同じ仮説を共有した状態で議論できるようになりました。根本原因分析の共有コストが下がり、複数の対応案を同時並行で検証環境に適用できるため、全体のリードタイムを数日単位に圧縮することができました。

AWS DevOps Agent の「Ask for human support」機能からサポートケースを作成することで、調査ログが自動的に AWS サポートへ共有されるため、調査内容の全文を手動で説明する手間がありません。AWS DevOps Agent が客観的な第三者として仮説を整理し、KDDI の運用チームと AWS サポートがその仮説を検証・補強するという三者の役割分担が自然に生まれました。AI が大量のメトリクス・ログ・設定値を横断的に分析して仮説を提示し、AWS サポートはその有効性を確認・深掘りする。このやり取りが、調査の精度と速度を同時に高めることにつながりました。

今回のインシデントでは、AWS サポートとの調査を通じて、AWS Lambda と Amazon RDS Proxy 間のセッション管理の設定に起因する根本原因が特定されました。障害自体はその後自然解消しユーザー影響も収束しましたが、再発防止に向けて書き込みと読み取りのリクエストを適切に分離する構成への変更が有効であることを AWS サポートとの連携で確認済みであり、現在 KDDI 側で検証を進めています。

【注意】 AWS DevOps Agent から AWS サポートへのケース起票・チャット連携を利用するには、AWS サポートプランの契約が必要です。Basic サポートではテクニカルサポートケースを作成できないため、この機能は利用できません。Developer サポートではケースの起票は可能ですが、チャットによるやり取りには対応しておらず、AWS Support Center での対応となります。DevOps Agent 上の統合チャット体験を含むすべての機能を活用するには、Business サポート以上のプランが必要です。詳細は AWS サポートプランのページ をご参照ください。

導入効果と今後の展望

AWS DevOps Agent の活用により、KDDIのインシデント対応は「数週間」から「数日」へと大幅に短縮されました。被疑箇所の特定から複数の対応案の策定・検証まで、リードタイムを数日単位に圧縮できたことは大きな成果です。AI を万能な答えとして扱うのではなく、仮説生成と優先順位付けのパートナーとして活用し、AWS サポートとの協働で精度を担保するというアプローチは、マネージドサービスを多用するサーバーレスアーキテクチャにおいて特に有効です。KDDI では今後も AWS DevOps Agent の活用を深めていく予定です。今回はインシデント発生後の原因調査という使い方が中心でしたが、プロアクティブな障害予防機能にも期待しています。過去のインシデントパターンを学習して再発防止策を提案するこの機能を活用することで、障害が起きてから対応するのではなく、起きる前に手を打てる運用への転換を目指しています。また、Amazon CloudWatch・Amazon EventBridge・Amazon SNS と連携することで、現在は手動で行っている DevOps Agent の調査起動をアラーム発火と同時に自動化することも視野に入れています。調査完了後はその結果を Kiro に渡し、チケット起票やリポジトリの調査といった後続の運用作業をそのまま Kiro と連携して進める流れも検討しており、検知から対応までの一連のサイクルをより効率化していきたいと考えています。

まとめ

本ブログでは、KDDI による AWS DevOps Agent を活用したインシデント対応効率化の事例をご紹介しました。

今回の取り組みで特に印象的だったのは、「AI に答えを出させる」のではなく「AI と一緒に問いを立てる」という使い方です。AWS DevOps Agent が仮説を整理し、AWS サポートがその仮説を検証・補強する。この役割分担によって、人と AI とサポートの三者がそれぞれの強みを発揮できる新しい協働モデルが生まれました。

マネージドサービスを多用する現代のクラウドアーキテクチャでは、インシデントの原因が単一サービスに収まらないケースが増えています。そうした複雑な状況だからこそ、「まず仮説を持ってから相談する」というアプローチが、解決までの道のりを大きく変えます。本事例が、同様の課題を抱えるチームにとって一つのヒントになれば幸いです。

著者

中野 利彦 様（右）
KDDI株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 グループリーダー

久保田 剛史 様（左）
KDDI株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部

安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト