Shopify×Zapierで新規注文→Slack通知を実装する実務手順

2026年5月17日

DXの導入や効果にお悩みの担当者へ

スポンサードリンク

状況別に選べる

DXを前に進めたい、あなたの立場と目的は？

DXの推進には社内政治や人々のリテラシーなど組織の様々な壁が立ちはだかります。導入後も部署・全社のAIリテラシーを底上げしていき浸透させていく運用が重要です。目的に合った本を選びやり方を学ぶことでDXの成功と会社の成長をもたらすことができますよ。

▷ 硬直的な組織でDXを導入したいなら

【イノベーションOps　組織を動かすDX&AI導入プロセスのすべて】を購入する

机上の空論にならない実践的導入ができるようになります

▷ さらに様々な事例を学びAIリテラシーを底上げしたいなら

Kindle Unlimited をサブスクする

月額980円だけで読み放題。30日間無料なので、合わなければ解約してもOK

▶ その他では【AIエージェント時代のDX ビジネスオーケストレーションの衝撃】を購入する / 生成AIカテゴリーが参考になります。

Contents

1 導入前チェックリストと前提条件
2 Shopify認証とカスタムアプリ（Access Token取得と差分）
3 Zapier接続とZap作成 — 公式OAuthとカスタムアプリの違い
4 実務サンプル: 新規注文→Slack、Google Sheets、Admin API呼び出し例
5 運用設計・セキュリティ・トラブルシューティング
6 レート制限とスケーリング対策
7 代替手段の比較・コスト試算・導入後チェックリスト

スポンサードリンク

導入前チェックリストと前提条件

ShopifyとZapierで「新規注文→Slack通知」などを自動化する前に、権限・プラン・テスト環境・運用ルールを整えておくと導入後の手戻りを減らせます。ここでは導入前に必ず決めておく項目を実務目線で整理します。

必要なアカウントと権限

以下は実作業で最低限必要になるアカウントと権限です。管理者権限がないとアプリ作成やWebhook設定ができない点に注意してください。

Shopifyストア：管理者権限のアカウント（アプリ作成・インストールが可能）
Zapierアカウント：まずは無料で検証、運用はプランに応じて移行
連携先サービス（Slack、Googleアカウント、会計ソフトなど）
開発用ストア（ステージングや開発ストア）：本番データを検証に使わないこと

Zapierプラン別の制約

Zapierのプランにより利用可能な機能と制約が変わります。コストやリアルタイム要件を踏まえてプランを選んでください。

タスク課金：Zapの実行回数で課金されます。大量イベントはコスト増に直結します。
ステップ数：無料プランは単一ステップに制限される場合があります。マルチステップZapやPathsは有料プランが必要なケースが多いです。
トリガー方式：ポーリングトリガーはプラン毎にチェック間隔が異なります。即時性が必要ならWebhookベースの実装を検討してください。
公式情報：Zapierの料金・機能は公式ページで必ず確認してください（https://zapier.com/pricing）。

テスト環境の準備

テスト環境は本番の影響を避けるために必須です。ローカル検証方法も合わせて整備してください。

開発用ストアやステージングストアを用意し、ダミー注文で検証する。
ローカル検証にはngrokやlocaltunnel、webhook.siteなどを活用する（本番では必ずHTTPSかつ有効な証明書）。
テスト記録（ログ）はPIIが含まれないようにマスクして保存する。

接続方針の決定

接続方法の初期方針を決めると設計がぶれません。要件に応じて使い分けてください。

まずはZapier公式OAuth接続で素早く検証する。
標準機能で足りない場合、カスタムアプリ＋Webhook（またはZapierのHTTPアクション）でAdmin APIを直接叩く方針に移行する。

運用体制

誰が何を行うかを予め決めておけば障害時の初動が早くなります。以下を明確にしてください。

トークン管理者（誰がSecrets Managerを更新するか）
オンコール窓口（障害時の一次対応）
ログ/課金監視担当（Zapierのタスク数やAPI利用量を監視）
再発防止・権限変更の承認ルール

Shopify認証とカスタムアプリ（Access Token取得と差分）

ShopifyのAdmin APIへ接続する方法にはカスタムアプリ（ストア専用）と公開OAuthアプリ（複数ストア用）などがあり、トークンの性質や運用が異なります。ここでは種類ごとの特徴と取得・管理手順を実務的に示します。

Shopifyの認証方式（概観）

ShopifyのAdmin API接続は主に二つの方式があります。用途に応じて長期トークンとOAuthを使い分けてください。公式ドキュメントを必ず参照してください（https://shopify.dev/apps/auth）。

カスタムアプリ（Custom app）でのAccess Token

カスタムアプリは単一ストア向けで導入が簡単です。トークンは通常ストア側で発行され、明示的に取り消されるまで有効なことが多い点に留意してください（詳細は公式参照）。

作成手順（Shopify管理画面の表現は言語設定で異なります。英語例を括弧で示します）
Shopify管理画面に管理者でログインする。
サイドメニューで「アプリ（Apps）」を選ぶ。
「アプリを開発する（Develop apps）」または「管理者用アプリを開発（Develop private apps 等の表記に準ずる）」を選ぶ。
「アプリを作成（Create app）」を押し、アプリ名と連絡先を入力する。
「Admin API access scopes（アクセススコープ）」を設定し、必要最小限の権限だけ付与する。
「Install app（インストール）」してから「Reveal Admin API access token（Show token）」でトークンを取得する。
運用上の注意
トークンは表示されるのは一度きりの場合があるため、取得直後にSecrets Managerへ登録する。
トークンは平文でソース管理に残さない。Secrets Manager（AWS/GCP/Azure/HashiCorp Vault等）を利用する。
トークンのローテーション手順（例：6か月毎、インシデント発生時に即時）を定める。

公式のCustom appsや管理画面に関するヘルプ: https://help.shopify.com/en/manual/apps/custom-apps

OAuth（公開アプリ）のフローとトークン特性

公開アプリは複数ストアを対象とする場合に必要です。OAuthを使い、ユーザー認可でアクセストークンを取得します。OAuthでは「online」と「offline（長期））」というアクセスモードがあり、トークンの有効期間や更新方法が変わります。詳細はShopifyのOAuthドキュメントを参照してください（https://shopify.dev/apps/auth/oauth）。

公開アプリの要点
OAuthでストア管理者の同意を取り、コードを交換してトークンを取得する。
「offline_access」等のスコープで長期トークンを取得するフローがある（ドキュメント参照）。
トークンのリフレッシュや取り消しはアプリ側で実装・運用する必要がある。

OAuthの公式ドキュメント: https://shopify.dev/apps/auth/oauth

Private Appの廃止と移行

旧来のPrivate App（レガシー）方式は廃止対象となっており、移行が推奨されています。情報は公式ヘルプで確認してください。

移行ガイド（参考）: https://shopify.dev/apps/auth/legacy (最新の公式案内を参照のこと)

トークンの有効期限と取り消し手順（実務手順）

トークンが切れた・漏洩した場合の復旧手順を事前に文書化しておくことが重要です。

取り消し（一般的手順）
ストア管理画面で該当アプリをアンインストールまたはアプリ設定から認証情報を削除する。
Secrets Manager内の古いトークンを無効化/削除する。
新しいトークンを発行し、CI/CDや環境変数を更新してサービスを再起動する。
テスト注文で動作確認後、運用を再開する。
事前準備
トークン発行/差し替えの手順書（誰が何を行うか）を明文化する。
影響範囲（どのストア、どのZapが影響を受けるか）を把握しておく。

Zapier接続とZap作成 — 公式OAuthとカスタムアプリの違い

Zapier経由でShopifyと連携する場合、公式アプリ（OAuth）とカスタムアプリ＋Webhooks/HTTPの二軸で実装方針が変わります。目的に応じて選択し、作業手順と注意点を押さえてください。

公式OAuth接続の手順（実務向け）

公式接続は素早く試作する際に有効です。以下の手順で接続してテストします。

Zapierで「Make a Zap」を選択する。
トリガーアプリに「Shopify」を選び、イベント（例：New Order）を指定する。
「Connect an account」を選ぶとShopifyのOAuth画面が表示される（権限の同意を求められます）。
接続後に「Test trigger」でサンプルデータを取得してフィールド構成を確認する。
必要なアクション（Slack送信など）を追加してフィールドをマッピングし、テスト送信を行う。
Zapをオンにして挙動と課金を監視する。

カスタムアプリ＋Webhooks/HTTPの使い分け

より細かいAPI制御やGraphQLを使いたい場合、カスタムアプリでAccess Tokenを取得し、Zapierの「Webhooks by Zapier」や「Webhook/HTTP」アクションで通信します。Webhook受信はリアルタイム性に優れますが、署名検証など受信側の実装が必要です。

選択基準
リアルタイム性が必要：ShopifyのWebhookを使う
カスタム集計やGraphQLが必要：ZapierのHTTPアクションでAdmin APIを呼ぶ
Webhook受信の実務ポイント
受信URLは必ずHTTPSで有効な証明書を使用する（Shopifyの要件）。
HMAC署名（X-Shopify-Hmac-Sha256）を検証する実装を必須とする。

Zapierの機能制約と実務上の注意

Zapierのプランによる機能差は実運用に影響します。導入前に必ずプランと機能を確認してください。

一般的な差分（詳細はZapier公式で確認）
マルチステップZap、Paths、Delay、Storage、Formatterなどは多くの場合有料プランを要する。
ポーリング間隔はプランで短縮されるが、即時性はWebhookに依存する。
大量イベントはタスク消費が増えるため、バッチ化やキュー設計でコストを抑える。
公式参照（必読）
Zapier プラットフォーム／ドキュメント: https://platform.zapier.com/docs
Zapier 料金ページ: https://zapier.com/pricing

UI表記（英語⇔日本語）の整理

Shopifyの管理画面やZapier画面は言語設定で表記が変わります。以下はよく使う画面文言の対応例です。

操作（日本語）	操作（英語表記例）
アプリ（左メニュー）	Apps
アプリを開発する	Develop apps / Develop custom apps
アプリを作成	Create app
インストール	Install app
Admin APIアクセススコープ	Admin API access scopes
APIトークン（表示）	Reveal Admin API access token / Show token

管理画面で文言が見つからない場合は、類似するラベルを探し、操作前に説明文をよく読むことを薦めます。

実務サンプル: 新規注文→Slack、Google Sheets、Admin API呼び出し例

ここでは現場でそのまま使える手順やマッピング例、コード片を示します。画像は使わずテキストのみで操作手順と実装注意点を解説します。

新規注文→Slack（公式Shopifyトリガー）

公式Shopifyトリガーを使った最短で動くZapの作り方と、実用的なメッセージ例を示します。

Zapierで「Make a Zap」を作成する。
Triggerに「Shopify」を選び、イベントで「New Order」を選ぶ。
ShopifyアカウントをOAuthで接続し、「Test trigger」で注文サンプルを取得する。
Actionに「Slack」を追加し、「Send Channel Message」を選ぶ。
Slackアカウントを接続し、送信チャンネルを指定する。
メッセージ本文にフィールドをマッピングする（下記サンプル参照）。
必要ならFilterでテスト注文や低額注文を除外する。
テスト送信後、Zapをオンにして本番で監視する。

Slackメッセージ（プレーンテキスト）例（マスクの推奨あり）：

注文ID: {{order.id}}
合計: ${{order.total_price}} {{order.currency}}
顧客: {{customer.first_name}} {{customer.last_name}}（表示は必要最小限に）

顧客情報をSlackに送る場合は必ずマスキングを入れてください（氏名の省略、メールの部分マスクなど）。

Slack Block Kitの最小サンプル（マスク例）

以下はBlock Kit形式の最小例です。ZapierのSlackアクションでBlock JSONが使える場合に参考にしてください。

{
  &quot;blocks&quot;: [
    {
      &quot;type&quot;: &quot;section&quot;,
      &quot;text&quot;: {
        &quot;type&quot;: &quot;mrkdwn&quot;,
        &quot;text&quot;: &quot;*新規注文が入りました*\n注文ID: 12345\n合計: $100.00\n顧客: J*** D***\nメール: j***@example.com&quot;
      }
    }
  ]
}

{

"blocks": [

{

"type": "section",

"text": {

"type": "mrkdwn",

"text": "*新規注文が入りました*\n注文ID: 12345\n合計: $100.00\n顧客: J*** D***\nメール: j***@example.com"

}

]

}

マスキングの簡易例（JavaScript）:

function maskEmail(email) {
  return email.replace(/^(.).+(@.+)$/, '$1***$2');
}
function maskPhone(phone) {
  return phone.replace(/\d(?=\d{4})/g, '*');
}

function maskEmail(email) {

return email.replace(/^(.).+(@.+)$/, '$1***$2');

}

function maskPhone(phone) {

return phone.replace(/\d(?=\d{4})/g, '*');

}

Zapier内ではFormatterの「Replace」や「Extract Pattern」を使って同様のマスクを実装できます。

注文データ追記→Google Sheets（重複対策）

Google Sheetsへ追記する際の典型的な構成です。

Trigger：Shopify（New Order）またはWebhook（Catch Hook）
Action1：Google Sheets「Find Row」で注文IDを検索
条件分岐：Rowが見つからない場合のみ「Append Spreadsheet Row」で追記
失敗時：Zapierのタスクエラー通知をSlackに流す

このパターンでWebhook再送やZapの重複実行による二重登録を防ぎます。

商品・在庫の自動同期（考え方）

在庫更新は高頻度になり得ます。実務上は直接Zapierで個別同期するよりバッチ化や中間キューを推奨します。

Webhook（inventory_levels/update、fulfillments/update）でイベントを受信する。
受信したイベントを一時的にQueue（Redis、Pub/Sub、Storage）へ格納する。
定期バッチでまとめて外部倉庫/APIへ送る（まとめて呼ぶことでAPIコール数を削減）。

Shopify Admin APIのREST / GraphQL 例

RESTの注文一覧（cURL、プレースホルダを置換してください）:

curl -X GET &quot;https://{your-shop}.myshopify.com/admin/api/2024-10/orders.json?status=any&quot; \
  -H &quot;X-Shopify-Access-Token: &lt;ACCESS_TOKEN&gt;&quot; \
  -H &quot;Content-Type: application/json&quot;

curl -X GET "https://{your-shop}.myshopify.com/admin/api/2024-10/orders.json?status=any" \

-H "X-Shopify-Access-Token: <ACCESS_TOKEN>" \

-H "Content-Type: application/json"

GraphQLの簡易クエリ例（POST）:

curl -X POST &quot;https://{your-shop}.myshopify.com/admin/api/2024-10/graphql.json&quot; \
  -H &quot;X-Shopify-Access-Token: &lt;ACCESS_TOKEN&gt;&quot; \
  -H &quot;Content-Type: application/json&quot; \
  -d '{&quot;query&quot;:&quot;{ order(id: \&quot;gid://shopify/Order/12345\&quot;) { id name totalPrice } }&quot;}'

curl -X POST "https://{your-shop}.myshopify.com/admin/api/2024-10/graphql.json" \

-H "X-Shopify-Access-Token: <ACCESS_TOKEN>" \

-H "Content-Type: application/json" \

-d '{"query":"{ order(id: \"gid://shopify/Order/12345\") { id name totalPrice } }"}'

APIバージョン（例: 2024-10）はサンプルです。運用ではAPIバージョンの廃止スケジュールを定期的に確認してください（https://shopify.dev/concepts/about-apis/versioning）。

Webhook登録（REST）と注意点

WebhookをRESTで登録する例（アドレスはプレースホルダ）:

curl -X POST &quot;https://{your-shop}.myshopify.com/admin/api/2024-10/webhooks.json&quot; \
  -H &quot;X-Shopify-Access-Token: &lt;ACCESS_TOKEN&gt;&quot; \
  -H &quot;Content-Type: application/json&quot; \
  -d '{
    &quot;webhook&quot;: {
      &quot;topic&quot;: &quot;orders/create&quot;,
      &quot;address&quot;: &quot;https://your-receiver.example.com/webhook&quot;,
      &quot;format&quot;: &quot;json&quot;
    }
  }'

curl -X POST "https://{your-shop}.myshopify.com/admin/api/2024-10/webhooks.json" \

-H "X-Shopify-Access-Token: <ACCESS_TOKEN>" \

-H "Content-Type: application/json" \

-d '{

"webhook": {

"topic": "orders/create",

"address": "https://your-receiver.example.com/webhook",

"format": "json"

}

注意点：

受信URLはHTTPSかつ有効な証明書を必須とする。
ZapierのCatch Hook URLなど公開URLは長い乱数が含まれているとはいえ機密扱いにし、公開URLをそのまま公開しない。
受信側ではHMAC検証を必ず行う（次節参照）。

HMAC署名検証の実装サンプル（重要）

ShopifyのWebhook署名はX-Shopify-Hmac-Sha256ヘッダにBase64で付与されます。実装上の重要点は「受信したリクエストの生ボディ（raw bytes）を使うこと」と「定数時間比較で検証すること」です。改行や文字コード変換で値が変わると検証に失敗します。

Node.js（Express）の例：

// app.useを設定して raw body を保持する例
const express = require('express');
const crypto = require('crypto');

const app = express();
app.use(express.raw({ type: 'application/json' })); // 生バイトを保持

app.post('/webhook', (req, res) =&gt; {
  const secret = Buffer.from(process.env.SHOPIFY_SECRET, 'utf8');
  const hmacHeader = req.get('X-Shopify-Hmac-Sha256') || '';
  const generated = crypto.createHmac('sha256', secret).update(req.body).digest();
  const received = Buffer.from(hmacHeader, 'base64');

  if (received.length !== generated.length || !crypto.timingSafeEqual(received, generated)) {
    return res.status(401).send('HMAC mismatch');
  }

  // 検証成功：非同期処理へ渡すなど
  res.status(200).send('OK');
});

// app.useを設定して raw body を保持する例

const express = require('express');

const crypto = require('crypto');

const app = express();

app.use(express.raw({ type: 'application/json' })); // 生バイトを保持

app.post('/webhook', (req, res) => {

const secret = Buffer.from(process.env.SHOPIFY_SECRET, 'utf8');

const hmacHeader = req.get('X-Shopify-Hmac-Sha256') || '';

const generated = crypto.createHmac('sha256', secret).update(req.body).digest();

const received = Buffer.from(hmacHeader, 'base64');

if (received.length !== generated.length || !crypto.timingSafeEqual(received, generated)) {

return res.status(401).send('HMAC mismatch');

}

// 検証成功：非同期処理へ渡すなど

res.status(200).send('OK');

});

Python（Flask）の例：

from flask import request, abort
import hmac, hashlib, base64, os

@app.route('/webhook', methods=['POST'])
def webhook():
    secret = os.environ.get('SHOPIFY_SECRET').encode('utf-8')
    data = request.get_data()  # 生バイト
    received = base64.b64decode(request.headers.get('X-Shopify-Hmac-Sha256', ''))
    expected = hmac.new(secret, data, hashlib.sha256).digest()
    if not hmac.compare_digest(expected, received):
        abort(401)
    # 検証成功処理
    return '', 200

from flask import request, abort

import hmac, hashlib, base64, os

@app.route('/webhook', methods=['POST'])

def webhook():

secret = os.environ.get('SHOPIFY_SECRET').encode('utf-8')

data = request.get_data() # 生バイト

received = base64.b64decode(request.headers.get('X-Shopify-Hmac-Sha256', ''))

expected = hmac.new(secret, data, hashlib.sha256).digest()

if not hmac.compare_digest(expected, received):

abort(401)

# 検証成功処理

return '', 200

実装時の注意点：

リクエストボディはパーサで文字列化したものではなく生バイト（raw bytes）を使用する。
改行コードや文字エンコーディングをいじらないこと。
比較には定数時間比較（crypto.timingSafeEqual / hmac.compare_digest）を用いる。
署名が一致しない場合はログを残しつつ過度に詳細なエラー情報を外部に出さない。

公式のWebhook確認手順： https://shopify.dev/apps/webhooks/verify-webhooks

運用設計・セキュリティ・トラブルシューティング

本番運用で想定される障害とそれぞれの初動手順、さらにPIIや決済情報の扱いなどコンプライアンス上の注意点をまとめます。簡潔な要点集を先に示します。

セキュリティ要点の要約

まずは最低限のセキュリティ要点を短くまとめます。

Webhook受信はHTTPS必須、HMAC署名を常に検証する。
アクセストークンはSecrets Managerで管理し、ソース管理やログに出さない。
顧客の決済情報（カード番号、CVV等）は絶対に外部通知しない。
Slackに送る情報は最小化・マスキングし、必要に応じて暗号化済みの内部IDのみ送る。
GDPR/PCI等の要件は事前に確認し、必要なら法務/セキュリティ担当を巻き込む。

よくある障害と初動手順（401/403/404/429/5xx）

障害ごとにまず確認すべき項目と対処を簡潔に示します。

401 Unauthorized
確認：X-Shopify-Access-Tokenが正しいか、トークンが無効化されていないか。
対処：Secrets Managerのトークンを確認し、必要なら再インストール・再発行を行う。
403 Forbidden
確認：アプリのスコープ不足か、APIが許可されていない操作か。
対処：スコープを見直し、再インストールで権限を付与する。
404 Not Found
確認：URL誤り、APIバージョンミスマッチ、ストアサブドメインの誤り。
対処：エンドポイントとバージョンを再確認する。
429 / レート制限
確認：APIコールの急増、バッチ処理の欠如。
対処：指数バックオフとキュー設計、リトライ制御を適用する（後述）。
5xx / タイムアウト
確認：Shopify側障害かネットワーク問題か。
対処：再試行戦略、障害時に冪等化した処理で回復可能にする。

Webhookが届かない場合は、Shopify管理画面のWebhook配信履歴を確認し、HTTPステータスコードやレスポンスを確認してください。

トークン失効時の復旧手順と役割分担

トークン喪失や漏洩時の具体的な復旧フローを定例化しておきます。

影響範囲の特定：どのストア/どのZapが影響を受けているかを確認する（担当：オンコール）。
一次対応：問題のZapを一時停止して更なる二次被害を防ぐ（担当：運用担当）。
トークン無効化：Shopify管理画面でアプリをアンインストールまたはAPIキーを削除（担当：管理者）。
トークン再発行：新しいトークンを発行し、Secrets Managerへ登録（担当：開発者/管理者）。
配信テスト：ダミー注文で全フローを検証してからZapを再有効化（担当：QA/運用）。
報告とレビュー：インシデントの原因をまとめ、再発防止策を実装する（担当：SRE/セキュリティ）。

事前にロールと手順を文書化しておくことで復旧時間を短縮できます。

Zapの切替／ロールバック手順（実務例）

Zapが不調で即時復旧が必要な場合は以下の手順を推奨します。

本番Zapの前に「バックアップZap」を作成しておく（同等の動作をする控え）。
問題発生時はまず本番ZapをオフにしてバックアップZapをオンに切替する。
切替後、ステージングで数件のテスト注文を流して正しく処理されることを確認する。
切替ログとZapierのタスク履歴を保管し、原因調査を進める。

障害時のエスカレーションフロー（例）

エスカレーションの明文化は重要です。典型的なフローの例を示します。

Sev1（サービス停止）：即時オンコールエンジニア→チームリード→プロダクトオーナーへ通知
Sev2（顧客影響あり）：オンコール→担当チームで対応→必要時リードへエスカレート
Sev3（軽微）：運用チームで対応し、週次でレビュー

各社で連絡手段（Slackチャンネル、チケットシステム）と応答時間を決めておきます。

セキュリティとコンプライアンス（PII/PCI/GDPR）

外部通知やログに含めるデータは最小化し、法規制に従った取り扱いを行ってください。

絶対に送らないデータ：カード番号、CVV、フルカードトークン等の決済情報（PCIに抵触）。
マスキング例：メールは「t***@example.com」、電話は末尾4桁のみ表示など。
ログ retention：PIIの保存期間は最小限にし、不要になれば削除するポリシーを作る。
GDPR対応：EU居住者のデータを扱う場合はデータ処理契約（DPA）や保持ポリシーを整備する。
監査：トークンアクセスやSecretsの参照履歴を監査可能にする。

法的判断が必要な場合は必ず社内の法務や外部専門家に相談してください。

監視・アラート設計

運用中に監視すべき主要指標とアラート例を示します。

Webhook失敗率（時間あたりの401/5xx） → アラート発報
Zapierタスク消費数（突増） → コストアラート
APIエラー率（429や5xx） → 自動的にリトライと人通知
トークンの有効性警告（再認証が必要） → スケジュールチェック

監視は自動化し、閾値を超えたらSlackやメールで通知し、事件化のルールを決めておきます。

レート制限とスケーリング対策

ShopifyのRESTとGraphQLでは異なるレート制限モデルを採用しています。ここではモデルの概要と具体的な回避策、実装例を示します。

REST APIのレート制限と実務的対策

ShopifyのREST Admin APIは一般に「リーキーバケット（leaky bucket）」方式を採用しています。レスポンスヘッダに現在の使用状況が返るため、それを参照して制御します。

レスポンスヘッダ例（参照用）：X-Shopify-Shop-Api-Call-Limit: 12/40
左側が現在カウント、右側がバケット上限の例です。
回避策
バッチ化して必要なAPIコールをまとめる。
重要処理はキューに入れて順次処理する。
APIレスポンスのヘッダを見て残りコール数が少ない場合は待機するロジックを入れる。

GraphQLのコスト制限と最適化

GraphQLはクエリの「コスト」に基づく制限を採用しています。レスポンスに拡張情報（costやthrottleStatus）が含まれ、これを基にリトライや待機を実装します。

レスポンスに含まれる情報（例）
extensions.cost.requestedQueryCost
extensions.cost.throttleStatus.currentlyAvailable / restoreRate / maximumAvailable
最適化の方針
必要最小限のフィールドだけを問い合わせる（selective queries）。
大きなデータはページングして取得する。
重い集計はバッチで行うか、別途集計バッチを用意する。

詳細は公式ドキュメント参照: https://shopify.dev/apps/api/usage/rate-limits

具体的な回避策とリトライ戦略（コード例）

指数バックオフ＋ジッターの実装例（擬似コード）:

retry_count = 0
max_retries = 5
while retry_count &lt; max_retries:
  response = call_api()
  if response.success:
    break
  elif response.status == 429:
    wait = base_delay * (2 ** retry_count) + random_jitter()
    sleep(wait)
    retry_count += 1
  else:
    handle_other_errors()