電子契約とCRMを連携する方法｜契約書作成・署名依頼・締結状況・顧客管理をつなぐ
電子契約サービスを導入しても、営業担当が顧客名を転記し、締結済みPDFを探し、経理へメールで連絡しているなら、契約業務の負担は残っています。CRM連携で目指すのは、契約書を送れることだけではありません。どの案件の、どの版の契約が、誰の承認を経て、いつ締結されたかを営業と管理部門が同じ情報で確認できる状態です。
電子契約とCRMの連携は、契約書作成、承認・署名依頼、締結状況の取得、PDF保管、請求・更新への引き継ぎを分けて設計します。CRMの案件IDと電子契約の書類IDを対応させ、送信前の承認を残したうえで、完了状態と保存先をCRMへ戻すのが基本です。標準連携、外部アプリ、API開発で自動化できる範囲と費用は異なります。
掲載している製品情報は2026年9月11日に公式資料で確認した内容です。以下の設計例は特定CRMの実装済み機能を意味しません。Funnel Ai CRMを含め、実際の連携可否は対象API、契約プラン、権限、運用条件を照合して判断します。
本記事のポイント
- 電子契約とCRMの連携は文書作成から締結結果の反映、PDF保管、請求への引き継ぎまで分けて設計する。
- 案件IDと書類IDを対応させ、契約の版と最終同期日時を残すことで誤更新や同期漏れを見つけやすくなる。
- 標準連携でも対象プランと追加費用を確認し、API開発では二重送信と障害復旧まで運用責任を決める。
CRM連携は五つの工程に分けると要件が決まる
| 工程 | CRMから渡す情報 | 確認する結果 |
|---|---|---|
| 契約書作成 | 法人名、住所、案件条件、適用テンプレート | 差し込み済み文書と使用した版 |
| 承認・送信 | 承認結果、署名者、宛先、書類ID | 送信日時、依頼対象、送信状態 |
| 締結確認 | 対象書類ID | 全署名者の完了、取消、期限切れ等 |
| 保管 | 案件ID、顧客ID、保存先 | 署名済みPDF、証明書、保管URL |
| 請求・更新 | 開始日、終了日、請求条件 | 経理の確認、更新期限、担当者 |
最初に、現状で誰が何を転記しているかを書き出します。「顧客名を文書へ入れる」「相手が署名したか調べる」「締結日を営業案件へ記入する」「経理へPDFを送る」はそれぞれ別の作業です。最も件数が多い工程からつなげば、小さな導入でも効果を確認できます。全工程を一度に自動化する必要はありません。
契約書作成では、CRMの最新値をそのまま採用できるとは限りません。顧客マスターの住所が請求先住所だったり、案件金額が値引き承認前だったりする場合があります。契約名義、契約対象、税の扱い、契約期間、支払条件について、どの項目を正とするかを決めます。営業メモの自由記述を無確認で条文へ差し込む設計は避けます。
署名依頼では、契約書の内容を確認する社内承認と、取引先へ署名を求める操作を分けます。商談のステージが進んだだけで外部へ送信すると、金額変更や宛先変更を確認できません。「文書作成済み」「社内承認済み」「送信可能」のように、次の操作を許可する条件を明示します。誰が送信を確定したかも記録します。
締結後は、営業案件を受注へ変更する前に、その会社で何を受注の条件としているかを確認します。契約の締結日、サービス開始日、検収日、請求開始日は同一とは限りません。署名完了は契約状態へ反映し、売上計上や請求の判断は必要な条件を揃えて別に行うと、経理との食い違いを抑えられます。
標準連携・外部アプリ・API開発を選ぶ基準
標準または公式掲載の連携が業務に合うなら、まずその構成を検討します。認証、画面、状態取得、PDF取り込みを一から作る範囲が減るためです。ただし、公式サイトに掲載されていても第三者が提供する別製品である場合があります。契約先、問い合わせ先、対象CRMプラン、利用者数、追加ライセンスを確認してください。
例えばクラウドサインはSalesforce、HubSpot、kintoneの連携を掲載しています。HubSpot向けのSign Extension for クラウドサインはナウビレッジのサービスで、公式紹介では15分間隔の状態同期と締結済みPDF・合意締結証明書の取り込みを案内しています。これを「すべての連携がリアルタイムに反映される」と読み替えることはできません。
GMOサインはSalesforce、kintone、API連携などを案内しています。料金表では外部サービス・API連携がスタンダード以上に位置付けられており、連携製品やプラグインの費用が別途必要な場合があります。Salesforce連携のライセンスと帳票出力の費用も、電子契約本体の送信料とは分けて見積もります。
外部の連携サービスを使う方法は、締結済みPDFの自動保存など、決まった処理を組み合わせたい場合に向きます。クラウドサインとGMOサインはそれぞれActRecipeを用いたGoogle Drive等への保存を掲載しています。ただし、利用できるレシピ、対象プラン、無料範囲は同一とは限りません。自社に必要な保存先とエラー通知まで含めて確認します。
API開発は、独自の承認条件、複数システムの項目変換、特殊な文書生成が必要な場合の候補です。自由度と引き換えに、認証更新、障害対応、仕様変更への追従、運用監視を自社または開発委託先が担います。初期開発費だけで判断せず、誰が失敗に気付き、どこまで再実行できるかを設計に含めます。
Google Workspaceの標準電子署名はDocsやPDFから依頼する機能です。今回確認したDocs API・Drive APIの公開リファレンスでは、標準電子署名の依頼や締結状態取得に専用の操作は見つかっていません。文書の作成・保存をAPIで行えることと、署名工程まで自動実行できることを区別します。標準機能で手動送信を残す構成も選択肢になります。
CRM側のデータ整理から始める場合は、Google WorkspaceとCRMの機能要件を参考にしてください。APIとAIによる操作を検討する際は、CRMのAPIとMCPの違いも合わせて確認できます。AIが文書を作れる場合でも、承認済みの内容と宛先への送信を保証する制御は別に必要です。
案件IDと書類IDを軸に、重複と同期漏れを防ぐ
連携の中心は名前の一致ではなく、変更されにくい識別子です。一つの顧客に複数の案件があり、一つの案件にNDA、基本契約、個別契約、変更覚書があることを想定します。顧客名とPDF名だけでは同じ会社の別案件を区別できません。CRMの顧客ID・案件IDと、電子契約サービスの書類IDを対応表に保存します。
契約レコードには、文書種別、テンプレート版、契約版、書類ID、署名状態、送信日時、締結日時、保存先、最終同期日時、担当者を持たせます。契約金額や期間などの業務項目と、APIの処理状態は分けます。「送信中」「同期失敗」といった技術的な状態を、そのまま営業の受注ステージへ流し込まないことが大切です。
改訂文書を送る場合は、同じ案件内でも新しい契約版として扱います。前の依頼を取消したのか、追加契約なのかを記録し、有効な契約がどれかを示します。古い通知が後から到着したときに、新版の状態を旧版の状態で上書きしないよう、書類IDと版を確認します。状態が戻る更新は機械的に受け入れず、提供元の最新状態を照合します。
通知を受けるWebhookは反映を早くできますが、重複配信、到着順の入れ替わり、受信失敗を前提にします。イベントを受けたら即座に受注へ変更するのではなく、対象書類の状態をAPIで取得してから反映する設計が考えられます。対応イベントや認証方式はサービスごとに異なるため、公開されていない仕様を推測して実装しません。
定期取得は遅延を許容できる業務に適しています。取得間隔と件数制限を決め、前回成功した地点を保存します。途中で失敗した処理を最初から大量再実行するより、書類単位で成功・未処理を残すほうが復旧しやすくなります。営業画面には状態だけでなく最終同期日時を表示すると、古い情報である可能性を判断できます。
特に送信APIは、取得APIと同じ感覚で再試行しないでください。クラウドサインの公式APIヘルプは、504エラーでも処理が継続している場合があることや、送信済み文書への送信操作がリマインドになることを説明しています。応答がないときは書類の現状を取得し、既に送信されたかを照合してから次の操作を決めます。
自動処理が止まった場合に手動で完了させる入口も必要です。ただし手動処理の後で自動処理が同じ依頼を送らないよう、「手動対応済み」と書類IDを記録します。連携を止めるスイッチ、再開する条件、失敗一覧の担当者を用意すると、障害時にも契約の状況を追えます。
小規模な試験から始め、保管と引き継ぎまで確かめる
試験の単位は一社、一種類の文書、一つの承認経路から始めます。機密情報を含まないテストデータで、顧客情報の取得、文書生成、承認、送信、署名、PDF保存、CRM更新を一巡させます。サービスの検証環境では実際の契約締結が許可されていない場合があるため、本番とテストの用途を分けてください。
正常系の後は、宛先誤り、相手の辞退、期限切れ、取消、複数署名者の一部完了、通信失敗、権限不足を試します。判断すべきなのは画面にエラーが出るかだけではありません。営業が未完了を把握できるか、外部への重複依頼が発生しないか、担当者が復旧方法を理解できるかを確認します。
完成PDFと証明書は、原本性や検証に必要な情報を保った状態で保存します。署名済みPDFを印刷し直して再PDF化すると、元ファイルに含まれる電子署名情報を引き継げません。CRMには検索と案件からの参照を担わせ、保存先のアクセス権はDriveや文書管理側で設定します。URLを知っているだけで全員が閲覧できる状態にしないでください。
保存先の設計は、顧客フォルダの設計例から整理できます。個人のマイドライブに依存する場合には退職・異動時の引き継ぎが課題になるため、組織で管理する場所と実行アカウントを決めます。電子帳簿保存法等の適用は契約書の性質と保存運用で確認し、Driveへ置くだけで要件を満たすとは扱いません。
導入後は、月次でCRMの完了件数と電子契約サービスの締結件数を照合します。差分がある文書の書類ID、未保存ファイル、更新漏れを確認し、担当者に対応を割り当てます。通知が成功した割合だけでは、契約の取りこぼしを見つけられません。実際の完了文書を基準にした照合を残します。
効果は、文書作成時間、転記回数、締結から営業反映までの時間、保存漏れ件数、更新期限の把握率で測ります。自動化の範囲を広げる判断は、その結果を見て行います。運用担当者が説明できる小さな構成を安定させてから、請求・更新管理や別部門へ展開すると、複雑な例外が増えても対応しやすくなります。
権限の試験では、管理者アカウントだけで成功させないようにします。一般の営業担当、閲覧だけの経理担当、異動後の旧担当者で同じ契約を開き、送信・編集・ダウンロードが想定どおり制限されるかを確認します。連携用アカウントが処理できることと、担当者に開示してよいことは別です。必要な処理だけに権限を限定し、権限変更後には保存や状態取得が停止していないかも点検します。
全体設計の前に、Google Workspace電子署名の徹底解説、Google・クラウドサイン・GMOサインの比較、クラウドサインとGMOサインの比較で詳しく確認できます。
電子契約とCRM連携のFAQ
CRMから契約書を送れれば連携は完成ですか？
送信だけでは締結後の転記が残ります。書類ID、締結状態、完成PDFの保存先を案件へ戻し、失敗時の確認担当者まで決めることで一連の業務を追えるようになります。
すべてAPIで自動化したほうがよいですか？
契約件数、承認の複雑さ、運用体制によります。文書作成と保存を自動化し、最終確認と送信を人が行う構成も有効です。既存連携の機能と費用を確認してから個別開発を検討します。
締結完了でCRMを自動的に受注にできますか？
CRMの更新機能と業務ルールが整えば設計できます。ただし、一部署名者の完了と全員の完了を区別し、受注条件が契約締結と一致するかを確認する必要があります。
Funnel Ai CRMとの既製連携はありますか？
本記事では電子契約サービスとの既製コネクタの提供を確認したものではありません。対象API、契約情報の項目、認証と権限を確認し、既存機能でできる範囲と個別実装が必要な範囲を整理します。
一次情報：クラウドサイン連携一覧、クラウドサインWeb API、GMOサイン連携、Docs API。
契約書作成から締結後の顧客管理までを整理したい場合は、ファネルAiへCRMと電子契約の連携設計を相談することができます。
