滞留している売掛金の督促の優先順位を決めて連絡文の下書きを作る

処理の起点を決める

毎月、消込が確定した翌営業日の朝を主な起点にし、加えて週1回、滞留中の明細の状態を更新します。Make では、実行間隔を「at regular intervals」「once」「daily」「weekdays（月〜金）」「weekly」「monthly」「specified dates」「on demand」から選べます。既定は15分ごとで、最短の間隔は契約プランによって変わります。この業務は月次と週次で足ります。

消込が確定していない状態で走らせないでください。 入金済みの請求を督促すると、取引先に誤った連絡が届きます。消込確定フラグを見て、未確定なら処理を止める分岐を必ず入れます。

入力データを集める

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

明細と入金実績： 販売管理システムと会計システムからCSVでエクスポートします。APIの有無と仕様は製品によって異なるため、この部分は利用環境に応じた個別確認が必要です。

入金実績は請求番号つきで取り出す必要があります。 「いつ入金があったか」だけでは、支払期日から何日遅れたかを計算できません。UC-0007のような消込が請求単位で動いていることが前提で、残っていない場合は消込の整備が先です。

やり取りの記録： 請求番号または取引先コードで、直近3か月のメールと備考を集めます。

AIへ渡す前に整形する

1. 滞留日数の算出 … 支払期日が金融機関の休業日なら翌営業日に寄せてから、処理日との差を出します。この調整をしないと、土日の分だけ全社が「遅延」に見えます
2. 通常の入金ではないものの除外 … 相殺、値引き、返品、債権譲渡、手形の期日到来待ちは遅延とは別の事象です。滞留一覧から外します
3. 取引先ごとの分布を作る … 過去24か月の入金実績から、取引先ごとに「支払期日から何日で入金されたか」の中央値・75％点・90％点・最長を出します。pandas の DataFrameGroupBy.quantile は q に0から1の値（既定は0.5＝中央値）を渡して分位点を返し、値が2点の間に落ちる場合の扱いを interpolation（linear / lower / higher / midpoint / nearest）で選べます
4. 実績の少ない先を分ける … 入金実績が5件未満の先は分位点が当てになりません。「実績なし」にし、金額と支払条件だけで扱います
5. AIへ渡す対象の絞り込み … 「いつもと違う遅れ」と滞留31日以上の明細だけにします

AIに処理させる

役割を3つに分けます。ここを混ぜると、検算できない数字が督促リストに載ります。

入金の見込みを生成AIに出させないでください。 「いつ払いそうか」は、その取引先の過去の遅延日数の分布が答えです。分位点で出せば、なぜその日付になったかを実績で説明できます。誤差が大きければ機械学習へ進む道もありますが、まず分位点で足りるかを測ってください。

優先順位もAIに決めさせません。 式を人が決めます。

優先度点 ＝ 金額点 × 遅れの異常さ点 × 回収の難しさ点

金額点         1：100万円未満 → 5：3,000万円以上（社内の基準額で5段階）
遅れの異常さ点  1：中央値以内 ／ 2：75％点以内 ／ 3：90％点以内
               4：90％点超 ／ 5：過去最長を超えた
回収の難しさ点  1：請求書の再発行待ち ／ 2：担当者の変更 ／ 3：検収でもめている
               4：理由が読み取れない ／ 5：こちらの連絡に反応がない

この重みは自社で決めます。 3つを掛けるのは、「金額は大きいが毎回の遅れの範囲内」という明細を上位に置かないためです。式を表に出せば、なぜこの順番なのかを営業にも説明できます。

指示内容を固定する

滞留の理由を読み取らせる部分です。

以下のやり取りと備考から、この請求が未入金のままである理由を読み取ってください。

【厳守事項】
- 書かれていることだけを根拠にしてください。推測で理由を作らないでください。
- 根拠になる箇所を quote に原文のまま引用してください。
  引用できない理由は挙げないでください。
- 理由が読み取れない場合は reason を "unknown" にしてください。
- 取引先の信用、倒産の可能性、取引を止めるべきかを書かないでください。

【理由の区分】検収待ち / 請求書の再発行待ち / 担当者の変更 /
支払条件の認識違い / 先方の社内決裁待ち / 連絡に反応なし / unknown

【やり取り・備考】{correspondence}

連絡文の下書きを作らせる部分です。

取引先への連絡文の下書きを作ってください。

【厳守事項】
- 与えられた事実（請求番号、請求額、支払期日、滞留日数、理由）だけを使うこと。
- 法的手続き、遅延損害金、取引停止、信用に関する記述をしないこと。
- 断定的な催告ではなく、状況の確認を依頼する文にすること。
- 理由が "unknown" の場合は理由に触れず、確認のお願いだけを書くこと。
- 300文字以内で、【区分】の語調に従うこと。

【区分と語調】
主要：まずこちらの確認不足の可能性に触れ、照会の形にする
通常：事実を示し、入金予定日の回答を依頼する
新規：支払条件の認識違いの可能性に触れ、条件を再掲する
少額：簡潔に。請求書の再送を申し出る

「法的手続きと遅延損害金を書かせない」の1行が要です。 これらは自社の債権管理規程に沿って人が判断する事項で、文面に一度入ると取引関係に戻れません。「取引を止める」「信用が不安だ」も書かせません。 与信の判断は UC-0032 の領域で、この仕組みの外です。

出力形式を固定する

{
  "items": [
    {
      "invoice_no": "", "customer_code": "",
      "customer_tier": "main | normal | new | small",
      "outstanding_amount": 0, "overdue_days": 0,
      "expected_payment_date": "",
      "delay_flag": "usual | unusual | no_history",
      "reason": "", "quote": "", "excluded_reason": "",
      "amount_score": 0, "anomaly_score": 0, "difficulty_score": 0,
      "priority_score": 0,
      "draft_message": "", "needs_sales_review": true
    }
  ]
}

点数の内訳を3つとも返させるのは、順位の根拠を画面に出すためです。Claude API の構造化出力は output_config.format にJSONスキーマを指定します（旧 output_format は非推奨）。ただし minimum / maximum などの数値制約と minLength / maxLength などの文字列制約は指定できません。 点数が想定の範囲に収まっているかは、受け取ったあとに検算してください。

システムへ連携する

ワークフローに送信のアクションを置かないでください。 設定を1か所変えれば送れてしまう構成にすると、承認の運用が形骸化します。営業への確認依頼は、優先度の上位と主要取引先に限って通知します。全件を投げると、Beforeの「返ってこない」が残ります。

人が確認する

全件、人が確認します。自動送信はしません。 誤った督促は、入金済みの請求や、検収が終わっていない請求への催促につながります。どれも、次の受注に響きます。

最後の行を省かないでください。 理由が分からないまま送ると、こちらの請求漏れや検収の未了が原因だった場合に、取引先へ非を押しつけることになります。

例外に対処する

記録を残す

• 各月の滞留一覧（請求単位）と、計算に使った分位点
• AIが読み取った理由と、根拠として引用した原文
• 優先度点の内訳（金額点・遅れの異常さ点・回収の難しさ点）
• AIの下書きと、人が修正して実際に送った文面の両方
• 送付日、送付者、相手の回答、次に確認する日

4つ目を別々に残してください。 後で交渉になったとき、どこまでが機械の出力で、どこからが自社の意思表示だったのかが分かる必要があります。