賃貸借契約書と重要事項説明書の特約欄を、自社の例文集と消費者契約法で無効になりやすい書き方に照らして校正し、契約前に直しの案を担当へ返す

処理の起点を決める

営業担当が社内の画面で「特約チェック」を押したときに動かします。 画面は案件番号を入れてボタンを押すだけのもので、Azure Functions を HTTP で呼びます。

フォルダへの保存を起点にしない理由は、営業担当が特約を書き足している途中のファイルも保存されるからです。 書きかけの契約書に指摘を返すと、通知が増えるだけで誰も読まなくなります。「書き終えた」という意思表示を、ボタンで受けます。

直したあとにもう一度押せば、同じ案件の2回目として動きます。2回目は前回の指摘が直ったかも返します。 契約課は差分だけを見れば足ります。

入力データを集める

質を決めるのは、例文集の「必ず入れる要素」の列です。 クリーニングの特約なら「金額」と「消費税の内外」、通常損耗の負担なら「負担する範囲の具体的な列挙」と「単価」。この列があると、AIは「例文と言い回しが違う」ではなく「必ず入れる要素の金額が無い」と指摘できます。

注意の型の一覧は、法令の条文そのものではありません。 契約課が過去に直した書き方を、法務と顧問弁護士が型にまとめたものです。条文を渡して「無効かどうか判断して」と頼むと、AIが法的な判断をしてしまいます。型を渡して「どの型に近いか」を聞くのが、この構成の線引きです。

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

特約欄の取り出しは、見出しの文字で行います。 賃貸管理システムの雛形は見出しが決まっているので、「特約事項」から次の見出しまでを取れば足ります。見出しが見つからないものは、雛形を崩した契約書なので、AIに渡さず人へ回します。

例文集と注意の型には版の番号を付けます。 例文集を直した日以降の判定と、それより前の判定を区別できないと、同じ特約に違う指摘が出た理由が追えなくなります。

AIへ渡す前に整形する

1. 特約欄の取り出し … 契約書と重説のそれぞれから、特約欄の本文だけを取り出します
2. 条ごとの分割 … 「1.」「（1）」「第1条」などの番号で分けます。番号が無い段落は1段落を1条とします
3. 契約書と重説の対応付け … 条番号と本文の近さで、同じ特約どうしを組にします。片方にしか無い条は「片側のみ」と印を付けます
4. 差分の算出 … 組になった条どうしの文字の差分を出します。ここは AI ではなく文字列の比較で行います
5. 数値の抜き出し … 金額、率（％）、日数、か月数を拾い、条ごとに一覧にします
6. 数値の規則による確認 … 支払の遅れに対する損害金の率が、年14.6％を超えていないかを計算で見ます
7. 例文の候補の取り出し … 条ごとに、例文集の題目と本文の近さで候補を3本まで選びます
8. 個人情報の伏せ字 … 特約に入居者の氏名や電話番号が書かれていれば、伏せてから渡します

4番目と6番目を AI にさせないのは、計算と文字の比較は規則のほうが確実だからです。 消費者契約法の第9条第1項第2号は、支払の遅れに対する損害賠償の予定や違約金が、支払うべき額に年14.6％の割合を掛けた額を超える部分を無効としています。率が書かれていれば、比べるのは数の大小だけです。

AIに処理させる

させるのは、条ごとに「例文集との違い」「注意の型への当てはまり」「表記の乱れ」を指摘し、例文集に沿った直しの案を出すことです。

注意の型は、たとえば次のようなものです。 いずれも法令の条文や国の資料に出てくる考え方を、契約課の言葉で書き直したものです。

右の列の結論をAIに出させるのではありません。 「違約金の重さ」の型に当たっても、平均的な損害の額がいくらかはAIには分かりません。型に当たったという事実と原文の引用を返させ、重いかどうかは人が見ます。

4行目がいちばん起きやすい失敗です。 「より良い書き方」を頼むと、例文集に無いもっともらしい文を作ります。法務が一度も見ていない文が契約書に入ることになるので、直しの案は例文集の文言に限ります。

指示内容を固定する

あなたは賃貸住宅の管理会社の契約課で、契約書の特約欄を校正する担当です。
渡された特約を1条ずつ見て、指摘と直しの案を返してください。

【やること】
1. 各条について、例文の候補から最も近い例文を1つ選び、その番号を書く。
   近いものが無ければ template_id を "none" にする。
2. 選んだ例文の「必ず入れる要素」のうち、この条に書かれていないものを
   missing_elements に挙げる。
3. 注意の型の一覧のうち、この条に当てはまりそうな型の番号を caution_types に挙げる。
   当てはまる根拠の文を、特約の原文からそのまま quote に写す。
4. 表記の決まりに反する箇所を notation に挙げる。
5. 指摘がある条には、選んだ例文の文言をもとに直しの案を書く。
   金額・日数など会社や物件で決める値は「○」のまま空けておく。

【厳守事項】
- 特約が有効か無効か、法律に違反するかを書かないでください。
  「無効です」「違法です」「問題ありません」という言葉を使わないでください。
- 金額・率・日数が妥当かどうかを判断しないでください。
- quote は原文の文字を1字も変えずに写してください。要約や言い換えをしないでください。
- 直しの案は、例文集の文言から作ってください。例文集に無い文を新しく作らないでください。
- 貸主の条件そのもの（ペット不可、更新料の有無など）を削る案を出さないでください。
- 原文に書かれていないことを推測で補わないでください。読み取れない場合は「不明」とし、
  needs_human を true にしてください。
- 迷ったときは caution_types に挙げてください。挙げずに済ませないでください。

【案件の属性】{case_attributes}
【特約（契約書）】{clauses_contract}
【特約（重要事項説明書）との差分】{diff_result}
【数値の規則による確認の結果】{numeric_checks}
【例文の候補】{template_candidates}
【注意の型の一覧】{caution_list}
【表記の決まり】{notation_rules}

「無効です」という言葉を名指しで禁じないと、出てきます。 第8条や第10条の考え方を一覧で渡しているので、AIは自然に結論まで書こうとします。結論の言葉を禁じ、型の番号と引用だけを返させます。

「迷ったら挙げる」を最後に置くのは、見落としのほうが重いからです。 余計な指摘は契約課が1つ消せば終わりますが、挙がらなかった特約は誰の目にも止まりません。

出力形式を固定する

次の形の JSON を、構造化出力で受け取ります。

{
  "case_id": "",
  "clauses": [
    {
      "clause_no": "3",
      "template_id": "T-21 | none",
      "missing_elements": ["金額", "消費税の内外"],
      "caution_types": ["C-06"],
      "quote": "",
      "notation": [{ "issue": "", "quote": "" }],
      "rewrite": "",
      "needs_human": false
    }
  ],
  "contract_only": [],
  "disclosure_only": []
}

構造化出力を使う理由は、後段で規則を当てるためです。 caution_types が番号で返るので、「C-01 と C-03 は法務へ、それ以外は直しの依頼」という振り分けを Functions の側で書けます。公式の説明では、スキーマのすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があるとされています。項目を省略したい場合も、空の配列か空文字で返させます。

判定は Functions が次の規則で決めます。

quote の照合は必ず行います。 原文に無い引用が返ったら、その条の指摘はAIの思い込みかもしれません。照合に落ちた指摘は消さず、「引用不一致」の印を付けて人に見せます。

システムへ連携する

Word の契約書そのものには書き込みません。 指摘をコメントとして自動で差し込む作りもできますが、営業担当が直す前に誰の判断を経た指摘なのかが分からなくなります。 指摘は SharePoint のリストに置き、契約課が確かめたものだけを営業担当へ送ります。

人が確認する

契約課の担当が開くのは fix_suggested と legal_review の案件です。 clean の案件は一覧で物件名と特約の条数を流し見ます。

1. legal_review を先に見る … 型と引用を読み、法務担当へ回すかを決めます。回すときは、引用と案件の属性を添えます
2. fix_suggested の指摘を確かめる … 引用の箇所を原文で見て、指摘が当たっているかを判断します
3. 直しの案を採るかを決める … 例文集の文言に寄せるか、貸主の意向で今の文を残すかを決めます
4. 営業担当へ返す … 採った指摘だけを Teams で送ります
5. 指摘を退けたら理由を残す … 「貸主の指定」「法務の確認済み」など、選択肢から選びます

3番目は、AIに決めさせません。 例文集と違っても、貸主と合意済みで法務も確認した特約はあります。その記録が残っていれば、次の案件で同じ指摘を何度も退けずに済みます。

目標は、240件をならして1件5分です。 指摘のある案件が半分程度という想定で、それを大きく超える月は、例文集が古くなっているか、特定の店舗の書き方が崩れています。

例外に対処する

5行目は設計の最初に入れておきます。 借主が法人で事業用の物件なら、消費者契約法の考え方を当てる前提がありません。同じ注意の型を当てると、指摘が増えるだけで誰も読まなくなります。

記録を残す

• 校正にかけた契約書と重説の版（ファイルの版の番号と日時）
• 取り出した特約欄の本文と、条ごとの分割の結果
• 契約書と重説の差分、数値の規則による確認の結果
• Azure OpenAI に渡したプロンプトと、返った JSON の全文
• 使った例文集と注意の型の一覧の版の番号
• 判定、契約課の採否、退けた理由、法務の回答
• 営業担当が直したあとの2回目の判定

例文集の版を残すのは、例文集が直るからです。 版が分からないと、半年前の判定が今の例文集と食い違っているときに、どちらを信じればよいかが決まりません。

退けた理由の記録は、例文集を直す材料になります。 同じ例文に対して「貸主の指定」で退ける指摘が続くなら、例文集のほうに貸主ごとの変形を足す時期です。