WordPress を捨てて Astro にした話【Claude Code】

数週間前、Claude にリサーチを頼んで「個人ブログを WordPress から独自サイトに移すべきか」を調べてもらいました。結論は「今は移行しない、コンテンツを増やすほうが先」。 それなのに、結局 Astro に移しました。今この記事も Astro 版のサイトで公開されてます。

なぜ「やめておけ」と自分でまとめた直後に移行したのか、そして移行してみて何が変わったのか。Claude Code を使った個人ブログ移行の実体験としてまとめます。

「移行しない」が合理的だった、はずだった

リサーチで出てきた結論は割と明確でした。

• 記事10本未満の段階では、SEO 順位を決めるのは表示速度よりコンテンツ品質
• WordPress でも Core Web Vitals はチューニング次第で改善できる
• 移行には20〜40時間かかる。同じ時間で記事を4〜8本書いたほうが早い
• Claude Code + WordPress REST API ですでに記事公開できている

数字だけ見れば「今は移行する場面ではない」が正解です。実際、調査してすぐ「次の記事ネタを探す」ほうに動こうとしていました。

---

それでも移行に踏み切った 2 つの実感

合理性を引っくり返したのは、リサーチには出てこない肌感覚でした。

1. Claude Code と WordPress の相性が悪い

一番大きかったのはこれです。

Claude Code でブログのデザインを少し触ろうとしたとき、CSS の変更が一部だけ反映されなかったり、プラグインのキャッシュで差分が見えなかったりする場面が何度もありました。Claude が「直しました」と言っているのに画面は変わらない。やり直す、また反映されない、結局 WordPress 管理画面でキャッシュをクリアして手動で確認する、というループ。

AI に任せたかったはずの作業で、こちらが管理画面に入って手で詰めないと進まない。これが地味にストレスでした。

「AI 駆動で運用するための土台」と「WordPress のプラグイン依存」は、相性が悪い。これがまず一つ目の実感です。

2. テーマから出たかった、ツール拡張も視野に入れたかった

もう一つは、見た目とこの先の機能の自由度です。

WordPress テーマ（GeneratePress 子テーマ）に乗っているうちは、「テーマができる範囲」で発想を組み立てる癖がついていました。テーマ側で予約されている class を避けたり、独自 CSS を上書きしたり。

Astro に移してからは、src/pages/ と src/components/ を直接触る形になり、「テーマができることの中でやる」ではなく「やりたいことから作る」に変わりました。逆に、好きな見た目を出すのがラクになった、という感覚です。

それから、これから作りたい LoL や SF6 のツール（OPGG みたいな統計サイト）を考えると、WordPress の中に押し込むより、Astro と Cloudflare Workers の組み合わせのほうが自然だろうという判断もありました。サブパス（/lol/tool/、/sf6/tool/）で増やしていけるので、ドメインの SEO 資産を分散させずに済みます。

---

採用したスタックと、捨てたもの

最終的に組んだのはこんな構成です。

層	採用	役割
フロントエンド	Astro 6（SSG）	記事と固定ページの静的生成
ホスティング	CoreServer（静的ファイル）	kanalyzelab.com を配信。SCP デプロイ
動的 API	Cloudflare Workers + Hono（予定）	ツールページの動的処理（将来）
データ生成	CoreServer Python cron	YouTube/Twitch API からデータ取得 → JSON 生成
デプロイ	bash + scp スクリプト	deploy.sh staging/prod で配信

検討して捨てた選択肢もありました。

• Vercel + microCMS: ドメインを Cloudflare 経由に切り替える手間と、CoreServer の固定費がすでにある事情を考えて見送り
• Next.js + SSR: ブログには重い。SSG 主体なら Astro のほうが噛み合う
• Hugo: 学習コストとテンプレートエンジンの癖。Astro のコンポーネント志向のほうが Claude Code との相性が良さそうだった

要は「すでにある CoreServer の資産を捨てず、追加で動的部分だけ Cloudflare に逃がす」というハイブリッド構成です。Vercel のような派手な構成ではないけれど、固定費が増えないのが大きい。

---

移行で「やっと整理できた」2 つのこと

詰まった話を書こうとしたのですが、振り返ると「詰まり」よりも「整理できた」感覚のほうが残っていました。Astro に移したことで、WordPress 時代にずっとモヤッとしていた部分がスッとほどけた、というほうが正確です。

1. ディレクトリ構成が素直になった

WordPress 時代に変更箇所を探すとき、wp-content/themes/{テーマ名}/ の下に潜って、functions.php か style.css か、はたまた inc/ のどこか、と何度もファイルツリーを行ったり来たりしていました。

Astro はそこが直接的です。

src/
├── pages/         ← URL がそのままここのパスに対応
│   ├── blog/index.astro
│   ├── claude-code/[slug].astro
│   └── vspo/tool/index.astro
├── components/    ← 再利用パーツ
├── layouts/       ← ベース＆記事レイアウト
└── content/articles/  ← 記事 Markdown

「/claude-code/getting-started/ を直したい」と思ったら、src/pages/[category]/[slug].astro か src/content/articles/getting-started.md を見ればいい。階層が浅く、URL とファイル位置がそのまま対応します。

途中、astro/ というフォルダ名を frontend/ にリネームしたかっただけで Move-Item が「別プロセスで使用されている」と弾かれ、PC を再起動するハメになりました。それでも「将来 api/ や data-jobs/ を兄弟ディレクトリに置くつもりだから、astro/ のままだと意味が狭い」とハッキリ気づけたのは、Astro 移行の副産物だったと思っています。

2. URL とカテゴリ階層が分けられた

WordPress では「カテゴリ階層 = URL 階層」が標準でした。「LoL」と「SF6」を「ゲーム」配下にまとめると、URL も /game/lol/... になる。逆に URL を /lol/... にしたいなら、ナビ上のグループ化もあきらめるか、プラグインで URL リライトをひねり出すかの二択でした。

Astro なら、ナビ上の階層と URL の階層を別々に設計できます。

表示（ナビ）	URL
AI ▾ Claude Code / Codex	/claude-code/, /codex/
資産形成 ▾ 副業 / 投資	/side-job/, /investment/
ホビー ▾ LoL / SF6 / VSPO / ライフスタイル	/lol/, /sf6/, /vspo/, /lifestyle/

ナビゲーションは「AI / 資産形成 / ホビー」の3グループでコンパクトに、URL は全部フラットで意味のあるパス。src/lib/categories.ts に階層関係を書いて、getCategoryUrl() がフラット URL を返すだけ。プラグインも .htaccess の魔法もいりません。

---

これから書き溜めて、AdSense・ツール拡張へ

ここまで来て、ようやく本来やりたかった作業の土台ができた感じです。ただ、今この記事を含めても公開記事はまだ 5 本。AdSense の審査は記事数の明文基準こそないものの、現実的には 10〜20 本くらいの厚みがないと厳しいと言われている領域なので、まずは記事を書き溜めるフェーズに戻ります。

直近のロードマップはこんなイメージです。

• 記事執筆を再開: 下書きで止まっている 4 本（Canva 連携、Claude × Codex 同時利用、ChatGPT 差分画像、スマホ × Claude Code）を仕上げて、新規も書く
• AdSense 申請: 記事数とサイト運用が安定してから申請。プライバシーポリシーとお問い合わせページは移行と同時に整備済み
• LoL / SF6 のツール: /lol/tool/ 配下に BP 分析やアイテム検討のツール、/sf6/tool/ にリプレイ DB 閲覧。Astro + Cloudflare Workers で組む

正直に言うと、運用コストの本当のメリットは「ツールを拡張したとき」に初めて見えると思っています。WordPress に LoL の対話型ツールを乗せようとしたら、プラグイン地獄になっていたはずです。そこは数ヶ月後の自分が一番分かる話なので、また書きます。

---

まとめ：個人ブログ移行の判断軸

判断の材料として、自分が今振り返って「ここで決めるとよかった」と思うポイントを並べます。

• SEO だけで決めない: CMS は Google の評価対象ではない。順位を決めるのはコンテンツの中身
• AI 駆動で運用したいなら静的サイトが噛み合う: プラグインのキャッシュや管理画面操作が AI から見えない地点にあるのはノイズになる
• テーマの中で完結しているうちは WP のままで十分: ナビ・URL・見た目を自由に組みたくなったら検討時期
• ツール拡張の予定があるなら早めに動く: 後から WP からツール用に剥がすのは、最初から静的サイトで組むより重い
• 記事数の閾値だけで判断しない: 自分は記事 10 本未満で移行したが、後悔はしていない

「移行するべきか」の答えは「コンテンツの体積」だけでは決まらない、というのが今のところの実感です。リサーチが間違っていたわけではなく、自分の運用スタイル（Claude Code + 静的サイト + ツール拡張）を前提に置き直すと、答えが変わった、という話でした。

---

KanalyzeLab — データ×AIで好きをカタチに