開発日誌

Cloudflareに集約すると何が楽になる？｜Workers・D1・R2で作る小さなWebサービス基盤

サーバー、DB、キャッシュ、ストレージ、キュー、メール、防御を、まず一枚の設計図に戻す

小さなWebサービスを作るだけなのに、サーバー、DB、画像保存、ジョブキュー、メール配信、WAF、監視と、気づけばサービスの契約が増えている。これ、開発の初期ほど起きやすい話です。

海外のCloudflare公式ドキュメントを確認すると、Workers、D1、KV、R2、Queues、Hyperdrive、Email Service、WAF/DDoSまで、かなりの部品をCloudflare上に寄せられます。この記事では「全部Cloudflareで済む」と言い切るのではなく、どこまで寄せるとスタックが軽くなり、どこは注意して線を引くべきかを整理します。

lightbulb

この記事を読むとわかること

  • check_circleCloudflare上に置けるWebサービス部品の役割分担
  • check_circleD1、KV、R2、Queuesをどう使い分けるか
  • check_circleBetter Auth、Cloudflare Access、Email Serviceまわりの注意点
  • check_circle月5〜10ドル目安で始める時に、超過課金をどう見るか

向き：小さなSaaS、業務アプリ、会員サイト、AIツールを低コストに立ち上げたい方
向かない：大規模なRDB、複雑なメール配信基盤、既存AWS/GCPの詳細移行手順だけを知りたい方

Cloudflareに寄せる一番の価値は「部品の数」を減らせること

Cloudflare Workersは、サーバーを立てる代わりにエッジ上でAPIや画面処理を動かす基盤です。そこにD1、KV、R2、Queuesを組み合わせると、小さなWebサービスに必要な部品がかなり揃います。

見るべきポイントは、個々の機能が珍しいかどうかではありません。小さなチームにとっては、ログインする管理画面、請求、CLI、権限、デプロイの考え方が揃うことが効きます。裏側の仕組みが一枚にまとまると、保守の迷子が減ります。

役割Cloudflare側の候補実務での使いどころ
コンピュートWorkersAPI、フォーム処理、管理画面、AI連携
SQL DBD1会員、設定、履歴、軽めの業務データ
キャッシュKV設定値、短い状態、読み取り中心のキャッシュ
オブジェクト保存R2画像、添付ファイル、エクスポートデータ
非同期処理Queuesメール送信、画像処理、外部API再試行
防御WAF / DDoS Protection公開サイト・APIの入口保護

この表に収まる程度のサービスなら、最初から複数クラウドをまたぐより、Cloudflareを第一候補に置く方が現実的な場面が増えています。

D1とBetter Authで、ログイン付きの小さなSQLアプリを作る

D1はCloudflareのSQLデータベースです。公式Pricingでは、Workers Paidで月25B rows read、50M rows written、5GBストレージまでが含まれるとされています。小さな管理画面や会員サイトなら、かなり余裕を見やすい数字です。

認証は、用途で分けるのが安全です。社内管理画面の保護ならCloudflare Access。一般ユーザーが登録・ログインするアプリなら、Better Authのような認証ライブラリをD1やDrizzle/Kyselyと組み合わせる設計が候補になります。

lightbulb

ここは「より良い認証」として最初に設計したいところ

ログインは後付けすると崩れやすい部分です。ユーザー認証、管理者だけの画面、APIキー、招待制、パスワードリセット、メール認証を、最初に分けておくと後で楽になります。

用途候補注意点
社内・管理者だけCloudflare Access一般会員向けUIには別設計が必要
一般ユーザー認証Better Auth + D1メール認証、セッション、権限を最初に決める
巨大DB・複雑なRDB外部Postgres + HyperdriveD1だけに寄せすぎない判断も必要

KV・R2・Queuesは「何でもDBに入れる」を避けるために使う

スタックを単純化する時にやりがちなのが、全部をSQL DBに詰め込むことです。最初は楽ですが、画像、キャッシュ、再試行待ちのジョブまでDBに入ると、後から見通しが悪くなります。

Cloudflareに寄せるなら、D1を中心にしつつ、読み取り中心の値はKV、ファイルはR2、時間のかかる処理はQueuesに逃がす。これだけで小さなサービスの設計はかなり整います。

D1: users, projects, invoices, audit_logs
KV: feature_flags, public_settings, short_cache
R2: uploaded_images, csv_exports, attachments
Queues: send_email, resize_image, retry_external_api
  • check_circle読み取りが多く、多少古くてもよいものはKVへ
  • check_circleファイル本体はR2へ置き、D1にはメタ情報だけを持つ
  • check_circleメール送信や外部APIの再試行はQueuesで後ろに回す

HyperdriveとEmail Serviceは役割を分けて考える

Hyperdriveは、Cloudflare Workersから外部データベースへ接続する時の高速化や接続管理に効く仕組みです。つまり、D1だけで完結する小さなアプリでは必須ではありません。既存PostgreSQLを使い続けたい時に、Cloudflare側へ寄せる橋として考える方が自然です。

メールも同じです。以前の感覚で「Email Routing」と言うと、受信・転送の印象が強いはずです。現在のCloudflare Email Serviceでは、Email Routingに加えて、Workers Paid向けのEmail Sendingベータがあり、任意宛先への送信はPaidが必要です。

機能正しい見方設計メモ
Hyperdrive外部DBへの接続高速化・接続管理D1で足りない時の橋として使う
Email Routing受信・転送中心問い合わせ受信や処理フックに向く
Email Sending送信はEmail Service側の機能任意宛先送信はWorkers Paid、到達性設計も見る

ここを曖昧にすると、後で「できると思っていたこと」と「実際の料金・制限」がずれます。小さく始めるほど、最初の言葉の整理が効きます。

WAF・DDoS込みで、月5〜10ドル目安から始める。ただし上限固定とは書かない

Cloudflareの魅力は、公開入口の防御が最初から近くにあることです。WAFは全プランで利用でき、Cloudflare DDoS Protectionも全プランで自動検知・緩和の説明があります。小さなサービスでも、入口保護を後回しにしにくいのは地味に大きいです。

費用面では、Workers Paidの最低料金は月5ドルです。R2は10GB-monthや一定の操作無料枠、QueuesはPaidで月100万operations込み、Email ServiceはPaidで月3,000通の送信込みといった数字があります。だから、小さなサービスなら月5〜10ドル目安で始める設計はかなり現実的です。

lightbulb

ただし「最悪でも10ドル固定」とは書かない方が安全です

Cloudflareの各サービスには無料枠・込み枠がありますが、D1、KV、R2、Queues、メール送信には超過課金があります。公開前に、アラート、使用量監視、CPU limit、キュー投入数の上限を決めておくのが現実解です。

項目公式Pricingで確認した数字見るべきリスク
Workers Paid最低月5ドル、10M requests/月込みリクエスト数とCPU時間
D125B rows read/月、50M rows written/月込み書き込み増、DBサイズ上限
R210GB-month、Class A 1M、Class B 10M無料枠操作回数、大量保存
QueuesPaidで1M operations/月込み失敗時の無限リトライ
Email ServicePaidで3,000 outbound emails/月込み送信数、到達性、バウンス

今日やるなら、まず「Cloudflare標準構成」を1枚に書く

いきなり本番移行ではなく、まず1つの小さなサービスで標準構成を作るのがよいです。問い合わせ管理、会員向け資料ダウンロード、社内申請フォーム、AIツールの管理画面など、範囲が見えるものから始めます。

最初の設計メモは、次のくらいで十分です。

  1. WorkersでAPIと画面を動かす
  2. D1にユーザー、設定、履歴を置く
  3. Better Authで一般ユーザー認証、Cloudflare Accessで管理者保護を分ける
  4. R2にファイル、KVにキャッシュ、Queuesにメール送信や再試行を分ける
  5. WAF/DDoS、使用量アラート、キュー上限、メール送信上限を最初に決める

i-Styleでは、ツール選びよりも「後から迷わない型」を作ることが効くと見ています。Cloudflareに寄せる価値は、最新技術を使うことではなく、サービスを増やしすぎずに、自社サイズの一歩を早く出せることにあります。

よくある質問

小さなWebサービスは本当にCloudflareだけで始められますか？

Workers、D1、KV、R2、Queuesを使えば、API、SQL、キャッシュ、ファイル保存、バックグラウンド処理までかなり集約できます。ただし、複雑な検索、巨大なDB、細かいメール到達性管理などは別サービスを組み合わせる判断も必要です。

Cloudflare D1はPostgreSQLの代わりになりますか？

D1はSQLを使えるSQLite系のデータベースとして便利ですが、PostgreSQL互換ではありません。小規模な業務アプリや管理画面には向きますが、大規模な分析や複雑なRDB要件では、外部DBとHyperdriveを組み合わせる方が現実的です。

メール送信はEmail Routingでできますか？

Email Routingは主に受信・転送の仕組みです。CloudflareのEmail ServiceではEmail Sendingベータが用意されており、任意宛先への送信にはWorkers Paidが必要です。この記事ではEmail Routing単体ではなく、Email Serviceとして整理しています。

月10ドル以内に必ず収まりますか？

小さなサービスならWorkers Paidの最低5ドルを中心に、10ドル前後を目安に設計しやすいです。ただし、D1、KV、R2、Queues、メール送信などには超過課金があります。完全な固定上限としてではなく、監視と制限を置いた予算設計として考えるのが安全です。

まとめ

  • check_circleCloudflareはWorkers、D1、KV、R2、Queuesまで揃い、小さなWebサービスの部品をかなり集約できます。
  • check_circle認証はCloudflare AccessとBetter Authを用途で分けると、管理者向けと一般ユーザー向けを混ぜずに済みます。
  • check_circleHyperdriveとEmail Serviceは便利ですが、外部DBやメール送信の前提を正しく理解して使う必要があります。
  • check_circle月5〜10ドル目安で始めやすい一方、超過課金を避けるために使用量監視と上限設計は必要です。

スタックをシンプルにすることは、手抜きではありません。むしろ、小さなチームが継続して改善するための土台です。最初の一歩は、使うサービスを増やすことではなく、どの部品をCloudflareに置き、どこで人が確認し、どこで予算を止めるかを言語化することから始まります。

参考リンク

小さく作って、後から増やせるWebサービス基盤を一緒に整理しませんか

i-Styleでは、AI活用や業務アプリの開発で、最初から複雑な構成にしすぎない設計を大切にしています。Cloudflareを使った小さなWebサービス、認証、DB、ファイル保存、ジョブ処理の整理も相談できます。

お問い合わせページへarrow_forward

問い合わせ前に、i-Styleサポートデスクbotでも相談できます

「この構成で足りるか」「D1と外部DBのどちらがよいか」など、軽い確認はサポートデスクbotでも相談できます。

i-Styleサポートデスクbotで聞くarrow_forward

関連記事

AI活用

CloudflareがAIエージェント時代の個人開発に向く理由：CLI/APIで任せられるクラウド選定

AI活用

AIだけでは業務は変わらない｜エージェントを動かすシステム設計の考え方

ワークフロー自動化

毎日同じ作業をしている方へ｜2度同じことをしない自動化の始め方

arrow_backBlog一覧に戻る