はじめに
Sitecore という名前を最後に聞いたのが Sitecore 9 か 10 のオンプレ案件だった、という方は少なくないと思う。実情として、Sitecore はここ数年で「重いモノリス DXP」から「クラウドネイティブな製品スイートの集合」へ大きく姿を変えた。本連載は、その変わり方をなるべく素直な順序で追う 6 本のシリーズだ。第 1 回となる本稿では、まず現在の Sitecore がどういう構成になっているのかを俯瞰する。
「Sitecore」が指すものが広がった
かつての Sitecore は、CM サーバーと CD サーバーが SQL Server を持ち、xConnect が訪問者データを集めるという、ひとつにまとまった製品だった。現在の Sitecore は、それぞれが SaaS として独立した複数の製品を組み合わせる構成に移っている。中核となる CMS は Sitecore XM Cloud。コンテンツの編集と配信は完全にクラウド側で行われ、配信は Experience Edge という GraphQL ベースのエッジ API から取り出す。
パーソナライゼーションは Sitecore Personalize（旧 Boxever 由来）が単独の SaaS として担い、その背後で 1st-party データを束ねる Sitecore CDP がある。サイト内検索は Sitecore Search、推薦は Sitecore Discover、メールは Sitecore Send、コマースは Sitecore OrderCloud。それぞれが個別にライセンス可能で、API で連携する形を取る。
つまり「Sitecore を入れる」という言葉は、もはや単一の製品を指していない。XM Cloud だけで始めることもできれば、Personalize と CDP を先行導入することも、Search だけを差し込むこともできる。エンタープライズ DXP として歴史を持つ Sitecore が、コンポーザブル前提に組み直された結果だ。
composable DXP と MACH 原則
こうした構成変更は Sitecore 単独の流行ではなく、業界全体が MACH（Microservices / API-first / Cloud-native / Headless）の方向へ揃ってきた流れの中にある。MACH に乗る製品は、レンダリングを内部に持たず、コンテンツを API で返すことに徹し、ホスティングは SaaS、フロントエンドは別のフレームワークで作るという役割分担を前提にする。Sitecore のスイートはこの考え方にそのまま乗っている。
composable に切る利点は、何より置き換えの選択肢を残せることだ。コンテンツは XM Cloud、検索は別ベンダ、コマースもまた別、という構成にしても破綻しない。逆に欠点は、複数製品の責務境界をプロジェクト側で設計しないといけない点で、ここはあとで Part4 と Part5 で扱う。
XP（オンプレ）と XM Cloud（SaaS）の関係
既存案件の多くは、まだ Sitecore Experience Platform（XP）の 9.x / 10.x をオンプレや IaaS で動かしている。Sitecore は当面この XP も並行サポートする方針で、急にゼロから書き直す必要はない。ただし、新規案件で大きな機能拡張を載せる場合や、運用負荷を下げたい場合は、まず XM Cloud への移行可否を検討するのが現実的になっている。
移行は一気通貫ではなく、コンテンツモデルだけ XM Cloud に持ち、表示は既存サイトに残す段階や、Personalize だけ先に外出しする段階を踏める。本連載の以降では XM Cloud を前提に書き進めるが、既存 XP 上の判断についても各回でブリッジを置く。
典型的な構成イメージ
2026 年時点でよくある composable Sitecore の配線は、以下のようになる。コンテンツ編集者は XM Cloud の Pages で記事やページを編集し、公開された結果が Experience Edge にプッシュされる。フロントエンドは Next.js（App Router）+ Sitecore JSS で組まれ、Vercel や Azure Static Web Apps にデプロイされ、ビルド時または配信時に Edge から GraphQL でコンテンツを取得する。
同じフロントエンドが、初回訪問者の属性を Personalize に送り、戻ってきた decisioning 結果に応じてコンポーネントを差し替える。Personalize の裏では CDP が顧客プロファイルを束ね、メールや LINE といった別チャネルへの hand-off を仲介する。検索ボックスは Sitecore Search を呼び、商品カードは Discover が推薦する。
この構成図はあくまで一例で、実際の案件では Search を別製品（Algolia、Elastic）に振ったり、CDP の代わりに Segment を入れたりする組み合わせも珍しくない。Sitecore のドキュメントもそうしたヘテロな配線を想定して書かれている。
どの規模で Sitecore を選ぶか
「composable に切ったとはいえ、それでも Sitecore は重そう」という印象は半分正しい。中規模以下のプロジェクトであれば、サイト数 1〜2、編集者 5 名程度、月間 PV が数百万程度なら、Contentful や Sanity といった軽量 headless CMS のほうがフィットしやすい。Sitecore の旨味が出るのは、複数ブランド・複数言語・複数地域・複数編集者ロールが絡む規模、つまり XM Cloud の Pages や Sites による多サイト統制と、Personalize/CDP のエンタープライズ機能が必要になる場面だ。
もうひとつ、既存 Sitecore XP 資産がある場合は移行コストの観点で Sitecore を選び続ける合理性がある。コンテンツモデルの移植は楽ではないが、テンプレート構造の考え方自体は引き継げる。
本連載の流れと次回
次回（第 2 回）は 「XM Cloud の中身 — コンテンツモデルから headless 配信まで」。Pages / Sites / Components の編集体験と、配信を担う Experience Edge の挙動を扱う。第 3 回は Personalize と CDP、第 4 回は JSS と Next.js での開発、第 5 回は composable 構成の性能設計、最終回は架空のシナリオを使った導入パターンの整理に当てる。
本記事で composable Sitecore の地図を頭の中に置けたら、続編は具体の話に降りていく。エンハンスドでは、XP からのモダナイズや XM Cloud 中心の新規導入の相談を承っている。