LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Documensoとは？DocuSignの代替となるOSS電子署名プラットフォーム

Documensoとは、契約書などの電子署名をオープンソースで実現し、自社サーバーへセルフホストできる電子署名プラットフォームです。公式GitHubリポジトリでは「The Open Source DocuSign Alternative」を掲げており、2026年7月時点で14,100件を超えるスターを獲得しています^*2。ライセンスはAGPL-3.0（GNU Affero General Public License v3.0）で、現在は信頼できる貢献者以外からの外部プルリクエストを受け付けず、コミュニティからの課題報告と提案を軸に開発が進められています^*2。

DocuSignのようなSaaS型電子署名サービスを利用する場合、契約書データは外部事業者のクラウド上に保存されます。Documensoはこの構成を見直し、PDF文書へのデジタル署名機能をPAdES（PDF Advanced Electronic Signatures）標準に対応する形で提供しつつ^*2、自社インフラ上で動かせる点を特徴としています。国際化にはLinguiを採用し、複数言語での利用にも対応しているとされています^*2。

OSSとしてソースコードが公開されているため、監査可能性という観点でもSaaS一択の構成とは異なる選択肢になり得るでしょう。一方で、セルフホストを選ぶ以上、署名機能を成立させるための証明書準備やコンテナ運用は自社または委託先が担う前提になります。

署名証明書をどう用意するか？4つの選択肢

Documensoの公式ドキュメントは、セルフホストにあたって「署名証明書を生成する必要がある」ことを明記しています^*1。証明書なしでは署名機能そのものが動作しないため、構築プロジェクトの初期段階で優先的に検討すべき要件です。

証明書の用意にあたっては、4つの選択肢が案内されています^*4。1つ目はローカル証明書で、.p12ファイルまたはBase64エンコードした証明書内容を使う方式です。2つ目はGoogle Cloud HSM（Hardware Security Module）で、ハードウェアベースの鍵保護を利用します。3つ目はCSC（Cloud Signature Consortium）で、AESやQESといった第三者の信頼サービスプロバイダーを経由する方式です。4つ目は自己署名証明書で、公式ドキュメントは無料で作成でき証明書の詳細を自社で制御できる点を挙げています^*4。

どの方式を選ぶかによって、鍵管理の責任範囲や運用コストは大きく変わります。特にHSMやCSCを利用する場合は外部サービスとの契約が別途必要になるため、証明書の選定はセルフホスト計画の初期段階で決めておきたい判断事項です。

Docker・Docker Compose・Kubernetesなど4つの配置オプション

クイックスタートはリポジトリ取得から.env設定まで

公式ドキュメントが示すクイックスタート手順は、リポジトリのクローンから始まります^*1。「git clone https://github.com/documenso/documenso.git」でソースを取得し、「cd documenso」でディレクトリへ移動、「cp .env.example .env」で環境変数ファイルをコピーしたうえで、「docker compose -f docker/development/compose.yml up -d」を実行すると、ローカル環境では「http://localhost:3000」でアクセスできるようになります^*1。

ただしこの手順は開発向けのcompose構成を使うクイックスタートであり、本番運用を前提としたセットアップとは別に案内されている点に注意が必要です^*1。

用途に応じて選べる4つの配置オプション

公式ドキュメントは、配置方法として4つの選択肢を挙げています^*1。Dockerは外部データベースと組み合わせた単一コンテナ構成、Docker Composeはすべての依存関係を含む本番向けセットアップ、Railwayはマネージドインフラへのワンクリック配置、Kubernetesはエンタープライズ向けの高可用性構成として案内されています^*1。自社の運用体制やスケール要件に応じて、どの配置方式を選ぶかを最初に決める必要があるでしょう。

Docker Composeで構築する本番向けの構成

GitHubリポジトリが公開している本番向けのdocker-compose定義（docker/production/compose.yml）を確認すると、構成はデータベースとアプリケーションの2つのサービスに分かれています^*3。データベース側はpostgres:15イメージを使い、ヘルスチェック機能が組み込まれています^*3。アプリケーション側はdocumenso/documenso:latestイメージを使い、既定ではポート3000番でコンテナとホストが接続されます^*3。

アプリケーションコンテナは、データベースがヘルスチェックを通過してから起動するよう依存関係が設定されており^*3、起動順序の不整合による接続エラーを避ける設計です。データベースのデータは専用のボリュームに永続化されるため^*3、コンテナを再作成してもデータが失われない構成になっています。

この構成で稼働させるには、事前に署名証明書を用意し、SMTP通知やデータベース接続に関する設定を環境変数として渡す必要があります^*1。証明書の配置を後回しにしたまま起動すると、コンテナ自体は立ち上がっても署名機能が動かないという状態に陥りかねません。

セルフホスト内製と外注委託のコスト構造比較

セルフホストによる内製構築と、外部パートナーへの委託では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。

ネットワークセキュリティとSMTP・データベース運用の注意点

公式ドキュメントは「ネットワークセキュリティの確保は利用者自身の責任である」と明記しています^*1。あわせて、セルフホストしたインスタンスは社内ネットワーク上の内部アドレスへ到達できてしまう場合がある、という趣旨の注意も示されています^*1。ファイアウォールの設計を怠ると、意図しない内部リソースへのアクセス経路を残したまま公開してしまうおそれがあります。

アプリケーションの稼働にはSMTPによる通知設定やデータベース接続の設定が必要になりますが^*1、公式サイトが公開しているページの範囲では、個々の環境変数名までは網羅的に確認できませんでした。導入時は、公式ドキュメントの設定リファレンスを直接参照しながら、自社のメール基盤やデータベース運用ポリシーに合わせて値を確定させる進め方が現実的でしょう。

ライセンス体系：Community EditionとEnterprise Editionの違い

Documensoのライセンスは、大きく2つに分かれます。中核部分はAGPL-3.0（Community Edition）で、無料で利用でき、修正版をネットワーク経由で提供する場合には改変後のソースコードを開示する義務があります^*5*7。派生物についても同一のライセンス条件を引き継ぐ必要があり、保証は一切提供されません^*7。

一方、拡張機能を含むeeパッケージ（Enterprise Edition）は、AGPLとは別の商用ライセンスの下に置かれています^*6。このライセンスでは、本番環境での利用に有効な商用サブスクリプションが必要とされ、開発・テスト目的での複製や改変のみサブスクリプションなしで許可されています^*6。複製・結合・再頒布・サブライセンス・販売は制限されており^*6、修正内容を非公開にしたい企業や、商用製品へ組み込みたい企業はEnterprise Editionの契約を検討することになります^*5。

自社の利用形態がAGPL-3.0の条件で足りるのか、商用ライセンスが必要になるのかを見誤ると、後からライセンス条件の見直しを迫られる事態にもなりかねません。契約書の署名基盤という性質上、導入前にライセンス区分を確認しておく価値は大きいでしょう。

電子署名法との関係を確認する視点

日本国内で電子署名の法的効力を検討する際の基本的な枠組みは、電子署名及び認証業務に関する法律（平成12年法律第102号、2001年4月1日施行）です^*8。法務省の解説によれば、本人による一定の要件を満たす電子署名が行われた電子文書等は、真正に成立したもの（本人の意思に基づき作成されたもの）と推定されるとされています^*8。あわせて、一定の基準を満たす認証業務については内閣総理大臣および法務大臣の認定を受けられる制度が設けられており、2025年4月1日時点で9つの特定認証業務が認定されています^*8。

Documenso自体は、PAdES標準に対応した汎用のOSS電子署名プラットフォームであり^*2、日本の認定認証業務として認定を受けた専用サービスではありません。契約書等の署名にセルフホスト版を用いる場合、採用する署名方式が電子署名法上の推定要件を満たすかどうかは個別の確認が必要であり、法的な効力を重視する用途では専門家への相談も選択肢になるでしょう^*8。社内文書の回覧や検証目的での利用であれば、こうした確認の優先度は相対的に下がります。

内製構築に必要なスキルと外注との違い

証明書管理・Docker運用・ライセンス判断に求められる専門知識

Documensoを内製で構築・運用する場合、求められる専門知識は複数分野にまたがります。署名証明書の生成方式の選定と鍵管理、Docker Composeを使ったコンテナ運用、SMTP・データベースを含む環境変数の設計、ネットワークセキュリティの確保、そして自社の利用形態がAGPL-3.0の範囲に収まるかを判断するライセンス知識が必要になります。自社の情報システム部門や法務部門が連携する体制を組まないと、これらを漏れなく完結させるのは難しいでしょう。

判断を先延ばしにしたまま自己流で構築を進めると、証明書未生成で署名機能が動かない、ファイアウォール未設計のまま公開してしまう、といった問題に後から気づくケースが生じます。商用ライセンスが必要な利用形態であることに気づかないまま運用を続けてしまうと、後日ライセンス条件を見直す事態にもつながりかねません^*5。

専門パートナーに委託した場合の違い

専門パートナーに依頼すると、証明書方式の選定からDocker環境の構築、SMTP・データベース設定、ネットワークセキュリティの設計、ライセンス区分の確認まで一連の工程を任せられます。自社では調査や検証だけで時間がかかる場面でも、複数の電子契約基盤を扱ってきた知見を活用すれば、稼働までの期間を圧縮しやすくなります。内製と外注のどちらを選ぶ場合でも、まずは自社の利用形態とライセンス要件の整理が出発点になるでしょう。

まとめ：Documensoセルフホスト活用の3つの判断軸

本稿ではDocumensoの機能とセルフホスト構築の要点を、公式ドキュメントとGitHubリポジトリの情報に基づいて整理しました。要点は次の3つに集約されます。第一に、DocuSignの代替となるPDF電子署名機能はAGPL-3.0のCommunity Editionで無料利用できますが、署名証明書の生成とDocker運用が構築の前提条件になります^*1*4。第二に、修正内容を非公開にしたい場合や商用製品へ組み込みたい場合は、Enterprise Editionの商用ライセンスが別途必要です^*5*6。第三に、契約書等への利用では電子署名法上の要件充足を個別に確認する必要があり、証明書管理からネットワークセキュリティまでを含む構築・運用の実行は、外部委託によってリスクを抑えやすくなります^*8。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Documenso公式ドキュメント「Self-Hosting」（https://docs.documenso.com/developers/self-hosting）
2. *2　出典：Documenso公式GitHubリポジトリ「README」（https://github.com/documenso/documenso）
3. *3　出典：Documenso公式GitHubリポジトリ「docker/production/compose.yml」（https://github.com/documenso/documenso/blob/main/docker/production/compose.yml）
4. *4　出典：Documenso公式ドキュメント「Signing Certificate」（https://docs.documenso.com/developers/self-hosting/signing-certificate）
5. *5　出典：Documenso公式ドキュメント「Licenses」（https://docs.documenso.com/docs/policies/licenses）
6. *6　出典：Documenso公式GitHubリポジトリ「packages/ee/LICENSE」（https://github.com/documenso/documenso/blob/main/packages/ee/LICENSE）
7. *7　出典：Documenso公式GitHubリポジトリ「LICENSE」（https://github.com/documenso/documenso/blob/main/LICENSE）
8. *8　出典：法務省「電子署名法の概要と認定制度について」（https://www.moj.go.jp/MINJI/minji32.html）

Tweet