みんなで使えるデータ共有型WebアプリをCloudflareで作るための基礎知識

Pages + Pages Functions + D1 構成ガイド

チャット機能やランキング機能など、「データを保存・共有する」Webアプリを個人で作りたい場合、ネット上にデータベースが必要になる（参考）。 友達や同僚みんなが使えるWebアプリには、誰かが入力したデータをサーバー側で保存し、ほかの人からも見られるような仕組みが欠かせない。

この文書では、そのようなWebアプリを個人・小規模で作るためにおすすめの構成を紹介する。構成の全体像と、それぞれの役割を理解することが目的。実際の設定手順や導入方法は、別途ハンズオン資料（D1W）で説明する。

データ共有型Webアプリを構成する3つの要素

Webアプリは「フロントエンド」「バックエンド」「データベース」の3つの役割に分けて作るのが基本。レストランに例えるとわかりやすい。

3つの役割

レストランの例	Webアプリの役割
客席・メニュー・フロアスタッフ（お客さんが見て触り、注文を仲介する）	フロントエンド（画面・UI）
キッチン・料理人（注文を受けて料理を作る）	バックエンド（API）
冷蔵庫・食材庫（材料を保管する場所）	データベース（データ保存）

お客さん（ユーザー）はフロアスタッフ（フロントエンド）を通じて注文する。注文は料理人（バックエンド）が受け取り、冷蔵庫（データベース）から必要な食材（データ）を取り出して料理を作る。できあがった料理はフロアスタッフによってお客さんに届けられる。お客さんが冷蔵庫を直接触ることはない。これがセキュリティと役割分担を実現している設計。

ブラウザからのアクセスは以下の順番で処理される：

1. ユーザーがブラウザでURLにアクセス
2. フロントエンドがHTML/CSS/JSを返す（画面表示）
3. 画面からAPIリクエストがバックエンドへ送られる
4. バックエンドがデータベースを参照・更新して結果を返す

Cloudflareでの推奨構成：Pages + Pages Functions + D1

Pages・Pages Functions・D1はいずれもCloudflareのサービス。この3つの組み合わせが、個人・小規模でDBを使うWebアプリを作るのにシンプルで扱いやすい構成。

Webアプリの役割	Cloudflareのサービス
フロントエンド（画面・UI）	Cloudflare Pages
バックエンド（API）	Cloudflare Pages Functions
データベース（データ保存）	Cloudflare D1

Pages Functionsは「バックエンド的な役割」を担うが、独立したサーバーが別に存在するわけではない。Pages（フロントエンド）の中に処理が同居しているイメージ。フロントとAPIが一体化しているのがこの構成の特徴。ワンオペ営業の小規模飲食店のようなもの。

デプロイは wrangler での直接デプロイ、または Git連携・GitHub Actions による自動デプロイで行う。自動デプロイでは push をきっかけに Pages・Pages Functions が反映される（D1 マイグレーションは wrangler・Git連携方式は手元から、GitHub Actions 方式はワークフローに含めて自動実行）。

詳細は以下のいずれかを参照：

• デプロイ方式の入門（自動デプロイ）: 応用編の CGT (Git連携) / CGA (GitHub Actions・アーカイブ)
• D1 を含む実装手順: D1W / D1A (GitHub Actions版・アーカイブ)

補足: Pages から Workers への移行の流れ

Cloudflare は2025年以降、開発者プラットフォームの主軸を Cloudflare Workers に集約していく方針を打ち出している。Workers Static Assets により静的サイト配信も Workers 側で扱えるようになり、Pages の担っていた領域を Workers が取り込みつつある。

ただし Pages は廃止されておらず、継続サポート が明言されている。既存の Pages プロジェクトをすぐに移行する必要はなく、本サイトのハンズオンも初学者向けの取り回しのよさから Pages + Pages Functions + D1 の構成で進めている。

両者の関係と使い分けの詳細は WVP（Workers と Pages どちらを使うか） にまとめている。