ご挨拶
毎々お世話になっております、LayerXから三井物産デジタル・アセットマネジメント（以下、MDM）に出向中の片桐（@akinama3）と申します。
本記事については下記の後編になりますので、是非ご一読下さいますと幸いです。
前回の記事で、SaaSを活用して意思決定と業務執行をシームレスにした話を取り上げましたが、 今回はそこで利用した電子契約SaaSであるDocuSignについて、DocuSign eSignature APIとDocuSign Connectを中心にお話致します。
電子契約とは
電子契約については、COVID-19によるリモートワーク推進等で認知・利用されるようになってきました。 電子契約の詳しいメリットについては、 下記が分かりやすいと思います。 詳しい部分は専門家におまかせし、本記事では技術的な観点にフォーカスしたいと思います。
www.cloudsign.jp www.docusign.jp
とはいえ、DocuSignの機能が膨大であり、用語も特殊なので基本的な部分をさらっと紹介していきます。
DocuSignのアカウント体系
業務の自動化観点でDocuSignを契約する場合、プラン選定の注意点があります。 DocuSignにはWebから申し込めるWebプランと、個別の見積もりによって契約する通常プランがあり、 DocuSign eSignature APIとDocuSign Connectは、Webプランでは利用できません。 そのため、上記を利用する場合には見積もりによる通常プランを選択する必要があります。
料金
通常プランには、Business Pro、Enterprise Pro というプランがあり、 Enterprise Proが全機能を使えるプランになっており、Business ProはDocuSign eSignature APIとDocuSign Connectが利用でき、SSOなどの追加機能はオプションとなるプランです。
MDMでは、Business Proの契約で必要十分だったのでBusiness Proを契約しております。
契約によって一通あたりの金額決まる
多くの電子契約SaaSでは、プランごとに月額料金と１通あたりの料金が決められていることが多いかと思います。 DocuSignの通常プランは月額料金等は存在せず、プランとオプションによって１通あたりの金額が決まります。 1年に300通送信する契約であれば、１通あたりの金額 × 300が請求金額となります。（サポート料金等は別途）
DocuSign用語
アカウント
下記のように、アカウントという単位で契約を行います。 アカウント単位で印影の登録などアカウント全体で共有する設定やブランド設定による署名画面のカスタマイズも可能です。
Enterprise Pro プランでは、複数のアカウントを組織という単位で管理することもできます。 親会社が一括で管理したり、プロジェクト毎にアカウントを分けたりする必要がある場合に有用です。
ユーザー
アカウントに複数のユーザを持つことができます。 通常プランであればユーザ数の作成に制限がないため、各メンバーのユーザーに加え、自動化するサービス毎に作成することもできます。
- ユーザー権限として、Admin / Sender / Viewerの設定ができる
- ユーザーをグループに所属させることができる（部署の設定等に利用できる）
- ユーザーのエンベロープを他ユーザに公開するかを設定できる（共有エンベロープ）
エンベロープ
電子契約の送信は エンベロープ という単位で行います。 エンベロープには下記の様な設定が必要になり、作成・送信ともに API 経由で実行できます。
- どのドキュメントについて電子契約を行うか（ドキュメントという概念）
- どの部分に署名をしたり、フォーム入力したりしてもらうか（タブという概念）
- 誰にどの順番で署名・閲覧してもらうか（受信者という概念）
MDMで行った自動化においても、上記をAPI経由で設定し自動的に送信が行われるようにしています。
DocuSign eSignature API
DocuSign eSignature APIでは、DocuSignのダッシュボードからできることは基本的に何でもできます。 エンベロープの作成だけではなく、アカウントの各種設定、ユーザー管理もAPI経由で実施できるので、各種管理の自動化等も可能になります。
MDMでは、「甲印」「乙印」「丙印」などのアンカー用文字列をドキュメントに忍ばせることによって、署名場所の設定もAPIで自動化しています。
ただ、非常に悔しいのですが、現状やりたくてもできないポイントとして API経由で自動的に署名する があります。 前回お話した、意思決定と業務執行のシームレス化 のシステムに於いて、現状のシステムでは 稟議の承認 と 契約書の署名押印 の二度手間が発生しています。
稟議で承認されていれば、自動的に署名・押印されている状態にするのが理想です。今後のDocuSign eSignature APIの進化に期待したいと思います。
利用するための準備
DocuSign eSignature APIを利用するためには、管理画面からDocuSign eSignature APIの APIインテグレーションアプリを作成する必要があります。 認証についてはOAuth 2.0によって行うことができるので、サービスの特性に合わせて選択して下さい。
MDMでは自動化アプリの都合上、JWT Grantによるサービスインテーグレーションを採用し、 各ユーザから予めエンベロープ送信権限をアプリに委譲してもらっておく事によって、システムから自動的にエンベロープを送信できるようにしています。
今後、自社で稟議ワークフローを構築するなどの内製化が進んだ場合には、 認可コードフローによりアクセストークンを取得して送信するなどできると、よりセキュアかつ運用が楽になるのではと考えています。
DocuSign eSignature API の認証方法
DocuSign eSignature API Reference
DocuSign Connect
DocuSign Connectは、DocuSignの自動化に必要なコンポーネントの一つです。 いわゆる Webhook の機能で、締結完了を始めとしたエンベロープの各種イベントに対して発行できます。 開発を開始したタイミングでは、XML形式のWebhookしか対応しておらず若干めんどくさい状態でしたが、 現在はJSONによるWebhookに対応しているので、割と簡単に実装できるはずです。
MDMにてDocuSignを採用した観点として、下記のような観点が挙げられました。
発行できるイベントタイプが豊富
署名だけではなく、受信確認に対してもWebhookが設定できるので受信・開封したかどうかもシステムで管理することができます。
エンベロープ送信者毎にWebhookが設定できる
サービス専用のユーザーを用意し、そのサービスユーザが送信したエンベロープのみをWebhook対象とできるので、 雑多なWebhookが飛び交うことを防ぐことができます。 （ガバナンス・セキュリティ観点で有益）
HMAC署名検証が可能
WebhookのヘッダにHMAC検証用の署名を付与でき、実際にDocuSignから送られたということを検証できます。 HMAC署名用のConnect Keyについては複数登録でき、キーローテーションも可能です。
mTLSに対応可能
契約書や宛先といった情報のやり取りをよりセキュアに実施できます。
Webhook のログ・エラーが詳細に取得できる
管理画面からWebhookのログをリクエスト・レンスポンスを詳細に確認できるのでデバッグしやすくなっています。
DocuSign ConnectのデバッグTips
直接DocuSign Connectとは関係ありませんが、WebhookのHMAC署名検証やリクエストを変更してデバッグするときに、ngrokのinspect機能が役に立ちました。 開発環境でngrok経由でリクエストを受けるようにしておき、Modify Replayにて各種ヘッダを変更したり、 リクエストボディのStatus等を変更したりしながら動作検証をするということでデバッグ効率が向上しました。
MDMでの開発の進め方
ようやく一通り各種コンポーネントについて説明が終わったので、MDMのシステムではどのように実装したのかをお話したいと思います。
DocuSign関連部分の構成概要
DocuSign Sandboxを利用する
DocuSignは正式契約せずとも、DocuSign Sandboxを利用してシステム構築が可能です。 MDMでも、まずはSandbox 上にてアプリ構築を試して見てから、実際に正式契約するという形を取りました。
注意点としては、DocuSign SandboxはEnterprise Pro準拠で全ての機能が使える状態になっているため、 本契約で利用したい機能をしっかりとリストアップしておくことが重要です。
開発時に困ったポイント
エンベロープ送信権限の委譲のやり方がイマイチわからない
下記を参照することで解決できました。
基本的には各担当者がDocuSignにログインした状態で、 権限委譲甩のスコープを付与したAPIインテグレーションアプリごとのURL生成して展開し、 それ経由で権限移譲をブラウザ上で行ってもらう形になります。
エンベロープの送信者、署名者をしっかり整理する
誰の権限で送信し、社内の誰が署名して、社外の誰が署名するかをしっかり整理して置く必要がありました。 この整理により、システムのどの部分で情報を入力しなければいけないかが明確になりました。 （稟議情報入力時に入れるのかどうかなど）
アセットマネジメント業界においては、案件の秘密保持契約書を自社の署名のみで差し入れるパターンが多く、 また、MDMが持っている案件への差入れ依頼も自動化することを考えると、下記のようになります。
本番環境でアプリを使うためには審査がある
これは完全に盲点でした。
DocuSIgn Sandboxで開発をおこない、開発環境にて動作確認を行った後、いざ本番稼働させようとした時に管理画面からAPIインテグレーションアプリ作成の項目が見当たりません。 色々と調べていると、本番環境では Go Live という審査プロセスが存在することがわかり、若干対応コストがかかりました。 Go Live プロセスについては、DocuSign Sandboxアカウントで作成したアプリを本番アカウントに昇格させるプロセスになります。
基本的に、API が正しく実行できているかの確認プロセスを挟むだけなので普通にしっかりと作って問題なく通過すると思います。 開発環境から本番環境への以降は、環境変数等でインテグレーションキーやエンドポイント設定を本番向けに対応するだけで大丈夫です。
あなたの力が必要です
上記の通り、雰囲気で「APIもWebhookもあるからいけるやん」みたいなノリでやると痛い目を見ることが多く、 業務知識、ツール自体の知識、エンジニアリングの総合格闘技感があります。
というわけで前回に引き続き、Coporate Opsで100Xを達成したい方、下記よりお待ちしております
