Cloudflareの料金で失敗しない上限管理法

こんにちは。Osukeラーニング、運営者の「osuke」です。

AIコーディングでsiteやWeb appを公開したあと、「Cloudflareは無料のまま使えるのか」「Workers Paidの5ドルが請求上限なのか」「botや再試行で突然高くならないか」と不安になっていませんか。Cloudflareにはdomainごとの固定プランとaccount全体の従量課金があり、同じ請求画面に見えても数え方と更新時期が異なります。

結論からいうと、料金は「domain planの固定料金」「Workers・D1・R2などのusage」「Registrarの更新」「外部AI・email・origin」の4層へ分けてください。Budget AlertはUSD閾値を超えたことを知らせる機能で、利用を自動停止するspend capではありません。alert、製品別通知、CPU limit、rate limit、cache、retry上限を重ねて初めて請求事故を小さくできます。

この記事はosuke本人のCloudflare利用体験としては書かず、2026年9月1日時点のCloudflare公式資料17件と、Xで公開された8件の料金、上限到達、複合構成、支払いトラブルを照合しました。Xの金額や結果は投稿者の環境に限られ、料金仕様は公式資料と実際のinvoiceを優先します。全体像から確認したい方はCloudflareの機能と無料範囲もあわせてご覧ください。

記事のポイント

• Free・Pro・Businessはdomainごとの固定料金
• Workers・D1・R2などはaccount単位の利用量を別集計
• Billable UsageにProなどの固定料金は含まれない
• Budget Alertと製品別通知は自動停止ではない
• 週次usage確認と月次subscription監査を分ける

Cloudflareの料金体系と請求の仕組み

Cloudflareの料金で最初につまずく理由は、1つの「月額」だけで説明できないからです。Web siteのplanはdomain単位、Developer Platformの利用量はaccount単位、domain更新は年単位で動きます。まず請求の箱を分け、どの操作がどの箱を増やすかを整理します。

Free・Pro・Businessの月額を確認する

Cloudflare公式Plansでは、Network & CDNのFreeは0ドル、Proは年払い換算20ドル/月または月払い25ドル/月、Businessは年払い換算200ドル/月または月払い250ドル/月です。Contractは個別見積もりです。Proはprofessional website、Businessはonlineで事業を行うsmall businessが目安で、安さだけでなくWAF、画像最適化、SLAなど必要機能から選びます。

重要なのは、このplanがaccount全体へ1件ではなくdomainごとにかかる点です。公式Billing policyの例では、同じaccountにある2つのdomainをProへ上げると2件分が請求されます。subdomainはbillable domainへ追加されません。5 domainを月払いProにすれば固定料金だけで125ドル/月、年払い換算なら100ドル/月です。

一方、Workers Paidの最低5ドルはこのdomain planとは別です。Proへ上げてもWorkers Paidの月間含有量は自動で付きませんし、Workers Paidへ入ってもProのWAF機能が追加されるわけではありません。siteが増えた時は、BillingのSubscriptionsでdomain plan、addon、Developer Platformを別行として確認し、「Cloudflareに月25ドル」という一括表現を避けます。

固定料金と従量課金を分ける

Cloudflare公式の請求ライフサイクルでは、planやaddonの固定料金は次の期間分を前払いし、usage-based chargeは終わった期間の実績を後払いします。そのため1枚のinvoiceに、次期Pro planの固定料金と、前期Workers・R2などの超過料金が同居する場合があります。請求額だけを前月比較すると、期間の向きが違う項目を混ぜてしまいます。

Usage-based billingの例では、請求日が15日のaccountで1日にWorkersを有効化すると、次のinvoiceは1日から15日までの利用量を含み、その次からfull periodになります。billing periodは必ずしも暦月の1日から末日ではありません。広告開始日やdeploy日をusage chartへ重ねる時も、自分のperiod開始日を基準にします。

XではVenelin K.氏が400以上のdirectory siteと月約4,500万requestの構成を、VPS約35ドル、R2 1ドル、Cloudflare for SaaS 28ドル、DNS hosting 14ドル、合計約80ドル/月と報告しています。本人環境の金額で再現保証はありませんが、1つのserviceでも複数の固定費・従量費へ分かれる実例です。合計だけでなく各行の増減要因を記録してください。

1回のアクセスで複数料金が動くと知る

公式How charges accrueは、1つのpage requestがDNS、TLS、cache、Workers、R2、Argo、Cache Reserve、Image Resizingなどを通る例を示しています。DNS・TLS・通常CDN bandwidthがplan内でも、Worker実行、R2 operation、Argo bytesなど有効化した製品のmeterは別に進みます。「page viewが1回だから請求対象も1回」とは限りません。

Jason Szesze氏はWorkers、R2 cache、Browser Run fallback、D1 analytics、Static Assetsを使ったserviceを公開しています。利用者には1つの変換画面でも、内部ではWorker request、R2 read/write、D1 rows、browser実行が別々に動き得ます。特にfallbackとretryは正常時には見えず、障害時だけ複数製品のusageを増やします。

最も安い経路は、必要なresponseがedge cacheから直接返り、Workerやoriginを動かさない経路です。ただし認証済みdataを誤ってcacheするとsecurity事故になるため、「何でもcache」ではなく公開static asset、更新頻度の低いAPI、利用者固有responseを分けます。料金を下げる設計と正しい権限・鮮度を同時に満たす必要があります。

Freeの停止型上限とPaidの超過課金を区別する

Workers公式Pricingでは、Freeは1日100,000 request、1実行10ms CPUが基本です。Paidはaccount当たり最低5ドル/月で、月1,000万requestと3,000万CPU msを含み、超過requestは100万件0.30ドル、超過CPUは100万ms 0.02ドルです。Freeは一定量を超えると失敗し、Paidはserviceを継続しながら料金が増える設計です。

XではAA氏が24時間でFreeのCPU limitへ1,000回超達したと報告しています。またFlorian Baraz氏は全requestで認証を更新するmiddlewareへbotも入り、CPU limit後にsiteが停止した流れを公開しました。両例の処理量は不明ですが、アクセス総数より先に1実行当たりCPUへ当たる場合があることは分かります。

D1もFreeでは1日500万rows read、10万rows written、合計5GBが基本で、日次上限へ達するとqueryが失敗します。Paidは月250億rows readと5,000万rows writtenを含み、超過分を課金します。顧客予約や注文のように停止損失が5ドルを超える処理は、Freeの限界まで粘るよりPaidと防護設定を先に用意します。Workers単体の計算はWorkers料金の詳しい解説で確認できます。

請求日・更新・解約の注意点を押さえる

公式Invoices資料では、accountで最初に購入した月次subscriptionの日が今後の月次billing dateを決め、年次subscriptionは別のcycleを持ち得ます。月次と年次が同じaccountに共存すると「今月だけ請求が多い」ように見えるため、renewal calendarを作り、invoice emailをONにします。billing dateは日本時間ではなくUTC基準です。

Cancel subscriptionsによると、cancelやdowngradeは現在periodの終了時に反映され、未使用期間のrefundはありません。次期請求を避ける変更はUTCのbilling dateより少なくとも24時間前が推奨です。DNSを他社へ変更しただけではCloudflareのactive subscriptionはcancelされないため、Billing > Subscriptionsで状態を確認します。

XではMohith kumar氏がWorkers Paidへのupgrade失敗を繰り返し、銀行側で計3回・7.68ドルの表示になったと報告しています。投稿だけではsettled charge、保留枠、Cloudflare invoiceの一致を判断できません。このような時は再度購入を連打せず、invoice番号、bank側のpending/確定、時刻、ticket番号を保存します。Cloudflare Billing supportへinvoiceを提示し、銀行側の確定・取消時期はcard issuerへ確認してください。

Cloudflare料金の上限管理と請求事故防止

料金の仕組みが分かっても、月末だけinvoiceを見る運用では異常発見が遅れます。ここからは週次で増加を見つけ、通知を受け、codeと権限で被害範囲を狭める方法へ落とし込みます。完全なspend capがない前提で、複数の弱い防護を重ねます。

Billable Usageで日次コストを見る

公式Billable Usageは、Pay-as-you-go accountのusage-based overageを日次cost chartと製品別tableで表示します。invoiceを作るsystemと同じdata sourceを使い、終了済みperiodの合計はinvoiceのusage overageと一致します。Manage Account > Billing > Billable Usageで、現在periodと過去periodを切り替えます。

ただし、この画面はProなどの固定feeを含みません。画面に0ドルと出ても、domain plan、addon、Registrar、外部providerの請求が0とは限らない点に注意してください。反対にusage costが増えた時は、product family、metric、日付で絞り、deploy、campaign、bot、batch、障害retryのどれと重なるかを見ます。

EasyClaw InternはAI automationで成功数だけを見ず、accepted output 1件当たりcost、retry count、human review timeを合わせる考え方を示しています。これは特定の節約実績ではなく分析ですが、AI agentが同じ仕事を何度もやり直す時に有効です。成功したrequestだけでなく、失敗・取消・重複処理を含めたcostを記録します。

Budget Alertを請求上限と誤解しない

公式Budget alertsでは、account-wideのusage-based spendが設定したUSD thresholdを超えると、指定recipientへemailが1回送られます。alertはbilling period開始時にresetされ、Pay-as-you-go accountが対象です。5ドル運用を想定するなら5、10、20ドルのように段階を分け、少なくとも2人または確認できる共有宛先を設定します。

最重要の注意点は、Budget Alertがinformational onlyであることです。thresholdを超えてもWorkers、R2、D1、AIはpauseせず、請求も増え続けます。製品別usage notificationも同じく自動停止ではありません。通知が届くまでのdata更新時間やemail確認の遅れがあるため、深夜の数分で止めるcircuit breakerとしては使えません。

Cloudflare Changelogは2026年6月、Workers、D1、R2、KV、Queues、Vectorize、Durable Objects、ContainersのsidebarからBillable UsageとBudget Alertを使えると案内しました。設定入口が近くなっても、自動停止へ変わったわけではありません。alertを作った直後に、件名、recipient、threshold、対応担当、停止手順を運用表へ残します。

製品別通知と段階的な閾値を組み合わせる

Account全体のBudget Alertだけでは、どのmeterが増えたか分かりません。Usage-based billingのproduct notificationはArgo bytes、Workers request、視聴分数など製品固有のmetricを監視し、Budget Alertは合計USDを監視します。合計5ドル、10ドル、20ドルに加え、Workers request、R2 Class A/B、D1 rows、AI Neuronsへ通常値の1.5倍と2倍を置くと切り分けが速くなります。

閾値は無料枠の100%だけに置かないでください。100%通知では届いた時に既に停止または超過している可能性があります。過去4週間の最大日次をbaselineとし、50%、75%、90%または通常値の1.5倍、2倍、3倍で段階化します。新機能を出す前日、公開翌日、3日後、7日後に同じtableへ記録すると、自然増と異常増を区別できます。

通知を受けたら、まず新規deployのrollback、campaign停止、public endpointのrate limit、retry無効化の順に影響を小さくします。請求画面を眺めながら原因究明を始めると、その間もusageが増えます。緊急時の判断は「顧客dataを守る」「二重処理を止める」「公開範囲を狭める」を先にし、最適化は停止後に行います。

Workers・D1・R2・AIへ技術的な上限を置く

Cloudflare公式Optimize costsは、Billable Usageの週次確認、cache、製品別最適化を勧めています。Workers Paidではlimits.cpu_msを正常処理の上限へ合わせ、外部APIにtimeout、queueとretryに最大回数、public APIに認証とrate limitを置きます。5分CPUを使えるから5分へ広げるのではなく、正常時の高いquantileに安全余裕を加えます。

Data側は料金単位に合わせます。R2 Standardはstorage 0.015ドル/GB-month、Class A 4.50ドル/100万、Class B 0.36ドル/100万で、egress無料でもoperationは有料です。KVは存在しないkeyへのreadもoperationになり、D1はindexなしのfull scanで返却行数よりrows readが増え得ます。R2もstorage、operation、Lifecycleを別々に確認してください。

Workers AIは1日10,000 Neuronsを無料配分し、Paid超過は1,000 Neurons当たり0.011ドルです。XではRyan Hart氏が月2,000ドルのn8n構成をWorker等へ置き換え、Workers planは5ドルと投稿しましたが、外部AI、開発・移行工数、同等性は検証できません。成果1件当たりtoken、retry、外部APIを含めて判断します。

権限・支払い方法・ドメイン更新を監査する

公式Billing permissionsでは、Billing roleはinvoice、usage、支払いを扱えますがsubscriptionやplan変更はできません。Administratorはsubscription変更とBudget Alert設定ができ、Super Administratorはpayment methodも扱えます。開発者全員へ強い権限を渡さず、usageを見る人、支払う人、planを変える人を分けます。

Payment methodの期限切れや利用停止もservice継続へ影響します。公式の請求ライフサイクルでは支払い失敗後に5日のgrace periodと最大5回のretryがあり、未解決ならFreeへdowngradeされ得ます。利用量を抑えていてもカードが止まればpaid featureを失うため、primaryとadditional payment method、billing email、担当者退職時の引継ぎを四半期ごとに確認します。

Registrarのdomainはauto-renewが既定ONで、約30日前に初回renewalを試行します。不要domainはexpirationの少なくとも30日前にauto-renewをOFFにし、必要domainはrenewal完了を確認します。更新は返金不可です。原価販売と移管条件はCloudflare Registrar料金の記事で詳しく整理しています。

月次チェックリストで料金を管理する

料金管理は、毎日すべての数字を見るより、公開前、週次、月次の3周期へ分けると続きます。公開前は上限とrollback、週次はusageの変化、月次はinvoice・subscription・domain更新です。担当者と確認日をtableへ残し、「誰かがalertを見るはず」という状態をなくします。個人運用でもcalendarへ15分の定例を置いてください。

無料運用を続ける条件は、上限内にいることだけではありません。最大日次usageがfree limitへ近づいていない、Exceeded Resourcesがない、停止しても顧客・売上・dataへ大きな影響がない、外部APIも予算内という4条件を見ます。反対に予約、決済、問い合わせ、業務automationが止まるなら、最低5ドルと停止損失を比べ、Paidへ移る前に防護を設定します。

今日の一歩は、Manage Account > BillingでSubscriptions、Billable Usage、Budget Alerts、Invoicesを順に開き、現在の固定料金、usage累計、alert threshold、次回billing dateを1枚へ書き出すことです。その後、最も増えた製品へ技術上限を1つ追加します。Cloudflareの料金は「無料か有料か」ではなく、止まる上限と増える上限を見分ければ管理できます。