投稿日:2026年4月13日
更新日:2026年4月13日
kintoneの「テーブル」活用術|集計・計算・プラグイン活用の実践例

明細を「テーブル」にまとめたら、集計やグラフに使いづらくなってしまった。
履歴や明細を1レコードで管理したいのに、「テーブル」のせいでデータが重くなって表示が遅い。
とりあえず「テーブル¥で作ったら、あとから他アプリとの連携や検索条件の設定に限界が見えてきた。
―――kintoneを使用する中で、このようなお悩みを感じことはありませんか?
業務改善ツールとして人気のあるkintone(キントーン)は、顧客管理・案件管理・売上管理など、あらゆる業務データを一元管理できる点が大きな強みです。
しかし、多くのユーザーが感じるのは「テーブルを使うべきかの判断が難しい」という課題です。また、基本機能における「テーブル」には、物足りなさや使いにくさを感じる場面も少なくありません。
本記事では、テーブルの基本から「ハマる」活用パターン、「やってしまいがち」な設計、さらにJavaScriptやプラグインでどこまで拡張できるのかまで、整理していきます。
この記事を読めば、テーブルを「なんとなく」ではなく、狙いを持って設計・活用できるようになるので最後までご覧ください。
- 「テーブル」とは?
- kintoneにおける「テーブル」の位置づけ
- テーブルに向いていること
- テーブルに向いていないこと
- テーブルの活用例3選(基本機能での使い道・集計など)
- 活用例①:見積・請求の明細行をまとめる
- 活用例②:案件ごとの対応履歴・活動ログを管理する
- 活用例③:関係者リストやサブマスタとして使う
- テーブルのデメリットと設計時の注意点
- デメリット①:CSV出力時(ファイルでの書き出し時)の形式の扱いづらさ
- デメリット②:他アプリからルックアップ・関連レコード参照ができない
- デメリット③:一覧画面での並べ替え・検索の制約
- テーブルのカスタマイズについて
- カスタマイズ例①:標準の関数では不可能な計算方法での計算
- カスタマイズ例②:テーブル行の並び替え・複製
- 行単位の集計・分析を見据えたアプリ設計の考え方
- まとめ
- 【定額開発】kintone導入はルーブピークへ
「テーブル」とは?
kintoneにおける「テーブル」の位置づけ
kintoneのテーブルは、「1つのレコードの中に、同じ項目のセットを複数行もたせる」ためのパーツです。
通常フィールドだけで入力フォームを作ると、繰り返しが多い情報ほど縦に長くなってしまいますが、「テーブル」を使うことで見た目をコンパクトに保ちつつ、入力する人にも「ここは明細」「ここは履歴」といったまとまりが分かりやすくなります。
テーブルに向いていること
テーブルが向いているのは、次のような「1対多」の構造をもつ情報です。
1件の見積に対して、複数の明細行が存在する
1件の案件に対して、複数の対応履歴が時系列でたまっていく
1件の案件に対して、複数の関係者が紐づく
テーブルに向いていないこと
「1行ごとに独立して管理したい情報」や「行単位でグラフ・集計したい情報」は、テーブルではなく別アプリでレコードとして持ったほうが運用しやすくなります。
テーブルはあくまで「1レコードの明細やサブ情報をまとめる」ための部品だと捉えておくと、役割の切り分けがしやすくなります。
テーブルの活用例3選(基本機能での使い道・集計など)
テーブルは、基本機能だけでも十分に実用的です。代表的な活用パターンを押さえておくと、「どこで使うべきか」の判断がぐっと楽になります。
活用例①:見積・請求の明細行をまとめる
1レコード=1件の見積(または請求)とし、その中にテーブルで「品目/数量/単価/金額」を行ごとに並べていく構成が典型的です。
アプリのフィールドとしては、テーブルの外側に「得意先」「見積日」「支払条件」などのヘッダー情報を持たせ、テーブルに「明細」を持たせるイメージです。

小計や消費税などの計算は、テーブル内の金額を「SUM関数」で計算することで、基本機能だけでも十分に対応できます。
活用例②:案件ごとの対応履歴・活動ログを管理する
案件アプリの中にテーブルを用意し、「対応日」「担当者」「内容」「ステータス」「次回アクション」などを1行ずつ記録していくと、1つの案件カードの中に時系列の履歴がまとまります。

別アプリで「対応履歴」だけを持つ方法もありますが、「1案件ずつの履歴を素早く確認したい」シーンが中心であれば、テーブルのほうが画面遷移も少なく、現場には受け入れられやすいです。
活用例③:関係者リストやサブマスタとして使う
関係者リストや小さなサブマスタとしての使い方です。
たとえば、案件ごとの関係者をテーブルで持たせると、「この案件に関わる人一覧」を1画面で把握できます。

関係者の人数がそこまで多くなく、1件あたり数名〜十数名程度におさまるなら、わざわざ別アプリを切るよりもテーブルで済ませたほうが設計がシンプルです。
テーブルのデメリットと設計時の注意点
テーブルは便利な一方で、構造上の制約やデメリットもはっきり存在します。ここを理解せずに「とりあえずテーブルで」にしてしまうと、運用が進むほど困りごとが増えていきます。
デメリット①:CSV出力時(ファイルでの書き出し時)の形式の扱いづらさ
代表的なのが「CSV出力時の形式」です。1レコードのテーブル行がCSV上では複数行に分割されるため、ヘッダ情報との関係が直感的に見えにくく、Excel側での加工が必要になることがあります。
CSV活用を見込むなら、最初から出力後の扱いまで含めて設計しておくことが大切です。

デメリット②:他アプリからルックアップ・関連レコード参照ができない
テーブルの中の1行を「別アプリの1レコード」として扱うことはできません。そのため、他アプリからルックアップしたり、関連レコードで直接参照したりする設計には向いていません。
テーブル前提の設計は、後々の連携や分析の自由度を下げる可能性があります。
【補足】ルックアップとは
コピーして自分のアプリのデータとして扱いたいときに使用するフィールド
例)見積管理アプリで商品マスタに登録してある品目・商品・単価をコピーする
【補足】関連レコードとは
あるキー(顧客番号、商品コードなど)に紐づく「関連するレコードの一覧」を、常に最新状態で表示できるフィールド

デメリット③:一覧画面での並べ替え・検索の制約
テーブル内の行ごとに一覧画面でソートしたり、条件で柔軟に絞り込んだりすることはできません。あくまで「1レコード内部の明細」として扱われるため、行単位で柔軟に使いたい場合には不向きです。行を主役として扱いたくなった時点で、別アプリ化を検討したほうがよいケースが増えます。

また、1レコードに大量の行を詰め込みすぎると、画面の表示や編集が重くなり、モバイルアプリでは特に操作しづらくなります。
便利だからといって詰め込みすぎないことも、テーブル運用では大切な視点です。
テーブルのカスタマイズについて
基本機能だけでは物足りない場合、JavaScriptやプラグインでテーブルの使い勝手を大きく改善できます。ただし、「単一画面のカスタマイズで解決できること」と「設計を変えるべきこと」は分けて考える必要があります。
カスタマイズでよく行われるのは、標準の関数では不可能な計算方法での計算、行追加時にテンプレート行を自動で挿入する、必須項目や数値範囲を行ごとにチェックする、といったパターンです。
これらは「テーブルという構造自体はそのままに、入力や確認を楽にするための工夫」と考えると分かりやすいです。
カスタマイズ例①:標準の関数では不可能な計算方法での計算
標準の計算フィールドでは、同じ行内や同じ列内の単純な計算は可能です。
一方で、Excel のSUMIF関数のように、条件に一致する行だけを集計する処理は基本機能だけでは実現しにくい(不可能ではないがフィールドが増えすぎてしまう)です。そのため、このような要件はJavaScriptでのカスタマイズやプラグインで補うのが一般的です。
▼品目ごとの計算(JavaScriptカスタマイズ)

カスタマイズ例②:テーブル行の並び替え・複製
株式会社Crenaが提供する「テーブル操作プラグイン」を利用することで、テーブル行の並び順をドラッグ&ドロップで変更できるようになり、さらには行をワンクリックでコピーできるようにもなります。
このようなプラグインを使うことで、テーブル操作をより快適にします。
▼テーブル操作プラグイン(Crena Plugin)

弊社は、30種類のプラグインがセットになったCrena Pluginの「認定パートナー」ですCrena Pluginの導入を検討されているお客様はぜひご相談ください。
行単位の集計・分析を見据えたアプリ設計の考え方
さて、テーブルを便利にするカスタマイズをいくつか挙げましたが、単一のアプリのままではCSV形式や集計ができないといった構造的な制約まで解消できるわけではありません。
特に、行単位での集計・分析・連携が増えてくると、テーブルのままでは設計が窮屈になります。そこで検討したいのが、親アプリ+子アプリ(親アプリからの参照は関連レコード)に分割するパターンです。

この構成では、親アプリが案件や顧客などの「1件」を持ち、子アプリが見積明細・活動履歴など「複数行に増える情報」をレコードとして持ちます。そうすることで、子アプリ側のデータは通常の一覧画面でソートや絞り込みができ、グラフ化や集計も柔軟になります。
一方で、親子アプリ構成は設計と運用が少し複雑になるため、最初から必ず採用すべきものでもありません。行数が少ないうちはテーブルで簡潔に、行単位の集計や連携ニーズが見えてきたら子アプリへ切り出す、という段階的な進め方も現実的です。
▼テーブルデータ転送プラグイン(Crena Plugin)

公式サイト:https://create-new-air.com/service/kintone-plugin/table-data-transfer/
まとめ
いかがでしたか?
テーブルは頼れる反面、ちょっとクセのあるパーツでもありますが、 本記事の内容を大まかでも意識しておくだけで、設計はぐっと楽になります。
テーブルの守備範囲を決めておくことが、あとからの「こんなはずじゃなかった」を減らすいちばんのコツかもしれません。
日々のアプリづくりの中で、ふと思い出してもらえたらうれしいです。
【定額開発】kintone導入はルーブピークへ

kintoneでカスタマイズを行うには、専門的な知識が必要になるケースも多くあります。そのため、社内に対応できる人材がいない場合、「うまく活用できるのか」「継続的に運用できるのか」と不安に感じる方も少なくありません。
Lubepeak株式会社では、kintoneの力を最大限に引き出し、業務改善につながるシステム開発を行っています。
kintone定額開発サービス「KYOSOU」
kintoneでお悩みをお持ちの企業様は、ぜひお気軽にご相談ください。
Lubepeak株式会社 代表
平井 将吾

~ 経歴 ~
2021年
富士フイルムビジネスイノベーション株式会社へ新卒入社2022年~2025年
官公庁において、「kintone」の導入で「自治体DX」を多数支援2025年10月~
Lubepeak株式会社を設立。
中小企業のお客様を対象に「kintone」の導入支援を行い、要件整理から運用定着まで一貫支援
<主なサービス>
・ kintoneシステム開発サービス 「KYOSOU」
・ kintoneプラグイン提供サービス 「Plugin to Peak」2026年1月
Lubepeak株式会社が「サイボウズオフィシャルパートナー」に認定


この記事を書いた人
顧客の業務改善に向き合える場所
ルーブピークは、「kintone」で企業の課題を共に解決するメンバーを募集しています。
「kintone業務委託 募集サイト」はこちら



















