>
>
公開日
最終更新日
長期にわたり署名の検証可能性を維持する必要があるPDFでは、タイムスタンプを併用したPAdES-LTV形式の採用を検討します。保存期間、求める検証可能性、署名・タイムスタンプの付与時点、保管方式によって対応が異なるため、要件を確認した上で判断します。
Adobe Acrobat Sign（旧Adobe Sign）は、契約書の送信、署名依頼、進捗管理、監査証跡の保存を一元化する法人向け電子署名基盤です。Adobe Signという旧名称で検索されることも多い一方、2022年3月にAcrobat Signへリブランドされています。
情シス部門が検討する際は、単に電子署名を送れるかではなく、既存のCRM・文書管理・ID管理と連携できるか、送信数を予算内で管理できるか、監査ログや保存ルールを運用に組み込めるかで判断します。本記事では、製品の機能紹介にとどめず、導入前に整理すべき要件と失敗を防ぐ運用設計を解説します。
導入可否を決める4項目
対応SKUの確認：SSO、API、高度な認証など必要な機能がAcrobat ProとAcrobat Sign Solutionsのどちらに含まれるかを、利用予定機能の一覧をアドビ販売店へ提示して照合します。対象SKUが変わると見積金額と連携設計が変わるため、要件一覧の作成が先決です。→詳細は「Acrobat ProとAcrobat Sign Solutionsの機能差」の節。
送信数・トランザクション定義の確認：年間送信件数と「1トランザクション」の定義（差戻し・再送が加算されるかなど）を契約前に棚卸しします。定義がプランによって異なるため、見積書で対象SKUのトランザクション条件を確認した上で送信枠を算定します。→詳細は「年間150通のプール計算」の節。
保存・法務要件の確認：電子帳簿保存法の対象文書か、長期保存にPAdES-LTVが必要かを法務・税務担当と確認します。確認結果によって文書管理システムとの連携設計が変わります。→詳細は「長期保存とタイムスタンプの設計」の節。
連携可否の確認：CRM、人事、文書管理、ワークフローとのAPI連携がSign Solutionsの対象SKUで利用可能かを確認します。API連携が確認できれば限定検証に進み、確認できなければCSV連携や別サービスを含む業務設計に切り替えます。→詳細は「Microsoft 365と業務SaaSの連携」の節。
Adobe Acrobat Signとは
Acrobat Signは旧Adobe Signから改称された法人向け電子署名基盤です。
本記事のポイント
Adobe SignとAdobe Acrobat Signは名称変更前後の同一サービスです。
Acrobat Proの署名依頼機能とAcrobat Sign Solutionsは、組織管理や連携機能の範囲が異なります。SSO、管理者コンソール、API連携、高度な認証が必要になった時点でSign Solutionsが対象になるかを、アドビ販売店へ利用予定機能の一覧を提示して確認します。確認結果で対応SKUが変わるため、要件一覧の作成が先決です。
送信数を契約前に棚卸しすると、年度途中の追加コストを抑えられます。
電子契約の有効性は署名方式だけで決まらず、本人性・意思表示・証跡・運用を含めて評価します。
旧Adobe Signとの名称関係
アドビは2022年3月にAdobe SignをAcrobat Signへリブランドしました。「Adobe Sign」「Adobe Acrobat Sign」「Acrobat Sign」は同一サービスの新旧名称です。旧称で情報を探す取引先や社内利用者もいるため、運用マニュアルの初出では「Adobe Acrobat Sign（旧Adobe Sign）」と併記すると、名称の混乱による問い合わせを減らせます。本記事は法人向け導入設計を目的とするため、個人向けAcrobatライセンスの署名機能との使い分けは「Acrobat ProとAcrobat Sign Solutionsの機能差」の節で整理します。
名称変更は、PDF作成・編集・閲覧を含むAcrobat製品群との関係を明確にする目的です。ただし、Acrobatという名称が付くからといって、すべてのAcrobatライセンスで法人向け電子契約の統制機能を利用できるわけではありません。
Acrobat ProとAcrobat Sign Solutionsの機能差
少人数の署名依頼と、全社の電子契約基盤は分けて検討します。Acrobat ProはPDF編集を主目的とするライセンスであり、Acrobat Sign Solutionsは契約業務を組織横断で管理・連携するための提供形態です。
比較項目 | Acrobat Proの署名依頼機能 | Acrobat Sign Solutions |
|---|---|---|
主な用途 | PDF業務に付随する署名依頼 | 部門・全社の電子契約運用 |
管理対象 | 個人または限定的な利用者 | ユーザー、グループ、権限、テンプレート |
システム連携 | 要件に応じて利用範囲を確認 | APIや業務SaaS連携を前提に設計可能 |
認証・統制 | 基本的な署名依頼運用 | SSO、認証方法、監査、ブランド設定を含む設計 |
導入判断 | PDF作業の延長で使う場合 | 基幹・CRM・人事システムと接続する場合 |
アドビの公式案内では、署名済み文書をAdobe Document Cloudのほか、Box、Dropbox、Google Drive、Microsoft OneDriveへ保存できるとしています。保存先を既存の文書管理基盤に寄せられるかは、情シスの運用負荷に直結します。アドビの署名済み文書の保存先に関する案内も参照してください。
対象・提供状況の確認項目
認証方式、API、SSO、一括送信、送信上限、サポート範囲は契約形態や地域、購入チャネルで変わります。本記事では法人向け運用を前提に説明しますが、見積もり時には利用予定の機能を要件一覧にし、販売店またはアドビに対象SKUで利用できるかを照合します。API連携が確認できれば限定検証に進み、確認できなければCSV連携や別サービスを含む業務設計に切り替えます。
署名方式と証跡管理の仕組み
立会人型と当事者型の双方に対応し、業務ごとに認証強度と契約フローを設計できます。
立会人型と当事者型の使い分け
立会人型は、サービス上で送信・閲覧・署名の記録を残し、メール認証や追加認証を組み合わせて本人性を補強する方式です。取引先に電子証明書の準備を求めずに運用しやすいため、継続取引の契約、NDA、発注書などで採用されます。
当事者型は、署名者本人の電子証明書を用いて署名する方式です。電子署名法第3条は、本人だけが行える電子署名が付されている場合に、その文書が真正に成立したものと推定する規定です（推定効）。ただし、この推定効は「本人だけが行える署名」であることが前提であり、証明書の種類・発行方法・失効確認の有無など複数の要素を満たす必要があります。立会人型では署名者本人の電子証明書を用いないため、第3条の推定効を直接援用することは難しく、本人性の立証は送信先の特定、認証手段、閲覧・署名履歴などの証跡を組み合わせて行います。いずれの方式についても、推定効の適用可否は契約類型・認証の強度・権限管理・証拠関係の総合評価によって変わります。本記事は一般的な整理を示すものであり、個別の法的判断は法務部門が行います。高額取引や規制業種の契約では、証明書の発行元、本人確認方法、失効確認、署名者端末の運用まで含めて設計します。
監査証跡と本人性の評価
電子契約では、署名画像の有無だけで契約の有効性や証拠力が自動的に決まるわけではありません。署名依頼先の特定、認証手段、署名時刻、IPアドレス、閲覧・承認履歴、契約締結の権限、締結後の保管方法を組み合わせて説明できる状態を作ります。
Acrobat Signでは署名プロセスに関する監査レポートを残せます。情シス部門では、監査ログを誰が閲覧できるか、退職者アカウントをどう扱うか、監査や訴訟対応時にどの単位で出力するかを事前に決めます。監査ログをAPIで取得できる契約なら証跡保管庫への自動収集を設計し、取得できない場合は責任者による定期エクスポートと改ざん防止保管を運用に組み込みます。
長期保存とタイムスタンプの設計
デジタル庁は、保存が必要なPDFファイルへの電子署名について、タイムスタンプを併用したPAdES-LTV形式での作成を示しています。ただし、すべての文書に一律に適用される要件ではなく、保存目的・期間・対象制度によって要否が異なります。対象文書が電子帳簿保存法、e-文書法、業法上の保存義務のいずれに該当するかを法務・税務担当と確認した上で、PAdES-LTVの採用を判断します。PAdES-LTVは、将来に証明書が失効・期限切れとなった後も検証できるよう、検証情報をPDFに保持する長期署名形式です。デジタル庁の電子署名と長期保存に関する資料では、長期保存時の考え方を確認できます。
一方で、PDF/Aへの変換だけで電子帳簿保存法の検索要件に自動対応するわけではありません。取引年月日、取引金額、取引先を検索できる管理方法、訂正削除の履歴、事務処理規程などは別途必要です。契約書を保管する部門が検索項目を付与できるなら文書管理システムに連携し、付与できないなら契約台帳で補完する設計にします。
Acrobat Signの機能とシステム連携
Acrobat Signの価値は署名依頼そのものより、既存業務システムから契約処理を自動化できる点にあります。
署名ワークフローとテンプレート
送信者は、署名者、承認者、閲覧者を設定し、順番に処理するフローと同時に処理するフローを使い分けます。定型契約では、署名欄、日付、氏名、会社名、承認欄をテンプレート化すると、担当者がPDFごとにフィールドを配置する作業を減らせます。
Webフォームを使う場合は、公開範囲と回答データの保管先を先に定義します。採用応募や資料請求のように不特定多数から入力を受ける業務では、送信元メールアドレスの確認、個人情報の取扱い、重複申請時の処理、無効な入力の対応を設計してから公開します。
Microsoft 365と業務SaaSの連携
Microsoft 365を標準基盤にしている企業では、SharePointの保管ルール、Teamsの通知、Power Automateの承認フローと電子署名を分断しない設計が有効です。アドビはAcrobat Sign SolutionsがPower Automateを組み込み、Adobe側の追加費用なしでSharePointなどと連携した文書管理を構築できると紹介しています。ただし、Power Automateのプレミアムコネクタや高度な自動化を利用する場合は、Microsoft 365またはPower Platformのライセンス要件がテナント契約に依存して別途発生することがあります。Power Automateのライセンス条件はMicrosoftのライセンスガイドで確認し、必要なプランが現行契約に含まれているかを確認した上で連携設計に進みます。アドビのPower Automateと契約管理サービスの連携事例では、連携対象としてBUNTAN、Optim Contract、Contract Oneも案内されています。
Salesforce連携では、商談ステージの更新を契約締結状況と同期することで、営業担当がメールや表計算で進捗を追う作業を減らせます。パーソルホールディングスは、Adobe SignとSalesforceのAPI連携により、契約書作成時間を7分から10秒へ短縮したと公表しています。パーソルホールディングスの導入事例は、CRM連携を評価する際の参考になります。
AI利用時の情報管理
契約書の要約や条項抽出にAcrobat AI AssistantなどのAI機能を使う場合、契約書に含まれる個人情報、営業秘密、未公表の取引条件をどこまで入力できるかを先に決めます。利用規約、データ処理条件、学習利用の扱い、ログ保管、部門別の利用権限を確認し、機密区分が高い契約はAIに投入しない運用を採ります。
AIは契約内容の確認を補助できますが、法務判断を置き換える機能ではありません。条項の比較結果を法務レビュー前のチェックリストに転記する用途なら、見落としを減らす補助として使えます。
▲ Acrobat Signを中心とした業務システム連携の構成
部門別の導入提案と評価軸
各部門の業務システムやフローに応じた連携設計が全社定着の鍵です。
営業部門のCRM連携
営業部門では、見積、稟議、契約、受注、請求の情報がCRMや販売管理システムに分散しやすくなります。評価軸は、商談情報から契約書を生成できるか、契約送信後の状況をCRMに戻せるか、失注・差戻し時の担当変更を反映できるかです。
営業が契約書をローカルPCにダウンロードして送信する運用では、最新版の契約雛形を統制できません。CRMに登録された商品、取引先、金額をテンプレートに差し込み、法務承認済みの書式だけを送信できるなら、テンプレート逸脱を抑えられます。API連携が難しい場合は、まず定型契約だけを対象にしてCSV取り込みまたは手動送信で検証します。
人事・総務部門の雇用手続き
人事・総務部門では、雇用契約、誓約書、秘密保持契約、入社手続きの書類を扱います。評価軸は、入社予定者が社内アカウントを持たない状態でも署名できるか、本人確認をどこまで求めるか、入社後に人事システムへ保管情報を連携できるかです。
人事システムから対象者・入社日・所属を連携できるなら、対象者ごとに必要書類を自動判定する設計へ進めます。連携できない場合は、入社時期ごとの送信リストを二重承認にし、誤送信の検知を優先します。Microsoft Teamsなどの通知を使う場合も、契約書本文や個人情報を通知文に直接記載しないルールが必要です。
法務・経理部門の保存と検索
法務部門では、契約書の版管理、締結権限、更新期限、監査証跡を重視します。経理部門では、取引情報を検索できること、証憑保管のルールと矛盾しないこと、監査時に速やかに提出できることが評価軸になります。
法務・経理が保管責任を持つなら、契約種別、取引先、締結日、金額、保存年限、担当部署を最低限のメタデータとして統一します。電子帳簿保存法の対象文書を扱う場合は、電子取引データ保存の対象範囲を法務・経理・税務担当で分け、Acrobat Signの監査証跡と文書管理システムの検索台帳を対応付けます。
導入判断のチェックリスト
情シス部門では、製品比較の前に以下の項目を埋めると、必要なライセンスと連携範囲を絞り込めます。
月間の送信件数、繁忙月の最大件数、送信者数を部門別に集計する。
契約種別ごとに、立会人型・当事者型・追加認証の必要性を法務と決める。
契約書の正本保存先、検索項目、保管責任者、保存年限を定義する。
SSO、退職者アカウント停止、管理者権限、監査ログ出力の要件を整理する。
CRM、人事、文書管理、ワークフローのうち、初年度に連携するシステムを一つに絞る。
たとえば月間80件を12か月送信する部門では年間960件です。送信数が年150件のライセンス条件を適用する場合、960÷150で6.4となるため、送信枠だけで見れば7ライセンス相当の枠が必要になります。実際には繁忙月、差戻し、追加送信、部門横断利用を加味し、余裕枠を含めて見積もります。
Acrobat Signの使い方と署名手順
送信者と受信者の操作を分けて標準化すると、社内外の問い合わせを抑えながら署名を進められます。
送信者の基本手順
送信者は、契約内容と宛先を確認してから署名依頼を作成します。操作画面の名称や配置は更新されることがあるため、社内マニュアルには画面名だけでなく目的も併記します。
ステップ1：送信依頼の作成
Acrobat Signにログインし、送信機能から新しい署名依頼を作成します。テンプレートを使う場合は、契約種別と最新版の雛形を選びます。ステップ2：受信者と順序の設定
署名者、承認者、閲覧者のメールアドレスを登録し、順番に処理するか同時に処理するかを設定します。役職者の承認を挟む契約では、署名者と承認者を取り違えないようにします。ステップ3：文書と入力欄の配置
PDFなどの契約書を追加し、署名、氏名、日付、会社名などのフィールドを必要箇所に配置します。入力必須の項目は必須設定にし、不要な自由記入欄を残さないようにします。ステップ4：認証設定と送信
契約の重要度に応じてメール認証、パスワード、SMSなどの認証方法を選び、件名・メッセージ・有効期限を確認して送信します。送信後はダッシュボードで未署名、完了、却下を確認します。
受信者の基本手順
受信者はアカウント作成を求められない構成でも、署名依頼メールから内容確認と署名を進められます。取引先に案内する際は、メールの送信元ドメインと正規の操作手順を事前に共有し、フィッシング対策も兼ねます。
ステップ1：依頼メールの確認
受信者は送信元、件名、契約相手、契約内容を確認し、署名依頼メール内のリンクを開きます。不審なメールの場合はリンクを開かず、担当窓口へ確認します。ステップ2：認証の実施
パスワードやSMS認証が設定されている場合は、案内に従って認証を完了します。認証情報を第三者に転送しないことを署名案内に明記します。ステップ3：契約内容と入力欄の確認
文書全体を確認した上で、署名欄、日付欄、氏名欄など指定された入力項目を埋めます。内容に修正が必要なら署名せず、送信者へ差戻し方法を連絡します。ステップ4：署名と完了通知の保管
最終確認後に署名を実行し、完了通知と署名済み文書を保管します。受信者側の保管場所を定める場合は、メールだけでなく正式な文書管理先へ保存します。
一括送信の運用条件
同一書式を多数の相手に個別送信する業務では、一括送信機能を使うことで宛先ごとの送信作業を減らせます。ただし、一括送信は宛先・差し込み項目・署名順序の誤りを大量に広げるリスクがあります。初回はテスト用の内部アドレスで送信結果を確認し、宛先CSVの作成者と承認者を分ける運用にします。
「一括送信」と「複数の署名者が同一契約書に順番に署名する処理」は別の要件です。前者は同じ文書を複数人へ個別送付する用途であり、後者は一つの契約に複数当事者の署名を集める用途です。要件定義では件数だけでなく、文書単位と署名者単位を分けて確認します。
▲ 送信者における署名依頼作成から送信までの基本4ステップ
料金体系と送信数の管理
Acrobat Signの費用は送信者数だけでなく、年間トランザクション数と必要な連携・認証機能で決まります。
料金情報の扱い方
Acrobat Sign Solutionsの法人向け価格は、送信数、連携要件、認証、サポート、契約期間により個別見積となる場合があります。本記事の価格例・送信枠条件・連携機能の記述は2024年時点の公開情報を参照していますが、対象プラン・販売チャネル・契約時期によって変動します。予算策定時は、アドビ販売店または公式サイトの最新見積もり条件と照合した上で数値を使います。料金は税別・税込、年額・月額、初期費用・追加送信枠を同じ条件で並べます。
本節以降で「契約条件により異なる」「対象SKUを確認する」と記載している事項を下表に集約します。見積もり依頼時にこの一覧を販売店へ提示すると、確認漏れを防げます。
確認項目 | 確認先 | 確認結果による判断の分岐 |
|---|---|---|
年間トランザクション数の定義・プール可否 | 見積書またはアドビ販売店（対象SKUを指定） | プール可なら全社共通枠で予算化、不可なら部署別配分で管理 |
超過時の扱い（上限停止・追加課金・交渉） | 見積書の超過条件欄 | 追加課金なら繁忙月の余裕枠を事前確保、停止なら優先度付けを設計 |
SSO・API・高度な認証の対象プラン | アドビ販売店（利用予定機能の一覧を提示） | 含まれるならSign Solutionsで設計、含まれないならAcrobat Proの範囲で運用 |
Power Automateプレミアムコネクタのライセンス要件 | MicrosoftライセンスガイドまたはMicrosoft担当者 | 現行M365契約に含まれるなら追加費用不要、含まれないならPower Platform単体プランを追加 |
署名済み文書の保存先（Box・OneDrive等）の対象プラン | アドビ公式サイトまたは販売店 | 対象プランに含まれるなら文書管理基盤と直接連携、含まれないならAPI連携またはCSVエクスポートで補完 |
海外拠点・中国本土のアクセス可否 | アドビ公式サポート・現地IT・現地法務 | 利用可なら対象拠点を含む運用テストへ、不可なら現地で承認された契約手段を併用 |
Acrobat Standardが年額24,000円なら月額換算は2,000円であり、Acrobat Proが年額33,600円なら月額換算は2,800円です。ただし、これは年額を12か月で割った計算例であり、Acrobat Sign Solutionsの見積金額ではありません。PDF編集ライセンスの料金と電子契約基盤の料金を同じ表に混在させないようにします。
年間150通のプール計算
ユーザーライセンス型で「1ライセンスあたり年間150トランザクション」という契約条件が適用される場合、送信枠はライセンス数に応じて算出します。この条件は特定のプラン・販売チャネル・契約時期に基づく例示であり、すべての契約形態に共通する仕様ではありません。適用プランの実際のトランザクション条件は、見積もり時にアドビ販売店へ対象SKUを指定して照合します。たとえば10ライセンスなら、年間送信枠は150件×10ライセンスで1,500件です。組織内でプール利用する契約では、特定の送信者が多く使っても全体枠内であれば利用できます。
年間送信見込み | 150通換算の必要枠 | 計算 | 判断 |
|---|---|---|---|
600通 | 4ライセンス相当 | 600÷150＝4 | 繁忙月を確認して余裕枠を見積もります。 |
960通 | 7ライセンス相当 | 960÷150＝6.4、切り上げ | 送信者数とプール条件を確認します。 |
1,500通 | 10ライセンス相当 | 1,500÷150＝10 | API大量送信の有無で別契約も比較します。 |
トランザクションの数え方、プール可否、超過時の扱いは契約条件で異なります。見積書でプールの対象範囲が確認できれば全社共通の送信枠として予算化し、確認できなければ部署別に枠を配分して超過リスクを管理します。
超過防止の運用
送信数は、月次で「累計送信数」「年間枠に対する消化率」「残り3か月で必要な見込み」を可視化します。年間枠1,500通で9か月終了時点に1,250通を使っている場合、消化率は83.3％です。残り250通で最終四半期を運用できないなら、追加枠の交渉、対象契約の優先順位付け、紙運用の復活ではなく既存枠の再配分を早期に判断します。
導入時の失敗パターンと対策
導入の失敗は製品機能の不足より、要件定義と運用責任の曖昧さから起こります。
送信制限の誤認
よくある失敗は、送信者アカウント数だけを数え、年間送信数を把握しないまま全社展開することです。営業の繁忙期、人事の入社時期、契約更新月が重なると、通常月の件数から算定した枠を超える場合があります。
対策は、過去12か月の紙・メール・既存電子契約を含めて契約件数を集計し、契約種別ごとに送信数を見積もることです。件数を取得できるなら上位3部門から限定導入し、取得できないなら1か月間の実測を行ってからライセンス数を確定します。
権限管理と退職者アカウントの放置
電子契約では、管理者がテンプレート、送信履歴、契約書本文へアクセスできる場合があります。退職・異動後のアカウントを無効化しないと、情報漏えいだけでなく、誰が送信した契約かを説明できなくなる問題につながります。
IdP連携が利用できる場合は、入退社フローと連動してアカウントを制御します。連携できない場合は、人事異動一覧を基に月次で利用者棚卸しを行い、管理者権限は複数人へ分散しつつ付与理由を記録します。
取引先への案内不足
署名依頼の画面やメール文面はサービス更新で変わることがあります。社内手順書の画面キャプチャだけに依存すると、更新後に担当者が案内できなくなります。
取引先向けには、画面の色やボタン位置ではなく、「依頼メールを受け取る」「契約内容を確認する」「必要な認証を行う」「署名完了メールを保管する」という手順をA4一枚にまとめます。社内向けには、更新情報を確認する担当と、マニュアル改訂の承認者を決めます。
海外拠点・中国本土取引の事前確認不足
海外の署名者を含む契約では、利用可能な地域、データ保管、本人認証、現地法令、相手先の社内規程を確認しないまま導入すると、締結直前に手続きが止まるおそれがあります。中国本土を含むアクセス可否や対象範囲は、公開情報だけで一律に判断せず、契約前にアドビの公式サポート、現地IT部門、法務部門へ照会します。
利用可否が確認できれば対象拠点を含めた運用テストに進み、確認できない場合は当該取引に限って現地で承認された契約手段を併用します。VPNによるアクセス制限の回避を安易に設計すると、現地法令、利用規約、相手先のセキュリティ規程に抵触するおそれがあります。
国内企業の導入事例
導入効果は電子署名の利用自体ではなく、既存システムとの接続範囲と対象業務の絞り込みで変わります。
パーソルホールディングスのCRM連携
業種・規模は人材サービスを中心とする企業グループです。アドビは、パーソルホールディングスがAdobe SignとSalesforceをAPI連携し、契約書作成にかかる時間を7分から10秒へ短縮したと紹介しています。課題は契約書作成に伴う手作業であり、施策はCRMに蓄積された情報を契約プロセスへ連携することでした。成果は、契約書作成時間の短縮です。
この事例からは、電子署名の導入前に入力元となるCRMデータを整備する必要があると分かります。取引先名、契約主体、担当者、商品、金額のマスタが統一されているなら、営業部門の定型契約から連携範囲を広げられます。
株式会社Spartyの契約業務削減
業種・規模はパーソナライズヘアケア事業を手がける企業です。株式会社Tooは、SpartyがAcrobat Signを導入し、紙の契約と比べて1契約あたりの時間・工数を約50％削減したと紹介しています。課題は紙の契約に伴う送付、回収、保管の負荷であり、施策は契約締結の電子化でした。成果は、契約単位での作業時間・工数の削減です。株式会社SpartyのAcrobat Sign導入事例で詳細を確認できます。
紙契約の削減効果を見積もる場合は、郵送費だけではなく、印刷、押印依頼、回収督促、スキャン、保管、契約台帳更新を分解します。工程別に削減対象を定義すると、導入後に成果を測定できます。
市場動向と導入判断
国内電子契約サービス市場は拡大傾向にあるとされており、サービスの選択肢も増えています。市場の拡大は選択肢の多様化を意味しますが、自社に必要な連携、保存、認証、送信数の条件を満たすかは別途比較が必要です。
Adobeの公式紹介では、Acrobat Sign SolutionsはPower Automateや契約管理サービスとの連携を想定しています。Microsoft 365やSalesforceが契約業務の中心にある企業では連携要件を優先し、国内取引先の利用体験を最優先する企業では相手方の受容性やサポート体制を比較軸に加えます。
まとめ
Adobe Acrobat Signは、旧Adobe Signから改称された法人向け電子署名基盤です。導入判断では、Acrobat Proの機能だけで足りるのか、Acrobat Sign Solutionsで組織管理やAPI連携まで行うのかを切り分けます。最初の一歩は、過去12か月の契約送信件数、送信者数、保存先、認証要件を部門別に棚卸しすることです。年間送信数と連携要件が整理できれば、必要なライセンス枠と限定導入の対象業務を具体化できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
