Sitecoreのシステム開発の発注/外注/依頼/委託方法について

Sitecoreのシステム開発を発注・外注するなら、製品を入れること自体ではなく、対象サイト・データ連携・運用体制・セキュリティまで含めた全体像を先に決めることが重要です。特にXM Cloudか従来のXM／XPか、CMSだけか顧客データやコマースまで扱うかで、費用と委託先に求める技術が大きく変わります。

本記事では、Sitecoreのシステム開発を発注・外注・委託する担当者に向けて、発注形態の選び方、RFPと要件整理、契約形態、2026年時点での費用相場、開発会社の選定、見積比較、導入後の運用までを順番に解説します。社内稟議やベンダーへの相談前に、何を決め、何を質問すればよいかが分かる構成です。

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

Sitecoreのシステム発注・外注では何を決めますか？

結論から言うと、最初に決めるべきことは「どの機能を作るか」よりも「どの業務成果を、どの範囲のシステムで実現するか」です。Sitecoreはコンテンツ管理だけでなく、複数サイト・多言語・顧客データ・パーソナライゼーション・コマースなどを組み合わせられるため、範囲が曖昧なまま見積を依頼すると、会社ごとに前提が変わって比較できなくなります。

発注前に、サイト刷新の目的を「CMSを新しくする」ではなく、問い合わせ数の増加、会員登録率の向上、海外拠点の公開スピード改善、コンテンツ制作工数の削減などの業務目標に置き換えます。そのうえで、対象をコーポレートサイトだけにするのか、ブランドサイト、会員サイト、EC、店舗端末まで含めるのかを決めます。

たとえば商品情報をPIM、受注をECやOMS、在庫をERPやWMS、顧客情報をCRMやCDPが管理している場合、Sitecoreにすべてを集約する必要はありません。Sitecoreをコンテンツと顧客体験の層に置き、各システムとAPIやイベントで連携する責任分界を整理した方が、移行範囲と見積条件を明確にできます。

新規発注では、SaaS型のXM Cloudと、Azureやオンプレミスなどで運用する従来のXM／XPを比較します。XM Cloudは、Sitecore公式が説明するように、ヘッドレスCMS、Pagesエディター、SXA、Headless Services、Next.js SDK、Experience Edgeを含むフルマネージド型のサービスです。コンテンツ管理とフロントエンドを分離し、Experience EdgeのAPIからNext.jsなどの表示アプリへ配信する構成が基本です（出典：Sitecore Developer Portal「XM Cloud」）。

一方、既存のXPでxDB、xConnect、独自インデックス、MVC実装などを利用している場合は、移行前に互換性を確認します。従来環境は細かな制御や既存資産を活用しやすい反面、サーバー、バックアップ、監視、パッチ、アップグレードを誰が担うかを契約に含める必要があります。委託先には、製品名だけでなく、採用予定の構成と移行方式を明記して提案してもらいます。

Sitecoreの発注形態はどれを選びますか？

発注形態は、完成品を一括して任せるか、企画・要件定義から段階的に任せるか、自社チームと共同で進めるかで考えます。大規模なSitecore案件では、製品選定、コンテンツ移行、デザイン、フロントエンド、外部連携、運用設計が同時に動くため、最初からすべてを固定しすぎないことも重要です。

要件と納期が比較的明確で、受入条件を定義できる場合は、設計・開発・テスト・リリースを請負契約でまとめる方法があります。発注側の窓口を一本化しやすく、社内の開発要員が少なくても進めやすい点が特徴です。ただし、Sitecoreの導入では要件定義後に移行データや連携仕様の課題が見つかりやすいため、変更の扱いと追加費用の条件を契約前に定めます。

一括請負であっても、RFPに「Sitecoreを導入する」とだけ書くのは不十分です。対象URL数、コンテンツ件数、言語数、ブランド数、連携先、非機能要件、受入テストの合格条件まで書いて初めて、会社間の見積を比較しやすくなります。

XM Cloudと従来環境の差、既存コンテンツの移行難易度、Next.jsを使ったヘッドレス構成、CDPや外部ECとの連携可否が分からない場合は、最初にDiscoveryやPoCを発注します。期間と成果物を限定し、現行調査、構成案、移行サンプル、主要連携の技術検証、概算見積を出してもらう方法です。

PoCでは、本番に近い代表ページを数種類、移行対象データを少量、重要な外部連携を一つ以上選びます。見栄えだけのデモでは、実際の権限、公開ワークフロー、エラー処理、性能、運用担当者の使いやすさが分かりません。PoC終了時に「本番採用する条件」と「採用しない場合の撤退条件」を決めておくと、次工程への進退を判断しやすくなります。

自社にプロダクトマネージャー、ITアーキテクト、コンテンツ責任者、運用担当者がいる場合は、委託先にすべてを丸投げせず、役割分担型にします。委託先はSitecoreの設計・開発・移行を担当し、自社は優先順位、業務ルール、承認者、データの正しさ、受入判断を担います。

この形では、週次の意思決定会議、課題管理表、設計レビュー、ソースコードと環境設定の引き渡し、運用マニュアル、担当者向けトレーニングを成果物に含めます。プロジェクト終了後にベンダーへ質問し続ける状態を避けるため、知識移管の完了条件を数値や資料名で定義します。

RFPと要件整理はどこまで書けばよいですか？

RFPは機能一覧だけでなく、背景、対象範囲、現状、制約、成果物、評価方法を含めて作成します。委託先に自由な提案を求める部分と、必ず守ってほしい条件を分けると、提案力を比較しながら前提のずれも抑えられます。

まず、なぜ今Sitecoreのシステム開発を行うのかを記載します。たとえば、海外拠点ごとにCMSが分かれて更新が遅い、ブランドごとに表現が統一できない、会員データとコンテンツが分断されパーソナライズできない、といった課題です。KPIはページ制作日数、公開リードタイム、問い合わせ率、会員登録率、検索経由の売上など、導入後に測れるものにします。

対象チャネルはWebだけか、スマートフォンアプリ、メール、店舗端末、会員ポータルまで含むかを定義します。多言語・マルチサイトの場合は、言語数、ブランド数、ドメイン数、共通コンポーネント、地域ごとの承認ルールを明記します。ここが曖昧だと、同じページ数でも工数が大きく変わります。

現行CMSのサイト構成、テンプレート、コンポーネント、ユーザー権限、ワークフロー、公開予約、リダイレクト、画像・動画、PDF、検索、フォームを一覧化します。移行対象は「全部」ではなく、残す・作り直す・アーカイブする・廃棄するに分類します。ページ数だけでなく、再利用する部品数、翻訳の有無、作成者と承認者の人数も見積条件に含めます。

連携では、CRM、CDP、PIM、ERP、EC、OMS、WMS、POS、決済、検索、分析、認証のシステム名と、データ項目、更新頻度、連携方向、障害時の扱いを整理します。個人情報を扱う場合は、保管場所、アクセス権限、ログ、委託先、海外拠点への移転を要件に入れます。連携一覧があるだけで、各社の見積漏れを発見しやすくなります。

非機能要件には、想定PV、同時接続数、応答時間、可用性、バックアップ、障害復旧時間、監視、ログ保存、脆弱性診断、認証方式、権限分離を含めます。ECや会員サイトでは、キャンペーン時の負荷、在庫連携の遅延、決済障害時の表示も確認します。Sitecore CloudではSaaS側とフロントエンド側の責任分界を分けて書くことが重要です。

移行要件では、URLを維持するか、301リダイレクトをどう管理するか、メタ情報・構造化データ・画像の代替テキストをどう移すかを決めます。運用要件では、公開後の問い合わせ窓口、保守時間、緊急パッチ、月次改善、Sitecoreのバージョン管理、担当者教育を定義します。発注時点で運用を外すと、稼働後に別契約の費用が発生しやすくなります。

Sitecore開発の契約形態はどう使い分けますか？

契約は、成果物と完成責任を重視する部分に請負契約、調査・伴走・継続改善のように作業量や優先順位が変わる部分に準委任契約を使い分けるのが基本です。契約名だけで決めず、作業範囲、成果物、検収、責任分界、変更手続、知的財産、再委託、秘密保持、個人情報、障害対応を条項と別紙で確認します。

請負契約では、設計書、実装済みコンポーネント、移行済みコンテンツ、テスト結果、操作マニュアルなど、何を納品するかを一覧にします。検収では「画面が表示される」だけでなく、指定ブラウザ、権限別の操作、公開予約、検索、連携エラー、性能、アクセシビリティなどの合格条件を定義します。

要件変更が起きた場合は、影響範囲、追加工数、納期変更、費用、承認者を記録してから着手する変更管理にします。口頭依頼を積み重ねると、発注側は予算超過、受注側は無償対応という認識のずれが起きます。RFPの前提条件と除外事項を契約書の別紙に添付すると、変更判断がしやすくなります。

要件定義、現行調査、アーキテクチャ検討、移行計画、PMO、運用改善は、調査結果で次の作業が変わるため、準委任契約が適することがあります。発注側は作業時間や体制を確認し、受注側は月ごとの稼働範囲、会議体、成果報告、課題管理、優先順位の決め方を明らかにします。

準委任だから成果物が不要という意味ではありません。現行分析報告書、要件一覧、構成比較、PoC結果、リスク一覧、次工程の見積など、各期間のアウトプットを決めます。継続支援では、毎月の改善件数や対応時間を単純な件数だけで評価せず、事業KPIと運用品質も確認します。

Sitecore案件では、(1) Discovery・要件定義、(2) PoC・基本設計、(3) 詳細設計・開発、(4) 移行・テスト、(5) リリース・教育、(6) 保守・改善に分ける方法が現実的です。最初のフェーズで全体の概算を作り、次のフェーズへ進むゲートを設けると、技術的に難しい連携を早期に発見できます。

ただし、分割しすぎるとベンダー間の責任分界が複雑になります。要件定義会社と開発会社を分ける場合は、設計書の著作権、引き継ぎ時間、質問への回答者、品質保証の主体を契約で明確にします。後工程の会社が「前工程の資料不足」を理由に追加費用を出さないよう、成果物のレビューと受入を各フェーズで行います。

Sitecoreのシステム開発費用・相場はどのくらいですか？

Sitecoreの公式な一律価格表は確認できず、ライセンスやSaaS契約は企業規模、トラフィック、環境数、ユーザー数、製品・追加モジュール、契約条件で変わります。したがって、以下は日本企業への請求額を保証するものではなく、2026年時点で社内予算を置くための比較用レンジです。ライセンス、実装、移行、連携、保守を分けて見積を取ります。

公開されたForrester ConsultingのXM Cloud TEIでは、複合企業をモデルにした初期導入費が26万ドル弱、実装期間が3〜6か月とされています。1ドル150円の比較換算では約3,900万円弱です。また、別の導入インタビューではデジタルエージェンシーの実装費が50万ドル未満とされ、同じ換算で約7,500万円未満です。これは特定のモデル企業・調査条件の値であり、日本の定価ではありません（出典：Forrester Consulting「The Total Economic Impact of Sitecore XM Cloud」）。

この公開事例と、海外市場の実装推計を踏まえると、比較的単純なCMS移行・初期実装は約1,500万〜7,500万円を計画上の幅として置く方法があります。小・中規模の実装で約2,100万〜4,800万円、大企業の複数サイト・多言語・基幹連携で約4,500万〜1.5億円超という推計もあります。コンテンツ件数や連携数が多いEC・オムニチャネル案件では、上限を超える可能性もあります。

ライセンスやSaaSサブスクリプションは、公開市場推計では年約750万〜3,000万円超を比較の起点とする見方がありますが、製品、トラフィック、ユーザー、追加機能、契約条件で変動します。見積では、Sitecoreの契約費用に何が含まれるか、環境数や検証環境が別料金か、為替や契約更新で変動するかを確認します。

従来のXM／XPをAzureなどで運用する場合は、クラウド基盤、監視、バックアップ、環境維持、パッチ対応を含めて年約300万〜1,500万円超、保守・サポート・改善は年約375万〜1,800万円という推計を置くことがあります。XM Cloudではインフラ負担の構造が変わる一方、フロントエンドのホスティング、CI/CD、外部連携、運用支援は別途必要です。初年度だけでなく、3年程度の総保有コストで比べます。

見積書では、(1) Sitecoreのライセンス・SaaS契約、(2) 現行調査と要件定義、(3) UX・デザインとデザインシステム、(4) コンテンツモデルとコンポーネント開発、(5) フロントエンドとホスティング、(6) データ移行・SEO移行、(7) CRM・PIM・ERP・ECなどとの連携、(8) テスト・教育・運用保守に分けてもらいます。費用だけでなく、各費目の前提数量と除外事項を並べることが大切です。

特に見落とされるのがコンテンツの品質整備です。古いページの重複整理、画像の権利確認、翻訳、URL設計、メタ情報、リダイレクト、データクレンジングは、単純な機械移行では済まないことがあります。移行件数を1ページ単位で数えるだけでなく、テンプレート種類、コンポーネント数、例外ページ、言語ごとの違いを確認して算出します。

Sitecoreの委託先選定と見積比較のポイントは何ですか？

委託先は、知名度や見積総額だけでなく、採用するSitecore構成を実装できるか、同じ規模・業界の経験があるか、稼働後まで責任を持てるかで選びます。Sitecore公式のパートナー制度や認定は参考になりますが、認定の有無だけでプロジェクトの成功が保証されるわけではありません。提案対象と同じ製品・技術を担当者が扱った実績を確認します。

候補会社には、Sitecoreのパートナーランク、認定資格、Specialization、導入年、対応製品、担当するエンジニアの経験を質問します。たとえばXM Cloud、従来のXM／XP、CDP、Personalize、Commerce、OrderCloudのどこまで扱えるかは会社ごとに異なります。公式パートナー検索では、SCSKについてGold Partner、Experience PlatformのSpecialization、8名のCertified Professionalsなどが掲載されていますが、時点により更新されるため発注時に再確認します（出典：Sitecore公式パートナー情報「SCSK」）。

実績は社名や導入件数だけでなく、課題、構成、期間、移行件数、連携先、担当範囲、稼働後の成果まで聞きます。可能であれば、提案時の営業担当者とは別に、実装責任者、アーキテクト、移行責任者、運用責任者の面談を行います。再委託がある場合は、どの会社が何を担当し、品質と情報管理を誰が保証するかを明らかにします。

XM Cloudを選ぶ場合は、CMSの設定だけでなく、Next.jsなどのフロントエンド、Experience Edge、ホスティング、CI/CD、プレビュー、キャッシュ、監視を設計できるか確認します。Sitecore公式ドキュメントでは、Experience EdgeはGraphQL APIを通じてコンテンツを配信し、Vercel、Netlify、AWS、Azureなどのホストでアプリを動かす構成が説明されています。そのため、Sitecore担当者だけでなく、フロントエンドとクラウド運用の体制も必要です（出典：Sitecore Developer Portal「How to Set Up XM Cloud」）。

外部連携では、API仕様、認証、データ形式、同期方式、再送、重複排除、タイムアウト、障害通知、手動復旧を質問します。商品や注文などの取引データをSitecoreに持たせる場合は、既存ECやOMSとの責任分界が崩れないかを検証します。PoCで代表的な連携を動かし、性能と障害時の運用まで確認できる会社を優先します。

見積比較では、金額を足し合わせる前に、前提条件を同じシートへ転記します。対象サイト数、ページ・コンポーネント数、言語数、移行件数、連携先、環境数、テスト範囲、担当者数、期間、保守時間、ライセンスの含有、税・為替、出張、再委託、追加費用をそろえます。安い提案が魅力的に見えても、移行やテストが除外されていれば、実質的な総額は比較できません。

評価表は、価格だけでなく、要件適合度、Sitecoreの専門性、アーキテクチャ、移行計画、PM体制、品質管理、セキュリティ、運用保守、提案の具体性に配点します。見積が一式表記になっている場合は、工数、単価、役割、期間、成果物の内訳を再提出してもらいます。各社に同じRFPと質問票を渡し、回答期限と提案時間もそろえることが公正な比較につながります。

従来のXM／XPやManaged Cloudを含む環境では、Sitecore公式が2025年にSC2025-005、CVE-2025-53690について、構成によってはリモートコード実行や情報への不正アクセスにつながる可能性がある脆弱性を告知しています。発注時には、サポート対象バージョン、緊急パッチの通知と適用、ASP.NET machine keyなどの設定管理、脆弱性診断、ログ監視、インシデント時の連絡先を確認します（出典：Sitecore Security Bulletin SC2025-005）。

XM Cloudでも、SaaS側がすべてを担うわけではありません。フロントエンド、外部ホスティング、APIキー、権限、コンテンツ公開、個人情報、生成AIへの入力データ、委託先アカウントは発注側と受託側の双方で管理します。月次の脆弱性確認、障害対応の目標時間、バックアップと復旧テスト、担当者の交代時の引き継ぎを保守契約に含めます。

発注からリリースまでの進め方はどうなりますか？

発注後は、要件定義、設計、開発、移行、テスト、教育、リリース、改善の順で進めます。各段階で発注側の意思決定者が判断し、課題を次工程へ持ち越さないことが重要です。特にSitecoreでは、コンテンツモデルと運用ワークフローを後回しにすると、画面が完成しても現場が更新できない状態になりやすいです。

要件定義では、業務フロー、ユーザー権限、コンテンツタイプ、公開承認、言語・サイト構成、検索、フォーム、分析、連携、非機能要件を確定します。アーキテクチャ設計では、Sitecoreが管理する情報、外部システムが管理する情報、同期する情報、障害時に一時保持する情報を図にします。

この段階で、標準機能、設定、拡張、外部サービス、スクラッチ開発を分類します。標準から離れるほど、アップグレードや運用時の確認項目が増えるため、独自開発は事業上の差別化に必要な箇所へ絞ります。設計レビューには、業務部門、情報システム、セキュリティ、コンテンツ担当を参加させます。

開発が進んだら、代表データで移行テストを行い、件数、必須項目、リンク、画像、公開状態、翻訳、メタ情報、URL、リダイレクトを確認します。連携テストでは正常系だけでなく、タイムアウト、認証切れ、重複、未登録商品、在庫不整合、部分的な通信障害を再現します。

受入テストは、情報システム部門だけで実施しません。編集者、承認者、マーケティング担当、カスタマーサポート、店舗や海外拠点など、実際に使う人に操作してもらいます。合格条件、未解決課題の扱い、リリース延期の基準を決めておくと、納期だけを優先して品質を下げる判断を防げます。

リリース前には、運用マニュアル、権限表、問い合わせフロー、障害時の連絡網、バックアップと復旧手順、パッチ適用手順を整備します。編集者には、ページ作成だけでなく、コンポーネントの使い分け、承認、公開予約、プレビュー、画像管理、翻訳、検索改善を実際の業務に沿って教育します。

公開後の初期安定化期間は、通常運用と切り分けて設定します。アクセスログ、エラー、公開失敗、連携遅延、編集者からの問い合わせを見ながら、改善バックログを整理します。Sitecore公式はXM Cloudの導入効果として、Forrester調査に基づく371%の3年ROIや、デジタルコンバージョン50%改善を紹介していますが、これは調査対象の複合企業の結果であり、自社で同じ成果を約束する数字ではありません（出典：Sitecoreの2025年発表）。自社KPIを基準に効果を検証します。

よくある質問（FAQ）

Sitecoreの発注では、費用、開発会社、契約、XM Cloudへの移行可否について質問が集中します。自社の状況で判断が変わる点を含め、発注前に確認したい質問へ回答します。

一律の最低価格はありません。Sitecoreの契約条件、対象範囲、移行件数、連携、言語数、要件定義の有無で変わるため、まずは現行調査やPoCだけを小さく発注し、実装の概算を得る方法があります。公開された海外のTEIや市場推計は比較用であり、日本の見積額を保証するものではありません。

Sitecore公式のパートナー検索を起点にしつつ、候補会社へ同じRFPを渡して比較します。パートナーランクだけでなく、XM Cloudまたは従来XM／XPの実績、Next.js・Azure・API連携、移行、運用保守、担当予定者の経験を確認します。自社と同じ業界・規模・多言語数・連携数の事例を聞くことが大切です。

外注できますが、単純なサーバー移行とは限りません。Sitecore公式の案内では、XM CloudはヘッドレスCMSとExperience Edgeを前提とし、既存のMVC実装ではフロントエンドの再構築や利用機能の見直しが必要になる場合があります。現行資産の調査、移行対象の分類、代表ページのPoCを行ってから、本番移行の費用と期間を確定します。

どちらか一方が常に安全ということではありません。成果物と検収条件を固められる開発は請負、調査・要件定義・PMO・継続改善は準委任に分け、変更管理と責任分界を明確にすることが重要です。契約形態よりも、何をいつまでに誰が行い、問題が起きたときにどう判断するかが明文化されているかを確認します。

まとめ

Sitecoreのシステムを発注・外注するときは、まず事業目標と対象範囲を決め、XM Cloudか従来XM／XPか、Sitecoreが担う領域と外部システムが担う領域を整理します。次に、現行サイト・データ・連携・非機能要件・移行・運用をRFPへ落とし込み、候補会社から同じ前提で提案と見積を取得します。

発注前には、現行構成図、サイト・コンテンツ一覧、連携一覧、ユーザー・権限表、移行方針、KPI、RFP、予算の対象範囲、希望スケジュールをそろえます。見積は初期費用だけでなく、ライセンス、クラウド、保守、改善、教育、セキュリティ対応を含む複数年の総額で比較します。

不確実性が高い場合は、いきなり本番開発を一括発注せず、DiscoveryやPoCで移行・連携・運用の難所を検証します。Sitecoreの専門性だけでなく、業務理解、クラウドとフロントエンド、データ移行、セキュリティ、稼働後の改善まで一貫して相談できる委託先を選ぶことが、予算超過と再構築のリスクを抑える近道です。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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