はじめに
前回（第 1 回「コンポーザブル DXP 入門 — XM Cloud / Personalize / CDP の組み立て」）では、Sitecore が複数の SaaS 製品を組み合わせる composable DXP に姿を変えたことを俯瞰した。本稿（第 2 回）では、その中核に位置する Sitecore XM Cloud の中身に入る。コンテンツモデル、Pages による編集体験、サイト構造、そして配信を担う Experience Edge までを順に追い、編集者と開発者の双方から見たときの輪郭をつかんでもらうのが目標だ。
XM Cloud の概念マップ
XM Cloud は大きく見ると 3 つの層からなる。最上位に「編集体験」として Pages（ビジュアルエディタ）と Components（コンポーネントライブラリ）と Sites（サイト切替）があり、その下に「コンテンツ層」として Templates / Items / Renderings といった XM 由来のオブジェクトが残っている。さらに下層に「配信層」として Experience Edge があり、ここから GraphQL でフロントエンドへ流れる。
従来の Content Editor と Experience Editor を触っていた人にとって、Pages はそれらの後継にあたる。ただし内部のデータモデルそのものは XM 系の流れを継いでいるので、Templates と Items の概念は引き続き登場する。
コンテンツモデル — Templates と Items
記事や商品などのコンテンツは、Sitecore の世界では Item という単位で表される。Item の「型」を決めるのが Template で、フィールド名・データ型・継承関係を定義する。たとえば「記事ページ」テンプレートを作り、Title, Body, Author, PublishedAt, Eyecatch といったフィールドを持たせる、という設計になる。
テンプレートは継承できるので、共通基底（例: BasePage が SEO フィールドを持つ）を作って具体テンプレートで拡張する、という DRY な設計が自然に通る。これは XM Cloud でも変わらない。GraphQL スキーマもこの継承構造に追従して生成される。
Pages による編集体験
編集者は基本的に Pages から作業を始める。Pages はビジュアルエディタで、コンポーネントをドラッグ&ドロップしてレイアウトを組み、その場でテキストや画像を編集できる。実体としては、編集中のページは Sitecore 側の preview rendering host（フロントエンドの開発時 URL を Sitecore に登録したもの）を呼び出して描画している。
つまり編集体験は「裏で実際の Next.js アプリが SSR している画面を Sitecore がフレーム表示している」と捉えるとわかりやすい。コンポーネントの見た目はフロントエンドの実装そのものなので、実装と編集体験のずれが生まれにくい。
Sites と多サイト
XM Cloud には Sites という単位があり、ひとつのプロジェクトで複数のブランドサイトや言語版を運用するための仕切りになる。各 Site は自前のサイト構造（ルート Item ツリー）と、自前のフロントエンド rendering host を持てる。コンテンツの一部を Sites 間で共有することもできるので、共通のニュース記事を本社サイトとブランドサイトの両方に出す、といった案件にも素直に乗る。
Components と「再利用の単位」
編集側から見た再利用の単位は Component。これはフロントエンド側で実装した React コンポーネント（あるいは Vue、Angular）に、編集時のメタ情報を結びつけたものだ。コンポーネントには「許可されるデータソース型」「許可される配置スロット」といった編集者向けの制約が付くので、編集者が壊さないレールを開発者が敷ける構造になっている。
配信 — Experience Edge と GraphQL
編集者が公開を押すと、対象 Item は Sitecore の Experience Edge という配信レイヤにプッシュされる。Edge は地理的に分散した CDN 的なエンドポイントで、コンテンツ取得は GraphQL で行う。フロントエンドは次のような形でクエリを叩く。
query GetArticle($path: String!, $language: String!) {
item(path: $path, language: $language) {
... on Article {
title: field(name: "Title") { value }
body: field(name: "Body") { value }
author: field(name: "Author") { value }
eyecatch: field(name: "Eyecatch") { ... on ImageField { src alt } }
publishedAt: field(name: "PublishedAt") { value }
}
}
}このクエリで取れたデータをフロントエンドが組み立てる。Edge は preview endpoint（編集中も見られる、TTL ゼロ）と delivery endpoint（公開後の本番配信、CDN キャッシュあり）の 2 系統に分かれており、フロントエンドはどちらを叩くかを環境変数で切り替える。
ワークフローと公開
Item には任意のワークフロー状態を持たせられる。標準では Draft → In Review → Approved → Published のような状態遷移が用意されており、レビュアー権限を持つユーザーだけが Approved に上げられる、といったロールベース運用が組める。承認後の公開は手動でも、スケジュール公開でも、API 経由のオートメーションでも構わない。
公開操作は内部的に Edge への push を伴うので、フロントエンドはほぼリアルタイムに反映を観測できる。ただし CDN キャッシュとの兼ね合いで、「公開はしたがユーザーにはまだ届いていない」期間が発生することはあり、これは Part5 の性能設計で扱う。
ローカル開発の起点
XM Cloud のセットアップは Sitecore CLI でローカル環境を立ち上げ、`xmc` プロジェクトのスキーマを XM Cloud テナントに同期する、というのが典型的な流れになる。
dotnet tool install -g Sitecore.CLI
sitecore login --cm https://xmc-***.sitecorecloud.io --auth https://auth.sitecorecloud.io
sitecore ser pull # サーバ側のテンプレ等をローカルへ
sitecore ser push # ローカルの変更をサーバへテンプレートやアイテムは src/items 配下に YAML として落ちる。これを Git で管理することで、コンテンツモデルの変更も通常のレビューに乗せられる。
次回
次回（第 3 回）は 「Sitecore Personalize と CDP で実装する 1to1 体験」。XM Cloud と並んで composable 構成の柱になる Personalize と CDP を、1to1 配信の decisioning と 1st-party データ統合の観点からコードを交えて整理する。