【ITニュース解説】CMS Migration: From Nuxeo to Strapi

コンテンツ管理システム（CMS）は、ウェブサイトやアプリケーションで使う文章、画像、動画などの情報を一元的に管理するためのシステムである。現代のビジネスでは、増え続けるコンテンツを効率的に扱うためにCMSの導入が不可欠になっているが、時にはそのCMS自体が運用上の足かせとなることもある。今回のニュース記事は、まさにそのような状況に直面したあるグローバルなゲーム会社が、既存のCMS「Nuxeo」から新しいCMS「Strapi」へ移行した事例とその詳細について解説している。

このゲーム会社はこれまでNuxeoをCMSとして利用していたが、いくつかの深刻な課題に直面していた。まず、Nuxeoは高コストで運用が複雑であり、実際に利用されている機能に対してコストが見合っていないという問題があった。Nuxeoは多くの機能を持っていたが、クライアントは主にコンテンツの保存場所としてしか使っていなかった。次に、Nuxeoが提供する独自のデータ構造や開発手法に依存せざるを得ず、特定のベンダーに縛られる「ベンダーロックイン」の状態に陥っていた。これにより、ビジネスの変化に合わせたシステムの変更が難しくなり、データ所有権についても懸念が生じていた。さらに、Nuxeoのアクセス権限システムは非常に細かすぎて、一般の管理者が扱うには複雑すぎ、設定ミスが頻発していた。システムの拡張性も低く、複数のNuxeoインスタンスを連携させて規模を拡大しようとしても、うまく動作しないという問題も抱えていた。開発中にNuxeoのコア機能を代替する解決策を探す必要が生じるなど、これらの問題は日々の運用において顕著になっていった。

これらの課題を解決するため、クライアントは新しいCMSへの移行を検討し、いくつかの候補を比較した。Directusは短い移行期間での実装が難しいと判断され、ContentfulはNuxeoと同様に学習コストが高く、費用もかさむ上にデータの制御が制限されるという問題があった。最終的に選ばれたのが「Strapi」である。Strapiは、コンテンツの管理と表示を切り離して考えられる「ヘッドレスCMS」という種類のシステムで、柔軟性が高い。また、オープンソースであるため、特定のベンダーに縛られることなく自由にカスタマイズできる点が魅力だった。APIを通じてコンテンツを提供する「APIファースト」の設計思想により、多様なプラットフォームでコンテンツを再利用できるという利点もあった。これにより、クライアントはデータに対する完全な所有権を取り戻し、より柔軟なデジタルアセット管理を実現できるようになった。

新しいシステムは、大きく三つの層で構成されている。一つ目は「Strapi CMSサーバー」で、これがコンテンツの中心的な保存場所となる。コンテンツのデータはAWS S3というクラウド上のストレージサービスと連携して保存されるため、必要に応じて容量を柔軟に拡大できる。Strapiには管理者がコンテンツの作成や編集、ユーザーの権限設定などを行うための使いやすい管理画面が備わっているため、コードを書かずにコンテンツを管理できる。また、Strapiの「API層」は、コンテンツを外部のシステムに提供するための窓口となる。二つ目は「ミドルウェア層」で、これはStrapiと、ユーザーが直接操作する画面（フロントエンド）との間に位置し、データの加工や複雑な処理を行う役割を担う。具体的には、Node.jsというプログラミング言語で書かれたサービスをAWS ECSという環境で動作させ、フロントエンドからのリクエストを受け付けたり、画像や動画の処理を行ったりする。さらに、AWS Lambdaというイベント駆動型のサービスも活用し、ファイルのアップロードなどの特定のイベントが発生した際に自動的に処理を実行する仕組みを取り入れた。三つ目は「フロントエンド層」で、これはユーザーが実際に目にするウェブサイトやアプリケーションの画面部分であり、ReactJSという技術を使って開発されている。ユーザーの操作に応じてミドルウェア層のAPIと連携し、必要なコンテンツを表示する。

特に、画像や動画などのメディアアセットの処理は重要な改善点の一つだった。Nuxeoではアセットのアップロードと整理が標準機能として提供されていたが、Strapiではこの部分を新しく設計し直す必要があった。新しいミドルウェア層では、様々な種類の画像処理（例えば、サムネイルの生成や画像のリサイズ）を柔軟に行えるように「Strategyパターン」という設計の考え方を導入した。これは、処理のロジックを個別の「戦略」として分離し、実行時に必要な戦略を選んで適用することで、機能の追加や変更が容易になる仕組みである。これにより、ImageMagickのような画像処理ツールを使うコマンドを、実行時のパラメーターに基づいて生成できるようになった。例えば、「サムネイル」や「大サイズ」といった異なる画像の形式（レンディション）を、簡単な設定に基づいて自動で作成できる。さらに、この画像処理のワークフローはイベント駆動型で構築されている。つまり、画像がAWS S3にアップロードされると、それをトリガーとしてAWS Lambda関数が自動的に起動し、設定された複数のレンディションを生成してS3に保存するという流れである。この最適化により、以前Nuxeoで数秒かかっていたサムネイル生成時間が90%削減され、ファイルサイズも95%削減されるという劇的な改善が実現し、ストレージコストの削減とコンテンツ配信の高速化に貢献した。

データ移行もプロジェクトの重要な部分だった。Nuxeoに蓄積された大量のコンテンツデータを新しいStrapiシステムへスムーズに移行するため、Elasticsearchという検索エンジン兼データストアを利用した。まず、NuxeoからElasticsearchを通じて既存のデータを一括で抽出し、そのデータをStrapiに適した形に変換する処理を行った。この変換では、複雑だったデータの関係性を単純化し、新しいCMSで扱いやすい構造に整えられた。その後、Strapiが提供するAPIを利用して、変換されたデータを新しいシステムに自動的にインポートすることで、データの損失なく移行を完了させた。

プロジェクトを通じて、いくつかの技術的な課題に直面し、それぞれに対して適切な解決策が講じられた。大量の画像や動画を効率的に処理する「非同期アセット処理」は、AWS Lambda、ImageMagick、Sharp、FFmpegといったツールを組み合わせることで実現された。前述の「データ移行」はElasticsearchを活用して安定的に行われ、一部のコンテンツに対して全体ではなく必要な部分だけを更新する「部分更新処理」は、カスタムのNode.jsサービスを開発することでデータの整合性を保ちながら効率的に対応できた。そして、「セキュリティと権限」の確保は最優先事項であり、JSON Web Token (JWT) をベースとした認証システムを導入することで、APIへのアクセスを保護し、ユーザーや役割に応じた厳密なアクセス権限を管理する仕組みが構築された。

今後のロードマップとしては、コンテンツの利用状況やパフォーマンスをより深く分析するための機能強化、コンテンツの作成から更新、アーカイブまでのライフサイクル全体を自動化する仕組みの導入、そしてシステムのさらなる拡張性と堅牢性を向上させるためのAWSサービスとの連携強化が計画されている。

今回のNuxeoからStrapiへのCMS移行プロジェクトは、クライアントに大きな成果をもたらした。システムの技術構成がシンプルになり、開発・運用コストの削減につながっただけでなく、メディアアセットの処理時間が90%削減され、ファイルサイズも95%削減されるという明確なパフォーマンス向上を実現した。最も重要なのは、特定のベンダーに縛られる状況から脱却し、クライアントが自身のデータに対する完全なコントロールを取り戻し、将来の成長に合わせてデジタルアセット管理を自由に発展させられる基盤を構築できた点である。このプロジェクトは、適切なソリューションとチームの努力が、現在の効率性だけでなく、将来の柔軟性をもたらすことを明確に示した良い事例と言えるだろう。