この記事の結論

kintone と Pipedrive をつなぐとき、最初に決めるのは手段ではありません。どちらに何を 持たせるかという境界です。判断の軸は1つで、顧客に接する業務か、社内で完結する業務かです。決めずにつなぐと、両方に同じ顧客が別表記で増え、 どちらが正しいかを言えなくなります。境界が決まっていれば、同期する項目は数個に収まります。

なお、両社が公式に用意した連携コネクタはありません。API か iPaaS か CSV のいずれかで、 自分たちの手でつなぐことになります。だからこそ、つなぐ範囲を小さく設計できたかどうかが、 そのまま運用コストの差になります。

この記事でわかること

• つなぐ手段は3系統あり、費用のかかり方と、止まったときの直し方が違うこと

• kintone のどのアプリを Pipedrive のどのデータに対応させるか

• 片方向から始める理由と、双方向が必要になる範囲

• 突合キーに何を使うか（会社名では合わない理由）

• 重複を増やさないために、つなぐ前に片付ける順序

kintone と Pipedrive の役割 — 境界は「顧客接点か、社内業務か」

kintone は業務を載せる器です。申請、在庫、生産管理、原価を自社の形で作れます。 一方の Pipedrive は、受注前から受注後まで収益部門全体を1つの CRM で扱う設計です。 営業進捗管理に加えて、メールマーケティング、プロジェクト管理、リード生成、ウェブ訪問企業の 追跡、Smart Docs による書類作成と電子契約の締結までを持ち、Google・Teams・Zoom・Asana・ Slack など500以上のツールと連携します（機能の一覧はPipedriveの主要機能）。

営業の道具ではなく、顧客に接する部門の土台だと捉えると、境界の引き方が決まります。

kintone で営業管理を作った会社が Pipedrive を見に来るとき、症状はだいたい共通しています。

• 案件一覧の絞り込み条件が増え続け、見たい状態を出すのに手数がかかる

• 進捗の書き方が人によって違い、同じ「商談中」が別の意味で使われている

• 次に何をするかが記録から読めず、思い出せる人しか動けない

これは作り込みが足りないという話ではありません。kintone は業務を自由に設計できる方向に 作られており、自由に作れることと、顧客との進行が誰にでも同じ形で見えることは、 別の要求だというだけです。

kintone のユーザーコミュニティにも、営業を担う立場から同じ趣旨の相談が公開されています （鮮度の管理が難しい、タスクを見落とす、kintone の外にスプレッドシートが残る）。 そこでの回答は「kintone に寄せて解決する」方向が中心です。どちらの解き方もあり、 本記事は別の道具を足す側の設計を書いています。

kintone をやめる必要はありません。 顧客に接する部分を Pipedrive に寄せると、 kintone は社内業務に集中できます。営業のために生産管理や在庫のアプリを動かす必要は ありません。

Mer は Pipedrive の国内唯一のマスターパートナーとして、この切り分けから実装まで担っています。

つなぐ手段の比較 — API・iPaaS・CSVから選ぶ

kintone が公式に提供する連携コネクタの対応先は Microsoft 365 系のサービスであり、 Pipedrive は対象に含まれていません。つなぐ手段は次の3系統です。

iPaaS には CData Arc、viaSocket、Make、n8n などがあります。どれを選んでも、 止まったときに誰に知らせるかを先に決めます。ここを決めていれば、その日のうちに気づけます。 連携が止まった翌週に「Pipedrive に入っていない案件がある」と気づく形が最も多く、 分かれ目はツールの性能ではなく通知の有無です。

どれを選ぶかは、次の3点で決まります。

1. 件数。 月に数十件なら CSV、数百件を超えると自動化の方が安くなります

2. 頻度。 受注の引き継ぎが1日1回で足りるなら、iPaaS で十分です

3. 社内に API を読める人がいるか。 いない場合、API 直は作れても保守で止まります

迷ったときは iPaaS から始めます。作り直しのコストが最も小さく、後から API 直へ寄せる 判断もできます。

CSV は否定する対象ではありません。月に1回、受注済みの案件を kintone へ渡すだけなら、 CSV で足ります。頻度と件数が上がってから自動化する順序で構いません。

どちらをマスターにするか

kintone のアプリと Pipedrive のデータは、次のように対応させます。

つなぐ前に、Pipedrive 側にカスタム項目を1つ作ります。kintone のレコード番号を入れる項目で、 組織と取引の両方に持たせます。型は数値でも単行テキストでも構いませんが、後から桁や記号が 変わる可能性があるならテキストにします。この1項目があるかどうかで、障害が起きたときに 「どのレコードとどのレコードが対応しているか」を追えるかが決まります。

顧客情報の正は Pipedrive に置きます。 受注を境に kintone へ移す設計にしたくなりますが、 顧客の連絡先や担当者が変わるのは顧客接点側であり、そこで最新になります。受注後に正を 移すと、更新する人と正の置き場所がずれます。

kintone へ渡すのは、社内業務を始めるために必要な最小限です。受注した事実、金額、 納期、そして突合用の ID があれば、生産や請求は動き出せます。顧客の属性まで持たせると、 両方で更新される項目が生まれます。

対応履歴を同期しない理由は、量に対して使われないためです。商談中のやり取りを社内業務側で 読む場面は多くありません。必要になったときに Pipedrive を見に行けば足ります。

業務シナリオ別のパターン

境界の引き方は、実際の業務の流れに当てはめると決まります。よくある3つを挙げます。

受注から社内業務への引き渡し

最初に作るのはこれです。受注をきっかけに、社内業務が動き出すための情報だけを渡します。

受注後の顧客対応は Pipedrive に残します。カスタマーサクセスのパイプラインを別に作り、 プロジェクトの進行も Pipedrive 側で持つ運用は、実際の導入事例にあります （Timersの事例、 XaionDataの事例）。 kintone へ渡すのは、生産・在庫・原価のように社内で完結する処理に限られます。

• きっかけ: Pipedrive の取引が受注ステージに入ったとき

• 渡す項目: 組織名、法人番号、受注金額、納期、Pipedrive の取引 ID

• 向き: Pipedrive → kintone の片方向

• 渡さない項目: 担当者の連絡先、商談の経緯、見積の履歴。社内業務では使わず、 持たせると両方で更新される項目になります

• 注意: kintone の受注レコードに Pipedrive の取引 ID を必ず持たせます。後から 「この受注はどの商談だったか」を追う唯一の手がかりになります

1日1回で足ります。受注した数分後に生産が始まる会社は多くありません。

請求

請求は、置き場所が2つに分かれます。どちらが正しいかは業務の作りで決まります。

• kintone（または会計）に置く: 請求金額が生産実績や在庫の払い出しから決まる場合。 入力元が社内業務データなので、業務側で作る方が転記が減ります

• Pipedrive に置く: 請求の内容が商談で決めた金額と条件でほぼ確定する場合。 支払い関連まで Pipedrive で管理している導入事例があります （XaionDataの事例。 THE MODEL 型でチームごとにパイプラインを作り、支払い関連も同じ CRM に載せています）

日本の請求実務については、電子帳簿保存法やインボイスの要件を CRM 単体で満たせず、 会計ソフト側に依存するという声がレビューで挙がっています。請求を Pipedrive 側に置く場合も、 会計との役割分担は別に決めます。

判断の基準は、請求の入力元が社内業務データか、顧客とのやり取りかです。 避けたいのは両方に置くことです。金額が2か所にあると、どちらが請求済みかを人が覚えることに なります。

kintone に置く場合、CRM 側で売上を見たいなら受注時に取引の金額を確定値で一度だけ更新し、 そこで追うのをやめます。入金や消込まで両方に持ち込むと、営業が見る画面に営業が動かせない 数字が並びます。

問い合わせ流入

フォームの受け皿を kintone に置いている場合、全件を Pipedrive に送りません。 営業の対象になるものだけを送ります。

判断は kintone 側で済ませます。既存顧客のサポート依頼、採用の問い合わせ、営業目的の 売り込みは kintone に留めます。全件を送ると Pipedrive が名簿になり、パイプラインの 見通しが濁ります。送るときは取引ではなくリードとして作り、有効だと分かった時点で取引に 変えると、失注の数え方が保てます。

「境界を先に決める」原則

同期する項目は最小限にします。項目を足すかどうかは、次の順で判断します。

1. 誰が更新するか。 両方の現場が更新する項目は、同期の対象にしません

2. いつ確定するか。 確定後に一度だけ渡せばよい項目は、リアルタイムにしません

3. 二重に持つと食い違うか。 食い違う項目は、片方に置いて他方からは参照にします

突合キーには会社名を使えません。表記が揺れます。「株式会社」の位置、全角と半角、 英字の大小、支店名の有無で、同じ会社が別の会社になります。使えるのは次のどちらかです。

• kintone のレコード番号を Pipedrive のカスタム項目に持たせる

• 法人番号を両方に持たせる

メールアドレスは人物の突合には使えますが、組織の突合には使えません。同じ会社に複数の 担当者がいて、退職で消えます。

更新元を1つに決める

更新元を1つに決めると、運用が読める状態になります。決めないまま双方向にすると、次の3つが起きます。

• 更新ループ。 片方の更新がもう片方を更新し、それがまた戻ってきます

• どちらが正か判定できない。 同じ項目が両方で更新されたとき、機械には決められません

• 削除が伝播する。 片方で消した1件が、もう片方の履歴ごと消えます

片方向にすると、どちらでも編集できる自由は手放します。代わりに得られるのは、どちらが正しいかを 常に言える状態です。調べる先が1つに決まるので、直すのが速くなります。

「それでも両方から編集したい」という要望は必ず出ます。そのときは、項目単位で分けて 答えます。会社名や住所のように片方の現場しか直さない項目は片方向で足ります。両方が 触る項目が本当にあるなら、その項目は片方に置いて、他方からは見るだけにします。 「同期する」と「両方で編集できる」は別の要求で、前者だけで業務は回ります。

双方向にしてよいのはキー項目だけです。kintone のレコード番号と Pipedrive の ID を 互いに持ち合う形にして、それ以外は更新元を固定します。

重複を増やさない設計

CRM 側のレビューでは、カスタマイズの自由度が高いぶん、入力ルールを決めずに運用すると データが重複して散らかるという指摘が繰り返し挙がります。連携を足すと、この性質は 両方のシステムに広がります。

重複は次の3か所で生まれます。

• 同じ会社が、両方に別表記で登録されている

• CSV を作り直して再投入した

• フォームからの流入が、同じ人を何度も作っている

つなぐ前に、既存の重複を片付けます。 順序を逆にすると、重複を持ったまま同期が走り、 両方で増えます。片付けるときは、突合ルールを決めて、残す1件を決める作業になります。 どの値を採用するか（新しい方か、入力の質が高い方か）を項目ごとに決めた結果が、 ゴールデンレコードです。

片付けは次の順で進めます。

1. 両方から一覧を出す。 kintone のレコードと Pipedrive の組織を、それぞれ書き出します

2. 突合ルールを決める。 法人番号があればそれで、無ければ住所と電話番号の組で寄せます。 会社名は補助にしか使いません

3. 残す1件を決める。 項目ごとに「新しい方を採る」「入力が埋まっている方を採る」を 決めます。決めた内容は文書に残します。次に重複が出たときの判断が同じになります

この作業は手作業でも進みますが、件数が数千を超えると合いません。当社では DataSango で 突合と統合を扱っています。連携の設計と同時にデータ側を整える判断ができると、 つないだ後の手戻りが出ません。

小さく始める順序

一度に全部つなぐ設計は、動き出すまでに時間がかかり、途中で止まると何も残りません。 次の順で広げます。

段階1が2週間ほど回れば、足りない項目は現場から出てきます。設計段階で完璧に洗い出すより、 動かして足りないものを足す方が早く、項目が増えすぎません。

つないだ後に見るのは2つです。同期が動いているか（止まったら通知が来る仕組みになって いるか）と、両方に同じ会社が増えていないかです。後者は月に1回、件数の推移を見れば 気づけます。

よくある質問

kintone は他のアプリと連携できますか。

できます。公式の連携コネクタ、各社のプラグイン、API のいずれかを使います。ただし Pipedrive は公式コネクタの対象に含まれていないため、API か iPaaS か CSV でつなぎます。

kintone の外部連携プラグインの一覧はどこで見られますか。

サイボウズが提供する連携コネクタと、各社が提供するプラグインが公開されています。 Pipedrive 向けのものは公式には用意されていないため、一覧から探しても見つかりません。

連携コネクタで Pipedrive とつなげますか。

つなげません。公式の連携コネクタは Microsoft 365 系のサービスを対象にしています。 Pipedrive とつなぐ場合は、この記事の3系統から選びます。

同期はどれくらいの頻度にすべきですか。

相手を待たせる処理だけをリアルタイムにします。受注の引き継ぎは1日1回で足りる場面が 多くあります。頻度を上げるほど API の消費と障害点が増え、止まったときの影響も広がります。

費用はどれくらいかかりますか。

手段によって、かかる場所が変わります。iPaaS は月額と実行回数、API を直接使う場合は 初期の開発と仕様変更時の保守、CSV は人の時間です。つなぐ項目を絞れているかどうかが、 どの手段でも費用を決めます。項目が増えるほど、確認と修理の対象も増えます。

既存の kintone アプリを作り直す必要がありますか。

必要ありません。確認するのは、渡す項目に対応するフィールドがあるかと、突合に使える 一意の値があるかの2点です。無ければフィールドを1つ足すだけで済みます。アプリの構造を 変えるのは、連携のためではなく業務の都合で必要になったときです。

kintone をやめて Pipedrive に一本化すべきですか。

やめる必要はありません。ただし「一本化」を2つに分けて考えます。顧客に接する業務は Pipedrive に一本化できます — 商談、メール配信、受注後のプロジェクト進行、書類と契約まで 1つの CRM で扱えます。一方、生産管理や在庫のような社内業務は kintone に残す方が安く済みます。 kintone を手放す判断が要るのは、kintone 上に社内業務がほとんど残っていないときです。

設計を始める前のチェックリスト

つなぐ作業に入る前に、次の4つに答えられるかを確認します。答えが出ていない項目があるなら、 そこが最初に決めることです。

• 受注の前と後で、顧客情報を主に更新するのはそれぞれ誰か

• 突合に使える一意の値（法人番号、または採番したレコード番号）が両方にあるか

• 同期が止まったとき、誰にどうやって知らせるか

• いま両方に存在している重複を、つなぐ前に片付ける段取りがあるか

まとめ

• 手段より先に境界を決める。 決めてからつなぐと、同期する項目は数個に収まる

• 公式の連携コネクタは無い。 API・iPaaS・CSV のいずれかで、自分たちの手でつなぐ

• 境界は「顧客接点か社内業務か」で引く。 顧客情報の正は受注後も Pipedrive に置き、kintone へは社内業務に必要な最小限を渡す

• 突合キーに会社名は使わない。 レコード番号か法人番号を両方に持たせる

• 双方向はキー項目だけ。 片方向にして更新元を固定すると、正がどちらかを常に言える

参考リンク

• Pipedriveの主要機能 — 営業進捗管理、メールマーケティング、プロジェクト管理、リード生成、Smart Docsと電子契約、500以上の外部連携（2026-08-18確認）

• kintone 連携コネクタ（サイボウズ） — 公式コネクタの対応先。Microsoft 365 系と Garoon で、Pipedrive の記載は無い（2026-08-18確認）

• XaionData の導入事例 — チーム別パイプラインと、支払い関連までCRMで管理する運用

• Timers の導入事例 — カスタマーサクセスまで含めた運用とアラート実装

顧客に接する部分をまとめて試すなら、Pipedrive は2週間の無料トライアルで全機能を使えます。 境界の設計は、実際の画面を見ながらの方が早く決まります。

無料トライアルを始める

境界の引き方から相談する場合は、現在お使いの kintone のアプリ構成をお持ちください（相談する）。