kintoneテーブルルックアップの設計方法｜明細コピーとマスタ参照の分け方

kintoneで見積書、注文書、作業報告、価格表を作ると、テーブルとルックアップを組み合わせたくなります。

見積アプリの明細テーブルで、商品コードを入力して商品名と単価を取得したい。

商品マスタにある価格表テーブルを、見積明細へまとめてコピーしたい。

顧客ごとの契約明細を、請求アプリの明細へ取り込みたい。

作業メニューの一覧を、作業報告のテーブルへ反映したい。

このとき、全部を「テーブルルックアップ」と呼んでしまうと設計を間違えます。

実際には、次の3つは別の話です。

やりたいこと	典型例	設計の方向
テーブル内の各行でルックアップしたい	見積明細の各行で商品コードから商品名・単価を取得	標準ルックアップで検討する
参照元のテーブル明細を丸ごとコピーしたい	価格表テーブルを見積明細へ展開	プラグイン、JavaScript、外部連携を検討する
明細を常に最新で見たい	商品ごとの最新価格、契約明細、在庫明細	関連表示や明細アプリ分割を検討する

テーブルルックアップで失敗しやすいのは、標準機能の範囲を超えたまま、見積・請求・集計・帳票まで作り込んでしまうことです。

• 商品マスタのテーブル明細を、標準ルックアップで丸ごとコピーできると思っている
• 見積提出時点の単価を残すべきなのに、最新価格を毎回再取得してしまう
• 常に最新の契約明細を見たいだけなのに、請求アプリへコピーして固定している
• テーブル行数が増えすぎて、帳票出力やCSV更新が扱いづらい
• テーブル内の値で関連レコードや集計を作ろうとして詰まる
• 明細ごとの承認、出荷、請求、消込が必要なのに、1レコード内のテーブルで抱えている

kintoneテーブルルックアップで最初に決めるべきなのは、実装方法ではなく、明細データの正本をどこに置くかです。

この記事では、kintoneテーブルルックアップを設計するときの、標準ルックアップでできること、参照元テーブルをコピーできない制限、サブテーブルルックアッププラグイン、明細をコピーすべき業務と参照すべき業務、明細アプリに分ける判断、マスタ更新時の再取得、帳票・集計・CSV出力への影響を整理します。

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

先に結論：テーブルをコピーする前に正本を決める

テーブルルックアップで最初に決めるのは、明細の正本です。

正本とは、後から見返したときに「この値が業務上の正式な値」と言える場所です。

明細の種類	正本にしやすい場所	理由
見積明細	見積アプリのテーブル	提出時点の商品名・単価を固定したい
注文明細	注文アプリのテーブル、または注文明細アプリ	出荷・請求とつながるなら分ける
価格表	商品マスタ、価格表アプリ	最新価格と適用期間を管理したい
契約明細	契約明細アプリ	契約ごとの期間、数量、請求単位を持つ
作業明細	作業報告アプリのテーブル、または作業明細アプリ	行ごとの担当者や工数管理が必要なら分ける

たとえば、見積書の明細は、提出時点の値を残す必要があります。

商品名や単価が後から変わっても、過去に提出した見積明細まで変わると困ります。

この場合は、見積アプリのテーブルに商品名や単価をコピーして固定する設計が自然です。

一方、価格表は最新状態や適用開始日を管理したいデータです。

見積明細へ毎回丸ごとコピーするより、価格表アプリや商品マスタ側で正本として管理し、見積作成時点で必要な値だけコピーする方が扱いやすくなります。

明細をコピーするのは、当時値として固定したい場合です。常に最新を見たいなら、テーブルにコピーする前に関連表示や明細アプリ分割を検討します。

標準ルックアップでできることとできないこと

kintoneの標準機能でも、テーブル内にルックアップフィールドを配置できます。

kintone公式ヘルプのルックアップ設定例でも、注文管理アプリのテーブルにルックアップを配置し、商品コードをもとに商品名や単価を取得する例が紹介されています。

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

これは、見積明細や注文明細ではよく使う構成です。

テーブル内の列	例
ルックアップキー	商品コード
コピー項目	商品名、単価、税区分
入力項目	数量、値引、備考
計算項目	小計、税額、税込金額

この構成なら、各明細行で商品コードを入力し、商品マスタから必要な項目を取得できます。

ただし、標準ルックアップでできるのは、基本的に「1行ごとに1レコードを取得する」ことです。

参照元アプリのテーブルに入っている複数行を、取得先アプリのテーブルへ丸ごと展開する機能ではありません。

kintone公式ヘルプでは、テーブル内のフィールドは、ルックアップフィールドのコピー元のフィールドや、ほかのフィールドのコピーには指定できないと説明されています。

kintoneヘルプ：テーブルに設定したフィールドで使えない機能

つまり、次の違いを分けます。

やりたいこと	標準機能の考え方
見積明細の各行で商品コードを取得する	テーブル内にルックアップを置いて対応しやすい
商品マスタの通常フィールドをコピーする	ほかのフィールドのコピーで対応しやすい
商品マスタのテーブル明細を丸ごとコピーする	標準ルックアップだけでは設計しにくい
テーブル内フィールドをルックアップ元にする	制限がある
テーブル内フィールドを関連レコード条件に使う	制限がある

標準ルックアップは、テーブル内の各行で商品や顧客を取得する用途には向きます。一方で、参照元のサブテーブルを丸ごとコピーする用途は、別の設計が必要です。

サブテーブルルックアッププラグインの使いどころ

参照元アプリのテーブル明細を、取得先アプリのテーブルへコピーしたい場合は、プラグインや連携サービスを検討します。

トヨクモの記事では、kintoneのテーブルをルックアップする方法として、DataCollect、ルックアップ内サブテーブルコピープラグイン、ルックアップ自動取得プラグインなどが比較されています。

トヨクモ：kintoneのテーブルをルックアップする方法

Morinohiのサブテーブルルックアッププラグイン設定ガイドでも、標準のルックアップ、キー項目、コピーしたいテーブルのフィールド、コピー先・コピー元フィールドを設定する流れが説明されています。

Morinohi：サブテーブルルックアッププラグイン設定ガイド

プラグインが向くのは、次のような場面です。

場面	例
明細をまとめて転記したい	契約明細を請求予定明細へコピーする
テンプレート明細を展開したい	作業メニューを作業報告へコピーする
セット商品を明細化したい	セット品を構成品明細へ展開する
顧客別単価表を取り込みたい	顧客ごとの価格表を見積明細へコピーする
手入力を減らしたい	定型行を毎回入力しない

ただし、プラグインを入れる前に、次を決めます。

• コピー後の明細は、当時値として固定するのか
• 参照元のテーブルが変わったとき、コピー済み明細を再取得するのか
• コピー先の明細をユーザーが編集できるのか
• どのタイミングでコピーするのか
• コピー済み明細に行IDや参照元IDを残すのか
• 帳票や集計はコピー後の値を見るのか、参照元を見るのか

プラグインは、明細をコピーする操作を助けます。

しかし、コピーした後の明細が正本になるのか、一時的な入力補助なのかは、業務側で決める必要があります。

明細をコピーすべき業務と参照すべき業務

テーブル明細をコピーするか、参照するかは、過去値を残す必要で決めます。

業務	コピーが向く	参照が向く
見積	提出時点の商品名・単価を固定する	最新価格表を確認する
注文	注文時点の条件を固定する	現在の在庫や商品状態を見る
請求	請求時点の明細を固定する	契約マスタの最新状態を見る
作業報告	実施した作業内容を固定する	作業メニューの標準単価を見る
契約	契約締結時点のプランを固定する	最新プラン表を参照する

コピーが向くのは、帳票や証跡に残る値です。

見積書。

注文書。

請求書。

契約書。

作業報告書。

これらは、発行時点の内容を後から再現できる必要があります。

一方、参照が向くのは、現在状態を見たい値です。

現在の在庫数。

現在の担当者。

現在の契約ステータス。

最新の価格表。

最新の作業メニュー。

これらを毎回テーブルへコピーすると、データが増え、更新漏れも起きます。

判断軸	コピー	参照
過去時点の値を残す	必要	不要
帳票に出す	その時点の値を出す	最新値を確認用に見る
後から編集する	コピー先で管理する	参照元で管理する
マスタ変更の影響	原則受けない	受ける
集計	コピー先を集計する	参照元や明細アプリを集計する

テーブルルックアップを使う前に、この表を業務ごとに作ります。

テーブルではなく明細アプリに分ける判断

すべての明細をテーブルで持つ必要はありません。

明細が増えたり、明細ごとに状態管理が必要になったりする場合は、別アプリに分けた方がよいです。

テーブルで足りる	明細アプリに分けた方がよい
1レコード内で完結する	明細ごとに担当者、状態、期限がある
行数が少ない	行数が多い、追加変更が頻繁
帳票出力が主目的	集計、検索、承認、連携が重要
明細単位の権限が不要	明細単位で閲覧・編集を分けたい
見積や報告のスナップショット	出荷、請求、入金、在庫と連動する

たとえば、見積書の明細はテーブルで足りることが多いです。

見積1件に対して、商品行が数行から十数行。

提出時点の金額を残す。

帳票PDFを出す。

この程度なら、見積アプリのテーブルで扱いやすいです。

一方、注文後に明細ごとに出荷、検収、請求、入金を追うなら、テーブルでは苦しくなります。

その場合は、注文アプリと注文明細アプリを分けます。

親アプリ	明細アプリ	つなぎ方
見積	見積明細	見積番号、明細番号
注文	注文明細	注文番号、商品コード
契約	契約明細	契約番号、サービスコード
作業報告	作業明細	報告番号、作業コード
請求	請求明細	請求番号、売上明細ID

明細アプリに分けると、関連レコードや一覧、CSV、外部連携で扱いやすくなります。

ただし、画面上で1つの表として入力したい場合は、入力体験を別途設計する必要があります。

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

テーブルルックアップでも、マスタ更新時の扱いは重要です。

ルックアップでコピーした値は、マスタ更新で自動的に最新になるとは限りません。

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

そのため、明細ごとに再取得ルールを決めます。

明細	再取得する	再取得しない
未提出見積	商品名変更、税区分修正	提出済み見積、受注済み
未確定注文	商品名、配送条件	出荷済み、請求済み
作成中請求	請求先住所、担当者	請求書発行済み
未承認申請	部門名、責任者候補	承認済み、完了
作業予定	作業メニュー名	作業報告済み

テーブル内のルックアップも、再取得すれば当時値が変わります。見積・請求・契約の明細では、提出済みや発行済みを再取得しないルールが必要です。

再取得ルールは、テーブルの外に持つこともあります。

ステータス。

提出日。

請求済みフラグ。

更新除外フラグ。

マスタ適用開始日。

これらを使って、再取得してよい明細と、固定すべき明細を分けます。

帳票・集計・CSV出力への影響

テーブルルックアップは、帳票や集計にも影響します。

見積書や請求書では、テーブル明細をそのまま帳票に出します。

そのため、コピー元のマスタ値ではなく、コピー後のテーブル値が帳票の根拠になります。

影響範囲	確認すること
帳票	明細行の表示順、単価、税区分、小計
集計	テーブル内の金額をどう集計するか
CSV	テーブル行を含む出力・取込の形式
更新	テーブル内ルックアップを一括更新できるか
権限	テーブル内フィールドに個別のアクセス権を設定できるか
連携	外部システムが明細行をどう受け取るか

kintoneヘルプでは、テーブル内フィールドにはいくつかの制限があり、ファイル読み込みや権限、関連レコード条件にも注意が必要です。

kintoneヘルプ：ファイルを読み込むアプリを確認する

テーブルに明細を入れるほど、1レコードの中に多くの情報が閉じます。

帳票には向きます。

しかし、明細単位の検索、集計、承認、連携には向かない場面があります。

要件	テーブルのまま	明細アプリ化
帳票PDFを出す	扱いやすい	帳票側で結合が必要
明細単位で検索する	条件に制限が出やすい	扱いやすい
明細単位で集計する	集計設計が必要	扱いやすい
明細ごとにステータス管理	難しくなりやすい	扱いやすい
外部連携	CSVやAPI処理が複雑になりやすい	連携しやすい

この判断をせずに、全部をテーブルに入れると後から移行が大きくなります。

よくある失敗

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

失敗	起きること	対策
参照元テーブルを標準ルックアップでコピーできると思う	設計途中で詰まる	標準、プラグイン、明細アプリ分割を先に比較する
明細の正本を決めない	どの値が正式か分からない	コピー後の値か、マスタ側かを決める
提出済み見積を再取得する	過去の提出金額が変わる	ステータスで再取得を止める
テーブルに詰め込みすぎる	集計・検索・連携がつらくなる	明細アプリ化を検討する
プラグインで全行コピーするだけ	更新後の扱いが決まらない	編集可否、再取得、ログを決める
行ごとのIDを持たない	後で差分追跡できない	明細番号や参照元IDを持たせる
帳票だけ見て設計する	後から集計要件に対応できない	帳票、集計、連携を同時に見る

テーブルルックアップは、入力画面だけ見ると便利です。

しかし、業務システムとしては、マスタ、明細、帳票、集計、再取得、CSV更新まで影響します。

kintoneテーブルルックアップは、明細コピーとマスタ参照を分けて設計する

kintoneテーブルルックアップを設計するときは、次の順番で考えます。

1. 明細データの正本を決める
2. テーブル内の各行でルックアップするだけか、参照元テーブルを丸ごとコピーしたいのかを分ける
3. 標準ルックアップで足りる範囲を確認する
4. サブテーブルコピーが必要なら、プラグインやJavaScriptを検討する
5. 明細ごとに状態管理が必要なら、明細アプリに分ける
6. マスタ更新時に再取得する明細と固定する明細を分ける
7. 帳票、集計、CSV出力、外部連携への影響を見る

テーブルルックアップは、単なる入力補助ではありません。

見積、注文、請求、契約、作業報告の明細を、どの時点の値として残すかを決める設計です。

Bitlightでは、kintoneのテーブルルックアップを、標準機能、プラグイン、JavaScript、明細アプリ分割、帳票・集計・CSV連携まで含めて設計できます。

既存アプリでテーブル明細が増えすぎている場合は、まず「テーブルに残す明細」と「別アプリへ分ける明細」を整理するところから始めるのが現実的です。

kintone見積書作成の設計方法はこちら
kintoneデータベース設計の考え方はこちら