
エージェントが日曜午前2時33分の障害を13分35秒で診断
AIエージェントは、日曜午前2時33分にアラームが鳴った障害を13分35秒で診断しました。このアラームは、最先端モデルが応答できる状態にあるかを監視しています。本番の応答が途中で止まり、監視の仕組みが自動でチケットを起票しました。
また、13分35秒後の2時46分には、そのチケットに裏付け付きの診断が書き込まれていました。チケットは、障害ごとに対応の記録をまとめる受付票です。診断の中身は次のとおりです。
- 応答が止まる原因は、本番の不具合と処理能力の増減のどちらか
- 顧客に影響が出ている
- ほかに考えられる仮説は、すべて除外済み
- 次にとるべき行動が、根拠つきで書き出してある
この診断は、Kiro CLIの上で動作するAIエージェントが出しました。Kiro CLIは、Kiroが顧客にも提供している開発ツールで、文字で指示を打ち込んで使います。エージェントとは、ツールを自分で呼び出しながら障害の原因を探るAIを指します。

"At 2:33 AM PDT on a Sunday, an availability alarm fired for a frontier model. Production responses were stalling mid-stream, and monitoring opened a ticket automatically."/"By 2:46 AM PDT, 13 minutes and 35 seconds later, a defensible diagnosis sat on the ticket: streams stalling silently from either a production bug or capacity scaling, customers affected, every competing hypothesis ruled out, and a recommended next action written out with supporting evidence."(冒頭)— Kiro Blog より公式情報を見る →
専用基盤は作らず、Kiro CLIとMCPサーバーで構成
専用の基盤も、この用途向けに学習し直したモデルも作らず、顧客に売っているのと同じKiro CLIを使っています。専用の実行環境もありません。設定には、エンジニアがコードと同じように書いてレビューするテキストのファイルを3種類使います。
運用を支える3つの要素
| 要素 | 中身 |
|---|---|
| エージェント設定 | 使うモデルとツール、運用の規則を書いたmarkdownのファイル(steeringファイル) |
| MCPサーバー | AWS(読み取りのみ)・ログ・チケット・デプロイのパイプライン・コードレビュー・Slackと連携する接続口 |
| スキルと知識 | 状況ごとの手順書(スキル)と、過去の障害対応を貯めた検索できる保管場所 |
MCPサーバーは、AIが外部のツールに接続するための接続口を指します。AWSには読み取り専用の権限で接続しています。
"There is no orchestration framework, no fine-tuned model, no bespoke agent runtime."/"The system is Kiro CLI, the same CLI we ship to customers, pointed at our own operations and configured with three kinds of plain files our engineers write and review like code:"/"Model Context Protocol (MCP) servers: allow agents to connect to tools (AWS accounts as ReadOnly, logs, tickets, pipelines, code review, and Slack)."(The system 節)— Kiro Blog より公式情報を見る →
エージェントには107個の対応マニュアルの目次だけを先に読ませる
エージェントのコンテキスト(AIが一度に処理できる作業メモの範囲)には、107個ある手順書の目次だけを読み込ませています。Kiroはこの手順書を「スキル」と呼び、状況ごとに1本ずつ用意しています。そのため、チケットの内容がいずれかの手順書の状況と一致した時点で、その1本だけを丸ごと読み込む仕組みです。
手順書を全部最初のプロンプトに詰め込むやり方は、10個目あたりで行き詰まります。鳴っていない99件のアラーム向けの指示で、コンテキストが埋まってしまうためです。
"In contrast, a skill is a markdown playbook for one situation."/"The agent's context carries only the index of all 107 skills; when a ticket matches, it reads the full playbook for that one skill. Stuffing everything into the system prompt fails at about the tenth runbook, when the context fills with instructions for the 99 alarms that didn't fire."(Skills 節)— Kiro Blog より公式情報を見る →
ツール呼び出しの96.9%は読むだけの操作
エージェントが外部のツールを呼び出した操作のうち、96.9%は読み取りです。読み取りは安全でやり直しがきき、同時にいくつも実行できます。残りの操作は、実行の前に人の許可を求めるよう設定できます。
人が立ち会わない障害対応では、権限を制限しています。使ってよい役割を一覧で限定してあり、権限は初めから読み取り専用(ReadOnly)です。管理者権限(Admin)を求めても、エラーが表示されるだけです。
"The work is read-heavy: 96.9% of the agent's tool calls are reads (safe, reversible, parallelizable); the rest can be gated."/"Every unattended session defaults to ReadOnly through a role allowlist, and a request for Admin privileges returns an error."(The job / What we got wrong 節)— Kiro Blog より公式情報を見る →
エージェントは月約250件を中央値13.6分で終えている
代表的な1か月では、約250件の障害対応が人の手を借りずに終わり、かかった時間の中央値は13.6分でした。中央値は、時間の短い順に並べたときの真ん中の値を指します。
月額の費用は、Kiroの最上位プラン9契約ぶんに相当します。浮いた時間は、次の3つに充てています。
- 診断報告のレビュー
- エージェントの誤りの訂正
- 根本原因の修正
これらの値は、Kiroのチームが自社の運用について公表したものです。第三者は検証していません。
"a representative month produced about 250 investigations, completed unattended at a median of 13.6 minutes."/"All in, the monthly bill is equivalent to nine of our own top-tier subscriptions, and the reclaimed hours go into reviewing briefs, correcting the agent, and fixing root causes."(What it costs 節)— Kiro Blog より公式情報を見る →
チケットの解決と重大度の変更は人だけが行う
チケットを解決済みにすることと、障害の重大度を変えることは、人だけが行う運用です。エージェントには、この2つの操作を許可していません。反対にコードレビューの下書きは、人のレビューがそのまま承認になるので、エージェントが許可を求めずに作成します。
Kiroのチームは、エージェントにどこまで任せるかを一度に定める設定は無いと述べています。操作ごとに専用の規則が必要で、steeringファイルがその規則の一覧です。
"There is no single autonomy setting."/"\"stop asking permission to draft a code review; the review is the approval,\" and \"never resolve a ticket or change severity; only humans do that.\""/"Every action needs its own rule, and the agent's steering file is the list of those rules."(What we got wrong 節)— Kiro Blog より公式情報を見る →
教訓の取り込みで、生のコメントがそのまま保管庫へ混入
セッションから教訓を取り出して貯める処理は、終了時に残っていた文章を中身の検査なしに保存していました。中断したセッションでは、生のチケットコメントがそのまま訂正用の保管庫に書き込まれました。その後のセッションは、このコメントを運用の知恵として学んでしまったとのこと。
対策として、書き込む前にスキーマ検証(記録の形式が規定どおりかを調べる処理)を入れました。あわせて、夜間に不要な記録を削除する処理も追加しました。手入れをしない学習の仕組みは、知識と同じ速さでゴミも積み上げると、Kiroのチームは述べています。
"The lesson-capture pipeline once accepted whatever text was pending at session end, so interrupted sessions wrote raw ticket comments into the corrections store verbatim, and future sessions incorrectly studied them as operational wisdom. The fix was schema validation before writing, plus a nightly prune. Unless curated and carefully managed, a learning pipeline compounds garbage as efficiently as knowledge."(The flywheel 節)— Kiro Blog より公式情報を見る →
読み取り中心の作業と人に残した2つの判断
Kiroが障害対応に使う仕組みは、顧客に売っているKiro CLIにmarkdownのファイルとMCPサーバーを組み合わせたものです。専用の基盤も、学習し直したモデルもありません。
エージェントの作業は読み取りが中心で、ツール呼び出しの96.9%を占めます。チケットの解決と重大度の変更は、エージェントに任せず人が判断します。
月約250件という件数と中央値13.6分という所要時間は、Kiroのチームが自社の運用について公表した値です。第三者は検証していません。
FAQ
- Kiroのチームは、障害対応をどれくらいの速さで診断まで進めたのですか?
- 日曜午前2時33分にアラームが鳴り、13分35秒後の2時46分には、裏付け付きの診断がチケットに書き込まれていました。診断には、応答が止まった原因の見立てと顧客への影響、競合する仮説の除外、次にとるべき行動まで書かれていました。
- 障害対応のために、専用のAI基盤を作ったのですか?
- 作っていません。専用の基盤も、この用途向けに学習し直したモデルも、専用の実行環境もなく、顧客に売っているのと同じKiro CLIを自社の運用に向けて使っています。設定はmarkdownのファイルで、エンジニアがコードと同じように書いてレビューします。
- 障害対応で、人が判断を持ち続けているのは何ですか?
- チケットを解決済みにすることと、重大度を変えることです。この2つは人だけが行う運用です。人が立ち会わない障害対応は、初めから読み取り専用の権限に固定してあります。



