はじめに（免責）
前回（第 5 回「composable 構成の性能設計 — Edge 配信と CDN 最適化」）までで、コンポーザブル Sitecore の構成要素と実装、性能設計を一通り見てきた。最終回となる本稿は、その全体を 3 つの架空シナリオに当てはめる。
扱う 3 つの事例はいずれも実在の案件を題材にしたものではなく、composable Sitecore（XM Cloud + Personalize + CDP + JSS など）を採用したときに、どんな設計判断と落とし穴がありうるかを示すために構成した架空のシナリオだ。登場する会社名、業界の数字、製品の組み合わせはすべて創作だが、骨格は連載 第 1 回〜第 5 回で見てきた構成要素に揃えてある。
シナリオ A — リテール omnichannel
架空のアパレル企業「リテール R」は、首都圏中心に 80 店舗と EC サイトを持ち、年商 400 億円規模を想定する。課題はオンラインとオフラインの体験が分断されていることで、たとえば店頭で試着した顧客が EC で買おうとしても、店舗で見たものが推薦に出てこない、というケースが頻発していた。
構成: XM Cloud を EC サイトの CMS として導入し、Next.js + JSS でリプレイス。CDP に POS のトランザクションと EC の閲覧ログを接続し、ひとつの Guest プロファイルに統合。Personalize は EC のトップ・カテゴリ・商品詳細の 3 箇所でバナーと推薦の差し替えを担う。Sitecore Send で、店頭購入後のフォローメールを送る。Search は Sitecore Search ではなく Algolia を採用し、サイト内検索の関連商品スコアを CDP の Audience とブレンドする。
設計判断: ここでの最大の判断は「Search を Sitecore Search ではなく Algolia にする」だった。理由は、店舗在庫リアルタイム連携の要件が強く、Algolia の partial-update ベースのインデックスのほうが店舗 POS のオンライン化との親和性が高かったため。composable の良さは、こうした「部分的に他社を選ぶ」が後ろめたくないことだ。
落とし穴: Guest の identity 統合に時間がかかった。POS のレシート ID と EC のアカウント ID をどう紐づけるかで、初期 1 か月は重複 Guest が大量に生まれた。CDP の Identity Resolution Rules を慎重に設計し直す必要がある領域で、ここを SaaS 側の機能だけで完結させようとせず、データ統合は別のジョブ（自前の ETL）で先に名寄せしてから CDP に流す方針に切り替えて落ち着いた。
シナリオ B — B2B 製造業のグローバルポータル
架空の精密機械メーカー「Manufacturer M」は、北米・欧州・東アジアに展開し、代理店経由の B2B 販売が中心。課題は、製品カタログとサポート情報が地域ごとに分断されており、グローバル本社からは更新管理が見えない、各国法人からは「最新情報がいつ降りてくるか分からない」と不満が出ている状態だった。
構成: XM Cloud の Sites 機能で、本社サイト + 3 地域 + 主要 5 か国の合計 9 サイトを同一テナント内に並列管理。共通の製品テンプレートを継承して、各国サイトが必要な部分だけ上書きする。Next.js のフロントエンドは ロケール別 deployment にし、Edge CDN は Azure Front Door の地理ルーティングに任せる。Personalize は B2B の代理店ログイン後にのみ稼働し、契約段階に応じて表示する製品ラインを切り替える。
設計判断: グローバル展開で頻発する「コンテンツの翻訳ワークフロー」を、XM Cloud のワークフローと Smartling 連携で半自動化した。本社側で英語版を Approved にすると、Smartling が各言語の翻訳をキックして、戻ってきた翻訳が各国 Site の対応 Item に流れ込む。各国の編集者は翻訳をレビューして公開を押すだけだ。
落とし穴: 各国 Site の管理権限を素直に分けすぎて、本社が把握できないローカル変更が発散した時期があった。最終的には「サイト構造とテンプレートの変更は本社のみ、コンテンツのみ各国編集」というロール分離に落ち着いた。Sites 単位の権限設計は composable 化の前から残る論点で、ここは慎重に詰めたほうがよい。
シナリオ C — メディアの大規模配信
架空のメディア「Media P」は、月間 PV 8,000 万のニュース系サイトを想定する。課題は、ピーク時の負荷とコスト、そして編集者の作業効率。旧構成（Sitecore 9 オンプレ + IIS + Solr）では大型ニュース時に CD サーバーが落ちる事故が年数回発生していた。
構成: XM Cloud + Next.js + Vercel Edge Network。ほとんどのページは ISR（タグ付き revalidate）で、Edge から GraphQL を取得して 60 秒キャッシュ。速報記事だけは Edge SSR で更新を即時反映。CDP は読者の興味カテゴリを 1st-party データで束ね、Personalize でトップページのカード並びを変える。コメント機能と決済は別 SaaS（Disqus 系、Stripe）に切り出す。
設計判断: 大型ニュース時のスパイクは、もう「サーバを足す」議論ではなくなった。Edge CDN がほぼ無限にスケールするので、性能設計は「Edge にいかに乗せ続けるか」に集中する。速報記事だけ Edge SSR にする判断もその延長で、TTL 0 にすると CDN が外れるが、Vercel Edge ランタイムの並列性が桁違いなので持つ、という見立て。
落とし穴: 大量の記事 URL を ISR で持つと、ビルド時間が肥大化する。最初は generateStaticParams で全記事を返していたが、新規記事はオンデマンド生成に任せるようにし、ビルド時は「人気上位 5,000 記事だけ」を事前生成、それ以外は初回アクセス時に生成、という方針に落とした。これだけでビルドが 20 分台から 4 分台に縮んだ。
3 つに共通する判断軸
業種は違うが、判断のパターンには重なりがある。第一に「composable の良さは部分置換にある」。検索を Algolia にする、メールを Marketo にする、コメントを Disqus にする、といった置換が後ろめたくない設計を、最初から構造として持っておく。第二に「identity の統合は SaaS だけでは完結しない」。CDP の Identity Resolution は強力だが、上流の名寄せロジックは自前で持ったほうが事故が少ない。第三に「コンテンツの翻訳・多サイト管理は権限設計が肝」。本社と各国法人の責務をテンプレ・サイト・コンテンツのどの単位で分けるかは、composable に切ったあとも残る論点だ。
連載を通したまとめ
第 1 回で composable DXP の地図を描き、第 2 回で XM Cloud の中身、第 3 回で Personalize と CDP、第 4 回で JSS + Next.js の実装、第 5 回で性能設計、そして本稿で 3 つのシナリオを通した判断軸を見てきた。Sitecore は「ひとつの製品で全部やる DXP」から「複数の SaaS を選んで組み立てる DXP」へ姿を変え、開発スタックは .NET + MVC から JS/TS + Next.js + GraphQL へ移行した。
同時に、コンテンツモデルとロールとワークフローという「Sitecore が長く積み上げてきたエンタープライズ機能」は、composable 化のあとも資産として残っている。新しいスタックに乗せ直すことで、これらをむしろ素直に使えるようになった、というのが現在地に近い感覚だ。
composable Sitecore の導入や既存 XP からのモダナイズについては、エンハンスドでも設計・伴走の相談を承っている。本連載が、構成検討の入口に立つときの地図として役に立てば嬉しい。