メインコンテンツへスキップ

電子契約サービスの選び方|方式の違いと、基幹・ワークフローとつなぐ設計

2026.09.20

電子契約サービスは、契約書に押印して郵送する代わりに、契約データに電子署名を付けて締結する仕組みです。導入を決めたあとに実際の検討が始まると、判断が難しいのは機能の多さではなく、次の2点に絞られてきます。

  • 自社が結んでいる契約に、どちらの署名方式が合っているのか
  • 締結したあとの契約データを、基幹システム・ワークフロー・文書管理にどうつなぐのか

サービス比較サイトに並ぶ機能や料金の一覧は、この2つにはほとんど答えてくれません。本記事では、電子契約の法的な位置づけを電子署名法の条文と政府のQ&Aで確認したうえで、システムを開発する立場から「導入後につなぐこと」を中心に、選定基準と連携の設計を整理します。

電子契約サービスとは?何を電子化するのか#

電子契約サービスは、契約の「合意」「署名」「保管」「更新」という4つの工程を、紙を介さずデータのまま扱えるようにする仕組みです。紙の契約書をスキャンして電子化するだけのものではなく、締結そのものをデータ上で完結させる点が違います。各工程で起きることは次のとおりです。

  • 合意:契約内容を確定し、社内の決裁を通す
  • 署名:契約当事者が電子署名を付けて締結する
  • 保管:締結済みの契約データを、探せる形で保存する
  • 更新:期間満了・自動更新・解約の期日を管理する

導入の動機になるのは「署名」の工程ですが、実務で効いてくるのはほかの3つです。合意(承認)が既存のワークフローとつながらなければ稟議は紙のまま続きますし、保管と更新が仕組みに乗らなければ、契約書がサービスの中に溜まるだけで、契約台帳は別途Excelで管理し続けることになります。

署名の方式は2つある#

電子契約サービスの方式は、誰の署名鍵で電子署名を行うかによって大きく2つに分かれます。契約当事者それぞれの署名鍵を使う当事者署名型と、利用者の指示を受けてサービス提供事業者が自社の署名鍵で署名する事業者署名型です。

どちらが優れているという話ではなく、相手方に何を求められるかが違います。次の4つの観点で比べてください。

横スクロールできます
観点当事者署名型事業者署名型
署名の主体契約当事者それぞれの署名鍵サービス提供事業者の署名鍵
本人確認の方法認証局が発行する電子証明書メール認証(強度は設定次第)
相手方の負担相手方も電子証明書の準備が必要メールを受け取れば締結できる
向く契約本人性を厳格に示したい契約取引先が多く件数も多い契約
当事者署名型と事業者署名型を、署名の主体・本人確認の方法・相手方の負担・向く契約の4つの観点で比較したマトリクス
当事者署名型と事業者署名型を、署名の主体・本人確認の方法・相手方の負担・向く契約の4つの観点で比較したマトリクス

両方の方式に対応しているサービスもあるため、契約の類型ごとに使い分ける前提で選ぶのが現実的です。

なお、事業者署名型の本人確認の強度は方式に固定されているわけではなく、締結時にどこまでの認証を求めるかの設定で決まります。この点は、次の「3条の「推定」は何を意味するのか」とあわせて確認してください。

メリットと、導入しても残る手間#

電子契約に移して消えるのは、印刷・製本・押印・郵送・原本の物理保管といった工程です。締結までの日数が縮み、契約書を探す時間も減ります。

一方で、次の手間は残るか、むしろ新しく発生します。

  • 取引先への説明と、締結方法の合意を取り付ける作業
  • 紙で締結する契約が残る間の、紙と電子の二重管理
  • 社内規程(印章規程・職務権限規程)の改定
  • 契約データを他システムへ渡すための連携の設計と保守

「電子契約にすれば業務が減る」ではなく、「どの工程が消え、どの工程が新しく要るか」で見たほうが、導入後のギャップが小さくなります。

電子契約に法的効力はあるのか?(電子署名法2条・3条)#

結論から言えば、あります。民法(明治二十九年法律第八十九号)|e-Gov法令検索の第五百二十二条第二項は、「契約の成立には、法令に特別の定めがある場合を除き、書面の作成その他の方式を具備することを要しない」と定めており、書面によらずに結んだ契約も成立します。そのうえで、電子データが裁判で証拠として扱われる場面に備え、電子署名法が「電子署名」とは何かを定めた2条1項と、電磁的記録が真正に成立したものと推定される要件を定めた3条を置いています。

電子署名法2条1項の「電子署名」とは何か#

電子署名及び認証業務に関する法律(平成十二年法律第百二号)|e-Gov法令検索の第二条第一項は、「電子署名」を、電磁的記録に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものと定義しています。

  • 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること
  • 当該情報について改変が行われていないかどうかを確認することができるものであること

つまり「誰が作ったかを示す」ことと「改ざんされていないかを確認できる」ことの両方を満たす措置が、電子署名です。

事業者署名型は署名を行うのがサービス提供事業者であるため、この定義に当てはまるのかが論点になりました。この点は利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A|総務省・法務省・経済産業省(令和2年7月17日)の問2で整理されています。同Q&Aは、「技術的・機能的に見て、サービス提供事業者の意思が介在する余地がなく、利用者の意思のみに基づいて機械的に暗号化されたものであることが担保されていると認められる場合であれば」、「当該措置を行った者」はサービス提供事業者ではなくその利用者であると評価し得るものと考えられる、としています。

3条の「推定」は何を意味するのか#

同法の第三条は、電磁的記録であって情報を表すために作成されたもの(公務員が職務上作成したものを除く)について、記録された情報に「本人による電子署名(これを行うために必要な符号及び物件を適正に管理することにより、本人だけが行うことができることとなるものに限る。)」が行われているときは、真正に成立したものと推定する、と定めています。

条文が求めているのは「本人だけが行うことができる」という水準です。この水準を、利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A(電子署名法第3条関係)|デジタル庁・法務省(令和2年9月4日に総務省・法務省・経済産業省が公表し、令和6年1月9日にデジタル庁・法務省が一部改定)は「固有性の要件」として説明しています。二要素認証の例として挙げられているのは、「あらかじめ登録されたメールアドレス及びログインパスワードの入力並びにSMS送信又は手元にあるトークンの利用等当該メールアドレスの利用以外の手段により取得したワンタイム・パスワードの入力」です。メールが届くこと自体とは別の手段でワンタイム・パスワードを受け取らせる、という水準が示されている点が重要です。

同じQ&Aは、利用者の身元確認について、電子署名法第3条の推定効の要件として必ず求められているものではないとしつつ、有効な立証手段の一つとなり得るとしています。

システムを選ぶ側として押さえるべき実務上のポイントは、次の2点です。

  • 締結時にどのような認証を要求できるか(メールだけか、二要素認証まで求められるか)を、契約の重要度に応じて設定できること
  • 誰がいつどの端末から署名したかの記録が、あとから取り出せる形で残ること

つまり、問題は「紙より強いか弱いか」ではなく、争いになったときに立証をどれだけ支えられるかです。

電子契約サービスを選ぶとき、システム側で見る基準は?#

結論から言えば、機能の数ではなく「自社の基幹システム・ワークフロー・文書管理とつながるか」で選びます。締結そのものの操作は、どのサービスを選んでも大きくは変わりません。差が出やすいのは締結の前後、つまり承認をどう回すかと、締結したデータをどこへ渡すかで、ここは自社側の構成に依存するからです。

次の5項目を、自社の運用に当てはめて確認してください。

  • API・Webhook:締結結果を自動で受け取れるか。API(Application Programming Interface)はシステム同士をつなぐ接続口、Webhookは締結などのできごとが起きたときに自社側へ通知を送る仕組みを指します
  • 権限と承認フロー:職務権限規程どおりの順序と金額区分で回せるか
  • 文書管理と検索:取引先名・契約種別・金額・期日で、あとから契約を探せるか
  • 電子取引データの保存:税務上の保存要件を満たせる形でデータが残るか
  • 監査ログ:誰がいつ何をしたかを、締結後にも追える形で記録しているか
電子契約サービスをシステム側で見るときの5つの確認項目(API・Webhook、権限と承認フロー、文書管理と検索、電子取引データの保存、監査ログ)を並べたチェック表
電子契約サービスをシステム側で見るときの5つの確認項目(API・Webhook、権限と承認フロー、文書管理と検索、電子取引データの保存、監査ログ)を並べたチェック表

たとえば、月に数百件の業務委託契約を結び、その情報を販売管理システムの取引先マスタと突き合わせている会社なら、判断の重心は「API・Webhook」と「文書管理と検索」に寄ります。締結のたびに担当者が基幹システムへ手で登録する運用では、件数に比例して登録漏れが増えるからです。反対に、件数が少なく決裁の経路が複雑な会社であれば、「権限と承認フロー」と「監査ログ」が重くなります。

冒頭で挙げた4工程のうち「更新」がこの5項目に入っていないのは、更新期日の管理を電子契約サービス側に持たせない前提で書いているためです。理由は後述の「4つのデータを、どこに持つかを先に決める」で説明します。

5項目のすべてを同じ重みで見る必要はありません。契約の件数と決裁の複雑さのどちらが自社の負担になっているかで、優先順位を決めてください。

導入すると業務の流れはどう変わるか?#

契約1件あたりの工程が、紙を前提としたものから、データを前提としたものに置き換わります。消えるのは物理的な作業で、代わりに入るのは記録の自動化です。

紙で締結しているときの流れは次のとおりです。

  • 稟議を紙で回し、押印の決裁を別に取る
  • 契約書を印刷・製本し、必要に応じて収入印紙を貼る
  • 印章を管理している人の予定に合わせて押印する
  • 郵送し、相手方の押印と返送を待つ
  • 原本をファイルに綴じて書庫で保管する

電子契約に移したあとは、次のように変わります。

  • ワークフローで承認し、決裁の記録がそのまま残る
  • テンプレートから契約書を作り、差し込み項目を自動で埋める
  • 電子署名で締結し、署名の記録が契約データに付く
  • 送信から締結までの進み具合が画面で分かる
  • 締結と同時に保管され、取引先名や期日で探せる
紙で締結しているときの5工程(稟議を紙で回す、契約書を印刷・製本する、印章の管理者に合わせて押印する、郵送して返送を待つ、原本をファイルに綴じて保管する)と、電子契約に移したあとの5工程(ワークフローで承認する、テンプレートから契約書を作る、電子署名で締結する、進み具合が画面で分かる、締結と同時に保管・検索できる)を左右で対比した図
紙で締結しているときの5工程(稟議を紙で回す、契約書を印刷・製本する、印章の管理者に合わせて押印する、郵送して返送を待つ、原本をファイルに綴じて保管する)と、電子契約に移したあとの5工程(ワークフローで承認する、テンプレートから契約書を作る、電子署名で締結する、進み具合が画面で分かる、締結と同時に保管・検索できる)を左右で対比した図

見落とされやすいのは4番目と5番目です。「どこで止まっているか」が見えると、契約の遅れを担当者の記憶ではなくデータで把握できます。紙の運用で同じことをしようとすれば、結局は台帳を手で作るしかありません。

ただし、この流れが全件に適用できるわけではありません。業務委託契約を電子に移した会社でも、相手方の社内規程によって紙を求められる取引は一定数出てきます。紙と電子のどちらで締結したかを台帳で区別できるようにしておかないと、更新期日の管理だけが二重になり、電子化した分の効果が相殺されます。移行の設計では、全件を移すことよりも、紙で残る分を同じ台帳にどう載せるかのほうが効きます。

なお、不動産取引のように、業種ごとに電子化の可否や手続が個別に定められている分野もあります。不動産業のDX・システム活用|物件管理・追客・電子契約と業務システムの作り方では、その分野に固有の位置づけを整理しています。

基幹システム・ワークフローとどうつなぐか?#

締結したデータを、取引先マスタや契約台帳を持つシステムへどう渡すかが導入の成否を分けます。つなぎ方は大きく3つです。

基幹システム・ワークフローとのつなぎ方3通り(手動運用、ノーコード連携、API開発)を並べたカード図
基幹システム・ワークフローとのつなぎ方3通り(手動運用、ノーコード連携、API開発)を並べたカード図
  • 手動運用:締結した契約書を人が基幹システムや文書管理に登録します。件数が少ないうちは合理的ですが、登録漏れは起きる前提で、確認の手順を決めておく必要があります
  • ノーコード連携:サービスが用意した連携機能やツールでつなぎます。開発せずに始められる代わりに、渡せる項目とタイミングは決められた範囲に限られます
  • API開発:自社の基幹・ワークフローに合わせて接続を作ります。取引先コードの突き合わせや契約台帳への反映まで、自社のルールどおりに組めます

分岐の目安は、渡したいデータが固定かどうかと、基幹側に受け口があるかどうかです。渡す項目が決まっていて基幹側にAPIの受け口があるならノーコード連携で足ります。取引先コードの名寄せや契約台帳への自動反映が必要で、基幹側にも改修の余地があるならAPI開発に寄せます。締結の件数が少なく、取引先マスタとの突き合わせも不要なら、手動運用のまま連携を作らない判断が合理的です。

4つのデータを、どこに持つかを先に決める#

どのパターンでも設計の出発点は同じです。次の4つを、どのシステムが正として持つのかを決めてから連携の方向を決めます。

  • 取引先マスタ:電子契約サービス側の取引先と基幹システムの取引先コードをどう突き合わせるか。曖昧なまま始めると、同じ取引先が表記違いで複数登録され、あとから名寄せに追われます
  • 契約台帳:契約番号・契約種別・金額・期間を、どこで一覧できるようにするか
  • 更新期限:期間満了と自動更新の判定を、どのシステムが担って誰に通知するか
  • 電子取引データの保存:税務上の保存が必要なデータを、どこに置いて要件を満たすか

現実的な落としどころは、締結そのものは電子契約サービスに任せ、契約台帳と更新期限の管理は基幹システム側に持たせて、締結結果をAPIで流し込む形です。契約情報を業務の判断に使うのは基幹システム側であり、電子契約サービスの検索機能だけでは受発注や請求とのつながりまで見られないためです。受発注文書の電子化とも隣接するので、受発注管理システムの選び方|EDI・Web受発注・自社開発を比較もあわせて読むと、電子化の範囲を一度に整理できます。

弊社は、この「つなぎ込み」を開発の立場からご支援しています。既存の基幹システムやワークフローに合わせて、締結結果の取り込み、取引先コードの突き合わせ、契約台帳と更新期限アラートの実装を担う形です。詳しくはシステム受託開発のページをご覧ください。

導入の手順と落とし穴は?#

導入は、サービスの選定より前に社内の決め事から始めます。順序を誤ると、締結の仕組みだけ先に入って運用が追いつきません。進め方は次の順です。

  1. 1印章規程・職務権限規程を改定する:電子署名を誰の権限で実行できるのかを規程に落とします。紙の押印権限をそのまま読み替えられるとは限りません
  2. 2電子に移す契約類型を線引きする:全件を一度に移そうとすると、例外の検討で止まります
  3. 3サービスを選定する:前の「システム側で見る基準は?」の5項目のうち、自社にとって重い項目から見ます
  4. 4基幹・ワークフローとの連携を設計する:4つのデータの持ち主を決めてから接続方式を選びます
  5. 5取引先へ案内し、合意を取る:相手方の社内規程によっては紙を求められるため、断られた場合の運用も決めておきます
  6. 6紙と電子の併存運用を回しながら対象を広げる:例外の多い契約類型は最後に回します

落とし穴は、このうち1・2を飛ばして3から始めたときに出ます。

併存期間と保存を設計する#

紙と電子はしばらく併存します。契約台帳が紙用と電子用に分かれてしまうのが典型的な落とし穴です。台帳は最初から一本にし、締結方法を属性として持たせてください。

保存についても確認が要ります。電子契約で締結した契約書は、クラウドサービスや電子メールで取引情報を授受している以上、税務上の「電子取引」に当たります。電子帳簿保存法一問一答【電子取引関係】(令和8年7月)|国税庁の問3は、労働条件通知書データを電子メールに添付して送信した場合と、クラウドサービスを利用して雇用契約書の授受を行った場合について、「その取引情報の授受を電子メールなどの電磁的方式により行う場合には、電子取引に該当しますので、その電子取引データを保存する必要があります」としています。保存要件は同じ資料の問18にまとまっているので、導入とあわせて確認しておくと、あとから保存方法を作り直さずに済みます。

開発を伴うときの契約形態を決める#

連携の開発を外部に頼む場合、契約形態の選択が進め方に影響します。要件が固まらないうちに完成責任を負う契約を結ぶと、仕様変更のたびに交渉が発生します。判断の考え方はシステム開発の請負契約と準委任契約の違い|使い分けと注意点で整理しています。

まとめ#

電子契約サービスの選定は、締結機能の比較ではなく、次の3つを順に決める作業です。

  1. 1署名方式を契約の類型ごとに決める。相手方に電子証明書の準備を求められるかが分かれ目になります
  2. 25項目のうち、自社にとって重い項目を見極める。契約の件数が多ければ連携、決裁が複雑なら承認フローと監査ログが重くなります
  3. 34つのデータの持ち主を先に決める。取引先マスタ・契約台帳・更新期限・電子取引データの保存を、どのシステムが正として持つかを決めてから連携方式を選びます

この順で決めておけば、サービスを入れ替えることになっても、基幹側に残した仕組みを作り直さずに済みます。締結の機能だけで選ぶと、契約データがサービスの中に閉じ込められ、移行のたびに同じ設計をやり直すことになります。

よくある質問(FAQ)#

Q. すべての契約を電子契約にできますか?

A. 契約の成立に書面の作成を要しないのが原則であるため(民法第五百二十二条第二項)、取引先と交わす契約の多くは電子で締結できます。ただし、分野によっては書面の交付や手続が個別に定められている場合があるため、対象とする契約類型ごとに、所管する官庁の情報や顧問弁護士の確認を取ってから範囲を決めてください。

Q. 相手方が同じサービスを使っていなくても締結できますか?

A. 事業者署名型であれば、相手方はメールを受け取って画面上で操作するだけで締結できるのが一般的です。当事者署名型では、相手方にも電子証明書の準備を求めることになるため、取引先の数が多い場合は負担が実務上の障壁になります。

Q. 電子契約書に印紙税はかかりますか?

A. 取引先にメール送信した電磁的記録に関する印紙税の取扱い|国税庁は、建設工事の請負契約に関して、注文請書を作成する代わりに電子署名を付した電磁的記録を電子メールで送信した事例について、「電磁的記録は文書に含まれません。したがって、おたずねの電磁的記録に印紙税は課税されません」としています。個別の取扱いは文書の内容や交付の方法によって変わるため、自社の契約については所轄の税務署にご確認ください。

Q. 電子契約で締結した契約書はどのように保存すればよいですか?

A. 電子契約で授受した契約データは税務上の「電子取引」に当たるため、電子データのまま保存する必要があります。保存要件は電子帳簿保存法一問一答【電子取引関係】(令和8年7月)|国税庁の問18にまとめられています。電子契約サービス内に保存し続けるのか、自社の文書管理へ複製するのかは、解約時の取り出し方法とあわせて決めておくと安全です。

Q. 既存の文書管理システムや基幹システムとつなげますか?

A. 多くのサービスがAPIやWebhookを備えているため、締結結果を自社システムへ流し込むことは可能です。実務で詰まるのは接続そのものよりも、取引先コードの突き合わせや、契約台帳をどちらが正として持つかの設計です。つなぐ前に、本文の「4つのデータを、どこに持つかを先に決める」を整理してください。

電子契約と基幹システムの連携について相談する#

株式会社TryWithは、システム受託開発とシステム開発支援を通じて、電子契約サービスと基幹システム・ワークフロー・文書管理のつなぎ込みをご支援しています。既存システムの構成を前提に、どこまでを連携で自動化し、どこを運用で受けるかの線引きからご相談いただけます。

電子契約サービスと基幹・ワークフローの連携設計は、30分のオンライン相談でお話しできます。

お問い合わせはこちら

タグ

#電子契約#電子署名法#システム連携#ワークフロー#文書管理#業務効率化