Drupal Commerce が Shopify に勝つとき

Drupal Commerce は、ほとんどのオンラインショップにとって間違った答えです。これは 15 年にわたり丁寧に設計されてきたプロジェクトへの批判ではありません。大半のショップがどういうものかを述べているだけです。数百点の SKU、単一の通貨、消費者である顧客、そして最後にカード決済。この形の事業であれば、重要な軸のすべてでホスティング型プラットフォームが勝ち、議論は始まる前に終わります。

しかし、計算が完全に逆転する少数派が存在し、それは収益性の高い少数派です。バリエーションの表では表現できない構成型の製品。交渉済みの価格表を持つ取引先アカウント。カタログそのものが編集コンテンツであるサイト。在庫と価格を所有し、ウェブサイトを表示面としか見なさない ERP。こうした事業では、ホスティング型プラットフォームは安上がりではなく、アプリと回避策と「変更が許されないもの」という形で払い続ける恒久的な税金になります。

この記事は、その境界線が実際にどこにあるのかを、両側の数字とともに示します。Shopify の節を読んで自社の姿だと気づいたなら、そこで読むのをやめてください。多額の費用を節約できますし、この記事は役目を果たしたことになります。

Drupal Commerce が Shopify に勝つのはどんなときか。 製品を単純なバリエーションの表として表現できないとき、同じ SKU に対して顧客ごとに異なる価格が表示されるとき、カタログと編集コンテンツが同じものであるとき、あるいは ERP が正しさの源泉で、ショップがそこへの一つの窓であるときです。1 つか 2 つの通貨で完結する素直な消費者向けカタログであれば、3 年間の総額で Shopify のほうが安く、コンバージョンも優れています。分かれ目は製品と価格設定の複雑さであり、トラフィックや売上高ではありません。

Drupal Commerce の正体

Drupal Commerce はショップ製品ではありません。Drupal のエンティティとフィールドのシステムの上に重ねられた一連のエンティティタイプであり、この記事に続くすべてはその一文から導かれます。

Drupal Commerce における製品は、ノードとまったく同じくバンドルを持つエンティティです。製品バリエーション、注文、注文明細、支払い、プロモーション、ストアも同様です。そのいずれもが任意のフィールドを受け付けるため、バリエーションはロット番号、証明書の参照、営業日単位のリードタイム、価格計算に使う寸法を持てます。これらは固定のスキーマに横から取り付けたカスタムフィールドではありません。それがスキーマそのものです。

購入対象は製品ではなくバリエーションです。製品は見せ方の器であり、バリエーションが SKU と価格を持つ品目で、属性が選択可能な組み合わせを生成します。製品タイプは製品が持つフィールドを決め、バリエーションタイプはそのバリエーションが持つ属性を決めます。この仕組みのどこにも、衣料品や物理的な商品、あるいは選択肢の数が固定であることを前提にした部分はありません。

その結果、Drupal Commerce はあなたが何を売るかについてほとんど意見を持ちません。この自由の代償は、決定もほとんど提供されないことであり、そのすべてを誰かが下さなければならないという点です。

Drupal Commerce の現在地

現在の推奨リリースは 2026 年 7 月 17 日に公開された Drupal Commerce 3.3.8 で、Drupal 10.3 以降および Drupal 11 で動作します。安定版リリースは Drupal のセキュリティアドバイザリポリシーの対象で、これは聞こえる以上に重要です。公表された脆弱性が GitHub の issue ではなく、調整されたリリースとして扱われるということだからです。

Drupal Commerce のプロジェクトページは、このモジュールを利用しているサイトを 35,870 件と報告しています。Commerce 3.0.0 は 3.x 系で最初の安定版リリースで、2025 年 1 月に公開され、Drupal 9 のサポートを打ち切りました。その周囲には小さなコントリビュートのエコシステムがあります。Commerce Shipping は 3.0.3 でおよそ 15,200 件の導入があり、後で触れる専門的なモジュール群は数千件台にとどまります。

これを WooCommerce と比べてください。有効インストール数は 700 万件を超えると報告されており、WordPress 6.9 と PHP 7.4 以上を必要とします。Drupal Commerce は導入規模でおよそ 200 分の 1 です。

その比率こそがこの記事で最も重要な数字であり、自慢ではなく警告です。「それ用のモジュールはもうあるか」という問いへの答えが、しばしば「ない」になるということだからです。

Shopify を正直に評価する

Shopify は、自前でホスティングするショップの大半を沈める 4 つの問題を、コードを 1 行も書く前に解決します。

ホスティング型なので、稼働率、スケーリング、パッチ適用が自社の予算項目ではなくなります。カードデータを扱うため、引き受けるコンプライアンスの範囲は本来の何分の一かで済みます。そのチェックアウトは、どのエージェンシーにも再現できない量の実取引で検証されており、その規模での小さなコンバージョン差は、いかなるアーキテクチャの好みよりも価値があります。そしてアプリのエコシステムのおかげで、たいていの要件はプロジェクトではなくサブスクリプションとして届きます。

数千点の SKU、1 つか 2 つの通貨、交渉価格なしという消費者向けカタログであれば、この記事の後半で説明する利点はどれも当てはまりません。月額 65 ポンドで現在得ているものを、エージェンシーに費用を払って、より劣った形で作り直すことになります。

残りの部分は逆の主張をするので、はっきり言っておきます。大半のショップは Shopify で止まるべきです。あなたのショップがその一つなら、Shopify とカスタム構築を比較した記事のほうが、このページよりも詳しくその判断を扱っています。

英国での Shopify の費用

Shopify は英国価格をポンドで公表しているため、換算は不要です。2026 年 9 月時点の Shopify の料金ページによれば、Basic は月払いで月額 25 ポンド、年払いなら 19 ポンド、Grow は 65 ポンドまたは 49 ポンド、Advanced は 344 ポンドまたは 259 ポンド、Plus は月額 1,800 ポンドからです。POS Pro は 1 拠点あたり月額 69 ポンドが加算されます。

サブスクリプションよりもカード手数料のほうが重要です。Shopify Payments 経由のオンラインカード手数料は、Basic で 2% と 25 ペンス、Grow で 1.7% と 25 ペンス、Advanced で 1.5% と 25 ペンスです。多くの人が見落とすのは、Shopify Payments 以外のゲートウェイを使うときに課される第三者決済プロバイダ手数料で、Basic で 2%、Grow で 1%、Advanced で 0.6%、Plus で 0.2% です。

この手数料はゲートウェイ自体の手数料に上乗せされます。年商 100 万ポンドで Advanced を使い、外部のアクワイアラを利用しているショップなら、第三者手数料だけで年間 6,000 ポンド、3 年間で 18,000 ポンドになります。Shopify Payments を使わないという選択の代価です。

Shopify の限界

限界は公表されており、しかも具体的です。バリエーションの追加に関する Shopify のドキュメントは、1 つの製品につきオプションは最大 3 つ、バリエーションは最大 2,048 個までであり、いずれかを超える場合はサードパーティのアプリか、明細プロパティを取得するテーマコードが必要になると述べています。

最初に効いてくる上限はオプション 3 つです。窓、印刷パネル、オーダーメイドのブラインド、構成済みの機械は、独立した選択肢を 6 つも 8 つも持つのが普通で、3 つを超えた瞬間にプラットフォームはあなたの製品をモデル化するのをやめ、近似し始めます。

2 つ目の壁はチェックアウトです。情報、配送、支払いの各ステップに対する Shopify のチェックアウト UI 拡張は Plus プランでのみ利用できます。Plus 未満ではチェックアウトにブランドを反映できても、ロジックを差し込むことはできません。配送枠の選択、取引与信の確認、必要な時点でのコンプライアンス確認が排除されます。

3 つ目は積み重なりです。すべての隙間はアプリで埋められ、アプリはどれも月額費用とアップグレードの依存関係を伴います。アプリを 20 個抱えたショップは、かつて逃げ出したはずの保守問題とよく似たものを抱えることになります。

WooCommerce の利点と、苦しくなる場所

WooCommerce は、普段受けている評価よりも公平に扱われるべきです。無料で、月額数十ポンドのホスティングで動き、データは自社のもので、拡張機能のカタログは EC の中で圧倒的に最大です。チームがすでに WordPress を知っている中小規模の消費者向けショップであれば、これが正解であり最も安価であることが少なくありません。

苦しくなる場所は 3 つあり、いずれも予想できます。1 つ目はデータモデルです。製品は WordPress の投稿タイプで、属性はシリアライズされたメタとして保存されるため、属性の多い大規模カタログを絞り込むには、実際の列ではなくキーと値のテーブルを問い合わせることになります。1,000 点の製品なら耐えられますが、5 万点では苦痛です。

2 つ目はバリエーション数に対する性能で、WooCommerce ストアが遅く感じられる最も一般的な理由です。その仕組みはWooCommerce ストアが遅い理由の記事で詳しく扱いましたが、要点は、可変商品は行ではなくクエリを増やすということです。

3 つ目はプラグインの氾濫です。WooCommerce は何かをインストールすることで問題を解決するため、4 年も経つとストアは自社ではなく 30 社のリリーススケジュールによって定義されるようになります。

複雑な製品モデリング、最初の本当の分かれ目

Drupal Commerce にとって最も明快な適合案件は、選ぶのではなく構成する製品です。裁断料込みでメートル単位で売る生地。幅と高さの積で価格が決まり最低料金のあるガラス。8 つのオプショングループを持ち、一部が他を無効にする機械。数量による単価逓減とジョブごとの段取り費用がある印刷。

これらはどれもバリエーションの表ではありません。ホスティング型プラットフォームでは、アプリと明細プロパティの組み合わせで近似することになり、顧客に表示される価格はプラットフォーム自身の価格ロジックの外側で計算され、どこかの時点で突き合わせが必要になります。

Drupal Commerce では価格は自分が書いたコードで解決されます。プライスリゾルバがバリエーション、数量、現在のコンテキストを受け取り、価格を返します。特別なことは何もありませんが、これにより構成された価格がどこでも本当の価格になります。カートでも、注文でも、税の計算でも、ERP への書き出しでもです。

当てはめるべきテストは単純です。カタログを、購入できる単位ごとに 1 行のスプレッドシートとして書けるなら、これは必要ありません。書けないのであれば、この記事の残りすべてが関係してきます。

B2B の価格、価格表、交渉した条件

2 つ目の分かれ目は、同じ SKU に対して 2 人の顧客が異なる価格を見ることがあるかどうかです。消費者向けショップの答えは「ない」です。取引先向けの事業の答えは「ある」で、その答えがたいてい事業そのものです。

Shopify にも B2B はあり、B2B のプラン別機能に関するドキュメントは Basic、Grow、Advanced、Plus で利用できることを示しています。細部は制限にあります。Plus 未満ではすべての B2B マーケット合計で有効なカタログは最大 3 つ、企業に直接ひも付くカタログは Plus のみ、手付金、分割払い、出荷単位の支払い要求も Plus のみです。カタログ 3 つは価格帯 3 段階には十分ですが、交渉済みの 40 口座には役に立ちません。

Drupal 側で対応するのは Commerce Price List モジュールで、現在 8.x-2.16、報告されている導入数はおよそ 1,662 件、セキュリティチームの対象です。ユーザー単位またはロール単位で価格を設定し、数量帯と期間に対応し、CSV から取り込めます。

最後の点が実務では効きます。それぞれ独自の合意価格表を持つ 40 口座を抱え、四半期ごとに ERP から更新する卸売業者にとって、それはプラットフォームの移行ではなく CSV の取り込み作業です。

1 つのコードベースで実現するマルチストア、多通貨、多言語

Drupal Commerce ではストアが第一級のエンティティであり、製品はそれを販売してよいストアに割り当てられます。これは小さな設計上の判断ですが、結果は大きくなります。複数のストアフロントが 1 つのカタログ、1 つの注文パイプライン、1 つの管理画面を共有しながら、それぞれ異なる通貨、税の設定、決済ゲートウェイ、配送ルールを持てるのです。

よくある構成は、英国サイト、EU サイト、取引先ポータルを 1 つのデプロイから動かす形です。製品データの入力は一度きりです。価格表は取引先ストアにだけ適用されます。ストアが自身の請求国と登録情報を持つため、税はストアごとに解決されます。

Drupal コアは、言語ごとの URL エイリアス、翻訳されたエンティティ、代替言語リンクを備えた本当に強力な多言語レイヤーも提供します。Drupal が高等教育と公共部門で大きな存在感を持つのはそのためです。

Shopify Markets は今ではこの多くをカバーしていますが、Markets を通じた文脈依存のチェックアウトとストアフロントのカスタマイズは Advanced と Plus のプランに限られます。つまり比較対象は月額 25 ポンドではなく、最低でも月額 259 ポンドになります。

カタログが編集コンテンツであるとき

一部のカタログはコンテンツそのものです。製品ページに購入ガイド、比較表、技術解説、レビュアーの所見を載せている専門小売業者は、決済も受け付ける出版物を運営しているのです。

ホスティング型プラットフォームでは、それは 2 つのシステムになります。CMS が記事を持ち、ショップが SKU を持ち、両者はリンクと夜間のエクスポートで結ばれます。編集者は 2 か所で作業し、検索インデックスは二重になり、URL 構造には真ん中に継ぎ目ができます。

Drupal Commerce では製品はすべての記事と同じシステム内のエンティティなので、編集ワークフロー、リビジョン履歴、タクソノミーのボキャブラリ、メディアライブラリ、検索インデックス、アクセス制御を共有します。製品ページは 3 本の記事を参照でき、記事は 9 点の製品を参照できます。しかもどちらも貼り付けたリンクではなく、本物のエンティティ参照としてです。

これは、そうでなければ Shopify で十分に足りる事業に対して Drupal を正当化する最も多い論拠であり、同時に、編集チームが 2 つの管理画面で 1 年間作業するまでは「あれば嬉しい程度」と片付けられることが最も多い論拠でもあります。

規制対象の製品と、属性の多い製品

コンプライアンスデータを持つ製品が 4 つ目のケースです。安全データシートを伴う化学品。証明書番号と有効期限を持つ医療機器。アレルゲン表を持つ食品。適合宣言書を持つ電気製品。ロット追跡や販売制限のフラグを必要とするものすべてです。

求められるのは、それらの値を保存することだけではありません。検証し、版を管理し、顧客が実際に受け取ったロットに対応する正しいものを表示し、ある日付に何が公開されていたかを後から証明することです。Drupal のフィールド API とリビジョンのしくみは、販売促進ではなくコンテンツガバナンスのために作られているので、これができます。

強制する側も同じくらい重要です。注文プロセッサは、年齢制限のある商品を禁止国へ送ってしまう注文や、同梱してはならない 2 つの品目を組み合わせた注文を拒否できます。しかもテーマのテンプレートではなく、注文パイプラインの中でそれができます。

ホスティング型プラットフォームでは、こうしたチェックはそれぞれアプリになりますが、アプリは組み合わさりません。カートを変更するアプリが 2 つあれば、その 2 つはいずれ食い違います。

ERP が正しさの源泉であるとき

5 つ目のケースは構造的なものです。流通業や製造業では ERP が在庫、価格、与信、注文状況を所有し、ウェブサイトはショッピングカートの付いた表示面です。問われるのはショップに何ができるかではなく、実際に主導権を握っているシステムとの整合をどれだけ安く保てるかです。

Drupal Commerce がここで快適なのは、統合が自社のプロセス内で動くからです。キュー API が非同期処理を扱い、マイグレート API が繰り返し可能でべき等な取り込みを扱い、レコード単位で課金したり同期の時間枠を絞ったりする仲介者もいません。20 万行の価格と在庫を毎晩取り込む処理は、cron ジョブで済みます。

ホスティング型プラットフォームでは、同じ統合がアプリのサブスクリプションかミドルウェアのサブスクリプションになり、プラットフォームの API レート制限は細部ではなく、設計で回避すべきアーキテクチャ上の制約になります。それでも成り立ちますし、多くの事業にとっては正しい取引です。正しくなくなるのは、同期が大量で、頻繁で、しかも事業に不可欠であるときです。

統合の作業がショップ本体よりもプロジェクトの大半を占めるなら、それはストアフロントの付いたソフトウェア開発案件であり、最初からそのように見積もるべきです。

税務はホスティング型が安くなくなる場所

税務は越境 EC の静かなコストセンターであり、月額サブスクリプションの比較が誤解を招き始める場所です。ほとんどを決めるのは 2 つのしきい値です。

英国の VAT 登録ライン

GOV.UK の VAT 登録の時期に関する案内は、課税対象売上高の合計 90,000 ポンドをしきい値としています。登録の引き金になる判定は 2 つあります。1 つは直近 12 か月のローリング判定で、売上高が 90,000 ポンドを超えた月の末日から 30 日以内に登録しなければなりません。もう 1 つは将来予測の判定で、今後 30 日以内に売上高が 90,000 ポンドを超えると気づいた時点で直ちに登録しなければなりません。

成長中のショップを捕まえるのは将来予測の判定のほうです。登録日は入金があった日ではなく、気づいた日だからです。

EU の VAT とワンストップショップ

欧州委員会の課税地に関する案内は、EU 域内の物品の通信販売と、電気通信、放送、電子的サービスを合わせた年間合計のしきい値を 10,000 ユーロと定めています。これを下回る場合、課税地は発送または輸送が始まる場所です。上回ると課税は輸送が終わる場所、つまり顧客の国の税率へ移ります。

ワンストップショップを使えば、それらすべてを 1 つの加盟国での 1 通の申告にまとめられ、提出は四半期ごとで、期限は 4 月、7 月、10 月、1 月の各末日です。輸入ワンストップショップは、EU 域外から輸入される 150 ユーロ以下の貨物を対象とします。

Drupal Commerce が標準で行うこと

Commerce は欧州連合 VAT の税プラグインをアドオンではなくコアに同梱しています。27 の加盟国とモナコの税率を保持し、標準税率、軽減税率、中間税率、超軽減税率、ゼロ税率を区別し、一律の税率表がつまずく特別地域も扱います。コルシカ、アゾレス諸島、マデイラ、ギリシャの島々、オーストリアの飛び地ユングホルツなどです。

税率だけでなく規則も適用します。デジタル商品への仕向地課税、そして有効な税番号が提示された場合の EU 域内の事業者間取引のゼロ税率です。ホスティング型プラットフォームでは、その挙動はたいてい取引ごとに費用がかかるアプリになります。

決済、PCI DSS、そしてカードの受け取り方

カード番号をどう集めるかがコンプライアンスの負担を決めますが、その規則は最近、広く誤解される形で変わりました。

PCI セキュリティ標準協議会による SAQ A の適格条件の説明は、2025 年 4 月 1 日に発効した条件を解説しています。加盟店は自社サイトが「加盟店の EC システムに影響を与えうるスクリプトからの攻撃を受けやすくないこと」を確認しなければならず、これは PCI DSS 要件 6.4.3 と 11.6.1 の手法を実装するか、決済プロバイダから、その埋め込み型ソリューションにこれらの保護が含まれているという確認を得ることで満たされます。

多くの人が取り違えるのは、その適用範囲です。この条件は、自社のページに決済プロバイダの入力フォームを、通常は iframe で埋め込んでいる加盟店にのみ適用されます。協議会は、HTTP リダイレクト、meta refresh、JavaScript のいずれであれ顧客をプロバイダ側へ転送する加盟店には適用されないと明言しており、決済機能を完全に外部委託している加盟店にも適用されません。

つまりホスト型のリダイレクトなら攻撃面は小さいままです。コンバージョンが良く、ほぼ誰もが実際に望むのは埋め込み型の入力欄ですが、これはチェックアウトページで動くすべてのスクリプトの完全性を、あなたのコンプライアンスの議論の中に持ち込みます。

Shopify の本当の強みはここにあります。チェックアウトは Shopify のもので、その上のスクリプトも Shopify のものだからです。Drupal Commerce ではチェックアウトは自社のものなので、答えは設計するしかありません。厳格なコンテンツセキュリティポリシー、サブリソース完全性、決済ページで動くすべてのスクリプトの棚卸し、そしてそのいずれかが変わったときの検知です。この作業は難しくもなければ任意でもなく、監査の最中に発覚するのではなく予算に入っている必要があります。

アクセシビリティは法務上かつ商業上のリスク

EC のアクセシビリティ上の不備はチェックアウトに集中しますが、そこはあらゆる不備が直接お金を失う場所でもあります。

参照すべきは WCAG 2.2 で、2024 年 12 月 12 日に公開された W3C 勧告です。ショップで効いてくる達成基準は具体的です。レベル AA の 1.3.5「入力目的の特定」は住所欄とカード欄の自動入力に関わります。レベル A の 3.3.7「冗長な入力」は、支払いの段階で配送先住所を再入力させるチェックアウトが必ず違反する基準です。レベル AA の 3.3.8「アクセシブルな認証」はアカウント作成とサインインを扱います。レベル AA の 2.5.8「ターゲットのサイズ」は数量の増減ボタンやカートからの削除操作を捉え、レベル AA の 1.4.3「コントラスト」は、実際には有効なのに灰色に見える無効そうなボタンを捉えます。

注文そのものの周りにはさらに 2 つあります。レベル A の 3.3.1「エラーの特定」と、レベル AA の 3.3.4「法的、金銭的、データの取引に対するエラー回避」で、後者はまさに注文を確定する行為に関わるものです。

英国の法的な立ち位置はしばしば誇張されます。民間の小売業者が、WCAG の適合レベルを名指しする法律に縛られているわけではありません。適用されるのは、2010 年平等法第 20 条が定める、障害のある人が著しく不利にならないよう、補助的な手段の提供を含む合理的な措置を講じる義務です。適合レベルを名指しする規則である 2018 年公共部門機関（ウェブサイトおよびモバイルアプリケーション）アクセシビリティ規則（第 2 号）は、ショップではなく公共部門の機関に適用されます。

商業上の論点は法的な論点より鋭いものです。ホスティング型のテーマでは、アプリがチェックアウトに差し込んだものを常に直せるとは限りません。自分で制御できるプラットフォームなら直せます。

3 年間で実際にかかる費用

多くの人が行う比較は月額サブスクリプション対月額ホスティングですが、それは表の中で最も影響の小さい行です。支配的なのは構築費と保守費であり、取扱高が増えれば決済手数料の割合が支配的になります。

以下の帯域は、英国のミッドマーケット向けショップに対する Mecanik の社内目安です。ただし Shopify のサブスクリプションと手数料の数字だけは、Shopify が公表しているとおりのポンド表記です。それ以外は当社が提示するであろう金額であり、各行の幅は、低い側でのプラットフォーム間の差よりも広くなっています。

表の各行が実際に買っているもの

散文で言い直します。Shopify Advanced は年払いにするかどうかで 3 年間のサブスクリプションが 9,324 から 12,384 ポンドになり、ホスティングを含みますが、同じ期間に現実的には 5,400 から 14,400 ポンドのアプリ利用料が乗ります。WooCommerce はプラットフォームには何も払わず、ホスティングに 3,600 から 14,400 ポンド、拡張機能に 3 年で 3,000 から 9,000 ポンドを払います。Drupal Commerce はライセンス費用がゼロで、3 つの中で最も重いアプリケーションなのでホスティングには最も多く 5,400 から 21,600 ポンドを費やし、アドオンには最も少なく、ゼロから 3,000 ポンド程度です。同等の機能が商用ではなくコントリビュートモジュールだからです。

構築費こそがプラットフォームを分ける場所です。Shopify の 8,000 から 25,000 ポンドの構築は、標準的な統合を備えたテーマ適用済みストアを買うもので、WooCommerce では 10,000 から 35,000 ポンドです。同じ要件を Drupal Commerce で作ると 35,000 から 120,000 ポンドになります。チェックアウト、価格のロジック、統合のすべてを設定ではなく実装しているからです。保守も同じ形で、年あたり Shopify が 3,000 から 9,000 ポンド、WooCommerce が 4,000 から 12,000 ポンド、Drupal Commerce が 12,000 から 30,000 ポンドとなり、これはDrupal 開発者の単価のガイドで扱った、およそ 600 から 900 ポンドという英国エージェンシーの日額を反映しています。

3 年間の合計はどこに着地するか

3 年間の合計は、Shopify でおよそ 32,000 から 79,000 ポンド、WooCommerce で 29,000 から 94,000 ポンド、Drupal Commerce で 76,000 から 235,000 ポンドに着地します。カードとゲートウェイの手数料はこの 3 つすべての上に乗り、取扱高に比例します。だからこそ Advanced での 0.6% という Shopify の第三者ゲートウェイ手数料は、年商 100 万ポンドのショップで 3 年間に 18,000 ポンドの重みを持つのです。

表を正直に読めば、Drupal Commerce は 2 倍から 3 倍の費用です。それが正当化されるのは、代わりの選択肢が実際には使えない場合だけであり、それこそが前の 5 つの節すべての要点です。

ヘッドレスと分離型の Drupal Commerce

Drupal Commerce の分離は、限られたケースでは本物の要件ですが、それ以外の大半では流行です。正直な判定基準は、ウェブサイト以外の何かが同じカタログを必要としているかどうかです。

本物の要件になるのは、ネイティブのモバイルアプリとウェブサイトが 1 つの製品モデルと価格モデルを共有しなければならないとき、別のチームが作った既存のフロントエンドを置き換えない前提のとき、POS 端末やキオスクが同じカートを利用するとき、あるいはデザインシステムがプロジェクトの外で管理されていて Twig では表現できないときです。そうしたケースでは API が製品であり、CMS は意図的に見えなくなります。

流行なのは、理由として性能が挙げられるときです。よくキャッシュされた従来型の Drupal フロントエンドは匿名の製品ページをエッジから配信しますし、ショップを遅くしている原因が描画方式であることはめったにありません。

費用は 1 か所に集中します。Drupal コアは設定なしで JSON:API 経由でコンテンツを公開し、Commerce Cart API モジュールがカートを REST インターフェースの背後に置くので、カタログの読み出しとカートの構築はほぼ無償です。チェックアウトはそうではありません。住所の扱い、税の表示、配送方法の選択、プロモーション、決済要素の統合、注文確認のすべてをフロントエンド側で作り直す必要があり、それはたいてい構築全体の 40% 以上を占めます。

5 分でできる判断ルール

自社のカタログについて 6 つの質問に答えてください。「はい」ごとに 1 点です。

オプションが 3 つを超える製品、または購入できる組み合わせが 2,048 を超える製品はありますか。同じ SKU に対して 2 人の顧客が異なる価格を払うことはありますか。VAT の扱いが異なる複数の国へ販売していますか、あるいは OSS 申告を行う見込みがありますか。カタログは、同じチームが書いて保守する編集コンテンツでもありますか。価格と在庫の権威は ERP か PIM で、ショップはその下流にありますか。チェックアウトにブランドを反映するだけでなく、自前のロジックを差し込む必要がありますか。

0 点か 1 点なら Shopify を選んでください。この記事で説明した利点はあなたには当てはまらず、いま借りているものを作り直すために費用を払うことになります。

2 点なら判断は本当に開かれており、チームがすでに WordPress を運用しているなら特に、WooCommerce が中間の良策になることが多いでしょう。

3 点以上なら Drupal Commerce をきちんと見積もる価値があります。他の選択肢で必要になる回避策のほうが、3 年間ではプラットフォームより高くつくからです。5 点か 6 点なら、ホスティング型プラットフォームは安い選択肢ではなく、その仕事をこなせない別の製品です。

Drupal Commerce の案件が失敗しがちな理由

最も多い失敗は、間違った理由で選ぶことです。「すでに Drupal を使っているから」はコマースの要件ではありません。コンテンツサイトと取引サイトでは、求められる稼働率も、テストも、デプロイが失敗したときの結果も異なります。ショップを既存サイトのもう一つのセクションとして扱うことが、小さな EC 案件が計画外のプラットフォームチームを抱え込む経緯です。

2 つ目は保守の過小評価です。導入 35,870 件のエコシステムは、保守担当者が数人しかいないモジュールを使うことになる程度には小さく、セキュリティアドバイザリを監視して更新を計画する人が自社側に必要です。それを担当する人がいない Drupal Commerce サイトは、時限式のセキュリティ事故です。この点はDrupal が実際に必要とするホスティング要件と合わせてより詳しく扱っています。

3 つ目はモジュールがあると決めてかかることです。見積もりの前に確認してください。なければ、その作業は個別のウェブサイト開発であり、項目一行ではなく本物の見積もりが必要です。

4 つ目はメジャーバージョンの規律です。Commerce 3 は Drupal 10.3 以降を必要とし、コアから遅れたサイトはやがて、コマースのモジュールのほうが先に進んでしまったことに気づきます。2026 年の Drupal 開発のガイドと移行の費用と期限の記事は、どちらもそのサイクルを掘り下げています。

判断を正しく行うために

選択を決めるのは製品と価格設定の複雑さであり、トラフィックや売上高や好みではありません。まずカタログを紙の上でモデル化してください。すべてのオプション、すべての交渉価格、そして他のシステムとの整合を保たなければならないすべての統合を含めてです。そのモデルがバリエーションの表に収まるなら、ホスティング型プラットフォームを買い、浮いた予算をマーチャンダイジングに使ってください。

Mecanik は両方の種類のストアを構築して保守しており、見積もりを出す前に、あなたがどちら側にいるかをお伝えします。答えが Drupal Commerce なら、その仕事は相当な統合要素を伴うウェブサイト開発案件です。ERP 側の作業がストアフロントを上回るなら、ソフトウェア開発に属します。答えが Shopify なら、そう申し上げます。作り直しが 18 か月進んだ後よりも、今そう申し上げるほうがよいと考えています。

よくある質問

Drupal Commerce は Shopify より優れていますか。 大半のショップにとってはそうではありません。Shopify は 3 年間で見れば安く、PCI 準拠とホスティングを引き受け、どのエージェンシーにも並べない規模で検証されたチェックアウトを備えています。Drupal Commerce が勝つのは限られたケースです。オプションが 3 つまたはバリエーションが 2,048 を超える製品、顧客ごとの交渉価格、編集コンテンツでもあるカタログ、そして ERP が価格と在庫を所有するショップです。

英国での Drupal Commerce の構築費用はどれくらいですか。 初期構築で 35,000 から 120,000 ポンド、保守で年間 12,000 から 30,000 ポンドを見込んでください。英国エージェンシーの日額はおよそ 600 から 900 ポンドです。3 年間では、ホスティングを含めて Drupal Commerce のショップは通常 76,000 から 235,000 ポンドに収まり、Shopify Advanced はおよそ 32,000 から 79,000 ポンドです。これらは社内の目安であり、見積もりではありません。

どのバージョンの Drupal Commerce を使うべきですか。 Drupal Commerce 3 で、現在は 2026 年 7 月 17 日に公開された 3.3.8 です。Drupal 10.3 以降および Drupal 11 で動作し、安定版リリースは Drupal のセキュリティアドバイザリポリシーの対象です。Commerce 2 は Drupal 9 と 10 に対応した前のリリースサイクルなので、新規の案件は 3.x から始めるべきです。

Drupal Commerce は EU の VAT と OSS に対応していますか。 税の規則はアドオンとして売られるのではなく Commerce のコアに組み込まれています。欧州連合 VAT プラグインは 27 の加盟国とモナコの税率を保持し、標準、軽減、中間、超軽減、ゼロの各税率を区別し、特別地域を扱い、デジタル商品に仕向地課税を適用し、有効な税番号に対して EU 域内の B2B 取引をゼロ税率にします。OSS 申告の提出は会計上の作業として残ります。

ヘッドレスの Drupal Commerce はいつ価値がありますか。 ウェブサイト以外の何か、たとえばネイティブアプリ、POS 端末、別のチームが所有するフロントエンドが同じカタログを利用するときです。速度のためだけなら価値はありません。キャッシュされた従来型のフロントエンドはすでに十分速いからです。チェックアウトの作り直しを予算に入れてください。分離型の構築では通常 40% 以上を占めます。