kintoneデータベースの設計方法｜Excel移行で崩れないアプリ構成

kintoneは、社内のデータベースとして使えます。

顧客台帳、案件一覧、在庫表、問い合わせ履歴、申請データ、契約管理、請求前確認。

Excelで管理していた表をkintoneアプリに移すだけでも、複数人で同じデータを見られます。

レコードごとにコメントを残せます。

一覧やグラフを作れます。

アクセス権や変更履歴も使えます。

ただし、kintoneをデータベースとして使うときに一番危ないのは、「Excelの列をそのままフィールドにする」ことです。

実務で崩れるのは、次のような状態です。

• 顧客名、案件名、商品名を各アプリで自由入力して、表記揺れが起きる
• 1つのアプリにマスタ情報、取引情報、履歴、メモ、添付を全部入れる
• どのフィールドが正本か分からない
• レコード番号を主キーのように使い、外部連携で扱いづらくなる
• ルックアップでコピーした値とマスタ側の値がずれる
• 関連レコード一覧を集計や同期の代わりに使ってしまう
• CSV取込で重複レコードが増える
• 添付ファイルが散らばり、どのファイルが正式版か分からない
• 権限をアプリ単位でしか考えず、部署ごとの閲覧範囲が崩れる
• 外部DBや会計ソフトに任せるべきデータまでkintoneに抱え込む

kintoneをデータベースとして使うなら、最初に決めるべきなのはフィールド名ではありません。

「どの情報を正本にして、どのアプリに分け、どの関係でつなぐか」です。

kintoneデータベース設計で最初に決めるべきなのは、Excelの列名ではなく、マスタ・取引・履歴・集計・添付・権限の分け方です。

この記事では、kintoneをデータベースとして使うときの、Excel移行、アプリ分割、主キー、重複防止、一覧、権限、変更履歴、CSV/API、外部DB連携の境界を整理します。

Excelからkintoneへ移行する考え方はこちら
kintone顧客管理の設計方法はこちら

先に結論：kintoneは業務の責任単位でアプリを分ける

kintoneのアプリは、単なる表ではありません。

1つのアプリには、フォーム、レコード、一覧、グラフ、コメント、通知、アクセス権、プロセス管理、変更履歴が紐づきます。

そのため、アプリは「表の種類」ではなく「業務上の責任単位」として分けます。

分ける単位	1レコードの意味	役割
マスタ	1社、1商品、1担当者、1部門	正式名称、コード、分類、利用状態を持つ
取引データ	1案件、1注文、1申請、1問い合わせ	状態、金額、担当、期限、承認状況を持つ
履歴	1回の接点、1回の作業、1回の変更	いつ誰が何をしたかを残す
添付管理	1ファイル、1契約書、1証憑	正式版、版数、提出日、保管先を持つ
集計用データ	1日、1月、1担当、1商品など	レポートや分析の単位を揃える
連携ログ	1回のCSV取込、API同期、外部送信	成功、失敗、再実行、エラー内容を残す

Excel台帳では、これらが1シートに混ざっていることが多いです。

顧客名、案件名、最新ステータス、過去対応メモ、見積ファイル、請求予定、担当者変更履歴。

1人で使うExcelなら、それでも何とか運用できます。

しかし、kintoneで複数人が使うと、誰がどの項目を更新するのか、どの情報を信用するのかが問題になります。

kintone公式ヘルプでも、アプリ間のデータ連携として、ルックアップ、関連レコード一覧、アプリアクションなどの方法が案内されています。

kintoneヘルプ：アプリ間でデータを連携する

この機能を使う前に、どのアプリが正本なのかを決めます。

正本が決まっていないまま連携だけ増やすと、コピーされた値と元データがずれていきます。

Excelをそのまま移すと崩れる理由

Excelからkintoneへ移すとき、最初にやりがちなのは、Excelの列をそのままフィールドにすることです。

これは小さな台帳なら早く始められます。

ただし、Excelの表には、kintone上では分けるべき情報が混ざっています。

Excel列の例	kintoneでの扱い
顧客名	顧客マスタへ分ける
顧客担当者	担当者マスタへ分ける
案件名	案件アプリのレコードにする
最新状況	ステータス、または状態フィールドにする
対応メモ	活動履歴アプリへ分ける
見積PDF	添付管理、または帳票・ストレージと分ける
請求予定	請求確認アプリ、会計ソフトと分ける
変更メモ	変更履歴、コメント、履歴アプリで扱う

Excelでは、自由入力、セル結合、色分け、メモ、別シート参照、手作業の並べ替えがよく使われます。

kintoneに移すなら、それらをデータ構造に置き換えます。

色分けはステータスや優先度。

別シート参照はマスタアプリとルックアップ。

メモの積み上げは履歴アプリ。

セル結合は、1レコードの単位の見直し。

手作業の並べ替えは、一覧、絞り込み、ソート、グラフ。

この変換をせずに移すと、kintone上に「見た目だけデータベース」のアプリができます。

入力はできるが、検索しづらい。

一覧はあるが、正しい集計にならない。

権限はあるが、見せるべき単位が合わない。

履歴は残るが、業務上の経緯として読めない。

Excel移行では、列をフィールドに写す前に、Excel内の「マスタ」「取引」「履歴」「計算」「見た目の工夫」を分解します。

kintoneのアプリ・レコード・フィールドを整理する

kintoneをデータベースとして見ると、アプリ、レコード、フィールドを次のように考えます。

kintoneの要素	データ設計での意味	注意点
アプリ	データの責任単位	何でも1アプリにしない
レコード	業務上の1件	1社、1案件、1申請、1履歴などを決める
フィールド	1つの属性	自由入力と選択肢を使い分ける
レコード番号	kintone内の自動番号	外部の正式キーとは分ける
ルックアップ	他アプリの値をコピーする	マスタ変更時の反映範囲に注意する
関連レコード一覧	条件に合う他アプリのレコードを表示する	表示であって、データを持つわけではない
アプリアクション	レコードの値を別アプリへ転記する	コピー後の更新責任を決める

特に重要なのは、アプリを増やす判断です。

アプリが少なすぎると、1つのレコードに多くの意味が混ざります。

アプリが多すぎると、入力や参照が面倒になります。

基準は、「1レコードの意味」を一文で言えるかです。

1レコードの意味	アプリ候補
1社の顧客情報	顧客マスタ
1人の顧客担当者	担当者マスタ
1つの商談	案件
1回の面談や電話	活動履歴
1つの注文	受注管理
1件の問い合わせ	問い合わせ
1回の申請	申請・承認
1つの在庫品目	商品・在庫マスタ

この一文が曖昧なら、アプリ設計がまだ固まっていません。

たとえば、「顧客の案件と対応履歴と請求予定を持つレコード」は、1レコードの意味が広すぎます。

顧客、案件、活動履歴、請求確認を分けた方がよいです。

kintone案件管理の設計方法でも整理したように、案件の現在状態と、過去の活動履歴は分けて持つ方が後から使いやすくなります。

マスタと取引データを分ける

kintoneデータベース設計の基本は、マスタと取引データを分けることです。

マスタは、比較的変わりにくい辞書です。

取引データは、日々発生する業務イベントです。

マスタ	取引データ
顧客マスタ	案件、問い合わせ、契約確認
商品マスタ	受注、出荷、在庫移動
担当者マスタ	活動履歴、問い合わせ対応
部門マスタ	申請、承認、予算管理
勘定科目マスタ	経費申請、請求確認

マスタを分ける理由は、表記揺れを防ぐためだけではありません。

どの名前を正式名称にするか。

どのコードを使うか。

利用停止したものをどう扱うか。

誰がマスタを更新できるか。

これを決めるためです。

たとえば、顧客名を案件アプリに自由入力すると、次のような表記揺れが出ます。

入力例	問題
株式会社サンプル	正式名称
サンプル株式会社	別会社のように見える
（株）サンプル	集計で分かれる
サンプル	略称で検索できるが正式ではない
sample inc.	英字表記で別レコード化する

顧客マスタを作り、案件や問い合わせは顧客マスタを参照する。

これだけで、集計や検索の品質が上がります。

ただし、マスタを作れば終わりではありません。

マスタの管理者、登録ルール、重複確認、利用停止の扱いを決めます。

ルール	決めること
新規登録	誰が登録できるか
重複確認	会社名、コード、電話番号など何で確認するか
名称変更	旧名称を残すか、履歴をどう残すか
利用停止	削除ではなく無効化するか
権限	誰が編集でき、誰が閲覧だけか

kintoneでデータベースを作るなら、マスタは「参照用の一覧」ではなく、正式名称・コード・利用状態・更新責任を持つデータの正本として設計します。

主キー・重複防止・採番の考え方

データベースとして使うなら、レコードを識別するキーが必要です。

kintoneにはレコード番号があります。

ただし、レコード番号をそのまま業務上の主キーとして使うかは慎重に考えます。

キー	使いどころ	注意点
レコード番号	kintone内での識別	アプリごとに採番され、外部の正式コードとは別
顧客コード	顧客を外部システムとも識別	採番ルールと重複防止が必要
案件番号	案件、見積、契約をつなぐ	途中変更しない
商品コード	商品、在庫、受注をつなぐ	既存基幹システムと合わせる
外部ID	フォーム、会計、MAなどとの同期	連携元ごとに管理する

主キーは、表示名ではありません。

顧客名、商品名、案件名は変わることがあります。

正式名称が変わっても、同じ顧客として扱うなら顧客コードを変えない方がよいです。

商品名が変わっても、同じ商品なら商品コードで追えるようにします。

重複防止では、入力前と入力後の両方を考えます。

タイミング	対策
登録前	既存マスタを検索してから登録する
登録時	コード、メール、電話番号などで重複チェックする
取込時	CSVのキー列で更新か新規かを分ける
運用中	重複候補一覧を定期的に確認する
統合時	残すレコード、移す履歴、無効化するレコードを決める

CSV取込では、重複が増えやすいです。

一度登録した顧客を、別のCSVから新規登録してしまう。

案件番号が空欄のまま取込まれる。

外部IDを持たないため、更新なのか新規なのか判定できない。

このような事故を避けるには、移行前にキー列を決めます。

CSV/API連携を予定しているなら、外部IDフィールドを最初から持たせる方が安全です。

ルックアップ・関連レコード・アプリアクションの使い分け

kintoneでは、アプリ同士をつなぐ方法がいくつかあります。

ここを誤解すると、データベース設計が崩れます。

方法	役割	向いている使い方
ルックアップ	他アプリの値をコピーする	顧客コードから正式名称、住所、担当部署を取り込む
関連レコード一覧	条件に合う他アプリのレコードを表示する	顧客レコード上で案件や問い合わせ履歴を見る
アプリアクション	レコードの値を別アプリへ転記する	案件から見積確認、問い合わせからタスクを作る
API連携	外部システムや別処理と同期する	会計、フォーム、BI、外部DBと連携する

ルックアップは、参照ではなくコピーです。

顧客マスタから住所をコピーしたあと、顧客マスタ側の住所が変わっても、コピー済みのレコードが自動で全部更新されるとは考えない方がよいです。

だから、コピーしてよい情報と、常に最新を表示したい情報を分けます。

ルックアップでコピーしやすい	コピーに注意が必要
申請時点の顧客名	現在の契約状態
申請時点の住所	最新担当者
商品名、単価の当時値	在庫数
部門名の当時値	現在の承認者

関連レコード一覧は、表示です。

顧客マスタに案件を表示することはできます。

しかし、表示しているだけなので、顧客マスタ側に案件データを持っているわけではありません。

集計や通知、処理の正本は、関連先のアプリにあります。

アプリアクションは、転記です。

便利ですが、転記後にどちらを更新するのかを決めないと、同じようなデータが複数アプリに残ります。

kintone公式ヘルプでは、アプリ間連携の方法として、ルックアップ、関連レコード一覧、アプリアクションが整理されています。

データベース設計では、この3つを「コピー」「表示」「転記」として分けて考えると、事故が減ります。

一覧・絞り込み・グラフの設計

データベースは、登録できるだけでは意味がありません。

見る人ごとに、必要な一覧を作る必要があります。

見る人	必要な一覧
担当者	自分の未対応、期限超過、差し戻し
管理者	全体の滞留、重複候補、未入力
経理	請求前確認、支払予定、証憑不足
営業	案件フェーズ別、次回アクション、受注予定
サポート	問い合わせ状態別、期限超過、再発

一覧を作る前に、フィールドを整えます。

ステータス、担当者、期限、部門、種別、金額、利用状態。

これらが構造化されていないと、一覧やグラフは作れません。

自由入力のメモ欄に「至急」「未対応」「佐藤さん確認中」と書いても、一覧では拾いにくいです。

グラフも同じです。

集計したいなら、集計軸をフィールドにします。

見たい集計	必要なフィールド
月別の案件数	受注予定月、登録月
担当者別の対応件数	担当者
部門別の申請金額	部門、金額
商品別の受注数	商品コード、数量
失注理由別の件数	失注理由

「あとで集計したい」情報は、最初から選択肢や数値として持たせます。

メモ欄に入れた情報は、後から集計できない前提で設計します。

権限・履歴・添付ファイルの扱い

kintoneをデータベースとして使うなら、権限設計もデータ設計の一部です。

誰でも見られる台帳。

部署ごとに見える範囲が違う台帳。

本人と上長だけが見られる申請。

管理部門だけが編集できるマスタ。

これらは、アプリを作った後で考えると苦しくなります。

対象	決めること
アプリ権限	誰が閲覧、追加、編集、削除できるか
レコード権限	部門、担当者、状態によって見える範囲を変えるか
フィールド権限	金額、個人情報、内部メモを誰に見せるか
プロセス管理	誰が次の状態へ進められるか
変更履歴	監査や確認でどこまで使うか

kintone公式ヘルプでは、アプリ、レコード、フィールドそれぞれにアクセス権を設定できることが説明されています。

kintoneヘルプ：アクセス権の設定

添付ファイルも、扱いを決めます。

添付フィールドに入れればファイルは保存できます。

しかし、正式版、下書き、差し替え、契約締結済み、証憑、請求書控えが混ざると、どれを見ればよいか分からなくなります。

ファイル	扱い
一時資料	レコード添付でよい場合が多い
正式な見積書	帳票出力やストレージ上の正式ファイルと紐づける
契約書	電子契約、契約管理、保管ルールを分ける
請求書・証憑	会計ソフトや証憑保管との責任範囲を決める
版管理が必要な資料	ファイル管理アプリや外部ストレージを検討する

変更履歴は便利ですが、業務履歴の代わりにはしません。

変更履歴は、フィールドがいつ変わったかを見るものです。

営業活動や問い合わせ対応の内容は、活動履歴や対応履歴としてレコード化した方が使いやすいです。

CSV/API/外部DB連携の境界

kintoneをデータベースとして使うと、必ず外部連携の話が出ます。

CSVで取り込む。

フォームから登録する。

会計ソフトへ渡す。

BIで集計する。

外部DBと同期する。

ここで大事なのは、連携方法の前に、正本と更新方向を決めることです。

連携	決めること
CSV取込	新規登録か更新か、キー列は何か
CSV出力	出力先で編集して戻すのか、参照だけか
フォーム連携	入力データをどのアプリに分けるか
会計連携	請求書、入金、会計処理はどちらが正本か
BI連携	分析用に整形するデータをどこで作るか
外部DB連携	双方向同期か、片方向同期か
API連携	エラー時の再実行、ログ、権限をどう持つか

双方向同期は、特に慎重にします。

kintoneでも外部DBでも同じ項目を編集できる状態にすると、どちらを信用するか分からなくなります。

たとえば、顧客住所をkintoneでも会計ソフトでも編集できるなら、どちらが正しい住所なのかを決める必要があります。

在庫数、入金状態、請求書番号、契約状態のように、他システムが正式台帳になるデータは、kintone側では参照や確認に留める方が安全なことがあります。

CSV/API連携では、「つなげる方法」より先に、正本、更新方向、キー、エラー時の戻し方を決めます。

外部DBへ逃がすべきケースもあります。

外部DBや専用システムを検討するケース	理由
大量データの高速検索が必要	kintoneの一覧や絞り込みでは重くなる可能性がある
複雑な集計や分析が中心	BIやDWHの方が向く
厳密なトランザクションが必要	更新整合性を外部DBで持つ方がよい
会計、請求、在庫引当の正式処理	専用システムを正本にするべき
多数の外部システムと同期する	連携基盤やAPI設計が必要になる

kintoneは、現場が使う業務データベースとしては強いです。

ただし、基幹DB、会計DB、分析DBのすべてを置き換える前提で設計しない方がよいです。

移行前に作る設計表

kintoneデータベースを作る前に、次の設計表を作ります。

項目	書くこと
現行Excel	ファイル名、シート名、更新者、利用者
データの種類	マスタ、取引、履歴、集計、添付、ログ
1レコードの意味	1社、1案件、1履歴、1申請など
正本	kintone、会計ソフト、外部DB、Excelのどこか
主キー	顧客コード、案件番号、外部IDなど
参照関係	ルックアップ、関連レコード、アクション
権限	閲覧、編集、削除、管理者
一覧	誰が何を見るか
連携	CSV、API、フォーム、帳票、会計
移行方法	新規登録、更新、重複統合、過去データ保管

この表があると、kintoneアプリを作る前に、分けるべきアプリが見えます。

また、移行対象から外すデータも決められます。

古いメモ、使っていない列、意味が曖昧なフラグ、誰も見ていない集計列。

これらをそのまま移すと、kintone側でもノイズになります。

移行時は、すべてをきれいに移すより、正本として必要なデータを決める方が重要です。

よくある失敗

kintoneをデータベースとして使うときの失敗は、機能不足よりも設計不足で起きます。

失敗	起きること	対策
Excelをそのまま1アプリ化する	メモ、履歴、マスタが混ざる	データ種類ごとに分ける
顧客名や商品名を自由入力する	表記揺れで集計できない	マスタとコードを作る
レコード番号だけで管理する	外部連携や移行で扱いづらい	業務上のキーを持つ
ルックアップを参照と誤解する	マスタ変更が反映されない	コピーする情報を限定する
関連レコードを正本にする	表示と実データが混ざる	関連先アプリを正本にする
CSV取込のキーがない	重複登録が増える	更新用キーと外部IDを持つ
添付ファイルを全部入れる	正式版が分からない	ファイルの役割を分ける
権限を後回しにする	見せてはいけない情報が見える	アプリ、レコード、フィールドで設計する
外部システムと双方向編集する	どちらが正しいか分からない	正本と更新方向を決める

kintoneは柔軟に作れるため、最初のアプリはすぐに作れます。

しかし、データベースとして長く使うなら、最初の柔軟さをそのまま運用に持ち込まない方がよいです。

自由入力を選択肢へ。

メモを履歴レコードへ。

表記名をコードへ。

Excelの見た目を一覧やグラフへ。

この変換が、kintoneデータベース設計です。

kintoneデータベースは、アプリ作成より前の分解で決まる

kintoneは、社内データベースとして十分に使えます。

ただし、Excelをそのまま移すだけでは、同じ問題が別の画面で起きるだけです。

最初に確認するのは、次の順番です。

1. 現行Excelの列を、マスタ、取引、履歴、集計、添付、ログに分ける
2. 1レコードの意味をアプリごとに決める
3. 顧客コード、案件番号、商品コード、外部IDなどのキーを決める
4. ルックアップ、関連レコード、アプリアクションをコピー、表示、転記として使い分ける
5. 一覧、グラフ、権限、変更履歴、添付ファイルの扱いを決める
6. CSV/API/外部DB連携では、正本と更新方向を決める
7. 移行しないデータ、別システムを正本にするデータを決める

データベース設計は、アプリを増やすことではありません。

業務で信用できるデータを、誰が、どこで、どう更新するかを決めることです。

Bitlightでは、Excel台帳の棚卸しから、kintoneのアプリ分割、マスタ設計、ルックアップ、関連レコード、権限、CSV/API連携まで、業務データベースとして設計できます。

既存のExcelやkintoneアプリが増えてきた場合は、まず「正本」「キー」「参照関係」の整理から始めるのが現実的です。

kintone在庫管理の設計方法はこちら
kintoneプロセス管理の設計方法はこちら