--- title: "ヘッドレスコマースとは？仕組み・従来型ECとの違いと主要基盤の比較、導入判断【2026年10月】" url: "https://www.issoh.co.jp/column/details/1326/" published: 2023-09-12 updated: 2026-10-11 categories: ["EC"] publisher: "株式会社一創" --- # ヘッドレスコマースとは？仕組み・従来型ECとの違いと主要基盤の比較、導入判断【2026年10月】 ヘッドレスコマースとは、ECサイトの画面（フロントエンド）と、商品・在庫・カート・決済・注文を扱う仕組み（バックエンド）を切り離し、APIでつないで作る構築方式です。画面を好きな技術で作れる代わりに、その画面を自社で作り、保守し続ける責任を負います。この記事では、APIで何をやり取りしているのかを実際のリクエストで示したうえで、従来型ECやヘッドレスCMSとの違い、Shopify Hydrogen・commercetools・Medusa・EC-CUBEなど10の基盤の比較、公表されている導入事例の数字、継続コストの内訳、そして導入すべき企業の条件を整理します。 ## まとめ：ヘッドレスコマースの要点 - **定義**：ECのフロントエンドとバックエンドをAPIで分離し、画面を独立して開発する方式です。バックエンドはAPIで商品やカートなどのデータを提供し、顧客向け画面の描画は分離したフロントエンドが担います。 - **従来型ECとの違い**：テンプレートの範囲で画面を作る一体型に対し、画面の技術（Next.js・Nuxt等）を自由に選べます。半面、画面の開発と保守がまるごと自社の仕事になります。 - **コストの正体**：初期開発に加え、APIの仕様変更に追随する継続的な保守工数が発生します。ShopifyのStorefront APIは3か月ごとに新版が出て、各版の保守期間は最低12か月です。 - **基盤選び**：既存がShopifyならHydrogen、大規模・多国展開ならcommercetools等の商用SaaS、自社でコードまで持つならMedusa・Vendure・Saleor、国内パッケージを使い続けるならEC-CUBEのWeb APIプラグインやecbeingのUNITEが候補です。 - **導入判断**：売上規模ではなく、フロントエンドを保守できる開発体制と、テンプレートでは満たせない要件があるかで決めます。どちらかが欠けるなら従来型のままが合理的です。 ## ヘッドレスコマースの仕組み 「ヘッドレス（headless）」は、頭（ヘッド＝顧客が見る画面）を持たない状態を指します。バックエンドが画面を描かず、APIでデータだけを返す構造からこの名前がつきました。 ### APIで商品データを取り出す流れ（Storefront APIの例） ヘッドレスのフロントエンドは、表示に必要なデータをその都度バックエンドへ問い合わせます。Shopifyの場合、窓口は[Storefront API](https://shopify.dev/docs/api/storefront/latest)というGraphQL APIで、エンドポイントは `https://{store_name}.myshopify.com/api/2026-10/graphql.json` の形式、認証は公開アクセストークンを `X-Shopify-Storefront-Access-Token` ヘッダーに載せます。商品を2件取り出すリクエストは次のとおりです。 ``` curl -X POST "https://{store_name}.myshopify.com/api/2026-10/graphql.json" \ -H "Content-Type: application/json" \ -H "X-Shopify-Storefront-Access-Token: {公開アクセストークン}" \ -d '{"query":"{ products(first: 2) { nodes { title handle priceRange { minVariantPrice { amount currencyCode } } } } }"}' ``` Shopifyが公開しているデモ用のStorefront API（[mock.shop](https://mock.shop)）での2026年10月11日の実測結果から、応答JSONのdata内を抜粋して示します。 ``` { "products": { "nodes": [ { "title": "Slides", "handle": "slides", "priceRange": { "minVariantPrice": { "amount": "25.0", "currencyCode": "CAD" } } }, { "title": "Sweatpants", "handle": "sweatpants", "priceRange": { "minVariantPrice": { "amount": "35.0", "currencyCode": "CAD" } } } ] } } ``` 返ってくるのは商品名と価格のデータだけで、HTMLもデザインも含まれません。このJSONをどう並べ、どんな画面にするかはフロントエンド側がすべて決めます。同じデータをWebサイト・スマホアプリ・店頭の端末のどれからでも呼べるので、1つのバックエンドを複数のチャネルで共有できます。これがヘッドレスの核心です。 ### 従来型（モノリシック）ECとの違い 従来型のECは、画面とバックエンドが一体で動く「モノリシック（一枚岩）」型です。ShopifyのLiquidテーマやASPカートの標準テンプレートがこれにあたり、テーマを選べばすぐ公開できます。Liquidテーマの構造は[Shopify Liquidとは？テーマ開発の構造・構文とShopify CLIでの始め方](/tech/details/12315/)で解説しています。違いを並べると次のようになります。 | 比較項目 | 従来型（モノリシック） | ヘッドレス | | --------- | ---------------- | ------------- | | 画面の作り方 | 基盤のテーマ・テンプレート | 任意のフレームワークで自作 | | 画面とデータの関係 | サーバーがHTMLを返す | APIがJSONを返す | | チャネル展開 | 基盤が提供する販売チャネルに対応 | Web・アプリ・店頭で共有 | | 公開までの速さ | 既存テーマで開発範囲を抑えやすい | 画面の実装範囲により変動 | | 保守の担い手 | 主に基盤ベンダー | 画面は自社か委託先 | ヘッドレスは表示の自由度を得る代わりに、画面を作り続ける責任を引き受ける方式です。この交換条件に加え、必要なAPI機能、既存アプリとの互換性、移行費用を確認して導入を判断します。 ### ヘッドレスCMS・コンポーザブルコマース・MACHとの関係 似た言葉が多いので、範囲で区別します。**ヘッドレスCMS**は記事やページのコンテンツ管理を画面から切り離したもので、扱うのはコンテンツです。商品・カート・決済を扱うヘッドレスコマースとは守備範囲が違い、実際の構成では両者を組み合わせることが多くなります。ヘッドレスCMSの仕組みと料金は[ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】](/tech/details/1317/)で比較しています。 **コンポーザブルコマース**は、バックエンド側もカート・検索・決済などの機能単位に分け、各機能の要件に合うサービスを組み合わせる考え方です。**MACH**はそれを支える設計原則で、Microservices・API-first・Cloud-native・Headlessの頭文字です。推進団体の[MACH Alliance](https://machalliance.org/insights-hub/mach-brand-refresh)は2020年に設立された非営利の業界団体です。ヘッドレスはMACHの1要素で、画面の分離だけを指すと覚えておけば混同しません。 ## ヘッドレスコマースのメリット・デメリット メリットは「画面の自由」に集約され、デメリットは「画面の責任」に集約されます。片方だけ見て判断すると失敗します。 ### メリット：画面の自由度・チャネル共有・表示速度 一番の利点は、テンプレートの制約を受けずに画面を設計できることです。商品の見せ方、検索の挙動、購入までの導線を、ブランドの要件に合わせて作り込めます。商品データは1か所に保ったまま、Web・アプリ・店頭端末へ同じデータを配れるので、チャネルごとにECを分けずに済みます。画面をサーバー側で描画しエッジから配信すれば、表示速度の改善も狙えます。検索・決済・CMSまで独立したサービスとして組み合わせるコンポーザブル構成では、各サービスの連携仕様が許す範囲で機能単位の差し替えも可能です。 ### デメリット：開発体制と運用負荷 画面の独自実装が増えるほど初期の開発工数も増えますが、既存のテンプレートや公式部品を利用すれば開発範囲を抑えられます。React・Next.jsやVue・Nuxtを扱えるエンジニアが社内か委託先に必要で、この体制が途切れると更新が止まります。障害が起きたときも、画面・API・バックエンドのどこが原因かを切り分ける手間が増えます。カートや会員ログインは採用基盤のAPI・公式部品を使って実装します。決済画面は基盤側のものを使える場合があり、ShopifyではカートのcheckoutUrlからShopifyのチェックアウトへ遷移させます。Hydrogenのように公式がカート・ログイン処理まで部品化している基盤を選ぶと、この負担は軽くなります。 ## 導入事例で見る成果の数字 ベンダーの公式事例ページで、ヘッドレス・コンポーザブル構成へ移行した企業が公表している数字を並べます。 | 企業（業種） | 採用基盤 | 公表された成果 | | ------------------ | ------------------------ | ---------------------------- | | Flügger（塗料） | commercetools | B2C移行後CVR 500%超向上・新ブランド構築3か月 | | CHRONEXT（高級時計） | commercetools | 表示速度300%向上・CVR 10%向上 | | Mizuno USA（スポーツ用品） | BigCommerce＋Contentstack | 自然検索流入33%増・決済時間90%短縮 | | White Stuff（アパレル） | BigCommerce | CVR 37%向上・セッション単価26%向上 | 出典は[Flüggerの事例](https://commercetools.com/customer-stories/flugger)、[CHRONEXTの事例](https://commercetools.com/customer-stories/chronext)、[Mizuno USAの事例](https://www.bigcommerce.com/case-study/mizuno-usa-headless/)、[White Stuffの事例](https://www.bigcommerce.com/case-study/white-stuff/)（いずれも各ベンダー公式）です。Flüggerは2万件超のAI生成ランディングページの展開も同時に行っています。 この数字を自社の見積もりにそのまま使うのは避けてください。いずれもベンダー自身が公表した比較で、White Stuffは旧・新基盤の並行稼働期間に計測した数値です。同時に進めたサイト刷新・商品ページの作り直し・広告施策の効果と切り分けられていません。古いシステムからの全面刷新なら、ヘッドレスでなくても速度やCVRは上がります。読み取れるのは「画面を自由に作り直せる構成にしたことで、こうした改善を短期間で実行できた」という点までです。 ## 主要ヘッドレスコマース基盤の比較 基盤は、運用をベンダーに任せる商用SaaS型、自社でホスティングするオープンソース型、国内ECパッケージのAPI対応の3系統に分かれます。版とライセンスは2026年10月11日時点で確認した値です。 | 基盤 | 系統 | 画面側の技術 | ライセンス・料金 | | ----------------------- | ------- | -------------------------- | ----------------- | | Shopify Hydrogen | 商用SaaS | React Router・Next.js・Nuxt等 | Shopify各プラン | | commercetools | 商用SaaS | 任意（API-first） | 個別見積もり | | Salesforce B2C Commerce | 商用SaaS | PWA Kit（React） | 個別見積もり | | BigCommerce | 商用SaaS | Catalyst（Next.js） | BigCommerce各プラン | | Medusa 2.21.2 | OSS | 任意（Next.jsの雛形あり） | MIT（一部Enterprise） | | Vendure 3.7.4 | OSS | 任意（GraphQL） | GPLv3または商用 | | Saleor 3.23.41 | OSS | 任意（GraphQL） | BSD-3-Clause | | EC-CUBE＋Web APIプラグイン | 国内OSS | 任意（GraphQL） | プラグインはLGPL・無料 | | EBISUMART Enterprise | 国内SaaS | 任意（API） | 個別見積もり | | ecbeing＋UNITE | 国内パッケージ | UNITE（専用CMS） | 個別見積もり | ### 商用SaaS型：Shopify Hydrogen・commercetools・Salesforce・BigCommerce Shopify Hydrogenは、Shopifyを裏側に使ったまま画面だけをヘッドレス化する公式のツールキットです。2026年10月9日に公開された[Hydrogen 2026.10.0](https://github.com/Shopify/hydrogen/releases)からは、React Routerに加えてNext.js・Nuxt・Astro・SvelteKitでも使える構成に変わり、「HydrogenはReact Router専用」という説明は古くなりました。カート・ログイン・検索・Shop Payボタンの部品がそろっていて、ホスティング先のOxygenは[Starter・Basic・Grow・Advanced・Plusなどの有料プランで追加料金なし](https://shopify.dev/docs/storefronts/headless/hydrogen/fundamentals)で使えます。すでにShopifyで売っている企業が最初に検討する選択肢です。 commercetoolsはAPI-firstを掲げる大企業向けの商用SaaSで、バックエンドを機能単位に分けて組み合わせる要件で選ばれます。SalesforceのB2C Commerceは、[Composable Storefront](https://developer.salesforce.com/docs/commerce/pwa-kit-managed-runtime/guide/getting-started.html)としてReact製の画面キットPWA Kitとホスティング基盤Managed Runtimeを提供しています。BigCommerceはNext.js製の画面キット[Catalyst](https://docs.bigcommerce.com/developer/docs/storefront/catalyst/release-notes/1-10-1)を主力にしています（運営会社は2025年7月31日に社名をCommerce.comへ変更し、製品名のBigCommerceは継続）。 ### オープンソース型：Medusa・Vendure・Saleor コードまで自社で持ち、自社サーバーで動かしたい場合はオープンソース型が候補です。Medusa（Node.js／TypeScript）は2026年9月28日公開の2.21.2が最新で、[コアはMITライセンス](https://github.com/medusajs/medusa)ですが、権限管理（RBAC）まわりのEnterprise Editionは商用契約が必要なオープンコア方式です。公式ホスティングのMedusa Cloudは[月額29ドルのDevelopから、Launch 99ドル・Scale 299ドル](https://medusajs.com/pricing/)で、流通額に応じた手数料はかかりません。日本での使い方は[MedusaでEC構築する判断基準｜構成・費用・日本対応の実態【2026年最新】](/column/details/4372/)にまとめています。 Vendure（TypeScript／NestJS）は3.7.4が最新で、[GPLv3と商用ライセンス（VCL）のデュアルライセンス](https://github.com/vendurehq/vendure/blob/master/LICENSE.md)です。個別契約がなければGPLv3が適用されるので、改変したコードの扱いを法務と確認してから採用してください。Saleor（Python／Django）は3.23.41が最新で、[BSD-3-Clause](https://github.com/saleor/saleor/blob/main/LICENSE)の制約の緩いライセンスです。TypeScript製の2つで迷う場合は[VendureとMedusa JSの違いを比較｜TypeScript製ヘッドレスコマースの選び方【2026年最新】](/tech/details/1500/)で機能と設計の差を比べています。 ### 国内ECパッケージのヘッドレス対応：EC-CUBE・EBISUMART・ecbeing 国内の既存基盤を使い続けたまま画面だけ切り離す道もあります。EC-CUBEは公式の[Web APIプラグイン](https://github.com/EC-CUBE/eccube-api4)（EC-CUBE 4.2・4.3系向けは4.3.2）で、GraphQLによるデータの取得・更新、OAuth 2.0による認可、Webhook通知を提供しています。プラグインは無料でLGPLです。インターファクトリーは大規模向けのEBISUMART Enterprise（旧ebisu commerce）で、[APIによるヘッドレスコマースに対応](https://www.interfactory.co.jp/item/2023%5F8%5F23.html)しています。ecbeingは会員・商品データをecbeingで管理し、画面を専用CMSの[UNITE](https://www.ecbeing.net/product/linkedservices/unite)で作る構成を用意しています。既存基盤の決済・配送・ポイント連携を再利用できる可能性があります。ただし、画面を切り離しても利用できるかは、各機能のAPI対応と連携条件の確認が必要です。 ## ヘッドレスコマースの費用：継続コストの内訳 構築費の相場は要件で桁が変わるため一律には言えません。見積もりで見落とされやすいのは初期費用ではなく、毎年かかる次の3つです。 - **基盤の利用料**：商用SaaSは月額か流通額連動です。例えばShopify Plusは[1年契約で月額398,000円、3年契約で月額368,000円](https://www.shopify.com/jp/plus/pricing)からです（Hydrogen自体は通常プランでも使えます）。OSSはライセンス料が不要な代わりに、サーバー・データベース・監視の費用と保守の人件費が自社持ちになります。 - **画面のホスティング**：Oxygen（Shopify有料プランは追加料金なし）、Vercel、Cloudflare、自社のNode.js環境など、画面を動かす場所の費用が別にかかります。 - **API版の追随**：最も見落とされる費用です。Shopifyは[3か月ごとに新しいAPI版を出し、各版の保守期間は最低12か月](https://shopify.dev/docs/api/usage/versioning)です。2026年10月1日公開の2026-10版は2027年10月16日で保守が終わります。期限切れの版を指定し続けると、Shopifyは利用できる最も古い安定版で応答するため、仕様変更が予告どおり画面に効いてきます。年に1回以上は、画面側のクエリを新しい版で検証し直す工数を見込んでください。 従来型との差額は、双方の基盤利用料・ホスティング費・保守開発費を同じ期間で見積もり、その差を取って比較します。初期開発費だけで比べると、毎年発生するAPI版の追随工数が見積もりから抜け落ちます。 ## ヘッドレスコマースの構築手順 導入すると決めても、いきなり全面移行するのは危険です。バックエンドから順に決め、範囲を絞って始めます。 ### ヘッドレスEC構築の工程と技術選定 1. 商品・在庫・決済・注文を担うバックエンド（コマースエンジン）を決める。既存ECがあれば、そのAPIで画面側に必要なデータが取れるかを先に確かめる。 2. 画面の技術を決める。社内に経験者がいるフレームワーク（Next.js・Nuxt等）を優先する。 3. Storefront APIなどで商品一覧・商品詳細・カートのデータを取得し、画面を組む。Shopifyならmock.shopで、ストアを用意する前に試作できる。 4. 検索・CMS・決済など外部サービスを組み込み、計測（アクセス解析・同意管理）を設定する。 既存ECがある場合は、特集ページやブランドサイトなど一部のチャネルだけを先にヘッドレス化し、表示速度・CVR・保守工数を測ってから広げると失敗が減ります。記事や特集のコンテンツだけをヘッドレスCMSに任せる部分適用なら、[microCMSとShopifyを連携したECサイト構築｜ヘッドレス構成・費用・API制限の実務](/column/details/2342/)がデータの持ち分けとAPI制限の実例になります。WordPressで記事を持っている企業は、[WordPressとReactの連携方法：ヘッドレス構成とテーマ組み込みの使い分け](/tech/details/2059/)の構成から入る手もあります。 ### 内製と外注の判断 内製か外注かは、画面を継続保守できる人が社内にいるかで決まります。初期構築だけを外注し、公開後のAPI版の追随や機能追加を担う担当者を決めていないと、必要な更新を続けられなくなります。外注するなら、公開後の保守担当、対応範囲、障害時の窓口を契約で定め、委託先を変える場合の引き継ぎ条件も明記してください。Shopifyを基盤にした構築と運用の相談は、[ECサイト制作・Shopify構築](/service/web/shopify/)で受け付けています。 ## 導入すべき企業・見送るべき企業 ヘッドレスコマースは「売上が大きくなったら移る」ものではありません。判断軸は売上規模ではなく、開発体制と要件の2つです。 **導入すべき**なのは、フロントエンドエンジニアを継続的に確保でき、かつテンプレートでは満たせない要件が具体的にある企業です。例えば、アプリと店頭端末で同じ商品データを使う、検索や絞り込みを独自の仕様で作る、多言語・多通貨のサイトを1つのバックエンドから出す、といった要件です。 **見送るべき**なのは、次のどれかに当てはまる企業です。 - 標準テーマとアプリの組み合わせで要件が満たせている - 画面を保守できる人が社内にも委託先にもいない - 「表示を速くしたい」が主な動機で、テーマの改善や画像の最適化をまだ試していない 保守担当が不在なら更新を続けられず、一体型への再移行が必要になる場合があります。標準テーマで要件を満たせる場合は、追加の開発・保守費に見合う効果を得にくくなります。まず従来型の範囲でどこまでできるかを確かめ、それでも残る要件が明確になってから基盤選定に進んでください。ECの構築方法全体の比較は[ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説](/column/details/15234/)、Shopifyの上位プランへ移るべきかは[Shopify Plusとは｜通常プランとの機能差と移行する売上規模の線引き](/column/details/18085/)で判断材料を示しています。 ## よくある質問 ### ヘッドレスとはどういう意味ですか？ 「頭（ヘッド）がない」という意味で、ECやCMSでは顧客が見る画面を持たない状態を指します。バックエンドは画面を描かずにAPIでデータだけを返し、画面は別の技術で作ります。 ### ヘッドレスコマースとヘッドレスCMSの違いは何ですか？ 扱う対象が違います。ヘッドレスCMSは記事やページなどのコンテンツを、ヘッドレスコマースは商品・在庫・カート・決済・注文を、画面から切り離して管理します。実際のECでは、商品はコマース基盤、特集記事はヘッドレスCMSという組み合わせがよく使われます。 ### Shopifyでヘッドレスコマースは実現できますか？ できます。公式のHydrogenを使えば、Shopifyの在庫・決済を使ったまま画面だけを自作できます。2026.10.0からはReact RouterのほかNext.js・Nuxt・Astro・SvelteKitでも使え、ホスティング先のOxygenは有料プランなら追加料金なしです。 ### ヘッドレスコマースの構築費用はどれくらいですか？ 要件で大きく変わるため相場は一律に示せませんが、比較すべきは初期費用より継続コストです。基盤の利用料、画面のホスティング費、API版の追随にかかる開発工数の3つを年単位で見積もってください。Shopifyのバージョン管理対象APIは3か月ごとに新版が公開され、各安定版は最低12か月サポートされます。 ### ヘッドレス対応とは何ですか？ EC基盤やCMSが、画面を使わずにAPI経由でデータを読み書きできる状態を指します。国内でもEC-CUBEは公式のWeb APIプラグイン（GraphQL）で、EBISUMART Enterpriseはebisumart APIで、ヘッドレス構成に対応しています。 ## 関連記事 - [VendureとMedusa JSの違いを比較｜TypeScript製ヘッドレスコマースの選び方【2026年最新】](/tech/details/1500/) - [MedusaでEC構築する判断基準｜構成・費用・日本対応の実態【2026年最新】](/column/details/4372/) - [ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】](/tech/details/1317/) - [ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説](/column/details/15234/) - [Shopify Plusとは｜通常プランとの機能差と移行する売上規模の線引き](/column/details/18085/) --- 出典: [ヘッドレスコマースとは？仕組み・従来型ECとの違いと主要基盤の比較、導入判断【2026年10月】]()（株式会社一創）