OSS電子署名にDocuSealが選ばれる理由｜Documenso・OpenSignとの違い

DocuSign や PandaDoc に代表される SaaS 型の電子署名サービスは月額コストが高く、データを国内・自社環境に置きたい要件や、既存システムへ深く埋め込みたい要件と相性が悪い場面があります。こうした事情から「OSS の電子署名プラットフォームをセルフホストして使えないか」と検討するエンジニアが増えています。

ところが、いざ調べ始めると候補となる OSS は複数あり、それぞれが「DocuSign 代替」を名乗っています。各プロジェクトの紹介記事を読むと機能列挙ばかりで、「自社の要件に合うのはどれか」「メンテナンス状況は健全か」「採用後にライセンス上のトラブルが起きないか」を判断する材料がなかなか揃いません。

本記事では、その候補のひとつである DocuSeal を、類似 OSS である Documenso と OpenSign と並べて比較し、初見のエンジニアが採用可否を判断するための軸を整理します。具体的には、機能の網羅性、提供形態の3層構造、類似 OSS との差分、AGPL-3.0 ライセンスの注意点、そして採用判断のチェックリストを順に整理します。

なお、本記事は公式 README・公式ドキュメント・公式サイトに記載された情報をもとにした机上整理であり、筆者がインストールして動作検証したものではありません。実際の検証は本記事を踏まえて読者自身の要件で実施いただく前提で執筆しています。

DocuSeal とは｜OSS 電子署名プラットフォームの概要

DocuSeal は、PDF を中心としたドキュメントへのフォーム作成・記入・電子署名をワンストップで提供する OSS プラットフォームです。GitHub の説明文には「Open source DocuSign alternative. Create, fill, and sign digital documents」と記載されており、DocuSign や PandaDoc の代替を明確に意識した位置づけとなっています（出典: docusealco/docuseal）。

プロジェクトの概要と運営体制

DocuSeal は専任の企業（DocuSeal）によって運営されており、OSS 版に加えて SaaS 版「DocuSeal Cloud」とエンタープライズ向けの On-Premises 版を商用提供しています。OSS と商用プランが同一企業の手で開発・サポートされている点は、コミュニティ駆動のみのプロジェクトと比較して長期サポートの観点で安心材料になります。

コミュニティ規模とメンテナンス状況

リポジトリの規模は採用判断の重要な指標です。gh api /repos/docusealco/docuseal で取得した時点のメタ情報は次のとおりです。

スター 15,000 超は OSS 電子署名カテゴリーの中で最大級であり、直近 push が記事執筆日のわずか数日前であることから、メンテナンスは活発と判定できます。

採用実績と対応フォーマット

公式サイトでは 163,200 のビジネス・個人が DocuSeal を利用しているとされ、Intuit、University of California San Diego、Pharmbills、Absa、Thermondo、Fullscript などの企業名が掲載されています。対応フォーマットは PDF / DOCX / XLSX / JPEG / PNG / ZIP（最大 100MB）と幅広く、ビジネス文書のほぼ全領域をカバーしています。

DocuSeal の主要機能｜PDF フォームから署名・配信まで

採用判断にあたっては、自社で必要な機能が OSS 版に含まれているかどうかを最初に確認する必要があります。公式 README と 公式ドキュメント に記載された主要機能を整理します。

ドキュメント作成とフォームビルダー

DocuSeal の中核機能は WYSIWYG な PDF フォームビルダーです。アップロードした PDF・DOCX 上にフィールドを配置していくだけで署名フォームを作成できます。フィールドは 12 種類が用意されており、署名・初期化・日付・テキスト・数値・チェックボックス・ラジオ・セレクト・添付ファイル・画像など、契約書・同意書・申込書で必要となる種別を一通り押さえています。

署名ワークフローと配信

複数署名者ワークフローに対応しており、署名順序の制御、SMTP 経由のメール自動配信、署名完了後の PDF 自動電子署名・検証までが OSS 版に含まれます。多くの OSS 電子署名ツールが「単一署名者の署名取得」までしかカバーしないなか、複数署名者の順序制御まで OSS 版に内包されている点は DocuSeal の強みです。

ストレージ・多言語・対応フォーマット

ストレージ連携はローカルディスクに加え、Amazon S3 / Google Cloud Storage / Azure Blob に対応しています。多言語対応は UI が 7 言語、署名画面が 14 言語に対応しており、日本語環境も含まれます。多国籍に展開するプロダクトに組み込む場合に有利です。

提供形態とデプロイ選択肢｜OSS / Cloud / Enterprise の3層

DocuSeal は提供形態を 3 層に分けて整理しています。OSS 版だけで自社要件を満たせるのか、それとも Pro / Cloud に切り替えるのかを判断するために、機能差を理解しておく必要があります。OSS とマネージド API の使い分けの基本については「OSSとAPIの違い」も参照してください。

3 形態の機能差

公式サイトの整理に基づくと、3 形態のターゲットと OSS 版で利用できない機能は次のように分類できます。

OSS 版で利用できず、Pro / Cloud 限定となる主な機能は以下のとおりです。

• ホワイトレーベル（企業ロゴ・カスタムブランディング）
• ユーザーロール / 権限管理
• 自動リマインダー
• SMS による署名者検証
• 条件付きフィールド（フィールドのロジック分岐）
• CSV 一括インポート
• SSO / SAML
• Embedded フォーム / フォームビルダーの埋め込み

「OSS 採用 = 全機能無料で使える」と誤解しやすいポイントです。SSO / SAML や条件付きフィールドが必須要件になる場合、OSS 版だけで完結させようとせず、Pro 版・Cloud 版の利用を最初から検討する必要があります。

セルフホストのデプロイ選択肢

セルフホストのオプションは Install ガイド に整理されています。Docker Compose による起動、Heroku / Railway / DigitalOcean / Render での 1-click デプロイ、Kubernetes 向けの構成が用意されています。公式 Docker イメージは Docker Hub で配布されています。

公式 README には以下のような Docker 起動例が記載されています（出典: docusealco/docuseal README）。

docker run --name docuseal -p 3000:3000 -v.:/data docuseal/docuseal

このコマンドはあくまで公式 README からの引用であり、本記事では実行検証を行っていません。実際のデプロイ時はバージョンや環境変数の最新仕様を公式 Install ガイドで確認してください。

採用するデータベースの選び方

DocuSeal はデフォルトで SQLite を使用しますが、PostgreSQL と MySQL もサポートしています。検証用途や小規模な社内利用であれば SQLite で十分ですが、本番運用や複数インスタンスでの水平スケールを想定する場合は PostgreSQL を選ぶのが無難です。Rails 系プロダクトの一般的な運用パターンに沿うため、既存運用ノウハウが流用できます。

開発者向け機能｜API・Webhook・SDK・Embedded

既存システムへの組み込みを検討する場合、API・Webhook・SDK の充実度が採用可否を分けます。DocuSeal はこの領域に厚く投資しており、API リファレンス で詳細仕様が公開されています。

REST API の認証と主要エンドポイント

API 認証は HTTP ヘッダ X-Auth-Token: <API_KEY> によるシンプルな API キー方式です。主要エンドポイントは次の3カテゴリに整理されています。

PDF だけでなく DOCX や HTML を直接ポストして署名フローを起動できる点は、テンプレート管理を自社側で完結させたいケースで効きます。

Webhook イベント

Webhook は Form / Submission / Template の3種類が用意されており、署名フォームの作成・送信・テンプレート更新といったイベントを自社システムへリアルタイムに連携できます。基幹システムへの状態同期や、社内 Slack 通知の組み込みが容易です。

SDK と Embedded の使いどころ

公式 SDK / コードサンプルは Node.js / JavaScript / TypeScript / Python / Ruby / PHP / Go / C# / Java / cURL の幅広い言語で提供されており、主要なバックエンド言語をほぼ網羅します。フロントエンド埋め込み用には React / Vue / Angular / Next.js 向けのコンポーネントが提供されていますが、Embedded 機能は Pro 版限定である点に注意が必要です。

類似 OSS 電子署名との違い｜DocuSeal vs Documenso vs OpenSign

ここまでで DocuSeal 単体の特徴は把握できますが、実際の採用判断では他の OSS 電子署名と比べて優位性があるかが重要です。代表的な OSS である Documenso と OpenSign と並べて比較します。

比較サマリ表

スター数や push 頻度、機能網羅性で見ると DocuSeal が最も成熟しています。ただし「最大であること」と「自社にとって最適であること」は別であり、技術スタックや運用方針によっては Documenso・OpenSign の方が適合する場面があります。

DocuSeal が向いているケース

次の条件に該当する場合、DocuSeal を第一候補に置くのが妥当です。

• Ruby / Rails の運用経験があるチームで、Rails アプリのデプロイ・モニタリング基盤を流用したい
• 機能網羅性を重視し、複数署名者ワークフロー・自動電子署名・S3/GCS/Azure 連携をすぐに使いたい
• 日本語を含む多言語 UI が必要で、UI 7 言語・署名 14 言語のカバレッジが要件に合致する
• 商用ライセンスへの切替パス（Cloud / Enterprise）を将来的に確保しておきたい

Documenso / OpenSign を選ぶべきケース

逆に、次の場合は Documenso や OpenSign の方が合います。

• フロント・バックともに TypeScript で統一したい開発組織で、Next.js / Prisma / tRPC のスタックを採用している → Documenso
• PAdES 準拠の電子署名を最優先要件とする → Documenso
• 機能はシンプルで構わないので、完全無料・無制限・MongoDB ベースで軽量に運用したい → OpenSign
• スター数や成熟度よりも、自社の既存スタックとの親和性を優先する

AGPL-3.0 ライセンスの注意点｜セルフホストと SaaS 再提供の境界

DocuSeal、Documenso、OpenSign はいずれも AGPL-3.0 を採用していますが、DocuSeal は加えて Section 7(b) Additional Terms を付帯しています。AGPL の制約は採用判断に直結するため、技術選定と並行して整理しておく必要があります。OSS ライセンスの全体像は「OSSライセンスの種類と発注時の確認事項」で解説しています。

なお、ライセンスの最終的な解釈と適用判断は弁護士等の法務専門家に確認してください。本セクションは技術選定段階での前提整理に限定します。

AGPL-3.0 の概要

AGPL-3.0 は GPL-3.0 を強化したコピーレフトライセンスで、「ネットワーク経由でソフトウェアを利用させる場合も、改変したソースを利用者に対して提供しなければならない」という SaaS ループホール対策条項を含みます。クライアント・サーバーアプリケーションでは GPL の「配布」概念が発動しないことを利用して改変ソースを公開せずに済ませるパターンがあったため、AGPL はこの抜け道を塞いでいます。

Section 7(b) Additional Terms の含意

DocuSeal の LICENSE には AGPL-3.0 に加え Section 7(b) の Additional Terms が記載されています。Section 7(b) は AGPL の規定上認められている追加条件で、典型的には「派生物に著作者表記・帰属表示を残すこと」を求める条項として用いられます。DocuSeal の文脈では UI 内の DocuSeal 表記やブランド帰属の保持といった条件が課される可能性があるため、UI 改変・ホワイトレーベル化を検討する場合は LICENSE 原文と公式の利用規約を確認する必要があります。

社内利用と外部 SaaS 再提供で異なる制約

実務上のリスク評価は、利用形態を 2 つに分けて考えると整理しやすくなります。

• 社内利用に閉じたセルフホスト: 自社従業員が利用する範囲に限定するケース。AGPL の改変ソース提供義務は「利用者に対して」発生するため、利用者が社内のみであれば社内向けにソース開示すれば足りる、と整理されることが一般的です（最終解釈は法務確認）。実質的な追加負担は低めです。
• 外部顧客への SaaS 再提供: DocuSeal を組み込んだサービスを外部顧客に提供するケース。改変ソースの公開、ブランディング表記の継承などの義務が顕在化します。商用サービスとして再配布する場合は、商用ライセンス（DocuSeal Cloud / Enterprise）への切替を検討する方が安全です。

商用ライセンスへの切替判断軸

次のいずれかに該当する場合、商用ライセンスを採用候補に入れるのが現実的です。

• 自社プロダクトに DocuSeal の機能を組み込み、外部顧客向け SaaS として提供する
• ホワイトレーベル化や DocuSeal 表記の除去が必要
• SSO / SAML、条件付きフィールド、Embedded フォームなど Pro 限定機能が必須要件
• AGPL ソース公開義務を確実に回避したい

採用判断のチェックリスト｜DocuSeal を選ぶべきケース・避けるべきケース

ここまでの内容を踏まえ、DocuSeal の採用可否を最終判断するためのチェックリストを示します。各項目に Yes/No で答えていくことで「採用候補に残すか・落とすか」の判断材料になります。

DocuSeal を選ぶべきケース（要件チェックリスト）

• PDF / DOCX を中心とした電子署名フローが必要である
• 複数署名者ワークフロー、SMTP 配信、自動電子署名を OSS 版だけで完結させたい
• Docker / Rails 系の運用基盤がチームに整っている
• AGPL-3.0 + Section 7(b) の制約を許容できる、もしくは外部 SaaS 化しないユースケースである
• 日本語を含む多言語 UI が必要
• スター 15,000 超・直近メンテナンスが活発という成熟度を重視する

これらに概ね Yes が付くなら、DocuSeal は採用候補として有力です。

避けるべきケース

逆に、次の条件のいずれかに該当する場合は、別の OSS や商用 SaaS を検討する方が適切です。

• フロント・バックエンドを TypeScript で統一しており、Rails スタックを増やしたくない → Documenso が候補
• ホワイトレーベル化・SSO / SAML・条件付きフィールドが必須要件で OSS 版で賄えない → DocuSeal Cloud / Enterprise への切替か、別プロダクトを検討
• 改変ソースの公開義務を一切受け入れられない → AGPL を避け、商用 SaaS を選択
• 将来的にプロダクトの一部として外部顧客に再販する計画がある → ライセンス整理を最優先で進め、商用ライセンスや別 OSS を比較

次のアクション

採用候補に残すと決めた場合、次のステップは以下の順で進めるのが効率的です。

1. 公式ドキュメントを読み込み、必要機能が OSS 版に含まれるかを再確認する
2. Install ガイドに沿って PoC 環境を構築し、自社要件で動作検証する
3. AGPL-3.0 + Section 7(b) の解釈について法務に確認する
4. Pro 機能が必要な場合は DocuSeal Cloud / Enterprise の見積もりを取得する

まとめ

本記事では、OSS 電子署名プラットフォーム DocuSeal を採用判断の観点から整理しました。論点を整理すると次の3点に集約されます。

• 機能網羅性: WYSIWYG フォームビルダー、複数署名者ワークフロー、SMTP 配信、自動電子署名、S3/GCS/Azure 連携、UI 7 言語・署名 14 言語と、OSS 版だけでも実務適用可能な水準を備えている
• 提供形態の3層: OSS / Cloud / Enterprise を同一企業が運営しており、SSO / SAML や条件付きフィールドなど Pro 限定機能の存在を理解した上で採用を判断する必要がある
• 類似 OSS との差別化: スター 15,000 超で最大級の成熟度を持つが、TypeScript 統一志向なら Documenso、シンプル・無料無制限なら OpenSign が選択肢になる

裏テーマとして掲げた「初見エンジニアの意思決定支援」に立ち戻ると、DocuSeal は採用候補に残す価値が十分ある OSS と評価できます。ただし、AGPL-3.0 + Section 7(b) の制約と Pro 機能の要否という 2 つの判断軸を最初に明確化することが、検証コストを最小化する近道です。

本記事は公式情報に基づく机上整理であり、PoC は読者自身の要件で実施してください。実装段階の細部は DocuSeal の GitHub リポジトリ と 公式ドキュメント を参照しながら進めるのが確実です。