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

Adobe Commerceの発注は、業務とデータの要件を整理するところから始まります。RFPと契約範囲を定めたうえで、移行・連携・試験を経て進めると、稼働後の運用まで見通せます。

発注形態と開発工程、RFPと契約、費用相場と委託先の選び方を見ていきます。全体像は、Adobe Commerceのシステム開発の完全ガイドもご覧ください。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Adobe Commerceのシステムを発注する前に知るべき全体像

Adobe Commerceの発注は、販売業務をデジタル化するプロジェクトとして考える必要があります。そのため、標準機能、拡張機能、個別開発、周辺システムが担う役割を、発注前に決めておきます。

ECサイトではなく販売業務システムという捉え方

発注の時点で、商品ページや会員登録だけでなく、現場が扱う情報と業務ルールを洗い出しておきます。特に、誰が承認し、どのシステムの情報を正とするかは、開発に入る前に決めておく必要があります。

• B2Cの管理対象：商品カタログ、顧客、価格、販促、在庫、注文、返品、配送
• B2Bの管理対象：会社アカウント、担当者権限、承認、見積、契約価格、共有カタログ

業務情報を一覧にしたうえで、登録と承認の担当、データの正本を決めておくと、要件の抜けを防ぎやすくなります。

標準・拡張・個別開発の境界の決め方

発注前には、現行業務をFit/Gap分析で突き合わせ、実現方法を決めておきます。その際は、次の順で標準機能から確認します。

1. Adobe CommerceとB2Bの標準機能
2. Commerce Marketplaceなどの拡張機能
3. App BuilderやAPIによる外部拡張
4. 個別開発

コアコードを直接書き換えると、アップデートや脆弱性対応の負担が増えます。そのため、API、イベント、外部サービスを使ってコアの外に機能を置けないか、委託先に確認します。

初回からすべてを実装する必要はありません。機能をMust、Should、Laterに分けておくと、MVPの範囲と予算を管理できます。

Adobe Commerceが向く企業の見極め

複雑な価格、取引先ごとの商流、多数の商品や在庫拠点、複数ブランド・地域の運営を重視する企業には、Adobe Commerceが合います。

ERPやWMSとの連携を重視する企業にも適しています。一方で、商品数が少なく標準的なB2C販売を短期間で始める場合は、機能や運用コストが過剰になるおそれがあります。

Adobeの価格ページは一律の料金表ではなく、グローバル、マルチブランド、B2B・B2Cなどの要件に応じたカスタマイズ価格を案内しています（出典：Adobe「Adobe Commerce pricing」、2026年）。

Adobe Commerceの発注形態の選び方

発注形態は、内製力、要件の複雑さ、納期、運用人員の組み合わせで選びます。そのうえで、業務要件と責任範囲が合うかを基準にします。

一括請負で上流から運用まで任せる方法

要件定義と設定・開発を一社にまとめて任せる方法で、社内にECやITの専門家が少ない場合は、窓口と責任者を一本化できます。次の工程も、同じ委託先に任せられます。

• デザイン
• 移行
• 連携
• 試験
• リリース後の保守

一方で、提案どうしを比べにくく、委託先の実力が全体を左右する面もあります。そのため、設計書、ソースコード、試験結果、運用手順書の納品範囲と再委託の有無は、契約前に確認しておきます。

複数社に分離発注して専門性を組み合わせる方法

複数社に分ける場合は、分担と連携条件をそろえておく必要があります。たとえば、基幹連携はSI会社、画面やコンテンツは制作会社、クラウド運用はインフラ会社が担うといった分け方です。

• 統合する項目：API仕様、障害時の切り分け、スケジュール、受入条件
• 決める役割：発注者側の責任者と、品質・納期の全体責任者

各分野の専門性を活かせる一方で、全体の統合は発注者が担うことになります。そのため、責任者と責任範囲は文書で定めておきます。

準委任や伴走支援で自社にノウハウを残す方法

自社が要件と優先順位を決め、開発会社からプロジェクトマネージャー、Adobe Commerceエンジニア、連携担当などの支援を受ける形です。

継続的に改善するサイトや、将来の内製化を見据える企業に合う方法です。自社が業務理解と意思決定を担うため、担当者の時間を事前に確保しておくことが前提になります。

人数だけで契約すると、成果物や受入条件が曖昧になりがちです。そこで、スプリントごとの成果、レビュー、課題管理を契約書や計画書に含めておきます。

Adobe Commerceのシステム開発を外注する進め方

外注プロジェクトは、企画から保守までを一続きで進めます。工程が重なる場合でも、各段階で発注者が承認する成果物を決めておけば、認識のずれを抑えられます。

1. 企画・要件定義：業務とデータの役割を整理する
2. 設計・開発：拡張方式とシステム連携を決める
3. 移行・テスト：実データとピーク時の業務を検証する
4. リリース・保守：受入条件を満たした状態で運用へ移る

Adobe Commerceの場合は、画面の出来だけでなく、受注データの連携やピーク時の性能も受入条件に含めます。

企画・要件定義での業務とデータの正の決定

商品、顧客、価格、在庫、注文の今の状態を洗い出します。出荷、返品、会計も洗い出しの対象です。たとえば、PIMが商品を、ERPやWMSが在庫を管理している場合は、それぞれの役割と同期の時点を明記します。

部門ごとに別のExcelやシステムを正としている場合は、開発の前にデータオーナーを決めておきます。成果物には、業務フロー、画面・権限・連携の一覧を含めます。非機能要件、移行対象、運用体制も、成果物として残します。

売上や法令に直結する要件と、リリース後に改善できる要件を分けておくと、見積の前提が明確になります。

設計・開発での連携と拡張の方式の固定

中心になるのは、Adobe Commerceの設定とテーマ、拡張機能の設計です。そのうえで、個別モジュールやAPIなどの部品に加えて、バッチ、エラー処理、監視の仕組みを設計し、ERP・WMS・CRMとの連携方式も決めておきます。

• 連携タイミング：リアルタイムか定時バッチか
• エラー処理：失敗時の再送と重複防止
• 在庫管理：在庫を引当済みとして扱う時点

注文の二重登録や在庫引当の扱いが曖昧なままだと、販売機会の損失や出荷ミスにつながります。

フロントは、標準テーマと独自テーマのほか、PWAやヘッドレスの構成から選びます。Adobe Commerce 2.4.8では、PHP 8.4やMariaDB 11.4への対応などが示されています。

リリースノートでは、GraphQLの改善、Edge Deliveryを使うStorefrontへの移行支援、500件を超える品質改善も記載されています（出典：Adobe Experience League「Adobe Commerce 2.4.8 release notes」、2026年）。

新しい構成を選ぶ場合は、社内で保守できるか、既存の拡張を移行できるかも、見積の条件に含めます。

移行・試験・リリースでの実データとピークの再現

移行と試験では、対象データと業務シナリオを決めたうえで、次の観点を確認します。

• 移行対象：商品、顧客、会員ランク、価格、在庫、注文履歴、クーポン、画像、SEO用URL。変換ルールの作成と、リハーサルの繰り返しが要ります。
• データ検証：件数だけでなく、文字コード、桁数、重複、欠損、関連付けを確かめ、業務部門が実データを照合できる状態にしておきます。
• 試験と判定：単体・結合・受入・負荷試験、脆弱性診断、障害復旧訓練を行い、ピーク時の注文処理を業務シナリオで判定します。

セールやキャンペーンのピークを想定し、商品検索からカート、決済、在庫引当、注文連携までを同時に動かします。そのうえで、判定の対象は、注文の受付、各システムへの連携、失敗の検知です。

RFPと要件整理で決める事項

RFPは、価格だけを聞く文書ではなく、提案者に同じ条件を伝えて、比べられる提案を得るための文書です。事業目的や現状、対象範囲、期待成果を示し、制約と提案事項も明記します。

完成した仕様書がなくても問題ありません。未決定の事項は、その旨を明記しておきます。

RFPの冒頭に置く事業目的と対象範囲

RFPには、事業目的、成果指標、対象範囲、対象外を記載します。範囲をそろえておくと、提案と見積を比べやすくなります。

• 事業目的：取引先別価格の手作業削減、海外サイトの共通基盤化、部品検索から購入までの時間短縮、既存ECの保守切れへの備え
• 成果指標：売上、受注処理時間、入力ミス、問い合わせ件数、サイト表示速度
• 対象範囲：サイト、管理画面、商品・顧客・注文データ、決済、配送、在庫、ERP、WMS、PIM、CRM、分析、メール、会員移行、運用教育
• 対象外：会計システムの改修を別プロジェクトにする、店舗POSを対象外にするなど、対象外の作業も明記します

業務シナリオで書く機能要件

機能一覧に加えて、誰がいつどのデータを使い、何を承認して、どこへ渡すかを書いておきます。B2BとB2Cでは、必要な業務の流れが異なります。

• B2B：企業登録、会社階層、権限、見積、承認、契約価格、注文書、請求
• B2C：会員登録、検索、カート、決済、配送、返品、ポイントやクーポンの条件

標準機能、拡張機能、個別開発のどれで実現するかは、提案者に判定してもらいます。また、方式の理由と将来の更新への影響も示してもらいます。

数字で示す非機能要件と運用体制

非機能要件は数値で示します。数値が不明な場合は、アクセスログや受注実績、キャンペーン予定をもとに仮置きします。

• 性能・可用性：月間・日次の注文数、同時アクセス、ピーク時の注文数、目標表示速度、稼働時間
• 運用・保護：バックアップ、復旧目標、ログ保存、権限管理、監視、セキュリティ、個人情報の扱い
• 提案条件：前提と確認方法を提案者に求め、想定バージョン、更新方針、検証環境、パッチ適用担当をRFPに記載します

Adobeのシステム要件では、2026年時点の2.4.8-p5に対応する構成が示されています。なお、非対応の組み合わせは、Adobeが検証もサポートもしません。

具体的には、PHP 8.4・8.3とOpenSearch 3が対象です（出典：Adobe Experience League「System requirements」、2026年）。さらに、MariaDB 11.4・11.8やRabbitMQ 4.2も対象です（同出典）。

契約形態と責任分界の設計

要件定義には不確実さが残る一方で、開発後に確定する成果物は性質が異なります。そのため、両者を同じ契約で扱わず、工程に合わせた契約を検討します。

要件定義や伴走開発に使いやすい準委任

準委任は、専門家の知見や作業を一定期間提供してもらう契約です。要件や優先順位が変わりうる工程に合います。

• 活用する工程：調査、Fit/Gap分析、RFP作成支援、プロジェクト管理、アジャイル開発、保守運用
• 契約で決めること：時間単価や月額だけでなく、担当者の役割、稼働時間、会議体、成果確認、課題のエスカレーション
• 自社の役割：商品マスタの責任者や価格承認者を置き、委託先との担当範囲を分ける

発注者の意思決定が止まると、作業も進みません。そのため、課題は週次で、予算は月次で確認し、責任の押し付け合いを防ぎます。

実装と明確な成果物を管理する請負

請負は、合意した成果物を完成させ、検収する契約です。確定した画面、モジュール、APIを対象にできます。移行プログラムや試験仕様書、運用手順書も含められます。

予算と納期を管理しやすい一方で、要件が曖昧なままだと、対象外や変更として追加費用が発生しがちです。

仕様書や成果物、納期は、契約書や個別契約に明記します。検収基準と瑕疵対応、変更手続も含めて残します。

クラウド・コード・PCIの担当の三者分担

契約では、基盤・アプリケーション・SaaSとPaaSの違いに沿って、責任範囲を分けます。

• Adobeと基盤事業者：クラウド基盤のセキュリティ、インフラのPCI認証など
• 利用企業：カスタムコード、拡張機能、接続システム、アプリ試験、パッチ、PCI対応プロセス
• 外注時とSaaS利用時：パッチ検証、リリース承認、脆弱性対応、WAF・監視、障害連絡、機能や移行の制約

Adobe Commerce on Cloud InfrastructureはPaaSで、責任はAdobeや利用企業のほか、クラウド事業者とCDN事業者の間で分担されます（出典：Adobe Experience League「Shared responsibility security and operational model」、2026年）。

SaaSを選ぶ場合も、Luma非対応などの機能差を確認します。あわせて、既存カスタムの移行可否や、更新で変わる範囲も確かめます。

SaaSとPaaSでは、カスタマイズ、拡張性、制御の水準が異なります（出典：Adobe Experience League「Adobe Commerce SaaS and PaaS feature comparison」、2026年）。

Adobe Commerceのシステム開発費用相場と見積の内訳

Adobe Commerceのライセンス料金は、企業規模やGMVのほか、構成と契約条件で決まる個別見積です。ただし、次に示す金額には、ライセンス料、決済手数料、広告費を含めていません。

この金額は、国内の公開価格と業務システムの相場をもとにした、構築・移行・連携・初期設定の目安です。要件定義のあとに再計算するもので、特定の金額を確約するものではありません。

規模別に200万円台から1億円超まで広がる構築費

費用と期間は、規模、連携、要件によって異なります。以下の各金額は、ライセンス費用を含まない構築などの目安です。

• 小規模EC：テーマ調整、商品・顧客・注文、基本決済を中心に200万〜500万円程度、3〜6か月程度
• 中規模移行：既存EC移行、複数決済、在庫・物流連携を含み500万〜1,500万円程度、4〜9か月程度
• B2B・ERP連携：取引先別価格、会社階層、承認、見積、ERP・WMS連携を含み1,500万〜5,000万円程度、6〜12か月程度
• 大規模案件：多国展開、複数ブランド、リアルタイム連携、ヘッドレス、厳格な性能・監査・DRを含み5,000万〜1億5,000万円以上、9〜18か月以上

国内ベンダーの公開情報には、標準構成200万円〜、3か月〜という入口の例があります。なお、これはAdobe Commerceのライセンス価格ではありません。この例の出典は、マルウェブの「Magentoとは？特徴・費用・Shopifyとの違い」です。

いずれの規模でも、要件やデータ量に加えて、連携数と試験範囲によって、費用と期間は上下します。

要件定義・設計・実装・試験に分けた見積の比較

見積は「開発一式」とせず、工程と費目に分けてもらいます。下に示す比率は、Adobe Commerce固有の公定価格ではなく、提案の偏りを確かめる目安です。

• 要件定義：10〜12%
• 設計・環境構築：22〜24%
• 実装：48〜50%
• テスト：15〜17%

見積には、要件定義、設計・環境構築、実装、データ移行が含まれているかを確認します。さらに、外部連携、テスト、教育、リリース、保守も入っているかを見ます。

移行リハーサルや連携エラーの再送などが別見積になると、その分、総額は上がります。設計や試験の工数が含まれている見積は、品質や将来の保守性も見込んでいる可能性があります。そこで、工程ごとの成果物と工数を同じ条件で比べます。

ライセンス以外の運用費まで含めた年間TCO

初期構築後の費用は、ライセンス以外の運用費も含めて、固定費と変動費に分けて考えます。

• 継続費用：Adobeのライセンス、クラウド・サーバー、CDN、監視、バックアップ、決済、拡張機能、メール
• 保守・更新費：脆弱性診断、パッチ、バージョン更新、追加開発

一般的な業務システムでは、保守費は初期構築費の年15〜25%程度が目安になります。ただし、24時間監視、障害対応時間、SLA、改修枠、セキュリティ対応によって変わります。

SaaSは、インフラ管理や更新の負荷を下げやすい一方で、PaaSやオンプレミスに比べると、自由なカスタマイズに制約が出る場合があります。

PaaSは柔軟性が高いものの、コードや拡張、パッチの運用責任は残ります。

導入費だけでなく、3年程度の運用体制と将来の移行費も含めて判断します。

Adobe Commerceの委託先選定と見積比較のポイント

認定表示や会社規模だけで決めず、今回の要件に照らして評価します。確認の中心は構築経験と業務理解です。そのほか、連携や移行、試験、パッチ、保守窓口も見ます。

同じ業界・規模・連携条件の実績の確認

実績は、案件の規模・業務・連携条件と照らし合わせて確かめます。あわせて、候補会社の担当範囲と解決した課題も見ます。

• 規模と環境：商品数、顧客数、月間注文数、拠点・ストア・言語数、ERP・WMS・PIMの種類、移行件数、ピーク時のアクセス、保守期間
• 業務経験：B2Bの会社階層・契約価格・承認・見積・PunchOut、越境ECの多通貨・税・配送・決済・言語・現地法令
• JCBの事例：25万SKUの部品カタログ、部品番号・シリアル番号検索、ディーラー管理システムとのAPI連携、マルチストア

JCBの事例では、新規顧客の20%がリピート顧客に転換したと紹介されています。また、サイトは4か月で完成したとされています。この事例は、Adobe CommerceとiWebによるものです（出典：Adobe「JCB customer success story」、確認日2026年）。

機能名だけでなく、課題と解決方式を候補会社に聞きます。

金額より前提・除外・変更条件で比べる見積比較

3社程度から提案を受ける場合は、同じRFP、データ件数、連携一覧、テスト範囲を渡して比べます。

• 見積条件：工程、成果物、担当者、期間、工数、費用、前提、除外、再委託、保守、SLA、追加費用
• 作業範囲：データ移行回数と照合、拡張機能ライセンス、決済審査、コンテンツ登録、SEOリダイレクト
• 品質と変更：負荷試験、脆弱性診断、教育、リリース立会い、変更単価と承認フロー

金額の安さよりも、抜けている作業がないかで比べます。提案の時点で、想定リスクとできないことを示す会社を評価します。

契約前に確認する担当者と保守体制

契約前には、担当者、障害対応、納品物、保守の切替条件について提案者に質問します。

• 担当体制：提案者の要件定義参加、実装・保守担当、再委託先、担当変更時の引き継ぎ
• 保守対応：更新、パッチ、第三者拡張、決済障害、在庫連携失敗、緊急連絡の平常時・障害時の対応時間
• 納品と権利：ソースコード、設計書、IaC、テストコード、CI/CD設定、アカウント、拡張機能ライセンス、著作権、再利用部品

納品後に、別の会社へ保守を切り替えられるかも確認します。委託先は、開発期間だけでなく数年の運用パートナーとして選びます。

Adobe Commerceのシステム発注でよくある質問

Adobe Commerceの外注を検討する企業からよく寄せられる質問に答えます。自社の条件に置き換えて、RFPや提案依頼の確認項目として使ってください。

Adobe Commerceのシステム開発費用はいくらですか？

構築・移行・連携・初期設定の目安は、小規模ECで200万〜500万円程度、中規模移行で500万〜1,500万円程度です。B2BやERP連携では、1,500万〜5,000万円程度が目安になります。

Adobeのライセンスは個別見積です。クラウド、決済、拡張機能、保守、追加開発も別に発生するため、RFPで要件と除外範囲をそろえて比べます。

Adobe認定パートナーならどこでも依頼できますか？

認定表示は、候補を探す入口にすぎません。商品数の規模が近い案件や、同じ業界、B2B業務の実績を確認します。また、ERP・WMS連携、移行、性能試験、保守の経験も見ます。

実績の担当範囲、再委託、パッチ対応、障害時のSLAを聞きます。あわせて、提案担当者と実装・保守担当者の体制も確認し、比べます。

請負と準委任はどちらがよいですか？

要件が固まっていない調査や要件定義、伴走開発には準委任が向いています。一方、仕様と受入条件が明確な実装や成果物には、請負が合います。

工程ごとに契約を分けると、要件変更と責任を明確にできます。そのうえで、成果物、検収、変更手続、知的財産、再委託、保守への切替条件を確認します。

SaaSとPaaSは発注前にどのように選びますか？

運用の負荷を抑え、Adobe管理の範囲を広げたい場合は、SaaSを候補にします。反対に、既存Magento資産、深いカスタマイズ、インフラ制御、PaaS専用機能を重視する場合は、PaaSやオンプレミスを検討します。

SaaSの場合は、機能差、既存拡張の代替、Lumaを含むフロントの制約、データとカスタムコードの移行可否を確認します。あわせて、選択理由と将来の移行経路も提案依頼に含めます。

まとめ

Adobe Commerceの発注では、販売業務、データ、外部連携、セキュリティ、保守までを一つの計画にまとめます。そのうえで、標準・拡張・個別開発の境界とRFPを決めておきます。ほかに、次の項目も決めておきます。

• 契約
• 費用の除外
• 責任分界

発注前の業務・RFP・予算のすり合わせ

商品、顧客、価格、在庫のデータオーナーを決め、注文、出荷、返品、会計にも、それぞれ担当者を置きます。そのうえで、Must・Should・Laterに分けて、初回の範囲を絞ります。

業務シナリオと非機能要件をRFPにまとめ、要件定義から保守まで工程別に見積を依頼します。構築費は規模により200万〜500万円程度から1億5,000万円以上まで幅があります。そのため、見積は前提と除外も含めて比べます。

実績と運用責任まで比べる委託先の選び方

認定や知名度よりも、同規模のB2B・B2C案件やERP・WMS・PIM連携の経験を確認します。あわせて、移行、性能試験、パッチ、保守体制も見ます。

請負と準委任は工程に合わせて使い分け、ソースコード、設計書、試験結果、アカウント、拡張機能の扱いを契約に残します。そのうえで、複雑な商流やデータ連携を改善し、継続して運用できる体制まで含めて発注します。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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