kintoneルックアップ一括更新の設計方法｜CSV更新・対象抽出・再取得ルール

kintoneのルックアップは、参照元アプリの値を取得先レコードへコピーする機能です。

顧客マスタから、案件アプリへ会社名や住所をコピーする。

商品マスタから、見積アプリへ商品名や単価をコピーする。

部門マスタから、申請アプリへ部門名や責任者をコピーする。

このとき、マスタ側を後から修正しても、取得済みレコードの値は自動では変わりません。

顧客住所を直したのに、案件アプリ側の住所が古い。

商品名を変えたのに、見積アプリ側の商品名が古い。

部門責任者を変えたのに、申請アプリ側の候補者が古い。

こうした状態をまとめて直す方法として、ルックアップ一括更新を検討します。

ただし、一括更新は便利な反面、影響範囲が広い作業です。

更新対象を間違えると、次のような事故が起きます。

• 提出済み見積の単価が最新マスタで上書きされる
• 請求済みレコードの請求先住所が後から変わる
• 承認済み申請の部門名や責任者が変わる
• キーが重複していて、どのマスタを参照したか分からない
• CSV取込後に、コピー項目だけ一部古いまま残る
• 更新前の値を戻せない
• 何件を更新し、何件を除外したか記録が残らない

kintoneルックアップ一括更新は、CSVの操作手順ではなく、マスタ変更後のデータメンテナンス作業として設計する必要があります。

この記事では、kintoneルックアップ一括更新を安全に行うための、更新対象の決め方、公式のCSV一括更新でできること、重複キー確認、対象一覧、バックアップ、テスト更新、プラグイン利用、更新後検証、誤更新を防ぐ運用ルールを整理します。

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

先に結論：一括更新で上書きしてよいデータを決める

ルックアップ一括更新で最初に決めることは、更新方法ではありません。

上書きしてよいデータの範囲です。

マスタ変更	一括更新してよいことが多い	一括更新しない方がよいことが多い
顧客住所変更	未請求、未発送、未契約の案件	請求済み、発送済み、契約締結済み
顧客担当者変更	未着手、進行中の案件	完了済み、失注済みの案件
商品名変更	未提出見積、作成中の注文	提出済み見積、受注済み、請求済み
商品単価変更	適用開始日以降の新規見積	過去見積、注文済み、請求済み
部門責任者変更	未申請、承認待ち	承認済み、完了

一括更新は、今のマスタ値にそろえる作業です。

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

見積提出時点の単価。

請求書送付時点の住所。

承認時点の部門名。

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

これらは、後からマスタを直しても、当時値として残す方が自然です。

ルックアップ一括更新では、最新化するデータと、当時値として固定するデータを分けます。全件更新を前提にすると、証跡として残すべき値まで変わります。

公式のCSV一括更新でできること

kintone公式ヘルプでは、ルックアップで参照しているアプリの値に変更があっても、ルックアップ先で取得済みの値は維持されると説明されています。

取得済みレコードを更新したい場合は、CSVファイルを読み込んで一括更新する方法が案内されています。

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

公式ヘルプの重要な点は、ルックアップフィールドの値を一括更新すると、ほかのフィールドのコピーで取得した値も一括で更新できることです。

つまり、次のような更新ができます。

更新するフィールド	一緒に更新される可能性がある項目
顧客コード	顧客名、住所、担当者、請求先
商品コード	商品名、標準単価、税区分、カテゴリ
部門コード	部門名、責任者、適用開始日
仕入先コード	仕入先名、支払条件、所在地

これは便利ですが、同時に危険でもあります。

ルックアップキーだけを更新するつもりでも、コピー項目がまとめて再取得されます。

そのため、CSVに入れる列と、更新後に変わる列を事前に整理します。

確認項目	見る理由
ルックアップフィールド	どのキーで再取得されるか
コピー項目	どの値が再取得されるか
更新対象レコード	どのレコードが上書きされるか
除外条件	当時値として守るレコードを外せているか
変更前値	誤更新時に戻せるか
変更後値	マスタの最新値と一致するか

CSV一括更新を「キーだけ更新する作業」と見ない方が安全です。

関連するコピー項目まで含めた、データ更新作業として扱います。

更新前に確認するキー重複と対象範囲

ルックアップ一括更新で特に重要なのが、キーの重複です。

公式ヘルプでも、コピー元のフィールドに選んだ値が参照先アプリ内で重複している場合、ファイル読み込み時に対象レコードを特定できず、値を更新できないと説明されています。

これは当然ですが、現場ではよく起きます。

よくあるキー	重複しやすい理由
顧客名	同名会社、表記ゆれ、支店違いがある
商品名	旧商品名、新商品名、類似品番がある
担当者名	同姓同名、部署異動がある
部門名	組織改編で同じ名称が再利用される
メールアドレス	共有アドレス、退職者引継ぎがある

ルックアップキーは、できるだけ名称ではなくコードにします。

顧客コード。

商品コード。

部門コード。

外部ID。

一括更新前には、参照元マスタでキー重複を確認します。

確認	例
参照元キーの重複	顧客コードが2件以上ないか
更新対象側のキー空欄	ルックアップキーが空のレコードがないか
廃止マスタの混在	廃止商品コードを参照していないか
表記ゆれ	全角半角、スペース、旧社名が混ざっていないか
マスタ未登録	更新対象側のキーが参照元に存在するか

ルックアップ一括更新の前に、参照元マスタのキー重複と、更新対象側のキー空欄を潰します。ここを飛ばすと、CSVの手順が正しくても更新結果が安定しません。

更新対象を一覧で抽出する

一括更新は、対象一覧を作ってから実行します。

全レコードを書き出して、手元で加工して、全件戻す運用は避けます。

まず、kintone上で更新対象の一覧を作ります。

一覧名	条件例
ルックアップ一括更新対象	ステータスが下書き、未提出、未請求
顧客住所更新対象	請求状態が未請求、発送状態が未発送
商品名更新対象	見積状態が作成中、提出前
部門責任者更新対象	申請状態が未申請、承認待ち
更新除外確認	承認済み、請求済み、完了、取消

対象一覧には、更新判断に必要な列を入れます。

列	用途
レコード番号	戻し作業や照合に使う
ステータス	除外対象か判断する
請求状態	請求済みを更新しない
ルックアップキー	CSV更新のキーになる
コピー項目	更新前後の差分を見る
更新除外フラグ	個別判断を残す
最終更新日時	同時編集や直近変更を確認する

一括更新前には、対象件数を記録します。

たとえば、顧客住所を更新する場合は、次のように分けます。

区分	件数	扱い
未請求	42件	更新対象
請求準備中	8件	業務責任者が確認
請求済み	116件	更新除外
契約締結済み	34件	更新除外
キー空欄	3件	更新前に修正

この件数を残しておくと、実行後の確認がしやすくなります。

CSVバックアップとテスト更新

一括更新では、更新前のCSVバックアップを必ず取ります。

バックアップは「念のため」ではありません。

戻し方の材料です。

バックアップ対象	理由
更新対象一覧	更新前値を戻すため
更新除外一覧	除外対象が変わっていないか確認するため
参照元マスタ	どのマスタ値で更新したか残すため
CSV取込ファイル	実際に投入した内容を残すため
更新後一覧	結果確認に使うため

本番の一括更新前には、少数レコードでテストします。

テスト対象	見ること
正常なキー	コピー項目が期待通り更新されるか
更新除外予定	対象に含まれていないか
キー空欄	エラーになるか、事前に除けているか
廃止キー	想定通り失敗を検知できるか
承認済み	上書きされないか

テスト更新では、見た目だけで判断しません。

更新前CSVと更新後CSVを比べます。

比較項目	確認内容
ルックアップキー	期待したキーに更新されたか
コピー項目	最新マスタ値になったか
金額項目	意図せず変わっていないか
住所項目	請求済みまで変わっていないか
ステータス	更新対象外が混ざっていないか
更新者・更新日時	更新作業の履歴として見えるか

CSVバックアップとテスト更新があれば、誤更新したときに戻せます。

逆に、この2つがない一括更新は、作業後に祈るしかなくなります。

プラグインで一括更新するケース

CSVではなく、プラグインでルックアップ一括更新を行うケースもあります。

コムデックAIラボの記事では、CSVファイルを利用する方法のほか、gusuku Customineや一覧レコード一括更新/クリアプラグインを使う方法が紹介されています。

コムデックAIラボ：kintoneのルックアップを一括更新する方法

プラグインを使うと、一覧画面上で対象を絞り込んで更新できたり、作業の手数を減らせたりします。

ただし、プラグインを入れれば設計が不要になるわけではありません。

方法	向いている場面	注意点
CSV一括更新	単発のメンテナンス、更新前後のCSVを残したい	操作ミス、列ずれ、バックアップ漏れ
プラグイン	一覧から定期的に更新したい	更新対象条件、実行権限、ログ確認
JavaScript	独自条件で更新したい	保守担当、エラー処理、仕様変更
外部連携	マスタ同期と合わせて管理したい	連携ログ、再実行、認証管理

プラグインで更新する場合も、次を決めます。

• どの一覧から実行できるか
• 実行できるユーザーは誰か
• 実行前に対象件数を確認できるか
• 除外条件をどう設定するか
• 更新結果をどこに残すか
• 失敗したレコードをどう再実行するか

トヨクモの記事でも、マスタ変更後はルックアップ先のレコードを編集して取得ボタンを押す必要があることや、外部サービスを使った自動取得の考え方が紹介されています。

トヨクモ：kintoneルックアップ 基本の設定から自動取得の方法まで

外部サービスを使う場合も、ルックアップフィールドへ直接入れるのか、別フィールドに保持するのかで設計が変わります。

一括更新の頻度が高いなら、自動更新や外部連携も検討します。

ただし、月1回や四半期1回のマスタ改定なら、CSVで計画的に更新した方が分かりやすいこともあります。

更新後の検証項目

一括更新は、CSVを読み込んだら終わりではありません。

更新後に、期待した結果になっているか確認します。

検証	内容
対象件数	更新予定件数と実行結果が一致するか
コピー項目	マスタ最新値と一致しているか
除外対象	承認済み、請求済み、完了が変わっていないか
エラー	読み込み失敗や未更新レコードがないか
キー不一致	参照元に存在しないキーが残っていないか
金額差分	見積金額や請求金額が意図せず変わっていないか
帳票	更新後の帳票出力に影響がないか

特に金額や帳票に関わる項目は、件数だけでは足りません。

更新前後の差分を見ます。

差分の見方	例
更新前住所と更新後住所	未請求だけ変わっているか
更新前単価と更新後単価	未提出見積だけ変わっているか
更新前部門と更新後部門	承認済みが変わっていないか
更新前税区分と更新後税区分	適用開始日以降だけ変わっているか

更新後の検証一覧も、kintoneに残すと運用しやすくなります。

検証一覧	条件例
一括更新後確認	更新日時が本日、更新者が作業者
更新漏れ確認	対象条件に該当するがコピー項目が旧値
誤更新確認	除外条件に該当するが更新日時が本日
キー未一致確認	参照元に存在しないキー
金額差分確認	更新前後で金額項目が変わった

ルックアップ一括更新は、実行後の検証一覧まで作って完了です。CSVを読み込めたことと、業務上正しい値になったことは別です。

誤更新を防ぐ運用ルール

ルックアップ一括更新は、日常的に誰でも実行する作業には向きません。

マスタ変更のたびに行うなら、運用ルールを決めます。

ルール	内容
実行者	マスタ管理者、業務責任者、システム管理者に絞る
実行タイミング	月次締め前、価格改定日、組織変更日など
事前承認	対象件数、除外件数、更新項目を確認する
バックアップ	更新対象、除外対象、マスタ、取込CSVを保存する
テスト	数件で再取得結果を確認する
実行ログ	実行者、日時、対象件数、失敗件数を残す
戻し方	更新前CSVで戻す手順を決める

運用ルールがないと、次のような状態になります。

誰かがCSVで全件更新したが、何を変えたか分からない。

請求済みレコードまで最新住所に変わった。

見積提出済みの単価が変わり、過去の提出資料と合わなくなった。

キー重複で一部だけ更新されず、古い値が混ざった。

更新後の確認担当が決まっていない。

これを防ぐには、作業チェックリストを作ります。

順番	チェック
1	マスタ変更内容を確認する
2	更新してよい項目と固定する項目を分ける
3	参照元キーの重複を確認する
4	更新対象一覧と除外一覧を作る
5	更新前CSVを保存する
6	少数レコードでテストする
7	本番CSVを読み込む
8	更新後一覧で結果を確認する
9	失敗・除外・誤更新を記録する
10	必要なら戻し作業を行う

このチェックリストを毎回使えば、一括更新は属人的な作業ではなくなります。

kintoneルックアップ一括更新は、対象抽出と検証まで含めて設計する

kintoneルックアップ一括更新は、マスタ変更後の取得済み値をまとめて直す有効な手段です。

ただし、CSVの作り方だけ覚えても安全にはなりません。

設計すべきなのは、次の流れです。

1. 更新してよいデータと、当時値として残すデータを分ける
2. 参照元マスタのキー重複を確認する
3. 更新対象一覧と除外一覧を作る
4. 更新前CSVと参照元マスタをバックアップする
5. 少数レコードでテスト更新する
6. 本番CSVを読み込む
7. 更新後一覧でコピー項目、除外対象、エラーを確認する
8. 実行ログと戻し方を残す

一括更新は、古い値を全部消す作業ではありません。

最新化すべきレコードだけを直し、証跡として守るべきレコードを変えないための作業です。

Bitlightでは、kintoneルックアップ一括更新を、対象抽出、CSV設計、重複キー確認、バックアップ、テスト更新、更新後検証、戻し方まで含めて設計できます。

既存アプリでルックアップ値のずれが起きている場合は、まず「更新対象一覧」と「更新除外一覧」を作るところから始めるのが現実的です。

kintoneデータベース設計の考え方はこちら
kintoneリレーショナルDB設計の考え方はこちら