DocuSealを読む：PDFフォーム作成と電子署名を自分で運用する境界

DocuSealが担当する文書フロー

DocuSealは、PDFフォームを作成し、オンラインで入力と署名を受け付けるオープンソースのプラットフォームです。READMEには、モバイル向けに調整したWebツールで、文書の作成、入力、署名、処理を扱うと説明されています。入力欄の作成にはWYSIWYGのフォームビルダーを使い、署名、日付、ファイル、チェックボックスなど12種類のフィールドを利用できます。

複数の提出者、SMTPによる自動メール、署名済みPDFの生成、PDF署名の検証、ユーザー管理、APIとWebhookも機能一覧に含まれます。署名画面は14言語、UIは7言語に対応するとREADMEが記載しています。ここから判断できるのは機能の対象範囲です。自社の契約書が必要とする本人確認、証拠保全、国別の電子署名要件、保存期間まで満たすことを意味しません。法務と運用の要件は別に定義する必要があります。

ファイル保存先とデータベースの初期構成

Dockerの例では、docuseal/docusealコンテナを3000番ポートで起動し、/dataをホストへマウントします。READMEは既定のDockerコンテナがSQLiteへデータと設定を保存すると説明し、DATABASE_URL環境変数を指定すればPostgreSQLまたはMySQLも使えるとしています。小規模な検証ではSQLite構成が試しやすい一方、バックアップ、同時利用、障害復旧の方針は自分で決める必要があります。

ファイルの保存先にはローカルディスク、AWS S3、Google Storage、Azure Cloudが挙げられています。どの保存先を選んでも、署名前の原本、入力途中のファイル、完成済みPDF、監査用の情報を同じ扱いにできるとは限りません。オブジェクトストレージの権限、暗号化、削除規則、データベースとの整合性を設計し、復元テストまで行ってください。READMEは各環境の容量目安や復旧時間を示していないため、製品の説明をそのまま運用保証として扱うことはできません。

DockerとComposeで配置を固定する

READMEにはHeroku、Railway、DigitalOcean、Render向けのデプロイ入口があります。自分のサーバーへ置く場合はDockerの単体起動例とDocker Composeの例が中心です。Composeファイルを取得して、DNSをサーバーへ向けたうえでカスタムドメインとHTTPSで起動する手順が記載されています。Caddyによる証明書発行を想定した説明もあります。

この手順は、コンテナを動かし、名前解決と証明書を整える入口です。インターネットへ公開した後のアクセス制御、管理者アカウント、メール送信元、ログ、アップデート、バックアップは別の運用項目です。SQLiteから外部データベースへ切り替える場合も、既存データの移行と接続情報の秘匿を確認しなければなりません。まず非公開の検証環境でコンテナ、保存先、署名フローを確認し、その設定を記録してから本番相当の構成へ広げるのが安全です。

標準機能とPro機能を分けて見積もる

標準機能には、フォームフィールド、複数提出者、SMTPメール、保存先選択、電子署名PDF、署名検証、ユーザー管理、言語対応、API、Webhookが含まれます。外部アプリケーションから署名処理を呼び出したい場合は、APIとWebhookを中心に必要なイベントと再送時の扱いを確認してください。READMEだけでは、各APIの認証方式、レート制限、イベント順序、エラー形式までは詳しく分かりません。

Pro機能としては、会社ロゴとホワイトラベル、ユーザー権限、リマインダー、SMSによる招待と本人確認、条件フィールドと数式、CSVまたはXLSXからの一括送信、SSOとSAMLが挙げられています。HTML APIやPDF、DOCXのフィールドタグAPI、React、Vue、Angular、JavaScript向けの埋め込み署名フォームもProの一覧にあります。無料範囲だけで要件を満たせると想定せず、価格ページと契約条件で対象機能を確認してから工数を見積もるべきです。

署名業務で先に確認する認証と証跡

DocuSealの機能説明には、PDF署名の検証、SMSによる招待と本人確認、Webhook、ユーザー管理が含まれます。しかし、これらの機能名だけでは、契約の種類に必要な本人性、署名者の意思、改ざん検知、時刻、監査ログ、保管期間を判断できません。使う国や業界の電子文書法、社内の承認規程に沿って、何を証跡として残すかを先に決めてください。

チャットやメールで署名URLを送る構成では、宛先の誤り、転送、期限切れ、再送、アカウント共有が問題になります。管理画面へ誰がアクセスできるか、ファイルをどの保存先へ置くか、SMTPやSMSの外部事業者へ何が渡るかも確認が必要です。READMEには本番セキュリティ監査や、特定の法域での適合証明は記載されていません。安全性や法的有効性をプロジェクトの宣伝文句から推測せず、検証項目として分けて扱ってください。

リリース、保守、公式情報の読み方

素材取得時点のリリース一覧には3.2.2、3.2.1、3.2.0が記録され、リポジトリのデフォルトブランチはmasterです。リリース番号を固定することは再現可能な配置の出発点になりますが、Dockerイメージ、データベース、外部ストレージ、埋め込みSDKを一緒に更新する場合は互換性を別途確認してください。アップグレード前にはデータのバックアップと、作成、入力、署名、検証、Webhookの一連の操作を再実行できる手順を残すべきです。

ライセンスはAGPLv3で、Section 7(b)の追加条項があります。READMEはLICENSEとLICENSE_ADDITIONAL_TERMSの確認を求め、特に記載がないファイルの著作権表示も示しています。自社で改変したサービスを公開する場合、ネットワーク経由の利用者へどのソースや通知を提供する必要があるかは、ライセンス本文と専門家の確認が必要です。DocuSealは便利な署名基盤候補ですが、ライセンス、法務、保存、監査を含む業務システム全体を自動で完成させるものではありません。

編集部の結論

DocuSealは、PDFフォームを作成して複数の提出者へ送り、署名やファイル処理を自社環境へ組み込みたいチームの候補になります。まずSQLiteを使うDocker構成で操作を確認し、必要ならPostgreSQLやMySQL、S3系ストレージへ移す設計を検討してください。外部公開する前に、署名法令、認証、バックアップ、AGPLv3の追加条項を自社の責任範囲で確認する必要があります。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes