kintoneとSalesforce連携の設計方法｜顧客・案件データの正本を決める

kintoneとSalesforce連携は、営業部門と現場・管理部門の間でよく出てくるテーマです。

営業はSalesforceでリード、取引先、商談、活動を管理している。

一方で、受注後の作業、契約手続き、社内申請、納品準備、請求前確認、問い合わせ対応はkintoneで管理している。

この状態で、同じ顧客名、同じ案件名、同じ担当者、同じ金額を何度も入力している。

だから、kintoneとSalesforceを連携したい。

ここまでは自然です。

ただし、連携の設計を間違えると、次のような状態になります。

• Salesforceの取引先名とkintoneの顧客名が少しずつずれる
• Salesforceの商談とkintoneの案件が1対1なのか、1対多なのか分からない
• リードをSalesforceで取引先・取引先責任者・商談へ変換した後、kintone側の古い見込み客情報が残る
• kintone側で顧客名を直したら、Salesforceの営業CRMまで上書きしてしまう
• Salesforceで商談を失注にしたのに、kintone側の作業依頼が残る
• kintoneで契約後作業が完了したのに、Salesforceの商談や顧客ステータスへ戻らない
• 更新キーがメールアドレスだけで、担当者変更や共有メールアドレスに弱い
• 削除、統合、重複、名寄せのルールがない
• 連携エラーが営業にも管理部門にも通知されず、数日後に数字のずれとして見つかる

連携ツールを入れるだけでは、これらは解決しません。

むしろ、正本を決めないまま自動で同期すると、誤ったデータが早く広がります。

kintoneとSalesforce連携で最初に決めるべきなのは、連携ツールではなく、リード、取引先、商談、契約後作業、請求前データの正本です。

この記事では、kintoneとSalesforce連携を、ツール紹介ではなく、Salesforceを営業CRM、kintoneを周辺業務アプリとして使う前提で、データ責任、同期方向、更新キー、重複、削除、失敗通知、再実行まで含めて整理します。

kintone CRMの設計方法はこちら
kintone SFAの設計方法はこちら
kintoneデータ連携の設計方法はこちら
kintone API連携の設計方法はこちら

連携前に正本データを決める

kintoneとSalesforceを連携するときは、まず正本を決めます。

正本とは、業務上「この値が正式」と判断する場所です。

たとえば、営業CRMとしてSalesforceを使っているなら、取引先、取引先責任者、商談、営業フェーズ、受注確度はSalesforceが正本になりやすいです。

一方で、契約後の作業、社内申請、納品準備、請求前確認、顧客別の運用タスクはkintoneが正本になりやすいです。

データ	Salesforceを正本にしやすい	kintoneを正本にしやすい
リード	見込み客、流入元、営業割当	参照、受付補足
取引先	会社、顧客、親子関係、営業担当	社内管理用の補足、作業対象
取引先責任者	顧客側担当者、連絡先、役割	現場連絡先、納品窓口の補足
商談	金額、フェーズ、確度、クローズ予定日	受注後作業の起点、作業状態
活動履歴	営業活動、次回アクション	現場対応履歴、作業メモ
契約後作業	参照、進捗サマリ	タスク、担当、期限、チェック項目
請求前データ	受注金額、契約条件の参照	請求対象、検収、経理確認
連携ログ	参照リンク	実行結果、失敗、再実行、差戻し

正本が決まると、同期方向が決まります。

Salesforceの商談が受注になったら、kintoneに作業依頼を作る。

kintoneの作業状態が「完了」になったら、Salesforceへ完了日やリスク状態を戻す。

Salesforceの取引先名はkintoneに取り込むが、kintone側からは上書きしない。

kintoneの請求前確認はSalesforceに戻さず、営業が参照できるURLだけ持たせる。

このように、データごとに方向を分けます。

双方向同期は便利に見えますが、正本と更新責任が決まっていない顧客・案件データでは、上書き事故を広げる設計になりがちです。

Salesforceに置くべき営業データ

Salesforceを使っている会社では、営業活動の中心データはSalesforceに置く方が自然です。

特に、リード、取引先、取引先責任者、商談はSalesforce側のデータモデルに沿って管理します。

SalesforceのTrailheadでは、リードはまだ顧客になっていない見込み客、商談は評価を経て売上につながる見込みのある取引として説明されています。

また、リードを変換すると、Salesforceはリード情報から取引先、取引先責任者、必要に応じて商談を作る流れを持ちます。

Salesforce Trailhead：Track Potential Customers with Leads

この前提を無視して、kintone側にも同じ粒度のリード・取引先・商談を作ると、二重CRMになります。

Salesforceに置くべきデータは、次のように整理します。

Salesforce側データ	目的	kintoneへ連携する場合
リード	見込み客の受付、評価、営業割当	基本は連携しない。必要なら受付一覧だけ参照する
取引先	顧客企業、親会社、子会社、営業担当	Salesforce取引先IDと名称をkintoneへ持つ
取引先責任者	顧客側担当者、メール、電話、役割	作業や請求で必要な窓口だけ参照する
商談	金額、フェーズ、確度、受注予定日	受注、契約、作業開始のトリガーにする
活動	面談、電話、メール、次回予定	原則Salesforceで管理し、kintoneへ全量同期しない
商品・価格	商品、価格表、見積条件	作業・請求で必要な項目だけ抜き出す

Salesforceの営業データをkintoneへすべてコピーする必要はありません。

重要なのは、kintone側の業務に必要な最小限のID、名称、状態、金額、担当情報を渡すことです。

たとえば、kintoneの契約後作業アプリには、Salesforce取引先ID、Salesforce商談ID、商談名、受注金額、契約開始日、営業担当、Salesforce URLを持たせます。

これだけあれば、現場や管理部門は作業に必要な背景を確認できます。

一方で、商談フェーズや受注確度をkintoneから更新できるようにすると、営業管理の正本が壊れます。

営業判断に関わる項目はSalesforceに残します。

kintoneに置くべき周辺業務データ

kintoneに置くべきなのは、Salesforceの商談だけでは扱いにくい周辺業務です。

受注後の作業。

契約書の準備。

社内申請。

初期設定。

納品チェック。

請求前確認。

顧客別の運用対応。

問い合わせ対応。

営業CRMではなく、部門横断の作業台帳としてkintoneを使います。

kintone側アプリ	1レコードの意味	Salesforceとの関係
契約後作業	1商談から発生する作業	Salesforce商談IDを持つ
導入タスク	1つのタスク	作業レコードに紐づく
社内申請	1件の承認依頼	受注内容や顧客条件を参照する
請求前確認	1回の請求候補	商談金額、契約条件、検収状態を参照する
問い合わせ	1件の顧客対応	Salesforce取引先IDや取引先責任者IDを持つ
作業ログ	1回の対応履歴	Salesforceへ戻すかは選別する
連携ログ	1回の同期処理	成功、失敗、再実行、エラー理由を残す

この分け方にすると、Salesforceは営業の現在地、kintoneは受注後や社内処理の現在地になります。

kintone案件管理の設計方法はこちら
kintone売上管理の設計方法はこちら

kintone側にSalesforceの情報を持たせるときは、次の項目を基本にします。

項目	目的
Salesforce取引先ID	顧客の外部キーにする
Salesforce取引先責任者ID	窓口担当者を識別する
Salesforce商談ID	作業や申請の起点を識別する
Salesforce URL	営業情報をすぐ開けるようにする
最終同期日時	いつのSalesforce情報か分かるようにする
同期元項目	Salesforceから来た値を区別する
kintone正本項目	kintone側で更新する作業状態を分ける

kintone側で大事なのは、Salesforceの複製を作ることではなく、Salesforceの商談から派生する作業・申請・請求前確認を管理することです。

リード・取引先・商談の同期設計

kintoneとSalesforce連携で特に注意すべきなのは、リード、取引先、取引先責任者、商談の扱いです。

Salesforceでは、リードを商談へ進めるときに、取引先や取引先責任者へ変換する運用があります。

そのため、kintone側でリードをそのまま顧客マスタとして扱うと、後で重複しやすくなります。

同期設計では、次のように考えます。

データ	推奨する同期	理由
リード	原則Salesforce内で完結	変換前の見込み客をkintone顧客にしない
取引先	Salesforceからkintoneへ片方向	顧客の正式名称や親子関係は営業CRMで管理する
取引先責任者	必要な窓口だけkintoneへ片方向	全担当者を現場業務へ流すと管理が重くなる
商談	受注・特定フェーズでkintoneへ作成	すべての商談を作業対象にしない
作業状態	kintoneからSalesforceへ限定的に戻す	営業が進捗を見たい項目だけ戻す
請求前確認	Salesforceへ戻さないか、サマリだけ戻す	会計・管理側の処理を営業CRMへ広げすぎない

たとえば、商談フェーズが「受注」になったときだけ、kintoneに契約後作業レコードを作る。

Salesforce商談IDをkintoneの重複禁止項目にし、同じ商談から二重に作業レコードを作らない。

kintone側で作業担当、期限、チェック項目、請求前確認を進める。

作業完了日、リスク有無、請求準備完了フラグだけSalesforceへ戻す。

このくらいに絞ると、営業CRMと現場業務の境界が保てます。

逆に、次のような同期は慎重に扱います。

同期	危険な理由
Salesforceの全商談をkintoneへ同期	受注前の見込みまで現場作業に混ざる
kintoneからSalesforce商談金額を更新	営業予測やレポートの正本が崩れる
kintone顧客名でSalesforce取引先を上書き	表記ゆれや社内略称が正式CRMへ入る
リードをkintone顧客として登録	変換後の取引先・責任者と重複しやすい
削除を双方向で同期	誤削除や統合処理の影響が大きい

Salesforce側の営業データとkintone側の周辺業務データは、似ている項目が多いです。

だからこそ、「同じ項目名だから同期する」ではなく、「業務上どちらが直す項目か」で判断します。

Reckoner・Zapier・API連携の使い分け

kintoneとSalesforceをつなぐ方法は複数あります。

代表的には、連携サービス、ZapierなどのiPaaS、個別API連携があります。

Reckonerのユースケースでは、kintoneとSalesforceの接続、データ加工、差分抽出、ワークフロー作成を画面操作で構成する例が紹介されています。

Reckoner：kintoneとSalesforceを自動連携で顧客情報の一元管理をする方法

ZapierのkintoneとSalesforceの連携ページでは、kintoneとSalesforceを組み合わせたトリガーとアクションの自動処理を選べる形で案内されています。

Zapier：Kintone + Salesforce integrations

ただし、選ぶ基準は「有名なサービスか」ではありません。

同期の粒度、変換条件、エラー処理、再実行、監査ログ、保守担当で決めます。

方法	向いているケース	注意点
Reckonerなどのデータ連携サービス	定期同期、差分抽出、項目変換、複数データソース	正本設計とキー設計を先に決める
ZapierなどのiPaaS	単純なトリガー、少量のイベント連携、早期検証	大量処理、複雑な分岐、再実行管理は慎重に見る
kintone Webhook	kintone操作を外部へ通知	CSV読込や一部一括操作では通知されない条件がある
Salesforce Flow + 外部呼び出し	Salesforce側イベント起点	Salesforce管理者と変更管理が必要
個別API連携	大量同期、厳密な更新制御、独自エラー処理	認証、API制限、監視、保守が必要
CSV連携	初期移行、一時的な補正	継続運用の同期には向きにくい

kintone公式ヘルプでは、Webhookでレコード追加、編集、削除、コメント、ステータス更新などの操作を外部サービスへ送れることが説明されています。

一方で、Excel/CSV読込や複数レコードの一括操作ではWebhook通知が送信されない条件も案内されています。

kintoneヘルプ：Webhookを設定する

このため、kintone側のWebhookだけでSalesforce同期を設計すると、漏れる操作が出る可能性があります。

定期的な差分チェック、更新日時による再取得、連携ログとの照合を組み合わせます。

更新キー・重複・削除の扱い

kintoneとSalesforce連携では、更新キーが重要です。

更新キーとは、「このSalesforceレコードと、このkintoneレコードは同じ対象である」と判断するための項目です。

候補は複数あります。

キー	向いている使い方	注意点
Salesforce ID	Salesforceからkintoneへ連携する主キー	環境移行やサンドボックスでは扱いを分ける
Salesforce外部ID	外部システムからSalesforceへupsertするキー	Salesforce側で外部ID項目の設計が必要
kintoneレコード番号	kintone内の識別	Salesforce側から見ると意味が伝わりにくい
顧客コード	社内共通IDがある場合に強い	コード未整備の会社では導入が必要
メールアドレス	取引先責任者の候補キー	共有アドレス、変更、退職に弱い
会社名	名寄せ候補には使える	正式キーには弱い

Salesforce REST APIには、外部IDを使ってレコードを作成または更新するupsertの考え方があります。

Salesforce Developers：Insert or Update a Record Using an External ID

kintone REST APIでも、複数レコード更新ではレコード番号または重複禁止設定をしたテキスト・数値フィールドを更新キーにでき、upsertを使うと存在しない場合に追加できます。

Kintone Developer Program：Update Records

つまり、両方のシステムで「外部キー」をどう持つかが設計の中心になります。

おすすめは、kintone側に次のような項目を明示的に持たせることです。

kintone項目	役割
salesforce_account_id	Salesforce取引先ID
salesforce_contact_id	Salesforce取引先責任者ID
salesforce_opportunity_id	Salesforce商談ID
salesforce_url	Salesforce画面へのリンク
external_business_key	社内共通の顧客コードや契約コード
last_synced_at	最終同期日時
sync_source	最終更新元
sync_lock	手動修正中や差戻し中の同期停止

削除も重要です。

Salesforceで取引先を削除したからといって、kintoneの作業履歴まで削除してよいとは限りません。

kintoneで作業レコードを削除したからといって、Salesforce商談を削除してよいわけでもありません。

削除同期は、原則として物理削除ではなく、状態変更で扱います。

状態	設計
Salesforceで商談が失注	kintone側の未開始作業を取消候補にする
Salesforceで商談が統合	kintone側のSalesforce商談IDを統合先へ付け替えるか検討する
kintone作業が不要	kintone側で取消にし、Salesforceへサマリだけ戻す
顧客重複を発見	連携停止、名寄せ、ID付け替え、再同期の順に処理する
誤登録	連携ログを残し、削除ではなく無効化を基本にする

kintoneとSalesforce連携では、作成よりも、重複・統合・削除・再同期のルールを先に決めておく方が重要です。

失敗通知と再実行

連携は、必ず失敗します。

認証が切れる。

必須項目が不足する。

Salesforce側の入力規則に引っかかる。

kintone側の重複禁止に引っかかる。

項目型が変わる。

選択肢が足りない。

API制限に近づく。

担当者が権限を持っていない。

同じレコードが同時に更新される。

これらを想定せずに連携すると、エラーが出たときに現場が止まります。

kintone側には、連携ログアプリを用意します。

ログ項目	内容
実行日時	いつ連携したか
実行元	Salesforce、kintone、連携サービス、手動再実行
連携種別	取引先同期、商談取込、作業状態戻しなど
対象ID	Salesforce ID、kintoneレコード番号、外部キー
結果	成功、失敗、保留、再実行済み
エラー内容	必須項目不足、重複、権限、認証、制限など
再実行可否	そのまま再実行できるか、修正が必要か
対応担当	営業、管理、システム管理者
対応期限	いつまでに直すか

通知先も分けます。

エラー	通知先	対応
必須項目不足	入力担当、管理担当	対象レコードを修正して再実行
重複	データ管理者	名寄せ判断
認証切れ	システム管理者	接続再認証
API制限	システム管理者	実行間隔、件数、再試行を見直す
入力規則エラー	Salesforce管理者、業務担当	Salesforce側ルールと項目マッピングを確認
削除・統合	管理責任者	自動再実行せず手動判断

kintone Developer Programでは、REST APIの認証方法としてAPIトークン、OAuth 2.0、セッション認証などが説明されています。

特に外部アプリケーションからkintone APIを実行する場合、OAuth 2.0はユーザーの認証情報をアプリケーションに保存せず、スコープでアクセス範囲を制限できる方法として説明されています。

Kintone Developer Program：Authentication

本番運用では、接続情報を誰が管理するかも決めます。

個人ユーザーの認証で連携していると、退職、異動、権限変更、パスワード変更で連携が止まります。

連携専用ユーザー、OAuthクライアント、APIトークン、権限範囲、ローテーション手順を運用として持ちます。

Kintone Developer Program：How to Add OAuth Clients

よくある失敗

kintoneとSalesforce連携でよくある失敗を整理します。

失敗	原因	対策
顧客が二重登録される	会社名やメールだけで同一判定している	Salesforce ID、外部ID、顧客コードを持つ
Salesforceが上書きされる	kintoneから戻す項目を絞っていない	営業CRM項目はSalesforce正本にする
商談と作業の対応が分からない	Salesforce商談IDをkintoneに持っていない	1商談1作業か、1商談複数作業かを決める
リードが顧客化される	変換前データをkintone顧客にしている	リードは原則Salesforce内で扱う
受注前商談までkintoneへ流れる	連携条件が広すぎる	受注、契約準備、特定フェーズだけを対象にする
エラーに気づかない	連携ログと通知先がない	失敗通知、保留一覧、再実行担当を決める
削除で履歴が消える	双方向削除を許可している	無効化、取消、統合履歴で扱う
認証切れで止まる	個人認証に依存している	連携専用の認証管理と更新手順を作る
連携サービス設定が属人化する	設計書と変更履歴がない	項目マッピング、実行条件、変更履歴を残す

特に危ないのは、最初からすべてを双方向にすることです。

取引先、担当者、商談、作業、請求前確認には、それぞれ更新責任があります。

営業が責任を持つ項目をkintoneから自由に戻すと、営業レポートが信用できなくなります。

現場が責任を持つ作業状態をSalesforceから上書きすると、作業管理が信用できなくなります。

同期範囲は、広いほどよいわけではありません。

業務で必要な項目だけを、決めた方向に、ログを残して連携します。

実装前チェックリスト

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

チェック	確認内容
正本	リード、取引先、取引先責任者、商談、作業、請求前確認の正本を決めたか
同期方向	Salesforceからkintone、kintoneからSalesforce、参照だけを分けたか
連携条件	どのフェーズ、どの状態、どの項目変更で連携するか
更新キー	Salesforce ID、外部ID、顧客コード、kintone重複禁止項目を設計したか
項目マッピング	型、必須、選択肢、日付、金額、所有者を確認したか
リード変換	変換前リードをkintone顧客にしない設計か
商談と作業	1商談1作業か、1商談複数作業か
失注・取消	失注、取消、保留、再開時の扱いを決めたか
削除・統合	物理削除ではなく無効化や統合履歴で扱うか
エラー通知	誰に、何を、いつ通知するか
再実行	自動再試行、手動再実行、再実行禁止を分けたか
認証	APIトークン、OAuth、接続ユーザー、権限を管理できるか
変更管理	Salesforce項目変更、kintone項目変更、連携サービス設定変更を記録するか

このチェックをせずに連携を作ると、初期の動作確認では動いても、運用開始後に崩れます。

kintoneとSalesforce連携は、技術的にはいくつもの方法で実現できます。

しかし、実務で長く使えるかどうかは、ツールよりも、正本、同期方向、更新キー、失敗時対応で決まります。

Bitlightに相談できること

Bitlightでは、kintoneとSalesforce連携を、単なる自動同期ではなく、営業CRMと周辺業務アプリの責任分界として設計できます。

たとえば、次のような相談に対応できます。

• Salesforceのリード、取引先、取引先責任者、商談とkintoneアプリの対応整理
• 受注後作業、契約後作業、請求前確認、問い合わせ管理のkintoneアプリ設計
• Salesforce ID、外部ID、kintone重複禁止項目を使った更新キー設計
• Reckoner、Zapier、Webhook、個別API連携の使い分け
• 項目マッピング、型変換、選択肢、必須項目、所有者の整理
• 連携ログ、失敗通知、保留一覧、再実行フローの設計
• 削除、統合、失注、取消、名寄せの運用ルール作成
• 既存のSalesforce・kintoneデータを連携前に整理するデータ棚卸し

Salesforceを使っている会社にとって、kintoneはSalesforceの代替ではありません。

営業CRMでは扱いづらい、契約後、現場作業、社内申請、請求前確認を受け持つ業務アプリ基盤として使う方が自然です。

kintoneとSalesforce連携は、顧客データを丸ごと同期するのではなく、Salesforceの商談からkintoneの周辺業務へ、必要な情報だけを渡す設計にすると崩れにくくなります。