本番エラーをAIのコード修正につなぐCloudflare Issuesで組む自動化の設計

AIがコードを書けるようになっても、公開したWebサービスの不具合が自動で直るとは限りません。たとえば、見積もり画面から送られたデータに必要な項目がなく、サーバー側の処理が途中で止まったとします。サービスを使う人には失敗が見えますが、コードを書くAIは、別途その出来事を知らされなければ修正を始められません。

開発者は通常、エラーの通知からログを開き、同じ失敗が何度起きているかを調べ、どの版を公開した後に発生したかを確かめます。さらに該当するソースコードを探し、失敗した要求を再現して、入力の不足なのか、外部サービスの停止なのか、コードの誤りなのかを切り分けます。AIへ修正を頼む場合も、その材料を集めて渡す工程が残ります。

Cloudflare Workersは、WebサイトやAPIのサーバー側のコードをCloudflare上で動かすサービスです。2026年9月30日に発表された「Issues」は、その実行中に起きる関連した失敗を検出・集約します。Issuesの通知設定「Automation」が、指定した条件に達した問題のエラーや発生時の情報を連携先へ送ります。開発者が一件ずつログを拾う前に、同じ問題として扱う単位を作り、AIへ知らせられるようになりました。

通知の受け手をコーディングエージェントにすると、不具合の検知をコード修正の開始条件にできます。ここでいうエージェントは、指示された目的に沿ってコードを読み、実行環境でテストを動かし、結果を見ながら変更を進めるAIです。成功した変更を製品へ届けるには、修正対象、合格条件、反映する権限も用意します。

この記事では、検知からコード反映までを一つの流れとして設計します。Issuesによる失敗の集約と、Automationによる外部への通知は公式機能です。問題ごとに対象コードと修正の進行状況を記録する「修正台帳」や、コードを自動反映する規則は、筆者の提案として説明します。

Cloudflare上の検知・通知から本番反映までを通した実測は行っていません。

Issuesは、未処理の例外、実行の失敗、Workerが返したHTTP 5xx、エラーレベルや例外情報を含むコンソールログを検出します。同じWorkerの関連する発生例を一つのIssueにまとめるため、要求ごとに違う識別番号があっても、繰り返している問題を追えます。ブラウザ内で起きるJavaScriptの例外は、今回のWorkerの検出仕様に含まれていません。

検出のためのSDKやアプリのラッパーは不要です。WranglerというWorkersの開発・公開用ツールを使う場合は、4.134.0以上でobservability.issues.enabledを有効にして公開します。有効化後の通信が対象で、過去の障害を遡って集約する機能ではありません。2026年10月1日時点では全Workersアカウント向けのオープンベータで、Issuesはベータ期間中無料です。

発生例には、取得できた範囲でエラーとスタックトレース、関連ログとトレース、実行したWorkerのバージョン、要求の情報が付きます。スタックトレースは、失敗へ至ったコードの呼び出しを示す記録です。元のソースの位置へ戻せる情報があれば、AIが該当箇所を探す手掛かりになります。すべての発生例で同じ材料がそろうとは限りません。

外部への受け渡しは「Automation」で設定します。発生件数が指定値に達した時、または一定期間止まっていた問題が再発した時に起動します。件数の条件は、その後のエラー一件ごとに繰り返し起動するものではありません。標準のAI連携にはClaude Code、Cursor、Devinがあり、自前の処理にはHTTPSの通知先を指定する汎用Webhookを使えます。SlackやGoogle Chatへの通知は、人が進行状況を把握する入口にもなります。

Automationの実行が成功したという表示は、Cloudflareの通知基盤が配送するイベントを受け付けたことを示します。AIがコードを修正し、テストを通して本番へ反映する処理は、この通知を受けた後に別途進める仕事です。その完了は、通知の成功とは分けて確認します。

追加のログをAIに調べさせる場合は、AIが外部の道具を使う接続方式であるMCPなどを別途設定します。通知を受け取っただけでCloudflareアカウントの照会権限が付くわけではありません。また、Issuesの検出自体にログやトレースの有効化は不要ですが、独自の利用者識別情報を加えるにはトレースが必要です。トレースは2026年10月1日からログと共通の利用枠・従量料金に含まれるため、Issuesの無料提供と分けて考えます。

最初に試すなら、Issuesから標準連携のエージェントへ渡し、修正案を人が確認する構成で始められます。Claude Codeでは繰り返し実行する指示とリポジトリを登録したRoutine、CursorではWebhookで起動するAutomationを使います。AIが調査してコードを変更し、変更をレビューするためのプルリクエストを作るところまでを任せます。

複数の問題を継続して処理し、許可した変更を自動で反映するなら、通知とAIの間に受付と修正台帳を置きます。以下は、その管理層と反映後の確認器を加えた筆者の提案構成です。確認器は、安全な確認用の要求を送り、期待する応答、元のエラーの再発、別のエラー、応答時間を調べて台帳へ記録する仕組みです。図の上段でCloudflareが失敗を検出し、中段から下段で修正を製品へ戻します。

AIが編集するのは、製品のソースコードを複製した隔離環境の作業ブランチです。コードの変更を自動検証する仕組み（CI）がテストを実行します。マージと本番への公開は、反映規則とCIの結果を照合し、許可した変更を公開するプログラム（実行器）が担当します。実行器はAIの作業環境から独立して動かします。AIの処理が途中で失敗しても、どの工程まで進んだかを台帳から確認できるようにします。

Cloudflareで管理層を作る場合、長時間の処理を工程ごとに保存・再試行するWorkflowsが部品の候補になります。外部のAIの完了や人の承認を待つ処理も組めます。ただし、Workflowsを置いただけで外部の書き込みが一度だけになるとは限りません。AIの起動、プルリクエストの作成、デプロイには、同じ要求の再送でも既存の処理を再利用する設計を加えます。

エラーにWorkerのバージョンが付いていても、その値だけでGitのソースコードの版が確定するとは限りません。Gitはコードの変更履歴を管理する仕組みで、一つの保存版をコミットと呼びます。公開時に「WorkerのバージョンID、Gitコミット、リポジトリ、環境」を対応付けて記録しておくと、受付が発生時のコードを探せます。

Worker名と環境から、修正を許可するリポジトリと公開先を管理者の設定で決めます。エラーメッセージに書かれたURLやファイル名をそのまま修正先として採用しません。通知は認証して受け取り、AIへ渡す前に認証情報や必要のない要求本文を除きます。利用者が入力した文がログへ混ざる場合、その文は不具合の証拠として扱い、AIへの作業指示と区別します。

対象が分かったら、同じIssue、対象環境、発生版の組み合わせに進行中のジョブがあるかを確認します。既存のジョブが調査中やレビュー中なら、新しい通知は発生情報の追加へ回します。通知の再送で同じ修正を何度も開始しないためです。同時に通知が届く場合に備え、台帳ではこの組み合わせを一意にし、ジョブの登録と起動の予約を一回の更新にまとめます。解決後の再発は、新しい試行として回数を制限しながら扱います。

古い版のエラーが遅れて届くことも考えます。段階的な反映中は複数の版が稼働するため、単純に最新の版と違うという理由で捨てず、実際に通信を処理している版の集合と照合します。すでに使われていない版の問題は、現在稼働中の版へ同じ入力を与えても再現するかを先に調べます。

別のIssueを担当するAI同士にも調整が必要です。同じ製品を同時に変更すると、一方が直した箇所を他方が古い状態へ戻す可能性があります。調査用ブランチは並行して作れても、同じ公開先への反映は順番に進めます。先の変更を取り込んだ最新コードで後の変更を再検証し、その版に対してだけ反映を許可します。

台帳には、Issueと発生版、調査に使ったコミット、作業ブランチ、プルリクエスト、検証結果、反映したWorkerの版を残します。AIの起動がタイムアウトした場合も、すぐ別のAIを起動せず、外部の実行IDで既存の作業を照会します。起動結果が分からない状態と、作業が失敗した状態を分けると、二重の修正を減らせます。

AIへ渡す依頼には、直してよいコードと、期待する挙動を含めます。たとえば「郵便番号が欠けた見積もり要求は入力不備として返し、正常な要求の送料と合計は変えない」という条件です。値の不足を検出しただけでは、必須項目なのか、省略を許す仕様なのかは決まりません。期待する挙動が未定なら、コード変更の前に担当者が仕様を決めます。

AIは、発生時のコードと現在のコードを確認し、失敗した入力を安全なテストデータへ置き換えて再現します。現在のコードですでに直っていれば、同じ修正を追加しません。再現できなければ、調べた材料と不足する情報を返し、推測だけで反映へ進まないようにします。

筆者は再現テストと正常時のテストを併せて確かめるため、Workerのリクエスト処理を模したコードを、Cloudflareへ公開せずNode.jsで実行しました。この実演は、筆者が入力不備の修正例を用意し、同じテストを修正前後へ実行した比較です。通知を受けたAIの自動起動やコード修正、Cloudflareの実行環境、Issuesの検知・通知は検証していません。

テストの商品は、単価1200円を2点、小計2400円に固定しました。郵便番号の先頭が9なら送料700円、それ以外は500円とする実演用の条件です。変更前のコードはinput.customer.postalCode.trim()を呼ぶため、郵便番号が欠けると例外になります。修正例には、入力不備を検出して400応答を返す処理を加えました。郵便番号は、前後の空白を除いた7桁の数字の文字列を有効としました。以下は、この実演用の入力検証を修正前後で実行した結果です。金額は仮の送料規則から計算した値で、実サービスの料金や性能を検証した結果ではありません。

修正では、郵便番号の型と形式を先に確認し、JSONの読み取り失敗も入力不備として返すようにしました。HTTP 400は、送り手の入力を直す必要があると伝える応答です。例外を一律に成功扱いにすると不具合を隠しますが、必須項目が不足した要求を400で返す挙動なら、入力の不足を明示したまま処理を終えられます。

本番反映も検証していません。また、商品データ全体の検証まで実装したサンプルではありません。ここで得た結果は、失敗の再現と正常時の挙動を同時に確かめる工程に限られます。

修正前後のコードと7項目のテストをダウンロードできます。追加パッケージは不要で、同梱の手順に従ってNode.jsで修正前後を比較できます。

実サービスでAIが提出する変更にも、修正前に失敗し修正後に成功する再現テストと、既存の機能が変わっていないことを確認するテストを付けます。既存テストの期待値を都合よく変えて通した変更は、合格条件から外します。修正案には原因、変更した範囲、実行したテスト、確認できなかった条件を添えます。

事前に自動反映を許可する範囲を決めれば、条件を満たす修正は、人が毎回ボタンを押さずに製品へ戻せます。ここでは、反映用の実行器が規則と検証結果を照合する方法を提案します。標準のIssues連携は、人が変更をレビューして公開する流れを案内しており、この自動判定は追加で設計します。

最初の候補は、仕様が確定した入力チェックなど、変更範囲を狭く切れる修正です。変更を許可したファイル、禁止する変更、テスト、元の版へ戻せる条件を登録します。正常な要求の結果を変えないことに加え、認証、価格計算、決済、データベース構造へ触れていないことも確認します。ファイル名の照合だけでは変更内容を判定できないため、差分のレビューと保護ルールを組み合わせます。

AIが作業した後に別の変更が入った場合、以前のCI成功をそのまま使いません。反映するコードのコミットと検証済みのコミットを照合し、変わっていれば再検証します。CI、レビュー規則、マージ条件をAI自身が変更して通過できないよう、反映の判定は作業環境の外に置きます。

自動反映の許可は、担当者が設定した規則から与えます。エラーログに「今すぐデプロイ」と書かれていたことや、AIが「問題ない」と返したことを許可の根拠にはしません。実行時間、修正の試行回数、利用料金にも上限を設け、繰り返し直せない問題は担当者へ渡します。

マージできたこと、公開できたこと、問題が直ったことは、それぞれ別の結果です。修正コードが動き、問題が直った証拠まで台帳に残すには、本番反映の後に確認器を動かします。

Workersの段階的デプロイを使うと、通信の一部を新しいバージョンへ配分できます。新旧の版を区別して、元のエラーの発生率、正常な要求の成功、応答時間、別のエラーの増加を比べます。最初の配分や観測時間は、サービスの通信量と失敗時の影響に合わせて決めます。例えばこの見積もり処理では、郵便番号が欠けた入力と正常入力の確認用要求をすべて実行し、400応答と既存の金額に一致することを必須にします。さらに、あらかじめ決めた観測要求数と観測時間を満たす間に当該Issueが再発せず、正常系の失敗率と応答時間がサービスの許容値を超えないことを完了条件にします。

見積もりの例なら、安全な確認用の要求で、郵便番号が欠けた入力は400になること、正常な入力の送料と合計が変わらないことを確かめます。売上や決済を発生させる要求を本番へ繰り返し送る方法は避け、確認用の経路やテスト環境を用意します。入力不備の増加は400として別に数え、5xxが減った数字だけで改善を判定しません。

通信が少なく、問題の入力が再び来ていないだけなら、エラーがゼロでも修正成功と決められません。確認用の要求と十分な観測がそろった時に完了へ進め、期限内に確認できなければ「確認待ち」のまま担当者へ渡します。Issuesの発生例の詳細は7日間保持されるため、調査に必要な情報はその間に取得します。

悪化が見えた場合は、新しい版への配分を止め、戻せる直前の版へ復旧します。ただしコードを戻しても、保存データの変更や送信済みの外部操作まで戻るとは限りません。今回の自動反映対象からデータベース構造の変更などを外すのは、復旧手順を一つに保つためでもあります。

提案する確認器は、修正版の動作を確かめた後、修正台帳へ完了を記録します。Issuesは自動では解決済みにならないため、担当者が確認記録を見てIssueの状態を解決済みに更新します。確認器から状態を自動更新するAPIや権限は、今回の調査では確認していません。状態更新まで自動化する場合は、使える操作方法と必要な権限を別途確かめます。

解決後に新しい失敗が発生すると、IssueはActiveへ戻ります。再発した場合は、前回の修正内容と反映版、確認記録を添えて再調査するため、前回と同じ情報集めから始めずに済みます。

本番へコードを自動反映する前に、実際の通知から修正案を作る流れを一つのWorkerで通します。広い権限や複数の製品へ一度に広げず、どの工程で材料や判断が足りなくなるかを見ます。

1. Issuesを有効にし、修正対象のリポジトリと担当者を決めます。最初は標準AI連携か汎用Webhookで、修正案の作成までを動かします。
2. 公開するたびにWorkerのバージョンとGitコミットを対応付けます。受付では環境と対象を照合し、稼働中の版の問題を選びます。
3. 同じ問題の通知を再送しても修正ジョブが増えないこと、AIの処理が止まっても途中状態から確認できることを試します。
4. 再現テスト、正常時のテスト、差分レビューをそろえ、人の確認を経てテスト環境へ反映します。
5. 本番の一部へ反映し、修正した挙動と他の機能、戻す手順を確認します。問題が消えたと判定する観測条件も決めます。
6. 記録から安定して処理できた変更だけを、事前の自動反映規則へ追加します。規則外の問題は引き続き担当者へ渡します。

Cloudflareの公式発表には、自社のWorkflowsでIssuesを有効にし、移行処理の再試行が続く問題と削除処理が完了しない問題を発見した事例があります。Automationで社内のエージェント基盤Cloudflare OSへ送り、両方のコード修正案を得たという報告です。これはIssuesからAIへ問題を渡した提供企業の利用例です。今回提案した修正台帳、反映規則、反映後の確認までを検証した事例とは区別します。自分の製品での修正成功率を示す結果ではありませんが、本番の出来事をAIのコード作業の入口にする利用例として参考になります。

筆者の見立てでは、開発者の仕事は、エラーの情報をAIへ貼り付ける作業から、修正してよい範囲と成功の条件を整える仕事へ比重が移ります。再現できる入力、検証できる仕様、公開した版の記録がある製品ほど、コード修正を自動で進める条件を明確にできます。最初に整えるべきものは、現在の製品でどの不具合をどう直せば正しいのかを確かめられる記録です。