Cloudflareを利用するWordPressで「Error 1102: Worker exceeded resource limits」が表示され、ページ表示、REST API、画像変換、HTML書き換えなどが途中で止まることがあります。これはWordPressのPHPメモリ不足と同じエラーではなく、前段で実行されたCloudflare Workerが資源上限を超えたときに発生します。
Error 1102の原因は、大きくCPU時間の超過とメモリ上限の超過に分かれます。ループや重い解析はCPU、巨大なHTML・画像・JSONを一括で読み込む処理はメモリを疑います。先にMetricsとLogsでどちらかを分けないと、上限だけ変えて再発する可能性があります。
いきなりWordPressのPHP設定を上げたり、Workerの上限を最大にしたりしないでください。エラーURL、時刻、Ray ID、直前デプロイを保存し、資源を使い切った処理と入力条件を特定します。
先に結論：Error 1102は8段階で確認する
- エラー画面、URL、時刻、Ray IDを保存する
- 失敗するパス・操作・入力サイズと成功例を分ける
- 対象URLに一致するWorkerとルートを確認する
- 直前デプロイ・設定・依存関係の変更を確認する
- MetricsのInvocation StatusでCPU超過かメモリ超過かを見る
- Workers LogsでCPU時間、壁時計時間、例外、入力条件を照合する
- 安定版へのロールバック、処理削減、分割、ストリーミングを行う
- 代表URLとWordPressの保存・フォーム・APIを再確認する
Invocation Statusが「Uncaught Exception」なら資源超過ではなく、Cloudflare Error 1101の例外確認手順を使います。まずエラー分類を確定することが復旧の近道です。
Cloudflare Error 1102とは？
Cloudflare公式のError 1102では、WorkerがCPU時間またはメモリの上限を超えた状態と説明されています。CPUではループやJSON解析などの計算、メモリでは大きな本文の保持、巨大オブジェクト、配列や文字列の蓄積が代表例です。
WorkerがWordPressの前段でHTMLを書き換える、認証する、キャッシュを制御する、外部APIをまとめるといった処理を行っていると、オリジンのWordPressが正常でも1102が返ります。WordPressへ要求が到達する前、またはオリジン応答をWorkerが加工中に止まる場合があります。
1102・1101・524・503の違い
| 表示 | 主な意味 | 最初に見る場所 |
|---|---|---|
| Cloudflare 1102 | WorkerのCPU・メモリ資源超過 | Invocation Status、CPU・メモリ |
| Cloudflare 1101 | Workerの未処理例外 | exceptions、スタック、直前デプロイ |
| Cloudflare 524 | オリジン接続後の応答待ち | PHP、DB、外部API、長時間処理 |
| 503 Service Unavailable | 一時的な処理不能・過負荷・保守 | 発行元、Retry-After、サーバー状態 |
ページが長時間待ってから524になる場合は、Cloudflare 524の長時間処理を確認する手順が中心です。503なら、WordPressの503を原因別に直す手順で発行元を分けます。
CPU時間・壁時計時間・メモリの違い
| 指標 | 何を測るか | 増えやすい処理 |
|---|---|---|
| CPU時間 | WorkerコードがCPUで計算した時間 | ループ、解析、変換、圧縮、暗号、正規表現 |
| 壁時計時間 | 開始から終了までの実時間 | fetch、KV・DB待ち、外部API、ストリーム |
| メモリ | isolateが保持するデータ量 | 巨大本文の一括読込、配列蓄積、WASM、キャッシュ |
Cloudflare公式のWorkers Limitsによると、ネットワーク要求を待つ時間はCPU時間に含まれません。2026年8月確認時点では、HTTP要求のCPU時間はFreeで10ms、Paidは既定30秒で最大5分まで設定可能、メモリは1 isolateあたり128MBです。数値は変更され得るため、設定前に必ず最新の公式表を確認してください。
「ページが10秒かかった」だけではCPUを10秒使ったとは限りません。外部API待ちが長いのか、実際の計算が重いのかをLogsのCPU timeとwall timeで分けます。
WordPressで1102が出る主な原因
1．HTML全体を何度も解析・置換している
WorkerでWordPressのHTMLを取得し、複数の正規表現、DOM相当の解析、文字列置換を繰り返すとCPUとメモリの両方を使います。長い記事だけ失敗する場合は、本文サイズと処理回数を比較します。
2．大きなResponseやRequestを一括で読み込んでいる
response.text()やrequest.arrayBuffer()で大きな本文・画像・バックアップ・API応答を全量保持すると、メモリ使用量が急増します。ファイルサイズが大きい場合は、1102の前に413 Content Too Largeが別の層から返ることもあります。
3．終了条件の弱いループや再帰がある
ページ内リンク、JSON項目、検索結果などを走査するループで、入力に比例して処理量が急増することがあります。特定件数を超えたときだけCPU超過になるなら、ループ回数、ネスト、重複計算を確認します。
4．配列や文字列へデータを追加し続けている
ログ用データ、API結果、HTML断片を配列や文字列へ蓄積し、最後にまとめて返す設計はメモリを圧迫します。全件を保持せず、必要項目だけに絞る、逐次処理する、出力をストリーム化する方法を検討します。
5．グローバル領域に大きなデータを保持している
大きな辞書、テンプレート、解析済みデータ、WASMメモリをグローバル領域へ置くと、同じisolateが複数リクエストを処理する間のメモリ負担が増えます。小さな不変データの再利用と、大量データの保持を分けて考えます。
6．依存パッケージや新機能で計算量が増えた
画像処理、圧縮、暗号化、Markdown変換、Bot判定、A/Bテストなどを追加した直後は、バンドル変更と負荷増加を確認します。本番データの大きさやアクセス集中で初めて上限に達することがあります。
変更前に保存する情報
- 1102画面、URL、Ray ID、発生時刻、タイムゾーン
- 失敗するパス、HTTPメソッド、操作、入力サイズ
- 成功する最小入力と失敗する入力の違い
- 対象Worker名、ルート、デプロイバージョン
- 直前のコード、依存関係、Binding、設定変更
- Invocation Status、CPU time、wall time、メモリ関連の記録
- アクセス集中時だけか、単発でも再現するか
- 安定版と、ロールバック時に影響する関連データ
入力データやログを共有するときは、Cookie、Authorization、APIトークン、個人情報、投稿の非公開内容を隠します。巨大な本文そのものをログへ出すと、調査用ログが新たな負荷や情報漏えいの原因になります。
MetricsとLogsでCPU・メモリを分ける
CloudflareダッシュボードでWorkers & Pagesから対象Workerを選び、MetricsのErrorsとInvocation Statusesを確認します。「Exceeded CPU Time Limits」ならCPU、「Exceeded Memory」ならメモリを優先します。「Uncaught Exception」なら1101系の例外です。
次にWorkers Logsで失敗時刻と対象パスを絞り、CPU time、wall time、outcome、例外を照合します。平均値だけでなく、失敗した要求に共通するパス、本文サイズ、パラメータ、デプロイバージョンを確認してください。
| 観測結果 | 優先する調査 | 代表的な修正 |
|---|---|---|
| CPU timeが上限付近 | 重い関数、ループ、解析 | 計算削減、キャッシュ、分割 |
| wall timeだけ長い | fetch、DB、外部API待ち | タイムアウト、並列化、依存先確認 |
| Exceeded Memory | 本文の一括保持、配列、global | ストリーム、上限、保持削減 |
| 特定パスだけ失敗 | ルート別処理、入力サイズ | 対象処理限定、早期終了 |
| 更新直後から急増 | 新バージョンとの差分 | 安定版、修正版、段階展開 |
ローカルで再現できる場合は、Cloudflare公式のCPU profilingを使い、重い関数を特定します。本番と似たURL、件数、データ量で測り、軽いサンプルだけで正常と判断しません。
CPU超過・メモリ超過を安全に直す
1．更新直後なら安定版へ戻して影響を止める
新デプロイ直後に1102が増え、前バージョンが正常だった場合は、安定版へのロールバックを検討します。デプロイだけが戻り、KV・D1・R2などの保存データは自動では戻らないため、データ構造とBindingの互換性を確認します。
2．CPU超過は重複計算と処理対象を減らす
ループ回数、ネスト、正規表現、JSON解析、圧縮、暗号、HTML変換をProfilerで確認します。同じ値を何度も計算しない、対象パスやContent-Typeを早い段階で除外する、計算結果を適切にキャッシュするなど、最も重い箇所から減らします。
3．大きな処理を小さな単位へ分ける
一つの要求で大量の記事、画像、API結果を処理せず、件数制限、ページ分割、キュー、Durable Objectsなど用途に合う仕組みへ分けます。閲覧者への応答に不要な処理は、応答経路から切り離します。
4．メモリ超過は全量バッファをストリームへ変える
CloudflareのWorkers Best Practicesは、大きなRequestやResponseを一括で読み込まず、ストリーミングすることを推奨しています。内容を変更しないならResponse bodyをそのまま渡し、加工が必要でも逐次処理を検討します。
5．入力上限と早期終了を設ける
JSON、フォーム、画像、HTMLを読み込む前にContent-Lengthや業務上の上限を確認し、不要な大容量入力を処理しません。上限を超えた要求には、秘密情報を含まない明確な応答を返します。
6．CPU上限引き上げは最適化後に判断する
PaidプランではCPU時間上限を調整できますが、無限ループ、入力比例の急増、重複計算を残したまま上げると、遅い処理と費用を固定化します。必要CPUを測定し、業務上妥当な処理だけに限定して設定します。メモリ上限の128MBは同じ方法で引き上げるものではありません。
7．修正版を段階的に展開する
本番データでのみ再現する場合は、プレビューとテストを通したうえで、可能なら新旧バージョンへトラフィックを分け、エラー率とCPU時間を監視します。異常があれば安定版へ戻せる状態を保ちます。
WordPressサイトで確認するポイント
- 長い記事、検索結果、フィード、REST APIだけ失敗していないか
- 画像・バックアップ・フォームなど大容量処理だけ失敗していないか
- HTML書き換えWorkerを本当に全パスで実行する必要があるか
- 管理画面、ログイン、プレビュー、保存を不要に加工していないか
- キャッシュヒットとミスでWorker処理量が変わっていないか
- 投稿更新後のHTMLサイズ増加と1102開始時刻が一致していないか
- Worker復旧後にPHPやDB側の別エラーが残っていないか
WordPressのmemory_limitやPHP実行時間はオリジン側の設定です。1102がWorkersのExceeded MemoryまたはExceeded CPU Time Limitsなら、PHP設定を上げても直接の解決にはなりません。発行元と資源の場所を分けてください。
再発を防ぐチェック
- エラー率、CPU time、wall time、メモリ結果をデプロイ前後で比較する
- 長文、大きなJSON、画像、空値、異常値をテストに含める
- 大きな本文を全量保持せず、ストリームを基本にする
- ルートを必要最小限にし、不要なWordPressパスを除外する
- 新機能を段階展開し、安定版のロールバック先を残す
- ログへ本文・秘密値を出さず、識別に必要な情報だけ残す
- 公式のLimitsを定期確認し、固定値をコードへ埋め込まない
やってはいけない対処
- 原因未確認のままCPU上限だけを最大化する
- 1102を見てWordPressのPHPメモリだけを変更する
- 巨大なRequest・Response・ログを全量メモリへ載せる
- 本番の投稿保存や外部送信を連打して再現する
- 全Cloudflare機能を無効化し、影響範囲を分からなくする
- 安定版と関連データの互換性を見ずにロールバックする
よくある質問
1102はアクセス集中だけで起きますか？
アクセス集中がきっかけになることはありますが、単一リクエストの重い計算や巨大な本文でも発生します。失敗件数だけでなく、失敗した要求ごとのCPU時間、入力サイズ、メモリ結果を確認します。
待てば自然に直りますか？
一時的な入力や負荷なら次の要求は成功する場合がありますが、同じ処理が同じ上限を超えるなら再発します。送信系操作を連打せず、運営者がMetricsとLogsを確認してください。
CPU上限を上げれば解決しますか？
業務上必要な重い計算には有効ですが、無限ループや重複処理、入力サイズに比例して増え続ける設計の根本解決にはなりません。Profilerで必要量を測り、最適化と分割を先に行います。
WordPressの長い記事だけ失敗する場合は？
WorkerがHTML全体を一括読込・解析・置換している可能性があります。成功記事と失敗記事の応答サイズ、処理回数、キャッシュ状態を比べ、対象処理の限定やストリーミングを検討してください。
まとめ：1102はCPUとメモリを分けて直す
Cloudflare Error 1102では、WordPressを先に変更せず、対象Worker、ルート、Invocation Status、CPU time、wall time、入力サイズを確認します。CPU超過は重い計算を減らして分割し、メモリ超過は全量バッファをやめてストリーミングへ変えるのが基本です。
更新直後は安定版への復旧も検討し、修正版は段階的に展開します。Invocation StatusがUncaught Exceptionなら、資源上限を上げずにError 1101の例外ログ確認へ切り替えてください。