ヘッドレスコマースの仕組みとアーキテクチャ

Shopify APIの使い分けからシステム構成、導入時の考慮点まで、技術的な全体像を解説

ヘッドレスコマースアーキテクチャShopify APIStorefront APIAdmin API
読了時間: 10分

はじめに

ヘッドレスコマースの考え方は分かっても、「では裏側で何がどうつながっているのか」が見えないと、導入の判断も開発者との会話も難しいままです。全体像さえつかめば、個々の技術用語はぐっと理解しやすくなります。

この記事では、ShopifyとNext.jsで構成したヘッドレスECの仕組みを、2つのAPIの使い分け、データの流れ、導入時の考慮点の順に解説します。コードの書き方には踏み込まず、「何が何とつながっているか」という構成の話に絞ります。

2つのAPIを使い分ける

Shopifyには役割の異なる2つのAPI(システム同士がデータをやり取りする窓口)があり、ヘッドレス構成ではこの使い分けが土台になります。

Storefront API — ユーザー向けの窓口

ユーザーがWebサイト上で行う操作に使うAPIです。商品情報やコレクション(カテゴリ)の取得、カートへの追加、購入手続きの開始、会員のログインなどを担当します。データの問い合わせにはGraphQL(必要なデータだけをまとめて要求できる問い合わせ方式)を使います。

このAPIのアクセストークン(利用許可証のような文字列)は公開しても問題ない設計になっているため、ユーザーのブラウザから直接呼び出せます。

Admin API — 運営側の窓口

在庫数の更新、注文情報の管理、顧客情報の編集、割引コードの作成など、運営側の権限が必要な処理に使うAPIです。

こちらのアクセストークンは秘密にすべきもので、ブラウザには一切出しません。サーバー側(Next.jsのサーバー処理)からのみ呼び出す構成にします。

トークンの扱いが安全性を分ける

2つのAPIの違いは、「誰に開かれた窓口か」の違いでもあります。公開してよいトークンと秘密にすべきトークンを取り違えると、運営権限が外部に漏れることになるため、ここの区別だけは構成レベルで必ず守ります。逆に言えば、この原則さえ守れば、ヘッドレスでもShopifyの安全性をそのまま引き継げます。

システム構成図

Shopify (裏側 = データと決済の管理)
Storefront API (GraphQL)

商品・コレクション・カート操作・チェックアウト・顧客認証(公開トークン)

Admin API (REST/GraphQL)

注文管理・在庫更新・顧客管理・メタフィールド(秘密トークン)

フロントエンド(ユーザーが見る画面 = 複数チャネル)
Next.js Webサイト

Vercelでホスティング

モバイルアプリ

React Native

店頭端末 POS連携

タブレットアプリ

2つの図を一言でまとめると、「Shopifyが2つの窓口でデータを提供し、Webサイトやアプリなど複数の画面がその窓口を通じて同じデータを使う」構成です。

購入までのデータの流れ

ユーザーが商品を見つけて購入するまでに、裏側で何が起きているのかを3つの場面で追ってみます。

商品一覧ページの表示

商品一覧が表示されるまで
ユーザーがアクセス
商品一覧ページを開く
CDNが応答
作り置きしてあるページを即座に返す
表示完了
問い合わせを待たずにページが表示される

流れを一言でまとめると、「アクセスの時点ではもうページが出来上がっている」状態です。ページはあらかじめStorefront APIから商品データを取得して作り置きしてあり、ユーザーを待たせません。

商品をカートに入れる

カート追加の流れ
ボタンをクリック
「カートに追加」を押す
Storefront APIへ依頼
ブラウザから直接カートの更新を依頼
Shopifyが更新
カートの中身が更新され、画面に反映される

カートの中身は人によって違い、その場で変わるものなので、作り置きではなくAPIをリアルタイムに呼び出します。「共通のページは作り置き、個人ごとの操作はその場で問い合わせ」という使い分けです。

購入手続き(チェックアウト)

購入手続きの流れ
購入手続きへ進む
Storefront APIで決済ページのURLを取得
Shopifyの決済ページへ移動
カード情報はShopify側で入力
購入完了
決済はShopifyの安全な環境で完結

決済はShopifyが提供するページで行われるため、カード情報を自分たちのサーバーで扱う必要がありません。セキュリティ上の責任が最も重い部分を、専門のサービスに預けられる構成です。

鮮度と速度の両立、そして選択肢

ISRで作り置きを自動更新する

商品の価格や在庫は日々変わりますが、毎回APIに問い合わせていては表示が遅くなります。そこで使うのがISR(作り置きしたページを、決めた間隔で自動的に作り直す仕組み)です。ユーザーには作り置きの速いページを返しつつ、裏側で定期的に中身を更新する。更新頻度の高い商品ページは短い間隔、変化の少ないトップページは長い間隔、というようにページの性質に合わせて設定します。

Hydrogenという公式の選択肢

Shopifyは「Hydrogen」というヘッドレス専用の公式フレームワークも提供しています。Shopifyとの連携が密に設計されており、ゼロから新規に始めるプロジェクトでは有力な選択肢です。一方、既存のNext.jsの資産や知見がある場合、より広く使われているNext.jsで構築する選び方もあります。このプロジェクトでは後者を選びました。

導入前に確認しておきたいこと

体制と費用

フロントエンドを自分たちで持つ構成なので、React/Next.jsを扱える開発体制が必要です。近年はAIエージェント(AIによる開発支援)に指示を出しながら非エンジニアが構築を進める方法も現実的になってきました。費用面では、Shopifyの月額に加えて、Vercel(作ったページを載せておく置き場所)のホスティング費用と開発・保守の人件費を見込みます。開発期間は規模にもよりますが、最低でも1〜2ヶ月が目安です。

運用で増える作業

ShopifyとNext.jsの両方をメンテナンスすることになり、更新の反映(デプロイ)の仕組みづくりや、不具合が起きたときにどちら側の問題かを切り分ける作業も発生します。従来のテーマ運用より管理対象が増えることは、導入前に折り込んでおきたいポイントです。

まとめ

ヘッドレスコマースの仕組みは、「Storefront APIとAdmin APIという2つの窓口」「作り置きとリアルタイム問い合わせの使い分け」「決済はShopifyに任せる」という3点を押さえると全体像がつかめます。速度と自由度を得る代わりに、開発・運用の管理対象は増える。その両面を踏まえて、まずは小さな検証から始めるのがおすすめです。