4つの自律型AIエージェントが、ソフトウェアの不具合を検出し、問題のあるコードを修正し、その修正を確認するまでをすべて1分以内で行えるようになりました。これは、SigNozハッカソン向けに構築された、新しいオブザーバビリティ駆動型のワークフローによるものです。

AgentOpsと名付けられたこのシステムは、SigNozを監視してエラーの急増を検知し、関連するログとトレースを取得して、原因となっている正確なファイルと行を特定します。次に、サンドボックス内でソースコードを編集し、リクエストを再実行してバグが解消されたことを証明します。1サイクルは30〜60秒で完了し、プロセス全体が人間のプロンプトなしで実行されます。

なぜAIエージェントにオブザーバビリティが重要なのか

従来のSREの実務では、ログ、メトリクス、分散トレースはサービスの「目」として扱われます。リクエストが失敗すると、エンジニアはトレースを辿って問題のあるコンポーネントを特定します。AgentOpsも同じ原理で動作していますが、監視対象となる「サービス」はAIエージェント自身です。

エージェントが呼び出すすべてのツール（言語モデルの呼び出し、ファイルシステムの編集、テストランナーなど）は、トレース内にスパン（span）を作成します。スパンは開始時間、実行時間、成功ステータスを記録するため、エージェントは各推論ステップにどれくらいの時間がかかったか、そしてそれが成功したかどうかを確認できます。これらのスパンを繋ぎ合わせることで、エージェントは人間が手動でデバッグする時のように、自身の思考プロセスの全体像を構築します。

重要な転換点は、「レポート層としてのオブザーバビリティ」から「知覚としてのオブザーバビリティ」への移行です。AgentOpsはトレースデータをエージェントにフィードバックし、エージェントが自身の行動についてリアルタイムで推論できるようにします。その結果、AIは仮説を立てるだけでなく、問題を検知するために使用したのと同じテレメトリを用いて、その仮説を検証するというループが実現します。

4ステップのワークフロー

  1. 監視 (Monitor) – 軽量なウォッチャーがSigNozをスキャンし、新しく報告されたエラーを探します。
  2. 診断 (Diagnose) – エージェントは関連するログとトレースを取得してスタックを抽出し、失敗を引き起こしたソースファイルのファイル名と行番号を特定します。
  3. 修正 (Fix) – サンドボックス化されたファイルシステムサーバーを使用して、エージェントは特定された行にパッチを書き込みます。サンドボックスは厳格な権限を適用し、編集がポリシーに違反した場合は自動的にロールバックします。
  4. 検証 (Verify) – エージェントはパッチ適用後のコードに対して元のリクエストを再発行します。トレースが正常な実行を示せば修正がコミットされ、そうでなければエージェントはプロセスを繰り返します。

すべてのステップは同じエージェント群によってオーケストレーションされ、各エージェントが自律的なマイクロサービスとして機能します。一連のプロセス全体は、SigNozが取り込み可視化するOpenTelemetry互換のスパンを通じてオブザーバビリティが確保されています。

信頼性に関する苦い教訓

エラーの明確化

単なる「失敗（failed）」というステータスでは何も分かりません。チームは、「仮説が誤っている」や「パッチがプロセスを破壊した」といった詳細な失敗理由を追加しました。これにより、後続のエージェントが再試行、バックトラック、または中止のいずれを行うべきかを判断できるようになります。これは、人間がポストモーテム（事後分析）で根本原因をラベル付けする方法を反映しています。

データ遅延

テレメトリは即座に表示されるわけではありません。エージェントは現在、修正を断定する前に、必要なログが確実に届いていることを確認するための短い一時停止とサニティチェック（健全性確認）を含めています。このガードがなければ、エージェントは不完全なデータに基づいて行動し、誤検知（false positive）を引き起こす可能性があります。

セキュリティ境界

AIにコードの書き込みを許可することは、権限昇格のリスクを伴います。サンドボックスは専用のファイルシステムサーバーの後ろで動作し、書き込み範囲を対象のリポジトリに制限し、テストが失敗した場合には自動的に前の状態に復元します。この封じ込めモデルにより、AIの権限を適切に制御しています。

トークン制限

大規模言語モデルはAPIトークンを消費するため、調査の途中で1日の割り当て量（クォータ）を使い果たしてしまうことがあります。AgentOpsはインシデントごとのトークン使用量を追跡し、しきい値に達するとそれ以上の呼び出しを制限（スロットリング）することで、クォータ切れによる修正失敗の連鎖を防ぎます。

デモが証明したもの

チームは、コードベースにこれまで一度も現れたことのない、全く新しいバグを注入しました。AgentOpsはその異常を検知し、正確な行までトレースし、修正用の編集を生成し、サンドボックス内でパッチを適用し、リクエストが成功したことを検証しました。これらすべてが、手動のコード変更や新しいプロンプトなしで行われました。エンドツーエンドの時間は1分以内にとどまり、報告されていた30〜60秒という所要時間と一致しました。

反論：自律性は万能薬ではない

次に注目すべき点

  • モデルに依存しないテレメトリ – より多くのベンダーがOpenTelemetry互換のスパンを公開するようになるにつれ、このアプローチはベンダーニュートラルになり、異種混合のスタック間での導入が容易になる可能性があります。
  • ポリシー駆動のガードレール – エージェントが編集できるファイルや、コミット前にパスすべきテストスイートを規定する設定可能なポリシーを組み込むことで、ガバナンスに関する懸念に対処できます。
  • コストを意識したトークン予算管理 – インシデントの深刻度に基づいた動的なトークン割り当てにより、影響の大きいバグへの対応能力を維持しながら、クォータの枯渇を防ぐことができます。

AgentOpsは、バグ修正サイクルが30〜60秒で完了することを示しています。この実験は、オブザーバビリティが自律型ソフトウェアアシスタントによって活用できることを示す概念実証（PoC）です。