Contents
導入前チェックリストと前提条件
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が使える場合に参考にしてください。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ "blocks": [ { "type": "section", "text": { "type": "mrkdwn", "text": "*新規注文が入りました*\n注文ID: 12345\n合計: $100.00\n顧客: J*** D***\nメール: j***@example.com" } } ] } |
マスキングの簡易例（JavaScript）:
|
1 2 3 4 5 6 7 |
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、プレースホルダを置換してください）:
|
1 2 3 4 |
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）:
|
1 2 3 4 5 |
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で登録する例（アドレスはプレースホルダ）:
|
1 2 3 4 5 6 7 8 9 10 11 |
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）の例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
// 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）の例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
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
具体的な回避策とリトライ戦略（コード例）
指数バックオフ＋ジッターの実装例（擬似コード）:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
retry_count = 0 max_retries = 5 while retry_count < 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() |
実運用での設計ポイント：
- 冪等性：同じ処理を複数回実行しても副作用が起きないようIDempotencyを設計する（注文IDで重複判定など）。
- キュー化：高頻度イベントはQueue（Pub/Sub、SQS、Redis等）で平滑化する。
- バッチ処理：短時間で多数のAPIコールが必要な処理は一定間隔でまとめて実行する。
代替手段の比較・コスト試算・導入後チェックリスト
Zapier以外の選択肢やコスト抑制の具体例、導入後に必ず確認するチェックリストを示します。要件に応じて適切な手段を選んでください。
代替手段比較（Zapier / n8n / Shopify Flow / カスタムバックエンド）
各手段の長短を実務目線で整理します。
- Zapier
- 長所：ノーコードで多数コネクタが利用でき、短期間で試作可能。
- 短所：タスク課金・高頻度処理でコストが膨らむ可能性。
- n8n（セルフホスト）
- 長所：柔軟性が高くランニングコストを制御しやすい（自己運用が前提）。
- 短所：インフラ運用・メンテナンスが必要。
- Shopify Flow
- 長所：Shopify内で完結する自動化に向き、ストアネイティブな処理が得意（利用可否はプラン依存）。
- 短所：外部サービス連携の柔軟性は限定的。
- カスタムバックエンド（自社実装）
- 長所：最も柔軟でスケールしやすく、コスト設計が可能。
- 短所：開発・保守コストが高くエンジニアが必要。
選定は「トランザクション量」「リアルタイム性」「保守体制」「セキュリティ要件」「コスト感度」を総合して行ってください。
コスト削減の実践例
- フィルタで不要イベントを弾き、無駄なタスクを削減する。
- 高頻度イベントは一度キューに入れ、まとめて処理する（バッチ化）。
- Zap内でFormatter/Pathsを活用して無駄な外部呼び出しを減らす。
- ストア単位で処理を分離し、障害影響を限定する。
実装後チェックリスト（本番移行前と運用開始後）
以下は必ず確認する項目です。本番化前に完了していることを確認してください。
- ステージングでテスト注文をフルフローで流し、エラーがないか確認済みか。
- 重複対策（注文IDでの一意性チェックなど）を実装済みか。
- トークンの保管場所とローテーション手順が明文化されているか。
- WebhookのHMAC署名検証が実装されているか。
- APIバージョン管理ポリシー（更新チェックの運用）があるか。
- Zapierの月次タスク数とコスト予算をレビューする仕組みがあるか。
- 監視（Webhook失敗率、APIエラー、タスク消費）とアラートが設定されているか。
参考ドキュメント（公式）
以下は必ず目を通すことを推奨する公式ドキュメントです。最新の仕様や廃止スケジュールは随時更新されます。
- Shopify - Admin API 認証: https://shopify.dev/apps/auth
- Shopify - OAuth（公開アプリ）: https://shopify.dev/apps/auth/oauth
- Shopify - Webhooks（検証・設定）: https://shopify.dev/apps/webhooks
- Shopify - API バージョン管理: https://shopify.dev/concepts/about-apis/versioning
- Shopify - レート制限（Rate limits）: https://shopify.dev/apps/api/usage/rate-limits
- Zapier - 料金ページ: https://zapier.com/pricing
- Zapier - ドキュメント（プラットフォーム/トリガー/Webhook）: https://platform.zapier.com/docs
- Slack - Block Kit（メッセージフォーマット）: https://api.slack.com/block-kit
- GDPR (欧州一般データ保護規則) 概要（EU公式情報などを参照）
まとめ（運用に入る前の最小チェック）
- テスト環境でフロー全体を検証し、マスクや重複対策を確認する。
- Webhook受信はHTTPS＋HMAC検証を必須にする。
- トークンはSecrets Managerで管理し、ローテーション手順を用意する。
- Zapierのプラン差分（マルチステップ、ポーリング間隔、タスク課金）を踏まえて選定する。
- APIバージョン管理・レート制限対策（バッチ化・キュー・指数バックオフ）を実装する。
参考リンクは上記公式ドキュメントを参照し、実装・運用の都度最新情報を確認してください。
