kintoneルックアップの設計方法｜マスタ参照・コピー・更新漏れを防ぐ

kintoneのルックアップは、便利な機能です。

顧客コードを入力して、顧客名や住所を取得する。

商品コードを入力して、商品名や単価を取得する。

部門コードから、部門名や承認者候補を取得する。

案件番号から、顧客や見積条件を取得する。

これにより、同じ情報を何度も入力する必要が減ります。

表記揺れも減ります。

マスタアプリを中心に、複数の業務アプリをつなぎやすくなります。

ただし、ルックアップは「常に最新のマスタを見に行く参照機能」ではありません。

実務で問題になるのは、次のような状態です。

• 顧客名や商品名をキーにして、名称変更時に取得できなくなる
• ルックアップでコピーした値が、マスタ更新後も古いまま残る
• 最新値に再取得してよい項目と、過去時点の値として固定すべき項目を分けていない
• 商品単価を更新したら、過去見積まで上書きしてしまう
• 顧客住所を更新したのに、請求前確認アプリの住所が古いまま残る
• 関連レコード一覧で表示すべき情報までルックアップでコピーしている
• ルックアップ元のキーが重複し、CSV更新や取得時に対象を特定できない
• 取得ボタンの押し忘れを、設計ではなく現場の注意で防ごうとしている
• マスタアプリの編集権限が広すぎて、取引データ側の値も信用できなくなる

ルックアップで最初に決めるべきなのは、設定画面の項目ではありません。

「何をキーにして、何をコピーし、何をコピーしないか」です。

kintoneルックアップは、他アプリの値を「参照し続ける」機能ではなく、取得時点の値を「コピーする」機能として設計します。

この記事では、kintoneルックアップを使うときの、マスタアプリ、キー、コピー項目、関連レコードとの違い、マスタ更新時の再取得、過去データ固定、重複防止を整理します。

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

先に結論：ルックアップはコピーであり、同期ではない

kintone公式ヘルプでは、ルックアップを設定すると、他のアプリから必要なデータをコピーして取得できると説明されています。

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

この「コピー」という言葉を、設計の中心に置きます。

誤解	実際の考え方
マスタを参照し続ける	取得時点の値をコピーする
マスタ更新で自動反映される	取得済み値は自動で最新にならない
顧客名を入れれば十分	一意なキーを決める必要がある
コピー項目は多いほどよい	固定すべき項目だけコピーする
関連レコードと同じ	関連レコードは条件に合うレコードを表示する

公式ヘルプの注意点でも、参照先のマスターデータに変更があっても、ルックアップで取得済みの値はそのまま維持され、自動的に最新の値にはならないと説明されています。再度取得すると、最新の値で上書きされます。

つまり、ルックアップを使うときは、次の2種類を分けます。

情報の種類	例	設計
取得時点で固定したい情報	見積時点の商品名、単価、申請時点の部門名	ルックアップでコピーする
常に最新を見たい情報	現在の担当者、契約状態、最新問い合わせ	関連レコードやマスタ参照で見る

ルックアップは、入力を楽にするためだけの機能ではありません。

業務データの「当時値」を残すためにも使えます。

たとえば、見積書では、見積提出時点の商品名や単価を固定したいことがあります。

商品マスタの単価が後から変わっても、過去に提出した見積の単価まで変わると困ります。

この場合、ルックアップでコピーして固定する設計は合理的です。

一方で、顧客の現在担当者をいつも最新で見たいなら、コピーして固定するより、顧客マスタを見に行く画面や関連表示を考えた方がよいです。

マスタアプリと取引アプリを分ける

ルックアップを使う前提として、マスタアプリと取引アプリを分けます。

種類	1レコードの意味	例
マスタアプリ	比較的変わりにくい正本	顧客、商品、部門、担当者、勘定科目
取引アプリ	日々発生する業務データ	案件、見積、注文、申請、問い合わせ
履歴アプリ	いつ誰が何をしたか	活動履歴、対応履歴、変更履歴

ルックアップの参照先は、基本的にマスタアプリです。

顧客マスタ。

商品マスタ。

部門マスタ。

担当者マスタ。

取引アプリ側では、マスタから必要な値を取得します。

取引アプリ	ルックアップ元	取得する例
案件	顧客マスタ	顧客コード、正式名称、営業担当
見積	商品マスタ	商品コード、商品名、単価、税区分
経費申請	勘定科目マスタ	科目コード、科目名、税区分
購買申請	部門マスタ	部門コード、部門名、承認者候補
問い合わせ	顧客マスタ	顧客名、契約状態、サポート担当

ここで、取引アプリ同士をルックアップでつなぎすぎると、構造が読みにくくなります。

案件から見積。

見積から請求。

請求から入金。

このような連鎖を作る場合は、ルックアップだけでなく、アプリアクション、関連レコード、API、外部サービスとの境界も考えます。

kintoneとリレーショナルデータベースの違いでも整理したように、kintoneでは「コピー」「表示」「転記」「同期」を分ける方が安定します。

ルックアップを入れる前に、参照先をマスタ、取得先を取引データとして分けます。マスタが曖昧なままルックアップを増やすと、コピー元もコピー先も信用できなくなります。

キーにするフィールドの決め方

ルックアップでは、どのフィールドでマスタを探すかを決めます。

公式ヘルプでは、コピー元のフィールドとして、文字列1行、数値、計算、ルックアップ、リンク、レコード番号などを指定できると説明されています。

ただし、使えるフィールドであれば何でもよいわけではありません。

キーは、業務上変わりにくく、重複しないものにします。

キー候補	向き不向き	理由
顧客コード	向いている	名称変更や表記揺れに強い
商品コード	向いている	商品名変更後も同じ商品を追える
案件番号	向いている	見積、契約、請求とつなぎやすい
メールアドレス	ケース次第	個人単位なら便利だが変更や共有アドレスに注意
顧客名	注意	表記揺れ、社名変更、同名会社に弱い
商品名	注意	名称変更、類似商品に弱い
レコード番号	ケース次第	kintone内では一意だが、外部連携や移行では扱いに注意

キーにしたいフィールドは、マスタ側で重複しないように管理します。

公式ヘルプでも、CSVで一括更新する場合、コピー元フィールドの値が参照先アプリ内で重複していると対象レコードを特定できないと説明されています。

この点は、ルックアップ設計では重要です。

たとえば、顧客名をキーにした場合、同じ会社が2件登録されるだけで取得先を迷います。

商品名をキーにした場合、同名の商品や改名で崩れます。

できれば、マスタには次の項目を持たせます。

フィールド	役割
コード	ルックアップのキーにする
正式名称	表示や帳票に使う
略称	現場が探しやすくする
利用状態	有効、停止、統合済みを分ける
旧名称	社名変更や商品名変更の確認に使う
外部ID	会計、フォーム、外部DB連携に使う

キーを設計せずにルックアップを入れると、後からマスタ統合がつらくなります。

最初に、重複を許す項目と許さない項目を分けます。

ルックアップのキーは、現場が入力しやすい名前ではなく、重複せず長期的に変わりにくいコードを優先します。

コピーする項目とコピーしない項目

ルックアップで迷うのは、どの項目をコピーするかです。

コピー項目は、多ければよいわけではありません。

コピーした瞬間から、取引アプリ側にも値が残ります。

マスタが更新されても、その値は自動で最新になりません。

そのため、コピーする項目は「取引時点の値として残したいもの」に寄せます。

コピーする項目	理由
顧客正式名称	申請、見積、問い合わせ時点の表示名を残す
商品名	見積や注文時点の商品名を残す
単価	見積時点の金額根拠を残す
税区分	処理時点の条件を残す
部門名	申請時点の所属や承認ルートを残す
住所	帳票出力時点の宛先として残す場合がある

一方で、コピーに注意が必要な項目もあります。

コピーしない方がよいことが多い項目	理由
現在の契約状態	常に最新を見たい場合が多い
現在の担当者	異動や引き継ぎで変わる
在庫数	変動が激しく、コピー値がすぐ古くなる
未請求残高	会計や請求管理を正本にすべき
最新問い合わせ状態	関連レコードで履歴として見る方がよい

もちろん、業務によって判断は変わります。

たとえば、請求書を作る時点の住所は、当時値として残したい場合があります。

一方で、顧客詳細画面で見る住所は最新でよい場合があります。

同じ住所でも、用途によって扱いが変わります。

用途	扱い
顧客マスタの住所	最新値
見積提出時の住所	当時値としてコピー
請求書送付先	請求時点で確定
配送先住所	注文ごとに固定

コピーするかどうかは、フィールド名だけでは決められません。

その値が、過去の証跡なのか、現在状態なのかで決めます。

関連レコード・アプリアクションとの違い

ルックアップ、関連レコード、アプリアクションは、どれもアプリ間連携に見えます。

ただし、役割は違います。

機能	役割	向いていること
ルックアップ	他アプリの値をコピーする	取引時点の値を取得して固定する
関連レコード一覧	条件に合う他アプリのレコードを表示する	顧客別の案件、問い合わせ、活動履歴を見る
アプリアクション	開いているレコードの値を別アプリへ転記する	案件から見積、問い合わせからタスクを作る
API連携	外部処理で登録、更新、同期する	フォーム、会計、外部DB、BIとつなぐ

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

顧客マスタ上に、関連する案件や問い合わせを表示できます。

ただし、表示しているだけなので、顧客マスタに案件データをコピーしているわけではありません。

最新の履歴を見たいだけなら、関連レコードが向きます。

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

案件レコードを開いて、見積レコードを作る。

問い合わせレコードを開いて、タスクレコードを作る。

このように、次の業務レコードを作るときに向いています。

ルックアップは、値の取得です。

商品コードから商品名と単価を入れる。

顧客コードから正式名称と住所を入れる。

このように、入力中のレコードに必要な値をコピーするときに向いています。

どの機能を使うか迷ったら、次のように分けます。

やりたいこと	使う機能
マスタから値を取って固定したい	ルックアップ
関連する履歴を画面で見たい	関連レコード一覧
別アプリに新しいレコードを作りたい	アプリアクション
複数アプリを自動で登録、更新したい	API、連携サービス

この分け方をしておくと、ルックアップに仕事を持たせすぎずに済みます。

マスタ更新時の再取得ルール

ルックアップの運用で一番揉めるのは、マスタ更新後の扱いです。

顧客マスタを更新した。

商品マスタを更新した。

部門マスタを更新した。

このとき、取得済みレコードを再取得するのか、そのままにするのかを決めます。

マスタ更新	取得済み値の扱い
商品単価が変わった	過去見積は固定、新規見積から新単価
顧客住所が変わった	未請求レコードは再取得、請求済みは固定
顧客名が正式変更された	表示名だけ更新するか、旧名称を残すか判断
部門責任者が変わった	未承認レコードだけ更新する
税区分が変わった	適用開始日で分ける

再取得は、単純に全件実行すればよいわけではありません。

過去データまで最新値で上書きすると、当時の証跡が壊れることがあります。

一方で、最新値に更新すべきデータを放置すると、後続処理で誤りが出ます。

そこで、状態ごとに再取得可否を決めます。

レコード状態	再取得の考え方
下書き	再取得してよいことが多い
申請前	再取得してよいが、変更内容を確認する
承認待ち	再取得時に承認ルートや金額への影響を見る
承認済み	原則固定。必要なら再申請や履歴を残す
請求済み	原則固定
完了	原則固定

この表を作らずに、取得ボタンを押す運用だけにすると、現場判断がぶれます。

再取得してよい人、再取得してよい状態、再取得後に確認する項目を決めます。

マスタ更新時は、「全件を最新化するか」ではなく、「どの状態のレコードなら再取得してよいか」を先に決めます。

過去データを固定すべきケース

ルックアップは、過去データを守るためにも使えます。

特に、見積、請求、申請、承認、契約に関わる値は、当時値として残す必要があります。

業務	固定すべき値
見積	商品名、単価、税区分、値引条件
注文	注文時点の商品名、単価、配送先
請求確認	請求先、請求対象、税区分
経費申請	申請時点の部門、科目、承認者
契約確認	契約時点の顧客名、契約条件

固定すべき値を、マスタの最新値で上書きすると、過去の判断根拠が変わってしまいます。

たとえば、商品マスタの単価を改定した後、過去見積の単価まで更新されると、顧客に提出した金額とkintone上の金額がずれます。

部門マスタの責任者を変更した後、過去申請の承認者候補まで変わると、誰の責任で承認したのか分かりにくくなります。

過去データを固定する場合は、次の方針を持ちます。

方針	内容
取得時点を残す	取得日、取得元マスタ、取得者を残す
再取得を制限する	承認済み、請求済み、完了では再取得しない
変更理由を残す	例外的に再取得する場合は理由を記録する
最新確認は別にする	関連レコードやマスタリンクで現在値を確認する

「古い値が残っている」のが常に悪いわけではありません。

業務によっては、古い値が正しい証跡です。

自動取得・自動更新を検討する前に決めること

ルックアップでは、取得ボタンの押し忘れが問題になります。

そのため、自動取得や自動更新を検討することがあります。

ただし、自動化の前に、上書き可否を決めます。

自動化したいこと	先に決めること
新規作成時に自動取得	どのキー入力で取得するか
編集時に自動再取得	既存値を上書きしてよいか
マスタ変更時に自動更新	対象レコードの状態をどう絞るか
一括更新	更新対象、除外対象、失敗時の戻し方
プラグイン利用	どのアプリ、どのフィールドを対象にするか

新規レコードで、顧客コードを入力したら顧客名を自動取得する。

これは分かりやすい自動化です。

しかし、編集時に顧客コードを変更した場合、既存の住所、担当者、請求先、承認ルートまで上書きしてよいかは別問題です。

マスタ更新時に、取得済みレコードを自動更新する場合も同じです。

未処理レコードだけ更新するのか。

承認済みは除外するのか。

請求済みは固定するのか。

更新ログを残すのか。

ここを決めずに自動化すると、押し忘れは減っても、上書き事故が増えます。

自動取得や自動更新は、次の記事で詳しく扱うべきテーマです。

この記事の段階では、標準ルックアップを設計するときから、将来の自動化に備えて「更新してよい項目」と「固定する項目」を分けておくことが重要です。

テストケースと運用チェック

ルックアップを設定したら、通常の取得だけでなく、失敗するパターンもテストします。

テスト	確認すること
正しいキーで取得	必要な項目がコピーされるか
存在しないキー	取得できないときに現場が分かるか
重複キー	対象を特定できるか
利用停止マスタ	取得候補に出してよいか
マスタ更新後	取得済み値が自動更新されないことを理解しているか
再取得	上書きされる項目が正しいか
承認済みレコード	再取得を禁止、または制限できているか
CSV取込	キー列で正しく更新できるか
権限	マスタ編集者と取引入力者が分かれているか

ルックアップは、設定直後は正しく動いて見えます。

問題は、マスタが増えたとき、名称が変わったとき、単価が変わったとき、CSVで更新したときに起きます。

そのため、次の運用チェックを置きます。

チェック	頻度
重複マスタ候補	月次、またはマスタ登録時
利用停止マスタの取得状況	月次
キー未入力レコード	週次
再取得が必要な未処理レコード	マスタ更新時
承認済み後の再取得履歴	変更時
CSV取込エラー	取込ごと

ルックアップは、一度設定したら終わりではありません。

マスタの品質を保つ運用とセットで設計します。

よくある失敗

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

失敗	起きること	対策
顧客名をキーにする	表記揺れや社名変更で取得できない	顧客コードを作る
コピー項目を増やしすぎる	マスタ更新後に古い値が散らばる	固定すべき項目だけコピーする
最新値が自動反映されると思う	取得済み値が古いまま残る	再取得ルールを作る
過去見積を再取得する	当時の単価や条件が壊れる	状態ごとに再取得可否を決める
関連レコードで足りる情報をコピーする	同じ情報が複数アプリに残る	表示とコピーを分ける
マスタ編集権限が広い	正本の品質が崩れる	マスタ管理者を絞る
CSV取込時のキーが弱い	重複や更新失敗が起きる	外部IDやコードを持つ
取得ボタンの押し忘れに依存する	未取得レコードが残る	一覧、入力チェック、自動化を検討する

ルックアップは、設定そのものは難しくありません。

難しいのは、コピーした値をいつまで信用するかです。

マスタの最新値を使うのか。

取得時点の値を残すのか。

再取得してよい状態か。

この判断がないままルックアップを増やすと、kintone上に似た値が散らばり、どれが正しいか分からなくなります。

kintoneルックアップは、マスタ設計と再取得ルールまで決めて使う

kintoneルックアップは、マスタアプリを活用するうえで重要な機能です。

ただし、設定画面だけを見て作ると、運用で崩れます。

最初に確認するのは、次の順番です。

1. マスタアプリと取引アプリを分ける
2. キーにするフィールドを決める
3. コピーする項目とコピーしない項目を分ける
4. 関連レコードやアプリアクションとの使い分けを決める
5. マスタ更新時に再取得するか、当時値として固定するかを決める
6. 承認済み、請求済み、完了レコードの再取得可否を決める
7. 重複マスタ、未取得レコード、CSV取込エラーを確認する運用を作る

ルックアップは、マスタを参照するための入口ではあります。

しかし、実務では「コピーされた値をどう扱うか」までが設計です。

Bitlightでは、kintoneのルックアップを、マスタ設計、キー設計、関連レコード、アプリアクション、再取得ルール、CSV/API連携まで含めて整理できます。

既存アプリで取得済み値のずれや更新漏れが出ている場合は、まずコピー項目と再取得ルールの棚卸しから始めるのが現実的です。

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