最初の報告：2024 年 8 月
最終更新日 :
2026年2月10日
以下の Adobe Acrobat Sign の技術的なお知らせは、最も古いアップデートから順に記載されています。
|
|
現在のリストからの削除：2025 年 1 月 |
|---|
従来の Accept-Charset ヘッダーは、2024 年 11 月のリリースですべての Webhook およびコールバック通知から削除されます。
何らかの理由でこのヘッダーに依存するすべてのお客様は、ヘッダーが欠落した場合を考慮して、コードをリファクタリングする必要があります。
|
最初の報告：2024 年 9 月 |
現在のリストからの削除：2025 年 1 月 |
|---|
|
最初の報告：2024 年 11 月 |
現在のリストからの削除：2025 年 1 月 |
|---|
2024 年 11 月のリリースで、カスタムワークフローデザイナーの編集可能なラベルが 100 文字に制限されました。 この制限は、ワークフローの作成または更新時に評価されます。
ラベルが 100 文字を超える既存のワークフローでも正常に送信できますが、ワークフローが更新された場合、ラベルは、保存するには 100 文字以下に減らす必要があります。 問題のあるラベルは、わかりやすいように赤で示されます。
新しいワークフローは、保存される前に、ラベル制限について警告されます。
必要な対応
カスタムワークフローを制御する管理者はカスタムワークフローを開き、各ワークフローを確認して、テンプレートにエラーがないことを確認することをお勧めします。
|
最初の報告：2024 年 11 月 |
現在のリストからの削除：2025 年 2 月 |
|---|
新しい受信者エクスペリエンスには、デスクトップとモバイルの両方の web ブラウザーでの署名の改善が含まれています。この新しいエクスペリエンスは 2025 年の最初の数か月間に展開されますが、サンドボックス環境では 2024 年 12 月第 1 週目にご利用いただけるようになります。
|
最初の報告：2024 年 12 月 |
現在のリストからの削除：2025 年 2 月 |
|---|
Adobe Acrobat Sign で 2025 年 1 月 22 日に Adobe Acrobat Sign SSL 証明書がローテーションされます。
また、新しい SSL 証明書がデプロイされ、2025 年 1 月に実行される WAF ネットワークの変更がサポートされるようになります。 この新しい証明書は、Acrobat Sign サービスへのアクセスに直接影響し、WAF がオンラインに移行する前にインストールする必要があります。
必要な対応
- ネットワークアクティビティを明示的に保護するすべての顧客アカウントは、保存された証明書のリストに新しい WAF SSL 証明書を含める必要があります。
- SOAP または REST API を使用して Acrobat Sign との統合をすでにカスタムで構築して、それらの統合のいずれかで既存の公開鍵を「ピン留め」している場合は、特に操作は必要ありません。
- SSO に Acrobat Sign の SSL 証明書を使用している場合、または証明書自体をピン留めしている場合（またはその他の方法を使用して証明書をピン留めしている場合）、Adobe Acrobat Sign の必要システム構成で新しい Acrobat Sign SSL 証明書を取得できます。
- SSO 設定が複数のパブリック証明書／チェーンをサポートしている場合は、1 月の切り替え後に新しい証明書を追加して、古いパブリック証明書／チェーンを設定から削除することができます。
- SSO が複数のパブリック証明書／チェーンをサポートしていない場合は、2025 年 1 月 22 日に Acrobat Sign と SSL の切り替えを同期する必要があります。
新しい SSL 証明書は、2025 年 1 月 22 日に有効になります。
|
最初の報告：2025 年 9 月：2025 年 2 月更新 |
現在のリストからの削除：2025 年 3 月 |
|---|
Adobe Acrobat Sign サービスのセキュリティと堅牢性を向上させるために、web アプリケーションのファイアウォール（WAF）を含むネットワークの変更を 2025 年前半に実施予定です。 これらの変更では、WAF サービスを通じて、Acrobat Sign アプリケーションサーバーにトラフィックをルーティングします。 このルーティングは、ほとんどのお客様には表示されません。 この使用法により、Adobe クライアントまたは統合からの Acrobat Sign へのアクセスが妨げられることはありません。
必要な対応
必要な対応はありません。
Acrobat Sign API および API ドメイン名は変更されないため、この変更によってお客様の統合が影響されることはありません。 この解決策は、公開されている IP 範囲と下位互換性があります。
セキュリティデバイスを更新したお客様は、元に戻したり、その他の変更を行ったりする必要はありません。
現在の更新スケジュールは次のとおりです。
- 本番サンドボックスは、2025 年 2 月 24 日に更新されます。
- 本番シャード：IN1、JP1、AU1、SG1 は、2025 年 3 月 3 日に更新されます。
- 本番シャード：NA2、NA3、EU2 は、2025 年 3 月 6 日に更新されます。
- 本番シャード：NA1、NA4、EU1 は、2025 年 3 月 11 日に更新されます。
-
Acrobat Sign への着信アクセスと発信アクセス
Acrobat Sign では、以前にお知らせしたサーバー着信 IP アドレスリストのサポートを継続することになりました。
Acrobat Sign のシステム要件ページに記載されているとおり、サーバー着信および発信 IP アドレスは、引き続き使用可能となります。 -
Acrobat Sign でこれらの変更が行われる理由は何ですか？
WAF を使用すると、有害なトラフィックに対する Acrobat Sign の保護が向上し、セキュリティ、堅牢性、コンプライアンスの要件をより適切に満たすことができます。
-
Acrobat Sign へのカスタム統合があります。 私のアプリケーションに影響はありますか？
いいえ。統合が悪影響を受けることはありません。
-
置き換え可能な新しい IP アドレスリストはありますか？
いいえ。
Acrobat Sign のシステム要件ページの情報が正しいままです。 -
私の組織では、Acrobat Sign の公開ドメインリストを使用してネットワークフィルタリングを実装し、企業ネットワークからのトラフィックに対応しています。 私の組織は影響を受けますか？
いいえ。
ここで説明するネットワークの変更は、Acrobat Sign のシステム要件ページに記載されているように、Acrobat Sign のドメインリストには影響しません。ドメインレベルのフィルタリングは影響を受けません。 -
私の組織では、Acrobat Sign サーバーから電子メールを配信するために IP アドレスの検証を採用しています。 私の組織は影響を受けますか？
いいえ。
Acrobat Sign のシステム要件ページに示されている、送信メールリレーの IP 範囲は変更されません。 -
私の組織では、独自の IP アドレスへのアクセスを制限するように Acrobat Sign アカウントを設定しています。 私の組織は影響を受けますか？
いいえ。
Acrobat Sign は、IP アドレス範囲を使用したアカウントへのアクセス制限ページで説明されているように、お客様が選択した IP アドレスに対して受信トラフィックを検証するように設定できます。このような使用法は、この変更の影響を受けません。 -
私の組織では、Acrobat Sign の着信 IP アドレスの公開リストを使用してネットワークフィルタリングを実装しています。 私の組織は影響を受けますか？
いいえ。
新しい WAF 設定は既存のネットワークアーキテクチャと下位互換性があるため、セキュリティデバイスへの追加の調整は不要です。
注意：これは、アプリケーションをホストする環境の IP レベルのフィルタリングを示していることに注意してください。 ドメインレベルのフィルタリングは影響を受けません。
-
Salesforce 統合と明示的に設定された IP の許可リストを使用しています。 何か必要なことはありますか？
いいえ。
この時点で、既存の Salesforce のインストールでは、WAF のインストールに変更は必要ありません。
ヘルプドキュメントに記載されているとおり、既存の設定／プロセスは保持され、管理者は IP の許可リストのすべての手順を実行する必要があります。
ISV および Embed パートナーは、サクセスマネージャーに連絡して、詳細の内容についてお問い合わせいただけます。
|
最初の報告：2024 年 11 月 - 2025 年 1 月更新 |
現在のリストからの削除：2025 年 3 月 |
|---|
送信者は、受信者が使用可能な契約書内のフィールドのみを一覧表示する、モバイル受信者向けの契約書の追加ビューを提供できます。
送信者は、フィールドリストを自由に配置したり、フィールドを論理的なセクションにグループ化したりして、署名者が最小限のスクロールでフィールド入力間を移動できるように設定できます。
受信者は、モバイル対応のフィールドリストを表示するか、文書コンテンツ内に配置されているフィールドを含む元の PDF ビューを表示するかを選択できます。
この機能は、次のようにリリースされる予定です。
- 2024 年 12 月 11 日にサンドボックス環境にデプロイされる予定
- 2025 年 3 月 4 日に本番環境にデプロイされる予定
|
最初の報告：2024 年 5 月 |
現在のリストからの削除：2025 年 3 月 |
|---|
新しい「署名を依頼」機能では、ファイルのアップロードに外部ドライブを使用するオプションは、OneDrive のみに限定されます。
ファイルのアップロードに他のオプションを使用しているお客様は、ベンダー固有のアプリケーションを使用して、ユーザーのローカルシステム上のネイティブファイルピッカーからアクセス可能なネットワークドライブを提供することをお勧めします。
- Dropbox：https://www.dropbox.com/desktop
- Google ドライブ：https://support.google.com/drive/answer/10838124
- Box：https://support.box.com/hc/ja/articles/360043697194-Box-Sync%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB
- Acrobat/Document Cloud：https://www.adobe.com/acrobat/hub/share-sync-pdfs.html
|
最初の報告：2024 年 5 月 |
現在のリストからの削除：2025 年 4 月 |
|---|
必要な対応
機能を継続するには、Adobe Acrobat Sign SOAP API を使用するすべての統合およびアプリケーションを、無効化の実施日より前に最新の REST API V6 に移行する必要があります。
すべての Embedded パートナーに対する SOAP API へのアクセスは、2025 年 3 月 1 日以降に削除されます。
機能を引き続き使用するために、Adobe Acrobat Sign SOAP API を使用するすべての Embed パートナーは、2025 年 3 月 1 日より前に最新の REST API V6 に移行する必要があります。
詳しくは、REST v6 および移行に関するドキュメントを確認してください。
- Adobe Acrobat Sign REST API バージョン 6 メソッド
- SOAP からの移行
ご不明な点がある場合は、担当の Adobe Acrobat Sign PSM にお問い合わせください。
注意：
この更新は、Acrobat Sign サービスの商用バージョンにのみ適用されます。 Government Cloud アカウントは影響を受けません。
この更新は、送信（電子サインを依頼）ページにのみ適用されます。 構造化された自己署名ワークフローはまだ含まれていません。
|
最初の報告：2024 年 3 月 - 2025 年 1 月更新 |
現在のリストからの削除：2025 年 4 月 |
|---|
2025 年 4 月のリリース以降、最新の「署名を依頼」環境が新しい契約書を作成する際のデフォルト環境になります。
- 切り替えリンクは無効になり、ユーザーは新旧環境の切り替えができなくなります。
- 管理者は、管理者メニューから、従来の環境を有効にして切り替えリンクを復元することができます。
- Notarize 統合を使用しているお客様には、この変更の影響はありません。
|
最初の報告：2024 年 3 月 - 2025 年 4 月更新 |
現在のリストからの削除：2025 年 4 月 |
|---|
注意：
この更新は、Acrobat Sign サービスの商用バージョンにのみ適用されます。 Government Cloud アカウントは影響を受けません。
2025 年 4 月のリリースをもって、最新の「署名を依頼」環境が、新しい一括送信テンプレートを作成する際に使用できるデフォルト環境になります。
- ユーザーは、従来の環境に戻ることはできません。
- 管理者は、管理者メニューから、従来の環境を有効にして切り替えリンクを復元することができます。
|
最初の報告：2025 年 2 月 |
現在のリストからの削除：2025 年 4 月 |
|---|
Acrobat Sign アカウントレベル管理者が使用できる「アカウント」タブの名前が「管理者」に変更になります。
- この更新は、Acrobat Sign スタンドアロン環境（Acrobat Sign Solutions および官公庁用 Acrobat Sign）のみに適用されます。
- この更新は、商用環境では、2025 年 4 月に実施され、官公庁環境では、2025 年 5 月に実装されます。
この変更は単なる外観上の変更であり、機能上の変更はなく、タブラベルの更新のみであることにご注意ください。
注意：
グループレベルの管理者の「グループ」ラベルは変更されません。
|
最初の報告：2025 年 3 月 |
現在のリストからの削除：2025 年 4 月 |
|---|
- ユーザーログインエクスペリエンスの改善 - Acrobat Sign では、Adobe Identity Management システム（IMS）を通じたログインおよび認証プロセスが合理化されました。
- Acrobat Sign サービスの使用権限を持つユーザーの組織プロファイルがログインプロセス中に自動的に選択されます（Acrobat Sign ソースから要求が来ていることを識別します）。
- ログイン中にエラーが発生するユーザーには、エラーメッセージにリンクが表示され、Acrobat Sign 管理者に連絡してサポートを受けることができます。
- アクティブな権限が割り当てられているが、サービスにログインしていないすべてのユーザーに、最大 2 件の電子メールリマインダーが送信されます。 （これは、リリース日より前の既存の非アクティブなユーザーにも適用されます）
これらの改善により、ログインが簡素化され、手間が省け、全体的なユーザーエクスペリエンスが向上します。
使用可能な環境：商用 | 利用可能なサービスレベル：Acrobat Sign Solutions | 設定範囲：デフォルトで有効、設定不可
|
最初の報告：2025 年 3 月 - 2025 年 4 月更新 |
現在のリストからの削除：2025 年 6 月 |
|---|
2025 年 5 月のリリース以降、Acrobat Sign では、開発者レベルのアカウントに作成される webhook の数に、より厳格な制限が実装されます。
これらの制限は、webhook インフラストラクチャの信頼性を確保するために意図的に選択され、ワークフローのテストに向けて、より適切に調整されています。
|
変更点 |
以前の制限 |
新しい制限 |
説明 |
|---|---|---|---|
|
チャネルごとに作成されたアクティブな webhook の数 |
10 |
1 |
1 つの webhook が、チャネルに対して webhook サブスクリプションイベントごとに許可されます。 |
|
アカウントに対して作成されたアクティブな webhook の数 |
100 |
2 |
2 つのアカウントレベル webhook が、webhook サブスクリプションイベントごとに許可されます。 |
|
グループごとに作成されたアクティブな webhook の数 |
100 |
2 |
2 つのグループレベル webhook が、1 グループあたり webhook サブスクリプションイベントごとに許可されます。 |
|
契約書リソースごとに作成されたアクティブな webhook の数 |
50 |
1 |
1 つの webhook が、1 契約書あたり webhook サブスクリプションイベントごとに許可されます。 |
|
ユーザーごとに作成されたアクティブな webhook の数 |
100 |
1 |
1 つの webhook が 1 人のユーザーごとの webhook サブスクリプションイベントに対して許可されます。 |
使用可能な環境：商用 | 使用可能なサービス階層：開発者 | 設定範囲：デフォルトで有効、設定なし
|
最初の報告：2025 年 3 月 |
現在のリストからの削除：2025 年 4 月 |
|---|
Acrobat Sign のお客様は、Acrobat Sign webhook サービスを購入して、Adobe Status ポータルから停止、中断、およびメンテナンスイベントに関するプロアクティブな通知を受信できるようになりました。
サブスクリプションを管理および追加するには、Adobe Status サブスクリプションに関するヘルプを参照してください。
Adobe Acrobat Sign サービスは、Document Cloud ヘッディングの下に表示されています。
|
最初の報告：2025 年 3 月 |
現在のリストからの削除：2025 年 6 月 |
|---|
2025 年 5 月のリリースでは、応答時間を大幅に短縮するために、GET /agreements API を最適化しています。内部テストでは、最大 10 倍の改善が示されています。
変更点
- ページサイズの削減：これらの改善に対応するために、要求ごとに返される契約書の最大数を 500 件に削減しました。この制限は、今後のリリースで変更される可能性があります。 各応答には、以下が含まれます。
- 返された契約書の実際の数
- 結果の次のページへのリンク（使用可能な場合）
- 動的な結果数：特定の数の契約書を要求できますが、API はサービスで提供可能な数のみ返します。 各応答には、以下が含まれます。
予測される状況
場合によっては、契約書の作成と GET /agreements API を使用した取得の間にわずかな遅延が発生する場合があります。 この遅延は通常非常に短く、後続する要求により、新しい契約書が返されます。
使用可能な環境：商用、官公庁 | 利用可能なサービスレベル：Acrobat Sign サービス、官公庁 | 設定範囲：デフォルトで有効、設定不可
|
最初の報告：2025 年 4 月 |
現在のリストから削除：2025 年 8 月 |
|---|
「Acrobat Sign for Government」サービスを使用しているすべてのアカウントには、新しい「署名を依頼」エクスペリエンスと、最近作成されたその環境に依存する複数の機能を有効にするためのアクセス権が付与されます。
- eWitnessing
- 契約書へのアクセス制限
- 署名タイプの強制
- ID チェック
- 受信者ごとの CC
- 受信者リストと受信者プロパティは、オーサリング後に編集可能
|
最初の報告：2024 年 9 月 |
現在のリストから削除：2026年2月 |
|---|
必要な対応
この API を使用しているすべてのお客様は、中断のないサービスを確保するためにも、バージョン 6 エンドポイントをできる限り早く利用できるように API を更新する必要があります。
2025 年 12 月 1 日付けで、Acrobat Sign REST API のバージョン 1～4 は廃止され、サービスから削除される予定です。
API の更新には多大な労力が必要となる可能性があるため、2025 年 12 月の廃止日前に発生する質問や問題を解決するために十分なサポートが得られるよう、すべてのお客様はできる限り早く更新の範囲と予算を設定することを強くお勧めします。
REST API v1～4 は廃止されますが、REST API v1～4 が削除される 2025 年 12 月 1 日まで、REST API v1～4 は引き続き機能し、アプリケーションは動作を継続します。
2025 年 12 月 1 日以降、REST API v1～4 上に構築されたアプリケーションは機能しなくなります。
|
最初の報告：2025 年 4 月 |
現在のリストから削除：2026 年 2 月 |
|---|
「Acrobat Sign for Government」サービスを使用しているすべてのアカウントには、新しい「署名を依頼」エクスペリエンスと、最近作成されたその環境に依存する複数の機能を有効にするためのアクセス権が付与されます。
- eWitnessing
- 契約書へのアクセス制限
- 署名タイプの強制
- ID チェック
- 受信者ごとの CC
- 受信者リストと受信者プロパティは、オーサリング後に編集可能
|
最初の報告：2024 年 9 月 - 2025 年 4 月更新 |
現在のリストから削除：2026 年 2 月 |
|---|
Webhook 2.0 インフラストラクチャはすべてのお客様に展開されました。この完了に伴い、署名者への通知は廃止されました。 その結果、webhook ペイロードの webhookNotificationApplicableUsers パラメーターは有用なデータを提供しなくなり、すべての webhook ペイロードから削除されます。
サンドボックス環境は 2025 年 6 月のリリースで更新される予定です。
本番環境は 2025 年 7 月のリリースで更新されます。
送信ユーザー ID と電子メールは、通知ペイロードの initiatingUserId および initiatingUserEmail パラメーターを使用して取得できます。
|
最初の報告：2025 年 8 月：2025 年 10 月更新 |
現在のリストから削除：2026年2月 |
|---|
システムの安定性を維持し、パフォーマンスを向上させるため、Acrobat Sign では、2025 年 11 月 4 日のリリース（バージョン 16.2.1）でポーリングのしきい値を導入します。 この変更により、クライアントアプリケーションが特定の API エンドポイントをポーリングできる頻度が制限されます。
- 16.2.1 リリース後 2 か月以内に、お客様はコードで推奨されるポーリングの変更を実装する必要があります。 この期間中、システムはポーリング間隔のしきい値イベントのみをログに記録します。
- 2025 年 12 月以降、ポーリング保護ポリシーは「強制」モードに切り替わり、ユーザーに対してエラーのトリガーが開始されます。
高頻度のポーリングはバックエンドシステムに不要な負荷をかけ、パフォーマンスの低下や応答時間の遅延を引き起こします。 API 開発者はリアルタイムの更新にウェブフックを使用することをお勧めします。
価格改定の対象となるプラン
このポーリングポリシーは、すべての GET API エンドポイントに適用されます。
影響を受けるエンドポイントの例
ステータス取得：
- GET /agreements/{agreementId) – 契約書の現在のステータスを取得します。
- GET /agreements/{agreementId)/documents/{documentId) – 契約書内の文書のファイルストリームを取得します。
リスト表示：
- GET /agreements – ユーザーの契約書を取得します。
- GET /agreements/{agreementId)/events – 契約書のイベント情報を取得します。
実効ユーザーが Acrobat Sign サービスに同じ API 呼び出しを行える頻度に制限が適用されます。 同じ実効ユーザーが最小ポーリング間隔内に同じ呼び出しを行うと、エラーが返されます。
ポーリングポリシーの詳細
- 最小オブジェクトポーリング間隔（MOPI）：デフォルトの MOPI は、サービスのレベルやアプリケーションの種類によって以下のように異なります。
- Acrobat Sign パートナーアプリケーション：パートナーアプリケーションの MOPI は、ユーザーのアカウントのレベルによって決定されます。
- グローバル／エンタープライズ版レベル：1 分間隔で 3 回のコール
- その他のすべてのレベル：10 分間隔で 1 回の一意のコール
- グローバル／エンタープライズ版アカウントのカスタマーアプリケーション：1 分間隔で 3 回の同一コール。
- 開発者アカウントのカスタマーアプリケーション：10 分間隔で 1 回の一意のコール
- Acrobat Sign パートナーアプリケーション：パートナーアプリケーションの MOPI は、ユーザーのアカウントのレベルによって決定されます。
- MOPI 内の重複リクエスト：同じ有効なユーザーが、許可されたティアを超えて同一の GET リクエスト（同じパスとヘッダー）を MOPI 内で複数回行った場合、システムは以下を返します。
- ETag を使用する HTTP 条件付きリクエストに対する 304 Not Modified ステータスコード。
- その他のリクエストに対する retry-after を含む 429 Too Many Requests ステータスコード。
- ETag の処理：このポリシーは、If-None-Match ヘッダーで ETag 値が提供され、既に 304 Not Modified をサポートしているエンドポイントに適用されます。
必要な対応
Webhook：アプリケーションがほぼリアルタイムの更新を必要とする場合は、ポーリングの代わりに webhook を使用します。 Webhook は、タイムリーな更新を受け取るためのより効率的でスケーラブルな方法を提供します。
Webhook を実装できない場合、アプリケーションは API レスポンスを保存して再利用するためのクライアントサイドのキャッシュメカニズムを実装する必要があります。 304 Not Modified レスポンスを受け取った場合、別の API 呼び出しを行う代わりにキャッシュされたデータを使用する必要があります。
16.2.1 リリース後 2 か月以内に、お客様はコードで推奨されるポーリングの変更を実装する必要があります。 この期間中、システムはポーリング間隔のしきい値イベントをログに記録します。
2025 年 12 月以降、ポーリング保護ポリシーは「強制」モードに切り替わり、ユーザーに対してエラーのトリガーが開始されます。
サポートが必要な場合や質問がある場合は、担当の CSM にお問い合わせください。
サンドボックス環境では、2025 年 9 月 17 日にポーリングポリシーが有効化され、エラーをログ記録するようになり、2025 年 9 月 25 日には「強制」モードに設定されます。
|
最初の報告：2025 年 8 月 |
現在のリストから削除：2026年2月 |
|---|
FedRAMP CSP 要件に対応するため、「Acrobat Sign for Government」環境で IPv6 プロトコルを有効化します：
- 2001:489a:3102:4::160/124（IPv6）
- 2001:489a:3102:4::150/124（IPv6）
|
最初の報告：2025 年 9 月 |
現在のリストから削除：2026 年 2 月 |
|---|
API を介して契約書を作成する場合の言語設定検証が強化されました。 契約書ロケールがアカウントのポリシーによって許可されていない場合、API が明確なエラーでリクエストを却下します。 これにより、意図しない言語不一致が減少し、受信者エクスペリエンスと設定が一致するようになります。
対象者
- API リクエストで契約書ロケールを設定するアカウント。
- 使用可能なロケールを制限したり、送信中のロケール変更を禁止したりするアカウント。
変更点
DISPLAY_LOCALE_INFO_DURING_SEND 設定が有効（GLOBAL レベル）の場合、API が以下を強制します。
- ユーザーの AVAILABLE_LOCALES に契約書のロケールが含まれる必要があります。
- ALLOW_LOCALE_SELECTION_DURING_SEND が false の場合、契約書のロケールはユーザーの AGREEMENT_LOCALE と一致する必要があります。
違反があると、POST /agreementsは「ロケールが無効であるか、欠落しています。」というエラーで失敗します。
一般的なエラーとその修正方法
エラー：「ロケールが無効であるか、欠落しています。」
- APIリクエストで使用されているロケール（例：en_US）を確認してください。
- そのロケールが呼び出しユーザーのAVAILABLE_LOCALESに含まれていることを確認してください。
- ALLOW_LOCALE_SELECTION_DURING_SEND が false の場合、リクエストのロケールが AGREEMENT_LOCALE と一致することを確認してください。
- 地域間の柔軟性が必要な場合は、送信時のロケール選択を有効にしてください（必要なアクションを参照）。
後方互換性
- この変更以前は、ロケールが一致しないリクエストが成功する場合がありました。 現在は、検証に合格しない場合、そのようなリクエストは明確なエラーで失敗します。
- API スキーマの変更はありません。検証動作は DISPLAY_LOCALE_INFO_DURING_SEND が有効な場合にのみ変更されます。
必要な対応
管理者および API インテグレーターは、次のいずれかを行う必要があります。
- API リクエストのロケールを AVAILABLE_LOCALES に揃え、ALLOW_LOCALE_SELECTION_DURING_SEND が false の場合は AGREEMENT_LOCALE と正確に一致させる
- または -
- 次を設定することで、送信時のロケール選択を許可：
- ALLOW_LOCALE_SELECTION_DURING_SEND = true
- CAN_CHANGE_UI_LOCALE = true
|
最初の報告：2025 年 12 月 |
現在のリストから削除：2026年2月 |
|---|
Adobe Acrobat Sign で 2026 年 1 月 7 日に Adobe Acrobat Sign SSL 証明書がローテーションされます。
必要な対応
- REST API を使用して Acrobat Sign との統合をすでにカスタムで構築して、それらの統合のいずれかで既存の公開鍵を「ピン留め」している場合は、特に操作は必要ありません。
- SSO に Acrobat Sign の SSL 証明書を使用している場合、または証明書自体をピン留めしている場合（またはその他の方法を使用して証明書をピン留めしている場合）、Adobe Acrobat Sign の必要システム構成で新しい Acrobat Sign SSL 証明書を取得できます。
- SSO 設定が複数のパブリック証明書／チェーンをサポートしている場合は、1 月の切り替え後に新しい証明書を追加して、古いパブリック証明書／チェーンを設定から削除することができます。
- SSO が複数のパブリック証明書／チェーンをサポートしていない場合は、2026 年 1 月 7 日に Acrobat Sign と SSL の切り替えを同期する必要があります。
新しい SSL 証明書は、2026 年 1 月 7 日に有効になります。
|
最初の報告：2024 年 9 月 - 2025 年 4 月更新 |
現在 |
|---|
Webhook 2.0 インフラストラクチャはすべてのお客様に展開されました。この完了に伴い、署名者への通知は廃止されました。 その結果、webhook ペイロードの webhookNotificationApplicableUsers パラメーターは有用なデータを提供しなくなり、すべての webhook ペイロードから削除されます。
サンドボックス環境は 2025 年 6 月のリリースで更新される予定です。
本番環境は 2025 年 7 月のリリースで更新されます。
送信ユーザー ID と電子メールは、通知ペイロードの initiatingUserId および initiatingUserEmail パラメーターを使用して取得できます。