公開日：
長年運用してきた企業サイトは、デザインが現在のブランドに合っており、お知らせや製品情報も継続的に更新されています。一方で、システムの保守は年々複雑になりがちです。セキュリティ対策が必要になるたびに、改修を重ねるべきか、基盤から見直すべきか。こうした判断に悩む企業も少なくないでしょう。しかし、技術基盤を更新するために、デザインやコンテンツ、管理画面まですべて作り直す必要はあるのでしょうか。ネットスターズはこのほど、WordPressとPHPを基盤とする自社の企業サイトを、Next.jsとPayload CMSを組み合わせた新たな構成へ移行しました。従来の外観をほぼ維持しながら、コードの移行に約1時間、テストを含む一連の作業を約1日で行いました。短期間での移行を実現できた背景には、AIによるコード生成だけでなく、類似プロジェクトで培ってきた移行ノウハウと技術的な検証の積み重ねがあります。
当社は、マルチキャッシュレス決済ソリューション「StarPay」を中心に、店舗の省人化・DXや海外展開に取り組むフィンテック企業です。今回の移行では、これまで築いてきたブランド表現やコンテンツを維持しつつ、社内で保守・拡張しやすい運用基盤を整えることを重視しました。この実践で得た知見を、企業サイトの刷新を検討するお客様への支援にも生かしていきたいと考えています。
まず、WordPress と PHP は役割が異なります。PHP は、サーバー側でリクエストの処理やデータの読み込み、ページの生成などを行うプログラミング言語です。一方、WordPress は、記事や画像、ページを管理するためのコンテンツ管理システム、いわゆる CMS です。PHP はシステムを構成する技術の一つであり、WordPress はコンテンツの公開や更新に使う仕組みだと捉えると分かりやすくなります。
WordPress が長く企業サイトで使われてきた背景には、日々の運用に合った使いやすさがあります。担当者は管理画面からお知らせの公開やページの編集ができ、更新のたびに開発者へコードの修正を依頼する必要はありません。テーマやプラグインで一般的な機能を追加でき、オープンソースのエコシステムやホスティングの選択肢もあります。コンテンツを頻繁に更新する一方で、管理システムを独自開発したくない企業にとって、導入を検討しやすい選択肢です。
日本語の管理画面やドキュメント、コミュニティで共有される情報も、導入後の学習や運用を支えています。すでにWordPressを利用している企業にとっては、既存のデザイン資産や担当者の操作経験を引き継げることも大きな利点です。長く利用しているからといって、その技術選択が必ずしも時代遅れというわけではありません。
一方、長期間の運用では、独自にカスタマイズしたテーマやプラグインが増え、担当者や保守体制が変わることもあります。一つの機能を更新するにも、ほかの機能への影響を調べる必要があり、軽微な修正でも過去の実装を確認しなければならない場合があります。重要なのは技術の新旧だけではなく、こうした依存関係を把握し、継続的に保守できる体制を整えることです。
今回の刷新の背景には、従来のシステムにおけるセキュリティ上の懸念がありました。PHPをはじめとするソフトウェアには継続的にセキュリティ更新が提供されており、サイトが正常に表示されていても、基盤のバージョンや保守状況を定期的に確認することが欠かせません。当社の技術チームは既存の構成を見直し、今後の保守体制も含めて改善するため、移行を選択しました。
移行前は、WordPressを用いた一般的な企業サイトとして運用していました。コンテンツ担当者は管理画面から情報を更新できた一方、コードや機能、ページ構成に関わる開発では、外部の委託先に依頼する場面が多くありました。変更が積み重なるにつれ、調整や引き継ぎの負担も大きくなっていました。
移行にあたって重視したのは、訪問者に親しまれてきた外観を可能な限り維持し、技術基盤の更新を必要以上のブランド刷新につなげないことです。また、コンテンツ担当者が引き続き自分たちで情報を更新できることも重要でした。記事や製品情報、画像など、これまで蓄積してきた資産を生かすことが、移行の基本方針です。
Next.js は React をベースにした Web アプリケーションフレームワークであり、新しいプログラミング言語ではありません。ページの構成やルーティング、サーバー側の機能、複数のページ生成方式など、開発の基盤を提供します。開発チームは、コンテンツの更新頻度や必要な操作に応じて実装方式を選ぶことができます。
注目される理由の一つは、React の知識やコンポーネント、開発ツールを活用しながら、サイトに必要な複数の機能を共通の枠組みで扱えることです。企業にとって大切なのは、話題の技術を採用することではありません。コードの構成を整理し、改修を計画し、業務システムとの連携も含めて保守しやすい形にできるかどうかです。
Next.js の公式事例には、Nike、Sonos、Netflix Jobs などのサイトが紹介されています。多様な企業サイトでの実績やエコシステムを参考にしつつ、自社の保守と拡張の要件に合うかを見極めることが重要です。
Next.js だけで、運用担当者がニュースを投稿できる管理画面まで一式そろうわけではありません。表示する側とコンテンツを管理する側には、それぞれ適した仕組みが必要です。今回の移行では、Next.js と Payload CMS を組み合わせる構成を採用しました。Next.js がページやアプリケーションの処理を担い、Payload CMS がコンテンツ管理を担うことで、役割を分けながら共通の技術体系で連携できます。
Payload CMS は TypeScript を基盤とするオープンソースの CMS です。企業が扱う情報に合わせてコンテンツの種類を定義し、その管理画面を用意できます。例えば、お知らせ、製品、導入事例ごとに、タイトル、画像、分類などの項目を設定します。担当者は管理画面で情報を編集し、開発チームはその情報をサイト上でどう見せるかを設計します。
Payload の公式事例には Microsoft Designer に関連するコンテンツプロジェクトもあります。情報の構造や管理画面、Next.js との連携を要件に合わせて設計できることが、企業での利用を考えるうえでの特徴です。
表示とコンテンツ管理の役割を整理することで、実際の業務に沿った改善を進めやすくなります。今回の移行後は、日常の保守を社内の担当者で扱えるようになりました。新しいページが必要な場合も、社内の技術チームで実装を生成し、調整しやすくなっています。小さな変更のたびに外部との開発調整を始める必要が減り、情報更新と技術的な改修をより直接的につなげられます。
今回の作業効率は、一度の取り組みだけで実現したものではありません。当社のチームは、これまで複数の類似プロジェクトにおいて、大規模言語モデル（LLM）をコードの分析・移行・検証の補助に活用してきました。既存の実装を分析し、移行先の言語や構成に合わせたコードを生成したうえで、エンジニアが検証する。この一連の経験と手順が、今回の移行を支えています。
AIは、既存コードの分析や変換を支援し、反復的な作業を効率化できます。ただし、移行の品質を決めるのは、目指すシステム構成や業務上の要件を開発チームが正しく理解しているかどうかです。AIが生成したコードについても、維持すべき処理や見直すべき依存関係、業務への影響を判断するのはエンジニアです。
当社は、AIを検証可能な開発プロセスの中で活用することを重視しています。旧システムの役割と新システムとの対応関係を整理し、段階的に移行して結果を確認します。コードが動作するかどうかだけでなく、ページの表示、コンテンツの整合性、お問い合わせフォームなどの機能も検証対象です。こうした経験の蓄積が、新たな案件への対応力につながっています。
今回の移行では、開発担当者以外のメンバーもページの表示やお問い合わせフォームを含む移行状況を確認。技術面だけでなく、訪問者が必要な情報を閲覧し、当社へ問い合わせできるかという利用者の視点でも確認を行いました。
コード移行に約1時間、確認を含めた一連の作業に約1日という所要時間は、今回のサイトと作業範囲に限った実績であり、すべてのサイトに当てはまるものではありません。当社が重視するのは、これまでの経験、AIによる移行支援、技術的な検証、利用部門による確認を組み合わせた進め方です。
企業サイトの更新をお考えの場合は、現在のサイトを起点に、当社のチームへご相談いただけます。最初に行うべきことは、すぐにコードを書き直すことではありません。よく更新する情報、残したいページ、お問い合わせフォーム、多言語コンテンツ、外部システムとの連携などを把握し、今の保守で負担になっている点を明らかにすることです。
そのうえで、維持するデザインやページテンプレート、記事・画像などの移行方針、CMS のデータ構造と編集方法を検討できます。担当者にとって、管理画面の使いやすさや引き継ぎやすさは、公開ページが正常に表示されることと同じくらい重要です。日常の編集作業を開発者任せにするのではなく、現場の運用に合う仕組みを考えます。
移行計画には、画面の見た目だけでは分からない項目も含まれます。既存 URL の継続、変更する URL のリダイレクト、フォームの送信先、外部 API との接続、公開時のバックアップと切り戻しなどです。作業項目、テスト範囲、公開の進め方、公開後の支援範囲をお客様とすり合わせることで、移行完了の条件を共有できます。
外観が今も使えるサイトでは、技術と運用の課題を先に解決し、全面的なデザイン刷新は必要な時点で考えることもできます。従来の PHP 実行環境を停止すれば、その環境に固有の依存関係とリスクを取り除けます。一方、新しい構成でも更新や権限管理、運用は必要です。社内で保守しやすく、ページを拡張しやすくなったことで、今後の変更コストの低減も期待しています。これは現時点で測定済みの削減効果ではありません。
同様の課題をお持ちの場合は、ネットスターズ公式サイトのお問い合わせ窓口から、現在のサイトのURLと、保守やコンテンツ更新で改善したい点をお知らせください。既存システムと業務要件を踏まえ、維持すべき部分と見直すべき部分を整理し、適切な技術構成や支援範囲をご相談いただけます。これまで積み重ねてきたサイトの価値を生かし、次の運用と成長につながる基盤づくりを支援していきます。
