2724 文字
14 分
Claude Codeと一緒にブログをVuePressからAstroに引っ越した話
2026-04-14
automation
Astro
/
VuePress
/
Fuwari
/
ClaudeCode
/
サイト移行
/
SEO
この記事について

Claude（Anthropic）との共同編集により作成されました。

要約
  • LCP 9.6秒という計測結果を見て、VuePressのSPA構造が根本原因だと判断した
  • SSGはAstroを選択。テーマはAstroPaperとFuwariで悩んだ末にFuwariへ
  • Claude Codeとhikkoshi_plan.mdを使ってTODO管理しながら一気移行した
  • 残タスクは動的OGP（Satori）のみ。ほぼ完走した

きっかけは PageSpeed Insights を眺めていたときの一行だった。

LCP: 9.6秒

モバイルのパフォーマンススコアは66。「要改善」という帯が出ていた。SEOスコアは100で、記事の内容には自信があった。それだけに「パフォーマンスで損している」という感触が気持ち悪かった。

なぜ引っ越すことにしたか#

計測結果の概要#

指標モバイルデスクトップ
パフォーマンス66（要改善）85
ユーザー補助9091
おすすめの方法9696
SEO100100

LCPは9.6秒。Googleの基準では4.0秒超が「不良」とされている^6。デスクトップとモバイルのスコア差が大きく、VueのJSを実行するコストがモバイル端末で顕著に出ているのは明らかだった。

根本原因#

VuePressはSPA（Single Page Application）として動作する。初期HTMLはほぼ空で、Vueが起動してからコンテンツを描画する構造だ。テーマを替えても、この構造は変わらない。

  • 流入のほぼ全てが検索経由
  • GoogleはモバイルファーストインデックスのためモバイルのCore Web Vitalsを重視する
  • SEO 100（オンページSEOは完璧）なので、パフォーマンス改善でそのまま順位向上につながりやすい状態

「コンテンツは良いのにパフォーマンスで損している」。これは移行の必要十分条件だった。

移行の前提#

無理に急ぐことはしない、という判断から始めた。現状のGitLab→Netlifyのデプロイ構成は問題なく動いている。一気移行ではあるが、まずテストサイトで作り込んでから本番に切り替えるフローにした。

SSG選定：なぜAstroか#

選択肢はいくつかあった。

SSGJS量検索タグ学習コストPageSpeed見込み
AstroほぼゼロPagefindで簡単Content Collections中95+
Hugoゼロ別途設定Taxonomy（標準）高（Goテンプレ）95+
Eleventyゼロ別途設定自前実装低95+
Nextra多め（React）Pagefind標準自前実装低（React前提）80〜90

HugoはGoテンプレート構文の学習コストが高い。EleventyはタグやカテゴリをすべてJavaScriptで自前実装する必要がある。NextraはReact依存でJS量が増える。

Astroが本命だった理由を端的に言うと、Islands Architecture によってデフォルトのJS出力がほぼゼロであること、Pagefindによる日本語対応済みサイト内検索を10分程度で導入できること、そしてContent Collections で記事を型安全に扱えることの3点だ^1。

Netlifyとの公式パートナーシップがあり、既存のGitLab→Netlify構成をGitHub→Netlifyに置き換えるのもスムーズだという情報もあった。

テーマ選定：AstroPaperとFuwariで悩んだ話#

Astroに決めた後、テーマ選定で少し立ち止まった。候補は2つに絞られていた。

AstroPaper#

GitHub スター数は3,500超^3。SEO を強く意識したシンプルな設計で、ファジー検索（Fuse.js）を内蔵している。実績も多く、Astroテーマの中では最も信頼できる選択肢の一つだった。

ただ、デザインを見ていて引っかかったことがある。

  • 記事一覧でクリックできるエリアがタイトルテキストのみ（カード全体がクリッカブルでない）
  • フラットなリストUI。カード型でない
  • サイドバーがない。カテゴリやタグは別ページで確認する形

「ゆるディープ」の旧デザインはサイドバーがあって、カテゴリとタグを常時表示していた。それを捨てるコストを考えると、AstroPaperに乗り換えることのメリットとトレードオフが気になってきた。

Fuwari#

saicacaさん制作のFuwari^2は、カード型UIとサイドバーを標準で持っている。カテゴリとタグも標準搭載。デザインは以前から好みで、「これに近いものにしたい」というイメージがあった。

比較してみたときに出た結論がこれだ。

AstroPaperをFuwari風にカスタマイズするコストが、FuwariをそのままAstroベースで使うコストより明らかに高い。

どちらも個人開発で、メンテナンスが止まるリスクは同等。ならば「デザイン資産がある」という点でFuwariのほうがフォークして維持しやすいとも判断した。

Fuwariに決定。

Claude Codeを使った進め方#

ドキュメントをソースにする#

移行にあたって hikkoshi_plan.md というファイルを作り、要件・前提・計測結果・SSG比較・テーマ選定結論・移行方針・TODOを一元管理した。Claude CodeにはこのファイルをAnchored Contextとして参照させ、「今どこまで終わっているか」「次は何をすべきか」をTODOチェックリストで共有しながら進めた。

ドキュメントが「仕様書兼進捗ボード」として機能することで、会話をまたいでもコンテキストが失われにくくなった。

TODOを一つずつ潰す#

実際のTODOリストはこうだった（hikkoshi_plan.md から引用）:

- [x] GitHubにhiranormアカウントでリポジトリ作成（yurudeep）・clone済み
- [x] Fuwariを入れてテストサイト立ち上げ
- [x] 既存記事を全カテゴリ（deeplearning / automation / other）移行
- [x] Fuwariのサンプル記事を除去（draft / expressive-code / guide / markdown / video）
- [x] Aboutページをひらノルム用に更新
- [x] 動作確認・表示確認（パフォーマンス良好）
- [x] Netlifyのデプロイ連携を新リポジトリに切り替え（yurudeep.comで本番確認済み）
- [ ] 動的OGP実装（Satori）

記事の移行はFuwariの形式（published / category / tags の構造）に合わせてフロントマターを書き換える作業が発生した。旧VuePressの形式（date / categories / prev / next）との差異をClaude Codeに整理してもらいながら、カテゴリごとに順番に処理した。

サンプル記事の除去やAboutページの更新は、Claude Codeに既存ファイルを読ませてから編集を指示する形で進めた。「いったん読んでから判断する」というステップをClaude Code自身が取るため、既存の構造を壊さずに変更できた。

ビルド & デプロイ構成#

npm run build を実行すると、以下が順番に動く:

Terminal window
astro check        # TypeScript型チェック
astro build        # dist/ へ静的ファイル生成
pagefind --site dist  # Pagefindで検索インデックス生成
cp -r dist/pagefind public/  # 検索用ファイルをpublicへコピー

デプロイはNetlifyがGitHubリポジトリを直接監視している。git push するだけで自動ビルド＆デプロイが走る^5。GitLabからGitHubへの移動もNetlifyの設定をリポジトリの向き先を変えるだけで完了した。

sitemapの引き継ぎ#

移行後に対応が必要だったことがもう一つある。sitemap だ。

旧VuePressサイトは sitemap.xml を生成していた。Googleはこれを認識してインデックスを管理していたが、Astroに移行するとsitemapのURLが変わる。AstroのSitemap統合が生成するのは sitemap-index.xml という形式で、旧サイトの sitemap.xml とは別物になる^8。

対応したのは2点。

① 旧sitemapのURLから新sitemapへのリダイレクト

Netlifyのリダイレクト設定（netlify.toml または public/_redirects）に以下の内容を追加した：

/sitemap.xml  /sitemap-index.xml  301

旧URLにアクセスしてきたクローラーが新sitemapへ飛ぶようになる。

② Google Search Consoleへの登録

Search ConsoleのSitemapセクションで sitemap-index.xml を新たに登録した。旧 sitemap.xml はそのまま残しておき、しばらく様子を見る。

この2つで「Googleが旧サイトのsitemapを見続ける」という状態を解消できた。移行直後は検索クローラーが旧インデックスをもとに動くため、sitemapを正しく引き継ぐことはSEOを維持するうえで地味に重要な作業だった。

残タスクと後回しにしたこと#

現時点で残っているのは動的OGP実装のみだ。

Satori（@vercel/og^7）を使って、ビルド時に記事タイトル入りのOGP画像を生成する仕組みを入れたい。SNSでシェアされたときのカード表示が変わる。優先度は高いが、本番切り替えとは独立したタスクなので後回しにした。

人気記事ランキング（WalineまたはGoogle Analytics Data APIでPV取得してサイドバーに表示）は優先度低で後々の実装とした。

移行してみて#

パフォーマンスの改善は、計測しなくても体感でわかった。ローカルの開発サーバー（npm run dev → localhost:4321）でのページ遷移が明らかに速くなっていた。

Claude Codeとの共同作業で助かった点は大きく2つある。

一つは調査の圧縮だ。SSGの比較やPagefindの日本語対応状況、Netlifyの連携手順など、単体で調べると時間がかかることをClaude Codeに整理してもらいながら進められた。

もう一つは「いったん読んでから動く」という作業スタイルが自然に定着したことだ。Claude Codeは既存ファイルを確認してから編集するため、こちらも「何を変えるか明確にしてから指示する」という習慣が身についた。

迷いが残っているのはFuwariのメンテナンスリスクだ。個人開発テーマはいつ更新が止まってもおかしくない。フォークして管理する覚悟が必要になる可能性はある。ただ、「VuePressのSPAでLCP 9.6秒を抱えたまま続ける」というリスクより軽いと判断した。それは今でも変わっていない。

自分はフロントエンジニアではない。正直なところ、フロントエンドの移行作業は苦痛を伴う。Astroのビルド設定をいじったり、テーマのコンポーネントを読んで構造を把握したり、Netlifyの連携先を切り替えてうまく動くか確認したり——一人でやっていたら心が折れかけていたと思う。Claude Codeと並走していると、その感覚が薄れる。擬似的にふたりで進めているような雰囲気があって、それが精神的にも効いていた。

もう一点、これが個人的には大きかった。フレームワークの選定や移行方針の設計という、判断が必要な部分により力を割けるようになる。実装の手を動かす部分をClaude Codeに任せることで、「どのSSGか」「どのテーマか」「どういう構成にするか」という問いに集中できた。そこが、Claude Codeと並走する一番の強みだと感じている。

参考文献#

  1. Astro 公式 https://astro.build/
  2. Fuwari（saicaca/fuwari） https://github.com/saicaca/fuwari
  3. AstroPaper（satnaing/astro-paper） https://github.com/satnaing/astro-paper
  4. Pagefind https://pagefind.app/
  5. PageSpeed Insights https://pagespeed.web.dev/
  6. Core Web Vitals LCP https://web.dev/articles/lcp
  7. Satori（@vercel/og） https://github.com/vercel/satori
  8. Astro Sitemap Integration https://docs.astro.build/en/guides/integrations-guide/sitemap/
Claude Codeと一緒にブログをVuePressからAstroに引っ越した話
https://yurudeep.com/posts/automation/2026/20260414/
作者
ひらノルム
公開日
2026-04-14
ライセンス
CC BY-NC-SA 4.0
【AI安全性】自己顕示欲を持つAI「Claude Mythos」が怖すぎる件【サマーウォーズが現実に？】
© 2026 ひらノルム. All Rights Reserved. / RSS / Sitemap
Powered by Astro & Fuwari