Sitecoreのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Sitecoreのシステム開発は、要件整理、製品選定、設計・開発の順に進みます。その後は、テスト、稼働、定着へと続きます。どの工程で何を渡すかを先に決めておくと、全体の流れを見通せ、途中の判断もぶれにくくなります。

▼全体ガイドの記事
・Sitecoreのシステム開発の完全ガイド

Sitecoreのシステムの全体像

XM・XP・XCと周辺システムのデータ管理の役割を並べた図解。
製品機能とデータの保管先を分けて整理できます。

SitecoreはCMSにとどまらず、企業のデジタル体験を管理するDXPとして設計されています。ECやCRMなどの専門システムと、どこまでを誰が受け持つかを決めることが、開発の出発点です。

SitecoreはCMSだけでなく顧客体験の基盤

Sitecoreの製品と周辺システムは、役割を分けて組み合わせます。

  • XM:コンテンツの作成と管理を担う(Experience Manager)
  • Experience Platform(XP):xConnectとxDBで顧客行動データを扱い、分析やパーソナライゼーションを受け持つ
  • Experience Commerce(XC):コマース機能の担当
  • 追加製品:Content Hub、CDP、Personalize、Search、OrderCloudから必要なものを選び、組み合わせる
  • データ管理:商品はPIM、注文・決済はECまたはOMS、在庫はERPやWMS、会員はCRMが保持

Sitecoreはページ、キャンペーン、コンポーネント、顧客体験を管理します。一方で、すべてのCRMや受注管理を置き換えるとは限りません。コンテンツや体験の層と、取引や基幹処理の層のどちらを誰が担うかを、開発の前に決めておく必要があります。

特に、データの正本が曖昧なままだと、価格や在庫の不一致、二重登録、個人情報の過剰なコピーが起きがちです。

XM Cloudと従来のXM/XPの使い分け

新規構築では、SaaS型のXM Cloudを候補に入れます。なお、公式概要ではPages、SXA、Headless Services、Next.js SDK、Experience Edgeなどが含まれます(出典: Sitecore Developer Portal「XM Cloud Product Overview」)。

  • XM Cloud:管理と配信を分離し、Next.jsなどのヘッドレス構成を取りやすい
  • 従来XM/XP:既存xDB・xConnect、細かなサーバー制御、独自モジュールを活用
  • 運用比較:従来環境は構築、バックアップ、監視、パッチ、更新、脆弱性対応を担う
  • 判断軸:既存資産、運用負担、5年程度の総保有コスト、移行難易度

XM CloudのフロントエンドはVercel、Azure、AWSなどでホスティングできます。一方で、従来XM/XPはAzureなどで運用する選択肢があります。

比べる際は、初期開発費に加えて、既存資産を残す価値と運用負担を減らす価値を並べて検討します。

導入に向く企業と慎重に検討すべき企業の分かれ目

Sitecoreは、多言語・多地域、複数ブランド、複数チャネルでコンテンツを再利用したい企業に向きます。また、承認フローや公開予約を使い分ける場合にも適しています。

顧客の属性や行動に応じて体験を改善したい場合も、候補になります。一方で、単一サイトで更新頻度が低く、独自の顧客データ活用や複雑な連携を予定しない場合は、機能と費用が釣り合わない可能性があります。

製品デモを見る前に、導入判断に必要な項目を整理しておきます。

  • 対象範囲:サイト数とブランド数
  • 運用条件:対応言語、翻訳責任者
  • 負荷:月間トラフィックとピーク時の負荷
  • データ:会員・商品・注文・在庫の正本
  • 運用体制:編集者数、承認経路、公開後に改善を続ける体制

この5項目に答えられないまま製品デモだけを比べると、導入後に追加開発が膨らみがちです。

ポイント

迷ったときは、Sitecoreに任せる範囲と既存システムに残す範囲を先に分けます。XM Cloudか従来XM/XPかも、この線引きと既存資産の量をもとに比べます。

Sitecoreのシステム開発の進め方(6フェーズ)

Sitecore開発を要件整理からテスト、稼働・定着へつなぐ流れ図。
各段階の判定条件が次の作業をつなぎます。

Sitecore開発では、製品構成からコンテンツモデル、外部連携、移行、運用教育までを一つの計画にまとめます。そのうえで、各フェーズに成果物と次へ進む判定条件を置くと、後工程の手戻りを抑えられます。

フェーズ1:要件整理による目的と責任の範囲の確定

要件整理では、解決したい経営・業務の課題を、導入の目的として具体的なKPIに落とし込みます。

  • 目的の例:公開日数や翻訳重複の削減、店舗とECの商品統一、会員再訪率の向上
  • 現状整理:CMS、EC、CRM、PIM、ERP、WMS、POS、分析基盤のデータ項目を洗い出す
  • 成果物:課題、対象チャネル、構成図、連携一覧、移行対象、非機能要件、概算日程
  • 次工程の判定:対象・除外範囲、データの正本、編集者が運用を具体的に描けるか、未決定事項の担当と期限

現状整理では、各システムの更新頻度や障害時の連絡先、保有部門も一覧にします。

フェーズ2:製品選定とPoCによる実現性の検証

要件を基に製品構成を比べます。PoCでは、見栄えのよいトップページよりも、失敗しやすい代表ケースを選びます。

  • 構成候補:XM Cloud、従来XM/XP、CommerceやOrderCloudとの組み合わせ
  • 比較項目:配信、既存機能移行、xDB・xConnect、ホスティング、運用、地域、SLA、更新方法
  • PoC対象:多言語の承認・公開予約、ブランド間の部品再利用、商品更新、会員データの出し分け
  • 技術検証:Experience Edge配信、基幹API障害時の処理、速度、編集手順、API応答、権限、ログ、復旧時間

SaaSは運用負担を下げやすい一方で、標準の拡張方式に合わせる必要があります。従来環境は自由度がある反面、運用の責任範囲が広くなります。

PoCの合格条件は、表示速度や復旧時間のように測れる値で定めておきます。

フェーズ3:標準機能を使った設計・開発

設計では、画面を作るより先に、コンテンツモデルと運用モデルを決めます。そのうえで、再利用する単位と、作成・承認・公開・廃止を担う担当者を決めます。

  • 再利用と運用:ページ、セクション、部品、画像、動画、商品、キャンペーンの単位と担当
  • SEO移行:URL、リダイレクト、メタ情報、構造化データ、翻訳キーをモデルに含める
  • 実装方針:公式のNext.js SDK、SXA、Experience Edgeを使い、独自実装は必要な範囲に絞る
  • 連携と品質:同期API、イベント、リトライ、タイムアウト、重複排除、監視、個人情報のマスキングを設計

この設計を先に固めておくと、移行後のSEO事故を抑えられます。また、開発中はコードレビュー、環境ごとの設定分離、CI/CD、最小権限、テストデータの匿名化を、あわせて確かめておきます。

フェーズ4:業務と非機能を同時に確認するテスト

品質を判断するには、単体・結合テストに加えて、実業務と非機能の受入条件も検証する必要があります。

  • 編集業務:作成、承認、翻訳、予約公開、差し戻し、公開後の修正
  • 連携異常:API停止、古いデータ、重複イベント、タイムアウト、部分成功を試す
  • 非機能:ピーク時の速度、キャッシュ、検索、Edge・外部配信、バックアップ、監視、障害通知、復旧手順
  • 安全性:アクセス権限、多要素認証、ログ保存期間、脆弱性診断、個人情報マスキングを検証

合格条件は数値で示し、未達のときの改善費用と延期の判断を、事前に決めておきます。

フェーズ5:段階リリースと切り戻しの準備

市場、ブランド、コンテンツ種類で区切り、段階的にリリースします。

  • 先行対象:業務量が適度で協力を得やすく、失敗時の影響を限定できる領域
  • 公開前:DNS、証明書、CDN、検索、分析タグ、301、フォーム、決済、問い合わせ窓口
  • 稼働判定:未解決障害、移行件数、SEOクロール、ページ表示、編集者教育、監視通知、当番体制
  • 切り戻し・初動:注文影響、個人情報の誤表示、重大脆弱性、復旧見込み時間を基準にする

公開後の数日間は、開発会社と業務部門が同じダッシュボードを見て状況を共有します。

フェーズ6:運用と改善の仕組みづくり

操作研修に加えて、顧客側で運用設計と改善の仕組みを整えます。機能を増やすこと自体は、目的にしません。

  • 運用文書:コンテンツ、権限、承認、修正、翻訳、障害連絡、改善要望を定める
  • 効果測定:月次KPIで公開時間、再利用率、コンバージョン、検索、問い合わせ削減を評価
  • 顧客側の対応:XM Cloudでも品質、権限、フロントエンド、連携、データ保護を管理
  • SLAと契約:監視、更新・パッチ、99.90%以上の稼働率、対象外・クレジット条件を確認

2026年4月版のSLAは、24時間365日の監視、保守に伴う更新・パッチ、月間稼働率99.90%以上のコミットメントを示しています(出典: Sitecore「SaaS Service Level Agreement」v1.7)。

発注側は、契約前にSitecoreと自社の責任の範囲を確かめ、保守窓口と改善予算も残しておきます。

ポイント

迷ったときは、次のフェーズへ進む判定条件を満たしているかで決めます。満たしていない項目は、担当と期限を決めたうえで、次へ進みます。

Sitecoreのシステム開発の費用相場とコスト内訳

Sitecoreの価格は、企業規模、トラフィック、サイト数、ユーザー数、機能、契約条件によって変わります。そのため、一律の価格表では判断しきれず、条件ごとに金額を見ていく必要があります。

ここに示す金額は、公開された海外事例と市場推計を、2026年時点の比較用に1ドル=150円で概算したものです。これは為替や契約内容で変わる目安で、日本国内の正式見積もりとは別物です。

初期導入費の幅(約1,500万円〜1.5億円超)

初期費用は規模や移行・連携の範囲で変わるため、下に示す数字は参考レンジとして読みます。

Forrester ConsultingがSitecoreの委託を受けて、2025年7月にXM CloudのTEI資料を公開しています(出典: Forrester Consulting「The Total Economic Impact of Sitecore XM Cloud」2025年7月)。

  • 比較的単純なXM Cloud移行:約1,500万〜7,500万円未満
  • 小〜中規模CMS:約2,100万〜4,800万円の推計
  • 大企業の複合案件:約4,500万〜1.5億円超の推計
  • Forresterのモデル:複合企業の一回限りの実装費10万ドル、導入例のパートナー費用は50万ドル未満

大規模案件の数字は、複数サイト、多言語、会員・商品・基幹連携を含む場合の推計です。移行件数やデザイン変更、API数、データ整備、テスト範囲によっても、金額は変わります。

導入インタビューでは、期間が4〜6か月の例もあります。

この数字はSitecoreの定価でも、日本企業の相場でもありません。社内稟議では、公開モデルに基づく参考レンジであると明記しておきます。

見積書の内訳:ライセンス、移行、連携、運用

初期費用は、4つの区分に分けて見ると比べやすくなります。

  • 契約・要件:Sitecore契約、追加モジュール、現状分析、要件定義
  • 設計・開発:UX、デザイン、デザインシステム、テンプレート、コンポーネント、フロントエンド
  • 移行・連携:コンテンツ、メディア、CRM・ERP・PIM・OMS・POS・決済
  • 検証・稼働:テスト、性能検証、教育、稼働支援

見積書には、移行件数に加えて、重複削除や画像差し替え、URL調整、翻訳、手作業の有無も明記してもらいます。

公開推計では、ライセンスやSaaS契約が年約750万〜3,000万円超とされています。一方、従来環境のクラウド基盤と運用インフラは、年約300万〜1,500万円超です。

保守・改善は、年約375万〜1,800万円程度のレンジです。ただし、いずれも市場推計で、Sitecoreが正式に提示した額ではありません。

税や為替、環境数が見積書に含まれるかを確かめます。さらに、トラフィック上限、ユーザー数、追加サービス、サポート水準も、前提として確認しておきます。

期間と総保有コストでの比較

開発方式を比べるときは、期間と初期費用だけでなく、継続費用も見積もります。

  • 期間:単純移行の公開事例は4〜6か月
  • 工程表:Discovery、PoC、移行リハーサル、受入、教育、安定稼働支援を含める
  • 総額:初期費用に加えて、3〜5年分の契約・基盤費、保守と脆弱性対応、改善、人件費
  • 方式ごとの費用:XM Cloudのホスティング等と従来環境のパッチ・監視工数

複数ブランドや多言語、EC・会員・基幹連携を含む場合、要件整理とデータ整備まで入れると、1年以上の計画になることもあります。

XM Cloudは、インフラ運用や大規模更新の負担を下げやすい一方で、フロントエンドのホスティングや外部サービスの費用が別に必要です。

従来環境は既存資産を活かせる場合があります。ただし、パッチ適用や監視の工数も見積もっておく必要があります。

ポイント

迷ったら、初期導入費だけでなく、見積書の内訳と3〜5年分の総額で比べます。公開事例の数字は、参考レンジとして扱います。

Sitecoreの見積もりを取る際のポイント

SitecoreのRFPで提示する規模・利用、性能・移行、連携・体制、受入条件の4項目を並べた図解。
4項目を共通の前提にすると提案を照らし合わせやすくなります。

製品名だけで見積もりを依頼すると、各社の提案を比較できません。そこで、各社の提案を同じ前提で比べられるよう、RFPには目的や範囲、現行資産、データ、連携、非機能の条件を書き込みます。移行、運用、契約条件も含めます。

曖昧な項目は未確定と明示し、そのうえで金額の幅と確定期限を出してもらいます。

RFPに書く成果物と判定条件

RFPでは、対象範囲と判定条件を具体的に書き、各社が同じ前提で提案できるようにします。

  • 規模・利用:サイトとページ、コンテンツ・メディア件数、言語、編集者、権限、ワークフロー
  • 性能・移行:月間PV、ピーク負荷、移行対象、URL、SEO要件
  • 連携・体制:連携先、API仕様、環境数、納期、教育、保守時間
  • 受入条件:承認・公開、URL転送、障害時の復旧を完成条件にする

要件は、必須・望ましい・将来検討に分けます。初回はコンテンツ管理と多言語公開にとどめ、CDPや高度なパーソナライゼーションを第二段階にする方法もあります。

事業価値と学習効果の高い順に段階を分けると、予算とリスクを管理しやすくなります。

開発会社の比較:認定と担当チーム

認定の有無だけでなく、提案構成を担うチームまで見て、条件をそろえて比べます。

  • 実績・技術:Sitecoreの認定・Specialization、同規模・同業界、XM Cloud/従来環境の経験
  • 担当体制:提案構成の担当者、認定・経験年数、再委託範囲
  • 提案の前提:要件解釈、標準機能とカスタム、未計上、移行、テスト、障害時の責任
  • 会社比較:「別途見積り」等を確認し、課題に近い2〜3社を同じ条件で比較

あわせて、Next.js・JSS・Azure、外部基幹連携、移行、保守の技術力も確かめます。比較先には、Sitecore専門会社や大手SI、Azure運用会社、マーケティング戦略会社などがあります。

公式パートナーであることは入口の条件で、提案構成を誰が担うのか、担当者の認定や経験年数まで確かめます。

追加費用とセキュリティリスクの事前確認

追加費用とセキュリティ対応は、移行前に検証し、責任の範囲を確かめておく必要があります。

  • 追加費用の要因:データ品質、既存テンプレート再現、未整備API、翻訳・法務担当の未定
  • 移行リハーサル:1ページの作業量、例外、手作業の割合を測定
  • 従来環境:サポート対象版、修正適用、パッチ、設定、監視、脆弱性診断を確認
  • SaaS:顧客側カスタマイズや外部連携について、責任範囲を契約で定める

2025年、SitecoreはSC2025-005(CVE-2025-53690)の注意喚起を出しました。構成によっては、リモートコード実行や情報への不正アクセスにつながる可能性があります(出典: Sitecore Knowledge Portal「Security Bulletin SC2025-005」)。

同社はサポート対象バージョンの維持と修正適用を推奨しています。そのため、従来環境では修正の対応担当も見積もりに含めます。

ポイント

見積もりを比べる前に、RFPの前提と除外項目をそろえておきます。前提がそろわないまま金額だけを見ると、後から追加費用が膨らみがちです。

Sitecoreのシステム開発でよくある質問(FAQ)

Sitecore開発では、製品の違い、費用、期間、連携、運用体制についての質問がよく出ます。

導入判断の初期に確認しやすいものから、実務上の結論を先に示して答えます。

XM Cloudと従来のXM/XPはどちらを選ぶべきですか?

新規構築でインフラ運用とアップグレードの負担を抑えたいなら、XM Cloudを第一候補にします。ただし、既存のxDB・xConnectや独自機能が必要で、サーバー制御が業務要件なら、従来XM/XPも比べます。

最終的な判断は、機能表だけでなく、移行費用、5年分の運用費、PoCの結果をもとに下します。

Sitecoreの導入費用はいくらかかりますか?

公開事例と市場推計では、単純な移行や初期実装が約1,500万〜7,500万円未満、大規模な多言語・複数サイト・外部連携の案件が約4,500万〜1.5億円超とされ、参考になります。

契約や追加モジュール、移行、連携、保守の範囲によって金額は変わるため、単一の額で断定はできません。

見積もりを依頼する前に、ページ数、データ件数、連携先、トラフィック、運用体制をそろえておきます。

Sitecoreの開発会社は何を基準に選べばよいですか?

認定やパートナーランクだけでなく、同じ製品構成、業界、規模での実績を確かめます。

  • 技術の経験:XM Cloudか従来環境かの経験、Next.js、Azure、外部EC・CRM・ERP連携の経験
  • 移行と保守:データ移行と稼働後の保守を、同じ担当チームが支援できるか
  • 責任の範囲:標準機能とカスタマイズの境界、除外項目、担当者、障害時の連絡経路

SitecoreのAI機能や個人データは安全に利用できますか?

安全性は、製品名よりも、入力データや利用目的、アクセス権、保存期間の設計で決まります。委託先、出力の確認者、監査ログも、あわせて設計して判断します。

  • 生成AIへの入力:顧客情報や未公開の商品情報を渡す場合は、利用範囲と学習利用の有無を契約や設定で確かめます。
  • 公開前の確認:Human in the Loopの仕組みで行います。
  • 海外向けの法令:海外拠点やEU向けサービスを含む場合は、個人情報保護法やEU AI Actなどが当てはまるかを、法務・セキュリティ担当と確認します。

ポイント

判断に迷ったら、製品の選び方、費用、AI機能や個人データの扱いのどれに当たるかを見て、社内要件と開発会社の回答をもとに決めます。

まとめ:6フェーズと判断基準をそろえた進め方

Sitecore開発は、要件整理、選定、設計・開発の順に進みます。その後は、テスト、稼働、定着へと続きます。始めに決めるのは、KPIと、データの責任の範囲です。

XM Cloudと従来XM/XPは、移行費用、運用負担、拡張性で比べます。そのうえでPoCにより実現性を確かめ、モデル、連携、非機能、移行、教育の計画へ進みます。

導入後の業務まで含めた成功基準

費用は、初期導入費に加えて、契約、インフラ、移行、連携、保守の総額で判断します。脆弱性対応や社内運用も、同じ総額に含めます。

見積書では、範囲、除外項目、期間、受入条件、責任の範囲を並べて比べます。パートナーを選ぶ際は、認定だけでなく、同じ構成の実績と稼働後の支援体制も見ます。

最初の一歩:現行システムとデータの棚卸し

対象サイトとブランド、言語とコンテンツ件数、編集者を一枚にまとめます。連携先、ピークトラフィック、現行課題も同じ一覧に書き出します。

その情報をもとに、実現したい体験と、EC・CRM・PIM・ERPなどに残す処理を分けて考えます。導入前に判断基準を具体化しておくと、費用や納期、運用のぶれを抑えられます。

▼全体ガイドの記事
・Sitecoreのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。