kintoneテーブル集計の設計方法｜明細合計・条件付き集計・別アプリ化

kintoneのテーブルには、見積明細、請求明細、作業明細、工数明細、経費明細などを入れられます。

行ごとに数量、単価、小計を計算する。

テーブル外に合計金額を出す。

カテゴリ別に工数を集計する。

税区分別に金額を分ける。

帳票に合計を出す。

一覧やグラフで集計したい。

こうした要望は自然です。

ただし、kintoneテーブル集計を「SUM関数の書き方」だけで考えると、後から詰まります。

実務では、次のような問題が起きます。

• テーブル内の小計合計は出せるが、商品別や月別に集計できない
• 条件付き合計のために計算フィールドが増え、フォームが読みにくい
• テーブル内の明細を一覧画面で横断して確認しづらい
• グラフにしたいが、親レコード単位の合計しか見えない
• CSV更新でテーブル行の更新・削除を誤る
• 明細ごとに担当者、状態、承認、請求を持ちたくなる
• 外部BIやスプレッドシートに出すとき、テーブル行の展開が必要になる

テーブル集計は、単なる計算式ではありません。

明細を親レコード内に閉じてよいか、明細を1レコードとして分けるべきかの判断です。

kintoneテーブル集計で最初に決めるべきなのは、SUM関数の書き方ではなく、集計したい粒度が「親レコード単位」なのか「明細行単位」なのかです。

この記事では、kintoneのテーブル内数値を集計するときの、行ごとの計算、親レコード合計、条件付き集計、プラグインで補うケース、明細アプリに分けて集計するケース、一覧・グラフ・DataCollect・外部BIの使い分けを整理します。

kintoneテーブルの設計方法はこちら
kintoneテーブルルックアップの設計方法はこちら

先に結論：テーブル内集計で済むかを先に判断する

kintoneのテーブルでは、行ごとの計算や、テーブル内フィールドの合計ができます。

kintoneヘルプでも、演算子やSUM関数を使ってテーブル内のフィールドを計算できると案内されています。

kintoneヘルプ：テーブル内のフィールドを計算する

たとえば、テーブル内の「小計」フィールドを合計する場合、テーブルの外に計算フィールドを置き、次のような式を設定します。

SUM(小計)

これで、親レコード側に合計金額を表示できます。

見積書、請求書、経費申請、作業報告のように、1レコード内の明細を合計して帳票や承認に使うだけなら、この設計で足りることがあります。

集計したいこと	テーブル内集計で足りるか
1見積内の小計合計	足りることが多い
1請求内の明細合計	足りることが多い
1作業報告内の工数合計	足りることが多い
商品別売上合計	足りないことが多い
月別工数集計	足りないことが多い
担当者別明細集計	足りないことが多い

テーブル内集計で済むのは、集計結果を親レコードの中で使う場合です。

見積1件の合計。

請求1件の合計。

申請1件の合計。

報告1件の工数合計。

一方で、テーブル内の明細行を横断して集計したいなら、テーブルのままでは苦しくなります。

商品別、担当者別、月別、部門別、状態別に見たいなら、明細アプリや集計基盤を検討します。

親レコード内の合計ならテーブル集計で足ります。明細行を横断して比較・検索・グラフ化したいなら、明細アプリ化や外部集計を検討します。

行ごとの計算と親レコード合計

テーブル集計の基本は、行ごとの計算と親レコード合計を分けることです。

見積明細なら、各行で数量と単価から小計を計算します。

そのうえで、テーブル外の合計フィールドで小計を合計します。

場所	フィールド例	役割
テーブル内	商品コード	明細行の対象を示す
テーブル内	数量	行ごとの数量
テーブル内	単価	行ごとの単価
テーブル内	小計	数量×単価
テーブル外	小計合計	SUMで全行を合計
テーブル外	税額	税区分に応じて計算
テーブル外	総額	小計合計と税額の合算

この構成では、テーブル内の計算フィールドと、テーブル外の計算フィールドの役割が違います。

テーブル内の計算は、1行の中で完結する計算です。

テーブル外の計算は、複数行をまとめる計算です。

計算	例	置く場所
行小計	数量×単価	テーブル内
行工数	終了時刻-開始時刻	テーブル内
行税額	小計×税率	テーブル内、またはテーブル外で扱う
合計金額	SUM(小計)	テーブル外
合計時間	SUM(対応時間)	テーブル外
総額	小計合計+税額	テーブル外

この分け方を守ると、帳票や承認で使う合計が読みやすくなります。

逆に、テーブル外の合計フィールドを作らず、帳票側や外部出力側で毎回合計しようとすると、どの数字が正本なのか分からなくなります。

親レコードで使う合計値は、親レコード上にフィールドとして置く方が説明しやすいです。

条件付き集計の考え方

テーブル集計で次に出る要望が、条件付き集計です。

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

• カテゴリが「実装」の工数だけ合計したい
• 税率10%の明細だけ合計したい
• 請求対象の行だけ合計したい
• 交通費だけ合計したい
• 原価対象の行だけ合計したい

ロケットスタートの記事では、テーブル行のカテゴリに応じてIF関数で計算用フィールドを作り、そのフィールドをテーブル外でSUMする方法が紹介されています。

ロケットスタート：kintoneのテーブルで特定の条件を満たす行だけの合計を計算する

考え方は、次の通りです。

手順	内容
1	テーブル内に条件判定用の計算フィールドを作る
2	条件に合う行だけ金額や工数を返し、それ以外は0にする
3	テーブル外で、その計算フィールドをSUMする
4	必要な条件ごとに合計フィールドを分ける

たとえば、カテゴリが「実装」の工数だけを集計するなら、行ごとに実装工数を計算し、テーブル外で合計します。

条件付き集計は、標準機能だけで実現できる場合があります。

ただし、条件が増えすぎるとフォームが読みにくくなります。

条件付き集計	テーブルで続けやすい	見直した方がよい
税率別合計	2〜3種類なら可能	税区分や端数が複雑
カテゴリ別工数	少数カテゴリなら可能	カテゴリが頻繁に増える
請求対象合計	対象/対象外だけなら可能	月別請求や分割請求がある
原価区分別合計	区分が固定なら可能	原価明細として管理したい

条件付き集計が3種類程度なら、テーブル内の計算フィールドで対応できることがあります。

しかし、条件が増え続けるなら、テーブル内で計算フィールドを増やすより、明細アプリに分ける方がよいです。

条件付き集計は、少数の固定条件ならテーブル内計算で対応できます。条件が増える、変わる、分析に使うなら明細アプリ化を検討します。

プラグインで補うケース

標準の計算フィールドで足りない場合、プラグインを検討します。

ただし、プラグインを選ぶ前に、何を補いたいのかを分けます。

補いたいこと	選択肢
一覧画面で集計値を見たい	一覧集計系プラグイン
条件別の合計を見やすくしたい	計算補助、フィールド制御系プラグイン
テーブル内明細を外部集計したい	DataCollect、外部集計サービス
明細を別アプリへ展開したい	連携サービス、JavaScript、API
グラフを柔軟にしたい	グラフ系プラグイン、外部BI

Smart atの集計プラグインでは、レコード一覧画面に数値集計結果を表示する機能が紹介されています。

Smart at：集計プラグイン

これは、一覧上で合計や件数を見たい場合の選択肢です。

ただし、テーブル集計では、プラグインがどの粒度のデータを集計するのかを確認します。

親レコードの合計フィールドを集計するのか。

テーブル内の明細行を集計するのか。

明細アプリのレコードを集計するのか。

この粒度が違うと、同じ「売上合計」でも数字の意味が変わります。

プラグイン導入前には、次を確認します。

• 集計対象は親レコードか、テーブル行か、別アプリの明細か
• 集計対象の条件をどこで管理するか
• 集計結果は保存されるのか、表示だけか
• 一覧、グラフ、帳票、CSV出力で使えるか
• 権限によって集計結果が変わるか
• 設定変更時に誰が保守するか

明細アプリに分けて集計するケース

テーブル集計が苦しくなる最大の理由は、明細行を横断して使いたくなることです。

次の要望が出るなら、明細アプリ化を検討します。

要望	テーブルで抱えると起きること
商品別に売上を集計したい	各親レコードのテーブル行を展開する必要がある
月別に工数を集計したい	明細行の日付で横断集計しづらい
担当者別に作業時間を見たい	行ごとの担当者を1レコードとして扱いたくなる
請求対象だけを抽出したい	テーブル行単位の絞り込みが弱い
明細ごとに承認したい	親レコード単位の承認では粗い
会計や在庫へ連携したい	明細行を外部へ渡す処理が必要

明細アプリに分けると、1行が1レコードになります。

すると、kintoneの一覧、絞り込み、グラフ、CSV、API、権限を明細単位で使いやすくなります。

テーブル	明細アプリ
親レコードの中に行を持つ	明細1行を1レコードにする
帳票の内訳に向く	横断集計に向く
親と同じ権限で扱う	明細単位で権限を設計できる
行展開が必要	一覧やグラフで扱いやすい
親内合計に向く	商品別・月別・担当者別に向く

明細アプリ化した場合、親レコードには関連レコード一覧で明細を表示します。

親レコードに合計や件数を出したい場合は、集計処理で保存します。

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

一覧・グラフ・DataCollect・外部BIの使い分け

テーブル集計で迷いやすいのは、どこで数字を見るかです。

kintoneヘルプでは、アプリに登録されたレコードのデータから、数値やレコード数などを集計してグラフを作成できると説明されています。

kintoneヘルプ：グラフを作成する

ただし、標準グラフで扱いやすいのは、アプリのレコードとして持っているデータです。

親レコードの合計フィールドをグラフ化するなら扱いやすいです。

明細行を横断して商品別・月別に見るなら、明細アプリ化した方が自然です。

見たい数字	向いている場所
見積1件の合計	親レコードの合計フィールド
請求1件の税率別合計	テーブル内計算 + 親レコード合計
顧客ごとの累計請求額	親レコードに保存した集計値
商品別売上	明細アプリ、集計アプリ
月別工数	明細アプリ、グラフ、外部BI
複数アプリ横断の集計	DataCollect、外部BI、スプレッドシート

DataCollectの機能ページでは、複数アプリに散らばる情報を集計対象にできるフィールド式、集計の実行、ピボットテーブル、テーブル展開などが紹介されています。

DataCollect：機能一覧

テーブル内の情報を集計元として使いたい場合や、複数アプリ横断で集計したい場合は、このような集計基盤を検討します。

外部BIやスプレッドシートは、分析や共有に向きます。

ただし、外部に出す前に、kintone側でどのデータが正本なのかを決めます。

テーブル内明細が正本なのか。

明細アプリが正本なのか。

親レコードの合計フィールドが正本なのか。

ここが曖昧なまま外部集計すると、ダッシュボードの数字とkintone画面の数字が合わなくなります。

集計が遅い、合わないときの見直し

テーブル集計でよくある相談は、集計が遅い、数字が合わない、式が読めない、というものです。

原因は、計算式そのものではなく、データの持ち方にあることが多いです。

症状	見直すこと
合計が合わない	対象外行、空欄、取消行、税区分を確認する
条件付き合計が増えすぎる	条件を固定できるか、明細アプリ化するか
フォームが読みにくい	計算用フィールドを増やしすぎていないか
グラフが作りにくい	明細行を1レコードとして持つべきか
CSV更新が怖い	テーブル行の更新キーと手順を確認する
帳票と一覧の数字が違う	正本の合計フィールドを決める
外部集計と合わない	集計対象期間、税区分、取消、更新タイミングを揃える

集計が合わない場合は、まず定義を確認します。

売上とは、受注金額なのか、請求金額なのか、入金済み金額なのか。

工数とは、予定工数なのか、実績工数なのか、請求対象工数なのか。

税額は、行ごとに丸めるのか、合計後に丸めるのか。

この定義が曖昧だと、どのツールを使っても数字は合いません。

テーブル集計が合わないときは、式を直す前に、集計対象・除外条件・丸め・更新タイミングを定義します。数字の意味が曖昧なまま式だけ増やしても解決しません。

よくある失敗

kintoneテーブル集計でよくある失敗は、次の通りです。

失敗	起きること	修正の方向
SUMだけで全要件を満たそうとする	条件付き集計や横断集計で詰まる	親内合計と明細横断集計を分ける
条件ごとに計算フィールドを増やす	フォームが読みにくくなる	条件数を絞る、明細アプリ化する
親レコード合計を正本にしない	帳票、一覧、外部集計で数字がずれる	合計フィールドを定義する
明細単位の集計をテーブルで続ける	商品別・月別・担当者別が扱いづらい	明細アプリを作る
税区分と丸めを後回しにする	請求書や会計連携で差異が出る	行丸め、合計丸めを決める
外部集計だけで解決しようとする	kintone側の正本が不明になる	元データの責任範囲を決める
CSV更新の手順を決めない	テーブル行が消える、重複する	取込手順と更新キーを決める

特に危ないのは、テーブル内にある明細を、あとから商品別や月別に分析したくなるケースです。

最初は見積書の合計だけでよかった。

後から商品別売上、担当者別粗利、月別請求、原価集計を見たくなった。

この場合、テーブル内の明細を毎回展開して集計するより、明細アプリとして持つ方が安定します。

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

kintoneテーブル集計を作る前に、次を決めます。

確認項目	決めること
集計粒度	親レコード単位か、明細行単位か
行計算	数量×単価、時間差、税額など
親合計	小計合計、税額、総額、工数合計
条件付き集計	税率別、カテゴリ別、請求対象別
条件数	固定か、増える可能性があるか
グラフ	親レコード合計で足りるか、明細別に見るか
出力	帳票、CSV、外部BI、会計連携
正本	テーブル、親合計、明細アプリのどれか
更新	再計算、CSV更新、外部集計のタイミング
将来分割	明細アプリ化する場合のキーを持つか

この表で、明細行単位の要件が多いなら、テーブル集計だけで進めない方がよいです。

親レコード内の合計で足りるなら、SUMと条件付き計算で十分なことがあります。

どちらでも対応できる場合は、将来の集計軸を見ます。

商品別、担当者別、月別、部門別などの軸が増えそうなら、明細アプリ化を早めに検討します。

Bitlightに相談できること

Bitlightでは、kintoneテーブル集計を、計算式だけでなく、明細データの持ち方から設計できます。

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

• テーブル内集計で足りる範囲の整理
• 行計算、親レコード合計、条件付き集計の設計
• 税区分、丸め、取消、請求対象の定義整理
• 明細アプリ化した方がよい業務の切り分け
• 親レコードへの合計保存、集計日時、集計状態の設計
• 一覧、グラフ、DataCollect、外部BIの使い分け
• CSV取込・書き出しや外部連携を前提にした明細構成

kintoneテーブル集計は、最初は小さな計算式に見えます。

しかし、金額、工数、請求、原価、在庫に関わるなら、業務判断に使われる数字です。

1レコード内で完結する合計なのか。

明細行を横断して見るべき数字なのか。

この境界を決めておくと、テーブル集計は帳票にも一覧にもグラフにもつながる構成になります。

kintone請求書管理の設計方法はこちら
kintone予実管理の設計方法はこちら