WordPressからPayload CMSへ。rePlay.jpの再構築と、開発ノウハウを再利用する仕組みづくり

2026年、私たちは社内で運営してきた古いWordPressサイトを、順次Payload CMSへ移行する方針を決めました。

Payload CMSは、2025年にFigmaの一員となった、オープンソースのCMS・アプリケーションフレームワークです。

私たちは約2年前からPayloadについて学んできました。しかし今回目指したのは、単にWordPressから新しいCMSへ移行することではありません。

サイト制作を通じて得た知識や失敗、改善方法を、AIが再利用できる形で蓄積し、今後のサイト移行だけでなく、新しいサイトをゼロから開発するときにも活用できる仕組みを作ることが目的でした。

同時に、既存のPayload環境ではまだ十分に用意されていないと感じていた、日本市場向けの機能や最適化にも取り組みました。

最初に再構築したのはrePlay.jp

最初のプロジェクトとして選んだのが、私たちのメインサイトであるrePlay.jpです。

ちなみに、ジーンズブランドの「REPLAY」と当社rePlayは関係ありません。

rePlayは、小規模なデジタルプロジェクトの企画・開発と、会社代表が保有するドメインポートフォリオの管理を行っています。日本のユーザーに楽しんでもらえるようなウェブサイトやサービスを、少しずつ形にしている会社です。

以前のrePlay.jpは、Google Cloud上でホスティングされた英語のWordPressサイトでした。

今回、そのサイトを全面的に作り直し、コンテンツも日本語へ変更しました。まずは、当社が保有しているドメインのポートフォリオを紹介するところからスタートしています。

私たちは、これらのドメインを積極的に販売しているわけではありません。

基本的には、それぞれのドメインを活用して自分たちでサービスを開発していく方針です。ただし、より大きな企業がドメインを活用した優れた構想を持ち、具体的な提案をしてくださる場合には、ご相談を受け付けています。

必要な機能を自分たちで開発

新しいrePlay.jpには、ドメイン情報だけでなく、動画、記事、ブログ投稿など、複数のコンテンツを管理できるコレクションを追加しました。

もちろん、スマートフォンからでも快適に閲覧できるよう、モバイルでの使いやすさを重視して設計しています。

WordPressからPayloadへ移行して大きく変わった点の一つは、プラグインやテーマ、追加サービスの契約に依存しなくなったことです。

Payloadに関する機能については、私たちが必要とするものを自分たちで開発しました。

たとえば、次のような機能です。

お問い合わせフォーム

日本式の日付表示

日本円の表示

「1万」「10万」などの数値省略表記

サイト内検索

アクセス解析とトラッキング

SEOタイトルや説明文の文字数チェック

Google Tag Managerとの連携

既製のプラグインを組み合わせるのではなく、サイトに本当に必要な機能だけを実装できるため、不要な機能や継続的なライセンス費用を減らせるようになりました。

Vercelを使わず、Coolifyでホスティング

PayloadはNext.jsを基盤として動作します。

ただし、今回のホスティングにはVercelを選びませんでした。私たちは複数のプロジェクトを運営できるよう、クラウドサーバー上に構築したCoolifyを使用しています。

Coolifyを利用することで、Next.jsとPayloadで作られたサイトを、自分たちが管理するサーバーへデプロイできます。

Next.jsを基盤とした実装と、表示速度や画像、サーバー設定などの最適化を行った結果、rePlay.jpはGoogle Lighthouseの主要な評価項目で、ほぼ100点に近いスコアを記録しています。

開発ノウハウを「PL Agent」に蓄積

rePlay.jpの開発には、約2カ月半かかりました。

現在のAI開発のスピードを考えると、2カ月半は長く感じられるかもしれません。しかし、この期間は一つのサイトを作るためだけに使ったものではありません。

サイトを開発するのと並行して、そこで得た知識やルールを「PL Agent」というGitHubリポジトリへ蓄積しました。

PL Agentは、AIがいきなりコードを書き始めるのではなく、最初に計画を作成し、マイルストーンに沿って開発を進めるための仕組みです。

開発中の抜け漏れやエラーを減らし、それぞれの段階で必要な確認を行えるようにしています。また、GitHubへのコミットも管理し、作業内容や変更履歴が失われないようにしました。

今後、別のWordPressサイトをPayloadへ移行するときや、新しいウェブサイトを開発するときには、rePlay.jpで得た知識を一から学び直す必要がありません。

AIとPL Agentが、これまでに蓄積した設計方針や開発ルールを再利用できるためです。

データの再投入と静的ショーケース

PL Agentには、このほかにも私たちの開発方法に合わせた仕組みがあります。

その一つが、初期データを投入するシード処理の管理です。

開発中にデータベースをリセットする必要があった場合でも、シード処理を再実行することで、必要なコンテンツや設定を復元できます。

もう一つは、Payload本体とは分離した静的ショーケースです。

新しいデザインやコンポーネントを、いきなりPayloadへ組み込むことはありません。まず静的な環境で表示や操作を確認し、デザインを承認してから、ブロック、コレクション、グローバル設定などへ実装します。

この方法により、CMSのデータ構造とデザインの検討を切り分けられるため、修正やレビューもしやすくなりました。

2カ月半をかける価値はあった

私たちは、今回の結果にとても満足しています。

AIを使えば短期間でウェブサイトを作れる時代に、2カ月半という開発期間は長く見えるかもしれません。

しかし、私たちが作ったのはrePlay.jpという一つのサイトだけではありません。

今後のサイト移行や新規開発で再利用できる設計、コード、開発ルール、データ管理方法、そしてAIを活用するための仕組みも同時に作りました。

一度限りのサイト制作ではなく、これから複数のプロジェクトを継続的に開発していくための土台を構築できたと考えています。

そのため、私たちにとって、この2カ月半は十分に価値のある投資でした。