DocuSignからOdoo Signへの移行をすすめました。
以前の記事では、DocuSignで使っていた署名テンプレートをOdoo Signへ移行しました。
ただ、DocuSignにはこれまで実際に締結した契約書が残っています。
お客さんとの基本契約書、NDA、業務委託契約書、スタッフの雇用契約書など、過去にDocuSignで締結した文書です。
DocuSign自体はすでに有料契約ではなく、無料のアカウントを残している状態ですが、アカウントがある限り締結した契約書はアクセスできます。
ただせっかくOdooへ移行したのであれば、Odooの連絡帳（顧客DB）に過去の契約書を紐づけたいと思いました。
ただし、契約書を1件ずつ開いて、契約相手を確認して、Odooで会社を探して（無いければ登録）、紐づけるのはかなり面倒です。
そこで今回は、AIにこの作業をどこまで任せられるか試してみました。
今回の目的は、単にPDFをOdooへ保存することではありません。保存をするのではなく、Docusignの該当契約書のURLをOdooの連絡帳に紐づけて最終的には、Odooの連絡先から会社を開けば、その会社と過去に締結した契約書を確認できる状態にします。
例えば、DocuSignに「株式会社ABC × 株式会社マルウェブ」の基本契約書があった場合、Odoo側では、株式会社ABC→ 基本契約書（2023年4月2日 / DocuSignへのリンク）という形で紐づいていれば十分です。
会社間の契約であれば、契約書へ署名した担当者個人ではなく、契約主体となる会社へ契約書を紐づけます。担当者は退職や異動で変わりますが、契約自体は会社間で継続するためです。個人事業主や社員との雇用契約など、個人本人が契約当事者になっている場合だけ個人の連絡先へ紐づけます。
最初はPDFもOdoo Documentsへ入れるつもりでした。ただ、実際に必要なものを整理していくと、「この会社と、いつ、どの契約を結んだか」が分かれば十分です。年に1度確認するかしないかの契約書をわざわざDL、UPするのはだるいです。
また、Docusign以外にも他にGMOサイン、クラウドサイン、Freeサインなどもありこれらは無償で主に受け手（クライアントサイドから指定されて使う）として使っており、APIやMCPなどが使えるわけではないので、その３つもDLしたりULするのは、更にだるいです。
PDF本体はDocuSign側に残っていますし、必要になったときにリンクから開けば済みます。そこで最終的には、
の4つだけをOdooへ持たせる形にしました。Odoo Documentsは使わず、連絡先に「契約」タブを追加して、そこに一覧表示されるようにしています。
PDFを持たない分、移行はかなり軽くなりました。
「Odoo Signへ移行するのだから、契約書もOdoo Signへ入れるのでは」と思われるかもしれません。
ただ、今回はOdoo Signには入れていません。
Odoo Signはで契約書した相手の連絡帳に自動的に紐づくからです。
紐づく場所は違います。とはいえ整理は出来てます。
今回扱うのはすでに締結が終わった過去の契約です。
もう一度署名する必要はありませんし、署名依頼として登録すると、これから動かす本番の署名依頼と混ざってしまいます。
「進行中の署名依頼が5件」と表示されるべき画面に、10年前の締結済み契約が並ぶのは困ります。もう一つ、署名の法的な証跡はDocuSign側の完了証明書にあります。
締結済みのPDFをOdoo Signへ入れ直しても、その証跡が引き継がれるわけではありません。入れ直したところで「Odooで署名した契約」になるわけではないのです。
そこで、
というふうに、役割で置き場所を分けました。
Odoo Signは署名をするための仕組み、連絡先は取引先を管理するため箇所。
そもそも締結先から今後またDocusign他で締結ごとは発生します。
過去の契約は「この会社とこういう取引があった」という記録なので、後者に置くほうが自然だと判断しました。
1件だけなら難しい作業ではありません。
これだけです。ただ、過去の契約書を全部やるとなると、それなりの作業量になります。しかもOdoo側には、
が混在しています。単純に、「Odooで見つからなければ新しい会社を作る」だけでは、同じ会社を重複登録する可能性があります。そこで、この判断も含めてAIへ任せることにしました。
DocuSignにはAPIがあります。解約後も一定期間はAPIでアクセスできたので、今回はブラウザ操作ではなくAPI経由で処理しました。具体的には、Claude Code（ターミナルで動くAI）に対して、DocuSignのREST APIから契約一覧を取得する
という処理を書かせて実行しています。
ブラウザを1件ずつクリックしていく方法に比べると、全件を安定して処理できます。
ただし後編で書きますが、APIが使えないツールもあります。
無料プランだとAPIもCSVエクスポートも提供されないケースが多く、その場合はブラウザAIの出番になります。DocuSignとOdooのデータは、次のルールで扱いました。
最初にやったのは、DocuSignに何件残っているかを正確に数えることです。結果はこうでした。
| ステータス | 件数 | 扱い |
|---|---|---|
| Completed（締結済み） | 数百件 | 移行対象 |
| Sent（返信待ち） | 1件 | 移行対象 |
| Voided（取り消し） | 約30件 | 対象外 |
実際にOdooを整理している途中で、一つ問題が見つかりました。Odooの連絡帳には、通常の一覧画面では表示されていないものの、アーカイブ済みとして残っている連絡帳があります。以前Odoo Signで利用した連絡先なども、アーカイブされているケースがありました。この状態で、「見つからなければ新しい連絡帳を作る」という指示だけを出すと、同じ会社をもう一度作ってしまう可能性があります。
そのため、既存連絡帳を探す際にはアーカイブ済み連絡帳も必ず検索するというルールを追加しました。通常表示されないだけで、データそのものは残っている場合があります。AIへ業務作業を任せる場合、「存在しない」をどう定義するかは意外と重要です。
DocuSignでは、署名者の情報が中心になります。例えば、株式会社ABCとの契約で、田中太郎さんがDocuSignで署名していたとします。ただし今回Odooで管理したいのは、「田中さんが署名した契約」ではなく、「株式会社ABCと締結している契約」です。
そのため、会社間契約では署名担当者の個人Contactを新しく作ることはせず、原則として会社Contactへ契約書を紐づけます。Odooで株式会社ABCを開けば、
など、その会社との契約をまとめて確認できる形です。一方で、雇用契約書や誓約書は社員個人へ紐づけます。契約当事者が誰なのかで、紐づけ先を変えています。
移行を始めてすぐ、想定外の問題が出ました。
DocuSignのAPIは、署名者の会社名を返してくれませんでした。。。
正確には項目自体はあるのですが、全件すべてで空でした。取れるのは氏名とメールアドレスだけです。つまり、
xxxx@xxxxxx.co.jpというメールアドレスから、株式会社xxxxxという正式名称を自力で特定しなければなりません。件名から拾えることもありますが、「機密保持契約書.pdf」のような件名も多く、半分ほどは手がかりが無いようです。
最終的には、メールアドレスのドメインから各社の公式サイトを1社ずつ確認して、会社概要ページに書かれている正式名称を取得しました。約3分の1社ぶんです。ここはAIに推測させず、必ず一次情報にあたるようにしました。会社名を間違えて登録すると、後から名寄せするのが非常に面倒になるためです。
もう一つ、数件分だけですが、相手先が表面的にまったく分からない契約がありました。署名者が自社の人間ひとりだけで、件名も「機密保持契約書.pdf」としか書かれていません。
調べてみると、これらはDocuSignの「自分で署名」機能で処理された文書でした。先方から受け取った紙やPDFを取り込んで、自社側だけが署名したケースです。この場合、DocuSign側には受信者もCCもカスタムフィールドも残りません。
相手先は契約書本文にしか書かれていないわけです。そこでこの8件だけはPDFを一時的に取得して、本文からテキストを抽出しました。
結果、全件特定できました。
契約書は結局のところ、当事者が本文に明記されている文書です。システムのメタデータが空でも、中身を読めば分かります。
契約相手の会社が連絡帳に存在しない場合は、新しい連絡帳を作成します。
この場合も、AIに自由に情報を補完させるのではなく、契約書や公式サイトから明確に確認できる情報だけを利用します。
例えば、
などです。分からない情報を無理に推測して入力する必要はありません。住所については、契約書PDFの本文から抽出する方法も試しました。
63社中41社で取れましたが、そのうち7社は
「東京都渋谷区広尾」
のように番地が欠けていたり、契約条項の一部を住所と誤認していたりしました。このあたりは自動抽出の限界だと感じたので、最終的には公式サイトで確認し直しています。
今回の目標達成は非常にシンプルです。
Odooで会社名を検索する。
会社を開く。
その会社との契約書を確認する。
これまでのように、「DocuSignだったか」「メール添付だったか」「ファイルサーバーだったか」と探し回る必要をなくします。
契約先というOdoo上のマスターデータを中心に、関連する契約書をまとめて管理する形です。
今回の作業自体は、技術的には特別難しいものではありません。ただ、人がやるとかなり面倒です。
このような、複数のSaaSをまたぐ定型作業＋多少の判断が必要な作業は、AIとかなり相性が良いと感じました。
APIがあるならコードで、APIが無いならブラウザ操作で。入口は違っても、「読んで、判断して、登録する」という中身は同じです。従来のRPAの場合、「この位置をクリックして、この文字列をコピーする」という処理が中心でした。今回の場合は、「契約書を読んで、契約相手がどの会社なのか判断する」ところまでAIへ任せられます。一方で、AIへ何でも自由に判断させればよいわけではありません。
今回も、
といったルールは、人間側であらかじめ決めています。AIに作業を任せる場合、操作手順以上に、何を基準に判断させるかを決めることが重要になりそうです。
以前は、AIにプログラムを書いてもらうという使い方が中心でした。最近はそれだけではなく、AI自身に既存サービスの中にあるデータを整理させるという使い方も現実的になってきています。
今回のDocuSignからOdooへの移行も、その一例です。
契約書を確認する。
契約相手を判断する。
Odooの既存会社と照合する。
必要であれば会社を作る。
会社へ紐づける。
一つ一つは単純ですが、人が全部やると時間がかかります。こういった業務こそ、AIを活用できる領域なのかもしれません。DocuSignからOdoo Signへの署名機能の移行だけでなく、過去の契約資産までOdooへ集約できれば、契約管理そのものをOdooへ一本化できます。次回は、無料プランのまま使い続けているクラウドサイン・GMOサイン・freeeサインについても、同じようにOdooへまとめてみます。
入れていません。Odoo Signは「これから署名する」ための機能で、締結済みの契約を登録すると進行中の署名依頼と混ざります。署名の法的な証跡は元のDocuSign側の完了証明書にあり、入れ直しても引き継がれないため、過去の契約は取引の記録として連絡先に紐づけました。
今回は移行していません。契約書タイトル・契約日・元システムへのリンク・Envelope IDの4項目だけをOdooに持たせ、PDF本体は必要なときにリンクから元システムで開く方針にしました。移行が軽くなり、証跡も元システム側に保たれます。
今回のケースでは、解約後も一定期間はAPIで過去データへアクセスできました。この期間内であればコードによる一括処理が可能です。アクセスできる期間は契約条件によって異なるため、解約前に確認しておくのが安全です。
当社はOdooの公式パートナーとして、Signを含むOdooの導入設計・カスタマイズ・外部システムからの移行を支援しています。本記事のような移行の設計段階からのご相談はOdoo導入・開発・業務統合支援をご覧ください。