取引先の決算データと支払の状況から社内格付を毎月見直し、格下げの候補と理由を財務部に出す

処理の起点を決める

月次の締めで、入金の消込が終わった翌営業日の朝に動かします。 入金の記録が締まる前に動かすと、月末に入った入金が「遅れ」として数えられ、払っている取引先を格下げ候補に挙げてしまいます。 消込の完了は経理の締めの手順に1行足して、ファイルの置き場に完了の印を置く形にします。印が無ければ動かず、翌朝に再び確かめます。

決算が届くたびに動かす形にはしません。 1社ずつ候補を出すと、格付の会議の前に一覧を作り直す手間が残ります。月1回まとめて出し、会議の資料の形で渡します。

例外として、入金が予定日から30日以上遅れた取引先は、その週のうちに単独で出す設定を足せます。会議を待つあいだに出荷を続けてよいかを決めるためで、確率の計算は月次と同じものを使います。

入力データを集める

質を決めるのは、いちばん下の行です。 モデルは「過去に支払の問題が起きた取引先は、その前の12か月にどういう数字だったか」から学びます。何を「支払の問題」と呼ぶかを先に決めます。 本記事では、60日を超える遅れ、支払条件の変更の依頼（サイトの延長・分割）、法的整理・私的整理の申し出のどれかが起きたことを、問題が起きたと数えます。

「決算の入手の状況」を別に持つのは、決算が来ないこと自体が材料だからです。 毎年届いていた決算書が今年は来ない、届く時期が年々遅くなる、という変化は、数字そのものより先に出ることがあります。

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

販売管理からは、請求ごとの行で取ります。 月ごとの入金額の合計だけでは、「3件の請求のうち1件だけ遅れた」という形が消えます。遅れた日数は、入金予定日と入金日から自分で計算します。 販売管理の画面に出ている「延滞日数」は、締めの時点の数字で、すでに入金された分が消えていることがあります。

取引先の突き合わせは、取引先コードで行います。 決算データの表は社名で入っていることが多いので、最初に取引先コードの列を足すのが準備作業です。 社名で突き合わせると、「株式会社」の前後や支店名で別の会社になり、決算の無い取引先が実際より多く見えます。

学習の材料は、過去5年分の月末ごとの断面で作ります。 各月末の時点で手元にあった数字だけを使い、その後12か月に問題が起きたかを答えにします。その時点でまだ届いていない決算の数字を使わないことが、いちばん大事な点です。 届く前の決算を使って学ぶと、検証では当たっているのに、本番では当たりません。

AIへ渡す前に整形する

1. 取引先コードでそろえる … 3つの表を取引先コードでつなぎます。つながらない取引先は一覧の最後に別に出します
2. 決算の指標を作る … 自己資本比率（純資産÷総資産）、売上高経常利益率、有利子負債の月商倍率、現預金の月商倍率、売上の前期比、債務超過かどうか
3. 支払の状況を数える … 直近3か月と12か月それぞれで、遅れた回数、最大の遅れた日数、一部入金の回数。支払条件の変更の依頼の有無
4. 前期からの変化を作る … 自己資本比率と利益率の前期との差。2期分そろわない取引先は、差を空にして「前期なし」の印を立てます
5. 欠けを埋めない … 決算書が無い取引先は、決算の指標を平均で埋めず、「決算なし」の印を立てます。平均で埋めると、決算を出さない会社が「平均的な会社」に見えます
6. 外れ値を抑える … 利益率や倍率は、売上がごく小さい会社で極端な値になります。上下1％で切りそろえます
7. 標準化する … 項目ごとに平均0・ばらつき1にそろえます。標準化の物差しは学習のときのものを保存し、毎月それを使います

5番目を軽く見ないでください。 決算書を出さない取引先は、出す取引先より問題が起きやすいことがあります。「決算なし」の印を項目として入れれば、そのこと自体をモデルが学べます。 埋めてしまうと、その差が消えます。

AIに処理させる

させるのは、取引先ごとに「12か月以内に支払の問題が起きる確率」を見込み、確率に効いた項目を分解することだけです。 格付の区分への当てはめと、候補の分け方は、決められた表で機械的に行います。

格付の区分への当てはめは、財務部が決める表で行います。 例えば、確率が1％未満ならA、1〜3％ならB、3〜8％ならC、8〜20％ならD、20％以上ならE、のような区切りです。区切りの値は、財務部の与信管理規程で決めるもので、モデルが決めるものではありません。 区切りを変えても、モデルを学び直す必要はありません。

3行目が、いちばん起きやすい失敗です。 一覧を作るついでに台帳の格付の列を更新すると、営業の画面では翌日から新しい格付で与信枠が計算されます。 会議で覆したときに、元に戻すまでの間に出荷が止まります。

指示内容を固定する

この構成は生成AIを使わないので、プロンプトの代わりに、プログラムに渡す設定ファイルと、理由の文の決まりを示します。

【予測の設定】
target:            12か月以内に支払の問題が起きたか（0／1）
problem_events:    60日を超える遅れ ／ 支払条件の変更の依頼 ／ 法的整理・私的整理の申し出
snapshot:          毎月末。その時点で手元にあった数字だけを使う
history:           過去5年分の月末の断面
model:             LogisticRegression(l1_ratio=0, C=<交差検証で選ぶ>, max_iter=1000)
class_weight:      指定しない（確率をそのまま使うため）
calibration:       CalibratedClassifierCV(method="sigmoid")
                   ※問題が起きた例が1,000件に届かないため sigmoid を使う

【使う項目】
決算:  自己資本比率 / 売上高経常利益率 / 有利子負債の月商倍率 / 現預金の月商倍率 /
       売上の前期比 / 債務超過の印 / 決算なしの印 / 前期なしの印 /
       自己資本比率の前期との差 / 決算の届いた遅れ（決算月からの月数）
支払:  遅れた回数（3か月・12か月）/ 最大の遅れた日数（3か月・12か月）/
       一部入金の回数（12か月）/ 支払条件の変更の依頼の印 / 与信枠の使用率
属性:  業種（大分類）/ 取引の年数

【格付の区分（財務部の与信管理規程で決める）】
A: 確率 < 1%   B: 1% 以上 3% 未満   C: 3% 以上 8% 未満
D: 8% 以上 20% 未満   E: 20% 以上

【候補の分け方】
格下げ候補: 確率から決まる格付が、いまの格付より1段以上低い
格上げ候補: 2段以上高く、かつ直近12か月に遅れが無い
要確認:     取引が3か月未満 ／ 学習の範囲を外れる項目がある ／ 取引先コードがつながらない
据え置き:   上のどれでもない

【理由の文の決まり】
- 確率を上げた項目のうち、効いた大きさの上位3つを出す
- 文は項目ごとに決めた型で書く。例：
  「自己資本比率が {今期}％（前期 {前期}％）に下がった」
  「直近3か月で入金が {回数} 回遅れ、最長 {日数} 日だった」
  「決算書が届いていない（決算月から {月数} か月）」
- 数字は元の表の値をそのまま入れる。丸めや言い換えをしない
- 「業績が悪化」「信用不安」のような評価の言葉を使わない

class_weight を指定しないのは、確率をそのまま格付に使うためです。 支払の問題が起きる取引先は少ないので、'balanced' を付けたくなります。これはクラスの頻度に反比例した重みで学ぶ指定で、付けると問題の起きる側が重く数えられ、出てくる確率の水準が実際の頻度から離れます。 確率の区切りで格付を決める構成では、区切りの意味が変わってしまいます。

較正に sigmoid を選ぶのは、例の数が少ないためです。 公式の説明では、isotonic は1,000件を超えるくらいのデータがあれば sigmoid と同等以上になる一方、小さなデータでは当てはめすぎやすいとされています。問題が起きた取引先が5年で数百社という規模なら、sigmoid にします。 学習済みのモデルを後から較正するときは、FrozenEstimator で包んで渡し、学習に使っていないデータで較正します。

理由の文を決まった型で書くのは、言い回しで重みを変えないためです。 生成AIに書かせると、同じ数字でも「大きく悪化」と「やや低下」が混ざり、格付の会議で文の強さが議論の中身になってしまいます。 数字を入れた型の文なら、読む人は数字で判断します。

出力形式を固定する

取引先ごとに、次の形のJSONを1行ずつ書き出し、そこから会議の資料の表を作ります。

{
  "run_month": "2026-10",
  "partner_code": "",
  "partner_name": "",
  "current_grade": "B",
  "probability_12m": 0.094,
  "model_grade": "D",
  "category": "downgrade_candidate | upgrade_candidate | keep | needs_review",
  "reasons": [
    { "feature": "equity_ratio", "contribution": 0.61,
      "text": "自己資本比率が 8.2％（前期 14.5％）に下がった",
      "source": "決算データの表 2026年6月期" }
  ],
  "data_flags": ["no_prior_period"],
  "review_reason": "",
  "model_version": "2026-04"
}

reasons には上位3つまでを並べます。contribution は、その項目の係数と標準化した値の積で、確率そのものではなく、確率の対数オッズを押し上げた大きさです。

1つ目の理由は、category と model_grade を分けて持てることです。 model_grade は確率と区切りの表から決まり、category はいまの格付と比べて決まります。区切りの表を変えたときは、確率を計算し直さずに model_grade だけを作り直せます。

2つ目は、source で数字の出どころを示せることです。 担当者が営業に説明するとき、「どの期の決算のどの数字か」を一覧から直接たどれます。決算データの表の入力ミスも、ここで見つかります。 自己資本比率が前期の半分になっている取引先を開いたら、桁を1つ間違えて入れていた、ということが起きます。

3つ目は、model_version で、どのモデルで出した候補かを残せることです。 毎年学び直すと、同じ数字でも確率が変わります。

システムへ連携する

取引先台帳と販売管理へは書き込みません。 格付の会議で承認された格付は、これまでどおり担当者が台帳に入れます。台帳への入力を自動にしたくなりますが、承認の記録と台帳の値がずれる経路を作らないためです。

営業への連絡も自動にしません。 格下げ候補の一覧がそのまま営業に届くと、承認の前に取引先へ伝わることがあります。担当者が事情を聞くときに、必要な取引先だけを伝えます。

人が確認する

人が開くのは「格下げ候補」と「要確認」だけです。 300件のうち、合わせて3〜4割を想定します。「据え置き」は一覧で件数と確率の分布を流し見ます。

1. データの欠けから見る … data_flags のある取引先を先に開き、決算データの表の入力漏れや桁の誤りでないかを確かめます
2. 理由の数字を元の表で確かめる … source の決算と入金の記録を開き、数字が合っているかを見ます
3. 営業に事情を聞く … 大口の受注、増資、親会社の支援など、数字に出ていない事情を聞きます
4. 格付の案を決める … 候補どおりにするか、覆すかを決め、覆すときは理由を review_reason に書きます
5. 格上げ候補は急がない … 格上げは与信枠が増える方向なので、もう1か月様子を見る運用も選べます

4番目の記録を省かないでください。 覆した理由がたまると、モデルが知らない事情の型が見えてきます。「親会社の保証がある取引先を下げすぎる」と分かれば、保証の有無を項目に足せます。

目標は、300件をならして1件4分です。 据え置きは数秒、格下げ候補は営業への聞き取りを含めて10分以上かかります。格下げ候補が月に50件を超えるなら、区切りの表か、モデルの学び直しを疑います。

例外に対処する

上から4行目までが大半を占めます。 どれもモデルの問題ではなく、決算データの表の入力と、締めの手順の問題です。 直すほうが、モデルを作り直すより効きます。

記録を残す

• 毎月の入力（3つの表の書き出し）と、そのときの標準化の物差し
• 取引先ごとの確率・格付の候補・理由・データの欠け・モデルの版
• 人が候補を覆した記録 … どの取引先を、どの格付にし、なぜか
• 格付の会議で承認された格付と、台帳に入れた日
• 12か月後の突き合わせ … 確率の帯ごとに、実際に問題が起きた割合
• 学び直しのたびの、較正曲線と検証の数字

1つ目で入力そのものを残すのは、後から「なぜこの月に下げなかったのか」を問われるためです。 支払の問題が起きた取引先について、その前の月の確率と理由をそのまま出せるようにしておきます。

5つ目が、この構成を使い続けてよいかの判断の材料になります。 確率が3〜8％と出た取引先のうち、実際には15％で問題が起きていたなら、確率が低めに出ているということです。格付の区切りを見直すか、学び直します。