---
title: "microCMSとShopifyを連携したECサイト構築｜ヘッドレス構成・費用・API制限の実務"
url: "https://www.issoh.co.jp/column/details/2342/"
published: 2024-06-04
updated: 2026-10-19
categories: ["EC"]
publisher: "株式会社一創"
---

# microCMSとShopifyを連携したECサイト構築｜ヘッドレス構成・費用・API制限の実務

microCMSとShopifyの連携は、「Shopifyの管理画面だけではコンテンツを作り込めない」という詰まりから検討が始まります。ただし、記事や特集ページを足したいだけならShopify標準の機能で足りることも多く、ヘッドレスCMSを重ねた瞬間に運用が二重化します。ここでは、Shopify単体の守備範囲とmicroCMSを足す判断基準、Storefront APIを使った構成、microCMS・Shopify双方のAPI制限、料金の内訳までを、実装前に決めておくべき順で整理します。数値と仕様は2026年8月7日時点の公式ドキュメントで確認したものです。

## まとめ

- 商品はShopify、記事はmicroCMSに置き、両者は**Shopifyの商品IDだけで紐付ける**。商品名や価格をmicroCMSへ複製すると管理画面の更新とずれます。
- Storefront APIにリクエスト数のレートリミットはありません（全プラン「None」）。制約側になるのは**microCMSのレートリミット（GET 60回/1秒・WRITE 5回/1秒）**と、Shopifyの**APIバージョン12か月サポート**です。
- 費用はmicroCMSがHobby 0円／Team 4,900円〜／Business 75,000円〜（税抜）。Shopify側の月額とフロントのホスティングが別に積み上がります。
- 決済画面はShopifyがホストするため、フロントとチェックアウトで計測が分断されます。sitemap・robots・構造化データも自前実装になります。
- ブログとお知らせを載せたいだけなら、microCMSを足さずShopifyのブログとメタオブジェクトで完結させたほうが運用は軽くなります。

以下、判断基準・構成・制限・費用・落とし穴の順に、具体的な数値とともに見ていきます。

## Shopifyだけでできるコンテンツ管理と、microCMSを足す判断基準

### Shopify標準で扱えるコンテンツ｜ブログ・ページ・メタオブジェクト

Shopifyには商品・コレクションのほかに、オンラインストアのブログと固定ページがあり、さらにメタフィールドとメタオブジェクトで独自のデータ構造を持てます。メタフィールドは既存リソース（商品や顧客）に単一の項目を足す仕組み、メタオブジェクトは複数の関連フィールドをまとめた独立したデータ型で、公式ドキュメントではサイズチャート、著者プロフィール、原材料リスト、保証情報などが例示されています。メタオブジェクトは定義（スキーマ）を作ってからエントリーを追加する形式で、ハンドル・表示名・フィールド値と、有効化した場合の公開状態を持ちます。

つまり「記事を書く」「構造化した情報を商品に紐付ける」程度であれば、Shopify単体でも設計はできます。Shopify公式のヘッドレスフレームワークHydrogenのスケルトンにも、ブログ一覧・記事詳細のルート（`blogs.$blogHandle.$articleHandle.tsx`）が最初から含まれており、Shopifyのブログをそのままフロントに出せます。

### microCMSを足すべきケースと、足さないほうがよいケース

判断は「編集体制」と「コンテンツの型」で分かれます。microCMSを足す価値があるのは、編集者がShopify管理画面の権限を持たない、あるいは持たせたくない場合と、商品と独立した特集・インタビュー・ナレッジ記事を型を決めて量産する場合です。microCMSはAPIごとにスキーマを定義でき、レビュー機能は無料のHobbyプランから使えます。承認ステップを細かく分けるカスタムステータスはBusinessプラン以上です。

逆に、更新するのが月数本のブログとお知らせだけなら足さないほうが確実です。CMSを1つ増やすと、記事の公開フロー・権限管理・障害時の切り分けが二系統になり、フロントの再ビルドまで含めて運用コストが増えます。編集の担い手が同じ人であれば、Shopifyのブログとメタオブジェクトに寄せたほうが速く回ります。ヘッドレス構成そのものの向き不向きは[ヘッドレスコマースの仕組みと導入判断](/column/details/1326/)で、CMS側の比較軸は[ヘッドレスCMSと従来型CMSの違い](/tech/details/1317/)で整理しています。ヘッドレスにせず素のShopifyで組む場合の工程・費用・外注範囲は、[Shopify構築の進め方と4層で見る外注範囲の線引き](https://www.issoh.co.jp/column/details/17106/)にまとめました。

## 連携の全体構成｜Storefront APIとデータの持ち分け

### 商品はShopify・記事はmicroCMS、紐付けは商品IDのみ

実装の要は、どちらを正としてデータを持つかです。microCMS公式ブログが公開しているメディアEC構成では、microCMS側の記事コンテンツにShopifyの商品IDだけを保持し、表示時にStorefront APIで商品名・価格・画像を取得します。同記事は、商品情報そのものをmicroCMSに持たせるとShopify管理画面での更新と同期ずれが起き、運用が複雑になると明記しています。

この持ち分けにすると、価格改定やセール設定はShopify側の操作だけで全面に反映され、記事側は文脈（どの商品をどう推すか）だけを管理します。逆に「表示速度のためにmicroCMSへ価格をコピーしておく」といった設計は、セール開始時刻に旧価格が残る事故を招きます。

### HeadlessチャネルでのStorefront APIトークン発行と権限設定

Storefront APIを使うには、Shopify App StoreからHeadless（ヘッドレス）販売チャネルをインストールし、ストアフロントを作成してアクセストークンを発行します。発行されるのは公開用トークンと、認証付きアクセス用の非公開トークンの2種類です。取得できるデータの範囲は、管理画面のHeadlessチャネルからストアフロントを選び「Storefront APIの権限」を編集して絞り込みます。作業には対象ストアのスタッフ権限と、アプリと販売チャネルの権限が必要です。

制限として、**1ショップあたりのアクティブなストアフロントとアクセストークンは最大100**です。ステージング用・本番用・アプリ用と用途別に発行しても通常は上限に届きませんが、トークンをローテーションする運用では古いものを残し続けないようにします。フレームワークは限定されず、Hydrogen（Oxygenへの無料ホスティング付き）でもNext.jsやNuxtでも構いません。

## 更新反映の設計｜Webhookと在庫・価格の扱い

### microCMSのWebhookによる記事側だけの再ビルド

microCMSはコンテンツ更新時にWebhookを発火できます。静的生成（SSG）でフロントを作る場合、このWebhookでデプロイ先のビルドをトリガーし、記事の追加・修正を反映させます。記事数が増えると全ページの再ビルドは時間もコストもかかるため、更新されたコンテンツのパスだけを再生成するオンデマンド再検証（ISR）に寄せるのが実務的です。

注意すべきは、microCMSのWebhookが拾うのはmicroCMS側の更新だけという点です。Shopify側の商品更新を静的ページへ反映したい場合は、Shopifyのwebhook（商品更新イベント）も別に受ける必要があります。Shopifyのwebhookペイロードもレスポンスと同じ仕組みでバージョン管理され、`X-Shopify-Api-Version`ヘッダで実際に使われたバージョンを確認できます。

### 在庫・価格のランタイム取得｜ビルド時固定の回避

SSGだけで組むと、ビルド時点の在庫と価格がHTMLに焼き付きます。在庫切れ商品が「購入可能」と表示された状態でカート投入までは通り、チェックアウトで弾かれる導線ができあがるため、在庫・価格・セール情報はクライアント側またはサーバー側で都度Storefront APIから取得する設計にします。Storefront APIにはリクエスト数の上限がないため、呼び出し回数そのものは設計の制約になりません。ただしサーバー側から呼ぶ場合は後述のBuyer IPヘッダが前提条件になります。

カートの見積金額（`CartCost`）はあくまで概算で、最終価格はチェックアウトで確定します。国別に価格を出し分ける場合は、カート作成時の`buyerIdentity`や商品クエリの`@inContext`ディレクティブで国コードを渡す必要があり、これを省くと表示価格とチェックアウト価格がずれます。

## 実装前に確認するAPI制限とバージョン運用

### microCMS側の制約｜GET 60回/1秒・WRITE 5回/1秒とコンテンツサイズ

microCMSのコンテンツAPIは、1サービスあたり**GET APIが60回/1秒、WRITE API（POST・PUT・PATCH・DELETE）が5回/1秒**のレートリミットです。読み取りより書き込みが12分の1に絞られている点が重要で、Shopifyのwebhookを受けてmicroCMSへ書き戻す処理や、初回の一括インポートはこの5回/1秒に当たります。カウント対象はオリジンへのアクセスのみで、CDNのエッジキャッシュから返した分は含まれません。超過すると429が返り、レスポンスに`X-RateLimit-Limit`・`X-RateLimit-Remaining`・`X-RateLimit-Reset`が付きます。マルチテナント基盤のため、上限内でも稀に429や500番台が返る前提でリトライを実装しておくべきだと公式が明記しています。マネジメントAPI（ベータ）は別枠で、IPアドレスあたり10回/10秒です。

データ量側の制限も見落とされがちです。1コンテンツあたりのデータ量は約200KB（公式は、状態の持ち方によって2倍の約400KBまで保持できると案内しています）、最大レスポンスサイズは約5MB、最大レスポンスタイムは約29秒です。記事に大量の商品IDをぶら下げる設計や、絞り込み条件が複雑なクエリは、この上限に触れて500番台になります。

### Shopify側の実質的な期限｜APIバージョンの12か月サポート

ShopifyのAPIバージョンは日付形式（例: `2026-07`）で、四半期の初日にリリースされます。各安定版のサポートは最低12か月、隣接するバージョン同士は9か月以上重なる設計です。実際に2025-07は2026年7月16日15:00 UTCで利用できなくなりました。指定したバージョンが利用不可になるとShopifyは最も古い利用可能な安定版へフォールフォワードするため、リクエストは通り続けます。**止まらずに挙動だけ変わる**のが厄介で、年1回はバージョン更新を計画作業として組み込む必要があります。

| 項目      | microCMS コンテンツAPI      | Shopify Storefront API | Shopify GraphQL Admin API                    |
| ------- | ---------------------- | ---------------------- | -------------------------------------------- |
| レートリミット | GET 60回/1秒・WRITE 5回/1秒 | なし（全プラン）               | 100ポイント/秒（Standard）                          |
| プラン別の上限 | プランで変動なし               | Plus・Enterpriseも同じ「なし」 | Advanced 200／Plus 1000／Enterprise 2000ポイント/秒 |
| カウント単位  | 1サービス                  | —                      | アプリ＋ストアの組み合わせ                                |
| 超過時     | 429                    | —                      | スロットルエラー                                     |
| バージョン管理 | 四半期ごとの切り替えなし           | 四半期・最低12か月             | 四半期・最低12か月                                   |

Storefront APIはリクエスト数では制限されませんが、無条件ではありません。ボットやクローラーからの自動トラフィックは制限対象で、悪性と判定されると`430 Shopify Security Rejection`が返ります。サーバーサイドからAPIを呼ぶ構成では`Shopify-Storefront-Buyer-IP`ヘッダに購入者のIPを載せる必要があり、これを付けないと自社サーバーのIPに全アクセスが集中して制限側に倒れます。加えてチェックアウト作成には分あたりの別枠スロットルがあり、超えると`200 Throttled`が返るため、指数バックオフ付きのキューを用意しておきます。入力配列の要素は最大250件です。API制限を織り込んだ連携設計の考え方は、[ShopifyとkintoneのAPI連携における手段の選び方](/column/details/2341/)でも同じ論点を扱っています。

## 費用の内訳｜microCMSの料金プランとShopify側の追加コスト

microCMSの料金は以下のとおりです（税抜、2026年8月7日時点）。APIリクエスト数はどのプランも無制限で、実質的な上限になるのはデータ転送量とAPI数、コンテンツ数です。

| プラン        | 月額       | API数          | メンバー          | データ転送量         | コンテンツ数   |
| ---------- | -------- | ------------- | ------------- | -------------- | -------- |
| Hobby      | 0円       | 5             | 3人            | 20GB（超過でAPI停止） | 10,000件  |
| Team       | 4,900円〜  | 10（+2,000円/個） | 3人（+1,200円/人） | 200GB（+20円/GB） | 20,000件  |
| Business   | 75,000円〜 | 30            | 20人           | 1TB（+18円/GB）   | 50,000件  |
| Enterprise | 見積       | 50〜           | 50人〜          | 1TB〜（+16円/GB）  | 100,000件 |

検証環境はHobbyで足りますが、本番では転送量の性質に注意が必要です。Hobbyは20GB超過でAPIが停止する仕様のため、公開サイトで使うとアクセス集中がそのまま停止につながります。複数環境（開発環境）の分離、IP制限、カスタムステータスによる承認フローはBusinessプラン以上の機能で、ここが実質的な分岐点になります。

これに加えてShopifyの月額とフロントエンドのホスティング費が必要です。HydrogenをOxygenへデプロイする場合、ホスティング自体は追加費用なしで、継続的デプロイやプレビュー、即時ロールバックが含まれます。Next.jsなどを自前で運用する場合は、そのホスティング費と保守工数が別に乗ります。EC全体の構築費用をどう見積もるかは[ECサイト構築の5つの方法と費用相場](/column/details/15234/)を参照してください。

## ヘッドレス化で発生する運用の落とし穴｜チェックアウト・SEO・計測

### Shopifyホストのチェックアウトと決済導線の分断

ヘッドレス構成でも決済画面を自前で作るわけではありません。Storefront APIでカートを作成し、購入直前に`Cart`オブジェクトの`checkoutUrl`を取得して、そのURLへ遷移させます。公式ドキュメントが示すクエリとレスポンスは次の形です。

```
query checkoutURL {
  cart(id: "gid://shopify/Cart/Z2NwLXVzLWV4YW1wbGU6MDEyMzQ1Njc4OTAxMjM0NTY3ODkw?key=examplekey1234567890") {
    checkoutUrl
  }
}

# レスポンス例
# "checkoutUrl": "https://exam.myshopify.com/cart/c/29567c413f68cf5e8c1cb623954f3a28"
```

返るURLはShopifyのWebチェックアウトへのリダイレクト先です。公式は、セキュリティ上の理由から`checkoutUrl`は購入者がチェックアウトへ進む準備ができた時点で取得し、古くなっていれば取り直すよう案内しています。顧客アクセストークンをカートに設定しておくと、ログイン済みの状態でチェックアウトへ渡せます。ただしログイン状態を維持するには、サーバーサイドからの呼び出しで`Shopify-Storefront-Buyer-IP`ヘッダを付ける必要があります。

結果として、閲覧はフロントのドメイン、決済はShopify側という2つの領域にまたがります。フロントとチェックアウトでセッションが切れるため、計測と同意管理はこの分断を前提に設計する必要があります。checkoutUrlでの決済の受け渡しと、注文確定後のWebhook検証の実装は、[Shopify×Stripe連携の実装：Shopify ペイメントの仕組みとヘッドレス構成の決済設計](https://www.issoh.co.jp/tech/details/18547/)で解説しています。

### ヘッドレスECのSEO実装項目｜sitemap・robots・構造化データの自前実装

Shopifyのオンラインストアが自動生成していたsitemap.xmlやrobots.txtは、自前フロントでは提供されません。Hydrogenのスケルトンテンプレートには`[sitemap.xml].tsx`・`[robots.txt].tsx`・ページ分割用の`sitemap.$type.$page[.xml].tsx`が同梱されており、これが最低限そろえるべき出力の目安になります。他のフレームワークを選ぶ場合も、商品・コレクション・記事の各URLを網羅したsitemapと、商品の構造化データ（Product / Offer）は実装項目として最初から工数に入れておきます。

URL設計も要注意です。Shopifyのオンラインストアと自前フロントを併存させると、同じ商品が2つのURLで公開されて重複が生まれます。オンラインストアを閉じるか、パスワード保護またはcanonicalの向き先を決めてから公開すべきです。

### 計測側の制約｜Web Pixels APIの非バージョン管理

ヘッドレス構成でチェックアウトのイベントを取得する手段はWeb Pixels APIですが、これはShopifyが「非バージョン管理」に分類しているAPIです。Liquid、Ajax API、Storefront Web Components、Customer Privacy APIなども同じ扱いで、予告なく変更される可能性があります。四半期ごとにバージョンが切り替わるStorefront APIやAdmin APIと違い、変更時期を計画に織り込めないため、計測が壊れていないかを定期的に確認する運用を決めておく必要があります。

ここまでの制約を見て「Shopifyに乗ること自体が前提でよいか」を再検討したい場合は、TypeScript製のヘッドレスコマース基盤を比較した[VendureとMedusa JSの違い](/tech/details/1500/)も判断材料になります。

## よくある質問

### ShopifyだけでCMSとして使えますか？

ブログ記事、固定ページ、商品に紐づく構造化データであればShopify単体で管理できます。メタフィールドで既存リソースに単一項目を追加でき、メタオブジェクトでサイズチャートや著者プロフィールのような独自のデータ型を定義できます。編集者が数名でShopify管理画面を使える体制なら、これで足りるケースが多数です。逆に、Shopifyの権限を渡せない編集チームがいる、あるいは商品と無関係なコンテンツを型を決めて量産するといった要件が出てきたときが、ヘッドレスCMSを検討する境目になります。

### microCMSとShopifyの連携に必要なShopifyのプランは何ですか？

Storefront APIのレートリミットは公式ドキュメントの比較表でStandard・Advanced・Plus・Enterpriseのいずれも「なし」と記載されており、API利用の可否でプランが分かれる構造にはなっていません。必要なのはShopify App StoreからHeadless販売チャネルをインストールし、ストアフロントとアクセストークンを作成することです。作業者には対象ストアのスタッフ権限と、アプリおよび販売チャネルの権限が必要です。

### 商品データはmicroCMSとShopifyのどちらに持たせるべきですか？

Shopifyを正とし、microCMSにはShopifyの商品IDだけを持たせます。microCMS公式ブログのメディアEC構成もこの方式で、商品情報自体をmicroCMSに持つとShopify管理画面での更新と同期ずれが発生し運用が複雑になると明記されています。microCMS側が担うのは、どの商品をどの記事で、どの順番で、どんな文脈で見せるかという編集意図の部分です。

### 連携の費用はいくらから始められますか？

microCMSはHobbyプランが0円（API5個、メンバー3名、データ転送量20GB/月、コンテンツ10,000件）で、検証はここから始められます。ただしHobbyは転送量超過でAPIが停止するため、本番公開はTeam（4,900円〜/月、200GB/月）以上が現実的です。承認フローやIP制限、複数環境が必要ならBusiness（75,000円〜/月）になります。これにShopifyの月額と、フロントのホスティング費が加わります（HydrogenをOxygenへ載せる場合、ホスティングは追加費用なし）。

### ShopifyのAPIバージョンアップにはどう対応すればよいですか？

Shopifyは四半期ごとに日付形式の新バージョンをリリースし、各安定版を最低12か月サポートします。実例として2025-07は2026年7月16日15:00 UTCで利用できなくなりました。期限を過ぎるとエラーで止まるのではなく、最も古い利用可能な安定版へ自動的にフォールフォワードするため、気づかないまま挙動だけが変わります。レスポンスの`X-Shopify-API-Version`ヘッダで実際に使われたバージョンを確認し、リクエストで指定したものと差があれば更新時期だと判断してください。

## 関連記事

- [ヘッドレスコマースとは？仕組み・メリット・主要プラットフォームと導入判断【2026年最新】](/column/details/1326/)
- [ヘッドレスCMSとは？従来型CMSとの違い・主要サービス比較と選び方【2026年最新】](/tech/details/1317/)
- [ShopifyとkintoneのAPI連携｜手段の選び方・実現できることとAPI制限の設計【2026年版】](/column/details/2341/)
- [ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説](/column/details/15234/)
- [VendureとMedusa JSの違いを比較｜TypeScript製ヘッドレスコマースの選び方【2026年最新】](/tech/details/1500/)

---

出典: [microCMSとShopifyを連携したECサイト構築｜ヘッドレス構成・費用・API制限の実務](<https://www.issoh.co.jp/column/details/2342/>)（株式会社一創）