売掛金の入金予測から13週の資金繰り表を作る

処理の起点を決める

毎週月曜の始業前（定時実行）を起点にします。加えて、月次の締め処理が終わった翌日に1回走らせます。

前提が1つあります。前週の入金が会計に反映されていることを確認してから走らせてください。 反映前のデータで予測すると、入金済みの請求を「未入金」として扱い、見込みが実態より低く出ます。反映状況をチェックし、未反映なら処理を止めて通知する分岐を入れます。

入力データを集める

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

売掛金残高と入金実績： 販売管理システムと会計システムからCSVでエクスポートします。APIの有無と仕様は製品によって異なるため、この部分は利用環境に応じた個別確認が必要です。 日次のエクスポートで足ります。リアルタイム連携は必要ありません。

過去の遅延実績： ここが最も手間のかかる部分です。入金実績を「請求1件ごとに、支払期日から何日で入金されたか」という形に組み直す必要があります。入金明細と請求の突き合わせ（消込）が請求単位で残っていれば、そのまま使えます。残っていない場合は、この構成を作る前に消込の整備が必要です。

支払予定： 買掛金と給与は会計システムから、設備投資と一時的な支出は稟議や契約から人が入力します。ここは自動化の対象にしません。

AIへ渡す前に整形する

1. 入金と請求の突き合わせ … 一部入金、複数請求のまとめ入金、相殺、振込手数料の差引が混ざります。突き合わせられなかったものは、予測の対象から外して人へ回します。 無理に割り当てると学習データが汚れます
2. 遅延日数の算出 … 支払期日と実際の入金日の差を日数で出します。期日が金融機関の休業日なら翌営業日に寄せてから計算します。この調整をしないと、土日の分だけ「遅延」に見えます
3. 異常な取引の除外 … 債権譲渡、貸倒、値引き、返品による相殺は、通常の入金とは別の事象です。学習データから外します
4. 特徴量の作成 … 次のような項目を作ります

1. 学習期間と検証期間を時間で分ける … ここを間違えると、実運用で使えないモデルができます。 データをランダムに分けると、未来の入金実績を使って過去を予測する形になり、検証時の精度が実運用より高く出ます。「直近3か月を検証、それ以前を学習」のように、時間で切ってください

AIに処理させる

予測を生成AIにさせないでください。 表形式の数値データの予測では、勾配ブースティングのような表データ向けの手法のほうが精度が出て、どの特徴量が効いているかも確認できます。scikit-learn の HistGradientBoostingClassifier は、欠損値をそのまま扱えます（学習時に、欠損値のあるデータを左右どちらの枝へ送るかを分岐ごとに学習します）。カテゴリ変数も categorical_features で直接指定でき、10,000件以上のデータでは GradientBoostingClassifier より大幅に速いとされています。月1,800件の請求が36か月あれば約6万件になり、この条件に収まります。

生成AIの役割は説明文の下書きだけです。数値を作らせません。

指示内容を固定する

説明文を作らせる部分の指示です。

あなたは財務担当を支援する担当者です。
今週の資金繰り見込みと先週の見込みの差について、経営会議向けの説明文の
下書きを作ってください。

【厳守事項】
- 与えられた数値だけを使ってください。計算し直したり、
  記載のない数値を補ったりしないでください。
- 金額と週の対応を変えないでください。
- 「資金が不足する」「借入が必要」といった判断を書かないでください。
  差の内訳を事実として述べるだけにしてください。
- 予測は予測、実績は実績と明記してください。混ぜないでください。
- 差の大きい上位5件について、取引先の名前ではなく
  「支払サイトが翌々月の先」のような区分で説明してください。
- 200文字以内で書いてください。

【今週の週別見込み（標準ケース・悲観ケース）】
{forecast_this_week}

【先週の週別見込み】
{forecast_last_week}

【差の内訳（金額の大きい上位10件を区分別に集計したもの）】
{variance_breakdown}

取引先名を渡していない点に注意してください。 生成AIへ送るのは集計後の数値と区分だけにします。個別の取引先の支払遅延実績は、取引先の信用に関する情報です。

出力形式を固定する

{
  "as_of": "",
  "invoice_predictions": [
    {
      "invoice_no": "",
      "customer_code": "",
      "due_date": "",
      "amount": 0,
      "prob_on_time": 0.0,
      "delay_bucket": "0 | 1-10 | 11-30 | 31+",
      "predicted_week": "",
      "confidence": "high | medium | low",
      "excluded_reason": ""
    }
  ],
  "weekly_forecast": [
    {
      "week_start": "",
      "inflow_standard": 0,
      "inflow_pessimistic": 0,
      "outflow_scheduled": 0
    }
  ],
  "review_list": [
    { "customer_code": "", "amount": 0, "prob_on_time": 0.0, "reason": "" }
  ]
}

金額は数値型で返します。文字列にするとカンマ入りになり、後段の計算が壊れます。

構造化出力を使う場合、Claude API では output_config.format にJSONスキーマを指定します（旧来の output_format は output_config.format へ移行済みです）。ただしスキーマ側で数値の範囲（minimum / maximum）や文字列の長さを制約することはできません。 確率が0から1の範囲にあるか、金額が負になっていないかは、受け取ったあとに自分で検算してください。

システムへ連携する

出力先は3つです。

Excel への書き込みは、様式をテンプレート化し、週と項目の交点に値を差し込む方式にします。予測値のセルと、確定した実績のセルを、色で区別して表示してください。 混ざると、金融機関に提出する場面で説明できなくなります。

人が確認する

資金繰り表の確定は、必ず財務責任者が行います。運用が安定しても変えません。

理由は、資金繰りの判断が支払の遅延や借入の実行に直結するためです。予測が外れたときの影響は、工数では測れません。

人が行うのは次の3つです。

1. 上位30社と大口先の個別確認 … 遅延確率が高い先、金額が大きい先は、確率ではなく事実を確認します
2. 支払予定の入力と確認 … 設備投資や一時的な支出は自動では拾えません
3. 資金繰り表の確定 … 予測をそのまま使わず、悲観ケースを見て判断します

この構成で減らしているのは「集める時間」であって、「判断の責任」ではありません。

例外に対処する

記録を残す

• 各週の予測値（請求単位と週別集計の両方）
• 実際の入金と、予測とのずれ
• 人が確認した先と、その結果（入金予定日の変更など）
• 財務責任者が確定した資金繰り表の版
• 使用したモデルの版と、学習に使った期間

「実際の入金と予測とのずれ」の記録が、この構成の中心です。 これがなければ、精度が上がっているのか下がっているのかが分かりません。

記録する形は「取引先区分ごとの、週別入金額の誤差率」にします。「支払サイトが翌々月の先は、いつも1週遅れる」と分かれば、特徴量を足すか、運用で調整できます。