マーケターのためのCloudflare Workers入門

マーケティングやWeb施策において、新商品の発表、SNSキャンペーン、イベント特設ページの公開など、「いつ公開できるか」は、タイミングを逃さないという意味で、成果を決定づける極めて重要な要素です。

しかし実際の現場では、ページのデザインや原稿が完成していても、すぐには公開できないことが少なくありません。たとえば、想定されるアクセスに耐えられるよう、サーバーの準備と負荷テストだけでなく、場合によってはインフラの改修にも時間がかかったりするからです。

マーケターからすれば、「ページを1枚公開したいだけなのに、なぜこんなに時間がかかるのか」と歯がゆさを感じることも多いはずです。もちろんエンジニア側の作業にも理由がありますが、施策のたびにインフラの調整が発生し、マーケティングのスピードが止まってしまうのは大きな損失です。

このような、「企画から公開までのタイムラグ」を根本から縮める鍵となるのが、Webサイトやアプリを裏側で動かしている開発基盤（デベロッパーズ・プラットフォーム）の選び方です。

この節では、マーケターが、プログラミングの知識とは別に知っておくべき「Cloudflareの開発基盤（Cloudflare Workers）」の基本と、それがどのように施策のスピード、安全性、コストに影響するのかを解説します。

「サーバーのお世話」からエンジニアを解放するCloudflare Workers

Cloudflareといえば、Webサイトの表示を速くする「CDN」や、サイバー攻撃を防ぐ「WAF」が有名ですが、実はそれらの基盤の上でプログラムそのものを動かす「Cloudflare Workers（クラウドフレア・ワーカーズ）」という強力な開発環境を提供していることも見逃せません。

Workersの最大の特徴は、「サーバーレス（Serverless）」と呼ばれる仕組みにあります。「サーバーレス」と言っても、物理的なサーバーが存在しないわけではありません。開発者やインフラ担当者が「サーバーの台数」、「OSの設定」、「容量の計算」、「障害対策（冗長化）」といった面倒なインフラ管理を直接行わずに、プログラムを動かせる仕組みを意味します。

従来のサーバー運用では、アクセス増加に備えてあらかじめサーバーを増強したり、地域ごとの配信サーバーを用意したりする構築、管理作業が欠かせませんでした。

Workersを使えば、こうしたインフラ管理の大部分をCloudflare側が自動で処理してくれます。エンジニアが、インフラを維持、管理するために割く時間を減らし、「何を作るか（施策や機能の実装）」に集中できるようになるため、マーケティング側から見れば、企画から公開までのリードタイムが劇的に短縮される、という顕著なビジネスメリットが生まれます。

出典： Cloudflare Docs: Workers Overview

「バズったらサイトが落ちる」リスクと過剰投資からの脱却

マーケティング施策においてどうしても避けたい事態のひとつは、テレビで紹介されたり、SNSでバズったことによってアクセスが集中した際、サイトが重くなったり、サーバーが落ちたりして売上機会を逃すことでしょう。

従来のサーバー環境でこの事態を防ごうとすると、事前に入念なアクセス予測を行い、一時的な最大トラフィックに合わせて高額なサーバー構成を準備しておく必要がありました。しかし、当たるかどうか分からない施策のために、最初から巨大なインフラを用意するのはコスト面で非効率です。逆に予想を遥かに超えるアクセスが来れば、結局サイトは落ちてしまいます。

Cloudflare Workersは、全世界330以上の都市に展開するCloudflareの分散ネットワーク全体でプログラムが動くため、アクセスの急増に合わせて処理能力が自動的にスケール（拡張）します。

マーケターにとっては、キャンペーンのたびに過剰な事前インフラ予算を確保したり、アクセス集中によるサイトダウンに怯えたりすることなく、施策そのものにチャレンジできる選択肢が増えることを意味します。

出典： Cloudflare Docs: How Workers works

海外展開でも「どの国のサーバーに置くか」を悩まない

グローバル向けの施策や多言語サイトを展開する際、一般的なクラウド環境（AWSやAzureなど）では「東京リージョン」、「シンガポールリージョン」、「米国東部」といったように、どの地域のデータセンターにサーバーを配置するかを個別に設計、管理する必要があります。

しかし、ユーザーから物理的に遠い場所にあるサーバーからデータを配信すれば、どうしても通信の遅延（タイムラグ）が発生してしまいます。

Cloudflare Workersでは、アプリやプログラムを一度デプロイ（公開）すると、個別に地域ごとのサーバーを契約、管理することなく、Cloudflareが持つ世界中のネットワーク拠点へ自動的に展開されます。

海外ユーザーを対象にした施策であっても、マーケターやエンジニアが「どの国のサーバーに置くか」を意識することなく、国内と同等の超低遅延で快適な閲覧体験を提供することが可能となります。

適材適所なハイブリッド構成も可能

Cloudflareの開発基盤（Workers）を知ると、既存のAWSやGoogle Cloudをやめて、すべてCloudflareへ移行すべきなのか、という方向に考えが向くかもしれません。しかし、たとえばAWSからCloudflareに完全移行するといった単純な置き換えが常に正解とは限りません。

AWSには、大規模なデータベースや複雑な業務システム、長年蓄積されたマネージドサービスにおいて大きな強みがあります。一方Cloudflareは、Webの「最前線（エッジ）」における超高速なコンテンツ配信や軽量な処理、アクセス制御に圧倒的な強みを持っています。

そのため、実務においては、データベースや基幹システムは既存のAWSに残し、Webサイトのフロントエンドやキャンペーンページ、軽量なAPI処理だけをCloudflareで動かす、といったハイブリッドな構成が合理的な場合も少なくないでしょう。

重要なのは「どちらが優れているか」という製品比較ではなく、どの処理をどこに置けば、運用がシンプルになり、公開スピードが上がり、コストが最適化されるかという視点を持って検討することです。

サーバー料金だけでは測れない「本当のインフラコスト」

開発基盤のコストを比較する際には、月額のサーバー利用料やデータ単価だけに目が行きがちです。しかし、実際のインフラコストには、以下のような目に見えにくい運用コストが含まれています。

• サーバーの設計、構築にかかるエンジニアの人件費
• アクセス増加に備える負荷テストや事前設定の時間
• 夜間、休日の障害監視や緊急対応の負担
• クラウドからデータを取り出す際にかかる「データ転送量（エグレス料金）」

Cloudflare Workersや関連するストレージ（R2）では、クラウド業界で課題となっている「データ転送費用（エグレス料金）」が発生しないシンプルな料金体系を採用しています。

月額の基本料金だけでなく、開発、インフラ、運用、通信までを含めた「トータルの人手と時間」をどれだけ削れるか。公開までの期間が短くなり、エンジニアの運用工数が大幅に削減されるのであれば、Cloudflare Workersの採用は、事業全体として極めてコストパフォーマンスの高い選択となるはずです。

出典： Cloudflare Docs: Workers pricing

マーケターに必要なのは「技術」ではなく「適切な問い」

言うまでもないことですが、マーケター自身がWorkersのコードを書けるようになる必要は一切ありません。しかし、こうした開発基盤の選択肢があることを知っておくだけで、制作会社や社内エンジニアとのコミュニケーションは劇的に変わります。

開発基盤の進化が頭に入っていれば、以下のような、施策のスピードとコストを最適化するための適切な問いを投げかけられるようになります。

• キャンペーンサイトを短期間で公開したいが、もっとシンプルな構成で作れないか？
• 急なアクセス増加に備えるために、どれくらいのインフラ準備期間と費用がかかっているのか？
• 公開後のサーバー管理や保守にかかる運用工数は、将来的にどこまで減らせるのか？

重要なのは、制作会社やエンジニアと同じ専門知識を持つことではなく、企画と技術の間に入って、より速い、より無駄のない選択肢を一緒に選べるようになることです。これこそが、マーケターがCloudflareの開発基盤を知ることの本当の意味なのです。

DOMO視点

施策にブレーキをかけているボトルネックを見つける

DOMOとしてCloudflareの開発基盤（Workers）の導入を検討する際、最初に確認させていただくのは、「企画から公開までの工程で、何が時間と人手を最も消費しているか」という点です。

たとえば、以下のような問題が発生しているのではないかということを確認します。

• サーバー調達と環境構築による、公開までの数週間のタイムロス
• キャンペーン中のサーバー監視や負荷対策による、エンジニアへの過大な負担
• 海外からのアクセス遅延と、地域ごとの個別サーバー管理による運用のカオス

このような具体的なインフラ運用の「詰まり」が存在する場合には、Cloudflare Workersのようなサーバーレス基盤を採用することで、大きな価値が生まれる可能性があると考えます。逆に、すでにAWS等で自動化された安定運用が確立されており、特にボトルネックがないのであれば、無理にシステムを書き換える必要はありません。

技術選定のゴールは、やみくもに最新のインフラを使うことではありません。企画から公開までの距離を短くし、公開後も改善のためのループを最速で回せる環境を整えることです。マーケティング施策のスピードという最大の成果を出すために、技術の使いどころを見極めることこそが、DOMOの提案する基盤設計の考え方です。

まとめ

Cloudflare Developer PlatformやWorkersは、単なるエンジニア向けの開発ツールではなく、サーバー管理の負担を減らし、マーケティング施策を最速で世に出すためのインフラ基盤です。

以下に、Workersによって得られるメリットをまとめておきましょう。

• サーバーのお世話からの解放： サーバーの構築、台数管理、冗長化などの負担をCloudflareへ任せ、施策公開までのリードタイムを大幅に短縮する
• アクセス急増とグローバル対応の自動化： スパイクアクセスでのサイトダウンを防ぎ、国ごとの個別サーバー管理なしで世界中へ超低遅延で配信する
• トータルコストとスピードで評価： サーバー単価だけでなく、エンジニアの運用工数、障害対応、データ転送量を含めた全体の効率化で判断する

自社のWeb施策において、企画から公開までのスピードにブレーキをかけている原因は何でしょうか？ まずはインフラ運用における「待ち時間」の洗い出しから始めましょう。

覚えておきたい用語

• Cloudflare Developer Platform： Workersを中心に、Webサイトやアプリの開発、実行、データ保存などを提供するCloudflareの開発基盤
• Cloudflare Workers： Cloudflareのグローバルネットワーク上でWebアプリや処理を実行するサーバーレス開発基盤
• サーバーレス（Serverless）： 開発者がサーバーの台数やOSなどを直接管理せずに、プログラムを動かせる仕組み
• スケーリング： アクセス量に合わせて、システムの処理能力を自動的、動的に増減させること
• リージョン： クラウドサービスでサーバーなどのデータセンターを配置、管理する地理的地域（「東京」、「シンガポール」など）
• デプロイ： 作成したWebサイトやプログラムを実際の公開環境へ反映し、利用できる状態にすること
• エグレス料金： クラウドサービスから外部（インターネットなど）へデータを転送、配信する際にかかる従量課金費用