契約書の条番号のずれと別紙の参照漏れ、定義語の不統一を締結前に点検する

処理の起点を決める

作成者が契約書のドラフトを書き終えて、テキストにして貼り付けたときが起点です。自動実行はありません。

法務への審査依頼の前に置いてください。 依頼の後に法務が使う運用にすると、法務の作業が増えるだけで、作成者の側は何も変わりません。「審査依頼のときに、この点検を通した結果を添付する」というルールにすると定着します。

相手方のひな形を受け取った場合も同じです。先方が作った契約書にも、条番号のずれや別紙の参照漏れは普通にあります。 受領したらまず通してください。

入力データを集める

入力は契約書の本文だけで成立します。 ひな形も用語ルールもなくて構いません。この点検は、その文書の中だけで完結する整合を見るものです。 ひな形と比べる作業（ひな形からの逸脱を見つける）は別のユースケースです。

データの取得方法を決める

本文： Word からテキストをコピーして貼り付けます。このとき、条番号が本文と一緒にコピーされているかを確認してください。 Word の段落番号機能で自動採番している場合、コピーしたテキストに番号が入らないことがあります。番号が入っていなければ、この点検は成立しません。

対策は2つあります。1つは、PDFに書き出してからテキストを取ること。もう1つは、そもそも契約書で自動採番を使わないことです。 契約書は改訂と部分的な流用が前提の文書なので、番号を直接書くほうが扱いやすいという考え方があります。

別紙： 同じファイルの末尾にある場合はそのまま含めます。別ファイルの場合は、別紙の見出しだけを列挙して一緒に渡してください。 中身は不要です。「別紙1 仕様書」「別紙2 料金表」という一覧があれば、本文の引用と照合できます。

自社ひな形： 任意です。渡すと「ひな形の第10条に相当する条項が見当たらない」という指摘もできますが、まずはひな形なしで始めることをおすすめします。 指摘の種類が増えると、確認に時間がかかります。

AIへ渡す前に整形する

1. 条番号の確認 … 貼り付けたテキストに条番号が入っているかを、作成者が目視で確かめます。入っていなければPDF経由に切り替えます
2. 別紙の見出しの列挙 … 別ファイルの別紙がある場合、その見出しを本文の末尾に追記します
3. 押印欄・署名欄の分離 … 末尾の記名押印欄は点検の対象外です。含めても害はありませんが、指摘が出た場合は無視します
4. 相手方の社名の確認 … 契約書に相手方の社名が入っています。外部のAIサービスへ渡してよいかを確認したうえで、必要なら「甲」「乙」に置き換えます
5. 改行の整理 … PDFから取ったテキストは、条文の途中で改行が入ることがあります。極端に崩れている場合は整えます

AIに処理させる

条項の内容の評価はさせません。 「この責任制限条項は自社に不利です」といった判断は、この構成の対象外です。指摘の種類を機械的に判定できるものに限ることで、確認が速くなり、誤指摘も減ります。

修正案の文章も書かせません。 「第12条を第11条に直してください」という指摘までです。どう直すかは、条項を削った経緯を知っている作成者が決めます。

指示内容を固定する

あなたは契約書の形式面を点検する担当者です。
下の契約書について、文書としての整合だけを点検してください。

【点検する項目】
1. 条番号の相互参照
   「第◯条に定める」「第◯条第◯項」「前条」「次条」「前項」が、
   実在する条項を指しているかを確かめてください。
2. 条・項・号の番号の連番
   飛び番号、重複、順序の乱れを指摘してください。
3. 別紙・様式の照合
   本文で引用された別紙・様式が、下の「添付されている別紙の一覧」にあるかを確かめてください。
   引用されているのに一覧にないものと、一覧にあるのに引用されていないものの両方を挙げてください。
4. 定義語
   「以下『◯◯』という」の形で定義された語を抽出し、
   本文で一貫して使われているかを確かめてください。
   定義されていないのに定義語のように使われている語も挙げてください。
5. 表記ゆれ
   金額、期間、数量の表記の混在を挙げてください。

【厳守事項】
- 上の5項目だけを点検してください。条項の内容の妥当性を評価しないでください。
  有利・不利、追加すべき条項、リスクについて書かないでください。
- 修正後の文案を書かないでください。指摘と該当箇所までが役割です。
- 指摘は必ず「該当箇所（原文の該当部分を20字程度そのまま引用）／問題／根拠」の3列で返してください。
  原文を引用せずに指摘しないでください。
- 判断に迷うものは「要確認」として分けてください。断定しないでください。
- 「前条」「前項」の解釈が複数ありうる場合、その旨を書いてください。
- 契約書に書かれていない条項や別紙を前提にしないでください。
- 誤りが見つからなかった項目は「指摘なし」と書いてください。
  無理に指摘を作らないでください。

【契約書の本文】
{contract_text}

【添付されている別紙の一覧】
{attachment_list}

「無理に指摘を作らない」の1行が重要です。 これを書かないと、AIは何かしら指摘を絞り出します。「第5条の表現がやや冗長です」といった指摘が混ざると、本当の不備が埋もれます。

「原文を引用せずに指摘しない」も必須です。 「条番号にずれがあります」とだけ言われても、どこを見ればよいか分かりません。20字程度の引用があれば、Word の検索で一発でたどり着けます。

「内容の妥当性を評価しない」は、この構成の性格を決める一文です。 契約書の内容の審査は法務の専門業務です。そこへ踏み込ませると、作成者が「AIが問題ないと言ったから」と考えるようになります。 それがもっとも避けたい状態です。

出力形式を固定する

チャット画面で使うなら、表形式で受け取れば十分です。API連携まで進める場合は、JSON Schema を指定して出力を固定します。OpenAI API では response_format に json_schema 型を strict で指定することで、応答を必ずスキーマどおりの形にできます。

{
  "cross_references": [
    { "quote": "", "issue": "", "evidence": "", "status": "error | warning | check" }
  ],
  "numbering": [
    { "quote": "", "issue": "", "evidence": "", "status": "error | warning | check" }
  ],
  "attachments": {
    "cited_but_missing": [],
    "attached_but_not_cited": []
  },
  "defined_terms": [
    { "term": "", "defined_at": "", "inconsistent_uses": [], "status": "ok | inconsistent | undefined" }
  ],
  "notation": [
    { "quote": "", "issue": "", "evidence": "" }
  ],
  "no_findings": [],
  "needs_check": []
}

status を3段階にしている点に注意してください。

error だけを必須の修正対象にしてください。 すべてを同じ重さで扱うと、100件の契約書に対して数百件の指摘が出て、誰も直さなくなります。

no_findings は、点検して問題がなかった項目です。「別紙の照合：指摘なし」と明示されることで、点検が行われたことが記録されます。 何も出なかったのか、点検されなかったのかが区別できます。

システムへ連携する

連携先はありません。 指摘を見ながら Word のドラフトを手で直します。

強いて仕組みを足すなら、指摘の一覧をスプレッドシートに貼り付け、修正したかどうかの列を付ける程度です。これを契約ごとに残しておくと、審査依頼のときに「点検済み」の証跡になります。

法務への審査依頼のときに、この点検結果を添付する運用にしてください。法務は、error が0件であることを確認してから内容の審査に入れます。

電子契約サービスへの連携も不要です。締結の直前ではなく、審査の前に使うものです。

人が確認する

全件、作成者が1件ずつ確かめます。一括で修正しません。

理由は、指摘の中に誤りが混ざるためです。特に「前条」「前項」の解釈は、条項の構造によって変わります。AIが「第7条を指していると思われますが、第6条の可能性もあります」と書いたとき、どちらが正しいかは書いた人にしか分かりません。

確認の順序は次のとおりです。

1. status が error のもの … 必ず直す。存在しない条への参照と、別紙の添付漏れ
2. attachments.cited_but_missing … 添付漏れは締結後に問題になる。最優先
3. needs_check に入ったもの … 判断して、直すか残すかを決める
4. status が warning のもの … 時間があれば直す。定義語の揺れは直す価値が高い
5. attached_but_not_cited … 本文で引用されていない別紙。不要な別紙が残っている可能性がある

5つ目を見落とさないでください。 ひな形から流用したときに、使わない別紙が残っていることがあります。契約の一部として添付されている以上、効力を持ちます。

例外に対処する

記録を残す

チャット画面で使う場合、記録は自動では残りません。次の2つだけ、残すことをおすすめします。

• 点検の結果（error の件数と内容）と、修正したかどうか
• 法務への審査依頼に添付した点検結果

前者を契約ごとに残すと、どの種類の不備が多いかが見えます。 「別紙の添付漏れが月に5件ある」と分かれば、ドラフト作成の手順書に別紙のチェック欄を足すという対策が取れます。AIを使い続けるより、そちらのほうが根本的です。

契約書の本文そのものを外部サービスの履歴に残したくない場合は、履歴を残さない設定で使ってください。 相手方の社名と取引条件が含まれるため、組織の方針に従います。