はじめまして。2018年11月にクラウドサインのディレクターチームにジョインしました、ゆぎと申します。新入りの若輩メンバーとして、日々学びながら業務に勤しんでおります。

この記事では、先日リリースされた「合意締結証明書をAPI経由で取得できる」機能のご紹介とその経緯について書いていきます。

そもそも合意締結証明書とは？

機能のご紹介の前に、クラウドサインが提供している合意締結証明書そのものについて簡単にご説明します（もう知ってるよ！という方は読み飛ばして下さいね）。

クラウドサインのFAQを参照すると、

合意締結証明書とは、いつ誰がどの書類について合意をしたかということが簡単に確認できるよう、クラウドサインが発行するものです。

と記載されています。

これだけでは伝わらないと思うので、順を追ってご説明します。

紙の契約書においては一般的に、契約に際して当事者同士による署名や押印がなされます。そして民事訴訟法において、本人（もしくは代理人）の署名または押印があれば、その文書は成立していると推定されます。もっと噛み砕くと、しっかりと押印されていればその契約書が証拠として成り立つ、と言えます。

一方クラウドサインが提供している電子契約では、書類のPDFファイルに電子署名やタイムスタンプを施すことによってその契約書の証拠力を担保しています（このあたりは「サインのリ・デザイン」で詳しく解説されています）。
この「証拠力」はPDFファイルをクラウドサイン上からダウンロードし、「Adobe Acrobat Reader」で当該ファイルを開くと確認することができます。

「Adobe Acrobat Reader」の署名パネル

「証拠力」という観点では、書類上の署名や押印の有無にかかわらず、電子契約は紙と同等の証拠力を担保することができます。

しかし一方で、日常業務においては

- 「Adobe Acrobat Reader」というソフトウェアで書類を開く必要がある
- 紙に印刷する場合は、電子署名やタイムスタンプを目で確認することができない

という点で、利便性に欠ける面がありました。その利便性を向上させるために提供されているものが「合意締結証明書」です。

合意締結証明書サンプル

クラウドサインが提供している合意締結証明書では、画像の通り以下の内容が確認できます。

- 合意締結証明書のダウンロード日時
- ファイルのタイトル
- ファイルのファイル名
- ファイルの書類ID
- 契約者ごとの同意した日時
- 契約者名
- 契約者のメールアドレス

あくまで契約の証拠力は電子署名やタイムスタンプが施されたPDFファイルによって担保されていますが、合意締結証明書の内容を確認することで、誰が、いつ、どんな書類について合意締結を行ったのかを簡易的に把握できます。

今回リリースした機能でできること

さて改めて、今回のリリースによって何ができるようになったのか？ということについて書いていきたいのですが、端的にお伝えしますと記事タイトルの通りで、

これまでクラウドサインにアクセスしてダウンロードしなければ取得できなかった合意締結証明書が、API経由でも取得できるようになった

という一文に集約されます。

API仕様の詳細はクラウドサインWeb API 利用ガイドやクラウドサイン Web API 仕様書に記載されていますので、ここでは割愛し、開発の経緯や想いについてお伝えしていきたいと思います。

合意締結証明書はとても便利で、だからこそ、ボトルネックだった

当然と言えば当然なのですが、契約に関するフローや契約の形態はその企業、部署、場面ごとに様々です。

契約のやり方が違えば、クラウドサインの使い方も異なります。WEB上で契約締結〜書類管理まで一気通貫してクラウドサインを使用していただいているのはもちろんのこと、自社の基幹システムにAPIとして組み込み、クラウドサインの機能の一部をそれぞれのフローに最適化してお使いいただくことも多くあります。

例えば以下のような事例が考えられます。

1. 契約書の送信先情報は自社で使用しているシステムのデータベースで管理
2. 契約締結部分のみクラウドサインをAPI経由で使用
3. 締結済み書類は自社で使用しているシステムで保管

すでに浸透した運用を変更することなく、契約締結に関する部分だけをクラウドサインで簡易にしたい、という場合です。

それぞれの企業によって契約フローや使用しているシステムは異なるため、クラウドサイン単体で、すべてのユースケースやパターンに適合することは、容易ではありません。

よって、場合によってはクラウドサインの機能全てを利用いただき、既存フローやシステムを変更いただくよりも、API経由で、既存フローに合わせて機能の一部を利用していただくことの方が、合理的でスマートであると考えられます。

さてここで一旦、合意締結証明書の件に話を戻します。先にお伝えしたように、合意締結に関する情報が簡易的に確認できる合意締結証明書は業務上、利便性が高い有用なもの、と言えます。

これらをまとめると

- クラウドサインの機能をAPIで提供することは、各社ごとの運用フローや基幹システムに合わせて使っていただけるので合理的である
- 合意締結証明書はクラウドサインを使った日常業務の運営において、利便性が高い有用なものである

ということになります。

しかし、これまで合意締結証明書はAPI経由で提供されていませんでした。

上のまとめから考えますと、APIは合理的で合意締結証明書も利便性が高いのに、「合意締結証明書はAPI経由で取得できない」という事実は、クラウドサインAPIの利便性、ひいてはクラウドサイン自体のボトルネックたり得たことがお分かりいただけるかと思います。

契約の締結まではAPI連携によって自社の基幹システムとシームレスに行うことができるのに、合意締結証明書のダウンロードのためだけにクラウドサインにログインする……という非合理的な作業を生み出してしまっていたことになります。

リリースした機能としては（繰り返しになりますが）「これまでクラウドサインにアクセスしてダウンロードしなければ取得できなかった合意締結証明書がAPI経由でも取得できるようになった」ですが、その機能の価値以上に、クラウドサインAPIの利便性を大きく底上げすることができたのではないかと考えています。

まとめ

先日リリースされた「書類情報API」に加え、今回「合意締結証明書API」をリリースしました。

クラウドサインで提供しているAPIは多くの企業様にご活用いただいている一方、もっと拡張してほしいというお声も多くいただいております。
今回の「合意締結証明書API」の機能はいただいた声に対する回答の第一歩でしかありません。
既述の通り、クラウドサインそれだけですべてのお客様のニーズ全てに応えることは、SaaSプロダクトの特性上非常に難しいです。しかし、岩熊の記事にもありますが、であればこそのAPIで、ユースケースに応じてクラウドサインを柔軟に利用いただけるよう、今後もAPIの改善を続けていきたいと考えております。

そのために、皆様からいただいたフィードバックはありがたく拝読し、よりよいプロダクトを提供していけるよう、チーム全員で日々精査・検討を行っております。
引き続き、忌憚なきご意見をいただけますと幸いです。

▶フィードバックシートと開発進捗はこちら