Amazon Web Services ブログ
本番インシデントのトリアージを AI エージェントに任せられるようになるまで
本記事は「How We Learned to Trust an AI Agent to Triage Production Incidents」を翻訳したものです。
ある日曜日の午前 2 時 33 分（PDT）、フロンティアモデルの可用性アラームが発報しました。本番のレスポンスがストリームの途中で止まりはじめ、監視システムが自動でチケットを起票しました。
その 13 分 35 秒後、午前 2 時 46 分（PDT）には、根拠のある診断がチケット上に載っていました。ストリームが本番バグかキャパシティのスケーリングのいずれかによってエラーを出さずに停止していること、顧客に影響が出ていること、競合する仮説がすべて排除されていること、そして裏付けとなる証拠を添えた推奨される次のアクション、が書き出されていました。
オンコールエンジニアが打ち込んだのは 1 文だけでした。「エスカレーションを起票して」か「本番バグを対処して」か。本当の貢献は、仕上がったブリーフを読み、そこに浮かび上がった判断を吟味し、意思決定することでした。
調査を行ったのは、Kiro CLI 上で動く AI エージェントでした。本記事は、私たちのチーム、すなわちエージェントを中心に仕事の進め方を再設計しているフロンティアチームの 1 つが、どのようにして本番チケットキューをエージェントに任せられるようになったのか、そして今なお何をエージェントにやらせていないのかについて書いたものです。
仕事: 大規模に、午前 2 時に、トリアージする
私たちのチームは Kiro のデータプレーン、つまり Kiro の IDE、CLI、Web、iOS、Kiro Crew からのすべてのエージェンティックなチャットリクエストを、複数リージョンにまたがるモデル群（Anthropic、OpenAI、GLM、Qwen、DeepSeek、MiniMax。いずれも Amazon Bedrock 上でホスト）へと運ぶ配信経路を運用しています。各モデルには、それぞれ可用性、レイテンシー、スロットリング、キャッシュ、合成プローブのアラームが備わっています。
アラームが発報したら、誰かがそれをトリアージしなければなりません。これは本物か、何が壊れたのか、誰が影響を受けているのか。1 件の可用性の低下は、キャパシティイベントかもしれないし、不正アクセス攻撃、まずいデプロイ、あるいはチューニングを誤ったアラームかもしれません。そして各仮説は、それぞれ別のロググループ、別のアカウント、別のクエリ言語の中に存在します。優れたトリアージとは、500 個の問いのうちどの 5 個を最初に問うべきかを知っていることです。なぜなら、それぞれの結果が次のクエリを決めるからです。
トリアージは仮説探索であり、ツールを備えたエージェントはまさにそのために作られています。長年蓄積してきた Runbook、アラーム Wiki、ポストインシデントのメモは、すでにエージェントのコンテキストへの投資になっていました。この仕事は読み取り中心です。エージェントのツール呼び出しの 96.9% は読み取り（安全で、可逆で、並列化できる）で、残りはゲートをかけられます。そしてトリアージは繰り返されます。学んだことを書き留めるエージェントは、システムの知識を複利で積み上げていきます。午前 3 時の疲れた人間には、それができません。
システム: Kiro ハーネスを取り巻く markdown と MCP サーバー
オーケストレーションフレームワークもなければ、ファインチューニングしたモデルもなく、専用のエージェントランタイムもありません。システムは Kiro CLI、すなわち私たちが顧客に提供しているのと同じ CLI を、自分たちのオペレーションに向け、エンジニアがコードと同じように書いてレビューする 3 種類のプレーンなファイルで設定したものです。
- エージェント設定: モデル、ツール、そして運用ルールを記した markdown のステアリングファイル。各ルールは一度下した人間の判断であり、以降はそれが適用されます。
- Model Context Protocol（MCP）サーバー: エージェントがツール（ReadOnly の AWS アカウント、ログ、チケット、パイプライン、コードレビュー、Slack）に接続できるようにします。
- スキルと知識: 面白いのはここで、次に取り上げます。
ハーネスの周りには、チケットキューを監視し、チケット 1 件につき 1 つのヘッドレス Kiro CLI セッションを起動する、常駐のディスパッチャーが 1 つ配置されています。モデルはアーキテクチャ上の決定ではなくランタイムパラメータです。主任調査官（lead investigator）は利用可能な最も強力なモデルで動き、ファンアウトの作業は高速で安価なモデルで動くサブエージェントの群れに回され、本当に曖昧な判断は 3 つのプロバイダーのモデルからなる評議会（council）へ並列に投げかけられます。意見の不一致は、さらに証拠を集めよというシグナルとして扱われます。
図 1: トリアージのパイプライン。アラームがチケットになり、ディスパッチャーがエージェントセッションを起動し、エージェントはスコープを絞った ReadOnly ツールで調査してチケットに証拠を書き戻す。
スキルは巨大なプロンプトの代わりに段階的開示（progressive disclosure）をもたらす
対照的に、スキルは 1 つの状況のための markdown の手順書です。エージェントのコンテキストが抱えているのは全 107 個のスキルのインデックスだけで、チケットが合致したときに、その 1 つのスキルの手順書全体を読みます。何もかもをシステムプロンプトに詰め込むやり方は、10 個目の Runbook あたりで破綻します。コンテキストが、発報していない 99 個のアラームのための指示で埋まってしまうからです。以下は、あるレートリミットのインシデントの後に書かれた、要約した抜粋の例です。
知識はコストによって階層化されています。常に必要な事実は常時ロードされ、手順書はオンデマンドでロードされ、コンパイル済みの過去の調査が何百件も検索可能なアーカイブに収められています。この階層化が生存を可能にします。長い調査は、何よりもまずコンテキスト枯渇によって死ぬからです。
ある調査の解剖
あの午前 2 時 33 分のアラームに戻りましょう。エージェントが踏むすべてのステップはログに記録され、投稿するすべての主張は、それを生み出したクエリへのリンクを持ちます。
図 2: 分刻みで見た調査。アラームから診断の投稿まで 13 分 35 秒。人間による調査であれば始まってすらいなかった時間帯である。
より深い価値は、誰も手作業ではやらない仕事にあります。その 1 週間前、別の新しいモデルのアラームは、モデル全体に及ぶキャパシティイベントのように見えました。すべてのストリームエラーを、リクエスト ID でルーティングレコードと突き合わせたところ、エージェントはエラーの 96.5% が私たちの分離された配信セルのうちわずか 2 つに由来し、残りのセルではエラーがゼロだったことを突き止めました。生き残った仮説「セルごとのクォータが不均等」は ReadOnly の認証情報で確認され、上流の依存関係に潜んでいたバグを露呈させました。エンジニアでも同じことはできますが、週末の夜に、インシデント対応の最中に、何十ものアカウントをまたいで、というのは無理です。
フライホイール: 人間が作り、エージェントが回す
このシステムを毎週改善しているのは、その周りを回るループです。エンジニアがエージェントを導き、その学びをキュレーションします。
図 3: フライホイール（調査する、記録する、コンパイルする、進化させる）。次の同一アラームは、前回が終わったところから始まる。ステップ 1 からではない。
これを回し続けるための仕組みが 4 つあります。
- 修正はレッスンになる。 各修正は一度だけ保存され、その後のすべてのセッションに注入されます（数千の完了済みランに対して数百の修正であり、メモリの必要量を削減します）。そしてエージェントは、自分を誤らせたドキュメントにパッチを当てます。プロンプトのバグはドキュメントのバグから生まれたものだからです。
- 調査は知識になる。 クローズされたチケットは、その後のセッションが真っ先に照会するアーカイブへと蒸留されます。
- エージェントがスキルを作成し、人間がレビューする。 新規のインシデントの後、エージェントは新しい手順書か差分（delta）を作成します。レートリミットの手順書は、まさにその同じ夜にこの方法でセルごとのステップを得ました。エンジニアと夜間ジョブが、もう 1 つのコードベースとまったく同じようにライブラリをキュレーションします。
- エージェント間での状態共有。 条件付き書き込みのエスカレーショントラッカーによって、同じインシデントを観測している 10 個の並列エージェントは、上流チケットを 10 件ではなく 1 件だけ起票します。
その一方で、このループが私たちを裏切ったこともあります。レッスン取り込みのパイプラインは、かつてセッション終了時に保留状態だったテキストをそのまま受け入れていました。そのため中断されたセッションが、生のチケットコメントを一字一句そのまま修正ストアに書き込み、その後のセッションがそれを運用上の知恵として誤って学習してしまいました。修正策は、書き込み前のスキーマ検証と、夜間のクリーンアップでした。キュレーションと慎重な管理を欠くと、学習パイプラインはゴミを、知識と同じくらい効率よく複利で積み上げてしまいます。
何にコストがかかり、何を取り戻すのか
Kiro はエージェントを、顧客が購入するのと同じ単位であるクレジットで計測します。代表的な 1 か月で約 250 件の調査が生まれ、無人で、中央値 13.6 分で完了しました。支出は自制ではなく構造によって制限されます。すなわち、セッションのタイムアウト、スタック検知、同時実行数の上限、そしてファンアウト用の安価なモデルです。すべて合わせても、月々の請求額は私たち自身の最上位サブスクリプション 9 個分に相当し、取り戻した時間はブリーフのレビュー、エージェントの修正、根本原因の修正へと注がれます。
私たちが間違えたこと（あなたが学べるように）
エージェントは、あなたのドキュメントのバグをマシンの速度で受け継ぐ。 リファレンスドキュメントの古くなった 1 行が、人間が気づく前に複数のチケットへ伝播しました。私たちの修正策はより良いモデルとは関係なく、新しい習慣でした。セッションがおかしくなったら、それを修正し、何が自分を誤らせたのかを問い、そのドキュメントを直す。一度きり 5 分をかけるほうが、毎週 5 分を失うよりましです。
自信ありげな中途半端な答えは、間違った答えよりコストが高い。 どのモデルアップグレードよりも役立ったステアリングルールが 1 つあります。エージェントは結論を述べる前に、競合する仮説を検証して排除しなければならない、というものです。さらに算術・アラーム状態・重複についての自動チェックによって、以前は人間がレビューで捕まえなければならなかったカテゴリまるごとのエラーが取り除かれました。人々が信頼するのは、自分で検証できる出力であって、正確さについての主張ではありません。
簡潔さが信頼を築く。 初期のエージェントは、ステップごとの作業をすべて顧客に見えるスレッドへ投稿していました。内容は正確でしたが、体験としてはノイズが多いものでした。今では、見えるスレッドには短い投稿を 1 つだけ、詳細はすべてワークログに送っています。パートナーチームはエージェントを、その最良の調査ではなく、その最悪のコメントで評価するのです。
自律性に単一の設定は存在しない。 ある 1 週間で、私たちはエージェントを権限付与と抑制の両方向で修正しました。「コードレビューを作成する許可をいちいち求めるのをやめろ。そのレビュー自体が承認だ」と、「チケットを解決したり深刻度を変えたりするな。それをやるのは人間だけだ」です。すべてのアクションにはそれ専用のルールが必要であり、エージェントのステアリングファイルはそれらのルールの一覧なのです。
セキュリティはプロンプトだけでなく、インフラから生まれる。 すべての無人セッションは、ロールの許可リスト（allowlist）を通じてデフォルトで ReadOnly になり、Admin 権限のリクエストはエラーを返します。各認証情報は 1 セッションのために発行され、エージェントが宣言したタスクにスコープが絞られるため、セッションは自分がリクエストした API しか呼び出せません。
これからどこへ向かうのか
今日、エージェントはトリアージを行います。そしてますます、修復も行うようになっています。修正のためのコードレビューやしきい値のチューニングを、同じハーネス上で、必須の人間レビューを経る形でドラフトを作成します。そしてシステム全体が markdown、MCP サーバー、そして素の Kiro CLI でできているため、私たちが自分たち自身のために行うすべての改善は、私たちが提供する製品にも関係します。
オンコールのローテーションは今も存在しますが、仕事は変わりました。もはや午前 2 時 33 分に調査を始めるのではなく、午前 2 時 46 分に完了した調査をレビューするのです。オンコールエンジニアのポケベルは、エージェントがすでに行った仕事のための意思決定キューになりつつあります。Swami Sivasubramanian 氏によるフロンティアチームに関する記事は、開発チームにとっての第一歩として「エージェントのコンテキストに投資する」ことを挙げています。私たちのチケットキューは、オペレーションのためにエージェントに投資する 1 つの例です。
これがフロンティアエンジニアの新しい生活の 1 日目であり、まだ続きがあります。