Cloudflareと
Workersを
基礎から、実践まで。

小さなWebサービスを、自分で公開できるようになる

「イベントの申込みを受け付けたい」「自分の仕事に合うAIツールを作りたい」「作ったアプリを、ほかの人にも使ってもらいたい」。Cloudflareを学ぶと、こうしたアイデアを実際に使えるWebサービスにする方法が分かります。

画面を作るだけならできそうでも、公開するサーバー、データの保存先、アクセスが増えたときの対応まで考えると、急に難しく感じるかもしれません。Cloudflare、とくにWorkersの魅力は、小さなWebサービスに必要な機能を、一つずつ追加しながら始められることです。

最初の目標は、短いプログラムを書いて、アクセスすると結果が返るURLを一つ持つこと。その次に入力を受け取り、データを保存し、画面を付ける。Cloudflareの機能をすべて知ってから作り始める必要はありません。

たとえば、こんなものから始められる

これらは製品の機能を組み合わせた制作例です。完成済みのサービスが自動的に手に入るわけではなく、必要な処理や権限を実装していきます。

Cloudflareを選ぶと、何が変わる？

1. 最初の公開までに、自分で用意するものを少なくできる

Workersでは、自分でサーバーを借りてOSを設定する工程を持たずに、コードを配置できます。最初は独自ドメインも不要です。まず一つ動かし、結果を見ながら学べるため、「準備を終えるまで成果が見えない」という負担を小さくできます。

画面用のHTMLや画像もWorkersのStatic Assetsで配信でき、必要になったらデータベースやファイル保存を追加できます。画面とAPIを同じプロジェクトで扱える構成は、少人数で開発する場合にも試す価値があります。

公式資料：最初のWorkerを作る手順 / Static Assets

2. 複数の地域への配信を、共通の基盤に任せられる

Cloudflareは分散したネットワークでWeb通信やWorkersを処理します。利用者が増えるたびに自分で各地のサーバーを設置する方法とは、準備の仕方が変わります。広い地域の利用者に届けたいWebページや、短い処理のAPIでは、この仕組みが役立ちます。

ただし、実際の速さは保存先や外部APIとの距離にも左右されます。「Cloudflareへ移せば必ず速くなる」とは限りません。どこへの通信が多いかを見て、小さい機能で測ることが大切です。

公式資料：Workersの実行モデル

3. 小さく試し、利用量に合わせて費用を考えられる

Workersには無料プランがあり、最初の学習や小規模な試作に使えます。ファイル保存のR2には、R2から直接インターネットへ送るデータの転送料が無料という特徴があります。画像や資料を広く配信するサービスでは、費用を見直す理由になり得ます。

無料枠には上限があり、R2も保存量や読み書き操作は課金対象です。AIやログも別に考えます。比較するときは月額の表示だけでなく、自分のサービスの使われ方で、総額がどう変わるかを確認します。

公式資料：Workers料金 / R2料金

なぜ今、AIエージェントの基盤として注目されるのか

AIに文章を書いてもらうだけでなく、資料を調べ、必要な処理を実行し、途中経過を保存して、仕事を先へ進めてもらう。そのようなAIエージェントを、自分のWebサービスとして提供するための選択肢として、Cloudflareの役割が広がっています。

たとえば、イベントの資料を受け取り、案内文を作り、人が内容を確認したら公開するサービス。AIモデルを呼ぶ機能に加えて、資料の保存、処理の再開、承認待ち、実行履歴の確認が必要です。Cloudflareには、これらを組み合わせるためのサービスがあります。Workersを学ぶと、AIへの一度の質問から、継続して使えるアプリへ進むための基本が身に付きます。

まず区別したい、二つの「AIで作る」

二つを組み合わせることもできます。ただし、Cloudflareを選ぶだけで、AIが無条件に正しいアプリを作って公開してくれるわけではありません。AIが作った結果を自分で確かめられることが、学ぶ価値の一つです。

2026年の発表から分かること

公式発表：Anthropicとの協業 / Cloudflare Agents / Adaptive Intelligence / 脆弱性発見・修復支援

Managed Defenseの発表では、GPT-5.6 Cyberを含むOpenAI Daybreakモデルを使用し、モデルの推論はOpenAI側で実行すると説明されています。修正案は検証と顧客のレビューを経る仕組みです。「Cloudflare上のAIが、すべての弱点を自動で直す」と受け取らないようにしましょう。

開発と運用、セキュリティという異なる分野で発表が続いたことは、Cloudflareを目にする機会が増える背景として考えられます。ただし、これは発表内容をもとにした見方です。個人の周囲で評判が広がった原因や、開発者全体の支持の割合を示す調査ではありません。

エージェントに必要な機能を、どう分担する？

公式資料：Agents SDK / トレースと観測 / AgentsとWorkflows / Sandbox / Browser Run / Dynamic Workers

隔離された実行環境でも、外部へ送ってよい情報や、実行してよい操作は別に決めます。公開・送信・削除には必要に応じて承認を設け、モデル呼び出し回数と処理時間にも上限を持たせます。トレースには入力内容や機密情報が残り得るため、記録する対象を選びます。製品ごとに料金と利用条件があり、すべてを無料で使えるわけではありません。

AIを使う側だけでなく、情報を公開する側にも関係がある

Cloudflareは、AIによるアクセスをSearch（検索）、Training（学習）、Agent（利用者に代わる取得・操作）に分けて管理する仕組みも提供しています。目的が違えば、サイト運営者が許可したい範囲も違うためです。

「Disallow AI Training」は、学習への利用を拒否しつつ検索に残るための設定です。通信自体を止める「Block」とは異なり、対応するクローラーによる遵守が前提になります。検索と学習を兼ねるクローラーをBlockすると、検索にも影響します。古い発表だけを読んで「学習用は一律に遮断され、検索には影響しない」と判断しないでください。

最新の公式説明：2026年9月15日：検索とAI学習を区別する設定

話題になっていることと、自分に合うことを分けて考える

Cloudflareは以前からCDNやセキュリティで使われてきた会社です。最近の発表は、既存の実行・保存・通信の機能をエージェント開発へ広げる動きとして理解できます。株価やSNSの評判は関心の広がりを知る材料ですが、アプリが速くなること、安くなること、止まらないことの証明にはなりません。

これから作る人なら「AIで文章を整え、結果を保存する小さなアプリ」を試す。すでにAWSを使う人なら「新しいAI機能だけをWorkersで作り、既存DBと接続する」案を比較する。開発の手間、応答時間、総費用、復旧方法を自分の条件で確かめると、学習や移行の理由が具体的になります。

最初から自律的なエージェントを完成させる必要はありません。まずは入力を受け取り、結果を返すWorkerを一つ作る。保存とAI呼び出しを加え、その後に複数段階の処理へ進む。この順序なら、便利さを確かめながら、動く理由も理解できます。

AWS・Google Cloudと、どう選び分ける？

Cloudflareを選ぶ価値が高いのは、自分が作りたいものと、その仕組みが合うときです。Webサービスの作り始めや配信の改善では有力な候補ですが、既存のアプリや大量のデータを扱う仕事では、AWSやGoogle Cloudが向く場合もあります。

AWSのLambdaやGoogle CloudのCloud Runも、サーバーの管理をサービス側に任せてコードを実行できます。「サーバー管理が不要」という点だけでは、Cloudflareだけの優位性にはなりません。比較したいのは、公開・配信・保存まで含めて、自分の構成をどれだけ無理なく作れるかです。

公式資料：AWS Lambda / Google Cloud Runの実行環境

自分の目的から、候補を絞る

この表は各社の公式仕様をもとにした、教材としての選び方の提案です。速度・費用の実測比較や、すべてのサービスを網羅した順位表ではありません。

比較の根拠：AWS内でのLambdaとRDSの接続 / Fargateの実行条件 / Cloud Runのメモリ設定 / BigQueryの用途

Cloudflareの、不便になり得るところも知っておく

既存のプログラムを、そのまま動かせるとは限りません。通常のWorkersにはメモリやCPU時間などの制約があり、Node.jsとの互換性にも範囲があります。OSの機能に強く依存する処理や、長時間の重い計算は、別の実行方法を検討します。CloudflareにもContainersという別サービスがありますが、この教材の通常のWorkersとは実行条件・料金を分けて考えます。

データを置く場所の設計は必要です。Cloudflare側のAPIから、遠くのAWS上のデータベースへ何度も問い合わせれば、その通信が遅さの原因になることがあります。また、D1は既存のPostgreSQLやMySQLの完全な代替ではありません。既存DBを残して接続する方法も含めて判断します。

Cloudflare特有の機能を使うほど、移行時に直す部分は増えます。KVやDurable Objectsなどを使ったコードやデータ構造は、別のクラウドへそのまま移せるとは限りません。独自機能で開発が楽になる効果と、将来の変更に必要な作業の両方を考えます。

障害対応や費用管理の仕事は残ります。サーバーを直接管理しなくても、エラーの調査、データの復旧、利用者の権限、請求の確認は必要です。会社で採用するなら、監査・データの取扱地域・サポート契約なども条件に入れます。

公式資料：Workersの制限 / Node.js互換性 / Cloudflare Containers / 保存先の選び方

大規模障害から考える、一社への依存

2025年11月18日、Cloudflareでは中核の通信配信に大きな障害が発生しました。公式報告によると、攻撃ではなく、Bot Management用のファイル生成に関わる不具合が原因です。世界に分散した基盤でも、共通の仕組みの変更が広く影響することがあります。

個人の試作では、コードを手元にも保存し、重要なデータを取り出せるようにするところから始めます。仕事で使うなら、許容できる停止時間、バックアップの復元手順、別経路での障害案内を決めます。複数クラウドで動かす方法は費用と運用の複雑さも増すため、必要性に合わせて選びます。「障害後も話題だから安心」とは判断せず、便利さと停止時の影響を両方評価しましょう。

公式報告：2025年11月18日のCloudflareの障害

AWSからの乗り換えは、一つの機能で確かめられる

たとえば、既存アプリのDBはAWSに残し、新しい公開APIだけWorkersで試す。画像配信だけR2を比較する。既存サイトの手前で、特定のURLの処理やキャッシュだけをCloudflareに任せる。こうした部分的な採用から、移行する価値を確かめられます。

Workersから既存のPostgreSQLやMySQLへ接続するために、Hyperdriveを使う選択肢もあります。一方、クラウドをまたぐ通信には、接続方法、権限、転送料、障害の調査範囲が増えるという面もあります。S3からR2を検討するなら、使用中のS3 APIが対応しているかも確認します。

公式資料：既存DBを活かすHyperdrive / R2のS3 API互換範囲

最初に試すなら、「小さくて、結果が分かるもの」

これから学ぶ人は、名前を送ると挨拶を返すURLを一つ作ってみてください。すでにAWSなどを使っている人は、公開してよいデータを返す小さなAPIを一つ作り、今の方法と比べてみてください。作成と更新にどれくらい手間がかかるか、どこまで自分で理解して扱えるかが見えてきます。

まずは、一つのURLを動かすところから。その経験があれば、Cloudflareの説明を読むだけでなく、自分の用途に合うかを判断できるようになります。この教材では、その最初の一歩から、保存・公開・運用までを順番に試していきます。

Hello Worldの実習へ進む →　Webの仕組みから知りたい方は、このまま順に読み進めてください。

何ができる？ この教材の読み方

Cloudflare Workersを使うと、自分のプログラムをインターネット上で動かせます。たとえば、問い合わせを受け付けるAPI、画像を保存するサービス、AIへの質問を処理するアプリを作れます。

この教材では「Webの仕組みを知らない」状態から始め、短いプログラムを動かし、データ保存・公開・運用へ進みます。すべてのAPIを暗記する必要はありません。どこでコードが動き、何を保存し、何に料金がかかるかを説明できることが最初の目標です。

初回は、この順に読んでください

1. 全体像〜Workersの仕組み：図と太字を中心に読み、通信の流れをつかむ。
2. Hello World〜環境変数：手元のパソコンでコードを変え、結果を確かめる。
3. 保存・非同期・AI：まず比較表を読み、必要な製品を一つだけ試す。
4. デプロイ〜実践：小さなアプリを完成させ、公開前の条件を確認する。

コードはJavaScriptを基本とし、設定にはコメントを書けるJSON形式のJSONCを使います。「ファイル全体」と書いた例は置き換え用、「断片」と書いた例は既存コードへの追加用です。実際に入力する値が必要な箇所には説明を添えます。

Cloudflare全体を、通信とアプリの両方から見る

Cloudflareは、Web通信の配信・保護と、アプリを動かすためのサービスを提供しています。Workersは、その中の「プログラムを実行する」サービスです。

ブラウザはWebページを見るアプリです。サーバーはブラウザなどから依頼を受け、データを返すプログラムやコンピューターを指します。元のWebサイトを動かしているサーバーをオリジンサーバーと呼びます。

フロントエンドとバックエンド

フロントエンドは利用者が操作する画面、バックエンドはデータ保存や権限確認などを行うサーバー側の処理です。ブラウザに渡したJavaScriptは利用者から見えます。APIキーや管理者権限が必要な処理は、Workersなどのバックエンドで扱います。

APIはプログラム同士がデータや処理をやり取りするための決められた窓口です。「今日の予定を返すURL」「登録データを受け取るURL」などを作れます。Workersでは画面用HTMLもAPIのデータも返せます。

公式資料：Workersと公開URL

公式資料：静的ファイルも配信できるStatic Assets

DNS・CDN・セキュリティを順に理解する

DNS：ドメイン名から接続先を調べる

www.example.com のような名前がドメイン名です。通信先の識別に使うIPアドレスとの対応をDNSに登録します。AレコードはIPv4、AAAAはIPv6、CNAMEは別のホスト名、MXはメール配送先、TXTは所有権確認などの文字情報に使います。

ドメインを購入することと、DNSを管理することは別の作業です。CloudflareでDNS全体を管理する一般的な方法では、ドメイン登録事業者の画面でネームサーバーを指定します。既存サイトやメールがある場合は、その前に必要なDNSレコードをそろえます。

プロキシ化できるのは対応するA・AAAA・CNAMEレコードです。MXやTXTまでオレンジの雲にするわけではありません。所有権確認用CNAMEなども用途に従って設定します。DNSをCloudflareに移しただけで、すべての通信が自動的に保護対象になるとは限りません。

公式資料：DNSのProxy status

CDN：同じ内容を何度も取りに行かない

CDNは複数の拠点からコンテンツを配信する仕組みです。キャッシュは、取得した内容を保存して次のリクエストに再利用することです。保存済みの内容を使えればHIT、使えず取得が必要ならMISSと呼びます。再利用できる期間はTTLで指定します。

通常のCDNはHTMLやJSONをデフォルトではキャッシュしません。ファイル拡張子、レスポンスヘッダー、ルールなどで動作が変わります。ログイン中の個人情報を含むページを共有キャッシュに入れると、他の人に見せてしまう可能性があります。

公式資料：CDNの既定のキャッシュ動作

セキュリティ：それぞれ守る対象が異なる

既存オリジンを使う構成では、ブラウザ→CloudflareとCloudflare→オリジンの両区間を考えます。Full (strict)は後半のTLS証明書も検証するモードで、オリジン側に有効な証明書などの条件が必要です。これは独自のオリジンに接続する場合の設定です。

公式資料：WAF

公式資料：DDoS Protection

公式資料：Full (strict)の条件

Workersは、イベントが来るとコードを実行する

Workerには「HTTPリクエストを受け取ったら何をするか」を書きます。Cloudflareが実行環境を管理するため、自分で常時稼働するサーバーを用意する必要はありません。

サーバーレスは、サーバーが存在しないという意味ではありません。開発者がOS更新や台数管理を直接行わず、サービス側の実行基盤に処理を任せる方式です。コード、データ、権限、エラー、料金の管理は開発者の仕事です。

V8 Isolatesと、保存してはいけない状態

JavaScript版Workersの実行環境は、V8のIsolateという分離された実行領域を使います。各処理のために新しい仮想マシンを起動する方式とは異なり、素早く起動できるよう設計されています。ただし、常に同じ実行領域が残る保証はありません。

たとえばコードの先頭に let count = 0 と書いても、世界中で共有される永続的なアクセス数にはなりません。別の実行領域では値が違い、再起動で失われることもあります。残したいデータは保存サービスへ、利用者ごとの一時変数はリクエスト内へ置きます。

公式資料：Workersの実行モデル

「近くで動く」と「全処理が近くで完結する」は別

Cloudflareは分散したネットワークでリクエストを処理します。それでも、Workerから遠くのデータベースへ毎回問い合わせれば通信時間がかかります。利用者との距離だけでなく、データとの距離、問い合わせ回数、返す量も速さに影響します。特定の国や拠点で必ず実行されると決めつけないでください。

CPU時間と待ち時間

この例の経過時間は205msですが、CPU時間は5msです。CPU時間は、コードの実行にCPUを使った時間です。通信待ちが長い処理と、大きな配列の計算を続ける処理では、同じ経過時間でも消費が異なります。数値は理解のための例です。

Node.js用コードを使うとき

WorkersはNode.jsそのものではなく、Workersランタイムで動きます。Node.js互換APIはありますが、すべての機能が使えるわけではありません。現在の公式資料では compatibility_date が2026-08-04以降ならNode.js互換機能が既定で有効です。古い日付のプロジェクトでは設定が異なります。読み込めても実行できないAPIもあるため、依存ライブラリの使用部分を確認します。

公式資料：Node.js compatibility：日付による違い

公式資料：CPU時間などの制限

Hello World：まず一つ、動くものを作る

最初はパソコンの中で動かし、返す文字を変えてみましょう。公開は後の章で行います。

1. 準備するもの

Cloudflareアカウント、対応するNode.js、コードを書くエディター、ターミナルを用意します。Macなら「ターミナル」アプリにコマンドを入力できます。コマンドはコンピューターに実行させる文字の指示です。

Node.jsにはnpmというパッケージ管理ツールが付属します。開発用ツールを動かすためにNode.jsを使いますが、Worker本体はWorkersランタイムで実行されます。Node.jsは公式サイトのサポート中のLTSを選び、Wranglerの現行要件も確認してください。

node --version
npm --version

両方でバージョンが表示されれば準備を確認できます。command not found は、そのコマンドが見つからない状態です。導入後にターミナルを開き直し、再確認します。

公式資料：Wranglerの対応環境

2. プロジェクトを作る

npm create cloudflare@latest -- my-first-worker
cd my-first-worker

npm create が作成ツールを実行し、cd が作業フォルダーを移動します。作成時の選択は Hello World example → Worker only → JavaScript を基本にします。Gitを使うかは任意、最初のデプロイは No にします。対話画面の名称は更新で変わることがあります。

3. コードを入れる

src/index.js を次の内容に置き換えます。

export default {
  async fetch(request, env, ctx) {
    return new Response("こんにちは、Workers！", {
      headers: { "Content-Type": "text/plain; charset=utf-8" }
    });
  }
};

4. ローカルで起動する

npx wrangler dev

表示されたローカルURL（通常は http://localhost:8787）をブラウザで開きます。上の例なら「こんにちは、Workers！」が返る想定です。文字を変えて保存し、ページを再読み込みします。終了するときはターミナルで Control + C を押します。

公式資料：公式CLI入門

コードを一行ずつ読む

Request / Response：Webのやり取りを読む

Webのやり取りは「リクエストを送る → レスポンスを返す」が基本です。Workersでは、その両方をコードで扱えます。

https://api.example.com/api/hello?name=Hiro
└ 接続方式 ┘└ ホスト名 ┘└ パス ┘└ クエリ ┘

GETは取得、POSTは送信・作成、PUTやPATCHは更新、DELETEは削除に使うのが一般的です。GETでページを開いただけでデータを消すような設計は避けます。

名前に応じたJSONを返す

JSONは { "name": "Hiro" } のようにデータを表す形式です。次のコードでHello Worldを置き換え、/api/hello?name=Hiro を開いてください。

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === "/api/hello") {
      if (request.method !== "GET") {
        return new Response("GETを使ってください", {
          status: 405, headers: { Allow: "GET" }
        });
      }
      const name = url.searchParams.get("name") || "ゲスト";
      if (name.length > 40) {
        return Response.json({ error: "名前は40文字以内です" }, {
          status: 400
        });
      }
      return Response.json({ message: `こんにちは、${name}さん！` }, {
        headers: { "Cache-Control": "no-store" }
      });
    }

    return new Response("ページが見つかりません", { status: 404 });
  }
};

const は値に名前を付ける宣言、if は条件分岐です。new URL(...) でURLを分解し、pathname でパス、searchParams.get(...) でクエリ値を取り出します。|| の右側は、ここでは名前が空か未指定のときに使う値です。

公式資料：Request API

公式資料：Response API

POSTの本文を読む

const data = await request.json();
// 例：data.title が送信されたタイトル
// 形式だけでなく型・長さ・必要な項目も検証する

request.json() は、本文が不正なJSONなら例外になります。try / catch で扱い、400などを返します。本文は基本的に一度読むと消費されます。複数回読む設計や、大きなファイルを丸ごとメモリに載せる設計は避けます。後の実習では、小さいJSONに限定して扱います。

ルーティングは、公開先とコード内の2段階

まず「どのWorkerへ届けるか」をCloudflare側で決め、その後「Worker内のどの処理を行うか」をパスやメソッドで決めます。

ゾーンはCloudflareで管理するドメインの設定単位です。Custom DomainではCloudflareがDNSと証明書を設定します。RouteではURLパターンを指定します。次の2例は用途が異なるので、必要な方だけを設定へ追加します。

"routes": [
  { "pattern": "api.example.com", "custom_domain": true }
]

"routes": [
  { "pattern": "www.example.com/api/*", "zone_name": "example.com" }
]

example.com は説明用ドメインです。自分の管理するドメインへ置き換えます。Custom Domainはホスト名単位なので、/items などの振り分けはコード側で行います。既存CNAMEと競合するなど、追加できない条件もあります。

export default {
  async fetch(request) {
    const upstream = await fetch(request);
    const response = new Response(upstream.body, upstream);
    response.headers.set("X-App-Version", "1");
    return response;
  }
};

公式資料：公開先の選び方

公式資料：Custom Domains

公式資料：Routesの設定条件

環境変数・Secrets・Bindingsを使い分ける

コードに埋め込む必要のない値や接続先を、設定で渡します。envからアクセスできても、その種類と扱いは異なります。

Bindingはコード上の名前とリソースを接続する設定です。DBという名前は自動で生えるものではありません。設定に登録した名前とコードで使う名前を合わせます。varsやSecretsも、広い意味ではWorkerへ値を渡すBindingです。

基本の設定ファイル

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-first-worker",
  "main": "src/index.js",
  "compatibility_date": "2026-09-17",
  "vars": { "APP_NAME": "はじめてのWorkers" },
  "observability": { "enabled": true }
}

compatibility_date はランタイムの互換動作の基準日です。デプロイ日を記録する欄ではありません。更新すると有効になる動作が変わることがあるため、既存アプリではテストしてから更新します。サンプルは教材確認日を使っています。

公式資料：互換日付の考え方

秘密は、ローカルと公開環境に別々に登録する

ローカル開発では、設定ファイルと同じ場所に .dev.vars を作ります。以下の値はダミーです。ブラウザへ送るHTMLやJavaScriptに書かないでください。

EXTERNAL_API_KEY="local-test-value"

.dev.vars*
.env*

公開環境への登録は次のコマンドで行い、対話入力欄に値を入力します。コマンドの引数に秘密そのものを記載する必要はありません。

npx wrangler secret put EXTERNAL_API_KEY

Secretsでも、コードがレスポンスやログに出力すれば漏れます。console.log(env) や、秘密入りのエラーメッセージを返す処理は書かないでください。

公式資料：Secretsの登録・ローカル開発

開発・検証・本番を分ける

検証用の環境を staging、実利用の環境を production と呼ぶことがあります。Wranglerの環境設定を使えば、同じコードを異なるリソースに接続できます。varsやBindingsは環境ごとに必要な設定を定義し、Secretsも対象環境へ登録します。検証中に本番データを書き換えない接続先にすることが重要です。

公式資料：環境変数と環境ごとの設定

データをどこに置くかは、「どう読み、どう更新したいか」で決める

Cloudflareには保存先がいくつもあります。まず「設定を世界中で速く読みたい」「SQLで検索したい」「ファイルを置きたい」「同じ状態を順番に更新したい」のどれかを選びます。保存するデータの形より、読み書きの性質から選ぶと迷いません。

SQLはデータベースに検索や更新を指示する言語です。SQLiteはD1などが使うデータベース技術。namespaceはKVのデータを分ける単位、bucketはR2の保存単位です。以下の各例は独立した練習です。Hello Worldと同じ手順で別々のWorkerプロジェクトを作り、設定断片を基本のwrangler.jsoncへ追加してください。作成コマンドはCloudflare側にリソースを作りますが、通常のローカル開発では保存データをローカルに分けて扱います。

// 単独例: POSTで書き、GETで読む
export default {
  async fetch(request, env) {
    if (request.method === "POST") {
      await env.SETTINGS.put("announcement", "10月のイベントを公開しました");
      return new Response("saved");
    }
    if (request.method !== "GET") return new Response("Method Not Allowed", { status: 405, headers: { Allow: "GET, POST" } });
    const message = await env.SETTINGS.get("announcement");
    return new Response(message ?? "お知らせはありません");
  }
};

# ターミナル：namespaceを作成
npx wrangler kv namespace create SETTINGS

// wrangler.jsonc の断片。出力されたidを設定する
{ "kv_namespaces": [{ "binding": "SETTINGS", "id": "<NAMESPACE_ID>" }] }

// fetchハンドラー内の断片：D1に申込みを登録する
const result = await env.DB.prepare(
  "INSERT INTO registrations (email, attendance_type) VALUES (?1, ?2)"
).bind("hiro@example.com", "online").run();

return Response.json({ id: result.meta.last_row_id });

-- 事前に一度だけ実行するSQL（migrationファイルに保存）
CREATE TABLE registrations (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL,
  attendance_type TEXT NOT NULL
);
CREATE INDEX idx_registrations_type ON registrations(attendance_type);

// 単独例: PUTで本文を保存し、GETで同じキーを読む
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const key = url.pathname.replace(/^\//, "") || "sample.txt";
    if (request.method === "GET") {
      const object = await env.FILES.get(key);
      return object ? new Response(object.body, {
        headers: { "Content-Type": "text/plain; charset=utf-8", "X-Content-Type-Options": "nosniff" }
      }) : new Response("Not Found", { status: 404 });
    }
    if (request.method !== "PUT") return new Response("Method Not Allowed", { status: 405 });
    // 小さいテキスト用。全文をメモリに読み込む。
    await env.FILES.put(key, await request.arrayBuffer(), {
      httpMetadata: { contentType: request.headers.get("content-type") ?? "text/plain" }
    });
    return Response.json({ key });
  }
};

# ターミナル：bucketを作成
npx wrangler r2 bucket create learning-files

// wrangler.jsonc の断片
{ "r2_buckets": [{ "binding": "FILES", "bucket_name": "learning-files" }] }

// src/index.js: 入口WorkerとSQLite Durable Object
import { DurableObject } from "cloudflare:workers";

export class Counter extends DurableObject {
  constructor(ctx, env) {
    super(ctx, env);
    this.sql = ctx.storage.sql;
    this.sql.exec("CREATE TABLE IF NOT EXISTS state (key TEXT PRIMARY KEY, value INTEGER NOT NULL)");
    this.sql.exec("INSERT OR IGNORE INTO state (key, value) VALUES (?, ?)", "visits", 0);
  }

  async fetch(request) {
    if (request.method !== "POST") return new Response("Method Not Allowed", { status: 405 });
    this.sql.exec("UPDATE state SET value = value + 1 WHERE key = ?", "visits");
    const row = this.sql.exec("SELECT value FROM state WHERE key = ?", "visits").one();
    return Response.json({ visits: row.value });
  }
}

export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("POST / で数える", { status: 405 });
    const id = env.COUNTER.idFromName("learning-counter");
    return env.COUNTER.get(id).fetch(request);
  }
};

// wrangler.jsonc: bindingとSQLite migrationを同じデプロイに含める
{
  "name": "learning-counter",
  "main": "src/index.js",
  "compatibility_date": "2026-09-17",
  "durable_objects": {
    "bindings": [{ "name": "COUNTER", "class_name": "Counter" }]
  },
  "migrations": [{ "tag": "v1", "new_sqlite_classes": ["Counter"] }]
}

待たせない処理と、決まった時刻の処理を分ける

利用者の画面をすぐ返したいとき、重い処理はQueuesへ渡します。毎日・毎時の処理はCron Triggersで起動します。どちらもWorkerを動かしますが、Queuesは「届いた仕事」、Cronは「時刻」がきっかけです。

Producerは仕事をキューへ送る側、Consumerは取り出して処理する側です。Dead Letter Queue（DLQ）は、指定回数の再試行後も失敗した仕事の送り先です。DLQを設定し、そこに届いた仕事を調査・復旧する手順も用意します。

公式：ContextとwaitUntil

// src/index.js：ファイル全体。ローカル学習用・認証なし。
export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("POSTを使ってください", {
        status: 405, headers: { Allow: "POST" }
      });
    }
    await env.MAIL_QUEUE.send({
      eventId: crypto.randomUUID(), task: "send-confirmation"
    });
    return new Response("queued", { status: 202 });
  },
  async queue(batch, env) {
    for (const message of batch.messages) {
      // 学習用のログ出力。メール送信は行わない。
      console.log("received", message.body.eventId, message.body.task);
      message.ack();
    }
  }
};

# ターミナル：QueueとDLQを作成する
npx wrangler queues create mail-jobs
npx wrangler queues create mail-jobs-dlq

// wrangler.jsoncへの追加設定：同じWorkerにproducer/consumerを置く
{
  "queues": {
    "producers": [{ "binding": "MAIL_QUEUE", "queue": "mail-jobs" }],
    "consumers": [{
      "queue": "mail-jobs", "max_batch_size": 10, "max_batch_timeout": 5,
      "max_retries": 3, "dead_letter_queue": "mail-jobs-dlq"
    }]
  }
}

// 単独例: 毎日UTC 0:00（日本時間09:00）に動くWorker
export default {
  async scheduled(controller, env, ctx) {
    console.log("daily summary started", new Date().toISOString());
  }
};

// wrangler.jsonc の断片
{
  "triggers": {
    "crons": ["0 0 * * *"]
  }
}

AIを実行するWorkers AIと、AI呼び出しを整えるAI Gateway

Workers AIはCloudflare上でモデルを推論するサービスです。AI Gatewayは、Cloudflareや外部AIプロバイダーへの呼び出しを記録・キャッシュ・制限する入口です。両者は競合せず、Workers AIをAI Gateway経由で呼ぶこともできます。

推論は学習済みモデルへ入力を渡して結果を得ることです。LLMは文章などを扱う大規模言語モデル、GPUは並列計算が得意な計算装置。埋め込みは文章などを数値の列へ変換し、意味の近さを比較しやすくする方法です。

// 単独例: Workers AI bindingでチャットモデルを呼ぶ
export default {
  async fetch(request, env) {
    const answer = await env.AI.run("@cf/meta/llama-3.2-1b-instruct", {
      messages: [
        { role: "system", content: "日本語で短く答えてください。" },
        { role: "user", content: "Cloudflare Workersとは何ですか？" }
      ],
      max_tokens: 120
    });
    return Response.json(answer);
  }
};

// fetchハンドラー内の断片：AI呼び出しへGatewayを追加する
const answer = await env.AI.run(
  "@cf/meta/llama-3.2-1b-instruct",
  { prompt: "Cloudflare Workersを1文で説明して", max_tokens: 80 },
  {
    gateway: {
      id: "learning-gateway", // Dashboardで作った同一アカウントのGateway名
      skipCache: false,
      cacheTtl: 300
    }
  }
);
return Response.json(answer);

デプロイ・デバッグ・ログで動作を確かめる

デプロイとは、コードや設定を実行環境へ配置することです。コマンドが成功した後も、公開URLで期待どおりに動くかを確認します。

最初の公開

Hello Worldや名前を返すAPIなど、公開してよい内容のWorkerで実行します。

npx wrangler login
npx wrangler deploy

ログインではブラウザでCloudflareアカウントを認証します。公開後に表示されるURLを開いて確認してください。学習例では https://my-first-worker.<自分のサブドメイン>.workers.dev のような形式です。API例ならその末尾に /api/hello?name=Hiro を付けます。

公式資料：Wranglerでの公開手順

ログを見る

npx wrangler tail

console.log({ event: "request", method: request.method,
  path: new URL(request.url).pathname });

保存して後から検索するWorkers Logsは、"observability": { "enabled": true } を設定し、再デプロイします。ダッシュボードの対象WorkerのObservabilityで確認できます。ローカルのログと公開環境のログを混同しないでください。

ログには保存期間と使用量の制約があります。サンプリングは記録するリクエストの割合を下げる機能です。全件を残しているとは限らないため、「ログがないから呼び出されていない」とは断定できません。トークン、本文全文、個人情報を安易に記録しない設計にします。

公式資料：Workers Logsの有効化と検索

公式資料：ログの種類

困ったときは、症状から調べる

デバッガーでは途中で処理を止め、変数を調べられます。まず再現する入力を一つに絞り、ローカルのログやDevToolsで確認すると原因を追いやすくなります。

料金と制限：何を数えているかを理解する

Workersの料金は、主にリクエスト数とCPU時間で考えます。保存サービス、ログ、AIなどは、それぞれの使用量も確認します。

Freeの日次リセットはUTCの0時です。日本時間では9時に相当します。Webサイト向けのPro / Businessと、Workers Paidは別のプランとして確認してください。

初期値の例では、月2,000万回 × 5ms = 1億CPU-ms。基本 $5 ＋ リクエスト超過 $3 ＋ CPU超過 $1.40 = 月 $9.40です。これは見積もり例であり、実請求の保証ではありません。

通常のStatic Assetsへの直接のリクエストは無料・無制限です。ただしWorkers Cachingを有効にした場合は、キャッシュから返るリクエストも課金対象になります。キャッシュHITではWorkerのCPU実行は課金されません。構成による違いを確認してください。

公式資料：Workersの料金・キャッシュ課金の注記

無料枠と、実行上の制限は別

HTTPの経過時間とCPU時間の制限は異なります。CronやQueueには別の実行条件があるため、HTTPの上限をそのまま当てはめません。大きな本文を受け付けられても、全体をメモリに読み込めるとは限りません。

公式資料：最新の制限一覧

意図しない使用量を減らす

Paidでは1回あたりのCPU上限を設定できます。次は100msという説明用の値です。必要な処理に足りるか計測して決めます。これは月額の支出上限ではありません。呼び出し回数、保存量、AI利用などは別に制御します。

"limits": { "cpu_ms": 100 }

料金の確認では「何回呼ばれるか」「何を何回読み書きするか」「再試行が何回起こるか」を書き出します。ログの全件保存、D1の大量走査、R2の大量操作、AIの長い入出力も、アプリの総額に影響します。

公開前に、入力・権限・秘密を確認する

Cloudflareが通信を保護していても、「他人のデータを編集してよいか」はアプリが判断します。小さいAPIでも、公開する前に境界を決めます。

実装で押さえる7点

1. 入力：型、長さ、許可値、本文サイズを検証する。JSONを読めたことと、安全な入力であることは別。
2. SQL：入力をSQL文字列へ連結せず、prepare(...).bind(...) で値を渡す。
3. HTML：利用者入力をHTMLへそのまま埋め込まない。文字の表示には textContent などを使う。
4. 秘密：Secretsに登録し、ブラウザやログへ返さない。漏れたキーは削除だけでなく失効・再発行する。
5. 外部通信：利用者が渡す任意のURLをそのままfetchしない。許可する接続先を限定する。
6. 回数：重い処理に利用者単位の回数制限を設け、上限に達したら停止する。
7. データ：個人情報の必要量、保存期間、削除手段、バックアップ・復旧方法を決める。

CORSは、本人確認ではない

Originは「接続方式・ホスト・ポート」の組み合わせです。ブラウザが異なるOriginへリクエストするとき、応答を画面側のコードから読んでよいかを制御する仕組みがCORSです。

許可するOrigin、メソッド、ヘッダーを必要な範囲に絞り、必要に応じてOPTIONSの事前確認に応答します。Cookieなどの資格情報を使うときに Access-Control-Allow-Origin: * を安易に設定しないでください。CORSで許可しなくても、ブラウザ以外からAPIを呼ぶことはできます。認証・認可はサーバー側で必ず行います。

Cookieで認証するアプリでは、別サイトから意図しない更新操作を起こすCSRFへの対策も考えます。SameSite設定、Origin確認、CSRFトークンなどを、認証方式に合わせて選びます。

キャッシュと権限を組み合わせるとき

公開してよい静的画像と、利用者別の請求書では保存方針が違います。個人用APIは Cache-Control: no-store などで共有を防ぎ、明示的なキャッシュルールがそれを上書きしないかも確認します。キャッシュキーにユーザーIDを足せば、すべての認可問題が解決するわけではありません。

公式資料：Workersの実装上の推奨事項

公式資料：Custom DomainとAccess

実習：D1に保存する小さなメモAPI

入力を受け取り、検証し、データベースに保存して一覧を返す。ここまで学んだ基本を一つにつなげます。

1. 新しいWorkerとD1を準備する

npm create cloudflare@latest -- notes-worker
cd notes-worker
npx wrangler d1 create notes-db

D1の作成コマンドはCloudflare上にデータベースを作ります。返された database_id を次の設定の指定箇所へ入れます。生成ツールが設定を追加した場合も、Binding名が DB か確認してください。

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "notes-worker",
  "main": "src/index.js",
  "compatibility_date": "2026-09-17",
  "d1_databases": [{
    "binding": "DB",
    "database_name": "notes-db",
    "database_id": "作成コマンドが返したIDに置き換える"
  }],
  "observability": { "enabled": true }
}

2. 保存する表を作る

プロジェクトの直下に schema.sql を作ります。テーブルはデータを行と列で保存する単位です。id は行を識別する番号、title はメモ本文として使う短い文字列です。

CREATE TABLE IF NOT EXISTS notes (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  title TEXT NOT NULL
);

npx wrangler d1 execute notes-db --local --file=./schema.sql

--localは手元のDBが対象です。Cloudflare上のD1に同じ表を作る操作とは別です。本番ではスキーマ変更をマイグレーションとして履歴管理し、適用先を確認します。

3. Workerを書く

次はファイル全体です。長い部分の多くは入力検証で、保存処理自体は最後の prepare(...).bind(...).run() です。

function json(data, status = 200) {
  return Response.json(data, {
    status, headers: { "Cache-Control": "no-store" }
  });
}

// 本文を最大8KBまで読む。Content-Lengthだけには依存しない。
async function readSmallJson(request) {
  if (!request.body) throw new Error("empty");
  const reader = request.body.getReader();
  const chunks = [];
  let size = 0;
  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    size += value.byteLength;
    if (size > 8192) {
      await reader.cancel();
      throw new Error("too_large");
    }
    chunks.push(value);
  }
  const bytes = new Uint8Array(size);
  let offset = 0;
  for (const chunk of chunks) {
    bytes.set(chunk, offset);
    offset += chunk.byteLength;
  }
  return JSON.parse(new TextDecoder().decode(bytes));
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname !== "/api/notes") {
      return json({ error: "not_found" }, 404);
    }
    try {
      if (request.method === "GET") {
        const { results } = await env.DB.prepare(
          "SELECT id, title FROM notes ORDER BY id DESC LIMIT 20"
        ).all();
        return json({ notes: results });
      }
      if (request.method !== "POST") {
        return new Response("Method not allowed", {
          status: 405, headers: { Allow: "GET, POST" }
        });
      }
      const type = request.headers.get("Content-Type") || "";
      if (type.split(";")[0].trim().toLowerCase() !== "application/json") {
        return json({ error: "JSONで送ってください" }, 415);
      }
      let data;
      try {
        data = await readSmallJson(request);
      } catch (error) {
        return json({ error: "本文は8KB以内の正しいJSONにしてください" },
          error.message === "too_large" ? 413 : 400);
      }
      if (typeof data?.title !== "string") {
        return json({ error: "titleは文字列です" }, 400);
      }
      const title = data.title.trim();
      if (!title || title.length > 100) {
        return json({ error: "titleは1〜100文字にしてください" }, 400);
      }
      await env.DB.prepare("INSERT INTO notes (title) VALUES (?)")
        .bind(title).run();
      return json({ saved: true }, 201);
    } catch {
      console.error({ event: "notes_failed" });
      return json({ error: "保存サービスの処理に失敗しました" }, 500);
    }
  }
};

? に値を渡す bind(title) は、利用者入力をSQL命令として解釈させないために使います。title.length はJavaScriptの文字列長の数え方なので、絵文字などは見た目の1文字と一致しない場合があります。

4. 保存と読み出しを確認する

一つのターミナルで起動し、別のターミナルでリクエストを送ります。curl はHTTP通信を試すコマンドです。

npx wrangler dev

curl -i http://localhost:8787/api/notes \
  -H 'Content-Type: application/json' \
  --data '{"title":"Workersを学ぶ"}'

curl -i http://localhost:8787/api/notes

最初は 201 と {"saved":true}、次は 200 とメモを含む一覧が期待結果です。さらに空タイトルは400、不正JSONは400、別パスは404、DELETEは405になることを試します。

公式資料：D1のはじめ方

公式資料：D1のPrepared statements

実践アーキテクチャ：目的に合わせて組み合わせる

最初から全部の製品を使う必要はありません。画面、処理、保存、非同期処理を分け、必要なものだけ加えます。以下は教材用の構成例です。

A. 小さな会員制Webアプリ

まずD1だけで文字データを扱い、添付機能が必要になったらR2を足します。R2のキーを知っていることと、読む権限があることは別です。ダウンロード時にWorkerで認可し、必要に応じて短期間だけ使えるURLを発行します。

B. 外部サービスからの通知を受け取る

送信元の署名を検証し、キュー投入が完了してから受け付け成功を返します。ConsumerはイベントIDの重複を処理して、同じ通知で二重登録しないようにします。キューに入る前の受付失敗と、受け付け後の処理失敗を分けると復旧しやすくなります。

C. AIを使う問い合わせ支援

AIへの呼び出しには時間と費用がかかります。入力と出力の長さ、同時実行、利用者ごとの回数を決めます。AIの文章は事実確認済みとは限らないため、業務で使う場合は根拠の表示や人の確認を設計に含めます。保存する履歴とログには、個人情報の取り扱いも反映します。

D. 複数人で共有する部屋

チャットや共同操作では、部屋ごとに一貫した状態を扱える仕組みが役立ちます。一つの巨大なオブジェクトに全利用者を集めると負荷が集中するため、部屋や対象データごとの単位を考えます。メッセージ履歴などをどこまで永続化するかも明示します。

設計時に書き出す5つの質問

1. 誰がどのURLへ、どの操作を送るか。
2. 誰の権限で、どのデータを読む・書くか。
3. その場で返す必要がある処理と、後でよい処理は何か。
4. 同じ操作が2回来た場合や、途中で失敗した場合にどうするか。
5. 1回あたり何を消費し、アクセス増加で何が増えるか。

学習ロードマップと理解度チェック

一つずつ「自分で確認できる成果」を作ると、知識がつながります。日数を固定せず、達成条件を満たしてから次へ進みましょう。

自分の理解を確かめる

次に読むテーマ

基本APIを作れたら、画面も配信するStatic Assets、ルートが増えたらルーターやフレームワーク、テストを増やすならWorkersのテスト環境へ進めます。長い複数段階の処理にはWorkflows、既存DBとの接続にはHyperdriveなどの選択肢があります。必要が生まれたときに公式資料を調べてください。

公式資料：Workers公式チュートリアル

公式資料：Workersのテスト

最初の到達点：「受け取る → 検証する → 処理・保存する → 結果を返す」を自分で実装し、失敗時の動作も確認できること。ここまでできれば、Workersを使った小さなアプリを段階的に育てられます。

用語集：分からない言葉を引く

公式資料の使い方

各章末のリンクはCloudflare・AWS・Google Cloudの公式ドキュメントです。料金・上限・設定方法は、使う直前にそのページを確認してください。ページの更新日、対象プラン、実験的機能かどうかも読みます。本文の構成図と練習問題は、この教材のために作成したものです。

教材確認日：2026年9月17日。製品の仕様やUIは変わります。学習用コードの検証範囲は巻末の「確認済みの範囲」に記載しています。本教材はCloudflare公式の発行物ではありません。