自社コーポレートサイト

Cloudflareを活用した自社サイト基盤の設計・構築

自社コーポレートサイトをCloudflareへ移行。静的配信と問い合わせ処理を分離し、GitHub Actionsで記事のプレビューから画像公開・デプロイまでを自動化しました。

対象： Markshipの自社コーポレートサイト

担当範囲： 移行設計、フロントエンドの移植、Cloudflare基盤構築、問い合わせ処理、GitHub ActionsによるCI/CD、記事のプレビュー・公開機能

Cloudflareによるサイト配信と、Workersで検証・保存・通知を順に行う問い合わせ処理の構成図

サイト配信と問い合わせ処理の主な構成

サイトの配信と更新運用を見直す

Webflowで運用していた自社サイトを、既存のデザインやURLを引き継ぎながら、AstroとCloudflareを用いた構成へ移行しました。ページ表示に加え、問い合わせの受付と通知、記事を確認してから公開する運用までを対象にしています。

通常のページ表示は静的配信で完結させ、入力の検証やデータ保存が必要な処理だけをWorkersで実行する方針としました。また、ソースコードと記事をGitHubで管理し、変更の確認から本番反映までを共通の手順で進められるよう整えました。

Astroで生成したHTMLやCSSをWorkers Static Assetsで配信し、記事画像はR2に保存しています。公開ページの閲覧ではWorkerの処理を起動せず、問い合わせAPIと認証付きプレビューへのアクセスをWorkerで処理する構成です。

問い合わせはTurnstileによる検証を経てD1へ保存し、その後にResendで担当者への通知と受付の自動返信を送ります。サイトの配信・データ保存にはCloudflareを使い、メール送信は外部サービスと連携しています。

メール通知の一時的な失敗で問い合わせ内容を失わないよう、D1への保存が完了してから受付成功を返す設計にしました。通知と自動返信の送信結果はそれぞれ記録し、失敗した処理をCronで再送します。

フォームにはTurnstileに加え、送信頻度の制限とサーバー側の入力検証を組み込みました。処理ログには受付番号や失敗の種別を残し、問い合わせ本文や連絡先を出力しないようにしています。

記事の変更をPRとして提出すると、GitHub Actionsがプレビューを生成し、画像とともに非公開のR2へ保存します。確認者は認証付きURLから実際のページを確認し、公開を承認した版をmainへマージします。

マージ後は記事画像を公開用R2へコピーし、成功した場合にサイトをビルド・デプロイします。画像だけが未公開のまま記事が反映されないよう、公開処理の順序を制御しました。

GitHub Actionsでプレビューを生成し、確認後のマージを起点に画像公開とサイトデプロイを順に実行する構成図

記事の確認・公開フロー。プレビューは問い合わせ処理と同じWorkerで提供しています。

原稿はMarkdownで管理し、ChatGPTやClaudeによる記事・画像の準備にも対応しています。専用の編集画面を増やさず、GitHubの変更履歴とPRを使って、人が確認してから公開する運用にしました。

プレビューと未公開画像は非公開R2に置き、Workerで認証した後に読み出します。プレビューには検索避けとキャッシュ抑制の設定を付け、記事内のスクリプト実行やフォーム送信も無効にしています。

PRのビルドには本番や画像保存用の秘密情報を渡さず、プレビューの保存はmain上の処理で行います。対象PRとコミットを照合し、古い版の成果物を最新のプレビューとして扱わないようにしました。

DNS・D1・R2・TurnstileなどのCloudflareリソースをTerraformで管理し、アプリケーションの反映はGitHub ActionsとWranglerで行う構成にしました。

コード変更時は型検査・ビルド・テストを行い、記事だけの変更ではビルドと原稿・画像参照の検査を中心に実行します。本番デプロイ前には設定値と接続先D1を確認し、データベースのマイグレーションを実行する手順も組み込んでいます。

移行時は画面幅ごとの画像比較と操作テストを行い、既存サイトのレイアウトや動作を確認しながら移植しました。

対応実績一覧へ