目次
運用もAIが見ますと言われた方へ
開発だけでなく保守運用までAIエージェントに任せる、という提案を受けている方に向けて書いています。
確認すべきなのは、AIがどこまで賢いかではありません。AIが呼ばれる条件を、誰が、どこに書いてあるかです。その線の引き方の実例が、8月に公開されました。
公開されたのは工程の6段目です
Anthropicが自社のプレイブックとして、AIネイティブな開発ライフサイクルの設計を公開しました（The AI-native SDLC playbook）。計画・設計・実装・テスト・デプロイ・保守の6段階を扱っています。
前の5段階は、すでに議論が進んでいる領域です。要件をAIにまとめさせる、レビューをAIに一次通過させる、フックで承認を挟む。このあたりは提案書でもよく見かけます。
読みどころは6段目、保守運用です。ここだけ、人が起動しないという前提で書かれています。
従来の保守は、人待ちの構造です
プレイブックは従来型をこう描写しています。深夜3時にアラートが鳴っても見逃されうる。チケットは誰かが拾うまでバックログに残る。障害後の振り返りで決めた対策は、次の火事が起きればコードへ届かないまま終わる。
保守が受け身の工程になるのは、担当者の怠慢ではありません。すべての起点に人の着手が要る構造だからです。
検知にモデルを使いません
ここが本題です。
本番を見張るのは、決定的なスクリプトです。ローリング30日の平均と標準偏差を取り、Western Electricルールのような判定規則を当てて、急なスパイクだけでなく緩やかなドリフトも拾います。このスクリプト自体がバージョン管理され、単体テストが書かれています。
そして明記されています。検知は完全に決定的であり、モデルは一切関与しません。
できることが段階で変わります
エージェントが呼ばれた後も、権限は一段ずつです。
| 逸脱の大きさ | エージェントの動作 | できること |
|---|---|---|
| 1σ | 呼ばれない | スクリプトがログを残すだけ |
| 2σ | 読み取り専用 | 原因の診断のみ。書き込みは不可 |
| 3σ | 行動可 | PRを開く、または事前承認済みの手順を起動する |
3σでも、本番へ直接触れるわけではありません。開けるのはレビューゲートへ向かうPRか、あらかじめ承認された手順の呼び出しだけです。
この段階の境界はbands.yamlのような設定ファイルに書かれ、バージョン管理されます。権限と管理者設定の側では、本番アクセスそのものを拒否します。呼び出し・発見・仕分けの判断は、すべてタイムスタンプ付きで記録されます。
例として挙がっているのは、CIのテスト失敗率、デプロイ後の5xx率、PRのサイクルタイムです。テスト失敗率が3σを割ればフレーキーテストを隔離するか差し戻しのPRを開き、判断はレビューゲートに委ねる。デプロイ直後に5xx率が3σを割れば、既存のロールバック手順を起動する。
出てくるのは報告書ではありません
診断結果の置き場所が、この設計でいちばん効いている部分です。
エージェントが書くのは調査メモではなく、計画段と同じ形式のintent.mdです。異常の内容とその証拠、想定される成果、影響を受けるシステム、未解決の問いを含みます。つまり最初の工程が読める形で出てきます。
だから発見はそのまま設計・実装・テスト・レビューのパイプラインへ乗ります。ループが閉じる、というのはこの意味です。
人の仕事は、起こす役から仕分ける役へ
サービスのオーナーかオンコール担当が、溜まったintent.mdを仕分けます。いま直す、後で予定する、却下する。この3択です。
面白いのは却下の扱いで、却下は帯の調整に使われます。ノイズが多ければ帯を広げ、見逃しが多ければ狭める。人が「これは違う」と言った回数が、次の検知精度になります。
そして修正が出たら、そのインシデントに対応する評価項目をテストへ追加します。同じ種類の障害が二度目に起きないよう、発見が資産へ変わる導線まで設計されています。
測り方まで書いてあります
プレイブックには効果測定の指標が2つ挙がっています。
先行指標は、帯を割ってからintent.mdが仕分けの列に載るまでの時間です。比較対象は従来の「障害発生から振り返りの対策が決まるまで」。検知スクリプトのログに逸脱の時刻と段階が残るので、そのまま測れます。
遅行指標は、発見のうち実際にマージされた修正になった割合と、同じ種類の障害の再発件数です。後者は、評価項目が増えるにつれて減るはずだ、という予測とセットで書かれています。
提案を受ける側にとっては、ここが確認のしどころです。指標を先に決めていない自動化は、効いたかどうかを後から言い張れます。
運用の提案を受けたときに確認すること
AIに運用を任せる提案への4つの質問
-
異常を見つけるのは何ですか。モデルなのか、決まった計算式なのか
-
エージェントが呼ばれる条件はどこに書いてありますか。設定ファイルとしてバージョン管理されているか
-
段階ごとにできることが分かれていますか。読むだけの段階と、手を動かせる段階が別か
-
見つけたものは、どの形式で出てきますか。報告書か、次の工程が読める成果物か
保守運用契約の打ち合わせ、AI運用サービスの比較検討でそのまま使えます
賢さではなく、条件の置き場所を見ます
AIに運用を任せるという話は、これまで「どこまで賢く判断できるか」で語られてきました。この設計はその問いを避けています。
賢さを問うかわりに、呼ばれる条件を外へ出して、バージョン管理下に置いた。判断の質ではなく、判断が起きる場所を設計対象にしています。
任せられる範囲は、モデルの性能ではなく、条件をどこに書いたかで決まります。
出典
- The AI-native SDLC playbook（Anthropic）