契約書にAIを使うなら、まず条項の抽出や新旧版の比較を補助させ、結果を原文へ戻って確かめる工程を作りましょう。「どこに何が書かれているか」の整理と、「その条件で契約してよいか」の判断を分けることが出発点です。
この記事では、企業の契約担当者とAI導入担当者に向け、入力前の情報管理、出力の照合、試行の確認表を示します。表と指示文は運用設計の例であり、特定製品の性能や個別契約の法的結論を示すものではありません。
契約書のどの作業をAIで補助するか
文書処理の機能例として、MicrosoftのDocument Intelligenceには、文字・構造・フィールドを抽出する機能があります。ただし、文書から値を取り出せることと、契約条件を適切に評価できることは別に考える必要があります。Microsoftの技術資料
試行では、次のように作業と最終確認者を決めます。抽出や比較がどこまでできるかは、採用するツールと対象文書で検証してください。
| 作業 | AIに求める出力の例 | 人が確認・判断すること |
|---|---|---|
| 条項の抽出 | 契約期間、更新、解除などの原文と条番号 | 抽出漏れ、例外、別紙への参照 |
| 新旧版の比較 | 変更前後の文章と位置 | 変更の意味、他の条項への影響 |
| 社内基準との比較 | 基準と異なる箇所の候補 | 基準の適用可否、例外承認の要否 |
| 修正文案の作成 | 指定した交渉方針に沿う下書き | 法的な妥当性、他条項との整合、相手への提示可否 |
最初は抽出または比較に対象を絞ると、正誤を原文と照合する試行を組みやすくなります。リスクを受け入れるか、どの条件を交渉するか、契約を承認するかは、社内の権限者と契約・法務担当の工程に残します。
入力前に、契約文書を渡してよいか確かめる
個人情報保護委員会は、個人情報を含む入力が利用目的の達成に必要な範囲か確認するよう求めています。また、本人同意なく入力した個人データが応答出力以外に扱われる場合は法違反となる可能性があり、機械学習に使われないこと等の確認を促しています。個人情報保護委員会の注意喚起・（1）
契約書では個人情報に加え、秘密保持の対象や未公開の取引条件も点検しましょう。入力可否を判断するときは、次の項目を社内の情報管理担当と埋めます。
| 確認項目 | 記入する内容 |
|---|---|
| 利用する環境 | サービス名、契約プラン、組織アカウント、管理者 |
| 渡す情報 | 対象文書、個人情報・秘密情報の有無、入力を認める根拠 |
| データの利用 | 学習利用の有無、その他の利用目的、適用される規約・設定 |
| 保存と削除 | 原文・出力・ログの保存期間、削除方法、確認担当 |
| 閲覧と共有 | 閲覧権限、共有先、外部連携先 |
学習に使われないという説明だけで入力可とせず、保存・閲覧・共有も別々に確認します。自社の契約に適用される条件が不明なら、実際の契約書の投入は保留し、入力許可を確認できた文書で試してください。
名称を伏せて使う場合も、本文、別紙、コメントなどに確認対象の情報が残っていないか点検します。置換後の「甲」「乙」などの対応は保ち、誰の義務か照合できる状態にします。
抽出結果には条番号と原文を付ける
生成AIは誤った内容を自信のある表現で出すことがあります。NISTもこれを生成AIのリスクとして整理しています。そのため、読みやすい要約だけを確認材料にしないことが大切です。NIST AI 600-1・2.2
抽出時は、次のような指示を出発点にできます。
指定した契約書から、契約期間、更新条件、解除手続きを抽出してください。項目ごとに文書名・版、条番号、原文、要約、例外条件、参照先を分けて示してください。原文から確認できない値を補わず、見つけられない場合は「未確認」としてください。法的な有効性や契約の承認可否は判定しないでください。
この指示に従ったかも検証対象です。確認担当者は原文と出力を並べ、金額・日付・否定表現・例外条件を照合します。「未確認」は条項がないことの証明にはせず、別名の見出しや別紙も探します。
画像PDFを使うときは、文字認識（OCR）の結果も確認してください。Microsoftは、スキャン品質や解像度などがOCRの精度に影響すると説明しています。抽出された文字だけでなく、必要な箇所を元画像に戻って確認する手順を入れます。Microsoftの精度に関する説明
新旧比較では「差分なし」も照合する
比較する文書には、旧版と新版の名前・版を明記し、別紙や変更合意書を含める範囲を先に決めます。AIが挙げた変更点だけでなく、人が用意した確認対象との突き合わせも行いましょう。
たとえば、検証用の文書で「更新しない旨の通知」の期限だけを変えた場合、期限の差が抽出されたかに加え、通知の主体、方法、例外を同じ行で確かめます。これは検証例であり、実在の契約や当社の導入実績ではありません。
| 照合する項目 | 記入欄 |
|---|---|
| 対象 | 文書名・旧版・新版：＿＿ |
| 原文 | 旧版の条番号と文言：＿＿／新版：＿＿ |
| 差分 | AIの出力：＿＿／人が確認した差分：＿＿ |
| 周辺条件 | 定義、ただし書き、別紙、参照条項：＿＿ |
| 判定 | 一致・修正必要・未確認：＿＿ |
| 引継ぎ | 判断が必要な論点、担当者、期限：＿＿ |
条番号だけが変わった箇所と、条件が変わった箇所は分けて記録します。システム開発契約で何を読むべきかを整理する場合は、工程・成果物・変更をモデル契約で確認する方法も参考になります。
試行では、確認と修正を含めて評価する
試行用の文書では、契約担当者が原文を読んで抽出項目や差分の正解を先に用意します。読みやすい文書に加え、別紙参照、例外条件、画像の読み取りが必要なものも含め、実際に使う範囲を確かめてください。
評価記録には、正しく抽出できた項目だけでなく、見落とした項目、存在しないのに出した内容、修正した箇所、人へ戻した理由を残します。所要時間はAIの処理時間に加え、入力準備、照合、修正、承認まで測り、同じ文書を従来の手順で確認した結果と比べます。
承認の条件としては、「重要な差分の見落としが残れば対象を広げない」「原文に戻れない出力は採用しない」などを試行前に決めておくとよいでしょう。利用範囲やツールの変更後も、同じ評価用文書で再確認します。
まず決めるのは、試す契約の種類、入力してよい文書、照合担当者の三つです。限定した業務で結果を確かめた後の進め方は、生成AI導入のステップで整理しています。