Claude Code と Cloudflare でサンプルサイトを公開するまで

AI コーディングアシスタントの Claude Code を使って、HTML だけのシンプルなサイトを一瞬で作り、Cloudflare Workers で無料公開してみました。

実際に試してみると、設定ファイルの書き方や Cloudflare ダッシュボードの設定でいくつか地味にハマったポイントがありました。そこで今回は、無駄な遠回りをせずに最短でサクッと公開まで持っていくための手順をまとめています。つまずきやすい箇所には実体験を交えたヒントを添えています。

記事内のプロンプト例はそのままコピーして使えます（<ユーザー名> などはお使いの環境に合わせて書き換えてください）。Cloudflare の画面の名前や手順は、2026年9月時点のものです。

作るページのイメージと、事前に準備するもの

本手順で最終的にできあがるのは、https://<Worker名>.<サブドメイン>.workers.dev という URL で動く以下の3ページです。<Worker名> は設定ファイルで自由に決める名前（今回は mysite）、<サブドメイン> は Cloudflare アカウントに自動で割り当てられる固有のドメインです。

トップページ（/）：サービス紹介の構成を持つサンプルページ
プライバシーポリシー（/privacy）：一般的なWebサイトに必要な条文のひな形
404 ページ：存在しない URL へアクセスされた際のエラー案内

事前に必要なものは次の4つだけです。アカウント作成も数分で終わります。

Claude Code（デスクトップアプリ、または CLI 環境）
GitHub アカウント（初期ファイルを作らない空のリポジトリを用意）
Cloudflare アカウント（無料プランで十分です）
Git（ローカル環境にインストール済みであること）

Claude Code にプロンプトを投げて、GitHub 反映まで丸投げする

空の作業フォルダを Claude Code で開き、以下のプロンプトをそのまま投げます。HTML/CSS のコーディングから、Cloudflare 用の設定ファイル作成、初期コミット、GitHub への push までを、この1回の指示でまとめてやってくれます。

Claude への指示の例

Cloudflare Workers（静的アセット機能）で公開する静的サイトを作成してください。
- トップページ（サンプル構成）とプライバシーポリシー（一般的な条文）の2ページを用意
- 公開対象ファイルは public ディレクトリに格納し、wrangler.toml で配信設定を行う
- workers.dev ドメインでアクセス可能にするため workers_dev = true を指定
- 生成完了後、https://github.com/<ユーザー名>/<リポジトリ名>.git へプッシュする（空リポジトリ）
- 最後に、Cloudflare ダッシュボード側で必要な設定手順を案内してください

指示を受け取った Claude Code は、以下のようなシンプルなディレクトリ構成を自動で作ってくれます。

生成されるファイル構成

public/
├── index.html        トップページ
├── privacy.html      プライバシーポリシー
├── 404.html          404エラーページ
├── _headers          セキュリティ・キャッシュ関連ヘッダー設定
└── assets/style.css  共通スタイルシート
wrangler.toml         Cloudflare Workers 構成設定ファイル
README.md             差し替え箇所の一覧およびデプロイ手順書

Claude Code はブラウザでローカル表示を確認した上で、指定した GitHub リポジトリへ自動で push してくれます。サイト名や連絡先など、あとから自分の情報に差し替えるべき箇所は README.md に一覧でまとめてくれるので安心です。

実体験ヒント：「Pages」ではなく「Workers」と明示するのが近道

プロンプトで「Cloudflare Pages で公開したい」と頼むと、旧方式の Pages 向けの設定で作られてしまいます。そうすると、ダッシュボード側で「ビルド出力ディレクトリ」の入力を求められる案内になるのですが、今の Cloudflare 管理画面で新規作成を開くと Workers のインポート画面が最初に出てくるため、案内と画面の見た目が食い違って戸惑ってしまいます。今の Cloudflare の仕様なら、最初から「Workers」と明示して作ってもらうのが一番スムーズです。

Pages と Workers の違い

項目	Cloudflare Pages	Cloudflare Workers
従来の役割	静的サイト（HTML/CSS/JS）のホスティング	エッジサーバー上でのサーバーレス関数実行
現在の位置づけ	レガシー方式（現在も稼働可能）	現在の統合標準。静的アセット配信も統合対応
公開ディレクトリ指定	管理画面上の入力フィールド	設定ファイル `wrangler.toml` 側で定義
公開ドメイン形式	`〇〇.pages.dev`	`〇〇.<サブドメイン>.workers.dev`

設定ファイル（wrangler.toml）で公開設定を確認する

Cloudflare Workers で静的サイトを配信する場合、どのフォルダを公開するかなどの設定は、画面ではなく wrangler.toml というファイルに直接書きます。リポジトリ直下にこのファイルができているので、中身をサクッと確認しておきましょう。

wrangler.toml

name = "mysite"
compatibility_date = "2026-09-12"
workers_dev = true

[assets]
directory = "./public"
not_found_handling = "404-page"

各設定項目の意味は以下のとおりです。

name：Worker のプロジェクト識別名。公開 URL のサブドメイン先頭部分になります（mysite は例なので、半角英小文字・数字・ハイフンでお好きな名前に変えて OK です）。
workers_dev：workers.dev ドメインでアクセスできるようにする必須フラグ（true を指定）。
directory：配信対象となる静的ファイルが格納されたディレクトリパス（今回は ./public）。
not_found_handling：該当ファイルが存在しない場合に 404.html を返却するルーティング指定。

実体験ヒント：workers_dev = true を書き忘れると画面が開かない

筆者が実際に試して一番ハマったのがここです。この設定値が抜けていると、ビルド自体は成功するのに、URL を開いた瞬間に「error code: 1042」とだけ表示されて途方に暮れることになります。管理画面の「設定」→「ドメインとルート」において workers.dev ルートが無効化されてしまうためです。

ダッシュボード側で手動で「有効」に切り替えることもできますが、GitHub に push するたびに wrangler.toml の内容で上書きされて再び無効に戻ってしまいます。設定ファイルに workers_dev = true としっかり書いておくのが確実な解決策です。

Cloudflare ダッシュボードでリポジトリを連携してデプロイする

コードが GitHub に上がったら、あとは Cloudflare と連携させるだけです。ダッシュボードでポチポチと設定していきましょう。

Cloudflare 管理画面にログインし、左メニューの「Workers & Pages」→「作成」→「リポジトリをインポート」を選択します。
GitHub アカウントとの連携を承認し、先ほど作成したリポジトリを指定します。
ビルド設定画面で以下の項目を入力し、「保存してデプロイ」を押します。

設定項目	入力値	説明
プロジェクト名	`mysite`	`wrangler.toml` の `name` と完全一致させる
ビルドコマンド	（空欄）	静的 HTML のためビルド工程は不要
デプロイコマンド	`npx wrangler deploy`	デフォルト値のまま維持
ルートディレクトリ（Path）	（空欄）	リポジトリ直下を参照させるため未入力にする

注意点：「Path（ルートディレクトリ）」に public を入力しない

入力欄にある「Path」は、リポジトリの起点となる作業ディレクトリを指定する項目です。ここに public を指定してしまうと、設定ファイル wrangler.toml が認識されずデプロイエラーになります。配信ディレクトリは既に wrangler.toml 内の [assets] directory = “./public” で定義済みですので、Path 欄は必ず空欄のまま進めてください。

公開された URL を開いて表示をチェックする

デプロイ処理が始まって数十秒ほど待つと、管理画面の概要ページに公開 URL（https://<Worker名>.<サブドメイン>.workers.dev）が発行されます。

リンクをクリックして、トップページがきれいに表示されれば公開完了です！あわせて /privacy を開いて、下層ページも問題なく見られるか確認しておきましょう。

実体験ヒント：もしページが表示されないときのチェックリスト

万が一エラー画面が出たり接続できない場合は、落ち着いて次のポイントをチェックしてみてください。

ドメインルートが有効か：「設定」→「ドメインとルート」で workers.dev が「有効」になっているか
デプロイログにエラーがないか：ログの末尾に Deployed <プロジェクト名> triggers と出ているか
対象ブランチが合っているか：デプロイ対象が GitHub のデフォルトブランチ（main）になっているか
少し待ってみる：初回公開直後は世界中のエッジ拠点に反映されるまで1〜2分ほどタイムラグがある場合があります

それでも原因が分からないときは、画面のエラーメッセージやビルドログの末尾をそのまま Claude Code に貼り付けて聞いてしまうのが一番早いです。

Claude への調査依頼プロンプト例

Cloudflare Workers へのデプロイ後にページが表示されません。
アクセス時に以下のエラーが表示されています。原因と修正手順を教えてください。

【エラーメッセージまたはビルドログ】
（画面のエラー表示やログの末尾数行を貼り付け）

公開後のサイト更新と、プレビュー URL による事前確認

一度公開してしまえば、以後の更新はとてもシンプルです。GitHub の main ブランチに push するたびに、Cloudflare が勝手に最新の状態へデプロイしてくれます。

ちょっとした文言の修正や連絡先の更新も、Claude Code にチャットで頼むだけで完了します。

Claude への指示の例：サイト情報の更新

サイト名を「〇〇」、運営者名を「〇〇」、連絡先メールアドレスを「contact@example.com」に書き換え、GitHub へ反映してください。

初期状態のプライバシーポリシーは一般的なひな形なので、実際にアクセス解析やお問い合わせフォームを導入したタイミングで、取得する情報に合わせて見直しておきましょう。

Claude への指示の例：プライバシーポリシーの改定

Google アナリティクスによるアクセス解析と、外部フォームによる問い合わせ受付を行う前提で、プライバシーポリシーの条文を改定してください。

本番にいきなり反映せず、プレビュー URL で安全に確認する

main ブランチに push すると、すぐに本番サイトが書き換わってしまいます。「公開前にちゃんと表示崩れがないか確認したい」というときは、作業用の別ブランチに push しましょう。Cloudflare は main 以外のブランチに対しても、本番とは別の専用プレビュー URL を自動で発行してくれます。

Cloudflare 管理画面で対象 Worker を開き、「設定」→「ビルド」→「ブランチコントロール」にて「非本番ブランチのビルド」にチェックが入っているか確認します（入っていなければチェック）。
Claude Code に頼んで、作業用の別ブランチを作って push してもらいます。
自動発行されたプレビュー URL を開いて、表示を確認します。
問題がなければ、そのブランチを main にマージして本番へ反映します。

Claude への指示の例：作業ブランチの作成とプッシュ

トップページの見出し文を「〇〇」に修正してください。
- main ブランチは変更せず、新設する update-top ブランチへコミット・プッシュすること
- プッシュ後、GitHub 上でプルリクエストを作成してください

プレビュー環境には以下の形式で一意の URL が割り当てられます。

プレビュー URL の構成規則

https://<ブランチ名>-<Worker名>.<サブドメイン>.workers.dev

例として update-top ブランチであれば、https://update-top-mysite.<サブドメイン>.workers.dev という URL になります。プルリクエストを作っておくと、Cloudflare の bot がプルリクエストのコメント欄にプレビュー URL を自動投稿してくれるのでとても便利です。

表示確認に問題がなければ、GitHub 上でプルリクエストをマージするか、Claude Code にマージを指示して本番環境へ反映します。

Claude への指示の例：本番マージの依頼

プレビュー環境での表示を確認しました。update-top ブランチを main にマージし、GitHub のリモートへ反映してください。

注意点：プレビュー URL は誰でもアクセスできる

プレビュー環境の URL には認証機能が設定されていないため、URL を知っていれば誰でも開けます。まだ一般公開したくない情報や未発表のコンテンツを載せているときは、URL の取り扱いに注意しましょう。

なお、wrangler.toml に workers_dev = true が明記されていればプレビュー環境も自動で有効化されます。もしプレビュー URL が発行されない場合は、前述の「非本番ブランチのビルド」設定が有効になっているかを確認してください。

最短公開の勘所：Workers 指定と workers_dev 設定

Claude Code と Cloudflare を使って最短でサイトを公開するためのポイントは、実質的に次の2つだけです。

初期プロンプトで「Pages」ではなく「Workers（静的アセット）」を指定すること
設定ファイル wrangler.toml に workers_dev = true を忘れずに明記しておくこと

この2点さえ押さえておけば、あとは Claude Code にリポジトリへの反映を任せ、Cloudflare の画面で連携するだけで迷わずサクッと公開できます。

ページ数が増えてきたり、ブログ記事を定期的に書いていきたくなったら、コンポーネント化や Markdown 執筆がしやすい静的サイトジェネレーター（Astro など）の導入がおすすめです。当サイトを素の HTML から Astro へ移行した実際の手順は、次の記事にまとめています。

次に読むサンプルサイトを Astro に移行して Cloudflare で公開するまでHTML だけで作ったサンプルサイトを静的サイトジェネレーター Astro へ移行し、Cloudflare Workers で再公開するまでの最短手順と、Next.js・Hugo・11ty との比較を解説します。2026.09.14