電子契約のAPI連携で見積もりを取るとき、何を先に確認すべきですか？

仕様書の入手条件（契約前に読めるか、NDAや費用が必要か）と検証環境の有無です。仕様書を読めない状態では工数バッファが積まれるか、後から追加になります。あわせて監査に必要な粒度の操作ログをAPIで取得できるか、保存年数に対して長期署名がサービス側で担保されるかも早期に確認すべき項目です。

電子契約のAPI連携と自作の線引き

Q: 電子契約のAPI連携とembedded署名は何が違うのですか？

API連携は契約書の作成・送信・ステータス管理をAPIで自動化する形で、署名体験はSaaS側にあります。embeddedは署名画面自体を自社UIの中に表示し、ユーザーがSaaSの存在を意識しない体験にする形です。大半の案件はAPI連携で足り、embeddedが必要なのは契約がプロダクト体験の中心にある場合に限られます。

Q: DocuSignのembedded署名はどういう仕組みですか？

envelope作成時に受信者へclientUserIdを設定し、recipient view URLを生成APIで取得して自社アプリ内に表示、署名完了後は指定したreturnUrlへ戻す3ステップです。このURLは有効期限5分の使い切りで長寿命リンクにはできません。自社アプリを中間層にして署名画面を開くたびにURLを生成するのが公式推奨のパターンです。

「契約の締結を自社サービスの中で完結させたい」という要望は、事業側からはひとことで出てきますが、実装の選択肢は3つに分かれます。電子契約SaaSのAPIを叩いて業務を自動化するのか、署名画面そのものを自社UIに埋め込むのか、SaaSに乗らず署名基盤を自作するのか。この3つはコストも開発期間も、背負う法対応の範囲もまったく違います。本記事は、発注者・事業会社の開発責任者が、ベンダー選定や見積もり依頼の前に「自社はどのレイヤーを買い、どこから作るのか」を判断できるよう、公開情報から確認できる範囲を整理したものです。確認日: 2026年7月18日。

この記事の要点

「組み込む」には API連携と embedded（署名UIの埋め込み）の2段階があり、大半の案件は API連携で足ります

国内サービスはAPI概要のみの公開が主流で、詳細仕様書は契約者向けです。仕様書の入手条件と費用を見積もり前に確認してください

embedded署名を公式ドキュメントで確認できたのはDocuSignです。recipient view URLは有効期限5分の使い切りで、都度生成する設計が公式推奨です

自作に踏み込むと、タイムスタンプの調達・証明書の調達・長期署名の設計まで自社で背負います。SaaSが隠しているコストを見積もりに含めて比較する必要があります

まず「どこまで組み込むのか」を決める

自社サービスに契約機能を入れる、と言ったときの深さには段階があります。

API連携: 契約書の作成・送信・ステータス管理を電子契約SaaSのAPIで自動化する。署名の体験そのものはSaaS側に置く（メールで届く署名リンクなど）
embedded（埋め込み）: 署名画面そのものを自社UIの中に埋め込み、ユーザーがSaaSの存在を意識しない体験にする

判断の分かれ目はシンプルで、契約がプロダクト体験の中心にあるかどうかです。バックオフィスの契約業務を効率化したいだけなら1で十分です。ユーザーが署名した瞬間に取引が成立するマーケットプレイスや、入会手続きが署名で完結するサービスのように、契約そのものがコンバージョンポイントになっている場合に初めて2の投資が正当化されます。

発注時によくある失敗は、事業側の「シームレスにしたい」という言葉を要件として受け取り、実際にはメール経由でも成立する業務に embedded の見積もりを取ってしまうことです。まず現行フロー（あるいは想定フロー）で、署名がユーザー体験の連続性を壊す位置にあるのかを確認してください。壊さないなら、API連携で足ります。

国内主要サービスのAPI公開状況（2026年7月時点）

サービス	API	公開ドキュメント	API利用の条件（公開情報）
クラウドサイン	あり	ヘルプ記事で概要公開	スタンダード以上のプランで利用可
GMOサイン	あり	紹介ページのみ。仕様書は契約者向け	スタンダードプラン以上+仕様書開示・検証環境は別途費用
freeeサイン	あり	Swagger UIを公開	プラン条件は非公開
DocuSign	あり	開発者サイトで完全公開	開発者アカウントで無償検証可
マネーフォワードクラウド契約	公開APIなし	開発者サイトのAPI一覧に契約は未掲載	-

APIでできること自体は各社おおむね共通です。文書のアップロードと送信、署名位置の設定、ステータスや操作ログの取得、OAuth 2.0による認証、というあたりが基本セットになります。機能差でサービスを選ぶ場面は、実はそれほど多くありません。

差がつくのはドキュメントの公開度のほうです。DocuSignは仕様からサンプルコードまで全公開で、開発者アカウントを取れば契約前に実際に動かして確認できます。国内勢は概要のみの公開が主流で、GMOサインのように仕様書の開示と検証環境の提供に別途費用がかかる場合もあります。

これは見積もりの精度に直結します。仕様書を読めない状態で「API連携込み」の見積もりを出させると、ベンダーは不確実性を工数バッファとして積むか、あるいは楽観的な前提で見積もって後から追加になるかのどちらかです。API連携前提で見積もりを取るなら、仕様書の入手タイミングと費用、検証環境の有無を最初に確認するのが実務上の鉄則です。RFPの前提条件欄に「契約前に仕様書開示が可能か」を書いておくだけで、後工程のトラブルがかなり減ります。

embedded署名: 公式パターンを基準に各社を評価する

自社UIへの署名埋め込みについて、公式ドキュメントで実装方法を確認できたのはDocuSignです。embedded signingのHow-toによると、仕組みは次の3ステップです。

envelope（契約書）の作成時に、受信者へ clientUserId（自社システムのユーザーID）を設定する
recipient view URLを生成APIで取得し、自社アプリ内に表示する
署名完了後、指定した returnUrl へ戻す

設計上の要点は、この recipient view URL が有効期限5分の使い切りである点です（公式ブログに明記されています）。つまり、生成したURLをメールに貼って送るような長寿命リンクの使い方はできません。自社アプリを中間層に置き、ユーザーが署名画面を開こうとするたびにサーバー側でURLを生成して返す、というのが公式推奨のパターンです。

この制約は、システム構成に具体的な要求を生みます。署名画面へ入る前に自社側で認証を済ませていること、URL生成用のサーバーサイド処理を持つこと、そして5分以内に署名を完了できないユーザーのために再生成の導線を用意することです。「iframeに貼るだけ」という理解で工数を見積もると、確実にずれます。

国内3社（クラウドサイン・GMOサイン・freeeサイン）については、公開ドキュメント上で embedded 署名への対応を確認できませんでした。対応していないと断定できるわけではなく、非公開の仕様書に記載がある可能性は残ります。国内サービスを検討する場合は、上のDocuSignのモデルを基準にして「同じことができるか」を商談で直接確認する項目にしてください。具体的には、署名画面を自社ドメイン内に表示できるか、URLの有効期限と再生成の方法、完了後のコールバックまたはリダイレクトの仕様、の3点です。

「自作」に踏み込むと何を背負うか

SaaSの立会人型に乗らず、署名基盤を自作する判断もあり得ます。ただしその場合、背負うのは技術だけではありません。調達と法対応が付いてきます。

タイムスタンプの調達: 電子帳簿保存法への対応や長期の証拠性確保には、総務大臣認定の時刻認証業務によるタイムスタンプを使います。認定事業者にはセイコーソリューションズ、アマノ、三菱電機系（DiaStamp）などがあります。件数課金のランニングコストとして継続的に発生します
当事者型にするなら証明書の調達: 利用者ごとの電子証明書が必要になります。JIPDECの認定認証業務一覧に掲載されているセコムトラストシステムズ、日本電子認証（AOSign）等から調達するか、マイナンバーカード（JPKI）の署名用証明書を使う設計になります
長期署名の設計: 契約書を7年、10年と保存するなら、PAdES/LTVによる長期署名の設計が必須です。SaaSであればサービス側が面倒を見てくれる領域を、すべて自前で設計・運用することになります

見積もり比較の場面で見落とされやすいのは、この3つがSaaSの月額料金に溶け込んでいるということです。自作の見積もりを「開発費だけ」でSaaSの初期費用と並べると、自作が安く見えます。タイムスタンプの件数課金、証明書の調達コスト、長期署名の再署名を含む運用、そして法解釈のアップデート追従まで含めた3年〜5年の総額で並べて初めて、比較として成立します。

線引きの目安

判断軸を1つの表にまとめます。

目的	選ぶべき構成	主な確認事項
契約業務の自動化（送信・管理の効率化）	API連携	ドキュメントの公開度、仕様書の入手条件と費用、検証環境の有無
署名体験を自社UIに溶かしたい	embedded対応サービス	対応可否（現状の公式確認はDocuSign）、URL有効期限と再生成、コールバック仕様
契約がプロダクトそのもの・件数が多い・要件が特殊	自作の検討余地	タイムスタンプ調達、証明書調達、長期署名設計、法解釈の追従体制

自作を検討する段階に来ている場合は、本人確認とセットで全体像を描いてから判断してください。契約の相手方が本当にその人なのかを確認する仕組みがなければ、署名基盤だけを堅牢にしても意味がありません。マイナンバーカードを使う場合の選択肢はマイナンバーカードによる本人確認の選択肢に、本人確認方式全体の地図はeKYC完全マップ2026にまとめています。

発注前チェックリスト

商談やRFPの段階で埋めておきたい項目です。

必要な深さの確認: 署名がユーザー体験の連続性を壊す位置にあるか。壊さないならAPI連携で足りる
仕様書の入手条件: 契約前に読めるか、NDAが必要か、開示に費用がかかるか
検証環境: サンドボックスの有無と費用。契約前に実際に動かせるか
embedded対応: 自社ドメイン内表示の可否、URLの有効期限と再生成方法、完了後のコールバック仕様
ステータス・操作ログの取得: 監査に必要な粒度のログをAPIで取得できるか
保存要件との整合: 何年保存する契約か。長期署名（LTV）はサービス側で担保されるか
自作と比較する場合: タイムスタンプの件数課金、証明書調達費、長期署名の運用を含めた3〜5年総額で並べているか
本人確認との接続: 署名者が本人であることをどう確認するか。本人確認の方式選定と並行して設計しているか

まとめ

組み込みには「API連携」と「embedded（署名UIの埋め込み）」の2段階があります。大半の案件はAPI連携で足り、embeddedが要るのは契約がプロダクト体験の中心にある場合です
国内サービスはAPI概要のみの公開が主流で、詳細仕様書は契約者向けです。仕様書の入手タイミングと費用、検証環境の有無を見積もり依頼の前に確認してください
DocuSignは仕様からサンプルまで全公開で、契約前に検証できます。embedded signingの公式パターンでは recipient view URL が有効期限5分の使い切りで、都度生成する構成が前提です
国内3社のembedded対応は公開ドキュメントで確認できませんでした。DocuSignのモデルを基準に、表示先ドメイン・URL有効期限・コールバック仕様を商談で確認するのが実務的です
自作はタイムスタンプ（認定事業者から調達）・証明書（認定認証業務またはJPKI）・長期署名の設計まで背負います。SaaSが隠しているコストを見積もりに含めて比較してください
自作を検討する段階では、本人確認の方式選定と並行して全体像を描いてから判断するのが安全です

よくある質問

Q. 電子契約のAPI連携とembedded署名は何が違うのですか？

API連携は、契約書の作成・送信・ステータス管理といった業務処理を電子契約SaaSのAPIで自動化する形です。署名の体験そのものはSaaS側にあり、ユーザーはメールで届いた署名リンクから署名します。embedded（埋め込み）は署名画面自体を自社UIの中に表示し、ユーザーがSaaSの存在を意識しない体験にする形です。大半の案件はAPI連携で足り、embeddedが必要になるのは契約がプロダクト体験の中心にある場合に限られます。

Q. 国内の電子契約サービスはAPI仕様書を公開していますか？

概要のみの公開が主流です。クラウドサインはヘルプ記事で概要を、freeeサインはSwagger UIを公開していますが、GMOサインは紹介ページのみで仕様書は契約者向けとなっており、仕様書開示と検証環境に別途費用がかかる場合があります。一方DocuSignは開発者サイトで仕様からサンプルまで完全公開しており、開発者アカウントで無償の検証が可能です。API連携前提で見積もりを取る際は、仕様書の入手タイミングと費用を最初に確認してください。

Q. embedded署名に対応している電子契約サービスはどれですか？

公開ドキュメントで実装方法を確認できたのはDocuSignです。国内3社（クラウドサイン・GMOサイン・freeeサイン）については公開ドキュメント上で対応を確認できませんでした。非公開の仕様書に記載がある可能性は残るため、国内サービスを検討する場合は商談で直接確認する項目になります。

Q. DocuSignのembedded署名はどういう仕組みですか？

envelope（契約書）の作成時に受信者へclientUserId（自社システムのユーザーID）を設定し、recipient view URLを生成APIで取得して自社アプリ内に表示、署名完了後は指定したreturnUrlへ戻す、という3ステップです。このrecipient view URLは有効期限5分の使い切りで、メールで送る長寿命リンクにはできません。自社アプリを中間層にして、ユーザーが署名画面を開くたびにサーバー側でURLを生成するのが公式推奨のパターンです。

Q. 電子契約の署名基盤を自作するとどんなコストがかかりますか？

技術以外に調達と法対応が加わります。電子帳簿保存法対応や長期の証拠性には総務大臣認定の時刻認証業務によるタイムスタンプが必要で、これは件数課金のランニングコストです。当事者型にする場合は利用者ごとの電子証明書を認定認証業務から調達するか、マイナンバーカードのJPKI署名用証明書を使う設計になります。さらに7年・10年保存するならPAdES/LTVの長期署名設計が必須です。SaaSの月額に溶け込んでいるこれらを含めた3〜5年の総額で比較してください。

Q. API連携で見積もりを取るとき、何を先に確認すべきですか？

仕様書の入手条件（契約前に読めるか、NDAや費用が必要か）と検証環境の有無です。仕様書を読めない状態で見積もりを出させると、ベンダーは不確実性を工数バッファとして積むか、楽観的な前提で見積もって後から追加になります。あわせて、監査に必要な粒度の操作ログをAPIで取得できるか、契約書の保存年数に対して長期署名がサービス側で担保されるかも、早い段階で確認しておくべき項目です。

主な参考資料: クラウドサイン Web API、GMOサイン API、DocuSign eSignature REST API、総務省タイムスタンプ認定制度、JIPDEC 認定認証業務一覧

TodoONada株式会社では、電子契約のAPI連携開発から、SaaSに乗らない署名要件の設計・実装までを受託しています。あわせてマイナンバーカード認証（JPKI・eKYC）を組み込んだWebサービス・スマホアプリの開発も行っており、「誰が署名したのか」を担保する本人確認まで含めた一体の設計をご支援できます。API連携とembeddedのどちらが合うのかという整理や、SaaS利用と自作の総額比較といった上流段階からのご相談も可能です。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。マイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。

この記事に関連するサービス

TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。

マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。