Cloudflareは、Cloudflare Workers内のエラーを監視するIssues機能を開始し、現在オープンベータ版として提供している。この機能は繰り返し発生する失敗を1つの問題にまとめ、その詳細をコーディングエージェントへ送信して、調査の継続、修正案の提案、プルリクエストの作成を行えるようにする。
Cloudflareが対象とするのは、本番障害の処理サイクルにおける実務上のギャップだ。エージェントは監視データを照会し、コードリポジトリ内を移動し、テストを作成してコードを変更できる。しかし、これらの手順を結び付けるには、複数の失敗が同じ障害に起因することを確認しながら、ログやトレースを人間が集める必要があった。
Issuesが監視する対象
この機能はWorkers環境内で動作し、SDKのインストールやアプリケーションへのラッパーの追加を必要としない。有効化すると、未処理の例外、失敗した呼び出し、5xxクラスのHTTPレスポンス、console.log()とconsole.error()の出力に加え、呼び出しスタックを含むログを記録する。また、アラートのトリガーが繰り返し実行される状態や、ループ内で大量のログが書き込まれる状況も検知する。
失敗したリクエストをそれぞれ別のケースとして表示するのではなく、Issuesは類似したエラーをまとめ、最初に発生した時刻、発生回数、発生率が増加しているかどうかを示す。問題、利用可能な場合は呼び出しスタック、前後のログとトレース、Workerのバージョン、リクエストの詳細、時間経過に伴う問題の傾向を表示する。
調査にアプリケーションコンテキストを追加
開発者はWorkers環境に組み込まれたOpenTelemetryインターフェースを使用して、ユーザー、アカウント、セッションなどの識別子を付加できる。これらのデータは各occurrenceとともに表示されるため、エージェントへ送信する前に、障害が特定のアカウントやセッションに集中しているかどうかを特定するのに役立つ。
監視ダッシュボードからコーディングエージェントへ
Automationを設定すると、問題の発生回数が指定したしきい値を超えた場合や、一定の静止期間後に再発した場合に送信を実行できる。Cloudflareは、routine IDとtokenを使用したClaude Codeとの連携、webhook URLを使用したCursorとの連携、API tokenと組織IDを使用したDevinとの連携に加え、一般的なwebhook、チャットシステム、インシデント管理システムにも対応している。
送信されるコンテキストには、失敗の概要、例外、ソースに対応付けられた呼び出しスタック、ログとトレース、Workerのバージョン、開発者が追加したアプリケーションコンテキストが含まれる。より深い調査を行うため、エージェントをCloudflare MCPに別途接続し、関連するログやトレースを照会して、コードやテストの変更を提案し、プルリクエストを作成することもできる。
実際に何が変わるのか
Issuesは、障害の検知から調査までの手作業を減らすが、修正を完全に自動化するものではない。プルリクエストのレビュー、変更のデプロイ、問題を解決済みの状態にする作業は、引き続きチームの管理下にある。また、結果の品質は、アプリケーションが追加するコンテキストと、選択した実行設定およびしきい値に左右される。
Cloudflareは、Workers上に構築された長時間実行・多段階アプリケーション向けコンポーネントであるWorkflowsでこの機能をテストした。1日の間に、自動化によって2つの問題を発見できた。1つは、外部キーに関するSQLiteエラーが原因で、コントロールプレーンの移行中にリトライループが発生した問題。もう1つは、Workersのサブリクエスト制限を超過したため、削除処理が完了しなかった問題だ。自動化はこの2つの問題をCloudflare OSに送信し、Cloudflare OSはWorkflowsのコード内でエラーを追跡し、2つの修正案を提案した。
利用を開始するには、まずwrangler.jsoncファイルでobservability.issues.enabledを有効にし、その後Cloudflareのダッシュボードで最初のAutomationを設定して、問題の送信先としてエージェント、webhook、インシデント管理ツール、チャットプラットフォームのいずれかを選択する必要がある。