Adobe Acrobat Signとは？API連携の制約と国内サービスとの選び分けを解説

Adobe Acrobat Signは、PDFの作成と編集を担うAcrobatとは課金も機能も分かれた、署名依頼の送信と進行管理を受け持つサービスです。導入検討で情報が足りなくなるのは機能一覧でも料金表でもなく、既存の販売管理システムや契約書管理システムとつなぐ段階でしょう。本記事では、Acrobat Signが処理の単位に置く「合意」の考え方、電子署名法2条1項に関する国のQ&Aから見た立会人型の位置づけ、Adobeの開発者向けドキュメントに書かれた実装上の制約を順に整理します。国内サービスと比べた取引先の負担と費用構造の違い、採用条件と見送りが妥当になる場面まで扱います。

まとめ：Acrobat Signの採否はAPI提供条件と署名方式の二層で決まる

Acrobat Signの評価は、機能の多寡ではなく二つの層で決まります。一層目は署名方式です。取引先にアカウントも証明書も求めない方式で運用するのか、証明書ベースの署名を求めるのか。この選択が取引先の負担と電子署名法上の評価の両方を規定します。国のQ&Aが示すのは、事業者が自身の署名鍵で措置を行う方式でも、その意思が介在する余地がなく利用者の意思だけで機械的に処理されたと担保できるなら、措置を行った者は利用者と評価し得るという整理。方式名だけで法的効力は決まりません。

二層目が連携の設計です。APIは、書類を一時領域へ上げて合意を作り、状態変化を受け取って完成PDFを引き取る三段構え。ここに、一時ドキュメントの7日という寿命、トークンの更新設計、状態通知の受け口という三つの制約が乗ります。月末だけ動くバッチや、社内承認を挟んで数週間待つ運用は、この制約にぶつかります。

Adobeのライセンスを全社で既に持ち、海外との取引がある企業なら、Acrobat Signは追加投資の少ない選択肢でしょう。国内の取引先が中心で送信件数が月に数十通規模なら、送信課金型の国内サービスに分があります。判断を分けるのは製品の優劣ではなく、既存契約の有無と取引相手の所在です。

Adobe Acrobat Signの機能範囲と電子サイン・デジタル署名の使い分け

製品名が似ているため混同されますが、Acrobatは手元のPDFを編集するアプリケーション、Acrobat Signは署名の依頼と回収を進めるサービスで、担当する工程が違います。APIの視点で見ると輪郭がはっきりします。処理の単位がファイルではなく、誰が何を承認するかまで含んだ「合意」だからです。

合意を単位に送信から署名と保管まで進む処理の流れと参加者の役割指定

Adobeの開発者向けガイドAPI Usage（Last update: Oct 27, 2025）は、基本の署名ワークフローを三段階と説明しています。

1. 書類を送信する（一時ドキュメントとして上げ、合意を作る）
2. 署名の進行状況を確認する（通知か、状態の取得）
3. 完成した合意をダウンロードする

合意を作るとき、受信者には役割を必ず指定します。指定できる値は、署名者のSIGNER、承認のみのAPPROVER、内容確認のACCEPTOR、身元確認済みの受信者を示すCERTIFIED_RECIPIENT、入力だけを担うFORM_FILLER、それぞれの委任先であるDELEGATE_TO_SIGNERなど、共有のSHAREまで。orderに1から順の番号を与えれば署名順も制御できます。承認者と署名者を別人に割り当てられるので、社内の決裁ラインまで載せる構成も技術的には成立するでしょう。ただし社内決裁は差し戻しや代理承認の要件が会社ごとに細かく、締結サービスの承認機能では吸収しきれません。社内側はワークフローシステムに残す分担のほうが、後の改修が軽く済みます。

合意にはstateがあり、DRAFT、AUTHORING、IN_PROCESSの三つを取ります。段階的に組み立てるならDRAFT、フォーム項目を編集するならAUTHORING、すぐ送るならIN_PROCESSという使い分けで、DRAFTからAUTHORING、IN_PROCESS、CANCELLEDの順に遷移する仕様です。承認前にIN_PROCESSへ進める事故を防ぐには、社内承認の完了イベントを受けるまでDRAFTで止める作りが有効になります。

電子サインと証明書ベースのデジタル署名で分かれる要件と使い分け

合意の作成時にはsignatureTypeという属性があり、公式ガイドが挙げる値はESIGNとWRITTENの二つです。前者が画面上で完結する電子サイン、後者が印刷して手書き署名し、読み込んで戻す運用。これとは別に、署名者側がデジタルIDを用意して行う証明書ベースの署名という選択肢もあります。違いは一点、署名者に何を準備させるかです。

選択の実務的な影響は回収率に出ます。証明書の取得を相手方に求めた瞬間、締結までの日数が相手の社内手続きに引きずられるからです。相手方が官公庁や金融機関で、もともと証明書を保有しているなら障害になりません。そうでない取引先に対して、証明書ベースを標準に据える設計は避けるべきでしょう。

電子署名法での位置づけと立会人型サービスに求められる二つのプロセス

製品選定の議論が「法的に有効か」で止まるのは、条文とQ&Aを分けて読んでいないからです。基本的な仕組みと書面契約との違いは電子契約の仕組みと電子署名法による法的効力の整理で扱うため、ここではサービス型の署名が法律上どう評価されるかに絞ります。

電子署名法第二条第一項が定める二つの要件と第三条の推定効の関係

電子署名法（電子署名及び認証業務に関する法律）の第2条第1項は、電子署名を二つの条件で定義しています。総務省・法務省・経済産業省が令和2年7月17日に公表した電子署名法2条1項に関するQ&AのQ1が、その内容を明示しました。第一に、その情報が措置を行った者の作成に係るものであることを示すためのものであること。第二に、改変が行われていないかどうかを確認できるものであること。両方に該当して初めて電子署名にあたります。

押さえたいのは、2条の定義を満たすことと3条の推定効が働くこととが別だという点です。3条は、本人による一定の電子署名が行われているときに、その電磁的記録が真正に成立したものと推定する規定。立証の負担がどちらへ寄るかを左右する条文であり、定義を満たせば自動的に推定が働くわけではありません。選定の場で「電子署名法に準拠」という表現を見たら、2条と3条のどちらの話かを確認してください。

事業者の署名鍵で措置する方式が利用者の措置と評価される場合の条件

Acrobat Signを含め、利用者の指示を受けて事業者が自身の署名鍵で暗号化を行う方式は、立会人型と呼ばれます。先のQ&AのQ2は、この方式の評価基準を具体的に書きました。技術的・機能的に見て、事業者の意思が介在する余地がなく、利用者の意思のみに基づいて機械的に暗号化されたものであることが担保されていると認められるなら、措置を行った者は事業者ではなく利用者と評価し得る、という整理です。

さらに同Q&Aは、電子文書を送信した利用者やその日時等の情報を付随情報として確認できる場合、その情報を含めた全体を一つの措置と捉え直すことで2条1項第1号の要件を満たすと考えられる、とも述べています。監査ログや操作履歴の設計が、そのまま法的評価に効くということ。ベンダーの資料を読むときは暗号化の強度ではなく、誰がいつ送信したかを後から確認できる形で残るかを見てください。同Q&AのQ3は、本人確認の方法やなりすまし防止のレベルはサービスごとに様々であり、契約の性質と必要な本人確認レベルに応じて適切なサービスを選ぶのが適当だと結んでいます。全社一律で一つの方式に寄せず、契約の重要度で使い分ける前提の記述です。実務上の選び分けは当事者型・立会人型の選び分けと署名のやり方で詳しく扱っています。

Acrobat Sign APIで基幹システムと連携する際の実装制約と設計の勘所

ここからが、比較メディアの記事には出てこない部分です。販売管理システムから契約書を自動送信する、契約書管理システムに完成PDFを取り込む。この段になると、公式ドキュメントに書かれた三つの制約が設計を左右します。

一時ドキュメントの七日間と一回一ファイルの制限から決める送信設計

署名対象のPDFは、まず一時領域へアップロードします。エンドポイントはPOST /api/rest/v6/transientDocumentsで、ファイル名とMIMEタイプとファイル本体を含むマルチパートのリクエスト。返ってくるtransientDocumentIdを使って合意を作ります。公式ガイドが明記する制限は二つ。書類はtransient（一時的）と呼ばれるとおり7日間だけ有効で、1回のリクエストで送れるのは1ファイルのみです。

POST /api/rest/v6/agreements HTTP/1.1
Host: api.na1.echosign.com
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

{
  "fileInfos": [{ "transientDocumentId": "TRANSIENT_ID" }],
  "name": "業務委託基本契約書",
  "participantSetsInfo": [{
    "memberInfos": [{ "email": "[email protected]" }],
    "order": 1,
    "role": "SIGNER"
  }],
  "signatureType": "ESIGN",
  "state": "IN_PROCESS"
}

7日間という寿命は、社内承認を挟む業務フローと相性が悪い箇所です。契約書を生成した時点でアップロードし、法務レビューと役員承認を待ってから送信する順序で組むと、承認が翌週へ持ち越された案件でIDが失効します。回避策は単純で、アップロードを承認完了後まで遅らせること。契約書と添付資料をまとめて送る場合は、ファイルごとにアップロードしてfileInfosに並べます。

ホスト名の扱いにも注意が要ります。公式ガイドは、APIのアクセスポイントがOAuth認可時にクエリパラメータとして返され、以後の呼び出しはすべてそこへ行うと説明しました。アカウントが属するシャードでホストが変わるため、サンプルのホスト名を定数に埋め込むと本番で疎通しません。認可時に受け取った値を保存して使います。

アクセストークン一時間とリフレッシュトークン六十日で組む更新処理

認可まわりの数字は、AdobeのManaging Oauth Tokens（Last update: Feb 06, 2024）に明記されています。アクセストークンの有効期限はexpires_inが3600、つまり1時間。失効したらリフレッシュトークンで取り直します。実務で効くのはリフレッシュトークン側の条件で、60日間使われないと失効する一方、一度使えば期限が60日後へリセットされます。

この仕様が刺さるのは、稼働頻度の低い連携です。四半期に一度しか動かない契約更新バッチや、繁忙期だけ使う申込フォーム連携は、次に動いたときにはトークンが切れています。公式ドキュメント自身が対処法を示しており、失効が心配なら1日からN日おき（例として50日）にアクセストークンを更新するジョブを組むよう案内しました。業務処理とは独立した保守ジョブが要る、ということです。

失効の連鎖にも注意が要ります。アクセストークンを失効させると、対応するリフレッシュトークンも一緒に失効。逆にリフレッシュトークンを失効させると、そこから発行された全アクセストークンが失効します。運用担当が誤って一つ取り消すだけで連携全体が止まるため、失効操作は誰でも実行できない状態にしておいてください。エラー時のコードは、空または欠落ならINVALID_REQUEST、期限切れか取り消し済みならEXPIRED_TOKEN、有効でないならINVALID_TOKENの三つで、いずれもHTTP 400。監視ではステータスコードだけを見ず、本文のエラーコードで分岐させます。

通知の受け取りと定期取得のどちらを選ぶかを接続経路の可否で判定

署名の進行状況を知る方法は二つあります。公式ガイドが最も簡単な仕組みとして挙げるのは、送信時にWebhookのURLを渡し、状態が変わるたびに通知を受ける方式です。通知には対象の合意のID、現在のステータス、原因となったイベントの情報が含まれるため、受け取った側で処理を分岐できます。

もう一方が定期取得です。GET /api/rest/v6/agreements/{agreementId}を周期的に呼んで状態を確認します。公式ガイドはこの方式の利点を、呼び出し側がファイアウォールの内側にあって到達できない場合にも使える点だと説明しました。欠点は、未署名の書類を問い合わせるスケジューラを自前で作る必要があること。一定日数を過ぎても署名されない書類は問い合わせ頻度を落とすことも推奨されています。オンプレミスに閉じた環境なら定期取得、クラウド側にAPIを公開できるなら通知、という分岐で判断すれば外しません。

確認しておきたい制約がもう一つ。公式ガイドは、ブラウザがサードパーティCookieをブロックしていると署名依頼の連携でエラーが起きることがあり、Cookieに依存しないRequest Signatureのワークフローを有効にすれば解消すると記載しています。ただしその有効化は、テスト用のAPIアプリケーションで検証したうえで、本番のIDを添えてAdobeのカスタマーサポートへ依頼する手続き。自社の設定画面で完結しないため、スケジュールに待ち時間を織り込んでください。実装の出発点には、Adobeが公開するREST APIのサンプル（Last update: Apr 06, 2023）が使えます。

国内の電子契約サービスと比べたときの取引先の受領体験と費用構造の差

Acrobat Signと国内サービスの比較は、機能表を横に並べても差が出ません。どこも似通っているからです。差が出るのは、取引先が署名する場面と、契約数が増えたときの費用の伸び方の二か所です。

取引先が署名するまでの手順と回答率に効く受領側の負担を比べる

締結までの日数を決めるのは、送信側の機能ではなく受け取る側の手間です。立会人型で運用する限り、Acrobat Signも国内サービスも受領側の基本動作は変わりません。メールのリンクを開き、内容を確認し、署名して返す。違いが出るのは画面の言語と、相手方にとっての見慣れ具合でしょう。国内の中小企業が取引先なら、過去に受け取った経験の有無で問い合わせの発生率が変わります。「このメールは本物か」という電話が入る前提で、送信前の案内文を用意しておくと安全です。

逆に海外取引が多い企業では、Acrobat Signが優位に立ちます。多言語対応と国際的な普及度により、相手方が既にアカウントを持っている確率が高いためです。判断の順序としては、まず契約相手の所在地と業種を数えてから選ぶ。逆にすると社内で使いやすいという理由だけで決めてしまい、締結率が落ちます。比較の設計は署名方式・証拠力・保存要件で選び分ける判断軸を先に読むと、載せる項目が定まります。

送信量ではなく利用者数で増える費用の伸び方と上位プランの条件

費用の見積もりで最初に確認するのは金額ではなく課金軸です。Acrobat Signは送信する側のライセンス数を軸に据え、送信件数には一定の枠を割り当てる考え方を採ります。国内の主要サービスの多くは、月額の基本料に送信1件ごとの従量料金を積む構造。どちらが安くなるかは、社内の送信担当者の人数で反転します。

API連携を前提にするなら、APIがどのプランから使えるかも最初に確認してください。電子契約サービスの多くは、API機能を上位プランの条件に置いています。最小構成で試算して稟議を通したあと、連携の要件が出た段階でプラン変更が必要になり予算を超える。この順序の事故が実際に起きます。料金体系と割引条件は改定されるため、金額そのものは各社の公式ページで検討時点の値を確認してください。サービス単位の判断軸は認証方式・連携・費用で選ぶ電子契約システムの選び方で整理しています。

基幹システムに組み込む場合の採用条件と見送りが妥当になる場面

ここまでの制約を踏まえて、判断を言い切ります。Acrobat Signは万能ではなく、既存資産と取引相手で向き不向きが明確に分かれる製品です。

既存のAdobe契約と英語圏の取引がある場合に採用してよい条件

次の三つがそろうなら、Acrobat Signを選んで構いません。第一に、AcrobatのライセンスをAdmin Console経由で全社に配布済みであること。ユーザー管理と権限付与を二重に持たずに済みます。第二に、契約相手に英語圏の企業が含まれること。多言語での署名依頼と国際的な認知度が、締結までの日数に効きます。第三に、署名依頼を出す担当者が部門横断で20名を超えないこと。ライセンス数課金では担当者が増えるほど費用が伸びるためです。

この条件下で基幹システムとつなぐなら、設計の要点は三つ。一時ドキュメントの7日間に収まる送信順序、50日以内にリフレッシュトークンを更新する保守ジョブ、通知を受けるエンドポイントの公開可否です。いずれも既存システム側の作り方に依存し、Acrobat Sign側の設定では解決しません。設計を固める段階では、外部APIとの連携開発として、認証情報の保管場所とリトライ方針まで要件に落としておくと手戻りが減ります。

国内の取引先が中心で送信量も少ない場合に見送りを選ぶ判断の根拠

反対に、次のいずれかに当てはまるなら見送りを推奨します。契約相手が国内企業のみで、月間の締結件数が数十通にとどまる場合。この規模では送信課金型の国内サービスのほうが総額で安く、取引先にも受け取り慣れた画面です。Adobe製品を社内で使っていない場合も同様。単独で契約すると既存ライセンスを持つ企業の価格上の利点が消え、比較の前提が崩れます。

判断を保留してよい場面も一つあります。現在は国内取引が中心でも、1年以内に海外拠点との契約が始まる計画が具体化している場合です。まず国内サービスで運用を立ち上げ、海外取引が始まってから併用を検討する段階導入が現実的でしょう。移行のコストは保管場所の移動ではなく、取引先への再案内に集中します。ここを見誤らなければ、後から乗り換える判断は十分に取り返しがつくはずです。

よくある質問

よく挙がる質問を、公式ドキュメントと国のQ&Aに沿って整理します。

Adobe Acrobat SignとAdobe Acrobatの違いは何ですか？

担当する工程が違います。Acrobatは手元でPDFを作成・編集するアプリケーション、Acrobat Signは署名依頼を送信し、署名状況を追跡し、完成した合意を保管するサービスです。法人向けプランに署名機能が含まれる形態もあるため、契約前に自社のプランで何が使えるかを確認してください。API連携が要件なら、プランごとの提供条件を先に押さえます。

Adobe Acrobat Signは無料で使えますか？

評価目的の無料期間や、Acrobatの一部プランに含まれる限定的な署名機能はありますが、業務としての継続利用には有償の契約が要ります。注意したいのは、API連携やユーザー管理といった導入判断の分かれ目になる機能ほど上位の条件に置かれる点。無料期間中に検証すべきは署名画面の操作性ではなく、自社システムからの送信と状態取得が動くかどうかでしょう。

Acrobat Signで締結した契約は日本の法律で有効ですか？

電子署名法2条1項に関する国のQ&A（令和2年7月17日）は、事業者が利用者の指示で自身の署名鍵により暗号化する方式について、事業者の意思が介在する余地がなく利用者の意思のみで機械的に処理されたと担保されるなら、措置を行った者は利用者と評価し得るとしました。送信した利用者や日時の付随情報を含めて一つの措置と捉え直す考え方も示されています。有効性はサービス名ではなく、本人確認の方法と記録の残り方で決まります。

Acrobat SignのAPIで最初に詰まりやすいのはどこですか？

三つあります。アップロードした一時ドキュメントが7日で失効すること、アクセストークンが1時間で切れリフレッシュトークンも60日の未使用で失効すること、APIのアクセスポイントがOAuth認可時に返る値であり、サンプルのホスト名を固定すると疎通しないことです。いずれも公式の開発者ガイドに明記されていますが、比較サイトには出てきません。要件定義の段階で確認しておくと、実装での手戻りを避けられます。

既存の販売管理システムから送信する場合は何から着手しますか？

着手順は、通知を受けるエンドポイントを公開できるかの確認からです。公開できるなら通知方式、できないなら定期取得方式となり、必要な実装量が変わります。次に決めるのが契約書PDFの生成タイミングで、社内承認の完了後にアップロードする順序へ寄せてください。最後にトークン更新の保守ジョブを加えます。残りは合意の作成と完成PDFの取得という定型処理に収まります。

関連記事

• 電子契約とは？仕組み・電子署名法による法的効力・書面契約との違いを解説：法的効力の全体像を押さえる出発点。
• 契約書の電子署名とは？当事者型・立会人型の選び分けと署名のやり方：署名方式の違いと実際の手順。
• 電子契約の比較とは？署名方式・証拠力・保存要件で選び分ける判断軸を解説：比較表の設計から整理。
• 電子契約システムの比較と選び方とは？認証方式・連携・費用の判断軸を解説：製品単位の選定に進む段階で。
• 電子契約の費用相場とは？月額・送信料の内訳と無料プランの線引き：費用の内訳と無料プランの限界。