取引先ごとの与信限度額と売掛金・受注残を毎日照らし合わせ、限度を超えた先と近づいた先に見直しの要否のコメント案を添えて知らせる

処理の起点を決める

毎朝7時台の時間主導型のトリガーで動かします。 夜間に販売管理と会計がCSVを出し終えている時刻を前提にします。受注のたびに動かすことはしません。 受注は1日に数百件あり、そのたびに3つのシステムの残高をそろえ直すと、途中の状態の数字で判定することになります。

動き始めたら、まずCSVの日付を確かめます。 受け渡しフォルダのCSVが前日の夜の出力でなければ、計算を始めずに財務のスペースへ「前日分のCSVが届いていない」とだけ投稿します。古い残高で判定した一覧を出すと、すでに入金された先を「超過」と知らせてしまいます。

トリガーは財務部の共有の管理用アカウントで作ります。 インストール型のトリガーは作った人のアカウントで動くため、担当者の個人アカウントで作ると、その人が異動したときに止まります。 失敗したときにはトリガーの持ち主へ失敗をまとめたメールが届くので、その宛先も財務部で見られるようにしておきます。

入力データを集める

質を決めるのは、下の2つです。 対応表が無いと、会計では入金済みなのに販売管理の側では残高が残っている先が出ます。同じ取引先を2社として数え、一方は超過、もう一方は余裕ありという一覧になります。

過去の記録は、AIが区分を付けるための材料です。 1日の使用率だけでは、一時的な山か、恒常的な不足かは分かりません。過去3か月の推移を渡すことで、「毎月少しずつ上がっている」という形を読めるようにします。

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

3つのCSVと台帳は、スプレッドシートに読み込んでから一度にまとめて扱います。 Apps Script ではスクリプトの中での計算は他のサービスを呼ぶより速く、範囲を1回でまとめて読み、計算してから1回で書き戻すのがよいとされています。1社ずつセルを読み書きすると、800社ではトリガーの1回の実行時間に収まりません。

計算の式は、1つに決めて文書にします。

使用額 ＝ 売掛金の残高 ＋ 未決済の受取手形 ＋ 受注残（出荷前の全件）
使用率 ＝ 使用額 ÷ 限度額
見込み使用率 ＝（使用額 ＋ 今後5営業日の出荷予定のうち受注残に未計上のもの − 今後5営業日の入金予定）÷ 限度額

受注残を「全件」にするか「出荷予定日が今月のものだけ」にするかは、第3章の（b）の原因でした。 どちらにするかを財務の責任者が決め、スクリプトにはその1つだけを書きます。ここが人によって違うままだと、自動にしても一覧の数字は信用されません。

AIへ渡す前に整形する

1. CSVの日付の確認 … 3つのCSVがすべて前日の夜の出力かを、ファイル名かファイルの中の基準日で確かめます。1つでも古ければ止めます
2. 名寄せ … 対応表で、販売管理と会計の取引先コードを1つにそろえます。枠を共有するグループは、グループの合計で使用率を出します
3. 対応表に無いコードの抽出 … どちらか一方のシステムにしか無いコードは、計算に入れずに「対応表に無い」として一覧の末尾に出します
4. 使用額と使用率の計算 … 「データの取得方法」の式で計算し、小数第1位まで残します
5. 帯の判定 … 使用率100％以上か見込み使用率100％以上を over、使用率90％以上を near、80％以上を watch とします。線は財務の責任者が決め、スクリプトのプロパティに置きます
6. 前日との差分 … 前日の帯、区分、使用率と比べ、新しく載った先、帯が上がった先、帯が下がった先に印を付けます
7. AIに渡す材料の組み立て … 一覧に載った先だけについて、過去3か月の使用率の推移、受注残の上位5件、入金の遅れの記録を1社1つのまとまりにします

5番目の線をAIに決めさせないでください。 80％か85％かは与信の方針で、AIの判断で毎日動くものではありません。 線をプロパティに置いておけば、方針が変わったときにもスクリプトを書き換えずに済みます。

7番目で、取引先の名称を渡すかどうかを決めます。 区分の判定に名称は要りません。取引先コードと数字だけを渡し、名称は通知を組み立てるときにスクリプトの側で付けます。

AIに処理させる

させるのは、一覧に載った先ごとに「なぜ枠に近づいたのか」の区分を付け、見直しの要否のコメント案を書くことです。 使用率の計算と帯の判定は前処理で終わっています。

区分は1社に1つだけ付けさせます。 入金の遅れがあって、取引も増えている先は、payment_delay を優先させます。 増枠を検討する前に回収を確かめるのが順序だからです。この優先順位も指示に書きます。

4行目が、いちばん起きやすい失敗です。 入金の遅れがある先について、何も言わなければ「資金繰りの悪化が懸念されます」と書きます。渡したのは入金の日付だけで、資金繰りの情報は渡していません。 この一文が営業に届くと、取引先への聞き方が変わってしまいます。

指示内容を固定する

あなたは商社の財務部で、取引先の与信の使用状況を確認する立場です。
与えられた数字と記録だけを見て判定してください。推測で埋めないでください。

【あなたの仕事】
一覧に載った取引先ごとに、与信の枠に近づいた理由の区分を1つ選び、
見直しの要否についてのコメント案を書いてください。

【区分の選び方】
- temporary_peak ...... 受注残の上位に大口の受注があり、
                         入金予定を反映した見込み使用率が下がる
- structural_growth ... 過去3か月の月末の使用率が毎月上がっており、
                         入金の遅れの記録が無い
- payment_delay ....... 入金の遅れの記録があり、売掛金の残高が増えている
- limit_outdated ...... 限度額を決めた日から見直しの予定日を過ぎている
- insufficient_data ... 推移の記録が2か月分に満たない、または判断の材料が足りない
複数に当てはまるときは、payment_delay を最優先にしてください。
迷ったときは insufficient_data を選んでください。

【厳守事項】
- 使用率・使用額・金額は、入力の値をそのまま書いてください。計算し直さないでください。
- evidence には、判定の根拠にした入力の項目名と値を書いてください。
- 限度額をいくらにすべきかを書かないでください。
- 出荷を止めるべきかどうかを書かないでください。
- 取引先の業績、資金繰り、信用状態について、入力に無いことを書かないでください。
- 入金が遅れた理由を推測しないでください。遅れた日数と回数だけを書いてください。
- コメント案は、営業向けに3文以内、財務向けに3文以内で書いてください。
- 営業向けのコメント案には、取引先に何を確かめればよいかを1つ書いてください。

【取引先ごとの入力】{accounts_json}
【帯の線】{thresholds}
【今日の日付】{today}

「計算し直さない」を明記しないと、使用率を自分で割り直します。 端数の扱いが前処理と違うので、通知の中で同じ取引先の使用率が2つの値で並ぶことがあります。数字は前処理の1か所でだけ作ります。

「迷ったら insufficient_data」も同じ考え方です。 材料が足りないときに structural_growth を選ぶと、営業が増枠の相談を始めてしまいます。わからないことを、わからないと返させます。

出力形式を固定する

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

{
  "results": [
    {
      "account_id": "C-01234",
      "band": "near",
      "reason": "temporary_peak | structural_growth | payment_delay | limit_outdated | insufficient_data",
      "review_needed": "yes | no | undecided",
      "evidence": [
        { "field": "", "value": "" }
      ],
      "comment_sales": "",
      "comment_finance": "",
      "question_to_customer": ""
    }
  ]
}

1つ目の理由は、reason を enum で絞れることです。 自由文で理由を書かせると、「一時的な増加」「一過性の要因」「スポット案件」と言い方が毎日変わり、判定の記録を後から数えられません。 区分が決まった値なら、「payment_delay が3か月続いた先」を記録から機械的に拾えます。

2つ目は、band をAIが書き換えていないかを確かめられることです。 band は前処理で付けた値をそのまま返させ、スクリプトの側で入力と一致するかを比べます。一致しなければ、その社の結果を捨てて「判定できず」とします。

3つ目は、evidence の数字を入力と突き合わせられることです。 field と value の組で返させ、スクリプトが入力の同じ項目の値と比べます。AIが書いた数字が入力に無い値なら、コメント案を通知に載せません。

システムへ連携する

Claude API は UrlFetchApp.fetch で呼びます。 method を post、contentType を JSON にし、headers に API キーを入れます。muteHttpExceptions を true にすると、失敗の応答でも例外を投げずに応答が返ります。 応答のコードを見て、失敗した社だけを後で回し直します。

API キーはスクリプトのプロパティに置きます。 スクリプトのプロパティは、そのスクリプトのすべての利用者に共有されるアプリ全体の設定の置き場所です。キーをスクリプトの本文に書かないでください。 帯の線もここに置きます。

Google Chat の受信 Webhook には、スペースあたりの上限があります。 spaces.messages.create のスペースごとの上限、毎秒1件が、そのスペースのすべての Webhook で共有されます。30社を1社1件で投稿せず、1件のメッセージにまとめます。 区分ごとに見出しを分け、新しく載った先を先頭に置きます。

営業へのメールは、担当者ごとに1通にまとめます。 1人の営業が5社を持っていれば、5社分を1通にします。Google Workspace のアカウントでは、メールの受信者数に1日あたりの上限があります。担当先の無い営業には送りません。

人が確認する

人が開くのは、新しく載った先、帯が上がった先、区分が変わった先です。 前日と同じ帯・同じ区分の先は「継続」とまとめ、財務は件数と社名を流し見ます。全社を開く設計にすると、第10章の10.0時間には収まりません。

1. over を最初に見る … 超過している先と、見込みで超える先。出荷を進めてよいかを、その日のうちに営業と決めます
2. payment_delay を次に見る … 入金の遅れの日付を会計の画面で確かめます。入金の消し込みが遅れているだけのことがあります
3. AIの区分を確かめる … evidence の数字を見て、区分が妥当かを判断します。違えば区分を直し、直したことを記録します
4. 営業へ確認を頼む … question_to_customer を参考に、営業が取引先に確かめます。メールの文面をそのまま取引先へ転送しないように、営業に伝えておきます
5. 見直しの決裁を回す … 増枠の相談は、与信管理の規程どおりに審査の資料をそろえて決裁へ回します

2番目を省かないでください。 会計の側で入金の消し込みが翌日にずれただけでも、データの上では入金の遅れに見えます。その先を payment_delay として営業に知らせると、営業は支払いの催促と受け取られかねない聞き方をします。

目標は、600件をならして1件1分です。 毎日30社のうち、時間を使って見るのは新しく載った先と状況が変わった先の5〜8社という想定です。

例外に対処する

上から3行目までが、最初の1か月の大半を占めます。 どれもAIの問題ではなく、名寄せと台帳の整備の問題です。 対応表に無いコードの一覧を毎日見て、1件ずつ表に足していくと、2か月ほどで落ち着きます。

記録を残す

• その日に読み込んだCSVのファイル名と基準日
• 取引先ごとの使用額、使用率、見込み使用率、帯（前処理の結果）
• AIに渡した入力と、返ってきたJSONの全文
• 人が区分を直した記録 … どの社を、どの区分からどの区分に変えたか
• 営業が取引先に確かめた結果と、その後の判断（増枠の決裁、一時的な超過の承認、回収の確認）
• そのとき使った帯の線と、台帳の限度額

最後の行を残すのは、線と限度額が後から変わるためです。 線を80％から85％に変えると、過去の一覧に載っていた先の意味が変わります。当時の線が残っていないと、なぜその日にその先が載ったのかを説明できません。