NDAを自社ひな形と比較して差分と論点を出す

処理の起点を決める

NDAファイルのアップロードが起点です。

現状はメール添付で来ているため、専用フォームでの受付に変えることが前提になります。 これは運用変更ですが、レビュー依頼の起点が揃うだけでも管理が楽になります。フォームでは、ファイルに加えて次を入力させます。

• 相手先の社名
• 契約の目的（何の検討のためのNDAか）
• 情報の流れ（自社が開示側／受領側／相互）
• 希望する回答期限

情報の流れを聞くことが重要です。 自社が主に開示する側か受領する側かで、有利な条項が逆になります。これを聞かずにレビューすると、判断の方向が定まりません。

入力データを集める

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

審査基準の構造化が、この構成でもっとも重要な作業です。

自社ひな形をそのまま渡して「違いを教えて」と聞くだけでは、些細な文言の違いまで大量に出てきます。必要なのは「どの差分が問題で、どの差分は許容できるか」の基準です。

{
  "clause_type": "有効期間・存続期間",
  "our_standard": "秘密保持義務の存続期間は契約終了後5年",
  "acceptable_range": {
    "max_years": 5,
    "conditions": "情報の性質により3年まで短縮可"
  },
  "escalation_trigger": "5年を超える、または期間の定めがない",
  "reason": "長期の管理義務は社内の情報管理体制で担保できないため",
  "negotiation_note": "対象情報を限定することで期間の長さを受け入れる余地はある",
  "severity_if_violated": "要交渉"
}

この基準表を、NDAの主要条項（10〜15項目）について作ります。 秘密情報の定義、除外事由、目的外使用の禁止、第三者開示、複製・返還、存続期間、損害賠償、差止め、準拠法・管轄、反社会的勢力の排除などです。

この作業は法務部が行ってください。外注できません。 何を許容し何を許容しないかは、その会社の事業とリスク許容度で決まります。

AIへ渡す前に整形する

1. テキスト抽出 … Word（.docx）は構造ごと読めます。PDFはテキスト抽出、スキャンPDFはOCRが必要です
2. 条文単位への分解 … 「第◯条（見出し）」の単位で分けます。項・号の階層も保ちます
3. 条項タイプの判定 … 各条文が、審査基準のどの条項タイプに該当するかを判定します。条文の見出しだけでは判定できないことがあるため、本文の内容も見ます
4. 自社ひな形の対応条項の特定 … 条項タイプで対応づけます

AIに処理させる

指示内容を固定する

あなたは法務担当者を補佐する担当者です。
以下の先方提示のNDAについて、自社ひな形および審査基準との差分を抽出してください。

【厳守事項】
- 契約を締結してよいか、法的に問題があるかの判断をしないでください。
- 「問題ありません」「妥当です」といった評価を書かないでください。
- 差分の指摘には、必ず審査基準のどの項目に基づくかを記載してください。
  審査基準に定めのない事柄を、一般的な法律知識で指摘しないでください。
- 法令の条文、判例、法解釈に言及しないでください。
- 先方案の条文を引用する際は、原文のまま引用してください。要約しないでください。
- 該当する条項が先方案に存在しない場合、
  missing_clauses に記載してください。
  （例：自社ひな形にある「反社会的勢力の排除」条項がない）
- 自社が {information_flow} の立場であることを踏まえて、
  差分の影響を記載してください。
- 重要度は、審査基準の severity_if_violated の値をそのまま使ってください。
  独自に判断しないでください。

【案件情報】
相手先: {counterparty} / 契約目的: {purpose}
情報の流れ: {information_flow}（自社が開示側 / 受領側 / 相互）

【自社ひな形（条文単位）】
{our_template}

【審査基準】
{review_criteria}

【この相手先との過去の合意内容】
{past_agreements}

【先方提示のNDA（条文単位）】
{counterparty_draft}

「法令の条文、判例、法解釈に言及しない」の制約は、意図的なものです。 理由は2つあります。

1. 正確性の問題 … LLMは存在しない判例や条文番号を生成することがあります。法務担当者がそれを信じると、誤った前提で交渉することになります
2. 役割の線引き … このツールは「自社の審査基準と照らす」道具です。法的判断は法務担当者と、必要に応じて顧問弁護士が行います。AIに法解釈をさせない設計にすることで、§13に書く弁護士法上の論点を避けられます

「審査基準に定めのない事柄を一般知識で指摘しない」も同じ理由です。基準にない指摘が出ると、法務担当者はそれを検証しなければならず、かえって時間がかかります。

出力形式を固定する

{
  "counterparty": "",
  "clause_mapping": [
    {
      "counterparty_clause": "第6条（有効期間）",
      "clause_type": "有効期間・存続期間",
      "our_clause": "第8条",
      "mapping_confidence": "high | medium | low"
    }
  ],
  "differences": [
    {
      "clause_type": "",
      "counterparty_text": "",
      "our_standard": "",
      "difference": "",
      "impact_note": "",
      "criteria_ref": "",
      "severity": "要交渉 | 要確認 | 許容範囲",
      "suggested_revision": ""
    }
  ],
  "missing_clauses": [],
  "unmapped_clauses": [],
  "past_agreement_note": ""
}

• unmapped_clauses … 自社ひな形にも審査基準にもない、先方独自の条項。ここは必ず人が読みます。 想定外の条項が入っているのは、最も注意が必要な箇所です
• criteria_ref … 審査基準のどの項目に基づく指摘か。これがない指摘は無効とします

システムへ連携する

法務担当向け： レビュー結果を、重要度別に並べた画面またはスプレッドシートで表示します。先方の条文原文と自社基準を左右に並べます。

修正案： suggested_revision をもとに、Wordの変更履歴付きファイルを生成する構成も可能ですが、まずは文言の提示までにとどめることを勧めます。 変更履歴の自動生成は実装が重く、法務担当者は結局自分で書き直すことが多いためです。

営業部門向け： 法務担当が確認した後、「この条項の修正を先方に依頼してください」という形で返します。AIの出力をそのまま営業部門に渡さないでください。 法務のレビューを経ていない指摘が先方に伝わると、交渉が混乱します。

人が確認する

全件、法務担当者が確認します。 段階的な自動化もしません。

理由は、契約が法的な権利義務を生じさせる文書だからです。この構成で減らしているのは「条文を探して比べる時間」であって、「法的判断の責任」ではありません。

特に次の2つは、必ず人が読みます。

1. unmapped_clauses … 想定外の条項。AIは審査基準に基づいて判断するため、基準にない条項の危険性を評価できません
2. mapping_confidence が low の対応づけ … 対応づけを誤ると、比較そのものが無意味になります

例外に対処する

記録を残す

• 先方提示のNDA原本
• AIの抽出結果
• 法務担当者の判断と修正案
• AIの指摘のうち、採用したもの・却下したもの

最後が改善材料です。「特定の条項タイプで毎回過剰な指摘が出る」と分かれば、審査基準の記述を調整できます。

また、合意した内容を相手先ごとに蓄積します。次回、同じ相手先とのNDAレビューで参照できます。