取引銀行から毎月届く返済のお知らせと利息の計算書を読み取り、借入金の台帳と照らして、元金・利息・適用金利の食い違いを財務担当へ出す

処理の起点を決める

Google Apps Script の時間主導型トリガーで、数分おきに取込フォルダを見ます。 時間主導型のトリガーは、毎分から月1回までの間隔で動かせるとされています。返済日は銀行と借入ごとに散らばっているため、月末にまとめて処理しません。 返済の前に届くお知らせの段階で食い違いを見つければ、引き落としの前に銀行に確かめられます。

入る経路は2つです。郵送の紙をスキャンしたものと、インターネットバンキングからダウンロードしたPDFです。どちらも同じ取込フォルダに入れ、そこから先は区別しません。ダウンロードは人が行います（第13章）。

1回の実行で処理する件数に上限を置きます。 Apps Script の1回の実行は6分までとされています。1回に5件までとし、残りは次の実行に回します。 処理済みフォルダへ移すのは、照合結果のシートへの書き込みまで成功したときだけにします。

入力データを集める

質を決めるのは、借入ごとの条件の列です。 片端と両端の違いだけで1日分の利息が変わります。 差が銀行の誤りか自社の数え方の誤りかを分けるには、条件を台帳に書いておくしかありません。

営業日カレンダーは、返済日のずれを説明するために持ちます。 返済日が休日で翌営業日にずれると、利息の日数が伸びます。理由として付けられないと、毎月同じ食い違いが人に回ってきます。

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

読み取りは、Apps Script から Document AI の処理のAPIを呼ぶだけです。ファイルを渡すと、Document という形の応答が返ります。

金利は、信頼度とあわせて取ります。 「1.875％」と「1.375％」の違いは、利息の額をまるごと変えます。信頼度の低い金利や金額は、その書類を needs_review にして人に回します。

台帳はスプレッドシートを読むだけで足ります。 引く順は借入番号が先で、番号が無い書類に限り銀行・返済日・元金の組で候補を出します。候補が2つ以上あれば選ばず、unmatched にします。

AIへ渡す前に整形する

1. 形式の確認 … Form Parser の対象は PDF、GIF、TIFF、JPEG、PNG、BMP、WebP です。それ以外は PDF にします
2. ページ数の確認 … 同期処理は15ページまでです。期間の長い返済予定表で15ページを超えるものは、バッチ処理に回します
3. 解像度の確認 … 公式には、OCRの精度のためにスキャンは最低200dpiが望ましいとされ、300dpi以上が一般に最もよい結果になるとされています。複合機の既定の設定を確かめます
4. 圧縮の確認 … JPEG のような非可逆の形式は、ファイルを小さくすると精度が落ちることがあるとされています。保存形式は PDF にします
5. 銀行の推定 … ファイル名、1ページ目の銀行名とロゴの近くの文字から銀行を推定し、書式メモを引きます
6. 1ファイルに複数の書類がないかの確認 … 同じ封筒の「お知らせ」と「計算書」をまとめてスキャンしたものは、ページで分けます
7. 重複の検知 … 同じ借入番号・返済日・書類の種類のものが直近にあれば、既処理として印を付けます

6番目を軽く見ないでください。 予告と確定が1つのファイルにあると、2つの数字が混ざります。返済日がずれると予告と確定の利息は違う額になるので、混ざると理由が付けられません。

AIに処理させる

させるのは、書類の種類を見分け、書かれた数字を決まった項目に写すことだけです。 計算はさせません。

右端の列が、この構成でいちばん大事な区別です。 書かれていない項目を、台帳の値や計算で埋めさせません。特に適用金利と日数は、書かれていなければ空のままにします。

2行目がいちばん起きやすい失敗です。 適用金利が書かれていない計算書を渡すと、AIは利息と残高から金利を逆算して埋めます。その瞬間、金利の見直しの見落としが「一致」にすり替わります。

指示内容を固定する

あなたは財務部門で、取引銀行から届いた借入金の書類を読み、
借入金の台帳と照合するための下書きを作る立場です。
OCRが返した読み取り結果だけを見てください。推測で埋めないでください。

【やること】
1. 書類の種類を次から1つ選んでください。
   - notice ...... 返済日より前に届く予告（「ご返済のお知らせ」「ご返済予定額」など）
   - statement ... 返済後の確定（「利息計算書」「ご返済明細」「お取引明細」など）
   - schedule .... 返済予定表（複数回分の返済日・元金・利息・残高の表）
   - rate_change . 適用金利の変更のお知らせ
   - unknown ..... 上のどれか決められない
2. 書類に書かれている数字を、指定の項目に写してください。
   返済予定表のときは、表の各回を1行ずつ installments に入れてください。

【厳守事項】
- 数字は書類に書かれたものをそのまま入れてください。
  桁区切りや「円」「％」は外してかまいませんが、値は変えないでください。
- 計算をしないでください。適用金利が書かれていないときに、
  利息と残高から逆算して埋めないでください。書かれていなければ空にします。
- 利息の日数が書かれていないときに、期間から数えて埋めないでください。
- 元金と利息の合計しか書かれていないときに、元金と利息に分けないでください。
- 借入番号は読み取った文字列をそのまま loan_ref に入れてください。
  桁を補う、似た番号に直すことをしないでください。読めなければ空にします。
- 「予定」「お知らせ」と書かれた額を、確定した額として扱わないでください。
  予告か確定かは、書類に書かれた語で決めてください。
- 残高が返済前の残高か返済後の残高か書かれていなければ、
  balance_basis を unknown にしてください。
- 食い違いの原因や、台帳との比較について書かないでください。
- evidence には、各値の根拠にした文字列をそのまま写してください。
- 借入の書類でないもの（預金の明細、手数料の案内など）と判断した場合は、
  写さずに document_type を other にしてください。

【読み取り結果】{ocr_result}
【この銀行の書式メモ】{bank_note}

「逆算して埋めない」と「期間から数えて埋めない」を分けて書くのは、片方だけでは止まらないからです。 金利の逆算だけを禁じると日数を数えて埋め、銀行が片端と両端のどちらで数えたかという情報が消えます。

出力形式を固定する

Gemini API の構造化出力で、次の形のJSONに固定して受け取ります。 公式には、指定したJSONスキーマに従う応答を生成させられるとされ、enum で値の候補を限り、required で必須の項目を決められます。

{
  "document_type": "notice | statement | schedule | rate_change | unknown | other",
  "bank_name": "",
  "loan_ref": "",
  "payment_date": "",
  "principal": null,
  "interest": null,
  "total_payment": null,
  "rate": { "applied": null, "base": null, "spread": null, "effective_from": "" },
  "interest_period": { "from": "", "to": "", "days": null },
  "balance": null,
  "balance_basis": "after | before | unknown",
  "installments": [],
  "evidence": [{ "field": "", "text": "", "confidence": 0 }]
}

1つ目の理由は、AIの仕事と計算の仕事を別の層に置けることです。 JSONはAIが埋め、検算と判定は Apps Script が台帳の条件で行います。

interest_diff には、要素ごとの理由を付けます。 Apps Script は、書類の日数と台帳の日数、書類の金利と台帳の金利を別々に比べ、どれが違うのかを reason に入れます。

2つ目の理由は、スキーマに合っていても値が正しいとは限らないことです。 公式にも、値はアプリケーションの側で検証するよう書かれています。元金と利息の和が total_payment と合わなければ needs_review にします。

3つ目は、evidence で確認が速くなることです。 利息の期間の原文が残っていれば、画像を開く前に銀行の数え方が分かります。

システムへ連携する

借入金の台帳には書き込みません。 書き込むのは別シートの照合結果だけです。金利変更のお知らせを読んだときも、台帳の金利は直しません。 照合結果に「rate_change を受け取った。台帳の金利は未更新」と出し、人が直します。

銀行への照会メモの下書きは、unexplained と rate_diff にだけ作ります。 宛先は銀行の担当者ですが、送るのは財務担当です。 下書きには借入番号、返済日、書類の値、自社の検算の値、どの要素が違うかを並べ、銀行の担当者が自分の計算と比べやすい形にします。

人が確認する

人が開くのは match 以外の行だけです。 match のものは一覧で件数と銀行を流し見ます。全件を開く設計にすると、第10章の9.0時間には収まりません。

1. needs_review を先に見る … 金額・金利・日付を画像で確かめて直します
2. rate_diff を見る … 金利変更のお知らせが届いていないか、取込フォルダと照合結果を探します。届いていれば台帳を直し、届いていなければ銀行に確かめます
3. interest_diff の reason を読む … days_holiday_shift と rounding は説明がつくものとして流し、days_count_method は契約書で確かめます
4. unexplained と principal_diff を照会に回す … 下書きを直して銀行へ送ります
5. 判断を記録する … 台帳を直したか、銀行の誤りか、照会中かを残します

2番目を省かないでください。 適用金利の食い違いは、放っておくと翌月以降の全部の予定に乗ります。

目標は、90件をならして1件6分です。 開くのは3割前後という想定で、それより多い月は、台帳の条件の列が埋まっていない借入があります。

例外に対処する

4行目がいちばん手間のかかる例外です。 作り直した返済予定表が届くまでの書類は、古い予定と比べると全部食い違いになります。繰上返済を実行したら、その借入に「予定表待ち」の印を付けておきます。

記録を残す

• 元の書類のファイルと、受け取った日時・経路（郵送／インターネットバンキング）
• Document AI が返した Document のJSONの全文
• Gemini API に渡した書式メモの版と、返ってきたJSON
• Apps Script が検算した値、状態、理由、そのとき照合した台帳の行と借入ごとの条件
• 人が状態を覆した記録と、台帳を直した記録
• 銀行に照会した日時と、銀行からの回答

4つ目で「そのときの条件」を残すのは、条件が後から直るためです。 当時どの条件で検算したかが残っていないと、どの月の結果をやり直せばよいかが決まりません。