信用調査会社から届く取引先の変動のお知らせメールを読み、取引先台帳と与信の残高に照らして、確かめるべきものを財務担当に回す

処理の起点を決める

お知らせのメールにラベルが付いたことを起点にします。 Gmail の側で、信用調査会社の送信元アドレスと件名の決まった語でフィルタを作り、「与信お知らせ」のラベルを付けます。Zap はこのラベルだけを見ます。

New Email Matching Search を使わないのは、取りこぼしを避けるためです。 Zapier のヘルプでは、New Email Matching Search は直近1時間のメールが対象で、Zap を止めていた間に届いたメールは拾われません。 New Labeled Email は期間の制限が無く、保守で Zap を止めた後でも、ラベルの付いたメールを拾い直せます。

フィルタの条件は、送信元のアドレスだけにしないでください。 信用調査会社からは、モニタリングのお知らせのほかに、請求や新サービスの案内も同じアドレスから届くことがあります。件名の決まった語も条件に足し、お知らせだけにラベルが付くようにします。 外れたものは、例外処理の「変動が無い」で拾います。

処理が終わったメールには、別のラベル「処理済み」を付けます。 Gmail のアクションの Add Label to Email で付けます。「与信お知らせ」が付いていて「処理済み」が無いメールが、まだ処理されていないメールです。 財務担当はこの差を週に1回見ます。

入力データを集める

質を決めるのは、取引先台帳の企業コードの列です。 お知らせの商号は信用調査会社の登録名で、自社の台帳の名称と一致しないことがあります。企業コードで結べば、名前の表記ゆれに左右されません。 信用調査会社の側でモニタリングを一括登録するときに企業コードを使っているなら、その一覧から台帳に写せます。

判定の基準表は、AI への指示の材料です。 どの変動を悪化の兆しとみるかは会社ごとの取り決めで、財務部が決めたものを毎回 AI に渡します。 最初の版は、次のくらいの粒度で足ります。

代表者と商号の変更を要確認にしているのは、本文だけでは良し悪しが決まらないからです。 後継への交代も、経営の行き詰まりによる交代も、お知らせの上では同じ「代表者の変更」です。

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

メールの本文はトリガーがそのまま渡します。取引先台帳と売掛残高は、取引先ごとにループの中で引きます。

企業コードで引けず、商号でも1行に決まらないときは、照合不可として残します。 似た商号の別会社に結びつけると、取引の無い会社の倒産の知らせを、取引先の知らせとして回すことになります。

判定の基準表は、ループの中で毎回読み直しません。 1通の処理の途中で基準表が書き換わると、同じメールの中で判定の基準が変わるからです。Zap の最初に1回読み、その版をすべての回で使います。

売掛残高は毎朝の書き出しなので、当日の入金は反映されていません。 確認台帳には、残高の書き出し日時も一緒に書きます。 財務担当が読むときに、どの時点の数字かが分かるようにします。

AIへ渡す前に整形する

1. 本文を文字にそろえる … HTML のメールは本文の文字だけにします（Formatter）。表の形の本文は、行の区切りを残します
2. 定型の文を落とす … 配信停止の案内、利用規約の文、署名を落とします。AI に渡す文が短いほど、取引先の取り違えが減ります
3. 受信日時を添える … 変動の日付が本文に無いときの基準にします
4. 判定の基準表を添える … 変動の項目ごとの扱いを、AI の指示に入れます
5. 重複の検知 … 同じ企業コード・同じ変動の項目・同じ変動後の値の行が、確認台帳の直近にあれば、二重の書き込みとして印を付けます

5番目は、連休の後に効きます。 同じ変動が複数のお知らせに載って届くことがあり、そのまま書くと同じ取引先が確認台帳に何行も並びます。

AIに処理させる

AI のステップは2つあります。 1つ目はメールの本文から取引先ごとの変動を一覧にすること、2つ目は取引先ごとに変動が信用の悪化の兆しにあたるかを判定することです。

1つ目で抜き出す項目

2つ目で判定すること

判定の根拠は、基準表と本文の文に置きます。 2つ目のステップには、変動の行と基準表だけを渡し、残高も与信限度額も渡しません。 判定と残高を混ぜないためです。

優先度は、判定と残高から表の関数で決めます。

50％の線は例です。 財務部が決め、表の関数の1か所で持ちます。AI の指示には書きません。 線を変えるたびに指示を変えると、どの判定がどの線で出たかが追えなくなります。

3行目は、指示に書かないと起きます。 代表者の変更のお知らせに「経営の立て直しのためとみられる」と書き足します。それらしい理由が付くと、読む人の判断がそれに引きずられます。

指示内容を固定する

2つ目のステップ（判定）の指示です。

あなたは商社の財務部で、取引先の信用の変動のお知らせを読む立場です。
1件の変動について、信用の悪化の兆しにあたるかを判定してください。
判定には【変動】と【判定の基準表】だけを使ってください。

【判定の選び方】
- deteriorating ... 基準表で「悪化の兆し」とされた変動。
                    評点・リスクスコアが変動前より下がった場合も含む
- neutral ......... 基準表で「中立」とされた変動。評点が上がった場合
- needs_review .... 基準表に無い変動。変動前か変動後の値が無く、
                    上がったか下がったかが決められない場合
迷ったときに neutral を選ばないでください。

【厳守事項】
- 変動の理由や背景を書かないでください。本文に無いことを推測しないでください。
- 取引をどうすべきか、与信限度額をどうすべきかを書かないでください。
- 急ぐかどうかを書かないでください。
- evidence には、判定の根拠にした本文の文をそのまま写してください。
- basis には、当てはめた基準表の行をそのまま写してください。
- 本文の値を書き換えたり、単位をそろえたりしないでください。

【変動】{change_item}
【判定の基準表】{criteria}

「迷ったときに neutral を選ばない」が、この指示でいちばん大事な一文です。 中立と判定された行は記録のみになり、人の目に入りません。 迷ったものは needs_review に寄せ、人が読む側に残します。

「急ぐかどうかを書かない」も要ります。 書かせると、AI はそれを優先度のつもりで書き、表の関数の優先度と食い違ったときに、読む人がどちらを信じるかで迷います。

出力形式を固定する

1つ目のステップは配列、2つ目は1件ずつの判定で受け取ります。

{
  "corp_code": "",
  "trade_name": "",
  "change_item": "",
  "before": "",
  "after": "",
  "change_date": "",
  "judgement": "deteriorating | neutral | needs_review",
  "evidence": "",
  "basis": ""
}

1つ目の理由は、ループで回せることです。 1つ目のステップが返す配列の1要素が、確認台帳の1行になります。1通に何社入っていても、同じ処理で回ります。

2つ目は、judgement と優先度を別の列に置けることです。 judgement は AI が埋め、優先度は表の関数が判定と残高から出します。線を変えても直すのは関数だけで、過去の判定はそのまま読み直せます。

3つ目は、evidence と basis で確認が速くなることです。 財務担当はメールを開かずに、どの文をどの基準に当てはめたかを一覧で読めます。

確認台帳の1行は、次の列を持ちます。

システムへ連携する

知らせのメールには、至急と要確認の件数と、確認台帳へのリンクだけを載せます。 取引先名や残高はメールの本文に書きません。数字は確認台帳の中に留めます。

営業への連絡は、財務担当が確かめてから行います。 Zap から営業に直接知らせる経路は作りません。

人が確認する

1. 至急の行から読む … evidence と basis を読み、必要ならお知らせのメールを開きます
2. 残高の時点を確かめる … 書き出し日時が前日なら、当日の入金を会計システムで見ます
3. 担当の営業に確かめを頼む … 取引先の最近の様子、支払の遅れの有無を聞きます
4. 結果を確認台帳に書く … 与信限度額を見直す、様子を見る、などを記録します
5. 要確認の行は、その日のうちに目を通す … needs_review は基準表の穴でもあります

5番目で needs_review が多い変動の項目は、基準表に足します。 足すかどうかは財務部が決めます。AI の判定を見て基準表を直すことはあっても、基準表を AI に作らせることはしません。

記録のみの行は、週に1回まとめて流し見ます。 neutral の判定が本当に中立だったかを、数件ずつ抜き出して確かめます。

財務担当が判定を覆したら、確認台帳に覆した理由を書きます。 neutral を要確認に変えた件が同じ変動の項目に続くなら、基準表のその行の扱いを見直す合図です。

例外に対処する

1行目の照合不可を至急に準じて扱うのは、取り違えより見落としのほうが重いからです。 照合できないまま記録のみにすると、台帳の企業コードが欠けている取引先のお知らせは、ずっと人の目に入りません。

最後の行は、AI の判定に頼らない安全弁です。 本文に倒産や事業停止にあたる語があれば、表の関数で優先度を至急に上げます。

記録を残す

• お知らせのメールそのもの（Gmail に残し、確認台帳にメールの ID を書く）
• AI の出力（変動の一覧、judgement、evidence、basis）
• そのとき使った判定の基準表の版
• 照合に使った台帳の行と、残高の書き出し日時
• 財務担当の確認の結果と、確認した人・日時
• 照合不可の件数と、企業コードが欠けていた取引先

3つ目で基準表の版を残すのは、基準表が後から変わるためです。 所在地の変更を中立から要確認に変えたら、過去の判定がどちらの基準で出たかが分からないと、見直す範囲が決まりません。

最後の行は、台帳の整備の材料になります。 照合不可が続く取引先は、企業コードを台帳に足します。