kintoneルックアップ自動取得の設計方法｜プラグイン・JavaScript・運用ルール

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

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

顧客コードから顧客名や住所を取得する。

商品コードから商品名や単価を取得する。

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

このとき、標準機能ではユーザーが「取得」ボタンを押して値を取得します。

しかし、現場では次のような問題が起きます。

• 顧客コードを入力したが、取得ボタンを押し忘れる
• 商品コードを変えたのに、商品名や単価が古いまま残る
• 取得ボタンを押したかどうかが見た目で分かりにくい
• CSV取込後に取得済み項目が空欄のままになる
• 編集時に再取得してよい項目と、固定すべき項目が混ざる
• 承認済みや請求済みのレコードで再取得して、当時の金額を上書きする
• プラグインを入れたが、どの画面・どの状態で自動取得されるか把握できていない
• JavaScriptで自動取得したが、エラー時やモバイル画面の確認が漏れる

自動取得を入れると、取得ボタンの押し忘れは減らせます。

ただし、ルックアップは参照ではなくコピーです。

自動取得は、コピー操作を自動で実行することです。

つまり、上書きしてはいけない値まで自動で変えてしまう可能性があります。

kintoneルックアップ自動取得で最初に決めるべきなのは、実装方法ではなく、「いつ、どの状態で、どの項目を上書きしてよいか」です。

この記事では、kintoneルックアップ自動取得を設計するときの、手動取得、プラグイン、JavaScript、新規作成時、編集時、承認後、上書き禁止、過去データ保護、テスト項目を整理します。

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

先に結論：取得ボタンを消す前に上書き可否を決める

ルックアップ自動取得は、取得ボタンを押す操作を減らすための方法です。

Smart atのルックアップ自動取得プラグインでも、kintone標準機能ではルックアップ項目で「取得」ボタンを手動クリックする必要があり、プラグインによりそのクリックを省略できると説明されています。

Smart at：ルックアップ自動取得プラグイン

この方向性は分かりやすいです。

ただし、設計では次の順番で考えます。

順番	決めること
1	どのキー入力で自動取得するか
2	新規作成時だけか、編集時も自動取得するか
3	上書きしてよいコピー項目は何か
4	承認済み、請求済み、完了レコードでは禁止するか
5	失敗時にどう気づくか
6	プラグイン、JavaScript、手動運用のどれで実現するか

自動取得は、すべてのレコードで有効にすればよいわけではありません。

たとえば、新規作成時に顧客コードを入力したら顧客名を取得する。

これは自然です。

一方で、承認済みの見積レコードを開いたときに、商品マスタの最新単価で自動取得してしまう。

これは危険です。

過去に提出した見積金額や承認時点の条件が変わってしまうからです。

ルックアップ自動取得は、押し忘れ対策としては有効ですが、承認済み・請求済み・完了データでは上書き禁止を先に決めます。

手動取得・プラグイン・JavaScriptの違い

ルックアップ自動取得には、大きく3つの選択肢があります。

手動取得のまま運用する。

プラグインを使う。

JavaScriptでカスタマイズする。

方法	向いているケース	注意点
手動取得	件数が少ない、上書き判断が人に必要	押し忘れ対策が必要
プラグイン	標準操作に近く、保守を外部製品に任せたい	対象画面、対象フィールド、費用、サポート範囲を確認する
JavaScript	条件分岐や画面制御を細かく作りたい	保守者、テスト、権限、モバイル対応を確認する
連携サービス	フォーム、外部DB、他アプリ更新と合わせたい	正本、更新方向、エラー処理を設計する

ロフタルの記事でも、JavaScript自前実装、有償プラグイン、代替製品という選択肢が整理されています。

ロフタル：kintoneでルックアップを自動取得する3つの方法

ただし、選び方は「安いか」「実装できるか」だけでは決めません。

業務上、どこまで自動で上書きしてよいかで決めます。

判断軸	手動取得	プラグイン	JavaScript
新規作成時の取得	できる	向いている	向いている
編集時の条件分岐	人が判断	製品機能次第	細かく作れる
承認済みの禁止	運用で制限	製品機能次第	条件で制御しやすい
エラー表示	標準中心	製品機能次第	独自表示できる
保守	現場運用	ベンダー依存	自社または開発者が保守
監査・ログ	別設計が必要	製品機能次第	実装が必要

社内に保守できる人がいないのにJavaScriptで作ると、担当者がいなくなった後に直せなくなります。

反対に、業務条件が細かいのにプラグインだけで済ませると、必要な制御ができないことがあります。

まず、業務ルールを表にしてから実装方法を選びます。

新規作成時だけ自動取得する設計

最も安全なのは、新規作成時だけ自動取得する設計です。

新しいレコードを作るとき、キーを入力したらマスタから必要な値を取得する。

既存レコードの編集時には、勝手に再取得しない。

この形なら、上書き事故を減らしやすいです。

場面	自動取得の方針
レコード新規作成	キー入力後に自動取得してよい
レコード複製	複製元の値を使うか、再取得するか決める
レコード編集	原則自動再取得しない
キー変更時	警告を出してから取得する
承認済み後	自動取得しない

たとえば、見積アプリで商品コードを入力したら、商品名、単価、税区分を自動取得する。

新規見積なら自然です。

しかし、提出済み見積を編集で開いたときに、自動取得で単価を最新化してしまうと危険です。

新規作成時だけ自動取得する場合でも、次を決めます。

項目	決めること
キーフィールド	顧客コード、商品コード、部門コードなど
取得タイミング	画面表示時、キー変更時、保存前
未入力時	何もしない、エラー表示、保存禁止
取得失敗時	メッセージ、保存禁止、手動修正
複数候補	キー重複を禁止する、候補選択を許可しない

JavaScriptで実装する場合、イベントの使い方も設計対象です。

Ribbitの記事では、ルックアップフィールドに値をセットし、lookup プロパティを true にすることで取得処理をトリガーする実装例が紹介されています。

Ribbit：kintoneのルックアップをJavaScriptで自動取得する方法

実装できることと、業務上実行してよいことは別です。

新規作成時だけに絞るのか、編集時にも使うのかを先に決めます。

編集時に再取得してよい項目と禁止すべき項目

編集時の自動取得は、慎重に扱います。

既存レコードには、すでに業務上の意味を持つ値が入っています。

その値を最新マスタで上書きしてよいとは限りません。

項目	編集時の再取得
顧客名	未処理なら再取得可。請求済みなら慎重
顧客住所	請求前なら再取得可。請求済みは固定
商品名	表示名の変更なら判断が必要
商品単価	過去見積や注文では原則固定
税区分	適用開始日で判断
部門名	申請時点を残すなら固定
承認者候補	未承認なら更新可。承認済みは固定

編集時に自動取得するなら、状態で分けます。

レコード状態	自動取得の方針
下書き	自動取得してよいことが多い
申請前	取得後に確認項目を表示する
承認待ち	金額や承認ルートが変わるなら警告する
承認済み	原則自動取得しない
請求済み	原則自動取得しない
完了	原則自動取得しない

「編集画面を開いたら自動取得」は便利に見えます。

しかし、編集画面を開くだけで値が変わると、ユーザーは何が変わったか分かりません。

編集時は、次のどれかにします。

設計	向いているケース
自動取得しない	過去データを守りたい
キー変更時だけ取得	顧客コードや商品コードを変えたときだけ更新したい
警告してから取得	上書き対象を確認させたい
保存前に未取得を検出	押し忘れだけ防ぎたい
管理者だけ再取得	例外処理として扱いたい

編集時の自動取得は、画面を開いた瞬間に実行するのではなく、キー変更・未取得検出・警告表示・状態判定を組み合わせて設計します。

マスタ変更時の更新ルール

ルックアップ自動取得と、マスタ変更後の自動更新は別のテーマです。

自動取得は、主にレコード作成や編集のタイミングで、マスタから値を取得することです。

マスタ変更後の自動更新は、すでに取得済みの複数レコードへ、マスタ変更を反映することです。

ここを混ぜると、設計が危険になります。

テーマ	主な論点
自動取得	入力時、編集時、保存前に取得するか
自動更新	マスタ変更後に既存レコードを更新するか
一括更新	CSVやプラグインで対象レコードをまとめて更新するか

この記事で扱う自動取得では、次の程度まで決めておきます。

マスタ変更	自動取得側で決めること
顧客住所変更	新規作成時は新住所を取得する
商品単価変更	新規見積から新単価を取得する
部門責任者変更	新規申請から新担当を取得する
既存レコード	自動取得で勝手に更新しない
更新が必要な既存データ	別途対象抽出と更新ルールを作る

マスタ変更後に既存レコードを更新する場合は、対象抽出、除外条件、バックアップ、更新ログが必要です。

これは「自動取得」ではなく「自動更新」または「一括更新」の設計です。

自動取得を入れる段階では、少なくとも「既存レコードは自動で変えない」ことを初期値にすると安全です。

過去見積・請求データを守る考え方

自動取得で最も守るべきなのは、過去時点の条件です。

特に、見積、注文、請求、承認、契約に関わるデータは、当時値を残す必要があります。

業務	自動取得で注意する値
見積	商品名、単価、税区分、値引条件
注文	注文時点の商品名、配送先、単価
請求確認	請求先住所、請求対象、税区分
経費申請	申請時点の部門、科目、承認者候補
契約確認	契約時点の顧客名、契約条件

過去見積で、商品マスタの最新単価を自動取得してしまうと、提出済みの見積金額が変わります。

請求済みレコードで、顧客住所を自動取得してしまうと、当時送付した請求先とkintone上の表示がずれます。

承認済み申請で、部門や承認者候補を再取得してしまうと、承認時点の責任が曖昧になります。

したがって、過去データを守るために、次を設計します。

ルール	内容
状態で禁止	承認済み、請求済み、完了では自動取得しない
項目で禁止	単価、税区分、契約条件などは上書きしない
例外処理	管理者だけ手動で再取得できる
履歴	例外的な再取得は理由を残す
確認画面	上書き前に変更前後を見せる

自動取得は、入力の手間を減らすためのものです。

過去データを最新化するためのものではありません。

過去見積・請求・承認データでは、古い値が誤りとは限りません。当時値として残すべき項目は、自動取得の対象から外します。

実装時の注意点

JavaScriptで自動取得する場合は、実装上の注意点もあります。

cybozu developer networkのJavaScript API共通仕様では、アプリに取り込んだJavaScriptやCSSのカスタマイズファイルが、レコード一覧、登録、編集、詳細、印刷、グラフ、動作テスト環境の画面に適用されることが説明されています。

cybozu developer network：kintone JavaScript APIの共通仕様

また、ライトコースではJavaScriptやCSSを使ったカスタマイズを利用できない旨も補足されています。

そのため、JavaScriptで作る前に、契約コース、対象画面、保守者を確認します。

注意点	確認すること
契約コース	JavaScriptカスタマイズを使えるか
対象画面	PC、モバイル、レコード追加、編集、複製
イベント	画面表示時、フィールド変更時、保存前のどこで実行するか
エラー	取得失敗時に保存させるか、止めるか
権限	取得元マスタを参照できるか
競合	他のカスタマイズやプラグインと干渉しないか
テスト	動作テスト環境と本番環境の違いを確認する

JavaScriptで自動取得する場合、取得失敗時の扱いが重要です。

値が取得できなかったのに、空欄のまま保存される。

エラーが出たが、ユーザーには意味が分からない。

モバイルでは動かない。

別のプラグインと競合する。

このような状態を防ぐため、テストケースを作ります。

プラグインを使う場合も、確認することはあります。

確認項目	見ること
対象フィールド	どのルックアップを自動取得するか
対象タイミング	新規作成、編集、キー変更、保存前
除外条件	承認済みや完了を除外できるか
権限	操作者権限か、プラグイン設定か
ログ	取得失敗や上書き結果を追えるか
サポート	バージョンアップ時の対応

プラグインなら安全、JavaScriptなら危険、という単純な話ではありません。

どちらでも、業務ルールが曖昧なら危険です。

テストケースを作る

ルックアップ自動取得は、正常系だけテストしても足りません。

次のケースを確認します。

テスト	確認すること
新規作成時	キー入力後に必要項目が取得されるか
キー未入力	自動取得しない、または保存時に止まるか
存在しないキー	分かるメッセージが出るか
重複キー	マスタ側の重複を検出できるか
編集時	既存値を勝手に上書きしないか
キー変更時	変更前後の値を確認できるか
承認済み	自動取得しないか
請求済み	自動取得しないか
モバイル	必要なら同じ動作をするか
権限不足	マスタ参照権限がないユーザーでどう見えるか
取得失敗	保存を止めるか、警告だけにするか

特に、承認済みと請求済みのテストは外さない方がよいです。

自動取得の不具合は、入力時よりも、後から値が変わってしまったときに問題になります。

また、テスト用に次の一覧を作ります。

一覧	目的
ルックアップ未取得一覧	キーはあるがコピー項目が空欄のレコードを見る
キー未入力一覧	保存前に防げなかった未入力を拾う
承認済み再取得候補	本来変えるべきでない状態を確認する
マスタ重複候補	自動取得前にキー重複を直す
取得エラー確認一覧	JavaScriptやプラグインの失敗を追う

自動取得は、実装したら終わりではありません。

未取得、誤取得、上書き、権限不足を見つける一覧まで作ります。

よくある失敗

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

失敗	起きること	対策
取得ボタンを消すことだけ考える	上書き可否が未整理のまま進む	状態別の自動取得ルールを作る
編集画面表示時に常に取得する	既存値が知らないうちに変わる	キー変更時や保存前検出に絞る
過去見積を自動取得する	当時の単価が壊れる	見積済み、承認済み、請求済みは固定する
プラグイン設定だけで済ませる	業務条件に合わない自動取得になる	設定前に対象項目と除外条件を表にする
JavaScriptの保守者がいない	仕様変更時に直せない	保守責任者とドキュメントを残す
モバイル確認をしない	現場端末で動かない	PC/モバイルを分けてテストする
取得失敗時に保存できる	空欄や古い値のまま残る	保存前チェックやエラー表示を入れる
マスタ重複を放置する	どの値を取得すべきか不明になる	キーの一意性を先に整える

自動取得は、設定やコードだけ見ると小さな改善に見えます。

しかし、コピー項目が金額、住所、承認者、税区分に関わる場合は、業務データの正確性に直結します。

「自動で入るようにする」ではなく、「自動で入れてよい状態だけにする」と考えます。

kintoneルックアップ自動取得は、上書き禁止まで設計して使う

kintoneルックアップ自動取得は、取得ボタンの押し忘れを減らす有効な手段です。

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

1. 新規作成時だけ自動取得するのか、編集時も対象にするのか
2. どのキー入力で取得するのか
3. どのコピー項目を上書きしてよいのか
4. 承認済み、請求済み、完了レコードを除外するのか
5. 手動取得、プラグイン、JavaScriptのどれで実装するのか
6. 取得失敗、権限不足、重複キーをどう検出するのか
7. テスト用一覧と運用チェックをどう作るのか

自動取得は、ルックアップの押し忘れをなくすだけの話ではありません。

コピー済みの業務データを、いつ更新し、いつ守るかの設計です。

Bitlightでは、kintoneルックアップ自動取得を、マスタ設計、上書き可否、状態別制御、プラグイン選定、JavaScript実装、テストケースまで含めて整理できます。

既存アプリで取得漏れや上書き事故が起きている場合は、まず自動取得対象と上書き禁止条件の棚卸しから始めるのが現実的です。

kintoneルックアップ設計の記事はこちら
kintone見積書作成の設計方法はこちら