kintone関連レコードの設計方法｜マスタと履歴を安全につなぐ構成

kintoneの関連レコード一覧は、複数アプリの情報をつなぐときに便利です。

顧客レコードに、その顧客の案件一覧を表示する。

顧客レコードに、問い合わせ履歴を表示する。

案件レコードに、見積履歴や活動履歴を表示する。

請求先レコードに、過去の請求や入金確認を表示する。

このような用途では、関連レコードがよく使われます。

ただし、関連レコードを「何でも一覧表示できる便利枠」として使うと、後から困ります。

実務でよく起きるのは、次のような状態です。

• ルックアップでコピーすべき値まで、関連レコードで見せるだけにしている
• 関連レコードで見えている値を、集計や帳票の正本だと思っている
• 顧客名を紐づけキーにして、社名変更で表示が崩れる
• アクセス権の違いで、人によって関連レコードの表示件数が違う
• 関連レコードを一覧画面やCSV出力で使えると思っている
• テーブル内の値で関連付けようとして制約に当たる
• 表示条件が曖昧で、完了案件や失注案件まで混ざる
• 関連レコードで集計したいが、標準機能だけでは足りない

関連レコードは、別アプリのレコードをコピーしません。

現在の条件に合うレコードを、画面上に表示します。

kintone関連レコードは、値をコピーして保存する機能ではなく、別アプリの履歴や現在状態を表示する機能として設計します。

この記事では、kintone関連レコード一覧を設計するときの、ルックアップとの違い、紐づけキー、顧客・案件・問い合わせ・請求の設計例、表示条件、アクセス権、一覧表示・集計・CSV出力の制約、関連レコードで足りないときの選択肢を整理します。

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

先に結論：関連レコードはコピーではなく表示

関連レコード一覧は、条件に合う別アプリのレコードを表示するためのフィールドです。

たとえば、顧客マスタの「顧客コード」と、案件アプリの「顧客コード」が一致する案件を、顧客レコード上に一覧表示します。

このとき、案件データが顧客レコードにコピーされるわけではありません。

案件アプリにあるレコードを、顧客レコードの画面で見ているだけです。

観点	関連レコード
データの持ち方	参照先アプリに残る
表示内容	条件に一致するレコード
マスタ変更の影響	表示条件や参照先の変更に影響される
帳票や計算の正本	原則として参照元アプリ側
向いている用途	履歴、関連案件、問い合わせ、請求履歴の確認

この性質を理解すると、使いどころがはっきりします。

顧客に紐づく案件履歴を見たい。

案件に紐づく活動履歴を見たい。

請求先に紐づく過去請求を見たい。

問い合わせ元の顧客に関する過去対応を見たい。

こうした「今ある別アプリの履歴を横断して見る」用途に向いています。

関連レコードは、履歴や関連情報を確認するための表示です。見積金額、請求先住所、承認時点の部門名のように当時値を残したい項目は、コピーや明細として持つ設計を検討します。

ルックアップとの違い

関連レコードと混同しやすいのがルックアップです。

ルックアップは、参照先アプリの値を取得先レコードにコピーします。

関連レコードは、参照先アプリのレコードを一覧表示します。

比較	ルックアップ	関連レコード
役割	値をコピーする	別アプリのレコードを表示する
保存先	取得先レコードに値が入る	表示元には値を保存しない
過去値	取得時点の値を残しやすい	参照先の現在状態を見る
入力補助	向いている	向いていない
履歴表示	向かないことが多い	向いている
集計・帳票	コピーした値を使える	標準では制約がある

たとえば、見積書に商品名と単価を入れるなら、ルックアップでコピーする方が自然です。

見積提出時点の商品名と単価を残す必要があるからです。

一方、顧客レコードに過去の案件や問い合わせを表示するなら、関連レコードが向いています。

案件や問い合わせは、それぞれのアプリに正本として残り、顧客画面では履歴として確認できればよいからです。

目的	選ぶ候補
入力時に顧客名や住所を自動入力したい	ルックアップ
顧客に紐づく案件を一覧で見たい	関連レコード
商品単価を見積明細に残したい	ルックアップ
顧客の過去問い合わせを見たい	関連レコード
集計値をレコードに持ちたい	集計用フィールド、プラグイン、カスタマイズ
別アプリへレコードを作成したい	アプリアクション、API

テクバンの記事でも、関連レコードは関連情報を一覧表示し、ルックアップはレコード入力時に参照先の情報を取得する機能として説明されています。

テクバン：kintone「関連レコード一覧」の便利な使い道

ルックアップと関連レコードは、どちらが上位という話ではありません。

コピーする必要があるならルックアップ。

コピーせず履歴を見たいなら関連レコード。

この分け方が基本です。

紐づけキーをどう決めるか

関連レコードは、現在のアプリと参照先アプリのフィールド値が一致するレコードを表示します。

kintone公式ヘルプでも、関連レコード一覧の設定で「このアプリのフィールド」と「参照先のアプリのフィールド」を選び、値が一致するレコードを表示する例が説明されています。

kintoneヘルプ：関連レコード一覧を設定する

ここで重要なのが、紐づけキーです。

顧客名でつなぐのか。

顧客コードでつなぐのか。

案件番号でつなぐのか。

請求先コードでつなぐのか。

おすすめは、名称ではなくコードです。

キー候補	評価	理由
顧客名	避けたい	社名変更、表記ゆれ、同名会社がある
顧客コード	使いやすい	名称変更に強い
案件名	避けたい	同じ名前の案件が起きる
案件番号	使いやすい	1案件を特定しやすい
メールアドレス	場合による	共有アドレスや変更がある
レコード番号	場合による	アプリをまたぐ業務IDとしては見えにくい

関連レコードの紐づけキーは、表示名ではなく業務上変わりにくいコードにします。顧客名や案件名でつなぐと、名称変更や表記ゆれで表示が崩れます。

キーは、参照先アプリにも同じ値を持たせます。

顧客マスタに顧客コード。

案件アプリにも顧客コード。

問い合わせアプリにも顧客コード。

請求アプリにも顧客コードまたは請求先コード。

このように持たせると、顧客レコードから関連する履歴を表示しやすくなります。

顧客・案件・問い合わせ・請求の設計例

関連レコードが特に使いやすいのは、マスタに紐づく履歴を見る場面です。

たとえば、顧客マスタを中心に次のように設計します。

表示元	参照先	紐づけキー	表示する情報
顧客マスタ	案件アプリ	顧客コード	案件名、ステータス、担当者、予定金額
顧客マスタ	問い合わせアプリ	顧客コード	問い合わせ日、種別、対応状況
顧客マスタ	請求アプリ	請求先コード	請求月、請求額、入金状態
案件アプリ	活動履歴アプリ	案件番号	活動日、内容、次回予定
案件アプリ	見積アプリ	案件番号	見積番号、提出日、金額、版

この構成にすると、顧客レコードを開くだけで、周辺情報を確認できます。

顧客の進行中案件。

過去問い合わせ。

未入金の請求。

直近の活動履歴。

これらを顧客レコードにコピーして持つ必要はありません。

正本は、それぞれのアプリに残します。

情報	正本	顧客レコードでの見せ方
案件状況	案件アプリ	関連レコードで表示
問い合わせ履歴	問い合わせアプリ	関連レコードで表示
請求・入金	請求アプリ	関連レコードで表示
顧客名・住所	顧客マスタ	通常フィールドで保持
見積金額	見積アプリ	必要なら関連レコードで表示

関連レコードは、ダッシュボードではなく、レコード詳細画面の文脈で見る情報です。

顧客を開いたときに、その顧客に関する履歴を横断して確認する。

案件を開いたときに、その案件に関する見積や活動を確認する。

この使い方が安定します。

表示条件とアクセス権の注意点

関連レコードは、表示条件とアクセス権の影響を受けます。

kintone公式ヘルプでは、表示するレコードの条件や絞り込み条件の判定には、レコードを閲覧するユーザーのアクセス権が影響すると説明されています。

条件に使うフィールドを閲覧できないユーザーでは、条件が正しく判定されません。

また、参照先アプリや参照先レコードの閲覧権限がない場合、関連レコードは表示されません。

論点	起きること	設計
参照先アプリの閲覧権限	人によって表示件数が変わる	権限ごとの見え方を確認する
条件に使うフィールド権限	条件判定が想定通りにならない	紐づけキーは閲覧可能にする
参照先レコード権限	一部履歴だけ見えない	顧客担当、部門、役割で整理する
表示フィールド権限	列はあっても値が見えない	表示項目を権限込みで決める
ゲストスペース	参照範囲が限られる	外部共有用は別設計にする

これは欠点ではありません。

むしろ、権限を反映した表示になることは重要です。

ただし、管理者が見る件数と、現場担当が見る件数が違うことを前提にします。

関連レコードを使う場合は、次のロールで表示確認します。

ロール	確認すること
管理者	すべての関連レコードが見えるか
営業担当	自分の顧客・案件だけ見えるか
経理	請求・入金は見えるが、不要な案件情報は見えないか
サポート	問い合わせ履歴と契約状態が見えるか
外部ユーザー	見せてはいけない履歴が出ていないか

関連レコードは、同じ設定でもユーザーごとに見え方が変わります。

だから、設定後に権限別の画面確認が必要です。

一覧表示・集計・CSV出力の制約

関連レコードは便利ですが、標準機能では制約があります。

kintone公式ヘルプでは、関連レコード一覧フィールドはレコードの一覧画面には表示できず、値をファイルに書き出せず、集計・自動計算・アプリ内検索の対象にもならないと説明されています。

また、関連レコード一覧の表示フィールドには、関連レコード一覧、テーブル、グループ、ラベル、スペース、罫線などを設定できません。

やりたいこと	関連レコード標準機能だけでの考え方
レコード詳細で履歴を見る	向いている
一覧画面に関連履歴を表示する	向かない
関連レコードの金額を合計する	標準では制約がある
関連レコードをCSV出力する	値自体は書き出せない
アプリ内検索の対象にする	対象にならない
帳票に一覧として出す	帳票ツールや別設計を検討する

関連レコードは「画面で確認する表示」です。一覧、集計、CSV、帳票の正本として使うなら、集計用アプリや明細アプリなど別の持ち方を検討します。

関連レコードに見えているからといって、その値をそのまま集計できるわけではありません。

たとえば、顧客マスタに関連レコードで請求履歴を表示していても、顧客レコード側で合計請求額を標準計算することはできません。

合計が必要なら、次のような方法を考えます。

要件	選択肢
画面で履歴を見たい	関連レコード
合計金額を持ちたい	集計用フィールド、プラグイン、カスタマイズ
月次レポートにしたい	集計アプリ、CSV、外部BI
帳票に明細を出したい	帳票ツール、明細アプリ
検索対象にしたい	参照先アプリで検索する

関連レコードで足りないときの選択肢

関連レコードで足りない場合は、無理に関連レコードを拡張し続けるより、別の方法を選びます。

不足すること	選択肢
値を固定したい	ルックアップでコピーする
別アプリにレコードを作りたい	アプリアクション、API
合計値を持ちたい	集計プラグイン、JavaScript、集計アプリ
明細単位で状態管理したい	明細アプリに分ける
一覧画面で横断確認したい	専用の確認アプリや集計ビューを作る
外部帳票へ出したい	帳票ツール、CSV、API連携

たとえば、顧客レコードに案件履歴を表示するだけなら関連レコードで十分です。

しかし、顧客ごとの受注金額合計を顧客レコードに持ちたいなら、関連レコードだけでは足りません。

案件アプリ側で集計する。

集計結果を顧客マスタへ反映する。

外部BIやスプレッドシートに出す。

プラグインやJavaScriptで合計を表示する。

このように目的に合わせて選びます。

よくある失敗

kintone関連レコードでよくある失敗は、次の通りです。

失敗	起きること	対策
顧客名で紐づける	社名変更や表記ゆれで表示が崩れる	顧客コードでつなぐ
コピーすべき値を関連レコードで済ませる	帳票や計算に使えない	ルックアップや明細として持つ
関連レコードを集計できると思う	合計や検索で詰まる	集計用の設計を別に作る
アクセス権を確認しない	人によって表示件数が違う	ロール別に画面確認する
表示条件が広すぎる	完了・失注・古い履歴が混ざる	絞り込み条件を決める
関連レコードを一覧画面で使おうとする	一覧に表示できない	詳細画面用と割り切る
テーブル内フィールドでつなごうとする	制約に当たる	通常フィールドや明細アプリを使う

関連レコードは、きれいに使うと画面の見通しが良くなります。

ただし、便利に見える分、正本・集計・帳票・権限の責任を曖昧にしがちです。

kintone関連レコードは、マスタと履歴をつなぐ表示として設計する

kintone関連レコードを設計するときは、次の順番で考えます。

1. 関連レコードで表示したい履歴を決める
2. 値をコピーすべき項目と、表示だけでよい項目を分ける
3. 顧客コード、案件番号など変わりにくい紐づけキーを決める
4. 表示条件と絞り込み条件を決める
5. 表示フィールドを最小限に絞る
6. アクセス権ごとの見え方を確認する
7. 一覧、集計、CSV、帳票に使う場合は別設計を検討する

関連レコードは、データをコピーして増やす機能ではありません。

マスタと履歴をつなぎ、詳細画面で必要な情報を確認するための表示です。

Bitlightでは、kintone関連レコードを、顧客、案件、問い合わせ、請求、活動履歴のアプリ構成、紐づけキー、アクセス権、集計用アプリ、帳票・CSV連携まで含めて設計できます。

既存アプリで関連レコードが増えすぎている場合は、まず「表示で足りる情報」と「コピー・集計・明細として持つ情報」を分けるところから始めるのが現実的です。

kintone顧客管理の設計方法はこちら
kintone案件管理の設計方法はこちら