VendureとMedusaは、どちらもTypeScriptで書かれたオープンソースのヘッドレスコマース基盤です。2026年10月11日時点の最新版は、Vendureが3.7.4(2026年10月5日)、Medusaが2.21.2(2026年9月28日)です。この記事では、両者の違いを「ライセンス」「APIの形」「対応データベース」「B2B・多店舗の作り方」「有償版の料金」の5点で並べ、要件ごとにどちらを選ぶかを判断できるようにします。
まとめ
- VendureはNestJS+GraphQL+TypeORMの構成で、PostgreSQL・MySQL/MariaDB・SQLiteに対応します。ライセンスはv3.0からGPLv3で、その条件を守って利用・改変・配布するか、商用ライセンス(VCL)を結ぶかを選びます。
- MedusaはREST API+Modules・Workflowsの構成で、データベースはPostgreSQLのみです。コアはMITですが、v2.19.0(2026年8月13日)からRBACとSSOのコードは商用契約が必要なEnterprise部分になりました。
- 1つのサーバーで複数店舗・地域別店舗・マーケットプレイスを動かすならVendureのChannel、ライセンス審査を軽くしてREST中心に組むならMedusaが有利です。
- 有償版は、Vendure Platformが年額固定の個別見積もり、Medusa Cloudが月額29ドルからの4プランです。どちらもGMV(流通総額)に応じた手数料はかかりません。
- 管理画面の日本語訳は、翻訳ファイル上はVendureが99.0%、Medusaが99.4%まで埋まっています。実装で差が出やすいのは、決済プラグインの供給元と、APIが返す金額の単位(Vendureは最小単位、Medusaは主単位)です。
以下、比較表で全体像を押さえたあと、各製品の構成、ライセンス、有償版、B2B、日本向けの差分、選び方、動かし方の順に説明します。
VendureとMedusaの違いを比較表で確認
| 項目 | Vendure | Medusa |
|---|---|---|
| 最新版(2026-10-11) | 3.7.4(2026-10-05) | 2.21.2(2026-09-28) |
| 現行メジャーの開始 | 3.0.0(2024-07-17) | 2.0.0(2024-10-22) |
| サーバー基盤 | NestJS | Express.js |
| API | GraphQL(Shop API/Admin API) | REST(Store API/Admin API)+JS SDK |
| ORM | TypeORM | MikroORM |
| 対応DB | PostgreSQL・MySQL/MariaDB・SQLite | PostgreSQLのみ |
| コアのライセンス | GPLv3(またはVCL) | MIT(RBAC・SSOは除く) |
| Node.js(公式手順) | v20・v22・v24 | v20.19以上またはv22.12以上のLTS |
| 管理画面 | React製Dashboard(v3.5で安定版) | Medusa Admin(Vite+React) |
| 有償版 | Vendure Platform(年額見積) | Medusa Cloud(月29ドル〜) |
版と日付はnpmの@vendure/coreと@medusajs/medusaの公開記録から取りました。Node.jsの要件はVendureのインストール手順とMedusaのインストール手順の記載です。両者ともほぼ毎月パッチを出しているため、導入時点の版はnpmで確認してください。
Vendureとは:NestJSとGraphQLで組むTypeScript製コマース基盤
Vendureは、Node.js上のNestJSで動くヘッドレスコマースのフレームワークです。商品・在庫・注文・配送・決済・プロモーションといったEC機能をGraphQL APIで提供し、ストアフロントは自由に作ります。データベースはTypeORM経由でPostgreSQL、MySQL/MariaDB、SQLiteを選べます(Vendureの開発者ガイド)。SQLiteで手元検証を始め、本番でPostgreSQLに切り替える進め方ができるのは、PostgreSQL専用のMedusaにない利点です。
Shop APIとAdmin APIの2系統GraphQL
Vendureは購入者向けの/shop-apiと管理者向けの/admin-apiを分けて公開します。公式の公開デモに商品一覧のクエリを投げると、次の結果が返りました(2026年10月11日に実行)。
curl -s -X POST https://demo.vendure.io/shop-api \
-H 'content-type: application/json' \
-d '{"query":"{ products(options:{take:2}){ totalItems items{ name variants{ sku priceWithTax currencyCode } } } }"}'
# 結果(抜粋)
# "totalItems": 54
# "name": "Laptop"
# "sku": "L2201308", "priceWithTax": 155880, "currencyCode": "USD"
# "name": "Tablet"
# "sku": "TBL200032", "priceWithTax": 39480, "currencyCode": "USD"
priceWithTaxの155880は1,558.80ドルを表します。Vendureは金額を通貨の最小単位(ドルならセント)の整数で保存する設計で、USDなら表示側で100で割って整形します(Vendureの金額の扱い)。ストアフロントを書くときに小数を使わない前提で組めるため、合計金額の丸め誤差が出にくい反面、フロント側で桁の変換を忘れると100倍の価格を表示します。
Channelによる複数店舗・マーケットプレイスの集約
VendureのChannelは、1つのサーバーの中に複数の販売チャネルを作る仕組みです。チャネルごとに通貨・言語・税・配送の既定値、扱う商品とその価格、管理者の権限範囲を分けられます(Channelsのドキュメント)。公式が挙げる用途は、複数ショップを1台で動かすマルチテナント、チャネルを出品者に見立てたマーケットプレイス、地域別ストア、自社EC・Amazon・Facebookのような販売経路の分離の4つです。各チャネルにはSellerエンティティが1つ紐づき、出品者情報をカスタムフィールドで足せます。
商品・注文・顧客・プロモーション・在庫拠点など13種類のエンティティがチャネルに属する設計なので、「ブランドAとブランドBで価格と在庫拠点を分け、管理者も分けたい」という要件を、テーブル設計から作らずに設定で満たせます。
v3.7で加わったCLIとDashboardの変更
2026年7月1日のVendure 3.7.0では、vendure dev・vendure build・vendure startの3コマンドが入り、サーバー・ワーカー・Dashboardの起動とビルドを自前のスクリプトなしで行えるようになりました。設定・依存関係・スキーマ・DBを点検するvendure doctorも追加されています。Dashboardを事前バンドルで配る試験的なオプションでは、初回表示のネットワークリクエストが3,047件から39件に減ったと公式が計測しています。
React製の新Dashboardは3.2でalpha、3.5(2025年10月22日)で安定版になりました。従来のAngular製Admin UI向けに画面拡張を書いている場合は、新Dashboardの拡張APIへ移し替える作業が発生します(旧UIの拡張APIはドキュメント上「Legacy APIs」に分類されています)。
Medusaとは:ModulesとWorkflowsで組むv2のアーキテクチャ
Medusaは、Express.jsベースのサーバーとVite製の管理画面(Medusa Admin)で構成されるコマース基盤です。2024年10月のv2.0で全面的に作り直され、2026年はほぼ月1回のペースでマイナー版が出ています(2.18.0が7月23日、2.19.0が8月13日、2.20.0が9月2日、2.21.0が9月11日)。Medusa単体の構成・費用・日本対応はMedusaでEC構築する判断基準で詳しく扱っているので、ここではVendureとの比較に必要な点に絞ります。
4層構成とPostgreSQL専用の割り切り
Medusaのリクエストは、API Routes(HTTP)→Workflows→Modules→データストアの4層を通ります。業務ロジックはWorkflowsに置き、商品・カート・価格・在庫といったドメインごとの処理はModulesが持ちます(Medusaのアーキテクチャ)。Workflowsは各ステップに取り消し処理(compensation)を書けるので、決済は通ったが在庫引当で失敗した、といった途中失敗を巻き戻す処理をフレームワークの作法で書けます。
データベースは「PostgreSQLのみ対応」と公式に明記されています。MySQLを社内標準にしている組織では、ここが最初の分岐点になります。
Store APIのpublishable API keyと販売チャネルの範囲
Medusaの購入者向けAPI(/store)は、すべてのリクエストにx-publishable-api-keyヘッダーが必要です。キーは販売チャネル(Sales Channel)に紐づき、どのキーで呼んだかで返す商品の範囲が決まります(publishable API keyのドキュメント)。手元に構築したMedusa 2.21.2で確かめた結果は次のとおりです。
# キーなし
curl -s http://localhost:9000/store/products
# => 400 {"type":"not_allowed","message":"Publishable API key required in the request header: x-publishable-api-key. ..."}
# キーあり(pk_...とreg_01M4...は自環境の有効な値に置換)
# region_idを付けると、その地域に基づいて価格が計算される
curl -s "http://localhost:9000/store/products?limit=1&fields=title,variants.sku,*variants.calculated_price®ion_id=reg_01M4..." \
-H "x-publishable-api-key: pk_..."
# => "count": 4, "title": "Medusa Sweatpants", "sku": "SWEATPANTS-L"
# "calculated_price": { "calculated_amount": 10, "currency_code": "eur", ... }
キーなしの呼び出しは拒否されます。キーありの例はlimit=1なので、取得する商品は最大1点です。countは条件に一致する商品の総件数を表します。価格はregion_idを渡したときに地域の通貨で計算されます。Vendureとの違いは金額の表し方で、Medusaは10ユーロを10(通貨の主単位)で返し、DBにも{"value": "10", "precision": 20}の形で保存していました。USDやEURを表示する場合、Vendureの最小単位の値は100で割り、Medusaの主単位の値はそのまま整形します。Vendureの換算倍率は通貨の小数桁数に合わせます。
ライセンスの違い:GPLv3のVendureとMIT+Enterprise部分のMedusa
ライセンスを比較する際は、コアと商用機能を分けて確認します。2026年に入って両者とも有償部分の線引きを動かしています。社内の法務確認に回す前に、次の2点を押さえてください。
Vendure:v3.0からGPLv3とVCLのデュアルライセンス
Vendureのライセンスは、2.x系まではMITでした。npmの公開記録では、2024年7月17日の3.0.0からGPL-3.0-or-laterに変わり、並行保守された2.3.x系(最終は2026年4月13日の2.3.4)はMITのままです。現行のLICENSE.mdは「GPLv3(Community Edition)」と「Vendure Commercial License(VCL)」の二本立てで、商用契約がなければGPLv3が適用されます。GPLv3の第7条に基づく追加の例外があり、Vendure用のプラグインは別のライセンスで配布できます。
実務上は、改変の有無だけでなく、Vendureを第三者に配布するか、配布時にGPLv3の条件を満たせるかを確認します。自社ECのサーバーで動かすだけなら配布にあたらないのが一般的な解釈ですが、Vendureを組み込んだパッケージ製品を顧客に納品・販売する場合はソース開示義務の対象になりうるため、VCLを結ぶか、法務の判断を取ってから着手します。
Medusa:v2.19.0からRBACとSSOが商用契約の対象
Medusaのリポジトリは、2026年8月11日のコミットでENTERPRISE-LICENSE.mdを追加しました。RBAC(ロールベースのアクセス制御)とSSO(シングルサインオン)のコードは「Enterprise Materials」としてMITの対象から外れ、MedusaJS, Inc.との商用契約がなければ使えません。この変更は2026年8月13日公開の2.19.0から含まれます。それより前の版でMITとして公開された部分の権利は取り消さない、と同ファイルに明記されています。
つまり「MITだから全機能を無償で使える」は2.19.0以降は成り立ちません。管理画面で担当者ごとに権限を分ける、社内IdPでログインさせる、という要件があるなら、Medusaでは自前実装かEnterprise契約のどちらかを選ぶことになります。
有償版と料金:Vendure PlatformとMedusa Cloud
| 提供形態 | 料金 | 主な内容 |
|---|---|---|
| Vendure Core | 無料(GPLv3) | OSSのフレームワーク本体 |
| Vendure Platform | 年額固定・個別見積 | B2B機能・VCL・サポート・LTS |
| Vendure Cloud | デザインパートナー募集中 | 一般提供は2027年第1四半期予定 |
| Medusa(セルフホスト) | 無料(MIT部分) | RBAC・SSOは含まない |
| Medusa Cloud Develop | 月29ドル〜 | GitHub連携デプロイ・PRプレビュー |
| Medusa Cloud Launch | 月99ドル〜 | オートスケール・自動バックアップ |
| Medusa Cloud Scale | 月299ドル〜 | バックグラウンドワーカー・優先サポート |
| Medusa Enterprise | 個別見積 | RBAC・SSO・監査ログ・SLA |
Vendureの料金ページによると、Platformは流通総額・注文数・ユーザー数・機能ごとの課金がない年額固定のサブスクリプションで、案件ごとに見積もります。B2Bの購買・価格・カタログ、検索、ストアフロント、商用ライセンスとIP補償が含まれます。マネージド実行環境のVendure Cloudは有償のデザインパートナー制度で受け付けており、正式なSLAは一般提供から始まります(Vendure Cloud)。
Medusaの料金ページは4プランともGMV手数料0.0%で、注文数・商品数・販売チャネル数は無制限です。RBAC・SSO・監査ログはEnterpriseプランの項目に並んでおり、前章のライセンス変更と対応しています。月額で始めて規模に応じて上げられるのはMedusa、最初から商用ライセンスとB2B機能込みの年間契約を前提にするのはVendureという違いです。
B2B・多店舗要件での実装単位の違い
同じ「B2B対応」でも、両者は道具の組み合わせ方が違います。Medusaは、販売チャネル(B2B用の商品だけを載せる)、顧客グループ(取引先ごとの分類)、価格表(Price List、グループ別の価格や期間条件)の3つのCommerce Moduleを組み合わせる手順を公式レシピで示し、そのまま使えるB2Bスターターも公開しています(MedusaのB2Bレシピ)。B2BスターターはMITライセンスで、企業の登録と従業員の招待、従業員ごとの購入上限、発注前の承認フロー、見積の交渉までを実装済みです。
Vendureは、Core側にChannel・顧客グループ・プロモーションがあり、契約価格、顧客別価格、数量段階価格、承認フロー、企業アカウント、SSO、監査ログといった企業間取引の機能は有償のPlatform側で提供する分担です(Vendureの2026年技術ロードマップ)。
判断の目安は、承認フローや企業アカウントを「自社でコードを持って保守するか、製品の機能として買うか」です。コードを持つならMedusaのB2Bスターターを起点に改修し、製品として保守まで任せたいならVendure Platformの見積を取ります。顧客グループ別の価格と専用カタログで足りるなら、MedusaのOSS部分かVendure Coreで十分に組めます。どちらでも、社内IdPとのSSOを製品機能として使う部分は有償契約(Vendure Platform、Medusa Enterprise)の範囲です。
日本向けECで確かめる実装差分
管理画面の日本語訳は、翻訳ファイルの充足率で見るとどちらもほぼ埋まっています。リポジトリの翻訳ファイルを数えると、VendureのDashboard(ja.po)は1,314項目のうち未翻訳が13件で99.0%、Medusa Admin(ja.json)は英語版en.jsonの2,446キーがすべて存在し、英語と同じ文字列のまま残っているのが14件で99.4%でした(2026年10月11日時点のmaster/developブランチ。14件にはSKUのように訳す必要のない語も含みます)。
差が出るのは決済まわりです。Vendureは2026年のロードマップで、Stripeなど外部サービス連携のプラグインをコアから切り離し、v3.6以降は@vendure-communityのnpm組織から公開すると発表しました。実際に@vendure-community/stripe-pluginの1.0.0が2026年3月30日に公開され、旧@vendure/payments-pluginは3.5.6で更新が止まっています。保守はコミュニティ主体になるため、決済連携の更新頻度は導入前にリポジトリで確認しておきます。Medusaの@medusajs/payment-stripeはコアと同じ2.21.2で公開されており、版がそろっています。
KOMOJUやGMOペイメントゲートウェイを使う場合は、採用する版に対応した連携の提供元と保守状況を確認します。npmで「komoju」を検索した範囲では、VendureやMedusa向けの連携パッケージは見当たりませんでした(2026年10月11日時点)。利用できる連携がなければ、VendureはPaymentMethodHandler、MedusaはPayment Module Providerとして実装することになり、ここがスケジュールの読みどころです。
VendureとMedusaの選び方:要件別の判断基準
| 要件 | 向く方 | 理由 |
|---|---|---|
| MySQLを使う・SQLiteで試したい | Vendure | MedusaはPostgreSQLのみ |
| 1台で複数ブランド・地域店舗 | Vendure | Channelで価格・在庫・権限を分割 |
| GraphQLで型を生成して使う | Vendure | Shop/Admin APIがGraphQL |
| 受託で納品し再配布する | Medusa | コアはMIT(RBAC・SSO除く) |
| 月額で小さく開発・検証 | Medusa | Developは月29ドルから |
| 途中失敗の巻き戻しが多い処理 | Medusa | Workflowsの取り消し処理 |
| 承認フロー・購入上限を自社コードで持つ | Medusa | MITのB2Bスターターに実装済み |
| 標準提供の企業向けSSO | どちらも有償 | Vendure Platform/Medusa Enterprise |
迷ったときは、データベースとライセンスの2点で先に絞り込みます。機能の多くは両者で作れますが、PostgreSQL以外を使えるかどうかと、配布時にソース開示が問題になるかどうかは、後から設計で吸収できません。
どちらも採用しない方がよい場面もあります。商品数が数百点で、決済・配送が国内の標準的な組み合わせなら、Shopifyのようなホスト型のほうが立ち上げも保守も軽く済みます(規模ごとの線引きはShopify Plusとは|通常プランとの機能差と移行する売上規模の線引き)。Node.jsとTypeScriptを書ける開発者が社内に1人もいない体制でVendureやMedusaを選ぶと、毎月のパッチ追従とセキュリティ修正を外部に頼り続けることになります。自社の要件に対して、ホスト型・パッケージ・OSS・フルスクラッチのどれが合うかから決めたい場合は、ECシステム開発の支援内容も参考にしてください。
VendureとMedusaを手元で動かす手順
Vendureの最小構成
Vendureは@vendure/createで雛形を作ります。Quick Startを選ぶと、Docker Desktopが動いていればPostgreSQL、なければSQLiteで構成され、DBを別に用意せずに試せます。
npx @vendure/create my-shop
# 「Quick Start」を選択(ストアフロントはTanStack Start/Next.js/なしから選択)
cd my-shop
npm run dev
# Dashboard: http://localhost:3000/dashboard(superadmin / superadmin)
# Shop API: http://localhost:3000/shop-api
Medusaの最小構成
Medusaはcreate-medusa-appで作ります。PostgreSQLが動いていることが前提で、既存のDBを使う場合は--db-urlで接続先を渡します。
# 以下の2コマンドはどちらか一方を実行
npx create-medusa-app@latest my-medusa-store
# 既存のPostgreSQLを使う場合はこちら
npx create-medusa-app@latest my-medusa-store --db-url "postgres://postgres@localhost:5432/medusa"
# 管理画面: http://localhost:9000/app
# バックエンドの再起動: cd my-medusa-store/apps/backend && npm run dev
2026年10月11日に上のコマンドで構築したところ、生成されたのはapps/backend(Medusa本体と管理画面)を含むモノレポで、マイグレーションと初期データ(商品4点・地域1つ・publishable API key 1本)の投入まで自動で終わりました。生成されたpackage.jsonはenginesでnode >=22.22.0を要求していたため、公式手順の下限(v20.19・v22.12)を満たしていても、22.22.0未満なら先に上げておきます。
よくある質問
Vendureとは何ですか?
Vendureは、TypeScriptとNestJSで作られたオープンソースのヘッドレスコマース基盤です。EC機能をGraphQLのShop APIとAdmin APIで提供し、PostgreSQL・MySQL/MariaDB・SQLiteで動きます。コアはGPLv3で、商用ライセンスと年額制のVendure Platformも提供されています。
Medusa.jsはオープンソースで無料で使えますか?
MIT対象部分は、自社サーバーか外部クラウドかにかかわらずライセンス料なしで利用できます。ただし2.19.0(2026年8月)以降、RBACとSSOのコードは商用契約が必要なEnterprise部分です。マネージド環境のMedusa Cloudは月29ドルからの有料プランです。
VendureとMedusaの最新バージョンはいくつですか?
2026年10月11日時点で、Vendureは3.7.4(2026年10月5日)、Medusaは2.21.2(2026年9月28日)です。どちらも毎月のようにパッチが出るため、導入時はnpmの公開記録で確認してください。
VendureとMedusaはどちらがB2Bに向いていますか?
顧客グループ別の価格と専用カタログで足りるなら、どちらのOSS部分でも構築できます。Medusaでは企業管理・承認フローをMITライセンスの公式B2Bスターターで構築でき、標準のEnterprise SSOは商用契約の対象です。Vendure Platformの提供機能も含め、見積と自社開発の工数を比べて決めます。
ヘッドレスEコマースとは何ですか?
ストアフロント(画面)とEC機能(商品・カート・注文・決済)をAPIで分離した構成です。画面は任意のフレームワークで作り、EC機能はVendureやMedusaのような基盤から呼び出します。仕組みと従来型ECとの違いはヘッドレスコマースとは?で解説しています。