Cloudflare無料枠で副業サービスを月0円で運用する方法

テクノロジー

副業でWebサービスを立ち上げる際、多くの開発者が頭を悩ませるのがインフラコストです。VPSサービスでは月々1,000円から3,000円、ホスティングとデータベースを分離すれば5,000円を超えることも珍しくありません。まだ収益がゼロの段階で毎月の固定費が積み重なるのは、心理的な負担が大きいもの。この課題を解決する強力な味方こそが、Cloudflareの無料層です。

本記事では、筆者が実際に家族向けライフイベントツール群をCloudflare上で運用している実例に基づき、その構成、セットアップ、そして実装上の注意点を詳細に解説します。現在の固定費は、ドメイン取得前のため実質0円。初期投資を抑え、アイデアを迅速に形にしたい副業エンジニアの皆さんにとって、きっと役立つ情報となるでしょう。

Cloudflareの無料層が持つ圧倒的な優位性

複数地域に分散したクラウドインフラストラクチャーネットワーク

Cloudflareの公式ページをご覧いただければ一目瞭然ですが、その無料枠のスケールは業界内で突出しています。具体的な数値で他社と比較してみましょう。

サービス 無料枠の提供量
Cloudflare Pages 帯域制限なし、ビルド500回/月
Cloudflare D1（SQLite） 5GBストレージ、読み取り500万行/日、書き込み10万行/日
Cloudflare KV 読み取り10万回/日、書き込み1,000回/日、1GBストレージ
Cloudflare Workers 10万リクエスト/日
Cloudflare Turnstile 制限なし（不正対策）
Cloudflare Email Routing 制限なし（受信転送）

⚠️ 重要な注意事項：上記の数値はCloudflare公式ドキュメントを参照しています。仕様変更は予告なく実施される可能性があるため、サービス利用時には最新情報をご確認ください。

月間PVが数万規模の個人開発サービスであれば、この無料層で十分な運用が可能です。特にD1の「1日500万行読み取り」という数値は、個人・副業レベルのサービス開発ではまず上限に達することはないでしょう。これにより、データベースのコストを気にせず、開発に集中できる環境が手に入ります。

実装環境の全体像：ミニマルにしてパワフル

筆者が採用している構成は、以下のようなシンプルかつ強力な層構造です。

Cloudflare Pages（Astro SSR）
  ↓ Pages Functions
  ↓ D1（SQLite Database）
  ↓ Turnstile（Bot対策）

フロントエンドにはAstroを、バックエンド処理にはAstroの統合API Routes（Cloudflare上ではPages Functionsとして動作）を、そしてデータベースにはD1を採用しています。さらにORM層にはDrizzleを組み合わせることで、型安全な開発を実現しています。従来のバックエンドサーバーを立てる必要がなく、すべての処理がCloudflareのエッジで実行されるのが特徴です。

Astroをプラットフォームに選ぶメリット

Astroを採用した背景には、いくつかの決定的な要因があります。

  • Cloudflareとの統合: 公式で提供される@astrojs/cloudflareアダプタにより、セットアップが極めて容易です。
  • SEO親和性: 静的HTMLを優先するアーキテクチャは、検索エンジンからの評価を堅牢なものにします。
  • SSR対応: output: "server"オプションを活用すれば、サーバーサイドレンダリング環境も柔軟に実現可能です。
  • 部分キャッシング: prerender = trueを設定した静的ページはWorkersを経由せず、CDNから直接配信されます。これにより、Workersのリクエスト消費を最小限に抑え、コスト効率を大幅に向上させることができます。

D1（エッジSQLite）の活用パターン

D1はCloudflareが提供するエッジベースのSQLiteサービスです。Drizzle ORMとの組み合わせにより、TypeScriptスキーマからのマイグレーション自動生成、そして型安全なクエリ構築が実現します。

wrangler.tomlでD1をプロジェクトに登録する手順は以下の通りです。

[[d1_databases]]
binding = "DB"
database_name = "my-db"
database_id = "xxx-xxx" # Cloudflareダッシュボードまたはwrangler d1 createコマンドで取得

コード内での使用例は非常に直感的です。

// schema.ts (Drizzle ORMのスキーマ定義例)
import { sqliteTable, text, integer } from "drizzle-orm/sqlite-core";

export const boards = sqliteTable("boards", {
  id: text("id").primaryKey(),
  shortId: text("short_id").notNull().unique(),
  title: text("title").notNull(),
  createdAt: integer("created_at").notNull(),
});

// API routeでの利用例
import { drizzle } from "drizzle-orm/cloudflare-d1";
import { eq } from "drizzle-orm";
import { boards } from "../db/schema"; // スキーマファイルのパス

// Pages Functionsの環境変数からDBバインディングを取得
const db = drizzle(env.DB);
const board = await db.select().from(boards)
  .where(eq(boards.shortId, shortId)).get();

ローカル開発時にはwrangler pages devコマンドを実行するだけで、自動的にローカルSQLiteが立ち上がります。これにより、本番データベースに一切影響を与えることなく、安心して開発を進められるのです。

自動デプロイメントで開発サイクルを加速

クラウドデプロイメントの自動化を表現するサーバーインフラストラクチャ

GitHubリポジトリとCloudflare Pagesを連携させれば、mainブランチへのpushをトリガーとして、本番環境への自動デプロイメントが瞬時に開始されます。さらに、プルリクエスト作成時に自動生成されるプレビューURLは、チーム開発やレビュープロセスを格段に効率化する、見過ごせない機能と言えるでしょう。

git push origin main
# → 数秒でhttps://your-app.pages.devに最新版がアップロードされます

D1のマイグレーションに関しては、誤って本番環境を破損するリスクを避けるため、手動での実行を原則としています。

wrangler d1 migrations apply my-db --remote

複数サービスをmonorepoで統合管理する戦略

現在の筆者の運用では、4つのアプリケーション（コアとなるハブサイト + 3つのユーティリティアプリ）を、ひとつのpnpm workspaceで一元管理しています。

apps/
  lifeevent-hub/     # ハブとなるブログサイト
  yarutoko/          # タスク管理サービス
  shugi-navi/        # ご祝儀計算ツール
  kazoku-hikaku/     # 家族構成比較アプリ
packages/
  utils/             # 共有ユーティリティ

各アプリはそれぞれ独立したCloudflare Pagesプロジェクトとしてデプロイされ、D1データベースはサービスごとに分離されています。共通で利用するコードはpackages/以下に抽出し、再利用性を高めています。

ここで強調しておきたい重要なポイントがあります。 各Cloudflare Pagesプロジェクトには、無料枠が個別に適用されるのです。つまり、たとえ4つのアプリを展開する構成であっても、それぞれのプロジェクトが独立して月10万リクエスト、D1は月150億行の読み取りといった無料枠を享受できます。これにより、複数サービスを拡張しても、追加の課金が発生する心配はほとんどありません。monorepo構成は、このような強力なコスト効率化を実現する上で非常に有効な戦略と言えるでしょう。

無料層を超過した場合の料金体系

拡張可能なクラウドサーバーインフラストラクチャー

万が一、無料層の上限に達した場合でも、Cloudflare Workers Basicプランは月額$5で利用可能です。執筆時点のレート基準では約750円となりますが、為替レートは変動するため、最新の換算値はご自身でご確認ください。このプランでは、Workersは月1,000万リクエスト、D1は読み取り250億行・書き込み5,000万行まで利用できるようになります。

💡 収益化とコスト負担の考え方：サービスの運用モデルや収益化の方法によって判断基準は異なりますが、一般的に月間PVが10万を超える段階に入れば、アドセンス運用やアフィリエイト施策での収益化が具体的に検討できるようになります。月額$5程度のコストは、その段階で初めて導入を検討すれば、十分に回収できる範囲と言えるでしょう。初期段階でコストを気にしすぎる必要はありません。

運用時に直面しやすい課題と対策

Cloudflareの無料層を最大限に活用する上で、いくつかの実装上の課題に遭遇することがあります。スムーズな運用を目指すなら、あらかじめこれらを認識し、対策を講じておくことが賢明です。

Node.js組み込みモジュールとの互換性問題

Node.jsの標準モジュール（cryptoなど）に依存するライブラリは、Workers環境でそのままでは動作しない可能性があります。例えば、bcryptjsはNodeのcryptoを参照しているため、デフォルトでは500エラーを引き起こすことがあります。対策には、次の優先順位で段階的にアプローチすることをお勧めします。

対策の優先順位：

  1. 第一段階：nodejs_compatフラグの有効化
    wrangler.tomlに以下の設定を追加します。

    compatibility_flags = ["nodejs_compat"]

    このフラグを有効にするだけで、大多数のライブラリが正常に動作するようになるため、まずはこれを試してみましょう。

  2. 第二段階：Web Crypto APIへの実装変更
    互換モードで解決しない場合、crypto.subtleベースの実装に置き換えることを検討します。このアプローチはバンドルサイズを最小化できるという利点もあります。

筆者はbcryptをSHA-256（crypto.subtle.digest）ベースの実装に変更した経験があります。

⚠️ SHA-256利用の注意：SHA-256は、ランダムトークンの一方向ハッシュ化といった限定的な用途のみに使用しています。パスワードの保存・検証には絶対に使用しないでください。 パスワード用途では、Argon2やbcrypt等の専用アルゴリズムが必須です。

AI クローラーによるリクエスト枯渇への対処

Workersは従量課金制であるため、AI学習目的のBotによる大量クロールが発生すると、無料枠が瞬く間に消費されてしまう危険性があります。以下の3つの対策を組み合わせて防御を固めましょう。

  • robots.txtファイルでクロール対象を明示的に制限する。
  • Pages Functionsミドルウェアでユーザーエージェントを検査し、疑わしいBotからのアクセスをブロックする。
  • prerender機能で静的化可能なページはCDNから直接配信し、Workersへのリクエスト数を削減する。

ドキュメントには載っていない実装上の落とし穴

実運用の中で筆者が遭遇した、いわゆる「隠れた問題」を2つご紹介します。

落とし穴その1：ローカル開発時のD1スキーマ不整合

wrangler pages devを起動する際、ローカルD1のテーブル定義が本番環境と異なっていると、実行時エラーが発生することがあります。マイグレーションが未適用な状態で開発を進めると、コード上は存在するはずのテーブルが実際には存在せず、「テーブルが見つからない」といった不可解なエラーで、貴重な開発時間を浪費してしまう事態になりかねません。

対策： 開発サーバー起動前に必ずwrangler d1 migrations apply --localを実行し、ローカルD1のスキーマを最新の状態に保つようにしましょう。

落とし穴その2：wrangler.tomlのBinding設定ミス

database_idの誤記やBinding設定のエラーは、ビルド段階では検出されません。本番デプロイ後に実際にアクセスしてみて初めてenv.DB is undefinedといったランタイムエラーとして顕在化します。これは検証段階で見逃しやすい盲点です。

対策： 初回デプロイ直後には、CloudflareダッシュボードからBindings設定を念入りに確認し、簡単なクエリ（例：SELECT 1）をPages Functionsから実行して、DB接続が正常に行われているかを検証することを強く推奨します。

ゼロからの構築ステップ：アイデアを形にするロードマップ

クラウドデプロイメントパイプラインのシステム統合イメージ

Cloudflare PagesとD1を初期状態から構築する具体的な手順を追ってみましょう。

  1. Cloudflareアカウントの作成
    まずはCloudflareの公式サイトでアカウントを登録します。無料枠のみの利用であれば、クレジットカード登録は不要です。

  2. GitHubリポジトリとの連携
    GitHubに新規リポジトリを作成したら、Cloudflareダッシュボードの Workers & Pages → Create application から連携を設定します。ビルドコマンドと出力ディレクトリを指定してください。Astroの場合、通常は以下の通りです。

    ビルドコマンド: pnpm run build
出力ディレクトリ: dist

    これで、以降のGitHubへのpushが自動デプロイのトリガーとなります。

  3. D1データベースの作成と紐付け

    wrangler d1 create my-db

    コマンド実行後に表示されるdatabase_idをwrangler.tomlに記入するか、Pagesダッシュボードの Settings → Functions → D1 Database bindings から登録します。どちらの方法でも、コード内からenv.DBとしてデータベースにアクセスできるようになります。

  4. ローカル開発の開始

    wrangler pages dev -- pnpm run dev

    このコマンド一つで、Pages FunctionsとローカルD1が同時に起動します。ローカルデータは.wrangler/state/v3/d1/に保存され、本番環境に一切影響を与えることなく開発を進められます。

  5. マイグレーションの実行

    # ローカル環境への適用
wrangler d1 migrations apply my-db

# 本番環境への適用（--remote オプション付き）
wrangler d1 migrations apply my-db --remote

    Drizzleを使用している場合は、drizzle-kit generateでマイグレーションファイルを生成してから実行します。

  6. シークレット・環境変数の設定
    APIキーなどの機密情報はwrangler secret putコマンドで登録します。

    wrangler secret put MY_SECRET_KEY

    Pagesダッシュボードからの設定も可能で、本番環境とプレビュー環境で異なる値を指定できます。

  7. カスタムドメインの設定（オプション）
    デフォルトではyour-app.pages.devというURLが割り当てられます。独自ドメインを使用したい場合は、Pagesの Custom domains から追加します。CloudflareでDNS管理を行っていれば、数クリックでSSL証明書付きの設定が完了します。

他ソリューションとの比較：Cloudflareが選ばれる理由

| スタック | 月額コスト（個人規模） | 要点 |
|—|—|
| Cloudflare Pages + D1 | 0円〜 | 無制限の帯域、広大なDB無料層。ドメイン代のみ。 |
| Vercel + Supabase | 0円〜（制限あり） | DB同時接続数・容量上限に注意が必要。 |
| Vercel + Neon | 0円〜（制限あり） | 無料層が0.5GBストレージに制限される。 |
| VPS（さくら等） | 500〜1,500円/月 | 収益前から固定費が発生。管理負担も考慮すべき。 |
| AWS（EC2+RDS） | 5,000円〜/月 | 本格的な構成だが、学習コストと運用コストが高い。 |

SupabaseやNeonも優れた選択肢ですが、接続数やストレージに一定の制限があります。対してCloudflare D1は、「1日500万行読み取り、5GBストレージ」という、個人開発レベルではほぼ制限を感じさせない次元の無料層を提供している点が大きな魅力です。

もう一つの大きな差別化要因は「エッジ実行」にあります。Pages Functionsはグローバルに分散されたエッジロケーションで実行されるため、ユーザーに地理的に最も近いサーバーから応答が返却されます。これにより、例えば日本のユーザーであれば東京のエッジからの高速なレスポンスを得られ、優れたユーザーエクスペリエンスを実現できるのです。

最後に：まずは「形にすること」を最優先に

クラウドインフラストラクチャの段階的スケーリング

項目 費用
ホスティング（Pages） 無料
DB（D1） 無料（個人規模なら）
Bot対策（Turnstile） 無料
ドメイン 1,500〜2,000円/年
合計 ドメイン代のみ

副業サービスをプロトタイプ段階で「実現し、公開する」というフェーズに限定するなら、インフラコストをゼロで始められるのは開発者にとって極めて大きなアドバンテージです。PVが順調に伸び、収益が見えてくる段階になってから、初めて有料プランの導入を検討すれば、時間的にも金銭的にも十分な余裕があります。

Cloudflareの実践を始めるなら、まずはアカウント作成とGitHubリポジトリの連携だけで十分です。それだけで、デプロイメントパイプラインの全体像を掴むことができるでしょう。D1は後からでも追加できるため、wranglerの基本操作に慣れてからでも遅くはありません。

このように「最小限で始める」ことの容易さこそが、Cloudflareスタックを副業開発環境として強く推奨する最大の理由です。

📅 記事の鮮度について：本記事は2026年5月時点の情報で執筆されています。Cloudflareの無料枠仕様や料金体系は予告なく変更される可能性があります。サービス利用の際は公式ドキュメントで最新情報をご確認ください。

著者について

本記事の著者は、lifeevent-tools（ライフイベント支援ツール群）をCloudflare上で実装・運用しています。現在クローズドβ版として、yarutoko（幹事向けタスク管理）、shugi-navi（ご祝儀計算）、kazoku-hikaku（家族構成比較）を含む複数サービスを展開中であり、Cloudflareの無料層を最大限に活用した実運用を継続しています。副業初期段階におけるインフラ最適化について、実践知に基づいた情報提供を心がけています。

スポンサーリンク

コメント