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

Adobe Commerceのシステム開発を発注するなら、ECサイトの制作費だけでなく、商品・価格・在庫・受注・基幹連携・保守まで含めた業務システムとして要件を定義することが重要です。

Adobe Commerceは、B2Cの販売サイトから、取引先別価格や承認ワークフローを持つB2Bコマース、複数ブランド・多言語・多通貨の越境ECまで対応できる高機能な基盤です。一方で、発注形態や契約、データ移行、ERP・WMS連携の責任分界を曖昧にしたまま外注すると、見積の追加やリリース延期につながります。この記事では、Adobe Commerceのシステム開発を発注・外注・委託する際の進め方、RFPの作り方、契約形態、費用相場、委託先の選び方を順番に解説します。

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

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

Adobe Commerceの発注は、見た目のよいショップを作る依頼ではなく、販売業務の流れをデジタル化するプロジェクトです。まず、何を標準機能で使い、何を拡張機能や個別開発で補い、どの業務を周辺システムに残すかを決めます。

Adobe Commerceでは、商品カタログ、顧客アカウント、顧客グループ別価格、プロモーション、在庫、注文、返品、配送などを管理できます。B2Bでは、会社アカウント、担当者の権限、承認、見積、契約価格、共有カタログなどが関係します。そのため、発注時に「商品ページを作る」「会員登録を付ける」とだけ伝えると、業務ルールの漏れが起きやすくなります。現場がどの情報を登録し、誰が承認し、どのシステムを正とするかまで書き出すことが大切です。

発注前には、現行業務をAdobe Commerceの標準機能、B2B標準機能、Commerce Marketplaceなどの拡張機能、App BuilderやAPIによる外部拡張、個別開発の順にFit/Gap分析します。コアコードを直接改変すると、アップデートや脆弱性対応の負担が増えます。API、イベント、外部サービスを使ってコアの外側に機能を置けるかを、委託先に確認してください。

また、初回リリースですべてを実装する必要はありません。売上と業務継続に必須のMust、効果が高いShould、将来拡張のLaterに分けると、MVPの範囲と予算を管理しやすくなります。要件を増やすことより、最初の稼働に必要な業務を絞ることが、発注の品質を高めます。

Adobe Commerceは、複雑な価格設定、取引先ごとの商流、多数の商品や在庫拠点、複数ブランド・地域の運営、ERPやWMSとの連携を重視する企業に向いています。反対に、商品数が少なく、標準的なB2C販売だけを短期間で始めたい場合は、機能と運用コストが過剰になる可能性があります。Adobeの価格ページも一律の料金表ではなく、グローバル、マルチブランド、B2B・B2Cなどの要件に応じたカスタマイズ価格の相談を案内しています（出典：Adobe「Adobe Commerce pricing」、2026年）。

Adobe Commerceの発注形態はどれを選べばよいですか？

発注形態は、企業の内製力、要件の複雑さ、納期、運用を担う人員で選びます。Adobeや認定パートナーに上流から一括委託する方法、複数社に分けて発注する方法、自社主導で開発会社の技術支援を受ける方法があります。最適解は会社の知名度ではなく、業務要件とプロジェクトの責任範囲が合っているかで決まります。

要件定義、デザイン、Adobe Commerceの設定・開発、データ移行、連携、テスト、リリース後の保守までを一社にまとめる方法です。社内にECやITの専門家が少ない場合、窓口と責任者を一本化できる点がメリットです。反面、提案内容を比較しにくく、委託先の実力にプロジェクト全体が左右されます。契約前に、設計書、ソースコード、テスト結果、運用手順書の納品範囲と、再委託の有無を確認します。

基幹連携はSI会社、画面やコンテンツは制作会社、クラウド運用はインフラ会社というように分ける方法です。各分野の専門性を活かせますが、API仕様、障害時の切り分け、スケジュール、受入条件を発注者が統合しなければなりません。複数社にするなら、発注者側にプロジェクト責任者を置き、誰が全体の品質と納期に責任を持つかを文書で決めます。

自社が要件と優先順位を決め、開発会社からプロジェクトマネージャー、Adobe Commerceエンジニア、連携担当などの支援を受ける方法です。継続的に改善するサイトや、将来の内製化を見据える企業に向いています。業務理解や意思決定を自社で担うため、担当者の時間を確保できることが前提です。人数だけを契約すると、成果物や受入条件が曖昧になりやすいため、スプリントごとの成果、レビュー、課題管理を契約書や計画書に含めます。

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

外注プロジェクトは、企画、要件定義、設計・開発、移行・テスト、リリース、保守の順に進めます。実際には工程が重なりますが、各段階で発注者が承認する成果物を決めておくと、後からの認識違いを抑えられます。特にAdobe Commerceでは、画面の完成だけでなく、受注データの連携やピーク時の性能まで受入条件にすることが重要です。

最初に、商品マスタ、顧客マスタ、価格、在庫、注文、出荷、返品、会計の現状を棚卸しします。例えば商品情報をPIMが管理し、在庫をERPやWMSが管理し、Adobe Commerceは販売価格と注文を扱うなら、その役割と同期タイミングを明記します。担当部門ごとに別のExcelやシステムが正になっている場合は、開発より先にデータオーナーを決める必要があります。

この段階では、業務フロー、画面一覧、権限一覧、連携一覧、非機能要件、移行対象、運用体制を成果物にします。売上や法令に直結する要件と、リリース後に改善できる要件を分けることで、見積の前提が明確になります。

要件定義の後は、Adobe Commerceの設定、テーマ、拡張機能、個別モジュール、API、バッチ、エラー処理、監視を設計します。ERP・WMS・CRMとの連携では、リアルタイム連携か定時バッチか、連携失敗時の再送と重複防止を決めます。注文を二重登録しない仕組みや、在庫を引当済みとして扱う時点を曖昧にすると、販売機会の損失や出荷ミスにつながります。

フロントを標準テーマ、独自テーマ、PWAやヘッドレスのどれにするかもこの段階で決めます。Adobe公式の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は、開発会社に価格だけを聞く文書ではありません。自社の事業目的、現状、対象範囲、期待する成果、制約、提案してほしい事項を同じ条件で伝え、比較可能な提案を得るための文書です。完成した仕様書がなくても構いませんが、未決定事項を未決定のまま明記することが重要です。

冒頭には、なぜAdobe Commerceを検討するのか、何を改善したいのかを書きます。例えば、取引先別価格の手作業を減らす、海外サイトを共通基盤で運営する、部品検索から購入までの時間を短縮する、既存ECの保守切れに備える、といった目的です。売上、受注処理時間、入力ミス、問い合わせ件数、サイト表示速度など、測定可能な成果指標も置きます。

対象範囲は、サイト、管理画面、商品・顧客・注文データ、決済、配送、在庫、ERP、WMS、PIM、CRM、分析、メール、会員移行、運用教育まで書きます。対象外も同じくらい重要です。例えば会計システムの改修は別プロジェクト、店舗POSは対象外と明記すると、提案と見積の差が小さくなります。

機能一覧だけでなく、「誰が、いつ、どのデータを使い、何を承認し、どのシステムへ渡すか」という業務シナリオで書きます。B2Bなら、企業登録、会社階層、担当者権限、見積依頼、承認、契約価格、注文書、請求までを一連の流れにします。B2Cなら、会員登録、検索、カート、決済、配送、返品、ポイントやクーポンの条件を整理します。

さらに、標準機能で実現したい要件、拡張機能で対応してもよい要件、個別開発が必要な要件を提案者に判定してもらいます。RFPに「標準・拡張・個別の理由と、将来のアップデート影響を示してください」と書くと、単に機能を実装するだけの提案との差が見えます。

非機能要件には、月間・日次の注文数、同時アクセス、ピーク時の注文数、目標表示速度、稼働時間、バックアップ、復旧目標、ログ保存、権限管理、監視、セキュリティ、個人情報の扱いを含めます。数値が分からない場合でも、過去のアクセスログ、受注実績、キャンペーン予定から仮置きし、提案者に前提と確認方法を求めます。

Adobe公式のシステム要件では、2026年時点で2.4.8-p5についてPHP 8.4・8.3、OpenSearch 3、MariaDB 11.4・11.8、RabbitMQ 4.2などが示されています。非対応の組み合わせはAdobeが検証・サポートしないため、RFPには想定バージョン、更新方針、検証環境、パッチ適用の担当を記載します（出典：Adobe Experience League「System requirements」、2026年）。

契約形態と責任分界はどう設計すべきですか？

Adobe Commerceのシステム開発では、企画・要件定義の不確実性と、開発後に確定した成果物を同じ契約で扱わないことがポイントです。要件が固まる前は準委任で調査・設計を進め、仕様と受入条件が固まった部分は請負に切り替えるなど、工程に合った契約を検討します。

準委任は、専門家の知見や作業を一定期間提供してもらう契約です。現行業務の調査、Fit/Gap分析、RFP作成支援、プロジェクト管理、アジャイル開発、保守運用など、進めながら優先順位が変わる工程と相性がよいです。時間単価や月額だけで判断せず、担当者の役割、稼働時間、会議体、成果の確認方法、課題のエスカレーションを決めます。

準委任では、発注者が意思決定を止めると作業が進まなくなります。商品マスタの責任者や価格承認者を自社に置き、週次の課題確認と月次の予算確認を行います。委託先に任せる範囲と、自社が決める範囲を分けることで、責任の押し付け合いを防ぎます。

請負は、合意した成果物を完成させ、検収する契約です。確定した画面、モジュール、API、移行プログラム、テスト仕様書、運用手順書などを対象にしやすく、予算と納期を管理しやすい点が特徴です。ただし、要件が曖昧なまま請負にすると、対象外や変更として追加費用が発生しやすくなります。仕様書、成果物、納期、検収基準、瑕疵対応、変更手続を契約書や個別契約に明記します。

Adobe Commerce on Cloud Infrastructureは、Adobe、利用企業、クラウド事業者、CDN事業者が責任を分担するPaaSです。Adobeは基盤のセキュリティやインフラのPCI認証などを担いますが、利用企業はカスタムコード、拡張機能、接続システム、アプリケーションのテスト、パッチ適用、PCI対応プロセスを担います（出典：Adobe Experience League「Shared responsibility security and operational model」、2026年）。

外注時には、Adobeが提供する基盤の範囲、委託先が行うパッチ検証、発注者が承認するリリース、拡張機能の脆弱性対応、WAFや監視、障害時の連絡順を一覧化します。SaaSを選ぶ場合も、機能差、Luma非対応などの制約、既存カスタムの移行可否、更新で変わる範囲を確認します。Adobe公式の比較資料も、SaaSとPaaSではカスタマイズ、拡張性、コントロールの水準が異なると説明しています（出典：Adobe Experience League「Adobe Commerce SaaS and PaaS feature comparison」、2026年）。

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

Adobe Commerceのライセンス料金は、企業規模、GMV、構成、契約条件に応じた個別見積です。そのため、以下の金額はAdobeのライセンス料や決済手数料、広告費を含まない、国内の公開価格と業務システムの相場から整理した「構築・移行・連携・初期設定」の目安です。要件定義後に再計算する前提で、特定金額を確約するものではありません。

標準的な小規模ECであれば、テーマ調整、商品・顧客・注文、基本決済を中心に、構築費は200万〜500万円程度、期間は3〜6か月程度が一つの目安です。国内ベンダーの公開情報には標準構成200万円〜、3か月〜という入口の例がありますが、Adobe Commerceのライセンス費用そのものを示す価格ではありません（出典：マルウェブ「Magentoとは？特徴・費用・Shopifyとの違い」、公開情報）。

既存ECからの移行、複数決済、在庫・物流連携を含む中規模では、500万〜1,500万円程度、4〜9か月程度を見込みます。B2Bの取引先別価格、会社階層、承認、見積、ERP・WMS連携まで含む場合は、1,500万〜5,000万円程度、6〜12か月程度が目安です。多国展開、複数ブランド、リアルタイム連携、ヘッドレス、厳格な性能・監査・DRを含む大規模案件では、5,000万〜1億5,000万円以上、9〜18か月以上になる可能性があります。いずれも要件、データ量、連携数、試験範囲で上下します。

見積書は「開発一式」ではなく、要件定義、設計・環境構築、実装、データ移行、外部連携、テスト、教育、リリース、保守に分解してもらいます。リサーチノートで整理した業務システム相場の比率を仮置きすると、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度を検討の起点にできます。この比率はAdobe Commerce固有の公定価格ではなく、提案内容の偏りを確認するための目安です。

例えば実装費が安く見えても、移行リハーサル、連携エラーの再送、負荷試験、脆弱性診断、受入支援が別見積なら、総額は上がります。逆に、設計やテストの工数が十分に含まれている見積は、初期費用だけでなく品質と将来の保守性を見ている可能性があります。工程ごとの成果物と工数を並べ、同じ条件で比較してください。

初期構築後は、Adobeのライセンス、クラウドまたはサーバー、CDN、監視、バックアップ、決済、拡張機能、メール、脆弱性診断、パッチ適用、バージョンアップ、追加開発が継続的に発生します。保守費は初期構築費の年15〜25%程度を一般的な業務システムの目安として置けますが、24時間監視、障害対応時間、SLA、改修枠、セキュリティ対応の範囲で変わります。金額を一本で聞かず、年間の固定費と変動費に分けて確認します。

また、SaaSはインフラ管理や更新の負荷を下げやすい一方、PaaSやオンプレミスより自由なカスタマイズに制約が出る場合があります。PaaSは柔軟性が高い代わりに、コードや拡張、パッチの運用責任が残ります。導入費の安さだけでなく、3年程度の運用体制と将来の移行費を含めて判断してください。

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

委託先は、Adobeの認定表示や会社規模だけで選ばないことが大切です。Adobe Commerceの構築経験、B2B・B2Cの業務理解、ERP・WMS・PIM連携、データ移行、性能試験、パッチと脆弱性対応、保守窓口を、今回の要件に照らして評価します。実績はロゴの数ではなく、似た規模と複雑さの案件で何を担当したかを確認します。

候補会社には、商品数、顧客数、月間注文数、拠点数、ストア数、言語数、ERP・WMS・PIMの種類、移行件数、ピーク時のアクセス、保守期間を伝え、類似案件の担当範囲を聞きます。B2Bであれば、会社階層、契約価格、承認、見積、PunchOutなどの経験を確認します。越境ECであれば、多通貨、税、配送、決済、言語、現地法令への対応を質問します。

公式事例も、機能名だけでなく業務成果に翻訳して読みます。JCBの公式事例では、Adobe CommerceとiWebにより25万SKUの部品カタログ、部品番号・シリアル番号検索、ディーラー管理システムとのAPI連携、マルチストアを実現し、新規顧客の20%がリピート顧客に転換したと紹介されています。また、サイトは4か月で完成したとされています（出典：Adobe「JCB customer success story」、確認日2026年）。このように、候補会社へは「何を作ったか」だけでなく「どの課題をどの方式で解決したか」を聞きます。

3社程度から提案を受ける場合は、同じRFP、同じデータ件数、同じ連携一覧、同じテスト範囲を渡します。比較表には、工程、成果物、担当者、期間、工数、費用、前提、除外、再委託、保守、SLA、追加費用の条件を並べます。安い会社を選ぶのではなく、抜けている作業がない会社を見つけます。

特に確認したいのは、データ移行の回数、移行後の照合、拡張機能のライセンス、決済審査、コンテンツ登録、SEOリダイレクト、負荷試験、脆弱性診断、教育、リリース立会いです。要件変更の単価や承認フローが書かれていないと、プロジェクト途中で予算を管理できません。提案プレゼンでは、想定リスクを先に説明し、できないことを正直に示す会社を評価します。

商談では、提案書を書いた人が要件定義に参加するか、実装と保守を誰が担うか、再委託先はどこか、担当者が変わった場合にどう引き継ぐかを確認します。Adobe Commerceのバージョンアップ、セキュリティパッチ、第三者拡張の更新、決済障害、在庫連携の失敗、緊急時の連絡方法について、平常時と障害時の対応時間を聞きます。

さらに、ソースコード、設計書、IaC、テストコード、CI/CD設定、アカウント、拡張機能のライセンス、著作権、再利用できる部品の扱いを確認します。納品後に別会社へ保守を切り替えられるかも重要です。委託先を選ぶことは、開発期間だけでなく、数年の運用パートナーを選ぶことだからです。

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

ここでは、Adobe Commerceの外注を検討する企業から寄せられやすい質問に、発注判断に使える形で回答します。自社の条件に置き換えながら、RFPや提案依頼の確認項目として利用してください。

構築・移行・連携・初期設定だけなら、標準的な小規模ECで200万〜500万円程度、中規模の移行案件で500万〜1,500万円程度、B2BやERP連携で1,500万〜5,000万円程度が目安です。ただし、Adobeのライセンスは個別見積で、クラウド、決済、拡張機能、保守、追加開発も別に発生します。RFPで要件と除外範囲を揃えて見積を比較してください。

認定やパートナー表示は候補を探す入口になりますが、それだけで判断しないでください。今回と近い商品数、業界、B2B業務、ERP・WMS連携、移行、性能試験、保守の実績があるかを確認し、提案担当者と実装・保守担当者の体制を聞きます。実績の担当範囲、再委託、パッチ対応、障害時のSLAまで確認して初めて、依頼先として比較できます。

要件が固まっていない調査・要件定義・伴走開発は準委任、仕様と受入条件が明確な実装や成果物は請負が向いています。すべてを一つの契約にせず、工程ごとに契約を分けると、要件変更の扱いと責任が明確になります。契約前に、成果物、検収、変更手続、知的財産、再委託、保守への切替条件を確認してください。

運用負荷を抑え、Adobeが管理する範囲を広げたい場合はSaaSを候補にします。既存Magento資産や深いカスタマイズ、インフラ制御、PaaS専用の機能を重視する場合はPaaSやオンプレミスを検討します。SaaSは機能差、既存拡張の代替、Lumaを含むフロントの制約、データ・カスタムコードの移行可否を確認してから発注してください。提案依頼では、選択理由と将来の移行経路を比較させると判断しやすくなります。

まとめ

Adobe Commerceのシステムを発注・外注する際は、ECサイトの制作範囲だけでなく、販売業務、データ、外部連携、セキュリティ、保守までを一つの計画として整理します。特に、標準機能・拡張機能・個別開発の境界、RFPの前提、契約形態、費用の除外項目、責任分界を先に決めることが重要です。

最初に、商品、顧客、価格、在庫、注文、出荷、返品、会計のデータオーナーを決め、Must・Should・Laterで初回リリースの範囲を絞ります。そのうえで、業務シナリオと非機能要件をRFPにまとめ、要件定義、設計、実装、移行、テスト、保守を工程別に見積してもらいます。構築費は規模により200万〜500万円程度から1億5,000万円以上まで幅があるため、金額だけでなく前提と除外を比較します。

委託先は、認定や知名度ではなく、同規模のB2B・B2C案件、ERP・WMS・PIM連携、移行、性能試験、パッチ対応、保守体制を確認して選びます。請負と準委任を工程に合わせて使い分け、ソースコードや設計書、テスト結果、アカウント、拡張機能の扱いを契約に残します。Adobe Commerceを導入すること自体を目的にせず、複雑な商流やデータ連携を改善し、継続して運用できる体制まで含めて発注してください。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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