賃貸の入居申込書と本人確認・収入証明の書類を読み取り、記載の食い違いを審査に回す前に洗い出す

処理の起点を決める

受付台帳の状態が「書類そろい」になった行を、10分おきの定時の処理で拾います。 Apps Script のインストール型トリガーには時間主導型があり、公式には最短で1分ごとから月1回まで設定できるとされています。ドライブへのファイル追加を直接きっかけにするトリガーは、確認した一覧にはありませんでした。

ファイルが届いたことではなく、書類がそろったことを起点にするのには理由があります。 本人確認書類が先に届き、収入証明が翌日に届くことはよくあります。ファイルが届くたびに動かすと、毎回「収入証明が無い」という結果が出て、担当者がそれを見なくなります。

処理を終えた行は「点検済み」に、失敗した行は「点検エラー」に変えます。 「書類そろい」のまま残っている行の数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の2つです。 字体の対応表が無いと、申込書の「高」と免許証の「髙」を別の字として不一致にします。 年収の比べ方の表が無いと、比べる欄をAIがその都度選ぶことになり、担当者ごとの揺れがAIに移るだけです。

本人確認書類は必ず裏面も受け取ります。 運転免許証は住所が変わると裏面に新しい住所が書かれます。表だけを読むと、引っ越した人の申込はすべて住所の食い違いになります。 マイナンバーカードは表面だけを受け取る運用にします。この点検で個人番号は使いません。

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

1. 受付台帳から「書類そろい」の行を読み、申込番号でフォルダを特定する
2. フォルダ内のファイル名の先頭（本人_、収入_）で書類の種類を仮に決める
3. 本人確認書類は prebuilt-idDocument、収入証明は prebuilt-layout に features=keyValuePairs を付けて送る
4. 返ってきたJSONをフォルダに保存し、台帳の申込書の値とあわせて次の段へ渡す

源泉徴収票のように項目名が決まった書類では、クエリ フィールドも使えます。 公式には、抽出したいフィールド名を指定すると値を返すアドオンで、1回の要求で最大20個まで指定できるとされています。ただしプレミアムのアドオンで、料金の区分が別です。 まずは無料の keyValuePairs で組み、取りこぼしの多い書類だけに使います。

AIへ渡す前に整形する

1. 形式の確認 … PDFと画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）であることを確かめます。それ以外はPDFに変換します
2. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間である必要があります
3. 文字の大きさの確認 … 抽出するテキストの最小の高さは、1024×768の画像で12ピクセルとされています。FAXの受信画像はこれに近いことが多いので、寸法を記録しておきます
4. ロックの解除 … パスワードでロックされたPDFは、提出前に解除する必要があります
5. マイナンバーカード裏面の除外 … ファイル名や仲介会社からの連絡で裏面と分かるものは、読み取りに回さず担当者へ戻します
6. 項目名のそろえ … 台帳の列名と、読み取った値の名前を name_kanji、birth_date のように1つの名前にそろえます
7. 字体の正規化 … 対応表にある字を、比べるときだけ同じ字に置き換えます。元の値は置き換えずに残します

7番目で元の値を残すのは、確認依頼の文面に正確な表記が要るためです。 置き換えた字で「高橋様の申込で」と書くと、申込者の書いた字と違ってしまいます。

AIに処理させる

させるのは、6つの項目それぞれの突き合わせだけです。

右端の列の区別が、この構成でいちばん大事です。 mismatch は書類どうしが合っていない、explainable は違うが理由の見当がつく、unreadable は値として確定できない、not_in_document はその書類にその項目が無い、ということです。仲介会社に確かめるのは mismatch だけで、unreadable は自社で画像を見直せば済みます。

分ける材料は、読み取りが返した confidence です。 値が無ければ not_in_document、値があって信頼度が低ければ unreadable。根拠をOCRが返した数値に置きます。

3行目がいちばん起きやすい失敗です。 FAXで番地の数字がつぶれていると、台帳の値から埋めて match にしがちです。その瞬間、読めなかったという事実が消えます。

指示内容を固定する

あなたは賃貸管理会社の受付担当で、入居申込の書類どうしの記載が合っているかを点検します。
入居を認めるかどうかの判断はしません。書類に書かれていることだけを比べてください。

【比べる6項目】
1. 氏名（漢字）  2. フリガナ  3. 生年月日  4. 現住所  5. 勤務先  6. 年収

【status の選び方】
- match ............ 書類どうしで一致している
- mismatch ......... 書類どうしで違っており、下の explainable に当たらない
- explainable ...... 違うが、次のどれかに当たる
                     字体の対応表にある字の違い／旧姓の書類／建物名・部屋番号の省略／
                     「株式会社」の位置や略称の違い／和暦と西暦の違い
- unreadable ....... 値は検出されているが confidence が {threshold} 未満、または字がつぶれている
- not_in_document .. 比べる相手の書類に、その項目の値が無い
迷ったときに match を選ばないでください。

【厳守事項】
- 読めない文字を、申込書の値で補って埋めないでください。
- 項目名だけがあって値が空の場合は not_in_document です。
  項目名があることを、値があることとして扱わないでください。
- 現住所は、本人確認書類の裏面に新しい住所の記載があれば、そちらと比べ、
  どちらと比べたかを basis に書いてください。
- 年収は【年収の比べ方の表】に従い、比べた欄を basis に書いてください。
  差を「許容範囲」と判断せず、差額をそのまま diff に入れてください。
- evidence には、各書類から読み取った文字列をそのまま写してください。
- confidence は読み取り結果の値をそのまま入れてください。
- 入居の可否、収入が足りるか、書類が本物かは書かないでください。
- 国籍、在留資格、年齢について評価を書かないでください。
- 個人番号の記載を見つけた場合は、値を写さずに contains_my_number を true にしてください。

【申込書の値（台帳）】{application}
【本人確認書類の読み取り結果（表・裏）】{identity}
【収入証明の読み取り結果】{income}
【字体の対応表】{variant_table}
【年収の比べ方の表】{income_rule}

「迷ったときに match を選ばない」を書かないと、一致が増えます。 値が似ていると一致と答えがちで、それが見落としになります。 迷ったら人に回る側へ倒します。

「差を許容範囲と判断しない」も同じ理由です。 年収の50万円の差を許すかは保証会社の要件で決まり、AIが「おおむね一致」と書くと、その判断が誰のものか分からなくなります。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力を使い、output_config.format に type: "json_schema" とスキーマを渡します。公式には、スキーマのすべてのオブジェクトに additionalProperties: false が必要とされています。

{
  "application_no": "",
  "contains_my_number": false,
  "checks": [
    { "item": "name_kanji", "status": "match | mismatch | explainable | unreadable | not_in_document",
      "application_value": "", "document_value": "", "compared_with": "",
      "basis": "", "diff": "", "confidence": 0, "evidence": "" }
  ],
  "identity_expiry": "",
  "income_year": "",
  "verdict": "ready | ask_agent | needs_human",
  "agent_request_draft": ""
}

checks には6つの要素を並べます。item は name_kanji ／ name_kana ／ birth_date ／ address ／ employer ／ annual_income です。

1つ目の理由は、status と verdict を別の層に置けることです。 checks はAIが埋め、verdict は Apps Script の規則で決めます。保証会社の要件が変わっても、直すのは規則だけです。

2つ目の理由は、数値の範囲を規則の側で持てることです。 公式には、構造化出力では minimum や maximum といった数値の制約はサポートされないとされています。年収の差の許容幅はスキーマで縛れないので、diff を受け取ってから Apps Script で比べます。

3つ目は、evidence と compared_with で確認が速くなることです。 どの書類のどの文字列と比べたかが一覧で読めるので、画像を開く前に、食い違いが本物か見当がつきます。

システムへ連携する

台帳には、項目ごとの結果を列で書き戻します。 6列に status を入れ、verdict を先頭の列に置きます。担当者は台帳を verdict で並べ替えるだけで、今日見るものが分かります。

台帳の申込書の値は書き換えません。 本人確認書類のほうが正しそうに見えても、直すかどうかは仲介会社に確かめてから人が決めます。 賃貸管理システムにも書き込みません。確認依頼の下書きは台帳の行にリンクを付けて置き、送信は担当者がメールから行います。

人が確認する

人が開くのは ask_agent と needs_human のものだけです。 ready のものは台帳で6列の結果を流し見て、審査に回します。

1. needs_human を先に見る … unreadable を含むものは、元の画像を拡大して自分で読みます。読めなければ仲介会社に再送を頼みます
2. mismatch を画像で確かめる … evidence の文字列を元の画像と見比べ、本当に書類どうしが違うかを目で確かめます
3. explainable を認める … 旧姓の書類などは、そのまま通してよいかを担当者が決めます
4. 確認依頼の下書きを直して送る … どの書類のどの項目がどう違うかが書かれているかを見ます
5. 判定を覆したら記録する … どの項目を、どの status からどれに変えたか

2番目を省かないでください。 mismatch は、申込者に書類を出し直してもらうことに直結します。空振りの差し戻しは、仲介会社との関係に残ります。

目標は、240件をならして1件4分です。 ready のものは台帳を見るだけで短く、ask_agent と needs_human のものは画像を見て下書きを直すので長くかかります。

例外に対処する

上から4行目までが、件数の大半を占めます。 どれもAIの問題ではなく、書類の受け取り方の問題です。 仲介会社に「書類ごとにファイルを分ける」「免許証は裏面も」と頼むほうが、判定を直すより効きます。

記録を残す

• 受け取った書類の元ファイルと、受け取った日時・経路（FAX／PDF／写真）
• 読み取りが返したJSONの全文（個人番号を含むページは保存しない）
• 突き合わせの結果（checks、verdict）と、そのとき使った字体の対応表・年収の比べ方の表・規則の版
• 人が判定を覆した記録 … どの項目を、どの status からどれに変えたか
• 仲介会社へ確認を頼んだ日時と、再提出された書類との対応
• 仲介会社ごとの unreadable と mismatch の発生率

3つ目で規則の版を残すのは、年収の許容幅が後から変わるためです。 幅を直すと、過去に ready とした申込の意味が変わります。 当時の規則が残っていないと、どこまで見直すかが決まりません。