kintoneテーブルの設計方法｜明細・履歴・別アプリ化の判断基準

kintoneのテーブルは、1つのレコードの中に、複数行の明細を持たせる機能です。

見積明細。

注文明細。

作業報告の作業行。

日報の訪問先一覧。

点検項目。

請求明細。

こうした「1件の業務レコードに紐づく複数行」を入力するときに便利です。

ただし、テーブルは便利な反面、設計を間違えると後から詰まります。

• 1レコード内のテーブル行が増えすぎる
• 明細ごとに担当者やステータスを持たせたくなる
• 明細単位で検索、集計、CSV出力したくなる
• テーブル内の値を別アプリの関連レコード条件に使いたくなる
• 明細ごとに権限を分けたくなる
• 帳票には出せるが、月次集計や外部連携で扱いづらい
• サブテーブル、関連レコード、明細アプリの違いが曖昧になる

テーブルは「行を増やせる入力欄」として見ると簡単です。

しかし、業務システムとして見ると、明細データの正本をどこに置くかの判断です。

kintoneテーブルで最初に決めるべきなのは、行を追加できるかではなく、その明細が親レコードの一部なのか、独立した業務データなのかです。

この記事では、kintoneテーブルを設計するときの、テーブルとサブテーブルの関係、テーブル化してよいデータ、別アプリに分けるべきデータ、ルックアップ・関連レコード・帳票との関係、集計・CSV・一覧表示への影響、明細が増えたときの設計変更を整理します。

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

先に結論：テーブルは親レコードに従属する明細に使う

kintoneのテーブルは、複数のフィールドを1行としてまとめ、同じ構成の行を追加できる機能です。

kintoneヘルプでも、フォームにテーブルを配置し、複数の項目を1つのまとまりとして入力できる機能として案内されています。

kintoneヘルプ：テーブルを追加する

テーブルが向いているのは、親レコードに従属する明細です。

従属する、というのは、その明細だけを独立して管理する必要が弱いという意味です。

テーブルに向く明細	理由
見積書の明細	見積1件の中で完結し、帳票に出したい
作業報告の作業行	報告1件の内訳として残したい
点検チェック項目	点検1件の結果として保存したい
申請の費目明細	申請1件の内訳として承認したい
請求書の明細	請求1件の発行時点の内訳を残したい

逆に、明細そのものを独立して探したい、集計したい、承認したい、連携したいなら、テーブルだけで抱えない方がよいです。

別アプリ化を考える明細	理由
出荷明細	明細ごとに出荷状態や検収状態がある
作業タスク	行ごとに担当者、期限、完了状態がある
在庫入出庫履歴	明細ごとに在庫数や倉庫を動かす
売上明細	月次集計、会計連携、商品別集計に使う
問い合わせ履歴	1件ごとの対応状況やコメントが必要

テーブルに入れてよいのは、親レコードと一緒に読まれる明細です。明細単位で状態・権限・集計・連携が必要なら、別アプリ化を検討します。

テーブルとサブテーブルはどう違うか

kintoneでは、現在の画面やヘルプでは主に「テーブル」と表記されます。

一方で、記事やプラグイン、現場の会話では「サブテーブル」と呼ばれることがあります。

多くの場合、サブテーブルはkintoneのテーブル機能を指しています。

トライコーンの記事でも、kintoneのテーブル機能はサブテーブルとも呼ばれる機能として説明されています。

トライコーン：kintoneのテーブル機能とは？

ペパコミの記事でも、テーブル機能とサブテーブル機能の違いについて、基本的には同じ機能を指す文脈で整理されています。

ペパコミ：kintoneのテーブル機能とは？

実務では、呼び方よりも設計上の意味が重要です。

呼び方	実務で見ること
テーブル	kintoneのフォーム上の機能名として扱う
サブテーブル	プラグインや過去資料で使われる呼び方として読む
明細	業務上の行データとして扱う
明細アプリ	明細を1レコードとして独立させる設計

この記事では、kintoneの機能名としては「テーブル」と呼びます。

ただし、プラグイン名や検索語としては「サブテーブル」も出てきます。

大事なのは、テーブルかサブテーブルかではなく、その行データを1レコード内に閉じてよいかです。

テーブル化してよいデータ

テーブル化してよいデータには、共通点があります。

親レコードが主で、明細が従です。

明細だけを単独で業務処理する必要が弱い。

親レコードと同じ権限で見せればよい。

帳票に出す内訳として使いたい。

行数が大きく増えない。

この条件に合うなら、テーブルは扱いやすいです。

業務	親レコード	テーブル明細	向く理由
見積	見積1件	商品・作業明細	提出時点の内訳を固定できる
請求	請求1件	請求明細	帳票の行として扱いやすい
作業報告	報告1件	作業内容、時間	報告書内で完結しやすい
点検	点検1件	点検項目、結果	同じ点検内の結果として残せる
経費申請	申請1件	日付、費目、金額	申請全体として承認しやすい

たとえば、見積書の明細はテーブルに向きます。

見積1件に対して、明細行が数行から十数行。

商品名、数量、単価、金額を入力する。

小計や合計を計算する。

見積書PDFに出す。

この場合、明細だけを単独で探すより、見積レコードの一部として残す意味が強いです。

作業報告も、1日の作業内容を報告書として残すだけならテーブルで足ります。

ただし、作業行ごとに担当者、承認、請求、原価、在庫消費が絡むなら、別アプリ化を考えます。

別アプリに分けるべきデータ

テーブルを別アプリに分けるべきかは、明細1行を独立したレコードとして扱いたいかで判断します。

次の条件が増えるほど、テーブルではなく明細アプリが向きます。

判断軸	テーブルで足りる	別アプリが向く
行数	少ない	多い、増え続ける
検索	親レコードを探せればよい	明細行そのものを検索したい
集計	親レコード内の合計でよい	商品別、担当者別、月別に集計したい
状態管理	親レコード全体で同じ状態	行ごとに未着手、完了、取消がある
権限	親と同じ権限でよい	行ごとに閲覧・編集を分けたい
連携	帳票に出す程度	会計、在庫、外部システムへ渡す
更新頻度	親レコード編集時にまとめて更新	明細だけ頻繁に更新される

たとえば、受注管理で注文ごとの商品行を持つ場合を考えます。

注文書を出すだけなら、注文明細はテーブルで足りることがあります。

しかし、商品行ごとに出荷予定日、出荷状態、欠品、納品、請求、返品を追うなら、明細アプリに分けた方がよいです。

親アプリ	明細アプリ	分ける理由
受注	受注明細	商品行ごとに出荷・請求を追う
請求	請求明細	売上明細を会計や集計へ渡す
作業報告	作業明細	作業行ごとに担当・工数・原価を持つ
在庫	入出庫履歴	1回の入出庫を履歴として残す
問い合わせ	対応履歴	1回の対応ごとに担当や状態を持つ

明細アプリに分けると、親レコードからは関連レコード一覧で見せます。

必要なら、親レコードに件数や合計を保存します。

このあたりは、kintone関連レコードの設計方法やkintone関連レコード集計の設計方法とつながります。

ルックアップ・関連レコード・帳票との関係

kintoneテーブルは、単体で完結する機能ではありません。

ルックアップ、関連レコード、帳票出力と一緒に設計します。

組み合わせ	使いどころ	注意点
テーブル + ルックアップ	明細行で商品や作業メニューを取得する	コピーした値を再取得するルールが必要
テーブル + 計算	数量、単価、小計、合計を計算する	税区分や端数処理を決める
テーブル + 帳票	見積書、請求書、作業報告書を出す	帳票に出す項目と社内項目を分ける
明細アプリ + 関連レコード	親から明細履歴を見る	標準では一覧・集計・CSVに制約がある
明細アプリ + 集計値保存	親に件数や合計を持つ	再計算日時と状態を持つ

kintone公式ヘルプでは、ルックアップの設定例として、テーブル内にルックアップを配置し、商品コードから商品名や単価を取得する例が紹介されています。

kintoneヘルプ：ルックアップを設定する

これは見積明細や注文明細でよく使う構成です。

ただし、参照元のテーブルをそのままコピーする話は別です。

kintoneテーブルルックアップの記事でも整理している通り、テーブル内の各行でルックアップすることと、参照元アプリのテーブル明細を丸ごとコピーすることは分けて考えます。

帳票との関係も重要です。

見積書や請求書では、テーブル明細が帳票の行になります。

その場合、提出時点の値を残すために、商品名、単価、税区分、摘要などをテーブルにコピーして固定する設計が自然です。

一方、常に最新のマスタ値を見たいだけなら、テーブルにコピーする必要がない場合もあります。

集計・CSV・一覧表示への影響

テーブルは、帳票には向きます。

しかし、集計、CSV、一覧表示、外部連携では注意が必要です。

kintoneヘルプでは、テーブルに設定したフィールドには、通常フィールドとは異なる制限があることが案内されています。

kintoneヘルプ：テーブルに設定したフィールドで使えない機能

たとえば、テーブル内フィールドをアプリアクション、レコードのアクセス権の条件、関連レコード一覧の条件、ルックアップのコピー元などに使う場面では制約を確認する必要があります。

また、テーブルを含むCSVの読み込みや書き出しでは、行の持ち方を理解しておかないと更新を誤ります。

kintoneヘルプ：テーブルを含むレコードをファイルから読み込む際の注意事項

要件	テーブルのまま	明細アプリ化
帳票に明細を出す	扱いやすい	帳票側で結合が必要
親レコード内で合計する	扱いやすい	集計処理が必要
明細単位で検索する	制約が出やすい	扱いやすい
明細単位で一覧表示する	親レコードを開く必要がある	標準一覧で扱いやすい
明細単位で権限を分ける	難しい	設計しやすい
外部システムへ連携する	行展開が必要	1レコード1明細で渡しやすい

テーブルは帳票内の明細には向きますが、明細単位の検索・集計・権限・外部連携が主目的なら、最初から明細アプリを検討します。

明細が増えたときの設計変更

最初はテーブルで始めても、運用が進むと明細が増えることがあります。

次の兆候が出たら、明細アプリへの分割を検討します。

• 1レコード内の行数が増え、入力や確認が重い
• 明細行ごとに担当者、期限、状態を持ちたくなる
• 明細行だけを検索したいという要望が増える
• 商品別、担当者別、月別の集計が必要になる
• 明細行ごとに外部システムへ渡したくなる
• テーブルのCSV更新で事故が起きる
• テーブル内の値を別アプリから参照したくなる

分割するときは、いきなり全部を移すのではなく、次の形を整理します。

移行前	移行後
親レコード内テーブル	親アプリ + 明細アプリ
行番号	明細番号
親レコード番号	親ID、業務番号
テーブル内商品コード	明細アプリの商品コード
テーブル内金額	明細アプリの金額
親レコードの合計	明細アプリ集計値を親へ保存

大事なのは、親レコードとの紐づけキーです。

レコード番号だけに頼るより、見積番号、注文番号、請求番号、報告番号など、業務上のIDを持たせる方が扱いやすいことが多いです。

明細アプリに分けた後も、親レコードから関連レコード一覧で明細を見せられます。

親レコードに合計や件数を持たせたい場合は、集計処理を設計します。

よくある失敗

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

失敗	起きること	修正の方向
何でもテーブルに入れる	明細単位の検索や集計で詰まる	明細アプリ化の基準を作る
履歴をテーブルに積む	1レコードが肥大化し、時系列が追いにくい	履歴アプリに分ける
行ごとの状態管理をする	完了、取消、差し戻しが複雑になる	1行を1レコードにする
帳票だけ見て設計する	後から分析や連携に対応しづらい	帳票、集計、連携を同時に見る
テーブル内ルックアップを過信する	参照元テーブルのコピーで詰まる	標準機能とプラグインの範囲を分ける
CSV更新を軽く見る	行の更新・削除で事故が起きる	更新キーと取込手順を決める
サブテーブルという名前だけで判断する	機能理解が曖昧なまま進む	業務上の明細単位を決める

特に多いのは、作業履歴や対応履歴をテーブルに積み続けるケースです。

「1件の顧客レコードの中に履歴を増やせるから便利」と見えますが、履歴は本来、1回の対応ごとに日時、担当者、内容、次回予定、添付、コメントを持つことがあります。

その場合は、顧客アプリのテーブルではなく、活動履歴アプリや問い合わせ履歴アプリに分けた方がよいです。

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

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

確認項目	決めること
親レコード	テーブルを持つ業務レコードは何か
明細の意味	1行が何を表すか
行数	通常何行、最大何行になりそうか
状態管理	行ごとのステータスが必要か
権限	行ごとに閲覧・編集を分ける必要があるか
集計	親内合計で足りるか、明細単位で集計するか
帳票	どの行を帳票に出すか
ルックアップ	商品、顧客、作業メニューなどを取得するか
CSV/API	外部連携や一括更新でどう扱うか
将来分割	明細アプリ化する場合のキーを持つか

この表で、行ごとの責任が重いなら、テーブルではなく明細アプリを検討します。

逆に、親レコードの内訳として帳票に出すだけなら、テーブルは有効です。

Bitlightに相談できること

Bitlightでは、kintoneのテーブル設計を、入力画面だけでなく、帳票、集計、CSV、API連携、将来の明細アプリ化まで含めて整理できます。

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

• 見積明細、請求明細、作業明細、履歴のテーブル化判断
• テーブルに残す項目と、別アプリに分ける項目の整理
• テーブル内ルックアップ、計算フィールド、帳票出力の設計
• 明細アプリ化した場合のキー設計、関連レコード表示、集計値保存
• テーブルを含むCSV取込・書き出しの運用手順
• 既存アプリのテーブル肥大化を整理する移行方針
• 商品別、担当者別、月別集計に耐える明細データ構成

kintoneテーブルは、少量の明細を親レコード内に持つには便利です。

しかし、明細が業務の主役になった瞬間に、テーブルだけでは足りなくなります。

親レコードの一部として残す明細なのか。

独立した業務データとして扱う明細なのか。

ここを決めてからテーブルを作ることで、帳票にも集計にも連携にも耐えやすい構成になります。

kintone帳票管理の設計方法はこちら
kintone請求書管理の設計方法はこちら