Headless Commerce（ヘッドレスコマース）

ヘッドレスコマースは、買い物客が見る画面と、商品・在庫・注文・決済を扱うコマース機能を切り離す構成を指す。切り離される「ヘッド」は画面のほうで、コマース機能はAPI越しに使う。

Shopifyの場合、商品や在庫、注文、そしてチェックアウトはShopifyに残る。切り替わるのはストアフロントの実装だけで、テーマの代わりに自前のWebアプリケーションを置き、Storefront API からデータを取得して描画する。ログイン後のマイページを作るなら Customer Account API を使う。

「ヘッドレスにする」と何が変わるのか

チェックアウトが常にShopify側に残るのは重要な点で、決済とPCI準拠の範囲はヘッドレスにしても自社に降りてこない。

実装の選択肢

Shopify純正の Hydrogen と Oxygen を使う道と、Next.js や Nuxt、Astro のような汎用フレームワークで組む道がある。コンテンツ量が多いサイトでは、商品以外の情報をヘッドレスCMSに持たせて組み合わせる構成もよく採られる。

何のために選ぶのか

採用理由はおおむね4つに整理できる。ブランド体験を細部まで作り込みたい。商品以外のコンテンツが多く、CMS主体でサイトを設計したい。Web以外のチャネルからも同じコマースデータを使いたい。表示速度や実装の制御を自分たちで握りたい。

いずれも「テーマの枠組みの中では難しいこと」が動機になっている。逆に言えば、その難しさが実在しないならヘッドレスにする理由もない。

引き換えに増えるもの

ヘッドレスにすると、これまでShopifyが引き受けていたフロントエンドの責任が自社に移る。ビルドとデプロイ、ホスティング、監視、SEOやアクセシビリティの担保、APIバージョンの追随が、継続的な運用項目として増える。

見落とされやすいのがアプリの扱いで、テーマに差し込む形のアプリ（Theme App Extension）はヘッドレスのフロントには載らない。同等の機能が必要なら、APIで連携するか自前で実装することになる。運用コストと複雑性が上がるというトレードオフは、この具体の積み重ねを指している。

日本での構成例

国内でもヘッドレスのShopifyストアは動いている。公開されているサイトから確認できる範囲で、構成はそれぞれ異なる（2026年9月時点）。

3つとも背後はShopifyだが、フロントの作り方は揃っていない。ヘッドレスという言葉が指すのはあくまで分離の方針であって、特定の技術構成ではない。Hydrogenを使うかどうかも、その中の選択肢のひとつになる。

選ばない判断も同じだけ重要

Online Store 2.0 のテーマは、セクション単位の編集やアプリの組み込みを含めて、かなりの要件をカバーする。テーマで足りる要件にヘッドレスを持ち込むと、得られる自由度より運用の負担のほうが大きくなる。

当社のコーポレートサイト（このサイト）自体が、Hydrogen と Oxygen で構築したヘッドレス構成になっている。用語集を含むコンテンツはSanityで管理し、商品や記事のデータはShopifyから取得している。提案する構成を自社の運用でも使っている状態で、移行の判断からデプロイ、監視までを継続的に扱っている。

クライアントには、ヘッドレスにすべきか Online Store 2.0 のテーマで十分かを、要件・規模・運用体制から整理して提案する。テーマで足りる案件にヘッドレスを勧めないことも含めて判断基準を持っている。Hydrogenの実際の利点と難しさは、自社サイトを作り直した経験としてコラムにも書いている。