Claude Codeで作ったWebアプリをCloudflare Pagesにデプロイする4つの方法

手動アップロード / Wrangler / Git連携 / GitHub Actions

Claude Codeで作ったWebアプリをCloudflare Pagesに公開する方法は、大きく4つある。ブラウザで手動アップロードする方法、Wranglerで直接デプロイする方法、Cloudflare PagesのGit連携を使う方法、GitHub ActionsからWranglerを実行する方法。

この記事では、4つのデプロイ方法の違い、向いている場面、無料枠やD1への発展を見据えた選び方を整理する。

Cloudflareへのデプロイ方法4つ

1. Cloudflare Pagesへのデプロイは4種類ある

Cloudflare Pages へのデプロイ方法は主要なもので 4種類 ある。手軽な順に並べる。

• ブラウザでドラッグ＆ドロップ
• Wrangler CLI
• Cloudflare Pages の Git連携
• GitHub Actions + Wrangler

以下、それぞれを順に見ていく。

1-1. ブラウザでドラッグ＆ドロップ

Cloudflareダッシュボードのプロジェクト画面に、HTMLファイルなどをドラッグ＆ドロップするとそのままデプロイされる。

• メリット: アカウント作成だけで使える。GitHubもターミナルも不要
• デメリット: 更新のたびに手でアップロードする必要がある
• 向いているとき: とにかく試しに公開してみたい、シンプルな静的サイトの初回公開

1-2. Wrangler CLI

Cloudflare公式のCLIツール wrangler を、ローカル（Claude Code経由など）から実行してデプロイする。

• メリット: Claude Codeに「デプロイして」と頼むだけで反映できる
• デメリット: Node.js のインストールが必要。デプロイのたびに手動でコマンド実行
• 向いているとき: ローカルで開発しながら、自分のタイミングでコマンド一発で本番反映したい

1-3. Cloudflare Pages の Git連携

Cloudflareダッシュボード上で GitHub リポジトリを連携すると、リポジトリへのpushを検知して Cloudflare側でビルド・デプロイが実行される。

• メリット: 設定が最短。ダッシュボードでリポジトリを選ぶだけ。後述のGitHub ActionsのようなAPIトークン作成もワークフローファイル（YAML）作成も不要
• デメリット: Cloudflare無料プランではビルド回数に上限あり（月500回まで）
• 向いているとき: GitHubでバージョン管理しつつ、最短で自動デプロイを使いたい

1-4. GitHub Actions + Wrangler

GitHub Actions のワークフローファイル（YAML）に npx wrangler pages deploy を書き、GitHubへのpushで GitHub Actions側から Cloudflare へデプロイする。

• メリット: デプロイ手順を YAML にコード管理できる。テストやマイグレーションなどの前処理を後から差し込みやすい。Cloudflare側のビルド枠を消費しない
• デメリット: APIトークン作成、Secrets登録、YAML作成など初期セットアップが多い
• 向いているとき: デプロイ前にやりたい処理（テスト、ビルド、マイグレーション等）があるとき、CI/CDをコード管理したいとき

1-5. 4種類を比較する

観点	ブラウザでドラッグ＆ドロップ	Wrangler CLI	Git連携	GitHub Actions
事前準備	アカウントのみ	+ Node.js	+ GitHub	+ GitHub・APIトークン・YAML
公開操作	手動アップロード	手動コマンド	git push	git push
デプロイ自動化	×	×	○	○
デプロイ前処理	×	×	工夫すれば可	○
D1への発展	不向き	手動なら可	工夫が必要	向いている
Cloudflareビルド枠	消費しない	消費しない	消費する（無料500回/月）	消費しない
初学者向け	◎	○	○	△

迷ったときの目安：

• とにかく試しに公開してみたい → ブラウザでドラッグ＆ドロップ
• ローカルで開発しながらコマンド一発で反映したい → Wrangler CLI
• GitHubと連携して最短で自動デプロイにしたい → Git連携
• 自動デプロイに加えてテスト・マイグレーション等の前処理も組み込みたい → GitHub Actions

2. 論点: Wrangler vs. GitHub

4種類のデプロイ方法は、大きく Wrangler 系（手元から直接Cloudflareに流す）と GitHub 系（GitHubへのpushをきっかけにCloudflareに反映する）の2つに分けられる。

系統	含まれる方法	デプロイ起点	コード管理
Wrangler 系	1-2. Wrangler CLI	手元	自分で（Git使うかは自由）
GitHub 系	1-3. Git連携 / 1-4. GitHub Actions	GitHub への push	GitHub（履歴・差分が残る）

1-1. ブラウザでドラッグ＆ドロップは、ダッシュボード操作だけで完結する別系統。試し公開向け。

2-1. 手軽に試せるならWrangler

Wranglerは Node.js さえ入っていればよく、Claude Code に「デプロイして」と頼めばすぐ反映できる。GitHubアカウントもAPIトークンもYAMLも不要で、導入が一番気軽。試行錯誤しながらサクッと公開したい個人開発に向いている。

一方で、コードのバージョン管理は自分でやる必要がある（Gitを使うかどうかも自由）。あとから履歴を追ったり共同編集したりする段階になると、GitHub側に乗せ替えるか、別途Git管理を始めることになる。

2-2. コード管理とデプロイを連携させるならGitHub

GitHubにコードを置く前提で、リポジトリへのpushをデプロイトリガーにする。コードのバージョン管理・履歴・差分レビューが自然にでき、その上に Git連携や GitHub Actions の自動デプロイが乗る形になる。事故時のロールバックや変更追跡もやりやすい。

ただし、GitHubアカウントや gh のセットアップなど最初の準備が必要（→ Git と GitHub の基本）。継続的に作っていく場合や、複数の環境・自動処理を組み合わせたい場合は、最初に整えておくと以降の運用が楽になる。

2-3. D1（データ共有型Webアプリ）はどちらでも

D1（Cloudflareのデータベース）を使うデータ共有型Webアプリも、Wrangler／GitHub のどちらの系統からでも構築できる。本サイトの D1 ハンズオン（D1W）では、両方の公開方法を案内している。

• Wrangler だけで完結させる → D1ハンズオンの【ケース1】wrangler で直接公開する（npx wrangler d1 migrations apply を手元から実行）
• GitHub 経由で自動デプロイ → D1ハンズオンの【ケース2】Git連携で公開する（マイグレーションは手元から実行）/ D1A（GitHub Actions版・アーカイブ）（マイグレーションとデプロイをYAMLで一連にまとめる）

本サイトのロードマップでは GitHub 経由のほうを採用している。コード管理とデプロイが GitHub に集約されることで、あとから運用を広げるときに引き継ぎやすいため。

2-4. まとめ

• 手軽に試したい、コード管理は自分でやれる → Wrangler
• 継続的に運用していく、コード管理とデプロイを連携させたい → GitHub

3. 論点: Git連携 vs. GitHub Actions

4つの中で、CGT（Git連携）と CGA（GitHub Actions）は「pushすると自動でデプロイされる」点が共通していて、最初は使い分けに迷いやすい。 ここでは少しだけ詳細に検討する。

3-1. 手軽さならGit連携

静的ファイルだけで完結するWebアプリなら、Cloudflare PagesのGit連携が一番手軽。Cloudflare DashboardでGitHubリポジトリを選べば、pushだけで自動デプロイできる。APIトークンやGitHub ActionsのYAMLは不要。

一方で、D1マイグレーション、テスト、ビルド前処理などをデプロイ前に実行したい場合は、GitHub Actions + Wranglerの方が扱いやすい。処理の順番をYAMLに明示できるため、あとからD1を使うデータ共有型Webアプリへ発展させやすい。

ただし GitHub Actions は事前準備（APIトークン作成、Secrets登録、YAML作成）の手間がかかる。静的サイトを自動デプロイしたいだけなら、Git連携の方が早い。

3-2. 無料枠の違い

Cloudflare Pages の Git連携では、Cloudflare側で build が走るため、Cloudflare Pages の build 回数を消費する。Free plan では月500回の上限がある（参考）。

GitHub Actions + Wrangler では、build や deploy コマンドの実行場所が GitHub Actions 側になるため、Cloudflare Pages の build 回数は消費しない。GitHub Actions Free の実行時間枠は Public リポジトリなら無制限、Private でも月2,000分（参考）。個人開発の通常運用（デプロイ1回あたり1〜2分程度）なら月1,000〜2,000回はデプロイできる計算で、上限に届くことはまずない。

つまり、無料枠の余裕という観点では GitHub Actions の方が有利。

3-3. D1 を使う場合の使い分け

Cloudflare D1 を使うデータ共有型Webアプリでは、デプロイとは別に DBスキーマ更新（マイグレーション）の適用が必要になる。

本サイトのロードマップの D1W では、公開方法として wrangler 直接デプロイ（ケース1）と Git連携の自動デプロイ（ケース2）の両方 を案内している（→ D1W）。どちらの方法でも、DBスキーマ更新（マイグレーション）は手元から wrangler d1 migrations apply で明示的に行う。コードのデプロイ方法によらず DB の変更だけは手元で明示的に行う、初学者に流れが見えやすい形。

マイグレーションの適用まで自動化したい場合は GitHub Actions が向く。d1 migrations apply と pages deploy を別々のステップとして書け、何をどの順番で実行しているかが見えやすく、失敗時の切り分けもしやすい（→ D1A（アーカイブ））。

3-4. まとめ

• 静的サイトを最短で自動デプロイしたい → Git連携
• 無料枠の余裕・マイグレーションの自動適用・テストやビルド前処理を組み込みたい → GitHub Actions

3-5. 補足：Workersの場合

ここまでは Cloudflare Pages を前提にしているが、Workers でも「Cloudflare側CI（Workers Builds）に任せる／GitHub Actions から流す」の構図は同じ。違いとして大きいのは無料枠で、Workers Builds は月3,000 build minutes（1ビルド1〜2分換算で月1,500〜3,000回相当）あるため、3-2 で挙げた「無料枠の余裕」は Workers では選択の決め手になりにくい。それ以外の論点はほぼ変わらない。

そもそも Workers と Pages のどちらを使うか、という1段上の選択については WVP（Workers と Pages どちらを使うか） を参照。

4. 本サイトのハンズオンで順番に体験する

本サイトには、Claude Code を使ってWebアプリを作り Cloudflare に公開する一連のハンズオンがロードマップとして並んでいる。順に進めることで、手動デプロイ、CLIデプロイ、Cloudflare側の自動デプロイ、GitHub Actions側の自動デプロイを段階的に体験できる構成にしている。

1. ブラウザにドラッグ＆ドロップ
   • CloudflareにHTMLファイルなどをブラウザでアップロードしてWebサイトとして公開する
2. Wrangler CLI
   • Claude CodeでWebアプリを作ってWranglerでCloudflareに公開する
3. Cloudflare PagesのGit連携 (静的サイト)
   • Claude CodeでWebアプリを作ってGit連携でCloudflareに公開する
4. Cloudflare PagesのGit連携 (D1を使うデータ共有型Webアプリ)
   • Claude Codeでデータ共有型Webアプリを作ってCloudflareに公開する
5. GitHub Actions (静的サイト)
   • Claude CodeでWebアプリを作ってGitHub ActionsでCloudflareに公開する
6. GitHub Actions (D1を使うデータ共有型Webアプリ)
   • Claude Codeでデータ共有型Webアプリを作ってCloudflareで公開する

すでに経験済みの方法がある場合は、その次のステップから始めてもよい。