kintoneアプリ間データ連携の設計方法｜ルックアップ・関連レコード・APIの使い分け

kintoneアプリ間データ連携でよくある相談は、次のようなものです。

顧客アプリの情報を案件アプリに入れたい。

案件アプリから活動履歴アプリを作りたい。

顧客レコードに、その顧客の案件一覧や請求一覧を表示したい。

商品マスタの単価を見積明細へ持ってきたい。

請求アプリの金額を顧客アプリに合計表示したい。

案件が受注になったら、受注アプリや請求アプリへデータを作りたい。

複数アプリに散らばったデータを集計アプリへまとめたい。

一見すると、すべて「アプリ間でデータをつなぎたい」という同じ相談に見えます。

しかし、必要な設計はまったく違います。

コピーするのか。

表示するだけなのか。

ユーザー操作で転記するのか。

自動で同期するのか。

集計結果として別アプリに持つのか。

この分類をしないままルックアップやプラグインを増やすと、アプリ間の関係が分からなくなります。

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

顧客マスタを変更しても、案件アプリにコピー済みの顧客名が変わらない。

関連レコードに表示されている請求金額を、顧客アプリの正式な合計だと思っている。

アプリアクションで作った活動履歴を、あとから元案件と同期できると思っている。

ルックアップ、アプリアクション、手入力が混ざり、どこから作られたレコードか分からない。

顧客名でアプリ間をつないでしまい、名称変更や表記ゆれで関連レコードが切れる。

集計アプリを作ったが、再計算のタイミングと対象レコードが決まっていない。

JavaScriptやAPIで同期を作ったが、失敗時に再実行できない。

アプリごとのアクセス権が違い、人によって関連レコードの見え方が変わる。

kintoneアプリ間データ連携は、最初に「コピー」「表示」「転記」「同期」「集計」を分けると、標準機能で足りる範囲とAPIや連携サービスが必要な範囲が見えます。

この記事では、kintoneアプリ間データ連携を、ルックアップ、関連レコード一覧、アプリアクション、JavaScript/API、DataCollectに分け、顧客マスタ、案件、活動履歴、請求、集計アプリの設計方法を整理します。

kintone連携の設計方法はこちら
kintoneデータ連携の設計方法はこちら
kintoneルックアップ設計はこちら

連携したいデータの種類を分ける

アプリ間連携を設計するときは、まずデータの扱いを分けます。

すべてを「連携」と呼ぶと、判断を間違えます。

やりたいこと	代表機能	データの持ち方
他アプリの値を入力時に持ってくる	ルックアップ	コピーして保存する
関連する別アプリの履歴を見たい	関連レコード一覧	表示するだけでコピーしない
今のレコードから別アプリに新規レコードを作る	アプリアクション	ユーザー操作で転記する
条件に応じて既存レコードを更新する	API、JavaScript、プラグイン	同期処理として更新する
複数アプリをまたいで合計や集計値を持つ	DataCollect、API、集計用アプリ	集計結果を保存する

kintone公式ヘルプでは、アプリ間でデータを連携する機能として、ルックアップ、アプリアクション、関連レコード一覧の3つが整理されています。

kintoneヘルプ：アプリ間でデータを連携する

この3つは似ていますが、役割は違います。

ルックアップは、他アプリのデータを検索してコピーします。

アプリアクションは、今開いているレコードの値を別アプリへ転記して新規レコードを作る導線です。

関連レコード一覧は、条件に合う別アプリのレコードを表示します。

標準機能のアプリ間連携は、同期機能ではありません。コピー、手動転記、表示を分けて使う機能です。

まずは、次のように判断します。

判断	選ぶもの
入力時点の値を保存したい	ルックアップ
過去の案件や活動履歴を見たい	関連レコード一覧
ボタンで次のアプリにレコードを作りたい	アプリアクション
条件付きで既存レコードを更新したい	API、JavaScript、プラグイン
合計、件数、ピボット、定期集計が必要	DataCollect、API、集計用アプリ

この分類が、アプリ間データ連携の土台です。

ルックアップはコピー

ルックアップは、他アプリの値をコピーして取得する機能です。

顧客コードを選ぶと、顧客名、住所、担当者、請求先などを案件アプリへ持ってくる。

商品コードを選ぶと、商品名、単価、税区分を見積明細へ持ってくる。

部門コードを選ぶと、部門名や承認者を申請アプリへ持ってくる。

こうした用途に向いています。

ルックアップに向くもの	理由
見積時点の商品名・単価	当時値として残したい
申請時点の部門名	後から組織名が変わっても申請時点を残したい
顧客番号と請求先情報	入力時点の情報を帳票や連携に使う
担当者の所属情報	申請時点の確認履歴として使う

ただし、ルックアップは参照ではありません。

コピーした値は、取得先アプリのレコードに保存されます。

参照元のマスタが変わっても、取得先の値が自動で変わる前提にしない方が安全です。

この性質は、良い面もあります。

見積作成時の単価を残したいなら、コピーして固定する方が自然です。

一方、常に最新の契約状態や最新問い合わせ履歴を見たい場合は、コピーではなく表示や集計で考えます。

kintoneヘルプ：ルックアップを設定する

kintoneルックアップ自動更新の設計はこちら

関連レコードは表示

関連レコード一覧は、条件に合う別アプリのレコードを表示する機能です。

顧客レコードに、案件一覧を表示する。

顧客レコードに、問い合わせ履歴を表示する。

案件レコードに、活動履歴や見積履歴を表示する。

請求レコードに、入金履歴を表示する。

このように、今見ているレコードの文脈で関連情報を確認する用途に向いています。

kintoneヘルプでも、関連レコード一覧は関連するレコードを一覧表示し、ルックアップやアクションと異なりコピーしない機能として説明されています。

kintoneヘルプ：関連レコード一覧を設定する

関連レコードを使うときは、紐づけキーを決めます。

顧客名ではなく顧客コード。

案件名ではなく案件番号。

商品名ではなく商品コード。

名称でつなぐと、表記ゆれや名称変更で表示が崩れます。

表示したい情報	参照元	紐づけキー
顧客ごとの案件	案件アプリ	顧客コード
顧客ごとの問い合わせ	問い合わせアプリ	顧客コード
案件ごとの活動履歴	活動履歴アプリ	案件番号
請求ごとの入金履歴	入金アプリ	請求番号

関連レコードは、データを持つ場所ではありません。

見えているだけです。

そのため、一覧画面、帳票、CSV、集計、外部連携の正本として使う場合は注意が必要です。

kintone関連レコード設計はこちら

関連レコードは「画面で見るための表示」です。合計、帳票、外部連携に使う値は、集計用アプリや明細アプリとして持つ設計を検討します。

アプリアクションは手動転記

アプリアクションは、現在開いているレコードの情報を使って、別アプリに新規レコードを作る導線です。

顧客アプリから案件アプリを作る。

案件アプリから活動履歴を作る。

案件アプリから見積依頼を作る。

問い合わせアプリから対応タスクを作る。

このような「次の作業を作る」用途に向いています。

アプリアクションに向く用途	理由
顧客から案件を作る	顧客情報を持った新規案件を作れる
案件から活動履歴を作る	案件番号や顧客情報を引き継げる
問い合わせからタスクを作る	対応内容を次のアプリに渡せる
見積から受注確認を作る	受注化の導線を明確にできる

アプリアクションは、既存レコードを自動更新する機能ではありません。

ユーザーがボタンを押して、新しいレコードを作る導線として考えます。

そのため、次のような用途には別の設計が必要です。

既存の請求レコードを更新したい。

活動履歴のステータスを元案件に戻したい。

顧客マスタの変更をすべての案件に反映したい。

条件に合う複数レコードをまとめて作りたい。

これらは、API、JavaScript、DataCollect、プラグイン、CSV一括更新などを検討します。

アプリアクションは「流れを作る」機能です。

同期ではなく、作業の入口として使います。

API・JavaScript・DataCollectが必要なケース

標準機能だけでは足りないアプリ間データ連携もあります。

たとえば、次のようなケースです。

顧客マスタ更新時に、関連する案件の一部項目を更新したい。

案件が受注になったら、請求アプリへ自動でレコードを作りたい。

活動履歴の最新対応日を顧客アプリへ反映したい。

請求アプリの未入金合計を顧客アプリへ持ちたい。

複数アプリにまたがる集計値を、定期的に集計アプリへ保存したい。

こうした場合は、コピー、表示、手動転記ではなく、同期や集計として設計します。

要件	選択肢	注意点
既存レコードを条件付き更新したい	REST API、JavaScript、プラグイン	更新キー、権限、ログ
複数アプリをまたぐ集計を保存したい	DataCollect、API、集計用アプリ	再計算条件、実行タイミング
一覧で選んだ複数レコードを作成したい	DataCollect、プラグイン、API	対象条件と重複防止
ステータス変更をきっかけに処理したい	Webhook、API、DataCollect	失敗時の通知と再実行
月次で集計値を固定したい	集計用アプリ、CSV、API	確定後修正と版管理

DataCollectでは、複数アプリを集計元にしたフィールド式、時間指定の集計実行、アプリ間レコード追加、Webhookをきっかけにした追加、ピボットテーブルなどが紹介されています。

DataCollect：機能紹介

REST APIで既存レコードを更新する場合は、更新キーやレコードIDをどう扱うかを決めます。

Kintone Developer ProgramのUpdate Records APIでは、複数レコードを更新する方法や、レコード番号または一意キーを指定する方法が説明されています。

Kintone Developer Program：Update Records

APIやJavaScriptを使うと柔軟になります。

ただし、柔軟さの代わりに、保守、権限、エラー、再実行、仕様変更への対応が必要になります。

マスタ更新と過去値保持

アプリ間データ連携で最も揉めやすいのが、マスタ更新時の扱いです。

たとえば、商品マスタの単価が変わったとします。

過去の見積明細も新単価に変えるべきでしょうか。

多くの場合、答えは違います。

見積時点の単価は過去値として固定したい。

現在の商品マスタは最新値として見たい。

この2つを分けます。

データ	過去値として固定	最新値として表示
商品名	見積明細、受注明細	商品マスタ
単価	見積時点の単価	現在の標準単価
顧客住所	請求書発行時点の住所	顧客マスタ
部門名	申請時点の部門	組織マスタ
担当者	受付時点の担当	現在の担当

ルックアップは、過去値を固定したい場面に向いています。

関連レコードは、最新の関連情報を確認する場面に向いています。

APIやDataCollectは、最新値を別アプリへ反映したい場合に使います。

ただし、反映してよい項目と、反映してはいけない項目を分けます。

反映してよい例	反映に注意する例
顧客マスタの現在担当	請求書発行済みの請求先名
商品マスタの公開停止フラグ	見積済み商品の単価
顧客ランク	契約締結時点の会社名
最新対応日	承認済み申請の部門名

マスタ更新時に「最新化する項目」と「当時値として残す項目」を分けないと、過去の見積、請求、承認履歴が後から変わってしまいます。

権限・集計・同期ログの注意点

アプリ間データ連携では、権限も重要です。

顧客アプリは営業だけ見られる。

請求アプリは経理だけ見られる。

活動履歴は担当部署ごとに見える範囲が違う。

この状態で関連レコードを表示すると、人によって見える件数が変わることがあります。

また、APIやDataCollectで集計値を作る場合、どの権限で処理するかも確認します。

観点	確認すること
アプリ権限	参照元、参照先のどちらも見られるか
レコード権限	関連レコードの表示件数がユーザーごとに変わらないか
フィールド権限	コピー・集計対象フィールドを処理者が読めるか
APIトークン	必要なアプリだけに権限を絞れているか
集計権限	集計値に含めてよいデータ範囲か

同期処理を作るなら、ログも必要です。

ログがないと、何がいつ作られたのか分かりません。

ログ項目	目的
処理ID	1回の同期処理を追う
参照元アプリ	どのアプリから来たかを残す
参照元レコードID	元データを追えるようにする
反映先アプリ	どのアプリへ作成・更新したかを残す
反映先レコードID	作成・更新先を追えるようにする
処理結果	成功、失敗、保留、対象外を分ける
エラー内容	修正担当が原因を把握する

小さなアプリ間連携でも、業務に使うならログを残します。

特に請求、契約、在庫、承認、外部連携に関わるデータは、あとから追える形にします。

kintoneセキュリティ設計はこちら
kintone API制限の設計方法はこちら

設計例：顧客・案件・活動履歴・請求をつなぐ

典型的な構成で考えます。

顧客マスタ。

案件アプリ。

活動履歴アプリ。

見積アプリ。

請求アプリ。

この5つをつなぐ場合、次のように役割を分けます。

アプリ	役割	連携方法
顧客マスタ	顧客コード、会社名、住所、担当	正本
案件アプリ	顧客に紐づく商談・進捗	顧客コードをルックアップ
活動履歴	案件ごとの打ち合わせ・電話・メール	案件からアプリアクションで作成
見積アプリ	案件に紐づく見積と明細	案件番号で関連表示、必要項目をコピー
請求アプリ	受注後の請求・入金	承認後にAPIまたは手動転記

顧客マスタ側では、関連レコードで案件一覧、活動履歴、請求履歴を表示します。

案件アプリでは、顧客情報はルックアップでコピーし、活動履歴は関連レコードで表示します。

案件から活動履歴を作る場合は、アプリアクションで顧客コード、案件番号、件名を引き継ぎます。

請求アプリへは、承認済み・受注済みの状態だけを連携対象にします。

データ	方法	理由
顧客コード、会社名	ルックアップ	案件作成時点の情報を保存
顧客の案件一覧	関連レコード	顧客画面で履歴確認
案件から活動履歴作成	アプリアクション	ユーザー操作で次の作業を作る
活動履歴の最新対応日	APIまたは集計	顧客や案件に戻すなら自動処理が必要
受注後の請求作成	API、DataCollect、手動転記	承認後だけ作成する条件が必要
顧客別請求合計	DataCollect、集計用アプリ	関連レコード表示だけでは合計値を持てない

このように、同じ顧客情報でも、コピーするもの、表示するもの、転記するもの、集計するものを分けます。

よくある失敗

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

失敗	起きること	対策
すべてルックアップでつなぐ	コピーだらけになり、どれが最新か分からない	コピーする項目を絞る
関連レコードを集計に使う	合計、帳票、CSVで詰まる	集計用アプリを作る
アプリアクションを同期扱いする	作成後の更新が追えない	作成導線として使う
顧客名や案件名で紐づける	名称変更で表示が切れる	顧客コード、案件番号でつなぐ
マスタ更新を一括反映する	過去の見積や承認履歴が変わる	当時値と最新値を分ける
APIだけで解決しようとする	保守担当しか直せない処理になる	標準機能で足りる範囲を先に使う
ログを残さない	作成・更新の経路が追えない	連携ログアプリを作る
権限を見ない	人によって表示・集計が変わる	参照元/参照先の権限を確認する

特に、既存アプリが増えている環境では、まずアプリ間の関係図を作ることが必要です。

どのアプリがマスタか。

どのアプリが取引か。

どのアプリが履歴か。

どのアプリが集計か。

どのフィールドが紐づけキーか。

どこでコピーしているか。

どこで表示しているだけか。

この棚卸しをせずに連携を増やすと、既存のずれを広げるだけになります。

実装前チェックリスト

アプリ間データ連携を実装する前に、次を確認します。

観点	確認すること
目的	コピー、表示、転記、同期、集計のどれか
正本	マスタアプリはどれか
紐づけキー	顧客コード、案件番号、請求番号などがあるか
過去値	当時値として固定する項目はどれか
最新値	最新を見たいだけの項目はどれか
権限	参照元と参照先のアクセス権が合っているか
作成導線	手動ボタンでよいか、自動作成が必要か
更新対象	既存レコードを更新する必要があるか
集計	合計や件数を保存する必要があるか
ログ	作成、更新、失敗、再実行を追えるか
保守	設定変更時に影響範囲を確認できるか

このチェックが埋まれば、どの機能を使うべきか決めやすくなります。

ルックアップで足りるもの。

関連レコードで見るだけでよいもの。

アプリアクションで作ればよいもの。

DataCollectやプラグインが合うもの。

APIやJavaScriptで作るべきもの。

それぞれを分けます。

Bitlightに相談できること

Bitlightでは、kintoneアプリ間データ連携を、機能選定ではなくアプリ構造と業務フローから設計できます。

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

既存アプリの関係図作成。

マスタ、取引、履歴、集計アプリの整理。

ルックアップ、関連レコード、アプリアクションの使い分け。

顧客コード、案件番号、請求番号などの紐づけキー設計。

マスタ更新時の再取得、当時値保持、反映範囲の整理。

DataCollect、プラグイン、API、JavaScriptの使い分け。

同期ログ、失敗通知、再実行の設計。

アクセス権を踏まえた関連レコードと集計の見直し。

アプリ間連携で重要なのは、たくさんのアプリをつなぐことではありません。

コピーしてよい値、表示だけでよい値、転記すべき値、自動同期すべき値、集計して保存すべき値を分けることです。

この整理ができると、kintoneは複数アプリに分かれていても、業務システムとして扱いやすくなります。