開発者向けオープンソースEコマースプラットフォーム5選

2026年にヘッドレスストアフロントを構築するフロントエンドエンジニアが評価すべき、最も優れたオープンソースコマースバックエンドは、Medusa、Saleor、Vendure、Sylius、Shopware の5つです。いずれもAPIファーストで積極的にメンテナンスされており、Next.jsやその他のReactベースのストアフロントとの親和性が高い設計になっています。ただし、言語ランタイム、APIの形式（REST vs GraphQL）、ライセンスモデル、セルフホスティング時の運用負荷といった点では、それぞれ大きく異なります。本記事は、数週間の統合作業と数年にわたるメンテナンスを伴うプロジェクトに向けて、最適なプラットフォームを絞り込む際の判断材料を提供することを目的としています。

WooCommerce、Magento、PrestaShopについても、正直に触れておく必要があります。これらは成熟したエコシステムを持ち、広く普及しており、以下で紹介するプラットフォームが未だ追いついていない豊富なプラグインマーケットプレイスとマーチャント向けツールを備えています。しかし、その中心はWordPress／管理テンプレートの世界であり、TypeScriptで記述されたAPIドリブンなストアフロントではありません。ストアフロントがNext.jsアプリとして型付きSDKやGraphQLエンドポイントを呼び出す構成であれば、以下の5つのプラットフォームが検討すべき候補です。マーケティングチームが管理するテーマ型CMSサイトであれば、本記事はその目的に合っていません。

ヘッドレスコマースはもはや売り込むべきトレンドではなく、グリーンフィールドのストアフロント開発においてデフォルトのアーキテクチャとなっています。問われるべきは「ストアフロントをコマースエンジンから切り離すかどうか」ではなく、「その後に続く長年の機能開発において、最良の開発者体験を提供するエンジンはどれか」です。

選び方：比較表

候補を絞り込む最も早い方法は、ストアフロント開発者が実際に重視する観点でプラットフォームを並べて比較することです。以下の表に5つの候補をまとめています。スター数やリリースバージョンは常に変動するため、あくまで出発点として捉え、採用を決定する前に各プロジェクトのGitHubリリースページで最新情報を確認してください。

プラットフォーム	主要言語／ランタイム	アーキテクチャ	APIモデル	OSSライセンス	デフォルトストアフロント	セルフホスティングの構成要素	公式／推奨Next.jsスターター
Medusa	TypeScript / Node.js	ヘッドレス、モジュラー（v2）	REST中心のAPI	MIT	Next.jsスターター	Node + PostgreSQL + Redis	あり（公式）
Saleor	Python / Django	ヘッドレス	GraphQLのみ	BSD-3-Clause	Reactストアフロントサンプル	Python + PostgreSQL + Redis + Celeryワーカー	あり（公式Next.jsサンプル）
Vendure	TypeScript / NestJS	ヘッドレス	GraphQL（Shop + Admin API）	MIT（コア）	Remix + Next.jsコミュニティスターター	Node + PostgreSQL/MySQL	コミュニティスターター
Sylius	PHP / Symfony	ハイブリッド（サーバーレンダリング + API PlatformによるREST/GraphQL）	REST + GraphQL	MIT	Twigストアフロント（ヘッドレスはオプション）	PHP + MySQL/PostgreSQL	コミュニティサンプル
Shopware	PHP / Symfony + Vue.js	ハイブリッドヘッドレス	REST Store API + Admin API	MIT（コア）	Vue.jsストアフロント（ヘッドレスはオプション）	PHP + MySQL + Elasticsearch/OpenSearch	コミュニティスターター

特に注目すべき列が2つあります。ライセンス列はすべてを語っているわけではありません。VendureとShopwareはいずれも、本番環境で完全に使用可能なMITライセンスのコアを提供しつつ、別途ライセンスされる商用マネージドプラットフォームも提供しています。これは評価予算を検討する上で重要な特徴であり、罠ではありません。オープンソースのコアは、プラットフォームの有料プランなしで実際に利用可能です。セルフホスティングの構成要素列は、本番環境で運用することになる最小限のサービスを示しており、SaleorがNodeベースの選択肢と大きく異なる点がここに現れています。

Medusa — v2モジュールとワークフローを備えたNode.js/TypeScriptヘッドレスコマース

Medusaは、Node.js/TypeScriptのヘッドレスコマースバックエンドです。v2リリースでは、プラットフォームが独立したコマースモジュール（商品、カート、注文、在庫、価格設定）を中心に再構成され、それぞれをカスタム実装またはサードパーティサービスに差し替えることができます。モジュールとワークフローのアーキテクチャについては、公式のv2ドキュメントを参照してください。

フロントエンドエンジニアの観点では、本記事で紹介する5つのプラットフォームの中で最もコンポーザブルな設計です。ストアフロントのコードは型付きJavaScriptクライアントを通じてMedusaサーバーと通信し、バックエンドのカスタマイズはTypeScriptでモジュールとワークフローを記述することで行います。これらはチームの他のサービスと同じモノレポに配置することも可能です。Medusaドキュメントの公式Next.jsスターターを使えば、create-medusa-app コマンド一つで、カート、チェックアウト、アカウントフローを備えた動作するストアフロントを構築できます。

Medusaが優れている点：

• エンドツーエンドの型整合性。 サーバーはTypeScript、ストアフロントSDKはTypeScript、カスタムモジュールもTypeScriptです。スキーマとストアフロントの型の間にコード生成ステップは不要です。
• ワークフロー。 Medusa v2は、複数ステップのコマース操作（注文確定、返品など）のための明示的なワークフロープリミティブを提供しており、暗黙的なトランザクションチェーンよりも長時間実行や補償ロジックを扱いやすくなっています。
• ローカル開発が簡単。 PostgreSQLに対する単一のNodeプロセスと、バックグラウンドジョブ用のRedisだけで動作します。

Medusaで注意すべき点：

• REST中心。 MedusaのプライマリAPIはRESTです。単一のGraphQLエンドポイントとコード生成による型付きクエリを求めるストアフロントには、Saleorの方が自然に感じられるでしょう。
• v1 → v2の移行。 Medusa v1を使用しているコードベースは、無視できない移行作業が必要です。モジュールシステム、管理画面、APIがすべて大幅に変更されています。

Medusaを選ぶべき場合： チームがTypeScriptネイティブで、自分たちの言語でカスタマイズの完全な所有権を持ちたく、REST + 型付きSDKのエルゴノミクスが適している場合。Medusaを避けるべき場合： GraphQLのみのデータレイヤーが必要な場合、または初日から充実したオフザシェルフの管理・マーチャンダイジングツールセットが必要な場合。

Saleor — Python/Django上のGraphQLファーストヘッドレスコマース

SaleorはPython/Djangoのヘッドレスコマースプラットフォームであり、GraphQLファーストのAPIを採用しています。商品クエリ、チェックアウトのミューテーション、注文管理、顧客アカウントなど、すべてのコマース操作はSaleor APIリファレンスに記載された単一のバージョン管理されたGraphQLエンドポイントを通じて実行されます。コードベースはBSD-3-Clauseライセンスです。GitHubのLICENSEファイルを参照してください。

GraphQLファーストの設計が最も効果を発揮するのはストアフロントレイヤーです。Next.jsストアフロントは urql、Apollo、または graphql-request を使用してコンポーネントとデータ要件を共存させ、Saleorのスキーマに対してgraphql-codegenを実行することで、別途RESTアダプターレイヤーを記述することなく完全に型付けされたクエリとミューテーションフックを得られます。典型的な商品ページのクエリは次のようになります：

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

この単一のクエリは、ページがレンダリングするものをそのまま返します。過剰なフェッチも、別途の在庫呼び出しも、サーバーの通貨認識とずれが生じる価格フォーマットヘルパーも不要です。Saleorはまた、ゼロから構築する代わりにフォークできる公式Next.jsストアフロントサンプル（storefrontリポジトリ）も公開しています。

Saleorで注意すべき点：

• 運用上の負荷。 Saleorをセルフホストするには、Python、PostgreSQL、Redis、非同期タスク用のCeleryワーカープロセスが必要です。Node + PostgreSQLの組み合わせよりも重く、チームがすでにPythonスタックを運用していない場合は考慮が必要です。
• スキーマバージョニングの規律。 GraphQLファーストのプラットフォームでは、スキーマの破壊的変更が表面化します。Saleorは明確な移行ノートを伴う新しいマイナーバージョンをリリースしていますが、スキーマをピン留めして型を再生成しないストアフロントは、アップグレード後にサイレントな不具合に直面します。

Saleorを選ぶべき場合： 単一のGraphQLエンドポイントが必要で、Pythonスタックの運用に問題なく、ストアフロントチームがGraphQLクライアントとコード生成に精通している場合。Saleorを避けるべき場合： チームにPythonの運用経験がなく、スタック全体をNodeで統一したい場合。

Vendure — MITコアと商用Platformティアを持つTypeScript/NestJSフレームワーク

VendureはTypeScript/NestJSのヘッドレスコマースフレームワークであり、GraphQL APIとAngularベースの管理画面を備えています。本比較の中で唯一、プラグインAPI、サービスレイヤー、GraphQLスキーマ拡張を完全な型推論付きのTypeScriptで提供するプラットフォームです。つまり、カスタムプラグインとストアフロントのコードが単一の言語と型モデルを共有します。Vendureドキュメントでは、プラグインシステム、Shop/Admin GraphQL APIの二重構成、データモデルについて説明しています。

VendureのオープンソースCore（MITライセンス）は、完全に機能するヘッドレスコマースエンジンです。商用のVendure Platformはマネージドホスティング、エンタープライズサポート、追加モジュールを提供しますが、本番ストアフロントの運用には必須ではありません。採用前にこの分離を理解しておくことが重要です。Coreは本当に完成されており、「オープンソース」は「機能が制限されたデモ版」を意味しません。

ストアフロントの観点では、Vendureはパブリックなストアフロント操作用の Shop と、バックオフィスツール用の Admin という2つのGraphQL APIを公開しています。どちらもイントロスペクション可能でコード生成に対応しています。サーバーの基盤にはNestJSが使われているため、チームにNestJSの経験があれば、カスタムプラグインは馴染みのあるモジュール・プロバイダーパターンに従います。

Vendureが優れている点：

• あらゆる場所でTypeScript。 サーバー、プラグイン、管理UI拡張、ストアフロントが1つの型システムで統一されています。
• クリーンなプラグインアーキテクチャ。 カスタムフィールド、ライフサイクルフック、GraphQLスキーマ拡張が一級市民として扱われており、後付けではありません。
• 軽量なセルフホスティング。 PostgreSQLまたはMySQLに対する単一のNodeプロセスで動作します。ローカル開発のデフォルトはSQLiteを使用します。

Vendureのトレードオフ：

• エコシステムが小さい。 SaleorやMedusaと比較して、サードパーティのプラグインや統合のカタログが少ないです。より多くのグルーコードを自分で書く必要があります。
• 管理画面はAngular。 管理UIを大幅にカスタマイズする予定があり、チームがReactのみの場合、コンテキストスイッチのコストが発生します。

Vendureを選ぶべき場合： 最もTypeScriptネイティブで型安全なヘッドレスコマーススタックを求めており、一部の統合を自分で構築することを厭わない場合。Vendureを避けるべき場合： 初日から最も広いプラグインマーケットプレイスが必要な場合、またはAngularの管理画面を許容できない場合。

Sylius — API PlatformによるRESTとGraphQLを備えたSymfonyコマースフレームワーク

Syliusは、Symfony（PHP）上に構築されたオープンソースのEコマースフレームワークです。ターンキープラットフォームではなくフレームワークとして位置付けられており、コマースのプリミティブ（商品、チャネル、注文、プロモーション、カート）を提供し、それらをビジネスが実際に必要とするアプリケーションに組み合わせることを前提としています。Syliusドキュメントでは、コンポーネントモデルとSymfonyバンドルについて説明しています。

フロントエンドエンジニアにとってSyliusが重要なのは、そのAPIレイヤーにあります。SyliusはAPI Platformと統合してデータモデル上にRESTおよびGraphQLエンドポイントを公開しており、Next.jsやその他のJavaScriptストアフロントのヘッドレスバックエンドとして利用可能です。デフォルトのストアフロントはTwigテンプレートを使用しており、従来型のビルドには適していますが、ヘッドレス構成では無視できます。

Syliusが優れている点：

• Symfonyの深み。 組織がSymfonyに精通している場合、Syliusはここで紹介する他のどのプラットフォームよりも自然にPHPエンタープライズエコシステムに統合されます。
• フレームワークのイディオムによるカスタマイズ。 標準的なSymfonyパターンを使用してサービス、イベント、エンティティをオーバーライドできます。独自のプラグインDSLは不要です。
• MITライセンス、商用ティア不要。 MITライセンス下のSyliusコードベース全体がそのまま構築の基盤となります。

Syliusのトレードオフ：

• PHPランタイム。 PHPの運用経験がないNext.jsチームは、バックエンドのためにPHP-FPM、Composer、Symfonyツールを引き継ぐことになります。
• より多くの組み立てが必要。 Syliusはフレームワークであることを正直に示しています。ターンキープラットフォームと同等の機能に達するには、MedusaやSaleorよりも多くのコードを書く必要があります。

Syliusを選ぶべき場合： 社内にSymfonyの知識があり、ドメインに完全に合わせて形成できるコマースフレームワークを求めている場合。Syliusを避けるべき場合： チームがJSのみで、NodeサービスのそばにPHPランタイムを運用したくない場合。

Shopware 6 — 充実したマーチャントツールとVue.jsストアフロントを持つPHP/Symfonyバックエンド

Shopware 6のMITライセンスのCommunity Editionは、従来型とヘッドレスの両方のデプロイオプションを持つフル機能のコマースバックエンドであり、Vue.jsベースのストアフロントフレームワークと並行してREST Store APIを公開しています。商用のRise、Evolve、Beyondプランはマネージドホスティング、高度なB2B機能、エンタープライズサポート機能を追加しますが、オープンソースのコアは商用ライセンスなしで本番環境での使用が可能です。Shopware開発者ドキュメントでは、Store API、Admin API、アプリ／プラグインシステムについて説明しています。

Shopwareは本比較の中でマーチャント向け機能が最も充実したプラットフォームです。「Shopping Experiences」CMSはマーケティングページ用のドラッグアンドドロップページビルダーを提供し、ルールビルダーはコードなしで動的な価格設定、配送、プロモーションルールをサポートし、管理ツールは本格的な深さを持っています。Next.jsストアフロントを構築する開発者にとって、Store APIはRESTベースでドキュメントが充実しており、それを利用するコミュニティのNext.jsストアフロントスターターも存在します。

Shopwareが優れている点：

• 上記の開発者ファーストなプラットフォームのいずれも追いついていないすぐに使えるマーチャントツール。
• 成熟したパートナーエコシステムを持つ欧州市場での強固なポジション。
• ハイブリッドヘッドレス。 デフォルトのVue.jsストアフロントを実行するか、Store APIを通じて完全なヘッドレス構成にするかを選択できます。

Shopwareのトレードオフ：

• PHP + Elasticsearchの運用負荷。 Nodeの選択肢よりもセルフホスティングが重くなります。
• プラグインシステムはPHP中心。 ストアフロントがTypeScriptであっても、バックエンドのカスタマイズはPHP/Symfonyで行います。

Shopwareを選ぶべき場合： 初日から充実したマーチャント機能が必要で、Symfony/PHPスタックの運用に問題がない場合。Shopwareを避けるべき場合： チームがJSのみで、MedusaやVendureのようなより軽量で開発者ファーストな選択肢を好む場合。

Spreeが適している場面

Shopwareが大企業向けすぎると感じ、チームにRuby on Railsの経験がある場合、Spree Commerceは合理的な代替案です。MITライセンスで完全にAPIドリブン、マルチストアおよびマルチベンダー構成をサポートし、Railsのパターンが十分に確立されるほど長い歴史を持っています。トレードオフはSyliusと同じ形をしています。Symfonyの代わりにRuby on Railsを使用しますが、判断の構造は同じです。非JSランタイムの代わりに成熟したサーバーサイドフレームワークのエコシステムを採用するということです。

フロントエンド側の意思決定要素

ストアフロントの統合レイヤーでは、バックエンドが生産的に感じられるか苦痛に感じられるかを決める5つの要素があります。TypeScriptのエルゴノミクス、Next.jsとの互換性、ローカル開発のコールドスタート、プラグインアーキテクチャ、ドキュメントの充実度です。

TypeScriptとコード生成のエルゴノミクス。 MedusaとVendureはいずれも、別途生成ステップなしにサーバーの型と整合するTypeScript SDKを提供しています。SaleorのGraphQLスキーマは graphql-codegen を通じて利用するのが最適で、ビルドステップが追加されますが、優れた型付きフックが生成されます。SyliusとShopwareは、APIレスポンスを自分でモデル化するか、コミュニティが生成したクライアントを使用する必要があります。

Next.jsとの互換性。 MedusaとSaleorはいずれも、App Routerに対応した公式のNext.jsストアフロントサンプルを提供しています。Vendureにはコミュニティスターターがあります。SyliusとShopwareは通常、直接のAPI呼び出しやコミュニティSDKを通じてNext.jsストアフロントから利用されます。実用上は問題ありませんが、統合の多くを自分で記述することになります。

ローカル開発体験。 MedusaとVendureは最も速いコールドスタートを提供します。依存関係をインストールし、マイグレーションを実行し、サーバーを起動すれば完了です。SaleorはPython + Redis + Celeryの要件により重くなりますが、ドキュメントは充実しており、Docker Composeが推奨されています。ShopwareとSyliusは動作するPHP開発環境を前提としており、Dockerイメージで緩和されますが、構成要素はより多くなります。

プラグインと拡張アーキテクチャ。 5つのプラットフォームすべてがカスタム拡張をサポートしていますが、開発者体験は異なります。VendureのプラグインはTypeScriptモジュールで、型安全なライフサイクルフックを持ちます。Medusa v2のモジュールは明確なコントラクトを持つTypeScriptクラスです。Saleorはウェブフックベースの「アプリ」を使用し、別サービスとして実行されます。これは強力な分離境界ですが、運用上のオーバーヘッドが増えます。SyliusとShopwareはSymfonyのバンドル／プラグインシステムを使用します。

ドキュメントの品質。 5つの中で、Medusa、Saleor、Vendure、Shopwareはいずれも、APIリファレンス、チュートリアル、アーキテクチャ概要を含むドキュメントサイトをリリースに合わせて適切に更新しています。Syliusのドキュメントは充実していますが、Symfonyの知識を前提としています。

どのプラットフォームを選んでも発生する本番環境での障害

ヘッドレスストアフロントにおける本番環境での一般的な障害パターンとして、本記事のすべてのバックエンドに共通するものがあります。商品ページでのReactのハイドレーションミスマッチです。サーバーレンダリングされた価格、在庫数、またはローカライズされた文字列が、新鮮なデータをフェッチした後にクライアントがレンダリングするものと乖離する問題です。その他の繰り返し発生するパターンとしては、ネットワーク障害後にクライアントのカートとサーバーセッションがずれた場合のサイレントなカート状態の乖離、支払いプロバイダーのスクリプト（Stripe、Adyen、PayPal）の読み込みや初期化の失敗（チェックアウトボタンが動かなくなるだけで表面化する）、バックエンドのアップグレード後の破壊的なスキーマ変更による明確なエラーではなく不可解なnullフィールドの発生などがあります。

これらの障害はプラットフォームに依存しませんが、デバッグのしやすさはバックエンドがAPIレスポンスでエラーコンテキストをどのように公開するかによって異なります。SaleorのGraphQLエラーは構造化されたコードを持ち、MedusaのRESTレスポンスにはエラータイプが含まれ、ShopwareとSyliusはSymfonyの構造化エラーフォーマットを公開しています。どれを選択するにしても、ストアフロントにOpenReplayのようなセッションリプレイツールを導入して、実際のDOM状態、ネットワークリクエスト、コンソールエラー、カートの失敗やチェックアウトの破損につながるユーザー操作をキャプチャすることで、「ユーザーがチェックアウトが壊れていると言っている」から再現可能なバグレポートまでのループを閉じることができます。OpenReplayのセッションリプレイ製品は、このカテゴリのフロントエンド本番デバッグのために特別に構築されています。

最終判断

チームの言語習熟度とストアフロントのデータレイヤーの好みを考慮すれば、候補はすぐに絞り込まれます。型付きSDKを使用したNext.jsストアフロントを構築するTypeScriptネイティブなチームは、まずMedusaを、次にVendureを評価すべきです。単一のGraphQLエンドポイントを求め、Pythonスタックの運用を厭わないチームはSaleorを評価すべきです。Symfonyに精通したチームは、フレームワーク型のビルドにはSyliusを、最も充実したマーチャントツールにはShopwareを評価すべきです。コミットする前に、上位1〜2候補のローカルクイックスタートを実際に試してみてください。docker-compose up を実行して管理画面を一通り確認する半日の作業は、さらに一週間の比較記事を読むよりも多くのことを教えてくれます。

よくある質問

Shopifyをこれらのプラットフォームのオープンソースの代替として使用できますか？

いいえ。Shopifyはクローズドソースのホスト型SaaSプラットフォームであり、オープンソースではありません。ストアフロントのテーマはLiquidテンプレートを編集できる意味で公開されており、ヘッドレスストアフロント用のHydrogenフレームワークはMITライセンスですが、コマースエンジン自体はプロプライエタリでセルフホスティングはできません。セルフホスティングとソースコードへのアクセスが要件である場合、ShopifyはMedusa、Saleor、Vendure、Sylius、Shopwareと同じカテゴリには属しません。

これらのプラットフォームをセルフホストする場合、PCIコンプライアンスはどのように対応すればよいですか？

Stripe、Adyen、Braintree、Mollieなどのトークン化決済プロバイダーにカードデータを委ねて、生のカード番号がサーバーに触れないようにしてください。本記事の5つのプラットフォームはすべて、ホスト型決済フィールドまたはリダイレクトフローを通じてこれらのプロバイダーと統合しており、PCIの対象範囲を最も軽い自己評価ティアであるSAQ Aに抑えることができます。決済プロバイダーがカードのキャプチャを処理する限り、コマースバックエンドをセルフホストすること自体がPCIの負担を増やすわけではありません。

WooCommerceやMagentoからこれらのヘッドレスプラットフォームに移行できますか？

はい、ただし設定変更ではなくデータ移行と統合プロジェクトとして扱ってください。ソースプラットフォームから商品、顧客、注文、履歴データをエクスポートし、移行先プラットフォームの管理APIまたはカスタムインポートスクリプトを通じてインポートする必要があります。Saleor、Medusa、ShopwareはいずれもバルクインポートのためのAdmin APIを公開しています。URLの構造、SEOリダイレクト、顧客のパスワードハッシュは、最も過小評価されがちな移行ステップです。

これらのプラットフォームはマルチ通貨・マルチリージョンのストアフロントをサポートしていますか？

5つすべてがマルチ通貨をサポートしていますが、モデルは異なります。Saleorは「チャネル」を使用して通貨、言語、倉庫、価格をリージョンごとにスコープします。Medusa v2はリージョンごとの通貨、税率、決済プロバイダーを持つリージョンをサポートします。Vendureも同様のスコープを持つチャネルを持ちます。Shopwareは同じ目的に「セールスチャネル」を使用します。Syliusはチャネルシステムでこれをモデル化します。価格が通貨ごとに保存されるのか、リクエスト時に変換されるのかについては、各プラットフォームのドキュメントを確認してください。