1 何を作るか|問い合わせフォームと管理画面の全体像
Cloudflare 入門コースの第1章です。7章かけて作る「問い合わせフォームと管理画面」の全体像と、Workers / D1 / R2 / Access のどれが何を引き受けるのかを整理します。Vercel・Supabase の各コースとの違いもここで示します。
このレッスンでわかること
このコースは、問い合わせフォームと、その受信を確認する管理画面を、ゼロから作って独自ドメインで公開するまでを7章で通します。第1章では実装をしません。何を作るのか、どの部品を使うのか、なぜその部品なのかを先に決めます。
- 7章を通じて完成するものの姿がわかる
- Cloudflare のどの製品が、題材のどの部分を引き受けるのかがわかる
- Vercel コース・Supabase コースと何が違うのかがわかる
**Web アプリを1本、自分の手で公開したことがない方は、まずこのコースから読んでください。**3コースのうち Cloudflare が主経路です。理由は後述します。
作るもの
2つの画面だけです。
| 画面 | 誰が使うか | できること |
|---|---|---|
| 問い合わせフォーム | 誰でも(認証なし) | 名前・メールアドレス・本文を送る。添付ファイルを1点付けられる |
| 管理画面 | 自分とチームだけ | 届いた問い合わせの一覧を見る。添付を開く。対応済みフラグを立てる |
小さく見えますが、Web アプリが持つ要素はひととおり入っています。
- 外部からの入力を受け取る(フォーム)
- 構造化されたデータを残す(データベース)
- 構造化されていないデータを残す(ファイル)
- 見せてよい相手を絞る(認証・認可)
- 本番として動かし続ける(ドメイン・環境・シークレット・費用)
**この5つが揃えば、たいていの業務アプリは同じ型で作れます。**題材が小さいのは、型を見えやすくするためです。
Cloudflare のどの部品を使うか
Cloudflare は製品が多く、最初は地図がないと迷います。このコースで触るのは4つだけです。
| 部品 | 役割 | 章 |
|---|---|---|
| Workers | リクエストを受けて HTML と JSON を返す。アプリ本体 | 第2〜3章 |
| D1 | SQLite ベースのデータベース。問い合わせ1件を1行として残す | 第4章 |
| R2 | オブジェクトストレージ。添付ファイルの実体を置く | 第5章 |
| Cloudflare Access | 管理画面の手前に立つ認証の壁 | 第6章 |
残りの製品(KV / Durable Objects / Queues / Workers AI など)は、この題材では使いません。**必要になっていない機能を先に足さないのが、最初の1本を完成させるコツです。**製品ごとの全体像が知りたくなったら、Cloudflare リファレンスを後から引いてください。
なぜ Pages ではなく Workers なのか
Cloudflare には、静的サイト向けの Cloudflare Pages という製品もあります。**2026-08 時点では、新規プロジェクトは Workers で始めるのが公式の案内です。**Pages の概要ページには “Workers supports most Pages use cases and offers a broader feature set. It is Cloudflare’s primary platform for building applications. Start new projects with Workers.” と書かれています。
Workers は静的ファイルの配信(Static Assets)も担当できるので、**「画面 + サーバー側の処理」を1つの Worker にまとめられます。**このコースでは、最小構成で通すために、ページの HTML も Worker が組み立てて返す形にします。ビルド設定を覚えずに済み、どこで何が起きているかが読みやすくなります。
Workers は Node.js の API が使えないのでは、という疑問について
古い記事にはそう書かれていることがあります。2026-08 時点では前提が変わっています。
Cloudflare の互換性フラグのドキュメントには “For compatibility dates of 2026-08-04 or later, Workers and Pages projects enable both nodejs_compat and nodejs_compat_v2 by default.” とあります。つまり compatibility_date を 2026-08-04 以降にしておけば、Node.js 互換は自動で有効です。第2章で作るプロジェクトはこの条件を満たします。
実例:1件の問い合わせが通る道
完成後、送信ボタンが押されてから管理画面に出るまでに何が起きるかを追います。これが7章分の地図です。
[訪問者]
│ ① フォームを開く
▼
[Workers] ── 静的な HTML を返す
│ ② 名前・本文・添付を POST
▼
[Workers] ── 入力を検証する
├─ ③ 添付の実体を R2 に置く(キーを受け取る)
└─ ④ 名前・本文・R2 のキーを D1 に 1 行 INSERT
│
▼ ⑤ 「送信しました」を返す
[担当者]
│ ⑥ /admin を開く
▼
[Cloudflare Access] ── 許可されたメールアドレスか判定
│ 通った場合だけ
▼
[Workers] ── D1 から一覧を SELECT、添付は R2 から取り出して返す
ここで押さえてほしいのは ③と④が分かれていることです。
**ファイルの実体はデータベースに入れません。**R2 に置いて、D1 には「どこに置いたか」を示すキーだけを残します。理由は第5章で扱いますが、先に一言だけ書いておくと、データベースは行を読むたびに課金・上限の対象になるため、数MBのバイナリを行に埋めると読み取りが重くなるからです。
3コースの違い
同じ題材を Vercel コース・Supabase コースでも作ります。同じ課題を別の道具で解くと、道具の性格が見えます。
| 課題 | Cloudflare(本コース) | Vercel コース | Supabase コース |
|---|---|---|---|
| アプリの実行 | Workers | Next.js / Vercel Functions | 任意のホスティング + Edge Functions |
| データの保存 | D1 | 外部のデータ層を組み合わせる | Postgres |
| ファイルの保存 | R2 | 外部のストレージを組み合わせる | Storage |
| 管理画面の保護 | Cloudflare Access | Deployment Protection | Auth + RLS |
| 一般ユーザーのログイン | このコースでは扱わない | 扱わない | 扱う |
最後の行が3コースの分かれ目です。**Cloudflare Access は社内向けの仕組みで、不特定多数のユーザー登録には使えません。**この線引きは第6章の中心テーマにします。一般ユーザーがログインするアプリを作りたい方は、本コースを終えたあとに Supabase 入門コースへ進むのが近道です。Next.js のエコシステムに寄せたい方は Vercel 入門コースを見てください。
このコースを主経路にしている理由
3つあります。
**1. 1つのアカウントで最後まで行ける。**アプリ・データベース・ファイル・認証・ドメインが同じダッシュボードに揃っています。最初の1本では、サービスをまたぐ設定が減るほど完走率が上がります。
**2. 小規模なら無料枠に収まる。**2026-08 時点の各サービスの無料枠は次のとおりです。
| サービス | Free プランの主な枠 |
|---|---|
| Workers | 1日あたり 100,000 リクエスト、1呼び出しあたり CPU 時間 10 ミリ秒 |
| D1 | 読み取り 500万行/日、書き込み 10万行/日、ストレージ合計 5 GB、DB 10個まで |
| R2 | ストレージ 10 GB-month/月、Class A 操作 100万/月、Class B 操作 1,000万/月。外向きの転送料(エグレス)は無料 |
社内の問い合わせ窓口くらいの規模なら、かかるのはドメイン代だけという状態から始められます。第7章で費用の見方を扱います。
**3. 覚える概念が少ない。**Workers は「リクエストを受け取って Response を返す関数」がすべてです。フレームワークの規約を先に覚える必要がありません。
一方で、向いていない場面もあります。大きな npm パッケージに強く依存するアプリ、長時間かかるバッチ処理、既存の Postgres 資産をそのまま活かしたいケースは、素直に別の選択肢を見たほうが早いことがあります。
これから7章でやること
| 章 | やること | 手を動かす時間の目安 |
|---|---|---|
| 1 | 全体像を決める(この章) | 20分 |
| 2 | アカウントと Wrangler を用意し、ローカルで動かす | 40分 |
| 3 | 初回デプロイ。URL が返るところまで | 35分 |
| 4 | D1 にテーブルを作り、送信内容を残す | 60分 |
| 5 | R2 に添付を保存し、安全に取り出す | 60分 |
| 6 | Cloudflare Access で管理画面を守る | 50分 |
| 7 | 独自ドメイン・環境分離・シークレット・費用 | 55分 |
**各章は前章の成果物の上に積みます。**飛ばして読むと動きません。時間がない日は、章の中の「やってみよう」だけを先に眺めて、次に開くときの目印にしてください。
やってみよう
この章では手を動かす代わりに、**決めることを決めます。**紙でもメモアプリでもかまいません。
- 題材を自分の文脈に置き換える。「問い合わせ」を、実際に自分が欲しいもの(社内の備品申請、イベント参加登録、不具合報告)に読み替えてください。項目名が変わるだけで、構造は同じです
- **保存する項目を書き出す。**名前・メール・本文・添付。ここに1〜2個だけ足すなら何かを決めます。**足しすぎないでください。**第4章でテーブルを作るときにそのまま使います
- **管理画面を見る人のメールアドレスを列挙する。**自分の分だけでもかまいません。第6章の Access ポリシーでそのまま使います
- **Cloudflare アカウントを持っているか確認する。**なければ第2章で作ります。持っている場合は、どのメールアドレスで作ったかを思い出しておいてください
3番目を今のうちに決めておくと、第6章で迷いません。「誰に見せるか」は技術ではなく運用の決定なので、先に決めておくほど後が楽です。
まとめ
- 作るのは問い合わせフォームと管理画面の2画面。小さいが、Web アプリの要素は5つとも入っている
- 使う部品は Workers / D1 / R2 / Cloudflare Access の4つだけ。ほかの製品は必要になるまで足さない
- 2026-08 時点、新規プロジェクトは Pages ではなく Workers で始めるのが公式の案内
compatibility_dateが 2026-08-04 以降なら、Node.js 互換は既定で有効。「Workers では Node.js の API が使えない」は古い前提- ファイルの実体は R2、その所在を示すキーは D1 と役割を分ける
- Cloudflare Access は社内向け。一般ユーザーのサインアップには使えない(第6章で詳述)
- 小規模なら無料枠に収まり、かかるのはドメイン代だけという状態から始められる
理解度チェック
Q1. 添付ファイルの実体を D1 ではなく R2 に置くのはなぜでしょう?
- D1 はバイナリを保存する機能を持っていないから
- R2 のほうが保存できる容量が大きく、行の読み取りを重くせずに済むから
- R2 に置いたファイルは自動的に暗号化されるから
- D1 に置くと Workers から読み出せないから
答えを見る
正解:2
D1 の課金と上限は「読み書きした行数」と「ストレージ量」で決まります。数MBのバイナリを行の中に持たせると、一覧を表示するだけで重い行を読むことになります。R2 は 10 GB-month/月まで無料で、外向きの転送料もかかりません。構造化データは D1、バイナリは R2 という分担が素直です。なお、D1 に BLOB を保存すること自体は可能なので、1と4は誤りです。
Q2. 「Workers では Node.js の API が使えない」と書かれた記事を見つけました。2026-08 時点ではどう考えるべきでしょう?
- 今もそのとおりなので、ブラウザ互換の API だけで書く
compatibility_dateが 2026-08-04 以降ならnodejs_compatは既定で有効なので、前提が変わっている- 有料プランに切り替えると使えるようになる
- Pages に移せば使えるようになる
答えを見る
正解:2
Cloudflare の互換性フラグのドキュメントに、compatibility date が 2026-08-04 以降のプロジェクトでは nodejs_compat と nodejs_compat_v2 の両方が既定で有効になると明記されています。プランの違いではありません。Cloudflare のドキュメントは変更が速いため、記事の日付と compatibility_date の値をセットで確認する習慣が要ります。
参考リンク
- Cloudflare Pages の概要 — 新規プロジェクトを Workers で始めるよう案内している箇所
- Workers の互換性フラグ —
nodejs_compatの既定有効化について - Workers の料金
- D1 の料金
- R2 の料金