kintone関連レコードを一覧に表示する設計方法｜標準制約と代替案

kintoneの関連レコード一覧は、顧客、案件、問い合わせ、請求、活動履歴をつなぐときに便利です。

顧客レコードを開くと、その顧客の案件一覧が見える。

案件レコードを開くと、見積履歴や活動履歴が見える。

請求先レコードを開くと、過去請求や入金状態が見える。

このように、レコード詳細画面で周辺情報を見る用途には向いています。

ただし、運用が進むと、次の要望が出ます。

• 顧客一覧で、各顧客の直近案件を一緒に見たい
• 商品一覧で、最近の入出庫履歴を見たい
• 案件一覧で、関連する問い合わせや見積履歴を見たい
• 請求先一覧で、未入金の請求を見たい
• 1件ずつ詳細画面を開かず、一覧上で比較したい
• 関連レコードにある金額や件数を一覧に出したい

気持ちは自然です。

一覧画面は、複数レコードを横に見比べる場所です。

関連レコードも一緒に出せれば、画面移動は減ります。

しかし、ここには標準機能の制約があります。

kintoneの関連レコード一覧フィールドは、標準機能ではレコード一覧画面に表示できません。

また、関連レコード一覧の値は、ファイル書き出し、集計、自動計算、アプリ内検索の対象にもなりません。

kintone関連レコードを一覧に表示したいときは、まず「履歴をそのまま横に出したい」のか、「判断に必要な要約だけを一覧に出したい」のかを分けます。

この記事では、kintone関連レコードを一覧に表示したいときに、標準機能でできないこと、詳細画面のままでよいケース、集計値だけ親レコードに持たせるケース、プラグインで一覧表示するケース、カスタムビューやダッシュボードへ分けるケース、権限・表示件数・画面速度の注意点を整理します。

kintone関連レコードの設計方法はこちら
kintone関連レコード集計の設計方法はこちら

先に結論：標準一覧に関連レコード一覧フィールドは出せない

kintone公式ヘルプでは、関連レコード一覧を表示するには、参照したいアプリ、紐づけたいフィールド、表示したいフィールドを設定すると説明されています。

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

同じヘルプの補足では、関連レコード一覧フィールドはレコード一覧画面には表示できないとされています。

さらに、関連レコード一覧フィールドの値は、ファイルに書き出せず、集計、自動計算、アプリ内検索の対象にもなりません。

つまり、標準機能だけで次のような一覧は作れません。

やりたいこと	標準機能だけでの考え方
顧客一覧に案件履歴をそのまま出す	関連レコード一覧フィールドは一覧に表示できない
商品一覧に入出庫履歴を出す	詳細画面で見る前提になる
一覧に関連レコードの明細を横展開する	標準一覧の列としては扱えない
関連レコードの値で一覧検索する	アプリ内検索の対象にならない
関連レコードの値をCSV出力する	関連レコード一覧の値は書き出せない
関連レコードの件数や合計を計算する	別途保存値や集計処理が必要

これは、関連レコードが弱いというより、役割の違いです。

関連レコード一覧は、レコード詳細画面の文脈で、条件に合う別アプリのレコードを表示する機能です。

一覧画面は、現在のアプリのレコードを横に並べる画面です。

別アプリの複数レコードをそのまま一覧列に持ち込むと、列幅、件数、読み込み、権限、並び順が一気に複雑になります。

標準機能の関連レコードは、詳細画面で履歴を確認するための表示です。一覧で比較・検索・出力したい情報は、別の持ち方を設計します。

一覧に出したい理由を整理する

関連レコードを一覧に出したい理由は、現場によって違います。

理由が違うと、選ぶ方法も変わります。

一覧に出したい理由	代表例	向きやすい方法
詳細画面を開く回数を減らしたい	顧客ごとの直近案件を確認したい	プラグイン、要約フィールド
判断に必要な状態だけ見たい	未入金あり、未対応あり、最終活動日	親レコードに保存
金額や件数を比較したい	累計受注額、未入金件数	集計値保存、集計アプリ
関連履歴そのものを一覧で見たい	最近の問い合わせ3件を表示	プラグイン、カスタムビュー
大量データを分析したい	月別・部門別・担当者別に見る	集計アプリ、ダッシュボード
外部提出や二次加工をしたい	CSV、帳票、Excel提出	出力用アプリ、帳票設計

たとえば、顧客一覧で「未対応問い合わせがあるか」を知りたいだけなら、問い合わせ履歴をそのまま一覧に出す必要はありません。

顧客レコードに「未対応問い合わせ件数」「最終問い合わせ日」「要確認フラグ」を保存すれば足ります。

一方、商品一覧で直近の入出庫履歴を3件だけ見たいなら、関連レコード一覧を一覧上に表示するプラグインが合うかもしれません。

さらに、月別の入出庫数や担当者別の対応件数を見たいなら、一覧表示ではなく集計アプリやダッシュボードの領域です。

一覧に出すべきかどうかは、次の順で判断します。

1. 詳細画面を開けば足りるか
2. 要約値を親レコードに保存すれば足りるか
3. 関連レコードそのものを一覧で見る必要があるか
4. 分析画面や集計アプリへ分けるべきか

この順で考えると、一覧画面が重くなりにくくなります。

詳細画面のままでよいケース

関連レコードを一覧に出したくなっても、詳細画面のままでよいケースは多いです。

特に、次の条件に当てはまるなら、標準の関連レコード一覧で十分です。

詳細画面でよいケース	理由
関連履歴を確認する頻度が低い	一覧を重くするほどの効果がない
1件ごとの文脈を見ながら判断する	詳細画面の方が情報を置きやすい
関連レコードの件数が多い	一覧に出すと画面が読みにくい
表示項目が多い	一覧列に押し込むと判別しづらい
権限が複雑	一覧での見え方確認が増える
編集やコメント確認が必要	結局、詳細画面へ移動する

たとえば、顧客レコードで過去の問い合わせ全文を読む場合、一覧画面に出しても読み切れません。

問い合わせ日、種別、担当者、対応状況、本文、添付、コメントまで確認するなら、詳細画面で開いた方が自然です。

案件の活動履歴も同じです。

一覧で全履歴を並べるより、顧客または案件レコードを開き、必要な履歴だけを確認する方が、画面としては安定します。

詳細画面のままにするなら、代わりに次を整えます。

• 関連レコード一覧の表示項目を絞る
• 並び順を「更新日降順」「対応日降順」などにする
• 一度に表示する最大レコード数を用途に合わせる
• 詳細画面の上部に重要な関連レコードを配置する
• タブやグループで関連情報を整理する
• 見るべき関連レコードがあることを親レコード側のフラグで知らせる

一覧表示は万能ではありません。関連レコードの中身を読んで判断する業務では、詳細画面を見やすくする方が安定します。

集計値だけ親レコードに持たせるケース

一覧で見たいものが、履歴そのものではなく要約なら、親レコードに保存する設計を検討します。

たとえば、顧客一覧で次の情報を見たいケースです。

一覧で見たい情報	親レコードに持たせるフィールド例
進行中案件があるか	進行中案件件数
未対応問い合わせがあるか	未対応問い合わせ件数
最後に接触した日	最終活動日
未入金があるか	未入金請求件数、未入金額
直近の受注状況	最終受注日、累計受注額
要確認の履歴があるか	要確認フラグ

この方法なら、標準のレコード一覧に表示できます。

検索、絞り込み、ソート、通知、帳票、CSV出力にも使いやすくなります。

ただし、集計値を保存するなら、再計算ルールが必要です。

kintone関連レコード集計の記事でも整理している通り、保存した集計値には、集計日時と集計状態を持たせます。

フィールド	役割
最終活動日	関連活動履歴の最新日
未対応件数	条件に合う関連レコード数
未入金額	請求アプリの未入金合計
集計日時	いつ時点の数字か
集計状態	正常、再計算待ち、エラー

親レコードに要約値を持つと、一覧画面は軽く保てます。

関連レコードそのものは詳細画面で見る。

一覧では、判断に必要な要約だけを見る。

この分け方が、実務ではかなり使いやすいです。

プラグインで一覧表示するケース

関連レコードそのものを一覧上で見たいなら、プラグインが候補になります。

コムデックAIラボの記事では、kintoneの関連レコードは標準機能では一覧画面に表示できないため、関連レコード一覧表示系のプラグイン、関連レコード拡張系のプラグイン、krewSheetなどの選択肢が紹介されています。

コムデックAIラボ：kintoneで関連レコードを一覧に表示するには？

縁の下の「一覧画面で関連レコード」プラグインでは、任意の一覧上に関連レコードを表示し、表示された関連レコードをクリックして参照先レコードを開く機能が紹介されています。

縁の下：一覧画面で関連レコード

プラグインが向いているのは、次のようなケースです。

向いているケース	理由
関連レコードの項目数が少ない	一覧上でも読める
直近数件だけ見ればよい	画面が重くなりにくい
詳細画面を頻繁に開いている	画面移動を減らせる
クリックで参照先を開ければ十分	一覧上で全編集しなくてよい
プラグインの保守担当がいる	設定変更時に対応できる

一方、次のような場合は慎重に見ます。

注意が必要なケース	理由
関連レコードが大量にある	読み込みが重くなりやすい
表示したい項目が多い	一覧が横に広がりすぎる
権限が細かい	ユーザーごとの見え方確認が増える
関連条件を頻繁に変える	プラグイン設定の追従が必要になる
一覧上で編集したい	製品によって制約がある

製品ごとの制約も確認します。

たとえば、縁の下のページでは、一覧上に表示するフィールドは5つまで、一度に取得できる関連レコードは50件まで、関連レコード条件を変更した場合はプラグイン設定の再保存が必要、といった注意点が示されています。

これは、その製品固有の仕様ですが、一覧表示プラグイン全般でも見るべき観点です。

一覧に出せるかだけでなく、何件まで現実的に読めるか、項目数を絞れるか、条件変更時に誰が設定を直すかを確認します。

カスタムビューや外部画面にするケース

プラグインで足りない場合、JavaScriptカスタマイズや外部画面を検討します。

ただし、カスタムビューは最後の手段に近いです。

理由は、一覧表示のために別アプリの関連レコードを取得し、組み合わせ、表示し、権限やエラーを扱う必要があるからです。

方法	向いているケース	注意点
JavaScriptで標準一覧を拡張	少量の関連情報を補助表示したい	一覧イベント、取得件数、表示崩れを管理する
カスタムビュー	独自の一覧画面が必要	標準一覧の操作感と変わる
外部画面	kintone外のデータも同時に見たい	認証、権限、保守範囲が広がる
集計アプリ	集計済みの結果を一覧にしたい	元データとの同期設計が必要
ダッシュボード	複数軸で比較したい	詳細確認画面とは役割が違う

kintone REST APIでレコードを取得する場合、Get Records APIには1回で取得できるレコード数やoffsetの制限があります。

Kintone Developer Program：Get Records

そのため、一覧上の全レコードに対して関連レコードを都度取得する設計は、件数が増えるほど苦しくなります。

たとえば、一覧に100件の顧客が表示され、それぞれの関連案件を取得する場合、設計を誤ると読み込み回数が増えます。

毎回その場で別アプリを検索するのか。

あらかじめ要約値を保存するのか。

集計アプリを別に作るのか。

ここを決めずにカスタマイズすると、最初は動いても、データが増えたときに画面が重くなります。

ダッシュボード化するケース

一覧に関連レコードを出したい要望の中には、実はダッシュボード化した方がよいものがあります。

たとえば、次のような要望です。

• 顧客別の受注金額を比較したい
• 担当者別の未対応件数を見たい
• 月別の問い合わせ件数を見たい
• 商品別の入出庫履歴を分析したい
• 案件ステータス別の金額を見たい

これは、関連レコードを一覧に出す話ではなく、集計や分析の話です。

顧客一覧に無理やり関連履歴を出すより、集計アプリやダッシュボードを作る方が自然です。

要望	向いている画面
顧客ごとの現在状態を見る	顧客一覧
顧客の履歴詳細を見る	顧客詳細画面
月別や担当者別に比較する	集計アプリ、ダッシュボード
明細を外部提出する	帳票、CSV、出力用アプリ
未対応だけを追う	対応管理アプリ、専用一覧

一覧画面は、何でも置く場所ではありません。

同じ一覧に、顧客基本情報、案件履歴、請求履歴、問い合わせ履歴、活動履歴をすべて並べると、どれも読みにくくなります。

現場が毎朝見る一覧なら、判断に必要な項目だけに絞ります。

分析したいなら、集計アプリやダッシュボードへ分けます。

権限・表示件数・画面速度の注意点

関連レコードを一覧に出す設計で、必ず見るべきなのは、権限、表示件数、画面速度です。

観点	確認すること
アプリ権限	参照先アプリを閲覧できるか
レコード権限	部門や担当者で見える関連レコードが変わらないか
フィールド権限	表示したい列がユーザーに見えるか
一覧件数	親レコードが何件並ぶか
関連件数	1親レコードあたり何件取得するか
表示項目	何列まで読めるか
条件変更	関連レコード条件変更時に設定が追従するか
エラー時	取得失敗時にどう表示するか

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

つまり、一覧上で関連レコードを表示する場合も、誰が見るかによって見え方が変わる可能性があります。

管理者では表示される。

営業担当では一部だけ表示される。

経理では金額列が見えない。

外部ユーザーには履歴を見せてはいけない。

このようなケースを、導入前に確認します。

また、画面速度は「表示できるか」より重要です。

プラグインやカスタマイズで関連レコードを一覧に出せても、一覧を開くたびに読み込みが遅いなら、現場は使いません。

表示するなら、次のように絞ります。

• 表示する関連レコードは直近数件にする
• 表示フィールドは3から5項目に絞る
• 全履歴ではなく、未対応や進行中だけに絞る
• 金額や件数は親レコードに保存する
• 月別・担当者別の比較はダッシュボードへ分ける

関連レコードを一覧に出す設計では、「出せるか」より「読める件数・待てる速度・説明できる権限」で判断します。

よくある失敗

関連レコードを一覧に表示しようとすると、次の失敗が起きがちです。

失敗	起きること	修正の方向
何でも一覧に出す	横に広がり、読めない一覧になる	判断に必要な項目だけに絞る
履歴全件を表示する	読み込みが重くなる	直近数件、未対応だけにする
要約値まで関連レコードで出す	検索、ソート、CSVで使いにくい	親レコードに保存する
権限確認をしない	人によって見える内容が違う	ロール別に表示確認する
条件変更の運用を決めない	プラグイン表示と詳細表示がずれる	設定変更手順を決める
一覧で編集まで求める	制約や事故が増える	詳細画面で編集する範囲を残す
分析まで一覧で済ませる	指標が増えすぎる	集計アプリやダッシュボードへ分ける

特に多いのは、詳細画面を開く手間を減らしたいだけなのに、関連レコードの全項目を一覧に出そうとすることです。

一覧は比較のための画面です。

詳細は読むための画面です。

集計は判断するための画面です。

この3つを混ぜると、どの画面も中途半端になります。

設計時に決めるチェックリスト

関連レコードを一覧に表示する前に、次を決めておきます。

確認項目	決めること
一覧で見たい理由	画面移動削減、状態確認、比較、分析、出力
表示範囲	全件、直近数件、未対応だけ、進行中だけ
表示項目	日付、状態、金額、担当者、リンクなど
親レコード保存	件数、合計、最終日、フラグで足りるか
詳細画面との役割	一覧で見ること、詳細で読むこと
プラグイン制約	件数、項目数、編集可否、設定変更時の手順
権限	参照先アプリ、レコード、フィールドの閲覧権限
画面速度	一覧件数、関連件数、読み込み時間
出力要件	CSV、帳票、外部連携が必要か
保守担当	条件変更、プラグイン更新、エラー確認の担当者

この表を埋めると、選択肢は自然に絞れます。

詳細画面で足りるなら、標準の関連レコード一覧を整える。

要約で足りるなら、親レコードに保存する。

関連履歴を一覧で見たいなら、プラグインを検討する。

複雑な比較や分析なら、集計アプリやダッシュボードへ分ける。

この順番で考えるのが現実的です。

Bitlightに相談できること

Bitlightでは、kintone関連レコードの一覧表示を、単なるプラグイン選定ではなく、業務画面の設計として整理できます。

たとえば、次のような支援ができます。

• 関連レコードを一覧に出す必要があるかの判断
• 詳細画面、一覧画面、集計画面の役割分担
• 顧客、案件、問い合わせ、請求、活動履歴の紐づけ設計
• 親レコードに保存する要約フィールドの設計
• 関連レコード一覧表示プラグインの選定観点整理
• JavaScriptやカスタムビューに進むべきかの判断
• 権限、表示件数、画面速度を含めた導入前検証
• 条件変更やプラグイン設定変更の運用手順

kintone関連レコードを一覧に出すこと自体は、プラグインやカスタマイズで実現できる場合があります。

ただし、実務で大事なのは、一覧が判断に使えることです。

何を一覧で見て、何を詳細で読み、何を集計値として保存するのか。

この境界を決めることで、関連レコードは見やすく、一覧は軽く、数字は説明しやすくなります。

kintone顧客管理の設計方法はこちら
kintone在庫管理の設計方法はこちら