Cloudflare Pagesは、GitHubのリポジトリをつなぐだけで静的サイトを世界中のCDNに配信できるホスティングサービスです。無料枠でも帯域制限がなく、個人開発のアプリやポートフォリオの公開先として選ばれています。
ただし、実際にデプロイしてみると、ビルド出力ディレクトリの指定やカスタムドメインのDNS設定でつまずく人が少なくありません。この記事では、Git連携とWrangler CLIの2つの手順を並べて整理し、公開後に必要なセキュリティヘッダーや法令表記の確認までまとめます。
ローンチガード編集部
個人開発アプリの法令表記・UXを自動監査するツール「ローンチガード」を運営しています。本記事は一般的な情報提供であり、法的助言ではありません。個別の判断が必要な場合は専門家にご相談ください。
この記事でわかること
Cloudflare Pagesのデプロイ前に決めておく準備
手順に入る前に、どの方式でデプロイするかを決めておくと迷いが減ります。Cloudflare Pagesには大きく分けてGit連携とWrangler CLIの2通りがあり、運用のしやすさが変わります。
デプロイ方式の2択
Git連携は、リポジトリへのpushをトリガーにCloudflare側でビルドが走る方式です。Wrangler CLIは手元でビルドした成果物をアップロードする方式で、CIを自前で組みたい場合や、ビルドに独自ツールを使う場合に向いています。
| 比較項目 | Git連携 | Wrangler CLI |
|---|---|---|
| 初期設定 | ダッシュボードのみで完結 | CLIのインストールとログインが必要 |
| デプロイの起点 | ブランチへのpush | 手元またはCIからのコマンド実行 |
| ビルド環境 | Cloudflareのビルドコンテナ | 自分の環境に依存 |
| 向いているケース | 個人開発の通常運用 | プライベートな依存やモノレポ構成 |
事前に揃えておくもの
どちらの方式でも、事前に用意しておく前提はほぼ共通です。着手してから止まらないよう、以下を先に確認しておきます。
- Cloudflareの無料アカウント（メール認証まで済ませておく）
- 公開したいコードが入ったGitHubまたはGitLabのリポジトリ
- ローカルでビルドが通ることの確認とビルド出力ディレクトリ名の把握
- Node.jsのバージョン（package.jsonのenginesかNODE_VERSIONで固定しておくと安全）
💬 編集部コメント
ビルドが失敗する相談の多くは、ローカルのNode.jsバージョンとCloudflare側の既定バージョンのずれが原因です。最初にNODE_VERSIONを明示しておくと、後から原因を探す時間を丸ごと節約できます。
Git連携によるCloudflare Pagesのデプロイ手順
もっとも一般的なのがGit連携です。ダッシュボードの操作だけで完了し、以降はpushするたびに自動でビルドとデプロイが走ります。
リポジトリの接続からデプロイまでの流れ
Cloudflareダッシュボードの「Workers & Pages」から新規プロジェクトを作成し、Gitプロバイダを認証します。権限の付与範囲は、対象リポジトリだけに絞る指定も選べます。
- 「Workers & Pages」からPagesを選び、Gitへの接続を開始する
- 連携するリポジトリと、本番にあてるブランチ（通常はmain）を指定する
- ビルドコマンドとビルド出力ディレクトリを入力する
- 保存してデプロイを実行し、ビルドログの完了を待つ
初回のビルドは数十秒から数分で終わり、完了するとプロジェクト名.pages.devのURLが払い出されます。ここまでで公開自体は完了です。
フレームワーク別のビルド設定
つまずきが集中するのがビルド出力ディレクトリの指定です。フレームワークごとに既定の出力先が違うため、次の対応を確認してから入力します。
| 構成 | ビルドコマンド | 出力ディレクトリ |
|---|---|---|
| 素のHTML/CSS/JS | （空欄のまま） | /（リポジトリ直下） |
| Vite | npm run build | dist |
| Next.js（静的エクスポート） | npm run build | out |
| Astro | npm run build | dist |
| Hugo | hugo | public |
環境変数とシークレットの扱い
APIキーなどは、プロジェクト設定の環境変数に登録します。本番用とプレビュー用が分かれているため、両方に入れないとプレビューだけ動かないという状態になります。
ブラウザ側に露出する変数と、サーバー側でだけ使う変数の区別も重要です。クライアントに配られるビルド成果物に秘密情報を埋め込まないよう、変数名の接頭辞の意味を確認してから登録してください。
🛡️ デプロイしたURLをそのまま診断
ローンチガードは、公開済みのURLを入力するだけで法令表記・UX・SEO・セキュリティの26項目を自動チェックします。デプロイ直後の抜け漏れ確認にお使いいただけます。
無料で診断してみる →Wrangler CLIでのデプロイ手順とプレビュー運用
手元のビルド成果物を直接アップロードしたい場合は、Wrangler CLIを使います。GitHub Actionsなど自前のCIに組み込むときも同じコマンドです。
基本コマンドの流れ
まずCLIをインストールし、ブラウザ経由でアカウントを認証します。以降はビルドしてからアップロードするだけの2ステップです。
npm install -D wrangler
npx wrangler login
npm run build
npx wrangler pages deploy dist --project-name=my-appCIから実行する場合は、対話的なログインの代わりにAPIトークンを環境変数で渡します。トークンの権限は、Pagesの編集に必要な範囲だけに絞るのが安全です。
プレビューデプロイとロールバック
本番以外のブランチにpushすると、プレビュー用のURLが自動で発行されます。レビュー依頼や動作確認を本番に影響させずに進められるしくみです。
公開後に問題が見つかったときは、ダッシュボードのデプロイ履歴から以前のビルドに戻せます。切り戻しの手順を先に一度試しておくと、障害時に慌てずに済みます。
💬 編集部コメント
プレビューURLは検索エンジンにも到達しうるため、未完成の内容を長期間置いたままにするのは避けたいところです。公開前の検証用ブランチにはnoindexを入れておく運用をおすすめします。
カスタムドメインとSSLの設定手順
pages.devのURLのままでも公開はできますが、サービスとして運用するなら独自ドメインを割り当てます。証明書は自動発行されるため、手動での更新作業は不要です。
DNSレコードの追加パターン
プロジェクト設定のカスタムドメインからドメインを追加します。ネームサーバーをCloudflareに向けている場合は、必要なレコードが自動で作成されます。
外部のDNSを使っている場合は、サブドメインならCNAMEをpages.devのホスト名に向けます。ルートドメインはCNAMEを置けない仕様のため、CNAMEフラットニングに対応した事業者かどうかの確認が必要です。
wwwあり・なしの統一
両方のホスト名で同じ内容が見える状態は、SEOの評価が分散する原因になります。どちらかを正とし、もう一方からはリダイレクトさせる方針を決めておきます。
Pages側では_redirectsファイルにリダイレクトルールを書けます。あわせて各ページのcanonicalタグが正しいホスト名を指しているかも確認しておくと安心です。
デプロイ後に設定したいセキュリティヘッダー
Cloudflare PagesはHTTPS化までは自動でやってくれますが、セキュリティヘッダーは自分で追加する必要があります。設定はリポジトリ直下の_headersファイルで完結します。
_headersファイルの書き方
出力ディレクトリに含まれる場所に_headersを置き、パスのパターンごとにヘッダーを列挙します。最低限入れておきたいものは次の3つです。
| ヘッダー | 設定値の例 | 目的 |
|---|---|---|
| Strict-Transport-Security | max-age=31536000; includeSubDomains | HTTPSでの接続を強制する |
| X-Frame-Options | SAMEORIGIN | 他サイトへの埋め込みを防ぐ |
| X-Content-Type-Options | nosniff | MIMEタイプの推測を止める |
監査から見えた実際の傾向
ローンチガードで多数の個人開発サイトを自動監査してきた中で、Cloudflare Pagesで公開されたサイトには共通した傾向がありました。HTTPS化とOGP画像は整っている一方で、_headersを一度も置いていないケースが目立ちます。
ホスティング側が自動で面倒を見てくれる範囲が広いぶん、自分で足すべき設定が見過ごされやすいのだと考えられます。デプロイ手順の最後に_headersの追加を組み込んでおくと、この抜けは防げます。
💬 編集部コメント
_headersはビルド成果物に含まれて初めて効きます。Viteなどを使っている場合はpublicディレクトリに置く必要があり、リポジトリ直下に置いたまま効いていない例をよく見かけます。
🛡️ ヘッダーの反映漏れをまとめて確認
設定したはずのセキュリティヘッダーが実際に返っているかは、公開URLを見ないと判断できません。ローンチガードなら実際のレスポンスをもとに確認できます。
無料で診断してみる →Cloudflare Pagesのデプロイでつまずきやすいポイント
デプロイが完了しない、あるいは公開したのに表示されないという相談には、いくつかの定番パターンがあります。原因の切り分け順を知っておくと復旧が早くなります。
ビルドが通らない場合の確認順序
ビルドログの最初のエラー行を読むのが基本です。手元では成功しているのにCloudflare側で失敗する場合、環境差が原因である可能性が高くなります。
- Node.jsのバージョン差（NODE_VERSIONの指定で解消することが多い）
- lockファイルの未コミットによる依存関係のずれ
- 環境変数の未登録でビルド時に値がundefinedになる
- 大文字小文字を区別するファイルシステムでのimportパスの不一致
404とリダイレクトの設定漏れ
SPAで直接URLを叩くと404になるのは、ルーティングをクライアント側で処理しているためです。_redirectsにすべてのパスをindex.htmlへ返すルールを追加すると解決します。
静的サイトで404になる場合は、ビルド出力ディレクトリの指定が実際の出力先とずれている可能性があります。デプロイのファイル一覧にindex.htmlが含まれているかを確認してください。
公開後に残りやすい表記の抜け
デプロイが成功すると作業が終わった気になりますが、サービスとして公開する場合はプライバシーポリシーや問い合わせ先の記載が必要になります。アクセス解析や広告を入れているなら、その旨の記載も欠かせません。
特に、有料プランを用意しているサービスでは特定商取引法に基づく表記が求められます。デプロイ手順書の末尾にこれらの確認項目を書き足しておくのが現実的な対策です。
💬 編集部コメント
監査していて多いのが、フッターにポリシーへのリンクはあるのにページ自体が404という状態です。ルーティングの都合で消えていることもあるので、公開後に実際のURLを踏んで確かめるところまでを手順に含めてください。
Cloudflare Pagesのデプロイに関するよくある質問
個人開発者から寄せられることの多い疑問を、実際の運用を前提に整理します。プラン選びや技術構成の判断材料としてご覧ください。
無料プランのまま商用サービスを公開できますか
静的アセットの配信については、無料プランでも帯域の従量課金がない設計になっています。一方でビルド回数や同時ビルド数には上限があるため、更新頻度が高い運用ではプランの確認をおすすめします。
Next.jsのサーバー機能はそのまま動きますか
静的エクスポートであればそのまま配信できます。サーバー側の処理を含む構成では、Cloudflareのランタイム向けアダプタを使うか、Pages Functionsに処理を寄せる形になります。
デプロイ後にサイトが表示されないときは何を見ますか
まずデプロイ詳細画面で、アップロードされたファイル一覧にindex.htmlがあるかを確認します。ファイルが正しく、それでも表示されない場合はDNSの伝播待ちかキャッシュを疑う順序が効率的です。
🛡️ リリース前夜のチェックを1回で
法令表記・UX・SEO・セキュリティの26項目を、URLを入れるだけで自動チェックします。デプロイ手順の最後の工程として組み込んでみてください。
無料で診断してみる →まとめ
Cloudflare Pagesのデプロイ手順は、Git連携ならリポジトリの接続とビルド設定の入力でほぼ完了します。つまずきの多くはビルド出力ディレクトリの指定とNode.jsのバージョン差に集約されるため、この2点を先に押さえておけば大きく詰まることはありません。
公開できたあとに残るのが、_headersによるセキュリティヘッダーと、プライバシーポリシーなどの表記です。ここまでを一続きの手順として扱うと、リリース後に慌てて直す場面を減らせます。