8月22日、Kiroが「How We Learned to Trust an AI Agent to Triage Production Incidents」と題した記事を公開した。この記事では、本番インシデントのトリアージをAIエージェントに任せるまでの過程と、信頼を醸成するために設計した仕組みについて詳しく紹介されている。

Kiroとは

KiroはAWSが提供するAIネイティブなIDE・開発支援サービスだ。Amazon Bedrockをバックエンドに複数のフロンティアモデルへのアクセスを束ねるデータプレーンを運営しており、Anthropic、OpenAI、GLM（中国・智谱AIが開発する大規模言語モデル）、Qwen（Alibabaが開発する大規模言語モデル）、DeepSeek、MiniMax（いずれも中国系の大規模言語モデル）といった多様なモデルへのリクエストを中継している。本記事は、そのKiroチーム自身が「AIエージェントにプロダクションのチケットキューを任せる」ところまで至った経緯を書いたものだ。

日曜深夜2時33分、13分35秒で診断が出た

アラートが鳴ったのは太平洋時間の日曜深夜2時33分。フロンティアモデルの可用性アラームが発火し、ストリーミングレスポンスが途中で止まり始めた。モニタリングシステムが自動でチケットを起票した。

2時46分、13分35秒後、そのチケットには完成された診断が書かれていた。内容は：ストリームがサイレントに停止している原因はプロダクションバグまたはキャパシティスケーリングの問題、影響を受けているユーザーの範囲、競合仮説のすべてを否定した根拠、推奨アクションとその裏付け証拠——。

オンコールエンジニアがやったことは、完成したブリーフを読み、「escalationを起票する」か「プロダクションバグを対処する」か、一文を入力することだけだった。

調査を行ったのはKiro CLI上で動作するAIエージェントだ。

アーキテクチャ：マークダウンとMCPサーバーだけ

システムは意外なほどシンプルだ。専用のオーケストレーションフレームワークも、ファインチューニングされたモデルも、独自のエージェントランタイムもない。構成要素は3つだけだ：

• エージェント設定ファイル：使用モデル、ツール一覧、運用ルールを書いたマークダウンのステアリングファイル
• MCP（Model Context Protocol）サーバー：AWSアカウント（ReadOnly）、ログ、チケット、パイプライン、コードレビュー、Slackへのアクセスを提供
• **スキルと知識ベース**：後述

チケットキューを監視する常駐ディスパッチャーがチケット1件ごとにKiro CLIのヘッドレスセッションを起動する。モデルはアーキテクチャではなくランタイムパラメータとして扱われており、リード調査役は最も強力なモデルで動き、ファンアウト作業は高速・低コストのモデル群へ委譲される。判断が難しい曖昧なケースは3つのプロバイダーのモデルを並列で動かし、意見が割れた場合はエビデンスを追加収集するシグナルとして扱う。

図1：トリアージパイプライン。アラームがチケットになり、ディスパッチャーがエージェントセッションを起動し、エージェントがReadOnlyツールで調査してチケットに結果を書き込む。

「巨大なプロンプト」ではなくスキルによる段階的開示

このシステムで最も工夫されているのがコンテキスト管理だ。107個のスキル（マークダウンのプレイブック）を持つが、エージェントのコンテキストにはインデックスだけを常時ロードし、マッチするスキルの本文はオンデマンドで読み込む。

全ランブックをシステムプロンプトに詰め込む方式は、10本目あたりで破綻する——発火していない99件のアラーム向けの手順がコンテキストを圧迫するからだ。知識は「常時ロード→オンデマンド→検索可能アーカイブ」の3層構造で管理されており、長時間の調査がコンテキスト枯渇で死なないよう設計されている。

実際に起きた調査の例：96.5%のエラーがわずか2つのセルに集中

冒頭の13分事例だけでなく、別のケースも紹介されている。あるモデルのアラームが「モデル全体のキャパシティ問題」のように見えた際、エージェントはすべてのストリームエラーをリクエストIDでルーティングレコードと結合した。結果、エラーの96.5%はサービングセル全体のうちわずか2つのセルから発生しており、残りはゼロだった。

生き残った仮説「セルごとのクォータが不均一」をReadOnly認証で確認し、上流依存サービスの潜在バグを発見した。エンジニアが手動でやることは不可能ではないが、週末の夜中に数十のAWSアカウントをまたいで実施するのは現実的ではない。

フライホイール：エージェントが学び続ける仕組み

図3：調査→記録→コンパイル→進化のループ。次の同一アラームは前回の調査が終わった地点からスタートする。

このシステムでは複数のエージェントセッションが並列で動作する構成を採っている。前述のとおり、ディスパッチャーはチケット1件ごとにセッションを起動するため、同一インシデントに対して複数のエージェントが同時に動作するケースが生じる。4つのメカニズムがこのループを回している：

• 修正がレッスンになる：エンジニアによる修正は全セッションに注入され、エージェントは誤りを招いたドキュメント自体も修正する
• 調査が知識になる：クローズされたチケットは検索可能アーカイブに蒸留される
• エージェントがスキルを草稿し、人間がレビューする：新規インシデント後、エージェントが新しいプレイブックの下書きを作成し、エンジニアがコードと同様に管理する
• エージェント間での共有状態：10の並列エージェントが同一インシデントを観測しても、escalationチケットは1件だけ起票される

ただし、このフライホイールは失敗も増幅する。過去に学習パイプラインが未完了セッションの生のチケットコメントを「教訓」として取り込んでしまったことがあった。修正はスキーマバリデーションの追加と夜次のプルーニングジョブだった。

実際に間違えたこと

Kiroが「失敗から学んだこと」として挙げている点は実践的だ：

• ドキュメントのバグをエージェントは機械速度で継承する。 古い1行が複数チケットに波及してから人間が気づいた。対処はモデル改善ではなく、誤りを招いたドキュメントの修正だ。
• 確信を持った半正解は、間違いより高くつく。 「複数の競合仮説を否定してから結論を出す」というルールが最も効いた。
• 簡潔さが信頼を作る。 初期のエージェントはすべての作業ステップをユーザー可視スレッドに投稿していた。現在は要約を可視スレッド、詳細をワークログに分けている。
• 自律性の設定は一つではない。 「コードレビューの下書きは許可を求めずに行え」と「チケットのクローズや重大度変更は絶対に人間だけ」は、同じ一週間で追加された。
• セキュリティはプロンプトではなくインフラで担保する。 全未管理セッションはロールの許可リストによりReadOnlyに限定され、Admin権限の要求はエラーを返す。

コストと費用対効果

コストは月間約250件の調査で、Kiro自社のトップティアサブスクリプション9本分に相当する。セッションタイムアウト、スタック検出、並列実行上限、ファンアウトへの低コストモデル活用でコストを構造的に抑制している。

現在はトリアージだけでなく、修正のコードレビュー草稿やしきい値調整まで担い始めている。オンコールローテーションは今も存在するが、役割は変わった。「2時33分に調査を始める」のではなく、「2時46分に完成した調査をレビューする」仕事になっている。

詳細はHow We Learned to Trust an AI Agent to Triage Production Incidentsを参照していただきたい。