ラマン・ヴァルマ氏は、プラットフォームエンジニアリング向けAIエージェントを構築するスタートアップ、Kestrel AIの創業者兼CEOである。
多くの企業は当初、文書の下書き作成、サポートチケットの要約、エンジニアのコード記述支援といった低リスクのタスクにAIを採用した。しかし現在、その段階はより重要な領域へと拡大しつつある。それは、インシデントの自律的な調査、クラウド環境の検査、インフラ変更の提案、運用アクションの実行が可能なエージェントシステムである。
これは全く異なる信頼モデルだ。エンジニアに誤った回答を与えるチャットボットは混乱を生むが、本番環境へのアクセス権を持つエージェントは、数百万ドルのコストをもたらすダウンタイムやセキュリティ問題を引き起こす可能性がある。
多くのCTOは「AIエージェントはインシデントを修正できるか」と問うているが、代わりに「AIシステムに本番運用への参加を許可する前に、どのような条件が満たされている必要があるか」と問うべきである。答えはAIエージェントを完全に避けることではない。AIエージェントは既に多くのクラウド運用ワークフローにおいて測定可能な効果を示している。むしろ、人間のエンジニア、CI/CDシステム、自動化パイプラインに適用するのと同じ規律を必要とする、新たなクラスの運用アクターとして扱うことである。
本番インフラには通常のSaaSワークフローより高い信頼基準が必要だ
多くのAIエージェントの評価とベンチマークは、応答品質に焦点を当てている。これは、エージェントがプロンプトをどれだけ理解したか、有用な回答を生成したか、適切なコンテキストを要約したかを測定するものだ。
本番インフラにおいては、これでは不十分である。重要な問いは、AIエージェントの回答がもっともらしいかどうかではなく、そのアクションが安全で回復可能かどうかである。本番環境のAIエージェントは、Kubernetesクラスター、IAMポリシー、IaC（Infrastructure as Code）モジュール、デプロイメントパイプライン、クラウドネットワーキング、シークレット、データベースなど、非常に多くのものと相互作用する。これらのシステムはすべて相互接続されており、1つの小さなミスが多くのシステムに連鎖する可能性がある。
例えば、不適切な本番ロールアウトは顧客向けのダウンタイムを引き起こす可能性があり、過度に寛容なIAM変更はセキュリティ侵害の影響範囲を拡大させる可能性があり、ネットワーキング変更はサービス間通信を破壊する可能性がある。
CTOにとって、これはAIエージェントを生産性ソフトウェアとしてではなく、境界、アイデンティティ、監査可能性を必要とする本番自動化として評価することを意味する。ここでAIリスク基準が有用となる。例えば、米国立標準技術研究所（NIST）のAIリスク管理フレームワークは、ガバナンス、マッピング、測定、管理の各機能を中心に構成されており、AIエージェントがどこで行動できるか、そのリスクをどのように監視すべきかを決定するモデルを提供している。
スコープを限定した権限から始める
第一の、そしておそらく最も重要な設計原則は、最小権限である。AIエージェントは、多くの複雑なシステムにわたって推論できるという理由だけで、広範な本番アクセスと権限を得るべきではない。
CTOにとって、AIエージェントがどのシステムにアクセスでき、それらのシステムでどのようなアクションを実行できるかを追跡し、読み取りアクセスと書き込みアクセスのトレードオフを評価することは極めて重要である。
例えば、適切にスコープが設定されたエージェントシステムは、ログメトリクスとデプロイメント履歴を読み取るアクセス権を持つが、修正を推奨したり、人間の承認を経なければならないプルリクエストを開くことしかできない。一方、高リスクのエージェントシステムは、ネットワークポリシーの変更、リソースの削除、認証情報のローテーションの権限を持つものである。これらのアクションはすべて、企業に収益損失をもたらす顧客に見える本番障害につながる可能性がある。
すべてのエージェントは（人間のエンジニアと同様に）独自のアイデンティティを持つべきであり、人間の管理者の認証情報を借用すべきではない。そして各アクションはそのアイデンティティに帰属させるべきである。そうすることで、エージェントが何をしたか、どのシステムと相互作用したかを実際に追跡できる。
エージェントを可観測性のあるものにする
ブラックボックスの運用エージェントは大混乱を引き起こす可能性があり、私はこれを直接目にしてきた。AIエージェントに本番問題の調査と修復を任せるのであれば、エージェントがどのような証拠を使用し、どのような仮説を形成し、どのようなアクションを検討し、実際にどのようなアクションを実行したかについて、完全な可視性が必要である。
インシデント対応エージェントの場合、これは関連するアラート、ログ、メトリクス、デプロイメントとインフライベント、依存関係を含む調査証跡を生成することを意味する。そして修復エージェントの場合、これは提案されたコマンド、コード修正、構成変更を適用前に示すことを意味する。
エージェントを可観測性のあるものにする目的は、エンジニアにLLM推論のすべてのトークンを読ませることではなく、経験豊富なエンジニアがエージェントの結論とアクションを検証できる十分な証拠を公開することである。エージェントの可観測性はアクション適用前に限定されない。例えば、エージェントがデプロイメントをロールバックした場合、可観測性システムはインシデントが改善したか、変わらなかったか、さらには悪化したかを確認する必要がある。
検出、調査、安全な修復を圧縮する
本番インフラ向けAIエージェントの目標は、人間のサイト信頼性エンジニアを完全に置き換えることではない。目標は、検出、調査、そして最終的に安全な修復を適用するまでにかかる時間を短縮することである。
スタートアップから大企業まで、数十社のインシデント対応プロセスを観察してきた結果、最も遅い部分は人間に知性が欠けているからではない。関連するコンテキストがあまりにも多くの切り離されたツールとシステムに散在しているからである。AIエージェントは、これらのツール全体からコンテキストを迅速に引き出し、このデータを推論し、推奨される修正を伴う仮説を形成することに優れている。
これにより、人間のエンジニアにとっての手作業の全クラスが排除されるが、彼らの役割が排除されるわけではない。判断、エージェントが生成したアクションと修正の承認、ポリシーとコントロールの設定、パターンの特定、どの修復を恒久的な改善にすべきかの決定へとシフトするだけである。
CTOは運用規律を持ってAIエージェントを導入すべきだ
AIエージェントシステムは本番運用の不可欠な部分となる可能性が高まっており、最も恩恵を受ける企業は、エージェントに自由裁量と広範なアクセスを与える企業ではなく、明確な境界（スコープを限定した権限、可観測性、承認ゲート、監査可能性）を定義する企業である可能性がある。
CTOは、読み取り中心のワークフローと低リスクのアクションから始めるべきである。これらは、リスクを導入することなく、エンジニアの無数の手作業時間を節約するのに役立つ。そして必要なコントロールを実装した後、エージェントの自律性を拡大できる。
AIエージェントを本番インフラから完全に遮断しようとすることは正しいアプローチではない。代わりに、エージェントには、本番システムが依存する既存のエンジニアリング原則（最小権限、監査可能性、可逆性、説明責任など）を維持する方法でアクセスを許可すべきである。
CTOがこの基盤を正しく構築すれば、AIエージェントは、人間のエンジニアが高リスクのアクションをコントロールし続けながら、面倒な作業を削減する上で強力なものとなり得る。
