kintoneのアプリ設計｜1レコードの決め方

アプリ設計でやることは、1レコードが何かを1文で言い切る・マスタと記録を分ける・文字列にしてよい項目だけ文字列にするの3つです。 この3つを外すと、3か月後に作り直しになります。逆に言えば、それ以外の決定（色・並び順・必須・一覧の数）は、あとからいくらでも直せます。 この章は、直しにくい決定を先に決め切り、直せる決定を後回しにするための章です。

この章で分かること

• 1アプリをどこで切るか。マスタ（変わりにくい情報）と記録（発生するもの）の分け方
• フィールドの型・選択肢・サブテーブルの選び方と、それぞれの分かれ目
• 12項目の設計レビューと、作り直しになる3項目

まず「1レコード＝何か」を1文で言う

アプリを作る前に、紙に1文だけ書きます。

このアプリの1レコードは、（　　　）である。

言えないアプリは、必ず途中で破綻します。当社が実際に作った製造業の見本（製造業のkintone）を例にすると、こうなります。

• ① 品目マスタ＝1つの品番（作る物・買う物が1種類）
• ② 受注＝得意先から受けた1件の注文／③ 製造指示＝その受注を工場の仕事に落とした1枚の指示書
• ④ 工程実績＝1枚の指示書の、1つの工程を、1人が、ある時間帯に作業した記録
• ⑤ 在庫入出庫＝1回の入庫または出庫／⑥ 不良・是正＝1件の不良と、その原因・対策

④が肝心です。「工程実績」を「1枚の指示書の実績」と定義していたら、1レコードに何人分もの作業が入り、作業者ごとの時間を集計できなくなります。1レコード＝1人・1工程・1時間帯と決めたからこそ、作業者・開始・終了・良品数・不良数という項目が決まり、同じ作業者の時間の重なりを保存前に警告できるようになりました。

項目を決めてから1レコードを決めるのではなく、1レコードを決めると項目が決まります。 順番が逆になっている設計は、だいたい項目が多すぎます。

マスタと記録を分ける

kintoneの設計で最初に作り直しになるのは、ここを混ぜたときです。

• マスタ＝変わりにくい情報。品目、取引先、物件、社員
• 記録（トランザクション）＝日々発生するもの。受注、日報、入出庫、内見予約

見本の製造業では、① 品目マスタ と ⑤ 在庫入出庫 の関係がそのまま教材になります。

アプリ	持っている項目	役割
① 品目マスタ	品番（重複禁止・必須）／品名／区分／単位／標準原価／在庫数／安全在庫／在庫の余裕	いま何個あるかの結論を持つ
⑤ 在庫入出庫	品番（ルックアップ）／区分（入庫・出庫）／数量／日付／ロット／備考	その結論の裏付けを1件ずつ持つ

もしこれを1アプリにまとめたら、「ベアリングの在庫は何個か」を見るために入出庫の履歴を全部足し算することになります。逆に、入出庫を持たずにマスタの在庫数だけを手で書き換えていたら、数が合わなくなったときに原因をたどれません。結論と裏付けは、別のアプリに分けて両方持つのが正解です。

分けたうえで、品目マスタには関連レコード一覧として 受注の履歴 と 入出庫の履歴 を置いてあります。品番で自動的に絞り込まれるので、品目を1件開けば、その品番に起きたことが下に全部並びます。不動産の見本も同じ形で、① 物件台帳 に 内見の予定・契約・修繕履歴 が並びます。マスタは「開くと、その先の全部が見える場所」になります。

フィールドの型：文字列にしてよいのは何か

日付・数値・選択肢を文字列フィールドで作ると、あとから直すのに全レコードの移行が要ります。型の変更は、値を持ったあとにはできないと考えてください。

見本の受注アプリでの持ち方です。

項目	実際の型	文字列にしたらどうなるか
納期	日付	「9/30」「2026-9-30」「9月末」が混ざり、期限の並べ替えも残日数の計算もできない
数量 単価	数値（単位「個」「円」）	合計が出ない。「1,200円」と書かれたら計算不能
受注金額	計算（数量 * 単価）	手入力だと、単価を直したときに金額が古いまま残る
状況	ドロップダウン（受付／生産中／出荷済／完了／キャンセル）	「出荷済み」「出荷済」「発送済」に割れ、集計もグラフも作れない

計算フィールドは見本の随所で使っています。在庫の余裕 = 在庫数 - 安全在庫、生産数 = 良品数 + 不良数、予定時間の合計 = SUM(予定時間)、原状回復の 金額 = 数量*単価 と 見積合計 = SUM(金額)。足し算・引き算で出せる値を手入力にしない——これだけで、あとから合わなくなる事故がかなり減ります。

在庫の余裕 は、そのまま色の条件にも使っています。条件書式プラグインで「在庫の余裕 が 0 以下なら赤く」と設定しているので、安全在庫を割った品目が一覧で目に飛び込みます。計算フィールドを1つ足すと、色の条件も通知の条件もそこに集約できます。

比較：文字列／選択肢／マスタのどれにするか

同じ「文字を入れる項目」でも、選択肢は4つあります。

	文字列（1行）	ドロップダウン／ラジオボタン	別アプリ＋ルックアップ
向く場面	毎回違う値（住所・ロット番号・備考）	決まった値から選ぶ。集計の軸にする項目（2〜4個ならラジオ）	値に付随情報がある（単価・住所・担当者）
集計	できない（表記ゆれで割れる）	できる	できる
値を増やすとき	自由	アプリの設定変更が要る。選択肢を消すと過去の値が浮く	レコードを1件足すだけ
見本での例	ロット／備考／住所	工程名／区分（入庫・出庫）／状況	品番／物件コード／案件番号

判断は上から3問です。①集計したいか（したいなら文字列にしない）、②値に付随情報があるか（品番を選んだら品名と標準原価も入ってほしい→マスタ＋ルックアップ）、③値が増え続けるか（増え続けるならマスタ、固定ならドロップダウン）。

見本の受注アプリの 品番 は、ルックアップで品目マスタから 品名 と 標準原価 を持ってきます。選ぶときの候補画面には 品番・品名・区分・在庫数 を出しているので、在庫を見ながら受注を入れられる。ドロップダウンでは作れない形です。

人を指す項目には注意点があります。見本の工程実績は 作業者（ユーザー選択）と 作業者名（文字列・必須）を両方持っています。ユーザー選択は通知や権限に使えますが、kintoneのアカウントを持っていない職人・パート・外注先は選べません。建設の作業日報も同じ2本立てです。全員がアカウントを持っているかで決まる判断で、見誤ると現場で入力できなくなります。

比較：サブテーブルで持つか、別アプリにするか

一番相談の多いところです。分かれ目は1つ、その中の値を集計・絞り込みしたいかです。

	サブテーブルで持つ	別アプリにしてつなぐ
向く場面	親と一体で、1枚の紙として意味がある明細	1件ずつ独立して発生し、あとで数えたい記録
集計	親の中の合計は出せる（SUM()）。テーブルをまたいだ集計はできない	できる。グラフの軸にもできる
絞り込み	行だけを条件で絞った一覧は作れない	一覧で自由に絞れる
入力の手間	親を開いて行を足すだけ。速い	1件ずつ新規作成。やや重い
見本での例	原状回復の 工事明細（No／工事項目／数量／単価／金額）、建設の見積 明細、製造指示の 工程（行番号／工程名／担当／予定時間）	④ 工程実績、⑤ 在庫入出庫、⑤ 作業日報

同じ「工程」が、見本の中で両方の形で出てくるのが見どころです。③ 製造指示 の 工程 はサブテーブル——材料切断→旋盤加工→熱処理→組立→検査をこの順でやるという予定であり、指示書と一体で、合計も 予定時間の合計 = SUM(予定時間) で足ります。いっぽう ④ 工程実績 は別アプリ——誰が・いつ・何個作って・何個不良だったかを、作業者別・工程別に数えたいからです。実績もサブテーブルに入れていたら、「今月、旋盤加工の不良率はいくつか」に答えられません。

「あとで数えたくなる値がテーブルの中にある」と気づいた時点で、別アプリに出す——これが9番目の点検項目です。

名前は、ラベルとコードの2つある

ラベル（画面に出る名前）の決まりは3つだけです。具体的に（「日付」ではなく 契約開始日）、アプリをまたいで統一する（顧客名 を「お客様」と書き分けない。ルックアップと集計でつまずきます）、短くしすぎない（「料金」ではなく 月額利用料）。

フィールドコード（画面に出ない名前）のほうが重要です。コードは、あとで書くすべての設定から名指しで参照されるからです。期限プラグインは "納期" → "納期までの残日数"、条件書式は "在庫の余裕" ≦ 0、条件付き必須は "状態" = "完了" のとき ["対策","完了日","確認者"]、重複チェックは ["品番","区分","日付","ロット"] の組み合わせ。これが 文字列__1行__0 や 数値__3 だったら、設定画面を開いた人は何のルールか読めません。1年後に直すのは、たいてい作った本人ではない人です。コードは、将来の担当者へのメモだと思って付けてください。

付け直すのはアプリを作った直後です。 運用が始まると、設定と計算式が参照しているので触れなくなります。命名の流儀（日本語でそろえるか、半角英小文字にそろえるか）、既定のコードが残っていないかを一括で棚卸しするスクリプト、型を変えたくなったときの手順は、記事kintoneのフィールド設計にまとめてあります。この章が決めるのは、どの決定を先に決め切るかの順番だけです。

一覧は「誰が・いつ見るか」で数える

kintoneの既定の一覧（(All records)）のままのアプリは、まず使われません。列が英語のままだったり、全項目が横に並んで読めなかったりするからです。見本では6つのアプリすべてに日本語の一覧を1つずつ作り、列と並び順を業務に合わせています。

一覧の名前	並び順	誰が何のために見るか
受注一覧	納期 の昇順	納期の近い順に、今日追うべき受注を見る
製造指示一覧	完了予定日 の昇順	工場の朝礼で、遅れそうな指示を確認する
不良・是正一覧	是正期限 の昇順	期限の近い是正から片付ける
工程実績一覧／入出庫一覧	開始／日付 の降順	直近に入力された実績・最近の動きを追う

並び順に法則があります。 これから対応するもの（納期・期限・予定）は昇順、すでに起きたもの（実績・履歴）は降順。迷ったらこれで決めて構いません。一覧の数は最初は1〜3個で十分です。「毎朝これを見る」が1つ決まっていれば合格で、あとから使いながら増やします。

直しにくい決定から順に決める

設計の判断には、作り直しになるものと、いつでも直せるものがあります。上から順に決めてください。

順	決めること	あとから直すと
1	アプリの切り方（1レコード＝何か）	全データの作り直し・再移行（最も戻しにくい）
2	キーになる項目（品番・物件コード・案件番号）	関連する全アプリのつなぎ直し
3	フィールドの型（日付・数値・選択肢）	項目を作り直して全件を入れ直す
4	サブテーブルか別アプリか	データの作り直し
5	マスタに切り出すか、選択肢にするか	既存レコードのひも付け作業が発生
6	必須・入力チェック・色・一覧・選択肢の追加	設定を変えるだけ（いつでも直せる）

1〜4は、最初の2週間で決め切ります。5・6は現場に触らせてから決めます。 順番を守れば、現場の要望をいくら受けても作り直しにはなりません。

よくある間違いを5つ

1. 1つのアプリに全部入れる——「顧客も案件も請求も1アプリで」。結果、項目が60を超え、どの画面でも9割が空欄になります。 → 直し方：1レコードが何かを1文で言ってみます。「顧客であり案件でもある」としか言えないなら、そこが分割線です。見本の6アプリは、6つの別々の文で説明できます。項目が50を超えたら、分割を検討すべきサインだと思ってください。逆側の壊れ方もあります——直すのが怖くてアプリを複製し、「〇〇管理」「〇〇管理_v2」「〇〇管理_新」が並ぶ形です。どれが本番か誰にも分からなくなるので、複製して逃げないことをルールにします（複製が要るのは、戻せない変更を試すときだけ。15章）。

2. 集計したい項目を自由入力にする——工程名 を文字列にすると「旋盤」「旋盤加工」「センバン」に割れ、工程別の集計が永久に出せません。 → 直し方：着手前に「この業務で見たい数字」を3つ書き出し、その軸になる項目を先にドロップダウンかマスタ参照に決めます。見本の 工程名 が6択のドロップダウンなのは、工程別に数えるためです。

3. 例外処理を全部アプリに作り込む——「このお客様だけ締め日が違う」を項目とルールで再現すると、画面が誰にも読めなくなります。 → 直し方：月1件以下の例外は備考欄と運用で吸収します。頻度が上がってきたら、そのとき項目にする。最初から作り込まない。

4. 必須項目を増やしすぎる——「漏れを防ぎたい」で必須を20個付けると、現場は保存できずダミーの値を入れ始め、品質はむしろ落ちます。 → 直し方：常時の必須は10個以内に抑え、残りは条件付き必須にします。見本の不良・是正は 状態 が「完了」のときだけ 対策・完了日・確認者 を必須にし、受注は 状況 が「キャンセル」のときだけ キャンセル理由 を必須にしています。入力の途中では縛らず、状態が進んだときだけ縛るのが現実的です。

5. 「あとで使うかも」の項目を先に作る——使う人が決まっていない項目は永久に空欄のまま残り、一覧を読みにくくします。 → 直し方：全項目に「誰が・いつ入れるか」を言えるか確かめ、言えない項目は作りません。kintoneは項目を足すのが一番簡単な操作なので、必要になってから足せば間に合います。

この章の出口

1レコードが何かを書いた1文、項目の一覧（型・必須・選択肢の中身まで決まっている）、キーになる項目が1つ（重複禁止が付いている）、「毎朝これを見る」一覧が1つ、そして点検リストの結果（3・4・9 が○）。

ここまでで、アプリ1つの中は片付きました。次の問題は、そのアプリの外です。品番を受注アプリにも入出庫アプリにも持たせるとき、どちらをコピーにして、どちらを参照にするのか。マスタを直したとき、過去のレコードはどうなるのか。ここを間違えると、アプリは増えるのに数字が合わなくなります。

次の章へ：6章 kintoneのアプリ連携とルックアップの使い方