Shopify APIの種類と選び方｜Admin API・Storefront API・Functions・Webhookの実装判断

「shopify api」で調べる人の多くは、最初から細かいGraphQLクエリを書きたいわけではありません。知りたいのは、商品、注文、顧客、在庫、チェックアウト、テーマ、外部連携のどこに対して、どの実装手段を選べばよいかです。

Shopify公式のAPI一覧を見ると、GraphQL Admin API、Shopify Functions、Webhooks、REST Admin API、Storefront API、Liquid、Ajax APIなどが並んでいます。公式Docsは正確ですが、実務では「どれが何に使えるか」だけでなく、「今回の要件ではどれを使わないべきか」も決める必要があります。

既存記事のShopify API連携の設計方法では、受注、在庫、会計、CRMなど外部連携の正本と同期イベントを整理しました。この記事ではそこから一段手前に戻り、開発方式そのものを選ぶための判断ハブとして、Shopify APIの種類と境界を整理します。

Shopify APIの選定で最初に決めるべきなのは、GraphQLかRESTかではなく、管理データ、購入体験、チェックアウト判定、イベント処理、テーマ表示のどこを変えたいのかです。

先に結論：目的からAPIを逆引きする

Shopify APIは、ひとつの万能な入口ではありません。管理画面側のデータを扱うAPI、購入体験を作るAPI、チェックアウトの裏側を拡張するFunctions、イベントを受け取るWebhook、テーマ上で動くLiquidやAjax APIを分けて考えます。

やりたいこと	第一候補	使わない方がよいもの	判断のポイント
商品、注文、顧客、在庫、フルフィルメントを読み書きしたい	GraphQL Admin API	Storefront API	管理側データの権限、スコープ、バージョン、レート制限を確認する
既存REST連携を保守したい	REST Admin APIを短期保守し、GraphQL移行を計画	新規のREST前提設計	RESTはlegacy扱いなので、新規開発の主軸にしない
ヘッドレスECや外部サイトで商品、検索、カートを扱いたい	Storefront API	Admin API	顧客向け体験なのか、管理業務なのかを分ける
割引、配送、支払い、カート検証など購入フローの判定を変えたい	Shopify Functions	Webhookの後処理	チェックアウト中に即時判定が必要かを見る
注文作成、在庫更新、返金などの発生を外部へ通知したい	Webhooks	定期ポーリング	近リアルタイム通知、署名検証、重複排除、再実行ログを設計する
Shopifyテーマの商品表示や条件分岐を変えたい	Liquid	Admin API	表示ロジックで済むか、外部DBや管理データ更新が必要かを見る
カート追加、カート数量変更、商品レコメンドをテーマ内で動的にしたい	Ajax API	Storefront API	Shopifyホストテーマ内の軽い動的処理かどうかを見る
管理画面設定、標準アプリ、Flow、既存アプリで足りる	APIを使わない	カスタムアプリ	保守者、障害対応、費用対効果を確認する

強いAPIを選ぶのではなく、最小の実装面で要件を満たし、保守できる形を選びます。

GraphQL Admin API：管理側データを扱う主軸

商品、注文、顧客、在庫、ロケーション、フルフィルメント、メタフィールドなど、Shopify管理画面側のデータを読み書きする中心はGraphQL Admin APIです。公式Docsでも、Shopify adminを拡張・強化するアプリや連携を作るAPIとして説明され、Products、Orders、Customers、Inventory、Metafields、Shipping and fulfillmentなど幅広い領域が用意されています。

実務では、次のような要件で候補になります。

要件	GraphQL Admin APIで見る主な領域	先に決めること
商品マスタを外部から登録・更新したい	Products、Product variants、Metafields、Metaobjects	SKUやJANの正本、販売文言の編集権限、画像更新の責任
受注をWMSや基幹に渡したい	Orders、Fulfillment orders、Customers	どの注文状態を出荷可能とみなすか
在庫数を更新したい	Inventory、Locations	在庫正本、ロケーション、引当済み数量の扱い
顧客情報をCRMへ渡したい	Customers、Customer tags、Marketing consent	顧客ID、メール、同意、配信停止の責任
管理画面用アプリを作りたい	App、Access、Webhooks、Metafields	スタッフ権限、アプリのインストール範囲、監査ログ

GraphQL Admin APIは、必要なフィールドを選んで取得できます。ただし、出荷可否、支払状態、返品、返金、顧客タグ、配送先、税、割引、メタフィールドまで含めると、クエリ設計は業務設計そのものになります。リクエストには有効なアクセストークンが必要で、アプリは必要なアクセススコープを要求します。「とりあえずread/writeを広く付ける」のではなく、読み取りだけでよいデータ、書き込みが必要なデータ、スタッフが手動変更してよいデータを分けます。

REST Admin APIの現在地：新規の主軸ではなく保守対象

ShopifyのREST Admin APIは、既存連携や古いアプリではまだ目にします。ただし公式Docsでは、REST Admin APIは2024年10月1日からlegacy APIであり、2025年4月1日以降の新規公開アプリはGraphQL Admin APIだけで構築する必要があると説明されています。また、新しいプラットフォーム機能の一部はGraphQLでのみ利用可能です。

したがって、判断は次のように分けます。

状況	判断	実務上の進め方
既存のREST連携が安定稼働している	すぐ止める必要はないが、保守対象として扱う	使っているエンドポイント、APIバージョン、依存先を棚卸しする
新規で商品・注文・在庫連携を作る	GraphQL Admin APIを第一候補にする	RESTのサンプル記事をそのまま採用しない
外部ベンダーの仕様がREST前提	短期は受け入れつつ、GraphQL移行可否を確認する	ベンダーの保守方針、対応予定、代替APIを確認する
新しいShopify機能を扱いたい	GraphQL対応を確認する	REST側にない機能を前提にしない

RESTを使ってはいけない、という単純な話ではありません。短期保守ではRESTを読み、長期設計ではGraphQL Admin APIへ寄せる。この切り分けが現実的です。

Storefront API：購入体験を作るAPI

Storefront APIは、Web、アプリ、ゲームなど任意のプラットフォームで、商品閲覧、コレクション、検索、カート、チェックアウトなどの顧客向け体験を作るためのGraphQL APIです。Hydrogenのようなヘッドレスコマース構成や、既存サイトにShopifyの商品・カート体験を組み込む場合に候補になります。

一方で、Storefront APIは管理業務のためのAPIではありません。受注を会計へ渡す、在庫をWMSから更新する、顧客タグを管理する、返金を処理する、といったバックオフィス連携の中心に置くものではありません。

Storefront APIが向くこと	Storefront APIが向かないこと
独自フロントで商品一覧、商品詳細、検索を作る	注文、在庫、顧客を管理側で更新する
ヘッドレスECでカート体験を実装する	WMS、会計、CRMとの業務連携を作る
モバイルアプリや外部メディアに購入導線を出す	Shopify管理画面の運用を自動化する
顧客向けに商品・コレクションを表示する	管理者権限が必要なデータを取得する

既存ブランドサイトにShopifyの商品検索とカートを組み込むならStorefront APIは自然です。注文作成後にWMSへ出荷指示を送るなら、WebhookとAdmin APIの領域です。

Shopify Functions：チェックアウト中の判定を変える

Shopify Functionsは、割引、配送、支払い、カートやチェックアウトの検証など、Shopifyのバックエンドロジックをカスタムコードで拡張する仕組みです。公式Docsでは、カスタム配送オプション、割引、カートとチェックアウトのバリデーションなどの例が示され、購入フローの中で実行されるため性能を重視すべきと説明されています。

要件	Functionsが向く理由	代替候補
特定商品を含む注文で配送方法を制限したい	チェックアウト中に配送選択を制御する	配送設定、配送アプリ
顧客タグや商品条件で支払い方法を出し分けたい	支払い方法の候補を購入時点で制御する	決済設定、手動運用
複雑な割引条件を実装したい	カート内容に基づいて割引を計算できる	Shopify標準割引、割引アプリ
禁止組み合わせや購入制限を入れたい	カート・チェックアウト検証に使える	テーマ上の注意表示、注文後キャンセル

Functionsは、通常のAPI連携とは性質が違います。注文後に外部処理を動かすのではなく、購入フローの途中でShopify側の判断に影響します。外部サービスの状態を見て長い処理をするより、Shopify内のデータや事前同期されたメタフィールド・メタオブジェクトを使い、即時に判定する設計が向きます。

決済や返金の業務運用は、別記事のShopifyの決済設定は何を決めてから有効化すべきかでも整理しています。Functionsを使う場合も、購入時の制御だけでなく、入金、返金、会計照合への影響まで見ます。

Webhooks：イベントに反応して外部処理を動かす

Webhooksは、Shopify上で特定イベントが起きたときに、外部のエンドポイントへ近リアルタイムで通知する仕組みです。公式Docsでも、アプリをShopifyデータと同期させる、イベント後に追加処理を実行する、継続的なポーリングの代替にする用途が説明されています。

Webhookは、API呼び出しの代わりではありません。イベントを受け取り、その後に必要ならAdmin APIで詳細取得や更新を行います。

イベント例	Webhookで受ける理由	受信後に決める処理
注文作成	WMS、CRM、会計、通知の起点にする	支払状態を確認し、出荷対象か判定する
商品更新	外部商品DBや検索基盤へ反映する	更新項目を比較し、必要なデータだけ同期する
在庫更新	低在庫通知や外部在庫DBの更新に使う	ロケーション、SKU、同期元を確認する
返金・返品	会計、CS、在庫復帰の起点にする	返金理由、金額、在庫戻し、承認者を記録する
アプリ削除	保持データやトークンを無効化する	データ削除、連携停止、通知を実行する

Webhook設計で落ちやすいのは、受信後の運用です。

設計項目	確認すること
署名検証	Shopifyから来た通知かを検証する
冪等性	同じイベントが複数回来ても二重処理しない
受信ログ	いつ、どのトピックを、どの内容で受けたか残す
リトライ	一時障害時に再処理できるようにする
詳細取得	ペイロードだけで足りない場合、Admin APIで取り直す
手動補正	失敗した注文や在庫を人が再実行・補正できるようにする

受注、在庫、会計など外部連携の全体像は、Shopify API連携の設計方法で扱っています。この記事では、Webhookを「通知を受ける入口」として位置づけ、データ同期の主処理や復旧運用と分けて考えます。

LiquidとAjax API：テーマ内で済む変更

Shopifyテーマの表示や条件分岐は、まずLiquidで考えます。LiquidはShopifyテーマで使われるテンプレート言語で、商品名、価格、画像、在庫状態、メタフィールドなどをテンプレート上に出し分けるために使います。

一方、Ajax APIは、Shopifyにホストされたテーマ内で使える軽量なREST APIです。公式Docsでは、カートへの商品追加、カート数量表示の更新、関連商品表示、検索候補などの用途が挙げられています。GETでカートや一部商品データを読み、POSTで現在セッションのカートを更新するような使い方です。

変更したいこと	Liquidでよいか	Ajax APIが向くか	Admin APIやStorefront APIを考える境界
商品ページに注意文を出したい	向く	不要なことが多い	外部DBのリアルタイム判定が必要な場合
顧客タグで表示を変えたい	条件によって向く	不要なことが多い	管理側データ更新や厳密な権限制御が必要な場合
カート数量を画面遷移なしで変えたい	表示だけならLiquid	向く	ヘッドレス構成や外部サイトならStorefront API
商品検索の候補を出したい	静的表示ならLiquid	向く場合がある	独自検索基盤や外部サイトなら別設計
注文データを外部へ送信したい	向かない	向かない	WebhookとAdmin API
在庫数を外部から更新したい	向かない	向かない	Admin API

テーマ内で済む変更を、いきなりカスタムアプリにしないことは大切です。逆に、管理データ更新や外部システム連携をLiquidやAjax APIだけで済ませようとすると、セキュリティ、権限、復旧、監査の面で無理が出ます。

認証、スコープ、バージョン、レート制限を開発前に確認する

Shopify API開発では、動くコードを書く前に、認証、スコープ、バージョン、レート制限を確認します。ここを後回しにすると、実装後に「本番ストアで権限が足りない」「APIバージョン更新でレスポンスが変わった」「夜間バッチがレート制限に当たった」という形で返ってきます。

確認項目	見る場所	設計で決めること
認証方式	OAuth、トークン交換、カスタムアプリ、Storefront用トークン	公開アプリか、単一ストアのカスタムアプリか、管理画面内アプリか
アクセススコープ	API access scopes	読み取り、書き込み、顧客データ、注文データをどこまで許可するか
APIバージョン	API versioning	利用バージョン、更新周期、非推奨変更の確認担当
レート制限	API limits	同期頻度、バッチサイズ、リトライ、キャッシュ、Bulk operationsの検討
エラー処理	各APIのstatus/error docs	失敗時の再実行、通知、手動補正、二重処理防止

公式Docsでは、Shopify APIはバージョン管理されるものとされないものに分かれ、Admin API、Storefront API、Function APIs、Webhooksなどは四半期リリースの対象です。2026年7月3日時点では、GraphQL Admin APIとStorefront APIのlatestは2026-07です。安定版は最低12か月サポートされますが、最新安定版へ定期的に更新し、リクエストでは必ずバージョンを指定することが推奨されています。

レート制限もAPIごとに見方が違います。GraphQL Admin APIでは、クエリのコスト、アプリとストアの組み合わせ、バケット、restore rateを見ます。単純に「1分に何回まで」と考えるより、重いクエリを減らす、ページングや絞り込みを入れる、夜間一括同期を分割する、必要ならBulk operationsを検討する方が実務的です。

Shopify APIの保守性は、初回実装の速さではなく、スコープ、バージョン、レート制限、エラー復旧を運用に落とせているかで決まります。

APIを使わない選択肢も先に検討する

Shopify APIを調べていると、すべてをカスタム実装したくなります。しかし、APIを使わない方がよいケースもあります。

要件	API不要の候補	API実装に進む境界
商品ページに注意文やスペック表を出したい	テーマ編集、メタフィールド、Liquid	外部DB連携や複雑な権限判定が必要
低在庫を通知したい	Shopify Flow、既存アプリ	通知条件が複雑で、複数システムの状態を見る
決済方法を整理したい	Shopify設定、決済アプリ	チェックアウト中の独自判定が必要
注文をスプレッドシートへ送る	既存アプリ、iPaaS、Flow	失敗時の再実行、項目変換、監査ログが必要
SNSや広告の商品同期	公式販売チャネル、連携アプリ	独自商品フィードや複数カタログの統制が必要
在庫数を外部倉庫と合わせたい	WMS連携アプリ	正本、引当、複数ロケーション、差異復旧が必要

APIを使わない判断は、技術的に弱い選択ではありません。標準設定、テーマ、アプリ、Flow、iPaaSで十分なら、その方が保守しやすいことがあります。一方で、業務が複数部署にまたがり、データの正本、失敗時の補正、権限、監査、再実行が必要になるなら、カスタムアプリやAPI連携の設計に進むべきです。在庫連携の判断は、Shopify在庫連携の設計方法も参考になります。

失敗時の切り分け：API選定より運用ログが大事

Shopify API開発で本番運用に入ると、問題は「APIが呼べるか」ではなく「どこで失敗したかを切り分けられるか」に変わります。

症状	見るべき場所	よくある原因	復旧の考え方
注文が外部システムに送られない	Webhook受信ログ、Shopifyイベント、連携DB	Webhook未登録、受信失敗、重複排除ミス	対象注文を再送または手動同期する
商品更新が反映されない	Admin APIレスポンス、スコープ、メタフィールド定義	権限不足、APIバージョン差分、更新対象の取り違え	エラー内容と対象IDを残して再実行する
Storefront側の商品が古い	Storefront APIレスポンス、キャッシュ、公開チャネル	公開対象外、キャッシュ、商品ステータス	商品公開状態とフロント側キャッシュを確認する
割引や配送制御が効かない	Functionsの入力、設定、対象条件	メタフィールド未設定、条件式、実行順序	テストカートで入力データを再現する
レート制限に当たる	APIレスポンスのcost/throttle情報、バッチログ	重いクエリ、過剰な全件取得、短時間集中	クエリ削減、ページング、分割、キャッシュを入れる
権限エラーが出る	インストール時スコープ、Granted scopes、アプリ設定	必要スコープ不足、再インストール未実施	スコープ変更と再承認の手順を決める
バージョン更新後に壊れる	APIバージョン、Developer changelog、テスト環境	非推奨フィールド、レスポンス変更	四半期ごとの確認と事前テストを運用化する

この切り分け表を作っておくと、運用担当者が「開発会社に聞かないと何も分からない」状態を避けられます。API実装では、成功時の連携だけでなく、失敗時に誰が見て、どこまで戻せるかを成果物に含めるべきです。

まとめ

Shopify APIは、種類を暗記しても実務では使い分けられません。

管理データを読み書きするならGraphQL Admin API、既存RESTは保守対象として棚卸し、顧客向け購入体験ならStorefront API、購入フローの判定ならFunctions、イベント起点の外部処理ならWebhooks、テーマ内表示ならLiquid、カート周りの軽い動的処理ならAjax API、というように、目的から逆引きする必要があります。

さらに、認証、スコープ、バージョン、レート制限、ログ、再実行、APIを使わない選択肢まで含めて初めて、Shopify API開発は保守できる形になります。

Bitlightでは、Shopifyの画面設定だけでなく、受注、在庫、決済、顧客、ストアフロント、外部システムまで含めて、どのAPIを使い、どこは使わないかを業務要件から整理します。API一覧から実装を始める前に、まずはデータ、権限、運用、復旧まで含めた設計に落とし込むことが重要です。