BigCommerceとAdobe Commerceの比較：複雑なカタログに強いのはどちらか

2026年8月更新

BigCommerceのストアなら、約4分で費用を見積もれます。すべてのプラン、すべての手数料、すべての売上上限が1つの公開ページに載っているからです。一方、Adobe Commerceは、Adobeに問い合わせない限り費用を見積もれません。Adobeはどこにも金額を公開していないからです。プランも、エディションも、「〜から」という開始価格もありません。この非対称性は、この比較の脚注ではありません。多くの購入者にとっては、これこそが比較そのものです。誰が議論の場に必要になるか、評価にどれだけ時間がかかるか、そして契約するときに実際に何にコミットするのかが変わるからです。

その根底にあるカタログの問題も、同じくらい鋭いものです。BigCommerceは1つの商品に対して600 SKUという上限を設けており、これはBigCommerce自身のAPIリファレンスに明記されたプラットフォームの厳格な制限です。Adobe Commerceは、中核プラットフォームについては同等の上限を公開しておらず、新しいSaaS型のカタログサービスでは、1商品あたり10,000バリエーションという上限が文書化されています。カタログが数百点の商品で、それぞれにいくつかのオプションがある程度なら、この差が影響することはなく、BigCommerceのほうが安価で速い答えです。構成可能な産業用部品、受注生産の商品、あるいは1つの商品が正当に数千通りの注文可能な組み合わせに膨らむ卸売カタログを扱うなら、この差こそが判断のすべてです。このガイドでは、2026年8月に各ベンダー自身のページで確認した数字を使って、両方の軸を検討します。

重要なポイント

• BigCommerceは、商品バリエーション用の自社APIリファレンスに明記されているとおり、1商品あたり600 SKU、1 SKUあたり255文字というプラットフォームの厳格な上限を設けています。（BigCommerce Developer Docs）
• AdobeはAdobe Commerceの価格を公開していません。製品ページにはプランもエディションもドル建ての金額もなく、すべての取引はAdobeの営業を通じて見積もられます。（Adobe）
• Adobe自身の法的な製品説明では、ライセンスはGross Merchandise Value（GMV）とAverage Order Value（AOV）で計測され、Pricing Levelは「the GMV and AOV tiers, Order Limit, or other pricing tier」と定義されています。（Adobeの法的な製品説明）
• Adobeが公開しているシステム要件によると、Adobe Commerce 2.4.9を動かすには、PHP 8.5、MariaDB 12.3またはMySQL 8.4、OpenSearch 3、Valkey 9、RabbitMQ 4.3、nginx 1.30、Composer 2.10が必要です。（Adobe Experience League）
• Magento Open Sourceは、OSL 3.0ライセンスの下でGitHubから入手できる、無料でセルフホスト型のダウンロードであり続けています。これはAdobe Commerceとは別の製品で、Adobe自身のリポジトリのREADMEは、フル機能のストアにはAdobe Commerceを勧めています。（GitHub）

TL;DR：BigCommerceとAdobe Commerceの概要比較

各プラットフォームが想定している利用者

どちらのプラットフォームも同じ広い領域に向けて販売しており、どちらもカタログの多いストアを問題なく動かせます。両者が分かれるのは、何を購入するのかという点です。BigCommerceは、設定して使う完成されたコマースプラットフォームを販売し、Adobe Commerceは、その上に構築するコマースフレームワークを販売します。これはどちらかの品質を評価する話ではありません。作業がどこに行き、誰がそれを担い、予算のうちどれだけがサブスクリプションでどれだけがプロジェクトなのか、という話です。

購入者のプロフィールもそこから決まります。BigCommerceの評価は、通常ECマネージャーやEC責任者を通じて進み、テーマや連携の作業のために開発者が待機していることもあります。Adobe Commerceの評価には、ほぼ必ずCTOやソリューションアーキテクト、そして導入パートナーが関わります。製品だけでなく、スタックを選ぶことになるからです。組織に後者のグループがなく、採用や外部委託の計画もないなら、それは本物のシグナルであり、たいていはAdobeではなくBigCommerceか、2026年のおすすめECプラットフォームの比較記事で取り上げているプラットフォームのいずれかに戻る結論になります。

規模も重要ですが、思われているほどではありません。オンライン売上が2,000万ドルあるビジネスでも、カタログが単純でルールもシンプルなので、BigCommerceで問題なく運営している例は数多くあります。逆に、もっと小さなビジネスが、カタログがまったく単純でないために、Adobe Commerceを本当に必要としている例も数多くあります。寸法による価格設定、アカウントごとの契約価格、数千通りの構成可能な組み合わせ、あるいは6種類の購入者タイプごとに表示を変える必要があるカタログなどです。ストアをAdobeへと押しやる変数は、売上ではなく複雑さです。

料金の非対称性をありのままに

これが正直な見方です。オンラインの比較コンテンツの多くが、ここをあいまいにしているからです。BigCommerceは完全な料金表を公開しています。Adobeは何も公開していません。開始価格も、価格帯も、プラン名もありません。Adobeから数字がほしければ、見積もりを依頼すれば、Adobeが御社のビジネスに合わせて作成します。

これは、あいまいにするためだけのあいまいさではありません。Adobeのライセンスは売上の規模で計測されるため、公開できる単一の数字がないのです。ただし、購入者にとって実務上の影響が3つあり、そのすべてに備えておく必要があります。評価に時間がかかること、価格は公開価格にはない形で交渉可能であること、そしてBigCommerceのように、公開された数字と自社の見積もりを比較することができないことです。

BigCommerceのプラン一覧（現行のプラン名、2026年6月1日から有効）

この表から予算を組む前に、2点に注意してください。オンライン売上の上限は、暦年ではなく直近12か月を基準に測定されるため、季節的な急増によって、年間の数字から見て考えるよりも早く、次の段階に押し上げられることがあります。また、Open Payment Provider手数料は、BigCommerceの承認リストにないゲートウェイで注文を処理した場合にのみ適用されます。BigCommerce承認の組み込み型プロバイダーを使えば、どのプランでもゼロになります。Standard、Plus、Proは2026年6月1日付で廃止された名称であり、サードパーティの比較コンテンツの多くが、すでに存在しないプランに対する数字を今も掲載しているのはそのためです。ShopifyとBigCommerceの比較の記事では、この手数料体系をShopifyの同等のものと比べて、さらに詳しく検討しています。

Adobe Commerceの見積もりを実際に左右する要素

Adobeは価格を公開していませんが、各デプロイ形態に付属する法的な製品説明の中で、ライセンスがどう計測されるかは公開しています。これはAdobeが提供する、公開された料金モデルに最も近いものであり、サードパーティが示すどんな価格帯よりも役に立ちます。Adobeが自社のどの数字を尋ねてくるかが分かるからです。

誰も公開していない数字、そしてAdobe Commerceが自社にとって手の届く価格かどうかを実際に決める数字は、ライセンスではありません。構築費です。サードパーティの導入パートナーは、Adobe Commerceの年間総コストを、数万ドルから数十万ドル台前半と見積もっており（導入エージェンシーのElogic Commerceなどによる報告）、ほぼすべての内訳で、ライセンスは合計の少数派です。オンラインで見つかるどんな価格帯も、これを含めて、Adobeの数字ではなく、パートナーが自社の市場について行った見積もりとして扱い、それをもとにビジネスケースを作る前に、自分で見積もりを取ってください。

Adobe CommerceはMagento Open Sourceではない

これはこのカテゴリで最も混同されやすいポイントであり、正確に説明する価値があります。2つの製品は同じ系譜を持ちながら、経済性はまったく異なるからです。

エージェンシーから「Magento」で見積もりを受けたなら、どちらなのかを尋ねてください。Magento Open Sourceでの構築にはライセンス料がまったくかからないため、同じスコープでもAdobe Commerceの見積もりよりも劇的に安く見えますが、ホスティング、セキュリティパッチの適用、アップグレードの作業は、恒久的に自社に移ります。おすすめのMagento代替製品の比較記事では、その継続的な負担が想定より重いと分かったときに、チームが最も多くたどり着くプラットフォームを取り上げています。

カタログの深さ：2つのプラットフォームが本当に分かれる点

このセクションがこの比較全体の軸になるため、最も多くの紙幅を割きます。どちらのプラットフォームも、通常のカタログは問題なく扱えます。問題は限界で何が起きるかです。1つの商品に数千の正当な組み合わせがあるとき、同じSKUに6種類の購入者向けの6通りの価格が必要なとき、あるいは同じカタログで、ナビゲーションの異なる4つのストアフロントを動かす必要があるときです。

商品モデル、バリエーション、SKU上限

600 SKUの上限には、脅しではなく率直な答えが必要です。大多数のストアにとっては無関係です。8色6サイズのシャツは48 SKUで、上限にはほど遠い数字です。600に達するのは、オプションが掛け算で増えるときで、オプションは急速に増えます。5つの値を持つ4つの属性で625通りの組み合わせになり、すでに上限を超えています。産業用や受注生産のカタログは、これを日常的に超えます。そして、まさにそのセグメントがAdobeにたどり着くのです。

BigCommerce自身の答えはモディファイアで、これは本物の答えであり、本物のコストを伴います。モディファイアを使うと、バリエーションを生成せずに、購入者が何か（刻印、カット長、保険のアドオン）を選べるため、上限を完全に回避できます。その代わりに失うのは、組み合わせごとの在庫です。モディファイアの選択に対応するSKUが存在しないため、バリエーションのようにそれに対する在庫を追跡することはできません。組み合わせが実際に在庫される品目なら、このトレードオフは問題です。注文に応じて作られる、あるいは構成されるものなら、それはどのみち正しいモデルであることが多いでしょう。

Adobe側にも、同じように正直な注意書きが必要です。「公開された上限がない」ことは「無制限」と同じではありません。Adobe Commerceのすべての構成可能なバリエーションは、データベース内の実在するシンプル商品であり、インデックス作成、キャッシュ、検索の対象になります。そのため、5,000バリエーションを持つ商品は、タダで済む話ではなく、インフラとインデックス作成の話になります。違いは、上限が議論の余地のない固定の数字ではなく、ハードウェアとチューニングで自分たちが引き上げられるものだということです。Adobeの新しいSaaS型カタログ・マーチャンダイジングサービスであるAdobe Commerce Optimizerは、具体的な境界（1商品あたり10,000バリエーション、カタログソースあたり250,000 SKU、50のカタログソース）を公開しており、従来型のプラットフォームを使っている場合でも、役に立つ基準点になります。

ストアフロントごとのカタログ、カテゴリツリー、通貨

違いをすっきり捉えるなら、こうです。BigCommerceは共有カタログを提供し、そこからストアフロントごとのビューを切り出せるようにします。Adobeは、スコープがシステム内のほぼすべての設定に適用される第一級の概念である、階層構造を提供します。Adobeのモデルはより強力ですが、学ぶことがかなり多くなります。BigCommerceのモデルは設定が速い反面、ブランドが見た目だけでなく構造的に分岐する必要がある場合には、より早く上限にぶつかります。要件が「4つのブランド、4つのナビゲーション、1つの倉庫」に近いなら、どちらも対応できます。「4つのブランドで、税ロジック、属性セット、チェックアウトルールがそれぞれ異なる」なら、それはAdobeの領域です。

B2B価格リスト、企業アカウント、見積もり

どちらのベンダーも、B2Bレイヤーの価格を公開していません。そのため、これは双方が情報を出さず、問い合わせる必要がある数少ない行です。違うのは、深さと既定の状態です。Adobe CommerceのB2Bは、標準でより充実したモデルです。親会社と子会社の構造を持つ企業階層、独自の価格を持つ企業ごとに制限されたカタログ、交渉可能な見積もり、発注書の承認フロー、購買依頼リスト、企業の与信限度額に対する掛け払いがあります。BigCommerceのB2B Editionも、大半の卸売事業については同じ領域を十分にカバーし、顧客グループごと、ストアフロントごとに割り当てられる価格リストが、一般的なケースをすっきりと処理します。

率直な振り分けのルールはこうです。B2Bが「卸売顧客に専用の価格を設定し、簡単に再注文できるようにする」ことなら、BigCommerceがはるかに少ない労力でカバーします。B2Bに、多層のアカウント階層、顧客の社内調達プロセスを反映した承認ワークフロー、すべての取引で通常の一部として行われる交渉済みの見積もりが含まれるなら、Adobeのモデルはまさにそのために設計されたもので、BigCommerceのものはそこに向けて無理に引き伸ばされています。どちらの背後にある受注と在庫は別の問題です。2026年のおすすめ注文管理ソフトウェアと2026年のおすすめ在庫管理ソフトウェアの比較記事が、その下にあるレイヤーを取り上げています。

APIのオープン性とヘッドレス

この表は、2つの思想を最もはっきり示しています。BigCommerceはAPIがオープンでコードはクローズドです。好きなフロントエンドを構築し、何とでも連携できますが、コマースエンジンそのものはBigCommerceのものであり、公開されている範囲で作業することになります。Adobe Commerceは文字どおりの意味でコードがオープンで、アプリケーションを読み、変更し、拡張できます。変更したものはすべて、アップグレードのたびに自分で保守することになります。Adobeの構築で、立ち上げ後も長く開発チームが付きっきりになる傾向があるのは、まさにそのためです。

レート制限も、逆の側から同じことを物語っています。BigCommerceはインフラを運用しているため、明確な数字を公開しており、その数字が、各プランで連携にできることを制限します。Adobeは、セルフマネージドのデプロイについて同等のものを公開していません。中央で制限するものがないからです。連携が遅いなら、それは自社側の容量とチューニングの問題です。

総所有コスト

ここでサブスクリプションの行を比べることは、ほとんど意味がありません。測っているものが違うからです。以下は、お金がどこに行くかの構造的な比較であり、料金表ではありません。Adobeの列には、Adobeが公開していない数字は意図的に入れていません。

システム要件の行は、埋め草ではありません。Adobe Commerceが自社の組織に合うかどうかを、最も手早く確認する方法です。そのリストは、実際の運用上の義務を伴う、本物のスタックであり、ストアが存続する間、誰かがそれぞれの要素を担わなければなりません。それを読んで「そのために採用が必要になる」と思ったとしても、答えはAdobe Commerceが悪いということではありません。そのコストモデルが、新たに追加することになるエンジニアリングの体制を前提にしており、その追加分をライセンスの隣に並べて比較に含めるべきだ、ということです。ライセンスだけを見積もって、チームのことを忘れたチームが、18か月後に不満を抱えることになります。

BigCommerceにおける予算の想定外は、もっと小さく予測しやすいものです。直近12か月の売上上限を超えて成長すると、それに付随する機能が必要だったかどうかにかかわらず、上位のプランに移されます。それは煩わしいものですが、今日の自社の売上データから予測できる算術です。Adobeにおける想定外はスコープであり、予測がはるかに難しく、過小評価されやすいものです。

移行とロックイン

Adobe Commerceは、コードを自分で持つため、紙の上ではロックインが弱く見えますが、ある特定の点では実際にそのとおりです。オンプレミスのAdobe Commerceのストアには、Magento Open Sourceへの現実的な道筋があり、BigCommerceにはそれに相当するものがありません。しかし、コードの所有には両面があります。パートナーが書いたすべてのカスタムモジュールは、ここでしか動かない資産であり、それが増えるほど、離脱は高くつきます。BigCommerceのロックインは、より浅く、より味気ないものです。作り直すものは少ない一方で、持ち出せるものもありません。BigCommerceからの乗り換えを具体的に検討しているなら、おすすめのBigCommerce代替製品の比較記事が、Adobeだけよりも幅広い選択肢を取り上げています。

サポートと導入パートナー

比較表にはめったに載らない、実務上の注意点があります。Adobe Commerceでは、プラットフォームの選択よりも、導入パートナーのほうが重要です。同じライセンスでも、あるパートナーなら高速で保守しやすいストアになり、別のパートナーなら保守できないストアになります。手に入るものの大半が、彼らの書いたコードだからです。プラットフォームの候補リストだけでなく、パートナーの候補リストにも評価の時間を使い、3年前に構築して今も保守しているストアを見せてもらってください。

BigCommerceが適している場合

• 今日、予算を組める公開価格がほしい。 すべてのプラン、上限、手数料が1つのページにあり、営業と話さずに自社のコストをモデル化できます。
• カタログは複雑だが、極端ではない。 ネイティブの価格リスト、顧客グループ、チャネルごとのカテゴリツリーで、1商品あたり600 SKUの上限が問題になるまでの、かなり広い範囲をカバーできます。
• 常設の開発チームを持っておらず、持ちたくもない。 BigCommerceはSaaSです。追跡すべきPHPのバージョンも、運用すべき検索クラスターも、アップグレードのプロジェクトもありません。
• 構造的に異なる4つの事業ではなく、1つのカタログから複数のストアフロントが必要。 Multi-Storefrontの、チャネルごとの上書きを持つ共有カタログは、1つのオペレーションを共有するマルチブランドのポートフォリオにきれいに合います。
• 無限の柔軟性よりも、立ち上げの速さが重要である。 標準的なストアは、四半期単位ではなく、数日で稼働します。

Adobe Commerceが適している場合

• 1つの商品に、正当に数千通りの注文可能な組み合わせが必要。 BigCommerceの600 SKUの上限は厳格で、モディファイアでは組み合わせごとの在庫追跡を失います。Adobeには、公開された同等の上限がありません。
• B2Bが本当に複雑である。 企業階層、企業ごとに制限されたカタログ、交渉可能な見積もり、発注書の承認フロー、掛け払いは、回避策ではなく、Adobe Commerce B2Bの中核機能です。
• コマースの挙動そのものを変える必要がある。 ソースコードにアクセスできるため、価格ロジック、チェックアウトのルール、税の処理を、APIを介して回避するのではなく、書き換えられます。
• 構造的にルールが異なる多数のブランドや地域を運営している。 ウェブサイト、ストア、ストアビューの階層は、ほぼすべての設定にスコープを適用し、チャネルごとの上書きで表現できる範囲を超えます。
• すでにエンジニアリングの体制や、信頼できるパートナーがいる。 これはボーナスではなく前提条件です。それがなければ、このプラットフォームの強みは発揮されません。

どちらも合わない場合

ライセンスなしでコードがほしいなら、Magento Open Sourceが正直な中間の道です。OSL 3.0の下でGitHubから入手できる、無料でセルフホスト型のダウンロードで、系譜は同じですが、Adobeのサポート、ホスティング、商用の拡張機能はありません。Adobe自身のリポジトリのREADMEが、フル機能を求める購入者をAdobe Commerceに誘導しているのもまさにそのためなので、ホスティング、パッチ適用、アップグレードを恒久的に引き受けることを理解したうえで臨んでください。魅力が主に「安くて柔軟」であるなら、WooCommerceのほうが、通常はより軽い答えです。無料のコアプラグインがあり、本当のコストはホスティング、拡張機能、決済処理に移ります。

そして、本当のギャップがストアフロントにまったくないなら、候補リストは完全に変わります。この2つのプラットフォームを評価しているチームの多くが、ストアフロントには問題がなく、痛みはその裏側にあると気づきます。注文は1つのシステム、顧客レコードはCRM、在庫は3つ目のツールにあり、それらが、静かにずれていく同期でつなぎ止められているのです。ReworkのCommerceモジュールは、Sales CRM、Lead、Inventory、Invoice、Product、Work Opsも備えた、より広いプラットフォームの中で、注文とコマースのオペレーションを動かすため、注文、顧客レコード、在庫数が、3つの同期ツールではなく、1つのプラットフォーム上に置かれます。それが何ではないのかも、はっきりさせておきます。Reworkはストアフロントのビルダーでも、エンタープライズ向けのコマースプラットフォームでもありません。テーマ付きのストアフロントも、テンプレートギャラリーも、D2Cのチェックアウトもなく、Adobeのカタログの深さに迫るものも何もないため、選んだプラットフォームを置き換えるのではなく、その裏側か隣に置くものです。価格はrework.com/pricingで、組織ごとの見積もりとして案内されており、およそ10人から200人規模の中堅事業者向けに作られています。これは、Adobe Commerceを評価している多くの人にとって、同等の置き換えではなく、規模を一段下げる選択肢です。組織がそれより大きい場合は、オペレーションに関する指摘だけを受け取り、解決は別の場所で行ってください。

意思決定フレームワーク

次のステップ

この比較は、私たちの例を自社の数字に置き換えて初めて結論が出ます。次の順序で進めてください。

1. 平均的な商品ではなく、最も大変な商品を数えてください。 カタログの中で、注文可能な組み合わせが最も多い商品を1つ見つけ、そのオプションを掛け算してください。その数が600を余裕で下回るなら、BigCommerceの厳格な上限は問題にならず、心配する必要はありません。
2. その組み合わせに在庫追跡が必要かどうかを判断してください。 必要なら、モディファイアは現実的な回避策にならず、600の上限は自社にとって現実のものです。注文に応じて作られる、あるいは構成されるものなら、プラットフォームにかかわらず、モディファイアが正しいモデルかもしれません。
3. Adobeを軸にしたビジネスケースを作る前に、Adobeの見積もりを取ってください。 公開された数字は存在せず、オンラインで出回っている価格帯はパートナーの見積もりです。見積もりを依頼し、それとは別に、2社の導入パートナーに構築費を尋ねてください。
4. ライセンスだけでなく、チームも見積もってください。 2.4.9に対するAdobeのシステム要件を見て、今後3年間、組織の誰がそれぞれの構成要素を担うのかを正直に判断してください。答えが「採用することになる」なら、それを比較に含めてください。
5. どのMagentoの見積もりを受けているのか確認してください。 エージェンシーの提案書に「Magento」とあれば、Magento Open SourceなのかAdobe Commerceなのかを尋ねてください。スコープは同じに見えても、ライセンスの行はまったく異なることがあります。
6. ストアフロントがボトルネックでないなら、その裏側のレイヤーを確認してください。 うまく動いているものをプラットフォームごと入れ替える前に、2026年のおすすめ注文管理ソフトウェアの比較記事を参照してください。