保険会社から毎月届く代理店手数料の明細書を読み取り、契約台帳と照合して、計上漏れ・率の違い・戻入れを理由付きで洗い出す

処理の起点を決める

受付用フォルダに明細書のPDFが保存されたことを起点にします。 明細書は保険会社ごとに届く日が違い、月初の数日に散らばります。全社分がそろうのを待って一括で処理すると、早く届いた会社の照会が遅れます。 1通ずつ動かします。

Google Apps Script の時間主導のトリガーで、数分おきに受付用フォルダの新しいファイルを見ます。ファイル名は「保険会社コード_対象年月.pdf」に決めておき、名前が規則に合わないものは処理せずに担当者へ知らせます。 保険会社が分からないと、列の対応表を選べないためです。

処理が終わったファイルは処理済みフォルダへ移します。 移すのは照合結果の書き出しまで成功したときだけです。受付用フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 台帳に解約の日付が無ければ、戻入れは説明がつきません。列の対応表が無ければ、どの列が手数料額なのかを決められません。率の改定の記録が無ければ、規定の改定による差と誤りによる差が区別できません。

率の改定の記録は、保険会社からの通知を経理が1行ずつ書き足していくものです。 最初は空でも構いません。照合で「率の違い」が続いた種目から、通知を探して埋めていきます。

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

ページ数で処理の方式を分けます。 Document AI の上限では、Form Parser はオンライン（同期）の処理で15ページ、バッチ（非同期）の処理で100ページまでとされています。オンラインの処理で imageless_mode を有効にすると30ページまで広がりますが、1ページ目から連続して処理する場合に限るとされています。ファイルサイズの上限は、オンラインの処理で40MB、バッチの処理で1GBです。

返ってくる結果から取るものは3つです。

セルの文字は layout の textAnchor から本文を引いて取り出します。 セルに文字そのものは入っておらず、文書全体のテキストのどこからどこまでかが示される形です。ページをまたぐ表は、見出し行が2ページ目以降にも繰り返されるかを保険会社ごとに対応表へ書いておきます。

契約台帳は、照合の前に契約管理システムからCSVで書き出し、所定のフォルダに置きます。書き出しの日付をファイル名に入れ、照合結果にもどの日付の台帳を使ったかを残します。

AIへ渡す前に整形する

1. 保険会社と対象月の確認 … ファイル名から取り、明細のキーと値の組（対象月）とも一致するかを確かめます
2. 列の対応づけ … 見出しの文字列を対応表で引き、共通の項目に置き換えます。対応表に無い見出しが出たら処理を止め、担当者に知らせます
3. 数値の正規化 … 「1,234」「△1,234」「(1,234)」「-1,234」をそろえます。マイナスの書き方は保険会社ごとに対応表へ書きます
4. 証券番号の正規化 … 全角と半角、ハイフンの有無、先頭のゼロをそろえます。台帳の側も同じ規則でそろえます
5. 区分の読み替え … 「新」「継」「異」「解」のような略号を、new／renewal／change／cancel／chargeback に置き換えます
6. 合計の検算 … 本体の行の手数料額を足し、明細のキーと値の組にある合計と比べます。合わなければ、行の読み落としか読み違いがあります

6番目を省かないでください。 読み取りの誤りは、照合の段で「台帳にあって明細に無い」という差に化けます。合計が合わない明細書のまま照合に進むと、計上漏れに見える行の多くが読み落としになります。 合計が合わないものは照合に進めず、担当者に返します。

AIに処理させる

照合と差の計算は、すべて Google Apps Script の規則で行います。 生成AIに渡すのは、規則で差が出た行と、その契約の台帳の履歴・備考だけです。

生成AIにさせるのは、差のある行ごとに、理由の候補を決まった語の中から1つ選び、根拠にした台帳の記述を写すことだけです。

3行目がいちばん起きやすい失敗です。 戻入れの行を渡すと、台帳に解約の記録が無くても「解約に伴う戻入れと考えられる」と書きます。もっともらしい説明が付いた瞬間、台帳の更新漏れという本当の問題が消えます。

指示内容を固定する

あなたは保険代理店の経理で、代理店手数料の明細と契約台帳の差を確認する立場です。
渡された差のある行ごとに、理由の候補を1つ選んでください。

【理由の候補】
- cancellation_recorded ... 台帳に解約・失効・減額の記録と日付がある
- rate_revision ........... 率の改定の記録に、同じ保険会社・種目の改定がある
- change_recorded ......... 台帳に保険料の変更などの異動の記録がある
- timing .................. 始期・異動日が対象月の末日に近く、計上の月がずれうる
- ledger_not_updated ...... 備考に解約・変更の申し出の記述があるが、台帳の状態が変わっていない
- unexplained ............. 渡した記録のどこにも説明が無い

【厳守事項】
- 渡した台帳の履歴・備考・率の改定の記録に書かれていることだけを根拠にしてください。
- 記録に無いことを推測で補わないでください。説明が見つからなければ unexplained です。
- 「戻入れだから解約だろう」と考えないでください。台帳に解約の記録と日付が
  なければ cancellation_recorded を選ばないでください。
- 手数料額や率を計算し直さないでください。差の値は渡したものをそのまま使ってください。
- evidence には、根拠にした記録の文字列をそのまま写してください。
- unexplained のときは evidence を空にしてください。
- 照会すべきか、保険会社の誤りかどうかは書かないでください。
- 迷ったときは unexplained を選んでください。

【差のある行】{diff_rows}
【該当する契約の台帳の履歴と備考】{ledger_history}
【率の改定の記録】{rate_revisions}
【対象月】{target_month}

「戻入れだから解約だろう」を名指しで禁じないと、cancellation_recorded が増えます。 戻入れと解約は結び付きやすく、何も言わなければ連想で選びます。禁じるのは、台帳の記録ではなく連想を根拠にする判断です。

「迷ったら unexplained」も同じ理由です。 unexplained は人が見る行で、そこに入りすぎても時間が少し増えるだけです。逆に説明のつかない行が explained に入ると、誰も見ません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "insurer_code": "",
  "target_month": "",
  "results": [
    {
      "policy_no": "",
      "diff_type": "missing_on_statement | missing_in_ledger | rate_diff | amount_diff | chargeback",
      "diff_amount": 0,
      "reason": "cancellation_recorded | rate_revision | change_recorded | timing | ledger_not_updated | unexplained",
      "evidence": "",
      "note": ""
    }
  ]
}

diff_type と diff_amount は規則で出したものをそのまま返させ、生成AIが埋めるのは reason、evidence、note の3つです。スキーマで reason を enum にしておくと、6つ以外の言い方で返ってくることがありません。

そのうえで、振り分けは規則で行います。

1つ目の理由は、照合の結果と理由の候補を別の層に置けることです。 差は規則が出し、理由はAIが選び、振り分けはまた規則で決めます。照会の基準額を変えても、直すのは規則だけです。

2つ目は、evidence で確認が速くなることです。 経理担当は台帳を開く前に、何を根拠に説明がつくとされたのかを一覧で読めます。evidence が空なのに explained に入る行は、規則で作れないようにしてあります。

システムへ連携する

契約管理システムには書き込みません。 ledger_not_updated の行が出ても、台帳の状態を直すのは営業事務の仕事です。照合の仕組みが台帳を書き換えると、何が本当の状態だったのかが分からなくなります。

人が確認する

人が開くのは check と inquiry_candidate の行だけです。 explained の行は、件数と金額の合計を一覧で見ます。

1. 合計の検算を先に見る … 明細の合計と行の合計が合っているか。合わない明細書は照合の結果を使わない
2. inquiry_candidate を見る … 明細書の該当箇所と台帳を開き、照会するかを決めます。照会の連絡そのものは人が行います
3. check を営業事務へ戻す … 台帳の更新漏れを直してもらい、翌月の照合で消えたかを見ます
4. 判定を覆したら記録する … どの行の理由を、何に変えたかを残します

目標は、明細書1通あたり45分です。 差のある行が1割前後という想定で、それより多い月は、列の対応表か率の改定の記録が追いついていません。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、保険会社の書式の変更と、ファイルの受け取り方の問題です。 対応表を直すほうが、読み取りの精度を上げるより効きます。

記録を残す

• 元の明細書のPDFと、取得した日時
• Document AI が返したJSONの全文
• そのとき使った列の対応表と率の改定の記録の版
• 照合に使った契約台帳のCSVの書き出し日付
• 規則が出した差と、生成AIが選んだ理由の候補、振り分けの結果
• 人が理由を覆した記録と、照会した結果（保険会社の回答と、差が解消したか）

3つ目で対応表の版を残すのは、書式の変更が後から分かることがあるためです。 どの版で読んだかが残っていないと、過去の照合をどこまでやり直すかが決まりません。

最後の行は、翌年の照合を速くします。 照会して「規定どおり」と回答のあった差は、率の改定の記録に書き足せば、次からは rate_revision として説明がつきます。