---
title: "kintoneのデータ連携を実装視点で選ぶ｜4方式の判定表とAPI制限の設計"
url: "https://www.issoh.co.jp/tech/details/17178/"
published: 2026-08-31
updated: 2026-08-31
categories: ["自動化"]
publisher: "株式会社一創"
---

# kintoneのデータ連携を実装視点で選ぶ｜4方式の判定表とAPI制限の設計

kintoneのデータ連携は、つなぐ相手とデータ量を先に決めないと方式が定まりません。REST APIで直に叩くのか、プラグインに載せるのか、iPaaSを挟むのか、標準機能で済ませるのか。この記事では4方式を実装作業の量と保守の担当者という2軸で判定し、公式ドキュメントの制限値から件数の分岐点を割り出します。kintone自体の機能や料金は[kintoneとは？できること・料金・プラグインからノーコードで内製する判断まで解説](https://www.issoh.co.jp/column/details/15084/)に譲り、以下は連携の実装だけを扱います。数値は2026年8月時点の実測です。

## まとめ：kintoneのデータ連携は4方式のうち3つで決着する

結論を先に置きます。現実的に残る選択肢は、iPaaS経由・REST APIの自社実装・標準機能の3つです。プラグインは連携そのものの手段ではなく、REST APIの実装を画面に載せて配布するための器なので、方式選定の第一階層では外して考えたほうが判断が速く進みます。

分岐は件数で引けます。1日の処理件数が数十件で、つなぐ相手が主要SaaSなら、iPaaSを挟むのが工数と保守の両面で妥当な選択です。日次で数千件を超える、または基幹システムとの双方向で整合を揃えたいならREST APIの自社実装へ寄せてください。アプリ間で値を持ってくるだけならルックアップと関連レコード一覧で足りますが、この2つはコピー元の変更に追随しない仕様です。

最初に見るべき数値は3つです。1日のAPIリクエスト数がスタンダードコースで1アプリ10,000件、一度に取得できるレコードが500件、一度に登録・更新・削除できるレコードが100件。この3つを業務件数へ当てはめるだけで、方式の候補は半分に絞れます。

## kintoneのデータ連携を分ける4方式と担当者・費用の置き場所の違い

4方式は技術的な難易度で並んでいるのではありません。実装物をどこに置き、誰が保守するかで分かれます。取り違えると、誰も触れない資産が増えます。

| 方式         | 実装物の置き場所    | 向く件数    | 保守の担当  |
| ---------- | ----------- | ------- | ------ |
| 標準機能       | アプリ設定       | アプリ間の参照 | 現場の管理者 |
| iPaaS      | iPaaS側のフロー  | 1日数十件まで | 現場＋情シス |
| プラグイン      | kintone内に配布 | 画面操作の起点 | 開発側    |
| REST API実装 | 自社サーバー      | 日次数千件以上 | 開発側    |

### REST APIで直に叩く方式が向く条件と必要になる実装作業の範囲

REST APIは、kintoneのレコードをHTTPで操作する方式です。認証はAPIトークンかパスワード認証を選び、アプリ単位でトークンを発行して権限を絞ります。取得・登録・更新・削除のほかファイル操作も揃うため、外部システム側の都合に処理を合わせられます。

向くのは3つの条件が重なる場面です。件数が多い、変換ロジックが業務固有で複雑、失敗時の再実行やログを自社の運用基準へ揃えたい。この3つが揃うなら自社実装のほうが読めるコードになります。1つしか当てはまらないなら、実装と保守の人件費が先に効いてきます。

見落とされがちなのが、成功したかどうかの記録と再実行の入口です。APIを呼ぶコードは1日で書けますが、失敗分だけを流し直す入口がないと障害のたびに手作業が発生します。連携1本の工数は、この周辺のほうが大きくなります。

### プラグイン方式が受け持つ範囲と配布・保守で発生する作業の実際

プラグインは、JavaScriptとCSSをまとめてkintoneへ配布する仕組みです。連携処理そのものはREST APIかWebhookで実現するため、その処理を画面のボタンや保存時のイベントへ紐づけ、設定値を管理者が変えられるようにする器と捉えるのが実態に近い理解になります。manifestの構成や配布手順は[kintoneプラグイン開発とは｜manifest構成から配布・内製外注の判断まで](https://www.issoh.co.jp/tech/details/15327/)で扱っています。

この方式が効くのは、同じ連携処理を複数アプリへ横展開する場合と、接続先のURLや認証情報をアプリごとに変えたい場合です。1つのアプリで完結するならJavaScriptカスタマイズのままでも運用は回ります。

注意したいのは、画面が起点になるという制約です。プラグインのJavaScriptはブラウザでアプリを開いたときにしか動きません。夜間バッチや外部からの一括更新は扱えず、サーバー側の実装が別に必要です。この線を引かずに設計すると、後から作り直しになります。

### iPaaS経由の連携が吸収する部分と自社に残る責任の線引きの目安

iPaaSは、SaaS間の接続とデータの受け渡しを画面上のフロー定義で組む方式です。認証情報の保管、API差異の吸収、リトライや実行ログが製品側に揃うため、自社で書くコードはゼロに近づきます。分類の定義とRPAとの違いは[iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説](https://www.issoh.co.jp/column/details/13373/)で整理しました。

吸収してくれない部分は3つ残ります。1つ目は業務ルールです。どのレコードをどの条件で送るかの判断はフロー定義として自社が持ちます。2つ目は課金設計です。多くの製品はレコード単位やオペレーション単位で消費が積み上がるため、件数が増えるほど費用が伸びます。3つ目は接続先の仕様変更です。標準コネクタの範囲外を独自の接続で作った場合、その追随は自社の責任範囲に残ります。

線引きの目安は、フローの本数と分岐の数です。連携が5本以内、1本あたりの分岐が5本以内なら現場が持てる規模に収まります。それを超えると棚卸しと命名規則の統制が必要になり、実質的に情報システム部門の運用対象へ変わります。方式の上位判断は[iPaaSとETLの違いを実装視点で判定｜連携方式5種の選定表と分岐条件](https://www.issoh.co.jp/tech/details/16495/)と併せて確認してください。

## REST APIの制限値から逆算する取得・更新の設計と件数の分岐点

設計の自由度を決めているのは、性能ではなく制限値です。公式ドキュメントの数値を先に業務件数へ当てはめると、実装方針は機械的に決まります。

### 1日10,000リクエストの上限をアプリ単位で使い切らない見積り方

公式ドキュメントでは、1日に実行できるAPIリクエスト数がスタンダードコースで1アプリにつき10,000、ワイドコースで100,000と示されています。同時にリクエストできる数は1ドメインにつき100までです。上限の単位がドメインではなくアプリである点が、設計上で効いてくる部分になります。

見積りは掛け算で足ります。1回の同期で呼ぶAPIの本数に、1日の同期回数を掛けるだけです。5分間隔のポーリングで1回に3本呼ぶ構成なら、1日288回×3本で864リクエスト。手動操作やプラグインからの呼び出しが乗っても上限には余裕があります。危ないのはレコード単位のループで、1件ごとに更新と参照を呼ぶ処理を2,000件流すと、それだけで4,000リクエストに達します。

使い切らないための手は2つです。1件ずつのループを一括更新へ置き換えて呼び出し回数を削るか、参照先の値をキャッシュして呼ばずに済ませるか。前者のほうが効果が大きく、実装も単純になります。上限へ近づいたときは通知が届く仕組みがあるため、閾値の監視も運用手順に入れてください。

### 一度に500件・offset10,000件の壁とカーソルへ切り替える基準

レコードの取得では、一度に取得できるレコードが500件まで、offsetで指定できるレコードの上限が10,000件までと定められています。この2つを組み合わせると、offsetを増やしながらページングする素朴な実装は10,000件で頭を打つ構造です。1万件を超えるアプリの全件同期は、この時点で設計を変える必要があります。

切り替え先はカーソルAPIです。カーソルを作ってから順に読み進める方式で、すべてのレコードを取得し終えるとカーソルは自動的に削除されます。判断基準は単純で、対象アプリが将来1万件を超えるなら最初からカーソルで組んでください。後から差し替えると、取得順序と重複の扱いを作り直すことになります。

```
{
  "app": 100,
  "fields": ["レコード番号", "顧客コード", "更新日時"],
  "query": "更新日時 >= TODAY() order by レコード番号 asc",
  "size": 500
}
```

全件を毎回流す設計そのものを避けられる場合もあります。更新日時で絞る差分取得にすれば、対象は1日数十件に収まり、件数の壁にぶつかりません。全件同期が要るのは初回移行と突き合わせだけです。

### 登録更新100件と一括リクエスト20件でバッチを組む分割の設計

書き込み側の制限は取得側より厳しくなっています。一度に登録・更新・削除できるレコードは100件まで、一括リクエストで同時に処理できるのは最大20件までです。3,000件の更新なら100件×30回が最小構成となります。

一括リクエストには、いずれかのAPIで処理が失敗した場合はそれ以降を実行せずすべてロールバックする性質があります。複数アプリへの更新をまとめて成功か失敗かに揃えたいときに使えます。ただし1回に20リクエストまでなので、数千件を1トランザクションには収められません。

分割する場合は、どこまで成功したかを外部側に記録する形にします。100件ずつのまとまりに連番を振り、成功した連番を自社のテーブルへ書いてから次へ進む。途中で落ちても記録の次から流し直せば、重複も欠落も避けられます。

## アプリ間のデータ連携でルックアップが破れる場面と整合を保つ設計

kintoneのアプリ間連携は、標準機能だけで組めるように見えて、リレーショナルデータベースと同じ挙動を期待した瞬間に破れます。仕様を知らずに設計すると、稼働後の食い違いとして表面化します。

### コピー元の変更が追随しないルックアップの仕様と3通りの回避策

ルックアップは、コピー元アプリの値を取得してコピー先のフィールドへ書き写す機能です。押さえるべき仕様は、書き写した後にコピー元が変更されても、コピー先の値は自動では追随しない点です。参照ではなく、取得した時点の値のコピーとして保持されます。

回避策は3通りあります。1つ目は運用で解く方法です。コピー先のレコードを開いて取得ボタンを押し直します。件数が少なく変更が稀な業務なら、これで成立します。2つ目はファイル読み込みです。ルックアップのコピー対象に指定されたフィールドはファイル読み込み時に再取得される仕様なので、対象レコードを書き出して読み込み直せば一括で揃えられます。

3つ目はREST APIによる更新です。コピー元の更新をWebhookで受け、対象のコピー先レコードを検索して更新APIを呼びます。この方式だけが自動で追随しますが、実装物が増える分、方式選定の階層はREST API実装へ移ります。どれを採るかは、変更頻度と食い違いの影響で決めてください。

### 関連レコード一覧で集計を作ろうとして詰まる場面と代替の置き方

関連レコード一覧は、条件に合う他アプリのレコードを画面へ表示する機能です。表示は動的なので値の追随は問題になりません。詰まるのは、一覧を数値として扱いたくなったときです。

典型は取引先ごとの受注金額の合計を顧客アプリに持ちたいという要件です。関連レコード一覧は表示の機能なので、並んだ金額を自アプリの計算フィールドの入力には使えません。一覧では見えているのに集計に使えない状態が、設計のやり直しを招きます。

代替は2通りです。集計値を持つ専用のフィールドを用意し、明細側の追加・更新・削除を契機にREST APIで書き戻す。あるいは集計をkintoneに持たず、外部のデータベースやBIツール側で出す。集計の粒度が固定で、画面で即座に見たい要件なら前者を選びます。

### kintone側に置く正データと外部マスタの主従を決めるときの判断

外部システムとつなぐ場合、同じ意味のデータが両側に存在する状態が生まれます。顧客マスタが基幹システムとkintoneの両方にある構成です。ここで主従を決めずに双方向同期を組むと、どちらの更新が勝つかが実行順序で変わる不安定な状態になります。

判断の基準は、そのデータを業務上どこで登録するかに置きます。与信や取引条件を含む顧客マスタは基幹側が主で、kintoneは読み取り専用の写しにする。案件の進捗や現場のメモはkintoneが主とする。項目単位で主従を分けるのが現実的な設計です。

主従を決めたら、従側での編集を機能として塞いでください。アクセス権でフィールドを編集不可にする形が確実です。運用のお願いで済ませると必ず破られます。特定のペアでの設計例は[ShopifyとkintoneのAPI連携｜手段の選び方・実現できることとAPI制限の設計【2026年版】](https://www.issoh.co.jp/column/details/2341/)で扱っています。

## Webhookとポーリングの選び分けと重複・欠落を前提にした実装

kintone側の変更を外部へ伝える手段は、Webhookで押し出すかポーリングで取りに行くかの2系統です。どちらにも取りこぼしと重複が残るため、外れたときの受け止め方まで設計に含めます。

### Webhookの即時性と取りこぼしをどこで補うかの二重化の設計

Webhookが通知を送る契機は、レコードの追加・編集・削除、コメントの書き込み、プロセス管理のステータス更新です。イベントが起きた時点で通知が飛ぶため反映は速く、ポーリングのような無駄な問い合わせも発生しません。

弱点は、受信側が落ちていた場合や通知が届かなかった場合の扱いです。再送の挙動やタイムアウトは公式ドキュメントの当該ページに明記がないため、届かない可能性を織り込んで組むのが安全側の判断になります。実務での構成はこうです。Webhookを即時反映の主経路にしつつ、1日1回の差分ポーリングを保険として並走させる。更新日時で絞った差分取得なら、コストはリクエスト数本で済みます。

もう1つの注意は、通知の中身が軽いことです。届いた通知をきっかけに、対象レコードを取得APIで読み直す作り方にしてください。通知の値だけで処理を組むと、順序が入れ替わったときに古い値で上書きします。

### 冪等キーを業務キーに持たせて二重実行に耐える更新処理の作り方

重複起動は避けられない前提で設計します。同一のURLが複数登録されていた、JavaScriptによる自動処理が編集イベントとして検知された、処理内での再編集が新しい通知を生んだ。原因は複数あり、どれも設定と実装の組み合わせで起きます。iPaaSを挟んだ場合の重複起動と無限ループの回避手順は[Yoomとは？国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】](https://www.issoh.co.jp/tech/details/15962/)で扱いました。

自社実装で耐性を持たせる手は、業務キーを一意キーとして外部側に持つことです。レコード番号や伝票番号を外部システムの一意制約に使い、登録ではなく存在すれば更新という形へ寄せる。同じ通知が2回届いても同じ状態に収束します。

取り消せない副作用を持つ処理は別扱いにします。メール送信や決済のような操作は、実行前に送信済みの記録を確認する分岐を挟んでください。加えてkintone側に処理済みフラグのフィールドを1つ持たせ、通知を受けた直後に判定して抜ける形にすると、無限ループも塞げます。フラグの更新自体が新しい通知を生むため、その通知はフラグ判定で必ず止まる順序に組むのが要点です。

## 基幹システムとkintoneをつなぐ受託実装の分岐と見送るべき条件

ここからは他社の解説記事が踏み込まない部分を、条件を付けて言い切ります。どの方式でも組めるからこそ、寄せる場所を間違えると運用が壊れます。

### 連携をkintone側に寄せず基幹システム側へ寄せるべき3つの条件

1つ目の条件は件数です。日次で数千件を超えるレコードの同期をkintone側に寄せるべきではありません。理由は性能ではなく制限値の構造にあります。書き込みが100件単位、1日のリクエストがアプリ単位で10,000という枠で数千件を動かすと、業務の成長余地を先に食い潰します。

2つ目が整合の要求です。複数システムへの更新をどれか失敗したら全部戻す形に揃えたい業務は、一括リクエストだけでは収まりません。20リクエストの枠を超える範囲は補償処理を自前で書くことになり、基幹側でトランザクションを張る実装より複雑になります。

3つ目が変換ロジックの重さです。単価計算や在庫引当のように、参照するマスタが多く例外分岐が十数通りに広がる処理をフローやJavaScriptへ載せると、テストが書けない資産になります。この3条件のいずれかに当てはまるなら、kintoneは入力と閲覧の画面に留めてください。内製と外注の費用感は[kintone開発とは？カスタマイズ手段・費用相場・内製と外注の判断まで解説](https://www.issoh.co.jp/column/details/15784/)が判断材料になります。

### iPaaSで始めてREST API実装へ移す切り替えのサインと移行手順

現実的な進め方は、iPaaSで始めて必要になった部分だけを実装へ移す形です。最初からREST API実装で組むと、要件が固まる前に工数を払います。まずフローで動かし、業務ルールが安定してから移す順序が見合います。

切り替えのサインは3つです。月間の消費量が契約プランの上限に近づいた、上限のためにフローを3本以上へ分割した、同じフローの改修を月2回以上行っている。いずれかに当てはまる連携は、ノーコードで持ち続ける前提を見直す段階に来ています。

移行は、フロー全体を一度に置き換えないのが要点です。件数が多い1本だけを実装へ移し、残りはフローに置いたまま並走させる。切り替え当日は両方を動かして結果を突き合わせる。この段取りなら業務を止めずに移せます。一創では[iPaaS導入支援（Zapier／Make／Workato／Yoom）](https://www.issoh.co.jp/service/rpa/ipaas/)として、連携の棚卸しから実装へ切り出す業務の切り分けまで対応しています。

### kintoneをデータ連携のハブにしてはいけない場面と代わりの構成

やりがちな構成が、kintoneを中継地点にして複数システムをつなぐ形です。画面で中身が見えるので運用者には歓迎されますが、この構成は制限値を二重に消費し、片方が落ちたときの再送の起点も曖昧になります。

kintoneがハブとして成立するのは、中継したデータを人が確認・修正する工程が業務として存在する場合だけです。人が触らず素通りするだけなら、システム間を直接つなぐか、連携基盤側でデータを保持する構成へ変えてください。

代わりの構成は2つです。件数が少なくSaaS同士ならiPaaSで直結し、kintoneは参照用の写しを持つだけにする。件数が多いか変換が重いなら、中間にデータベースを1つ置いて、そこを正とする。どちらの場合も、kintoneに置くのは人が見る必要のあるデータだけに絞るのが判断の軸になります。

## よくある質問

連携の設計で実際に多い質問を、公式ドキュメントで確認できる範囲で答えます。

### kintoneのデータ連携は追加費用なしで実現できますか？

標準機能とREST APIの利用自体に追加費用はかかりません。ルックアップや関連レコード一覧はアプリ設定の範囲で組め、REST APIもコースに応じた枠内で呼べます。費用が発生するのは、iPaaSを挟む場合の製品利用料と、自社実装を置くサーバーおよび開発の工数です。

### REST APIとプラグインはどちらを先に検討すべきですか？

連携方式としてはREST APIを先に検討します。プラグインは処理を画面イベントへ紐づけて配布する器であり、連携そのものはその中でREST APIを呼ぶためです。プラグイン化を先に決めるのは、同じ処理を複数アプリへ横展開する場合に限られます。

### kintoneのアプリ間でリアルタイムに同期できますか？

標準機能では実現できません。ルックアップはコピー元の変更に自動追随しない仕様で、関連レコード一覧は表示のみを担います。追随が要るなら、レコード編集を契機にWebhookで通知を受け、REST APIで更新する処理を置きます。通知の遅延と重複は残るため、冪等な更新として組んでください。

### 数万件のデータをkintoneへ移行するときの手順はどうなりますか？

初回はファイル読み込みで入れ、APIは差分の追随に使う分担が扱いやすくなります。APIで入れる場合は一度に登録できるレコードが100件までなので、3万件なら300回の分割となり、1日のリクエスト上限との兼ね合いを先に計算してください。突き合わせでは全件取得が要るため、カーソルAPIを前提に組みます。

### 外部システムからkintoneを更新すると通知や自動処理は動きますか？

Webhookはレコードの追加・編集・削除で通知が飛ぶため、外部からの更新でも契機になります。一方でプラグインやJavaScriptカスタマイズはブラウザで画面が開かれたときにしか動かないので、APIによる更新では実行されません。保存時のチェック処理を画面側だけに置くと、API経由の更新が検証を素通りします。検証はサーバー側にも持たせてください。

## 関連記事

- [iPaaSとは？仕組み・RPAとの違い・主要ツールと導入判断をわかりやすく解説](https://www.issoh.co.jp/column/details/13373/)：連携方式としてiPaaSを選ぶ場合の分類と、RPAとの役割の違いを整理しています
- [Yoomとは？国産iPaaSの仕組み・料金・kintone連携の実装と採用判断【2026年版】](https://www.issoh.co.jp/tech/details/15962/)：kintone連携で起きる重複起動と無限ループの原因と回避手順を製品側の設定まで踏み込んで扱っています
- [kintoneプラグイン開発とは｜manifest構成から配布・内製外注の判断まで](https://www.issoh.co.jp/tech/details/15327/)：連携処理をプラグインとして配布する場合のmanifest構成と配布手順を扱っています
- [ShopifyとkintoneのAPI連携｜手段の選び方・実現できることとAPI制限の設計【2026年版】](https://www.issoh.co.jp/column/details/2341/)：ECサイトという特定ペアでの手段選定と、API制限を踏まえた設計例を扱っています
- [iPaaSとETLの違いを実装視点で判定｜連携方式5種の選定表と分岐条件](https://www.issoh.co.jp/tech/details/16495/)：kintoneに限らない連携方式全体の選定表と、方式ごとの実装責任の境界を扱っています

---

出典: [kintoneのデータ連携を実装視点で選ぶ｜4方式の判定表とAPI制限の設計](<https://www.issoh.co.jp/tech/details/17178/>)（株式会社一創）