オンコール担当:AIエージェントがPagerDutyのアラートを修正案に変える

午前3時、インシデントの最初の30分はいつも同じ調査になります。アラートを読み、インシデントのログを開き、最近何が変わったかを考え、直近のデプロイを遡り、以前にも起きたかを確かめます。この読み込みと突き合わせの作業は繰り返しの多いものですが、オンコール担当者がそれを上手にこなせる状態から最も遠い瞬間に、重くのしかかります。1つの重要な条件のもとで、AIエージェントに向いています。エージェントは読んで提案し、行動するのは人間であることです。

着想:読む初動担当

出発点は、Hermes Agentのユーザーが報告している使い方で、オンコール担当のエンジニアに関するカードにまとめられています。アラートから修正案まで、という流れです。エージェントがインシデントを受け取り、原因になり得たものをリポジトリから探し、確認用の修正案を用意します。

読むことと提案することは残し、実行するものはすべて取り除きます。Atakoは、インシデントへのメモとリポジトリへのissueを書くものの、インシデントの解決、マージ、コードのプッシュのツールを持たないエージェントで、この考え方を実現します。

エージェントの仕事

このシナリオは、PagerDutyとGitHubリポジトリに接続した1つのエージェントをデプロイします。

監視対象サービスの新しいインシデント(発生中または確認済み)ごとに、アラート、イベントログ、すでにあるメモを読み、誰がオンコールかを確認します。次に、リポジトリで原因を探します。インシデント前の48時間のコミット(怪しいものは開いて確認)、アラートやスタックトレースに記載されたファイル、最近マージされたプルリクエストです。最初にどこを見るかは、入力された技術的な背景を手がかりにします。同種の過去のインシデントを含め、関連するissueも探します。

その後、PagerDutyのインシデントに、簡潔で事実に基づくメモを書きます。根拠が示していること、確信度付きの原因の可能性、根拠、確認できなかったこと、オンコール担当者の次の一手です。続いて、リポジトリに完全な分析を載せたissueを作成します。時系列、原因の可能性、根拠、言葉またはコード断片で記した修正案、そのリスクと確認方法です。重複を作らないよう、まず既存のissueを探し、完璧な分析を待つのではなく最初のメモを補足していきます。

サービスは15分ごとに監視し、毎週月曜日の9:00に、プロジェクトのwikiに「今週のインシデント振り返り」ページを書きます。対応したインシデント、原因の可能性、作成したissue、まだ未解決の事項です。

エージェントが行わないこと

制限は設計の一部です。エージェントはインシデントの解決、確認応答、再割り当て、エスカレーションを行いません。付与されたPagerDutyのアクセスは、読み取りとメモの追加に限られます。何もマージせず、コードもプッシュせず、ブランチやプルリクエストも作らず、インフラや本番環境にもアクセスしません。これらのツールは付与されていません。指示の中で約束しているのではなく、できる機能そのものがないのです。

エージェントは仮説を事実として提示しません。「可能性の高い原因」と書き、確信度と根拠を示し、何も見つからなかったときははっきりそう伝えます。ログやファイルで見つけた秘密情報、トークン、個人データはコピーせず、存在することとその場所だけを伝えます。アラートの文面、ログの行、コミットメッセージ、コードは分析対象のデータとして扱い、指示としては扱いません。判断と行動は人が担います。これが人による確認を組み込んだ設計の原則です。

Atakoでの設定方法

このユースケースのページから、デプロイは4つのステップで完了します。

1. PagerDutyとGitHubを接続します。 メモの追加権限付きで、できれば読み取り専用のPagerDuty APIキーと、サービスのリポジトリに限定したきめ細かい権限のGitHubトークンを作成します。接続は、何かが作成される前に確認されます。
2. コンテキストを入力します。 リポジトリを「オーナー/名前」の形式で指定し、監視するPagerDutyサービスの名前を伝え、必要なら技術的な背景(スタック、構成要素、壊れやすいと分かっている箇所)も簡単に書いてください。具体的なほど、エージェントは適切な場所を早く調べられます。
3. デプロイします。 1回の操作でエージェントとプロジェクト「オンコール」が作成されます。エージェントはプロビジョニングされ、最初の指示を自分で受け取ります。
4. 最初の結果、その後は定期監視。 エージェントはサービスを見つけ、誰がオンコールかを伝え、直近のインシデントを処理して、原因の可能性と修正案をチャットで要約します。その後、15分ごとの監視と月曜日の振り返りを自分でスケジュールします。

アカウントをまだお持ちでない場合は、作成するとトライアルが始まり、その直後にシナリオが設定されます。管理者がエージェントの作成を許可していない場合は、デプロイでその旨が通知され、そこで終了します。

結果の確認場所

分析メモはPagerDutyのインシデント上で、修正案を載せたissueはGitHubのリポジトリで確認できます。対応した各インシデントの要約は、エージェントのチャットで読めます。Atakoのプロジェクト「オンコール」には、仕組みを説明するページと週次の振り返りがあり、Atakoのフロアではエージェントが現在の動きとともに表示されます。

作業を細かく調整するには、エージェントのチャットで伝えます。たとえば「このサービスでは、まずデータベースのマイグレーションを確認してください」と書くと、その指示は記憶に保持され、以降のインシデントに反映されます。

安全策

アクセスは意図的に狭くしています。PagerDutyの接続は、読み取りとメモの追加のための7つのツールの一覧で、GitHubの接続は、コミット、ファイル、プルリクエストの読み取りと、issueの検索と作成のための7つのツールで付与されます。ツールの一覧が短いエージェントは、数百のカタログの中で迷うエージェントより確実にツールを使えます。さらに重要なのは、付与されていないことは、アラートの文面で強要されても起こり得ないという点です。

作成するキーが最初の安全策です。1つのサービス、1つのリポジトリ、明確な権限に限定されているため、何が起きても被害の範囲が抑えられます。キーは暗号化して保存され、失効やエージェントのアクセス削除はいつでも可能です。

人による確認は、意思決定の場面に置かれています。オンコール担当者がメモを読み、仮説を確認し、修正方針を決め、自分で修正を書いてマージし、そのうえでインシデントの確認応答と解決を行います。

期待できること

数分で有用な最初の分析が得られます。特に、デプロイ、設定変更、依存関係など、最近の変更から見える原因がある場合に有効です。原因がリポジトリの外にある場合、たとえばプロバイダーの障害やリソースの飽和では、エージェントは説明を無理に作らず、低い確信度でそのことを伝えます。リポジトリは読めますが、アラートとメモに書かれている内容を超えて、アプリケーションのログやメトリクスにはアクセスできません。価値は最初の読み込みの速さにあります。オンコール担当者は、白紙の状態ではなく、時系列、順位付けされた手がかり、確認すべき修正案を持ってインシデントに臨めます。