「AIでコストを削減せよ」という指示が降りてくる。
しかし現場の実態はといえば、システムは年々増え続け、稼働中のものは誰も止められず、新しい取り組みに充てる時間は保守業務に食われている。JUASの企業IT動向調査2026（2025年度調査・回答957社）でも、2025年度計画でIT予算が増えた理由の第1位は「既存システム・基盤の刷新・更新・増強」で66.3%。同じ調査で「AI関連の投資・利用料増加」は2026年度予測が43.7%（2025年度計画36.3%から+7.4ポイント）。項目としては第4位だが、伸び幅は全項目でもっとも大きい。維持費が予算を圧迫しているのと、AIへの投資を求められているのが、同時進行で起きている。
この状況に対して、ひとつ具体的な答えが示された。AWSのKiroチームが、本番障害の一次調査をAIエージェントに委ねた運用事例を公開している。2026年8月16日の深夜2時33分にアラームが鳴り、2時46分には原因の診断がまとまっていた。所要13分35秒。その間、人間は起きていない。
注目すべきはここからだ。これを成立させていたのは、モデルの賢さではなかった。107枚のMarkdownである。
※本記事はKiroの公開情報（公式ブログ）と公式ドキュメントに基づく解説で、筆者環境で同じ本番インシデント対応を再現する検証は行っていません。数値・仕様はすべて2026年8月時点のものです。
深夜2時33分のアラームで、誰も起きなかった
まず何が起きたのかを事実として置きます。
Kiroのデータプレーンは複数リージョン・複数モデルプロバイダー（Anthropic、OpenAI、GLM、Qwen、DeepSeek、MiniMax）にまたがっていて、アラームが鳴ったときに「どこが原因か」を絞るだけで相当な手作業が要る構成です。そこにトリアージ専用のエージェントを置いた。
- 2026-08-16 2:33 AM PDT：アラーム発火
- 2:46 AM：エージェントが診断を公開。13分35秒
- 代表的な月で 約250件 の調査を無人で完了、所要時間の 中央値13.6分
このエージェントは「答えを出す」ようには作られていません。仮説探索として設計されていて、次の5段階を踏みます。
- Orient（方向を決める）
- Measure（計測する）
- Classify（分類する）
- Rule out（対立する仮説を潰す）
- Publish（診断を公開する）
4番目が入っているのが重要で、公式は理由をはっきり書いています。「自信満々の半解は、人間がレビューして検証できない主張よりも危険だ」。つまり検証可能な結論しか出させないための工程です。障害対応でいちばん高くつくのは、それらしい原因に飛びついて別の場所を掘り続けることなので、これは実務的な設計だと思います。
実際に効いた例も出ています。あるアラームは「モデル全体のキャパシティ障害」に見えた。エージェントが精査した結果、実際にはN個あるセルのうち2個でクォータが不均等になっていたバグでした。全体障害と局所バグでは、呼ぶ人も打つ手も全部違います。
先にコストの話をする。月250件の一次調査が、上位サブスク9個分
稟議で最初に聞かれるのはここなので、先に出します。
この運用の月額コストは、顧客向け上位サブスクリプション9個分に相当する、と公式は書いています（原文は “the monthly bill is equivalent to nine of our own top-tier subscriptions”）。
ここは注意して読む必要があります。公式はどのプランを指すか明示していません。 Kiroの公開価格は Free $0／Pro $20／Pro+ $40／Pro Max $100／Power $200（1ユーザーあたり月額・※2026年8月28日時点）で、最上位のPowerで換算すれば月1,800ドル前後、日本円ならおおむね月30万円弱という水準になります。あくまで筆者の換算であり、公式の数字ではありません。
それでも桁の感覚はつかめます。月250件の一次調査に対する費用として、深夜のオンコール当番にかかる人件費と比べる意味があるかどうかは、各社の単価を入れれば数分で出ます。
ただし、ここは誠実に書いておきたいところです。この事例で削れたのは人件費そのものではありません。削れたのは「深夜に人間が叩き起こされる回数」と「調査を始めるまでのリードタイム」です。オンコール体制自体は継続していると公式も明言しています。
「AIでコストを下げろ」への回答を人員削減として設計すると、まず現場が協力しません。一次調査の移管として設計すれば、当番している本人が最初の受益者になる。同じ技術でも、どちらの言葉で稟議を書くかで通り方がまったく違うはずです。
効いているのはLLMではない。Markdown 107枚が本体
ここが本題です。
Kiroが使っているのは、顧客に売っているのと同じKiro CLIと、AWS・ログ・チケット・パイプラインに繋ぐMCPサーバー、そして設定としてのMarkdownファイルだけ。オーケストレーションフレームワークも、ファインチューニングも使っていません。
そのMarkdownが107枚あります。1枚ずつが「こういう症状のときはこう切り分ける」というプレイブックです。
なぜ107枚に分けたのか。理由は失敗から来ています。当初はシステムプロンプトにルールを全部書こうとして、10個目あたりで文脈が飽和した。そこで構造を変えました。
| 層 | 中身 | 読み込み |
|---|---|---|
| 常時ロード | 必須の事実だけ | 毎回 |
| オンデマンド | 107枚のプレイブック | 索引だけ常時保持し、該当時に全文を読む |
| アーカイブ | 過去の調査記録 | 検索して必要な分だけ |
エージェントは普段、索引しか持っていません。レート制限のインシデントが来たときに初めて、レート制限のプレイブックを全文読む。人間の当番が分厚いRunbookから該当ページだけ開くのと同じことを、コンテキストウィンドウの制約に合わせてやっている。
そしてこの107枚は、書いて終わりではなく増えます。公式が Learning Flywheel と呼んでいるループが4本回っています。
- 修正を教訓に変える — 一度直したことを記録し、以降の全セッションに注入する。原因がドキュメントのバグだったなら、エージェントを直すのではなくドキュメントを直す
- 調査を知識に変える — クローズしたチケットをアーカイブに蒸留する
- エージェントがスキル案を書き、人間がレビューする — 新しいインシデントの後、エージェントが「今回の教訓をプレイブックにするとこうです」と案を出し、人間がコードレビューと同じ形で承認する。レート制限のプレイブックは、この方式で同じ夜のうちに追加されて機能した
- エージェント間で状態を共有する — 条件付き書き込みを使い、並列で動く10体が同じ事象を観測しても、上流のチケット1本に集約される
1番目に注目してほしいです。ドキュメントのバグを直すと、それが原因で毎週5分ずつ溶けていた損失が永久に消える。AIエージェントの導入が、結果としてドキュメント整備のインセンティブになっている。これは情シスにとって、たぶん最大の副産物です。
そして裏返すと、この記事でいちばん言いたいことになります。
運用知識がドキュメント化されていない部門は、どのモデルを買っても13分にはなりません。 107枚のMarkdownは、Kiroが買ったものではなく、Kiroが書いたものです。ここに近道はない。逆に言えば、Markdownを書く作業には予算も稟議も要りません。
なお「AIエージェント用のMarkdown」は、Kiro固有の作法ではありません。KiroのAgent Skillsは、YAMLフロントマター付きMarkdownを SKILL.md として置くオープン標準です。この形式はもともとAnthropicが開発してオープン標準として公開したもので、公式のClient Showcaseには Claude Code / GitHub Copilot / VS Code / Cursor / Gemini CLI / ChatGPT・Codex / Kiro など46の製品が並んでいます（agentskills.io、2026年8月28日時点）。
しかも標準側が定めている読み込み方式が、そのまま前述の3層です。起動時は名前と説明だけを読む「Discovery」、タスクが一致したときに全文を読む「Activation」、必要に応じて同梱スクリプトや参照ファイルを開く「Execution」。Kiroが工夫したのではなく、標準がそう設計されているわけです。
つまり、今書いたプレイブックは、ツールを乗り換えても持っていけます。ベンダーロックインを気にする部門にとって、この移植性は無視できない材料のはずです。
権限はプロンプトで説得せず、インフラで削る
「AIが本番環境を触る」と聞いた瞬間に会議が止まる、というのは想像がつきます。Kiroの答えは明快でした。
エージェントのツール呼び出しは、96.9%が読み取りです（公式の原文は「96.9% of the agent’s tool calls are reads … the rest can be gated」で、残りはゲートで制御できる、という書き方をしています）。これは結果論ではなく、そうなるように権限で縛った数字です。
- 全セッションが既定でReadOnly
- ロールはホワイトリストで制限
- Admin権限を要求するとエラーが返る
- 認証情報はセッションごとに新規発行し、宣言されたタスクにスコープを限定
設計思想は公式の言葉が的確です。セキュリティはプロンプトで説得するものではなく、インフラで制限するもの。「本番を壊さないでください」とシステムプロンプトに書くのは対策ではない、ということです。
この一点だけでも、社内で「AIエージェントに障害対応をやらせたい」と提案するときの説明が変わると思います。議論すべきは「AIは信用できるか」ではなく「何を読ませ、何を書かせないか」であり、後者はIAMとロールの話なので、情シスがいちばん得意な領域です。
学習させると汚染される。Kiroが踏んだ地雷
うまくいった話だけ書くと嘘になるので、失敗も公開されている分を書きます。
中断したセッションの生ログが、誤って「修正ストア」に登録されました。 結果、以降のセッションが誤った運用知識を学習した状態になった。対策はスキーマ検証の追加と、夜間のプルーン（不要データの刈り取り）です。
これは仕組みとして避けられない種類の事故だと思います。「学習ループを回す」ということは「間違いも学習する経路がある」ということで、知識ストアに書き込む工程には、必ず検証を挟まないといけない。前述の学習ループ3番目が「エージェントの案を人間がレビューする」形になっているのも、同じ理由でしょう。
自動で溜まる知識は、自動で腐ります。溜める設計をするなら、捨てる設計と検証する設計を同時に作る必要があります。
「単一の自律性設定」は存在しない
もう一つ、実装を考えるうえで効く指摘があります。Kiroは「エージェントの自律性レベル」というスライダーを1本持つ設計をしていません。アクションごとに個別の許可規則を持たせています。
- コードレビュー案の作成 → 許可を広げる
- チケットの解決（クローズ） → 許可を絞る
これは実務の感覚と一致します。「読んで報告する」と「状態を変える」では、間違えたときのコストが二桁違う。ひとつのつまみで両方を制御しようとするから、「まだ信用できないから全部止める」か「もう全部任せる」の二択になってしまう。
自律度は0か1かではなく、アクションの一覧です。 導入を検討するなら、最初に作るべき成果物はこの一覧かもしれません。ログを読む・メトリクスを取る・チケットにコメントする・チケットを閉じる・設定を変える……を並べて、それぞれに○×を振る。それがそのまま権限設計になります。
明日、1枚目のMarkdownを書くところから始まる
最後に、自分の話を少しだけ書きます。
私はこの記事を書くにあたって本番インシデント対応の再現はしていません（冒頭のとおりです）。ただ、Markdownでエージェントを運用するという部分については、手元で毎日動かしています。個人のObsidian VaultをClaude Codeで運用していて（Apple M5 Mac / macOS 26.5.2 / Claude Code CLI）、.claude/ 配下のMarkdownを数えたら209枚ありました（2026-08-28に find .claude -name '*.md' | wc -l で実測）。内訳はコマンド84、エージェント定義35、スキル19、ドキュメント10、常駐ルール7、ほか。
数だけ見ればKiroの107枚を上回る。構造もほぼ同じだ。索引を常時持ち、必要になったときに該当ファイルだけ読み込ませ、失敗するたびにルールを1枚足す。個人の知識管理でやっていることと、AWSが本番障害のトリアージでやっていることが、同じ形をしている。これは特殊な技術ではない、という手応えがある。
そのうえで、情シス部門が明日から手をつけられることを3つ挙げます。
- 直近3ヶ月のインシデントを1件、Markdown 1枚に書く。 症状 → 見るべきログ → 除外すべき仮説 → 判定、の順で。AIに読ませる前に、まず人間の当番が読める形にする。1枚目は完全に手作業でよく、予算も稟議も要りません
- アクションの一覧を作り、○×を振る。 読む系と書く系を分けるだけで、権限設計の8割が終わります
- 一次調査だけを切り出す。 「AIで運用を自動化する」は稟議が通りません。「深夜のアラームで人間が起きる前に、切り分け結果を用意しておく」なら、範囲も効果も測れます
「AIを使ってコストを下げろ」への現時点でのいちばん誠実な回答は、おそらくこうだ。下がるのはコストより先に、深夜2時33分に起こされる回数のほうだ。 それを可能にするのは高いモデルではなく、いままで誰も書かないままにしてきた運用知識のドキュメントだ。
書く相手がAIになったというだけで、書くべきものはずっと同じだった。
参考
- Kiro公式ブログ「How We Learned to Trust an AI Agent to Triage Production Incidents」 （2026-08-28取得）
- Kiro Docs: Agent Skills
- Kiro Docs: MCP
- Kiro 料金ページ（2026-08-28取得）
- Agent Skills（オープン標準・Client Showcase）（2026-08-28取得）
- JUAS「企業IT動向調査2026」プレスリリース第1弾（2026-08-28取得）
コメント