電子契約の締結状況をCRMに反映する方法｜Webhook・定期取得・手動更新の使い分け
電子契約では相手が署名を終えているのに、CRMでは「契約待ち」のままになっていることがあります。反対に、一人の署名完了を受注と扱ってしまうケースもあります。締結状況を正しく反映するには、通知の方式だけでなく、何を完了と見なし、どの契約へ書き戻すかを決める必要があります。
電子契約の状態同期は、書類IDとCRMの契約レコードを対応させ、提供元の最新状態を確認して更新する設計が基本です。Webhookは変更通知、定期取得は一覧の照合、手動更新は少量運用や例外処理に使い分けます。全員の署名完了と営業の受注条件を区別し、最終同期日時、重複通知、取消と再依頼を扱えるようにします。
公式仕様の確認日は2026年9月11日です。以下の状態名や処理手順は設計例であり、各サービスのAPIが同じ名称や通知項目を持つことを意味しません。実装時は対象サービスの仕様書と契約条件で確認します。
本記事のポイント
- Webhook・定期取得・手動更新は反映速度と運用条件で選び、書類IDで同じ契約を照合して更新する。
- 全員の署名完了と営業の受注条件を区別し、古い通知や旧版の契約で状態を上書きしない。
- 最終同期日時と失敗一覧を残し、締結済み一覧との定期照合で通知されなかった更新も確認する。
Webhook・定期取得・手動更新の使い分け
| 方法 | 向く条件 | 設計する注意点 |
|---|---|---|
| Webhook | 変更後の反映を早くしたい | 送信元確認、重複、順序逆転、受信失敗 |
| 定期取得 | 一定の遅延を許容できる | 取得間隔、ページング、件数制限、再開位置 |
| 手動更新 | 少量運用、正式APIがない、例外対応 | 担当者、確認時刻、証拠、更新漏れ |
| 通知と定期照合の併用 | 反映速度と取りこぼし対策を両立したい | 同じ書類を二重処理しない更新ルール |
Webhookは、提供元で発生したイベントを受信側へ知らせる仕組みです。常に即時・一回だけ・順番どおりに届くと仮定しないでください。通知を受けたら対象書類を確認するための手掛かりとして扱い、必要に応じてAPIで最新状態を取得してからCRMへ反映します。
クラウドサインの公式Web APIヘルプは、API利用申請に伴うWebhook利用を案内しています。一方、すべての電子契約サービスやすべてのプランで同じイベントを利用できるとは限りません。GMOサイン等についても、実際のAPI仕様書で対応イベント、通知の認証方法、再配信条件を確認して設計します。
定期取得は一定間隔で状態を読み取る方法です。例えばHubSpot向けのSign Extension for クラウドサインは、公式掲載で15分間隔の同期を案内しています。これはそのアプリの仕様であり、クラウドサインのAPI全体に共通する固定間隔ではありません。自社で実装する場合は、業務の許容遅延とAPI制限から決めます。
手動更新も、件数が少ない場合には有効です。ただし「相手から連絡があったら更新する」といった曖昧な運用では漏れが生じます。毎日の確認担当者、対象一覧、確認時刻、参照した書類IDを定めます。Google標準電子署名のように、今回の公開API調査で専用の状態取得操作を確認できていない機能では、完了確認を人が担当する構成を検討します。
契約状態と営業ステージの対応を定義する
最初に、CRMのどのレコードを更新するかを決めます。顧客名だけでは、同じ会社の別契約を区別できません。電子契約の書類IDとCRMの契約レコードIDを一対一で対応付け、その契約を顧客と案件へ関連付けます。一案件に複数文書がある場合も、文書ごとの状態を保持します。
状態の対応表には、作成中、送信済み、署名待ち、全員完了、却下、取消、期限切れなどの意味を記載します。提供元に存在しない状態をAPI値として作らず、CRMでまとめる場合はどの値を含めるかを明示します。「完了」という表示だけで、署名完了なのか処理完了なのかが分からない設計を避けます。
複数署名者がいる場合は、一人の完了と文書全体の完了を区別します。社内署名者だけが終わった状態、外部署名者が一人残る状態を試験し、受注や請求の開始へ誤って進まないことを確認します。署名者の数や順序を変更したときの状態も、仕様書に従って扱います。
契約状態と商談ステージは別の項目です。基本契約の締結は取引開始条件の一つでも、個別案件の受注を意味しない場合があります。締結完了を受けて「受注候補」や確認タスクを作り、担当者が条件を確認して進める構成も選べます。経理の売上計上や請求判断を署名イベントだけで実行しません。
CRMに戻す項目は、状態、書類ID、締結日時、保存先、最終同期日時、更新元、処理結果を基本にします。日時はタイムゾーンを揃え、日付だけ保存する項目と時刻まで必要な監査項目を分けます。APIの取得日時を実際の締結日時として記録しないようにしてください。
重複通知と順序逆転を受けても状態を壊さない
同じ通知を二度受けても同じ結果になる更新を設計します。提供元のイベントIDがある場合は処理済み記録と照合し、ない場合も書類ID、状態、更新日時などを使って重複を判定します。二度目の受信で請求タスクやメールがもう一つ作られないことが重要です。
通知の到着順が逆転すると、「締結済み」の後に古い「送信済み」が届くことがあります。通知に含まれる状態をそのまま書き戻すと状態が後戻りします。更新時刻や版を照合し、判断できないときは元サービスの現在の状態を取得します。正当な取消等があるため、すべての状態を単純な数値の大小だけで比較する設計も避けます。
契約の再依頼では書類IDが変わることがあります。旧書類と新書類を別レコードまたは版として保持し、どちらが現在の有効契約かを示します。旧版の署名通知で新しい契約の状態を上書きしないよう、CRM更新の前に書類IDと契約版を照合します。
定期取得ではページングと取得対象を確認します。先頭の一定件数だけを毎回取得すると、古い未完了契約の更新を見落とす可能性があります。最終成功時刻、未完了一覧、更新差分の提供条件を組み合わせ、途中で失敗しても処理を再開できるようにします。APIの件数制限に合わせた間隔も必要です。
CRM更新が失敗した場合は、元サービスの状態を変更せず、書き戻しだけ再試行します。署名依頼を再送する必要はありません。外部への送信とCRMの状態更新を別の処理に分けると、データ更新の障害が契約相手への二重依頼へつながるのを防げます。
日次の失敗確認と月次の全体照合を残す
日次では、最終同期日時が一定時間より古い契約、取得失敗、CRM書き戻し失敗、保存先未登録を確認します。営業担当が画面を見たときに、署名待ちなのか同期が止まっているのかを判別できる表示を用意します。エラーをすべて管理者だけが見るログへ閉じ込めないようにします。
月次では、電子契約サービスの締結済み一覧を基準にCRMと照合します。通知が届かなかった文書は、通知ログだけを確認しても発見できません。書類IDごとの突き合わせで、未反映、重複登録、別案件への誤関連を抽出し、担当者に修正を割り当てます。
手動修正を許す場合は、修正理由、確認者、確認元の書類IDを残します。次の自動同期で手動修正を上書きしてよいかも決めます。業務上の注記と提供元の署名状態を別項目にすれば、元データと社内判断のどちらが正しいかで混乱しにくくなります。
運用試験では、重複通知、古い通知、通信切断、認証失効、CRMの権限変更、部分署名、取消・再依頼を確認します。合格条件は処理が動くことだけでなく、失敗した書類を特定でき、再開しても外部への重複依頼や誤受注が起きないことです。
契約データの項目整理はCRMの要件定義、APIの役割はCRMのAPIとMCP、保存先の管理は顧客フォルダ設計と合わせて確認できます。状態同期は契約の進捗を共有する仕組みとして設計し、文書の保管と営業判断も対応させて運用してください。
連携全体と製品別の同期方法は、電子契約とCRMの連携方法、Salesforceと電子契約の連携比較、HubSpotとクラウドサインの連携、kintoneと電子契約の連携で詳しく確認できます。
電子契約の状態同期FAQ
Webhookを使えば同期漏れはなくなりますか？
受信失敗や重複、順序逆転を考慮する必要があります。通知に加えて定期的な書類一覧との照合を行うと、届かなかった更新を見つけやすくなります。
締結完了をCRMの受注に直結させてよいですか？
自社の受注条件と一致する場合に限って設計します。基本契約だけの締結や一部署名者の完了は、個別案件の受注と区別してください。
同期に失敗したら契約書を再送しますか？
状態の書き戻し失敗なら、元サービスを確認してCRM更新だけを再実行します。契約書の送信は別処理であり、無条件の再送は不要です。
手動更新でも運用できますか？
少量運用なら可能です。確認担当者、頻度、書類ID、確認時刻を決め、更新漏れを定期的に照合することが必要です。
一次情報：クラウドサインWeb API、HubSpot連携の同期仕様、Drive API。
契約の進捗共有と同期漏れの確認を整えたい場合は、ファネルAiへ電子契約とCRMの連携設計を相談することができます。
