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

Adobe Commerceの開発は、業務整理と方式選定から始めます。続いて設計・開発を行い、試験、稼働、定着の順に進めます。その過程で、販売業務とデータ連携を整えていきます。

費用と見積もりで確認する点も、あわせて取り上げます。全体像について詳しくは、下のリンク先の完全ガイドもご覧ください。

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

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

Adobe Commerceのシステムの全体像

Adobe Commerceは、商品マスタや顧客情報を管理し、注文から決済、在庫、配送、会計へつなぐ中心基盤です。販売画面と管理画面の内側だけで考えると、周辺業務とのつながりが抜けやすくなります。そのため、最初にどの業務データをAdobe Commerceの正として扱うかを決めます。

販売業務システムとしてのAdobe Commerce

画面一覧から始めると業務ルールや連携に抜けが生じやすいため、最初に業務図を作ります。業務図では、どの業務データを誰が登録し、誰が更新し、どこから参照するかを明らかにします。

• 販売データ：商品、カテゴリ、画像、価格、プロモーション
• 顧客・受注：顧客、会員、在庫、注文、返品
• 販売連携：決済、配送、コンテンツ、検索、分析
• B2B機能：企業アカウント、共有カタログ、取引先別価格、権限、承認、見積依頼

さらに、受注から出荷、返品、請求までの流れも業務図に含めます。B2Bで販売する場合は、上の一覧にあるB2B機能が要件の候補になります。

在庫をERPの正とする場合は、Commerceで編集するか、ERPから定期的に連携するかによって、権限、API、エラー処理、運用担当が変わります。また、注文後のキャンセル期限、分納、返品の可否、店舗受取の扱いも決めておくと、設計・テスト・見積の内容が具体的になります。

標準機能・拡張機能・個別開発の切り分け

要望はまず標準機能で満たせるかを確認し、必要に応じて拡張や開発へ進めます。コアコードを直接改変すると、パッチやバージョンアップのたびに差分の検証が必要になります。

• 標準機能：設定だけで要件を満たせるかの確認
• 拡張：Marketplace、API、イベントで補える範囲の検討
• 個別開発：独自モジュールやコア改変。最後に検討する対象

コア改変は将来の移行費用を膨らませやすいため、Fit/Gapで実現方法を判定します。PaaSやオンプレミスは自由度が高い反面、運用、パッチ、監視の責任が利用企業側に残ります。一方、Adobe Commerce as a Cloud Serviceは、Adobeが管理するSaaSで、運用負荷を抑えやすい方式です。

ただし、SaaSとPaaSは機能や拡張方法が同じとは限りません。公式の比較では、ストアフロント、コンテンツ、カタログ、B2B機能の提供方法が異なります。また、既存のカスタムをそのまま移せるかも決めつけず、方式を比べます。

Adobe Commerceのシステム開発の進め方

開発は6フェーズで進みます。要件整理と選定の次に設計・開発を行い、最後はテスト、稼働、定着です。各段階で残す成果物と承認者、次の段階へ進む条件をあらかじめ決めておきます。そうすると、要件の追加や責任の押し付け合いを防ぎやすくなります。

フェーズ1：要件整理による業務とデータの正の確定

まず、EC、ERP、WMSなど現行のシステムを一覧にします。CRM、店舗、決済、配送、会計も対象に含めます。そのうえで、データごとに、登録元や連携方向、更新頻度、失敗時の再処理を確認します。

• 対象データ：商品、顧客、価格、在庫、注文、出荷、返品、ポイント
• 連携条件：方向、頻度、許容遅延、失敗検知の担当と期限
• 優先度：要望のMust、Should、Laterへの分類

連携は「リアルタイム連携」と書くだけでなく、許容遅延を何分にするか、失敗を誰が何分以内に検知するかまで決めておきます。

Mustには、売上、法令、業務継続に直結する機能を置きます。一方、Shouldは改善効果が高い機能で、Laterは将来の多言語化やヘッドレス化などです。

この段階で残す資料は、業務フロー、機能一覧、非機能要件です。移行対象表、連携一覧、課題・前提・制約の台帳も残します。事業と業務の担当者が確認し、情報システム、物流、CSの担当者も加わります。法務とセキュリティの担当者まで確認が済んでから、選定へ進みます。

フェーズ2：選定での構築方式とFit/Gapの比較

Adobe Commerceを採用する理由を、業務要件に結び付けます。企業別価格、会社階層、購買承認などが投資効果の中心なら、Adobe Commerceを候補に入れます。

また、複数ブランド・国での運営、複雑な商品属性、ERP・WMS連携も、投資効果の中心なら候補になります。一方、商品販売が単純で、連携や権限の要件が少ない場合は、運用負荷の小さいサービスも比較します。

• 方式：PaaS、オンプレミス、SaaSを同じ条件での比較
• 拡張：カスタムモジュール、GraphQL・REST API、外部拡張の対応範囲
• 運用：データ出力、復旧、環境数、監視、パッチ、サポートの扱い

デモでは、通常購入だけでなく、価格変更、在庫不足、分納、返品、承認却下、連携失敗後の再処理も実演してもらいます。そうすることで、製品の違いと提案力を判断できます。

フェーズ3：設計・開発での連携と拡張の責任の明確化

画面の設計より先に、構成とデータ連携を固めます。認証、監査ログ、再試行、重複排除を、システムのどこで担うかを定義します。

• 構成図：Webフロント、Commerce、DB、キャッシュ、検索、キューの配置
• 境界：CDN・WAFと外部システムとの接続点
• 連携定義：送受信元、形式、認証、タイムアウト、再送、手動復旧、通知の取り決め

Adobe Commerce 2.4.8-p5では、PHP 8.4または8.3、OpenSearch 3、MariaDB 11.4または11.8などが要件です。そのため、採用版と互換性のある構成にします（出典：Adobe Commerce「System Requirements」、2026年6月更新）。

開発では、標準機能、設定、テーマ、拡張機能、独自モジュール、外部連携を分けて管理します。

移行は、少量移行、全量リハーサル、差分移行、本番移行の順に行います。あわせて、件数照合とサンプル確認の結果も記録します。

フェーズ4：テストによる正常系と業務停止リスクの洗い出し

単体、結合、システムの各試験を分けて進めます。さらに、受入、性能、セキュリティの試験と、移行リハーサルも行います。担当者には、画面操作だけでなく、実際の一日の注文処理を再現してもらいます。

• 注文：購入完了、二重注文、クーポン条件外、価格期限切れ
• 例外：在庫引当失敗、決済タイムアウト、返品・返金、配送分割
• 連携：外部API停止時の動作の確認

性能試験は、平均的なアクセスではなく、繁忙期の同時接続、検索、カート投入、注文ピークを基準に行います。目標値は、表示時間に加えて、注文完了率、API応答、キュー滞留、検索遅延、DB負荷、エラー率で定めます。

Adobeの責任分界では、カスタムアプリの性能試験とQAは利用企業側の責任になります。そのため、「クラウドだから安心」として試験を省かないようにします。

フェーズ5・6：稼働と定着による運用の仕組み化

稼働前には移行判定会議を開き、移行件数と金額、決済・配送・在庫連携、権限を確認します。あわせて、バックアップと復旧、監視通知、問い合わせ窓口、切り戻しの条件も確認します。

段階リリースや限定商品の先行稼働が可能であれば、一斉切替のリスクを下げられます。そのうえで、切り戻し時間と注文データの扱いも決めておきます。

• 日次：注文、決済、連携エラーの確認
• 週次：検索、在庫、返品、権限の見直し
• 月次：売上、コンバージョン、再購入、欠品、連携遅延、パッチの確認

定着には、操作研修に加えて、日次・週次・月次の運用設計が必要です。Adobe Commerceは導入後も改善を続けます。

さらに、拡張機能の更新、脆弱性対応、バージョンアップ、商品登録ルールの改善も継続します。責任者、一次対応者、ベンダー、Adobeの窓口を一覧にしておくと、障害時の初動が速まります。

Adobe Commerceの費用相場とコストの内訳

費用は、ライセンス、クラウド、構築に分けて考えます。デザイン、移行、外部連携も含めて見ておきます。拡張機能と保守も、あわせて考えます。なお、Adobeの製品価格は、企業規模、GMV、契約条件などに応じた個別見積です。

ここに示す国内の構築費は、ライセンス、決済手数料、広告費を含みません。要件定義の後に計算し直す目安です。

規模別の構築費と期間の目安

小規模ECは、200万〜500万円、3〜6か月程度が目安です。テーマ調整、商品・顧客・注文、基本決済に絞る場合を想定します。

国内ベンダーの公開例には、標準構成200万円から、期間3か月からというものもあります（出典：株式会社マルウェブのAdobe Commerce／Magento構築支援に関する公開情報）。

この金額には、Adobe Commerceのライセンスやクラウド費用が含まれません。そのため、下限だけで判断しないようにしてください。

• 中規模：既存EC移行、会員・受注、複数決済、在庫・物流連携で500万〜1,500万円、4〜9か月
• B2B：取引先別価格、承認、見積、会社階層、ERP・WMS、性能・移行試験で1,500万〜5,000万円、6〜12か月
• 大規模：複数国・ブランド、ヘッドレス、リアルタイム基幹連携、厳格な監査やDRで5,000万〜1億5,000万円以上、9〜18か月以上

いずれも目安で、機能数だけでなく、連携先、データ品質、試験範囲によって大きく変わります。

初期費用とランニングコストの分解

見積では、項目を初期費用とランニング費用に分けて整理します。

• 初期費用：企画・要件定義、基本設計・詳細設計、環境構築
• 実装・移行：フロント実装、Commerce設定・開発、外部連携、移行、テスト、教育、稼働支援
• ランニング費用：ライセンス、クラウド、CDN・WAF・監視、決済、検索・レコメンド、拡張更新、保守、脆弱性診断、追加開発

比率を仮に置くなら、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%です。ただし、これは一般的な業務システムの相場を参考にした配分で、Adobe Commerce案件の固定比率ではありません。

保守費は、業務システムの目安として、初期構築費の年15〜25%程度と考えられます。24時間監視、SLA、セキュリティ対応、月間改修時間の有無によって変わります。

見積では、月次対応時間、緊急対応、パッチ、バージョンアップ、障害調査の範囲を分けて確認します。「保守一式」とまとめてあると、費用の中身を判断しにくくなります。

初期費用ではなく3年程度のTCOによる判断

採用の判断では、初期費だけでなく、少なくとも数年分の総保有コストを比べます。その3年分には、構築、ライセンス・クラウド、保守を含めます。さらに、拡張、決済、移行も入れます。追加開発、更新、障害対応もあわせて含めます。

• 投資効果：価格・受注の標準化や重複運用の削減を、業務コストを含めて評価
• 構成の妥当性：要件が少ない場合、大規模ヘッドレスや過剰な個別開発は費用を増やす要因
• 比較項目：初年度額、2年目以降の固定費、追加開発単価、データ取得費（運用工数の削減効果を含む）

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

見積は、金額の安さだけでなく、前提と成果物の具体性で評価します。移行、連携、試験、セキュリティ、保守が別契約だと、追加費用が起きやすいためです。

まず、必要条件をRFPに書き、各社から同じ粒度の工程別見積を受け取ります。

RFPに書く業務・データ・非機能の条件

RFPには、対象サイトとブランド数、国・言語・通貨を記します。SKU数、顧客数、月間・ピーク注文数、同時接続数も書きます。さらに、会員ランクと価格ルール、在庫拠点を書き添えます。配送パターン、返品、決済、連携先も加えます。

移行件数に加えて、画像容量、属性数、過去注文の保持年数、会員パスワードの移行可否によっても、見積が変わります。

• 性能・復旧：表示・API・注文時間、稼働率、バックアップ、復旧目標時間と時点
• 統制：監査ログ、権限、脆弱性診断、PCI DSS、個人情報の保管場所
• バージョン：サポート構成と更新方針の指定

Adobe Commerce 2.4.8では、PHPや検索エンジンなどのサポート構成を守る必要があります。対象外の依存ソフトでは、障害調査やセキュリティ対応を受けられない可能性があります。

開発会社の実績・担当者・保守体制による比較

認定状況だけでなく、同規模・業界・連携構成の事例を確認します。たとえば、Adobe公式のJCB事例には、25万SKU、部品・モデル番号検索、ディーラー管理連携、マルチストアがあります。

事例では、機能名だけでなく、移行数、ピーク性能、障害対応、運用人数、稼働後の改善を質問して確かめます。数字と公開時点は、提案時に再確認します。

• 体制：要件定義の担当者が実装・保守にも関わるか
• 経験：ERP・WMS・PIM・決済連携、移行リハーサル、2.4.8以降への更新経験
• 契約：SaaS移行時のカスタム評価、障害時の一次窓口、再委託範囲

ソース、設計書、IaC、拡張機能ライセンスの帰属も、契約で確認します。3社以上から同じRFPで提案を受けると、工程の抜けや価格差が見やすくなります。

追加費用と遅延のリスクへの契約上の備え

追加費用は、データ欠損、複雑な価格、古いAPI、決済審査、移行できないパスワード、拡張の互換性、性能不足などから生じる場合があります。そのため、見積の時点でサンプルデータを渡し、重要連携と業務シナリオを検証します。調査項目は、確定見積に含めるか、調査フェーズの上限額と成果物を定めるかのどちらかにします。

• 受入と変更：成果物の基準、変更管理、遅延時の責任
• 保守と権利：再委託、知財、脆弱性発見時の修正期限、パッチ、引き継ぎ
• 責任分界：Adobeと利用企業の担当範囲の、契約と運用設計での一致

Adobeはコア基盤やプラットフォームの一部を担います。一方で、カスタムコード、外部連携、拡張、アプリQA、性能試験、利用企業側のPCI対応は、企業側に残ります。責任分界を契約と運用設計で一致させておくと、稼働後に担当がはっきりしない事態を防げます。

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

導入時は、機能、費用、移行、保守をまとめて確認します。よくある疑問ごとに、判断の目安を示します。

Adobe CommerceとMagento Open Sourceはどう使い分けますか？

複雑なB2B商流、企業別価格、承認、複数ブランド・国を重視する場合は、Adobe Commerceが比較候補になります。

外部連携やAdobe Experience Cloudとの連携を重視する場合も、Adobe Commerceが候補に入ります。

一方、販売がシンプルで、必要な機能を個別に補える場合は、Magento Open Sourceも候補になります。拡張・開発費、保守責任、サポートを含めて判断します。

Adobe Commerceのシステム開発には何か月かかりますか？

開発期間の目安は、構成の規模や移行・連携の範囲によって異なります。

• 小規模：標準的な構成で3〜6か月
• 中規模：既存EC移行や複数連携を含み、4〜9か月
• 大規模：B2B・ERP連携や多国展開を含み、6〜18か月以上

要件整理、移行リハーサル、性能・受入試験を短くすると、稼働後の障害や追加費用につながります。

期間は、機能数だけでなく、意思決定の速さ、データ品質、連携先の仕様、社内の受入体制によっても変わります。

Adobe Commerce as a Cloud ServiceとPaaSはどちらがよいですか？

運用負荷を抑えて、標準機能で早く立ち上げたい企業は、SaaSを比較対象にします。一方、既存資産、複雑なカスタム、細かなインフラ制御を重視する企業は、PaaSを優先します。

SaaSは、PaaSの単純な上位互換とはいえません。コンテンツ、ストアフロント、カタログ、B2B、拡張方法に差があるためです。そのため、独自モジュール、テーマ、連携、移行データが移せるかは、PoCで確認してから決めます。

稼働後の保守で特に確認すべきことは何ですか？

Commerce本体とPHPや検索などの依存ソフトには、更新、試験、障害対応の担当を決めます。カスタムコードや第三者拡張、外部連携、クラウド・CDN・WAFについても、それぞれ担当を決めます。

Adobe公式のライフサイクルポリシーでは、各リリースに標準サポート期間があります。たとえば、2.4.8系は2028年までサポート対象として案内されています。そのため、採用版の期限、パッチ適用期限、アップグレード予算も、運用計画に含めます。

まとめ

Adobe Commerceの開発は、ECサイトを作るだけの仕事ではなく、販売業務とデータ連携を再設計するプロジェクトです。まず業務とデータの正を決め、方式を比べ、機能・拡張・個別開発の境界を定めます。

成果物と判定条件による6フェーズのつなぎ方

要件整理と選定を行い、設計・開発へ進みます。全体は6段階で、テスト、稼働、定着へと続きます。各段階では、業務フロー、Fit/Gap表、構成図を残しておきます。移行・テスト記録、切り戻し計画、運用手順も残します。

事業とシステムの責任者が、各成果物を承認します。費用は、構築だけでなく、ライセンス、クラウド、保守を含むTCOで比べます。拡張、パッチ、移行、追加開発も、TCOに含めます。

最初に作る資料：業務・連携・移行のチェックリスト

導入準備では、業務・連携・移行の情報を一つの資料にまとめます。

• 業務と連携：商品、顧客、価格、在庫、注文、出荷、返品の流れと、ERP・WMS・PIM・決済・配送との連携の整理
• 選定準備：Must／Should／Later、非機能、移行、保守責任の整理と、同じRFPによる複数社の比較
• パートナー：移行、性能、脆弱性、更新、SaaS移行まで相談できる会社の選定

▼全体ガイドの記事
・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を創業。