Cloudflare Workers無料プランのcronで毎朝の統計取得は動くか：wranglerでPhase 0を実測した

毎朝の make-diary（前日のログから日記を作るコマンドのチェーン）を1回流すと、コンテキストをだいたい35%まで使う。

その一部を Cloudflare Workers の cron（定時実行）へ移したらどうか。クラウド上で毎日スクリプトが自動で走り、ローカルでは make-diary を実行したときにデータを受け取るだけになる。それならかなり短縮できるはずだ、と筆者は考えた。

make-diary のステップを3つの問いで仕分ける

最初に、Claude Code にサブエージェントで2つの調査を並行して走らせた。

make-diary の全ステップについて、何を取りに行くか、判断に LLM が要るか、ログイン済みの Chrome が要るか
Cloudflare の料金と制限

筆者は途中で、ほとんど移せないのではないかと質問していた。仕分けの結果は、そのとおりになった。移せるのは、公開統計を取ってくる部分だけである。計画書では、各ステップを4つに分けて整理した。

無料プランの壁は CPU 時間とリクエスト数

料金と制限の調査のほうが先に戻ってきた。無料プランでは、cron 1回あたりの CPU 時間が 10ms、外部へのリクエストが50本までで、この2つが最初に効く。 cron トリガーは5本までしか置けない。

計画書を Codex に通し、判断は3択ボタンで

調査をもとに、Claude Code に計画書（make-diary-workers-offload-plan.md）を書かせ、Codex でレビューした。指摘を受けて、4-1〜4-3節（監視するソースの一覧、ローカル側の受け取り方、「処理済み」の記録）を書き直させた。図と判断事項の選択肢も、書き直した内容に合わせて直させた。再レビューで Codex が承認した。

計画書は HTML にして、判断してほしい3点を選択ボタン付きで Chrome に開いてもらった。計画書の結論は、無料プランに収まる「見込み」だった。この時点では、まだ Cloudflare の上で何も動かしていない。筆者は3点とも推奨案を選び、コメントは付けなかった。

そのあと、取得結果とエラーを D1 に残して Claude Code が読む節を足すよう指示した。実行ログを Turso ではなく D1 に置く理由も書き足させた。 Turso には全部が入っているわけではなく、あるのは決算系を含む2種類のデータだけだった。この変更も Codex の再レビューで承認された。

「CLI 使えるはずなんで」

Phase 0（事前確認）は、読み取りだけで済む確認から進めていた。筆者はそのあとで、「Cloudflare 側のなんか作るやつは、あなた CLI 使えるはずなんで、ちょっとそれで見てもらえませんか」と頼んだ。そこから先は、wrangler の CLI で Phase 0 を進めてもらった。

まず、既存の取得スクリプトが叩いている URL を集め、使い捨ての Worker から取りに行かせた。 Cloudflare の IP からでも、全ソースが200を返した。台湾 MOF の 2026年9月分のファイルだけは404だったが、まだ公表前なので正しい応答である。

次にログで CPU 時間を見る段で、一度つまずいた。ログのパースをインラインのワンライナーで書いて失敗し、スクリプトファイルへ移して書き直させた。

もう一つのつまずきは、メモリ価格を載せた公開ページで起きた。ページ自体は中身ごと返ってきた。価格表が6つあり、タイムスタンプは 2026-09-24 18:10 だった。ところがパーサーに通すと0件になった。

既存のスクリプトでの呼び方を確かめさせると、パーサーは R2 に置いた HTML をそのまま読む作りだった。その形で読ませると、DRAM の4グループ、19品目が取れた。最後に e-Stat の1年分（一覧ページと CSV）の CPU 時間を単独で測らせた。

片付けとして、Worker の削除と、R2 のバケットが0件になったことの確認までやらせた。結果は計画書に書き戻し、ここも Codex の承認を取った。

実測で分かったのは、無料プランで動くということだ。条件は、1回の実行で取るソースを1つに絞ること。 Phase 0 のうち、KDI の新号検知の調査だけが残った。

5本の上限と、移さないもの

報告を読んで、筆者は cron の上限が5本しかないことに目を留めた。ここがおそらく、有料プランへ切り替えるときの分岐点になる、と筆者は考えた。では今回は5本で足りるのか。

答えは、この計画で使う cron は1本だけ、というものだった。上限の5本は実行回数ではなく、予定表の数の上限である。 1本の cron に「10分おき」と書けば、1日に何回でも走る。今回はその1本を朝4:00〜5:50に10分おき（1日12回）で回し、各回で1ソースずつ取る設計にした。 CPU 10ms の壁を、1回の仕事を小さく刻んでくぐる形になる。

金融データサービスAについても聞いた。ここだけはクラウドへ移すのが難しそうだと感じていた。筆者は、金融データサービスAは移さなくてよいと決めた。

韓国の統計も調べる

続けて、韓国の統計（make-diary の 11.5 ステップ）も同じ仕組みに乗るか調べてもらった。まずサブエージェントに、各系列の取得元、公表時期、取り方を洗い出させた。

戻ってきた報告では、4つの系列が公開ページを curl で見るだけで新号を判定できた。ただしこの確認は、手元の日本の回線から行ったものだった。そこで再び使い捨ての Worker をデプロイさせ、Cloudflare の IP から同じページに届くかを試させた。

CPU 時間はどのソースも 0〜2ms に収まった。一方、韓国の貿易統計サイト（tradedata.go.kr）の応答は24バイトしかなかった。中身を読むと「웹방화벽에서 차단되었습니다」（ウェブファイアウォールで遮断されました）で、Cloudflare の IP ははじかれていた。

判定と取得で、結果が分かれた。新しいデータが公表されたかどうかの判定は、クラウドでできる。値そのものの取得は、手元に残る。

この結果を計画書に足し、Codex でレビューした。ほかのセッションが並行して Codex を使っていた可能性があるので、前回のレビューを引き継がず、新しいセッションで見てもらった。承認は通った。計画書には Phase 2.5 として韓国の統計を足したが、着手は筆者の確認を待つ扱いにしてある。

途中で PC のメモリが足りなくなり、別のセッションから dev サーバーを立てないでほしいという連絡が届いた。このセッションは dev サーバーを使っていなかったので、止めるものはなかった。ただ、メモリ不足のせいか、Chrome の再読み込みには時間がかかった。

35%はどこまで下がるのか

Phase 0 に入る前、筆者はこの計画をプロンプトも含めて Google タスクの今日のタスクに入れるよう頼んだ。あわせて、見積もりを仮説でいいので計画書に入れてほしいと指示した。中身は、35%がどれくらい下がる余地があるかを、前日の分などをもとにフェーズごとに見ることだ。メインのコンテキストに限らず、サブエージェントを使う場合はその分も含めて、という条件を付けた。

Claude Code に 2026-09-24 の make-diary のセッションログを探させ、測らせた。メインのコンテキストは、開始時の約130kから終了時の約316kまで伸びていた。筆者の「だいたい35%」という感覚と合う。統計チェーンを受け持つサブエージェントは、実行中に約88k増えていた。

結論は期待より小さかった。この計画の範囲では、メインのコンテキストは1%も減らない。 Phase 0 のあとで「結局どれくらい減らせるんでしたっけ」と聞き直したときも、答えは同じだった。 Workers への移行（Phase 1〜2）だけでは、メインのコンテキストはほとんど減らない。

統計チェーンの約88kの伸びは、サブエージェントの側で起きていた。メインの35%を下げたいなら Workers とは別の手が要り、計画書にはその話を参考として別の節に分けてある。

Google タスクは、Phase 0 が終わった時点で Phase 1 から始める内容に更新してもらった。

学び

無料プランの cron 上限5本は、実行回数ではなく予定表の数の上限だった。1本を10分おきに回し、1回で1ソースずつ取れば、CPU 10ms とリクエスト50本の枠に収まる
「クラウドに移せば make-diary が軽くなる」という見立ては、前日のログを測ると外れた。統計チェーンの約88kの伸びはサブエージェントの側で起きており、この計画の範囲ではメインのコンテキストは1%も減らない

#Cloudflare Workers#wrangler#cron#Claude Code#make-diary#Codex