Drupalを捨てたLushが、オープンソースのSaleorに賭けた理由

Saleorはポーランド発のオープンソース・ヘッドレスコマース基盤だ。

商品・在庫・注文・価格・プロモーションを単一のGraphQL APIで提供し、ストアフロントは自社で組める。

コードはBSD-3-Clauseで公開され、法人としてのSaleor Commerceは2020年に創業。

2021年に$2.5M、2024年2月に$8Mのシード拡張ラウンドを調達した。出典

Saleor Cloudは月間10億APIリクエスト超、GitHubスターは23,475に達している。出典

2013年、GitHubに置かれたコマースエンジン

SaleorのリポジトリがGitHubに公開されたのは2013年2月だった。出典

当時のコマース製品の多くは、管理画面とフロントエンドが一体のモノリスだった。

Saleorは最初からAPIを中心に据え、フロントを顧客のものにする道を選んだ。

この選択が10年後に効いてくる。

2020年の法人化と、2021年のシード

コードは2013年から公開されていたが、法人としてのSaleor Commerceがポーランドで生まれたのは2020年。

創業者はMirek MencelとPatryk Zawadzkiだ。出典

2021年には$2.5Mのシードを調達し、SaaSクラウドの提供を始める。

オープンソースで信頼を得て、運用で収益を立てる型がここで固まった。出典

Zalandoが投資した理由

2024年2月5日、Saleorは$8Mのシード拡張ラウンドを発表する。

共同リードはTarget GlobalとZalandoだった。出典

Mirek Mencelは当時こう述べている。

「We're thrilled to welcome Target Global and Zalando to the Saleor team. With the new capital, we'll further establish Saleor as the most composable, multimarket-ready platform available while keeping the dev community at the heart of what we do.」出典 資金の用途として挙げられたのは、成長、代理店プログラムの拡張、コア製品の強化だった。出典

LushがDrupalを捨てた日

最も重い説得材料は顧客の移行記録だ。

Lushは国ごとに独立したOpenCartのインスタンスを並べていたが、地域間の連携がなく、2014年の大型セールで障害を起こした。

その後、外部エージェンシーと組んで巨大なDrupalのコードベースを築くも、開発サイクルとコストに耐えられなくなる。出典

LushのSophia Rayneは「We had the largest Drupal codebase in existence, and we pushed it to its limits — we never managed to get through a Winter Holidays sale without it crashing.」と振り返っている。出典

コマースの標準機能だけをSaleorに任せ、業務固有のマイクロサービスは自社で持つ。

この分担が決め手になった。

2026年、エージェント経由の購買へ

2026年2月、SaleorはSOC 2 Type 2を取得し、同じ月にACP対応を含むAIネイティブのコマーススタックを発表した。出典 出典

検索が流入の入口だった時代から、エージェントが入口になる時代へ。

API-firstで作ってきたことが、そのまま次の入口への耐性になっている。

Saleorが刺さるのは、ECを「買って終わり」にできないチームだ。

複数国・複数チャネル・B2BとB2Cの混在など、標準機能の外側に業務があるほど、SaaSのテンプレートは壁になる。

Saleorは商品・在庫・注文・価格をGraphQLの単一APIで出し、フロントも業務フローも自社で組めるようにした。出典

化粧品大手Lushは、国ごとに分断されたモノリスと巨大なDrupalコードベースに限界を感じ、コマースのコアだけをSaleorへ移した。出典

つまり売れているのは機能数ではなく、業務の自由度と移行可能性だ。

moatはコードの可視性とGraphQLスキーマそのものにある。

スキーマは自己記述的で、外部の開発者もAIエージェントも構造を読んで安全に操作できる。出典

設定をConfiguratorでコード化できるため、移行後の乗り換えコストは「データ」より「手順」に宿る。

ネットワーク効果は中程度。

OSSのコントリビューターとパートナー代理店が増えるほど導入は速くなるが、コマース基盤は顧客同士がつながる製品ではない。出典

一方で、決済・ERP・3PLなど拡張アプリの蓄積は、後発が同じ体験を再現しにくくする。

月間の流通額が数億円以上で、複数国・複数ブランド・B2BとB2Cを1つのコアに寄せたい小売・ブランド。

自社にエンジニアか信頼できるSIerがいて、フロントエンドと業務フローを自分で設計したいチーム。出典

第一に、早い段階でAPI-firstとGraphQLを選び、フロントエンドを顧客のものにしたこと。

公式ドキュメントはGraphQLの全面採用を自社の起点として説明している。出典

第二に、オープンソース版とSaleor Cloudを分け、信頼はコードで、収益は運用で取る構造を作ったこと。出典

第三に、Lushのような大規模移行の事例を公開し、エンタープライズの説得材料として使っていること。出典

セルフホストを選ぶほど運用責任は顧客側に残り、PostgreSQLやワーカーの設計を誤るとコマース停止に直結する。

Cloudへ寄せるほどベンダー依存は強まり、オープンソースを選んだ理由と衝突しうる。

ARRや顧客数は非公開で、成長の実数を外部が検証できない点も導入判断の不確実性になる。

Magentoがそうであったように、OSSであってもアーキテクチャの負債化リスクはゼロではない。出典

成長は三段階。

まずOSSとGitHubで開発者に触れ、次にCloudで運用を引き受け、最後にパートナーとForward Deployed Engineeringで大規模移行を伴走する。出典

2024年にはZalandoが投資家として入り、マルチマーケットの共同開発という文脈を得た。出典

トレードオフは、伴走型の受託色が強まるほど、グロス・マージンと再現性が下がることだ。

主要チャネル: openSource, github, partners, discord, contentMarketing

「所有できる」ことを売りにした基盤は、規制・多国展開・買収といった変化に強い。課金をGMV連動にすると顧客の成長と売上が一致し、値上げ交渉を成長の話に変換できる。そしてエージェント対応はUIの追加ではなく、APIとスキーマの設計がそのまま効く。

日本では、大手小売の内製チームか、EC構築を担うSIerとのパートナー契約が現実的だ。

決済は国内PSP、税と与信は国ごとの要件が重いので、セルフホスト運用代行とCloudの中間のような提供が刺さる。

日本語の管理画面と監査対応を前面に出すと、稟議が通りやすい。