kintoneのフィールド設計｜後から直せなくなる前に決めること

kintoneのフィールドで後から直せないのは「型」「フィールドコード」「重複禁止の後付け」の3つです。この3つだけは、アプリを作るときに決めきってください。

残りは運用しながら足せます。逆に言えば、最初から完璧な項目一覧を作ろうとする必要はありません。直せないものだけ先に決め、直せるものは現場に使わせてから足すのが、いちばん早く進みます。

後から直せるもの・直せないもの

フィールドの型の選び方（迷いやすいところだけ）

「文字列にしてはいけないもの」を先に潰す

現場のExcelをそのまま持ち込むと、日付・数値・選択肢がすべて文字列になります。これが後でいちばん効いてきます。

• 日付が文字列 → 並び替えが「2026/1/5 より 2026/10/1 が先」になる。残日数も出せない
• 数値が文字列 → 合計・平均・グラフが出せない
• 選択肢が文字列 → 「完了」「完了 」「済」が別物として集計される

この3つは、型を作り直すしか直す方法がありません。 移行前のExcel側の掃除については11章 Excelからの移行にまとめています。

選択肢にするか、マスタにするか

分かれ目は「その選択肢は、現場の人が増やしたくなるか」です。

選択肢を増やすにはアプリの設定変更（＝アプリ管理権限）が要ります。現場が自分で増やしたいものは、設定ではなくレコードとして持たせるのが原則です。マスタと記録の分け方は6章 複数アプリのつなぎ方、引き方はルックアップの使い方と設計のコツにあります。

チェックボックス・複数選択の落とし穴

「該当するものすべて」を1つの項目に入れると、集計が素直に出ません。 1レコードに複数の値が入るので、「件数の合計が母数と合わない」状態になります。

分類ごとの件数をグラフで見たいなら、1つだけ選ぶ型（ドロップダウン・ラジオ）に直すか、集計したい分類だけを別のフィールドに切り出してください。

フィールドコードの命名

フィールドコードは、画面には出ないが、計算式・JavaScript・プラグイン設定・CSV・APIがすべて参照している名前です。既定のままだと 文字列__1行__0 のような名前になります。

決めるのは3つだけです。

1. 半角英小文字とアンダースコアにそろえる（日本語コードも動きますが、JSやCSVで扱うときに面倒が増えます）
2. アプリをまたいで同じ意味には同じコードを使う（kokyaku_code はどのアプリでも顧客コード）
3. アプリを作った直後に、全フィールドのコードを付け直す。運用が始まると触れなくなります

アプリの設定画面からコードの一覧を出せますが、アプリが増えてくるとブラウザのコンソールで一気に見るほうが早いです。

// アプリを開いた状態で、ブラウザのコンソールに貼って実行する（棚卸し用）
(async () => {
  const res = await kintone.api('/k/v1/app/form/fields', 'GET', {
    app: kintone.app.getId(),
  });
  const rows = Object.values(res.properties)
    .map((f) => ({
      コード: f.code,
      ラベル: f.label,
      型: f.type,
      必須: f.required ? '○' : '',
      重複禁止: f.unique ? '○' : '',
    }))
    .sort((a, b) => a.型.localeCompare(b.型));
  console.table(rows);
  // CSVで欲しいときは次の行を使う
  // console.log(rows.map((r) => Object.values(r).join(',')).join('\n'));
})();

既定のままのコード（文字列__ で始まるもの）が残っていないか、重複禁止を付け忘れたキーがないかを、この一覧で確認します。運用開始後は同じものをアプリの設定書として保存しておくと、引き継ぎのときに効きます（→kintoneを定着させる）。

一意（重複禁止）は最初に付ける

キーになる項目（顧客コード・物件コード・品番・契約番号）には、アプリを作った時点で「値の重複を禁止する」を付けてください。

後から付けようとすると、すでに重複しているデータがある限り設定を保存できません。運用が半年進んだ状態で数千件の重複を直すのは、現実的には止まります。

標準の重複禁止は1つの項目しか見ません。 「物件名＋部屋番号」「会社名＋電話番号」のような組み合わせで止めたいときは、無料の重複チェック Proを使います（→重複を禁止・チェックする方法）。

番号を人が手で入れる運用にすると必ず重複するので、契約番号・受注番号は自動採番で振ります。

テーブル（サブテーブル）を使う条件

テーブルの行は、1レコードの一部です。ここから使ってよい条件が決まります。

判断の一文は「その行だけを開いて、誰かが仕事をするか」です。仕事をするなら、それはレコードです。

建設の見本では、見積の明細はテーブル、発注は別アプリにしています。発注を業者別・支払予定日別に集計したいからです（→建設会社のkintone）。製造の見本でも、製造指示の工程はテーブル、工程実績は別アプリです。実績には作業者と時間があり、重なりを止める必要があるからです（→製造業のkintone）。

テーブルの行番号は標準では出ないので、無料のテーブル行番号を使います（→テーブルに行番号を付ける方法）。

計算フィールドの限界

計算フィールドでできるのは、同じレコードの中の、数と日時の計算だけです。

とくに「他アプリの値は計算に使えない」は設計に効きます。「案件アプリで、発注アプリの合計原価を出す」はできません。合計を持ちたいなら、集計する側に値を書き戻す作り（JavaScript）が要ります。ここは13章 JavaScript・API・外部連携の範囲です。

見本アプリのフィールド構成

不動産：物件台帳（/kintone/for/fudosan）

製造：品目マスタ（/kintone/for/seizo）

マスタ側の型が、そのまま下流のアプリに効きます。 標準原価を文字列にしていたら、受注アプリで原価の合計が出せません。マスタのフィールド設計を先に固めるのは、このためです。

どうしても型を変えたくなったら

運用後に「この項目、数値にしておけばよかった」となったときの手順です。

1. 新しいフィールドを正しい型で追加する（名前は 賃料（新） などで区別）
2. 既存レコードをCSVで書き出し、値を新しい列に移して取り込む
3. 一覧・グラフ・絞り込み・計算式・JavaScript・プラグイン設定の参照を新しいフィールドに直す
4. 現場に周知し、入力を新しいフィールドに切り替える
5. 古いフィールドをまず非表示にして1か月様子を見る。問題なければ削除する

件数が多いときは、一覧からまとめて書き換えられる無料の一覧からの一括更新も使えます。3が抜けると、古い値のままのグラフが残ります。 運用中にやると半日〜1日仕事になるので、最初に型を決めます。

よくある質問

kintoneでフィールドの型は後から変更できますか

できません。文字列（1行）で作った項目を、あとから数値や日付に変えることはできません。変えたい場合は、正しい型のフィールドを新しく追加し、CSVで書き出して値を移し、古いフィールドを非表示にしてから削除する、という手順になります。運用を始めてからだと、一覧・グラフ・ルックアップ・JavaScriptの参照も一緒に直すことになります。

フィールドコードは後から変えても大丈夫ですか

設定上は変えられますが、変えた瞬間に、そのコードを参照している計算式・一覧の絞り込み・JavaScript・プラグインの設定・CSVの取り込みファイル・APIの呼び出しが動かなくなります。運用開始後のコード変更は、実質「変えられない」と考えて、アプリを作るときに読める名前を付けてください。

電話番号や郵便番号は数値フィールドにすべきですか

文字列（1行）にしてください。数値フィールドにすると先頭の0が消え、桁区切りのカンマが入り、ハイフンを含む表記が入りません。数値フィールドは「足し算・掛け算・集計をする数」にだけ使います。社員番号・伝票番号・品番も同じ理由で文字列です。

選択肢はドロップダウンとラジオボタンのどちらにすればいいですか

選択肢が4つ以下で必ず1つ選ぶならラジオボタン、5つ以上ならドロップダウンが目安です。選択肢が20を超える、または選択肢そのものが業務で増減する（取引先・品目・現場）なら、フィールドではなくマスタアプリにしてルックアップで引きます。

サブテーブルはどんなときに使ってよいですか

明細が親と一緒にしか意味を持たず、行だけを取り出して検索・集計・承認しないときだけです。行ごとに担当者や期限を持たせたい、行の状態を管理したい、行を軸に集計したいと思った時点で、それは別アプリにすべき明細です。テーブルの行は1レコードの一部なので、行単位の権限・プロセス管理・通知は持てません。