kintone連携の設計方法｜アプリ間・外部SaaS・APIを使い分ける構成

kintone連携という言葉は広いです。

顧客マスタを案件アプリで参照したい。

案件から見積アプリへ情報を転記したい。

外部フォームからkintoneへ問い合わせを登録したい。

kintoneのデータを帳票やCSVで外へ出したい。

GoogleスプレッドシートやExcelとつなぎたい。

会計、販売管理、CRM、MA、チャット、メール配信とつなぎたい。

レコード追加やステータス変更をきっかけに外部へ通知したい。

kintoneのデータをBIや集計基盤へ渡したい。

こうした要望はすべて「kintone連携」と呼ばれます。

ただし、同じ連携でも設計はまったく違います。

アプリ間で値をコピーするだけなら、ルックアップで足りるかもしれません。

関連する履歴を見たいだけなら、関連レコード一覧で十分なことがあります。

別アプリへ手動で転記するなら、アプリアクションが合うことがあります。

外部入力や帳票出力なら、連携サービスが早い場合があります。

複数SaaSをまたいで同期するなら、API、Webhook、iPaaS、個別開発を検討します。

問題は、手段を先に選ぶことです。

よくある失敗は、次のような状態です。

マスタをコピーしたいだけなのに、双方向同期を作ってしまう。

外部フォームから登録できるが、重複や必須項目の検証がない。

帳票出力はできるが、どの状態のレコードを正式に出してよいか決まっていない。

Webhookで通知しているが、失敗時の再送やログ確認が運用に入っていない。

会計システムと連携したが、請求金額の正本がどちらか分からない。

APIトークンの権限が広く、不要なアプリまで読める。

連携処理が途中で止まり、どこまで成功したか追えない。

kintone連携で最初に決めるべきなのは、「何とつなぐか」ではなく、「入力・出力・同期・通知・集計のどの目的でつなぐか」です。

この記事では、kintone連携を、標準機能、連携サービス、REST API、Webhook、iPaaSの一覧ではなく、業務目的、正本データ、同期方向、更新キー、権限、失敗時の再実行、監視ログまで含めて整理します。

kintoneデータベース設計はこちら
kintone API制限の設計方法はこちら
kintoneバックアップ設計はこちら

連携はツール選定より業務目的から決める

kintone連携を考えるときは、まず目的を分けます。

連携手段の名前から考えると、過剰な構成になりやすいです。

連携目的	例	最初に決めること
入力	フォーム、CSV、スプレッドシート、外部SaaSから登録	入力元、検証、重複防止
出力	帳票、CSV、社外共有、外部提出	出してよい状態、項目、権限
同期	顧客、商品、案件、請求データの同期	正本、同期方向、更新キー
通知	承認、差戻し、変更、異常検知	きっかけ、通知先、失敗時対応
集計	月報、BI、複数アプリ集計	集計元、粒度、更新頻度
バックアップ	更新前退避、監査提出、復旧	取得範囲、保管先、戻し方

この分類をせずに「kintoneと連携したい」とだけ考えると、次のような判断ミスが起きます。

表示だけでよいデータをコピーしてしまう。

一度だけの移行に、常時同期の仕組みを作ってしまう。

人が確認すべき承認処理まで自動で外へ流してしまう。

集計用データを正本のように更新してしまう。

通知だけでよい処理に、重いAPI連携を作ってしまう。

まず、連携を目的別に分けます。

そのうえで、標準機能で足りるか、連携サービスが合うか、APIやWebhookが必要かを判断します。

連携方式は目的の後に選びます。入力、出力、同期、通知、集計を分けるだけで、標準機能で済む範囲と開発が必要な範囲が見えます。

入力・出力・同期・通知・集計に分ける

連携目的ごとに、設計する項目を整理します。

入力連携

入力連携は、kintoneの外からデータを受ける連携です。

フォーム、CSV、Excel、スプレッドシート、外部SaaS、基幹システムなどが入力元になります。

入力元	設計すること
Webフォーム	必須項目、重複、添付、確認者
CSV/Excel	更新キー、文字コード、項目マッピング
スプレッドシート	状態列、更新日時、失敗行
外部SaaS	認証、項目対応、同期タイミング
基幹システム	正本、締め処理、再実行

入力連携では、何でも受け入れないことが重要です。

kintoneへ登録する前に、必須、型、選択肢、重複、添付ファイル、担当者、対象期間を確認します。

kintone CSVインポートの設計方法はこちら
kintoneとスプレッドシート連携の設計方法はこちら

出力連携

出力連携は、kintoneのデータを外へ出す連携です。

帳票、CSV、Excel、社外共有、BI、外部システム投入などがあります。

出力先	設計すること
CSV	出力項目、文字コード、先頭ゼロ
Excel帳票	出力条件、版、再発行
PDF/帳票	承認後だけ出すか、保存先
社外共有	出してよい列、閲覧期限
BI/集計基盤	取得条件、更新頻度、列定義

出力連携では、出してよい状態を決めます。

下書き、承認前、差戻し中、締め後、取消済みを同じように出すと、外部側の判断を誤ります。

kintone CSV出力の設計方法はこちら
kintone帳票出力の設計方法はこちら

同期連携

同期連携は、kintoneと外部システム、または複数アプリの間でデータをそろえる連携です。

同期では、正本を決めます。

データ	正本候補	注意点
顧客マスタ	kintone、CRM、販売管理	重複、住所変更、担当変更
商品マスタ	販売管理、会計、kintone	単価、税区分、廃止商品
案件	kintone、CRM	状態、担当、見積金額
請求	会計、販売管理、kintone	締め後更新、請求番号
対応履歴	kintone、CRM	追加型か更新型か

正本が決まらないまま双方向にすると、最後に更新した値が残るだけの仕組みになります。

業務上の正しさとは別です。

通知連携

通知連携は、kintoneで起きた変化を外部へ知らせる連携です。

承認依頼、差戻し、担当変更、レコード追加、エラー検知、期限超過などがあります。

通知は、データ同期とは分けます。

通知は「気づかせる」ための連携です。

通知を受けた後に、外部側でデータを更新するなら、別途同期設計が必要です。

kintone通知設計はこちら

集計・バックアップ連携

集計やバックアップは、正本データを外へ渡す連携です。

月報、売上集計、監査提出、更新前退避、日次バックアップなどがあります。

用途	設計すること
月報	集計元、締め日、更新頻度
BI連携	取得条件、列定義、権限
更新前退避	対象レコード、保存先、復元方法
監査提出	出力者、日時、版、保管
障害時復旧	戻す単位、更新前後の差分

バックアップは、ファイルを出すだけでは足りません。

戻し方まで決めておきます。

kintoneバックアップ設計はこちら

kintone標準のアプリ間連携

kintone内の複数アプリをつなぐだけなら、まず標準機能を見ます。

kintoneヘルプでは、アプリ間連携として、ルックアップ、アプリアクション、関連レコード一覧が説明されています。

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

それぞれの役割は違います。

機能	向いていること	注意点
ルックアップ	マスタから値をコピーする	コピー後にマスタが変わっても過去レコードは自動更新されない
関連レコード一覧	紐づく別アプリのレコードを表示する	表示であり、値を保存するわけではない
アプリアクション	レコード内容を別アプリへ手動転記する	実行者が押す操作。自動同期ではない

たとえば、顧客マスタと案件アプリをつなぐ場合を考えます。

顧客番号を選んだ時点の顧客名や住所を案件へコピーしたいなら、ルックアップが合います。

その顧客に紐づく過去案件を案件画面に表示したいなら、関連レコード一覧が合います。

案件から見積アプリへ情報を転記したいなら、アプリアクションが合います。

この3つを混ぜて考えると、運用が崩れます。

やりたいこと	使う候補
マスタ値をその時点で保存したい	ルックアップ
紐づく履歴を見たい	関連レコード一覧
別アプリへ手動でレコードを作りたい	アプリアクション
マスタ変更を既存レコードへ反映したい	API、プラグイン、運用手順
複数アプリを集計したい	集計アプリ、連携サービス、API

標準機能のアプリ間連携は、コピー、表示、手動転記を分けて使います。自動同期の代わりとして扱うと、マスタ更新や過去値保持で混乱します。

連携サービスで済むケース

外部入力、帳票、メール、集計、バックアップなどは、連携サービスで済むことがあります。

たとえば、外部フォーム、外部公開ビュー、帳票出力、メール送信、集計、バックアップなどです。

トヨクモのkintone連携サービスでは、FormBridge、kViewer、kMailer、PrintCreator、DataCollect、kBackupなど、kintone周辺の入力、閲覧、メール、帳票、集計、バックアップに関わるサービスが紹介されています。

トヨクモのkintone連携サービス

連携サービスが向くのは、次のようなケースです。

ケース	理由
外部フォームから登録したい	画面、入力制御、添付、通知を早く作れる
社外に一部データを見せたい	kintoneユーザーを増やさず閲覧画面を作れる
帳票を出したい	レイアウト、PDF、Excel出力を作りやすい
メール送信したい	宛先、テンプレート、送信履歴を扱える
複数アプリを集計したい	標準グラフより柔軟な集計ができる
バックアップしたい	退避、復元、保管の運用に乗せやすい

連携サービスを使う場合でも、設計は必要です。

設計項目	決めること
正本	kintoneか、外部サービスか
対象項目	どのフィールドを出す、受けるか
権限	誰が閲覧、登録、送信できるか
実行条件	どの状態のレコードを対象にするか
ログ	登録、出力、送信、失敗を追えるか
戻し方	誤登録や誤送信時にどう戻すか

連携サービスは、実装を短くできることがあります。

ただし、業務設計を省略できるわけではありません。

API・Webhook・iPaaSが必要なケース

標準機能や連携サービスで足りない場合は、REST API、Webhook、iPaaS、個別開発を検討します。

Kintone Developer ProgramのREST API概要では、kintone REST APIがアプリレコードの作成、取得、更新、削除や、アプリ設定、スペース操作などを扱えることが説明されています。

Kintone Developer Program：Kintone REST API Overview

kintoneヘルプの外部サービス連携カテゴリでは、Microsoft Power Automateなどとの連携に必要な設定、OAuthクライアント、APIトークン、Webhookの送信制御などが整理されています。

kintoneヘルプ：外部サービスとの連携

APIやWebhookが必要になるのは、次のようなケースです。

ケース	使う候補	設計すること
外部SaaSから定期取得する	API、iPaaS	認証、差分条件、件数制御
kintone更新を外部へ通知する	Webhook、iPaaS	通知条件、失敗時の再送
会計や販売管理へ請求データを渡す	API、個別開発	正本、締め処理、二重送信
複数SaaSをまたぐ処理	iPaaS、個別開発	処理順、失敗時の戻し方
大量データを集計基盤へ渡す	API、ETL	バッチ、差分、監視
画面操作と連動して登録する	JavaScript、REST API	権限、入力制御、エラー表示

Webhookは、きっかけを外へ送る仕組みです。

Webhookを設定しただけでは、外部側の処理成功までは保証されません。

外部側で受け取り、処理し、失敗時に通知し、再実行する仕組みが必要です。

iPaaSを使う場合も同じです。

フローを作るだけでなく、失敗通知、再実行、認証切れ、API制限、担当者変更を運用に入れます。

正本データと同期方向

連携で最も重要なのは、正本データです。

正本とは、業務上の正式な値として扱う場所です。

データ	kintoneを正本にしやすいケース	外部を正本にしやすいケース
顧客情報	営業・対応履歴をkintoneで見る	CRMや販売管理が正式顧客台帳
商品情報	小規模な商品マスタ	販売管理やECが商品マスタ
案件	kintoneで進捗と承認を見る	CRMが商談管理の中心
見積	kintoneで見積作成・承認する	販売管理が見積番号を採番
請求	kintoneで請求前確認をする	会計システムが請求・入金の正本
対応履歴	kintoneで社内対応を追う	CRMやヘルプデスクが正本

正本が決まったら、同期方向を決めます。

同期方向	向いているケース	注意点
kintoneから外部へ片方向	帳票、通知、集計、外部提出	外部側で手修正しない
外部からkintoneへ片方向	フォーム、基幹マスタ、外部申請	取込検証と重複防止が必要
双方向	両方で更新が必要な限定項目	競合、更新責任、ログが必須
手動転記	人が確認してから進める業務	押し忘れ、転記ミスを防ぐ

双方向同期は便利に見えます。

しかし、同じ項目を複数画面から更新できる状態にするため、競合が起きます。

双方向にする場合は、対象項目をかなり絞ります。

更新日時、更新者、更新キー、締め状態、承認状態を見て、上書きしてよいか判断します。

kintone Excel連携の設計方法はこちら
kintoneとスプレッドシート連携の設計方法はこちら

失敗時の再実行と監視ログ

連携は、成功する前提だけで設計しない方がよいです。

連携では、必ず失敗が起きます。

外部SaaSの認証が切れる。

API制限に当たる。

必須項目が空欄になる。

選択肢にない値が来る。

同じ更新キーが重複する。

外部側の仕様変更で項目名が変わる。

Webhook受信側が一時的に落ちる。

締め後のデータを更新しようとする。

失敗時に必要なのは、原因が分かり、必要な範囲だけ再実行できることです。

ログ項目	内容
実行ID	1回の処理を識別する
実行日時	開始、終了、処理時間
連携元、連携先	どのアプリ、どの外部サービスか
対象件数	成功、失敗、スキップ
更新キー	どのレコードか
エラー理由	APIエラー、入力不備、競合など
再実行可否	そのまま再実行できるか、修正が必要か
実行者	手動実行者、トリガー、連携アカウント

再実行は、全件ではなく失敗分だけ処理できるようにします。

全件を再実行すると、成功済みの登録が重複したり、正しい更新をもう一度上書きしたりします。

また、連携前の退避も必要です。

一括更新や外部からの戻し込みを行う前に、対象レコードをCSVで出しておくと、失敗時に戻しやすくなります。

kintoneバックアップ設計はこちら

連携パターン別の設計例

ここでは、よくある3つのパターンで整理します。

顧客マスタを案件アプリで使う

これはkintone内のアプリ間連携です。

項目	設計
正本	顧客マスタ
案件側	顧客番号をキーにルックアップ
表示	過去案件は関連レコード一覧で表示
過去値	案件作成時点の顧客名、住所を保持するか決める
マスタ更新	既存案件へ反映するか、しないかを決める

顧客住所が変わったとき、過去の見積や請求に新住所を反映するかは業務判断です。

自動で全部更新する前に、過去値保持のルールを決めます。

外部フォームから問い合わせを登録する

外部入力の連携です。

項目	設計
入力元	外部フォーム
登録先	問い合わせアプリ
検証	必須、メール形式、添付、重複
通知	担当部署、受付確認
後続処理	ステータス、担当者、期限
ログ	登録日時、フォームID、失敗理由

フォームから登録できるだけでは不十分です。

登録後に誰が対応するか、重複問い合わせをどう扱うか、個人情報を誰が見られるかまで設計します。

kintoneワークフロー設計はこちら

請求データを会計システムへ渡す

外部SaaS連携の中でも注意が必要なパターンです。

項目	設計
正本	会計システムか、kintoneか
連携タイミング	承認後、締め後、請求確定後
更新キー	請求番号、取引先コード、対象月
二重送信防止	送信済みフラグ、外部ID
エラー処理	失敗理由、修正担当、再送
戻し方	取消、再発行、差し替え

請求や会計は、締め後更新が問題になりやすいです。

kintoneで作った請求データを会計へ渡すのか、会計が確定した情報をkintoneへ戻すのかを先に決めます。

よくある失敗

kintone連携でよくある失敗をまとめます。

失敗	起きること	対処
目的を分けずに連携する	過剰な双方向同期になる	入力、出力、同期、通知、集計に分ける
正本が決まっていない	どちらの値が正しいか分からない	データ種別ごとに正本を決める
標準機能を自動同期扱いする	ルックアップや関連レコードの役割を誤る	コピー、表示、転記を分ける
APIトークン権限が広い	不要なアプリや操作まで許可される	必要最小限にする
Webhookを送るだけ	外部側の失敗に気づけない	受信ログ、失敗通知、再実行を作る
全件再実行する	重複登録や上書きが起きる	失敗分だけ再実行する
更新前退避がない	誤更新を戻せない	対象レコードを事前に退避する
担当者依存の連携	異動や退職で止まる	連携アカウントと運用責任を決める
外部仕様変更に弱い	項目名や認証変更で止まる	監視ログと保守窓口を決める

特に危ないのは、「つなげば自動で整う」と考えることです。

連携は、正しくないデータも速く移動させます。

だからこそ、正本、更新キー、権限、ログ、再実行を先に決めます。

実装前チェックリスト

kintone連携を作る前に、次を確認します。

チェック	内容
目的	入力、出力、同期、通知、集計、バックアップのどれか
正本	kintone、外部SaaS、基幹システムのどこか
同期方向	片方向か、双方向か
標準機能	ルックアップ、関連レコード、アプリアクションで足りるか
連携サービス	入力、出力、帳票、集計、バックアップで使えるか
API	必要な操作は取得、追加、更新、削除のどれか
Webhook	何をきっかけに外部へ通知するか
更新キー	どの値で同じレコードを判定するか
権限	アプリ、レコード、フィールド、APIトークンの範囲
ログ	実行ID、件数、失敗理由、外部IDを残すか
再実行	失敗分だけ再実行できるか
退避	更新前CSVやバックアップがあるか
保守	認証切れ、仕様変更、担当者変更に対応できるか

このチェックが埋まれば、連携方式は選びやすくなります。

標準機能で足りるなら、無理にAPIを使わない。

連携サービスで運用できるなら、個別開発を増やしすぎない。

APIやWebhookが必要なら、監視ログと再実行を最初から入れる。

この順番で考えます。

Bitlightに相談できること

Bitlightでは、kintone連携を、ツール一覧から選ぶのではなく、業務データの流れとして設計できます。

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

入力、出力、同期、通知、集計、バックアップの目的を分ける。

kintone標準機能で済むアプリ間連携を整理する。

連携サービスで早く作る範囲と、個別API連携が必要な範囲を分ける。

正本データ、同期方向、更新キー、過去値保持を設計する。

Webhook、iPaaS、外部SaaS連携の失敗通知と再実行を作る。

APIトークン、アプリ権限、フィールド権限を必要最小限にする。

更新前退避、監視ログ、運用責任者まで含めて設計する。

kintone連携は、単に別のサービスとつなぐ作業ではありません。

業務データが、どこから入り、どこで正式値になり、どこへ出て、失敗したときにどこから戻すかを決める作業です。

そこまで決めると、標準機能、連携サービス、API、Webhook、iPaaSを無理なく使い分けられます。