Drupal から Next.js へ：移行できるもの、動作しなくなるもの、必要なこと.

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

新しいフロントエンドの背後でDrupalを使い続ける場合に限り、コンテンツモデルはそのまま維持されます。権限設定や編集作業の流れも同じです。でも、注意してください。Twigテンプレートやテーマは新環境へ移行できないため、これまでの表示形式を引き継ぐ前提で進めないでください。ヘッドレス構成では、Drupal標準のJSON:APIモジュールからデータを取得し、作り直すのは表示層のみです。そして、Drupal自体をやめるなら、移行先でモデルを一から再設計することになります。

実装に入る前に、前提条件を確認してください。まずは見落としがちな設定項目から着手します。サイト名、スローガン、トップページ設定、ロゴ、ファビコンは設定ファイルに保存されているため、JSON:API経由では取得できません。新環境側で手動で再構築する必要があります。特殊な例外ではなく、単に見落とされやすい部分です。また、インライン画像やview-embedトークンはWordPressのショートコードと同様に動かなくなるため、移行前に全箇所を監査してください。段落やエンティティ参照フィールドはヘッドレスのモデルに近い形でマッピングできるため、スキーマの策定は早い段階から進められます。

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

コードを書く前に、URLのマッピングを行ってください。公開中の全URLとパスエイリアスをエクスポートし、それぞれを新しいアドレスと1対1で紐付けます。作業はここから始まります。DrupalのRedirectモジュールはコンテンツ1件につき1つの正規URLを割り当て、他のエイリアスを301リダイレクトでそこへ誘導します。既存のリダイレクトも、最初から移行リストに含める必要があります。既存エイリアスの処理を公開後に回すと、気付かないうちにアクセスが流出します。そして、1つのノードに複数のエイリアスが転送されている場合、どのエイリアスを残すかはご自身で判断してください。

新しいサーバーで、連鎖のないサーバーサイドの301または308リダイレクトを設定します。あわせて内部リンクを更新し、新しいサイトマップを公開し、canonicalタグを新しいURLに向け、一時的なnoindexルールをすべて解除します。canonicalタグには、古いアドレスではなく新しいアドレスを指定してください。ただ、転送の代用にはなりません。Googleはrel=canonicalを命令ではなくヒントとして扱います。リダイレクトのテストにはURL検査ツールを使うか、数千件規模ならスクリプトを作成して検証してください。大規模サイトの場合は、ディレクトリごとに段階的に移行し、新旧両方のトラフィックを監視して、404レポートで見落としたURLがないか確認します。リダイレクトは少なくとも1年間は有効にしておいてください。

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

Drupalからのデータ抽出にはAPIリクエストを利用します。データベースのエクスポートやページのスクレイピングという手段もありますが、できる限りノイズのないソースを使ってください。コンテンツはすでに構造化されています。だから、APIから取得するのが最も確実です。JSON:APIを有効にすると、/jsonapi/node/article のようなパスへリクエストを送るだけで、参照関係を保った型付きJSON形式の記事を受け取れます。一方、データベースの生エクスポートでは、再構成が必要なフラットファイルが生成されます。クロールでは描画後のページに見えている内容しか取得できないため、見失った孤立ページを救済する最終手段程度に扱ってください。

データマッピングは、手作業の設計から始めます。近道はありません。スクリプトを実行する前に、スキーマの変換ルール、参照関係のモデル化、ロケールの扱いを詰める必要があります。自動インポートは、設計と検証を終えた一番最後に実行してください。移行先システムには、インポートツールや書き込みAPIを通じてレコードを取り込みます。ただし、バックエンドとしてDrupalを使い続けるならインポート自体が不要で、フロントエンドが同じAPIにリアルタイムでクエリを実行します。

メディアファイルについては別途チェックが必要です。ファイル、代替テキスト、PDFは個別に処理し、その後、編集担当者が各コンテンツタイプのサンプルを抜き取り検査してください。

Next.jsとDrupalを比較した場合、編集者にはどのようなメリットがありますか？?

Next.jsのフロントエンドではDrupalのテーマ層が使われません。そのため、プレビュー画面やオンデマンド公開の機能は自前で構築しなければ利用できません。Drupal側は新しいフロントエンドの表示処理を関知しません。ここは分けて考えてください。でも、ヘッドレス構成でも、編集者は慣れ親しんだDrupalの管理画面を使い続けられます。ドラフトモードを連携させれば、ノード画面を開いて未公開ドラフトやリビジョンを直接プレビューできるようになります。プレビューボタンは最初の保存前でも動作します。

更新対象は手動で指定します。タグプラグインを入れると、DrupalサイトからNext.jsの再検証エンドポイントへキャッシュタグが送られ、該当データが無効化されます。無効になるのは、接続しているデータだけです。たとえばトップページに記事一覧がある場合、記事の再検証設定へそのパスを手動で加える必要があります。だから、運用中のリストページはすべて洗い出してください（放置されたページほど、古いデータが残り続けます）。

ヘッドレスCMSへ移行するなら、編集者は新しいホスト型管理画面の使い方を覚える必要があります。ここがトレードオフです。「Sanity Visual Editing」を使えば、どのプランでもプレビュー画面から「Studio」へワンクリックで移動し、そのまま編集に入れます。ただし、その裏でDrupalモジュールはすべて不要になり、権限設定は引き継がれません。最初から組み直す前提で見てください。

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

プロジェクト期間を左右する要因は5つあります。URL数、コンテンツ種別、メディアアセット数、外部連携、対象地域です。まずはURL数とコンテンツ種別から確認しましょう。ある公開ベンチマークの試算では、一般的なエンタープライズ向けDrupalからContentfulへの移行には、中程度のリスク想定で12～22週間かかります。ここにはモデル再設計、データインポート、フロントエンド全面再構築に加え、ローカライズ作業、ワークフロー設定、編集者へのトレーニングまで含まれます。貴社サイトなら、もっと短く済むかもしれません。大事なのは他社の平均値ではなく、ご自身のサイトの実数で見積もることです。

Drupal を残せば、コンテンツ移行の手間は省けます。ただし、運用するシステムは2つに増えます。パッチ適用と監視を続ける Drupal のホストと、Next.js のホストの両方です。Drupal を完全に手放す場合は移行作業が発生しますが、既存ホスティング環境の維持費や手間はなくなります。

私はこうした移行プロジェクトを設計と実務の両方で手がけており、古い環境やWordPressサイトをAstroやNext.jsへ載せ替えています。着手時にまず見るのは件数です。ページ総数だけを見ても、見積もりはあまり締まりません。ロケール数や連携先の一覧のほうが初期フェーズで実態をよく示すため、全体量より先にそこを精査します。

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

Drupalサイトが正常に動作している場合は、移行すべきではありません。編集者が問題なく作業できており、検索からのトラフィックも安定しているなら、移行を行うとこれら3つのすべてがリスクにさらされることになります。 無料診断でサイトの評価が「良好」（80～100）と判定され、HTTPヘッダー、キャッシュ、スキーマ出力、画像サイズなどの弱点がDrupal内で修正可能な場合は、現状を維持してください。 これは「その場で修正」すべきケースであり、これを移行案件と呼ぶことは、必要のない作業を売り込むことに他なりません。

2重のシステム運用に耐えられないなら、現状維持が賢明です。分離構成に踏み切れば、Drupalとは別にフロントエンドの保守も抱えます。コストは無視できません。単にトレンドを追うだけなら、やめておくべきです。移行が生きるのは、Webアプリケーションの要件がある場合です。そして、パーソナライゼーションの実装や、大勢の編集者による構造化コンテンツの同時管理が必要な場面でも、確かな価値があります。

要件に合わせて選びます。判断軸は明快です。コンテンツ配信やマーケティングページが中心なら、Astroが適しています。一方で、アプリケーション機能、パーソナライゼーション、多人数の編集体制を求めるなら、SanityやContentfulと連携させたNext.jsが力を発揮します。ただし、Astroを選ぶと視覚的な編集画面は失われます。ヘッドレスCMSを採る場合は、Drupalのモジュール群や自前の管理画面が、マネージドのダッシュボードへ切り替わります。

よくある質問.

次に読む.

1. 01Drupalの代替ツールページの状況に応じて、アップグレード、分離、または移行をご検討ください。
2. 02Drupal から WordPress へ「シンプルであることが正しい」場合と、コンテンツモデルが失うもの。
3. 03Next.js SEO監査レンダリングモード、メタデータ、ハイドレーションコスト。
4. 04ヘッドレスCMSのSEO監査レンダリング、canonical、プレビュー、テンプレート由来の構造化データ。