前回まで

前回まで、AstroとNext.jsで作ったサイトをCloudflare Workersにデプロイし、GitHubリポジトリと連携させて運用できる状態まで整えました。ここまでで「Workersでサイトを配信する」という目的は達成できました。

最終回となる今回は、Workersに載せたWebサイト・アプリを、Cloudflareのほかのサービスと連携させるお話です。また、運用していく中で欠かせないログ監視についても触れます。

バインディングという仕組み

Cloudflare社はセキュリティやネットワークインフラ・CDNのイメージが強いかもしれませんが（セキュリティから事業を始めたのは事実です）、現在ではデータベースやストレージ、アクセス解析など、Webアプリケーションのバックエンドでよく利用されるようなサービスも提供しています。いずれも、Cloudflareのインフラに載っていますから、データの読み書きのパフォーマンスに優れています。

もちろんこういったサービスにはさまざまな選択肢があり、たとえばデータベースであればCodeGridでも紹介しているTursoや、MongoDBなどが挙げられます。こういったCloudflare外部のサービスをWebアプリから使うとなると、認証情報のやり取りが必要になります。サービスのダッシュボードでAPIキーを発行し、それを環境変数に入れ、エンドポイントのURLと一緒にコードから読み込む……といった流れです。キーの管理にも気を遣います。

Cloudflare WorkersからCloudflareのサービスを使う場合は、この手間がありません。「バインディング」という機能によって、認証情報なしで接続ができます。

Bindings allow your Worker to interact with resources on the Cloudflare Developer Platform.

• Bindings | Cloudflare Docs

厳密には、認証をしていないわけではありません。ドキュメントには、バインディングは権限がAPIに埋め込まれているため、コードにキーやトークンを書く必要がない、と書かれています。その認証に必要な情報を開発者が取り扱う必要がない、ということです。

抽象的な話が続いてもわかりにくいので、実際の記述を見ていきましょう。

wrangler.jsoncに宣言する

例として、SQLデータベースの「D1」を使うことにします。ここではバインディングの操作にフォーカスし、具体的なWebアプリケーションなどは作成しません。データベースを用いたWebアプリケーション例は冒頭に挙げたデモで確認してください。

それでは「D1」を既存サイトにバインディングしてみましょう。

Cloudflareのダッシュボードで、左側のメニューから「ストレージとデータベース」→「D1 SQLite データベース」を選択します。「データベースを作成」ボタンから作成画面に進み、任意の名前をつけてください。ここでは「codegrid-demo」としました。データベースは空っぽですがひとまずこれでOKです。

Workers側からは、これまでの回でも触ってきたwrangler.jsoncにバインディングの設定を書きます。

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "2026-workers-hosting-bindings",
  "main": "./src/index.ts",
  "compatibility_date": "2026-09-01",
  "d1_databases": [
    {
      "binding": "DB", // env.DB になる
      "database_name": "codegrid-demo",
      "database_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
    }
  ]
}

database_nameは先ほどつけた名前、database_idはダッシュボードの一覧にあるUUIDを記入します。その上のbindingは自分で決められます。ここではDBとしていますが、Workersで動かすコードの中では、env.DBと書けばこのD1データベースに接続できるようになります。準備はこれで終わりです。

データベースから読み取るコードの例は次のようになります。

export default {
  async fetch(request, env) {
    // D1：SQLを実行する
    const { results } = await env.DB.prepare(
      "SELECT title FROM articles WHERE published = 1 LIMIT 10"
    ).all();

    const res = results.map((result) => {
      // レスポンスを整形する処理
    });

    return Response.json({ res });
  },
} satisfies ExportedHandler<Env>;

ダッシュボードからバインディングを確認する

wrangler.jsoncにバインディングを追加してデプロイすると、ダッシュボードのWorkersのページからもバインディングが確認できるようになります。Workersの「概要」欄右側にもバインディングが出てきますし、タブで「バインディング」を選択すると、より詳しい情報が確認できます。

なお、「バインディング」のUIには「バインディングを追加」のボタンもありますし、下部にあるリストでは編集や削除もできるようになっています。ここで何かしら変更を行ったとしましょう。その後にwrangler.jsoncを変更しないままデプロイすると、wrangler.jsoncの内容で上書きされ、ダッシュボードでの変更は元に戻ってしまいますので注意が必要です。

筆者は、バインディングなどの設定は常にwrangler.jsoncで管理し、Gitで履歴を追跡できるようにしておくのが一番よいと考えています。ダッシュボードは確認用とし、UIでの編集は行わないという方針です。

Cloudflareのさまざまなサービス

前節ではデータベースのD1を例にしましたが、CloudflareにはほかにもWebサイト・アプリケーションに有用なサービスがあります。

KV

Workers KVは、キーと値だけを扱うストアです。公式ドキュメントでも、APIレスポンスのキャッシュ、ユーザーの設定や環境設定の保存といった、読み取りの多い用途が挙げられています。書き込みに関しては、更新した値がすぐに全世界のエッジに反映されるわけではない、という特徴があります。

KVについては、以前にCodeGridでも紹介しています。

• Workers KV | サーバーレス実行環境Cloudflare Workers

D1

D1は、SQLiteのSQLをそのまま使えるサーバーレスのデータベースです。ブログの記事データやユーザーの情報など、テーブル構造のデータであれば素直にD1を使うのがよいと思います。

CodeGridで取り上げたTurso CloudもSQLベースで類似点がありますが、Cloudflare Workersから使い、Tursoの特徴であるマルチテナントなどが不要ということであれば、バインディングで接続できるD1のほうが使いやすいのではないかと考えます。

R2

R2は、前回のNext.jsのSSRアダプターのところでも出てきましたが、オブジェクトストレージです。Next.jsのデプロイではキャッシュデータを置いていましたが、格納できるデータの種類には特に制約はありません。

よくある使い方としては、Webサイト用の画像置き場だったり、バックアップデータを期限付きで置いたり、といったところでしょうか。多くの画像を扱うWebサイトや、ユーザーがファイルをアップロードするようなサービスでは、Gitリポジトリ以外にこうしたデータ置き場が必要なことも多いでしょう。

その他のサービス

Cloudflareには数十のサービスがあり、追加や更新も頻繁なので、チェックしてみると興味深いです。Workers AIという、Workersから直接呼び出せるAIモデルの実行環境や、Queuesというバックグラウンド処理のためのキュー、Durable Objectsというリアルタイム性のあるストレージ（チャットやGoogle ドキュメントのような同時編集が必要なデータのバックエンドに適しています）など、目的によっては強力な選択肢になりそうなサービスが展開されています。

// 前後省略
"services": [
  {
    "binding": "INPUT_PROCESSOR",
    "service": "input-processor",
    "entrypoint": "InputProcessor"
  }
]

const text = await env.INPUT_PROCESSOR.sanitize(input);

Workersのログ

さて、バインディングと並んで、Cloudflare Workersの便利な機能がObservability、つまり「ログ」の閲覧です。これはCloudflare Pagesにはない機能です。ログの設定もwrangler.jsoncに記述するか、ダッシュボードから行います。バインディングと同様に、ダッシュボードからの設定はデプロイ時にwrangler.jsoncの内容で上書きされますので気をつけてください。

ログとトレース

ダッシュボードのタブメニューにある「Observability」がログです。ここではconsole.log()の出力やリクエストの記録を閲覧・検索できます。エラーの発生率も一番上にグラフで表示されるのでわかりやすいです。また、ログ出力が不要であればオフにすることもできます。ログに記録されるのは、Workerへのアクセスごとのリクエストやレスポンスの情報、処理が正常に終わったかどうか、コード内にあるconsole.log()の出力、エラーなどです。HTTP以外の経路でのWorkerの実行（ほかのWorkerからの呼び出しやcronによる定期実行など）も同様にログに残ります。

wrangler.jsoncでログに関する設定をするには、observabilityというキーに記述します。

{
  "observability": {
    "enabled": true,
    "head_sampling_rate": 1 // 1 = 100%のリクエストを記録
  }
}

head_sampling_rateは記録するリクエストの割合で、1が100%です。デフォルトでは1ですが、ここを0.1にすれば10%だけ記録されます。Workersのログは、無料プランでは1日20万件までしか記録できず、それ以上は強制的に間引かれてしまいます。なお、有料プランでも月に2000万件を超えると課金されますので、アクセスが多いサイトでは、最初からサンプリングの指定をしておくとよいでしょう。また、ログの保持期間も、無料プランで3日、有料プランで7日なので、時間が経過すると閲覧はできません。

つまり、ログは全部が残るとは限らず、残ったとしても数日で消えます。このログの使いどころは「今、何かおかしくなっていないか」を見ることです。エラーレートを確認する、エラーになっているリクエストを追いかけて原因を掴む、といった監視やデバッグの用途ですね。アクセス解析のような、過去1年のページビューを数える、といった目的には向きません。

• Workers Logs | Cloudflare Docs

また、Observabilityにはログのほかにトレースの機能もあります。トレースはWorkerの処理をたどるためのもので、リクエストを受けたWorker自体の処理だけでなく、バインディング経由のKVやD1の操作なども自動で記録されます。コード内に任意の計測処理を埋め込むこともできます。

記録されるデータは、OpenTelemetryという規格に準拠したフォーマットなので、外部のサービスにエクスポートしてグラフなどを閲覧することもできます。トレースは執筆時点（2026年9月）では無料ですが、10月1日から課金が開始されると発表されていますので、アクセスの多いサービスで有効にする際には、サンプリングも併せて指定しておくのがよいでしょう。

• Traces | Cloudflare Docs

アクセス集計のためのAnalytics Engine

ログやトレースではなく、すべてのアクセスの統計データが欲しいというケースもあるでしょう。そのためのサービスがWorkers Analytics Engineです。こちらはD1やKVと同様に、バインディングとして接続できます。Workerのコード上の任意の場所から、自由にデータを書き込めます。データは3ヶ月間保持され、SQLで集計できます。

Analyticsという名前から、Google Analyticsのようなアクセス解析ツールを連想するかもしれませんが、こちらはユーザーの行動や特性を分析するというよりは、アクセスごとに必要なデータを淡々と蓄積するというイメージです。

たとえば、アクセス元のホスト名とどのようなパラメーターでリクエストしてきたかを記録しておき、アクセス数に応じて課金する、といった使い方が紹介されています。Analytics Engineも執筆時点では無料で使えますが、公式のドキュメントには料金表が掲載されているので、いずれは課金が開始されるかもしれません。

おわりに

今回は、WorkerからCloudflareのほかのサービスを使う方法を紹介してきました。Webサービスのバックエンドに活用できるさまざまなサービスがCloudflare内で完結するというのは、VercelやNetlifyにはない特徴です。

AWS/GCP/Azureといったクラウドサービスほどの規模感ではありませんが、フロントエンドをメインでやってきたエンジニアがWebサービスを作る、という場合には、むしろCloudflareのサービスをいくつか繋ぎ合わせる、というのがちょうどよいと筆者は感じています。

シンプルなWebサイトのホスティングから、バックエンドを伴ったサービス構築まで、Cloudflare Workersを軸にぜひ触ってみてください。