本番障害の一次調査を AI に渡すかどうかは、所要時間では決まりません。公式の公開事例では、日曜日 02:33 PDT の可用性アラームから 13分35秒後に、根拠付きの診断がチケットへ載ります。
📑目次
オンコール時に残す作業は、エスカレーションか本番バグ対応かのどちらかに1文で判断することです。テクノロジー運用で真の差が生まれるのは対応速度ではなく、無人セッションを ReadOnly に制限し、チケット解決と深刻度変更を人間だけに残す明確な権限境界です。
採用可否はデモの品質ではなく、次の条件で判断してください。
- 証拠付きの原因分析
- ゲート付き操作
- Secrets の拒否リスト
13分35秒で診断が載ったあと、人間が残した判断
一次調査を AI に渡す前に確認するのは、所要時間ではありません。チケットの診断がクエリ証拠と結び付いていること、操作が承認ゲートを通っていること、Secrets と本番書き込みが拒否リストで閉じられていることです。公式の 13分35秒は速さの宣伝ではなく、その境界が守られたあとにオンコールが残す判断を示す数字です。
次の公式タイムラインは、診断がチケットへ載ったあと、人間が実際に残した仕事を示しています。
公式が公開したタイムライン
Kiro 公式ブログと、その日本語公開面である AWS Japan 公式ブログは、同じタイムラインを公開しています。
- 日曜日 02:33 PDT にフロンティアモデルの可用性アラームが発報し、監視がチケットを自動起票します。
- 02:46 PDT、13分35秒後には「ストリームが無言停止している」「顧客影響がある」「競合仮説を排除した」「次に取る操作」がチケットへ載ります。
- オンコールが打つのは、エスカレーションか本番バグ対処かの1文です。
公開されている調査手順
手順も公開されています。
- アラームがチケットを作ります。
- 常駐ディスパッチャーがチケットごとにヘッドレス CLI セッションを1件起動します。
- スコープ付き ReadOnly の接続でログ、チケット、パイプライン、コードレビューを読み、主張は生成したクエリへリンクします。
- 見えるスレッドには短い投稿、詳細はワークログです。
- スキルは 107 件の索引だけを常時保持し、合致したプレイブック1件だけを読みます。巨大プロンプトへ Runbook を詰め込む方式は、約10件目で破綻すると公式側は書いています。
公開数値と役割の読み替え
数字だけを見ると自動化は十分に進んでいるように見えます。
- ツール呼び出しの 96.9% は読み取りです。
- 別件ではエラーの 96.5% が配信セル2つに集中し、残りはゼロでした。
- 代表月では無人調査が約250件、所要時間の中央値は 13.6 分です。
- 月額コストは自社最上位サブスクリプション9個相当と公開されています。
- 支出の抑制は「自制」ではなく、セッションタイムアウト、スタック検知、同時実行上限、安価モデルへのファンアウトという構造です。
独立面の Antoine Buteau の 2026-08-21 ダイジェストは、同じ事例を「調査者から、AI が集めた証拠のレビュー担当へ」と要約しています。一次数値は公式面で確認し、ダイジェストは役割の読み替えとして使います。
テクノロジーのオンコールローテーションは消えません。変わるのは 02:33 に調査を始めることではなく、02:46 の完成ブリーフを読んで決めることです。
公開数値の一覧
| 観点 | 数値・条件 | 出典 |
|---|---|---|
| アラームから診断 | 13分35秒（02:33→02:46 PDT） | Kiro 公式 |
| 無人調査の規模 | 代表月 約250件、中央値 13.6分 | AWS Japan |
| 既定権限 | 無人セッションは ReadOnly。Admin 要求はエラー | 同上 |
| 人間だけが残す操作 | チケット解決、深刻度変更、変更のデプロイ承認 | Kiro / Azure SRE Agent |
| 採用判定 | 証拠付き RCA、統合失敗の明示、deny list | One2N |
出典は次です（2026年8月時点）。
テクノロジー運用で無人調査を ReadOnly に閉じ、解決は人間に残す
信頼はプロンプトの上手さから来ません。インフラの許可リストと、「やってはいけない操作」の列挙から来ます。
Kiro の既定権限
Kiro 側の既定は明確です。
- 無人セッションはロール許可リストで ReadOnly です。
- Admin 要求はエラーになります。
- 認証情報は1セッションと、宣言したタスクにスコープします。
- チケット解決と深刻度変更は人間のみです。
- 自律性を単一スライダーにはせず、権限付与と抑制をアクション単位でステアリングファイルへ書きます。
強い権限を常時持たない設計は、AWS の JIT アクセスと TEAM 導入の判断軸とも同じ問題です。エージェントに渡す前に、人間側の昇格経路を先に決めてください。
Azure SRE Agent の許可ゲート
同じ「調査はエージェント、適用は人間」はクラウド SRE でも繰り返されます。Microsoft Learn の Azure SRE Agent 概要（更新 2026-07-30）では、許可ゲートがツール呼び出しを実行前に評価します。
- 軽減策は提案しますが、人のサインオフなしではデプロイしません。
- 02:47 の決済サービスアラート例では、数分でメモリ傾向（40分前）と2時間前のデプロイを相関し、ポッド再起動と HPA 調整の2案を事前入力します。
- 調査スレッドが7分で閉じた例もあります。戦争室も、タブの往復も不要だった、と公式は書いています。
制限もあります。
- チャット UI は英語のみ
- 可用性はリージョンとテナント設定に依存
- 課金は従量
- 誤った結論や環境に合わない軽減策があり得るため、承認前の確認は省略できません。
SOC アラート運用の並行例
セキュリティ運用の並行例もあります。IT Leaders（日川佳三、2026-08-19）は、マクニカが Prophet Agentic AI SOC Platform の販売を開始したと報じています。
- SIEM / EDR など 200 種類以上のソースから AI が調査し、Slack / Teams / Webhook で通知します。
- 端末隔離は自動実行し得ます。
- 新規またはチューニングした検知ルールは担当者承認後です。
- 人間が 24時間365日で危険度を判定し、30分以内にエスカレーションするサービスもあります。
対象は可用性オンコールではなく SOC アラートです。同一製品の主張には使いません。共通なのは、調査の自動化と、ルール適用を人間に残す点です。エージェントへ広い権限を渡すときの過剰な自律性は、AI セキュリティの学習順でも先に潰すべき項目です。
公開されている失敗モード
失敗モードも公開されています。
- 古いドキュメントの1行は、複数チケットへ機械速度で伝播します。
- 学習パイプラインが、中断セッションの生コメントを教訓ストアへ取り込んだ失敗もあります。修正はスキーマ検証と夜間クリーンアップです。
- 結論前に競合仮説を検証しない半答は、誤答より高い、と公式側は書いています。
自信ありげな一文を、証拠の代わりに用いないでください。
公式事例と評価軸を並べて採用範囲を決める
13分という速さだけでは採用しません。左2列は調査の自動化事例、SOC列はセキュリティ運用の並行事例、右列は自チームの合格基準です。
公開事例の比較表
| 項目 | 本番オンコール一次調査（公開事例） | クラウド SRE エージェント | SOC アラートトリアージ（販売報道） | 導入前評価の物差し |
|---|---|---|---|---|
| 発火 | 可用性アラーム→自動チケット | Monitor / PagerDuty / ServiceNow | SIEM / EDR 等 200種超 | Alertmanager 等、単発とバーストの両方 |
| 既定権限 | ReadOnly。Admin 不可 | 実行前許可ゲート | 調査は全件。隔離は自動可 | 本番はゲート。Secrets / DB は deny |
| 人間が残す判断 | 解決と深刻度。1文の意思決定 | 軽減策の承認。未承認はデプロイしない | 検知ルール適用。24h 危険度判定（30分） | 証拠不足を認めるか、操作を承認するか |
| 知識の持ち方 | 107 スキル索引 + アーカイブ | 調査が組織知見として残る | MITRE でルール可視化 | runbook / 過去件が取れないと不合格 |
| 出典 | Kiro | Azure SRE Agent | IT Leaders | One2N |
出典：上表 URL（2026年8月時点）
導入前評価の合格線
One2N の Hemant Kumar（Staff SRE、2026-08-11）は、デモ品質ではなく「本番のページ中に、取れる証拠の範囲で頼れるか」を合格線にします。
5軸は次の通りです。
- 操作安全性
- RCA
- 可観測性の相関
- インシデント記憶
- セキュリティ
OpenSRE v0.1 の PoC は、Claude Opus 4.8 で約6時間動かした結果、次の点数で defer です。reject ではありません。
- Actionability 0
- RCA -1
- Integrations -1
- Knowledge -1
- Security 0
- 合計 -3
不合格理由は次の通りです。
- 証拠のない Helm rollback 提案
- 統合失敗後も答えを返すこと
- runbook と過去件を検証できないこと
Inferred ラベルが付いていても、クエリ証拠がなければ RCA は通りません。
読み方は次の通りです。公開事例は「ReadOnly と仮説排除が揃えば一次調査を渡せる」ことを示しています。評価軸は「自環境の統合と知識が足りなければ defer」を示しています。両方を満たさない導入は、速さの数字を権限設計の代わりに使うことになります。
自チームで本番に置くかを決めるチェックリスト
次にやるべきことは、自環境で1回ずつ試して、defer・限定導入・本番資格を決めることです。人気度や転載タイトルは判定に使いません。
- 単発アラートとマルチアラート（バースト）の両方で試す。単発デモだけで止めない。
- 壊れた統合を1つ入れ、欠落を明示するか原因を捏造するかを見る。
- Helm の幸福パス以外（kubectl / Kustomize）でも文脈が取れるか確認する。
- Secrets・データベース・本番書き込みの deny list を、書き込み許可の前に置く。認証情報の扱いは GitHub Actions の権限昇格対策と同じ優先順位です。
- RCA は仮説形成中のクエリ証拠を必須にする。情報不足なら「足りない証拠」を書かせ、推測を結論にしない。
- ステアリングに「解決と深刻度は人間のみ」などアクション単位の禁止を列挙する。単一の自律スライダーにしない。
- ドキュメント修正をレッスン化する。エージェントはドキュメントのバグを機械速度で増幅する。
- 学習ループへ未検証テキストを入れない。書き込み前のスキーマ検証と夜間クリーンアップを先に置く。
判定は5軸で行います。点数が足りなければ defer です。
Azure 側を確認する場合は、次の確認項目を加えてください。
- 英語 UI
- リージョン可用性
- 従量課金
- 提案の人間レビュー
コスト感の参照は、代表月 250件・中央値 13.6分でも、上限はタイムアウト、同時実行、安価モデルで構造的に置く、という公式の書き方です。自制に頼らないでください。
よくある質問
Q1. 13分で診断が出ればオンコールは不要ですか。
不要にはなりません。公式事例でもローテーションは残ります。変わるのは 02:33 に調査を始めることではなく、02:46 の完成ブリーフを読んで判断することです。
Q2. 既定が ReadOnly なら本番に出してよいですか。
既定 ReadOnly は必要条件です。Secrets / DB の deny、マスキングの検証、統合失敗時に黙らないことが揃うまで、本番資格にはしません。
Q3. モデルを強くすれば、仮説の飛ばしは消えますか。
公式側は、結論前に競合仮説を排除するステアリングと、算術・アラーム状態・重複の自動チェックの方が効いたと書いています。モデル更新だけでは足りません。
Q4. SOC 製品の自動隔離と、SRE の一次調査は同じですか。
対象が違います。SOC は SIEM / EDR アラート、SRE は可用性・レイテンシ・デプロイ相関です。共通なのは調査の自動化と、ルール適用・深刻度・デプロイを人間に残す点です。
Q5. 学習ループは無条件で回してよいですか。
不可です。未検証テキストを教訓ストアへ入れると、ゴミが複利で増えます。書き込み前のスキーマ検証が必要です。
関連記事:
- AIセキュリティ学習ロードマップ2026｜開発者が学ぶ順番
- EVPの証明範囲とOT条件：単一フォーム試験かDOI/OTP維持か
- JA: GPT-Transcribeの使い分け｜テクノロジー現場のコンテキスト指定
まとめ
一次調査の自動化は、13分35秒、約250件/月という公式数字で既に動いています。差がつくのは速さではなく、証拠付き診断、ReadOnly、競合仮説の排除、人間だけの解決・深刻度・デプロイ承認です。次は自環境で単発とバーストを1回ずつ回し、上のチェックリストで defer / 限定導入 / 本番資格を決めてください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す