kintoneルックアップ自動更新の設計方法｜マスタ変更を安全に反映する構成

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

顧客マスタの住所を案件アプリへコピーする。

商品マスタの単価を見積アプリへコピーする。

部門マスタの承認者候補を申請アプリへコピーする。

この仕組みは便利ですが、マスタを更新した後に問題が起きます。

顧客マスタの住所を直したのに、案件アプリ側の取得済み住所が古い。

商品マスタの単価を改定したのに、新しい見積と古い見積で値が混ざる。

部門責任者を変更したのに、未承認レコードの承認者候補が古いまま残る。

こうした課題から、ルックアップ自動更新を検討することがあります。

ただし、すべてを自動更新すればよいわけではありません。

実務で危ないのは、次のような状態です。

• 顧客住所は最新化したいが、請求済みレコードまで上書きしてしまう
• 商品単価を最新化した結果、過去見積の金額根拠が変わる
• 承認済み申請の部門名や承認者候補が後から変わる
• 更新対象の絞り込みがなく、完了データも更新される
• 誰がいつ自動更新を実行したか残らない
• プラグイン、JavaScript、一括更新のどれで更新したかが混在する
• CSV取込でマスタを更新したときだけ、自動更新が動かない
• 更新に失敗したレコードを見つけられない

ルックアップ自動更新は、便利なメンテナンス手段です。

しかし、設計なしに入れると、古い値を残すべき業務データまで最新化します。

kintoneルックアップ自動更新で最初に決めるべきなのは、更新方法ではなく、「最新値へ更新すべき項目」と「過去時点の値として固定すべき項目」の切り分けです。

この記事では、kintoneルックアップ自動更新を設計するときの、上書き可否、標準機能の限界、プラグイン、JavaScript、一括更新、承認済み・請求済み除外、更新権限、実行ログ、失敗時の戻し方を整理します。

kintoneルックアップの設計方法はこちら
kintoneルックアップ自動取得の設計方法はこちら

先に結論：自動更新の前に上書き可否を決める

ルックアップ自動更新は、マスタ変更を取得済みレコードへ反映するための仕組みです。

ただし、更新してよいデータと、更新してはいけないデータがあります。

マスタ変更	更新してよいことが多い	固定すべきことが多い
顧客住所変更	未請求、未発送、未契約のレコード	請求済み、発送済み、契約締結済み
商品名変更	未提出の見積、未処理の注文	提出済み見積、注文確定後
商品単価変更	新規見積、未提出見積	過去見積、注文済み、請求済み
部門責任者変更	未申請、未承認レコード	承認済み、完了レコード
税区分変更	適用開始日以降の新規処理	適用前の証跡

この表を作らずに自動更新を入れると、マスタの最新値が常に正しいという前提になります。

しかし、業務データでは、古い値が正しい場合があります。

見積提出時点の単価。

請求書送付時点の住所。

承認時点の部門。

契約締結時点の取引先名。

これらは、後からマスタが変わっても、当時値として残すべきです。

ルックアップ自動更新は「古い値を全部直す機能」ではありません。最新値にすべきデータだけを対象にし、当時値を守るデータは除外します。

ルックアップが標準では自動更新されない理由

kintoneのルックアップは、参照ではなくコピーです。

ルックアップで取得した値は、取得先レコードにコピーされます。

そのため、参照元のマスタを変更しても、取得済みの値が自動的に最新化されるとは考えない方がよいです。

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

kintone公式ヘルプでも、ルックアップで参照しているアプリの値を変更した場合、取得済みデータを一括更新する方法としてCSV読み込みを使う手順が案内されています。

kintoneヘルプ：ルックアップで取得したデータを一括更新したい

この仕様は、不便なだけではありません。

過去データを守る意味もあります。

たとえば、商品単価をマスタから見積へコピーしている場合、単価改定のたびに過去見積まで変わると困ります。

ルックアップが自動同期ではないからこそ、取得時点の条件を残せます。

仕様	業務上の意味
取得時点でコピーされる	当時値を残せる
マスタ変更で自動反映されない	過去データが勝手に変わらない
再取得や一括更新が必要	更新対象を選べる
キー重複に弱い	マスタの一意性が重要になる

自動更新を導入するなら、この仕様を上書きすることになります。

だから、更新対象を限定します。

最新値へ更新すべき項目と固定すべき項目

ルックアップ自動更新で最初に作るべきなのは、更新対象表です。

項目	最新化するか	理由
顧客の現在担当者	最新化しやすい	現在の対応先を見たい
顧客の表示名	ケース次第	社名変更を反映したいが旧名称も残したい
顧客住所	状態で判断	未請求は更新、請求済みは固定
商品名	ケース次第	表示名変更か、過去帳票の証跡かで変わる
商品単価	原則固定	過去見積や注文金額の根拠になる
税区分	適用開始日で判断	過去処理を壊さない
部門責任者	未処理のみ更新	承認済みは当時の責任を残す

この表で重要なのは、項目名だけで判断しないことです。

同じ住所でも、顧客マスタ上の現在住所なら最新値です。

請求済みレコードの請求先住所なら当時値です。

同じ単価でも、商品マスタ上の現在単価なら最新値です。

提出済み見積の単価なら当時値です。

使い方	扱い
現在の顧客情報を表示する	最新値へ更新
未提出の見積を作る	最新値へ更新
提出済み見積を保管する	固定
請求済みデータを保管する	固定
未承認の申請を正しい承認者へ回す	状態次第で更新

自動更新は、マスタの正しさを保つために使います。

一方で、過去の判断根拠を壊す使い方は避けます。

プラグイン・JavaScript・一括更新の使い分け

ルックアップ自動更新の方法は、主に3つあります。

プラグイン。

JavaScriptやカスタマイズ。

CSVなどによる一括更新。

方法	向いているケース	注意点
プラグイン	マスタ変更時に取得先を更新したい	更新対象、除外条件、実行者制限を確認する
JavaScript・カスタマイズ	条件を細かく制御したい	保守者、テスト、エラー処理が必要
一括更新	対象を抽出して計画的に更新したい	バックアップ、キー重複、検証が必要
手動再取得	件数が少ない、判断が人に必要	抜け漏れを一覧で拾う必要がある

Focus Uのルックアップ自動更新プラグインでは、ルックアップ元データ変更に合わせた更新、更新ボタン、保存後処理、プロセス管理アクション時の更新、更新結果確認、CSV出力などが紹介されています。

Focus U：ルックアップ自動更新プラグイン

このような機能は便利です。

ただし、機能があることと、自社の業務にそのまま使ってよいことは別です。

たとえば、プロセス管理のアクション時に更新する場合、どのステータスで実行するのかを決めます。

更新ボタンを出す場合、誰にだけ出すのかを決めます。

一覧で一括更新する場合、どの一覧を対象にするのかを決めます。

更新方法	設計で決めること
保存後に自動更新	マスタ保存だけで即反映してよいか
更新ボタン	誰が押せるか、押す前に何を見るか
プロセスアクション時	どのステータス、どのアクションで実行するか
条件付き更新	未処理、未請求、未承認だけに絞るか
一括更新	対象一覧、バックアップ、更新後検証をどうするか

コムデックAIラボの記事でも、自動更新では更新キーが必要で、条件を指定した更新やCSVによる一括更新などの使い分けが紹介されています。

コムデックAIラボ：ルックアップ先を自動更新する方法

Bitlightの実務判断としては、まず対象を絞りやすい方法を選びます。

「全部自動で最新化する」より、「未処理だけ自動、確定済みは除外、例外は管理者が実行」の方が安全です。

承認済み・請求済みレコードを除外する設計

ルックアップ自動更新で最も重要なのは、除外条件です。

更新してはいけないレコードを先に決めます。

除外候補	理由
承認済み	承認時点の金額、部門、承認者を残す
請求済み	請求時点の住所、金額、税区分を残す
契約締結済み	契約時点の相手先、条件を残す
出荷済み	出荷時点の商品名、配送先を残す
完了	業務上確定したデータを守る
取消・却下	後から値を変えても意味が薄い

除外条件は、ステータスだけでなく、日付やフラグでも考えます。

条件	例
ステータス	下書き、申請前、承認待ち、承認済み、完了
請求状態	未請求、請求準備中、請求済み
帳票状態	未出力、出力済み、送付済み
契約状態	作成中、確認中、締結済み
更新対象フラグ	自動更新対象、更新除外
適用開始日	2026-04-01以降だけ更新

たとえば、顧客住所の変更なら、未請求レコードだけ更新してよいかもしれません。

しかし、請求済みレコードの請求先住所は、当時送付した証跡として固定した方が安全です。

商品単価なら、未提出見積だけ更新し、提出済み・受注済み・請求済みは除外します。

ルックアップ自動更新では、更新対象より先に除外対象を決めます。承認済み、請求済み、契約締結済み、完了データは原則として守る側に置きます。

更新権限・実行ログ・失敗時の戻し方

自動更新は、誰でも実行できるようにしない方がよいです。

マスタ変更と同時に多くのレコードが更新される可能性があるためです。

論点	決めること
実行者	管理者、マスタ管理者、業務責任者
実行タイミング	マスタ保存時、更新ボタン、定期処理、承認アクション時
対象確認	実行前に対象件数を見せるか
ログ	実行者、実行日時、対象件数、成功件数、失敗件数
変更前後	変更前値、変更後値を残すか
失敗時	再実行、手動修正、対象除外
戻し方	バックアップ、CSV、変更履歴、更新ログ

プラグインに更新結果画面やCSV出力がある場合でも、それを業務ログとしてどう扱うかを決めます。

画面で確認して終わりにするのか。

更新ログアプリに記録するのか。

CSVを保管するのか。

失敗レコード一覧を作るのか。

自動更新を安全に運用するなら、少なくとも次の情報を残したいです。

ログ項目	目的
更新対象アプリ	どのアプリを更新したか
参照元マスタ	どのマスタ変更がきっかけか
対象条件	どの一覧、どの条件で絞ったか
実行者	誰が実行したか
実行日時	いつ反映したか
成功件数・失敗件数	結果を確認する
除外件数	意図通り除外されたか
失敗理由	権限不足、キー重複、該当なしなど

失敗時の戻し方も設計します。

自動更新前にCSVバックアップを取る。

更新ログを見て失敗分だけ再実行する。

誤更新した場合に、変更前値へ戻せるようにする。

これらを決めずに自動更新だけ入れると、事故時に復旧しづらくなります。

マスタ変更時の運用ルール

自動更新は、マスタ変更の運用とセットです。

顧客マスタ、商品マスタ、部門マスタを誰が変更できるかを決めます。

変更前に影響範囲を確認します。

変更後に自動更新の対象を確認します。

マスタ変更時の手順	内容
1	変更内容を記録する
2	更新対象アプリを確認する
3	最新化すべき項目と固定すべき項目を確認する
4	対象一覧で件数を確認する
5	除外条件を確認する
6	バックアップや更新ログを準備する
7	自動更新を実行する
8	成功、失敗、除外を確認する

特に、商品単価や税区分のように金額へ影響する項目は、適用開始日を持たせる方が安全です。

マスタ項目	追加したい管理項目
商品単価	適用開始日、旧単価、新単価
税区分	適用開始日、対象商品、対象取引
顧客住所	変更日、請求反映可否
部門責任者	変更日、未承認レコードの扱い
契約条件	適用日、対象契約、承認者

マスタを上書きするだけでは、どの時点から新しい値を使うべきか分かりません。

適用開始日や利用状態を持たせると、自動更新の対象判定がしやすくなります。

自動更新と一括更新の境界

自動更新と一括更新は似ていますが、設計上は分けます。

方法	使う場面
自動更新	マスタ変更に合わせて、定義済み条件の範囲を反映したい
一括更新	対象を抽出し、バックアップして、計画的に更新したい
個別再取得	件数が少なく、人が内容を見て判断したい

大量の過去データを更新する場合や、除外条件が複雑な場合は、一括更新の方が向くことがあります。

一括更新では、対象一覧を作り、CSVを書き出し、バックアップを取り、テスト更新し、更新後に検証します。

これは次のテーマとして深く扱うべき内容です。

この記事では、ルックアップ自動更新を検討する時点で、「自動で即時反映するべきか、対象を抽出して一括更新すべきか」を分けることが重要です。

判断	自動更新向き	一括更新向き
更新頻度	よくある	年数回
更新対象	条件が単純	条件が複雑
影響範囲	小さい	大きい
戻し方	ログで追える	バックアップが必要
確認	実行後確認でよい	実行前後に検証が必要

「マスタを変えたら即すべて反映」は、分かりやすいですが危険です。

影響が大きい更新ほど、一括更新として計画的に扱います。

よくある失敗

kintoneルックアップ自動更新でよくある失敗は、次の通りです。

失敗	起きること	対策
全件を自動更新する	過去見積や請求済みまで変わる	除外条件を先に作る
商品単価を自動更新する	提出済み見積の根拠が壊れる	新規・未提出だけ更新する
実行者を制限しない	誤って大規模更新される	管理者や業務責任者に絞る
更新ログがない	何が変わったか追えない	実行ログと変更前後を残す
失敗レコードを見ない	一部だけ古い値が残る	成功、失敗、除外一覧を確認する
CSV更新時の挙動を確認しない	想定した自動更新が動かない	マスタ更新方法ごとにテストする
キー重複を放置する	更新対象を特定できない	コードや外部IDを重複禁止にする
適用開始日がない	どこから新値を使うか曖昧	マスタに適用開始日を持たせる

自動更新は、運用がうまくいくと便利です。

しかし、失敗したときの影響は大きいです。

だから、実装前に更新対象表、除外条件、実行権限、ログ、戻し方を決めます。

kintoneルックアップ自動更新は、最新化と証跡保護を分けて設計する

kintoneルックアップ自動更新は、マスタ変更後の更新漏れを減らす有効な手段です。

ただし、導入前に次を決めます。

1. 最新値へ更新すべき項目と、当時値として固定すべき項目を分ける
2. 承認済み、請求済み、契約締結済み、完了レコードを除外する
3. プラグイン、JavaScript、一括更新、手動再取得の使い分けを決める
4. 更新対象を一覧や条件で絞り込む
5. 実行者、実行タイミング、対象件数確認を決める
6. 更新ログ、失敗ログ、変更前後、戻し方を決める
7. マスタ変更時の手順と適用開始日を管理する

自動更新は、古い値を消すための仕組みではありません。

最新であるべきデータを最新にし、当時値として守るべきデータを守るための仕組みです。

Bitlightでは、kintoneルックアップ自動更新を、マスタ設計、更新対象判定、除外条件、プラグイン選定、カスタマイズ、実行ログ、失敗時の戻し方まで含めて設計できます。

既存アプリで取得済み値のずれが起きている場合は、まず「最新化する項目」と「固定する項目」の棚卸しから始めるのが現実的です。

kintone見積書作成の設計方法はこちら
kintone請求管理の設計方法はこちら