kintoneとリレーショナルデータベースの違い｜ルックアップ・関連レコードの設計

kintoneでは、複数のアプリを関連付けて使えます。

顧客マスタから案件へ顧客名を取得する。

顧客レコード上に、関連する案件や問い合わせを表示する。

案件レコードから見積確認レコードを作る。

フォーム、会計ソフト、外部データベースとAPIでつなぐ。

このように使うと、kintoneをリレーショナルデータベースのように見せることはできます。

ただし、kintoneのアプリ間連携は、RDBのテーブル結合と同じではありません。

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

• ルックアップを「常に最新を参照する機能」だと思っている
• 関連レコード一覧を「データを持っている場所」だと思っている
• アプリアクションで転記した後、どちらのアプリを更新すべきか決めていない
• 顧客名や商品名をキーにして、名称変更時に紐付けが崩れる
• マスタ変更が、過去の案件、見積、請求へどう反映されるか決まっていない
• 複数アプリを同時に更新する処理で、片方だけ成功した場合の戻し方がない
• 関連レコードで見えている情報を、集計や権限設計の正本として扱っている
• kintone内に持つべきデータと、外部DBや会計ソフトへ逃がすべきデータを分けていない

kintoneをRDBの代わりとして見ると、できないことが気になります。

一方で、kintoneを業務アプリの集合として見ると、使いどころは明確です。

マスタを持つ。

取引データを持つ。

履歴を表示する。

必要な値をコピーする。

別アプリへレコードを作る。

外部システムへ必要な範囲だけ渡す。

kintoneでリレーショナルデータベース風に設計するなら、RDBを再現するのではなく、「コピーする」「表示する」「転記する」「同期する」を分けることが重要です。

この記事では、kintoneとリレーショナルデータベースの違いを、ルックアップ、関連レコード、アプリアクション、API、マスタ変更、整合性、外部DB連携の観点で整理します。

kintoneデータベースの設計方法はこちら
kintone顧客管理の設計方法はこちら

先に結論：kintoneはRDBそのものではない

kintoneは、複数のアプリをつなげて業務データを扱えるツールです。

ただし、RDBそのものとして設計しない方がよいです。

観点	RDB	kintone
データ単位	テーブル	アプリ
1件のデータ	行	レコード
関連付け	主キー、外部キー	ルックアップ、関連レコード、条件一致
結合	SQLのJOIN	関連レコード表示、API、集計用アプリなど
値の取得	参照、結合	ルックアップでコピー
別テーブル作成	INSERT処理	アプリアクション、API、手動登録
整合性	制約、トランザクション	設計、権限、運用、カスタマイズで担保
画面	別途アプリケーションが必要	アプリ自体が入力画面・一覧・権限を持つ

RDBは、データ構造を厳密に作り、アプリケーション側で画面や処理を実装する考え方です。

kintoneは、アプリがデータの入れ物であり、同時に入力画面、一覧、コメント、通知、権限、プロセス管理も持ちます。

この違いは大きいです。

RDBのように正規化しすぎると、kintoneでは入力画面が分かりにくくなります。

逆に、kintoneの画面都合だけで1アプリにまとめすぎると、マスタ、取引、履歴が混ざります。

設計の基本は、RDBを再現することではなく、kintoneの標準機能で保守できる関係に落とすことです。

kintoneは「簡易RDB」ではなく、業務画面を持つアプリ同士を関連付けるツールとして設計した方が安定します。

アプリをテーブルとして考えるときの注意点

kintoneアプリをRDBのテーブルのように考えることはできます。

顧客マスタアプリ。

案件アプリ。

見積アプリ。

請求確認アプリ。

活動履歴アプリ。

このように分けると、データの責任範囲は見えやすくなります。

ただし、アプリはテーブル以上の意味を持ちます。

アプリごとに、フォーム、一覧、グラフ、コメント、通知、アクセス権、プロセス管理が存在します。

そのため、アプリを分けるときは、データ構造だけでなく、誰がどの画面で更新するかも考えます。

アプリ	1レコードの意味	主な更新者	関連先
顧客マスタ	1社、1顧客	営業管理、サポート管理	案件、問い合わせ、請求確認
案件	1商談、1相談	営業担当	顧客、活動履歴、見積
見積確認	1見積、1版	営業、管理者	案件、顧客、帳票
請求確認	1請求対象	経理、担当者	顧客、案件、会計
活動履歴	1回の接点	担当者	顧客、案件

この表で重要なのは、「1レコードの意味」と「更新者」です。

RDBでは、正規化の都合でテーブルを分けます。

kintoneでは、現場が入力し、確認し、通知を受け、一覧で見る単位としてアプリを分けます。

たとえば、顧客マスタと案件を分けるのは、1社に複数案件があるからだけではありません。

顧客情報を更新する人と、案件の進捗を更新する人が違うからです。

活動履歴を分けるのは、1案件に複数の接点があるからだけではありません。

対応した事実を後から時系列で追い、担当者別の活動を確認したいからです。

kintone案件管理の設計方法でも整理したように、案件の現在状態と活動履歴を分けると、進捗と経緯を混同しにくくなります。

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

kintoneのルックアップは、他アプリの値を取得してコピーする機能です。

kintone公式ヘルプでも、ルックアップを設定すると、他のアプリから必要なデータをコピーして取得できると説明されています。

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

この「コピー」が重要です。

たとえば、顧客マスタから案件アプリへ、顧客名、住所、担当部署を取得するとします。

取得時点では便利です。

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

公式ヘルプでも、参照先レコードに変更があっても、ルックアップで取得済みの値は維持され、再度取得すると最新値で上書きされる旨が注意点として説明されています。

つまり、ルックアップでコピーする項目は、慎重に選ぶ必要があります。

コピーしやすい項目	理由
申請時点の顧客名	当時の表示名として残せる
見積時点の商品名	過去見積の表示として固定できる
見積時点の単価	当時の条件として残す必要がある
申請時点の部門名	当時の所属で承認履歴を残せる

コピーに注意する項目	理由
現在の契約状態	最新状態を見たいなら関連表示や参照が向く
現在の担当者	異動や引き継ぎで変わる
在庫数	常に変動するためコピー値がすぐ古くなる
未請求残高	外部システムや集計の正本が必要になる

ルックアップを外部キーのように使うなら、キーの一意性が必要です。

顧客名をキーにすると、名称変更や表記揺れに弱いです。

商品名をキーにすると、商品名変更で崩れます。

顧客コード、商品コード、案件番号、外部IDなど、変わりにくいキーを持たせます。

ルックアップは最新値の参照ではなく、取得時点の値をコピーする機能です。コピーして固定したい項目と、常に最新表示したい項目を分けます。

関連レコードはデータを持たず、条件に合うレコードを表示する

関連レコード一覧は、他アプリや同じアプリのレコードを、条件に合う一覧として表示する機能です。

kintone公式ヘルプでは、関連レコード一覧フィールドを配置すると、設定したアプリの中で条件に一致したレコードを一覧で表示できると説明されています。

kintoneヘルプ：関連レコード一覧

関連レコードは、データをコピーしません。

顧客レコード上に案件一覧を表示しても、案件データは案件アプリにあります。

顧客レコード上に問い合わせ履歴を表示しても、問い合わせデータは問い合わせアプリにあります。

この性質を理解すると、使い分けが分かりやすくなります。

使い方	向いている理由
顧客レコード上に案件を表示	顧客に紐づく案件を一覧で見られる
顧客レコード上に問い合わせを表示	過去対応を確認できる
案件レコード上に活動履歴を表示	商談の接点を時系列で見られる
商品レコード上に受注明細を表示	商品別の発生履歴を見られる

ただし、関連レコードは「見えている」だけです。

関連レコード一覧に表示された値を、そのまま顧客マスタの正本にしたり、レコード権限の前提にしたりすると危険です。

集計したい場合も、表示しているだけで十分か、別途集計用のアプリやグラフ、外部BIが必要かを考えます。

目的	関連レコードで足りるか
詳細画面で履歴を確認する	足りることが多い
最新の問い合わせを確認する	条件や表示順の設計が必要
月別に集計する	グラフや集計用データを検討する
レコード更新のトリガーにする	APIやカスタマイズを検討する
大量データを横断検索する	外部DBやBIも比較する

関連レコードは、画面上で関係を見せるには強いです。

しかし、データを同期する機能ではありません。

同期したいのか、表示したいだけなのかを先に決めます。

アプリアクションとAPI連携の使いどころ

アプリアクションは、開いているレコードのデータをコピーして、同じアプリや別アプリに新しいレコードを作成する機能です。

kintoneヘルプ：アプリアクションでできること

たとえば、次のような使い方があります。

元アプリ	アクション	作成先
顧客	案件を作成	案件アプリ
案件	見積確認を作成	見積確認アプリ
問い合わせ	タスクを作成	タスク管理アプリ
契約確認	請求確認を作成	請求確認アプリ

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

転記後に元アプリを変更しても、作成済みレコードが自動で追従するとは限りません。

したがって、転記する項目は「作成時点で固定してよいもの」に寄せます。

転記しやすい項目	注意が必要な項目
顧客コード	最新担当者
案件番号	現在ステータス
見積時点の金額	在庫数
申請時点の部門	請求残高
原本URL	最新契約状態

API連携は、より柔軟です。

フォーム入力を複数アプリに分けて登録する。

会計ソフトへ請求対象を渡す。

外部DBから参照用データを取り込む。

BIへ分析用データを送る。

ただし、API連携では、RDBのように複数テーブルを一括更新して必ず整合させる発想をそのまま持ち込まない方がよいです。

複数アプリを更新するなら、どの処理が成功し、どの処理が失敗したかをログに残します。

失敗時に再実行できるようにします。

必要なら、連携ログアプリを作ります。

API連携で決めること	例
正本	顧客情報はkintone、請求書は会計ソフト
更新方向	kintoneから会計へ片方向、外部DBから参照だけ
キー	顧客コード、案件番号、外部ID
エラー処理	失敗ログ、再実行、手動修正
権限	APIトークン、連携ユーザー、操作範囲

アプリアクションは現場操作に向いています。

API連携は自動処理に向いています。

どちらも「コピーや登録を発生させる」ため、更新責任を決めずに使うとデータが分岐します。

マスタ変更時に何が自動反映されるか

kintoneでRDB風に設計するとき、最も誤解されやすいのがマスタ変更です。

顧客マスタの住所を変更した。

商品マスタの単価を変更した。

部門マスタの責任者を変更した。

このとき、過去の案件、見積、申請、請求確認にどう反映されるかを決めておく必要があります。

変更内容	過去データへ反映すべきか
顧客の正式名称変更	表示上は最新にしたい場合がある
見積時点の単価	過去見積は変更しない方がよい
商品の現在販売状態	最新を見たい場合が多い
申請時点の部門	承認履歴として固定した方がよい
現在の担当者	最新担当を表示したい場合がある
請求先住所	請求タイミングに応じて判断が必要

ポイントは、「最新であるべき情報」と「当時値として残すべき情報」を分けることです。

情報の性質	設計
当時値を残す	ルックアップでコピーして固定する
最新を見たい	関連レコードやマスタ参照で見る
手続き時点で確定する	転記して証跡として残す
変わるたびに同期したい	API、プラグイン、外部DBを検討する

たとえば、見積書の単価は、見積提出時点の値を固定する必要があります。

商品マスタの単価が上がったからといって、過去の見積金額まで勝手に変わると困ります。

一方で、顧客マスタ上で現在の担当営業を確認したい場合は、常に最新値を見たいことがあります。

この違いを設計表に書きます。

項目	当時値か最新値か	実装方針
見積単価	当時値	ルックアップでコピー
見積提出先住所	当時値	見積作成時にコピー
顧客の現在担当	最新値	顧客マスタを参照
案件の活動履歴	最新一覧	関連レコードで表示
請求状態	会計側の最新	会計ソフトを正本にして連携

マスタ変更時の設計は、「自動反映したいか」ではなく、「過去データを守るべきか、最新値を見たいか」で決めます。

トランザクションと整合性の限界

RDBでは、複数の更新をひとまとまりの処理として扱い、途中で失敗したら全体を戻す設計ができます。

kintoneで複数アプリを扱う場合、この感覚をそのまま前提にしない方がよいです。

たとえば、フォームから次の3つを同時に作るとします。

顧客マスタ。

案件。

問い合わせ。

1件目は登録できたが、2件目で失敗した。

顧客は既にあるが、案件が作られていない。

問い合わせだけ重複した。

このような状態を想定する必要があります。

処理	整合性の考え方
複数アプリ登録	連携ログを残し、失敗時に再実行できるようにする
外部DB同期	同期済みID、最終同期日時、エラー内容を持つ
会計連携	会計側の登録結果をkintoneへ戻す
CSV取込	更新キー、取込ログ、重複候補一覧を作る
手動修正	誰が、いつ、何を直したかを残す

整合性を厳密に要求する業務では、kintoneだけで抱え込まない判断が必要です。

在庫引当。

入金消込。

会計仕訳。

大量明細の集計。

これらは、専用システムや外部DBを正本にした方がよいことがあります。

kintone側では、確認、申請、承認、ステータス管理、例外対応、現場入力を担う。

外部システム側では、厳密な処理や大量データ処理を担う。

この分担にすると、無理にkintoneをRDB化しなくて済みます。

外部DBへ逃がすべきケース

kintoneで十分なケースと、外部DBへ逃がすべきケースを分けます。

kintoneで十分なケース	理由
顧客、案件、問い合わせを現場で更新する	入力画面、一覧、コメント、通知が使いやすい
Excel台帳を共有データにする	最新版、権限、履歴を整えやすい
小〜中規模の業務アプリを作る	現場に合わせて変更しやすい
承認や確認が中心	プロセス管理と通知を使える
関連情報を画面で見たい	関連レコードやルックアップが使える

外部DBや専用システムを検討するケース	理由
大量データを高速に検索・結合したい	kintone画面だけでは重くなる可能性がある
複雑なJOINや集計が多い	BI、DWH、RDBの方が向く
複数テーブル更新の整合性が厳しい	トランザクション設計が必要
会計、在庫、請求の正式処理	専用システムを正本にすべき
外部サービスと多数同期する	連携基盤や外部DBを挟む方が管理しやすい

kintoneの強みは、現場が使う画面と業務フローをすばやく作れることです。

外部DBの強みは、厳密なデータ構造、複雑な検索、集計、システム間連携です。

どちらが上という話ではありません。

正本にするデータと、現場で扱うデータを分ける話です。

kintone在庫管理の設計方法でも触れたように、在庫数量や引当のように整合性が重要なデータは、業務の重さに応じて専用システムとの役割分担を考える必要があります。

kintoneで十分なケース

kintoneで十分なケースも多くあります。

特に、次の条件ならkintoneは向いています。

条件	kintoneで設計しやすい理由
現場が入力する	フォーム、一覧、コメント、通知が揃っている
関連情報を画面で確認したい	関連レコードで履歴を見せられる
マスタから値を取得したい	ルックアップで入力ミスを減らせる
申請や承認を含む	プロセス管理と作業者を使える
Excelから段階移行したい	CSV取込や一覧で始めやすい
業務ごとに権限を分けたい	アプリ、レコード、フィールド権限を設計できる

たとえば、顧客マスタ、案件、活動履歴、問い合わせ、契約確認をつなぐ程度なら、kintoneで十分に設計できます。

RDBのように完全な正規化を目指すより、現場が入力しやすく、一覧で確認しやすく、必要な履歴が追える構成にする方が現実的です。

ただし、kintoneで十分なケースでも、次の表は作ります。

表	書くこと
アプリ関係表	どのアプリがどのアプリを参照するか
キー設計表	顧客コード、案件番号、外部IDなど
コピー項目表	ルックアップで何をコピーするか
表示項目表	関連レコードで何を表示するか
転記項目表	アプリアクションで何を作成するか
連携表	API、CSV、会計、外部DBとの更新方向

この表があれば、kintoneをRDBのように作りすぎず、業務で必要な関係だけを保てます。

kintoneのリレーショナル設計は、機能名ではなく役割で分ける

kintoneでリレーショナルデータベース風に設計するときは、機能名から考えない方がよいです。

先に、データの関係を役割で分けます。

1. マスタとして正本にするデータを決める
2. 取引や履歴として発生するデータを分ける
3. コピーして固定する項目を決める
4. 画面上で表示するだけの関連情報を決める
5. 別アプリへ転記して作成するレコードを決める
6. APIや外部DBで同期するデータを決める
7. マスタ変更時に、過去データを守るか最新値へ更新するかを決める

そのうえで、ルックアップ、関連レコード、アプリアクション、APIを選びます。

したいこと	使う機能
マスタから値を取得して固定したい	ルックアップ
関連する履歴を画面で見たい	関連レコード一覧
開いているレコードから別レコードを作りたい	アプリアクション
複数アプリや外部システムと同期したい	API、連携サービス
厳密な整合性や大量集計が必要	外部DB、専用システム

kintoneは、RDBを置き換えるためだけのものではありません。

現場が使う入力画面、一覧、通知、コメント、承認まで含めて、業務データを扱う場所です。

Bitlightでは、kintoneのアプリ間連携を、ルックアップ、関連レコード、アプリアクション、API、外部DBの境界まで含めて設計できます。

既存アプリが増えて関係が分かりにくくなっている場合は、まず「コピー」「表示」「転記」「同期」の棚卸しから始めるのが現実的です。

kintoneデータベースの設計方法はこちら
kintoneプロセス管理の設計方法はこちら