Drupal多言語×マルチサイト構成の移行落とし穴｜設計前に確認すべき判断基準
グローバル展開を進める製造業、観光、EC事業者にとって、多言語サイトの構成判断はサイト公開後の運用を大きく左右する分岐点です。
特にDrupalでは、多言語機能とマルチサイト機能を組み合わせた構成が選択肢として挙がりますが、初期設計の判断次第で、数年後のリニューアル時にコンテンツ移行が事実上進められなくなる事例が発生しています。
本記事では、ドメイン別・言語別のマルチサイト構成で発生しやすい移行不能リスクの具体的な原因と、発注前に押さえておくべき構成判断の基準を整理します。
すでに運用中のサイトを抱える担当者、これから新規構築を検討する担当者、いずれにも参考となる観点をまとめました。
目次
Drupalにおける多言語構成の選択肢
Drupalで多言語サイトを構築する際、代表的な構成は次の3つに分かれます。
- 単一サイト＋言語別パス（例：example.com/ja/、example.com/en/）
- 単一サイト＋言語別サブドメイン（例：ja.example.com、en.example.com）
- マルチサイト構成＋ドメイン別分離（例：example.co.jp、example.com）
1・2は同一のデータベース・コードベース上で言語ごとの出し分けを行う構成であるのに対し、3のマルチサイト構成はサイトごとにデータベースを分離できる点が本質的に異なります。国ごとに独立したドメイン運用が求められる場合や、地域ごとに掲載内容・運用主体が異なるケースで採用され、製造業の海外現地法人別サイト、観光事業の国・地域別ドメイン運用、ECの地域別ストアなどが典型例です。
一見、地域ごとの独立性が高く柔軟に見える構成ですが、将来的な統合や移行を視野に入れると、設計段階で確認すべき論点が複数存在します。
移行不能を招く典型パターン：言語コードのコンテンツ内埋め込み
この問題は、単一サイトのパスプレフィックス構成でも起こり得ますが、マルチサイト構成ではドメインごとにURL構造が独立して分岐しやすいため、コンテンツ本文やリンク、メディアパスに言語コードや国コードが直書きされた状態で蓄積・深刻化しやすくなります。
具体的には次のような順序で問題が拡大します。
- 初期構築時に、各サイトで独自のURL構造（/jp/products/、/en-us/products/など）を採用する
- 記事本文中の内部リンクや画像パスに、絶対URLまたは言語コード付きの相対パスが直接記述される
- 記事数が増えるにつれ、リンク先の言語コードが本文データに恒久的に蓄積されていく
- リニューアル時に別ドメイン統合や別CMSへ移行しようとすると、本文中のパスを一括変換しない限りリンクが正しく機能しない
- 変換対象が数万件規模になり、機械的な置換では取りこぼしが発生し、目視確認の工数が膨大化する
この状態になると、コンテンツ資産を活かした移行が事実上進められず、再入稿に近い作業が発生します。運用チーム側の負担が想定を超え、リニューアル計画そのものが後ろ倒しになる要因になります。
マルチサイト構成でさらに増える調整項目
言語コード埋め込みに加え、マルチサイト構成では以下のような設計項目が積み上がります。
- 各サイトで利用するモジュール構成のずれ（同一のはずが、更新タイミングで差異が生じる）
- テーマの分岐管理（共通コンポーネントの標準化がされていないと、改修が全サイト分発生する）
- ユーザー権限と最上位管理者の責任範囲が不明確になり、緊急対応の判断が遅れる
- コンテンツタイプやフィールド定義が各サイトで独自進化し、統合時のマッピングが困難になる
つまり、マルチサイト構成は「独立性の高さ」というメリットの裏側で、標準化の維持と責任分界の明確化を怠ると、後年の移行工数が加速度的に増える構造を持っています。
設計前に判断すべき基準
構成判断にあたって、発注担当者が事前に整理すべき観点を整理します。
- 観点1：将来の統合可能性
- 5年後、10年後にサイトを統合する可能性があるか。可能性があるならば、コンテンツ本文への言語コード直書きは避け、リンク先をパスの文字列ではなくエンティティ参照（ノードIDなど）で管理し、表示時に言語別パスへ解決する設計を初期から求めるべきです。
- 観点2：運用主体の分離度
- 各国・各言語の運用チームが完全に独立しているか、本社側で一元管理するか。一元管理型であれば、単一サイトの多言語機能で十分に対応できる場合が多く、マルチサイトを選ぶ必然性が下がります。
- 観点3：コンテンツ標準化の方針
- コンテンツタイプ、フィールド、ワークフローを標準化して維持できる体制があるか。標準化が難しい場合、マルチサイトを選ぶと将来の統合時に調整が増えます。
- 観点4：責任分界の明確化
- モジュール更新、セキュリティ対応、コンテンツ承認の責任範囲を初期から文書化できるか。マルチサイト構成では、最上位管理者の権限設計を最初に定義することが、後年の運用負荷を抑える鍵になります。
既存サイトを抱える場合の確認ポイント
すでにマルチサイト構成で運用中の場合、まずは以下の棚卸しを推奨します。
- 本文中に含まれる絶対URLおよび言語コード付きパスの件数
- 各サイト間でのコンテンツタイプ・フィールド定義の差分
- モジュールバージョンおよびカスタム改修箇所の一覧
- 承認フローと権限設計の実態
この棚卸しを行うだけでも、次回リニューアル時に発生する移行工数の概算が把握でき、予算計画・スケジュール計画の精度が高まります。
よくあるご質問
マルチサイト構成は避けるべきなのでしょうか。
一律に避けるべきというものではありません。地域ごとに運用主体が完全に独立し、コンテンツも別体系で管理する場合には有効な選択肢です。ただし、将来的な統合や一元管理の可能性がある場合には、単一サイトの多言語機能で対応する方が、後年の移行工数を抑えられます。
すでに言語コードが本文に埋め込まれたサイトを運用しています。今からできる対策はありますか。
まずは埋め込まれているパスの件数と分布を棚卸しし、影響範囲を可視化することが第一歩です。その上で、新規記事からリンク先をエンティティ参照で管理する運用に切り替え、既存記事は優先度の高いページから段階的に置換するといった対応が現実的です。次回リニューアルを見据えて、標準化の方針を早めに定義しておくことをおすすめします。
発注前にベンダーへ確認すべき点は何ですか。
内部リンクや画像パスの記述方法、言語切り替え時のURL構造、コンテンツタイプの標準化方針、最上位管理者の権限設計、そして将来的な統合・移行時の想定シナリオの5点は、提案書段階で必ず確認することをおすすめします。これらが曖昧なまま構築を進めると、数年後の運用負荷や移行コストに直結します。
LYZONが提供するWebサービス
Webに関するお悩みは、まずLYZONへ
構築・運用・AIまで、Webに関わる課題をワンストップで対応。まず何ができるかをご覧ください。
鹿児島県出身
紅葉のシーズンが一番好き。寒さにめっぽうよわい。
いつかジョージアにシュクメルリを食べに行きたい。
