エッジコンピューティングって結局何がすごいんですか？

ユーザーの近くでコードが動くから、レスポンスが爆速。Cloudflare Workersなら世界330拠点でコールドスタートほぼゼロ、しかも無料枠で1日10万リクエストまでいける。

Cloudflare Workersでエッジコンピューティング、始めてみない？

ミドリ： タツヤさん、最近「エッジコンピューティング」ってよく聞くんですけど、正直よくわかってないんです。普通のクラウドと何が違うんですか？

タツヤ(nodding)： いい質問だね。まず面白いデータを一つ。Amazonが公表した話なんだけど、「ページの表示が0.1秒遅くなるだけで、コンバージョン率が7%低下する」んだよ。

ミドリ(surprised)： 0.1秒で7%！？それはヤバいですね……。

タツヤ： でしょ。で、エッジコンピューティングっていうのは、ユーザーに地理的に近いネットワークの「エッジ（端末に近い拠点）」でコードを実行する技術なんだ。従来のクラウドだと、たとえばサーバーが東京にあったら、アメリカからのアクセスは太平洋を往復しなきゃいけない。エッジなら、アメリカのユーザーにはアメリカの拠点から返せる。

ミドリ(nodding)： なるほど、物理的な距離が短いから速い、と。で、Cloudflare Workersっていうのがその技術を使えるサービスですか？

タツヤ(nodding)： その通り。Cloudflare Workersは、世界330以上のデータセンターでJavaScript/TypeScriptコードを実行できるサーバーレスプラットフォーム。しかも従来のサーバーレスの弱点だった「コールドスタート問題」を独自技術で解消してる。

ミドリ(thinking)： コールドスタートって何ですか？

タツヤ： 従来のサーバーレス、たとえばAWS Lambdaだと、しばらくアクセスがないとコンテナが停止するんだ。次のリクエストが来た時にコンテナを再起動するから、最初の1回だけ遅くなる。これがコールドスタート。Workersはこれがほぼゼロなんだよ。

ミドリ： 実績的にはどうなんですか？

タツヤ： Cloudflareの公式データだと、Workersプラットフォーム上では1日あたり数十億件以上のリクエストが処理されてる。導入企業の平均ページロード時間は30〜50%改善。しかも無料枠で1日10万リクエストまで対応可能っていう手軽さが、スタートアップから大企業まで幅広く支持されてる理由だね。

Cloudflare Workersの仕組みを理解しよう

ミドリ(surprised)： もう少し技術的に知りたいんですけど、なんでそんなに速いんですか？

タツヤ： Workersは、GoogleのV8 JavaScriptエンジン上で動作する軽量なサーバーレス実行環境なんだ。ポイントは、従来のコンテナベースのサーバーレスとは根本的に異なるアーキテクチャを採用してること。

V8 Isolateが速さの秘密

ミドリ： 根本的に違う、というと？

タツヤ： 従来のサーバーレスはリクエストごとにコンテナを起動するんだけど、WorkersはV8 Isolateっていう、V8エンジン内の隔離された実行環境を使う。Isolateはコンテナより桁違いに起動が速くて、コールドスタート時間はほぼゼロ、通常5ミリ秒未満だね。

ミドリ： 5ミリ秒！人間には感じられない速度ですね。

タツヤ： 特にAPIゲートウェイやリアルタイム処理のような低レイテンシが求められるユースケースでは、従来型サーバーレスとの差が顕著に出るよ。

Workersの主な特徴

ミドリ： 他にはどんな特徴がありますか？

タツヤ： 大きく4つある。

グローバル自動分散 — コードをデプロイすると、世界中のCloudflareエッジロケーションに自動配置。リージョン選択の必要がなくて、ユーザーに最も近い場所から自動的にレスポンスが返される
コールドスタートの実質排除 — さっき話した通り。初回リクエストでも数ミリ秒以下で応答開始
標準的なWeb API — Fetch API、Cache API、Web Crypto API、Streams APIなどのWeb標準APIをサポート。既存のWeb開発知識をそのまま活用できる
豊富なストレージオプション — KV（キーバリューストア）、D1（SQLiteベースのリレーショナルDB）、R2（S3互換のオブジェクトストレージ）、Durable Objects（強整合性のステートフルストレージ）を提供

ミドリ： ストレージまで全部エッジ側にあるんですか。従来のクラウドだと別途DBサーバーを立てなきゃいけなかったのに……。

タツヤ(nodding)： そう、それが大きな違いだね。

AWS Lambdaとどう違う？

ミドリ： サーバーレスっていうとAWS Lambdaが有名ですよね。Workersとはどう使い分ければいいんですか？

タツヤ： よく聞かれる質問だね。まずは比較表を見てみよう。

比較項目	AWS Lambda	Cloudflare Workers
コールドスタート	数百ms〜数秒（言語やパッケージサイズに依存）	ほぼゼロ（5ms未満）
実行場所	リージョンを指定（1〜数リージョン）	330以上のロケーションに自動分散
対応言語	Python, Node.js, Java, Go, .NETなど多数	JavaScript/TypeScript/WebAssembly
最大実行時間	15分	30秒（HTTP）/ 15分（Cron Triggers）
メモリ上限	10GB	128MB
スクリプトサイズ	250MB（デプロイパッケージ）	10MB（有料プラン）
料金（リクエスト）	100万件あたり$0.20	無料枠10万件/日、超過分100万件あたり$0.50
VPC統合	ネイティブサポート	Cloudflare Tunnelで対応

ミドリ(smiling)： コールドスタートの差がすごいですね……。でもメモリ上限とか実行時間はLambdaのほうが余裕がある。

タツヤ： いいところに気づいたね。だから使い分けが大事なんだ。

Workersが向いてるケース

タツヤ： Workersが力を発揮するのはこのあたり。

レスポンス速度が最優先の軽量なAPI処理
グローバルに展開するWebアプリケーション
HTMLの動的書き換えやA/Bテスト
エッジでのキャッシュ制御やリクエストルーティング
無料枠で始めたい小〜中規模のプロジェクト

Lambdaが向いてるケース

タツヤ： 逆にLambdaのほうがいいケースもある。

重い計算処理（機械学習推論、大規模データ処理など）
既存のAWSサービスとの深い統合が必要な場合
Java、Python、Goなどの言語で実装したい場合
長時間実行（15分まで）の処理が必要な場合

ミドリ： じゃあ「どっちか」じゃなくて、両方使うのもアリってことですか？

タツヤ： まさにそう。多くのプロダクションシステムでは、Workersをエッジ層、Lambdaをバックエンド処理層として組み合わせて使用するアーキテクチャが効果的だよ。

開発環境を整えよう

ミドリ： 実際に始めるにはどうすればいいですか？

Wranglerの導入

タツヤ： WranglerっていうCloudflare Workers公式のCLIツールを使う。プロジェクトの作成からローカル開発、デプロイまで一貫して管理できるよ。手順はこうだ。

Node.js（バージョン18以上推奨）をインストール
npm create cloudflare@latest でプロジェクトを作成。テンプレート選択で用途に応じたスターターを選べる
npx wrangler dev でローカル開発サーバーを起動。Miniflareランタイムがローカルで動いて、KV、D1、R2のストレージもエミュレートされるから、本番に近い環境でテストできる
npx wrangler deploy で本番環境にデプロイ。通常30秒以内に完了して、世界中のエッジロケーションに即座に反映される

ミドリ： 30秒でデプロイ完了って速いですね！

wrangler.tomlの設定

ミドリ： 設定ファイルとかはあるんですか？

タツヤ： wrangler.tomlっていう設定ファイルをプロジェクトのルートに置く。主要な項目はこのあたりだね。

name — Workerの名前（URLの一部にもなる）
main — エントリーポイントのファイルパス
compatibility_date — Workers runtimeの互換性日付。新機能の利用と後方互換性のバランスを制御
kv_namespaces、d1_databases、r2_buckets — 各ストレージへのバインディング定義
routes — カスタムドメインでのルーティング設定

実践的な活用パターン4選

ミドリ(thinking)： 具体的にどんなことに使えるんですか？

タツヤ： 実践的なパターンを4つ紹介するね。

パターン1：APIゲートウェイ

タツヤ： リクエストのルーティング、認証・認可、レート制限、レスポンスキャッシュといったAPIゲートウェイの機能をエッジで処理するパターン。バックエンドサーバーに到達する前に不正リクエストをブロックして、キャッシュ可能なレスポンスはエッジから直接返すから、オリジンサーバーの負荷を大幅に軽減できる。

ミドリ： 効果はどれくらいですか？

タツヤ： あるSaaS企業では、APIゲートウェイをWorkersに移行して、オリジンサーバーへのリクエスト量が65%減少、APIの平均レスポンス時間が320ms → 45msに改善した。

ミドリ： 320msが45ms！ 7分の1以下ですね。

タツヤ： 実装のポイントとしてはこのあたりを押さえるといい。

JWTトークンの検証をエッジで実行し、不正リクエストをオリジンに到達させない
レート制限にはDurable Objectsを使い、グローバルに一貫した制限を実現
Cache APIでGETリクエストのレスポンスをTTL付きでキャッシュ

パターン2：HTMLリライトとパーソナライゼーション

ミドリ： HTMLを書き換えるって、どういうことですか？

タツヤ： Cloudflare Workers独自のHTMLRewriterっていうストリーミングパーサーがあるんだ。HTMLを完全にパースせずに、特定の要素だけを効率的に変換できる。活用例をいくつか挙げるね。

A/Bテスト — ユーザーのCookieやリクエストヘッダーに基づいて、ページの特定セクションを差し替え。CDN上で完結するからオリジンサーバーに一切負荷をかけない
地域別コンテンツの出し分け — Cloudflareが提供するリクエストの地理情報（国、都市、タイムゾーン）で通貨表示や言語を動的に切り替え
パフォーマンス最適化 — 画像のlazy loading属性の追加、未使用のCSS/JSの除去、third-partyスクリプトの遅延読み込みをエッジで注入

ミドリ： A/Bテストがサーバー負荷ゼロでできるのは魅力的ですね。

パターン3：フルスタックアプリケーション

タツヤ： ここが個人的には一番面白いところ。Workers + D1 + R2 + KVの組み合わせで、完全にエッジで動作するフルスタックアプリケーションが作れるんだ。

ミドリ(surprised)： バックエンドサーバーなしで全部エッジ!?

タツヤ： そう。技術スタックの例を挙げると――

フレームワーク：Hono（軽量で高速。Express.jsに似たAPI設計）
データベース：D1（SQLiteベース。読み取りはグローバル分散レプリカから高速応答）
ファイルストレージ：R2（S3互換。データ転送料が無料という大きなコスト優位性）
セッション管理：KV（高速な読み取りと結果整合性モデルによるグローバル分散）
リアルタイム機能：Durable Objects（WebSocket接続の管理やリアルタイムコラボレーション）

ミドリ： コスト的にはどうなんですか？

タツヤ： 月間100万リクエスト規模のWebアプリケーションの場合、従来のVPS + データベース構成で月額$50〜$100程度。Workers + D1 + R2なら月額$5〜$15程度で運用可能。無料枠を含めればね。

ミドリ： 10分の1近いコストって……これは無視できないですね。

パターン4：画像最適化とメディア処理

タツヤ： Cloudflare Imagesと連携して、リクエストに応じた画像のリサイズ、フォーマット変換（WebP/AVIF対応）、品質調整をエッジで実行できる。

ミドリ： 効果のほどは？

タツヤ： ECサイトの例だと、画像の転送データ量が平均58%減少、Largest Contentful Paint（LCP）、つまりページの主要コンテンツが表示されるまでの時間が1.2秒改善した。

D1データベースをもう少し深掘り

ミドリ： さっきD1っていうデータベースが出てきましたけど、もうちょっと詳しく知りたいです。

タツヤ： D1はCloudflareが提供するエッジネイティブなSQLiteデータベース。Workersから直接SQLクエリを実行できて、読み取りはグローバルに分散されたレプリカから高速に応答する。

D1の技術的な強み

タツヤ： 特徴をまとめるとこんな感じだ。

SQLiteベース — 世界で最も広く使われているDBエンジンがベースだから、SQLの学習コストが低い
リードレプリカの自動分散 — 書き込みは単一プライマリ、読み取りはユーザーに最も近いレプリカから応答。読み取り重視のアプリに最適
マイグレーション管理 — Wrangler CLIでマイグレーションファイルの作成・適用を管理
バックアップとリストア — 自動バックアップとポイントインタイムリカバリ（特定時点への復元）に対応
コスト — 5GBまで無料。有料プランでもGB単位の課金で非常にリーズナブル

D1を使う時の注意点

ミドリ： 注意すべきことはありますか？

タツヤ： 3つある。

ORMは不要、むしろ非推奨。D1のAPIで直接SQLを書くシンプルな設計が推奨されてる
書き込みはプライマリリージョンで行われるから、書き込み頻度が高いアプリではレイテンシに注意
行ロックがないから、高頻度な同時書き込みにはDurable Objectsとの組み合わせを検討したほうがいい

ミドリ： 読み取り中心のアプリならD1、書き込みが多いならDurable Objectsも併用、ということですね。

タツヤ： 理解が早いね。

パフォーマンス最適化のコツ

ミドリ： せっかくWorkersを使うなら、最大限パフォーマンスを引き出したいです。コツはありますか？

Cache APIを戦略的に使う

タツヤ(nodding)： まずはCache API。頻繁にアクセスされるデータやAPIレスポンスをキャッシュして、ストレージへのアクセスを最小限に抑える。設計指針はこうだ。

静的コンテンツ — 長いTTL（24時間〜）を設定。更新時にはキャッシュパージで即時反映
APIレスポンス — データの鮮度要件に応じてTTLを設定（1分〜1時間）。stale-while-revalidateパターンで、キャッシュを返しつつバックグラウンドで更新
パーソナライズされたコンテンツ — ユーザー固有のデータはキャッシュしない。ただし共通部分はキャッシュして、固有の部分だけをESI的に差し込む設計も有効

バンドルサイズを絞る

ミドリ： サイズ制限があるんでしたっけ？

タツヤ： 無料プランで1MB、有料プランで10MB。この制限内に収める最適化は必須だね。

Tree Shaking — 使っていないコードを自動除去。esbuildかRollupを使う
依存関係の精査 — Node.js向けの大きなライブラリを避けて、Web標準APIやWorkers向けの軽量ライブラリを選ぶ
動的インポート — すべてのコードを初期ロードせず、必要な機能だけを動的にインポート

waitUntil()でバックグラウンド処理

ミドリ(thinking)： waitUntil()って何ですか？

タツヤ： レスポンスをクライアントに返した後に、バックグラウンドで処理を実行するためのAPI。こういう処理に使える。

アクセスログの外部サービスへの送信
分析データの記録
キャッシュの更新
Webhookの送信

タツヤ： ユーザーへのレスポンスは即座に返しつつ、付随する処理をバックグラウンドで完了させるから、体感速度を最大限に高められるんだ。

ミドリ： レスポンスを待たせずに裏で仕事してくれるわけですね。賢い。

セキュリティも忘れずに

ミドリ： エッジで動くからこそ、セキュリティも気になるんですけど。

エッジでのセキュリティ対策

タツヤ： もちろん大事。押さえるべきポイントを挙げるね。

環境変数の管理 — APIキーやシークレットはwrangler secret putでCloudflareに暗号化保存。ソースコードには絶対に含めない
CORSの適切な設定 — Access-Control-Allow-Originを必要なオリジンのみに限定。ワイルドカード（*）は開発環境のみ
入力バリデーション — 外部からのリクエストパラメータは必ずバリデーション。SQLインジェクション対策としてD1のパラメータバインディングを使う

DDoS耐性

ミドリ： DDoS攻撃の対策はどうなってますか？

タツヤ： ここはWorkersの大きなメリット。Cloudflareのグローバルネットワーク上で動作するから、Cloudflareが提供するDDoS保護を自動的に享受できる。追加費用なしで大規模なDDoS攻撃からアプリケーションを守れるのは、かなり心強いよ。

まとめ：エッジコンピューティングの敷居は下がった

ミドリ： 今日の話をまとめるとどうなりますか？

タツヤ： Cloudflare Workersは、エッジコンピューティングの敷居を大幅に下げるプラットフォームだということ。ポイントを振り返ろう。

V8 Isolateアーキテクチャがコールドスタート問題を解消し、一貫した低レイテンシを実現
AWS Lambdaとは補完関係にあり、エッジ処理とバックエンド処理で使い分けるのが効果的
D1、R2、KV、Durable Objectsの組み合わせで、フルスタックアプリケーションをエッジで構築可能
Cache API、waitUntil()、バンドル最適化の3つがパフォーマンスチューニングの柱
無料枠が充実しており、小規模プロジェクトならほぼ無料で運用可能

ミドリ： 速い、安い、グローバルの三拍子が揃ってるんですね。しかも既存のJavaScript/TypeScriptの知識でそのまま始められるのがいい。

タツヤ： そう。「エッジコンピューティングは難しそう」っていうイメージは、もう過去のものだよ。

次のアクション

ミドリ： 早速やってみたいんですけど、何から始めればいいですか？

タツヤ： 3ステップで進めてみよう。

ハンズオン — npm create cloudflare@latest で最初のWorkerを作成して、wrangler dev でローカル実行を体験する（所要時間：15分）
既存APIのエッジ化 — 今運用中のAPIの一つを選んで、Workers経由でリクエストを処理するプロキシを構築する
パフォーマンス計測 — 導入前後のレスポンス時間、TTFB（Time to First Byte）、エラー率を計測して、改善効果を定量化する

ミドリ： 15分で始められるなら、今日やってみます！

タツヤ： その意気だね。Shimanto AI Solutionsでは、Cloudflare Workersを活用したエッジアプリケーションの設計・開発支援もやってるよ。既存システムのエッジ移行、Workers + D1での新規プロダクト開発、AIエージェントのエッジデプロイなど、気軽に相談してほしい。