電子契約のAPI連携｜kintoneや基幹システムとつなぐときの考え方

そもそも電子契約のAPI連携は必要か、判断する基準

まず考えたいのは、連携しないと本当に困っているのか、という点です。電子契約サービスの多くは管理画面から相手のメールアドレスと書類をアップロードすれば送信できます。月に数件しか送らないのであれば、その操作にかかる時間より、連携の設計と保守にかかる手間のほうが大きくなることがあります。

判断の目安として、次の順に見てください。第一に、月の送信件数。毎月コンスタントに数十件以上送っているなら、自動化の効果が出やすい水準です。第二に、契約の元になる情報がどこにあるか。kintoneや販売管理システムに顧客名・金額・期間がすでに入っているなら、それを転記している時間がそのまま削減対象になります。第三に、締結後の情報をどこで追うか。締結済みPDFを手でダウンロードして共有フォルダに置いているなら、そこが一番の自動化ポイントです。

逆に、契約書の内容が毎回大きく異なる、相手ごとに条件を交渉してから作る、といった非定型の契約が中心なら、送信自体の自動化はあまり効きません。この場合は「送信は手動、締結後の記録だけ自動」という部分連携から考えると無理がありません。

連携の方法は3通り。公式コネクタ→連携ツール→自社開発の順に検討する

電子契約サービスと他のシステムをつなぐ手段は、大きく3つに分かれます。一つ目は、電子契約サービス側が公式に用意している連携機能や、他社が提供する連携アプリ・プラグインを使う方法です。クラウドサインやマネーフォワード クラウド契約のように、kintone用のプラグインや、販売管理・ワークフロー製品との連携メニューを公開しているサービスがあります。対応している連携先と、できることの範囲は各社の公式サイトで最新の情報を確認してください。

二つ目は、iPaaSと呼ばれる連携ツールを間に挟む方法です。ノーコードやローコードで、「kintoneのレコードのステータスが◯◯になったら電子契約を送信する」といった処理を組めます。自社でサーバーを用意せずに済み、条件分岐や通知も画面上で設定できるのが利点です。

三つ目が、電子契約サービスが公開しているAPIを使って自社で実装する方法です。自由度は最も高い一方、認証情報の管理、エラー時の再送、仕様変更への追随といった運用がずっと続きます。検討の順番は、公式コネクタ→連携ツール→自社開発です。上から順に「これで足りるか」を確かめ、足りない部分だけ下の手段に落とすと、無駄な開発を避けられます。

kintoneや基幹システムとつなぐとき、どこを自動化するか

連携の設計では、契約の流れを「作る・回す・送る・戻す・しまう」の5つに分けて考えると整理しやすくなります。作るは契約書の文面生成、回すは社内承認（ワークフロー）、送るは相手への送信依頼、戻るは相手の署名完了、しまうは締結済みファイルの保存と台帳登録です。

このうち、最初に手をつける価値が高いのは「戻る・しまう」です。締結が完了したタイミングで、ステータスと締結日、締結済みPDFのリンクをkintoneのレコードに書き戻す。これだけで、誰かが管理画面を見に行って手でダウンロードする作業がなくなり、契約台帳が自動で埋まります。更新期限のアラートも、台帳が正確であってこそ機能します。

次が「作る・送る」です。kintoneのレコードから差込データを渡してテンプレートに流し込み、承認済みになったら送信する、という流れです。ただし、宛先メールアドレスの誤りや、金額欄の空白はそのまま相手に届いてしまいます。自動送信にする場合は、送信直前に人が内容を確認するステップを1つ残す設計にしておくと安心です。社内承認そのものは、既存のワークフロー製品を使っているならそちらに寄せ、電子契約側は「承認が終わったものを送る装置」と割り切ったほうがシンプルになります。

進め方の手順：現状整理から本番運用まで

最初にやることは、今の契約の流れを紙に書き出すことです。誰が起案し、誰が承認し、誰が送信し、締結後のファイルはどこに置かれているか。この時点で、承認者が実質1人だった、台帳が2か所にあった、といった事実が見えてきます。連携の前に業務のほうを整理できると、開発量が減ります。

次に、対象とする契約の種類を1つに絞ります。業務委託基本契約、注文請書、雇用契約書など、定型で件数が多いものが向いています。絞ったうえで、電子契約サービスの公式サイトで、使いたい連携先に対応した機能が用意されているかを確認します。用意されていれば、テスト環境や試用の範囲で、実際に自社のテンプレートを1本通してみます。

動作が確認できたら、担当者2〜3名で1〜2か月ほど並行運用します。この期間に、相手先が署名しないまま止まった場合の督促、送信を間違えたときの取り消し、差し替えの手順を決めておきます。最後に、対象契約の範囲を広げ、社内マニュアルに「例外が起きたときは誰に言うか」を書いて完了です。なお、締結済みデータの保存方法は電子帳簿保存法などの制度に関わるため、要件の詳細は国税庁など所管官庁の資料を確認し、判断に迷う点は税理士にご確認ください。

よくあるつまずきと、事前に決めておくこと

一つ目は、権限と認証情報の管理です。API連携ではアクセストークンやAPIキーを使いますが、これを設定した担当者が退職して誰も分からなくなる、という事態が起きがちです。誰が発行し、どこに保管し、いつ更新するかを最初に文書化してください。また、電子契約サービス側の利用者権限と、kintone側のレコード閲覧権限がずれていると、契約情報が想定外の範囲に見えてしまうことがあります。

二つ目は、失敗したときの検知です。連携は動いているときは静かですが、止まってもやはり静かです。送信が失敗した、書き戻しが漏れた、といった異常を、担当者のチャットや管理者メールに通知する仕組みをあわせて用意しておきましょう。

三つ目は、相手方の都合です。相手が電子契約に応じない、押印を求める、自社指定のサービスで送りたいと言ってくる、というケースは一定数あります。紙や他社サービスで締結した契約も同じ台帳に載る設計にしておくと、後から契約の全体像が追えなくなる事態を避けられます。契約書の効力や本人確認の水準に関わる論点については、扱う契約の種類に応じて弁護士に相談しておくと判断がぶれません。

サービスを選ぶときに見るポイント

連携を前提に電子契約サービスを選ぶなら、料金より先に確認したいのは次の点です。APIとWebhook（締結完了などのイベントを外部に通知する仕組み）が公開されているか。開発者向けドキュメントが誰でも読める形で公開されているか。テスト用の環境が用意されているか。この3つが揃っていると、実装前に実現可能性を自分たちで確かめられます。

次に、使いたい連携先の対応状況です。kintone、販売管理システム、ワークフロー製品、会計サービスなど、どこまで公式に連携できるかは各社で異なります。連携アプリが有償オプションになっている場合もあるため、機能と料金は各社の公式サイトで最新の情報を確認してください。

会計や請求をひとつのシリーズで揃えている会社であれば、同じシリーズ内の契約サービスを使うと、取引先マスタを共有できて管理が楽になることがあります。一方、取引先から指定されるサービスが決まっている業界なら、その指定に対応しやすい構成を優先する、という選び方もあります。どちらが向くかは、自社の契約件数と相手先の顔ぶれで決まります。

契約の形式や保存方法は、税務・法務の取り扱いに影響することがあります。導入設計の段階で、保存要件については税理士に、契約条項や本人確認の扱いについては弁護士に、雇用契約を電子化する場合は社会保険労務士に、それぞれ確認しておくと、後から作り直す手間を減らせます。

よくある質問