取引先から戻ってきた契約書の修正版を自社の送付版と比べ、変更点と自社の運用への影響を法務担当向けに説明し、受け入れの判断の論点を並べる

処理の起点を決める

修正版が案件のフォルダの「受領」に保存されたことを起点にします。 法務の担当がメールやチャットで受け取った修正版を、決まった名前（例：2026-10-14_受領_修正版.docx）で保存する運用にします。定時の一括処理にしないのは、取引先が回答を急いでいることが多いからです。 受け取ってから数分でメモが届けば、その日のうちに論点を事業部に返せます。

同じ案件の送付版は、ファイル名の「送付」と日付で探し、いちばん新しいものを比べる元にします。 交渉が何往復かしていると、送付版が複数あります。前々回の版と比べると、すでに合意した変更まで出てきて、メモが読めなくなります。 比べる元にした版のファイル名は、メモの先頭に必ず書きます。

入力データを集める

質を決めるのは、運用の事実の表です。 「障害の第一報は2時間以内」「解約後のデータの削除は30日以内」のように、数字と、その数字を決めた部署と文書を1行ずつ持ちます。 AIはこの表に無い事実を作り出さないよう指示し、表に無ければ「確認先」として部署の名前だけを返させます。

最終確認日を持たせるのは、事実が変わるからです。 稼働率の目標や再委託先は、サービスの改善とともに変わります。半年以上確認していない行は、メモに「事実の確認が古い」と出します。

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

1. 修正版の本文を作る … .docx は ZIP の中の XML で、本文は document.xml にあります。Microsoft の Open XML の説明では、段落は p、その中の連続した文字のかたまりは r、文字は t で表され、挿入は ins、削除は del、移動は moveFrom／moveTo として記録されます。 挿入の中の文字は残し、削除と移動元は外して、変更をすべて受け入れた状態の本文を作ります
2. 変更履歴の一覧を別に持つ … 同じ XML から、挿入・削除の記録のある段落を控えます。後で「履歴に無い差分」を見分けるのに使います
3. 送付版の本文を作る … 送付版は自社が履歴を承諾してから送っている前提で、同じ方法で本文にします
4. 条項に分ける … 「第○条」で始まる段落で区切り、条番号と見出しを付けます。別紙と定義の条は別に扱います

1番目で、相手が受け入れたつもりの本文を作るのが要点です。 比べる相手を「変更をすべて反映した本文」にすると、履歴として残っている変更も、履歴を切って直した変更も、同じ差分として出てきます。 Word の画面で「変更履歴なし」の表示にしても履歴は一時的に隠れるだけで、承諾か却下をしない限り消えないとされています。見た目ではなく XML から作るのはそのためです。

AIへ渡す前に整形する

1. 表記のゆれをそろえる … 全角と半角の数字、空白、改行の位置をそろえます。そろえないと、空白1つの違いが差分として大量に出ます
2. 条番号の付け直しを見分ける … 条が1つ足されて以降の番号がずれた場合は、見出しと本文の一致の度合いで対応を取り、番号のずれだけの差分は「番号の変更」としてまとめます
3. 条項ごとの差分を取る … 対応する条項どうしを SequenceMatcher で比べ、get_opcodes() の equal 以外を変更として取り出します。比べる単位は文字です
4. 履歴の照合 … 取り出した変更が、2番目の取得の手順で控えた履歴の段落に入っているかを見て、入っていなければ untracked（履歴に無い変更）とします
5. 定義語の波及 … 定義の条で変わった語を拾い、その語を使っている条項をすべて集めます
6. 参照条項の波及 … 変更された条項を「第○条」で参照している条項と、変更された条項が参照している条項を集めます
7. 運用の事実の引き当て … 変更された文に、表の項目の語（稼働率、通知、削除、再委託、監査 など）があれば、その行を添えます

3番目で autojunk を切ります。 difflib の説明では、2つ目の並びが200要素以上あると、1％を超えて出てくる要素を「ジャンク」とみなすとされています。契約書を文字の並びで比べると「の」「を」「る」が1％を超え、差分の取り方が粗くなります。 SequenceMatcher(None, a, b, autojunk=False) で比べます。

4番目の untracked を、メモの一番上に出します。 相手が気づかせたくない変更とは限りませんが、担当者が履歴だけを見て読み飛ばしやすい変更です。

AIに処理させる

させるのは、機械が取り出した変更1つずつについて、説明と論点を書くことです。

論点は問いの形にさせます。 「障害の第一報の時間を1時間に縮めることを受け入れるか。受け入れる場合、夜間の当番の体制を変えるか」のように、決める人が答えればよい形にします。

4行目がいちばん起きやすい失敗です。 「一般的なクラウドサービスの稼働率は〜」のように業界の相場を自社の事実のように書きます。 表に無ければ「表に無い」と書かせ、確認先の部署の欄も空にします。

指示内容を固定する

あなたはクラウドサービス企業の法務部で、取引先から戻ってきた契約書の修正を、
法務の担当者に説明するメモを書く立場です。
【変更】は、自社の送付版と修正版をプログラムで比べて取り出したものです。
あなたが差分を探し直す必要はありません。渡された変更だけを説明してください。

【書くこと】（変更1つにつき）
1. what_changed：何が変わったか。変わった語を「」で示し、2〜3文で。
2. impact：自社のどの義務・権利が、どう変わるか。
   【波及先の条項】がある場合は、その条項の意味がどう変わるかも書く。
3. ops_conflicts：【運用の事実】の行と比べた結果。
   status は conflict（守れない）、needs_check（確認が要る）、ok（表の値で守れる）。
4. ask_to：確認先の部署。【運用の事実】の「決めた部署」だけを使う。
5. questions：受け入れを判断するための問いを1〜3個。問いの形で書く。

【厳守事項】
- 変更前・変更後の文言を言い換えて要約しないでください。引用は「」で原文のまま。
- 受け入れるべきか、断るべきかの結論を書かないでください。
- 代わりの文言を提案しないでください。
- 自社の稼働率、通知時間、削除の日数などは【運用の事実】の値だけを使ってください。
  表に無いときは ops_conflicts に「表に無い」と書き、値を推測しないでください。
- 業界の一般的な水準を、自社の事実のように書かないでください。
- 法令上の要件を断定しないでください。確認が要るなら questions に入れてください。
- untracked が true の変更は、what_changed の最初に「変更履歴に無い変更」と書いてください。

【案件】{deal}
【変更】{change}
【波及先の条項】{ripple}
【運用の事実】{ops_facts}

冒頭で「差分を探し直す必要はない」と書いているのは、AIが全文を読み直して別の変更を足すのを防ぐためです。 渡すのは1つの変更とその周辺だけですが、何も言わないと「ほかにも気になる点として」と書き足すことがあります。機械が拾っていない変更が混ざると、どれが本当の差分か分からなくなります。

推論の過程を出力させないのも、意図してのことです。 Claude の構造化出力の説明では、モデルの考えを段階的に書かせる項目を置くと拒否の扱い（reasoning_extraction）になることがあり、短い説明を求めるよう勧められています。impact と questions は短い説明と問いに限っています。

出力形式を固定する

変更1つにつき、次の形の JSON を構造化出力で受け取ります。

{
  "change_id": "",
  "clause": "",
  "untracked": false,
  "what_changed": "",
  "impact": "",
  "ripple_clauses": [
    { "clause": "", "effect": "" }
  ],
  "ops_conflicts": [
    { "fact": "", "our_value": "", "status": "conflict" }
  ],
  "ask_to": [""],
  "questions": [""]
}

障害の通知の条項が直された変更なら、受け取る中身はたとえば次のようになります。

{
  "change_id": "C-07",
  "clause": "第12条（障害の通知）",
  "untracked": true,
  "what_changed": "変更履歴に無い変更。第一報の期限が「障害を認識してから2時間以内」から「障害の発生から1時間以内」に変わった。",
  "impact": "起算点が「認識」から「発生」に移り、期限も短くなるため、通知の遅れが契約違反になりやすくなる。",
  "ripple_clauses": [
    { "clause": "第15条（損害賠償）", "effect": "第12条の違反が賠償の対象に入る" }
  ],
  "ops_conflicts": [
    { "fact": "障害の第一報", "our_value": "検知から2時間以内", "status": "conflict" }
  ],
  "ask_to": ["カスタマーサポート部"],
  "questions": ["起算点を「発生」とすることを受け入れるか", "1時間以内の第一報に夜間の体制で応じられるか"]
}

起算点の変更は、期限の数字よりも見落とされやすい変更です。 人が読み比べると「2時間が1時間に」だけに目が行き、「認識」が「発生」に変わったことに気づかないことがあります。差分を文字単位で取っているので、両方が変更として出てきます。

スキーマでは status を conflict・needs_check・ok の列挙にし、すべてのオブジェクトに additionalProperties: false を付けます。数の上限・下限を付けられないため、questions が3個を超えたらプログラムの側で切り、メモに「論点が多い」と印を付けます。

1つ目の理由は、運用の事実との食い違いを機械で数えられることです。 status が conflict の変更を集めれば、どの修正版がどの部署の運用に触れているかが一覧になります。担当部署へのまとめての問い合わせにも使えます。

2つ目は、untracked と ripple_clauses をメモの先頭に並べられることです。 法務の担当がまず見るべきは、履歴に無い変更と、波及の広い変更です。自由文で受け取ると、この並べ替えができません。

3つ目は、受け取った後に照合できることです。 プログラムは、what_changed の「」の中の文言が変更前か変更後の文に実際にあるか、ops_conflicts の our_value が運用の事実の表の値と一致するかを確かめます。一致しない項目は、メモで「要確認」にします。

応答が途中で切れたときの扱いも決めておきます。 公式の説明では、max_tokens に達すると stop_reason が max_tokens になり、出力が不完全でスキーマに合わないことがあるので、上限を上げて再試行するよう案内されています。拒否のときは stop_reason が refusal で、200で返り、スキーマに合わないことがあるとされています。どちらも stop_reason を見てから JSON を読みます。

システムへ連携する

契約書の本文には手を入れません。 この構成が作るのはメモだけで、修正版にも送付版にも書き込みません。 返すときの文言は、法務の担当が Word で直します。

メモの並び順を決めておきます。 先頭に「比べた版」「変更の数」「履歴に無い変更の数」「運用の事実と食い違う変更の数」、次に untracked の変更、conflict を含む変更、波及の広い変更、それ以外の順です。番号のずれだけの差分は、最後にまとめて1行ずつ並べます。

人が確認する

1. 差分そのものを確かめる … メモの各変更には、変更前と変更後の文を並べて載せます。AIの説明より先に、差分を目で見ます
2. untracked の変更を必ず読む … 取引先に「この変更は履歴に出ていなかった」と伝えるかも、担当者が決めます
3. 運用の事実との食い違いを担当部署に確かめる … conflict と needs_check だけを、確認先の部署にまとめて聞きます
4. 受け入れるかを決める … 論点を事業部に示し、上長の承認の範囲で決めます
5. 運用の事実の表を直す … 確かめた結果、表の値が古ければ、担当部署に表を直してもらいます

1番目を省かないでください。 AIの説明は差分の要約で、差分の取り違えがあれば説明も間違います。 変更前と変更後が並んでいれば、数秒で確かめられます。

目標は、40件をならして1件30分です。 差分の確認と、論点を事業部に示すまでの時間です。運用の事実の表に無い論点が多い月は30分を超えます。 それは表を育てる材料になります。

例外に対処する

いちばん重いのは、上から4行目です。 相手が自社の雛形の書式に全文を組み直して返してくると、条項の対応が取れず、差分が意味をなさなくなります。 その場合は、AIで無理に説明せず、交渉の担当に「全文の読み直しが要る」と知らせるのが正しい扱いです。

記録を残す

• 比べた2つのファイル（送付版と修正版）と、それぞれのハッシュ値
• 作った本文（変更を反映した修正版の本文、送付版の本文）と、条項の対応表
• 差分の一覧（get_opcodes() の結果）と、untracked の判定
• 波及先として集めた条項と、引き当てた運用の事実の行
• Claude API に渡した入力と受け取った出力の全文、stop_reason
• 照合の結果と、法務の担当が付けた判断（受け入れ／交渉／保留）

ハッシュ値を残すのは、どの版とどの版を比べたかを後から確かめるためです。 交渉が何往復かすると、「その変更はいつの版で入ったのか」を聞かれます。ファイル名だけでは、上書きされた版を区別できません。