Sitecore から Next.js へ：どうせ費用を支払っているリビルド.

Sitecore から Next.js へ移行できるものと、移行できないもの?

コンテンツ項目、フィールド値、ページ階層は引き継げます。一方で、レンダリング、パーソナライゼーションルール、xConnectデータは持っていけません。まず動かすのはフィールドです。CLI で .yml ファイルとしてシリアライズした項目から、生のフィールドを抜き出してください。テンプレートは移行先のコンテンツタイプに変わり、メディアは新しい URL を持つアセットへ移ります。描画ロジックは引き継げません。1つずつ Next.js コンポーネントとして組み直す必要があります。既存の HTML や CSS で再利用できる部分はごくわずかです（流用できるという見込みは捨ててください）。

移行で消える機能を把握してください。xDB を前提としたパーソナライゼーションには監査が不可欠です。そのまま動くと思い込まず、個々のルールを再構築するか、別の仕組みに替えるか、破棄するかを判断します。Sitecore Forms のワークフローも作り直さなければなりません。従来のパイプラインやイベントハンドラー、スケジュールタスクは、APIルートやエッジ関数、Webhookへ移植します。内蔵のSolrやAzure Searchを使っているなら、インデックス、ファセット、クエリのロジックを設計し直したうえで、AlgoliaやCoveoなどの代替ツールを選定してください。

検索トラフィックを維持するために、URLマップやリダイレクトをどのように計画すればよいでしょうか?

URLマップを作るなら、公開中のURLを現行サイトからすべて書き出してください。実装に入る前に、それぞれの転送先を正式に確定させます。勘に頼ってはいけません。サイトマップをそのまま信じず、本番サイトを実際にクロールしたうえで、サーバーログと突き合わせてください。流入や被リンクを抱えている本当のページが見えてきます。

URLは可能な限り変えないでください。変えなければ転送処理も不要です。シンプルに保ちましょう。どうしても変更するなら、サーバーサイドの301または308を使い、アドレスが恒久的に移った事実をGoogleへ伝えます。リダイレクトは連鎖させず、旧アドレスから最終目的地へ1跳びで解決させてください。転送ルールは最低1年間維持し、URL検査ツールや自動テストで検証します（抜き打ちの手動チェックはテストではありません）。

フィールドのエクスポートから漏れ落ちる項目に気をつけてください。Sitecoreのレンダリングが動的に吐き出しているカノニカル、hreflang、構造化データ、各種メタタグは、データ出力に含まれません。手動で洗い出す必要があります。まずそこを固めましょう。無料診断にかければ、サンプルページからカノニカルや構造化データのシグナルを拾えます。テンプレートのコードを掘り返す前に、土台となるリストを手早く揃えられます。

Sitecore からコンテンツを移行する方法：エクスポート、API、またはクロール?

データ移行は手堅い順序で進めてください。まずエクスポート、次に移行先のAPI投入、それでも拾えない箇所だけクロールで補います。ファイルから着手しましょう。CLIシリアライゼーションプラグインを入れ、pullサブコマンドを使い、Module.jsonに基づいて項目を.ymlファイルへ吐き出します。ローカルファイルにしておけばGitなどのバージョン管理に載せられるため、実行ごとの差分を追跡できます。結果の検証もしやすくなります。

次は取り込みです。これらのファイルを読み出し、各テンプレートをコンテンツタイプへマッピングしながら、API経由でヘッドレスCMSへ登録するスクリプトを組みます。この工程は何巡か回すことになります。エクスポートデータ内のメディア、リンク、リッチテキストは検証されていないため、取り込むたびに目視やテストで確認しなければなりません。とくにリッチテキストは厄介です。古い内部リンクが含まれているため、新しいURL規則へ書き換える必要があります。

公開ページのなかに、どのフィールドにも紐づかないテキストを見つけたら、クロールで回収してください。両者を厳密に突き合わせます。クロール結果と出力済みフィールドを照合すれば、エクスポート単体では欠落してしまうページを正確に特定できます。

Next.jsとSitecoreを比較した場合、編集者はどのような機能を利用できますか?

編集者は、構造化されたフィールドとライブプレビューを備えた専用の管理画面で作業します。Sitecoreは単一の編集空間を提供してくれましたが、移行先で何を選ぶかによって日々の操作感はガラリと変わります。使い勝手は死活問題です。Sanityを採用した場合、編集者はプレビュー画面上の要素をクリックするだけで、Sanity Studioの該当入力フィールドへ直行できます。公式ドキュメントには、ライブプレビュー、クリック編集、ドラッグ＆ドロップによるページ構築、Next.js App Router向けの導入手順まで揃っています。

自社サイトの要件に合わせて選定してください。読みもの中心のサイトやマーケティング用途なら Astro が軽快ですが、視覚的なキャンバス編集やプラグイン、標準のホスト型管理画面は付属しないため、別途CMSをつなぐ必要があります。複雑なWebアプリ、動的なパーソナライゼーション、多数のライターを抱える環境なら、SanityやContentfulと組んだNext.jsが有力な選択肢です。検索、フォーム、最適化ロジックはその周囲に自前で組み上げます。どちらを採るにしても、構築作業そのものは省けません。

今日、編集スタッフに普段の作業を1件だけ実際に見せてもらってください。エディタ上で残すべき機能が、かなりはっきり見えてきます。

Sitecore から Next.js への移行にはどのくらいの時間がかかり、その工数を左右する要因は何でしょうか?

移行スケジュールは長めに確保してください。Sengo社の試算によれば、中堅企業のXPからSitecoreAIへの移行には9～14ヶ月、大規模なマルチサイト構成では18ヶ月以上を要します。自社の工数がどのあたりに収まるかは、URL数、コンテンツタイプ、メディアの総量、外部連携、対応ロケールを見れば判断できます（大半の要素は、現時点で手元にあるはずです）。

比較すべき相手は、XM CloudとヘッドレスCMSです。XPからXM Cloudへの移行は、実質的にはNext.jsでサイトを作り直す話です。ストア選びは、その次に来ます。そもそもCMSは、よく似たフロントエンドの裏側にあるコンテンツストアにすぎません。どのストアを選んでも、作業の大半は変わりません。レンダリングをコンポーネントとして作り直し、連携機能を見直し、何回かに分けてコンテンツを移すことになります。つまり、ストア選びは全体から見ると小さめの判断です。

まずテンプレート数を数えてください。Sengoの経験則では、テンプレートが50未満でカスタムコードも少なければ、SitecoreAIへ直接移行できます。次に、カスタムパイプライン、イベントハンドラー、スケジュールされたタスクを洗い出します。移行先でもそれぞれ置き場が必要になり、多くは自分たちで一から組むことになるためです。ロケール数も必ず見ます。言語が1つ増えるだけで、コンテンツ処理の手間とリダイレクトの設定量は確実に増えます。

Sitecore から Next.js への移行を避けるべき場合?

今のサイトで目的を果たせていて、サポート期限にも余裕があり、再構築で解決したい課題もないなら、SitecoreからNext.jsへの移行は見送るべきです。急ぐ理由はありません。課題がはっきりしないまま再構築しても、残るのは余計なコストになりがちです。

まず、稼働中のバージョンを確認してください。Sitecore 10.4のサポート期限は2027年12月31日、10.3は2025年12月31日です。なお、10.5はWindows Server 2025、SQL Server 2025、Solr 10に対応しています。10.4なら、まだ計画を詰める時間があります。単純なアップグレードなら既存機能は今の場所に残ります。ですが、再構築を選ぶと、MVCレンダリングやxDBによるパーソナライゼーションは失われます。

代替できないxDBパーソナライゼーションに頼っている場合、手を加えたくない組み込みSolr検索がある場合、あるいは現行ページの評価スコアがすでに良好なら、現状維持が賢明です。一度、実際のページを確認してみてください。問題がプラットフォーム側にあるのか、ページ側にあるのかが見えやすくなります。私はレガシー環境やWordPressからこれらのスタックへの移行を設計し、実装していますが、あえて「何もしない」判断を勧める場面も少なくありません。（データがそう示しているなら、それも十分な答えです。）

よくある質問.

次に読む.

1. 01Sitecoreの代替ソリューションサポート期間、ライセンス情報、およびXPからの移行パスについて。
2. 02AEMの代替手段スイートの一部のみを使用する場合の実行手順。
3. 03Next.js SEO監査レンダリングモード、メタデータ、ハイドレーションコスト。