posted:

ブログをCloudflare Pagesによる静的サイトへ移行

カテゴリ： blog / ai

ここ数年、ブログを静的サイトにしたという記事を時々見かけるようになって、気にはなっていた。ただ、それほどマメにブログを更新しているわけでもないし、移行の手間に見合わなさそうとも思っていた。Astroのような新しいツールについて学ぶ必要もありそうだし、従来のブログを新しい仕組みで再現するのも面倒そうだ。できれば記事URLはすべて維持したかったし、画像も引き継ぐ必要がある。そうなると、リンクなどもいちいち確認しないといけない。

しかしここしばらくCodexを使ってみて、「もしかしたら静的サイトへの移行も、かなり自動化できるのではないか」と思うようになった。実際にやってみると、Codexが予想以上に賢い。CLIから大量の修復作業や変換作業をまとめて任せられるのも良い。昔なら気が遠くなりそうだった作業が、かなり現実的な手間で進んでいく。

せっかくなので、今回の移行手順や、やってみて分かったことをまとめておく。

なぜ静的サイトへ移行したかったのか

もともとの binWord/blog は、かなり古いWordPressベースのブログだった。2003年から続けていたので、記事数もそれなりにあるし、古いトラックバック文化の痕跡や、昔のAmazonアフィリエイト、画像リンク、さらに古いMovable Type時代の名残なども大量に混ざっている。

WordPress自体には大きな不満はなかったのだが、長年運用していると、どうしても次のような問題が気になってくる。

  • PHPやプラグインの更新
  • セキュリティ対策
  • MySQLやサーバ管理
  • 古いプラグインの互換性
  • バックアップ
  • スパム対策
  • WordPress特有の肥大化

特に最近は、単純な「文章公開システム」として考えると、静的HTMLの方がずっとシンプルなのではないかと思うようになった。

Cloudflare Pagesのようなサービスを使えば、静的HTMLを世界中のCDNから配信できる。しかも無料枠がかなり強い。

また、記事本体をMarkdownで持っておけば、将来的に別システムへ移行するのも比較的楽になる。WordPressのDBにロックインされない。

使用した構成

最終的に、次のような構成になった。

Astro
+ Markdown
+ GitHub
+ Cloudflare Pages
+ Pagefind
+ giscus

つまり、

Markdownを書く
↓
GitHubへpush
↓
Cloudflare Pagesが自動build
↓
静的HTML公開

という構成である。

検索にはPagefindを利用した。これは静的サイト向けの全文検索システムで、クライアント側だけで検索が完結する。Cloudflare Pagesとの相性も良い。

コメントは、旧WordPressコメントはJSON化して静的表示し、新規コメントはgiscusを使う形にした。giscusはGitHub Discussionsをコメントバックエンドとして使う仕組みで、静的サイトでも比較的簡単にコメント機能を追加できる。

WordPressの記事データをMarkdown化

WordPress側から、まずXMLエクスポートを行った。

binwordblog.WordPress.2026-04-23.xml

のようなファイルである。

その後、wordpress-export-to-markdown を利用してMarkdown化した。

ここでかなり重要だったのが、「記事URLを維持する」ことだった。

私の旧ブログは、かなり古い形式で、

/blog/archives/%postname%.html

というURL構造になっていた。

最近の静的サイトジェネレータは、

/post-name/

のような「ディレクトリ型URL」を前提にしていることが多い。しかし今回は、できる限り旧URLを維持したかった。

結果的には、Astro側で、

src/pages/blog/archives/[id].astro

のような特殊なルーティングを行い、build.format: 'file' を使うことで、

/blog/archives/000004.html

形式を維持することができた。

このあたりは、ChatGPTと相談しながらかなり試行錯誤した。

画像リンク修復が最大の難所だった

実際にやってみて、一番大変だったのは画像だった。

20年以上前の記事になると、画像リンクがかなり壊れている。

例えば、

  • Amazonアフィリエイト画像
  • 小さなバナー
  • 外部サイト画像
  • 昔のHTMLラッパー
  • URLエンコードされた画像名
  • .html を経由して実画像へ飛ぶ古い構造

などが大量に混ざっていた。

最初は手で直そうと思ったのだが、途中で諦めた。

ここで活躍したのがCodexだった。

例えば、次のような処理をCodexにかなり自然言語寄りで指示できる。

  • buildエラーになった画像を特定
  • WordPressのアップロードフォルダから実画像を探す
  • 記事ごとの images/ ディレクトリへコピー
  • Markdownの画像リンクを書き換え
  • 壊れたAmazon iframeを除去
  • .html 経由の画像リンクを実画像へ変換

実際、Codex作業ログを見ると、

  • 300件の画像リンク修復
  • 207件の画像コピー
  • 43件の .html ラッパー修復
  • Amazon画像の再取得
  • 31件の古いiframe削除

などを自動処理している。

このあたりは、「CLIでAIへ作業を渡せる」ことの強みをかなり感じた。

コメントとトラックバック

WordPress XMLには、昔のコメントも入っていた。

ただし、トラックバックやPingBackも大量に混ざっている。2000年代前半のブログ文化の名残である。

これらはJSON化し、

src/data/wp-comments.json

として扱うことにした。

ただ、トラックバックは今見るとノイズがかなり多い。結局、

  • <strong> で始まる
  • binWord/blog 名義
  • 引用だけの短い内容

などを条件に、かなり整理した。

固定ページもMarkdown化

about.html や works.html のような固定ページも、最終的にはMarkdown管理へ移行した。

src/content/blog/pages/about/index.md
src/content/blog/pages/works/index.md

のような形である。

これによって、「ブログ」と「固定ページ」が、同じMarkdown資産として扱えるようになった。

検索、RSS、カテゴリ、月別アーカイブ

単純に記事本文だけ移行しても、実際には「昔のブログらしさ」はかなり失われる。

そのため、

  • カテゴリ別一覧
  • 月別アーカイブ
  • RSS
  • Atom
  • コメントRSS
  • 前後記事リンク
  • Pagefind全文検索

なども再現した。

また、旧WordPress形式のカテゴリURLや月別URLについては、Cloudflare Pagesの _redirects を使って301リダイレクトを追加した。

静的サイト化して良かったか

今のところ、かなり満足している。

もちろん、WordPressの「管理画面から何でもできる便利さ」は失われる。しかし、その代わり、

  • Gitで履歴管理
  • Markdownが正本
  • DB不要
  • セキュリティリスク減少
  • AIとの相性が良い
  • 検索しやすい
  • 将来的な再利用がしやすい
  • CLIから操作できるので、自分で好きなように自動化していける

というメリットが大きい。

特に、MarkdownとGitHubをベースにすると、AIツールとの相性が非常に良い。CodexやChatGPTに対して、

このfrontmatterを直して
このリンクを修復して
このカテゴリを整理して

のような自然言語指示がかなり通る。

「ブログを書く」というより、「テキスト資産を長期管理する」感覚に近くなった気がする。

以前は「静的サイト化は面倒そう」と思っていたのだが、AI時代では事情がかなり変わってきているとも感じた。少なくとも今回の移行に関しては、「AIに作業を分担させながら段階的に直していく」という進め方がかなり有効だった。

コメント