選定理由#

fuwari（Astro） WordPress（PHP）は動的にページを生成するぶん、サーバーの処理とセキュリティ管理が重くなります。対してAstroは事前にHTMLを吐き出すSSGなので、軽量で速く、攻撃される面も少なくなります。テーマの見た目が好みだったのも大きいです。

Volta Node.jsのバージョン管理ツールです。Rust製で動作が速いのと、プロジェクトごとに使うバージョンを自動で切り替えてくれるのが楽です。正直この用途なら他のツール（nvm, fnm等）でも問題ないと思います。流行ってるので採用しました。

GitHub 言わずもがな。今回は特にソース管理より、GitHub Actions（自動ビルド・デプロイ）の働きが主役です。

Cloudflare Workers 当初はCloudflare Pagesを使う予定でしたが、Cloudflareが新規プロジェクトの推奨をPagesからWorkersに移しています。今から作るならWorkers一択です。

wrangler CloudflareのCLIツールです。Workers/Pagesへのデプロイやログの確認などができます。GitHub Actionsからのデプロイにも内部的に使われています（wrangler-action）。

GitHub CLI（gh） GitHubの操作をターミナルから完結させるCLIツールです。リポジトリの作成やPRの操作がブラウザを開かずにできます。今回はリポジトリ作成に使いました。

1. fuwariのセットアップ#

fuwari はAstro製のブログテーマで、Node.jsで動きます。自分の環境では、Node.jsのバージョン管理にVoltaを使用しました。

fuwariはNode.js 22、pnpm 9を指定しているので、それぞれインストールします。

1
volta install node@22
2
volta install pnpm@9

インストールできたらcreate-fuwariを使って、ローカルにプロジェクトを初期化します。

1
pnpm create fuwari@latest

src/config.ts でサイト名・プロフィール・テーマカラーを設定します。

2. Cloudflare Workersの準備#

Cloudflare Workersは、Cloudflareのネットワーク上でコードの実行や静的ファイルの配信ができるサービスです。今回はその中の「Static Assets」という静的ファイルを配信する機能だけを使います。Astroがビルドした成果物（HTML/CSS/JS）を世界中に高速配信する置き場として利用するイメージです。

まず、操作に使うCLIツールwranglerを導入します。グローバルに入れると環境ごとにバージョンがブレるので、プロジェクトのdevDependenciesに入れてpackage.jsonでバージョンを固定します。これでcloneした別の端末でも同じバージョンが使えます。

1
pnpm add -D wrangler

導入できたらログインします。pnpm wranglerでプロジェクトのwranglerを実行できます。

1
pnpm wrangler login

リポジトリのルートにwrangler.tomlを置き、配信するフォルダを指定します。

1
name = "fuwari"
2
compatibility_date = "2025-01-01"
3
workers_dev = true
4

5
[assets]
6
directory = "./dist"   # Astroのビルド出力先

この時点で一度、手元から手動デプロイして動作確認します。

1
pnpm run build     # dist/ を生成
2
pnpm wrangler deploy  # Workersにアップロード

成功すると https://プロジェクト名.アカウント名.workers.dev でアクセスできます。

3. GitHubにpush#

ローカルで動作確認ができたら、GitHubにリポジトリを作成してソースコードをpushします。後でGitHub Actionsに自動ビルドさせるための土台になります。

リポジトリの作成にはGitHub CLI（ghコマンド）を採用しました。

1
gh repo create fuwari --public   # 公開リポジトリを作成
2
git add .
3
git commit -m "initial commit"
4
git push origin main

4. GitHub Actionsで自動デプロイ#

ここがこの仕組みの核心です。GitHub Actionsは、リポジトリへのpushなどをきっかけに、ビルドやデプロイといった作業を自動実行してくれる機能です。

mainブランチにpushされたら「依存パッケージのインストール → Astroでビルド → Cloudflareへデプロイ」を自動で走らせるよう設定します。

リポジトリに.github/workflows/deploy.ymlを作成し、以下を記述します。

1
name: Build & Deploy
2

3
# mainへのpushで起動
4
on:
5
  push:
6
    branches: [main]
7

8
jobs:
9
  deploy:
10
    runs-on: ubuntu-latest
11
    steps:
12
      # リポジトリを取得
13
      - uses: actions/checkout@v4
14

15
      # pnpmを準備
16
      - uses: pnpm/action-setup@v4
17

18
      # Node.jsを準備（.node-versionファイルからバージョンを読む）
19
      - uses: actions/setup-node@v4
20
        with:
21
          node-version-file: .node-version
22
          cache: pnpm
23

24
      # 依存パッケージをインストール
25
      - name: Install dependencies
26
        run: pnpm install --frozen-lockfile
27

28
      # Astroでビルド（dist/を生成）
29
      - name: Build
30
        run: pnpm run build
31

32
      # wranglerでCloudflareへデプロイ
33
      - name: Deploy to Cloudflare Workers
34
        uses: cloudflare/wrangler-action@v3
35
        with:
36
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
37
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

最後のsecrets.〜は、APIトークンなどの秘密情報をyamlに直書きせず、GitHubに安全に保管して呼び出す仕組みです。リポジトリの Settings → Secrets and variables → Actions から登録します。

5. カスタムドメインの設定#

nonrem.net はすでにCloudflareで管理しているドメインなので、Workersのダッシュボードから追加するだけでDNS設定まで自動でやってくれます。

Workers & Pages → fuwari → Settings → Domains & Routes → Add Custom Domain

ここに nonrem.net を入力して保存するだけです。Cloudflareが管理しているドメインであれば、CNAMEレコードの追加などは不要で、数分後には https://nonrem.net でアクセスできるようになります。

他社のDNSサービスを使っている場合は、手動でCNAMEレコードを追加する必要があるので注意してください。

fuwariのビルドバグ（CSS処理順の問題）#

pnpm run build を実行したら即エラーが出ました。

1
The `link` class does not exist.
2
If `link` is a custom class, make sure it is defined within a `@layer` directive.

最初はCSSの書き方を間違えたのかと思いましたが、調べてみるとfuwari自体の問題でした。

fuwariのCSSはこういう構造になっています。

• main.css … @layer components の中で .link クラスを定義
• markdown.css … @apply link でそのクラスを参照

Tailwind v3はCSSファイルを個別にPostCSS処理します。ビルド時のファイル処理順序がランダムになることがあり、markdown.css が main.css より先に処理されると .link クラスがまだ定義されていないためエラーになります。毎回起きるわけではなく、ローカルの開発サーバーでは気づきにくいですが、本番ビルドで顕在化しやすい不安定な挙動らしいです。

同じ問題はfuwariのGitHubにも複数報告されており、PR#738 で修正パッチが提案されていました。

修正は src/styles/markdown.css の先頭に1行追加するだけです。

1
@import "./main.css";   /* ← これを追加 */
2

3
.custom-md {
4
  /* ... */
5
}

postcss-import が @import を先に解決するので、必ず main.css → markdown.css の順で処理されるようになります。

Node.jsとpnpmのバージョン固定#

GitHub Actionsでビルドが走ったとき、環境によってはNode.jsのバージョンがローカルと違うことがあります。バージョンを明示していないと「ローカルでは動くのにCI環境でだけ謎のエラーが出る」という事態になりやすいです。

そこで .node-version ファイルをリポジトリルートに置き、使うNode.jsのバージョンを1ファイルで管理します。

1
22

前述のワークフローでは actions/setup-node の node-version-file でこのファイルを参照させているので、バージョンを変えたいときはこの1ファイルを直すだけで済みます。

package.json の engines フィールドも合わせて設定しておくと、意図しないバージョンでのインストールを弾けて確実です。

1
"engines": {
2
  "node": ">=22",
3
  "pnpm": ">=9"
4
}

pnpmのバージョン二重指定に注意#

GitHub Actionsで pnpm/action-setup@v4 を使うとき、以下のように version を明記するとエラーになります。

1
# NG
2
- uses: pnpm/action-setup@v4
3
  with:
4
    version: 9   # package.jsonのpackageManagerと競合してエラー

package.json の packageManager フィールドに pnpm@9.14.4 のように書いてあれば、version は省略でOKです。action-setupがそこから自動で読んでくれます。

今後やりたいこと#

• OGP画像の自動生成
• 記事をちゃんと書く