TypeScript 製 OSS EC プラットフォームを 2026 年に選び直す — Medusa v2、Vendure v3、そして EverShop の使い分け
「TypeScript を中核に据えた OSS の EC プラットフォーム」という条件は、検索すると候補が大量に出てくる割に、実際にコアまで TypeScript で書かれていて、長期運用できるものまで絞ると、思いのほか狭い市場です。GitHub Topics で ecommerce-platform かつ TypeScript の公開リポジトリは約 100 件、ecommerce かつ TypeScript でおよそ 2,800 件ありますが、その大半はテンプレート、UI ライブラリ、管理画面、または特定 SaaS バックエンド向けのストアフロントです。
本記事では、コア API までが TypeScript で実装され、自前運用が現実的な OSS に絞ります。この基準でふるいにかけると、2026 年 5 月時点で候補は Medusa v2、Vendure v3、EverShop の 3 つに収束します。コアが Python の Saleor、ストアフロントのみで EC API を持たない Next.js Commerce などは、本稿の定義からは外しています。かつての有力候補だった Reaction Commerce（後の Mailchimp Open Commerce）は公式に “Project has been discontinued” と明示されており、新規採用の対象から外れています。
本記事では、この 3 つの技術スタック、ライセンス、アーキテクチャを揃えて比較したうえで、AI / Agentic Commerce 対応までを踏まえ、ユースケース別の選び方を整理します。
2026 年の地図 — TypeScript ネイティブで残ったのは 2 強 + α
まずは候補をひと目で把握できる地図を置きます。
flowchart LR
A[TypeScript ネイティブの OSS EC] --> A1[EC コア基盤]
A --> A2[一体型]
A1 --> M[Medusa v2<br/>MIT / Node.js]
A1 --> V[Vendure v3<br/>GPLv3 / NestJS / GraphQL]
A2 --> E[EverShop<br/>GPLv3 / Express + React]
A1 -.ディスコン.-> R[Reaction / Open Commerce]
「プロダクトの心臓部を OSS で完全に握りたい」「自前のデータモデルと業務ロジックを長期で組み続けたい」という前提に立つと、TypeScript ネイティブの選択肢はこれだけ狭いのが今の現実です。以下で、それぞれを順に見ていきます。
3 候補の概観
| プロジェクト | コア言語 | API | ORM / DB | ライセンス | GitHub Stars 概算 | 直近メジャー |
|---|---|---|---|---|---|---|
| Medusa v2 | TypeScript / Node.js | REST + JS SDK（内部に query.graph()） | MikroORM / PostgreSQL | MIT | 3 万超 | v2.0 = 2024-10-23、以後ほぼ月次で v2.x |
| Vendure v3 | TypeScript / NestJS | GraphQL（Shop / Admin） | TypeORM / PostgreSQL、MySQL、MariaDB、SQLite | GPLv3 | 約 8,000 | v3.6 系（2025 年後半）→ 継続パッチ |
| EverShop | TypeScript / Express | REST + GraphQL | カスタム + PostgreSQL | GPLv3 | 約 10,000 | 2026-04-03 リリース、TypeScript 5.8.3 |
数字は 2026 年初頭〜春時点の概算で、月単位で変動します。重要なオーダー感は、Medusa が最大の勢いと API-first の柔軟性、Vendure が型安全とエンタープライズ要件の堅さ、EverShop が小さく軽量な一体型という棲み分けです。
Medusa v2 — Decoupled Module で書き換えた「コマース OS」
Medusa は、デンマーク、コペンハーゲン発の OSS で、Shopify のオープン代替として急成長してきました。2024 年 10 月 23 日に v2.0 GA を出し、ここで完全リライトを敢行しています。設計の中核は「Decoupled Module Architecture」で、Cart、Inventory、Payment、Product、Promotion、Region、Translation など 17 のコマースモジュールがデータベース依存ゼロで独立し、Link Modules と Remote Joiner でモジュール間を論理的に結合します。
技術的には次の特徴があります。
- Workflows SDK によるリトライ、ロールバック付きオーケストレーション（補償トランザクション、つまりサーガパターンを単一アプリ内で実現）
- API は REST + JS SDK が主、
@medusajs/js-sdkでクライアント実装が型安全に書ける - 管理画面は Vite ベースの
@medusajs/dashboard、HMR とダークモード対応 - バリデーションは Zod（v2.14 で v4 に上がる破壊的変更あり）、ORM は MikroORM
- インフラは PostgreSQL + Redis、本番は server / worker 分離が公式推奨
ライセンスは MIT。商用利用、組み込み、SaaS 化、派生物の非公開のいずれも自由で、法務確認の重さは最小です。これが、エージェンシーや受託開発で第一候補に挙がる大きな理由になっています。
Medusa の弱点
一方で、Medusa は素のままだとサーバーレス相性が弱めで、長寿命 Worker を前提にしたインフラ設計になります。Redis 必須で、PostgreSQL に加えて Workflows のキューを持つため、構成は LocalStack 的な軽さではありません。コミュニティの実装プラグインも増えていますが、地域特化の決済プロバイダ向け公式プラグインがない領域ではカスタム実装が前提になります。
Vendure v3 — NestJS と GraphQL でエンタープライズ要件に振り切る
Vendure は、英国発、現在は商業母体 Elevantiq が運営する OSS で、NestJS + GraphQL + TypeORM が骨格です。Medusa が「REST のシンプルさと敏捷性」を取るのに対し、Vendure は型安全と DI（依存性の注入）による秩序を最優先しています。
技術的な特徴は次の通りです。
- API は GraphQL のみ（Shop API + Admin API）、スキーマ駆動開発（Schema-first Development）を強く推進
- ORM は TypeORM で、PostgreSQL / MySQL / MariaDB / SQLite に対応（TS コマースとしては珍しいマルチ DB 対応）
- プラグインシステムは NestJS Module を拡張したもので、サードパーティの NestJS ライブラリをそのまま組み込める
- 2025 年に React + TanStack + shadcn/ui ベースの新ダッシュボードへ全面リニューアル
- マルチチャネル、多通貨、多言語、多税ゾーン、RBAC を標準で持ち、Asset 翻訳、ProductOption の共有、チャネル化など、エンタープライズ要件を継続強化
- 公式 Next.js ストアフロントが公開ロードマップに掲載されており、提供準備が進んでいる（Remix / Qwik / Angular の公式スターターはすでに揃う）
ライセンスは 2.x 期に MIT から GPLv3 へ移行しました。SaaS 提供のみ（ASP 境界内）であれば通常コード公開義務は発生しませんが、コア改変版を「配布」する形態には、コピーレフトの伝播が発生します。リスクを下げたい組織向けには、有償の Vendure Commercial License（VCL）と Vendure Platform（LTS / SLA）が用意されています。
Vendure の導入事例
IBM 社内の Project Marlin では、レガシーシステムを Vendure に置き換えて変更リードタイムが数週間 → 数時間まで短縮されています。ハンガリーの Munch は 1 日 10,000 トランザクション、月間 350,000 アクティブユーザのマーケットプレイスを Vendure 上で運営しており、スタートアップから大規模まで通用するスケーラビリティを実証しています。
2025 年通年では、5 つの minor（v3.2〜v3.6）と 20 件以上の patch、400 件のマージ済み PR、62 名の新規コントリビュータと、コミュニティのモメンタムも継続中です。直近では languageCode クエリ経由の SQL Injection 脆弱性（PostgreSQL tsquery 起因） が責任ある開示によって発見され、v3.6 系および旧バージョンへ後方互換でセキュリティパッチが提供されました。月次レベルでのアップデート追随が前提になる点は Medusa と同様です。
EverShop — TypeScript / Express / React の一体型
EverShop は、TypeScript + Express + React + GraphQL + PostgreSQL で構成された、比較的理解しやすい一体型アーキテクチャの OSS です。リポジトリは evershopcommerce/evershop、ライセンスは GPL-3.0、TypeScript は 5.8.3 系で構築されています。
設計上の特徴は次の通りです。
- 商品、カテゴリ、コレクション管理、在庫表示、カート / チェックアウト、決済連携、注文管理、テーマ、拡張、マーケットプレイス機能、翻訳システムまでコアでカバー
- REST API と GraphQL API を両方提供、フロントは React + Tailwind CSS + Webpack で実装
- 公式デプロイガイドが AWS など主要環境向けに用意され、Node.js 20+ / PostgreSQL 13+ / 最小 2 core / 2 GiB RAM / 10 GB が公式の最小要件
- 公式 docs に Installation、REST/GraphQL API、Theme、Extension、Translation、Deployment Guide が整備されている
Medusa や Vendure と違い、ストアフロント、管理画面、API が同じプロジェクトに同梱されています。「ヘッドレス基盤 + 別途ストアフロント」のような分離設計を取らない分、立ち上げ初速は最も速く、セルフホスト型の D2C で「とりあえず動かしたい」段階に向いています。
一方で、多通貨、大規模マルチチャネル、複雑な B2B 要件についての一次情報は Vendure ほど厚くなく、Medusa のような Workflows SDK や Module Isolation に相当する高度な拡張性も持ちません。エコシステムの厚みも Medusa / Vendure に劣り、公開リポジトリ上に明確な SECURITY.md は 2026 年 5 月時点では確認できません。将来の複雑性が想定される案件では、PoC 段階で深さを必ず確認するのが安全です。
ライセンスが GPL-3.0 である点は Vendure と同じく、コピーレフトの伝播に注意が必要です。SaaS 提供のみであれば通常義務は発生しませんが、コア改変版を「配布」するモデルでは法務確認のステップを最初から織り込んでおきます。
ライセンスの違いが選定の最初の分岐になる
技術比較の前に、ライセンスでチームが Yes / No を出せるかで大半の候補は最初の篩にかかります。
| ライセンス | 候補 | 商用組み込み、SaaS 化への影響 |
|---|---|---|
| MIT | Medusa | 派生物の非公開可。法務確認が最も軽い |
| GPLv3 | Vendure、EverShop | コア改変版の配布にコピーレフト伝播。SaaS 提供のみなら通常義務なし |
特に GPLv3 の Vendure や EverShop を SaaS の中で動かす ケースは、コードを「配布」しているのかどうかの法的解釈が論点になります。SaaS の提供形態（マルチテナント、シングルテナント、オンプレ納品）と、フォーク改変の方針、商用ライセンスの取得可否を初期で整理しておくと、選定後の手戻りを抑えられます。
アーキテクチャと拡張モデルの違い
3 候補はいずれも「モジュラー化」「拡張可能」を掲げていますが、その粒度と拡張モデルは大きく違います。
| 観点 | Medusa v2 | Vendure v3 | EverShop |
|---|---|---|---|
| モジュラリティ | 17 モジュールが DB 依存ゼロ、Standalone 運用可 | NestJS Plugin / Module による伝統的モジュラーモノリス | 一体型、Extensions による拡張 |
| 拡張ポイント | Modules / Workflows / Plugins / UI Widgets / API Routes | NestJS Plugin / Interceptor / Custom Field / Strategy Pattern | Extension / Theme / Translation |
| イベント駆動 | Workflows SDK（リトライ、ロールバック付き） | OrderInterceptor API などの細粒度フック | コアレベルでの拡張は限定的 |
| 多言語、多通貨 | 標準（Region / Currency / Translation Module、Translation は Beta） | 標準（マルチ税ゾーン、Asset 翻訳） | 翻訳システムあり、多通貨は要追加検証 |
| サーバレス親和性 | 弱（長寿命 Worker 前提） | 弱（NestJS 前提） | 弱（モノリス前提） |
「プロダクトの心臓部を完全に握りたい」なら Medusa の DB 依存ゼロ、Module Isolation が魅力で、「型安全な独自業務ロジックを長期で組み続けたい」なら Vendure の DI とプラグインシステムが効きます。「少人数で素早く立ち上げ、運用も一枚岩で扱いたい」なら EverShop の一体型構成が最も初速を出しやすい構図です。
フロントエンドの標準は Next.js App Router + RSC + PPR
フロントエンド側の潮流は、3 候補で見るとほぼ収束しています。
- Medusa Next.js Starter: Next.js App Router 採用済み、安定運用に振った構成。v2 と同時に B2B 用などを含む 5 種類のスターターを提供
- Vendure: 公式スターターは Remix / Qwik / Angular。Vendure 公式 Next.js ストアフロントも公開準備が進行中
- EverShop: コア同梱の React + Tailwind ストアフロントを使用するか、別途 Next.js などでヘッドレス化（REST/GraphQL API を叩く）するかを選択
つまり、Next.js App Router + React Server Components + Server Actions + Cache Components（Partial Prerendering） が事実上の業界標準で、Medusa はすでに、Vendure も近々これに追随します。Next.js 16 系の Adapter API v16.2 stable により、Vercel 以外（Cloudflare、Netlify 等）への移植性も上がっています。
AI / Agentic Commerce 対応で 2026 年の差がついている
「商品推薦」「AI 検索」だけではなく、AI エージェントが顧客の代理で商品を比較し、在庫を確認し、最適な決済手段を選択して購入を完了させる という Agentic Commerce が、2026 年の新しい評価軸になりつつあります。OSS EC 側もここに合わせて動いています。
- Medusa: 公式が “Open-Source Commerce Platform for Agents and Developers” を打ち出し、MCP サーバ、Development Agent、Cloud CLI、Bloom アシスタントを提供。AI 経由でのスキーマ更新、データ生成を組み込みやすい
- Vendure: GraphQL の厳密な型システムが、AI エージェントによる API 呼び出しの正確性を支える基盤になる。Agentic 向けの公式機能は Medusa よりも限定的だが、スキーマファーストの設計と OrderInterceptor API は機械可読性の高い拡張ポイントとして有効
- EverShop: 現状は Agentic 視点での専用機能は限定的。REST/GraphQL API を経由した一般的な統合が中心になる
AI エージェントが信頼性高く動作するための API 設計（厳格な構造化、機械可読、明示的状態遷移） が、新たな選定基準として加わりつつあります。Agentic 視点でロードマップを引きたいなら、現時点で最も土台が厚いのは Medusa です。
Reaction Commerce ディスコンの教訓
OSS EC で必ず話題に上がる教訓が、Reaction Commerce（後の Mailchimp Open Commerce）のディスコンです。2026 年現在、GitHub リポジトリの説明文に “Project has been discontinued” と明示され、サテライトリポジトリも更新停止状態にあります。
失敗の要因は概ね 3 点に集約されます。
- Meteor と MongoDB という当時の先進的だが後に主流から外れたスタックに依存し過ぎ、現代の TypeScript / PostgreSQL エコシステムへの移行が遅れた
- 2020 年に Mailchimp が買収、Open Commerce にリブランドしたが、親会社の戦略変更で開発が凍結された
- Medusa / Vendure などが PostgreSQL / NestJS / GraphQL といった現代的プラクティスを掲げて開発者の支持を奪った
ここから引ける実用的な教訓は、ライセンス、母体企業、資金調達、コミュニティ規模、リリース頻度を技術選定の最重要 KPI として継続評価すること、そして「特定ベンダーへの依存度」と「採用している技術が業界標準に近いか」を厳格に評価することです。Medusa の MIT、Vendure の NestJS は、いずれも「主導組織に変化があってもコミュニティ、企業が自律的に開発を続けられる」可能性を高める要素として効いてきます。EverShop はチーム規模、コミュニティ厚みの両面で Medusa / Vendure に劣るため、Bus factor の観点を含めた PoC を進めるのが安全です。
ユースケース別の選び方
ここまでの整理を、実務の判断フローに落とします。
flowchart TD
A[要件整理] --> B{ライセンスは<br/>MIT 必須か}
B -- MIT 必須 --> M1[Medusa v2]
B -- GPLv3 も可 --> C{エンタープライズ要件<br/>（B2B / マルチチャネル<br/>/ 厳格な型）か}
C -- はい --> V[Vendure v3]
C -- いいえ --> D{素早い一体型立ち上げを<br/>最優先するか}
D -- はい --> E[EverShop]
D -- いいえ --> M2[Medusa v2]
判断の中身を、ユースケースごとに整理します。
革新と敏捷性を重視する D2C、スタートアップ
Medusa v2 が第一候補です。MIT ライセンスによる自由度、v2 で強化された Workflows SDK による複雑なロジックの安全性、Decoupled Module Architecture による段階的導入、そしてコミュニティの勢いが揃っています。Medusa Cloud（$29/月〜、GMV 連動手数料なし）を選べばマネージドにも乗れます。
品質、秩序、長期保守性を重視するエンタープライズ
Vendure v3 が最適です。NestJS の厳格なアーキテクチャ、GraphQL による型安全なデータ提供、TypeORM のマルチ DB 対応、IBM の Project Marlin など実績のあるスケーラビリティが、複数年運用における技術的負債の蓄積を抑えます。GPLv3 のリスクが組織として許容できない場合は、Vendure Commercial License（VCL）と Vendure Platform で SLA とエンタープライズ機能（SSO、監査ログ等）を取得する設計が現実解です。
AI / Agentic Commerce を視野に入れる
Medusa です。MCP サーバ、Development Agent、Cloud CLI が揃っており、Agentic Commerce 視点でロードマップを引くなら現時点で最も土台が厚い選択肢になります。Vendure は GraphQL の厳密な型を活かす方向で進化していますが、Agentic 向けの専用機能は Medusa よりも限定的です。
軽量に立ち上げたい、SaaS 並みの統合体験を求める
EverShop が候補です。TypeScript / Express / React / GraphQL / PostgreSQL で、商品、注文、チェックアウト、決済、テーマ、拡張、翻訳まで一体型でまとまっており、セルフホスト型 D2C を素直に立ち上げやすい構成です。多通貨、複雑 B2B 要件は Vendure ほど厚くないため、将来の複雑性が想定される場合は PoC で深さを確認するのが安全です。
新規で Reaction Commerce 採用を検討中
採用しないこと。既存運用があれば、Medusa / Vendure / EverShop のいずれかへの移行プロジェクトとして計画するのが現実解です。
採用前のチェックリスト
PoC や本番採用の前に、最低限埋めておくべき項目を並べておきます。
- ライセンス適合性: MIT 必須か、GPLv3 を許容できるか。社内プロダクト、受託、OEM、SaaS 組み込みのどれで使うかで重さが変わる
- 国際化要件: 多言語、多通貨、複数在庫拠点、税制差分。Vendure が一次情報の厚さで先行、Medusa も Region / Currency / Translation Module を持つ（Translation は Beta）
- 注文 / 在庫 / 支払の複雑さ: 複雑 OMS や独自フローなら Medusa か Vendure、標準的 D2C なら EverShop も初速が出やすい
- インフラ責務: Medusa は PostgreSQL + Redis + worker 分離を意識した設計、Vendure は小さく始めて負荷時に水平スケール、EverShop は PostgreSQL 前提の一枚岩
- セキュリティ運用: 脆弱性報告窓口、対応バージョンポリシー、production hardening、env / secrets 管理を明文化。EverShop はリポジトリ上の明確な SECURITY.md が薄いため、運用ルールでカバーする
- 負荷試験計画: 公式が server / worker 分離や水平スケールを推奨しており、PoC 段階から性能計画を外さない
- 出口戦略: 将来 SaaS へ寄せるか、OSS で長期運用するか、フロント / バックを分離し続けるかを最初に決める
まとめ
2024〜2026 年は 「TypeScript ネイティブの OSS EC が Composable Commerce の中で位置を確立した時期」 で、Reaction Commerce のような有力候補がディスコンになる中で、プロジェクトの事業継続性（ライセンス、母体企業、資金調達、コミュニティ規模、リリース頻度）を技術選定の最重要 KPI として継続評価する ことが、これまで以上に重要になっています。
スタートアップ、中堅企業の JS / TS チームには Medusa v2、複雑 B2B、型安全派には Vendure v3（GPLv3 を法務承認できれば）、軽量に立ち上げたい一体型なら EverShop という棲み分けが 2026 年時点の最適解です。フロントエンドは Next.js App Router + React Server Components + Server Actions + Cache Components (PPR) が事実上の業界標準となり、各バックエンドの公式または準公式ストアフロントがこれに追随しています。次の差別化軸は Agentic Commerce 対応 であり、MCP、構造化 API、AI エージェント向けスキル同梱がプラットフォーム選定の新たな評価基準になりつつあります。
以上、TypeScript 製 OSS EC プラットフォームの 2026 年地図を、現場からお送りしました。