あなたの製品が既に契約が生成されるワークフローがある場合(例:HRのオンボーディング、ローンの発行、ベンダーの登録)、エンベデッド署名はリダイレクトを排除し、ユーザーをフロー内に保持します。
リダイレクトではなくエンベデッドする理由は何ですか?
ユーザーを第三者の署名ページにリダイレクトすることで、摩擦が生じます:コンテキストの切り替え、ブランドの不連続性、離脱。エンベデッド署名は、署名プロセス全体を通じてユーザーをアプリケーション内に保持します。署名UIはiframeやネイティブコンポーネント内に表示され、あなたのデザインと感覚でブランド化され、署名エンジンはプロバイダーのバックエンドで動作します。
三つのエンベディングアプローチを比較
| デベロッパーの努力 | ブランド管理 | |
|---|---|---|
| Iframe埋め込み | 低(フロントエンドのみ) | 中程度 — スタイリッシュなiframe |
| API + カスタムUI | 高(フルスタック) | フル — 自分でUIを作成 |
| モバイルSDK | 中程度(プラットフォーム固有) | フルネイティブな体験 |
署名をエンベデッドするタイミング
エンベデッド署名は常に正しい選択肢ではありません。以下は、最も価値を提供するシナリオです。
従業員や顧客にサービスを提供する企業ポータルは、ユーザーを外部ツールに送らずに、ポリシー確認、内部承認、セルフサービス契約に署名をエンベデッドできます。
署名の量が高い場合(一日数千件)、各リダイレクトはコンバージョンのコストとなります。エンベデッド署名は離脱を減少させ、完了率を向上させ、直接収益に影響を与えます。
内蔵署名は、ユーザーの全体の旅程を制御し、カスタムの監査トレイル、規制の開示、同意のキャプチャをアプリケーションコンテキスト内で実装するのを簡単にします。
内蔵署名APIフロー
標準的内蔵署名実装はこの手順に従います。
APIを通じてエンベロープを作成
バックエンドが署名APIを呼び出し、エンベロープを作成します:ドキュメントをアップロードし、署名フィールドを定義し、署名者役割を設定し、認証要件を構成します。APIはエンベロープIDを返します。
署名URLの生成
各署名者に対して、APIから署名URLをリクエストします。URLには、この特定のエンベロープに対して署名者を認証する一時トークンが含まれています。オプションで、受信者認証(アクセスコード、SMS OTP、eID)を通じて提供できます。
iframeまたはSDKに埋め込み
iframe(ウェブ)またはモバイルSDK(iOS/Android)に署名URLをレンダリングします。署名UIはアプリケーション内にロードされます。ブランドの色、フォント、ロゴに合わせて外観をカスタマイズします。
完了webhookの処理
署名者が完了(または拒否)した場合、署名プラットフォームはバックエンドにwebhookを送信します。これを使用して、アプリケーションの状態を更新し、次のステップをトリガーし、他の関係者に通知します。
署名ドキュメントの取得
署名ドキュメントと証拠パッケージ(完了証明書、監査トレイル)をAPIを通じてダウンロードします。これらをシステムまたはクラウドストレージに保存します。
内蔵署名のための技術的な考慮事項
クロスオリジンおよびCSP
iframe埋め込みには、署名ドメインがコンテンツセキュリティポリシーで許可されている必要があります。frame-ancestorsおよびchild-srcヘッダーを構成します。多くの署名プラットフォームは、ドメインに対するホワイトリストメカニズムを提供しています。
Webhookの信頼性
Webhookはネットワーク問題により失敗することがあります。一意性のあるwebhookハンドラと、定期的にエンベロープの状態を確認するポーリングフォールバックを実装します。重要な状態遷移にはwebhookに完全に依存しないようにしてください。
モバイルの反応性
モバイルデバイス上でサインUIが動作する必要があります。iOS SafariおよびAndroid Chromeでのiframeベースのサインをテストしてください。一部のサインパッド実装では、モバイル上でタッチイベントに問題があります。ネイティブモバイルアプリ用のSDKを使用してください。
レート制限とバッチ処理
高容量の統合サインはAPIレート制限に達する可能性があります。サポートされている場合は、リクエストキューとバッチエンベロープの作成を実装し、APIの使用を監視し、近づく制限に対するアラートを設定してください。
eSign.AIの統合サインの動作方法
eSign.AIは、自社のインターフェース内でサインが必要なSaaS製品用のホワイトラベル統合サインを提供します。
iFrameとコンポーネントSDK
iFrameまたはReact/Vueコンポーネントを通じて、eSign.AIのサイン体験をプロダクト内に埋め込みます。サイン者はアプリケーションを出ることはありません。統合サインはすべてのeSign.AI機能をサポートします:複数のパーティーのルーティング、身元確認、QES、監査トレイル。
リアルタイムステータスのためのウェブフック
サインイベント(エンベロープ送信、視聴、サイン、完了、拒否)を受け取るウェブフックを設定してください。サイン完了後、アプリケーションは即座にダウンストリームワークフロー(契約アクティベーション、通知、請求)をトリガーできます。
統合電子署名API:遅延、SLA、ウェブフック
API統合計画のためのパフォーマンス仕様
API遅延ベンチマーク
eSign.AI:エンベロープ作成200-400 ms、ステータス取得50-100 ms、サイン済みPDFダウンロード300-800 ms。DocuSign:エンベロープ作成300-600 ms、ステータス取得80-150 ms。Adobe Sign:エンベロープ作成400-800 ms。統合サインiFrameのロード:eSign.AI 1-2秒、DocuSign 2-4秒。
ウェブフック信頼性
eSign.AIウェブフック:30秒タイムアウト、指数的バックオフで3回リトライ(5分、30分、2時間)、ペイロード検証のためのHMAC署名。DocuSign:10秒タイムアウト、24時間のリトライウィンドウ。Adobe Sign:3秒タイムアウト、72時間以内に6回リトライ。リアルタイムダウンストリームワークフローには、eSign.AIが最も信頼性の高いウェブフック配信があります。
よくある質問
いいえ。署名の法的有効性は、署名方法(SES、AES、QES)、身元確認、証拠パッケージに依存しており、サインUIが埋め込まれたりリダイレクトされたりするかどうかには依存しません。統合サインは独立したサインと同じ法的証拠を生成します。







