Claude Codeでデータ共有型Webアプリを作ってCloudflareに公開する

ここまでのハンズオンでは一人完結型Webアプリを公開した。今回はその先として、データベースを使ってみんなで使えるWebアプリを作る。データを保存・共有できると、できることが一気に広がる。

今回のハンズオンでは、データ共有型Webアプリ（参考）を作って、Cloudflare に公開する。公開のしかたは wrangler で直接デプロイする方法 と Git連携で自動デプロイする方法 の2通りを用意したので、好きな方を選べる。

本記事の位置付け

データを共有する Web アプリを作って公開したいなら、こんなざっくりとした依頼でも進められる：

Claude

みんなが書き込める掲示板アプリを作って公開したい

Claude Code は使いたいサービスや構成などを聞きながら、最終的にアプリの実装からデプロイまで案内してくれる。ただし、その過程で取る道は人によって違う。

本記事では、その中で Cloudflare D1 + Pages Functions を使ったデータ共有型アプリ を、つまずきにくい順序で作って公開する。公開の段では wrangler で直接デプロイする方法（ケース1） と GitHub に置いて Git連携で自動デプロイする方法（ケース2） の両方を案内する。

1. このハンズオンの全体像

1-1. 作るもの：匿名一行掲示板

このハンズオンではサンプルとして、匿名一行掲示板を作っていく。
仕様：

• 名前の入力不要。書き込むだけで投稿できる
• 書き込んだ人には自動的に「会員1号」「会員2号」と番号が割り振られる
• 同じブラウザから書き込むと、次回以降も同じ会員番号が使われる
• みんなの投稿を一覧表示する

匿名一行掲示板 作例（触ってみる）

▶ 完成版を触ってみる: bbs-sample.vibecodingnotes.com：この章で作る掲示板の完成版。実際に書き込んで動きを確かめられる（デモのため、投稿は予告なくリセット・削除することがある）。

1-2. 全体構成の復習

このハンズオンで使う構成を整理しておく（詳細はCloudflare構成ガイド）。

役割	Cloudflareのサービス
フロントエンド（画面・UI）	Cloudflare Pages
バックエンド（API処理）	Cloudflare Pages Functions
データベース	Cloudflare D1

この構成を念頭に置いて進めると、「今何をやっているのか」がわかりやすくなる。
本ハンズオンは大きく3段階に分かれる：

• 準備：作業フォルダを用意し、Wrangler のログインを確認して Claude Code を起動する
• 実装：D1データベース → スキーマとマイグレーション → wrangler.jsonc（D1 と Pages を結びつける設定）→ Pages Functions（バックエンド）→ フロントエンド、の順に作る
• 公開：本番環境にコードをデプロイする。本番DBにマイグレーションを適用する

1-3. 本番に反映する2つの流れ：デプロイとマイグレーション

公開のときに意識したいのは、手元の変更を本番に反映する作業が2種類あり、呼び名も反映のしかたも違うこと。まとめれば「本番反映」だが、中身は次の2つに分かれる。

手元（ローカル）の変更  →  本番に反映する（本番反映）
   ├ コード（画面・API）  →  デプロイ（今の状態で丸ごと置き換える）
   └ DBのスキーマ        →  本番DBへのマイグレーション適用（変更を1回だけ足す）

• コード（フロントエンド・API）：Cloudflare にデプロイして公開する。やり方は2通り。ケース1は wrangler で手元から直接デプロイ、ケース2は GitHub に push して Git連携で自動デプロイ。8章まで作ったら好きな方を選ぶ
• DBのスキーマ：手元から本番DB（--remote）にマイグレーションを適用する。どちらの公開方法でも共通で、自動では反映されないので手動で行う

コードのデプロイは今のファイルで丸ごと置き換える作業なのに対し、マイグレーションはDBの中のデータを残したまま構造だけを少しずつ変えていく。丸ごと入れ替えたらデータが消えてしまうので、DBは置き換えではなく差分の適用になる。

2. 事前準備

2-1. ベース名を決める

このアプリでは、作業フォルダ・D1データベース・プロジェクト・GitHubリポジトリの4つに名前を付ける。これらの名前は 自分のアカウント内で重複できない（Pages プロジェクト名だけは Cloudflare 全体で一意）。前に作ったものと同じ名前を一箇所でも使うとそこで衝突してうまくいかない。

そこで最初に、自分だけの ベース名 を1つ決めておく。

• 例: bbs-yto（イニシャル）、bbs-0629（日付）など、他と被らなそうなもの
• 短く・英小文字と数字とハイフンだけにしておくと、そのまま全部の名前に使える

ベース名はそのまま 公開URL（https://<ベース名>.pages.dev）になる。すでに使われているとベース名の後ろにランダムな英数3文字が付くので、URL をきれいにしたい場合はブラウザで https://候補名.pages.dev を開いて空きを確認しておくとよい。「このサイトにアクセスできません」と表示されれば、その名前はまだ使われていない（空き）。逆に Cloudflare のエラー画面（522 や 1016 など）や「ページが見つかりません」などが出たら、その名前はすでに使われているので避ける。

候補の pages.dev を開いたときの表示例。「このサイトにアクセスできません」だけが空きで、ほか（522 / 1016 / 404）は使われている

この記事では、決めたベース名を <ベース名>、D1データベース名を <ベース名>-db と表記する（D1データベースだけは名前のうしろに -db を付ける）。次の 2-3 でこの名前を Claude に覚えさせるので、以降は <ベース名> と書いたプロンプトをそのまま Claude に渡せば、Claude が自分のベース名に展開して実行してくれる。

2-2. 作業フォルダを準備

Finder で ~/claude フォルダ（なければ作る）の中に、ベース名の作業フォルダを作る（例: my-bbs）。

2-3. Claude Codeを起動

Claudeデスクトップアプリを起動。

Code（Claude Code）を選択 → New session をクリック → 作業フォルダを指定（例: ~/claude/my-bbs）

セッションを始める前に、画面左下のモード選択を 編集を承認 にしておく（自動モード にしない）。自動モードだと Claude がファイルの変更やコマンドを確認なしで一気に進めてしまい、意図しない結果になる事故が起きやすい。まずは一つずつ承認しながら進めるのが安全。

セッションを開始したら、最初にベース名を Claude に覚えさせる。次のプロンプトは、先頭の my-bbs（1箇所だけ）を自分のベース名に置き換えて渡す。置き換えるのはこの1箇所でよい（D1データベース名は Claude が自動で -db を付けてくれる）。

Claude

このプロジェクトのベース名は my-bbs です。これを CLAUDE.md に記録してください。
- アプリ名・プロジェクト名・GitHubリポジトリ名 = ベース名
- D1データベース名 = ベース名のうしろに -db を付けた名前
これ以降、私のプロンプトの <ベース名> はベース名に、<D1データベース> は「ベース名-db」に読み替えて作業してください。

これでベース名が CLAUDE.md（プロジェクトの設定ファイル）に書き込まれる。CLAUDE.md は Claude が毎回読み込むので、会話が長くなっても名前を忘れない。以降のステップでは <ベース名> や <D1データベース> と書いたプロンプトをそのまま渡せば、Claude が自分の名前に展開してくれる。なお、ターミナルで直接実行するコマンド例は my-bbs のまま載せているので、ターミナルに入力する場合は自分のベース名に読み替える。

本記事は Claude Code を例に進めるが、Codex など他のコーディングエージェントでも同じプロンプトで進められる。以降、プロンプトを渡す相手をまとめて エージェント と呼ぶ。なお、エージェントが読み込む設定ファイルは Claude Code では CLAUDE.md、Codex では AGENTS.md。Codex を使う場合は、上のプロンプトの CLAUDE.md を AGENTS.md に読み替える。

2-4. Wranglerログイン状態の確認

Wrangler のログイン状態を確認する。Wranglerハンズオンを完了している場合、Node.jsとWranglerログインは済んでいるはず。

npx wrangler whoami

アカウント名やメールアドレスが表示されればOK。表示されない場合はWranglerハンズオンの1章を参照してインストール・ログインする。

3. 【データベース】D1データベースを作成（初回のみ）

D1データベースを作成する。エージェントに次のように頼む。<D1データベース> は 2-3 で覚えさせたベース名（<ベース名>-db）に展開される。

Claude

D1データベース <D1データベース> を作って

これがデータベースの名前になる。自分のアカウント内で過去に作った D1 データベースと同じ名前は使えないので、ベース名を一意にしておけば衝突しない。この名前は後の wrangler.jsonc（5章）でも使う。

「既に存在しています」エラーが出たら、ベース名を変えて作り直す。

ターミナルでやる場合: npx wrangler d1 create my-bbs-db を実行する（my-bbs は自分のベース名に読み替え）。

実行すると database_id が表示される。この ID は後の wrangler.jsonc 作成で使うので控えておく（エージェントに頼んでいれば、そのまま覚えていて使ってくれる）。

Database ID（database_id）：データベースの識別子。仮に外部に漏れても、API Tokenがなければ操作できないため問題なし。

4. 【データベース】スキーマ設計とマイグレーションファイル

エージェントにアプリの仕様を伝えてテーブル設計を相談する。

サンプルプロンプト（BBSの例）：

Claude

このアプリに必要なデータベースのテーブル設計を提案してください。

【匿名一行掲示板】
- 名前登録なし、初めて投稿したときに会員番号が払い出される（1, 2, 3...の連番）
- 同じブラウザから投稿した人には毎回同じ会員番号が使われるようにする
- 画面には「会員1号」「会員2号」と表示する
- 投稿内容は1行のテキスト

エージェントがテーブル設計（スキーマ）を提案してくれる。疑問があれば質問しながら内容を確認しよう。

スキーマ：データベースの構造定義のこと。どんなテーブルがあり、それぞれどんな列（カラム）を持つかを定めたもので、建物で言えば「設計図」にあたる。

納得したら、以下のように依頼する。

Claude

このスキーマでマイグレーションファイルを作成してください。
ファイルは migrations/0001_init.sql に保存してください。

migrations/0001_init.sql が生成される。

マイグレーション：データベースの構造変更（テーブルの作成・変更・削除など）をSQLファイルとして管理する仕組み。変更をファイルに記録しておくことで、「どの変更がいつ適用されたか」を追跡でき、本番環境への反映も自動化できる。設計図（スキーマ）が「何を作るか」なら、マイグレーションファイル（0001_init.sql）は「それをどう作るか」を記した、建物で言えば「施工手順書」にあたる。

スキーマを変更したいときは、0001_init.sql を書き換えるのではなく、変更内容をエージェントに伝えて新しいマイグレーションファイル（0002_...）を追加してもらう。本番DBへの適用は、デプロイの段階でまとめて行う。

5. wrangler.jsonc の作成

Pages プロジェクトの設定と、用意した D1 データベースとの結びつけ（バインディング）をまとめて行う設定ファイル。プロジェクト名や公開対象フォルダ（public/）といった Pages 側の設定に加え、バインディング（コードから env.DB で呼ぶ名前）をここで定義する。プロジェクト名には <ベース名>、データベース名には3章で作った <D1データベース> を使う。

サンプルプロンプト： 同じセッションで D1 を作成していれば、エージェントが database_id を覚えているので自動で記入してくれる（分からなくなった場合は d1 create で表示された ID を伝える）。

Claude

このプロジェクト用の wrangler.jsonc を作って。
Cloudflare Pages プロジェクトで、公開ディレクトリは public。
D1データベース <D1データベース> を binding 名 DB で使う。
マイグレーションは migrations フォルダ。
compatibility_date は今日の前日の日付にする。
database_id は d1 create で表示された値を入れる。

compatibility_date を前日にするのは、UTC 基準で「今日」が未来日と判定されてエラーになるのを避けるため。

できあがる wrangler.jsonc はこんな形になる（<ベース名>・<D1データベース>・ID は実際の値に置き換わる）。

{
  "name": "<ベース名>",
  "compatibility_date": "（YYYY-MM-DD 形式の昨日の日付）",
  "pages_build_output_dir": "./public",
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "<D1データベース>",
      "database_id": "（d1 create で表示されたID）",
      "migrations_dir": "migrations"
    }
  ]
}

バインディング（binding）：プログラムからD1データベースを呼び出すときの名前。"binding": "DB" としたので、APIのコードからは env.DB でデータベースにアクセスできる。コード上の名前（DB）と実際のデータベース（database_name / database_id）を結びつけるのがバインディングの役割。

"pages_build_output_dir": "./public" で公開対象を public/ 配下のファイルに絞る（wrangler.jsonc や migrations/ などのプロジェクトファイルが誤って公開されるのを防ぐ）。

6. 【バックエンド】Pages Functions（API）の作成

エージェントにアプリの仕様とスキーマを伝えて「APIを作成して」と依頼すると functions/api/xxxx.js を生成してくれる。リソース名（掲示板なら posts など）やどの操作が要るかは、先ほど設計したスキーマからエージェントが判断してくれる。

サンプルプロンプト：

Claude

スキーマ作成時に提示した仕様と、先ほど設計したスキーマを使って、Pages Functions で API を作って。
D1 の binding 名は DB。

1件ごとの取得・更新・削除が要るアプリなら、エージェントは functions/api/<リソース名>/[id].js のような動的ルートで作る（[id] は /api/posts/3 のような1件指定を受ける）。掲示板のように一覧と投稿だけなら functions/api/<リソース名>.js 1つで足りる。

DBを操作するAPIの実装は、業界標準的なパターンがほぼ決まっている。生成はエージェントに任せてよい。

ただし、できあがったコードが「どんなときに何を返すのか」は自分で把握しておくと、あとで動作確認したり修正を依頼したりするときに困らない。エージェントに「いま作ったAPIの動きを箇条書きで説明して。投稿が空のときや長すぎるときの扱いも教えて」と聞くのもよい。

7. 【フロントエンド】フロントエンドの作成

DB定義・API定義を会話の中で共有した後に依頼すると、それを踏まえたUIを生成してくれる。

サンプルプロンプト：

Claude

これまでのDB定義、API定義を参考に
フロントエンドを public/index.html として作成してください。

デザインの好みがあれば追加で伝える：

Claude

シンプルで読みやすいデザインにしてください。
スマートフォンでも使いやすいようにしてください。

8. ローカルで動作確認する

公開する前に、手元（ローカル）でアプリを動かして確認しておく。ここまでで作ったアプリは、デプロイ方式に関係なくローカルでそのまま動かせる。

ローカルでは本番DBではなくローカル用のD1を使う。エージェントに、ローカルD1へのマイグレーション適用とローカルサーバー起動をまとめて頼む。

Claude

本番DBではなくローカルのD1で動作確認したい。
ローカルのD1にマイグレーションを適用してから、ローカルサーバーを起動して

「ローカルで確認したい」とだけ伝えると、マイグレーションのローカル適用が抜けてテーブルが無いまま起動することがある。「ローカルのD1に適用してから」まで含めると確実。

起動するのは wrangler pages dev（Pages Functions と D1 も動く Wrangler 内蔵サーバー）。python -m http.server のような静的サーバではバックエンドとDBが動かず、このアプリは正しく動作しない。

起動したら指定されたURL（http://localhost:8788 など）をブラウザで開いて動作確認する。

ターミナルでやる場合: まず npx wrangler d1 migrations apply my-bbs-db --local でローカルD1にテーブルを作り、その後 npx wrangler pages dev を起動する（my-bbs は自分のベース名に読み替え）。

9. 【ケース1】wrangler で直接公開する

ここから公開に入る。公開のやり方は2通りあり、まずは GitHub の用意がいらず最短で公開できるケース1（wrangler で直接デプロイ）から見ていく。継続的に育てたいなら次章のケース2（Git連携）を選ぶとよい（両方試してもよい）。

	【ケース1】wrangler で直接公開	【ケース2】Git連携で公開
GitHub	不要	必要
デプロイ	wrangler pages deploy を手元から実行	push で自動
変更履歴・ロールバック	Cloudflare のデプロイ履歴のみ	GitHub＋Cloudflare に残る
向き	まず公開したい・お試し	継続的に育てるアプリ

なお、本番DBへのスキーマ適用はどちらの方法でも必要。この章（ケース1）では、その適用とデプロイをまとめてエージェントに頼む。

8章のローカル動作確認まで終えていれば、GitHub アカウントやリポジトリを用意しなくても、wrangler で直接デプロイして公開できる。最初の公開までの手数が少ないのが利点。

Claude

本番DBにマイグレーションを適用してから、wrangler で Cloudflare に直接デプロイして

「デプロイして」とだけ伝えると本番D1へのマイグレーション適用が抜けて、画面は出るのに投稿でDBエラーになることがある。「本番DBにマイグレーションを適用してから」まで含めると確実。

やっていることは2つ。①本番D1にスキーマ（マイグレーション）を適用する（初回とスキーマ変更時に必要）、②wrangler.jsonc の pages_build_output_dir（./public）を読んで Direct Upload でデプロイする（functions/ の Pages Functions は自動でバンドルされ、D1 binding（env.DB）も反映される）。初回は Pages プロジェクト名やブランチを聞かれるので <ベース名> などと答える。

ターミナルでやる場合:

npx wrangler d1 migrations apply my-bbs-db --remote
npx wrangler pages deploy

（my-bbs は自分のベース名に読み替え。初回は Pages プロジェクト名やブランチを聞かれる）

デプロイ完了後、表示されたURL（https://<ベース名>.pages.dev）にアクセスして動作確認する。これでケース1の公開は完了。継続的な開発のために Git連携も使いたい場合は次章のケース2へ、そうでなければ「11. 修正と反映」へ進む。

10. 【ケース2】GitHub に置いて Git連携で公開する

GitHub にコードを置き、Cloudflare Pages と Git連携すると、push するたびに自動でビルド・デプロイされる。継続的にアプリを育てるのに向く。この章では「① 初回push → ② 本番DBにスキーマを適用 → ③ Git連携を設定して初回デプロイ」の順に進める（すでにケース1で公開した人も、同じアプリを GitHub 経由で公開し直せる）。

10-1. 初回push

ここまでに作ったコードを、GitHub のリポジトリにまとめて push する。Cloudflare で Git連携を設定するときに main ブランチを指定する必要があるため、先に GitHub 側にリポジトリと main ブランチを作っておく。

gh の認証がまだの場合はGit と GitHub の基本を参照。

GitHub の MCP プラグインはオフにしておく: Claudeデスクトップアプリの 設定 → カスタマイズ → プラグイン にある Github（GitHub 公式 MCP サーバ）をインストールしていると、Claude Code が gh・ローカルの git ではなく GitHub API 経由で操作してしまい、手順どおりに進まないことがある。本ハンズオンは gh に統一するので、入れている場合は無効化しておく（詳しくは GBA 4章 を参照）。

push前に .gitignore の設定。プロジェクトに作られる .wrangler/ フォルダ（ローカル状態のキャッシュ）はコミット不要なので、.gitignore に追加しておく。

Claude

.gitignore に .wrangler/ を追加して

続けて、リポジトリを作成して push する。エージェントに次のように頼めば、git init からコミット・リポジトリ作成・push までまとめてやってくれる。

Claude

GitHubに非公開のリポジトリ <ベース名> を作って、今のフォルダの内容をpushして

初期ブランチは main にしておくと、Cloudflare 側の Production branch 指定（main）と揃う（上のプロンプトならエージェントが main で作ってくれる）。

ターミナルでやる場合（→ GBA 4-5）：

git init -b main
git add -A
git commit -m "initial"
gh repo create my-bbs --private --source=. --remote=origin --push

gh repo create --source=. --push はローカルのコミットを GitHub の新規リポジトリに上げるコマンド。先に git init でリポジトリ化し、コミットを1つ作ってから実行する（コミットが無いと push しても中身が上がらない）。git init -b main で初期ブランチを main にしておく（my-bbs は自分のベース名に読み替え）。

これで GitHub にコードと main ブランチが反映された。

10-2. 本番DBにスキーマを適用する

Git連携方式では migration が自動では適用されない。次の Save and Deploy で本番のアプリが動き出す前に、手元から本番DBにスキーマを反映しておく（適用しないと、画面は出るのに投稿でDBエラーになる）。エージェントに次のように頼む。

Claude

本番（リモート）のD1にマイグレーションを適用して

未適用のマイグレーションファイルだけが本番DBに適用される。

「マイグレーションを適用して」とだけ伝えるとローカルD1に適用されることがある。「本番（リモート）の」まで含めると確実。

このコマンドは wrangler.jsonc を読むので、プロジェクトフォルダ（<ベース名>）内で実行する必要がある。エージェントなら最初からそのフォルダで動いている。

ターミナルでやる場合: npx wrangler d1 migrations apply my-bbs-db --remote を実行する（my-bbs は自分のベース名に読み替え）。

10-3. Git連携を設定して初回デプロイ

リポジトリを Cloudflare に連携する。Cloudflare ダッシュボード を開き、左メニューの Compute → Workers & Pages をクリック、右上の Create application をクリック。

下にある目立たない Looking to deploy Pages? の Get started をクリック。

次の画面で Import an existing Git repository の Get started をクリック。初回は GitHub との連携承認を求められる。詳しい手順は CGT (Git連携) を参照(リポジトリ名は <ベース名> に読み替え)。

リポジトリ一覧から自分のリポジトリ（<ベース名>）を選び、Begin setup をクリック。

Set up builds and deployments のページが開く。設定するのは以下：

• Project name に自分のベース名（例: my-bbs）を入れる。公開URLの一部になる（https://<ベース名>.pages.dev）

入力欄の直下に割り当てられるURLが表示される。<ベース名>.pages.dev のように入力した名前がそのままならば競合なし。競合する場合には区別するための文字列が付く。別の名前に変えてもよい。

• Production branch に main を選択
• Build output directory に public を入力：wrangler.jsonc の pages_build_output_dir と同じ場所

その他（Build command、Root directory など）は空欄のまま。functions/ 配下の Pages Functions と wrangler.jsonc の D1 binding は Cloudflare が自動で認識する。

Save and Deploy をクリック。Cloudflare が GitHub からコードを取得してビルド・デプロイを実行する。ダッシュボードの Deployments で進行状況を確認できる。

デプロイ完了後、表示されたURLにアクセスして動作確認する。

11. Webアプリの修正と反映

修正依頼プロンプト例:

Claude

ユーザーごとに投稿の背景色を変えてほしい

途中、操作の許可を求めてくることがあるので対応する。

修正をローカルで確認したいときは、「ローカルで動作確認する」章と同じ手順（手元のD1への適用＋ローカルサーバー）で試せる。

納得したら本番へ反映する。反映のしかたは選んだ公開方法による。

• ケース1（wrangler直接）: 「wrangler で Cloudflare に再デプロイして」と頼む（npx wrangler pages deploy を実行し直す）
• ケース2（Git連携）: 「コミットしてpushして」と頼む。Cloudflare が push を検知して自動デプロイする

しばらく待ってから公開URLにアクセスして確認。

修正例：投稿者（会員番号）ごとに投稿の背景色が変わった

スキーマ変更を伴う修正もできる。例えば、投稿者が名前を設定して投稿に表示できるようにする場合：

Claude

投稿者が名前を設定できるようにして、投稿に会員番号と一緒に名前も表示してほしい

このような修正では、テーブルに列を追加するための新しいmigrationファイル（0002_...）が追加される。この場合、コードのデプロイだけでは本番に反映されない。デプロイで反映されるのはコード（Pages・Pages Functions）だけで、本番DBのスキーマは変わらないため。スキーマ変更時は次の2つをセットで行う：

1. npx wrangler d1 migrations apply my-bbs-db --remote を手元から実行して本番DBに反映する（どちらのケースでも共通）
2. コードを本番へ反映する（ケース1なら再デプロイ、ケース2なら「コミットしてpushして」）

このように修正と反映を繰り返して、Webアプリを仕上げよう！

なお、コードの修正だけでなく本番DBのデータ操作もエージェントに頼める。不適切な投稿を消したいときは、管理画面を作らなくても次のように頼めばよい。

Claude

不適切な投稿があるので、◯◯の投稿を削除して

エージェントが wrangler d1 execute（... --remote --command "DELETE FROM ..."）で本番DBを直接操作してくれる。デモや個人運用なら、これで管理は十分なことが多い。わざわざ管理画面を作らなくても、手元のエージェントが管理コンソール代わりになる。

12. 次のステップ

DB付きの掲示板アプリが公開できた。投稿の削除程度ならエージェントで十分。ただし「自分以外が運営する」「スマホから手早く管理する」「複数人で管理する」となると、ブラウザから使える管理画面が欲しくなる。次のハンズオンで、認証付きの管理画面を追加する。

• Claude CodeでWebアプリに管理画面を追加してBasic認証でアクセス制限する：投稿の表示/非表示を切り替えられる管理画面を追加し、Basic認証でアクセス制限を設ける

補足: 練習用Webアプリ案

匿名一行掲示板以外に、練習で何か作ってみようというときの案をいくつか。どれも D1（データ共有）を使うお題なので、本記事の構成をそのまま流用できる。4. スキーマ設計のステップで、掲示板のプロンプトの代わりに次のいずれかをエージェントに投げれば、別のアプリとして作り始められる（以降の章も同じ流れで進む）。

二択でみんなの好みを決めるアンケート。

Claude

このアプリに必要なデータベースのテーブル設計を提案してください。

【あなたはどっち派？二択アンケート】
「あなたはキノコとタケノコどちらが好きですか」という問いに対して、どちらかを選ぶ。
何かしらの絵文字が払い出されて、回答者のアイコンとなる。
選んだ側にカウントされ、選んだ側のエリアにその絵文字が表示される。
一人一選択。
あとから選び直すことが可能。

連打速度を競うミニゲーム＋ランキング。

Claude

このアプリに必要なデータベースのテーブル設計を提案してください。

【クリックバトル】
マウスかタッチパッドでボタンを10回連打するのに何秒かかるかを競うゲーム。
最初のボタン押してから、10回目のボタンを押した時まで何秒かかるか。
結果（ミリ秒）はランキングとして記録される。
初回ランキング登録には名前入れる（同じブラウザからのアクセスは同じユーザとなる）。
それ以降は、自己ベスト更新しない限りはランキング登録しない。

みんなで一言ずつ書き込む寄せ書き。

Claude

このアプリに必要なデータベースのテーブル設計を提案してください。

【一人一言！みんなの寄せ書き】
名前と一言を入力すると、全員の寄せ書きに並ぶ。
一人一投稿、あとから編集可。

備忘録

• compatibility_date は UTC 基準なので JST の今日の日付は未来になる場合がある → 前日以前の日付を指定する
• プロジェクトに生成される .wrangler/ フォルダはローカル状態のキャッシュなのでコミット不要。.gitignore に追加しておく
• Git連携方式では migration が自動適用されない。スキーマ変更時は push 前に wrangler d1 migrations apply --remote を手元から実行する必要がある
• migration の適用も Cloudflare 側で自動化したい場合は、Pages の Build command に wrangler d1 migrations apply --remote を仕込む手はある。ただし APIトークンを発行して Pages の環境変数に登録する必要があり、Git連携の手軽さは薄れる
• Cloudflare Pages の Git連携は Cloudflare 側で build/deploy が実行されるため、Free plan の build 回数（月500回）を消費する。個人開発の通常運用で上限に届くことはほぼない
• Cloudflare は長期的に Pages の機能を Workers へ統合する方針を示しているが、2026年時点では強制移行の期限は発表されておらず、Pages は引き続き利用できる