静的サイトをCloudflareで公開する

《 Cloudflare完全ガイド 目次へ 》

前のページでは、リクエストごとにコードを実行するWorkerを作りました。今度はファイルをそのまま配るサイトを公開します。

対象になるのは、HTMLとCSSと画像を置いただけのシンプルなサイトから、Astro・Next.js・Hugo・Jekyllといった静的サイトジェネレーターで生成したもの、React・Vueで作ったシングルページアプリケーションまで、幅広く含まれます。ポートフォリオ、技術ブログ、企業のランディングページ、ドキュメントサイト――世の中のWebサイトのかなりの割合が、この方法で公開できます。

そして重要なのは、静的ファイルへのリクエストは無料かつ無制限であるという点です。個人サイト程度なら、費用は本当にゼロで済みます。

このページで分かること

  • 静的サイトをCloudflareで公開する2つの方法と、どちらを選ぶか
  • コマンド1つで公開する手順
  • GitHubと連携して、pushするだけで更新される仕組みを作る手順
  • 独自ドメインの割り当てと、SPAのルーティング設定
  • 無料枠の範囲と、知っておくべき上限

WorkersとPages、どちらを使うか

Cloudflareで静的サイトを公開する方法は2つあります。第5章のCloudflare Pagesで触れたとおり、この2つは現在統合が進んでいる途中です。

  • Cloudflare Pages：静的サイトホスティング専用として作られたサービス。今も現役で動いています
  • Workers の静的アセット機能：Workersにファイルを配る能力が加わったもの。新規はこちらが推奨されています

Pagesが廃止されるわけではありません。ただ、新しい機能はWorkers側に追加されていくため、これから作るなら Workers を選ぶのが素直です。

判断に迷ったときの目安を整理します。

Workers（静的アセット） Pages
新規プロジェクト 推奨 引き続き利用可
静的ファイルの配信 無料・無制限 無料・無制限
動的な処理の追加 同じプロジェクトにそのまま書ける Functions で書く
Cron・Durable Objects等 使える 一部使えない
Cloudflare管理外ドメイン 不可 CNAMEで可

このページではWorkersの方法を扱います。

方法1：コマンドで公開する

最も速い方法です。すでに index.html があるフォルダを、そのまま公開できます。

最小の構成を作る

作業用のフォルダを作り、次の2つのファイルを置きます。

まず public/index.html。

<!doctype html>
<html lang="ja">
<head>
  <meta charset="utf-8">
  <title>はじめての静的サイト</title>
</head>
<body>
  <h1>Cloudflareで公開しました</h1>
</body>
</html>

次に、フォルダの直下に wrangler.jsonc。

{
  "name": "my-static-site",
  "compatibility_date": "2026-08-20",
  "assets": {
    "directory": "./public"
  }
}

これだけです。 JavaScriptのコードは1行も要りません。main の指定すら不要です。

デプロイする

npx wrangler deploy

数秒で https://my-static-site.あなたのサブドメイン.workers.dev が使えるようになります。開いてみてください。

ローカルで確認したい場合は、前のページと同じく次のコマンドです。

npx wrangler dev
静的サイトを公開する2つの方法
図1：静的サイトを公開する2つの方法

静的サイトジェネレーターを使っている場合

Astro・Hugo・Next.jsなどでビルドしている場合は、directory にビルド結果の出力先を指定するだけです。

"assets": {
  "directory": "./dist"
}

出力先はツールによって dist・out・build・_site などさまざまです。手元でビルドしてできたフォルダ名を指定してください。

なお、これらのフレームワーク向けには専用の雛形も用意されています。

npm create cloudflare@latest -- my-site --framework=astro

こう指定すると、そのフレームワーク用の設定込みでプロジェクトが作られます。

方法2：GitHubと連携して自動デプロイする

実際の運用では、こちらのほうが便利です。GitHubにpushするだけで、自動でビルドとデプロイが行われます。

Cloudflareのダッシュボードで Workers & Pages → Create application → Import a repository を選び、GitHubまたはGitLabのリポジトリを接続します。

設定するのは主に3つです。

項目 例 説明
ビルドコマンド npm run build ビルドが不要なら空欄
出力ディレクトリ dist 生成物が置かれる場所
本番ブランチ main ここへのpushで本番が更新される

接続が終わると、次のように動きます。

  • main にpushする → 自動でビルドされ、本番が更新される
  • プルリクエストを作る → 専用のプレビューURLが作られ、その内容を実際に開いて確認できる
  • ビルドの状態がGitHub側に表示される → プルリクエストにコメントが付く

このプレビュー機能が特に便利です。「修正した結果を、本番に出す前に実際のURLで確認する」という作業が、追加の設定なしで行えます。

なお、自己ホストのGitHub・GitLabには対応していません（2026年8月時点）。

独自ドメインを割り当てる

workers.dev のままでも動きますが、実際のサイトなら独自ドメインを使います。

設定ファイルに書く方法は、前のページと同じです。

{
  "name": "my-static-site",
  "compatibility_date": "2026-08-20",
  "assets": { "directory": "./public" },
  "routes": [
    { "pattern": "www.example.com", "custom_domain": true }
  ]
}

デプロイすると、DNSレコードも証明書も自動で設定されます。

ダッシュボードから設定することもできます。Workerの詳細画面の Settings → Domains & Routes → Add から、使いたいホスト名を指定します。

404ページとSPAの扱い

静的サイトで必ず出てくるのが、「存在しないURLにアクセスされたとき、どうするか」という問題です。設定ファイルの not_found_handling で指定します。

普通のサイト（ブログ・企業サイトなど）

"assets": {
  "directory": "./dist",
  "not_found_handling": "404-page"
}

存在しないURLには、404.html を用意しておけばそれが表示されます。

SPA（React・Vueなどで作ったアプリ）

"assets": {
  "directory": "./dist",
  "not_found_handling": "single-page-application"
}

この指定が抜けていると、SPAは「トップページは見えるのに、URLを直接開くと404になる」という症状を起こします。 SPAではルーティングをブラウザ側のJavaScriptが担当しているため、サーバーはどのURLでも index.html を返す必要があるからです。この指定で、その動きになります。

動的な処理を足したくなったら

静的サイトを公開したあと、「問い合わせフォームを付けたい」「アクセス数を数えたい」といった要求が出てきます。

Workersの静的アセット機能なら、同じプロジェクトにコードを足すだけです。

{
  "name": "my-static-site",
  "main": "src/index.js",
  "compatibility_date": "2026-08-20",
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS"
  }
}

main を追加し、binding を指定します。あとはコードを書きます。

export default {
    async fetch(request, env) {
        const url = new URL(request.url);

        // /api/ で始まるURLだけ自分で処理する
        if (url.pathname.startsWith("/api/")) {
            return Response.json({ message: "APIからの応答です" });
        }

        // それ以外は静的ファイルを返す
        return env.ASSETS.fetch(request);
    },
};

静的サイトとAPIが、1つのプロジェクトに同居します。 ここにD1をつなげばデータベース付きのサイトになり、Workers AIをつなげばAI機能付きになります。

なお、フォームを設置するならTurnstileでスパム対策を、メールで受け取るならEmail Routingを組み合わせるのが定番です。

費用と上限

静的アセットの無料枠と上限
図2：静的アセットの無料枠と上限

静的ファイルへのアクセスは無料

静的ファイルへのリクエストは無料かつ無制限です。ファイルを保存しておくこと自体にも料金はかかりません。個人サイトでも、そこそこアクセスのあるサイトでも、この部分で請求が発生することはありません。

課金対象になるのは、Workerのコードが実行されたリクエストだけです。純粋な静的サイトであれば、コードは動きません。

知っておくべき上限

項目 Free Paid
1バージョンあたりのファイル数 20,000 100,000
1ファイルのサイズ 25MiB 25MiB
_headers のルール数 100 100
_redirects の合計 2,100 2,100

ファイル数の上限は、画像を大量に含むサイトで問題になることがあります。写真ギャラリーのように何万枚も置く場合は、画像だけR2に逃がす構成を検討してください。

1ファイル25MiBの制限は、動画ファイルで引っかかります。大きな動画は、そもそも静的アセットとして置くべきではありません。

初心者が注意するポイント

  • directory はビルド結果を指す：ソースのフォルダを指定すると、.md ファイルなどがそのまま公開されてしまいます。ビルドしてできたフォルダを指定してください
  • SPAで not_found_handling を忘れない：「トップは見えるのに直リンクで404」の原因はほぼこれです
  • 秘密のファイルを置かない：directory に指定したフォルダの中身は、すべて公開されます。.env やバックアップファイルが混ざっていないか、デプロイ前に確認してください
  • キャッシュの反映を確認する：更新したのに古い内容が出る場合は、ブラウザのキャッシュか、Cloudflare側のキャッシュです。プライベートウィンドウで確認し、必要ならダッシュボードからパージします
  • PagesからWorkersへの移行は急がなくてよい：既に動いているPagesのプロジェクトは、そのまま使い続けて問題ありません
  • プレビューURLも公開されている：プルリクエストごとに作られるURLは、知っていれば誰でも開けます。公開前の情報を含む場合は、Cloudflare Accessで保護してください
  • wrangler deploy は即座に本番反映：確認の一手間が欲しい場合は、GitHub連携のプレビュー機能を使うほうが安全です

関連サービス

まとめ

  • 新規の静的サイトは、Workersの静的アセット機能が推奨。Pagesも引き続き利用できる
  • wrangler.jsonc に assets.directory を書いて npx wrangler deploy するだけで公開できる。コードは不要
  • GitHubと連携すれば、pushで自動デプロイ、プルリクエストごとにプレビューURLが作られる
  • 独自ドメインは routes に custom_domain: true を書くだけ。DNSも証明書も自動
  • SPAでは not_found_handling: "single-page-application" を必ず指定する
  • 静的ファイルへのリクエストは無料かつ無制限。課金されるのはWorkerのコードが動いたときだけ
  • ファイル数の上限は Free 20,000／Paid 100,000、1ファイル25MiBまで
  • あとから main と binding を足せば、同じプロジェクトにAPIを同居させられる

サーバーの契約も、FTPでのアップロードも、証明書の更新作業もなく、サイトが世界中に配信される――静的サイトの公開は、Cloudflareを使い始める入口として最も敷居が低く、効果も分かりやすい題材です。

次のページでは、サーバーを持たずに独自ドメインのメールアドレスを作ります。

次に読む

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。

ホーム
Cloudflare完全ガイド
タイトルとURLをコピーしました