契約審査で、同じ条項を過去にどう修正したかを審査記録から根拠付きで引く

処理の起点を決める

担当者が条文または論点を入力したときを起点にします。

自動で走らせないでください。 契約書を受け取るたびに全条項を自動で検索すると、担当者が契約書を読む前に結果が出ます。 まず自分で読んで論点を見つけることが、この業務の出発点です。

入力の形は2通り用意してください。

1つ目が実務ではよく使われます。 相手方から届いた条文を貼れば、似た条文を過去にどう直したかが出ます。

2つ目も必要です。 自社から提案する条項を考えるとき、過去にどういう書き方をして通ったかを探したくなります。

もう1つの起点として、交渉中の確認があります。 相手方から「前回はこの条件で」と言われたとき、その場で確かめられる形にしてください。 スマートフォンからも引ける窓口があると、交渉の場で使えます。

締結後の記録の追加も、トリガーとして設計してください。 契約が締結されたら、今回の審査記録を検索の対象に足します。この蓄積がないと、索引が古くなります。

入力データを集める

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

条項の分類が、この構成の質を決めます。 「損害賠償」だけでは粗すぎます。次の粒度で分けてください。

小区分まで分けることが重要です。 「責任・賠償」で引くと2,800件中1,500件が当たります。「賠償の上限」で絞れば、200件程度に落ちます。

この分類は、過去の記録に後から付けることになります。 2,800件すべてに人が付けるのは現実的ではありません。生成AIに下書きさせて、人が確かめる形にしてください。条項単位で見れば、1件あたり数十秒で済みます。

「決着の内容」を、必ず属性として持ってください。

「決着」と「相手方の立場」の組み合わせが、この構成でもっとも価値のある情報です。 「賠償の上限について、仕入先に対しては要求が通った事例が18件、販売先に対しては取り下げた事例が12件」と分かれば、方針の判断が変わります。

「要求の理由」も必ず記録してください。 同じ修正を求めた理由が、「自社のひな形に合わせるため」と「この取引の特性上必要だから」では、譲る余地が違います。

ひな形の条文も索引に入れてください。 「自社のひな形ではどう書いているか」を引けると、審査の基準がそろいます。

AIへ渡す前に整形する

1. 契約書の条項への分割 … 条番号と見出しで分けます。別紙や付属文書も対象にします
2. 原案と最終版の対応づけ … 同じ条項の、修正前と修正後を対応させます。条番号がずれることがあるため、内容からも対応づけます
3. 審査のコメントの紐づけ … コメントがどの条項についてのものかを対応させます
4. 条項の分類の付与 … 小区分を判定します。生成AIの下書きを人が確かめます
5. 決着の判定 … 原案と最終版を比べて、要求が通ったかを判定します
6. 属性の付与 … 契約の種類、相手方の立場、金額の規模
7. 索引への取り込み … キーワード検索用のフィールドと、k-NN ベクトルフィールドの両方を作ります
8. 秘匿の確認 … 相手方の名称、金額、特定の取引の内容を、検索の結果に出すかを決めます

2の対応づけが、この構成でいちばん手間のかかる部分です。 原案と最終版の条文を並べないと、「どう直したか」が分かりません。 変更履歴が残っているファイルがあれば、そこから取れます。

8の秘匿の確認は、法務の用途では必須です。 過去の契約の相手方名や金額を、誰でも見られる状態にしないでください。条文と論点だけを見せて、相手方名は権限のある人にだけ見せる設計も可能です。

AIに処理させる

2つの工程に分けます。

（1）検索基盤にさせること

（2）Claude API にさせること

修正案を書かせません。 「次のように修正してください」といった条文案を出させないでください。

法律上の判断もさせません。 「この条項は公序良俗に反します」「消費者契約法により無効です」といった記述を禁じてください。法律の解釈は弁護士と法務の担当が行います。

リスクの大きさの評価もさせません。 「この条項のリスクは高い」といった判断は、取引の内容と金額を踏まえて人が行います。

過去の判断の評価もさせません。 「この修正の要求は妥当でした」といった記述は不要です。決着という事実を示せば足ります。

指示内容を固定する

あなたは法務部で契約審査を支援する担当者です。
審査中の条項について、過去の似た条項と、そのときの修正・決着を
探して並べることが役割です。

【厳守事項】
- 修正案を書かないでください。
  「次のように修正してください」という条文案を出さないでください。
  どう直すかは担当者と事業部門が判断します。
- 法律上の判断をしないでください。
  「この条項は無効です」「法令に違反します」「公序良俗に反します」
  と書かないでください。
  **法律の解釈は弁護士と法務の担当が行います。**
- リスクの大きさを評価しないでください。
  「この条項のリスクは高い」「重大な問題があります」と書かないでください。
- 過去の判断を評価しないでください。
  「この要求は妥当でした」「譲りすぎです」と書かないでください。
  決着という事実を示すだけにしてください。
- 検索の結果に含まれていない事例を作らないでください。
  該当が見つからない場合は「該当する事例が見つかりません」と返してください。
- 事例ごとに、必ず契約IDと、元の審査記録の該当箇所を示してください。
  示せない事例は出さないでください。
- 「似ている点」と「違う点」を必ず両方書いてください。
  特に、相手方の立場（仕入先／販売先など）が違う場合は必ず明記してください。
  **立場が逆だと、譲る線もまったく変わります。**
- 契約の種類が違う事例を排除しないでください。
  条項の論点が同じなら、種類が違っても参考になります。
  ただし、違うことは明記してください。
- 決着（要求どおり／一部受け入れ／取り下げ／相手方の案のまま）を必ず併記してください。
- 並べ替えは、論点の一致の度合いで行ってください。
  要求が通った事例を上に並べないでください。
  **通った事例だけを見せると、判断が偏ります。**
- 相手方の名称と金額は、検索の結果には含めないでください。
  必要な場合は、担当者が元の記録を開いて確かめます。

【審査中の条項】
{clause_text}

【この条項の分類（AIが判定した小区分）】
{clause_category}

【検索で見つかった過去の条項（条文 / 修正の要求 / 決着 / 属性）】
{search_results}

【自社のひな形の該当する条項】
{template_clause}

【今回の契約の属性（種類 / 相手方の立場 / 金額の規模）】
{contract_context}

「相手方の立場の違いを必ず明記する」の指示が、この構成で特に重要です。 同じ「賠償の上限」でも、自社が委託する側か、受託する側かで、求める方向が逆になります。 立場を見落とすと、逆の事例を参考にしてしまいます。

「通った事例だけを見せない」の指示も外せません。 要求が通った事例だけを上に並べると、「この要求は通るものだ」という誤った印象を与えます。 実際には取り下げた事例のほうが多いかもしれません。

「相手方の名称と金額を検索の結果に含めない」の指示は、秘匿の観点です。 条文と論点を見るだけなら、相手方が誰かは要りません。必要なときだけ、権限のある担当者が元の記録を開きます。

「法律上の判断をしない」の指示については、具体例を書いておくことが有効です。 「無効」「違反」「公序良俗」といった語を禁止語として挙げてください。抽象的に禁じるだけでは、モデルは境界を誤ります。

出力形式を固定する

{
  "query_id": "",
  "input_type": "clause_text | issue_description",
  "detected_category": {
    "major": "",
    "minor": "",
    "confidence": "high | low"
  },
  "issues": [
    { "point": "", "why_unfavorable": "" }
  ],
  "precedents": [
    {
      "contract_id": "",
      "contract_type": "",
      "counterparty_role": "supplier | customer | contractor | client | other",
      "amount_band": "",
      "year": "",
      "original_clause_summary": "",
      "our_request": "",
      "request_reason": "",
      "outcome": "as_requested | partially_accepted | withdrawn | as_is",
      "final_clause_summary": "",
      "negotiation_rounds": 0,
      "similar_points": [],
      "different_points": [],
      "role_matches_current": true,
      "source": { "document": "", "location": "" },
      "similarity": "high | medium | low"
    }
  ],
  "template_clause_present": false,
  "no_match_reason": "",
  "counts_by_outcome": { "as_requested": 0, "partially_accepted": 0, "withdrawn": 0, "as_is": 0 },
  "counts_by_role": {}
}

Claude API で出力をスキーマに沿わせるには、output_config の format に json_schema を指定します。 古い output_format は非推奨で、output_config.format に置き換わりました。

スキーマには制約があります。 enum は文字列・数値・真偽値・null に限られ、const と anyOf / allOf（allOf と $ref の組み合わせは不可）が使えます。$ref / $def / definitions は使えますが、外部の $ref は使えません。 一方、再帰的なスキーマ、数値の minimum / maximum / multipleOf、文字列の minLength / maxLength / pattern、条件付きの if / then / else は使えません。 minItems は0と1のみです。

オブジェクトには additionalProperties: false を設定する必要があります。

counts_by_outcome と counts_by_role が、実は最も見られる部分になります。 「この論点で過去32件、うち要求どおり8件・一部受け入れ14件・取り下げ10件。仕入先に対しては通りやすく、販売先には通りにくい」という分布が、方針の判断に直接効きます。

role_matches_current のフラグが要ります。 相手方の立場が今回と同じかどうかを、一目で分かる形にしてください。 立場が逆の事例を参考にすると、判断を誤ります。

request_reason を持たせている理由があります。 同じ修正を求めた理由が「ひな形に合わせるため」なのか「この取引特有の事情」なのかで、今回に当てはまるかが変わります。

template_clause_present は、自社のひな形に該当する条項があるかです。 ひな形があるなら、まずそれと比べるのが筋です。

システムへ連携する

検索の結果を一覧として出すだけで、他のシステムへの書き込みは行いません。

契約管理システムへ書き戻さないでください。 契約の管理情報に検索の結果が混ざると、後から何が正式な記録か分からなくなります。

事業部門へ自動で送らないでください。 過去の事例には、他の取引の交渉の経緯が含まれます。事業部門が見てよい範囲を、法務が判断してから渡してください。

相手方へは一切出さないでください。 「過去にこういう事例があります」という情報は、自社の交渉の手の内を明かすことになります。

記録への追加は、締結後に人が行ってください。 決着の内容と交渉の経緯を、索引の対象へ足します。自動で追加する形にすると、決着の判定が誤ったまま蓄積されます。

人が確認する

担当者が、事例を読んで判断します。

確認を速くするための設計が効きます。

• counts_by_outcome を一覧の先頭に置く
• role_matches_current を色で分ける
• 元の審査記録の該当箇所へ直接開けるリンクを付ける
• 同じ相手方との過去の契約に印を付ける
• 時期が新しい事例に印を付ける（法改正の影響）

4つ目が、相手方の主張を確かめる場面で効きます。 「前回はこの条件で」と言われたとき、同じ相手方との過去の契約を即座に引けます。

5つ目も重要です。 民法の改正など、条項の書き方に影響する変更があります。古い事例をそのまま参考にすると、現在の規定と合わない条文になります。

最終的な方針は担当者が決めます。 過去に32件中8件しか通らなかった要求でも、今回の取引では通すべきかもしれません。 取引の重要度と力関係を踏まえた判断が要ります。

例外に対処する

「事業部門が直接検索する」は、必ず制限してください。 過去の審査記録には、他の取引の交渉の経緯が含まれます。事業部門が自由に見られる状態にすると、取引先ごとの条件が社内で広く知られることになります。

記録を残す

この記録は、条項の分類と検索の精度を育てる材料になります。

• 検索の入力（貼った条文、書いた論点）
• 判定した条項の分類
• 返した事例と、その similarity
• 担当者が実際に採用した事例
• 採用しなかった事例と、その理由
• 今回決めた方針と、その後の決着

「担当者が実際に採用した事例」を必ず記録してください。 上位に出した事例が使われているかが、検索の精度を測る指標です。

「採用しなかった理由」も記録してください。 「相手方の立場が逆」「時期が古すぎる」といった理由が集まれば、different_points に書かせるべき観点や、絞り込みの条件が分かります。

審査記録には、取引先の名称、契約の金額、交渉の経緯が含まれます。 これらは秘密保持義務の対象になりえます。外部のAIサービスへ渡す範囲を、法務部として決めてください。

検索の結果に相手方の名称と金額を含めない設計を、初めから入れてください。 条文と論点だけで検索の目的は果たせます。必要なときだけ、権限のある担当者が元の記録を開きます。

保存期間は、契約書の保存期間に合わせるのが自然です。 契約に関する紛争は、締結から長い時間が経ってから起きることがあります。