火災保険の見積で受け取る建築確認済証・登記事項証明書の写しを読み取り、構造・建築年・床面積を見積入力の項目にそろえて、構造級別の候補と確かめる点を出す

処理の起点を決める

受付フォルダ（Cloud Storage）に書類が保存されたことを起点にします。 Cloud Run では、Eventarc を通じて、オブジェクトが作成・上書きされたとき（google.cloud.storage.object.v1.finalized）に関数を呼び出せます。

保存は、顧客ごとのフォルダ（見積の依頼番号）に、届いた順に入れます。1件の見積に、確認済証の写真が数枚、登記事項証明書のPDFが1つ、のように複数のファイルが届くので、依頼番号のフォルダの単位でまとめて処理します。

ファイルが届くたびに、その依頼番号の全書類を読み直します。 確認済証だけで「候補を決めるのに足りない」と出た後に、申請書の副本が届けば、同じ依頼の結果が更新され、印が消えます。 1件の見積が数日に分けて届くのは珍しくありません。

入力データを集める

質を決めるのは、下の2つです。 構造級別の規則が無ければ候補が出ません。値の選び方の取り決めが無ければ、書類どうしの値が違うたびに担当者が迷います。 この2つは、保険会社の資料を元に、代理店の中で一度文章にしてから設定ファイルにします。

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

登記事項証明書は、表題部だけを使います。 法務省の案内では、建物の表題部には所在、地番、家屋番号、種類、構造、床面積などが記録されます。甲区（所有権）と乙区（抵当権など）は見積に要らないので、読み取りの後に捨てます。

登記の構造の書き方は、不動産登記規則で決まっています。 構成材料（木造、土蔵造、石造、れんが造、コンクリートブロック造、鉄骨造、鉄筋コンクリート造、鉄骨鉄筋コンクリート造）、屋根の種類（かわらぶき、スレートぶき、亜鉛メッキ鋼板ぶき、草ぶき、陸屋根）、階数の組み合わせです。読み取った文字列をこの語彙に分けると、表記の揺れを規則で吸収できます。

確認済証には、申請書の副本が添えられます。 建築基準法施行規則では、確認済証は申請書の副本と添付図書を添えて交付するとされています。顧客の手元の綴りには副本が入っていることが多く、耐火・準耐火に関する記載はそちらを探します。 確認済証の1枚だけが届いたときは、副本の該当の頁を頼む依頼文を出します。

AIへ渡す前に整形する

1. 形式とサイズの確認 … PDF、JPEG、PNG などの形式で、同期の処理のファイルの上限を超えないかを見ます
2. 画像の品質の確認 … Enterprise Document OCR の品質の点数が低い写真は、読み取りに進まず撮り直しを頼みます
3. 向きの補正 … 斜めや横向きの写真は回転の補正を使います
4. 書類の見分け … ページの文字から、確認済証・申請書の副本・登記事項証明書のどれかを見分けます
5. 権利部の除去 … 登記事項証明書の甲区・乙区のページと行を、生成AIに渡す前に落とします
6. 依頼の住所との照合の準備 … 依頼の時点で聞いた住所を、番地の表記をそろえて持ちます

2番目を最初に置くのは、読めない写真で時間を使わないためです。 床面積の小数点が影で消えた写真を読み取りに進めると、それらしい数字が出て、誤りに気づけません。 点数が低ければ、その場で撮り直しを頼みます。

5番目は、見積に要らない情報を外へ出さないためです。 所有者の氏名と住所、抵当権の債権額は、構造級別にも床面積にも関係しません。

AIに処理させる

させるのは、書類の種類を見分け、項目を根拠付きで取り出すことだけです。

耐火・準耐火の記載が、この構成でいちばん大事な項目です。 構造級別の候補は、構成材料とこの記載の組み合わせで決まります。AIには「記載があるか」と「その文字列」だけを返させ、それが耐火構造に当たるかは判断させません。

2行目が、いちばん起きやすい失敗です。 「鉄骨造3階建」を見ると、AIは「鉄骨造なので準耐火の可能性が高い」と書きます。それは推測で、そう書かれた案を見た担当者は、副本を確かめずに進めてしまいます。

指示内容を固定する

あなたは損害保険の代理店で、火災保険の見積の前に、
顧客から受け取った建物の書類を読む担当です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【まず、ページごとに書類の種類を見分けてください】
confirmation（建築確認済証）/ application_copy（確認の申請書の副本）/
registry（登記事項証明書）/ other

【取り出す項目】
1. 所在地（登記の所在・地番、確認済証の建築場所を別々に）
2. 登記の構造（構成材料、屋根の種類、階数を分けて）
3. 耐火・準耐火に関する記載（書類に書かれた文字列のまま）
4. 建築年月（登記の新築の日、確認済証の確認の日を別々に）
5. 床面積（登記の各階の面積、確認の書類の延べ面積を別々に）

【status の選び方】
- ok ......... 値が読み取れている
- not_found .. その項目の記載が見つからない
- unreadable . 文字はあるが読み取れない（画像の品質の点数が低い場合を含む）
- ambiguous .. 候補が複数あり、1つに決められない
迷ったときに ok を選ばないでください。

【厳守事項】
- 構造級別（M・T・H など）を書かないでください。
- 構成材料や階数から、耐火・準耐火に当たるかを推し量らないでください。
  耐火・準耐火に関する記載は、書類に書かれた文字列だけを返してください。
  見つからなければ not_found にしてください。
- 書類どうしで値が違っても、どちらかに統一しないでください。
  書類ごとに別の行で返してください。
- 数字を補わないでください。小数点や桁が読めなければ unreadable にしてください。
- 元号と西暦を変換しないでください。書かれたとおりに返してください。
- 確認済証の確認の日を、建物が完成した日として扱わないでください。
- 登記事項証明書の甲区・乙区（所有者、抵当権など）の内容を返さないでください。
- evidence には、根拠にした文字列をそのまま写してください。

【読み取り結果】{ocr_result}
【ページごとの画像の品質の点数】{quality_scores}

「元号と西暦を変換しない」は、意図して書いています。 変換はプログラムで行えば誤りません。AIが変換すると、元号の境目の年で1年ずれることがあり、ずれた年は見た目では分かりません。

「確認の日を完成の日として扱わない」も同じです。 確認済証の日付は、工事の前に確認を受けた日です。建築年の欄にそのまま入れると、築年数が実際より古く見積もられることがあります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力（output_config.format に json_schema）で形を守らせます。

{
  "request_id": "",
  "pages": [ { "file": "", "page": 1, "doc_type": "registry" } ],
  "values": [
    { "item": "structure_material | roof | floors | fire_resistance_note |
               built_date | confirmation_date | floor_area_by_floor |
               total_floor_area | location",
      "source_doc": "registry | confirmation | application_copy",
      "status": "ok | not_found | unreadable | ambiguous",
      "value": "", "evidence": "", "file": "", "page": 1 }
  ]
}

1つ目の理由は、構造級別の候補を規則で出せることです。 structure_material と fire_resistance_note の組み合わせを、保険会社ごとの規則の表に当てます。

表の値は例です。 実際の規則は、契約する保険会社の判定基準で作ります。

2つ目は、書類どうしの値の違いを残せることです。 床面積が登記と確認の書類で違えば、両方が values に並びます。取り決めに沿って、どちらを見積に使うかをプログラムが選び、選んだ理由を添えます。 登記の床面積は、不動産登記規則で、区分建物以外は壁その他の区画の中心線、区分建物は内側線で囲まれた部分とされ、測り方の違いで値が違うことは異常ではありません。

3つ目は、evidence と頁で確認が速くなることです。 担当者は、候補の根拠になった記載の頁だけを開けば済みます。

元号の変換は、このJSONを受け取った後にプログラムが行います。 built_date の value は「令和3年5月12日」のように書かれたまま入り、プログラムが西暦に直して築年数を計算します。元号が改まった年の日付は、変換表で月日まで見て直します。

システムへ連携する

顧客の管理表には、依頼番号ごとに「所在地／構造級別の候補／建築年月／床面積／使った書類／確かめる点／依頼した書類」の列を書き出します。担当者はこの1行を見ながら見積の画面に入力し、決めた構造級別を同じ行に書き戻します。

見積の画面につながないのは、そこが保険会社の仕組みだからです。 代理店が自動で書き込む経路は無く、作るべきでもありません。担当者が案を見て入力することが、構造級別を人が決める仕組みそのものです。

人が確認する

担当者は、全件で構造級別を決めます。 この構成は候補と根拠を出すだけで、決める工程は省きません。

1. 画像の品質で止まったものを先に見る … 撮り直しの依頼を送ります
2. 確かめる点の付いた項目を見る … 耐火・準耐火の記載の頁、元号の読み違いの疑い、書類どうしの値の違いを画像で確かめます
3. 構造級別を決める … 規則の候補と根拠を見て決めます。迷うものは保険会社に照会します。 区分建物は、一棟の建物の構造と専有部分の記載を見比べます
4. 見積の画面に入力する … 決めた値を入力します

目標は、300件をならして1件3分です。 書類がそろっていて記載が明瞭な物件は1〜2分、副本を頼む物件や照会する物件は5分を超えます。照会する物件が増える月は、規則の表に足りない組み合わせがあります。

例外に対処する

4行目は、珍しくありません。 不動産登記規則は、区分に当たらない建物はこれに準じて定めるとしています。語彙に当たらない書き方を無理に当てはめず、そのまま担当者に見せます。

記録を残す

• 受け取った書類の画像・PDFと、受け取った日時・経路
• Document AI の結果のJSON（権利部を除いたもの）と、画像の品質の点数
• Claude API の出力（values）と、規則が出した候補
• 使った規則の表と取り決めの版
• 担当者が決めた構造級別と、照会した場合の保険会社の回答
• 追加の書類を頼んだ日時と、届いた日時

5つ目は、規則の表を育てる材料になります。 保険会社に照会して決まった組み合わせは、次から規則の表で候補が出るように1行足します。