Cloudflare に置いた個人サイトの構成メモ

結論

kimura512.dev は Cloudflare 上で、ビルド成果物と Worker に寄せて運用しています。サーバーを自分で立てず、更新はデプロイコマンド一つにまとめられます。Next.js アプリは vinext で Workers に載せ、記事データはリポジトリ内の TypeScript に置いています。

1. デプロイ

本番は pnpm run deploy（build + wrangler deploy）です。本番 URL は apex に固定し、preview 用 Worker を本番 DNS に向けないよう、デプロイ前に wrangler の設定名を二重確認します。手作業を減らすほど、設定ミスによる事故は起きにくくなります。

2. 画像

ブログのヒーロー画像は public/blog/ に置き、sharp で幅を揃えています。一覧ページのカード高さが揃うと、見た目のばらつきが減ります。以前は外部ストレージの直リンクに依存していた部分を、リポジトリ配信に寄せました。外部の障害や URL 変更で記事画像が消えるリスクを下げるためです。

3. セキュリティ

WAF と HTTPS を前提に、秘密情報は Workers のシークレットのみに置きます。API 用のサブドメインはトップからリンクせず、公開したくない入口をサイトの主導線から外しています。リポジトリや設定ファイルに平文の鍵を書かないのは、最低限のルールです。

4. キャッシュ

記事を更新したあとは、シークレットウィンドウで一覧件数と本文を確認します。ブラウザや CDN のキャッシュが残っていると、更新が反映されていないように見えることがあります。記事の正本は git で、posts.ts の差分がそのままデプロイ内容になる理解を固定しました。

5. コスト

画像は圧縮し、重い 3D 背景はトップと About だけに限定しています。全ページで同じ重い演出を使うと、モバイルでは体感速度が落ちます。読み込みが軽いページを増やす方が、離脱を抑えるうえでも効きます。

6. ログ

Workers のログは短期間しか残らないため、障害の内容はブログやメモに再現手順を残します。同じ問題に再び当たったとき、過去の記録があると調査が早くなります。

7. wrangler と環境

preview 用の Worker 名を本番と分け、誤デプロイを防ぎます。secrets は wrangler secret put でだけ登録し、平文をチャットに貼らない運用です。環境ごとに名前を分けると、どの環境に出したかを取り違えにくくなります。

8. サブドメイン

別プロダクト（Jev など）は外部リンクのままにし、dev 用の入口はトップからリンクしません。運用対象を apex の公開コンテンツに集中させるためです。サブドメインが増えるほど、DNS と設定の管理コストも増えます。

トップの 3D 背景や About の演出は、初見の印象用に残していますが、ブログ一覧は軽いレイアウトに寄せています。パフォーマンスと見た目のバランスは、ページごとに要件が違うので、一律に重くしない方針です。デプロイ後はモバイル幅でも一度スクロールし、体感速度を確認します。

まとめ

Worker は配信層、コンテンツの元データは git、記事本文は posts.ts に置く、という役割分担で運用しています。どこを直せばよいかで迷ったとき、この分担が効きます。

補足

Q. なぜ Workers？

静的ページと軽い API を一つのスタックで扱えるためです。個人サイトでは、管理するサービスの種類が少ないほど負担が軽くなります。

Q. R2 は使う？

ブログ画像は public に寄せ、R2 は別プロダクト用です。用途ごとにサービスを分けると、設定の影響範囲を追いやすくなります。

Q. ビルドはどこで？

ローカルで pnpm build を通してからデプロイします。CI で同じコマンドを回すようにして、手元と本番の差を減らしています。

環境変数は Workers のシークレットに寄せ、リポジトリには例だけを置きます。キーを記事に書くことはありませんが、どの機能がどの秘密に依存するかは README に残しています。

カスタムドメインを Workers に向けたあとは、古いホストのリダイレクトが残っていないか一度だけ確認します。二重リダイレクトは SEO と審査の両方でノイズになります。