外貨建ての売上の請求と回収の実績から、通貨別・月別の外貨の入金額を幅で見込み、為替予約の量の案を財務担当に示す

処理の起点を決める

月次の締めの翌営業日の朝6時に、タスクスケジューラで動かします。 会議は第5営業日なので、担当者が要確認の取引先を確かめる時間を3営業日残すためです。締めの前の残高で動かすと、月末に入った入金が消し込まれておらず、入った請求を「未入金」として見込むことになります。

消込の終わりを確かめてから動かします。 販売管理システムの CSV に、締めの処理を終えた日時の列があれば、それが前月末より後かを見ます。終わっていなければ処理を止め、担当者に通知します。 1日遅れても、半端な残高で見込むよりよいからです。

月の途中でも、担当者が手で動かせるようにします。 大口の入金が月の半ばに入ったときや、取引先の支払の延期の連絡があったときに、会議の前に見込みを出し直すためです。 手で動かしたときも、同じ記録を残します。

入力データを集める

質を決めるのは、入金の記録が請求に充てられているかです。 1回の送金で複数の請求をまとめて払う取引先は多く、どの請求に充てたかが消込に残っていれば、請求ごとの遅れが数えられます。 残っていなければ、その取引先は取引先単位でしか遅れを数えられません。

一部入金は、充てた額ごとに分けて扱います。 請求額の8割だけ入金され、残りが翌月に入る取引先があります。請求を「入金済み」か「未入金」かの2つで扱うと、残りの2割の遅れが消えます。

人の上書きの表も入力です。 前の月に担当者が営業に確かめて置き直した入金の月は、その請求が入金されるまで、モデルの見込みより優先します。

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

販売管理システムからは CSV の出力だけを使います。 データベースに直接つなぐ口があれば読み取り専用で使えますが、まずは画面からの出力で始め、出力の列の並びを固定します。 列の並びが変わったら処理を止めます。

学習用のデータは、入金が済んだ請求だけから作ります。 まだ入金されていない請求を学習に入れると、遅れの区分が決まっていないので、「遅れている請求」が「それ以降」として数えられず、遅れが少なく見えます。 ただし直近の数か月は、期日から日が浅い請求ほど入金済みが多いという偏りがあるので、学習に使うのは、期日から4か月以上たった請求までにします。

AIへ渡す前に整形する

1. 請求と入金の結び付け … 消込の記録で、入金を請求ごとに充てます。一部入金は充てた額ごとの行にします
2. 遅れの区分の作成 … 入金日の月が、支払の期日の月から見て「同じ月」「翌月」「翌々月」「それ以降」のどれかを付けます
3. 除くものの印 … 前受金、相殺、貸倒れの処理をした請求、取引先との係争中の請求に印を付け、学習と見込みから外します
4. 取引先の履歴の特徴量 … 取引先ごとの直近12件の遅れの日数の中央値、期日どおりの割合、最後の入金からの日数を、見込む時点より前の記録だけで作ります
5. 請求の特徴量 … 通貨、金額（対数）、決済の条件、請求から期日までの日数、期日の月、期日を過ぎた日数を作ります
6. 為替予約の台帳の整理 … 通貨別・受渡の月別に、売りの予約の残高を集計します

4番目の「見込む時点より前の記録だけで」を守らないと、評価がよく見えすぎます。 学習のときに、その請求より後の入金の記録から「取引先の遅れの中央値」を作ると、答えの一部を特徴量に入れたことになります。 本番では未来の記録は無いので、評価の成績どおりには当たりません。

3番目の係争中の請求は、見込みの表の外に別の一覧で出します。 品質の不具合で支払を止められている請求は、払われる月の見込みが立ちません。見込みに入れると、入らない外貨に予約を当てることになります。

AIに処理させる

させるのは、未入金の請求ごとに、どの月に入金されるかの確率を出すことです。 通貨別・月別の積み上げと、予約の量の案は、その確率から決まった手順で計算します。

シミュレーションは、取引先ごとにまとめて揺らします。 同じ取引先の請求は、遅れるときは一緒に遅れます。請求ごとにばらばらに揺らすと、遅れが打ち消し合って幅が狭く出ます。 そこで1回の試行ごとに、取引先ごとに1つの乱数を引き、その取引先のすべての請求の区分を同じ乱数で決めます。

予約の量の案に下側の額を使うのは、第1章で書いた理由です。 中央の額に割合を掛けると、入金が遅れた月に、受け渡す外貨が足りなくなる確率が高くなります。 どの点を使うかは規程で決めることなので、設定の表で10％点から変えられるようにしておきます。

1行目を入れていないことを、資料にも明記します。 見込みの表を見た人が、円に直した額や、相場の見通しが入っていると思わないようにです。この構成が見込むのは「何月に何ドル入るか」だけです。

指示内容を固定する

この構成は生成AIに指示を出しません。 モデルへの指示にあたるのは、Python の処理の設定と、学習と評価の手順です。

【学習のデータ】
- 対象：外貨建ての請求のうち、入金が済み、支払の期日から4か月以上たったもの
- 除く：前受金、相殺、貸倒れの処理、係争中の印があるもの
- 目的の変数：遅れの区分（0=期日の月、1=翌月、2=翌々月、3=それ以降）
- 期間：直近24か月

【特徴量】（見込む時点より前の記録だけで作る）
- 取引先の直近12件の遅れの日数の中央値（履歴が無ければ NaN）
- 取引先の期日どおりの割合（履歴が無ければ NaN）
- 最後の入金からの日数
- 通貨（カテゴリ）、決済の条件（カテゴリ）、国（カテゴリ）
- 金額（対数）、請求から期日までの日数、期日の月、期日を過ぎた日数

【モデル】
- HistGradientBoostingClassifier
  categorical_features="from_dtype"
  early_stopping="auto"
- 評価：TimeSeriesSplit(n_splits=5, gap=1)。請求の期日の月の順に並べて分ける

【確率の確かめ方】
- 区分ごとに、出した確率と実際にその区分になった割合を10の階級で比べる
- 確率が0.7前後の請求のうち、実際にその区分になったのが7割前後かを見る
- ずれが大きければ、CalibratedClassifierCV（method="sigmoid"）で較正する

【見込みの出力】
- 未入金の請求ごとに4区分の確率
- 取引先ごとに同じ乱数で区分を決める1万回のシミュレーション
- 通貨別・月別の10％点・50％点・90％点
- 過去6か月の見込みで、実際の入金額が10％点と90％点のあいだに入った割合

「確率の確かめ方」を入れておかないと、確率の数字が独り歩きします。 公式の説明では、較正された分類器とは、predict_proba の値をそのまま確からしさとして読めるもので、0.8前後と出した標本のおよそ8割が実際にその区分になる状態とされています。シミュレーションは確率をそのまま使うので、確率がずれていれば、幅もずれます。

較正の方法は、まず sigmoid にします。 公式の説明では、isotonic はデータが十分にある（およそ1,000件を超える）ときには sigmoid と同じかよい成績になる一方、少ないデータでは過学習しやすいとされています。通貨によっては請求の件数が少ないので、sigmoid から始めます。

最後の行が、見込みの幅を信じてよいかの目安です。 10％点から90％点のあいだには、本来8割の月が入るはずです。過去6か月で半分しか入っていなければ、幅が狭すぎます。 取引先ごとにまとめて揺らす処理が効いていないことが多い理由です。

出力形式を固定する

見込みの表は、通貨別・月別の行で出します。

要確認の一覧は、取引先ごとの行で出します。

{
  "run_id": "",
  "as_of": "YYYY-MM-DD",
  "customer_code": "",
  "currency": "",
  "open_amount": 0,
  "invoices": [
    { "invoice_no": "", "due_date": "", "amount": 0,
      "proba": { "due_month": 0.0, "plus1": 0.0, "plus2": 0.0, "later": 0.0 },
      "flags": ["split_probability", "low_history", "overdue"] }
  ],
  "history_summary": { "median_delay_days": 0, "on_time_ratio": 0.0, "n_history": 0 },
  "override": { "month": "", "by": "", "note": "" }
}

1つ目の理由は、確率と人の上書きを別の項目に置けることです。 proba はモデルが埋め、override は担当者が営業に確かめて書きます。上書きがあればそちらを使い、無ければ確率を使う、という規則が処理の側で決まります。

2つ目は、flags で要確認の理由が分かることです。 split_probability は、いちばん高い区分の確率が0.5未満で金額が上位の請求、low_history は履歴が3件未満の取引先、overdue は期日を過ぎた請求です。担当者は理由ごとに、営業に何を聞けばよいかが分かります。

3つ目は、history_summary で根拠を説明できることです。 会議で「なぜこの取引先は翌月に置いたのか」と聞かれたときに、過去の遅れの中央値と期日どおりの割合で答えられます。

システムへ連携する

どのシステムにも書き込みません。 見込みの表は共有フォルダに置くだけで、為替予約の台帳には、会議で決めて実際に結んだ予約だけが、従来の手順で入ります。 案が台帳に紛れ込む経路を作りません。

規程の割合は、コードに書かずに設定の表に置きます。 規程が改まったときに、財務部の手で直せるようにするためです。設定の表を誰がいつ変えたかは、ファイルの版の履歴で残します。

人が確認する

人が確かめるのは、要確認の一覧と、追加の量の案の根拠です。 要確認でない取引先は、見込みの表の数字として使います。

1. split_probability の大口の請求を先に見る … 入金の月が割れていて、額が大きいもの。営業に入金の予定を確かめ、override に書きます
2. overdue の請求を見る … 期日を過ぎたもの。遅れの理由が係争なら、係争中の印を付けて見込みから外します
3. low_history の取引先を見る … 取引を始めたばかりの取引先。契約の条件と、初回の入金の様子を営業に確かめます
4. 追加の量の案を確かめる … 下側の額、規程の割合、予約の残高を並べ、計算の筋を確かめます
5. 会議で決める … 相場の見方と銀行の枠を含めて、結ぶ量と時期を決めます

2番目を省かないでください。 期日を過ぎた請求は、モデルが「翌月」に高い確率を付けることがありますが、遅れの理由が品質の不具合なら、翌月に入る見込みはありません。 理由はモデルの外にあります。

目標は、300社をならして1社2分です。 要確認に回るのは3割前後という想定で、それより多い月は、消込の遅れか、新しい取引先の増加が起きています。

例外に対処する

下から2行目は、会議でいちばん大事な行になることがあります。 入金が遅れて見込みが下がると、すでに結んだ予約が規程の上限を超える月が出ます。 案が0というだけでなく、超えていることを示すのは、その手当てを会議で話すためです。

記録を残す

• 処理を動かした日時、使った CSV のファイルと行数
• 学習に使った期間、特徴量の一覧、モデルの版と設定
• 評価の結果（区分ごとの確率と実際の割合、幅に入った割合）
• 請求ごとの確率、通貨別・月別の分布の点、追加の量の案
• そのときの規程の割合と予約の残高
• 人の上書きの記録 … どの請求を、どの月に、誰が、何を根拠に置き直したか
• 会議で決めた予約の量と、案との差

5つ目で「そのときの規程の割合と予約の残高」を残すのは、後から案を検算できるようにするためです。 規程が改まったり予約を結んだりすると、同じ見込みからでも案が変わります。

最後の行は、モデルの見直しの材料になります。 案と決めた量の差が毎月同じ方向にずれていれば、会議が見込みを信じていない理由が、どこかにあります。