Cloudflare Workersでサイトを運用するメリットは？

世界300以上のエッジロケーションからの配信による高速表示、無料SSLの自動管理、DDoS防御、そして静的サイトであればホスティング費用が実質無料になる点が大きなメリットです。

AstroとCloudflare Workersの組み合わせが適している用途は？

コーポレートサイト、LP、ブログなどの静的コンテンツ中心のサイトに最適です。ビルド済みHTMLを配信するため表示が速く、セキュリティリスクも低くなります。

Astro + Cloudflare Workers で自社サイトを運用するまでの技術選定

はじめに

Trimora株式会社は、AIを活用したWeb制作・動画制作を行う会社である。自社サイト（trimora.co.jp）は Astro + Tailwind CSS で構築し、2026年3月にホスティング基盤を Cloudflare Workers へ移行した。

本記事では、移行に至った判断の背景、採用したアーキテクチャ、セキュリティヘッダーの設計、CI/CDの構成を記録として公開する。

移行判断の背景

検討に至った3つの観点

自社サイトのホスティング基盤を見直すにあたり、以下の3つの観点から検討した。

1. コスト構造

静的サイトの配信であれば、Cloudflare Workers の Free Plan で月額0円の運用が可能である。サービスの立ち上げ期においてランニングコストを抑えられることは、経営上の判断として合理的だと考えた。

2. 商用利用時の規約

ホスティングサービスを選定する際、利用規約の確認は不可欠である。各サービスの規約を確認し、当社の利用形態（静的サイトの商用配信）に適合するかを検討した。Cloudflare Workers は商用利用に関する制約が明確で、当社の用途に適していると判断した。

3. エッジ配信によるパフォーマンス

Cloudflare はグローバルに分散したエッジネットワークを持ち、日本国内にも複数の拠点がある。静的アセットをエッジから直接配信できるため、応答速度の面で有利であると考えた。

補足

移行前のホスティング環境が不適切だったわけではない。自社の要件を改めて整理した結果、Cloudflare Workers がこのケースに合っていたという判断である。

アーキテクチャ構成

全体像

Astro (static build)
  └─ dist/          ← astro build で生成される静的ファイル群
  └─ worker.js      ← セキュリティヘッダー付与のラッパー
  └─ wrangler.toml  ← Workers 設定

GitHub push (main)
  └─ GitHub Actions (deploy.yml)
       └─ npm ci → astro build → wrangler deploy

Astro の設定

Astro は output: 'static' モードで使用している。SSRは使わず、ビルド時にすべてのページをHTMLとして出力する。インテグレーションとして Tailwind CSS と sitemap を導入している。

worker.js — セキュリティヘッダーの付与

Cloudflare Workers の env.ASSETS.fetch() で静的アセットを取得し、レスポンスにセキュリティヘッダーを付与して返すシンプルな構成である。アプリケーションロジックは持たず、ヘッダー付与とキャッシュ制御のみを担う。

wrangler.toml

Workers の設定は最小限にしている。[assets] セクションで dist/ を静的ファイルのディレクトリとして指定し、not_found_handling = "404-page" でカスタム404ページを有効にしている。

セキュリティヘッダーの設計

worker.js で付与しているセキュリティヘッダーは以下のとおりである。

ヘッダー	設定値	目的
X-Content-Type-Options	nosniff	MIMEタイプスニッフィングの防止
X-Frame-Options	SAMEORIGIN	クリックジャッキング対策
Referrer-Policy	strict-origin-when-cross-origin	リファラー情報の制御
Permissions-Policy	camera=(), microphone=(), geolocation=()	不要なブラウザAPIの無効化
Strict-Transport-Security	max-age=63072000; includeSubDomains	HTTPS接続の強制（約2年間）
Content-Security-Policy	default-src ‘self’; …	リソース読み込み元の制限

CSP の設計方針

CSPでは default-src 'self' を基本とし、必要な外部リソースのみを個別に許可している。object-src 'none' でプラグインの読み込みを禁止し、base-uri 'self' と form-action 'self' でベースURLとフォーム送信先を制限している。

script-src と style-src には 'unsafe-inline' を許可している。Astro のビルド出力にインラインスクリプト・スタイルが含まれるため、現時点ではこの設定としている。将来的には nonce ベースの管理への移行を検討する。

キャッシュ制御

静的アセット（/assets/）にはハッシュ付きファイル名が付くため、immutable を付与した長期キャッシュを設定している。画像（/images/）には1日のキャッシュと stale-while-revalidate を設定し、更新時の配信遅延を最小限にしている。

CI/CD — GitHub Actions

main ブランチへの push をトリガーとして、以下のステップが自動実行される。

リポジトリのチェックアウト
Node.js のセットアップ（npm キャッシュ有効）
依存パッケージのインストール（npm ci）
Astro ビルド
Cloudflare Workers へのデプロイ（cloudflare/wrangler-action@v3）

GitHub Secrets には CLOUDFLARE_API_TOKEN と CLOUDFLARE_ACCOUNT_ID の2つを登録している。APIトークンは最小権限（Workers編集のみ）で発行した。

この構成により、コードを push するだけでビルドからデプロイまでが完了する。手動デプロイは緊急時のフォールバックとして npm run deploy を用意している。

運用コストと実績

月額コスト

Cloudflare Workers Free Plan の範囲で運用しており、月額は0円である。Free Plan のリクエスト上限は1日10万リクエストであり、コーポレートサイトの規模では十分な余裕がある。

DNS・SSL

ドメインのDNSは Cloudflare で管理しており、SSL証明書は Cloudflare が自動発行・更新する。Always Use HTTPS と HSTS を有効にしている。

今後の検討事項

CSP の unsafe-inline 排除: nonce ベースの管理に移行し、インラインスクリプト・スタイルの許可を段階的に撤廃する
Lighthouse スコアの継続的な計測: 現時点では手動計測にとどまっている。CI に Lighthouse を組み込み、デプロイごとのスコア変動を自動追跡する仕組みを検討している
Web Analytics の導入: Cloudflare Web Analytics の導入を予定している。クライアントサイドのスクリプトを追加しない方式であり、パフォーマンスへの影響が小さい

おわりに

Astro の静的ビルドと Cloudflare Workers の組み合わせは、コーポレートサイトの運用においてシンプルかつ合理的な選択だと考えている。worker.js を挟むことでセキュリティヘッダーを一元管理でき、GitHub Actions による自動デプロイで運用負荷も低い。

自社サイトの基盤選定で検討した内容が、同様の判断を行う方の参考になれば幸いである。

技術選定や品質改善の記録は今後も公開していく予定である。技術的な実装詳細は Zenn でも発信している。

本記事は2026年3月時点の構成に基づく記録である。今後の設定変更については、変更があり次第追記する。