Workers の無料枠が足りない？7 つの最適化で 1 日 10 万リクエストを 1 ヶ月持たせる

先月、Workers と R2 で画像ホスティングを組み立て、完璧だと思っていました。ところが 3 日も経たないうちに Cloudflare からメールが届きました——無料枠がまもなく使い切れる、と。

戸惑いました。1 日 10 万回のはずでは？ この小さな画像ホスティングにそんな流量があるはずがない。Analytics を開くと、日次 12 万リクエスト。あり得ない。アップロードしたのは数十枚だけなのに。

2 日かけてドキュメントとコミュニティを調べ、Workers の課金にいくつもの落とし穴があると理解しました。サブリクエスト、KV 読み取り、キャッシュヒット——どれも枠を「こっそり」消費します。

ルールを把握したあと、いくつかの最適化で日次リクエストを 12 万から 3 万に下げました。今は月の無料枠が足り、30% ほど余裕があります。今日はその実戦経験を共有します。月 5 ドルの有料プランを避けられるかもしれません。

騙されないで！Workers の「10 万回」は思っている通りではない

Cloudflare ドキュメントの「1 日 10 万リクエスト」は誤解されやすいです。最初は「Worker が 10 万回呼ばれたら上限」と思っていましたが、そうではありません。

要点 1：サブリクエストは個別課金されないが、数に制限がある

Worker 内で fetch() して他 API を呼ぶ、R2 を読む、KV を検索する——これらはサブリクエストです。良い点：別料金にはなりません。悪い点：無料プランは 1 リクエストあたり 50 回、有料で 1000 回まで。

例：ユーザーが画像ホスティング URL にアクセス（課金 1 回）、Worker が KV で権限確認（サブリクエスト 1）、R2 から画像取得（サブリクエスト 1）。サブリクエストは 2 つですが、課金は 1 回です。

集約サービスで 1 リクエストに 10 API を呼ぶと、サブリクエストは 10 回。無料の 50 回は一見余裕がありますが、実プロジェクトではすぐ天井に近づきます。

要点 2：10 万回はアカウント単位で、単一 Worker ではない

ここが罠です。複数 Worker で分散できると思いましたが、10 万回はアカウント全体の上限です。Worker を 10 個作っても合計は 10 万回のまま。

複数 Worker で枠回避？ できません。コミュニティでも試されていますが、制限はアカウント単位です。突破するには有料化か、リクエスト数の最適化です。

要点 3：KV の読み書き、Cache API 操作もリクエストにカウントされる

見落としやすい点です。KV.get() はサブリクエスト制限には入りませんが、リクエスト数を消費します。毎回 KV で権限確認するなら、ユーザー 1 アクセスあたり KV 操作が 1 回増えます。

Cache API も同様です。Cache でオリジンへのリクエストは減りますが、match() と put() 自体にもコストがあります。

最もハマりやすい 3 つの落とし穴

私がこれらに当たり、リクエストが爆発しました：

1. 落とし穴 1：リバースプロキシが毎回サブリクエスト、キャッシュなし
   API 中継で毎回 fetch() して元 API を叩き、キャッシュを入れませんでした。Cache API 追加後、ヒット率 80% でリクエストが半分に。

2. 落とし穴 2：KV 読み取りが多く、cacheTtl を知らない
   画像ごとに KV.get() で権限確認。cacheTtl でエッジキャッシュできることを知らず、cacheTtl: 600（10 分）後に KV 読み取りが 70% 減。

3. 落とし穴 3：リダイレクトチェーンの各ジャンプがカウント
   短縮 URL で Worker が 302 を返したが、3 段（A→B→C→最終）では各ジャンプがサブリクエスト 1 回。最終 URL を直接返すように変更し、2 回分を節約。

これらが重なり、10 万を超えて 12 万になりました。枠不足なら、まずこれらを自查してください。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

7 つの最適化で無料枠を 1 ヶ月持たせる

課金ルールを理解したあと、多くの案を試しました。この 7 つは実戦で効果が大きく、実装も難しくありません。

テクニック 1：キャッシュで重複リクエストを最大 80% 削減

いちばん効果が出た方法です。毎回リアルタイム計算が不要な Worker では、結果をキャッシュできます。

画像ホスティング最適化前は、毎回 検証→R2 読み取り→返却。Cache API 追加後：

const cache = caches.default;
const cacheKey = new Request(request.url, request);
// 先にキャッシュを確認
let response = await cache.match(cacheKey);
if (response) {
  return response; // ヒットしたらそのまま返す
}
// ミス時のみ処理
response = await handleRequest(request);
// キャッシュ設定（静的画像は 1 日）
response = new Response(response.body, {
  ...response,
  headers: {
    ...response.headers,
    'Cache-Control': 'public, max-age=86400',
  },
});
await cache.put(cacheKey, response.clone());
return response;

キャッシュヒット率 85%。日次 12 万のうち Worker ロジックを通るのは 1.8 万、10.2 万回を節約しました。

テクニック 2：KV 最適化の 3 点

KV は Workers でよく使うストレージですが、リクエスト数の大きな要因でもあります。3 点をまとめました。

1. cacheTtl パラメータを増やす
   KV はデフォルトでエッジに 60 秒キャッシュされます。更新頻度が低ければ値を大きくします：

   // 最適化前
   const value = await KV.get('key');
   // 最適化後（10 分キャッシュ）
   const value = await KV.get('key', { cacheTtl: 600 });

   権限データは 30 分に 1 回更新なので cacheTtl: 1800 にし、KV 読み取りが 70% 減りました。

2. Cache API で KV 結果をさらにキャッシュ
   更新がさらに遅いデータ（設定、ブラックリスト）なら Worker 層でも：

   const cacheKey = `kv-cache:${key}`;
   let cached = await caches.default.match(cacheKey);
   if (!cached) {
     const value = await KV.get(key);
     cached = new Response(value);
     await caches.default.put(cacheKey, cached.clone());
   }
   return cached.text();

3. waitUntil で非ブロッキング書き込み
   KV 書き込み結果を待たない場合：

   // KV 完了を待たずにレスポンス返却
   event.waitUntil(KV.put('key', 'value'));
   return new Response('OK');

3 点を組み合わせ、KV 操作を日次 3 万→8000 に削減しました。

テクニック 3：不要なサブリクエストを減らす

多くのサブリクエストは最適化できます。

以前、集約サービスで外部 API を 5 つ呼び、1 リクエスト = サブリクエスト 5 回でした。変更後：

• 高頻度 API の結果を 5 分キャッシュ
• 低頻度 API の結果を KV に 24 時間保存
• 可能ならデータを事前処理して R2 に保存

最適化後、80% のリクエストはサブリクエストなしでキャッシュから返却されます。

テクニック 4：Request.cache でキャッシュ動作を制御

Cloudflare は 2024 年 11 月に Request.cache を追加し、より細かく制御できます：

// キャッシュをスキップ（機密データ向け）
const response = await fetch(url, { cache: 'no-store' });
// デフォルト戦略
const response = await fetch(url, { cache: 'default' });

非公開画像には cache: 'no-store' で CDN キャッシュを避け、公開画像は default で Cloudflare に任せています。

テクニック 5：リダイレクトチェーンを最適化

Worker が 302/301 を返すとき、チェーンの各ジャンプはサブリクエストです。

短縮 URL サービス最適化前：

// 最適化前：302 リダイレクト
return Response.redirect(targetUrl, 302);

最適化後：

// 最適化後：最終 URL をキャッシュしてリダイレクトを減らす
const cached = await cache.match(shortUrl);
if (cached) {
  return cached; // キャッシュした最終 URL を直接返す
}

bit.ly → t.co → 最終 URL のように多段になるリンクは、最終 URL を保存し、毎回チェーンを辿らないようにします。

テクニック 6：リクエスト分布を監視し「食い尽くす」パスを特定

Cloudflare Analytics は無料です。必ず使いましょう。

80% のリクエストが 20% のパスから来る、という傾向があります。Analytics では次が分かります：

• どのパスが最多か
• どのパスでキャッシュヒット率が低いか
• どのパスが最も時間がかかるか

リクエスト上位のパスを重点的に最適化しました。/api/status のヘルスチェックが監視から 1 分に 100 回呼ばれ、日次の 15% を占めていました。60 秒キャッシュで 1.5 万回/日を節約。

テクニック 7：緊急でない処理を時間帯で分ける

Workers は Cron Triggers に対応します。リアルタイムでなくてよい統計・クリーンアップ・キャッシュウォームアップは低峰に回せます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

画像ホスティングでは、毎アクセスで KV にカウンタを書いていました。変更後：

• アクセス時はメモリ内カウントのみ（KV 書き込みなし）
• Cron Trigger で 1 時間ごとに集計

頻繁な KV 書き込みが、1 時間 1 回のバッチに。日次 KV 書き込みは 2 万→24 回になりました。

実戦例：画像ホスティングを日次 12 万→3 万に

ここまでのテクニックを組み合わせるとどうなるか。自分の画像ホスティングで全過程を振り返ります。

プロジェクト背景

シンプルな画像ホスティング：

• Cloudflare Workers でリクエスト処理
• R2 に画像
• KV にメタデータと権限
• 実ユーザーは 1 日約 2000 枚のアクセス

公開 3 日目に Cloudflare から通知：日次 12 万リクエスト、無料枠上限に接近。

問題の診断

半日かけ、Analytics とコードレビューで主因 3 つを特定：

1. 画像リクエストのたびに KV 参照
   毎回 KV.get() でメタデータ（ファイル名、サイズ、アップロード者）。2000 アクセス = 2000 回 KV 読み取り。メタデータはほぼ不変なのに毎回読んでいた。

2. ブラウザキャッシュなし
   レスポンスに Cache-Control がなく、再読み込みのたびに再リクエスト。同じ画像を同じユーザーが 10 回見ると Worker も 10 回。

3. サムネイルをリアルタイム生成
   一覧で Worker が都度リサイズ。1 ページ 30 枚 = 30 回処理。数ページめくるとリクエストが爆発。

実効 2000 アクセスが 12 万 Worker 呼び出しになっていました。

最適化の方針

優先度順に 4 段階：

ステップ 1：KV キャッシュ最適化（最速で効果）

// 最適化前
const metadata = await IMAGE_KV.get(imageId);
// 最適化後
const metadata = await IMAGE_KV.get(imageId, {
  cacheTtl: 600  // 10 分キャッシュ
});

効果：KV 読み取り 2000 回/日→約 300 回/日（-85%）

ステップ 2：ブラウザキャッシュ

return new Response(imageData, {
  headers: {
    'Content-Type': 'image/jpeg',
    'Cache-Control': 'public, max-age=86400',  // 1 日
    'CDN-Cache-Control': 'public, max-age=2592000'  // CDN 30 日
  }
});

効果：再訪問 60% 減、12 万→4.8 万

ステップ 3：サムネイル事前生成

リアルタイム生成をやめ、アップロード時に thumbnails/ へ保存：

// アップロード時に生成
const thumbnail = await generateThumbnail(image);
await R2.put(`thumbnails/${imageId}`, thumbnail);
// 参照時は直接読み取り
const thumbnail = await R2.get(`thumbnails/${imageId}`);

効果：サムネイルが Worker 処理を通らず、4.8 万→3.2 万

ステップ 4：Worker キャッシュ層

レスポンス全体に Cache API：

const cache = caches.default;
let response = await cache.match(request);
if (response) return response;
// 処理...
await cache.put(request, response.clone());
return response;

効果：ヒット率 78%、日次約 3 万で安定

最適化結果

2 ヶ月安定運用、日次 3〜4 万回で無料枠十分。有料 5 ドル/月換算で年 60 ドル節約。

経験まとめ

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

振り返ると次の 4 点が重要でした：

1. ボトルネックを特定してから最適化：盲目的に触らず Analytics で本当の問題を見つける
2. キャッシュが最優先：効果の 80% はブラウザ・CDN・Worker キャッシュ
3. KV は慎重に：cacheTtl、事前計算を優先
4. 段階的に最適化：4 ステップで各段階に効果。一度に全部変えない

有料か最適化か？ 経済性を計算する

ここまで読むと、「時間をかけて最適化するか、有料に上げるか」と迷うかもしれません。私も悩みましたが、計算すると明確になります。

無料プラン vs 有料プラン（5 ドル/月）

有料は日次約 3 倍、サブリクエスト制限 20 倍緩和と魅力的です。ただ、本当に必要かが先です。

いつ有料に上げるべきか

次の 3 シーンでは有料を推奨します：

1. 日次 10 万を安定して超える
   「安定」が鍵です。一時的なピークなら最適化で足ります。1 週間連続で超えるなら、业务量が上がっており有料の方が楽です。

2. 大量のサブリクエストが必要
   クローラ、集約サービス、API ゲートウェイで 1 回に 10+ の外部 API。無料 50 回では不足し、最適化の余地も限られます。有料 1000 回の方が合理的です。

3. 商用プロジェクトで安定性＞コスト
   顧客案件や自社プロダクトでは、無料枠で数ドル節約する価値は小さいです。有料の SLA、チケット対応——5 ドルで得られる安定性の方が大きいです。

最適化の限界はどこか

逆に、最適化が時間の無駄になる場合もあります：

1. 過度な最適化でコードが複雑化
   キャッシュ・事前計算・Cron を積み重ね、保守が困難になったら、時給換算で 5 ドルを大きく超えます。

2. 最適化の限界に達した
   キャッシュも KV もやり尽くしても足りない——それは业务量の問題。無理に耐えず有料へ。

3. 時間コスト vs 5 ドル
   最適化に 3 時間かかり、時給が 20 ドル超なら、有料の方が合理的です。

私の提案：

• 個人・学習プロジェクト：最適化優先（節約も学習も）
• 小規模チーム・初期プロダクト：限界まで最適化してから有料
• 商用・顧客案件：最初から有料。ここで節約しない

有料後も最適化は必要か？

はい。有料でも課金ルールは同じです。最適化しなければ月 1000 万回も使い切れます。

超過は 100 万リクエストあたり 0.50 ドル。日次 100 万なら月 15 ドル超過＋基本 5 ドル＝月 20 ドル。そのとき最適化の価値が再び出ます。

まとめ

核心は一言：Workers の課金を理解し、正しい方法で最適化する。

1 日 10 万回は一見多いですが、すぐ超えがちです。多くは业务量ではなく、最適化不足です。

私の画像ホスティングは実トラフィック 2000 アクセスなのに 12 万リクエストでした。キャッシュ、KV 最適化、事前計算で 3 万に下げ、余裕もできました。

枠不足のときは次の順で：

1. Workers Analytics で枠を消費しているパスを確認
2. キャッシュと KV から着手（いちばん効く）
3. 本文の 3 落とし穴を自查（サブリクエスト、KV cacheTtl、リダイレクトチェーン）
4. 7 テクニックを組み合わせる
5. 限界後に有料を検討

最後に：Cloudflare は商用企業です。無料枠は適正に使いましょう。過度な「タダ乗り」はレート制限やアカウント停止につながることがあります。目的はリソースの効率利用であり、抜け穴探しではありません。

この記事で月 5 ドル節約できたら、いいねや Workers を使う友人へのシェアも歓迎です。みんなで無料枠を最大限活かしましょう。