目次
kintoneのルックアップは、取引先マスタや商品マスタから単価や住所を引っ張ってくる、業務アプリの土台になる機能です。便利な一方で、「取得」が走っていない行が静かに残るという落とし穴があります。
実案件（匿名）で起きたのは、請求金額がゼロのまま帳票に乗っていた、という事象でした。エラーも出ず、画面上も違和感がないため、誰も気づかないまま件数が積み上がっていました。
さらに厄介だったのは、その是正です。「まとめて再取得すれば直る」と考えて一括更新をかけていたら、今度は過大計上という逆方向の事故になっていました。この記事では、何が起きて、どう直すのが正道だったのかを整理します。
この記事の結論
- ルックアップは取得時点のコピー。設計変更は既存レコードに遡らない
- 検出スクリプトの初版は誤検知だらけになる前提で組む
- 一括更新は「全行が正しい」前提が成り立つときだけ使える
kintoneルックアップの「取得漏れ」とは
ルックアップは、参照先アプリから値をその時点でコピーする仕組みです。参照元とリアルタイムに同期しているわけではありません。
つまり、ユーザーが「取得」を押していなければ値は入りませんし、押した後に参照先の値が変わっても、既存レコードは古いままです。この性質自体は仕様ですが、空欄が数値フィールドで0として扱われると、請求金額のゼロという形で表面化します。
取得漏れが起きる原因：設計変更が既存レコードに反映されない
原因の多くは、運用中の設計変更です。ルックアップのフィールドを追加した、参照先を差し替えた、コピー元の項目を増やした——こうした変更は新しく作るレコードにしか効きません。
変更前に作られた行は、そのまま残ります。しかも kintone は「取得していない」ことをエラーにしないため、保存も一覧表示も普通に通ってしまいます。人の目には「入力済みの正常なレコード」に見える、これが発見を遅らせる最大の理由です。
取得漏れの検出方法：スクリプトの初版は誤検知だらけになる
件数が多いと目視では追えないため、スクリプトで機械的に抽出することになります。ただし、実案件で最初に書いた監査スクリプトは、検出結果の大半が誤検知でした。
理由は単純で、「空欄＝異常」と定義したからです。実務では、そもそも金額が発生しない区分の行、キャンセル済みの行、集計対象外の期間の行など、空欄で正しい行がいくらでもあります。
そこで条件を是正し、対象期間・ステータス・区分で絞り込んだうえで、「本来値が入るはずなのに入っていない行」だけを残しました。ここまで絞って初めて、人が一件ずつ確認できる量になります。
| 検出条件の作り方 | 結果 |
|---|---|
| 空欄をすべて異常とみなす | 誤検知が大量に出て、確認作業が破綻する |
| 期間・ステータス・区分で絞る | 実害のある行だけが残り、確認が現実的になる |
監査スクリプトは「一発で正解を出す道具」ではなく、条件を直しながら精度を上げていく道具だと考えたほうがうまくいきます。
一括再取得をしてはいけない理由
洗い出しが終わると、次に「まとめて再取得すれば直る」という発想が出てきます。ここが最大の分岐点でした。
対象データを確認すると、箱数を入れる欄に個数が混入している行がありました。入力ルールが徹底されていない期間があり、単位の違う数字が同じ欄に入っていたのです。
この状態で一括再取得をかけるとどうなるか。ルックアップは入っている数字を素直に信じて単価を掛けます。結果、桁違いの金額が自動計算で確定します。しかもエラーは出ません。ゼロだった金額が「それらしい数字」に変わるため、目視でも気づきにくい。ゼロのままの取得漏れより、こちらのほうがはるかに危険です。
一括更新は作業を速くしますが、間違いも同じ速度で全行に広げます。
正しい是正の進め方
正道は、行ごとに正解値と突合することでした。手間はかかりますが、金額に直結するデータでは、この手順を省略した瞬間に事故になります。
- 対象行を絞り込む：条件を是正した監査結果で、実害のある行だけに限定する
- 元の伝票と突合する：kintone上の数字ではなく、注文書や納品書など一次情報と照合する
- 入力欄の誤りを是正する：単位違いなど、そもそもの入力ミスを先に直す
- 個別に再取得する：正しい前提が揃った行だけ、値を取り直す
順番が重要です。3と4を逆にすると、誤った値をもとに計算が確定します。
一括更新を使ってよい条件
とはいえ、一括更新が常に悪いわけではありません。判断軸は一つです。
一括更新は、「全行が正しい」という前提が成り立つときだけ使える。
前提が成り立つのは、たとえば入力欄に選択肢やバリデーションがかかっていて、そもそも単位違いが入り得ない場合。逆に、自由入力の数値欄が長く運用されてきたアプリでは、この前提はまず成り立ちません。
再発防止の観点では、是正後に入力欄そのものを直すことが本命です。単位が混ざる欄はドロップダウンに変える、必須チェックを入れる、ルックアップ未取得を保存時に検知する——ここまでやって初めて、同じ問題が二度起きなくなります。なお kintone の仕様やプラグインの挙動は変わるため、最新の条件は公式サイトで確認してください。
よくある質問
Q. kintoneでルックアップの値が入っていないレコードがあるのはなぜですか？ ルックアップは「取得」ボタンを押した時点の値をコピーする仕組みで、後からフィールドや参照先を変更しても既存レコードには反映されません。設計変更前に作られた行は、空欄やゼロのまま残ります。
Q. ルックアップの取得漏れを一括再取得で直してもよいですか？ 原則として避けてください。参照キーとなる欄に誤入力が混じっていると、再取得によって桁違いの金額が入り、静かに過大計上が発生します。一括更新は全行が正しい前提が成り立つときだけ有効です。
Q. 取得漏れのレコードはどうやって洗い出せばよいですか？ スクリプトで機械的に抽出しますが、初版は誤検知が大量に出る前提で組みます。対象期間・ステータス・空欄の定義を実務に合わせて絞り込み、実害のある行だけに絞ってから人が確認する流れが安全です。
まとめ
- ルックアップは取得時点のコピー。設計変更は既存レコードに遡らない
- 監査スクリプトは条件を是正しながら、実害のある行だけに絞り込む
- 入力欄に誤りが混じったまま一括再取得をかけると、過大計上を量産する
- 是正は行ごとに一次情報と突合するのが正道。速さより順番を守る
RENOYでは、kintoneのデータ品質診断や、取得漏れ・入力ゆれの是正設計をご支援しています。「金額の数字が合っているか自信がない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。