AI駆動のアシスタントが7日間にわたって私のオンコール業務を担当し、11件のアラートを処理、問題解決にかかる平均時間を45分から20分へと短縮しました。この実験が重要なのは、控えめな規模の言語モデルであっても、厳格な人間の監視を前提とすれば、インシデント対応時間を30分も短縮できることを示しているからです。

なぜAIをオンコールに投入したのか

クラウドチームは、シフトの大部分をログの調査、最近のデプロイの確認、スケーリング要求の安全性の確認などに費やします。こうした「退屈な」タスクは、定型的でデータ量が多く、人間の疲労によるミスが起こりやすいものです。近年の大規模言語モデルの進歩は、まさにこうしたパターンマッチング作業の自動化を約束していますが、公開されているデモの多くはサンドボックス環境で実行されています。私は、その期待が、実際に有料顧客にサービスを提供している本番環境グレードのクラスターでも通用するかどうかを確認したいと考えました。

テストのセットアップ

  • アクセス権限 – エージェントはすべてのメトリクス、ログ、デプロイ定義を読み取ることができました。書き込み権限は、Podの再起動、レプリカ数の増加、デプロイのスケーリングといった、限定的なホワイトリストのみに制限しました。それ以外の操作には、私の明示的な承認が必要でした。
  • 役割 – モデルを、最初のオンコールシフトに臨むジュニアエンジニアとして扱いました。モデルはアラートを受け取り、分析を実行し、インシデント用のチャンネルに推奨事項を投稿します。
  • セーフティネット – すべての書き込み操作は、手動の「Yes/No」プロンプトによって制限されました。また、コストを予測可能にするため、モデルのトークン使用量にも上限を設けました。

AIが真価を発揮した場面

エージェントのスピードは、最も顕著な利点でした。アラートが発生するとすぐに、関連するログを取得し、最近のメトリクスをプロットし、直近3件のデプロイをリストアップしました。私がノートPCを開く頃には、初期の調査はすでに完了していました。11件のアラートのうち：

  • 8件はルーチンな問題（メモリのスパイク、コンテナの再起動、単純な設定ミス）でした。AIは毎回、正しく根本原因を特定しました。
  • マイクロサービスにおける緩やかなメモリ増加を、問題が深夜2時の障害に発展する前に検知し、チームが早期に対処する機会を与えました。
  • 1週間全体のトークン消費量は約30ドルにとどまり、上限を設定していれば一般的なオンコールの予算内に十分収まる範囲でした。

これらの結果は、MTTR（平均復旧時間）を45分から20分へと測定可能なレベルで短縮し、エンジニアがより影響力の高い業務に集中できる環境を生み出しました。

AIが躓いた場面

「自信があること」は「正しいこと」を意味しません。AIは11件のアラートのうち3件で、自信満々に間違えました。

  1. データベースの接続失敗の原因を最近のコードデプロイのせいにしましたが、その説明は誤りでした。
  2. 未知のネットワーク異常に直面した際、根本的な問題に対処できない一般的な修正案を提示しました。
  3. 負荷に関連するアラートが発生した際、サービスのレプリカ数を3から30に増やすよう提案しました。問題は負荷ではなく、設定ミスでした。

私のガードレール（制限策）により、書き込み操作には手動の承認が必要だったため、モデルのミスが被害をもたらす前に食い止めることができました。それでも、この経験は核心的なリスクを浮き彫りにしました。つまり、モデルは、特に未知の問題に対して、もっともらしく聞こえるが不正確な推奨事項を生成する可能性があるということです。

コストとリスク管理

30ドルのトークン料金は、使用量を監視していれば、本番環境のループ内でLLMを運用することは安価であることを示しています。しかし、真のコストは運用リスクです。デプロイのスケーリングミスはクラウド費用の暴走を招く可能性があり、正常なリリースのロールバックは顧客の信頼を損なう可能性があります。この実験により、2つの防護策が再確認されました。

  • アクションのゲート管理 – モデルには提案のみを許可し、人間のクリックなしに影響力の大きい変更を実行させないこと。
  • 予算の上限設定 – トークン消費量にハードリミットを設定し、モデルが上限に近づいたときにチームに通知すること。

次に注視すべき点

今後、チームは以下の点を行うべきです。

  • 手動でのオーバーライド（上書き）が必要になったAI生成の提案の割合を追跡する。
  • インシデントのカテゴリ別（ルーチン vs 未知）のMTTRへの影響を測定する。
  • 本番環境への書き込み権限を付与する前に、合成アラートを使用してステージング環境でモデルをテストする。

運用チームへの教訓

  • 退屈な80%を自動化する – ログの集約、メトリクスの相関分析、初期の仮説生成にAIを活用しましょう。
  • リスクのある20%は人間が担当する – 一定のしきい値を超えるスケーリング、ロールバック、削除などは、手動の承認ステップを残すべきです。
  • モデルを「代替品」ではなく「パートナー」として扱う – システムを熟知しているエンジニアであれば、新人よりも早くAIの出力を検証でき、アシスタントを「戦力倍増器（フォース・マルチプライヤー）」へと変えることができます。

AIエージェントは、まだ単独でクラウド運用を完結させることはできませんが、トリアージのパートナーとしては、すでに具体的なスピード向上をもたらしています。重要なのは、過信を避け、厳格なガードレールを設けることです。モデルに反復的な単純作業を任せつつ、人間の専門知識によって重要な意思決定を導いていくことが鍵となります。