Shopifyからの移行戦略：ヘッドレスECの代替案を評価する

Shopifyは、その得意分野では非常に優れたサービスです。購入手続きのコンバージョン率は高く、アプリのエコシステムは充実し、運用の信頼性も高い水準にあります。インフラを構築せずに商品を販売したい事業者にとって、その価値は否定しがたいものです。当社がShopify上のストアを閉じた理由を説明する前に、この点を明確にしておく必要があります。Shopify自体の能力が不足していたのではなく、当社で積み重なった特有の運用要件に合わなくなったことが理由です。

「Shopifyからの移行」を語る記事の多くは、取引手数料、テーマの制約、独自のストアフロントへの要望に注目します。いずれも実際の理由ですが、最も重要な点ではありません。根本的には、Shopifyが大量販売、標準化されたカタログ、消費者への直接販売という特定の事業者像に最適化されており、要件がそこから外れると制約が負担になるという問題です。

Shopifyの優れていた点

Shopifyの価値を最も明確に示すのは購入手続きです。何百万ものストアで長年最適化を重ねた結果、購入につながりやすく、例外的なケースにも適切に対応し、市場ごとの決済手段を独自開発なしで導入できるフローになっています。同等の仕組みを一から作るには数か月を要し、その後も相当な保守負荷がかかります。

受注管理、フルフィルメント、返品、顧客対応ツールといった運用面も同様に成熟しています。管理画面には設計上の明確な方針があり、大規模なEC業務の実態に即した知見が反映されています。技術職以外のスタッフに受注管理を任せるチームにとって、ShopifyのUXは現在利用できるヘッドレス型の代替製品よりもはるかに扱いやすいものです。

アプリのエコシステムは、見えにくいコストがあると評される一方で、実際の課題を解決します。レビュープラットフォーム、定期課金、ロイヤルティプログラム、高度な分析が連携できるのは、外部アプリが依存するWebhook、データモデル、認証をShopifyが標準化しているからです。ヘッドレス構成では、それぞれの連携を独自開発するか、採用したプラットフォームを標準でサポートしているとは限らないベンダーから調達する必要があります。

移行の決め手となった制約

最初の障壁はi18nの制約でした。Shopifyの多言語対応は初期から大きく改善しましたが、英語圏以外の市場は依然として二次的な扱いです。管理画面で12言語のコンテンツを管理する運用負荷は、カタログが大きくなるほど増していきます。翻訳アプリは役立ちますが、追加費用と同期の複雑さが生じます。標準機能で対応できれば、こうした問題は避けられます。

時間とともに、より根本的な問題となったのはデータの所有権でした。注文履歴、顧客記録、商品カタログといった重要な運用データはすべてShopifyのデータベースにあり、Shopifyが管理するAPIを介してアクセスします。APIのレート制限、データ保持方針、エクスポート形式を決めるのは販売事業者ではなくShopifyです。自社の運用データを使って分析処理を実行したいチームにとって、これは設定で解消できる問題ではなく構造的な制約です。

3つ目の制約は価格モデルの複雑さでした。多数のバリエーションを持つ商品、顧客層別の独自価格、法人顧客向けの見積もりベースの業務フローは、Shopifyのバリエーション上限（1商品あたり100で、2025年10月にShopifyが2,048に引き上げ）や価格体系に抵触し、次第に複雑な回避策を必要とします。その結果、Liquidテンプレートが複雑化し、カタログの拡大に伴って保守上の負担が増していきます。

評価：Medusa v2、Saleor、Commerce.js

評価は4つの基準で行いました。データの所有権（データベースを完全に管理でき、ベンダーによるAPI制限がないこと）、i18nの対応範囲（複数通貨、多言語、地域別価格への標準対応）、開発者体験（ドキュメントの品質、TypeScript対応、ローカル開発の流れ）、運用面の成熟度（本番環境への導入実績、既知の障害パターン、コミュニティの規模）です。

Medusa v2は開発者体験で最も高い評価を得ました。v2での再設計は従来のアーキテクチャから大きく改善しており、モジュール構成はよく設計され、TypeScriptの型定義は網羅的で、ローカル開発も迅速に進められます。ドキュメントも大きく改善し、開発者体験を重視するチームの姿勢が表れています。制約は運用面の成熟度です。v2は比較的新しく（Medusa 2.0は2024年10月にリリース）、本番環境への導入事例は、歴史の長いプラットフォームほど多くも多様でもありません。Medusaへ移行するチームは、実質的に早期導入者となります。

Saleorは3製品の中で最も実績が豊富で、本番環境への導入数も多く、GraphQL APIも優れた設計です。市場、ストアフロント、顧客層ごとに「チャネル」を分けるマルチチャネル構成により、当社がShopifyを離れる原因となった価格とカタログの複雑さを、他の選択肢よりもすっきり扱えます。運用面の成熟度は評価した3製品で最も高い一方、習得には時間がかかり、GraphQLを前提とするAPIを効率よく使うにはツールへの投資が必要です。

Commerce.jsは位置づけが異なります。完全なECプラットフォームではなくヘッドレスAPIであり、単独で完結させるよりも、他のサービスと組み合わせることを想定しています。開発力があり、各構成要素を細かく制御したいチームには適しています。一方、Shopifyの運用負荷を減らしたいものの、別の形で同程度の開発負荷を抱えたくないチームには、おそらく合いません。ホスト型APIであるため、最初の評価基準であるデータベースの完全な管理権も得られません。また、2026年10月時点で、Commerce.jsの運営企業ChecはGitHub組織をアーカイブ済みです（2024年10月）。検討する前に、サービスの現在の状況を確認してください。

移行の進め方

プラットフォーム移行で最も過小評価されるのは、コードベースではなくデータの移行コストです。Shopifyから新しいプラットフォームへ商品カタログ、顧客記録、注文履歴を移すには、専用の抽出スクリプト、移行先スキーマに合わせたデータ変換、例外的なケースへの慎重な対応が必要です。100を超えるバリエーションを持つ商品、複雑な住所履歴を持つ顧客、一部のみ出荷済みの注文などは、記録全体では少数でも、移行の開発工数の大きな割合を占めます。

移行を検証しながら両方のシステムで注文を処理する運用切り替え期間には、出荷や顧客への連絡が重複しないよう慎重な計画が必要です。重要な例外ケースはEC全般に共通するものではなく、各事業者のカタログや注文履歴に固有のものなので、多くの移行で計画時に想定しなかった問題がこの段階で発生します。

今回の評価と、同様の判断に取り組む他社の経験から得た教訓は、プラットフォームの選択よりも移行計画の質が結果を左右するということです。MedusaとSaleorはいずれも本番のEC運用に対応でき、Commerce.jsも今回の評価時点では対応できていました。ヘッドレス構成への移行に成功するチームは、移行の途中ではなく、着手前にデータモデルの違いを理解するための時間を確保しています。

1つのサイトを数十言語に対応させる：ECのための実践的なi18n：Shopifyの標準ツールよりもヘッドレスプラットフォームで扱いやすいi18n要件。
Amazon出品者向けに本番環境で使えるデータ基盤を構築する：EC運用の基本原則としてのデータ所有権と、それに基づくインフラ構成。
効果につながるSEO修正：正規URL、サイトマップ、末尾のスラッシュ：プラットフォームとURL構造を同時に変更する際のSEO上の移行の注意点。