10月3日、Andrey Pokhilkoが「How to Move AI SRE Agents From Demo to Production」と題した記事を公開した。ラップトップ上で動くAI SREエージェントを本番インシデント対応に耐えうるシステムへ移行するには何が必要か——デモの完成度に満足した瞬間に見落とされがちな4つの要件を具体的に整理した内容だ。
AIエージェントがログを読み、オブザーバビリティツールを叩き、障害デプロイと設定変更を数分で結びつける——そのデモは確かに動く。問題は、その先だ。
著者のAndrey PokhilkoはKomodorのCTOオフィスでAI駆動のSREとKubernetes運用を研究しており、「ラップトップ上の実験と本番稼働には根本的な乖離がある」と指摘する。その乖離を埋めるのが、アクセス制御・コスト管理・調査証跡・テスト設計の4要件だ。
「監視付きセッション」は本番システムではない
ローカル環境でのエージェント実験が成立するのは、人間が常にそこにいるからだ。詰まれば追加の指示を与え、ログが足りなければ手動で補う。人間がオーケストレーションと品質管理を担っている。
本番では、アラートは監視システムから24時間飛んでくる。エージェントはユーザーのマシンの外に常駐し、複数の調査を並行して処理し、終わったら自律的にクリーンアップする必要がある。そしてエージェント自体が起動しない、ツールへのアクセスが切れる、調査の途中で止まる——そのどれもが新たな運用障害になる。
要件1：調査の証跡
記事の中で最も実践的な指摘がこれだ。ラップトップのターミナルを閉じれば、プロンプト、ツール呼び出し、レスポンス、最終的な推奨内容がすべて消える。
本番でAIエージェントが出した結論を信頼できるかどうかは、その結論に至るまでの過程が記録されているかどうかにかかっている。有用な調査記録が備えるべき要素として、記事は以下を挙げる：
- 起点となったアラート
- エージェントが参照した証拠
- 使用したツール
- 実行したアクション
- 最終的な推奨内容
この証跡はリアルタイムのインシデント対応だけでなく、エージェント改善にも直結する。「エージェントが症状で調査を止めてしまう」パターンが繰り返されるなら、デプロイ履歴やインフライベントのログが欠落しているという具体的な統合問題として特定できる。
※編集部の考察：調査証跡の設計は、OpenTelemetryのトレーシング概念とも親和性が高い。エージェントの各ツール呼び出しをスパンとして記録する構成は、既存のオブザーバビリティ基盤を流用できる可能性がある。
要件2：トークンコストは信頼性メトリクスである
本番ボリュームでは、汎用エージェントフレームワークの「使わない機能」が余計なコンテキストとして積み上がり、トークン消費を圧迫する。記事はコスト管理を後回しの最適化ではなく、設計段階から組み込むべき信頼性要件と位置づける。
監視すべき指標として挙げられているのは：
- セッションあたりのコスト・ユースケースあたりのコスト
- レイテンシ、成功率、ツール呼び出し回数
コスト監視は異常検知としても機能する。ツール呼び出しのループ、肥大化したコンテキストウィンドウ、統合の失敗——これらはクオリティ問題として表面化する前にコストの急増として先に現れる。バジェットアラート、使用量上限、サーキットブレーカーは本番設計に最初から含めるべきだと著者は述べる。
要件3：デモの成功は本番readinessを証明しない
プロンプトの修正が一つの調査では有効でも、別の調査では逆効果になる。モデルのアップグレードがより正確な根本原因を特定したとしても、レイテンシとコストが増えれば本番では使いにくくなる。
テストは「エンジニアのマシンでうまく動いた」ではなく、実際に行われる作業を反映したものでなければならない。具体的には、過去の調査から得られた既知の障害パターン、繰り返し発生する本番の事象、エッジケースをカバーする合成テストケースだ。
要件4：エージェントは人間の権限を引き継ぐな
ローカル実験では開発者の既存クレデンシャルをそのまま使うことが多い。セットアップは楽だが、本番では危険なモデルだ。
記事が推奨するアプローチは読み取り専用の調査から始めること。そこからリスクの低いアクション、影響の大きいアクション（明示的な承認またはポリシーチェックを伴う）へと段階的に自律性を広げる。各アクションには「どのセッションが、何の証拠に基づいて、なぜそのアクションを許可されたか」の記録が必要だ。
Kubernetesにおけるアクセス制御の文脈では、RBAC（Role-Based Access Control）の設計がエージェントの権限スコープにそのまま適用できる。最小権限の原則をエージェントにも徹底することが、この要件の核心だ。
記事全体を通じて著者が繰り返すのは、「AIエージェントは、それが支えるべき信頼性システムの一部になる」という点だ。エージェントが止まれば、チームには新たな運用問題が生まれる。アクセス制御・コスト管理・調査証跡・テスト設計——この4つへの対処こそが、ラップトップの実験と本番稼働の本質的な差だと整理されている。
詳細はHow to Move AI SRE Agents From Demo to Productionを参照していただきたい。
