このたび、ocws.jp のサイトを構築しているフレームワークを Gatsby.js から Next.js に移行しました。

なぜ移行を決め、どのように進め、そしてどんな成果が得られたのか。オクワスの実体験として、そのプロセスを振り返ります。
同じような課題に直面している方の参考になれば幸いです。

なぜ Gatsby.js からの移行を決めたのか

将来性に対する不安

最大の理由は、運用が不安定になる、そして、Gatsby.js の将来性に対する懸念でした。

ocws.jp の運用では、記事の追加や修正をリポジトリにプッシュすると、CI/CD によって自動でビルドとデプロイが行われる仕組みを採用しています。しかしある時期から、CI が頻繁に失敗するようになってしまいました。

コードに問題がないにもかかわらず、ビルドが成功したり失敗したりと不安定な状況が続きました。調べてみると、Gatsby.js の更新頻度が以前より落ちており、依存ライブラリとの整合性が取りづらくなっている印象を受けました。

2025年6月時点で、Gatsby.js は2024年から、WordPress のプラグイン WPGatsby プラグインは最終更新が3年前から更新されていない状況です。

「いつビルドが失敗するか分からない」という不安は、運用上見過ごせないリスクですし、単純にモチベーションにも影響するレベルでした。

Next.js の進化と WordPress 連携への安心感

一方、Next.js はメンテナンスも活発ですし、React ベースのフレームワークとして非常に広く使われており、特に App Router の登場以降は進化のスピードも加速しています。

Astro や SvelteKit などの他の選択肢も一瞬検討しましたが、React ベースであることによる移行のしやすさや、高い認知度、将来性などを踏まえて Next.js を選びました。

さらに決め手となったのは、ブログ機能の構成でした。ocws.jp のブログは WordPress をヘッドレス CMS として使い、GraphQL を通じてコンテンツを取得し静的サイト生成（SSG）を行っています。この構成が Next.js でも問題なく再現できる見込みが立ったことは、大きな後押しになりました。

Next.js（App Router）への移行プロセス

技術方針が決まり、いよいよ実作業へと踏み出しました。
React ベースということもあり、既存のコンポーネントがある程度再利用できると見込んでいましたが、実際には「良かった点」と「戸惑った点」の両方がありました。

良かった点：GraphQL と画像の扱いがより直感的に

Gatsby.js では GraphQL のクエリをページごとに export const query として定義するのが一般的でしたが、Next.js では fetch を使って直接データ取得を行うスタイルのため、より直感的に感じられました。
コード全体の見通しもよく、個人的にはこちらのほうが扱いやすいと感じました。

また、画像の取り扱いもシンプルになりました。Gatsby.js では gatsby-plugin-image を使い、GraphQL 経由で画像を取得・最適化していましたが、Next.js では public ディレクトリに配置し、パスを指定するだけで表示できます。この手軽さは、開発体験の向上に大きく貢献しました。

リンクタグの書き換え（<Link to=""> → <Link href="">）といった作業は必要でしたが、基本的には機械的な置換で対応できました。

戸惑った点：SSG の作法と 'use client' の概念

一番の学習ポイントは、App Router における SSG（静的サイト生成）の作法でした。

Gatsby.js では gatsby-node.js を使って動的なページ生成を記述していましたが、Next.js（App Router）では generateStaticParams() で動的パスを生成し、generateMetadata() でページのメタ情報を定義する形に変わります。慣れるまでは試行錯誤が続きました。

さらに、サーバーコンポーネントとクライアントコンポーネントの違いも当初は戸惑う点でした。インタラクティブな要素を含むコンポーネントには 'use client'; の記述が必要で、「どこをサーバー処理にし、どこをクライアント側に任せるか」を常に意識する必要があります。

ハマった点：WordPress 画像のローカル保存対応

具体的なトラブルのひとつが、WordPress にアップロードされた画像の扱いです。
最初は画像の URL が WordPress のドメインを直接参照しており、最適化もできなければ、WordPress 側への負荷も高くなってしまう問題がありました。

この点については、ビルド時に WordPress 上の画像をダウンロードし、Next.js 側でローカルリソースとして扱えるよう調整することで解決しました。

移行して感じた3つのメリット

苦労もありましたが、移行して得られたメリットは大きく、今ははっきりと実感できています。

メリット1：CI の安定性が向上

最大の課題だった CI の不安定さが完全に解消されました。
デプロイ時のトラブルを気にすることなく、開発に集中できる環境が整いました。

メリット2：開発サイクルの高速化

Gatsby.js もビルドの最適化をしてくれていましたが、Next.js の方がそれ以上にビルドが速く、修正後の反映もスムーズです。日々の開発サイクルがより快適になりました。

メリット3：パフォーマンスを維持したままの最新化

パフォーマンス面でも懸念はありましたが、移行後も Gatsby.js 時代と同等以上の水準を維持できています。ユーザー体験を損なうことなく、サイト基盤をよりモダンにアップデートすることができました。

今回の移行で得た学び

技術的な知見に加えて、長期的なサイト運用における学びもありました。

1. 技術に固執しない柔軟さ

どんなに優れた技術でも、状況は変わるものです。
特定の技術に過度に依存せず、「目的を実現する手段」として常に最適な選択肢を探れる柔軟さが大切だと改めて感じました。

2. データの持ち方が移行のしやすさを左右する

今回の移行がスムーズだった大きな要因は、コンテンツデータがフロントエンドと分離されていたことでした。WordPress に記事を管理し、他のデータも独立した形で保持していたため、フレームワークの移行に大きな影響を受けませんでした。

3. メンテナンス性とパフォーマンスのバランス

運用のしやすさは大事ですが、それだけに偏るとユーザー体験が犠牲になりかねません。保守性とパフォーマンス、その両立を意識することが重要です。

4. 原点回帰できる構成の重要性

今回の構成により、将来的に従来の WordPress サイトへ戻ることも現実的になりました。PHP のバージョンアップにより WordPress 自体の性能も向上しており、「戻れる選択肢を持っておく」ことは、長期運用において安心感につながります。

最後に：同じ悩みを抱える方へ

Gatsby.js から Next.js への移行は、オクワスにとって大きなチャレンジでした。
長年活用してきた Gatsby.js には感謝しつつ、今の ocws.jp にとって最適なパートナーとして Next.js を選びました。

もしあなたが現在の運用や将来性に少しでも不安を感じているなら、移行も一つの選択肢です。常に新しい技術にアンテナを張り、必要に応じて動ける体制を整えておくことをおすすめします。

この記事が、みなさまの開発や技術選定のヒントになれば幸いです。