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

前回のハンズオンでは、Git連携でCloudflareに自動デプロイする方法を扱い、一人完結型Webアプリを公開した。今回はその先として、データベースを使ってみんなで使えるWebアプリを作る。データを保存・共有できると、できることが一気に広がる。

今回のハンズオンでは、データ共有型Webアプリ（参考）を作って、Cloudflare Pages の Git連携で公開する。

本記事の位置付け

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

Claude

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

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

本記事では、その中で Cloudflare D1 + Pages Functions を Git連携でデプロイする 道筋を、つまずきにくい順序で追っていく。

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

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

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

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

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

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

1-2. 全体構成の復習

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

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

WranglerはCloudflare公式のCLIツール。ローカルではD1データベースの作成・ログイン・開発プレビュー・本番DBへのマイグレーション適用に使う。

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

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

1-3. この記事でのデプロイの流れ

公開（デプロイ）には Cloudflare Pages の Git連携 を使う。GitHubにpushすると、Git連携がpushを検知して、Pages・Pages Functionsのデプロイ（本番環境への公開・反映）を自動実行する。

ただし、D1のマイグレーションは自動では適用されない。手元から npx wrangler d1 migrations apply を実行して本番DBに反映する必要がある（手順は公開の段階で説明する）。

2. 事前準備

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

Finder で ~/Desktop/claude フォルダ（なければ作る）の中に作業フォルダ my-bbs を作る。

2-2. Claude Codeを起動

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

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

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

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

npx wrangler whoami

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

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

D1データベースを作成する。ターミナルで実行するか、Claude Code にプロンプトとして渡す。

npx wrangler d1 create my-bbs-db

コマンド末尾の my-bbs-db がデータベースの名前。自分で好きな名前を付けてよいが、この名前は後の wrangler.jsonc（5章）で database_name として指定するので、変えるならそちらも揃える。

「既に存在しています」エラーが出たら、別名（例：my-bbs-db2）で作り直す（後で wrangler.jsonc を作るときにその名前を使う）。

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

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

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

Claude Code にアプリの仕様を伝えてテーブル設計を相談する。

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

Claude

匿名一行掲示板を作ります。仕様は以下のとおりです。

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

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

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

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

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

Claude

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

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

マイグレーション — データベースの構造変更（テーブルの作成・変更・削除など）をSQLファイルとして管理する仕組み。変更をファイルに記録しておくことで、「どの変更がいつ適用されたか」を追跡でき、本番環境への反映も自動化できる。

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

5. wrangler.jsonc の作成

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

プロジェクト名（my-bbs）は公開URL（https://プロジェクト名.pages.dev）になる。すでに使われているとプロジェクト名の後に英数3文字が付く。それを避けたい場合はブラウザで https://候補名.pages.dev を開いて空きを確認しておく。

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

Claude

以下のテンプレートで wrangler.jsonc を作成してください。
プロジェクト名は「my-bbs」、データベース名は「my-bbs-db」、YYYY-MM-DDは昨日、
database_id には先ほど d1 create で表示された ID を記入してください。

---
{
  "name": "プロジェクト名",
  "compatibility_date": "YYYY-MM-DD",
  "pages_build_output_dir": "./public",
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "データベース名",
      "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）の作成

Claude Code にアプリの仕様とスキーマを伝えて「APIを作成して」と依頼すると functions/api/xxxx.js を生成してくれる。

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

Claude

匿名一行掲示板のAPIを functions/api/posts.js に作成してください。
投稿の一覧取得と新規投稿ができるようにしてください。
D1 の binding 名は DB、スキーマは先ほど設計したものを使ってください。

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

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

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

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

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

Claude

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

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

Claude

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

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

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

ローカルでは本番DBではなくローカル用のD1を使う。まず --local フラグを付けてマイグレーションを適用し、ローカルD1にテーブルを作る。

npx wrangler d1 migrations apply my-bbs-db --local

その後、Claude Code にローカルサーバーの起動を依頼する。

Claude

wrangler のローカルサーバー（wrangler pages dev）を起動して

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

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

プロンプトでまとめて頼んでもよい: 上の2ステップ（ローカルD1へのマイグレーション適用＋ローカルサーバー起動）は、Claude Code に次のように頼めばまとめてやってくれる。

Claude

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

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

9. 初回push

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

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

GitHub の MCP プラグインはオフにしておく: Claude の Customize →「プラグイン」にある Github（GitHub 公式 MCP サーバ）をインストールしていると、Claude Code が gh・ローカルの git ではなく GitHub API 経由で操作してしまい、手順どおりに進まないことがある。本ハンズオンは gh に統一するので、入れている場合は無効化しておく（詳しくは GBA 4章 を参照。Customize →「コネクタ」の GitHub連携 はアカウント接続で別物だが、有効だと Code セッションに読み込まれることがあるので、手順がズレるようなら同様に無効化してよい）。

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

Claude

.gitignore に .wrangler/ を追加して

続けて、リポジトリを作成して push する。ビュー → ターミナル から実行する（→ 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 にしておくと、Cloudflare 側の Production branch 指定（main）と揃う。

プロンプトでも頼める: 上の操作は Claude Code に次のように頼んでもよい。git init からコミット・リポジトリ作成・push までまとめてやってくれる。

Claude

GitHubに非公開のリポジトリ my-bbs を作って、今のフォルダの内容をpushして

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

10. Cloudflare Pages の Git連携をセットアップ

Cloudflare PagesにGitHubリポジトリを連携すると、リポジトリに変更がpushされるたびに自動でビルド・デプロイが実行される。この章では連携を設定して初回デプロイまで進める。

まず、本番DBにマイグレーションを適用する。 Git連携方式では migration が自動では適用されない。後述の Save and Deploy で本番のアプリが動き出す前に、手元から本番DBにスキーマを反映しておく（適用しないと、画面は出るのに投稿でDBエラーになる）。このコマンドは wrangler.jsonc を読むので、プロジェクトフォルダ（my-bbs）内で実行する。Claude Code の ビュー → ターミナル を使えば最初から my-bbs 内にいる（プロンプトとして渡してもよい）。

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

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

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

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

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

リポジトリ一覧から my-bbs を選び、Begin setup をクリック。

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

• Project name に my-bbs を入れる。公開URLの一部になる（https://my-bbs.pages.dev）

入力欄の直下に割り当てられるURLが表示される。my-bbs.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

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

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

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

納得したら、アップを依頼:

Claude

コミットしてpushして

Cloudflare が push を検知してデプロイを自動実行する。しばらく待ってから公開URLにアクセスして確認。

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

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

Claude

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

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

1. npx wrangler d1 migrations apply my-bbs-db --remote を手元から実行して本番DBに反映する
2. 「コミットしてpushして」でコードをpushして自動デプロイさせる

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

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

Claude

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

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

12. 次のステップ

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

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

補足: GitHubを使わず wrangler で直接デプロイする

本記事は Cloudflare Pages の Git連携（push で自動デプロイ）を学ぶのが主眼だが、GitHub を使わず wrangler で直接デプロイすることもできる。GitHub アカウントやリポジトリの用意が不要で、最初の公開までの手数が少ない。フロントエンドまで完成していれば（8章のローカル動作確認まで終えた状態なら）、9章の初回push と 10章の Git連携セットアップの代わりに、次の2コマンドで公開できる。

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

• 1つ目: 本番D1にスキーマ（マイグレーション）を適用する。Git連携方式と同じく、これは初回とスキーマ変更時に必要
• 2つ目: wrangler.jsonc の pages_build_output_dir（./public）を読んで Direct Upload でデプロイする。functions/ の Pages Functions は自動でバンドルされ、wrangler.jsonc の D1 binding（env.DB）もそのまま反映される

初回は Pages プロジェクト名やブランチを聞かれることがあるので、my-bbs などと答える。

プロンプトで頼む場合は、本番DBへのマイグレーション適用まで含めて頼むのが安全：

Claude

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

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

Git連携と比較してみる。

	Git連携（本記事 9〜10章）	wrangler 直接デプロイ（この補足）
GitHub	必要	不要
デプロイ	push で自動	wrangler pages deploy を手動実行
変更履歴・ロールバック	GitHub＋Cloudflare に残る	Cloudflare のデプロイ履歴のみ
向き	継続的に育てるアプリ	まず公開したい・お試し

マイグレーションの手動適用（--remote）はどちらの方式でも必要な点に注意。継続的に開発するなら Git連携、とにかく早く公開したいなら直接デプロイ、と使い分けられる。

備忘録

• 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 は引き続き利用できる