第１ 証明書の日付だけで成立日を決めない
電子契約の画面で同意した日と，電子署名が付された日又は合意締結証明書の発行日が異なる場合，最後に表示された日が当然に契約成立日になるとは限らない。
どの文書について，誰が，どの権限に基づいて，どの段階で確定的な意思表示をしたかを確認する必要がある。
契約成立，電子文書の成立の真正，会社を拘束する権限及び契約の内容・有効性は，それぞれ別の問題である。
本記事は，東京地方裁判所令和８年１月２０日判決（令和６年（ワ）第１２２３０号，サービス利用料金請求事件，判例秘書・判例番号L08130302）を踏まえ，電子契約の時系列と証拠の確認方法を整理する。
基準日は令和８年１０月３日である。
同判決は特定の営業支援サービス契約の成立を認めた事例であり，電子署名法３条の推定の要件を正面から判示したものではない。
第２ 契約成立と電子署名による証拠化
１ 申込みと承諾の合致
民法５２２条は，契約内容を示した申込みに対して相手方が承諾したときに契約が成立し，法令に特別の定めがある場合を除き，書面その他の方式を必要としないと定めている。
通知による意思表示の効力発生時期については同法９７条１項の到達の原則も確認する必要がある。
電子契約についても，画面の表示と契約条項を確認し，操作が文書の受領確認なのか，内容への確定的な承諾なのかを区別することになる。
当事者が，双方の署名完了又は所定の承認通知まで契約成立を留保している場合には，その定めも検討する。
法律上の方式が必要な契約や個別の成立条項を無視して，クリックだけで常に成立すると扱うことはできない。
契約成立日と，遡及して定めた適用開始日や実際の業務開始日も区別すべきである。
２ 電子署名法３条の推定が対象とする問題
電子署名法２条及び３条では，電子署名に当たる措置の定義と，所定の本人による電子署名が付された電磁的記録の真正な成立の推定を分けて定めている。
文書が名義人の意思に基づいて作成されたかという問題と，申込み及び承諾の合致によって契約がいつ成立したかという問題は，同一ではない。
推定が働くとしても，担当者の権限，条項の有効性，実際の履行又は請求額まで自動的に証明されるものではない。
関係省庁の３条Q&Aは，事業者署名型のサービスについて，本人の意思，利用者と事業者の間及び事業者内部の双方のプロセスの固有性，ログ等の保存を説明している。
二要素認証は例示であり，一律の必須要件とはしていない。
同Q&Aは行政の説明であり，個別事案の最終判断は裁判所に委ねられる。
第３ 東京地裁令和８年１月２０日判決
１ 同意操作と翌日の承認
本件では，営業支援サービスについてオンラインで説明を受けた会社の代表者が，従業員に届いた書類の確認等を指示した。
令和２年１１月３０日午後５時２７分頃，担当者はクラウドサインを利用して見積書兼申込書及び利用約款を送信し，同日午後６時１７分頃，従業員が書類を確認して複数の同意操作をしたと認定された。
操作は書類を開くための同意だけで終わらず，書類内容への同意と，確認を完了する旨の操作まで行われていた。
同日午後８時５８分頃，サービス提供側の担当者は，契約成立を前提とする謝礼等のメールを送信した。
翌１２月１日午後１時１１分，提供側の取締役が手続を承認し，電子署名の処理と合意締結証明書の発行が行われたと認定された（判決第３の１）。
２ 裁判所が前日の成立を認めた理由
裁判所は，説明経過，見積書兼申込書という文書の名称，確認依頼メール及び同意操作等を踏まえ，単なる見積書確認のための操作とはいえないと判断した。
従業員の操作も，会社のメールアドレスへ届いた依頼に従い，代表者の指示に基づいて行われた本件事情の下では，代表者の意思に基づくものと認めた。
そして，１１月３０日の提供側担当者の意思表示と，会社代表者の意思に基づく同意操作による意思表示との合意によって，本件契約が成立したと判断した。
翌日の取締役による手続は，電子契約上の合意を承認し，電子署名を施して証明書を発行するためのものであり，その手続によって初めて契約が成立したのではないとされた（判決第３の２(1)，３(1)～(2)）。
したがって，本件では承諾と証明書の時刻の相違は，契約成立を否定する時系列の矛盾とは扱われなかった。
３ この判決から一般化しない事項
この判決から，従業員のクリックが常に会社を拘束する，閲覧確認のボタンを押せば常に契約が成立する，あるいは送信側の最終承認がどの取引でも不要であると結論付けることはできない。
会社の権限や代理の問題は，民法９９条等を踏まえ，具体的な指示と権限を調べる必要がある。
本件の軽微な商号表記の相違が，住所及び代表者等から当事者の同一性に疑義を生じさせなかったことも，別法人との取り違えや権限の欠如を許容する一般論ではない。
第４ 紛争になったときに作る時系列
１ 日時ごとの操作と法的な意味を対応させる
担当者は，次の項目を一つの時系列にまとめ，操作時刻をそのまま法的な成立時刻に置き換えないようにする。
① 交渉及び説明の日時，担当者，料金・期間・解約条件の説明資料
② 送信した文書の名称，版，添付約款，申込みの内容及び送信先
③ 受信，閲覧，内容への同意，確認完了の各操作とその表示文言
④ 操作者の本人確認，メールアドレスの利用状況，社内指示，委任又は承認記録
⑤ 送信側の承認，電子署名処理，タイムスタンプ及び証明書発行の各日時
⑥ 承諾の到達を裏付ける履歴，成立通知及び契約成立を前提とするメール
⑦ 業務開始，請求，支払及びその後の異議の日時と内容
日時を比べる際は，タイムゾーン，システムの時刻表示，署名対象の版をそろえる。
合意締結証明書は重要な資料であるが，説明メールや社内指示，署名前の操作を省略する理由にはならない。
２ 原データと操作の意味を残す
契約書の原データ，署名の検証に必要な情報，証明書，メール及び取得できる操作履歴を保存し，取得者，取得日時，取得元と加工の有無を記録する。
スクリーンショットは当時の画面表示を補う資料になるが，それだけで原データや署名の検証情報を代替できるとは限らない。
サービス事業者からログを入手する必要がある場合に備え，保存期間，取得できる項目及び窓口を契約時に確認することが望ましい。
争いが生じたら，原データを編集して修正する前に保全し，どの時点のどの文書が合意対象であったかを弁護士と確認する。
相手方の「見積書を見ただけ」という主張に対しては，ボタンの名称だけでなく，書類，送信メール，表示文言，説明内容及び前後のやり取りを対応させて検討する必要がある。
第５ 成立時点を明確にする運用
１ 閲覧，承諾及び最終承認を区別する
契約管理者と営業担当者は，閲覧確認と契約内容への承諾が画面上で区別されているか，社内承認を完了する前に相手方へ申込みを送信していないかを点検する。
双方の署名完了まで成立させない運用なら，契約条項，送信メール及び画面表示がその運用と一致しているかを確認する。
成立時点を定める際には，サービスが発行する各日時の意味と，法的な効力発生時点を対応させることが必要である。
２ 自動送信の前に人の承認を置く
AIが契約草案を作成できることと，会社を拘束する申込み又は承諾を送信してよいことは別である。
実務上は，対象契約の版，金額，期間，相手方，署名者，権限及び未確定条件を人が確認してから送信する仕組みが考えられる。
例外条項や権限の疑義がある場合に法務担当者へ戻す条件も設けることが望ましい。
これは本記事の運用提案であり，本件判決が特定のAIシステムの適法性や承認設計を判断したものではない。
第６ 関連記事
① 電子署名法３条の推定とは
② 口頭の合意と契約書－書類を取り交わすまで契約成立を留保できるか
③ 電子契約で保証人に署名してもらうときの注意点
第７ 出典と確認範囲
① 民法９７条，９９条及び５２２条
② 電子署名及び認証業務に関する法律２条及び３条
③ 利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A（電子署名法第３条関係）（令和２年９月４日公表，令和６年１月９日一部改定）。問１，問２及び問４～問６。
④ 東京地方裁判所令和８年１月２０日判決（令和６年（ワ）第１２２３０号，サービス利用料金請求事件，判例秘書・判例番号L08130302，LLI/DB判例秘書登載）。主文，事実及び理由の全文を確認。
東京地裁判決は，令和８年１０月３日に裁判所の統合検索で令和６年（ワ）第１２２３０号を指定した範囲では該当結果が得られず，判例秘書掲載の本文によった。
控訴の有無，確定及び後続裁判例は確認していない。
令和２年の契約操作を認定した判決であるため，現在のクラウドサインの全プランの画面や仕様を示す資料としては扱わない。