Amazon Web Services ブログ
【寄稿】障害原因分析AIエージェントの開発とガバメントクラウド運用業務への導入
本記事は自治体向けシステムを展開する株式会社アイネスの運用本部管理部 田中翔氏、根岸亮太氏から寄稿いただいたものです。
背景
株式会社アイネスでは、自治体様の多岐にわたる業務を網羅する、豊富なラインナップを揃えた基幹業務パッケージシステム「WebRings」を全国の自治体様に提供しています。
自治体システムのガバメントクラウド移行を進める中で、私たちクラウド保守グループは 100 を超える膨大な数のアカウントを管理する必要性に迫られました。
しかし、アラームを人手で確認・調査する従来の仕組みでは、1 件あたりの対応に時間を要し、かつ経験者でないと調査が難しいため、これほど多くのアカウントを運用していくための人的リソースが非常に不足していました。
さらに、これらのシステムは同一のパッケージ及び、クラウド構成となっており、 アプリケーションの潜在的なバグやインフラ設定の不備により、複数の環境で同時に問題が起こる可能性が高いというリスクを抱えていました。
そのため、障害発生時に必要となる対応要員数が膨大になることが予測され、安定的な運用を維持することが困難でした。
これらの課題を根本的に解消し、限られたリソースで高品質な運用を維持するためには、運用の効率化が不可欠であり、生成 AI の活用を検討することとしました。
構築：Amazon Bedrock Agents を活用した AI エージェントの実装による障害分析
課題解決のため、私たちは AWS が公開していた「FA2（Failure Analysis Assistant）」を参考に、独自の障害原因自動分析機能「FA3（Failure Analysis Assistant Agent）」を実装しました。これは、エージェント版 FA2 を意味する社内での呼称です。
私たちは以前からガバメントクラウド上の環境を集約して管理する「共通運用アカウント」を構築・運用していました。FA3 は、この共通運用アカウントに集約されるデータを活用することで、効率的に障害分析を行える仕組みとしています。
FA3 の実装には Amazon Bedrock Agents を採用しました。これにより、複雑な実装は不要となり、プロンプトの調整などによるメンテナンスの容易さを確保しました。
さらに、マルチエージェント機能を利用することで、分析精度の向上、コスト削減、そして将来的な機能拡張性を実現しました。
エージェント構成
FA3 は、分析全体を統括する「分析エージェント」と、特定の情報収集を担当する複数の「収集エージェント」で構成されています。
分析エージェントは、障害の状況に応じて必要な調査タスクを自律的に計画し、配下の収集エージェント（Configuration, Log, Metrics）へ指示を行います。その後、各エージェントから返却された情報を分析し、障害の根本原因を特定します。
収集エージェントは、以下のとおり役割ごとに Action を定義し、AWS Lambda と連携させています。
ConfigurationAgent（サービスの詳細情報収集）
- /describe_service
- 指定された AWS リソース（Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Relational Database Service（Amazon RDS） 等）の詳細情報を収集します。
LogAgent（ログ情報収集）
- /describe_service
- 指定された AWS リソース（ロググループ）の詳細情報を収集します。
- /get_logsqueryresult
- CloudWatch Logs Insights クエリを実行し、そのクエリ結果を収集します。
- /get_athenaqueryresult
- Amazon Athena でクエリを実行し、そのクエリ結果を収集します。
MetricsAgent（メトリクス情報収集）
- /list_metrics
- 指定された名前空間やメトリクス名から取得可能な Amazon CloudWatch メトリクスの一覧を特定します。
- /get_metric_data
- 開始・終了時間やクエリを指定し、実際のメトリクスデータを収集します。
また、あらかじめ環境構成やログの格納方法といったアカウント毎の情報を Amazon DynamoDB に登録しておくことで、運用担当者の操作を不要としました。CloudWatch アラームから送られてくる JSON 形式のアラームデータのみをインプットとして、FA3 が自動で障害分析を実行します。分析が完了すると、その結果はメールで関係者に通知されます。
これにより、運用担当者はアラーム発生と同時にそのアラームに対する分析結果を受け取れるようになりました。
ガバメントクラウド外の生成 AI を利用する仕組み
本ソリューションは、ガバメントクラウド環境から事業者側で用意した AWS アカウントの Amazon Bedrock を利用する構成となっています。
ガバメントクラウド環境では国内に通信が完結する LLM の利用が認められています。同様のセキュリティ水準を遵守することを前提に、事業者側で用意したガバメントクラウド外の AWS アカウントで生成 AI サービスを利用することとし、以下のようなアーキテクチャを採用しました。
- セキュリティ設定
生成 AI（FA3）専用のアカウント（FA3 アカウント）には、デジタル庁から提供される必須適用テンプレートをコピーし、ガバメントクラウド環境と同等のセキュリティレベルを確保しました。 - データ分離
FA3 アカウントには、実際に通知されたアラームのデータのみを配置する構成とし、リソースを参照するための Role や Lambda はすべてガバメントクラウド環境の「共通運用アカウント」に設定することで、明確にデータと権限を分離しました。
本ソリューションによる障害分析の流れ
FA3 によるアラーム発生から分析結果通知までの障害分析の処理の流れは以下の通りです。
- アラーム発生
自治体アカウントで発生した障害を検知し、CloudWatch アラームを発報します。 - FA3 へアラームを連携
共通運用アカウントにてアラームを処理し、FA3 アカウントの Amazon Simple Queue Service（Amazon SQS） へ通知を行います。Amazon SQS は Amazon Bedrock Agents 呼び出し用の Lambda をトリガーします。
- プロンプト生成
呼び出された Lambda が、DynamoDB から該当アカウントの情報を取得し、受け取ったアラーム情報と組み合わせて、Amazon Bedrock Agents へのプロンプトを生成します。 - 障害調査
プロンプトを受け取った分析エージェントが、障害内容に合わせて必要な情報の取得を収集エージェント群に指示します。
各収集エージェントがそれぞれの担当領域（メトリクス、ログ、サービス情報など）の調査・情報収集を行います。分析エージェントは、収集エージェントから集約したデータを基に、障害の根本原因を分析します。
情報収集は以下のアーキテクチャにて実装しています。- 収集エージェントは、アクションとして定義された Lambda を実行します。
- 実行された Lambda は、共通運用アカウントに保管されているデータが必要な場合、共通運用アカウントへ AssumeRole を行い情報を収集します。
- 自治体アカウント内の情報（サービスの状態など）が必要な場合は、共通運用アカウントの Lambda を同期的に呼び出し、その Lambda が自治体アカウントへ AssumeRole を行い情報を収集します。
※処理の長時間化や複雑化が発生した場合には、リトライ処理や分岐などの管理を容易にするため AWS Step Functions を検討
- 結果通知
分析した結果をメールにて運用担当者へ通知します。
- AIの思考過程の記録
分析時に AI がどのような思考で調査を行ったのか、そのプロセスを DynamoDB に記録します。これにより、分析内容の妥当性を確認することが可能です。
検証結果
エージェント（FA3）の導入効果を検証するため、エンジニアによる調査結果と FA3 が報告した障害原因を照合し、その的中率を測定しました。
検証の結果、以下の通り全体で約9割、特にクラウド設定に関しては 100 %という高い信頼性が確認されました。
| 被疑箇所 | アラームサンプル数 | 的中数 | 的中率 |
|---|---|---|---|
| クラウド設定 | 27 | 27 | 100% |
| OS内 | 56 | 47 | 83.90% |
| 全体 | 83 | 74 | 89.20% |
実現効果
アラーム確認のオペレーションを「FA3 の報告を確認し、その妥当性を判断する」というフローへ変更した結果、多数のアラーム調査が 10 分未満で完了するようになっています。
従来、事象推定からデータ確認までの初動調査には 1～2 時間を要していたため、調査時間は約 10 分の 1 にまで短縮されました。
事象の特定が困難である OS 内が起因のアラームであっても、被疑箇所の絞り込みを FA3 が行ってくれるため、初動調査に要する時間は短縮されました。
| 対応フロー | 平均初動調査時間 |
|---|---|
| 従来 | 105分 |
| FA3活用（クラウド設定起因） | 7.5分 |
| FA3活用（OS内起因） | 15分 |
また、障害調査には AWS や業務システムに関する知見と経験を要するため、対応できるエンジニアが限られてしまうという課題がありましたが、FA3 が調査の大部分をサポートしてくれることで、経験の浅いエンジニアでも迅速かつ的確な対応が可能となりました。これにより、当初の課題であった人的リソースの不足が解消し、安定的な運用を維持することができるようになりました。
Why AWS？
私たちクラウド保守グループは、AWS のシステム運用を強みとしており、今回のガバメントクラウド移行 におけるシステム構築でも AWS を利用してきました。そのため、AWS の生成 AI サービスである Amazon Bedrock を利用することは、既存環境との親和性、シームレスな連携、そして私たちが持つノウハウを最大限に活かす上で、最適な選択でした。
また、今回参考にした「FA2」が AWS 環境での実行を前提としていたことも、Amazon Bedrock を採用する後押しとなりました。
コスト
生成 AI へのリクエスト費用は、1回あたり 75 円程度です。
マルチエージェントではエージェント毎にモデルを設定できますので、例えば、高度な分析を行う「分析エージェント」には高性能なモデルを使用し、比較的単純な情報収集を行う「収集エージェント」には低コストなモデルを使用する、といった柔軟な選択肢も可能です。
以下の対策を組み合わせることで、コストの最適化も可能です。
分析対象の絞り込み： ディスク使用率低下など、AI 分析の効果が薄いアラームを除外する。
入力トークンの最適化： 調査対象とするメトリクスを厳選することや、取得データを加工してから AI に渡すことで、AI への入力データ量を抑制する。
今後の構想
FA3 のさらなる進化に向けて、以下の構想を描いています。
- 分析精度の向上
AWS X-Ray の情報や、AWS の障害情報といった、より多様な情報ソースを収集・分析対象に加えることで、原因分析の精度をさらに高めていきます。 - 対話型インターフェースの実装
現在は分析結果を一方的にメールで通知する形式ですが、受けた通知を元に AI と対話しながら現在のシステムの状態をより深く探れるような機能を、Kiro や Amazon Q Developer といったサービスも活用しながら実装することを目指します。 - 複数アカウントにまたがる分析
同一パッケージシステムを利用している環境では、あるアカウントで発生した障害が他アカウントでも発生するリスクが高いです。そのため、単一アカウントの分析にとどまらず、特定した障害原因が他アカウントにも潜在していないかを横断的に分析できる機能を実装し、障害の未然防止につなげます。
著者について
