kintoneアプリ間レコード更新プラグインの設計方法｜同期と転記を分ける

kintoneでアプリが増えてくると、必ずアプリ間更新の相談が出ます。

案件アプリのステータスが変わったら、請求アプリも更新したい。

活動履歴を登録したら、顧客マスタの最終訪問日を更新したい。

出荷アプリで出荷済みにしたら、受注アプリの出荷状況も変えたい。

顧客マスタの担当者を変更したら、関連する案件アプリにも反映したい。

在庫アプリの数を、受注アプリや入出荷アプリの更新に合わせて変えたい。

こうした要望に対して、アプリ間レコード更新プラグインは有力な選択肢です。

ただし、便利だからこそ、設計なしに入れると危険です。

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

• どのアプリが正本か決まっていない
• 顧客名や案件名で連携し、名称変更で更新先を見失う
• 更新先に同じキーのレコードが複数あり、どれを更新するか分からない
• 更新元と更新先が互いに更新し合い、循環する
• 手動で直した値が、次の自動更新で上書きされる
• 削除連動を入れた結果、必要な履歴まで消える
• エラーになったレコードを誰も見ていない
• プラグインで足りる範囲とAPIで作るべき範囲が混ざる

アプリ間更新は、単なる転記ではありません。

別アプリのデータを書き換える以上、同期、履歴、正本、権限、エラー対応まで関係します。

kintoneアプリ間レコード更新プラグインで最初に決めるべきなのは、更新先ではなく、どのアプリのどの値を正本として扱うかです。

この記事では、kintoneアプリ間レコード更新プラグインを、製品機能の紹介ではなく、正本設計、更新キー、フィールドマッピング、作成・更新・削除・プロセス変更トリガー、循環同期、ログ、再実行、保守の設計として整理します。

kintoneアプリ間データ連携の設計方法はこちら
kintone条件分岐処理プラグインの設計方法はこちら
kintone API連携の設計方法はこちら
kintoneルックアップの設計方法はこちら

アプリ間更新は正本設計から始める

アプリ間更新で最初に決めるのは、更新元と更新先ではありません。

正本です。

正本とは、その項目について「どのアプリの値を正しいものとして扱うか」です。

データ	正本になりやすいアプリ	更新先になりやすいアプリ
顧客名、住所、担当者	顧客マスタ	案件、問い合わせ、請求
案件ステータス	案件管理	活動履歴、請求準備、集計
出荷状況	出荷管理	受注管理、顧客連絡用アプリ
入金状況	入金管理、会計側	請求管理、案件管理
在庫数	在庫管理	受注、出荷、発注
最終訪問日	活動履歴	顧客マスタ

たとえば、顧客マスタの住所を案件アプリへ反映する場合、顧客マスタが正本です。

案件アプリ側で住所を手動修正してよいのか。

請求済みの案件住所まで上書きしてよいのか。

過去の帳票に使った住所は固定すべきではないか。

これを決めます。

一方で、活動履歴を登録したときに顧客マスタの最終訪問日を更新する場合、活動履歴の最新日が正本になります。

ただし、訪問予定、電話、メール、商談のどれを最終訪問日に含めるのかを決めないと、顧客マスタの意味が崩れます。

クラウド Watchの記事では、ATTAZoo Uの例として、案件管理アプリで営業活動を登録したときに顧客管理アプリの最終訪問日を更新する、出荷アプリの出荷状況を受注アプリにも反映する、といった利用場面が紹介されています。

クラウド Watch：ATTAZoo U提供開始の記事

このような連携は便利ですが、設計上は「どちらの値を正とするか」を先に決めます。

アプリ間更新は、元アプリから更新先へ値を流すだけではありません。正本アプリを決めないと、どちらを直せばよいか分からないデータになります。

コピー・表示・転記・同期の違い

kintoneでアプリ間の値を扱う方法は複数あります。

アプリ間レコード更新プラグインを入れる前に、やりたいことが本当に同期なのか確認します。

やりたいこと	向いている方法	データの扱い
入力時点の値を持ってくる	ルックアップ	コピーして保存する
関連する別アプリの一覧を見たい	関連レコード一覧	表示するだけ
ボタンで別アプリに新規レコードを作る	アプリアクション	手動転記する
条件に応じて別アプリの既存レコードを更新する	アプリ間レコード更新プラグイン	自動更新する
複数アプリの値を集計して保存する	集計アプリ、API、連携サービス	集計結果を持つ

たとえば、顧客アプリに案件一覧を見たいだけなら、関連レコードで足ります。

案件から活動履歴を作りたいだけなら、アプリアクションで足りることがあります。

商品マスタの単価を見積へ持ってきたいだけなら、ルックアップで足ります。

しかし、案件のステータス変更に応じて、既存の請求準備レコードやタスクレコードを自動更新したい場合は、アプリ間更新の検討対象になります。

リコーのATTAZoo Uページでは、アプリ間レコード更新、データ更新用二次元コード生成、CSVダウンローダー、CSVアップローダーなどが概要機能として紹介されており、アプリ間レコード更新では設定したアプリのフィールド更新時に他アプリのフィールドを更新すると説明されています。

リコー：ATTAZoo U

このようなプラグインは、標準機能の「コピー」「表示」「手動転記」では足りないときに検討します。

ただし、同期にすると保守対象が増えます。

必要なときだけ使います。

更新キーとフィールドマッピング

アプリ間更新の中心は、更新キーとフィールドマッピングです。

更新キーは、元アプリのレコードと更新先アプリのレコードを対応させる値です。

フィールドマッピングは、どの値をどのフィールドへ書き込むかの対応表です。

設計項目	悪い例	よい例
更新キー	顧客名	顧客コード
更新キー	案件名	案件番号
更新キー	商品名	商品コード
更新キー	メールアドレスだけ	顧客コードや外部IDと併用
マッピング	似た名前の項目を感覚で対応	フィールドコード単位で対応表を作る
上書き	常に全部上書き	空欄時だけ、未確定時だけなど条件を決める

更新キーに名称を使うと、名称変更や表記揺れで壊れます。

顧客名が「株式会社ABC」から「ABC株式会社」に変わる。

案件名に年度が追加される。

商品名が改定される。

このような変更で更新先を見失う可能性があります。

更新キーには、できるだけコードや番号を使います。

アプリ間更新	更新キーの例
顧客マスタから案件へ	顧客コード
案件から活動履歴へ	案件番号
出荷から受注へ	受注番号
請求から入金へ	請求番号
商品マスタから見積明細へ	商品コード

Ribbit's worksのアプリ間連携プラグインでは、元アプリと連携先アプリを紐づけるためのキーフィールドを両方のアプリで選択し、連携先から一致するレコードを探して更新対象にする流れが説明されています。

Ribbit's works：アプリ間連携プラグイン

また、同ページでは、フィールドコピー、固定値、文字列結合、計算式、日付オフセットなどのフィールドバインディングが紹介されています。

こうした機能を使う場合でも、先にマッピング表を作ります。

元アプリ	元フィールド	更新先アプリ	更新先フィールド	上書き条件
案件	案件番号	請求準備	案件番号	新規作成時のみ
案件	顧客コード	請求準備	顧客コード	常に同じ
案件	受注金額	請求準備	請求予定金額	未請求のときだけ
案件	ステータス	請求準備	案件状態	受注後のみ

この表がないままプラグイン設定だけを作ると、後から誰も意図を追えません。

アプリ間更新の品質は、プラグイン設定画面ではなく、更新キーとフィールドマッピング表で決まります。名称ではなくコードや番号でつなぎます。

作成・更新・削除・プロセス変更のトリガー

アプリ間レコード更新では、いつ動かすかも重要です。

トリガーが広すぎると、意図しない更新が起きます。

トリガー	向いているケース	注意点
レコード作成時	初回登録と同時に関連レコードを作る	下書き段階で作ってよいか確認する
レコード更新時	特定項目の変更を反映する	関係ない更新で動かないよう条件を絞る
一覧インライン編集	一括更新に近い運用	操作ミスの影響範囲が広くなりやすい
プロセス変更時	承認済み、受注済みなど状態確定後に動かす	アクション名や遷移先ステータスを絞る
削除時	関連データも消す	履歴や証跡まで消えないか確認する

Ribbit's worksのページでは、レコード作成・更新・削除・プロセス変更を起点に他アプリのレコードを更新できること、プロセス管理ではアクション名や変更後ステータス名で絞り込めることが説明されています。

この中で特に注意すべきなのは、削除です。

削除連動は強い機能です。

元レコードを削除したら、更新先の関連レコードも削除される設計にすると、不要データを整理しやすい場面はあります。

しかし、業務履歴、承認履歴、請求履歴、出荷履歴まで消えると困ります。

削除は取り消せない前提で、慎重に扱います。

削除よりも、無効フラグ、取消ステータス、非表示、アーカイブの方が向いていることもあります。

消したい理由	推奨しやすい対応
入力ミスの下書き	削除でもよい場合がある
受注後に取消	取消ステータスを残す
請求済みデータ	削除せず取消や差額処理
顧客統合	旧顧客コードを残して統合履歴を管理
担当変更	履歴を消さず最新担当へ更新

自動作成も同じです。

更新先にレコードがない場合に自動作成できると便利ですが、キーの間違いで重複レコードを増やす可能性があります。

自動作成する場合は、作成条件と重複検知を決めます。

ルックアップ・関連レコード・APIとの使い分け

アプリ間レコード更新プラグインは万能ではありません。

標準機能やAPIとの使い分けを決めます。

方法	向いていること	向かないこと
ルックアップ	入力時点のマスタ値をコピーする	常時同期
関連レコード一覧	関連履歴を画面で見る	値を保存して集計する
アプリアクション	ユーザー操作で別アプリに作る	既存レコードの自動更新
アプリ間更新プラグイン	条件付きで別アプリを更新する	複雑な再実行、外部連携、大量処理
REST API	複雑な同期、外部SaaS連携、ログ管理	小さな画面補助

ルックアップはコピーです。

関連レコードは表示です。

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

アプリ間更新プラグインは自動更新です。

REST APIは、処理の流れ、ログ、再実行、外部連携まで作り込める方法です。

kintoneアプリ間データ連携の設計方法はこちら
kintoneルックアップ自動更新の設計方法はこちら
kintone API連携の設計方法はこちら

判断の基準は、失敗時に追えるかです。

少量の業務ルールで、更新元と更新先が明確ならプラグインが合うことがあります。

複数の外部システム、バッチ、承認済み除外、再実行、監査ログが必要なら、API連携や連携用アプリを検討します。

循環同期と二重更新を防ぐ

アプリ間更新で最も避けたいのは、循環同期と二重更新です。

循環同期とは、AアプリがBアプリを更新し、Bアプリの更新がまたAアプリを更新する状態です。

二重更新とは、同じ更新が複数回動き、金額、件数、履歴が重複する状態です。

危険な設計	起きる問題
AがBを更新し、BもAを更新する	循環する
更新先に該当レコードが複数ある	複数レコードが上書きされる
作成時と更新時の両方で同じ処理が動く	二重作成、二重更新
一覧編集でも詳細編集でも同じ連携が動く	操作経路で結果が変わる
削除連動で履歴を消す	後から確認できない
手動修正を常に自動更新で上書きする	例外対応が消える

防ぐ方法は、更新の方向を一方向にすることです。

顧客マスタから案件へ反映する。

活動履歴から顧客マスタの最終訪問日だけ更新する。

出荷アプリから受注アプリへ出荷状態だけ反映する。

このように、項目ごとに方向を決めます。

項目	更新方向	理由
顧客名	顧客マスタ → 案件	マスタを正本にする
最終訪問日	活動履歴 → 顧客マスタ	最新履歴から派生する
出荷状況	出荷 → 受注	実績側を正本にする
請求済みフラグ	請求 → 案件	請求側の処理結果を反映する

また、更新済みフラグや連携IDを持たせると、二重更新を防ぎやすくなります。

完璧な同期をプラグインだけで作ろうとしないことも重要です。

複雑になったら、連携ログアプリやAPI処理へ切り替えます。

アプリ間更新は、双方向にすると一気に壊れやすくなります。項目ごとに更新方向を決め、一方向の反映として設計します。

エラー通知・再実行・ログ設計

アプリ間更新は、成功する前提で作ると危険です。

失敗する前提で、ログと再実行を設計します。

失敗例	必要な対応
更新先レコードが見つからない	キー不一致を確認する一覧
更新先レコードが複数ある	キー重複を止める
権限不足で更新できない	実行ユーザーや権限設定を確認する
必須項目不足で作成できない	更新先の必須条件を見直す
削除連動の対象が多すぎる	削除前確認や除外条件を設ける
外部システム連携と衝突する	実行順と正本を見直す

Ribbit's worksのページでは、連携処理後の結果をダイアログで確認でき、正常、スキップ、エラーのように結果を確認できる機能が紹介されています。

こうした結果表示は、現場の操作確認には役立ちます。

ただし、業務としては、後から追えるログも必要です。

特に、請求、入金、在庫、出荷、承認済みデータに関わる更新では、誰がどのレコードを更新し、どの結果になったかを残します。

ログ項目	例
実行日時	2026-06-12 10:00
元アプリ	案件管理
元レコード	案件番号 A-2026-001
更新先アプリ	請求準備
更新キー	案件番号 A-2026-001
更新内容	請求予定金額、ステータス
結果	成功、スキップ、エラー
エラー理由	更新先なし、キー重複、権限不足
再実行	済、未、対象外

プラグインだけで十分なログが残せない場合は、連携ログアプリを別に作るか、API連携に切り替えます。

よくある失敗

kintoneアプリ間レコード更新プラグインでは、次の失敗が起きやすいです。

正本を決めずに更新する

どちらのアプリが正しいのか決めないまま更新すると、差分が出たときに判断できません。

項目ごとに正本アプリを決めます。

顧客名や案件名でつなぐ

名称は変わります。

更新キーには、顧客コード、案件番号、受注番号、請求番号などを使います。

手動修正を上書きする

更新先で例外的に直した値が、自動更新で戻ることがあります。

上書き条件と手動修正を守る条件を決めます。

削除連動で履歴を消す

削除は取り消せないことがあります。

履歴や証跡が必要な業務では、削除ではなく取消ステータスや無効フラグを使います。

作成時と更新時の両方で二重作成する

自動作成を使う場合、作成時、更新時、プロセス変更時のどれで動くかを絞ります。

同じ関連レコードが複数作られないようにします。

エラーを画面表示だけで終わらせる

その場のダイアログだけでは、後から追えません。

重要な連携ではログ、エラー一覧、再実行手順を用意します。

プラグインで複雑な業務同期を作り込みすぎる

条件、除外、再実行、外部連携、監査が増えたら、APIや連携ログアプリを検討します。

実装前チェックリスト

アプリ間レコード更新プラグインを入れる前に、次の項目を確認します。

確認項目	判断すること
目的	コピー、表示、転記、同期、集計のどれか
正本	どのアプリのどの項目を正とするか
更新方向	一方向か、双方向に見えていないか
更新キー	コード、番号、外部IDなど一意な値か
更新先	既存レコードを更新するか、新規作成するか
マッピング	どのフィールドをどこへ書くか
上書き条件	常に上書き、空欄時のみ、未確定時のみなど
トリガー	作成、更新、削除、プロセス変更のどれか
除外条件	承認済み、請求済み、完了済みを守るか
削除	削除連動ではなく取消でよいか
ログ	成功、スキップ、エラーを後から確認できるか
再実行	失敗分だけやり直せるか
保守	設定名、変更履歴、担当者を残すか

この表が埋まると、プラグインでよいか、API連携にすべきかが見えます。

小さく、方向が明確で、更新キーが安定している連携なら、プラグインが合うことがあります。

更新先が多い、条件が複雑、外部SaaSも関係する、再実行やログが重要な場合は、API連携や連携用アプリを検討します。

Bitlightに相談できること

Bitlightでは、kintoneアプリ間レコード更新を、単なる転記設定としては扱いません。

相談できる内容は次の通りです。

• 既存アプリ間の関係整理
• 正本アプリ、更新先アプリ、更新方向の整理
• 更新キーとフィールドマッピング表の作成
• ルックアップ、関連レコード、アプリアクション、プラグイン、APIの使い分け
• 作成・更新・削除・プロセス変更トリガーの設計
• 循環同期、二重更新、手動修正上書きの防止
• エラー通知、再実行、連携ログの設計
• プラグインで足りる範囲とAPI連携に切り替える範囲の判断

アプリ間更新は、設定できると一気に便利になります。

その一方で、設計が甘いと、複数アプリのデータを同時に壊します。

kintoneアプリ間レコード更新プラグインは、転記を楽にする道具ではなく、正本、更新キー、上書き、ログを決めたうえで使う同期処理です。

正本、更新方向、更新キー、失敗時の確認方法を先に決めれば、プラグインを使う範囲と、APIで作る範囲を落ち着いて分けられます。