保険代理店に保険会社から届く保険料の口座振替不能の通知を読み取り、契約者ごとに連絡文の下書きと失効までの期限を募集人に回す

処理の起点を決める

Watch emails を30分ごとに動かします。 対象は「不能通知」のラベルが付いた、添付のあるメールです。保険会社の通知の送信元のアドレスと、事務の担当が画面から取り出したPDFを送るときの決まった件名に、Gmail のフィルターでラベルを付けます。取り込んだときに既読にする設定にはしません。

通知は届いたらすぐに処理します。 月払の契約では、猶予の期間が払込期月の翌月の1日から末日までとされている例があり、通知が届いた時点で残りが3週間を切っていることもあります。 1日でも早く募集人に回すほど、連絡の余裕が増えます。

代理店向けの画面で届く会社の分は、取り出しを習慣にします。 画面に通知が載ったことはメールで知らされる会社が多いので、そのお知らせのメールにもラベルを付け、PDFが届いていない会社があればチャットで事務の担当に促す小さな仕組みを足します。画面の取り出しが遅れると、この構成全体が遅れるからです。

入力データを集める

AIに渡すのは、通知のPDFだけです。 顧客台帳はAIに渡さず、ワークフローの側で証券番号と契約者名を突き合わせます。台帳には保有契約9,000件分の連絡先が入っており、読み取りにも下書きにも要らないからです。

過去の振替不能の回数は、募集人の連絡の仕方を変える材料です。 初めての不能なら「念のためのお知らせ」、3回目なら「払込の方法の見直しのご相談」と、連絡の意味が違います。 回数は下書きのAIに渡し、書き出しを選ばせます。

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

通知のPDFを base64 にして、Make an API Call の document のブロックに入れます。 指示とスキーマは保険会社によらず1つです。

取り出す項目は、どの会社の通知にもある項目と、会社によって書き方の違う項目に分けて考えます。

期限は、呼び方ごと写させるのがこの構成の要です。 第3章の（b）のとおり、「次回振替日」と「払込期限」は意味が違います。一覧には、期限の日付と並べて呼び方の原文を必ず出し、募集人が読み違えないようにします。

顧客台帳は、証券番号で Search Rows を引きます。 引けた行の契約者名のよみがなと、通知の契約者名を突き合わせます。通知が漢字、台帳がよみがなの会社もあるので、漢字とよみがなの両方の列を台帳に持たせ、どちらかが一致すれば一致とします。

損害保険と生命保険で、同じ項目でも中身が違うことに気をつけます。 自動車や火災の契約は年払や一時払の分割が多く、生命保険は月払が多いので、同じ「保険料」の欄でも1回分なのか、複数回分をまとめた額なのかが通知によって違います。 金額は書かれた数字のまま写させ、何回分かが書かれていれば premium と並べて原文を残します。

AIへ渡す前に整形する

1. ファイルの確認 … 添付がPDFであること、パスワードが付いていないことを確かめます。付いている会社の通知は、事務の担当が開いてから送り直します
2. 会社の特定 … 送信元のアドレスと件名から保険会社の候補を決め、AIが読み取った会社名と一致するかを確かめます
3. 件数の確認 … 通知に「計○件」と書かれていれば、AIが返した契約の数と合うかを確かめます。合わなければ読み取りの誤りを疑い、全件を確認の列に回します
4. 重複の確認 … 同じ証券番号・同じ振替日の行がすでに一覧にあれば、二重に回しません
5. ページの多い通知の分割 … ページの上限に近い通知は、ページで分けて呼びます

3番目が、読み飛ばしを止める関所です。 1件を読み飛ばすと、その契約者には誰からも連絡が行きません。合計の件数が通知に書かれていない会社では、PDFのページ数と1ページあたりの行数から目安を出し、極端に少なければ確認の列に回します。

AIに処理させる

させるのは、通知から契約ごとの項目を取り出すことと、通知に書かれた内容だけで連絡文の下書きを作ることの2つです。 主眼は前者の取り出しです。

1行目がいちばん守らせたいことです。 月払の契約の猶予期間を「払込期月の翌月の末日まで」と覚えさせて計算させると、解除の予告の期間を設けている会社や、年払・半年払の契約で、誤った期限が一覧に並びます。 期限が書かれていない契約は「記載なし」とし、事務の担当が保険会社に確かめます。

連絡文の下書きには、通知に書かれた事実と、代理店の連絡先だけを使わせます。 書き出しは過去の不能の回数で選ばせ、残高不足かどうかを契約者に問いただすような書き方はさせません。 不能の理由が「口座の解約」なら、新しい口座の手続きの案内に寄せます。

下書きのAIに渡すものと、書かせる部分は次のとおりです。

期限の記載が無い契約には、下書きを作りません。 期限を書けない連絡文は、契約者に「いつまでに」を伝えられず、かえって問い合わせを増やすからです。 事務の担当が保険会社に確かめて一覧に期限を書いた後に、下書きを作り直します。

指示内容を固定する

取り出し（1回目）の指示の例です。

あなたは保険代理店の事務の担当で、保険会社から届いた
口座振替不能の通知を読み取る担当です。
PDFに書かれていることだけを写してください。推測で補わないでください。

【取り出す項目（契約ごと）】
- policy_no ........ 証券番号。書かれた文字列をそのまま
- holder_name ...... 契約者名。書かれたとおり（漢字・かな）
- product .......... 保険種目（自動車、火災、医療、終身など。書かれたとおり）
- debit_date ....... 振替日
- premium .......... 振替できなかった保険料。書かれた数字のまま
- reason_text ...... 不能の理由の原文。書かれていなければ空
- reason_class ..... insufficient / account_closed / form_missing / other / not_stated
- next_debit_text .. 次の振替の日についての原文。無ければ空
- deadline_text .... 払込の期限や失効・解除の予定日についての原文。無ければ空
- deadline_date .... deadline_text に書かれた日付。日付が書かれていなければ空
- deadline_kind .... payment_due / grace_end / lapse / cancellation / other / not_stated
- payment_method_text .. 払込の方法の案内の原文。無ければ空

【厳守事項】
- 書かれていない項目は空にし、kind や class は not_stated にしてください。
- 期限の日付を計算しないでください。猶予の期間の一般的な決まりから
  日付を推定しないでください。
- 「次回振替日」は next_debit_text に入れ、deadline_text に入れないでください。
  期限としての記載がほかに無ければ、deadline_kind は not_stated です。
- 証券番号の桁を補ったり、記号を足したりしないでください。
- 通知の合計件数が書かれていれば total_count_text にそのまま写してください。
- 読めない文字がある項目は、読めた範囲を写し、unreadable_fields に項目名を入れてください。

【保険会社の候補】{insurer_hint}

「次回振替日を期限に入れない」を名指しで書くのは、AIがそれを期限と読みたがるからです。 「次回振替日に2回分を振り替えます」という文は、振替が次もできなければどうなるかを書いていません。 期限として扱わせると、第3章の（b）を自動で起こすことになります。

「一般的な決まりから推定しない」も明記します。 書かないと、AIは月払の猶予の期間を知識として持っているので、親切に日付を埋めてしまいます。

出力形式を固定する

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

{
  "insurer": "",
  "notice_date": "",
  "total_count_text": "",
  "contracts": [
    {
      "policy_no": "",
      "holder_name": "",
      "product": "",
      "debit_date": "",
      "premium": "",
      "reason_text": "",
      "reason_class": "insufficient | account_closed | form_missing | other | not_stated",
      "next_debit_text": "",
      "deadline_text": "",
      "deadline_date": "",
      "deadline_kind": "payment_due | grace_end | lapse | cancellation | other | not_stated",
      "payment_method_text": "",
      "unreadable_fields": [""]
    }
  ]
}

1つ目の理由は、会社ごとに違う通知を1つの形にそろえられることです。 不能の一覧は、どの会社の通知から来た行も同じ列になり、募集人は会社を気にせず期限の順に見られます。

2つ目は、deadline_kind で確認の列への振り分けが機械的に決まることです。 not_stated か other なら事務の担当の確認の列へ、それ以外は募集人へ回します。区分は enum で縛るので、値の揺れで振り分けが外れません。

3つ目は、原文と値を並べて持てることです。 deadline_text と deadline_date が両方あれば、一覧で原文を見て日付が正しく写されたかを確かめられます。

不能の一覧には、ワークフローが次の列を足して1行にします。

システムへ連携する

保険会社の画面には何も書き込みません。 この構成が出すのは、誰がいつまでに誰に連絡するかの一覧と下書きまでです。

募集人への通知は、期限までの日数が少ない順に送ります。 残りが7日を切る契約は、チャットの通知に加えて、事務の担当の確認の列にも載せ、翌日に連絡済みになっていなければ事務の担当から募集人に声をかけます。

人が確認する

1. 確認の列を先に見る … 期限の記載が無いもの、台帳と一致しないもの、件数が合わない通知。事務の担当が当日中に見ます
2. 期限の記載が無い契約は保険会社に確かめる … 代理店向けの窓口に問い合わせ、確かめた期限を一覧に書きます
3. 台帳と一致しない契約は通知のPDFで確かめる … 読み取りの誤りか、台帳の誤りかを見ます
4. 募集人が下書きを直して連絡する … 送るのは募集人です。連絡した日と手段を一覧に書きます
5. 期限の後に入金を確かめる … 保険会社の画面で確かめ、一覧の状態を変えます

3番目を省かないでください。 名前が一致しない契約を「たぶん読み違いだろう」と募集人に回すと、別の契約者に振替不能を知らせる恐れがあります。 必ずPDFを開いて確かめます。

目標は、240件をならして1件3分です。 大半は、募集人が下書きを読んで少し直して送るだけで済み、確認の列に回るのは1割前後という想定です。

例外に対処する

上から3行目までが、最初の数か月の確認の列の大半です。 会社ごとの通知の書き方に慣れてくると、どの会社のどの書き方が not_stated になりやすいかが分かり、保険会社への確かめ方も決まってきます。

記録を残す

• 受け取った通知のPDFと、受け取った日時、保険会社
• AIが返したJSONの全文と、件数の確認の結果
• 不能の一覧の行と、状態を変えた日時と人
• 募集人が送った連絡文（下書きからどこを直したか）
• 確認の列に回った理由と、保険会社に確かめた結果

連絡した日時の記録は、後から「連絡をもらっていない」と言われたときの材料になります。 一覧の状態の変更を、変えた人と日時ごと残します。

保険会社ごとの not_stated の件数も、月ごとに数えます。 特定の会社の通知だけ期限の記載が無いと分かれば、その会社の代理店向けの窓口に、期限の書かれた帳票が別にないかを確かめるきっかけになります。