現場の自由な選定から生じた複数CMSを一元化しコスト9割減。プレイドがCraft Cross CMSで実践したリプレイスの型

登場人物の紹介：

自由なツール選定が生んだ「複数CMSの乱立」と統合への決断

プレイドでは過去、高い技術リテラシーと組織やプロジェクトごとの裁量などを背景に、デザイナーやエンジニアがその時々に最適なサービスを選んできました。その結果、コーポレートサイトやKARTEサービスサイト、ブログなど6つのサイトで、4種類（Contentful、Hygraph、microCMS、Newt）のヘッドレスCMSが併用される状態となっていました。

代表的なサイトの状況は以下の通りです。
・コーポレートサイト：Hygraph
・サポートサイト：Contentful
・KARTEサービスサイト：microCMS、Newt、Hygraph
・オウンドメディア「CX Clip」：Contentful

機能面での不満は少なかったものの、年間約547万円のコストが発生していることや、サイトごとに管理画面や運用フローが異なるという課題が顕在化しつつありました。そうした中、自社プロダクトである「Craft Cross CMS」がリリースされたことを機に、プロジェクトは動き出します。

藤井： もともとはドッグフーディング（自社製品の検証）の側面が強かったですね。自社で作ったCMSは自分たちで使うべきだと考え、まずはボトムアップの形で検証を始めました。コスト面でのメリットも大きいため、契約更新までにできるところからやろうと考えていたところ、途中からトップダウンの判断が入り、一気に進む感じになりました。

1つのサービスサイトだけで3つのCMSを使っていたり、コンテンツの形式がバラバラであったりと、まずは現状把握からスタートする必要がありました。6サイトで4つのCMSが動いているという、一般的な企業では珍しい複雑な状況下で、いかにして統合を進めていったのでしょうか。

プロジェクトマネジメントを担当した藤井

期限とコストから導き出した「着手の優先順位」

複数のサイトを移行する際、最も悩ましいのが「どこから手をつけるか」です。プロジェクトチームは、各CMSの契約期限（年払いか、月払いか）と解約コストを基準に優先順位を明確にしました。

直近でサービス終了を控えていたNewtから最初に着手し、次いで年払い契約でコスト圧縮効果が高いHygraphの移行を決定。一方で、月払い契約のmicroCMSは、大規模イベントの更新作業と重なっていたため、あえて後回しにする判断を下しました。

また、毎月約1,100ドルのランニングコストがかかっていたContentfulについても、コスト削減に加えて脆弱性や古いNode.jsバージョンの問題を抱えていたため、早期の移行が求められました。

同一CMS内でどのコンテンツから着手するかというミクロな判断においても、明確な基準が設けられました。オウンドメディア「CX Clip」の移行を担当した神谷は、以下のように振り返ります。

神谷： CX Clip内で最新記事のブロックエディタから古いリッチテキストやマークダウンなど3種のフォーマットが混在していました。もっとも複雑で現在も使われている新しいフォーマットから優先的に着手しました。一番複雑だったものから着手したことで、その先はスムーズに移行作業を進めることができました。

バックエンド／CMS全般を担当したエンジニアの神谷

移行しないものを決める「コンテンツの棚卸し」

CMS移行における最初の重要なステップは「何を移行するか」ではなく「何を移行しないか」を決めることでした。

定期的にアップデートされるものはCMS管理とし、しばらく更新予定のないランディングページは静的化（CMS化しない）するなど、更新頻度と情報のフレッシュさで移行対象を絞り込みました。例えばセミナーページでは445件のコンテンツがありましたが、「過去2年以内」かつ「オンデマンドで価値があるもの」のみに絞り込んでいます。

合計約17,000件のコンテンツを抱えていたサポートサイトでも、大掛かりな断捨離が行われました。CLIを使って全データをエクスポートし、AIを用いてCSVに書き出すスクリプトを作成。そのCSVを人間の目で確認し、どこからも参照されていない不要なコンテンツや画像を洗い出して削除しました。

※CLI（Command Line Interface：コマンドラインインターフェース）とは、ターミナルなどの画面からテキスト（文字）のコマンド（命令）を入力して、コンピューターやシステムを操作する仕組みのこと

CMS移行をスムーズに進めるための重要なポイントは、要件定義の窓口を最初に一本化し、運用判断の指揮権を、実際に運用するビジネス側（マーケティングやブランド管理など）に置いておくことです。

移行プロジェクトでは「現状の仕様をそのまま再現する」という方針になりがちですが、過去の下書きや使われていない機能までそのまま移行しようとすると、無駄な工数が膨れ上がってしまいます。そのため、早い段階で「このコンテンツや機能は今後も運用を続けるのか」という判断をビジネス側と開発側で合意しておく必要があります。

事前にビジネス側と開発側で運用方針をしっかりと握っておくことで、無駄な移行作業や手戻りを防ぎ、プロジェクトをよりスムーズに進めることが可能になります。

インフラ・周辺システムとの依存関係を整理する

CMSの移行は、単にデータを移し替えるだけで完結するものではありません。プレイドのプロジェクトでは、インフラ環境の刷新や周辺システムとの依存関係の整理が並行して進められました。

中西： Account EngagementやreCAPTCHAなど、CMSコンテンツ以外のマーケティングツールや認証システムがどう組み込まれているか、その全体把握が移行前の現状把握では重要になります。周辺システムとの依存関係を事前に整理することで、リリース段階での想定外の課題に対応する余裕が生まれます。

フロントエンド実装などを担当したエンジニアの中西・宮本

同時に、インフラ面でも大規模な改修が行われました。

宮本： サポートサイトでは、GKE（Google Kubernetes Engine）からCloud Runへのインフラ移行をCMS移行より先に完了させました。インフラ対応がCMS移行のバッファを食うリスクを事前に排除するためです。

CMS外の依存関係を洗い出し、影響範囲の大きいインフラ移行を先回りして終わらせておくことで、プロジェクト後半の不確実性を減らす設計がなされていました。

フレームワークの移行と、モダンな開発体験（DX）へのアップデート

フロントエンドの開発環境においても、モダンなアーキテクチャへのアップデートが図られました。
オウンドメディアの「CX Clip」では、元々古いNode.jsで稼働していましたが、このタイミングでバージョンアップが必須となりました。それに伴うディレクトリやコードの修正など、前提となる環境整備に多くの工数が割かれました。

同時に、GatsbyからAstroへのフレームワーク移行も進行しました。一部は動的な要素が多いためGatsbyを残存させていますが、大部分が軽量で高速なAstroへの移行を果たしています。

インフラの置き換えはバックエンド処理にも及びました。これまでContentfulのWebhookとGoogle Cloud Functionsを組み合わせて構築していた検索やナレッジベース用の仕組みを、すべて自社の「Craft Functions」へ置き換えました。これにより、KARTE Craftのエコシステム内で処理が完結するようになっています。

フロントエンド実装などを担当したエンジニアの清水

清水： これまでの開発では、手元のエディタでコードを書いても、最終的にはブラウザ上の管理画面にコードを貼り付けて保存し、手動でデプロイ（本番環境への反映）するという手間のかかる手順を踏む必要がありました。しかし今回は、KARTE Craftのローカル開発環境を活用しました。これにより、使い慣れた手元のエディタ上でコードの記述からテストまでを完結させ、CLIを使って手元から直接デプロイできるという、非常にスムーズで現代的な開発体験を得られました。

手作業とAIを組み合わせた泥臭いデータ移行

約4ヶ月という短期間で6サイトの移行を完了できた最大の要因は、AIエージェントの活用でした。ただし、それは「AIに丸投げする」といった魔法のような方法ではありません。エンジニア全員が「AIがなければこのスケジュールでは終わらなかった」「手作業だけなら1年はかかる」と口を揃えました。共通していたのは、まず手で型を掴み、AIで広げ、最後はまた手で仕上げるという進め方です。

全サイトのコンテンツ移行を担当した神谷は、HygraphやmicroCMSなど移行元ごとに形式がバラバラで、同じ記事でも本文の構造が記事ごとに違うケースも多く、AIの活用が不可欠だったと振り返ります。

神谷： AIがなければ、このスケジュールでは終わってないと思います。いきなりAIに丸投げするのではなく、まずは1〜2件を手作業で試し、データの構造やルールを把握してからAIにスクリプトを生成させました。移行先のAPIにデータを連携させるには、JSONの構造を詳細に検証する必要があったため、事前に検証環境でツールを作り込み、エラーログを出力させてAIに原因を調査させるフローを確立しました。
移行元の仕様と移行先の仕様の「癖」を把握することも重要です。検証環境での試行を重ねることで、移行プロセスで必要な対応を事前に洗い出し、本番での問題を最小化することができました。

フロントエンド実装などを担当したエンジニアの冨田・神谷・中西

フロントエンド移行を担当した冨田は、影響の大きいページは手作業、反復作業はAIという切り分けで進めました。フォームなど影響が大きい箇所は慎重に手で置き換え、大量置換ではCodexを使い、ステージング環境で10数ページをまとめて差し替えるプルリクエストを出し続けました。

冨田： 影響が大きいところは個別に手で進めました。Codexを使ってステージング環境にプルリクエストを上げて、ほぼ本番と同じ環境で確認していました。AIエージェントがなければ、この量の移行は現実的ではなかったと思います。
一方で、「これ無駄じゃないか」というデータや、データの持ち方・使われ方が正しいかの判断は、AIでは解けず、人の確認が必要でした。

同じくフロント移行を担当した中西は、GatsbyからAstroへのフレームワーク変更と、microCMSからCross CMSへの移行を同時に進めました。単なるCMSの入れ替えではなく、表示基盤ごと作り直す作業だったため、AIの活用が前提になりました。

中西： GatsbyからAstroに変える、それにmicroCMSからCross CMSに変える、という二重の移行でAIがめちゃくちゃ役に立ちました。自分で0から1まで書いていたら、多分まだ終わっていないと思います。CMS以外の周辺連携は、やってみないと分からないところが多く、そこも大変でした。AIがなければ、もっと時間がかかっていたと思います。

URLの維持と、移行後に発生した「APIリクエスト急増」の罠

SEOや既存ユーザーへの影響を考慮し、サポートサイトでは既存のURLを維持する設計が採用されました。ここでは、ContentfulのIDとCraft Cross CMSのIDを結びつける対応表（マッピングモデル）を新しく作成。編集者が誤ってURL用IDを書き換えないよう、編集者用のモデルと管理者用のモデルを分離する工夫がなされました。

しかし、切り替え直後に予期せぬインフラ課題が発生します。全コンテンツを一括取得してからフロントエンド側で絞り込む実装のままリリースしたため、APIリクエストが異常に急増し、インフラコストが跳ね上がってしまったのです。

データ構造移行などを担当したエンジニアの伊藤

伊藤： 対策として段階的なキャッシュの導入を行いました。また、リリースノートなどは過去に振り返ってまで見るケースはほぼないため、全件一気に取るのは無駄だと判断し、ページングに合わせて必要な件数（1ページ目のみ20件など）だけを取得する実装に変更しました。

取得件数の最適化とキャッシュ戦略の見直しにより、APIリクエスト数は約半分に減少し、事態は沈静化しました。

コンテンツ一元化がもたらす今後の展望

Craft Cross CMSへの移行を通じて、タグや検索の整理が進み、旧CMSで発生していた細かな不具合も解消されました。しかし、一元化はあくまでスタートラインです。散在していたデータが1つの基盤に統合されたことで、次なるデータ活用の構想が動き出しています。

ビジネス側では、今回導入されたKARTE Craftの拡張基盤を活用し、CMS内のコンテンツデータベースをAIに組み込み、社内のナレッジデータベースにしたり、別コンテンツへの展開を効率化することを視野に入れています。

サポートサイトにおいても、プロダクトの機能アップデートに合わせて、AIがドキュメントの不足を検知し、ドラフトを自動生成して人間がレビューするワークフローの構築が検討されています。

4つのCMSから1つへの集約。コスト削減という明確な成果の裏には、緻密なインフラ移行、AIを駆使した泥臭い実装、そして運用を見据えたアーキテクチャの再構築がありました。このプレイドの実践の型が、複数CMSの運用に悩む企業のヒントになれば幸いです。

移行の学び — つまずきやすいポイントチェックリスト