自社HPを WordPress から Next.jsへフルリニューアルしました
自社HPを WordPress から Next.jsへフルリニューアルしました
こんにちは。システムデザインワークスの渡辺です。
このたび、弊社コーポレートサイト（HP）をフルリニューアルしました。
結論から言うと、「WordPressの運用負債」を整理し、Next.js の静的生成（SSG）を軸に、Payload（Headless CMS）を組み合わせた構成でサイトを再構築しました。
今回はデザインも一新しつつ、裏側の構成・技術まで含めて土台から作り直しています。
リニューアルの背景：WordPress運用の“保守コスト”が増えてきた
これまで自社HPは WordPress で運用していました。
もちろん WordPress は便利で、導入も早いのですが、長期運用になると「更新作業そのもの」が負担になりがちです。
- 具体的には、以下のような“運用負債”が徐々に積み上がっていました。
- テーマ・プラグインの更新対応（互換性調査 → 検証 → 反映）
- PHP / ミドルウェアのバージョン追従
- セキュリティ面の注意点増加（脆弱性・権限・管理画面周り）
- 「保守のための保守」が発生しやすい（更新したいのに怖くて触れない）
そして自社としては普段、クライアント様向けの Webアプリ／業務システム開発で モダンな技術スタックを扱っている一方、
自社HPだけが以前の構成のまま残っている状態でした。
「せっかくなら、自社が普段使っている“今の実務スタック”をそのままHPに適用したい」
そう考えて今回のフルリニューアルに踏み切りました。
方針：最新技術の導入 + SEO/UX を“土台から”改善
弊社はWebアプリ開発が主軸なので、自社HPも最新技術を取り入れたモデルケースとして整備しつつ、SEO/UX、とくに表示速度を最優先に土台から改善する方針にしました。
採用した技術スタック
Next.js（静的生成中心 / SSG）
Reactベースのフレームワークとして Next.js を採用し、ほぼ全ページを静的生成（SSG）に寄せました。
SSG（Static Site Generation）は、事前に確定した内容をビルド時に静的ページとして生成して、アクセス時に動的レンダリングを行わずに配信できる、Next.js が提供する仕組みの1つです。
これにより、サーバー／クライアント双方の処理負荷を抑えつつ、軽量なレスポンスで高速にページを表示できます。
コーポレートサイトは「毎秒更新されるデータ」を表示するケースが少なく、更新頻度も比較的落ち着いているため、SSGとの相性が良いです。
SSG中心にすることで、
- リクエストごとのサーバーレンダリング負荷が減る
- CDN配信前提で高速化しやすい
- 表示速度改善が UX / SEO の両面で効いてくる
といったメリットが得られます。
Payload CMS（Headless CMS）
コンテンツ管理には Headless CMS として Payload CMS を採用しました。
Payload CMSを選んだ理由は、単なる「Headless CMS」だからではなく、Next.js と一体運用しやすい設計思想を持っている点が大きいです。
Payload 採用理由（技術的に刺さったポイント）
Next.js 前提で同居できる
フロントとCMSを別サービスに分けるのではなく、同一リポジトリ／同一アプリとして統合しやすい構成を取りやすい。
コードファーストでスキーマ定義できる
コンテンツ構造（Collections / Fields）をTypeScriptで管理できるため、変更をPRでレビューでき、運用が安定する。
管理画面のカスタム性が高い
「運用に合わせて管理画面を寄せる」ことができ、実務の要件に合わせて拡張しやすい。
大変だった点（参考記事が少ない問題）
Payload はオープンソースで勢いがあり、設計も綺麗ですが、日本語の参考記事がまだ少なめで、初期のキャッチアップに時間がかかりました。
ただ逆に言うと、Payload が「Next.js を前提にしている」ぶん、
ディレクトリの考え方
ルーティングの棲み分け
API・管理画面の置き方
などがハマってくると、後半は“Next.jsの延長”としてスムーズに連携できるようになりました。
「フロント（Next.js）とCMS（Payload）を別物として統合する」より、
「Next.jsの中にCMSも組み込む」発想に切り替えると、運用イメージが掴みやすかったです。
Tailwind CSS
スタイルは Tailwind CSS で統一しています。
最近はネガティブ寄りの話題も見かけますが、今回の構成では Next.js / React のコンポーネント思考と相性が良く、UIを部品単位で作っていく運用にフィットすると判断して採用しました。
コンポーネント単位でスタイルの一貫性を保ちやすい（CSSの散らばりを抑えやすい）
実装しながらUIを詰めやすく、試行錯誤のサイクルが速い
デザイン変更が入っても影響範囲を局所化しやすい
結果として、制作スピードと保守性のバランスが取りやすくなりました。
……とはいえ、個人的には好みが分かれる部分も多く、課題感もあるので、機会があれば別記事で触れようと思います。
取り組んだこと：SEO と UX を“実装で”強くする
今回のリニューアルでは、見た目の刷新だけでなく、検索と体験の両方を改善するために以下を実施しました。
表示速度改善：SSG中心 + 軽量化（体感で分かるレベルを目指す）
メタ情報の整理：検索結果で伝える情報設計
OGP最適化：SNS共有時の見栄えを安定させる
ページ階層の見直し：回遊性と問い合わせ導線を整理
「デザインを変えたらOK」ではなく、成果に繋がる状態を“構造として”作ることを意識しました。
リニューアルして良かったこと
1) とにかく表示が速い
SSG中心に寄せたことで、ページ表示・遷移がかなり軽くなりました。
UXとしての体感改善はもちろん、速度はSEO評価にも影響するため、土台として強くなった実感があります。
2) 運用がラクで安全
WordPress特有のテーマ・プラグイン更新、脆弱性対応の負担が減り、
“更新したいのに更新できない”状態を回避しやすくなりました。
Payload の管理画面でコンテンツ更新ができるため、編集体験を維持しつつ、保守対象を絞れたのが大きいです。
3) SEOの土台が整った
メタ情報・OGP・ページ構造など、検索に強い構成へ寄せました。
コンテンツを増やしていく前に、評価されやすいベースを作れたのは収穫です。
まとめ
今回のリニューアルでは、
WordPress運用で増え続ける負債を整理し
Next.js の SSG を軸にして速度と運用性を上げ
Payload を組み合わせて “更新しやすいCMS運用” を実現しました
今後はブログや実績、技術Tipsなども継続的に更新していく予定です。
もしよければ、また覗いていただけると嬉しいです 🙇
■ ご相談お待ちしております。
今回のHPリニューアルはあくまで自社の改善ですが、そこで得た知見や設計の考え方は Webアプリ／業務システム開発にそのまま活かせます。
- 社内業務のWebアプリ化（Excel運用のシステム化）
- 既存システムの改修／リプレイス（速度・UI・保守性）
- 会員管理／予約／在庫／受発注の仕組み構築
- 要件整理／設計相談
などなど、ご気軽にご相談ください