ShopifyとkintoneのAPI連携｜手段の選び方・実現できることとAPI制限の設計【2026年版】

Shopifyで受けた注文をkintoneで管理したい、という要望はEC運用の現場でよく出ます。ところが調べ始めると、プラグインを勧める記事、ノーコードツールを勧める記事、APIで自作する記事が並び、どれを選べばよいのか判断がつきません。実際に効いてくるのは機能の多さではなく、両サービスのAPIにかかっている制限です。kintoneは同時リクエスト数と1回で扱えるレコード件数に明確な上限があり、Shopifyは2024年10月にREST Admin APIをlegacy扱いへ切り替えました。この記事では連携で何が実現できるかを整理したうえで、3つの手段を選び分ける基準と、設計を縛るAPI制限までを扱います。

まとめ：連携手段の選び方と設計上の制約

• Shopifyとkintoneをつなぐ標準機能はない。実現手段はkintone向け連携プラグイン、iPaaS、自作APIの3つ。
• 選び分けの軸は「変換ロジックの複雑さ」。項目をそのまま写すだけならプラグインかiPaaS、条件分岐や独自計算が入るなら自作API。
• Shopify側はGraphQL Admin APIで作る。REST Admin APIは2024年10月1日にlegacyとなり、公式は新規の実装をGraphQLで行うよう案内している。
• kintone側の制限が同期方式を決める。同時リクエストは1ドメインにつき100まで、登録・更新・削除は1リクエストあたり100件まで。超過するとドメイン全体のREST APIがエラーになる。
• 全件洗い替えは選ばない。offsetで取得できるレコードは10,000件までで、日次の全件同期は1日あたりのAPIリクエスト上限にも当たりやすい。差分同期で組む。

ShopifyとkintoneをつなぐとEC運用の何が変わるか

連携の価値は「Shopifyの画面を見ずに済むこと」ではなく、Shopifyが持たない業務データと注文を同じ場所で扱えることにあります。Shopifyは受注と決済までを担いますが、その先の与信、出荷指示、問い合わせ履歴、仕入れといった社内業務はShopifyの外です。kintoneはこの部分をアプリとして自分たちで組めるため、注文レコードを受け取ったあとの処理を現場が設計できます。

実務で効果が出やすいのは次の3つです。第一に受注情報の取り込みで、注文が発生した時点でkintoneにレコードが作られ、出荷ステータスや担当者の割り当てをkintone側のプロセス管理で回せます。第二に在庫数の反映で、kintoneを在庫の正としてShopifyの在庫数を書き戻す構成にすると、実店舗や他モールとの在庫調整をkintoneに集約できる形です。第三に顧客データの統合で、Shopifyの顧客レコードと問い合わせ履歴を突き合わせ、購入履歴を見ながら対応できる状態を作れます。

見落とされがちなのがメタフィールドとタグの扱いです。Shopifyは商品や注文に対して、標準項目にない情報をメタフィールドとして持たせられます。産地や型番、社内管理コードといった自社固有の項目の置き場所がここです。タグも同様に、キャンペーン区分や発送区分をラベルとして付けられます。連携を設計するときは、この2つをkintone側のどのフィールドに落とすかを最初に決めてください。標準項目だけを写す設計にすると、あとから「社内コードが入っていない」と分かって作り直しになります。kintoneでどこまで業務を持てるかはkintoneとは？できること・料金・プラグインからノーコードで内製する判断まで解説で整理しています。

連携手段は3つ：プラグイン・iPaaS・自作API

Shopifyとkintoneをつなぐ標準機能は用意されていません。どの方法を採っても、どこかで両者のAPIを呼ぶ処理が必要になります。違いは、その処理を誰が持つかです。

kintone向け連携プラグイン

kintoneにプラグインとして導入し、Shopifyの注文や商品をkintoneアプリへ取り込む製品です。設定画面で項目の対応付けを行うだけで動くため、開発工数はほぼかかりません。向いているのは、Shopifyの項目をkintoneの項目へそのまま写す用途です。逆に、複数アプリへ振り分ける、条件によって変換ルールを変えるといった要件が入ると、プラグインの設定範囲を超えます。導入前に、自社が必要とする項目とタイミングが設定項目の中に収まるかを確認してください。プラグイン選定の考え方はkintone開発とは？カスタマイズ手段・費用相場・内製と外注の判断まで解説で扱っています。

iPaaSによるノーコード連携

Shopifyとkintoneの両方にコネクタを持つ連携サービスを間に挟む方法です。「注文が作成されたらkintoneにレコードを追加する」といった処理をテンプレートから組み立てられ、他システムを足すときも同じ基盤に乗せられます。Shopify側のWebhookを受けて動く構成にすれば、定期実行よりも反映が早くなります。注意点は実行回数の課金です。注文が多い事業者ほど実行数が積み上がるため、月間の想定件数を先に見積もってから採用可否を決めてください。他システムとの連携も同時に検討している場合は、ShopifyとSalesforceのAPI連携でできること：統合のメリットと活用法のような別の組み合わせも同じ基盤で扱えます。

自作API（Shopify GraphQL Admin API × kintone REST API）

自社でプログラムを書き、両者のAPIを直接呼ぶ方法です。変換ロジックを自由に書けるため、条件分岐や独自の計算、複数アプリへの振り分けにも対応できます。その代わり、認証情報の管理、失敗時のリトライ、APIのバージョン追随といった運用は自社の責任です。Shopify側はGraphQL Admin API、kintone側はREST APIを使います。

判断の順序としては、まず必要な変換ロジックを書き出してください。項目の対応表を作ってみて、すべてが1対1で対応するならプラグインかiPaaSで足ります。「この条件のときだけ別アプリへ」「送料は自社ルールで再計算」といった行が現れた時点で、自作APIの検討に入ってください。

Shopify側の前提：REST Admin APIはlegacy、GraphQLで作る

日本語で書かれた連携記事の多くは、ShopifyのREST Admin APIを使う前提のままです。この前提は現在の公式方針と食い違っています。Shopifyの公式ドキュメントは「The REST Admin API is a legacy API as of October 1, 2024. All apps and integrations should be built with the GraphQL Admin API.」と明記しており、2024年10月1日をもってREST Admin APIはlegacy扱いになりました。新しく作る連携はGraphQL Admin APIを前提にしてください。

アプリストアに出す公開アプリについては期限も示されています。2024年10月1日付のchangelogは「Starting April 1 2025, all new public apps submitted to the App Store after this date must only use GraphQL.」として、2025年4月1日以降に提出される新規の公開アプリはGraphQLのみを使うことを求めています。自社専用のカスタムアプリはこの提出要件の対象ではありませんが、legacy扱いという位置づけは変わりません。

なお、RESTの全面廃止日そのものは公式ドキュメントに明示されていません。第三者の解説記事には具体的な廃止スケジュールを書いたものもありますが、公式で確認できない以上、期日を前提にした計画は立てないほうが安全です。代わりに押さえるべきはバージョンのサポート期間で、Shopifyは四半期ごとに新しいAPIバージョンを出し、安定版には最低12か月のサポート、連続するバージョン間には9か月以上の重複期間を設けています。連携を自作するなら、少なくとも年1回はバージョンを上げる運用を前提に組んでください。このバージョン運用は、フロントをヘッドレス化してStorefront APIを叩く構成でも同じで、microCMSとShopifyを連携したECサイト構築でも実装前に確認すべき制約として扱っています。

レート制限の考え方もRESTとGraphQLで異なります。GraphQL Admin APIはクエリごとに算出されたコストをリーキーバケットで消費する方式で、上限はプランによって変わります（Shopify Plusは上位の枠）。超過すると 429 Too Many Requests やthrottleエラーが返るため、実装側でリトライを持つ必要があります。具体的なポイント数はプランと時期で変わるので、設計時に公式のレート制限ページで最新値を確認してください。

kintone側のAPI制限が連携設計を決める

連携の設計で最初に効いてくるのは、実はkintone側の制限です。cybozuの公式ドキュメントは「同時にリクエストできるAPIは、1ドメインにつき100までです。」と定めています。ここで重要なのは、この上限がアプリ単位ではなくドメイン単位である点です。同時接続が100を超えるとHTTP 429が返り、しかも超過の原因になったアプリだけでなく、そのドメイン全体のREST APIがエラーになります。Shopify連携のバッチが暴走すると、無関係な社内アプリのカスタマイズまで巻き添えで止まるということです。

1リクエストで扱える件数にも上限があります。公式仕様では「一度に登録／更新／削除できるレコードは、100件までです。」とされています。1,000件の注文をkintoneへ流すなら、100件ずつ10回に分けて呼ぶ設計です。ここで並列度を上げて一気に投げると、前述の同時接続100に近づきます。件数が多い連携ほど、並列数を絞って直列寄りに流してください。

# 100件ずつに分割して kintone へ送る（擬似コード）
for chunk in chunks(records, 100):
    POST /k/v1/records.json   # 1リクエスト＝最大100件
    # 並列数は絞る（同時リクエストは1ドメインにつき100が上限）

取得側では、offsetで指定できるレコードの上限が10,000件である点が設計を縛ります。1万件を超えるデータをoffsetでページングして全件取得することはできません。そのため「毎晩kintoneの全レコードとShopifyの全注文を突き合わせて洗い替える」という素朴な設計は、データが育った時点で破綻します。更新日時で絞った差分同期を最初から前提にしてください。

さらに、1アプリあたりの1日のAPIリクエスト数にも上限が設定されています。集計は日本時間の9:00から翌日8:59までで、リセットは毎日9:00です。上限を超えると翌日の9時ごろに超過を知らせるメールが届きます。定期実行の間隔を短くするほどこの上限に近づくため、リアルタイム性が必要なら定期ポーリングを短くするのではなく、ShopifyのWebhookを起点にして必要なときだけkintoneを呼ぶ構成へ変えるほうが筋のよい設計です。

採用すべきでない場面と失敗パターン

連携が有効でない場面もはっきりあります。注文が1日数件で、担当者が1人でShopifyの管理画面を見て処理できているなら、連携を入れる価値は薄いといえます。API連携は動き出したあとも、Shopifyのバージョン追随、認証情報の更新、失敗時の再送といった運用が続く点にも注意してください。手作業のほうが安い規模でそれを背負う必要はありません。

失敗パターンとして多いのは次の3つです。1つ目は在庫の正をどちらに置くか決めないまま双方向同期を組むケースで、Shopifyとkintoneの両方から在庫を更新できる状態にすると、更新の順序次第で数量が食い違い、原因の特定に時間がかかります。在庫は必ず片方を正とし、もう一方へは書き戻しのみにしてください。

2つ目は全件同期です。前述のとおりoffsetの上限とAPIリクエスト数の上限があるため、レコードが増えたところで止まります。3つ目は失敗時の扱いを決めていないケースで、429やタイムアウトで落ちた分をどこに記録し、いつ再送するかを決めていないと、注文が欠けたことに気づくのが顧客からの問い合わせ時になります。連携アプリとは別に、失敗レコードを溜めるアプリを用意しておくのが現実的な備えです。kintone側の設計や運用を含めて相談したい場合は、kintone導入支援のサービスページもご覧ください。

よくある質問

Shopifyとkintoneは標準機能だけで連携できますか

できません。両サービスに互いを直接つなぐ標準機能はないため、kintone向けの連携プラグイン、iPaaS、自作APIのいずれかを選ぶことになります。ノーコードで済ませたい場合はプラグインかiPaaSが候補です。

kintoneのAPI制限に引っかかるとどうなりますか

同時リクエストが1ドメインにつき100を超えるとHTTP 429が返り、原因となったアプリだけでなくドメイン全体のREST APIがエラーになります。1アプリあたりの1日のリクエスト数上限を超えた場合は、翌日9時ごろに超過を知らせるメールが届きます。集計は日本時間9:00から翌8:59まで、リセットは毎日9:00です。

ShopifyのREST Admin APIはまだ使えますか

公式ドキュメントは2024年10月1日付でREST Admin APIをlegacyと位置づけ、すべてのアプリと連携をGraphQL Admin APIで構築するよう案内しています。全面廃止の期日は公式には示されていませんが、新規に作るならGraphQLを前提にしてください。2025年4月1日以降にアプリストアへ提出する新規の公開アプリは、GraphQLのみを使うことが要件です。

kintoneへ一度に登録できるレコードは何件までですか

1リクエストあたり100件までです。それ以上を扱うときは100件ずつに分割して呼びます。取得側はoffsetで指定できるレコードが10,000件までのため、大量データは更新日時などで絞り込む差分同期にします。

ECサイトとの連携でまず同期すべきデータはどれですか

注文データから始めるのが定石です。注文はkintone側で出荷や請求のプロセスへ直結し、効果が最も見えやすい対象になります。在庫の双方向同期は正をどちらに置くかの設計が必要なので、注文の取り込みが安定してから着手してください。

関連記事

• kintoneとは？できること・料金・プラグインからノーコードで内製する判断まで解説
• kintone開発とは？カスタマイズ手段・費用相場・内製と外注の判断まで解説
• ShopifyとSalesforceのAPI連携でできること：統合のメリットと活用法