重要事項説明書の記載を、登記事項証明書と売買契約書案に突き合わせて食い違いを出す

処理の起点を決める

営業が点検用のライブラリの「状態」の列を「点検依頼」に変えたことを起点にします。 Power Automate の SharePoint のトリガー「ファイルが作成または変更されたとき (プロパティのみ)」で変更を受け、最初の条件で状態が「点検依頼」のときだけ先に進めます。

ファイルを置いたことではなく、状態を変えたことを起点にするのは、3つの書類がそろうまで待つためです。 登記事項証明書が先に届き、契約書案が翌日にできることはよくあります。1つ置くたびに動かすと、そのたびに「契約書案が無い」という結果が出ます。

同じ案件で状態の変更が続けて起きても、二重に動かさないよう、流れの最初で状態を「点検中」に変えます。終わったら「点検結果あり」にし、営業が直して再び「点検依頼」にすると2回目が動きます。

入力データを集める

登記事項証明書の構成は法務省の説明どおりに扱います。 登記記録は1筆の土地または1個の建物ごとに表題部と権利部に分かれ、権利部はさらに甲区と乙区に分かれます。表題部には土地なら所在・地番・地目・地積、建物なら所在・地番・家屋番号・種類・構造・床面積などが、甲区には所有者に関する事項が、乙区には抵当権など所有権以外の権利に関する事項が記録されます。

物件の種別と筆の数を必ず持たせます。 土地が3筆に分かれている案件で証明書が2枚しか置かれていなければ、読み取る前に「証明書が足りない」と返せます。

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

1. トリガーから案件のフォルダを特定し、「ファイル コンテンツの取得」で3種類の書類を取り出す
2. 登記事項証明書のPDFを、レイアウトモデルに keyValuePairs を付けて送る
3. 重要事項説明書と契約書案は、Word ならそのままレイアウトモデルに送る（アドオンは付けない）
4. 返ってきた本文と表から、次の単位に切り出す

切り出しは見出しの文字列で行います。 作成ソフトの様式が決まっていれば、「登記記録に記録された事項」「契約の解除に関する事項」「損害賠償額の予定又は違約金に関する事項」といった見出しは毎回同じ位置に出ます。見出しが見つからない書類は、切り出さずに needs_review にします。

AIへ渡す前に整形する

1. 書類の数の確認 … 物件の種別と筆の数に対して、証明書の枚数が足りているかを確かめます
2. 証明書の日付の確認 … 証明の日付を取り出し、自社の決めた日数より古ければ取り直しの印を付けます
3. 現在の権利と抹消された権利の区別 … 証明書には、すでに抹消された権利の記録が並んでいることがあります。抹消の記録が読み取れた順位番号には印を付け、区別がつかないものは needs_review に回します
4. 表記の正規化 … 対応表にある表記を、比べるときだけそろえます。元の表記は残します
5. 数字の正規化 … 地積・床面積・金額を数値に直した列を別に作ります。比べるのは数値、点検表に載せるのは元の表記です
6. 個人の情報の範囲の確認 … 甲区に過去の所有者の氏名・住所が並ぶ場合、比べるのに要るのは最新の所有者だけなので、それ以外は判定に渡しません

3番目がいちばん気をつける前処理です。 抹消された抵当権を今も生きている権利として数えると、重要事項説明書に正しく書かれていない権利がある、という誤った漏れが出ます。逆に、生きている権利を抹消済みと取り違えると、本物の漏れを見逃します。機械で決めきれないものは、人に回す側へ倒します。

AIに処理させる

させるのは、7つの観点それぞれで、書類どうしが合っているかの判定だけです。

③の missing_in_disclosure が、この構成でいちばん大事な値です。 重要事項説明書に書いてあることの誤りは mismatch、書いていないことの漏れは missing_in_disclosure と分けます。点検表では後者を必ず先頭に出します。

④から⑦の観点は、宅地建物取引業法第35条の説明事項に対応させています。 条文では、代金・交換差金・借賃以外に授受される金銭、契約の解除に関する事項、損害賠償額の予定又は違約金に関する事項、代金に関する金銭の貸借のあっせんの内容とそれが成立しないときの措置が挙げられています。これらは契約書案にも書かれるので、2つの書類で食い違いが起きやすい項目です。

4行目を明記しないと、AIは「重要事項説明書を登記に合わせて修正してください」と書きます。 登記が古い、契約書案が新しい、という場合もあります。どちらを直すかを決めるのは営業と担当者です。

指示内容を固定する

あなたは不動産会社の契約管理の担当で、売買の重要事項説明書の案を点検します。
重要事項説明書の内容が法令上足りているかは判断しません。
3つの書類のあいだで、同じ事実が同じように書かれているかだけを判定してください。

【観点】
1. 物件の表示（登記の表題部と、重要事項説明書の物件の表示）
2. 所有者（登記の甲区の最新の所有者、重要事項説明書の登記名義人、契約書案の売主）
3. 乙区の権利（登記の乙区の生きている権利と、重要事項説明書の所有権以外の権利の欄）
4. 手付金・手付解除  5. 違約金  6. ローン特約  7. 代金以外の金銭
   （4〜7は重要事項説明書と契約書案）

【status の選び方】
- match ................. 一致している
- mismatch .............. 書かれているが、内容が違う
- explainable ........... 違うが、表記の対応表にある違いだけである
- missing_in_disclosure . 登記または契約書案にあるのに、重要事項説明書に書かれていない
- unreadable ............ 読み取り結果が欠けている、または抹消済みかどうか区別できない
迷ったときに match を選ばないでください。

【厳守事項】
- 乙区の権利は、印の付いた抹消済みの順位番号を除いて、1本ずつ判定してください。
  重要事項説明書に「抵当権あり」とまとめて書かれていても、本数と権利者が合わなければ mismatch です。
- 重要事項説明書に抹消の予定が書かれていても、権利そのものの記載が無ければ missing_in_disclosure です。
- 所有者と売主が違う場合、理由を推測しないでください。mismatch とし、違いだけを書いてください。
- 金額・面積・日付は、【数値の列】の値で比べてください。自分で計算しないでください。
- どちらの書類が正しいか、どちらを直すべきかを書かないでください。
- 法令上の適否、説明の十分さ、抹消の見込みを書かないでください。
- evidence には、各書類の該当部分の文字列をそのまま写してください。

【登記事項証明書（表題部・甲区・乙区。抹消済みの印つき）】{registry}
【重要事項説明書の該当欄】{disclosure}
【売買契約書案の取引条件】{contract}
【数値の列】{normalized_numbers}
【表記の対応表】{variant_table}
【物件の種別】{property_type}

「まとめて書かれていても本数と権利者が合わなければ mismatch」が効きます。 重要事項説明書には「抵当権設定あり（決済時抹消予定）」と1行で書かれることがあり、乙区に抵当権が2本、権利者が別々にあっても、1行の記載で済んだように見えます。

「どちらを直すべきかを書かない」も同じくらい大事です。 書かせると、担当者は登記に合わせる直し方をそのまま営業に返しがちです。

出力形式を固定する

次の形のJSONで受け取ります。 response_format に json_schema と strict: true を設定します。

{
  "case_no": "",
  "certificate_date": "",
  "checks": [
    { "aspect": "encumbrance", "item": "乙区 順位番号2 抵当権",
      "status": "match | mismatch | explainable | missing_in_disclosure | unreadable",
      "registry_value": "", "disclosure_value": "", "contract_value": "",
      "evidence": "", "note": null }
  ]
}

aspect は property_display ／ owner ／ encumbrance ／ deposit ／ penalty ／ loan_contingency ／ other_money の7つです。

1つ目の理由は、項目の数が案件ごとに違っても同じ形で受け取れることです。 乙区の権利が0本の物件も5本の物件もあり、checks の要素の数が変わります。公式には、配列の minItems と maxItems はサポートされないとされているので、件数の確かめは Power Automate の側で行います。乙区の生きている権利の数と、encumbrance の要素の数が合わなければ needs_review にします。

2つ目の理由は、すべての項目が必ず返ってくることです。 公式には、構造化出力ではすべてのフィールドを必須にする必要があり、省略できる項目は null との共用型で表すとされています。note を ["string", "null"] にしておけば、書くことが無いときは null が入り、欄そのものが消えることはありません。 あわせて、スキーマのオブジェクトには additionalProperties: false が必要で、オブジェクトのプロパティは最大100個、入れ子は5段までとされています。この形はその範囲に収まります。

3つ目は、判定と扱いを分けられることです。 verdict はスキーマに入れず、Power Automate の条件で決めます。

システムへ連携する

点検表は1項目1行のリストにします。 案件番号・観点・項目・状態・3つの書類の値・根拠・担当者の確認の列を持たせます。2回目の点検では、前回の行と比べて状態が変わった行と、fix_required のまま変わっていない行を先に出します。

重要事項説明書と契約書案は書き換えません。 直すのは営業で、作成ソフトの側で直します。AIの出力をそのまま書類に反映する経路は作りません。

人が確認する

1. missing_in_disclosure を先に見る … 証明書の乙区の該当の順位番号を原本で確かめ、本当に生きている権利かを見ます
2. mismatch を確かめる … 3つの書類の値を並べ、どちらを直すかを営業と決めます
3. unreadable と件数の不一致を見る … 証明書の読み取りが欠けていれば、原本で読みます
4. explainable を流し見る … 表記の違いだけかを確かめます
5. 判定を覆したら記録する … どの項目を、どの状態からどれに変えたか

1番目を省かないでください。 漏れと出たものの多くは本物の漏れか、抹消済みの権利の取り違えのどちらかです。どちらなのかは、証明書の原本を見ないと決まりません。

点検の最後は宅地建物取引士が見ます。 この構成の点検表は、宅地建物取引士が説明の前に書類を見直すときの材料です。記名する宅地建物取引士の確認を省く設計にはしません。

目標は、80件をならして1件12分です。 乙区の権利の少ない土地の案件は点検表を流し見て数分、権利の多い区分マンションや漏れの出た案件は原本を確かめるので長くかかります。

例外に対処する

上から4行目までは、書類の受け渡しの問題です。 証明書をいつ取るか、どの様式で重要事項説明書を出すかを営業と決めておけば、多くは起きません。

記録を残す

• 点検に使った3つの書類の版（SharePoint のバージョン）
• 読み取りの結果のJSONと、切り出した単位
• Azure OpenAI に渡した内容と、返ってきた checks の全文
• 点検表の各行と、そのときの判定の条件と表記の対応表の版
• 人が判定を覆した記録と、営業へ返した内容
• 2回目以降の点検で、前回から変わった行

1つ目で書類の版を残すのは、どの案を点検したかを後から示すためです。 説明の後で記載の誤りが見つかったとき、点検した時点の案に誤りがあったのか、点検の後に書き換えられたのかが分かります。