kintoneデータ連携の設計方法｜正本・同期方向・更新タイミングを決める

kintoneデータ連携は、よく「APIでつなぐ」「連携サービスを入れる」「CSVを自動で取り込む」という話から始まります。

しかし、接続方法から入ると、あとで高い確率で詰まります。

顧客名はCRMとkintoneのどちらで直すのか。

商品単価は販売管理とkintoneのどちらが正しいのか。

請求金額は会計へ送った後にkintoneで修正してよいのか。

集計用のBIに出したデータを、現場が戻してよいのか。

外部システムで更新された値とkintoneで更新された値が衝突したら、どちらを優先するのか。

夜間バッチが失敗したら、どのレコードから再実行するのか。

こうした決めごとがないままデータを流すと、連携は動いているのに業務データは信用できない、という状態になります。

よくある失敗は、次のようなものです。

顧客マスタをCRMから取り込んだが、kintone側でも同じ顧客を手修正している。

商品マスタを外部から同期したが、kintone側の見積明細に古い単価が残っている。

案件データをBIへ出しているが、未承認の見込み金額まで経営レポートに載っている。

外部から受注データを取り込んだが、同じ注文番号を再取込して二重登録している。

全件同期を毎朝走らせて、件数増加とともに処理時間が伸びている。

API制限に当たっても、どの連携が失敗したか分からない。

双方向同期にした結果、古い外部データでkintoneの最新値が上書きされる。

CSV取込、GAS、iPaaS、個別API、ETL、外部DBが混ざり、どれが正式な連携なのか分からなくなる。

kintoneデータ連携で最初に決めるべきなのは、接続方法ではなく、データ種別ごとの正本、同期方向、更新タイミング、更新キーです。

この記事では、kintoneデータ連携を、マスタデータ、取引データ、履歴データ、集計データに分け、片方向同期、双方向同期、リアルタイム連携、バッチ連携、API制限、差分処理、更新競合、再実行、連携サービスの使い分けまで整理します。

kintone連携の設計方法はこちら
kintone外部連携の設計方法はこちら
kintone API制限の設計方法はこちら

データ連携は正本を決めることから始める

データ連携は、データを移動させる作業ではありません。

どのシステムを正本にするかを決める作業です。

正本とは、業務上「この値が正式」と判断する場所です。

たとえば、顧客情報の正本がCRMなら、kintoneの顧客名や住所は参照値です。

商品マスタの正本が販売管理なら、kintoneで商品名や標準単価を自由に直してはいけません。

請求データの正本が会計なら、会計へ送信した後の金額修正は、kintoneだけで完結させない設計にします。

一方、案件進捗や社内確認の正本がkintoneなら、外部の集計表や通知先で状態を直さないようにします。

データ	正本になりやすい場所	kintone側の役割
顧客マスタ	CRM、販売管理、kintone	参照、営業管理、社内補足
商品マスタ	販売管理、基幹システム	見積、案件、在庫確認の参照
案件データ	kintone、SFA	現場進捗、承認、履歴
受注データ	販売管理、EC、kintone	取込、確認、出荷連携
請求データ	会計、販売管理	承認前確認、送信履歴、差戻し
集計データ	BI、データ基盤、kintone	現場確認、月次会議、異常値確認

正本を決めないと、同期方向が決まりません。

「どちらからどちらへ流すか」が決まらないまま双方向にすると、衝突が起きます。

また、正本を決めないと権限も決まりません。

kintone側で編集できる項目と、外部から取り込むだけの項目を分けられないためです。

正本が決まると、編集できる場所、参照だけにする場所、戻してよい項目、戻してはいけない項目が決まります。

マスタ・取引・履歴・集計データを分ける

kintoneデータ連携では、すべてのデータを同じ扱いにしないことが重要です。

データ種別によって、更新頻度、正本、履歴の持ち方、連携の危険度が違います。

まず、次の4種類に分けます。

種別	例	連携で決めること
マスタデータ	顧客、商品、部門、担当者	正本、外部ID、変更反映、廃止扱い
取引データ	案件、受注、請求、入金	状態、承認、送信条件、取消
履歴データ	対応履歴、変更履歴、連携ログ	追記か上書きか、保存期間
集計データ	月次集計、BI、管理表	集計粒度、更新頻度、閲覧権限

マスタデータは、更新頻度は高くないものの、影響範囲が広いです。

顧客名、商品名、単価、部門名が変わると、多くのアプリや帳票に影響します。

そのため、マスタ連携では外部IDを必ず持たせます。

取引データは、状態管理が重要です。

未承認、承認済み、送信済み、取消、差戻しなどの状態によって、外部へ渡してよいかが変わります。

履歴データは、原則として上書きより追記が向いています。

対応履歴、送信履歴、エラー履歴を上書きすると、後から原因を追えません。

集計データは、正確さと速報性を分けて考えます。

現場確認用の速報値と、月次確定後の正式値を同じものとして扱うと、会議で数字が揺れます。

kintoneとリレーショナルデータベースの違いはこちら
kintoneデータベース設計はこちら

片方向同期と双方向同期の判断

データ連携は、できるだけ片方向に寄せます。

片方向同期は、正本から参照先へ流す設計です。

たとえば、販売管理の商品マスタをkintoneへ取り込む。

kintoneの承認済み請求データを会計へ渡す。

kintoneの案件データをBIへ出す。

こうした連携は、どちらが正しいかが比較的はっきりしています。

一方、双方向同期は難度が上がります。

kintoneでもCRMでも顧客情報を更新する。

kintoneでも外部SaaSでも商談状態を更新する。

kintoneでもスプレッドシートでも金額を直す。

このような設計では、更新競合が起きます。

同期方向	向いているケース	注意点
外部からkintoneへ片方向	商品、顧客、受注、勤怠、会計科目	kintone側の編集制御
kintoneから外部へ片方向	承認済み請求、帳票、BI、通知	出力条件と送信済み管理
双方向同期	顧客補足、商談状態、問い合わせ状態	対象項目、優先順位、競合処理
通知だけ	ステータス変更、エラー、承認依頼	通知後の処理責任

双方向同期にする場合は、対象項目を絞ります。

すべての項目を双方向にしないことです。

顧客名や請求先住所はCRMが正本。

kintone側の社内メモや対応ステータスだけ戻す。

このように、項目ごとに責任を分けます。

項目	正本	同期方向
顧客名	CRM	CRMからkintone
請求先住所	CRMまたは会計	CRMからkintone
社内ランク	kintone	kintoneからCRM
最終対応日	kintone	kintoneからCRM
メール配信停止	MA	MAからkintone

双方向同期は「便利だから」ではなく、「業務上どうしても両側で更新する必要があるから」採用します。

リアルタイム連携とバッチ連携の違い

データ連携では、更新タイミングも重要です。

リアルタイムに近い連携が必要なものと、一定時間ごとのバッチで足りるものがあります。

リアルタイム連携が向いているのは、次のような処理です。

問い合わせ登録後、すぐ担当者へ通知する。

承認済みの発注依頼をすぐ購買担当へ渡す。

緊急度の高い障害やクレームを外部の通知先へ送る。

一方、バッチ連携で足りるものも多いです。

毎朝、前日分の受注を取り込む。

毎晩、顧客マスタの差分を反映する。

月次締め後に請求データを出力する。

週次でBIへ集計用データを渡す。

タイミング	向いている処理	設計ポイント
即時	通知、受付、承認後の起票	失敗通知、重複防止
数分ごと	在庫確認、問い合わせ状態同期	差分条件、同時実行
日次	マスタ同期、受注取込、BI出力	実行時間、件数、再実行
月次	請求、会計、管理会計	締め状態、確定後修正

即時連携にすれば、すべてが良くなるわけではありません。

件数が多い処理を都度即時で走らせると、API制限や外部側の制限に近づきます。

また、承認前の途中データまで外へ送ってしまう危険もあります。

締めや承認がある業務では、むしろバッチの方が安全です。

kintone通知設計はこちら
kintoneワークフロー設計はこちら

API制限と差分処理

kintoneデータ連携でAPIを使う場合、API制限を設計条件として扱います。

Kintone Developer ProgramのREST API概要では、kintone REST APIのエンドポイント、認証、アクセス制限、制限事項が整理されています。

同ページでは、同時APIリクエスト数や、1アプリごとの1日あたりAPIリクエスト数などの制限も確認できます。

Kintone Developer Program：Kintone REST API Overview

データ連携で重要なのは、毎回全件を取らないことです。

件数が少ないうちは全件同期でも動きます。

しかし、レコード数が増えると処理時間が伸び、失敗時の再実行も重くなります。

差分処理では、次のような条件で対象を絞ります。

差分条件	使いどころ
更新日時	前回同期後に変わったレコードを取る
作成日時	新規登録分だけ取る
状態	承認済み、送信待ち、確定済みだけ取る
送信済みフラグ	未送信だけ処理する
外部ID有無	新規登録と更新を分ける
対象期間	今月分、前日分、締め対象だけ処理する

Get Records APIでは、検索条件や並び順を指定してレコードを取得できます。

ただし、取得件数やoffsetの扱いには制限があるため、大量データではカーソルや差分条件を前提にします。

Kintone Developer Program：Get Records

大量取得では、Cursor APIの利用も選択肢になります。

Add Cursor APIでは、取得対象の検索条件や取得フィールドを指定してカーソルを作り、Get Cursor APIで分割取得します。

Kintone Developer Program：Add Cursor

kintoneレコード数上限の考え方はこちら
kintone API上限の設計方法はこちら

更新キーと外部IDを持たせる

データ連携で最も重要なフィールドの1つが、更新キーです。

更新キーがないと、同じデータを更新すべきなのか、新規登録すべきなのか判断できません。

たとえば、外部の顧客ID、商品コード、注文番号、請求番号、連携IDなどです。

データ	更新キーの例	注意点
顧客	CRM顧客ID、取引先コード	表記ゆれではなくIDで照合する
商品	商品コード、SKU	廃番や改定をどう扱うか決める
受注	注文番号、EC注文ID	再取込時に二重登録しない
請求	請求番号、会計側ID	送信後修正と取消を分ける
問い合わせ	フォーム受付ID、チケットID	返信履歴と状態を分ける

名前やメールアドレスだけで照合すると危険です。

法人名は表記ゆれがあります。

メールアドレスは担当変更や共有アドレスで変わります。

商品名は改定で変わります。

注文番号も外部サービスごとに採番ルールが違います。

kintone側には、外部ID、最終同期日時、最終同期結果、外部更新日時を持たせます。

フィールド	目的
外部ID	外部システム上の同一データを識別する
連携元	CRM、販売管理、会計、フォームなどを分ける
最終同期日時	差分条件と再実行範囲を判断する
最終同期結果	成功、失敗、保留、対象外を分ける
外部更新日時	外部側の変更タイミングを比較する
連携エラー内容	修正担当が原因を把握する

Update Records APIでは、複数レコードの更新や、updateKeyを使った更新対象の指定ができます。

このような機能を使う場合も、業務上どの項目を更新キーにするかを先に決めます。

Kintone Developer Program：Update Records

データ連携は、更新キーを決めないまま始めると、重複登録、誤更新、再実行不能のどれかで必ず運用が苦しくなります。

更新競合と再実行の設計

データ連携では、失敗よりも更新競合の方が見えにくい問題になります。

失敗はエラーとして残しやすいです。

しかし、古い値で上書きしてしまった場合、見た目上は成功しているため気づきにくいです。

更新競合を避けるには、次を決めます。

論点	決めること
優先順位	kintoneと外部のどちらを優先するか
比較項目	更新日時、revision、状態、承認済みフラグ
対象項目	どの項目だけ外部から更新してよいか
保留条件	両側更新時に自動更新せず保留する条件
通知先	保留や失敗を誰が確認するか

kintone REST APIでは、レコード更新時にrevisionを指定して、想定した版から変わっていないかを確認できます。

これを使うと、連携処理中に別の更新が入った場合に検知しやすくなります。

ただし、revisionだけで業務上の正しさが保証されるわけではありません。

承認済み、締め済み、送信済みなど、業務状態を見て更新可否を決める必要があります。

再実行も、最初から設計します。

失敗したら最初から全件やり直す、という設計は危険です。

成功分まで重複処理する可能性があります。

連携ログに、処理対象、外部ID、処理結果、エラー内容、実行者、実行日時を残します。

ログ項目	目的
連携処理ID	同じ実行単位をまとめる
対象レコードID	kintone側の対象を追う
外部ID	外部側の対象を追う
処理種別	新規、更新、削除、取消、通知
処理結果	成功、失敗、保留、対象外
エラー内容	修正すべき原因を残す
再実行状態	未実行、再実行済み、手動対応

失敗したレコードだけを再実行できるようにしておくと、運用が安定します。

kintoneバックアップ設計はこちら
kintone一括更新の設計方法はこちら

Bulk Requestを使うときの考え方

複数のレコード操作をまとめたい場合、Bulk Request APIを使うことがあります。

Bulk Requestは、関連する複数APIを1つの処理単位として扱えるため、アプリをまたいだ登録や更新で役に立ちます。

Kintone Developer ProgramのBulk Request APIでは、複数のリクエストを指定でき、処理に失敗した場合の扱いも説明されています。

Kintone Developer Program：Bulk Request

ただし、Bulk Requestは万能ではありません。

「まとめれば安全」ではなく、「どこまでを同じ処理単位にするか」を決めるための機能です。

たとえば、受注ヘッダーと受注明細を同じ処理単位にする。

請求データと連携ログを同じ処理単位にする。

顧客マスタ更新と関連する案件更新を同じ処理単位にしない。

このように、業務上まとめるべき単位を決めます。

Bulk Requestに向く単位	理由
ヘッダーと明細の登録	片方だけ成功すると不整合になる
取込データとログ作成	成功・失敗の追跡を残したい
承認済みデータと送信済みフラグ	外部送信後の状態管理が必要

分けた方がよい単位	理由
大量マスタ全件更新	失敗範囲が大きくなりすぎる
集計データ出力	外部側で再生成できることが多い
通知だけの処理	ログを残して別処理にした方が追いやすい

Bulk Requestを使う場合も、差分条件、対象件数、失敗時の再実行単位を先に決めます。

CSV・API・連携サービス・外部DBの使い分け

kintoneデータ連携には、いくつかの実装方法があります。

すべてをAPIで作る必要はありません。

また、すべてを連携サービスに任せればよいわけでもありません。

方法	向いているケース	注意点
CSV	初回移行、月次取込、確認付き更新	手順、差分確認、戻し方
kintone標準機能	ルックアップ、関連レコード、アクション	コピーと参照の違い
連携サービス	フォーム、帳票、集計、アプリ間処理	サービスごとの得意範囲
GAS	スプレッドシートを確認画面にする処理	実行時間、権限、エラー通知
個別API	正本、差分、監査、再実行が複雑な処理	保守、監視、仕様変更
外部DB/ETL	大量データ、BI、複数システム横断	kintoneへ戻す範囲

CSVは、初回移行や確認付きの月次処理には向いています。

ただし、毎日手でCSVを出し入れする運用にすると、手順ミスが起きます。

APIは、差分同期や状態に応じた処理に向いています。

ただし、API制限、リトライ、ログ、保守担当を考えずに作ると、止まった時に直せません。

連携サービスは、特定用途では強いです。

たとえば、DataCollectはkintoneアプリ間の集計やレコード追加などを扱う選択肢になります。

DataCollect：機能紹介

CDataのkintone連携ドライバーは、BI、ETL、アプリケーションなど外部基盤からkintoneデータへ接続する選択肢になります。

CData：kintone データ連携

ただし、製品を選ぶ前に、次を決めます。

どのデータを扱うのか。

正本はどこか。

片方向か双方向か。

更新キーは何か。

失敗時に誰が直すのか。

連携ログをどこに残すのか。

この順番を守ると、ツール選定がぶれません。

kintone CSVインポートの設計方法はこちら
kintone CSV出力の設計方法はこちら
kintoneとスプレッドシートをGAS連携する設計方法はこちら

kintone内のアプリ間データ連携

kintoneデータ連携は、外部システムだけではありません。

kintone内の複数アプリ間でも、データ連携は必要です。

顧客アプリから案件アプリへ顧客情報を引く。

案件アプリから見積アプリへ案件情報を渡す。

商品マスタから明細へ商品名や単価をコピーする。

請求アプリから入金管理アプリへ対象データを作る。

こうした連携では、標準機能の役割を理解します。

機能	役割	注意点
ルックアップ	他アプリの値をコピーする	コピー後の変更反映
関連レコード一覧	条件に合う別アプリのレコードを表示する	表示でありコピーではない
アプリアクション	別アプリへ値を転記して新規作成する	更新ではなく作成が中心
計算・集計系サービス	アプリ間集計や明細計算	運用ルールと再計算条件
API	条件付き更新、複数アプリ更新	ログ、権限、失敗時対応

ルックアップは便利ですが、参照ではなくコピーです。

マスタ変更後に過去レコードへ自動反映されるものではないため、マスタ変更の扱いを決めます。

関連レコード一覧は、別アプリの情報を表示する機能です。

値を持ってくるわけではないため、帳票出力や外部連携に使う場合は注意が必要です。

アプリアクションは、別アプリにレコードを作る入口として使えます。

ただし、既存レコードの更新や複雑な同期には向きません。

kintoneルックアップ設計はこちら
kintone関連レコード設計はこちら

よくある失敗

kintoneデータ連携で多い失敗を整理します。

失敗	起きること	対策
正本を決めずに同期する	両方で修正され、どちらが正しいか分からない	データ種別ごとに正本を決める
名前で照合する	表記ゆれで重複や誤更新が起きる	外部IDやコードを持たせる
全件同期を続ける	件数増加で処理が重くなる	更新日時や状態で差分処理にする
承認前に外へ出す	外部システムに未確定データが入る	出力条件を状態で制御する
エラーを通知だけで終える	修正、再実行、確認が漏れる	エラー一覧と再実行手順を作る
双方向同期を広げすぎる	古い値で上書きされる	対象項目と優先順位を限定する
ログを残さない	いつ何を流したか追えない	連携ログアプリを作る
ツールを先に選ぶ	業務に合わない連携方式になる	正本、方向、頻度、失敗時対応から決める

特に危険なのは、「成功したように見える誤更新」です。

APIはエラーを返していない。

連携ログも成功になっている。

しかし、古い外部データでkintoneの値を上書きしている。

この状態を防ぐには、更新前の比較と、更新後の確認が必要です。

重要なデータでは、即時上書きではなく、差分確認アプリを挟む設計も有効です。

確認方法	向いている場面
自動更新	明確な外部IDと正本があるマスタ
差分確認後に更新	金額、住所、請求先、担当変更
承認後に送信	請求、発注、契約、返金
保留一覧で確認	両側更新や不一致があるデータ

実装前チェックリスト

kintoneデータ連携を実装する前に、次を確認します。

観点	確認すること
データ種別	マスタ、取引、履歴、集計を分けたか
正本	どのシステムが正式値を持つか
同期方向	片方向か双方向か、項目ごとに決めたか
更新キー	外部ID、コード、注文番号などがあるか
タイミング	即時、数分ごと、日次、月次のどれか
差分条件	全件ではなく対象を絞れるか
状態条件	承認済み、送信待ち、確定済みを分けたか
API制限	リクエスト数、同時実行、分割処理を見たか
競合処理	両側更新時の優先順位を決めたか
ログ	成功、失敗、保留、再実行を追えるか
権限	参照だけの項目と編集できる項目を分けたか
保守	誰が設定、監視、再実行、仕様変更を担当するか

このチェックが埋まると、API、CSV、連携サービス、外部DBのどれを選ぶべきかが見えます。

逆に、このチェックが埋まらない状態で実装すると、動作確認は通っても、運用開始後に崩れます。

Bitlightに相談できること

Bitlightでは、kintoneデータ連携を、ツール選定ではなく業務データ設計から支援できます。

たとえば、次のような相談に対応できます。

顧客、商品、案件、請求、履歴、集計の正本整理。

kintoneとCRM、会計、販売管理、BIの同期方向設計。

外部ID、更新キー、連携ログ、再実行アプリの設計。

CSV運用からAPI連携への移行。

GAS、iPaaS、個別API、外部DBの使い分け。

API制限を踏まえた差分同期、キュー、夜間バッチの設計。

承認後連携、送信済み管理、取消、差戻しの設計。

既存の連携が止まった時の調査と再設計。

単に「kintoneと外部サービスをつなぐ」のではなく、どのデータが正しく、どのタイミングで流れ、失敗時に戻せるかまで設計します。

kintoneデータ連携で重要なのは、接続先の数を増やすことではありません。

正しいデータが、正しい方向に、正しいタイミングで流れ、後から追える状態を作ることです。