弊社WEBサイトをGatsby.jsからNext.jsへ移行しました
弊社のコーポレートサイト（およびブログ）の裏側のシステムをリニューアルし、これまで使用していたGatsby.jsからNext.jsへと移行しました。
今回は、技術選定の背景や、なぜこのタイミングでNext.jsへの移行を決断したのかについて、その理由をまとめてみたいと思います。
さようなら、Gatsby.js
これまで弊社サイトを支えてくれたGatsby.jsには、非常に感謝しています。GraphQLを用いたデータソースの豊富さや、生成される静的サイトの圧倒的な表示速度は、Web制作において非常に魅力的でした。
しかし近年、Gatsby.js自体の開発スピードが鈍化し、エコシステム全体に停滞感が漂い始めました。技術の移り変わりが激しいフロントエンド界隈において、将来的なメンテナンスコストやセキュリティリスクを考慮すると、「このまま使い続けるのは不安要素が多い」と判断せざるを得ませんでした。
なぜWordPress（データベース）を選ばなかったのか
Webサイトやブログのリニューアルというと、WordPressなどのデータベース駆動型CMSが真っ先に候補に挙がります。しかし、今回の構成ではあえてデータベースを使用しない方針を貫きました。
理由は大きく2つあります。
- セキュリティの担保: データベースが存在しない静的ファイル（SSG）構成であれば、SQLインジェクションなどの脆弱性を根本から排除できます。
- 極限の表示速度: リクエストのたびにデータベースへ問い合わせるのではなく、あらかじめ生成されたHTMLを返すため、サーバーの応答速度が段違いに高速です。
表示速度の速さは、ユーザー体験の向上だけでなく、SEOの観点でも非常に重要です。
Next.js + Markdownという最適解
最終的に私たちが選んだのは、Next.jsとMarkdownファイルの組み合わせです。この構成を選んだ理由は、単なるGatsby.jsの代替というだけではありません。
1. Gatsby.jsからの移行が容易
Gatsby.js時代から、ブログ記事などはMarkdown（およびFrontmatter）で管理していました。Next.jsはファイルベースでのルーティングが強力であり、既存のMarkdown資産をそのまま活かしてスムーズに移植することができました。これまでの執筆フローを変えずに済むのは大きなメリットです。
2. 自社プロジェクトとの強力なシナジー
現在弊社では、新しいプロジェクトとして「Laravel + React + Lexical」を用いたモダンなヘッドレスCMSを開発中です。そして、そのCMSが出力するデータを表示するフロントエンド（表示側）として、Next.jsを採用しています。
自社サイトもNext.jsで構築・運用することで、社内にNext.js（App RouterやReact Server Componentsなど）の知見をより深く蓄積でき、結果としてお客様へ提供するシステムの品質向上にも直結すると考えています。
おわりに
Gatsby.jsからNext.jsへ移行したことで、表示速度を維持しつつ、よりモダンで拡張性の高い、そして何より「安心して運用できる」技術基盤を手に入れることができました。
今後も、この技術ブログを通して、Web制作の現場で得た知見や、開発中の自社CMSに関する情報などを発信していきたいと思います。