仲介会社から届く手書きの入居申込書を読み取り、申込管理表と保証会社への審査依頼の様式に転記する

処理の起点を決める

取込フォルダにファイルが入ったことを起点にします。 Google Apps Script の時間主導型トリガーで数分おきにフォルダを見て、未処理のファイルがあれば1件ずつ処理します。申込は受けた順に審査するため、1日1回のまとめ処理にはしません。 夕方に届いた申込をその日のうちに依頼できるかどうかが、この構成の効きどころです。

入る経路はFAX受信の画像、メール添付のPDF、写真の3つです。FAX受信は共有ドライブに保存する設定にし、メールと写真は受付担当が移します。入口を1つにそろえ、そこから先は経路を区別しません。

取込フォルダに入れるのは申込書のページだけです。 本人確認書類や収入証明が同じファイルに入っていれば、受付担当がページを分けてから入れます。処理が終わったファイルは処理済みフォルダへ移し、移すのは成功したときだけにします。 取込フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 列定義が無ければ、振り分けた値をどの列に入れるかが決まりません。保証会社の対応表が無ければ、2つ目の転記先が作れません。物件で使う保証会社が引けなければ、どの様式に出すかが決まりません。

仲介会社名は、書式の傾向を見るために持ちます。 section_unclear が続く会社には、管理会社の書式を使ってもらう相談ができます。

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

読み取りは、Google Apps Script から Document AI の処理のエンドポイントを呼ぶだけです。申込書は1件あたり1〜2ページなので、同期処理の上限の15ページに収まります。 超えるファイルは申込書以外のページが混ざっているとみなし、処理せずに受付担当へ戻します。

振り分けの手がかりは、欄の見出しと位置です。 「連帯保証人」の見出しの下の「氏名」は、保証人の氏名である可能性が高い。そのため項目ごとの境界の座標を捨てずに持ちます。

物件台帳と保証会社の対応表は、スプレッドシートを読むだけです。物件は、申込書に書かれた物件名と部屋番号で引きます。 引けなければ、物件の欄を blank として人に回します。

AIへ渡す前に整形する

1. 形式の確認 … 対応形式は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP とされています。スマートフォンの写真で別の形式が届けば変換します
2. ページ数の確認 … 同期処理で15ページ以内。申込書以外のページが混ざっていないかを受付担当に戻して確かめます
3. 解像度の確認 … 正確なOCRのために、スキャンは最低200dpiが望ましいとされています。FAXの受信設定によってはこれを下回るため、受信側の画質設定を先に見直します
4. 圧縮の確認 … 非可逆の形式でファイルを小さくすると画質と精度が落ちることがあるとされています。写真を送る仲介会社には、圧縮せずに送ってもらうよう頼みます
5. 向きと傾きの補正 … 写真は横向き・斜めで届くことが多いため、回転してから渡します
6. 重複の検知 … 同じ物件・同じ申込者の申込書が、FAXとPDFの両方で届くことがあります。物件と申込者の氏名で照合します

3番目を軽く見ないでください。 FAXを経た手書きの数字は、解像度が足りないと信頼度が低いまま出てくるとは限らず、別の数字として高い信頼度で出てくることもありえます。信頼度だけに頼らない理由が、第7章の「人間の確認」の「必ず見る項目」です。

AIに処理させる

Gemini API にさせるのは、項目名と値の組を「誰の項目か」で振り分け、申込管理表の列名に対応させることだけです。 値そのものは書き換えません。

4つ目と5つ目がいちばん迷う欄です。 緊急連絡先と連帯保証人が同じ人物であることは珍しくありませんが、同じ人かどうかをAIに決めさせると、欄を埋めるために同じ人にしてしまいます。 書かれている欄のとおりに分け、同じ人かは担当者が見ます。勤務先も、人物欄の外に書かれていれば属する人を推測しません。

状態の付与は、Gemini API ではなく Google Apps Script の規則で行います。

しきい値は、最初の1か月で決めます。 最初は高めに置いて low_confidence を多めに出し、人が直さずに済んだ項目の信頼度の分布を見て下げていきます。 最初から低く置くと、読み違いが ok に混ざったまま運用が始まります。

4行目は、頼まれなくても書き始めます。 年収と賃料が並ぶと「審査が厳しい可能性」と添えてきます。転記の段階で先入観を作りません。

指示内容を固定する

あなたは賃貸管理会社で、入居申込書の読み取り結果を整理する担当です。
OCRが返した項目名と値の組を、誰の項目かで振り分けてください。
値を推測で埋めないでください。

【振り分け先】
applicant（申込者） / occupants（同居人、人ごと）/
guarantor（連帯保証人） / emergency_contact（緊急連絡先） /
property（物件） / agency（仲介会社）

【振り分けの手がかり】
- 欄の見出し（申込者、入居者、連帯保証人、緊急連絡先）の位置
- 項目の境界の座標。見出しより下、次の見出しより上にある項目をその欄とする
- 見出しが読めない、または位置から決まらない項目は section_unclear とする

【厳守事項】
- value には、OCRが返した文字列をそのまま入れてください。
  桁を補う、ハイフンを足す、漢字を直す、金額を丸めることをしないでください。
- 記載がなければ value を空にしてください。他の欄から写さないでください。
- 緊急連絡先と連帯保証人が同じ人かどうかを判断しないでください。
  書かれている欄のとおりに振り分けてください。
- 勤務先は、その勤務先が書かれている人物欄の人のものとしてください。
  どの人物欄にも属さない勤務先は section_unclear としてください。
- confidence は OCRが返した値をそのまま入れてください。
- 審査の見込み、年収と賃料の比率、入居の可否についての意見を書かないでください。
- チェックボックスは OCR の値の種類（filled_checkbox / unfilled_checkbox）を
  そのまま写してください。同意しているかどうかを文章で書かないでください。
- 申込書でない書類（本人確認書類、収入証明など）と判断したページは、
  振り分けをせず document_type に種類だけを書いてください。

【読み取り結果】{form_fields}
【申込管理表の列定義】{columns}
【見出しの位置】{section_headers}

「値をそのまま入れる」を明記しないと、電話番号の書式を整えます。 手書きで10桁しか読めていない携帯電話の番号に、それらしい1桁を足して11桁にします。整えた番号は正しそうに見え、担当者が見比べる理由がなくなります。

最後の項目は、本人確認書類がOCRに入ってしまったときの歯止めです。 種類だけを返させ、そのページを処理の流れから外します。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API では JSON スキーマを指定した構造化出力を使い、enum で取りうる値を並べられるとされています。

{
  "application_id": "",
  "document_type": "rental_application",
  "property": { "name": "", "room": "", "status": "ok" },
  "agency": { "name": "", "staff": "" },
  "persons": [
    { "role": "applicant | occupant | guarantor | emergency_contact",
      "fields": [
        { "column": "氏名", "value": "", "confidence": 0,
          "status": "ok | blank | low_confidence | section_unclear",
          "source_field_name": "" }
      ] }
  ],
  "consent_checkbox": "filled_checkbox | unfilled_checkbox | not_found",
  "unassigned": [],
  "inquiry_draft": ""
}

1つ目の理由は、人ごとの配列にできることです。 同居人が2人いる申込書と0人の申込書を、同じ形で扱えます。role が付いていれば、保証会社の様式への並べ替えは対応表で機械的にできます。

2つ目は、source_field_name で根拠を残せることです。 申込書に書かれていた項目名をそのまま残し、「申込管理表の勤務先電話番号」がどの欄から来たかを担当者がすぐ追えます。

3つ目は、unassigned を分けて持つことです。 振り分けられなかった項目を捨てずに並べ、担当者が画像を見て列を決めます。捨てると、書かれていたのに blank と出て、仲介会社に不要な問い合わせをします。

保証会社の様式には、その保証会社が求める項目だけを出します。

システムへ連携する

保証会社へは、この構成から送りません。 出すのは様式に合わせたシートの1行までで、確認が済んだものを担当者が保証会社の申込の経路で送ります。 送信まで自動にすると、同意欄の読み違いがそのまま第三者提供になります。

申込管理表への書き込みは、状態の列とあわせて行います。 ok 以外が1つでもある行は「確認待ち」とし、確認が済むまで保証会社のシートには出しません。

人が確認する

人が見るのは、ok 以外の項目と、必ず見る項目だけです。 1件の申込書を開き、該当する項目の位置が画像の上で示された状態で見比べます。

1. section_unclear と unassigned を先に見る … 誰の項目かを決めます。取り違えを防ぐ、いちばん大事な確認です
2. low_confidence を見比べる … 画像の文字と値を比べて直します
3. 必ず見る項目を見比べる … 申込者と連帯保証人の生年月日、電話番号、年収は、信頼度にかかわらず毎回見ます
4. 同意欄を目で確かめる … filled_checkbox と出ていても、署名欄とあわせて画像で見ます
5. blank の問い合わせ文を直して送る … 送信は担当者が行います

3番目を省かないでください。 第7章の「前処理」の3番目のとおり、FAXを経た数字は高い信頼度のまま別の数字になることもありえます。この3項目は審査の結果と連絡に直結し、1文字の誤りで別人の審査になります。

目標は、360件をならして1件5分です。 必ず見る項目の見比べに2分、ok 以外の項目と同意欄に2分、問い合わせ文と保証会社のシートの確認に1分という見込みです。section_unclear が多い月は、その仲介会社の書式が原因であることが多く、書式の相談の材料になります。

例外に対処する

3行目と4行目は、ほかの行と重みが違います。 どちらも個人情報の扱いに関わり、読み取りの誤りではなく、取り扱いの誤りになります。 本人確認書類が混ざったときは、読み取り結果を申込管理表にもログにも残さない設計にします。

記録を残す

• 元の申込書ファイルと、受け取った日時・経路・仲介会社名
• Document AI が返した結果（項目名と値の組、信頼度、チェックボックス）
• 振り分けの結果（persons、unassigned）と、付けた状態と、そのときのしきい値
• 人が直した記録 … どの項目を、どの値に、どの列に変えたか
• 保証会社へ依頼した日時と担当者
• 仲介会社ごとの section_unclear と low_confidence の発生率

3つ目で「そのときのしきい値」を残すのは、後から動かすためです。 下げたあとで誤りが見つかれば、どの期間の ok を見直すかがこの記録で決まります。