More in
データ移行ガイド
Salesforceからのクリーンなエクスポート:移行対応エクスポートガイド
4月 18, 2026
HubSpotからのクリーンなエクスポート:標準エクスポートで見落とされること
4月 18, 2026
Pipedriveからのクリーンなエクスポート:商談・連絡先・活動履歴
4月 18, 2026 · Currently reading
スプレッドシートからの脱却:本格的なCRMへの5ステップ移行
4月 18, 2026
CRM移行における過去の活動履歴・メモ・メールの取り扱い
4月 18, 2026
移行後のデータ監査:何をいつ確認するか
4月 18, 2026
CRM移行中のユーザーアクセス管理:最小権限アプローチ
4月 18, 2026
営業チームへのCRM移行の伝え方
4月 18, 2026
CRM移行のロールバック計画:使わずに済むことを願って
4月 18, 2026
旧CRMデータの長期アーカイブ:何を残すか・どう保管するか
4月 18, 2026
Pipedriveからクリーンにエクスポートする: Deal、連絡先、活動履歴
あるファウンダーがPipedriveから新しいCRMに8,000件のDealを移行しました。インポートはクリーンに完了し、行数も一致しました。その6ヶ月後、取締役会メンバーから過去2年間で各ステージにDealが滞在した期間を示すPipeline velocityレポートを求められました。データはありませんでした。PipedriveのDealステージ履歴、つまり各DealがステージからステージへいつX移動したかのログは、標準エクスポートに含まれていません。APIかサードパーティツールが必要で、誰もそれを問い合わせていなかったのです。
ステージ履歴は消えていました。レポートは作れませんでした。2年分のPipelineパターンデータがエクスポート時に失われました。
このガイドでは、Pipedriveが何をクリーンにエクスポートし、何をサイレントに除外し、移行前に完全な移行可能なデータセットを取得する方法を説明します。
PipedriveのデータモデルをR理解する
PipedriveはDealを中心に構築されています。その他はすべて副次的な存在です。
ほとんどのCRM(Salesforce、HubSpot、最新ツールの多く)では、ContactとAccountが主要オブジェクトです。Deal(またはOpportunity)はそれらに紐付きます。Pipedriveでは、Dealが主要レコードです。Person(連絡先)とOrganization(会社)は、主にDealのフィールドとして存在します。PipedriveのAPIデベロッパードキュメントでは、Dealフローとステージ履歴の取得に利用可能なエンドポイントを含む完全なオブジェクトモデルを説明しています。
Pipedriveのコアオブジェクト:
| Pipedriveオブジェクト | ほとんどのCRMでの相当 | 主な違い |
|---|---|---|
| Deal | Opportunity | 主要オブジェクト。ほとんどのレポートの基盤 |
| Person | Contact | 副次的。DealとOrganizationに紐付く |
| Organization | Account | 任意。多くのDealはOrganizationではなくPersonに紐付く |
| Activity | Task/Event | Personではなく、Dealに紐付く |
| Note | Note | Deal、Person、Organizationのいずれにも添付可能 |
| File | 添付ファイル | どのオブジェクトにも添付可能 |
構造上の意味合い: Pipedriveでは営業担当者のリレーションシップ履歴はDealに蓄積します。ほとんどの移行先CRMではリレーションシップ履歴はContactに蓄積します。この不一致がすべてのPipedrive移行の核心的な課題であり、インポート後ではなく、整理ステップの前中に解決する必要があります。旧システムと新システム間のフィールドマッピングでは、整理が始まる前にこの構造的な変換を体系化します。
PipedriveのActivityも異なる動作をします。SalesforceやHubSpotではActivityはContactに対して記録されます。PipedriveではActivityはDealに対して記録されます。Contact中心のCRMに移行する場合、すべてのActivityをDealに紐付けたままにするのではなく、Contactに再アソシエートする必要があります。
ステップ1: オブジェクトを個別にエクスポートする
Pipedriveのエクスポートツールは「設定 > データエクスポート」にあります。オブジェクトは1つずつエクスポートします。
エクスポートパス: 「設定 > データエクスポート > [オブジェクトを選択]」
エクスポートするものとその順序:
- Organization: 最初にエクスポート(Accountに相当。PersonがOrganizationを参照する)
- Person: 2番目にエクスポート(Contact。Organizationを参照する)
- Deal: 3番目にエクスポート(主要オブジェクト。両方を参照する)
- Activity: 4番目にエクスポート(Deal、Person、Organizationを参照する)
- Note: 5番目にエクスポート(どのオブジェクトも参照できる)
各エクスポートで:
- CSV形式: ExcelよりCSVを選びます。Excelは日付フォーマットの不整合と文字エンコードの問題を生じさせ、整理作業が複雑になります。
- 全フィールドを含める: Pipedriveはデフォルトでフィールドのサブセットのみを表示します。列セレクターを使って必要なすべてのフィールドを含めます。デフォルト選択に頼らないでください。
- カスタムフィールドを含める: Pipedriveはセレクターに標準フィールドとカスタムフィールドを一緒に表示します。カスタムフィールドにチェックが入っているか確認します。
各エクスポートに含まれる内容:
Pipedriveのエクスポートは選択したすべてのフィールドを列として持つフラットなCSVを提供します。Dealのエクスポートには、Person名とOrganization名が列として含まれます(リレーションシップは非正規化されています)。しかし、それらの参照にはIDではなく名前が使われているため、データに重複する名前がある場合、インポート時にマッチングの課題が生じます。
ステップ2: Dealステージ履歴をエクスポートする
これが標準エクスポートで見落とされる内容です。Dealステージ履歴(各DealがPipelineのステージからステージへいつ移動したかのログ)は、Dealレコード自体ではなく、Pipedriveのアクティビティログに蓄積しています。Dealレコードには現在のステージしか保存されていません。
なぜ重要か:
ステージ履歴はPipeline velocity分析(各ステージでの平均滞在時間)、ステージ別のコンバージョン率レポート、および過去のパターン分析の基盤です。それがなければ、新しいCRMはPipelineのベンチマークデータなしでスタートすることになります。Harvard Business Reviewによれば、Pipelineステージデータを体系的に分析している企業は売上予測の精度が大幅に高く、過去のステージ進行データは将来のウィン率改善に最も活用できるデータの一つです。
ステージ履歴を取得する選択肢:
オプションA: Pipedrive API
Pipedrive APIは各Dealのステージ変更イベントを返すDealフローエンドポイントを提供しています:
GET /api/v1/deals/{id}/flow
これはDealへのすべての更新(タイムスタンプ付きのステージ変更を含む)のログを返します。大規模な環境(何千件ものDeal)では、Deal IDをループするスクリプトによるAPI呼び出しが必要です。技術リソースがある場合、これが最も完全なアプローチです。
オプションB: サードパーティエクスポートツール
Coupler.ioやHevo Dataなどのツールは、Dealステージ履歴を同期の一部として取得するPipedriveコネクターを持っています。セットアップには数時間かかり、APIプログラミングは不要です。費用はツールによりますが、1回の移行利用では通常月額1万円未満です。
オプションC: 対象外として記録・省略する
移行先CRMでステージ履歴が業務上重要でない場合(小規模なチームでは多くの場合そうです)は、その判断を明示的に記録し、エクスポート日を過去の基準日として設定し、先に進みます。業務上の必要性がない場合はこれをボトルネックにしないでください。移行しないことにしたレコードは計画的なアーカイブに入れます。レガシーCRMデータの長期アーカイブでは、Pipedriveのライセンスを永続的に維持せずにデータを保持する選択肢を説明しています。
ステップ3: カスタムフィールドを正しくエクスポートする
Pipedriveのカスタムフィールドは、UIで表示されるラベルではなく、内部フィールドIDを列ヘッダーとしてエクスポートされます。エクスポートの列が「Contract Value」の代わりにabcdef123456のように表示されることがあります。これは多くのCRMエクスポートツールに共通する特性です。データ辞書に関するWikipediaの記事では、フィールド名とIDのマッピングを文書化する実践について説明しており、Pipedriveのエクスポート実行前にまさにそれが必要です。
エクスポート前にラベルマッピングを取得する方法:
「設定 > データフィールド > カスタムフィールド」で確認します。各オブジェクト(Deal、Person、Organization)について、Pipedriveはフィールド名と内部キーを表示します。エクスポート実行前にこのマッピングをエクスポートまたはスクリーンショットで保存してください。フィールドマッピングと整理の際に必要になります。
Data LoaderまたはAPIエクスポートを使用する場合は、以下のエンドポイントでフィールドラベルを取得できます:
GET /api/v1/dealFields: 名前とキーを含むすべてのDealフィールドを返す
GET /api/v1/personFields: Personフィールドも同様
GET /api/v1/organizationFields: Organizationフィールドも同様
ラベルマッピングを別の参照spreadsheetに記録します。エクスポートファイルと一緒に保管します。
ステップ4: Account-Contact-Dealの階層を再構築する
これが構造的な変換ステップです。PipedriveのPerson/Organization/Dealモデルを、ほとんどの移行先CRMが使用するContact/Account/Opportunityモデルに変換する必要があります。
マッピング:
| Pipedrive | 移行先CRM |
|---|---|
| Organization | Account |
| Person | Contact |
| Deal | Opportunity |
| Activity(Dealに紐付く) | Task/Event(ContactとOpportunityに紐付く) |
| Dealオーナー(ユーザー) | Opportunityオーナー |
| Organizationオーナー | Accountオーナー |
エッジケース:
**Organizationに紐付いていないPerson。**PipedriveはOrganizationなしにPersonを作成できます。ContactにAccountのアソシエーションが必須の移行先CRMでは、これらのPersonはインポートに失敗します。プレースホルダーAccountを作成するか、インポート中だけ必須アソシエーションを一時的に外す必要があります。整理が始まる前にこれらのレコードを特定します。
**OrganizationなしでPersonに紐付くDeal。**これはトランザクション型または中小企業向けのPipelineでよく見られます。Contact中心のモデルでは、これらはAccountなしでContactのみに紐付くOpportunityになります。これらのPersonごとにAccountを作成するか、Contact-onlyのOpportunityを許容するかを事前に決定します。移行先CRMの扱いが異なる場合があります。
**1つのDealに複数のPerson。**Pipedriveは複数の連絡先をDealに追加できます。ほとんどのエクスポートCSVにはプライマリのPersonだけが含まれます。すべての連絡先アソシエーションを取得するには、APIを使うか、Pipedriveのエクスポート設定にセカンダリ参加者を含めるオプションがあるか確認します。この複数Contact-Dealレコードは、過去の活動履歴、メモ、メールの取り扱いと構造的変換が交わる具体的なケースです。Dealに関わる各Contactには、移行する価値のある独自のアクティビティコンテキストがある場合があります。
オブジェクトマッピング参照テーブル:
| Pipedriveフィールド | 移行先フィールド | 備考 |
|---|---|---|
| Dealタイトル | Opportunity名 | 直接マッピング |
| Deal金額 | Opportunity金額 | 通貨フィールドを確認 |
| 予定クローズ日 | クローズ日 | 日付形式を確認 |
| ステージ | ステージ | ステージ名のマッピングが必要 |
| Person名 | Contact名(姓・名) | スペースで分割が必要な場合 |
| Organization名 | Account名 | 紐付けのための名前でマッチング |
| Activityタイプ | Task/Eventタイプ | タイプが1対1でマッピングされない場合がある |
| Noteの内容 | Noteの本文 | 文字数制限を確認 |
ステップ5: エクスポートを検証する
整理ステップに進む前にこれらを確認します。
行数検証:
Pipedriveのインサイトまたはリストビューで正規のレコード数を確認します:
| オブジェクト | Pipedriveでの確認場所 | 比較対象 |
|---|---|---|
| Deal | 「Deal > リストビュー」(全Pipeline、全ステージ、全ユーザー) | CSVの行数からヘッダーを引いた数 |
| Person | 「連絡先 > 人物 > リストビュー」(全オーナー) | CSVの行数 |
| Organization | 「連絡先 > 組織 > リストビュー」 | CSVの行数 |
| Activity | 「アクティビティ > リストビュー」(全タイプ、全オーナー) | CSVの行数 |
大きな差異(2〜3%以上)はエクスポートのフィルタリングの問題を示しています。よくある原因: エクスポートが全レコードではなく「自分のレコード」にデフォルト設定されていること、またはアクティブ/非アクティブのフィルター。
カスタムフィールドの完全性:
ステップ3のラベルマッピング参照を使って、すべてのカスタムフィールドがエクスポートCSVに対応する列があることを確認します。欠けている列は、エクスポート時にそのフィールドが選択されていなかったことを意味します。
ActivityとDealの紐付け:
ランダムなDeal20件を選びます。各Dealについて、ActivitiesエクスポートにそのDeal名(またはDeal ID)と一致する行が少なくとも1件あることを確認します。PipedriveのUIにDealのアクティビティがあるのにエクスポートに何も表示されない場合は、Activitiesエクスポートにフィルタリングまたはエクスポートオプションの問題があります。
OrganizationなしのPerson:
Organizationの列が空白のPersonレコードの数をspreadsheetの数式で確認します。これにより、インポート前に作成が必要なプレースホルダーAccount数(または必要な判断の数)がわかります。
Pipedriveエクスポートチェックリスト
- Organizationを最初にエクスポート
- PersonをエクスポートO(Organization名の列を含む)
- DealをエクスポートO(Person名とOrganization名の列を含む)
- ActivitiesをエクスポートO(Deal名の列を含む)
- すべてのオブジェクトタイプのNoteをエクスポート
- エクスポートファイルと一緒にカスタムフィールドラベルのマッピングを記録
- Dealステージ履歴を取得(APIかサードパーティツール経由、またはスコープ外として記録)
- すべてのオブジェクトについてPipedriveのリストビューと行数を検証
- Organizationに紐付いていないPersonを特定してカウント
- ランダムなDeal20件についてActivity-Deal紐付けをスポットチェック
よくある失敗パターン
**成約/失注の理由を失う。**Pipedriveは成約/失注の理由を標準のエクスポート列には常に表示されない別フィールドとして保存します。Dealエクスポートのフィールド選択に「成約/失注の理由」を明示的に追加してください。存在していますが、デフォルトでは選択されていません。
**ActivityとDealのどちらに添付されているNoteかを見落とす。**PipedriveのNoteはDeal、Person、Activityのいずれにも独立して添付できます。Notesエクスポートには「リンクされたタイプ」と「リンクされたID」の列を含めることで、インポート後にどのNoteがどこに属するかを再構築できます。
**メール連携の履歴を忘れる。**チームがPipedriveのメール同期機能を使っていた場合、それらのメールはDealタイムラインに存在しますが、標準ツールではエクスポートできない場合があります。移行においてメール履歴が重要な場合は、APIのDealフローエンドポイントを確認してください。
**同一連絡先の重複Person。**PipedriveはデフォルトでPersonのメールの一意性を強制しません。長年にわたって手動でPersonを追加したチームは、名前が若干異なる重複、または同じメールを持つ重複を蓄積しています。Deloitteのデータ品質管理に関する調査では、重複レコードがCRMシステムで最も一般的かつコストのかかるデータ品質問題であり、解決にかかるコストは放置期間が長くなるほど増加すると述べています。整理前にPersonのメールで重複排除パスを実行します。完全な重複排除プロセスはデータクレンジング: 重複排除、正規化、エンリッチメントで説明しています。
次に取るべき行動
Pipedriveのエクスポートで生データが揃いました。しかし、整理してインポートする前に、データモデルの変換が必要です。Person/OrganizationからContact/Accountへの変換です。
次のステップは旧システムと新システム間のフィールドマッピングです。ここでPipedriveから移行先CRMへのフィールドマップを体系化し、Deal中心からAccount中心への構造的変換を処理します。
整理が始まる前に、スコープ、レコードタイプ、データ品質基準をまだ定義していない場合はデータ移行前の準備を確認してください。
その後、エクスポートとマッピングが固まったらデータクレンジング: 重複排除、正規化、エンリッチメントで実際の整理作業を行います。
