Cloudflare Workers に Issues が入り、本番エラーを Claude Code / Cursor / Devin へそのまま渡せるようになった

要約

Cloudflare は 2026-09-30、Workers に組み込みのエラー監視機能 Issues をオープンベータで追加しました。本番の失敗を自動で検知・グルーピングし、そのままコーディングエージェントへ調査と修正を渡せます。

捕捉する対象が具体的に列挙されています。 未捕捉の例外と失敗した invocation、HTTP 5xx 応答、スタックトレースを含む console のログとエラー、暴走した alarm、過剰なログ出力のパターン。繰り返す失敗はまとめられ、初出時刻・発生頻度・推移が追跡されます。

最後の2つが実務的です。 「暴走した alarm」と「過剰なログ出力」は、エラーとして現れないが課金に直結する問題です。Durable Objects の alarm がループすると、エラーログは出ないまま請求額だけが増えます。 これを検知対象に含めているのは、運用経験のある設計です。

ただし、この機能の中心は検知ではなく、連携先です。

接続先として明示されているのは次のとおりです。 Claude Code（routine ID とトークンで接続）、Cursor（automation webhook）、Devin（API トークンと org ID）、および汎用 webhook とインシデント管理ツール。

発火時に送られる情報が、エージェント向けに設計されています。 例外、ソースマップ適用済みのスタックトレース、ログ、トレース、Worker のバージョン、アプリケーションの文脈。

ソースマップ適用済みという点が重要です。 ビルド後のコードのスタックトレースを渡されても、エージェントは元のソースのどこが問題か判断できません。 適用済みで渡されるなら、調査がそのまま始められます。Worker のバージョンが含まれるのも、「どのデプロイから出ているか」を特定するために効きます。

文脈の追加も可能です。 組み込みの OpenTelemetry API で、追加パッケージなしにユーザー ID・アカウント ID・セッション ID などの独自識別子を付与できます。公式は「エージェントが調査に入る前に業務影響を把握できるようにする」意図と説明しています。

これは、エラー対応の優先順位付けに効きます。 同じ例外が100回出ていても、1人のユーザーで100回なのか、100人で1回ずつなのかで重大さが違います。 識別子が付いていれば、この判別がエージェント側でできます。

実例として、Cloudflare 自身のチームの話が出ています。 Workflows チームが Issues を有効化した当日に本番バグ2件を発見したとされています。内容は、マイグレーションのリトライループと、サブリクエスト上限を超える削除処理です。

この2件の性質に注目する価値があります。 どちらもサービスを停止させる障害ではありません。 リトライループは動き続け、サブリクエスト上限超過は一部の処理だけが失敗します。こうした「落ちないが壊れている」問題は、監視を入れていないと見つかりません。 ユーザーからの報告も来にくい種類です。

設定は wrangler.jsonc への1行追加で、オープンベータとして提供されています。ドキュメントは developers.cloudflare.com/workers/observability/issues/ にあります。

何が変わったか

• Workers に組み込みのエラー監視 Issues が追加（オープンベータ）
• 自動捕捉の対象: 未捕捉の例外、失敗した invocation、HTTP 5xx、スタックトレースを含む console のログとエラー、暴走した alarm、過剰なログ出力のパターン
• 繰り返す失敗をグルーピングし、初出時刻・発生頻度・推移を追跡
• 連携先: Claude Code（routine ID + トークン）、Cursor（automation webhook）、Devin（API トークン + org ID）、汎用 webhook、インシデント管理ツール
• 送信される情報: 例外、ソースマップ適用済みのスタックトレース、ログ、トレース、Worker のバージョン、アプリケーションの文脈
• 組み込みの OpenTelemetry API で独自識別子（ユーザー ID / アカウント ID / セッション ID 等）を付与。追加パッケージ不要
• 設定は wrangler.jsonc に1行
• Cloudflare の Workflows チームが有効化当日に本番バグ2件を発見（マイグレーションのリトライループ、サブリクエスト上限を超える削除処理）

業務インパクト（一般企業向け）

この機能は、エラー対応のフローを構造的に変えます。評価する前に、変わる部分を正確に把握してください。

従来のフローは、こうです。 エラーが出る → 監視ツールが通知する → 人が気づく → 人が調べる → 人が直す。ボトルネックは「人が気づく」と「人が調べる」の部分です。 特に調査は、ログを掘り、再現条件を特定し、該当コードを読むという作業で、時間がかかります。

Issues + エージェント連携のフローは、こうなります。 エラーが出る → Issues が検知・グルーピングする → エージェントへ文脈つきで渡る → エージェントが調査する → 人が結果を受け取る。

つまり、人が最初に見るものが「エラーの通知」から「調査結果」へ変わります。 これが効率の改善として働くか、別の問題を生むかは、統制の設計次第です。

先に決めるべきことを3つ挙げます。

1つ目。エージェントがどこまでやるか。

調査だけさせるのか、修正案を作らせるのか、PR を出させるのか、マージまでさせるのか。 この線をどこに引くかを、連携を設定する前に決めてください。 Claude Code の routine を接続するということは、エラーを契機にエージェントのセッションが起動するという意味です。 そのセッションに何を許すかは、routine の側の設定で決まります。

推奨は、最初は「調査と報告まで」です。 本番のエラーに対して自動で修正が入る構成は、動くことを確認してから広げるべき種類の自動化です。 調査結果の質が十分であることを数週間見てから、修正案の生成へ進む。これが安全な順序です。

2つ目。誤検知とノイズの扱い。

「過剰なログ出力のパターン」を検知対象に含めているということは、ログの出し方によっては頻繁に発火する可能性があります。 大量のエラーが毎回エージェントのセッションを起動すると、コストが発生し、かつ本当に重要なものが埋もれます。

最初の1週間は、連携先を設定せずに検知だけを有効にするのが実務的です。何がどれだけ検知されるかを見てから、どの条件でエージェントへ渡すかを決めます。 これを飛ばすと、初日に大量のセッションが起動することになります。

3つ目。OpenTelemetry の識別子に何を入れるか。

ユーザー ID を付与すると、エラーの重大さが判別できるようになります。 これは明確な利点です。

同時に、個人情報の取り扱いの問題が発生します。 識別子がエラー情報としてエージェントへ送られ、外部のサービス（Claude Code、Cursor、Devin）へ渡ります。 メールアドレスや氏名をそのまま入れると、本番の個人情報が第三者サービスへ流れる構成になります。

対策は単純です。内部 ID のみを入れ、個人を特定できる値を入れないことです。 「ユーザー 1,234 で3回発生」という情報で、重大さの判別は十分にできます。この方針を、実装する前にチームで明文化してください。 後から識別子を変更するのは、ログの連続性が失われるため面倒です。

次に、この機能が見つける問題の種類について。

公式の実例2件が示しているのは、「落ちないが壊れている」問題です。 マイグレーションのリトライループと、サブリクエスト上限超過。どちらも、サービスは動いています。 ユーザーからの報告は来ません。監視のダッシュボードでエラー率を見ていても、全体に対する割合が小さければ気づきません。

この種の問題は、放置されると2つの形で表に出ます。 1つは課金です。 リトライループは実行回数として課金されます。もう1つは、特定条件のユーザーの体験です。 一部の処理だけが失敗する状態は、該当するユーザーにとっては「このサービスは壊れている」です。

つまり、この機能の導入効果は「障害対応が速くなる」ではありません。 障害は、監視がなくても気づきます。効果は「気づいていなかった問題が見つかる」ことです。 導入初期に検知件数が多く出ても、それは機能の不具合ではなく、これまで見えていなかったものが見えた結果です。

この前提を関係者と共有しておいてください。 導入直後に「エラーが増えた」という報告が上がると、「監視を入れたせいで問題が増えた」という誤解が生まれます。 増えたのは検知であって、問題は元からありました。

副業・個人活用視点

個人開発では、エラー監視は後回しにされる機能の代表です。

理由は明確です。監視ツールの導入にはコストと手間がかかり、しかも「問題がないなら何も起きない」機能だからです。 Sentry などを入れようとして、SDK を追加し、DSN を設定し、ソースマップをアップロードする設定を書く。この工程を、個人のプロジェクトでやり切る人は少数です。

wrangler.jsonc に1行でよいなら、話が変わります。 オープンベータで、ソースマップの適用もプラットフォーム側が行います。 導入の障壁がほぼ消えています。

個人開発で最も効くのは、「落ちないが壊れている」問題の発見です。

ユーザーが少ないプロジェクトでは、問題のフィードバックが来ません。 10人のユーザーのうち1人の環境でエラーが出ていても、その1人は報告せずに離脱します。 そして、作った本人は自分の環境で動くので気づきません。

個人開発のツールが「使われない」理由の一部は、ここにあります。 機能や宣伝の問題だと思っていたものが、実は特定条件でのエラーだったという例は珍しくありません。検知の仕組みがないと、この可能性を検証できません。

課金への影響も、個人には直接的です。 暴走した alarm や過剰なログ出力は、請求額として現れます。 企業なら月の請求が数万円増えても気づくのに時間がかかりますが、個人のプロジェクトでは無料枠を一気に食い潰します。 これを検知できるのは、実利です。

Claude Code との連携は、個人開発の作業フローに組み込みやすいです。

「エラーが出たら、調査済みの状態で報告が来る」という状態を作れます。 個人開発では、エラーに気づいてから調査に入るまでの時間が最大のロスです。 平日は本業があり、週末にまとめて見る。その時点で「何が起きたか」をゼロから調べ直すのは、時間の無駄です。調査が済んでいれば、週末の時間を修正に使えます。

ただし、個人でも統制の線は引いてください。 自動で本番へ修正を入れる構成は、個人プロジェクトでも避けるべきです。 理由は、問題が起きたときに気づく人が自分しかいないからです。企業なら他の誰かが気づきますが、個人は気づきません。 調査と修正案の作成までに留め、マージは自分で行うのが安全です。

受託・支援の文脈では、これは提案しやすい材料です。

「本番で何が起きているかを把握していますか」という問いに、明確に答えられる組織は少ないです。 多くの場合、監視は入っていても、見られていません。 ダッシュボードは作られ、そして忘れられます。

ここでの提案価値は、「監視を入れる」ではなく「見なくても回る仕組みにする」ことです。 エラーがエージェントへ渡り、調査結果が Slack や PR として届く。人がダッシュボードを見に行く必要がない構成にすることが、実際に運用される監視の条件です。

提案の際の注意点を1つ。検知件数が初期に多く出ることを、先に説明しておいてください。

導入直後に「エラーが30件検知されました」という結果が出ると、顧客は「システムが壊れている」と受け取ります。 実際には、元からあった問題が見えただけです。 この説明を事前にしておかないと、「あなたが入れたツールのせいで問題が増えた」という誤解から始まります。

事前の説明の仕方としては、こう言うのが正確です。 「導入後、これまで見えていなかった問題が出てきます。件数が多く出ても、それは増えたのではなく見えるようになったということです。優先度を付けて順に対応します」。この一文を先に置いておくだけで、導入後の会話が変わります。

技術的な学びとしては、「検知」と「渡し先」を分けて考える発想が重要です。

この機能の新しさは、検知の部分ではありません。 エラー監視ツールは以前からあります。新しいのは、検知した情報を「エージェントが調査できる形」で渡すことを前提に設計されている点です。 ソースマップ適用済み、Worker のバージョン込み、OpenTelemetry での業務識別子付き。

ここから引き出せる設計原則は、こうです。 自動化の下流に何があるかで、上流が送るべき情報の形が変わる。 人が見る前提のエラー通知と、エージェントが処理する前提のエラー通知は、必要な情報量と構造が違います。 自社のログ設計を見直すとき、「これはエージェントが読んで調査できる形か」という問いを加える価値があります。