何が便利になったのか

2026年10月17日の公式発表は、Local ExplorerからWorkerの scheduled() ハンドラーへ、Cron Triggerを単発で送る機能を案内しています。Cronは、一定の時刻や間隔で処理を起動するための設定です。毎日の集計などで使います。

当サイトの評価では、翌朝の実行を待たずに処理の入口を確かめられる点が有用です。ただし「処理を手動で動かせた」「予定時刻に自動で始まった」「目的の結果ができた」は別の確認です。これはCloudflare Workersの機能であり、他サービスの定期タスクが動くことを保証するものでもありません。

試す前に、版と接続先を確認する

Local Explorerの公式資料によると、Cronの検査にはWrangler 4.139.0以上、またはCloudflare Vite plugin 1.60.0以上が必要です。Local Explorer自体が使える版でも、Cron機能の要件を満たすとは限りません。Worker側には scheduled() の実装も必要です。

当サイトが勧める事前点検は次のとおりです。以下は製品の自動保護機能ではなく、作業者が行う確認です。

  • 対象を分ける：開発用Worker名、対象環境、テスト用データを確認します。本番と同じ名前や接続先を安易に使い回しません。
  • 外部への影響を洗い出す：メール、Webhook、外部API、課金を伴う処理、データ削除が含まれるなら、検査用の宛先・設定へ分離できるまで実行しません。
  • ローカルという名前だけで判断しない：公式資料にはremote bindingsの説明もあります。ローカル画面からの操作でも、接続設定やコードによって外部資源へ影響し得ると考えて点検します。
  • 記録を最小化する：ログへ認証値や個人情報を残さず、架空データと処理件数などで結果を確認します。

Local Explorerで1回だけ試す手順

公式資料をもとにした操作の流れです。当サイトが実行して取得した結果ではありません。

  1. 対応する開発環境で wrangler dev などのローカル開発サーバーを起動します。cf dev を使う場合も、背後の開発環境がCron機能の要件を満たすか確認します。
  2. ローカルURLのパスを /cdn-cgi/local/explorer にしてLocal Explorerを開き、対象WorkerのCron Triggersを選びます。
  3. 設定済みの式を選び、Scheduled timeを指定します。初回はNowで入口を確認し、日付依存の処理ではUTCの指定時刻を使う、といった段階分けが考えられます。
  4. Triggerを押し、送った式・scheduled time・outcomeを確認します。必要なログは、そのWorkerを動かしている開発セッションで確認します。ログ・トレースの確認にはObservabilityの設定も関係します。

設定にない式を試すアドホック実行も可能です。公式発表では、アドホックの式や時刻プリセットはブラウザに保持され、設定ファイルやデプロイ済みのCronは変更しないと説明されています。ここでの操作は1回ずつの検査であり、ローカルで予定時刻を待って自動実行するスケジューラーではありません。

架空の「日次集計A」なら、何を確かめるか

以下は当サイトが提案する検査例で、Cloudflareが保証する挙動ではありません。架空の日次集計Aが前日分を数えるとします。

  • 通常日：ダミーの3件を用意し、集計件数と対象期間が想定どおりか確認します。「実行済み」の表示だけでは合格にしません。
  • 日付境界：日本時間の午前0時は、前日の15:00 UTCです。日本時間10月19日0時を試すなら、指定するUTCは10月18日15時になります。入力時刻だけでなく、コードがどのタイムゾーンで集計範囲を決めるかも確認します。
  • 0件と失敗：対象がない日と、検査用の依存先が失敗した場合を分けます。0件を障害扱いしないか、失敗を成功扱いしないかを調べます。
  • 同じ条件の再実行：検査用データで同じ日を2回処理し、二重登録・二重送信を防げるか確認します。防止できないなら、本番で再実行する前の対応を決めます。

指定したscheduled timeは、アプリ内の全時計や外部サービスの時刻まで同じ値に置き換える保証ではありません。コードが起動時刻、現在時刻、保存済み日付のどれを使うかを読み分けることが、この例の要点です。

本番は「設定・起動・成果物」の3段階で確認

Cron Triggersの公式資料では、スケジュール変更の反映に最大15分かかる場合があると説明されています。またHTTP API経由の検査では、リクエスト成功だけでなく result.outcome を見る必要があります。通信が成功したことと、ハンドラーの処理成功は同じではありません。

本番へ進める場合の当サイトの確認案は次の3段階です。この記事の公開作業ではWorkerやCronの設定は変更していません。

  1. 設定：本番のWorker・環境・Cron式・UTCと日本時間の対応・公開した版を確認します。
  2. 起動：反映時間を考慮し、予定時刻後に本番の実行履歴・ログで該当する起動と処理結果を確認します。デプロイ成功だけで定時稼働済みとは扱いません。
  3. 成果物：集計結果や検査用の出力が期待どおりか調べ、確認日時と対象期間を記録します。通知が目的なら、送信処理と実際の到達も分けて確認します。

注意点と未確認事項

本記事は公式資料を確認した解説です。開発サーバーの起動、画面操作、時刻指定による処理、各OSでの互換性、本番の起動は実機未検証です。実際の副作用や重複防止は、読者のコードと接続先に依存します。検査で実データや本番宛先を使う必要はありません。

資料の探し方は公式ドキュメントをCLIで調べる手順、記録の扱いはデータの最小化とログ点検の基本も参考にしてください。