契約交渉で相手方から戻ってきた変更履歴付きの修正案を、自社の交渉方針と譲歩の範囲に照らして受け入れ・反論・代案に仕分け、反論のコメント案を作る

処理の起点を決める

「交渉_戻り」ライブラリに修正案が置かれたことを起点にします。 SharePoint コネクタの「ファイルの作成時 (プロパティのみ)」のトリガーはライブラリの列の値だけを返すので、中身は「ファイル コンテンツの取得」で、返ってきたファイル識別子を使って取り出します。

案件の番号の列が空なら、何もせずに営業へ知らせます。 番号が無いと、送った版を引けず、変更履歴に出ない修正を探せません。送った版との突き合わせができないまま仕分けを出すと、見落としがあっても気づけないので、ここで止めます。

同じ案件で2本目、3本目の修正案が戻ってきたときも、同じフローで動かします。送った版は「直前に自社が返した版」を台帳から引きます。

入力データを集める

質を決めるのは、交渉方針の表の書き方です。 「責任の上限は柔軟に対応」では、AIも担当者と同じく経験で読むしかありません。「年額1,000万円未満は12か月分まで、それ以上は24か月分まで法務部長の承認で可、故意・重過失の除外は削除不可」のように、条件と範囲と承認者を1行に書きます。 金額と区分で範囲が変わる条項は、行を分けます。

前回の回答を渡すのは、第3章の（c）のためです。 同じ顧客の同じ条項に前回どう返したかを並べ、今回の仕分けが前回と違えば印を付けます。

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

交渉方針の表は全部を渡しません。 利用契約の修正に業務委託契約の方針を当てると、当たらない行を根拠に仕分けます。契約の種類で絞ってから渡します。

契約の本文も全部は渡しません。 渡すのは、修正のあった条と、定義語でつながる条だけです。20ページの本文を毎回渡すと、修正の無い条の文言を根拠に理由を書くことがあり、担当者が確かめる範囲が広がります。

AIへ渡す前に整形する

1. 変更履歴の取り出し … 挿入、削除、段落の書式の変更、移動元と移動先を、作成者・日時・本文の位置とともに取り出します
2. 作成者で分ける … 相手方が入れた修正と、自社が前回入れて残っている修正を、作成者で分けます。仕分けるのは相手方の修正だけです
3. 書式だけの変更を分ける … 段落の書式の変更だけのものは、仕分けの対象から外し、件数だけを残します
4. 変更履歴に出ない差を探す … 変更履歴をすべて受け入れた本文を作り、送った版の本文と段落ごとに比べます。変更履歴として記録された差を除いて残った差を、untracked として挙げます
5. 条項ごとにまとめる … 修正の位置から条番号を引き、同じ条の修正をまとめます。定義の条の修正は、その定義語を使っている条の番号も付けます
6. 前と後の文を作る … 修正ごとに、修正の前の文と後の文を並べます
7. 移動を1つの修正にまとめる … 移動元と移動先の要素は、同じ移動の名前で対になっています。削除と挿入の2つとして数えず、「条の順番を変えた」1つの修正として扱います

2番目の作成者は、そのまま信じません。 相手方の社内で何人も直していると、作成者が複数になり、作成者の名前が汎用の名前になっていることもあります。自社の担当者の名前の一覧に無い作成者を、すべて相手方として扱います。

4番目を省かないでください。 変更履歴に出ない修正は、この構成でなければ見つけにくいものです。1語でも違いがあれば untracked として挙げ、仕分けの一覧の先頭に置きます。

5番目の定義の扱いは、重い修正を見落とさないためです。 「損害」の定義から「間接損害」を外す修正は、定義の条では1語ですが、責任の条の意味を大きく変えます。

7番目を省くと、条の入れ替えが「条を丸ごと削除し、別の場所に同じ条を挿入した」ように見えます。 AIはそれを2つの重い修正として仕分け、担当者は中身の変わらない条を2回読むことになります。移動の中で文言まで変えている場合は、移動とは別に文言の修正を1つ挙げます。

AIに処理させる

させるのは、修正の1つずつについて、交渉方針の表のどの行に当たるかを示し、4つのどれかに仕分け、反論と代案にはコメント案を付けることです。

いちばん大事なのは、escalate の2つ目の条件です。 表に当たる行が無い修正を、AIが近い行に寄せて accept や counter にすると、誰も決めていない譲歩が回答に入ります。 当たる行が無ければ、AIは判断しません。

counter の代案は、表の文例から作ります。 文例をそのまま使えないときに、修正の文に合わせて語句を直すのはかまいませんが、文例に無い新しい譲歩を足すことは禁じます。 足した場合は new_concession の印を付けさせ、人が必ず見ます。

変更履歴に出ない修正（untracked）も、同じように仕分けます。 ただし、コメント案には「変更履歴の付いていない修正がありました」という事実を相手方に伝える文を必ず入れます。

指示内容を固定する

あなたはSaaS事業者の法務部で、相手方から戻ってきた契約の修正を仕分ける担当者です。
渡された交渉方針の表と契約の条件だけを根拠にしてください。

【修正ごとに答えること】
1. 当たる交渉方針の表の行の番号（当たらなければ none）
2. 仕分け：accept / counter / reject / escalate
3. counter なら代案の文、counter と reject なら相手方へのコメント案
4. 仕分けの理由（方針の表のどの文言に照らしたか）

【厳守事項】
- 方針の表に当たる行が無い修正は、escalate にしてください。
  近い行に寄せて accept や counter にしないでください。
- 譲れない線に触れる修正は、escalate にしてください。
- 受け入れてよい範囲が契約の年額や顧客の区分で変わる行は、
  渡した契約の条件で範囲を決めてください。承認者が要る範囲なら escalate です。
- 代案の文は、方針の表の文例をもとに作ってください。
  文例に無い譲歩（上限の引き上げ、期間の延長、例外の追加など）を足した場合は、
  new_concession を true にしてください。
- 定義の条の修正は、その定義語を使っている条への影響を理由に書いてください。
- untracked の修正には、変更履歴の付いていない修正があったことを
  相手方に伝える一文をコメント案に入れてください。
- 相手方の意図を推測して書かないでください。
- 法令に適合するかどうかの結論を書かないでください。
- コメント案は、相手方の法務担当者に向けた丁寧な文にしてください。
  自社の譲歩の範囲や、承認者の名前をコメント案に書かないでください。
- 前回の回答と仕分けが違う場合は、changed_from_previous を true にしてください。

【契約の条件】{deal_terms}
【交渉方針の表（契約の種類で絞ったもの）】{playbook}
【修正の一覧（条項ごと、前と後の文）】{revisions}
【この顧客との前回の回答】{previous}

「自社の譲歩の範囲をコメント案に書かない」は、見落とされやすい指示です。 理由を丁寧に書かせると、AIは「当社では24か月分までお受けしております」のように、手の内をそのまま相手方への文に書きます。 理由の欄とコメント案の欄を分け、コメント案には書かないよう明記します。

「近い行に寄せない」は2か所に書いています。 1か所だけでは、AIは「近い行」を「当たる行」と読み替えます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、JSON Schema に沿った形で返させます。

{
  "case_id": "",
  "revisions": [
    {
      "revision_id": "",
      "clause_no": "",
      "kind": "tracked | untracked",
      "before": "",
      "after": "",
      "playbook_row": "",
      "decision": "accept | counter | reject | escalate",
      "reason": "",
      "counter_text": "",
      "comment_draft": "",
      "new_concession": false,
      "changed_from_previous": false
    }
  ],
  "format_only_count": 0
}

1つ目の理由は、decision を enum で縛れることです。 構造化出力は enum に対応しているので、「条件付きで受け入れ」のような4つ以外の答えが返りません。 迷ったものは escalate に入ります。

2つ目は、reason と comment_draft を別の欄に分けられることです。 理由は社内向け、コメント案は相手方向けです。同じ欄に書かせると、社内の事情が相手方への文に混ざります。

3つ目は、すべての項目が必ず返ることです。 構造化出力ではすべての項目を必須にし、任意の項目は null との組み合わせの型で表します。playbook_row が空のまま返らず、当たらなければ none と明示されます。 フローはこれを見て、decision が escalate になっているかを確かめます。

フローは返ってきた結果を規則で点検します。 playbook_row が none なのに escalate でないもの、new_concession が true のものは、仕分けを escalate に書き換えてリストに入れます。

システムへ連携する

修正案のファイルには書き込みません。 コメントを Word に書き込むのは担当者です。仕分けの誤りが、そのまま相手方への回答の版に入る経路を作らないためです。

仕分けのリストは、修正ごとに1行にします。 担当者が直した仕分けとコメントは同じ行に残り、次に同じ顧客から修正案が戻ったときの「前回の回答」になります。

人が確認する

法務の担当者は、全件を次の順で見ます。

1. untracked を見る … 変更履歴に出ない修正です。本当に差があるかを、2つの版で確かめます
2. escalate を見る … 上申の要点を整え、法務部長や事業部長に相談します
3. new_concession と changed_from_previous の印が付いたものを見る … 新しい譲歩と、前回と違う返し方です
4. reject と counter を見る … 理由と方針の行が合っているか、コメント案が相手方に出せる文かを見ます
5. accept は一覧で流し見る … 方針の行と前後の文を見て確定します

1番目を先にするのは、見落としたときの影響がいちばん大きいからです。 変更履歴に出ない修正は、相手方も意識していないことがあり、回答で指摘すれば、たいていはそのまま戻してもらえます。

目標は、30件をならして1件50分です。 修正の並べ直しと見落とし探しの時間がなくなり、担当者の時間が escalate と counter に集まることを見込んでいます。

例外に対処する

上から3行目は、交渉の終盤によく起きます。 相手方が「これで最終版です」と変更履歴を消して送ってくる場合です。変更履歴が無いからといって修正が無いとは限らないので、送った版との差を必ず取ります。

記録を残す

• 修正案と送った版のファイルと、それぞれの版の情報
• 取り出した変更履歴の一覧と、変更履歴に出ない差の一覧
• AIに渡した入力の全文と、返ってきたJSONの全文
• 仕分けたときに渡した交渉方針の表の版
• 担当者が直した仕分けとコメント、上申の結果と承認者
• 回答の版を営業に返した日

4つ目を残すのは、交渉方針が後から変わるためです。 譲歩の範囲を見直すと、過去の仕分けの意味が変わります。当時の表が残っていないと、なぜその修正を受け入れたのかを説明できません。