Cloudflare Workersで実現するサーバーレス開発とは何でしょうか。Cloudflare Workersはエッジで動作するサーバーレスプラットフォーム。世界330都市以上に分散したサーバーでコードを実行し、従来のVPS・オンプレミスとは異なり、リクエスト発生地点の近くで自動的に処理が実行されます。 地方の中小企業が低コストで本格的なAPI層を構築できる選択肢として、ここ数年で急速に広がっています。

ユーザーからは「ステートレス制約の解決方法がわからない」「DNSやドメイン連携が複雑」「複数のCloudflareサービスを組み合わせたときの動作検証ができていない」といった声が数多く寄せられています。また、個人開発者から中小企業まで、「このレベルのインフラが無料枠で使える」という現実に驚きながらも、実装パターンの選び方で悩むケースも少なくありません。

この記事では、京谷商会でCloudflare Workersを使った22サイト・複数の本番APIの運用経験(測定期間:過去12ヶ月、対象:従業員20~50名の製造業・小売業計7社、測定方法:Cloudflareダッシュボード・旧VPS管理画面の比較分析)に基づいて、サーバーレスアーキテクチャの実装方法、状態管理の具体例、よくあるつまずきと対策を解説します。

Cloudflare Workersがサーバーレス開発を変えた3つの理由

Cloudflare Workersの3つの変革点。エッジ実行による低遅延化、従量課金による固定費削減、Durable Objectsによる状態管理を図解

Cloudflare Workersの最大の特徴は、ステートレス制約を緩和し、コスト構造を根本から変えたことです。従来のAWS Lambda・Google Cloud Functionsがリージョン(特定地域のデータセンター)に限定されていたのに対し、Workersはリクエスト発生地点の近くで自動的に処理を実行します。

1つ目はステートレス制約の緩和です。従来のサーバーレスは、本質的に「入力 → 処理 → 出力」の単発処理に特化していました。セッション管理やキャッシュの永続化には、別途のデータストア(DynamoDB、RDS等)が必須で、追加コスト・管理負荷が生じていました。Cloudflare Durable Objects(DO、分散ステートマシン)と組み合わせることで、単一のWorkerコード内で状態を持つロジックが実装でき、データベースの負荷を大幅に削減できるようになったのです。

2つ目はコスト構造の革命です。Cloudflare Workersの無料枠は月間約300万リクエスト(1日10万リクエスト相当)です。月間数百万リクエストを処理する中小企業のAPIサーバーなら、そのほぼ全部がこの無料枠に収まります。京谷商会が支援した従業員20~50名の製造業・小売業7社では、従来のVPS(月額3,000~8,000円)を削除するだけで月額コストが最大70%削減されました。これはCloudflareの無料枠の実行性能と、VPSの低利用時間帯を比較したものです。

3つ目はデプロイメント速度です。Workersはコードを書いて数秒後には全世界に反映されます。CI/CDパイプラインも簡潔で、フロントエンド開発者が自力でバックエンド機能を追加できるレベルの敷居の低さが、チーム全体の開発効率を変えています。したがって、組織規模が小さいほどWorkers導入の効果が高まります。

よくある落とし穴:設定後に「本当に動いてるか確認できない」問題

Cloudflare環境での可視化の課題。従来型サーバーと異なり、複数のサービスがエッジで分散実行されるため、問題原因の特定が困難

多くの中小企業の担当者から相談されるのが、複数のCloudflareサービス(CDN、DNS、Workers、Tunnel等)の相互作用を、視覚的に検証する手段がないという課題です。従来のWebサーバーなら、SSHで入ってログを見るだけで済みました。しかしCloudflareは「エッジで動く」という抽象性のため、問題発生時にどこで何が起きているかが不明確になりやすいのです。

実務的な対策は、設定段階で3つの検証ポイントを順番に通すことです。

検証項目 方法 チェック基準
DNS疎通確認 ターミナルで dig example.com +trace を実行 CloudflareのNSサーバーが応答し、AレコードIPが正しい
CDNキャッシュ動作 ダッシュボード→Analytics→Cache タブ Cache Statusが「HIT」の割合が30%以上に到達
Workers実行確認 ダッシュボード→Workers→Tail機能 デプロイ後、実リクエストが該当Workerで実行されたログ出現

これらを本番運用の1週間前に一通り実施することで、ドメイン切り替え後に「動かない」という大きなトラブルを防げます。京谷商会では、このチェックリストを設定マニュアルに含めることで、クライアント企業が自力で検証できるようにしました。したがって、初期設定段階での検証スキップは本番運用のリスクに直結します。

API実装するときの3つのパターン

Cloudflare Workersを使ったAPI開発の選択は、リクエスト量とステートフルネス(状態管理の必要性)のバランスで決まります。

パターン1: Hono + Workers + KVの軽量構成

このパターンは、月間リクエスト数が100万件以下で、セッション管理がKVで十分な中小企業に適しています。Hono(ほの)は、Cloudflare Workers専用に設計されたフレームワークで、Express.jsよりシンプルです。

import { Hono } from 'hono';

const app = new Hono();

app.post('/webhook', async (c) => {
  const body = await c.req.json();
  const userId = body.events[0].source.userId;
  const customerName = await c.env.KV.get(`user:${userId}`);
  
  return c.json({
    replyToken: body.events[0].replyToken,
    messages: [
      { type: 'text', text: `${customerName}さん、いらっしゃいませ!` }
    ]
  });
});

export default app;

このコードは、LINE公式アカウントからのWebhookメッセージを受け取り、顧客名をKV(キー・バリューストア)から取得して返信する実装です。京谷商会でサポートしている受発注系LINEボット(食品メーカー3社・建設資材卸売業2社)の大半がこのパターンで稼働しており、月額コストは0円(無料枠内)で、応答時間は50ms以下です。したがって、月間数十万件の単発リクエストが主体なら、このパターンで十分です。

パターン2: Hono + Durable Objects + D1の状態保持型

セッション管理やリアルタイム通知が必要な場合は、Durable Objects(DO)を使います。DOは、Cloudflareが提供する分散ステートマシンで、単一オブジェクトに対するアクセスをシリアライズ(一列処理)し、強い一貫性を保証します。

export class SessionHandler {
  constructor(state, env) {
    this.state = state;
    this.env = env;
  }

  async fetch(request) {
    const { pathname } = new URL(request.url);
    
    if (pathname === '/session/create') {
      const sessionId = crypto.randomUUID();
      const sessionData = {
        userId: await request.json(),
        createdAt: new Date(),
        lastAccess: new Date()
      };
      await this.state.storage.put(`session:${sessionId}`, JSON.stringify(sessionData));
      return new Response(JSON.stringify({ sessionId }));
    }
    
    if (pathname === '/session/get') {
      const sessionId = await request.json();
      const data = await this.state.storage.get(`session:${sessionId}`);
      return new Response(data || '{}');
    }
  }
}

このコードは複数のCloudflare Workersから同時にアクセスされても、セッション情報を正確に保持し、データ競合をDOが自動で回避する実装です。Durable Objectsが必要なケースは、複数ユーザーの同時アクセスで一貫性が求められる場合です。例えば、製造業の「現在の生産進捗状況をリアルタイム表示するダッシュボード」や、小売業の「在庫数をLINEで即座に確認する」といったシーンです。コスト面では月額$0.50/百万リクエストの追加課金が発生しますが、従来のセッション用RDSインスタンス(月額3,000円以上)と比べると圧倒的に安価です。したがって、同時実行制御が必要な業務では、Durable Objectsへの移行で初期投資を取り戻せます。

パターン3: フルスタック&AI連携型(Claude Code活用)

複雑な業務ロジックが必要な場合は、Durable ObjectsとD1(Cloudflareが提供するSQLite互換データベース)を組み合わせます。『地方中小企業のAI活用入門 — Claude Codeで始める業務自動化の全手順』(吉田慎一郎著、pububu)では、AI支援開発ツール「Claude Code」が骨組み生成に最適であると解説されています。実務的には、Claude CodeがWorker関数の初期コード・スキーマ定義・エラーハンドリングのテンプレートを自動生成し、人間の開発者が本番環境への適応・セキュリティ監査・パフォーマンステストを担当するという分業が現実的です。

Durable Objectsで状態管理を実装するときの注意点

Durable Objectsは非常に強力ですが、設計時に1つの大きな落とし穴があります。それは「オブジェクト数の無限増殖」です。

Durable Objectのインスタンスは、初回アクセス時に自動生成されます。例えば、ユーザーIDごとにオブジェクトを作成するロジックを書くと、ユーザー数だけオブジェクトが増殖し、メモリ・ストレージコストが際限なく増加します。年間500万件のリクエストを処理する場合、アクティブユーザーが1万名なら1万個のDOインスタンスが生成され、月額コストは約$250(月額基本料$5 + $0.50/百万リクエスト × 500万)になります。これを防ぐため、「セッション」「チャットルーム」「在庫管理タスク」といった業務単位で、オブジェクト数が有限になるような設計を先に決める必要があります。

具体的には、食品メーカーの「1つの営業担当者ごとのセッション」であれば、営業人数(例:30名)が上限になるため、DOインスタンスは最大30個に収まります。この設計判断を誤ると、月額コストが予測不可能に膨らむため、実装前の設計レビューが必須です。

複数のCloudflareサービス組み合わせの段階的導入

Cloudflareサービスの段階的導入。DNS→CDN→Workers→その他の順で、最小構成から始めることが成功の鍵

Cloudflareは現在、CDN・DNS・Tunnel・Workers・KV・D1・R2・Pages など、多数のサービスを提供しています。初心者が陥りやすいのは、「すべてのサービスを理解した上で、最適な組み合わせを設計しなければならない」という思い込みです。実務的には、最小構成から始めて、必要に応じて足していく段階的アプローチが正解です。

企業規模・業務内容 推奨構成 月間コスト目安 追加が必要になる条件
小規模LP・ブログ(従業員10名以下、月間訪問者1,000~5,000) Pages + CDN(無料プラン) ¥0 訪問者月1万超、またはページ容量50MB超
受発注LINE bot(月間メッセージ10,000~50,000件、従業員20~30名の製造業・飲食店) Hono + Workers + KV ¥0~1,000 複数営業担当者の同時セッション管理が必須になった場合、Durable Objectsへ移行
ダッシュボード・在庫管理API(複数拠点、月間リクエスト100万件以上) Workers + Durable Objects + D1 + R2 ¥3,000~5,000 アクセス制御・監査ログが法的に必須になった場合、WAF(有料)が必要
大規模SaaS・業務システム Workers + DO + D1 + PostgresコネクタまたはAWS RDS接続 ¥10,000+ 既存レガシーシステムとの連携、マルチテナント対応などの複雑性

重要なのは、各サービスが独立していないという点です。例えば、Pagesは静的サイト用ですが、その背後にWorkersを配置するだけで、APIサーバーとしても機能します。一度この相互関係を理解すると、複雑さが劇的に低下します。したがって、最初の1〜2つのサービスのみに集中し、運用を安定させた後に次のサービスを追加するのが、失敗を避けるコツです。

地方中小企業が最初にやるべき3ステップ

従業員20~50名の製造業・小売業が陥りやすいのは、「大規模なシステムを一度に構築しようとする」という判断ミスです。実務的には、まず**「1つの業務フロー」を選んで、そこだけサーバーレス化する**のが正解です。

例えば、食品メーカーの「営業がLINEで受け取った注文を、即座にシステムに記録する」といったケースです。従来なら、営業担当者が手作業でFAXやメールから注文番号・数量・納期を打ち込んでいました。これをCloudflare WorkersとLINE Message APIを組み合わせることで、営業がLINEに「製品A 100個 納期は金曜日」と送信するだけで、バックエンド側の在庫・生産管理システムに自動連携されます。

このプロセスの初期化には、1~2週間で完結するサイズを意識的に選ぶことが重要です。京谷商会では、こうした小規模から始める段階的導入をサポートしており、平均して3ヶ月で3~4つの業務フロー(受発注システム、在庫確認bot、請求データ自動抽出)をサーバーレス化しています。その過程で、クライアント企業の開発チーム自身が「Workersで何ができるか」を実感でき、その後の自走性が大きく向上しています。

よくある質問

Cloudflare Workersは本当に無料で使えるのでしょうか?

はい、基本的には無料です。Workersの無料枠は月間約300万リクエスト(1日10万リクエスト相当)です。これは中小企業のAPI層ならほぼ完全に賄える規模です。有料プランは月額$10で、リクエスト数無制限になりますが、多くの場合は無料枠で事足ります。ただし、Durable Objectsを使う場合は月額$0.50/百万リクエストが発生するため、事前に把握しておく必要があります。

DNSをCloudflareに移管する際、既存のメールサービスが止まるリスクはありますか?

リスクはゼロではありませんが、正しい手順を踏めば回避できます。重要なのは、DNS移管前にCloudflareのDNSレコードを完全に設定し、テスト環境で疎通確認を済ませることです。特にMXレコード(メール配信)とSPF・DKIM・DMARC(メール認証)は、1文字の誤りでメール配信停止につながります。京谷商会では、移管前に最低7日間のテスト期間を設けて、実際のメール送受信を検証してから本番切り替えを行っています。

個人開発で始める場合、どれくらい学習期間が必要ですか?

Hono + Workers + KVの最小構成なら、JavaScriptの基礎知識がある人で1週間程度です。ただし、本番環境での「設定検証 → テスト → デプロイ → 監視」という一連のプロセス理解には、別途2~3週間見ておくと安全です。Cloudflareの公式ドキュメントは充実しているため、チュートリアルに沿って進めば大きな落とし穴は少ないです。

📚 この記事で引用した書籍

地方中小企業のAI活用入門 — Claude Codeで始める業務自動化の全手順

地方中小企業のAI活用入門 — Claude Codeで始める業務自動化の全手順

著者: 吉田慎一郎 | pububu刊

地方中小企業がClaude Codeを使って業務自動化した実践記録。SEO記事自動執筆、顧客対応効率化、データ分析自動化まで網羅。

Amazonで購入 →