電子署名の当事者型・立会人型を開発要件に翻訳する。何を作れば法的に有効なのか
電子契約サービスの導入を検討したり、自社システムに署名機能を組み込もうとすると、必ず「当事者型」「立会人型」という分類にぶつかります。法律事務所や弁護士による解説記事は数多くありますが、そこで語られているのは契約実務の話であって、「では、システムとして何を作れば法的に有効な署名になるのか」に翻訳した情報はほとんど見つかりません。発注者が要件定義書に書くべきこと、開発者が実装すべきことは、条文の解説からは直接は読み取れないのです。
この記事は、電子契約の導入を検討している事業会社の意思決定者と、署名機能を実装・組み込む開発責任者に向けて、電子署名法の建て付けを開発要件へ落とし込みます。契約書レビューのための解説ではなく、RFPと設計書のための整理です。制度情報の確認時点は2026年7月5日です。
この記事の要点
- 当事者型と立会人型の違いは技術的には1点、「署名に使う秘密鍵が本人のものか事業者のものか」に集約されます
- 法的な論点は、電子署名法3条の推定効が取れるかどうかです。立会人型は2020年の三省Q&Aで、固有性の要件を満たせば推定効が及び得ることが明確化されました
- 固有性の要件はそのまま実装要件になります。署名指示の直前の2要素認証、指示と署名処理の1対1の紐付け、改ざん不能な監査証跡、鍵のHSM管理の4点です
- 電子契約サービスのAPIを自社サービスへ埋め込む（embedded署名）場合、認証フローをどちら側が持つかが法的効力に直結します。UXの都合で決めてよい項目ではありません
- 当事者型はマイナンバーカードの普及で現実解になりました。ただし検証側には署名検証とJ-LISへの失効確認、そしてそのための認定または認定事業者との契約が必要です
押さえるべき条文は2つだけ。電子署名法2条と3条
電子署名法は決して長い法律ではありませんが、開発要件を考えるうえで実際に効いてくる条文は2つに絞れます。
2条（定義） は、何が「電子署名」に当たるかを定めています。要件は、その措置によって本人が作成したことを示せること、そして改変の有無を確認できることの2つです。ハッシュ値と公開鍵暗号を使ったデジタル署名は当然これを満たしますが、条文自体は特定の技術方式を指定していません。
3条（推定効） は、本人だけが行い得る一定の電子署名が付されている電子文書について、真正に成立したものと推定する、という規定です。これが実務上の主戦場になります。
なぜ3条が重要かというと、紛争になったときの立証負担が変わるからです。「この契約書は本物か」が裁判で争われたとき、推定効があれば、文書を提出する側は署名が付されていることを示せば足り、争う相手方が推定を覆す側に回ります。推定効がなければ、そもそも本人が作成したことを一から立証しなければなりません。
当事者型・立会人型という分類の議論は、突き詰めると「その方式で3条の推定効まで届くのか」の議論です。発注者としては、この一点を軸に方式を選べば判断がぶれません。逆に言えば、社内の稟議記録のように紛争リスクが極めて低い用途であれば、3条まで求めない設計もあり得ます。要件の重さを決めるのは、法律ではなく取引の性質です。
2つの型の違いは「誰の秘密鍵で署名するか」
まず全体像を表で押さえます。
| 項目 | 当事者型 | 立会人型（事業者署名型） |
|---|---|---|
| 誰の鍵で署名するか | 契約当事者本人の秘密鍵 | サービス事業者の秘密鍵（利用者の指示に基づく） |
| 本人の証明書 | 必要（認定認証事業者発行、マイナンバーカード等） | 不要 |
| 代表サービス | セコムあんしんエコ文書、e-Taxの署名、JPKI利用の署名 | クラウドサイン、GMOサイン、ドキュサイン等 |
| 導入のハードル | 相手方にも証明書・環境が必要 | 相手方はメール認証等で完結 |
| 法的な位置づけ | 2条・3条に素直に該当 | 固有性の要件を満たせば3条の推定効が及び得る（2020年の政府Q&A） |
技術的な違いは、表の1行目に尽きます。署名に使う秘密鍵が「本人のもの」か「事業者のもの」か。ここから他のすべての違いが派生します。
当事者型は、PKIの教科書どおりの構成です。本人が自分の秘密鍵で文書に署名し、検証側は本人の公開鍵証明書で署名を検証する。「その署名を作れるのは秘密鍵を持つ本人だけ」という前提が成り立つので、2条にも3条にも素直に当てはまります。本人性を担保しているのは、証明書を発行するときに認証局が行った身元確認です。
立会人型は、利用者が「この文書に署名してほしい」と事業者に指示し、事業者が自社名義の鍵で署名する構成です。署名そのものは事業者が行うので、素朴に読むと「これは本人の電子署名なのか」という疑問が生じます。2020年より前、この点はグレーでした。
その状況を変えたのが、総務省・法務省・経済産業省による連名のQ&Aです。2020年7月に2条関係、9月に3条関係が公表され、一定の要件を満たせば立会人型のサービスによる署名も2条の電子署名に該当し、3条の推定効も及び得ることが明確化されました。国内で電子契約サービスが一気に普及した法的な転換点がここにあります。
発注の観点で言えば、この経緯を理解しておくことには実利があります。ベンダーが「弊社のサービスは3条に対応しています」と説明するとき、それはサービスの機能一覧に書ける属性ではなく、要件を満たす運用と実装をしているという主張です。何をもって満たしていると言えるのかを次に見ます。
立会人型の「固有性の要件」を実装要件に翻訳する
3条Q&Aが示した条件は、「固有性」という言葉に集約されます。署名のプロセス全体を見たときに「本人だけが行い得る」と言えること。これを分解すると、2つの段階に分かれます。
①利用者と事業者の間のプロセスでは、署名の指示が確かに本人によるものだと確認できる必要があります。Q&Aは、その例として2要素認証を挙げています。メールアドレスとログインパスワードに加えて、SMSやトークンで発行されるワンタイムパスワードを組み合わせる、といった構成です。
②事業者内部のプロセスでは、利用者ごとの指示と署名処理が1対1で紐づき、他の利用者の指示と混ざらない仕組みであることが求められます。指示を受けてから署名鍵が使われるまでの経路が、誰の指示に対応する処理なのかを見失わない設計になっているか、という話です。
この2段階を、そのままシステム要件に置き換えると次のようになります。
- 認証: 署名指示の直前に2要素認証を要求する設計にします。ログイン時に一度認証しているから十分、という組み立てでは固有性の説明が弱くなります。「ログインしたセッションの持ち主」と「今この文書に署名を指示した人」を別々に確認するイメージです
- 監査証跡: 誰が・いつ・どの文書に・どの認証手段で署名指示したかを、改ざん不能な形で保存します。追記のみのログストア、ハッシュチェーン、タイムスタンプ付与など、後から書き換えていないことを説明できる保存方式を選びます
- 鍵管理: 事業者署名鍵はHSMで管理します。加えて、署名処理と署名指示の紐付けが一意であること（②の要件）を、キューやジョブIDの設計レベルで担保します
- 完了文書: 署名済みPDFに、監査証跡（合意締結証明書に相当するもの）とタイムスタンプを付与します。文書単体を渡された相手方が、その文書だけで経緯を確認できる状態が理想です
要件定義の実務で言えば、この4項目は「セキュリティ要件」の章ではなく「機能要件」の章に書くべき内容です。法的効力に直結するため、後から予算調整で削られると成果物の価値そのものが変わってしまうからです。
embedded組み込みでいちばん危ないのは認証フローの押し付け合い
自社サービスに電子契約サービスのAPIを組み込むケース、いわゆるembedded署名では、この構造が特に問題になります。
ありがちな設計はこうです。自社アプリでユーザーは既にログインしている。だから署名のたびに再認証を求めるとUXが悪い。そこで、自社アプリ側で「認証済み」として扱い、署名APIだけを叩く。画面遷移も減り、ユーザーの離脱も減ります。
この設計は、UXとしては合理的に見えて、固有性の①が崩れます。署名事業者から見ると、署名指示が本人によるものだと確認したのは自社ではなく、依頼元のシステムです。その依頼元がどんな認証をしているかは、署名事業者の統制の外にあります。結果として、後から「この署名は本人の指示によるものだ」と説明する材料が、契約当事者間の主張以上のものにならなくなります。
したがって、embedded組み込みを検討する場合、最初に決めるべきは画面設計ではなく認証の責任分界です。判断の型は3つあります。
- 署名事業者側に認証を持たせる: 署名の直前だけ事業者のホスト画面へ遷移し、そこで2要素認証を通す。UXの一貫性は落ちますが、固有性の説明はいちばん明快です
- 自社側で2要素認証を実装し、その結果を証跡として引き渡す: 事業者のAPIが認証結果や認証手段の情報を受け取れる場合に成立します。自社の認証実装が監査対象になるため、認証ログの保存要件も自社に来ます
- そもそも3条を狙わない: 社内ワークフローの承認など、推定効が不要な用途と割り切る。この判断をした事実と理由を、設計書に明記しておくことが重要です
どれを選ぶにせよ、「UXの都合で認証を軽くしたら法的効力が変わった」という事態を避けるために、認証フローの持ち方は要件定義の最初に固めてください。APIの詳細な組み込み設計は電子契約APIのembedded連携で扱っています。
当事者型を作る場合。マイナンバーカードという現実解
当事者型の最大の壁は、長らく「本人が電子証明書を持っていない」ことでした。相手方に証明書の取得を求める契約フローは、BtoBの特定取引ならともかく、一般消費者向けには成立しません。
これを変えたのがマイナンバーカードです。ほぼ全国民が署名用電子証明書を保有している状態になったことで、利用者に追加コストを求めずに当事者型の署名が可能になりました。実装上のポイントは次のとおりです。
- 署名にはマイナンバーカードの署名用電子証明書を使います。利用時のPINは6〜16桁の英数字です。もう一方の利用者証明用電子証明書は用途が異なるため、混同しないでください（2種類の違いは署名用電子証明書と利用者証明用電子証明書の違いで詳しく整理しています）
- 検証側は、署名の検証に加えてJ-LISへの失効確認が必要です。ここに主務大臣認定、または認定を受けたプラットフォーム事業者との契約が絡みます。自社で認定を取るか事業者経由にするかは公的個人認証（JPKI）の民間利用で比較しています
- スマートフォンのNFC読み取りが普及したことで、UXも実用レベルになりました。専用のカードリーダーを前提にしなくてよくなったことの意味は小さくありません
発注の観点で見ると、当事者型は「署名」と「本人確認」を1つのフローで済ませられる点が大きな利点です。犯収法などで身元確認が義務づけられている取引では、eKYCと署名を別々に作るより構成が単純になります。本人確認方式全体との位置関係はeKYC完全マップ2026を参照してください。
どちらを選ぶか。用途別の目安
方式選定の目安を、用途ごとに整理します。
| 用途 | 推奨 | 理由 |
|---|---|---|
| 社外との一般的な契約（受発注、雇用契約等） | 立会人型 | 相手方の負担が小さく、判例・実務の蓄積も進んだ |
| 高額・重要契約、規制上の本人確認が要る取引 | 当事者型（マイナンバーカード署名） | 犯収法対応と署名を1フローで済ませられる |
| 自社システムへの組み込み | まず立会人型のembedded API | UX・件数・要件次第でJPKI直接実装へ。認証フローの持ち方だけは最初に固める |
| 発行元証明だけでよい文書（請求書等） | eシール | そもそも個人の電子署名の領域ではない |
最後の行は特に見落とされがちです。請求書や各種証明書のように、個人の意思表示ではなく「この組織が発行した」ことを示せば足りる文書に、担当者個人の電子署名を付ける設計は過剰です。この領域はeシールとは。電子署名・タイムスタンプとの違いで扱っています。
また、方式を決めた後には署名した文書を何年残すかという別の設計課題が待っています。証明書の有効期限が切れた後も検証できる状態を保つには、長期署名の設計が必要です。詳しくは長期署名とLTVを参照してください。当事者型でも立会人型でも、この課題は同じように発生します。
発注前チェックリスト
ベンダーとの商談やRFP作成の前に、次の項目を自社で決めておくと議論が早く進みます。
- この文書は3条の推定効が必要か。必要な理由（紛争リスク、監督官庁への説明、社内規程）を1行で書けるか
- 署名するのは個人か組織か。組織の発行元証明で足りるならeシールを検討したか
- 相手方は誰か。一般消費者を含むなら、証明書の保有を前提にできない
- embedded組み込みなら、署名指示直前の2要素認証を「どちら側が」実施するか決めたか
- 監査証跡の保存年限と保存形式（改ざん検知の方法）を決めたか
- 署名済み文書の保存年限が証明書の有効期間を超えるか。超えるなら長期署名の要件を入れたか
- 検証する側（相手方・自社・監督官庁）が、何を使ってどう検証するかを想定したか
ベンダーへの確認事項としては、次の3点が実装の質を見分けやすい質問です。「署名指示の直前に2要素認証を要求できますか、それともログイン時の認証で代替されますか」「監査証跡には認証手段の情報が含まれますか」「PAdESのどのレベルまで対応していますか」。いずれも仕様書の表紙には書かれていないが、法的効力に効く項目です。
電子署名・本人確認まわりの記事の読む順序はeKYC記事の学習パスにまとめています。
まとめ
- 当事者型と立会人型の違いは「誰の秘密鍵で署名するか」。法的な論点は電子署名法3条の推定効が取れるかに集約されます
- 立会人型は2020年の三省Q&Aで推定効の道が開けました。鍵になるのは固有性、すなわち署名指示直前の2要素認証と、指示と署名処理の1対1の紐付けです
- 固有性の要件は、認証・監査証跡・鍵管理・完了文書という4つの実装要件へそのまま翻訳できます。これらは機能要件として書くべき項目です
- embedded組み込みでは、認証フローをどちらが持つかが法的効力に直結します。UXの都合で後から変更してよい項目ではありません
- 当事者型はマイナンバーカードの普及で現実解になりました。検証側の認定・契約構造まで含めて設計してください
- 発行元証明で足りる文書はeシール、長期保存が要る文書は長期署名と、隣接領域の設計まで含めて要件を組み立てます
よくある質問
Q. 電子署名の当事者型と立会人型の違いは何ですか？
署名に使う秘密鍵が誰のものかが違います。当事者型は契約当事者本人の秘密鍵で署名し、本人の電子証明書で検証します。立会人型（事業者署名型）は、利用者の指示に基づいてサービス事業者が自社の秘密鍵で署名します。当事者型は相手方にも証明書と環境が必要ですが、立会人型は相手方がメール認証等で完結できるため導入のハードルが低くなります。
Q. 立会人型の電子署名でも法的効力はありますか？
あります。2020年に総務省・法務省・経済産業省が公表した連名Q&A（7月に2条関係、9月に3条関係）で、一定の要件を満たせば立会人型のサービスによる署名も電子署名法2条の電子署名に該当し、3条の推定効も及び得ることが明確化されました。要件は「固有性」、すなわちプロセス全体が本人だけが行い得ると言えることです。
Q. 固有性の要件とは具体的に何をすればよいのですか？
2段階あります。第一に、利用者と事業者の間で署名の指示が本人によるものだと確認できること。Q&Aは例として2要素認証（メールアドレスとパスワードに加え、SMSやトークンのワンタイムパスワード等）を挙げています。第二に、事業者内部で利用者ごとの指示と署名処理が1対1に紐づき、他の利用者の指示と混ざらないことです。実装としては、署名指示直前の2要素認証、改ざん不能な監査証跡、署名鍵のHSM管理、指示と署名の一意な紐付けが必要になります。
Q. 電子契約サービスのAPIを自社アプリに組み込むとき何に注意すべきですか？
認証フローをどちら側が持つかです。自社アプリでログイン済みだからという理由で認証を省き、署名APIだけを呼ぶ設計にすると、固有性の第一段階が崩れて推定効が危うくなります。署名事業者側に認証を持たせる、自社で2要素認証を実装して結果を証跡として引き渡す、あるいはそもそも推定効を狙わないと割り切る、のいずれかを要件定義の最初に決めてください。
Q. マイナンバーカードで当事者型の電子署名はできますか？
できます。マイナンバーカードの署名用電子証明書（6〜16桁の英数字PIN）を使って本人の秘密鍵で署名します。ほぼ全国民が証明書を保有しているため、利用者に追加コストを求めずに当事者型を実現できる点が大きな利点です。ただし検証側では署名検証とJ-LISへの失効確認が必要で、主務大臣認定を自社で取得するか、認定を受けたプラットフォーム事業者と契約する必要があります。
Q. 電子署名とeシールはどう使い分けますか？
証明したい内容で分かれます。電子署名は「この人が署名した」という自然人の意思表示を示すもので、契約書や申込書に使います。eシールは「この組織が発行した」という発行元証明で、請求書や各種証明書のように個人の意思表示が不要で大量に発行する文書に向きます。要件定義の最初に「本人の意思表示が必要か、発行元証明で足りるか」を分岐させてください。
Q. 署名した文書を長期間保存する場合に追加で必要なことはありますか？
長期署名の設計が必要です。署名に使った電子証明書は数年で有効期限を迎えるため、その後も「署名時点では有効だった」ことを検証できるよう、証明書チェーンや失効情報を文書に埋め込み、タイムスタンプで時刻を固定します。この課題は当事者型でも立会人型でも同じように発生します。クラウド署名サービスを使う場合は、長期署名への対応有無と対応レベルを仕様確認の項目に入れてください。
主な参考資料: 経済産業省 電子署名法3条Q&A、法務省 電子署名法3条Q&A（PDF）、クラウドサイン 3条Q&Aの読み方
TodoONada株式会社では、電子署名（立会人型embedded連携・マイナンバーカードによる当事者型）を組み込んだWebサービス・スマホアプリの受託開発を行っています。方式選定から開発・運用までワンストップで支援し、デジタル庁「デジタル認証アプリ」の利用申請・審査対応も書類作成から指摘対応まで伴走します。料金の目安は認証機能組込みプラン150万円〜、認証込みアプリ開発プラン400万円〜、大規模・個別要件は1,000万円〜です。「うちの契約フローはどちらの型で作るべきか」という要件整理の段階からのご相談も、マイナンバーシステム導入支援またはお問い合わせからお気軽にどうぞ。
この記事に関連するサービス
TodoONada株式会社では、マイナンバーカード認証を組み込んだシステム開発を行っています。
- マイナンバーシステム導入支援 — JPKI・eKYC対応の本人確認をワンストップで
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- 経済産業省 電子署名法3条Q&A （2026年7月5日確認）
- 法務省 電子署名法3条Q&A（PDF） （2026年7月5日確認）
- クラウドサイン 3条Q&Aの読み方 （2026年7月5日確認）
