概要
2026/07/31に開催されたJAWS UG 名古屋 × Gov JAWSコラボにて「ガバメントクラウドでのAWS DevOps Agentの活用」というタイトルでLT登壇させていただいた内容です。
ガバメントクラウドの運用はマルチアカウント構成や閉域ネットワークなど制約が多く、障害調査の負担も大きくなりがちです。本記事ではAWS DevOps Agentを使って運用を楽にするための設計ポイント（調査範囲・セキュリティ）と利用例を記載します。
ガバメントクラウドの運用が大変
ガバメントクラウドはデジタル庁が整備する政府共通のクラウド基盤ですが、マルチアカウント構成・閉域ネットワーク・マルチベンダー運用など制約が多い環境です。運用フェーズに入ると、障害調査やログ分析など日常的な運用タスクの負担が増していきます。
フロンティアエージェントに手伝ってもらおう
これまで手動で行っていたログ分析や障害調査をフロンティアエージェントに任せて運用を楽にしたいと思います。
各種フロンティアエージェントを検証
6月～7月にかけてQiita Tech Festaが開催されていたため、多くの記事を書いていましたが、半分くらいはDevOps Agent、FinOps Agent、Security Agentなど各種フロンティアエージェントに関する記事になります。今回はその中でAWS DevOps Agent×ガバメントクラウドの内容について記載します。
AWS DevOps Agent
AWS DevOps AgentはAWSのフロンティアエージェントの一つです。CloudWatch LogsやCloudTrailなどのログを自律的に調査し、インシデントの原因分析をしてくれます。
以前は運用ツールを自分で作成
以前はCloudTrailログ分析ツールを自前で構築していました。左側のUIから検索期間やキーワードを入力し、Bedrockで要約した結果を出力する仕組みです。DevOps Agentを使用すれば、こうした自前ツールの構築が不要になりつつあります。
本日の内容
今回は以下の3つの観点でお話しします。
調査範囲
エージェントスペースの設計
DevOps Agentは、調査範囲（Agent Space）、調査手順（Instructions、Skills）を設定して調査対象（CloudWatch、CloudTrailなど）から分析を行います。
エージェントスペースとは
Agent SpaceはDevOps Agentの調査スコープを定義する論理コンテナです。同一アカウント内のリソースに加え、クロスアカウントでのアクセスも可能です。
共同利用方式での活用（ASP観点）
共同利用方式ではベンダー視点での設計になります。ASPの共通利用領域にDevOps Agentを配置し、各自治体のASPアカウントをセカンダリリソースとしてAgent Spaceに追加する構成が考えられます。
単独利用方式での活用（自治体観点）
単独利用方式では自治体視点の設計になります。ネットワークアカウントなどの管理用アカウントにDevOps Agentを配置し、各ASPアカウントをセカンダリリソースとして追加することで自治体内の全てのアカウントを調査対象にすることが可能です。
エージェントスペースの設計（ベストプラクティス）
AWS公式ブログ「AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス」では、Agent Spaceの範囲設定について解説されています。Agent Spaceの範囲が狭すぎると重要なコンテキストを見逃し、広すぎるとパフォーマンスのオーバーヘッドや複雑さが増大します。調査能力と運用効率のバランスを取る設計が重要です。また、クォータなどに関しても考慮が必要です。
セキュリティ
DevOps Agentからリソースへのアクセス
DevOps AgentがAWSリソースへアクセスする際はIAMロールを使用します。AWS DevOpsサービスがIAMロールをAssumeRoleし、調査対象のリソースにアクセスします。クロスアカウントの場合も同様に、セカンダリアカウント側に作成されたIAMロールを経由します。
どのような権限が設定されているか
DevOps Agentに付与される権限を確認します。マネージドポリシーAIDevOpsAgentAccessPolicyにより各種リソースの読み取り権限が付与されます。読み取り以外の権限としては下記のようなものも含まれています。
-
support:CreateCase：AWSサポートケースの作成 -
logs:StartQuery、logs:StopQuery、logs:GetQueryResults：CloudWatch Logs Insightsのクエリ実行 -
cloudtrail:StartQuery、cloudtrail:LookupEvents：CloudTrailのクエリ実行
ガードレール
DevOps AgentがIAMロールを引き受ける際、権限ガードレールがセッションポリシーとして付与されます。ガードレールはエージェントが実行可能な権限の上限を定義するもので、IAMロール側に権限を追加してもガードレール側で許可されていなければ、エージェントはそのリソースにアクセスできません。
利用例
自分が管理するアカウントが問題ないことの調査
ガバメントクラウドではマルチベンダーで運用されるケースが多いため、「何か繋がりません」「何か遅いです」という問い合わせに対して、自分の管理するアカウント側に問題がないことを迅速に証明できることが重要です。
自分のアカウントが問題ないことを証明する
実際にDevOps Agentに下記プロンプトで調査の依頼をしてみます。
下記のように各種メトリクスやログ、直近の変更内容まで調査を行い、自アカウント内に問題がないことを回答してくれます。
結構運用改善に使用できそう
ガバメントクラウドのようなマルチアカウント・閉域環境であっても、DevOps Agentで運用改善できそうです。
まとめ
ガバメントクラウドのマルチアカウント・閉域環境でもAWS DevOps Agentは使えます。Agent Spaceの設計を工夫すれば、共同利用方式・単独利用方式いずれの場合でも効率的な調査環境を構築できます。セキュリティ面ではIAMロールとガードレールによる多層防御が行われており、最小権限の原則が守られた状態で運用の自動化を進められます。「自分のアカウントに問題がないことの証明」のような実用的なユースケースで、日々の運用負担を軽減していきたいと思います。