AWS DevOps Agent と Kiro CLI によるインシデント修正の自動化

本記事は 2026 年 7 月 14 日に公開された Jishnu Dasgupta と Chetan Dharma の “Automated Incident Remediation with AWS DevOps Agent and Kiro CLI” を翻訳したものです。

はじめに

インシデント修正の自動化、つまり調査結果を人手をかけずにデプロイ済みの修正へとつなげることは、AWS 上で分散ワークロードを運用するオペレーションチームにとって次の課題です。現在、インシデントが深夜 2 時に発生すると、オンコール担当のエンジニアは Amazon CloudWatch、デプロイパイプライン、アプリケーションログをまたいでテレメトリを突き合わせ、その後手動で修正を書いてデプロイする必要があります。これには通常数時間かかります。AWS DevOps Agent は、インシデントを自律的に調査し、根本原因を特定し、数分で修正計画を生成することで、この前半部分を解決します。プレビュー期間中、お客様やパートナーからは MTTR が最大 75% 短縮、調査速度が最大 80% 向上、根本原因の特定精度が 94% という結果が報告されました。

しかし、調査と修正の提案はあくまで半分にすぎません。調査結果を読み、修正を書き、テストし、デプロイする作業は依然として人手が必要です。この後半部分も自動化できたらどうでしょうか。

前回の記事「AWS DevOps Agent によるエージェント型 AI を活用した自律的インシデント対応」では、AWS DevOps Agent を設定してアプリケーションを監視し、自律的な調査をトリガーし、本番デプロイのベストプラクティスに従う方法を紹介しました。また、Amazon CloudWatch アラームが発生した際に調査を自動的にトリガーする仕組みを示すコードサンプルも公開しています。この 2 つの記事により、Amazon CloudWatch アラームをきっかけに AWS DevOps Agent の調査をトリガーし、修正計画を生成できるようになりました。

本記事では、AWS DevOps Agent の修正計画の出力を、AWS CodeBuild 上でヘッドレスモードで動作する Kiro CLI と統合して、修正のループをエンドツーエンドで完結させる方法を紹介します。AWS DevOps Agent が修正分析を完了すると、イベント駆動型のパイプラインが調査結果を自動的に Kiro CLI へルーティングします。Kiro CLI はコードベースに修正を適用し、人によるレビュー用の pull request を作成し、承認後にデプロイをトリガーします。結果として、L1/L2 インシデントは検知からデプロイ済みの修正まで、最小限の人手介入で完了します。唯一人が介在するのは pull request の承認だけです。

サンプルの CloudFormation アプリケーションを使い、インフラのコード、異常発生用のスクリプト、イベントルーティング、そしてすべてを機能させる Kiro CLI の steering 設定を含めた、ソリューション全体を解説します。ソースコードはすべて、付随する aws-samples のリポジトリで公開されています。

ソリューションの概要

AWS 上で稼働する典型的な Web アプリケーションを考えてみましょう。Application Load Balancer の背後にフロントエンドがあり、バックエンドの計算処理は Amazon EC2、データベースは Amazon RDS で構成され、ソースコードと CloudFormation テンプレートは AWS CodeCommit に置かれています。この環境で何か問題が発生すると、本ソリューションは 2 つの AWS フロンティアエージェント — 自律的な調査と修正を行う AWS DevOps Agent、そして自動的なコード修正を行う Kiro CLI — を、完全サーバーレスのイベント駆動型ブリッジでつなぎ、インシデントからデプロイ済みの修正までアプリケーションを進めます。

図 1 – ソリューションアーキテクチャ

仕組み

インシデントの発生 – アプリケーションで問題が発生します。CPU 使用率の上昇、エラー率の上昇、応答速度の低下などです。Amazon CloudWatch アラームが発生します。
DevOps Agent による調査 – アプリケーションが Agent Space にオンボードされている AWS DevOps Agent が、メトリクス、ログ、デプロイ履歴を自律的に突き合わせ、根本原因を特定して修正計画を生成します。
EventBridge による信号のルーティング – Amazon EventBridge のルールが Mitigation Completed イベント（ソース: aws.aidevops）を検知し、AWS Lambda 関数を呼び出します。
Lambda による抽出とキューイング – AWS Lambda 関数が AWS DevOps Agent の API を呼び出して修正の要約と実行計画を取得し、そのペイロードを Amazon SQS キューに送信します。
CodeBuild による Kiro CLI の実行 – Amazon SQS キューにメッセージが届くと、SQS イベントソースマッピングを持つ AWS Lambda 関数が AWS CodeBuild の実行をトリガーし、メッセージの内容を環境変数として渡します。AWS CodeBuild は、修正のペイロードを修正用プロンプトとして使い、ヘッドレスモード（--no-interactive --trust-tools=read,write,grep,shell）で Kiro CLI を実行します。
Kiro CLI による修正の適用 – リポジトリの構成と修正の規約を記述した steering ファイルに従い、Kiro CLI は CloudFormation テンプレートやアプリケーションコードを修正し、フィーチャーブランチにコミットして pull request を作成します。
人による承認とパイプラインによるデプロイ – 開発者が pull request をレビューします。承認されてマージされると、関連するデプロイパイプラインがトリガーされ、変更が実行されます。

前提条件

このウォークスルーを進めるには、以下が必要です。

AWS DevOps Agent へアクセスできる AWS アカウント
設定済みの Agent Space
Pro、Pro+、Power のいずれかのサブスクリプションを持つ Kiro CLI（ヘッドレスモードの API キーに必要）
適切な認証情報で設定済みの AWS CLI
アカウントの AWS CodeCommit リポジトリに push したサンプルリポジトリ

完了したら、Readme ファイルに従って、上記のアーキテクチャを実装・実行するためのコンポーネントをセットアップしてください。以下のセクションでは、このアーキテクチャを支えるために構築されたコンポーネントについて説明します。

修正イベントの取得

AWS DevOps Agent は、調査や修正の状態が変化するたびに、Amazon EventBridge のデフォルトイベントバスへライフサイクルイベントを発行します。各イベントはソース aws.aidevops を使用し、Mitigation Completed、Investigation Completed、Mitigation Failed のように、具体的な内容を示す detail-type を持ちます。本記事では、修正が正常に完了した瞬間という単一の信号に焦点を当てます。

EventBridge のルールと Lambda による抽出

Mitigation Completed の detail-type に一致する Amazon EventBridge のルールが、AWS Lambda 関数を呼び出します。イベントのペイロードには（agent_space_id、task_id、execution_id という）メタデータが含まれており、これにより AWS Lambda 関数は AWS DevOps Agent を呼び出し、修正の要約（どのアクションを取るべきか、その理由）と実行計画（ステップバイステップの手順）という 2 つの重要なオブジェクトを取得できます。この構造化されたペイロードは、後続の処理のために Amazon SQS キューへ発行されます。

Kiro CLI によるヘッドレスな修正

修正のペイロードが Amazon SQS キューに届くようになったので、次はアプリケーションとインフラのリポジトリをチェックアウトし、コードベースに対して Kiro CLI エージェントを実行し、変更を push できるコンピューティング環境が必要です。AWS CodeBuild はこれに適しています。オンデマンドのコンピューティングを提供し、AWS CodeCommit とネイティブに統合され、永続的なインフラを必要としません。

Kiro CLI 2.0 ではヘッドレスモードが導入され、対話的なターミナルなしでデプロイパイプライン内でプログラムから実行できるようになりました。（AWS Secrets Manager に保管された）API キーで認証し、プロンプトを渡すと、Kiro CLI は対話型の体験と同じツール、同じエージェント、同じ機能でエンドツーエンドに実行します。

CodeBuild による修正のオーケストレーション

Amazon SQS キューにメッセージが届くと、トリガー用の AWS Lambda 関数が Amazon SQS のメッセージ本文を環境変数として渡し、AWS CodeBuild の実行を開始します。AWS CodeBuild の buildspec は、次のような単純な手順で構成されています。

インストール: Kiro CLI をインストールし、環境を設定します。KIRO_API_KEY は AWS Secrets Manager から自動的に取得され、ハードコードされることはありません。
プロンプトの生成: Python スクリプトが、構造化された修正のペイロードを自然言語の修正用プロンプトに変換します。内容を検査して、変更がインフラ向けかアプリケーションコード向けかを分類し、アクション、判断理由、具体的な指示を含む、絞り込んだプロンプトを生成します。
フィーチャーブランチの作成: 追跡できるよう、agent space と実行 ID にもとづいて名付けた新しいブランチをチェックアウトします。
Kiro CLI の実行: 生成したプロンプトとともに、Kiro CLI をヘッドレスモードで呼び出します（kiro-cli chat --no-interactive --trust-tools=read,write,grep,shell "生成したプロンプト"）。承認を行う人間がいないため、--trust-tools フラグは最小権限の原則に従って特定のツールカテゴリのみを自動承認します。
検証とコミット: ガードレールが変更を検査します。ファイル数の上限、保護対象ファイルの検出、Python の構文検証（py_compile）、YAML の lint です。すべてのチェックを通過すると、変更がコミットされ push されます。
pull request の作成: 修正のアクションをタイトルとし、AWS DevOps Agent の判断理由を説明文に含めた AWS CodeCommit の pull request を作成します。

steering ファイル

Kiro CLI が修正において効果的なのは、単に一般的なコードを生成するからではなく、steering ファイルによるものです。steering は、リポジトリの構成、コーディング規約、意思決定のフレームワークといった、プロジェクトに関する永続的な知識を Kiro に与えます。

このソリューションでは、steering ファイルが自動修正のガードレールとして機能します。次の内容を定義しています。

リポジトリの構成 – 各ディレクトリをその用途に対応付けます。
意思決定のフレームワーク – 変更をインフラ向けかアプリケーション向けかに分類するルールです。
スコープの制約 – 1 回の修正につき最大 3 ファイルまで、新規ファイルの作成禁止、新規依存関係の追加禁止、削除の禁止です。
保護対象ファイル – buildspec、インフラのパイプラインテンプレート、ブリッジのコード、そして steering ファイル自体は、明示的に変更禁止です。
フェイルセーフ – プロンプトが曖昧であったり、Kiro が何を変更すべきか判断できない場合は、推測するのではなく変更を行いません。

この steering ファイルはリポジトリにコミットされているため、すべての AWS CodeBuild の実行時に自動的に読み込まれます。これにより、Kiro CLI は大規模なリファクタリングではなく、対象を絞った予測可能な変更を行えます。

pull request からデプロイまで

ここまでで、自動化されたパイプラインはその役割を果たしています。Kiro CLI が修正計画を分析し、適切なファイルを変更し、フィーチャーブランチ上に pull request を作成しました。pull request の説明文には、何を変更したか、なぜ変更したか（AWS DevOps Agent の判断理由そのもの）、そして元のインシデントまで完全に追跡できる agent space と実行 ID が含まれています。

ここで、human-in-the-loop によるゲートが機能します。開発者が pull request をレビューし、変更が正しく、適切な範囲に収まっており、デプロイして安全であることを確認します。この承認のステップは意図的なものです。エージェントによる調査、分析、修正の提案は信頼していますが、最終的なデプロイの判断は人が行います。

pull request が承認されメインブランチにマージされると、デプロイパイプラインが承認された変更を対象の環境に反映します。

Amazon CloudWatch アラームからデプロイ済みの修正までの一連のサイクルは、数時間ではなく数分で完了し、唯一の手動ステップは pull request のレビューです。L1/L2 インシデントを大量に扱う組織にとって、これは運用にかかる負担の軽減と復旧の高速化に直結します。

クリーンアップ

継続的な課金を避けるため、このウォークスルーで作成したリソースを削除してください。完全な削除手順については Readme を参照してください。

まとめ

本記事では、AWS DevOps Agent の修正出力を Kiro CLI と統合し、クローズドループのインシデント修正パイプラインを構築する方法を紹介しました。この 2 つのフロンティアエージェントを連携させることで、オペレーションチームはインシデントの検知から、pull request の承認という単一の人的タッチポイントを経て、デプロイ済みの修正までを実現できます。

このアプローチは、エンタープライズのオペレーションに次のような明確な効果をもたらします。

MTTR の短縮 – これまで手動での調査と修正に数時間を要していた L1/L2 インシデントが、数分で解決できるようになります。
オペレーターの生産性向上 – エンジニアは、その場対応の消火作業から、対象を絞った AI 生成の修正をレビューし承認する作業へと移行できます。
一貫した修正 – steering ファイルがチームの規約と意思決定のフレームワークを体系化することで、インシデントの発生時期や頻度にかかわらず、すべての自動修正が同じ基準に従うようになります。

始めてみたい方は、aws-samples のリポジトリから完全な実装を clone し、AWS DevOps Agent のドキュメントで最初の Agent Space を設定し、Kiro CLI のドキュメントで steering ファイル駆動のコード生成についてさらに詳しく確認してください。ご質問や、このパターンをどのように応用したかを共有したい場合は、以下にコメントを残すか、リポジトリで issue を開いてください。

翻訳は App Dev Consultant の宇賀神が担当しました。

Amazon Web Services ブログ