> 継続的なプロセス改善 > 契約管理 > DocuSign CLM > データテンプレート

契約管理データテンプレート

DocuSign CLM

契約管理の属性 (19) 契約管理のアクティビティ (15) 抽出ガイド (1)

契約管理データテンプレート

このテンプレートでは、契約管理プロセスの分析に必要な主要データを体系的に整理しています。収集すべき基本属性、追跡すべき主要アクティビティ、情報を抽出するための具体的な手順を確認できます。プロセスの詳細な把握と最適化に必要なデータを漏れなく収集するためにご利用ください。

収集を推奨する属性
追跡すべき主要アクティビティ
データ抽出の手順

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

契約管理の属性

契約管理プロセスを詳細に分析するために、イベントログに含めることを推奨するデータ項目です。

5 必須 7 推奨 7 任意

	名前	説明
	アクティビティ ActivityName	契約ライフサイクルで発生した特定のタスクまたはイベントの名称です。
説明この属性は、契約管理プロセスにおける単一のステップまたはマイルストーンを表します。たとえば、「契約書作成済み」、「法務レビュー開始」、「契約締結済み」などです。これらのアクティビティが、プロセスマップを構成する基本要素となります。これらのアクティビティの順序と頻度を分析することは、プロセスマイニングの基本です。実際のプロセスフローを特定し、標準手順からの逸脱を見つけ、時間がかかっている、または繰り返し発生しているアクティビティを明らかにできます。重要な理由プロセス内のステップを定義し、契約ワークフロー、ボトルネック、ばらつきを可視化・分析できるようにします。入手先通常は、DocuSign CLMのイベントログまたは監査証跡データから取得されます。これらには、契約書やワークフロー上で実行された操作が記録されています。例契約書案を作成社内レビューを開始取引先へ送信契約を締結
	契約ID ContractId	システム内で管理される各契約を一意に識別するIDです。
説明 Contract IDは、契約の開始から完了まで、特定の契約に関連するすべてのイベントとアクティビティを一意に結び付ける、正式なケース識別子です。DocuSign CLMでは、Envelope IDまたは契約識別用に設定されたカスタム項目に該当する場合があります。この属性はプロセスマイニングに欠かせません。個々の契約のエンドツーエンドの行程を再構成できるためです。関連するすべてのアクティビティを1つのContract IDにまとめることで、分析担当者はプロセス全体の流れを可視化し、サイクルタイムを測定し、契約ごとの違いを分析できます。重要な理由関連するすべてのプロセスイベントを結び付ける主キーです。1件の契約のライフサイクル全体を追跡し、分析できます。入手先通常、DocuSign CLMにおける契約またはエンベロープオブジェクトの主要識別子です。Envelope ID、または契約識別用に設定されたカスタム項目として表示される場合があります。例 CON-2023-03-112MSA-4815162342NDA-CORP-9981
	開始時刻 EventTime	特定のアクティビティまたはイベントが開始された時点を示すタイムスタンプです。
説明この属性は、アクティビティが発生した正確な日付と時刻を記録します。プロセスマイニングにおける時間情報の基盤となり、時間の経過に伴うプロセスパフォーマンスを分析できます。開始時刻に基づいてイベントを並べると、ケースごとの時系列ログが作成されます。これにより、アクティビティ間のサイクルタイム、各ステップの所要時間、プロセス全体の開始から終了までの期間を計算できます。ボトルネックの特定、待ち時間の測定、SLAに照らしたプロセス効率の評価にも欠かせません。重要な理由イベントを時系列に並べ、サイクルタイムや所要時間など、時間に基づくすべての指標を計算するうえで重要なタイムスタンプです。入手先 DocuSign CLMのイベントログまたは監査証跡に標準的に含まれる情報で、記録されたすべての操作に関連付けられています。例 2023-04-15T09:00:00Z2023-05-20T14:35:10Z2023-06-01T11:21:05Z
	ソースシステム SourceSystem	データの抽出元となるシステムを特定します。
説明この属性は、プロセスデータの取得元を示します。このビューでは、値は一貫して「DocuSign CLM」または同様の識別子になります。単一システムの分析では冗長に見える場合がありますが、この項目を含めることは推奨される方法です。複数のシステムのデータを統合する際に重要になります。たとえば、CRMの契約データとDocuSignのワークフローデータを組み合わせる場合でも、データの系譜と追跡可能性を明確に保てます。重要な理由データの追跡可能性を確保し、複数の企業システムのデータを組み合わせる分析に欠かせません。入手先通常は、データの抽出・変換処理でデータセットの取得元を示すために付与される固定値です。例 DocuSign CLMDocuSign CLM v24.1
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新または抽出された時点のタイムスタンプです。
説明この属性は、データセットが最後に更新された日時を示します。分析対象のデータがどの程度新しく、最新の状態に近いかを把握できます。ダッシュボードやレポートでは、データガバナンスと利用者の信頼を支える重要な情報です。リアルタイムの情報を見ているのか、特定時点のスナップショットを見ているのかを分析担当者が判断できるため、適切なタイミングで意思決定を行ううえで役立ちます。重要な理由データの鮮度を把握するための重要な情報であり、プロセス分析がどの時点のデータに基づいているかを明確にします。入手先メタデータ属性の一つで、通常はETL（Extract、Transform、Load）ツールまたはデータパイプラインがデータ取り込み時に生成・保存します。例 2023-10-26T08:00:00Z2023-10-27T08:00:00Z
	契約ステータス ContractStatus	契約のライフサイクルにおける現在の状態またはステータスです。
説明この属性は、特定時点における契約全体のステータスを示します。たとえば、「下書き」、「レビュー中」、「署名待ち」、「締結済み」などです。契約がプロセスのどの段階にあるかを大まかに把握できます。プロセスマイニングでは、ステータスを分析することでケースを絞り込み、さまざまな段階にある契約数を追跡するダッシュボードを作成できます。「リアルタイム契約ステータス追跡」ダッシュボードは、この属性を直接利用して、進行中の契約ポートフォリオを可視化し、作業が滞留している箇所を特定します。重要な理由契約の進捗状況を把握できるため、ステータスの追跡、作業量の管理、ボトルネックの特定に欠かせません。入手先通常は、DocuSign CLM内の契約オブジェクトまたはワークフローオブジェクトに主要属性として登録されています。例草案社内レビュー中署名待ち締結済み終了
	契約担当者 ContractOwner	契約のライフサイクル全体を管理する責任を負う利用者または従業員です。
説明契約担当者は、契約の進行に責任を持つ主な窓口です。通常は、契約依頼を開始した人、または取引関係を担当する人が該当します。契約担当者別にパフォーマンスを分析すると、効率性、手戻り率、サイクルタイムの傾向を把握できます。高い成果を上げている個人やチーム、追加のトレーニングや支援が必要な担当者を特定するのにも役立ちます。「契約サイクルタイム分析」などのダッシュボードでデータを分類する際の重要な軸です。重要な理由個人またはチーム単位でパフォーマンスを分析でき、利用者が行うアクティビティのベストプラクティスや改善領域を特定できます。入手先通常は契約オブジェクトに関連付けられた利用者項目で、ワークフローを作成または所有する利用者の名前が入力されます。例 Alice SmithBob JohnsonCharlie Brown
	契約相手方 Counterparty	契約に関与する顧客や取引先など、外部の相手方です。
説明この属性は、契約に参加するもう一方の組織を特定します。契約相手方によって交渉の進め方、法的要件、応答時間が異なるため、契約のライフサイクルに大きな影響を与える場合があります。契約相手方別にプロセスパフォーマンスを分析すると、協業しやすい相手と、継続的に遅延を引き起こす相手を特定できます。この情報は、関係管理の改善や、今後の交渉における現実的な見通しの設定に役立ちます。「契約の手戻りと改訂頻度」分析における重要な軸です。重要な理由外部の相手方とのやり取りが、交渉期間、改訂回数、全体のサイクルタイムに与える影響を分析できます。入手先契約記録の基本情報で、通常は専用の「契約相手方名」または「会社」項目に保存されます。例 Acme CorporationGlobex Inc.Stark Industries
	契約種別 ContractType	NDA、MSA、SOWなど、契約の分類です。
説明この属性は、契約を法的または業務上の目的に基づいて分類します。契約種別によってワークフロー、承認要件、複雑さが異なることがよくあります。契約種別ごとにプロセスを分析することは、パフォーマンスの違いを理解するうえで基本となります。契約の種類ごとにサイクルタイム、コンプライアンス率、交渉の傾向を比較できます。たとえば、NDAは複雑な基本サービス契約よりもサイクルタイムが大幅に短いはずです。この属性により、その比較が可能になります。重要な理由契約の種類ごとに固有のワークフローや複雑さがある場合でも、プロセスパフォーマンスを比較できます。入手先重要なメタデータ項目で、通常はDocuSign CLMで契約を作成する際にドロップダウンリストから選択します。例秘密保持契約（NDA）基本サービス契約（MSA）作業範囲記述書（SOW）
	契約金額 ContractValue	契約の総額です。
説明この属性は契約の金銭的価値を表し、一括金額の場合と継続的に発生する金額の場合があります。契約金額によって、必要な審査の水準や承認経路の複雑さが決まることがよくあります。契約金額に基づいてプロセスを分析すると、高額案件を優先し、不必要な遅延が発生していないかを確認できます。一定額を超える契約にCFOの承認があるかを確認するなど、コンプライアンスの確認にも利用できます。この属性により、金銭的な影響が大きい契約に改善の取り組みを集中できます。重要な理由高額な契約ほど厳格な審査が必要で、事業への影響も大きい傾向があるため、優先順位付けとリスク評価に役立ちます。入手先通常は、DocuSign CLM内の契約メタデータにある数値項目または通貨項目です。例 500002500001200000
	有効期限 ExpirationDate	契約が満了する日付です。
説明この属性は契約上の有効期限を保存します。特に、継続的な収益や長期サービス契約を含む契約ポートフォリオを先回りして管理するうえで重要なメタデータです。この日付は、「契約更新・有効期限見通し」ダッシュボードの主要な基準となります。有効期限が近づいている契約を監視することで、適切なタイミングで更新ワークフローを開始できます。また、「契約期限内更新率」KPIの計算にも使われ、収益の取りこぼしやサービス中断の防止に役立ちます。重要な理由契約を先回りして管理し、適切なタイミングで更新するとともに、意図しない契約失効を防ぐうえで欠かせません。入手先 DocuSign CLMで期間が定められた契約には、標準的なメタデータ項目として記録する必要があります。例 2024-12-312025-06-302026-01-15
	終了時刻 EndTime	特定のアクティビティまたはイベントが完了した時点を示すタイムスタンプです。
説明この属性は、アクティビティが完了した正確な日付と時刻を記録します。開始時刻が開始を示すのに対し、終了時刻は完了を示すため、個々のアクティビティの所要時間を正確に計算できます。終了時刻を分析すると、アクティビティの処理時間、つまりタスクに実際に費やした作業時間を計算できます。これにより、実作業時間と待ち時間を区別し、リソース効率や遅延による実際のコストをより詳しく把握できます。たとえば、「法務レビュー」アクティビティの正確な所要時間を計算できます。重要な理由個々のアクティビティの所要時間を正確に計算し、実際の処理時間とアイドル状態の待ち時間を区別できます。入手先 DocuSign CLMのようなシステムでは、監査証跡に明示的に記録される場合と、後続イベントの開始時刻から推定する必要がある場合があります。例 2023-04-15T17:30:00Z2023-05-21T10:00:15Z2023-06-01T11:55:00Z
	手戻りかどうか IsRework	契約で大幅な改訂の繰り返しが発生したかどうかを示すブール値のフラグです。
説明この計算属性は、社内承認を受けた後に変更履歴の確認のため差し戻された契約など、手戻りが発生した契約を特定します。通常は、望ましくない特定のアクティビティの順序を検索して導出します。このフラグにより、プロセスの非効率性を簡単に分析できます。「契約手戻り率」KPIを直接計算でき、追加の作業が必要だった契約だけを絞り込んで分析できます。初期要件が不明確だった、交渉が難航したなど、手戻りの根本原因を特定するのにも役立ちます。重要な理由手戻りの頻度を定量化・分析し、プロセスの非効率性や見えにくいコストを示す重要な指標として利用できます。入手先「社内承認受領済み」イベントの後に「契約変更履歴確認済み」イベントが発生するなど、手戻りのループを特定するルールを定義し、プロセスマイニングツール内で計算します。例 truefalse
	承認ステータス ApprovalStatus	「保留中」、「承認済み」、「却下」など、承認ステップのステータスです。
説明この属性は、契約のライフサイクルにおける承認段階に特化した詳細なステータスを示します。契約ステータスがケース全体の概要ステータスであるのに対し、承認ステータスは個々の承認アクティビティの結果を追跡します。「契約承認ボトルネックレポート」と「リアルタイム契約ステータス追跡」には欠かせません。承認待ちの契約、却下されて手戻りが必要な契約、承認段階を正常に通過した契約を明確に把握できます。これらのステータス間の遷移を分析すると、承認経路上の具体的な失敗箇所や遅延箇所を特定できます。重要な理由承認段階を詳しく把握できるため、どの契約が、なぜ滞留しているのかを特定できます。入手先 DocuSign CLM内の承認タスクまたはワークフローステップの結果です。例法務承認待ち財務承認済み営業担当副社長により却下
	承認段階の所要時間 ApprovalPhaseDuration	承認に関連するすべてのアクティビティに費やした合計時間です。
説明この指標は、契約が承認段階に費やした合計期間を計算します。最初の社内承認に回付された時点から、必要な最終承認を取得するまでの期間です。承認関連アクティビティの所要時間を合計するか、最初の承認アクティビティの開始から最後の承認アクティビティの終了までの時間を測定して計算できます。この属性は、「平均承認段階所要時間」KPIの中心となる指標です。作成や交渉ではなく、承認プロセスに起因する遅延を切り分けられます。この所要時間を追跡することで、承認マトリクスの影響を把握し、効率化の機会を特定できます。重要な理由承認に費やした時間を切り分けることで、承認経路内のボトルネックを特定し、対処しやすくなります。入手先「社内承認回付済み」や「社内承認受領済み」など、承認に関連するすべてのイベントを特定し、ケースごとに最初のイベントから最後のイベントまでの時間を測定して、プロセスマイニングツール内で計算します。例 5日2時間10日1時間2日6時間
	文書バージョン DocumentVersion	契約書のバージョン番号です。
説明この属性は、契約書が改訂や変更履歴の確認を経る中で、何回目の版であるかを追跡します。新しいバージョンをアップロードまたは保存するたびに、この番号は増加します。文書バージョンを追跡すると、手戻りの量や交渉の複雑さを直接測定できます。契約書のバージョン数が多い場合、当事者間で大幅なやり取りが発生したことを示します。この属性は、「平均文書改訂回数」KPIの計算や、「契約の手戻りと改訂頻度」ダッシュボードの分析における主要な入力値です。重要な理由文書が何回改訂されたかを追跡することで、手戻りの量と交渉にかかった労力を直接測定できます。入手先 DocuSign CLMには文書のバージョン管理機能が組み込まれています。この属性は、文書のバージョン履歴から抽出されます。例 1234
	法務担当者 LegalCounsel	契約のレビューを担当する法務専門家またはチームメンバーです。
説明この属性は、契約のレビューと承認を担当する法務部門の特定の担当者を示します。通常は事業部門側の担当者である契約担当者とは異なります。レビューを特定の法務担当者に割り当てると、法務レビューのステップを詳しく分析できます。「法務レビューのパフォーマンス」ダッシュボードを作成し、法務チームのメンバーごとに処理量やサイクルタイムを測定・比較できます。これにより、作業量の配分を調整し、法務部門内の効率化の機会を見つけられます。重要な理由法務レビュー段階を詳しく分析し、作業量の配分を調整しながら、法務チームのパフォーマンスを測定できます。入手先 DocuSign CLMのワークフローにあるタスク割り当てデータから取得し、「法務レビュー」タスクの割り当て先を示します。例 Jennifer WaltersMatt MurdockHarvey Specter
	部門 Department	契約を所管する社内の事業部門または部署です。
説明この属性は、契約を開始した、または契約に責任を持つ社内部門を示します。たとえば、営業、マーケティング、ITなどです。部門ごとにプロセスやニーズが異なるため、契約管理の進め方にも違いが生じます。部門別に分析することは、社内の各部門が契約管理プロセスをどのように利用しているかを理解するうえで欠かせません。「契約承認ボトルネックレポート」のような対象を絞ったレポートを作成し、特定の事業部門に遅延が集中しているかを確認できます。また、部門のニーズに合わせてプロセスを改善できます。重要な理由事業部門間でパフォーマンスを比較し、効率性、コンプライアンス、作業量の違いを明らかにできます。入手先契約のメタデータ項目として登録される場合と、契約担当者である利用者の所属部門から導出される場合があります。例営業法務調達マーケティング
	電子署名済みかどうか IsESigned	契約が電子署名によって締結されたかどうかを示すブール値のフラグです。
説明この属性は、DocuSign eSignatureのような連携済みの電子署名ツールで契約に署名したか、紙の署名とスキャンなどのオフライン方式で締結したかを追跡します。この属性は、「電子署名導入率」KPIを直接支えます。電子署名された契約の割合を分析することで、デジタルトランスフォーメーション施策の成果を測定できます。導入率が高いほど、通常は締結時間の短縮、管理コストの削減、コンプライアンスと文書追跡の改善につながります。重要な理由デジタルプロセスの導入状況を測定し、連携した電子署名機能による効率化の効果を定量化できます。入手先「契約締結済み」イベントの発生元が、連携済みのDocuSign eSignatureサービスかどうかを確認して判定できます。例 truefalse

必須推奨任意

契約管理のアクティビティ

契約管理におけるプロセスを正確に発見するために、イベントログに記録する主要なプロセス手順とマイルストーンです。

6 推奨 9 任意

	アクティビティ	説明
	契約を終了	有効期限の到来、解約、または双方の合意によって、契約ライフサイクルが正式に終了したことを示します。多くの場合、システム上でステータスを手動変更した時点で記録されます。
重要な理由プロセスにおける別の終了点です。契約の終了や期限切れを追跡することは、契約ライフサイクル全体の把握と更新分析に欠かせません。入手先ユーザーが契約のステータス項目を「Terminated」、「Expired」、「Cancelled」のいずれかに更新した時点で記録されます。このステータス変更のタイムスタンプが使用されます。取得契約の主要ステータス項目が終了状態に変更されたことから推定されます。イベントタイプ inferred
	契約を締結	最後に必要な署名者が書類に署名し、契約が正常に完了したことを示します。DocuSign eSignatureプラットフォームによって明示的に記録されます。
重要な理由契約作成プロセスにおける主要な成功終了点です。「Average Contract Cycle Time」の算出と、プロセス全体の処理量の測定に欠かせません。入手先 eSignatureワークフローが完全に完了した時点で、完了証明書と書類の監査ログにこのイベントのタイムスタンプが記録されます。取得最後の署名が付与された時点で、eSignatureコンポーネントによって自動的に記録されます。イベントタイプ explicit
	契約依頼を開始	このアクティビティは、契約ライフサイクルの正式な開始を示します。通常は、ユーザーが契約依頼フォームを送信するか、DocuSign CLM内で新しい契約レコードを作成した時点で記録され、関連するワークフローが開始されます。
重要な理由これはプロセスの主要な開始イベントです。このアクティビティを分析することは、契約処理量全体とエンドツーエンドのサイクルタイムの起点を測定するうえで欠かせません。入手先監査ログまたはワークフロー履歴から取得されます。契約レコードの作成時刻、または受付フォームの送信時刻に対応します。取得契約開始フォームの送信、または新しい契約オブジェクトの作成から記録されます。イベントタイプ explicit
	契約書を署名へ送信	最終承認済みの契約書について、電子署名プロセスを開始したことを示します。DocuSignの主要機能の一つであり、ユーザーがDocuSign eSignatureのエンベロープを通じて書類を送信した時点で記録されます。
重要な理由締結前の重要なマイルストーンです。この時点から締結までの時間を分析することで、署名回収の効率を把握し、「E-Signature Adoption Rate」KPIを支援できます。入手先書類の詳細履歴または監査証跡に記録される明示的かつ主要なイベントです。多くの場合、「Envelope History」と呼ばれます。取得 eSignatureのエンベロープが作成され、送信された時点でシステムに直接記録されます。イベントタイプ explicit
	法務レビューを開始	契約を正式に法務部門へ提出し、レビューとフィードバックを依頼した時点を示します。契約がワークフローの「Legal Review」段階に入った時点で記録される重要なステップです。
重要な理由法務レビューは、契約管理でよく発生するボトルネックです。所要時間を測定することは、「Legal Review Performance」ダッシュボードの作成と、迅速化の機会を特定するうえで重要です。入手先ワークフローの監査証跡から取得されます。タスクが法務チームに割り当てられた時刻、または契約ステータスが「In Legal Review」に変更された時刻が記録されます。取得契約が法務レビュータスクまたはキューに割り当てられた時点で、ワークフローエンジンから記録されます。イベントタイプ explicit
	社内承認を受領	必要な社内承認者全員が契約を承認したことを示すマイルストーンです。最後の承認者がワークフロー内のタスクを完了した時点で記録されます。
重要な理由契約が外部との交渉または締結に進める状態になったことを示す重要なマイルストーンです。この時点までの遅延から、社内調整上の問題を把握できます。入手先承認タスクが最終的な「Approved」状態になった時点で、ワークフロー履歴に記録されます。取得順次承認または並列承認のワークフローで、最後の承認者が承認した時点で記録されます。イベントタイプ explicit
	取引先との交渉を開始	取引先が応答し、通常は契約書へのフィードバックや修正版を提供したことを示します。外部関係者が新しい書類バージョンをアップロードした時点、またはステータスが社内レビュー段階に戻った時点から推定されます。
重要な理由このアクティビティは、「Negotiation Handoff Count Per Contract」KPIの分析に欠かせません。社内チームと取引先の間を頻繁に行き来している場合、交渉に摩擦が生じている可能性があります。入手先外部ソースから新しい書類バージョンを受領した時点、または取引先からフィードバックを受領したことを示すためにユーザーがステータスを手動で変更した時点から推定されます。取得契約が取引先側に渡った後、ステータスが「Internal Review」または「Drafting」に戻った時点から推定されます。イベントタイプ inferred
	取引先へ送信	契約書を外部の取引先に共有し、レビューと署名を依頼する操作を示します。通常は、DocuSign CLM内の「send」または「share」操作によって記録されます。
重要な理由外部関係者への引き渡しを示すアクティビティです。この段階ではプロセスを直接管理しにくいため、取引先側で費やされた時間を把握することが外部要因による遅延の特定に役立ちます。入手先監査証跡から取得されます。CLMから書類を添付したメールを送信した操作や、外部ポータルで共有した操作などが記録されます。取得プラットフォームの機能を使って書類を外部共有した、特定のユーザー操作から記録されます。イベントタイプ explicit
	契約更新を開始	既存契約の更新プロセスの開始を示します。通常は、契約所有者が手動で開始するか、契約の有効期限に基づいて自動的に開始されます。
重要な理由「Timely Contract Renewal Rate」KPIの追跡に欠かせないアクティビティです。組織が期限の近い契約をどれだけ先回りして管理しているかを把握できます。入手先「Renew Contract」操作が実行された時点で記録されます。この操作によって、元の契約に関連付けられた新しい契約レコードが作成されるか、更新ワークフローが開始されます。取得更新ワークフローを開始する特定のユーザー操作または自動トリガーから記録されます。イベントタイプ explicit
	契約書に修正を反映	交渉またはレビューの過程で、契約書に修正や変更を加えたことを示します。新しい書類バージョンをアップロードまたは保存するたびに記録されます。
重要な理由修正履歴の頻度を追跡することは、「Contract Rework Rate」KPIにとって重要です。修正回数が多い場合、条項が不明確、交渉が非効率、初稿の品質が不十分といった可能性があります。入手先契約に関連付けられた書類のバージョン履歴から導出されます。初稿の後に作成された各バージョンを、「Contract Redlined」イベントとして扱えます。取得 DocuSign CLMのリポジトリ内で新しい書類バージョンがアップロードまたは生成された時点で記録されます。イベントタイプ explicit
	契約書をリポジトリに保存	完全に締結された契約書を中央契約リポジトリに自動保存する、最後の管理ステップです。通常は署名プロセスの完了によって開始されます。
重要な理由適切な記録管理でプロセスを完了させます。締結前のライフサイクルの最後の時点であり、締結後の段階の開始点でもあります。入手先署名済み書類をアーカイブする最後のステップが完了した時点で、ワークフロー履歴から取得されます。取得契約締結が正常に完了した後の最後の自動ステップとして、ワークフローエンジンに記録されます。イベントタイプ explicit
	契約書案を作成	契約書の初稿を作成し、完成させたことを示します。通常は、書類の最初のバージョンをアップロードまたは生成し、システム内に保存した時点で取得されます。
重要な理由このアクティビティを追跡すると、レビュー開始前の作成・準備にかかった時間を把握できます。その後の修正頻度を測定するための基準値にもなります。入手先契約書の履歴にある最初の書類バージョンの作成時刻、またはステータスが「Drafting Complete」に変更された時点から推定します。取得契約IDに関連付けられた最初の書類バージョンの作成イベントを特定します。イベントタイプ inferred
	社内レビューを開始	このアクティビティは、作成した契約書を財務や業務部門などの社内関係者がレビューするために提出したことを示します。通常は、ユーザーがワークフロー内の「Internal Review」タスクを開始した時点で記録されます。
重要な理由レビュー段階の開始を示します。レビュー段階は、ボトルネックが発生しやすい箇所です。所要時間を分析することで、関係者からのフィードバックにおける遅延を特定できます。入手先契約が「Internal Review」ステータスに移行した時点、または法務以外の社内ユーザーにレビュータスクが割り当てられた時点で、ワークフロー履歴に記録されます。取得ワークフローが社内業務レビュー用の状態またはタスクに移行した時点で記録されます。イベントタイプ explicit
	社内承認へ送信	レビューを完了した契約を、指定された社内承認者による正式な承認に回した時点で発生します。承認ワークフローを開始した時点で記録されます。
重要な理由最終的な社内承認フェーズの開始を示します。所要時間は「Average Approval Phase Duration」KPIを構成する重要な要素です。入手先ユーザーが契約を承認に回し、承認者への割り当てを開始した時点で、ワークフロー履歴に明示的な操作として記録されます。取得「Send for Approval」または同様のワークフロー操作が実行された時点で記録されます。イベントタイプ explicit
	義務モニタリングを開始	締結後の管理を開始したことを示します。契約上の重要な日付や成果物を追跡する段階です。契約上の義務をモニタリングするタスクまたはサブプロセスを開始した時点で記録されます。
重要な理由「Post-Execution Obligation Adherence Rate」KPIに欠かせないアクティビティです。署名後に契約上の義務が適切に管理されているかを把握できます。入手先システム分析が必要です。通常は、主契約に関連付けられた義務追跡タスクまたはワークフローの作成時点から取得します。取得締結後の義務管理に関するタスクまたはワークフローが作成された時点で記録されます。イベントタイプ explicit

推奨任意

抽出ガイド

DocuSign CLMからデータを取得する方法

ステップ

前提条件とAPI設定：スクリプトを実行する前に、APIアクセスが有効なDocuSign CLMアカウントが必要です。DocuSign Adminパネルで、JWT Grant認証用に設定したIntegration Key（App ID）を作成します。RSAキーペアを生成し、公開鍵をDocuSignに登録します。User ID（APIユーザー名のGUID）、Integration Key、Account IDを控えておきます。
Python環境を設定：ローカルのPython環境を用意します。次のコマンドを実行して、APIリクエストとJWT認証に必要なライブラリをインストールします：pip install requests PyJWT pandas。データ処理とCSVエクスポートにはPandasが便利です。
スクリプトに認証情報を追加：Pythonスクリプトを開き、先頭にあるプレースホルダー変数を設定します。INTEGRATION_KEY、USER_ID、ACCOUNT_ID、OAUTH_BASE_PATH（デモアカウントの場合はaccount-d.docusign.comなど）、private.keyファイルのパスを指定します。
抽出パラメーターを設定：スクリプトのメイン部分で、契約を抽出する期間としてSTART_DATEとEND_DATEを定義します。契約の作成日で絞り込み、データ量を管理します。
Pythonスクリプトを実行：ターミナルからpython your_script_name.pyを実行します。スクリプトはまずDocuSign APIで認証し、アクセストークンを取得します。
APIからデータを取得：スクリプトは一連のAPI呼び出しを実行します。まず指定期間内のすべての文書（契約）を検索し、見つかった各契約について、ワークフロー履歴と文書バージョン履歴の詳細を取得します。
データを変換・対応付け：スクリプトはAPIから返された生のJSONを処理します。各契約のワークフロー履歴のステップと文書バージョンを順に処理し、ワークフローステップ名（「Legal Review」など）やイベントタイプ（新しいバージョンのアップロードなど）を、イベントログに必要な標準ActivityName（「Legal Review Started」、「Contract Redlined」など）に対応付けます。
属性を抽出：各アクティビティに必要な属性を抽出します。ContractIdは文書オブジェクトから、EventTimeはワークフローステップのタイムスタンプから取得します。ContractOwner、ContractType、ContractValueなどのメタデータは文書の属性リストから抽出します。
推定イベントを処理：ワークフローステップとして明示されないイベントを作成するロジックを含めます。たとえば、「Sent to Counterparty」イベントの後に新しい文書バージョンがアップロードされた場合、「Counterparty Negotiation Started」を推定します。
CSV出力を生成・確認：すべての契約と履歴の処理が完了したら、データを構造化し、Pandasを使ってdocusign_clm_event_log.csvというCSVファイルにエクスポートします。このファイルはProcessMindに直接アップロードできる形式です。

設定

API認証情報：JWT認証には、有効なIntegration Key、User ID（GUID）、RSA秘密鍵が必須です。これらをDocuSign Adminで設定し、通常は「signature」と「impersonation」の権限を付与します。
Account ID：特定のDocuSign Account IDが必要です。すべてのAPI呼び出しでベースURLの一部として使用します。
日付範囲：スクリプトではcreatedStartDateとcreatedEndDateパラメーターを使って契約を絞り込みます。抽出時間を管理し、APIのレート制限を避けるため、まずは過去3～6か月などの限定的な範囲から始めることを強く推奨します。
ワークフローの命名規則：スクリプトのロジックは、ワークフローステップ名（「Legal Review」、「Internal Approval」など）の一致に依存します。組織のDocuSign CLM設定で使われている正確なステップ名に合わせて、スクリプトのACTIVITY_MAP辞書を変更してください。
APIのレート制限：DocuSignのAPIには、1時間あたりの呼び出し回数を制限するレート制限があります。スクリプトにはこれを緩和するための基本的なtime.sleep()が含まれていますが、大規模なデータセットでは、より高度なバックオフ戦略が必要になる場合があります。
前提条件：User IDに関連付けられたユーザーアカウントには、抽出対象の契約、ワークフロー、文書を閲覧するための十分な権限が必要です。

a サンプルクエリ python

import requests
import jwt
import time
import datetime
import csv
import json

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your DocuSign account details
INTEGRATION_KEY = class="hl-string">"[Your Integration Key]"
USER_ID = class="hl-string">"[Your User ID GUID]"
ACCOUNT_ID = class="hl-string">"[Your Account ID]"
OAUTH_BASE_PATH = class="hl-string">"account-d.docusign.com" class=class="hl-string">"hl-comment"># Use account.docusign.com for demo, account.docusign.com for production

class=class="hl-string">"hl-comment"># --- Constants ---
SOURCE_SYSTEM = class="hl-string">"DocuSign CLM"
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

class=class="hl-string">"hl-comment"># --- Functions ---
def get_access_token(private_key_path):
    class="hl-string">"""Generates a JWT and exchanges it for an access token."""
    try:
        with open(private_key_path, class="hl-string">'r') as key_file:
            private_key = key_file.read()

        payload = {
            class="hl-string">"iss": INTEGRATION_KEY,
            class="hl-string">"sub": USER_ID,
            class="hl-string">"iat": int(time.time()),
            class="hl-string">"exp": int(time.time()) + 3600,
            class="hl-string">"aud": OAUTH_BASE_PATH,
            class="hl-string">"scope": class="hl-string">"signature impersonation"
        }

        token = jwt.encode(payload, private_key, algorithm=class="hl-string">'RS256')
        
        headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
        data = {
            class="hl-string">'grant_type': class="hl-string">'urn:ietf:params:oauth:grant-type:jwt-bearer',
            class="hl-string">'assertion': token
        }
        
        response = requests.post(fclass="hl-string">"https протокол://{OAUTH_BASE_PATH}/oauth/token", headers=headers, data=data)
        response.raise_for_status()
        return response.json()[class="hl-string">'access_token']

    except Exception as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def get_document_attribute(doc_attributes, attribute_name):
    class="hl-string">"""Helper function to safely get a value from the document's attribute list."""
    for attr in doc_attributes:
        if attr.get(class="hl-string">'name') == attribute_name:
            return attr.get(class="hl-string">'value')
    return None

def extract_event_log(access_token, start_date_str, end_date_str):
    class="hl-string">"""Main function to extract, process, and save the event log."""
    
    event_log = []
    api_base_url = fclass="hl-string">"https протокол://{OAUTH_BASE_PATH.replace('account', 'api')}/api/v2/accounts/{ACCOUNT_ID}"
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}', class="hl-string">'Content-Type': class="hl-string">'application/json'}
    
    class=class="hl-string">"hl-comment"># Activity mapping: Customize keys to match your workflow step names
    ACTIVITY_MAP = {
        class="hl-string">'Start': class="hl-string">'Contract Request Initiated',
        class="hl-string">'Drafting': class="hl-string">'Contract Drafted',
        class="hl-string">'Internal Review': class="hl-string">'Internal Review Started',
        class="hl-string">'Legal Review': class="hl-string">'Legal Review Started',
        class="hl-string">'Send for Internal Approval': class="hl-string">'Internal Approval Sent',
        class="hl-string">'Internal Approval': class="hl-string">'Internal Approval Received',
        class="hl-string">'Send to Counterparty': class="hl-string">'Sent to Counterparty',
        class="hl-string">'Send for Signature': class="hl-string">'Contract Sent for Signature',
        class="hl-string">'Executed': class="hl-string">'Contract Executed',
        class="hl-string">'Archive': class="hl-string">'Contract Stored in Repository',
        class="hl-string">'Start Obligation Monitoring': class="hl-string">'Obligation Monitoring Started',
        class="hl-string">'Initiate Renewal': class="hl-string">'Contract Renewal Initiated',
        class="hl-string">'Terminate': class="hl-string">'Contract Terminated'
    }
    
    class=class="hl-string">"hl-comment"># 1. Search for documents (contracts)
    search_url = fclass="hl-string">"{api_base_url}/search"
    search_params = {
        class="hl-string">'q': fclass="hl-string">'IsLatestVersion:true AND CreatedDate:[{start_date_str} TO {end_date_str}]',
        class="hl-string">'limit': 100, class=class="hl-string">"hl-comment"># Max limit per page
        class="hl-string">'offset': 0
    }
    
    while True:
        print(fclass="hl-string">"Searching for documents with offset {search_params['offset']}...")
        response = requests.get(search_url, headers=headers, params=search_params)
        if response.status_code != 200:
            print(fclass="hl-string">"Error searching documents: {response.text}")
            break
        
        data = response.json()
        documents = data.get(class="hl-string">'value', [])
        
        if not documents:
            print(class="hl-string">"No more documents found.")
            break

        for doc in documents:
            contract_id = doc.get(class="hl-string">'id')
            doc_attributes = doc.get(class="hl-string">'attributes', [])
            
            base_event_data = {
                class="hl-string">'ContractId': contract_id,
                class="hl-string">'ContractStatus': get_document_attribute(doc_attributes, class="hl-string">'Contract Status'),
                class="hl-string">'ContractOwner': get_document_attribute(doc_attributes, class="hl-string">'Contract Owner'),
                class="hl-string">'ContractType': doc.get(class="hl-string">'documentTypeName'),
                class="hl-string">'ContractValue': get_document_attribute(doc_attributes, class="hl-string">'Contract Value'),
                class="hl-string">'Counterparty': get_document_attribute(doc_attributes, class="hl-string">'Counterparty Name'),
                class="hl-string">'ExpirationDate': get_document_attribute(doc_attributes, class="hl-string">'Expiration Date'),
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># Can be populated if logic is added
                class="hl-string">'CycleTime': None class=class="hl-string">"hl-comment"># Requires post-processing
            }
            
            class=class="hl-string">"hl-comment"># 2. Get workflow history for each document
            workflow_url = fclass="hl-string">"{api_base_url}/documents/{contract_id}/workflow"
            workflow_response = requests.get(workflow_url, headers=headers)
            
            if workflow_response.status_code == 200:
                workflow_data = workflow_response.json()
                
                class=class="hl-string">"hl-comment"># Process workflow steps
                for step in workflow_data.get(class="hl-string">'workflow', {}).get(class="hl-string">'steps', []):
                    step_name = step.get(class="hl-string">'stepName')
                    if step_name in ACTIVITY_MAP:
                        event = base_event_data.copy()
                        event[class="hl-string">'ActivityName'] = ACTIVITY_MAP[step_name]
                        event[class="hl-string">'EventTime'] = step.get(class="hl-string">'started')
                        event[class="hl-string">'EndTime'] = step.get(class="hl-string">'completed')
                        event_log.append(event)
                        
                        class=class="hl-string">"hl-comment"># Special case for final approval
                        if step_name == class="hl-string">'Internal Approval' and step.get(class="hl-string">'completed'):
                            event_approval = base_event_data.copy()
                            event_approval[class="hl-string">'ActivityName'] = class="hl-string">'Internal Approval Received'
                            event_approval[class="hl-string">'EventTime'] = step.get(class="hl-string">'completed')
                            event_log.append(event_approval)
                            
            class=class="hl-string">"hl-comment"># 3. Get document version history for class="hl-string">'Contract Redlined' events
            versions_url = fclass="hl-string">"{api_base_url}/documents/{contract_id}/versions"
            versions_response = requests.get(versions_url, headers=headers)
            if versions_response.status_code == 200:
                versions_data = versions_response.json()
                for version in versions_data.get(class="hl-string">'value', []):
                    if version.get(class="hl-string">'versionNumber', 0) > 1: class=class="hl-string">"hl-comment"># Version 1 is the initial draft
                        event = base_event_data.copy()
                        event[class="hl-string">'ActivityName'] = class="hl-string">'Contract Redlined'
                        event[class="hl-string">'EventTime'] = version.get(class="hl-string">'createdDate')
                        event_log.append(event)
        
        class=class="hl-string">"hl-comment"># Handle pagination
        search_params[class="hl-string">'offset'] += len(documents)
        if len(documents) < 100:
            break class=class="hl-string">"hl-comment"># Last page

        time.sleep(1) class=class="hl-string">"hl-comment"># Simple rate limit mitigation
        
    class=class="hl-string">"hl-comment"># 4. Save to CSV
    if not event_log:
        print(class="hl-string">"No events were extracted.")
        return

    class=class="hl-string">"hl-comment"># Sort events by contract and time for logical order
    event_log.sort(key=lambda x: (x[class="hl-string">'ContractId'], x[class="hl-string">'EventTime'] or class="hl-string">''))

    fieldnames = [
        class="hl-string">'ContractId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'ContractStatus',
        class="hl-string">'ContractOwner', class="hl-string">'ContractType', class="hl-string">'ContractValue', class="hl-string">'Counterparty',
        class="hl-string">'ExpirationDate', class="hl-string">'CycleTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate'
    ]
    
    with open(class="hl-string">'docusign_clm_event_log.csv', class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
        writer.writeheader()
        writer.writerows(event_log)
        
    print(fclass="hl-string">"Successfully extracted {len(event_log)} events to docusign_clm_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># --- Execution --- 
    PRIVATE_KEY_PATH = class="hl-string">"./private.key" class=class="hl-string">"hl-comment"># Path to your RSA private key file
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
    
    access_token = get_access_token(PRIVATE_KEY_PATH)
    if access_token:
        extract_event_log(access_token, START_DATE, END_DATE)

始める準備はできていますか？

このデータテンプレートを使ってプロセスマイニングを始め、契約管理ワークフローの効率化につなげてください。

改善ガイドに戻るテンプレートをダウンロード

遅延を解消：今すぐ契約管理を効率化

非効率を特定し、サイクル時間を30％短縮して、コンプライアンスを強化します。

無料トライアルを開始

クレジットカード不要 • 数分で開始できます

契約管理データテンプレート

契約管理データテンプレート

契約管理の属性

契約管理のアクティビティ

抽出ガイド

DocuSign CLM REST APIを使用したPythonスクリプト

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

遅延を解消：今すぐ契約管理を効率化

プライバシーを大切にしています