海外の取引先から変更履歴付きで返ってきた英文NDAの修正を、条項ごとに訳して自社の雛形との違いを法務向けのメモにする

処理の起点を決める

案件のフォルダの「受領」に、Word のファイルが保存されたことを起点にします。 メールの添付を自動で拾う形にはしません。相手方からのメールには、修正案のほかに参考の資料や、古い版が付いてくることがあり、どれが今回の修正案かは担当が決めたほうが確かです。

スクリプトは15分おきに「受領」を見に行き、新しいファイルがあれば処理します。

処理が終わったファイルは「処理済み」へ移し、メモの下書きを同じ案件のフォルダに置きます。移すのは、メモまでできたときだけにします。 途中で止まったものは「受領」に残り、残っている数がそのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 交渉の目安が無ければ、AIは「雛形と違う」とまでしか言えず、その違いを受け入れてよいかの手がかりがメモに入りません。 用語の対訳表が無ければ、同じ語が案件ごとに違う訳になり、第3章の（b）がそのまま残ります。

前回送った版は、必ずそろえます。 第1章で書いた「変更履歴に出てこない差」は、これが無いと拾えません。相手方が自社の版に手を入れたのではなく、別の版を下敷きにして返してくることもあるので、比べる相手は雛形ではなく、実際に送った版です。

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

Word のファイル（.docx）は、中身が XML のファイルをまとめた圧縮ファイルです。Python の標準のライブラリで開き、本文の XML から変更の記録を取り出します。 取り出すものは次のとおりです。

変更ごとに、前後の文もあわせて取り出します。 削除と挿入は、単語の単位で細かく入ることが多く、「"or" を消して "and" を入れた」だけを渡しても意味が分かりません。 変更を含む一文を、変更前と変更後の2つの形に組み立ててから渡します。

作成者で、相手方の変更と自社の変更を分けます。 往復が2回目以降になると、ファイルの中には自社が前回入れた変更履歴も残っていることがあります。メモに載せるのは、相手方の作成者の変更だけにします。

前回送った版との突き合わせには、受け取った版の「変更前の状態」を使います。 相手方の変更をすべて取り消した形の文を組み立て、送った版の文と条項ごとに比べます。差が無ければ、相手方の変更はすべて変更履歴に出ています。差があれば、それが履歴を付けずに直された箇所です。

AIへ渡す前に整形する

1. ファイルの形式の確認 … .docx であることを確かめます。.doc や PDF で届いたものは処理せず、担当に知らせます
2. パスワードの確認 … 開けないファイルは止めて担当に知らせます。相手方に、パスワードを外した版を頼むのは人の仕事です
3. 条項の番号の付与 … 見出しと段落の番号から「第3条第2項」のような位置を付けます。自動の段落番号は、XML の中では数字として書かれていないことがあるので、番号の振り方を数えて組み立てます
4. 変更のまとめ … 同じ一文の中の細かい挿入と削除は、1つの変更としてまとめます
5. 作成者による振り分け … 相手方の変更と、自社が前回入れた変更を分けます
6. 履歴に出てこない差の抽出 … 第7章の「データの取得方法」で書いた突き合わせを行います
7. 雛形と目安の引き当て … 条項の見出しから、雛形の該当条項と交渉の目安の行を引きます。見出しが変えられているときは、本文の書き出しで引きます
8. 大きさの確認 … 変更が多い修正案は、条項のまとまりごとに分けて Claude API に渡します

4番目の手を抜くと、メモが読めなくなります。 1つの文に削除と挿入が10か所あると、そのまま渡せば10行の訳と説明が並びます。読む側が知りたいのは、その文が全体としてどう変わったかです。

7番目で引けなかった条項は、「雛形に無い条項」として扱います。 相手方が新しく足した条項（たとえば、相手方にも自社の情報を使わせる条項や、競業を禁じる条項）は、雛形との比較ができないので、メモの中でいちばん目立つ場所に置きます。

AIに処理させる

させるのは、取り出した変更の1つずつについて、訳と意味の説明を書くことだけです。

2行目がこの設計の要です。 変更の範囲はプログラムが決め、AIはその範囲の中だけで働きます。AIが「ほかにも変わっている箇所があります」と書いてきたら、それは誤りか、プログラムの取り出し漏れのどちらかです。 どちらであっても、AIの出力から拾うのではなく、取り出しのほうを直します。

交渉の目安との当てはめを「候補」にしているのは、目安の表が言葉で書かれているからです。 「秘密保持の期間は3年以上」のように数で書かれた行は当てはめやすいですが、「開示目的の範囲を広げすぎない」のような行は、読む人によって答えが変わります。 候補として出し、担当が確かめます。

指示内容を固定する

あなたは日本企業の法務部で、海外の取引先との秘密保持契約（NDA）の交渉を
補助する立場です。相手方から返ってきた修正案の変更を、法務の担当が
日本語で理解できるように説明します。

【前提】
- 自社の立場：{disclosing_or_receiving}（開示する側／受ける側／相互）
- 取引の目的：{purpose}
- 開示する予定の情報：{info_types}

【あなたに渡すもの】
- 変更の一覧：変更ごとに change_id、条項の番号、変更前の一文、変更後の一文、
  相手方のコメント（あれば）
- 自社の雛形の該当条項
- 交渉の目安の表（条項ごとの受け入れる範囲・押し返す点）
- 用語の対訳表

【やること】
変更ごとに、次を書いてください。
1. 変更前の一文と変更後の一文の日本語訳
2. 何がどう変わったかの要約（一文）
3. 自社の義務・権利がどう変わるか
4. 自社の雛形の該当条項との違い
5. 交渉の目安の表のどの行に当たるか、範囲の内か外かの候補
6. 原文の意味が一つに決まらない箇所、相手方に意図を聞くべき箇所

【厳守事項】
- 渡された変更の一覧の中の変更だけを扱ってください。
  一覧に無い変更を見つけたと思っても、新しい変更として書かないでください。
  気づいたことがあれば notes に書いてください。
- 訳語は用語の対訳表に従ってください。対訳表にある語を言い換えないでください。
- "shall" "may" "will" "best efforts" "reasonable efforts" "including but
  not limited to" など、義務の強さや範囲を決める語は、訳で強さを変えないでください。
- 原文に書かれていないことを補って説明しないでください。
  意味が一つに決まらないときは ambiguity に書き、どちらかに決めないでください。
- 受け入れるべきか、押し返すべきかを書かないでください。
- 準拠法・管轄・外国法の効果について、法的な評価を書かないでください。
- 交渉の目安の表に当たる行が無いときは、playbook_row を空にし、
  playbook_fit を not_covered にしてください。
- 雛形に該当する条項が無いときは、template_diff に「雛形に無い条項」と書いてください。

【変更の一覧】{changes}
【雛形の該当条項】{template_clauses}
【交渉の目安】{playbook}
【用語の対訳表】{glossary}

「一覧に無い変更を書かない」を最初に置いているのは、AIが親切に探してしまうからです。 前後の文を渡しているので、AIはそこから「この語も変わっているようです」と推測で書くことがあります。推測の変更がメモに混ざると、担当は本物の変更と区別できません。 気づきは notes という別の欄に逃がします。

義務の強さを決める語を名指しで並べているのは、訳で強さが動きやすいからです。 "shall use reasonable efforts" を「努める」と訳すか「合理的な努力をしなければならない」と訳すかで、読む人が受け取る義務の重さが変わります。 変更の多くは、まさにこの語の入れ替えです。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "contract_id": "",
  "round": 2,
  "changes": [
    {
      "change_id": "c07",
      "clause": "第4条第1項",
      "change_type": "insert | delete | replace | move | format",
      "before_en": "",
      "after_en": "",
      "before_ja": "",
      "after_ja": "",
      "summary_ja": "",
      "effect_on_us": "",
      "template_diff": "",
      "playbook_row": "",
      "playbook_fit": "within | outside | not_covered | unclear",
      "ambiguity": "",
      "questions_to_counterparty": []
    }
  ],
  "notes": ""
}

1つ目の理由は、変更ごとの行が対照表にそのまま入ることです。 change_id はプログラムが付けた番号で、AIはそれを写すだけです。プログラムが取り出した変更の数と、返ってきた行の数が合わなければ、その時点で止めます。 抜けた変更があるメモを担当に渡さないためです。

2つ目は、playbook_fit を4つの値から選ばせることです。 担当はまず outside と not_covered と unclear の行から読みます。within の行は、訳と要約だけを確かめれば足ります。 読む順番が決まることで、メモを確かめる時間が短くなります。

3つ目は、notes を別に持つことです。 一覧に無い変更についての気づきは、ここにしか書かせません。notes に何か書かれていたら、プログラムの取り出しを疑う合図にします。

メモの下書きは、この JSON から Python が Word のファイルとして組み立てます。先頭に「変更履歴に出てこない差」と「雛形に無い条項」を置き、そのあとに条項の順で変更の対照表を並べます。 対照表は「条項｜変更前の原文｜変更後の原文｜訳｜要約｜意味｜目安」の列です。

システムへ連携する

契約の申請の仕組みには、自動では書き込みません。 メモは担当が確かめて自分の判断を書き足してから、担当の名前で申請に添えます。 AIの下書きのまま事業部に届くと、それが法務の見解として読まれます。

交渉の目安と対訳表は、読むだけです。 交渉の中で新しく決めた目安や訳語は、担当が表に書き足します。AIの出力から目安を自動で足す仕組みは作りません。

人が確認する

メモは全件、法務の担当が読んでから使います。 確かめる順番を決めておきます。

1. 「変更履歴に出てこない差」を最初に見る … ここに何か出ていたら、相手方に意図を確かめるかを決めます。AIの訳より先に見ます
2. outside・not_covered・unclear の行を、原文と訳を並べて読む … 訳が原文の強さどおりか、意味の説明が正しいかを確かめます
3. within の行は、訳と要約を流し読む … 目安の当てはめが本当に内側かを、数で書かれた目安から確かめます
4. 自分の判断を書き足す … 受け入れる・押し返す・代案、とその理由を担当が書きます
5. 直したところを記録する … 訳や説明を直したら、どの変更の、どの欄を直したかを残します

1番目を飛ばさないでください。 変更履歴に出てこない差は、件数としては少なくても、見落としたまま締結すると取り返しがつきません。 体裁を整えただけに見える差でも、定義の語が1つ変わっていれば意味が変わります。

目標は、1通あたり50分です。 変更が多い修正案は時間がかかり、往復の3回目以降で変更が2〜3か所のものはすぐに終わります。ならして50分を超える月が続くなら、交渉の目安の表が足りていない可能性があります。 not_covered が多ければ、目安を書き足すのが先です。

例外に対処する

上の2行が、運用を始めてしばらくいちばん多い例外になります。 相手方によっては、変更履歴を付けない、PDFでしか返さないのが習慣になっています。そうした相手方には、交渉の最初に「変更履歴付きの Word で返してほしい」と頼むほうが、仕組みを工夫するより早く効きます。

記録を残す

• 受け取った修正案と前回送った版のファイル、受け取った日時
• 取り出した変更の一覧（変更の番号、条項、種類、作成者、日時、変更前と変更後の一文）
• 変更履歴に出てこない差の一覧
• Claude API に渡した内容と、返ってきた JSON の全文
• そのとき参照した交渉の目安と対訳表の版
• 担当が直した箇所の記録 … どの変更の、どの欄を、どう直したか
• 担当が書き足した判断と、最終的に相手方へ返した内容

目安と対訳表の版を残すのは、表が交渉のたびに育つからです。 半年前のメモで within だった変更が、いまの目安では outside になることがあります。当時の目安が残っていないと、なぜその変更を受け入れたのかが説明できません。

担当が直した記録は、指示と対訳表を直す材料です。 同じ語の訳を何度も直しているなら、対訳表に足します。同じ種類の説明を何度も直しているなら、指示の書き方が足りていません。