Shopifyで受けた注文をkintoneで管理したいとき、最初に迷うのが手段の選び方です。調べ始めると、連携アプリの紹介、ノーコードツールの手順、APIで自作する記事が別々に並んでいて、どれを選べばよいか比べられません。この記事では、2026年10月25日時点の公式情報をもとに、3つの手段を製品名と料金で並べます。そのうえで、選び方を左右する前提を扱います。前提は3つで、kintoneのコースの条件、ShopifyのWebhookの再試行と重複配信、kintoneのAPI制限です。
まとめ:Shopify×kintone連携の手段・費用・設計の要点
- 両者を直接つなぐ標準機能はない。kintoneの公式オプション「連携コネクタ」もMicrosoft 365向けで、Shopifyは対象外。手段は連携アプリ(既製品)、iPaaS、自作APIの3つ。
- kintoneはスタンダードコース以上が前提。ライトコースは外部サービス連携とプラグインが使えない。スタンダードは1ユーザー月1,800円(税抜)で最低10ユーザーのため、kintone側だけで月18,000円からになる。
- 既製品で済ませるならスライベックスの「キントーン かんたん連携 | THRIVEX」。商品・顧客・注文の連携は月$98、タグとメタフィールドも連携するなら月$198(USD建て・30日ごとの請求)。Yoomなら、2026年5月1日の改定後のプランではミニプラン(月20,000円・税抜)以上が目安。
- 自作するならShopify側はGraphQL Admin APIとWebhook。Webhookは5秒以内に200番台を返さないと失敗扱いになり、4時間で最大8回再試行され、同じ通知が重複して届くこともある。注文IDを重複禁止フィールドにしてkintoneのUPSERTで受ければ、重複しても二重登録にならない。
- kintone側の制限が同期方式を決める。同時リクエストは1ドメイン100まで、登録・更新は1回100件まで、offsetは10,000件まで、1日のリクエストは1アプリ1万件(スタンダード)まで。全件洗い替えではなく差分同期で組む。
Shopify×kintone連携で変わる受注後の業務
連携の価値は、Shopifyが持たない業務データと注文を同じ場所で扱えることにあります。Shopifyにも出荷処理や在庫の機能はありますが、与信、出荷前の社内承認、問い合わせ履歴、仕入れといった自社固有の業務は、Shopifyの標準機能だけでは組みにくい部分です。kintoneはこの部分をアプリとして自分たちで組めるため、注文を受け取ったあとの処理を現場で設計できます。
最も効くのは受注情報の取り込みです。注文が入った時点でkintoneにレコードを作れば、出荷ステータスや担当者の割り当てをkintoneのプロセス管理で回せます。次が在庫数の反映で、kintoneを在庫の正にしてShopifyへ書き戻せば、実店舗や他モールとの在庫調整をkintoneに集約できます。顧客データの統合は、購入履歴を見ながら問い合わせに答えたい場合に効きます。楽天市場やAmazonなど複数のモールの受注をまとめたい場合は、Shopify単体の連携より受注管理システムが向いています。
設計で最初に決めるべきなのがメタフィールドとタグです。Shopifyでは、商品や注文に標準項目にない情報をメタフィールドとして持たせられます。産地や型番、社内管理コードといった自社固有の項目はここに入ります。タグも同様に、キャンペーン区分や発送区分のラベルとして使われます。連携を設計するときは、この2つをkintoneのどのフィールドに落とすかを最初に決めてください。標準項目だけを写す設計にすると、あとで「社内コードが入っていない」と分かって作り直しになります。後述の既製品でも、タグとメタフィールドの連携は上位プランだけです。kintoneでどこまで業務を持てるかはkintoneとは?できること・料金・プラグインからノーコードで内製する判断まで解説で整理しています。
連携の前提条件:kintoneはスタンダードコース以上
どの手段を選ぶ場合でも、最初に確かめるのはkintoneの契約コースです。kintoneの料金ページの比較表では、「外部サービス連携、プラグインなどの拡張機能」はライトコースが対象外、スタンダードコースとワイドコースが対象です。ライトコースのままではAPI連携も連携プラグインも使えません。
| コース | 月額(税抜・1ユーザー) | 最小ユーザー数 | 外部連携・プラグイン | 1アプリの1日のAPIリクエスト数 |
|---|---|---|---|---|
| ライト | 1,000円 | 10 | 使えない | なし |
| スタンダード | 1,800円 | 10 | 使える | 10,000件 |
| ワイド | 3,000円 | 1,000 | 使える | 100,000件 |
つまり連携の総費用は、kintoneスタンダードの「1,800円×ユーザー数(最低10)」に、後述する連携手段の費用が上乗せされる形になります。ライトコースで運用している会社は、連携の見積もりにコース変更の差額を入れてください。なお、料金表のオプションにある「連携コネクタ」は、サイボウズの説明ではkintone・GaroonとMicrosoft 365の主要サービスをつなぐオプションで、Shopifyとの連携には使えません。
Shopify×kintoneの連携手段3つと製品・料金
どの方法を採っても、どこかで両者のAPIを呼ぶ処理が動きます。違いは、その処理を誰が持つかです。既製品なら提供元、iPaaSならサービス事業者、自作なら自社が持ちます。
既製品:キントーン かんたん連携とshopikin
Shopifyとkintoneの組み合わせに特化した既製品を出しているのは、長崎市の株式会社スライベックスです。同社は2024年6月21日にkintone向けの連携プラグインの提供を始めました(発表時の価格はライトプラン月18,000円・スタンダードプラン月27,000円、税別)。2024年12月16日には、Shopifyアプリ「キントーン かんたん連携 | THRIVEX」も公開しています。Shopify App Storeの掲載では、アプリの料金は次の3段階です。
- FREE(無料):フィールド連携の設定のみ。実際のデータ連携には有料プランが必要。
- LITE(月$98):商品・顧客・注文の各管理情報をkintoneへ連携。
- STANDARD(月$198):LITEに加えて、商品・顧客・注文のタグとメタフィールドも連携。
請求はUSDで、30日ごとです。製品説明では、連携の方向はShopifyからkintoneで、エラーログと再実行の機能を持つとされています。kintoneを在庫の正にしてShopifyへ在庫数を書き戻す運用を考えているなら、その方向に対応しているかを導入前に提供元へ確認してください。App Storeのレビューは2026年10月25日時点で0件で、外部の評価から導入実績を判断する材料はまだありません。無料プランで項目の対応付けまで試してから有料に切り替えると、項目の不足を契約前に見つけられます。
同社はもう1つ、kintoneをベースにECと実店舗を一元管理するパッケージ「shopikin(ショピキン)」を2024年11月6日から提供しています。公式の料金はライトプランが初期300,000円・月30,000円、スタンダードプランが初期500,000円・月50,000円です。連携だけでなく、顧客管理や在庫の画面まで含めて既製のアプリ群を使いたい場合の選択肢になります。
iPaaS:Yoomなどのノーコード連携
Shopifyとkintoneの両方に接続できる連携サービスを間に挟む方法です。「注文が発生したらkintoneにレコードを追加する」といった処理をテンプレートから組めて、他のSaaSを足すときも同じ基盤に載せられます。国産のYoomは2026年5月1日に料金プランを改定しました。改定後は、Shopifyはすべてのプランで連携できるアプリに入りましたが、kintoneはこの一覧にありません。新料金プランの比較表で「すべてのアプリ」と連携できるのはミニプラン(月20,000円・税抜、月5,000タスク)以上です。そのため、Shopifyとkintoneをつなぐならミニプラン以上が目安になります。新プランが適用されるのは2026年5月1日以降に契約・更新した利用者です。Yoomの手順記事には「Shopifyはチームプラン・サクセスプランのみ」とする改定前の注記が残っているため、契約時期に合わせて確認してください。
起動の方式は2つあり、反映の速さが変わります。1つはトリガーの起動間隔ごとの定期確認で、新プランの最短間隔はミニが10分、チームとサクセスが5分です。もう1つは「注文情報が作成されたら(Webhook)」のようにShopifyのWebhookで起動する方式で、注文の直後に動きます。新プランのWebhookの受信上限はミニが1分120件、チームが300件なので、セール直後の注文集中では上限に注意が必要です。出荷指示を当日中に回したいならWebhook起動、日次の売上集計だけなら定期確認で足ります。どちらも実行の回数が課金に効くため、月間の注文件数と1件あたりの処理数を先に見積もってください。Yoomの課金単位とプラン別の上限はYoomとは?国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】、他製品との比較はiPaaSの比較9製品|料金と課金単位・接続数で選ぶ判断軸と規模別の結論で扱っています。
自作API:Shopify GraphQL Admin API × kintone REST API
自社でプログラムを書き、両者のAPIを直接呼ぶ方法です。変換ロジックを自由に書けるため、条件分岐や独自の計算、複数アプリへの振り分け、kintoneからShopifyへの書き戻しにも対応できます。その代わり、認証情報の管理、失敗時の再送、Shopify APIのバージョン追随は自社の仕事です。構成はShopify側がWebhookとGraphQL Admin API、kintone側がREST APIになります。kintone側の画面に処理を組み込む場合はkintoneカスタマイズ・開発とは?できること・手段・費用相場と内製外注の判断が参考になります。
| 手段 | 代表例 | 月額の目安 | 連携の向き | 向く場面 |
|---|---|---|---|---|
| 連携アプリ | キントーン かんたん連携 | $98〜$198 | Shopify→kintone | 項目をそのまま写す |
| パッケージ | shopikin | 3万〜5万円+初期30万〜50万円 | 提供元に確認 | 既製の管理画面まで欲しい |
| iPaaS | Yoom | ミニ2万円〜(新プラン) | フロー次第で双方向 | 他のSaaSもつなぐ |
| 自作API | GraphQL+REST | 開発・保守費 | 双方向 | 独自ロジックが要る |
Yoomの金額は税抜、App Storeの金額はUSD建てです。表の金額にはkintone(スタンダード月1,800円×ユーザー数)とShopifyの利用料が含まれません。最小構成のキントーン かんたん連携LITEでも、kintone側10ユーザーと合わせて「月18,000円+$98」が下限です。
選ぶ順序としては、まず必要な変換ロジックを書き出してください。Shopifyとkintoneの項目の対応表を作り、すべてが1対1で対応してShopifyからkintoneへの一方向で足りるなら、連携アプリかiPaaSで間に合います。「この条件のときだけ別アプリへ」「送料は自社ルールで再計算」「kintoneの在庫をShopifyへ戻す」といった行が出てきたら、自作APIを検討する段階です。Shopify以外の相手も含めたkintone側の方式の決め方は、kintoneのデータ連携を実装視点で選ぶ|4方式の判定表とAPI制限の設計で制限値から逆算しています。
Shopify側の前提:REST Admin APIのlegacy化とGraphQL移行
REST Admin APIのlegacy化とAPIバージョンの更新周期
2024年以前に書かれた連携記事には、ShopifyのREST Admin APIを使う前提のものがあります。Shopifyの公式ドキュメントは「The REST Admin API is a legacy API as of October 1, 2024.」と書いており、2024年10月1日にREST Admin APIはlegacy扱いになりました。同じ箇所に「Starting April 1, 2025, all new public apps must be built exclusively with the GraphQL Admin API.」とあり、2025年4月1日以降の新規の公開アプリはGraphQL Admin APIだけで作る必要があります。この要件の対象は公開アプリで、自社専用のカスタムアプリについては明記されていませんが、新しく作るならGraphQLを前提にしてください。
APIのバージョンは四半期ごとに出ます。バージョン管理のページによると、各安定版は最低12か月サポートされ、2026年10月25日時点の最新安定版は2026-10です。2025-10は2026年10月16日(UTC)で提供を終えました。サポートの切れた版を指定したリクエストには、Shopifyが提供中で最も古い安定版で応答します。エラーにならないまま挙動が変わることがあるため、公式の推奨どおり四半期ごと、遅くとも半年ごとに、指定している版(Webhookの購読に設定したAPIバージョンを含む)を見直す運用を決めておいてください。
GraphQL Admin APIのレート制限
GraphQL Admin APIの制限はリクエスト数ではなく、クエリの計算コスト(ポイント)で数えます。公式のレート制限では、回復の速さが店舗のプランで決まり、Standard(Advanced・Plus以外の通常プラン)が毎秒100ポイント、Advanced Shopifyが毎秒200ポイント、Shopify Plusが毎秒1,000ポイントで、制限はアプリとストアの組み合わせごとにかかります。1つのクエリのコストはプランに関係なく1,000ポイントが上限です。商品数が多い店舗で全商品を一度に引くと、この上限で止まります。ページングで分けるか、大量取得向けのバルク操作を使ってください。クエリコストの測り方とバルクオペレーションの手順は、Shopify APIとは:Admin・Storefront・Webhookの使い分けとレート制限をコードで解説で解説しています。
Webhookで注文を受ける設計:5秒応答・再試行・重複配信
注文をすぐkintoneに反映するなら、ShopifyのWebhookで注文作成の通知を受けます。配信ルールを知らずに作ると、取りこぼしや二重登録が起きます。公式の受信ガイドとトラブルシューティングから、設計に効く仕様を抜き出すと次のとおりです。
- 応答は5秒以内:接続のタイムアウトは1秒、リクエスト全体は5秒。200番台以外は3xxも含めて失敗扱い。
- 失敗すると再試行:4時間で8回。8回続けて失敗すると、Admin APIで設定した購読(サブスクリプション)は自動で削除され、アプリの緊急連絡用メールアドレスに警告メールが届く。
- 重複して届くことがある:ネットワークのタイムアウトや再試行のあとに同じ通知が再び届く。処理を冪等にするのが基本で、冪等にできない場合は
X-Shopify-Webhook-Idヘッダーで重複を判定する。 - 署名を検証する:
X-Shopify-Hmac-SHA256ヘッダーに、アプリのクライアントシークレットと生のリクエストボディから作ったHMACが入る。JSONとして解析する前の生のボディで検証する。 - 順序は保証されない:同じトピックの中でも、同じリソースの別トピック間でも、届く順番は前後する(公式の例は
products/updateがproducts/createより先に届くケース)。
この仕様から導ける設計は2点です。1点目は、受信したらすぐ200を返し、kintoneへの書き込みは後で行うことです。kintone側が混んでいて書き込みに5秒以上かかると、Shopifyは失敗とみなして再送し、最後は購読を消します。2点目は、重複して届いても結果が変わらない書き込み方にすることです。kintoneの複数のレコードを更新するAPIには upsert: true のUPSERTモードがあります。updateKey に指定したフィールドの値が一致するレコードがあれば更新し、無ければ新規登録します。updateKey に使えるのは重複禁止を設定した「文字列(1行)」か「数値」フィールドだけです。そこでkintoneアプリにShopifyの注文IDを入れる重複禁止フィールドを作り、そこをキーにUPSERTします。こうすれば、同じ注文の通知が2回届いてもレコードは1件のままです。注文の更新(orders/updated)も受ける場合は、順序が前後して古い内容で上書きされないよう、Shopifyの updated_at をkintoneにも保存し、届いた通知の方が古ければ書き込まないようにしてください。
次のコードはNode.js(Express)での最小構成です。署名を検証して200を返し、注文をキューに積んで、10秒ごとに100件ずつkintoneへUPSERTします。kintoneが429や5xxを返したとき、または通信に失敗したときは、その分をキューに戻して次の回に送り直します。400などの入力エラーは再送せずログに残します。入力エラーは何度送っても結果が変わらず、再送を続けるとキューの先頭に居座って後続の注文を止め、1日のリクエスト数だけを消費するからです。
const express = require('express');
const crypto = require('crypto');
const app = express();
const SECRET = process.env.SHOPIFY_CLIENT_SECRET;
const KINTONE = process.env.KINTONE_BASE;
const queue = [];
app.post('/webhooks/orders-create', express.raw({ type: '*/*' }), (req, res) => {
const digest = crypto.createHmac('sha256', SECRET).update(req.body).digest();
const header = Buffer.from(req.get('X-Shopify-Hmac-SHA256') || '', 'base64');
if (header.length !== digest.length || !crypto.timingSafeEqual(digest, header)) {
return res.sendStatus(401);
}
queue.push(JSON.parse(req.body.toString('utf8')));
res.sendStatus(200); // 5秒以内に返し、kintoneへの書き込みは後で行う
});
async function flush() {
const batch = queue.splice(0, 100); // kintoneの1リクエスト上限は100件
if (batch.length === 0) return;
const records = batch.map((o) => ({
updateKey: { field: 'order_id', value: String(o.id) }, // 重複禁止フィールド
record: {
order_name: { value: o.name },
total_price: { value: o.total_price },
},
}));
let r;
try {
r = await fetch(`${KINTONE}/k/v1/records.json`, {
method: 'PUT',
headers: {
'X-Cybozu-API-Token': process.env.KINTONE_API_TOKEN,
'Content-Type': 'application/json',
},
body: JSON.stringify({ app: Number(process.env.KINTONE_APP_ID), upsert: true, records }),
});
} catch (e) {
queue.unshift(...batch); // 通信エラーも戻して次回に再送
throw e;
}
if (r.status === 429 || r.status >= 500) {
queue.unshift(...batch); // 一時的な失敗だけ戻して次回に再送
} else if (!r.ok) {
console.error('kintone', r.status, await r.text(), batch.map((o) => o.id)); // 400などは再送せず記録
}
}
setInterval(() => flush().catch(console.error), 10000);
app.listen(3000);
このコードは、Express 5とNode.js 26で、kintoneの代わりに立てたモックサーバーに向けて動かしています。正しい署名には200、不正な署名とヘッダー無しには401を返しました。モックが429を返すと同じ注文を次の回に再送し、400を返すと1回だけ送ってログに残し、モックを止めている間に届いた注文は再起動後に送りました。KINTONE_BASE には https://<サブドメイン>.cybozu.com を入れます。注文IDを入れる order_id フィールドには、kintone側で重複禁止を設定してください。実運用では、メモリ上のキューはプロセスの再起動で消えるため、データベースやメッセージキューに置き換えます。署名検証と冪等性の考え方はWebhookの作り方と実装方法|受信側の署名検証・冪等性と送信側の再送をNode.js・Pythonで解説で詳しく扱っています。
kintone側のAPI制限と同期設計への影響
kintoneのREST APIには、公式の概要ページに制限事項がまとまっています。連携の設計に効くのは次の4つです。
| 制限 | 値 | 設計への影響 |
|---|---|---|
| 同時リクエスト数 | 1ドメイン100まで | 並列で投げすぎない |
| 一度に登録・更新・削除 | 1リクエスト100件まで | 100件ずつに分ける |
| offsetで指定できる件数 | 10,000件まで | 全件取得はカーソルAPI |
| 1日のリクエスト数 | 1アプリ1万件(ワイドは10万件) | 定期実行の間隔を詰めない |
最も影響が大きいのは同時リクエスト数です。cybozu developer networkの解説によると、101件目以降のリクエストはエラーになり、原因となったアプリだけでなくドメイン全体でREST APIがエラーになります。応答はHTTP 429です(同時接続数の制限値の解説)。Shopifyでセールを開始した直後のように注文が集中するとき、Webhookを受けるたびにkintoneを並列で呼ぶ作りだと、連携とは関係のない社内の他のkintoneアプリやプラグインまで巻き込んで止まります。上のコードでキューに積んで間隔を空けて書き込んでいるのはこのためです。
取得では、offsetで指定できる件数の上限10,000件が設計を縛ります。「毎晩kintoneの全レコードとShopifyの全注文を突き合わせて洗い替える」という作りは、データが1万件を超えた時点で破綻します。差分は更新日時で絞って取り、1万件を超える一括取得が必要なときはカーソルAPI(レコードの一括取得)を使ってください。
1日のリクエスト数は、スタンダードコースなら1アプリ1万件です。リセットは日本時間の毎日9時で、上限を超えると翌日の9時ごろに超過メールが届きます。1分ごとに未処理の注文を確認する定期実行を組むと、確認だけで1日1,440回を使います。Webhookを起点に必要なときだけkintoneを呼び、100件ずつまとめて書き込む構成なら、注文が1日数千件でも上限まで余裕が残ります。
採用すべきでない場面と失敗パターン
連携が割に合わない場面もあります。注文が1日数件で、担当者1人がShopifyの管理画面で処理できているなら、連携を入れる価値は薄いです。kintoneがライトコースなら、コース変更の差額(10ユーザーで月8,000円)と連携の費用が上乗せされます。手作業のほうが安い規模で、Shopifyのバージョン追随や認証情報の更新、失敗時の再送といった運用まで背負う必要はありません。
起きやすい失敗は次の4つです。1つ目は、在庫の正をどちらに置くか決めないまま双方向同期を組むケースです。Shopifyとkintoneの両方から在庫を更新できる状態にすると、更新の順序で数量が食い違い、原因の特定に時間がかかります。在庫は片方を正とし、もう一方へは書き戻すだけにしてください。在庫の引当と配分の考え方は、受注管理の仕組みと合わせて決めます(EC受注管理システムとは?多店舗一元管理の機能・費用相場と導入判断を解説)。
2つ目は全件同期です。offsetが10,000件を超えるとその先のレコードを取得できなくなり、1日のリクエスト数も上限を超え続けると、サイボウズからの確認やAPI処理の中断の対象になります。3つ目は、Webhookの購読が消えたことに気づかないケースです。受信側の障害が続いて8回の再試行がすべて失敗すると、Admin APIで設定した購読は削除され、障害が直ったあとも注文が届かないままになります。警告メールの宛先になる緊急連絡用メールアドレスを実際に読まれる宛先にし、注文が一定時間届かないときに通知する監視も用意してください。公式も、Webhookだけに頼らず定期的にAPIでデータを取り直す突き合わせ処理を置くよう案内しています。updated_at で絞ってGraphQL Admin APIから注文を取り直し、kintoneと照合すれば取りこぼしを拾えます。4つ目は、失敗した分の扱いを決めていないケースです。429やタイムアウトで落ちた注文をどこに記録し、いつ再送するかを決めていないと、注文の欠けに気づくのが顧客からの問い合わせ時になります。連携用とは別に、失敗した注文を溜めるkintoneアプリを用意しておくと、担当者が画面で再送の要否を判断できます。連携方式の選定から実装・運用まで外部に任せたい場合は、API開発・システム連携の支援もご覧ください。
よくある質問
Shopifyとkintoneは標準機能だけで連携できますか?
できません。両サービスに互いを直接つなぐ標準機能はなく、kintoneの公式オプション「連携コネクタ」もMicrosoft 365向けです。Shopifyアプリ「キントーン かんたん連携 | THRIVEX」などの連携アプリ、YoomなどのiPaaS、自作APIのいずれかを選ぶことになります。
kintoneのライトコースでもShopifyと連携できますか?
できません。kintoneの料金表では、外部サービス連携とプラグインはスタンダードコースとワイドコースの機能で、ライトコースでは使えません。スタンダードコースは1ユーザー月1,800円(税抜)、最小ユーザー数は10です。
Shopifyとkintoneの連携にかかる費用はいくらですか?
手段によって変わります。キントーン かんたん連携は月$98(商品・顧客・注文)か月$198(タグ・メタフィールドも連携)で、無料プランは設定のみです。shopikinは初期300,000円・月30,000円から、Yoomは新プランならミニプランの月20,000円(税抜)からです。いずれもkintoneの利用料(スタンダード月1,800円×最低10ユーザー)が別にかかります。自作APIは開発費と保守費が中心になります。
kintoneのAPI制限に引っかかるとどうなりますか?
同時リクエストが1ドメインにつき100を超えるとHTTP 429が返り、原因となったアプリだけでなくドメイン全体のREST APIがエラーになります。1アプリあたりの1日のリクエスト数(スタンダードは1万件)を超えてもリクエストはエラーになりませんが、翌日9時ごろに超過メールが届き、他の利用者に重大な影響があればAPI処理を中断されることがあります。リセットは日本時間の毎日9時です。
ShopifyのREST Admin APIはまだ使えますか?
公式ドキュメントは2024年10月1日付でREST Admin APIをlegacyと位置づけ、2025年4月1日以降の新規の公開アプリにはGraphQL Admin APIだけで作ることを求めています。新しく連携を作るならGraphQLを前提にしてください。APIのバージョンは四半期ごとに出て、2026年10月時点の最新安定版は2026-10です。