kintone関連レコード集計の設計方法｜表示だけで終わらせない集計構成

kintoneの関連レコード一覧は、顧客に紐づく案件、問い合わせ、請求、活動履歴などを表示するのに便利です。

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

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

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

ここまでは、関連レコード一覧の得意領域です。

ただ、実務ではすぐに次の要望が出ます。

• 関連レコード一覧に表示された案件金額を合計したい
• 関連する問い合わせ件数を顧客レコードに出したい
• 未入金の請求だけを合計したい
• 今月分だけ、進行中だけ、承認済みだけを集計したい
• 集計値を一覧画面、グラフ、帳票、通知条件でも使いたい
• 関連レコードが増えたときに、自動で再計算したい
• ユーザーの権限によって数字が変わらないようにしたい

このとき、関連レコード一覧をそのまま集計の正本にすると危険です。

関連レコード一覧は、別アプリのレコードを条件に合わせて画面上に表示します。

集計値を保存する機能ではありません。

kintone関連レコード集計で最初に決めるべきなのは、プラグイン名ではなく「その集計値をどこに保存し、いつ再計算し、何に使うか」です。

この記事では、kintoneの関連レコード一覧を集計したいときに、標準機能の制約、集計値の保存先、件数・合計・条件付き集計、プラグイン・JavaScript・DataCollectの使い分け、再計算、権限、ダッシュボードへ分ける判断を整理します。

kintone関連レコードの設計方法はこちら
kintone帳票管理の設計方法はこちら

先に結論：関連レコードは表示、集計値は別に設計する

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

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

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

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

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

つまり、関連レコード一覧は「見えている表」であって、「集計用の明細テーブル」ではありません。

やりたいこと	関連レコード一覧だけで考えると起きること
顧客ごとの案件合計を一覧に出す	一覧画面に関連レコード一覧を出せない
関連請求の合計を計算式で使う	関連レコード一覧は計算対象にできない
関連レコードの値をCSV出力する	関連レコード一覧の値は書き出せない
関連問い合わせ件数で検索する	アプリ内検索の対象にできない
帳票に集計値を出す	別途保存されたフィールドが必要になる

関連レコード一覧は「画面で確認する表示」です。合計、件数、通知、検索、帳票、外部連携に使う数字は、関連レコードとは別に保存先を決めます。

ここを分けないと、顧客画面では見えているのに、一覧、帳票、通知、連携では使えない数字が生まれます。

逆に、最初から保存先と再計算ルールを決めておけば、関連レコードは確認用、集計値は業務判断用として役割を分けられます。

集計値を保存するか、都度表示するか

関連レコード集計でまず決めるのは、集計値を保存するかどうかです。

保存しない集計は、その場で見るための数字です。

保存する集計は、ほかの画面や処理でも使う数字です。

集計値の持ち方	向いているケース	注意点
関連レコード一覧を目視する	件数が少なく、詳細確認が目的	合計値としては使いにくい
画面表示時にJavaScriptで計算する	レコード詳細画面だけで見たい	一覧、検索、帳票、API連携には残らない
プラグインで親レコードに保存する	顧客や案件に合計値を持ちたい	再計算条件と対象権限を確認する
JavaScriptやAPIで親レコードに保存する	複雑な条件や独自ルールがある	保守担当とエラー検知が必要
集計アプリに保存する	月次、部門別、商品別など軸が多い	親レコードとは別の正本になる
DataCollectなど集計基盤を使う	複数アプリをまたぐ集計や分析が多い	集計結果の利用先を決めておく

保存しない集計でよい場面はあります。

たとえば、顧客レコードを開いたときに、その場で案件一覧を確認し、概算で状況をつかむだけなら、関連レコード一覧の表示で足ります。

一方、次のような用途では保存が必要です。

• 顧客一覧に「累計受注額」を出す
• 顧客ランクを受注額で自動判定する
• 未入金額が一定以上なら通知する
• 帳票に請求残高を出す
• 外部システムへ集計値を渡す
• 月次レポートで集計値を比較する

保存するなら、親レコードに集計値フィールドを作ります。

たとえば、顧客アプリに次のフィールドを持たせます。

フィールド	型	用途
関連案件件数	数値	顧客に紐づく案件数
進行中案件件数	数値	ステータスが進行中の案件数
受注済み金額合計	数値	受注済み案件の金額合計
未入金請求額合計	数値	未入金請求の金額合計
最終活動日	日付	活動履歴の最新日
集計日時	日時	最後に計算したタイミング
集計状態	ドロップダウン	正常、対象なし、再計算待ち、エラー

このように保存しておくと、一覧、グラフ、通知、帳票、API連携で使いやすくなります。

ただし、保存した瞬間から、再計算と整合性の責任が発生します。

件数・合計・条件付き集計を分ける

関連レコード集計は、単純な合計だけではありません。

実務で必要になる集計は、少なくとも3種類あります。

集計種別	例	設計で見ること
件数	案件数、問い合わせ件数、未対応件数	対象条件と重複の扱い
合計	受注金額合計、請求額合計、入金額合計	税込・税抜、取消、通貨、端数
条件付き集計	進行中だけ、当月だけ、未入金だけ	条件の保存場所と変更責任

件数集計は簡単に見えますが、条件を決めないと使えません。

案件数といっても、全案件なのか、進行中だけなのか、失注やキャンセルを含むのかで意味が変わります。

問い合わせ件数も、すべての問い合わせなのか、未対応だけなのか、クレームだけなのかで判断が変わります。

指標	そのまま数えると危ない理由
案件件数	完了、失注、重複案件が混ざる
問い合わせ件数	返信済みと未対応が混ざる
請求件数	取消、再発行、分割請求が混ざる
活動件数	自動登録と手動登録が混ざる

合計集計は、金額の定義が重要です。

受注金額を合計するなら、どのステータスで確定とするかを決めます。

請求額を合計するなら、取消請求、返金、値引、消費税、源泉、端数処理をどう扱うかを決めます。

金額集計	決めること
予定金額合計	確度の低い案件を含めるか
受注金額合計	受注ステータスの定義
請求額合計	税込・税抜、取消、再発行
入金額合計	部分入金、過入金、返金
未入金額合計	入金消込と締め日の扱い

条件付き集計は、さらに注意が必要です。

たとえば、未入金請求額を集計する場合、関連レコード一覧の絞り込み条件だけで終わらせない方がよいです。

集計処理側にも、同じ条件が必要です。

表示条件と集計条件が別々に管理されると、画面では3件見えているのに、保存された合計は4件分になっている、といったずれが起きます。

関連レコード集計では、表示条件と集計条件を同じ言葉で定義します。「見えている対象」と「合計された対象」が違うと、数字を説明できません。

プラグイン・JavaScript・DataCollectの使い分け

関連レコード集計の実装方法は、大きく分けると、プラグイン、JavaScript、集計基盤の3つです。

どれがよいかは、機能数ではなく、保守のしやすさと集計値の使い道で決めます。

方法	向いているケース	避けたいケース
関連レコード集計プラグイン	親レコードに件数・合計を保存したい	複雑な業務条件が多い
JavaScriptカスタマイズ	画面表示や独自条件を細かく制御したい	引き継ぎ先がいない
API・バッチ処理	夜間再計算や大量データの補正が必要	即時反映だけを求める
DataCollectなど	複数アプリ横断、分析、集計表が多い	親レコードにだけ数字がほしい

コムデックAIラボの記事でも、kintone標準では関連レコード一覧の数値を集計できないことを起点に、プラグインやカスタマイズで自動集計する考え方が紹介されています。

コムデックAIラボ：kintoneの関連レコードの数値を自動集計する方法

アディエムの関連レコード集計プラグインの設定方法では、関連レコード一覧フィールド、集計先格納フィールド、条件付き集計、集計日時フィールドなどの設定項目が説明されています。

アディエム：関連レコード集計プラグイン for kintone設定方法・留意事項

このタイプのプラグインが向いているのは、親レコードに数字を保存したい場面です。

顧客レコードに累計受注額を持つ。

案件レコードに請求済み金額を持つ。

請求先レコードに未入金額を持つ。

このように、親レコード側で見たい・並べたい・帳票に出したい数字がある場合は、保存型の集計が合います。

一方、JavaScriptは、画面表示の柔軟性が高い反面、保守が属人化しやすいです。

条件が複雑で、標準的なプラグイン設定では足りない場合に検討します。

ただし、コードで集計するなら、次を決めてから実装します。

• どのイベントで実行するか
• レコード保存前に計算するのか、保存後に親レコードを更新するのか
• API取得件数が増えたときにどう分割するか
• エラー時に誰が気づくか
• 手動再計算ボタンを用意するか
• 権限不足で取得できないレコードをどう扱うか

DataCollectのような集計サービスは、親レコード1件に集計値を返すだけでなく、複数アプリを横断して集計表や分析を作りたい場合に候補になります。

DataCollect：機能一覧

顧客ごとの累計だけなら、親レコード保存で十分かもしれません。

月別、部門別、商品別、担当者別、ステータス別に切り替えて見るなら、集計アプリや集計基盤へ分けた方が扱いやすくなります。

再計算タイミングと集計日時を管理する

集計値を保存するなら、必ず再計算タイミングを決めます。

関連レコードの元データは、親レコードとは別アプリにあります。

そのため、親レコード側の集計値は、元データが変わったときに更新される必要があります。

元データで起きること	再計算が必要な理由
関連レコードが追加される	件数や合計が増える
金額が変更される	合計が変わる
ステータスが変更される	条件付き集計の対象が変わる
顧客コードが変更される	紐づく親レコードが変わる
レコードが削除される	件数や合計が減る
入金状態が変更される	未入金額が変わる

再計算タイミングは、要件によって変えます。

タイミング	向いている用途	注意点
関連レコード保存時に即時更新	顧客画面ですぐ最新を見たい	更新対象が多いと重くなる
親レコード表示時に計算	画面確認だけでよい	保存値としては使えない
手動再計算	月次確認や補正作業	押し忘れを防ぐ運用が必要
夜間バッチ	大量データや月次集計	当日中は古い数字になる
定期集計アプリ更新	レポートや部門別集計	集計アプリ側の設計が必要

どの方式でも、集計日時を持たせます。

集計日時がない集計値は、いつ時点の数字か分かりません。

特に請求、入金、案件金額のように、日々変わる数字では重要です。

フィールド	役割
集計日時	最後に計算した時刻
集計対象期間	いつからいつまでを含むか
集計条件名	どの条件で計算したか
集計状態	正常、再計算待ち、エラー
集計エラー内容	失敗理由の確認

保存された集計値には、集計日時と集計状態をセットで持たせます。数字だけを保存すると、古いのか、最新なのか、失敗しているのかを判断できません。

権限と表示件数の注意点

関連レコード集計で見落としやすいのが、権限です。

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

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

つまり、管理者には関連レコードが見えるが、営業担当には見えない、ということが起きます。

集計値を誰の権限で計算するかは、業務上の意味に直結します。

観点	確認すること
閲覧権限	集計対象レコードを誰が見られるか
フィールド権限	条件に使うフィールドを見られるか
レコード権限	担当者別や部門別で除外されないか
プラグイン実行権限	どの権限で集計されるか
APIトークン	どのアプリ・フィールドにアクセスできるか
保存先権限	集計値フィールドを誰が更新できるか

「表示されている関連レコードだけを集計する」のか。

「閲覧者に関係なく、業務上の全件を集計する」のか。

ここを曖昧にすると、ユーザーごとに見える数字と保存された数字の説明ができなくなります。

金額集計では、基本的に業務上の正本を集計します。

顧客の未入金額や累計受注額は、閲覧者ごとに変わると困ることが多いです。

一方、営業担当者が自分の担当案件だけを見る画面なら、担当者権限に合わせた集計もあり得ます。

また、関連レコード一覧には一度に表示する最大レコード数の設定があります。

画面に表示する件数と、業務上集計すべき件数は分けて考えます。

「画面に50件表示されているから50件だけ合計すればよい」とは限りません。

集計処理側では、対象条件に一致する全件を取るのか、表示件数と同じ範囲だけを見るのかを決めます。

ダッシュボード集計へ分けるケース

親レコードに集計値を保存する設計は、1件の親に対して状態を見たいときに向いています。

顧客ごとの累計受注額。

案件ごとの請求済み金額。

請求先ごとの未入金額。

このような数字は、親レコードに持つと分かりやすいです。

しかし、集計の軸が増えると、親レコード保存だけでは苦しくなります。

やりたい集計	親レコード保存だけでつらい理由
月別売上	顧客レコードに月ごとの列が増え続ける
部門別売上	部門異動や兼務の扱いが難しい
商品別粗利	明細単位の正本が必要
担当者別活動件数	担当変更や引き継ぎ履歴が絡む
ステータス別案件金額	条件変更の影響を受けやすい

この場合は、集計アプリやダッシュボードへ分けます。

たとえば、月次顧客集計アプリを作り、1レコードを「顧客×年月」とします。

アプリ	1レコードの意味	持たせる値
顧客アプリ	1社	現在の累計、未入金、最終活動日
月次顧客集計アプリ	1社×1か月	月間受注、月間請求、月間活動件数
担当者集計アプリ	1担当者×1か月	案件数、受注額、対応件数
商品集計アプリ	1商品×1か月	数量、売上、粗利

親レコードは、現在状態を見る場所。

集計アプリは、期間別・軸別に見る場所。

このように分けると、顧客レコードが月別列だらけになるのを防げます。

kintone帳票管理の記事でも、業務レコード、明細、出力履歴を分ける考え方を整理しています。

関連レコード集計でも同じで、画面に表示するもの、保存して使うもの、分析するものを分けるほど運用しやすくなります。

よくある失敗

関連レコード集計では、次の失敗がよく起きます。

失敗	起きる問題	修正の方向
関連レコード一覧を集計テーブルだと思う	一覧、CSV、計算、検索で使えない	保存フィールドか集計アプリを作る
表示条件と集計条件が違う	見えている件数と合計値が合わない	条件を定義表にする
集計日時を持たない	数字がいつ時点か分からない	集計日時と集計状態を保存する
権限を確認しない	ユーザーごとに見える数字が違う	管理者、営業、経理で確認する
親レコードに月別列を増やす	フォームが肥大化する	月次集計アプリへ分ける
JavaScriptだけで済ませる	一覧や帳票で使えない	保存が必要かを先に決める
プラグイン設定だけ残る	条件変更時に誰も直せない	集計条件と責任者を文書化する

特に多いのは、「顧客レコードに出ている関連案件の合計だから、すぐ使えるだろう」という誤解です。

画面に見えることと、業務上使える数字として保存されていることは別です。

帳票、通知、グラフ、外部連携に使うなら、保存先と再計算ルールが必要です。

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

関連レコード集計を作る前に、次を決めておくと手戻りが減ります。

確認項目	決めること
集計値の用途	画面表示、一覧、通知、帳票、連携、分析
保存先	親レコード、集計アプリ、外部集計基盤
集計種別	件数、合計、最大、最小、最新日、条件付き
集計条件	ステータス、期間、担当者、取消、入金状態
再計算	即時、手動、定期、夜間、表示時
権限	誰の権限で対象を取得し、誰が見られるか
エラー対応	失敗時の通知、再実行、ログ確認
件数増加	取得件数、処理時間、表示件数との違い
変更責任者	条件変更、項目追加、プラグイン設定の管理者

このチェックリストを埋めると、プラグインを選ぶべきか、JavaScriptを書くべきか、集計アプリへ分けるべきかが見えます。

プラグインは、設定で済む範囲なら強いです。

JavaScriptは、独自条件や画面体験を作るときに強いです。

DataCollectや集計アプリは、複数軸で見るときに強いです。

選択肢の優劣ではなく、数字の使い道で選ぶことが重要です。

Bitlightに相談できること

Bitlightでは、kintone関連レコード集計を、単なるプラグイン設定ではなく、業務上の数字として設計できます。

たとえば、次のような整理から支援できます。

• 関連レコード一覧で見せる情報と、保存すべき集計値の切り分け
• 顧客、案件、請求、問い合わせ、活動履歴の紐づけキー設計
• 件数、合計、条件付き集計の定義表作成
• 親レコード保存、集計アプリ、ダッシュボードの使い分け
• 再計算タイミング、集計日時、エラー状態の設計
• 権限別の見え方と、業務上の正本数字の整理
• プラグイン、JavaScript、API、DataCollectの選定

kintone関連レコード集計は、機能追加として見ると小さく見えます。

しかし、金額や件数が業務判断に使われるなら、設計対象です。

どの数字を、どこに保存し、いつ更新し、誰が確認するのか。

ここまで決めることで、関連レコードは単なる表示ではなく、業務判断を支える構成になります。

kintone顧客管理の設計方法はこちら
kintone営業管理の設計方法はこちら