電子契約をAIで自作した会社の話。サービスを契約する前に決めた3つの線と、法律で“自作にできないこと”
業務委託の契約書を1通送るたびに、月額の電子契約サービスを契約すべきか迷ったことはありませんか？
うちは迷った末に、変なことをしました。電子契約の仕組みを、AIに作らせたんです。
2026年8月のことです。30人のAI社員を回している会社なので、「作れるなら作ってみよう」で始めました。
で、実際に動いて、9月の業務委託契約で本当に使いました。でも同じ9月に、外部の電子契約サービスの契約も進めています。
矛盾してるように見えますよね。この記事は、その矛盾の中身の話です。自作で何ができて、法律のどこで線を引き、どこから先はサービスに任せると決めたか。順に書きます。
電子契約を自作しようと思ったきっかけ
きっかけは単純で、契約書を送る回数が月に数通だったことです。
月額を払うほど使っていない。でも紙に印刷して郵送するのは、もっと嫌だった。
もう1つ、うちは「送る前の下書き」をAI社員が作っています。契約書の文面、相手の名前、金額、期日。ここまでAIが埋めるなら、送る仕組みまでつながっていたほうが楽なはずだ、と考えました。
正直に言うと、「電子署名法」という言葉を、この時点では深く読んでいませんでした。
読んだのは、作った後です。順番が逆でした。
電子契約の“自作”で作れたのは、同意の記録
作ったものを一言でいうと、同意記録型の電子サインです。
流れはこうです。相手のメールアドレスへ、文書を開くリンクを送る。相手はアカウントを作らずにリンクを開き、内容を最後まで読む。名前を入れて「同意して締結する」を押す。
押した瞬間に、文書のハッシュ（SHA-256という、文書が1文字でも変わると別物になる指紋）を記録して、監査の記録に追記する。記録は追記だけで、あとから書き換える命令をコードに書かない。
最後に、締結済みのPDFを双方へメールで送ります。末尾には、誰がいつどの文書に同意したかの証明ページを付けました。
できあがったものは、ふつうの電子契約サービスと見た目はそれほど変わりません。
ただし、中身は「本人の電子署名」ではなく、「本人が同意した記録」です。この違いが、次の法律の話につながります。
電子契約の法律で、自作に“できないこと”
↑ここまで前提。↓ここから本題。
電子署名法には、大事な条文が2つあります。総務省の資料に条文がそのまま載っているので、そこから引きます（https://www.soumu.go.jp/main_content/000711458.pdf）。
第2条第1項は「電子署名とは何か」の定義です。要件は2つで、その情報が措置を行った者の作成に係るものであることを示すためのものであること、そして改変が行われていないかどうかを確認することができるものであること。
第3条は「推定」の話です。本人による電子署名が行われているときは、真正に成立したものと推定する、とあります。ただしカッコ書きがあって、その署名を行うために必要な符号や物件を適正に管理することで、本人だけが行うことができるものに限る、です。
推定というのは、総務省の資料の言葉を借りると、本人の意思に基づいて文書が作成されたことについて、反論がない限り裁判で証拠として扱われる、という効き目です。
で、ここが自作の限界でした。
うちの仕組みは、相手がリンクを開いて同意を押した記録は残せます。でも「本人だけが行うことができる符号」を相手に持たせているわけではない。だから第3条の推定が働くとは言えない。
法務省のページにも、本人による一定の要件を満たす電子署名が行われた電子文書は真正に成立したものと推定される、とあります（https://www.moj.go.jp/MINJI/minji32.html）。裏返せば、要件を満たさないものに推定はありません。
ちなみに、クラウドのサービスが自社の鍵で署名する「立会人型」については、総務省・法務省・経済産業省が2020年7月17日に第2条1項との関係を、同年9月4日に第3条との関係を整理したQ&Aを出しています。利用者の意思だけで機械的に暗号化されていることが担保されていれば、措置を行った者は利用者と評価できる、という解釈です。法務省が2022年4月にある事業者の照会へ回答した文書にも、その解釈が引用されています（https://www.moj.go.jp/content/001371653.pdf）。
つまり、ちゃんとしたサービスは、この要件を満たす設計と運用を積み上げている。個人の会社が8月に数日で作ったものと、そこは違う。
ここを認めたうえで、うちは3つの線を引きました。
線1：金額と種類で、自作とサービスを分ける
1本目は、どの契約に使うかの線です。
高額な契約（目安は50万円超）、雇用に関わる契約、争いになる可能性が高い契約は、自作の仕組みを使わず、外部のサービスを併用する。これを運用ルールとして書きました。
逆に、少額の業務委託や、内容の確認が主目的の合意は、同意記録型で足りると判断しました。
いや、全部サービスでいいでしょ？
僕もそう思った時期があります。でも、月に数通のために契約するのは、やっぱり負担でした。だから9月に業務委託の契約が増えてきた時点で、外部サービスの比較と契約の手続きを進めました。自作は「代わり」ではなく「少額の口」として残しています。
線2：証拠は、相手の手元にも残す
2本目は、記録の置き場所です。
自作の仕組みは、自分のサーバーに記録があります。でも、それだけだと「あなたのサーバーの記録でしょ」で終わる。
だから締結のたびに、相手にも締結済みのPDFと、その文書のハッシュを送るようにしました。相手の手元に同じ指紋があれば、後からどちらかが文書を差し替えても、照合でずれが出ます。
これは推定効の代わりにはなりません。ただ、改ざんを疑われた時に反証する材料にはなる。自作で持てるのはここまで、と割り切りました。
線3：送るボタンは、人が押す
3本目は、AIの関わり方です。
うちのAI社員は、契約書の下書きを作って、この仕組みに投入するところまでやります。でも「送る」ための口は、わざと作っていません。
送信は、人が管理画面で押す。これだけです。
理由は、契約は相手のある行為だからです。宛先の間違い、金額の桁、まだ合意していない条文。AIが途中まで作った下書きに、人が目を通すのは最後の1回だけで済む。その1回を省くと、取り返しがつかない。
作ってから直した2つの失敗
正直、動くまでに2回つまずきました。
1回目はフォントです。日本語のフォントをPDFに埋め込んだら、一部の表示系で日本語が描画されず、空白になりました。原因はフォントの形式で、別の形式のフォントに固定して解決しました。
2回目は、少し古いiPhoneです。文書を表示する部品の新しい版が古いブラウザで動かず、画面が真っ白になった。最新のパソコンのブラウザだけで確認していたので、気づけませんでした。古い版の部品へ戻し、表示できない端末向けに「端末の標準ビューアで開いて、最後まで読んだことを手で確認する」逃げ道を足しました。
どちらも、相手の画面で起きる失敗です。契約は相手が開くものなので、自分の環境で動いた、は何の保証にもならない。ここは痛かったです。
まとめ：自作で持てるのは「同意の記録」まで
電子契約をAIで自作して分かったことを、3つにまとめます。
作れるのは、本人が同意したことの記録と、文書が変わっていないことの指紋まで。第3条の推定は、符号を本人だけが持つ設計がないと働かない。
だから、金額と種類で線を引き、高額や雇用はサービスへ。証拠は相手の手元にも残す。送るボタンは人が押す。
まず、先月送った契約書の数を数えてみてください。月に数通なら、同意の記録を自分で持つ選択肢はあります。毎週送っているなら、最初からサービスのほうが早いです。
今日はこんな話でした。
AI社員構築 12大特典
AI社員に契約書の下書きを作らせて、人が最後の1回だけ見る形の指示書と、送る前の照合の型をまとめました。AIに仕事を任せ始めた経営者向けです。
