kintoneサブテーブルの設計方法｜テーブルとの違いと明細管理の注意点

kintoneの情報を調べていると、「サブテーブル」という言葉が出てきます。

見積明細をサブテーブルに入れる。

請求明細をサブテーブルで管理する。

作業履歴をサブテーブルに追加する。

サブテーブルの合計を計算する。

サブテーブルをJavaScriptでチェックする。

このような表現はよく使われます。

一方、kintoneの公式ヘルプでは、現在は主に「テーブル」と表記されています。

この呼び方の違いで、次のように迷うことがあります。

• サブテーブルとテーブルは別機能なのか
• サブテーブルにはどのフィールドを入れられるのか
• サブテーブル内でルックアップや計算はできるのか
• サブテーブルをCSVで更新できるのか
• サブテーブル内の明細を集計やグラフに使えるのか
• JavaScriptやプラグインで補うべきなのか
• 明細アプリに分けた方がよいのか

結論から言うと、実務上「サブテーブル」と呼ばれているものは、多くの場合、kintoneの「テーブル」機能を指します。

ただし、呼び方の理解だけでは足りません。

大事なのは、その行データを親レコードの中に閉じてよいかどうかです。

kintoneサブテーブルは、別機能として覚えるより、1レコード内に明細行を持つテーブル機能として理解します。そのうえで、明細を親レコード内に閉じてよいかを判断します。

この記事では、kintoneサブテーブルとテーブルの関係、サブテーブルが向く業務、入れるべきでないデータ、計算・重複チェック・ルックアップの注意点、CSV・帳票・APIで困りやすい点、JavaScriptやプラグインで補う範囲、別アプリ化する判断基準を整理します。

kintoneテーブルの設計方法はこちら
kintoneテーブル集計の設計方法はこちら

先に結論：サブテーブルとテーブルは基本的に同じものとして扱う

kintoneの公式ヘルプでは、フォームに「テーブル」を追加する方法が案内されています。

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

このテーブルは、複数のフィールドを1行としてまとめ、同じ形式の行をレコード内に追加できる機能です。

「サブテーブル」という言葉は、現場の会話、過去の記事、プラグイン名、JavaScript解説で使われることがあります。

ロケットスタートの記事でも、kintoneのテーブル機能を「テーブル（サブテーブル）」として説明し、レコードの中に表形式のデータを持たせる機能として紹介しています。

ロケットスタート：kintoneテーブル機能とは？

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

トライコーン：kintoneのテーブル（サブテーブル）とは？

実務では、次のように整理するとよいです。

呼び方	実務上の扱い
テーブル	kintone公式ヘルプやフォーム設定での主な表記
サブテーブル	記事、プラグイン、現場会話で使われる呼び方
明細	業務上の1行データ
明細アプリ	明細1行を1レコードとして独立させる設計

サブテーブルという名前を見たら、まず「レコード内の明細テーブル」と読み替えます。

ただし、明細データが複雑になっている場合は、サブテーブルに入れるかどうかを再検討します。

サブテーブルという呼び方に引っ張られず、業務上の1行が親レコードの内訳なのか、独立したレコードなのかで設計します。

サブテーブルが向く業務

サブテーブルが向くのは、親レコードに従属する少量の明細です。

親レコードが主で、サブテーブル行はその内訳です。

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

親レコードと一緒に承認すればよい。

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

こういう場合は、サブテーブルが使いやすいです。

業務	親レコード	サブテーブル明細	向く理由
見積	見積1件	商品、作業、数量、単価	見積書の内訳として出しやすい
請求	請求1件	請求項目、金額、税区分	請求書の明細として残せる
経費申請	申請1件	日付、費目、金額	申請全体をまとめて承認しやすい
作業報告	報告1件	作業内容、時間、担当	報告書の内訳として読める
点検報告	点検1件	点検項目、結果、備考	同じ点検の結果としてまとまる

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

見積1件の中に、品名、数量、単価、金額を行として持つ。

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

帳票に行として出す。

このような用途では、サブテーブルは自然です。

経費申請も、申請1件の中に複数の費目明細を持つならサブテーブルで始めやすいです。

ただし、費目ごとに個別承認、支払状態、会計連携、証憑確認を細かく追うなら、別アプリ化を検討します。

サブテーブルに入れるべきでないデータ

サブテーブルに向かないのは、明細行そのものが業務の主役になるデータです。

次の条件があるなら、サブテーブルだけで抱えない方がよいです。

判断軸	サブテーブルで足りる	別アプリが向く
行数	少ない	多い、増え続ける
検索	親レコードを探せればよい	明細行を直接検索したい
集計	親レコード内の合計でよい	商品別、月別、担当者別に集計したい
状態管理	親レコード全体で同じ状態	行ごとに未処理、完了、取消がある
権限	親と同じ権限でよい	行ごとに閲覧・編集を分けたい
履歴	親の一部として残せばよい	1回ごとの対応履歴として追いたい
外部連携	帳票に出す程度	会計、在庫、販売管理へ渡す

たとえば、問い合わせ対応履歴を顧客レコードのサブテーブルに入れる設計は、最初は楽に見えます。

しかし、対応履歴は1回ごとに、対応日時、担当者、内容、添付、次回予定、対応状態を持つことがあります。

後から対応履歴だけを検索したい。

未対応だけを一覧にしたい。

担当者別に対応件数を見たい。

顧客以外の案件や契約とも紐づけたい。

こうなったら、サブテーブルではなく対応履歴アプリに分けた方がよいです。

同じことは、作業タスク、出荷明細、在庫入出庫、売上明細にも言えます。

サブテーブルに入れてよいのは、親レコードと一緒に読まれる内訳です。明細行を単独で探す、承認する、集計する、連携するなら別アプリ化を考えます。

計算・重複チェック・ルックアップの注意点

サブテーブルでは、行ごとの計算や、テーブル外での合計ができます。

たとえば、見積明細では、テーブル内で数量と単価から小計を計算し、テーブル外でSUMを使って合計を出します。

この考え方は、kintoneテーブル集計の記事で詳しく整理しています。

サブテーブルでよく出る要件は、次の3つです。

要件	例	注意点
行計算	数量×単価、時間×単価	税区分や丸めを決める
重複チェック	同じ商品コード、同じ日付を禁止	標準機能だけでは足りない場合がある
ルックアップ	商品コードから品名・単価を取得	テーブル内各行で取得する設計になる

Ribbitの記事では、サブテーブル内の重複チェックや合計集計をJavaScriptで実装する例が紹介されています。

Ribbit：kintoneのサブテーブルで重複チェックや合計集計をJavaScriptで実装する方法

JavaScriptで補えば、標準機能だけでは難しいチェックや表示を作れる場合があります。

ただし、JavaScriptを入れる前に、次を決めます。

• 重複を禁止したいのか、警告だけでよいのか
• どのフィールドの組み合わせで重複とみなすのか
• 保存時だけチェックするのか、入力中にもチェックするのか
• 既存データに重複がある場合どうするのか
• 保守担当者がコードを読めるか
• プラグインで足りる範囲ではないか

ルックアップも同じです。

テーブル内の各行で商品コードを選び、商品名や単価を取得する構成はよく使われます。

ただし、参照元アプリのサブテーブルを丸ごとコピーしたい場合は、標準ルックアップとは別の話です。

kintoneテーブルルックアップの記事で整理している通り、各行のルックアップと、サブテーブル丸ごとのコピーは分けて考えます。

CSV・帳票・APIで困りやすい点

サブテーブルは、画面入力や帳票出力では便利です。

一方で、CSV、API、外部連携では注意が必要です。

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

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

また、テーブルを含むレコードをファイルから読み込む場合、ファイルの準備方法や更新時の扱いに注意が必要です。

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

設計時には、次を確認します。

観点	確認すること
CSV取込	既存行の更新、追加、削除をどう扱うか
CSV出力	サブテーブル行がどの形式で出るか
帳票	行順、空行、税区分、社内項目をどう出すか
API	テーブル行をどう読み書きするか
外部連携	外部側が1行1明細を期待していないか
バックアップ	テーブル行まで復元手順を確認するか

特にCSV更新は慎重に扱います。

親レコードの通常フィールドを更新する感覚で、サブテーブル行を更新すると、意図しない行の上書きや削除が起きることがあります。

業務上重要な見積明細、請求明細、原価明細をCSVで更新するなら、事前に検証用アプリで手順を確認します。

帳票では、サブテーブルの表示順と項目名が重要です。

見積書や請求書では、テーブル行がそのまま顧客に渡る明細になります。

社内メモ、原価、承認コメントなどを同じサブテーブルに入れている場合、帳票に出してよい項目と出してはいけない項目を分けます。

サブテーブルは帳票には向きますが、CSV更新や外部連携では行の扱いが複雑になります。重要な明細ほど、取込・出力・復元手順を先に決めます。

JavaScriptやプラグインで補う範囲

サブテーブルでは、標準機能だけで足りない場面があります。

このとき、JavaScriptやプラグインで補うことがあります。

ただし、何でもカスタマイズすればよいわけではありません。

補いたいこと	候補
重複チェック	JavaScript、入力チェック系プラグイン
行ごとの自動計算	計算フィールド、JavaScript
サブテーブル丸ごとコピー	サブテーブルコピー系プラグイン、JavaScript
明細を別アプリに登録	データ転送系プラグイン、API
行の表示制御	JavaScript、フォーム制御系プラグイン
帳票出力	帳票プラグイン

JavaScriptが向くのは、標準機能やプラグインでは表現しづらい細かい入力制御です。

たとえば、同じ商品コードを同じ見積内で重複させない。

特定区分の行だけ必須チェックを変える。

行追加時に初期値を入れる。

保存前に合計値や条件を検証する。

ただし、JavaScriptは保守が必要です。

フォーム変更、フィールドコード変更、プラグイン追加、kintoneアップデートの影響を受けます。

一方、プラグインは設定で扱えるため、保守しやすい場合があります。

ただし、プラグインごとに、扱えるフィールド、行数、実行タイミング、エラー時の挙動、他プラグインとの相性が違います。

補う前に、次を決めます。

• 標準機能で足りない要件は何か
• 入力時の補助なのか、保存後の転記なのか
• 明細の正本はサブテーブルか、別アプリか
• エラー時に誰が気づくか
• 設定やコードを誰が保守するか

別アプリ化する判断基準

サブテーブルで始めた明細を、別アプリに分けるべきタイミングがあります。

次の条件が2つ以上あるなら、分割を検討します。

条件	なぜ分けるか
明細行が増え続ける	親レコードが重くなり、確認しづらくなる
明細単位で検索したい	サブテーブル内より、1レコード化した方が探しやすい
明細単位で集計したい	商品別、月別、担当者別に見やすい
明細ごとに状態がある	出荷、請求、完了、取消を行ごとに持てる
明細ごとに権限を分けたい	親レコードと同じ権限では粗い
外部連携したい	1行1レコードの方が連携しやすい
履歴として積み上げたい	対応履歴や作業履歴は独立レコードが向く

別アプリ化すると、親レコードからは関連レコード一覧で明細を表示します。

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

サブテーブルで持つ	別アプリ化する
親レコード内で入力する	明細1行を1レコードにする
帳票内の明細に向く	横断集計に向く
親と同じ権限で扱う	明細ごとの権限を設計できる
CSV更新に注意が必要	レコード単位で更新しやすい
親レコードの一部として読む	明細を業務データとして扱う

たとえば、見積明細はサブテーブルでよいことが多いです。

一方、受注明細、出荷明細、請求明細、売上明細、在庫入出庫履歴は、業務量によっては別アプリ化した方がよいです。

明細が後工程に渡るかどうかを見ます。

帳票で終わる明細なら、サブテーブル。

後工程で処理する明細なら、別アプリ。

この分け方が基本です。

よくある失敗

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

失敗	起きること	修正の方向
サブテーブルとテーブルを別物だと思う	調査や設計の前提がずれる	公式表記はテーブル、通称はサブテーブルと整理する
履歴をサブテーブルに積む	検索、集計、担当別確認がしづらい	履歴アプリに分ける
行ごとの状態をサブテーブルで管理する	進捗や承認が複雑になる	明細アプリ化する
CSV更新を軽く見る	行の上書きや削除で事故が起きる	検証用アプリで取込手順を確認する
JavaScriptで何でも補う	保守担当がいなくなる	標準、プラグイン、別アプリ化を比較する
帳票だけを見て設計する	後から集計や連携で詰まる	帳票、集計、CSV、APIを同時に見る
明細の正本を決めない	サブテーブル、集計値、外部表の数字がずれる	正本と更新タイミングを決める

特に危ないのは、対応履歴や作業履歴をサブテーブルに入れ続けることです。

履歴は、最初は数行でも、時間とともに増えます。

増えたあとで、未対応だけ探したい、担当者別に見たい、期間で絞りたい、別案件にも紐づけたい、という要望が出ます。

その時点で移行すると大きな手戻りになります。

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

kintoneでサブテーブルを使う前に、次を決めます。

確認項目	決めること
呼び方	公式表記はテーブル、現場呼称はサブテーブルとして整理する
親レコード	どの業務レコードの内訳か
1行の意味	商品明細、作業行、費目、点検項目など
行数	通常行数と最大行数
計算	行計算、合計、条件付き合計
重複チェック	標準で足りるか、JavaScriptやプラグインが必要か
ルックアップ	行ごとにマスタ参照するか
CSV/API	行更新、出力、外部連携の扱い
帳票	出す項目、出さない項目、行順
分割判断	明細アプリ化する条件

この表を埋めると、サブテーブルでよいのか、別アプリ化すべきかが見えます。

少量の内訳として、親レコードと一緒に読むならサブテーブル。

明細行が業務の単位になるなら、別アプリ。

JavaScriptやプラグインは、その判断をした後に使います。

Bitlightに相談できること

Bitlightでは、kintoneサブテーブルを、入力欄としてではなく、明細データの設計として整理できます。

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

• サブテーブルとテーブルの呼称整理
• 見積明細、請求明細、作業明細、対応履歴の持ち方判断
• サブテーブル内の計算、合計、重複チェックの設計
• ルックアップ、帳票、CSV、API連携を前提にした明細設計
• JavaScriptやプラグインで補う範囲の整理
• 明細アプリ化した方がよい業務の切り分け
• 既存サブテーブルを別アプリへ移す移行方針

サブテーブルは、kintoneで明細を扱ううえで便利な機能です。

ただし、便利だからといって、履歴や明細をすべて親レコードの中に閉じる必要はありません。

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

明細自体を業務データとして扱うべきなのか。

この境界を決めておくと、サブテーブルは帳票にも入力にも使いやすく、必要な明細は集計や連携にも耐えやすくなります。

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