今回のブログ構築トラブルを通じて、「日本語URL（A面・B面など）を扱う際のレンダリングモードの選び方」 について深い学びがあったので共有する。

結論から言うと、Cloudflare Pages × 日本語URL × Astro なら「動的（SSR）」が安定解 だ。

1. 静的生成（SSG / prerender = true）

Astroのデフォルトであり、ビルド時にすべてのHTMLファイルを作成しておく方式。

• メリット:
  • アクセス時の表示が爆速。
  • サーバー負荷がほぼゼロ。
• デメリット（日本語URLの罠）:
  • ビルドすると、サーバー上には A面.html や カテゴリー.html という物理ファイルが作られる。
  • しかし、ブラウザからのリクエストは A%E9%9D%A2（URLエンコード）で飛んでくる。
  • サーバー（特にCloudflare）によっては、この**「エンコードされた文字」と「実際の日本語ファイル名」のマッチングに失敗**し、ファイルがあるのに「404 Not Found」を返すことがある。

2. 動的生成（SSR / prerender = false）

アクセスがあった瞬間に、サーバー（Edge Worker）がプログラムを動かしてHTMLを作る方式。

• メリット:
  • 「ファイル名の不一致」が起きない。 プログラムがその場でURLを読み取り、「あ、これは『A面』のことですね」と解釈してページを作るため、文字コードのトラブルによる404を回避できる。
  • ビルド時間が短い（HTMLを量産しなくていい）。
• デメリット:
  • 設定が少し複雑（Adapterが必要）。
  • 無料枠の制限などを気にする必要がある（Cloudflareの場合はほぼ無視できるレベル）。

3. 今回の解決策：ハイブリッド構成

今回はトラブル回避のため、以下の構成を採用した。

1. モード: SSR（prerender = false）
   • 日本語URLの処理を確実にするため。
2. スタイリング: インラインスタイル（直接指定）
   • Tailwind CSSのビルド不整合を防ぐため、重要なレイアウト（グリッドや配色）は style="..." で直接HTMLに書き込んだ。

結論

「ブログは静的サイトで作るもの」という固定観念があったが、日本語をURLに使う場合、物理ファイルを作らないSSRの方が、実は管理が楽でエラーに強い ということが分かった。

「技術の常識」よりも「実際の挙動」を信じること。これがエンジニアリング（とAIとの協業）の鉄則だ。

（執筆協力：Gemini / 編集・監修：古老）