Hugo/Hexo/Next.jsからAstroへの移行ガイド：3日で完了する手順書

はじめに

自分のブログを開くたびに、「なんか遅いな…」と感じたり、Hugoのテンプレート構文を修正するのに疲れたりしていませんか？あるいはNext.jsで作った静的ブログなのに、巨大なJSバンドルが読み込まれることに疑問を感じていませんか？

私も同じでした。そして、「Astro」というフレームワークに出会いました。
「PageSpeed Insightsで100点が簡単に出る」という噂は本当でした。しかし、移行には不安がつきものです。

• 「記事が100本以上あるけど、全部手直しが必要？」
• 「SEOの順位が下がったらどうしよう」
• 「途中で挫折しないかな」

安心してください。この記事では、私が実際にHugo、Hexo、Next.jsからAstroへ移行した際の知見を元に、1〜3日で完了する具体的な移行パスを解説します。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

なぜ今、Astroへ移行すべきなのか

Astroの圧倒的なメリット

1. ゼロ JavaScript（デフォルト）
   AstroはデフォルトでJSを一切ブラウザに送信しません。ブログのようなコンテンツサイトにおいて、これは最強のパフォーマンス最適化です。Reactで作ったブログは、記事を読むだけなのにReactのライブラリ全体を読み込みますが、AstroはHTMLだけを返します。

   1-3日

   移行期間

   平均的なブログの場合

   85→100

   スコア改善

   PageSpeed Insights

   なし

   SEO影響

   URL維持で無傷

2. Islands Architecture（必要な部分だけ動的に）
   「でも検索機能やコメント欄は？」大丈夫です。Astroは必要なコンポーネントだけを「島（Island）」として独立させ、そこだけJSを読み込んで動かします（Hydration）。

3. 現代的な開発体験（vs Hugo/Hexo）
   HugoのGoテンプレートやHexoのEJSに苦しむ必要はありません。AstroはJSXライクな構文で書け、TypeScriptも標準サポート。ReactやVueのコンポーネントもそのまま使えます。

移行前のチェックリスト

作業を始める前に、以下の準備をしておきましょう。

1. Gitブランチを切る：git checkout -b migrate-to-astro で現在の状態を保存。
2. 仕事量の見積もり：
   • 記事数 < 50：1日
   • 50〜200：2日
   • 200以上：3日
3. テーマ選び：
   • AstroPaper：シンプルで高機能。技術ブログ向き。
   • Astrowind：LP向きだがブログもいける。
   • Fuwari：多言語対応。

パターンA：Hugoからの移行

Hugoユーザーにとって最大の障壁は「Goテンプレート」からの脱却ですが、Astroの記法ははるかに直感的です。

Step 1: プロジェクト作成

npm create astro@latest my-blog

Step 2: コンテンツの移行
Hugoの content/ フォルダの中身を、Astroの src/content/blog/ にコピーします。
Frontmatterの互換性は高いですが、日付フィールドなどを調整する必要があるかもしれません。

# 日付フィールドの一括置換例（macOS/Linux）
find src/content -name "*.md" -exec sed -i '' 's/^date:/pubDate:/g' {} +

Step 3: テンプレートの書き換え
Hugoの {{ range .Pages }} は、Astroでは map 関数になります。

Hugo:

{{ range .Pages }}
  <h2>{{ .Title }}</h2>
{{ end }}

Astro:

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

---
const posts = await getCollection('blog');
---
{posts.map(post => (
  <h2>{post.data.title}</h2>
))}

Step 4: 静的ファイル
Hugoの static/ の中身を、Astroの public/ に移動します。これで画像パスなどはそのまま使えます。

パターンB：Hexoからの移行

Hexoユーザーの場合、EJS/Pugテンプレートからの移行になります。

Step 1: Content Collectionsの設定
Hexoはスキーマが緩いですが、Astroは src/content/config.ts で型定義ができます。

import { defineCollection, z } from 'astro:content';
const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    pubDate: z.date(),
    tags: z.array(z.string()),
  }),
});
export const collections = { blog };

これにより、Frontmatterの記述ミスをビルド時に検知できるようになります。

Step 2: URL構造の維持
Hexoのデフォルトは /YYYY/MM/DD/title/ ですが、Astroは設定で変更可能です。
もし変える場合は、astro.config.mjs でリダイレクトを設定しましょう。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

redirects: {
  '/:year/:month/:day/:slug': '/blog/:slug',
}

パターンC：Next.jsからの移行

これが一番面白い移行です。なぜなら同じJavaScript（React）エコシステムだからです。

Step 1: 思考の転換
Next.js（SPA/SPAライク）からAstro（MPA）への移行は、「ウェブアプリ」から「ウェブサイト」への回帰です。_app.js のようなグローバルな状態管理は、AstroのLayoutコンポーネントに置き換わります。

Step 2: Reactコンポーネントの再利用
Next.jsで作ったReactコンポーネントは、そのままAstroで使えます。

npx astro add react

---
import MyReactButton from '../components/MyReactButton.jsx';
---
<!-- インタラクティブな場合のみ client:load をつける -->
<MyReactButton client:load />

ほとんどのコンポーネント（ヘッダー、フッター、カードなど）は静的なので、.astro ファイルに書き直すことをお勧めします。そうすればJSの実行コストがゼロになります。

Step 3: データフェッチ
Next.jsの getStaticProps は不要です。Astroではファイルの先頭（Frontmatter部分）でデータを取得します。

Next.js:

export async function getStaticProps() {
  const data = await fetch(...);
  return { props: { data } };
}

Astro:

---
const data = await fetch(...).then(r => r.json());
---
<div>{data.title}</div>

共通のベストプラクティス

1. 301リダイレクトの設定
   URLが変わる場合は必須です。Cloudflare Pagesなら _redirects ファイル、Vercelなら vercel.json で設定します。SEO評価を引き継ぐために忘れないでください。
2. 画像の最適化
   Astroの <Image /> コンポーネントを積極的に使いましょう。マークダウン内の画像も自動でWebP化されます。
3. 段階的な移行
   記事数が多い場合、まずはトップページと数記事だけ移行して、デザインや機能を固めてから全量移行・デプロイするのが安全です。

結論：その苦労に見合う価値はあるか？

間違いなくあります。
Next.jsで「どうやってJSバンドルを減らそうか」と悩んでいた時間、Hugoで「もっと自由にコンポーネントを使いたい」と嘆いていた時間が、Astroによって解決されます。

あなたのブログが、読み込み0.x秒の世界に突入する快感を、ぜひ体験してください。

3 min read · 公開日: 2025年12月3日 · 更新日: 2026年1月22日

Easton

技術開発