この記事で分かること
- 期待損失 EL = PD × LGD × EAD のうち、統計・機械学習モデルが担うのは PD と LGD の推定であり、EAD は契約条件から算定する量だという役割の切り分け
- 仮設3社ポートフォリオ(与信合計1,600百万円)で期待損失を整数で通し、1社が格下げされたときに合計 EL が15.4百万円から28.0百万円へ動く過程を検算つきで確認する手順
- 目的変数の定義・データリーク・生存バイアス・不均衡データ・期間の代表性・再学習頻度を潰すモデル設計チェックリストと、欠損・名寄せ・決算期の不揃いを潰すデータ品質点検表
- 金融庁「モデル・リスク管理に関する原則」の8つの原則を実務の工程に翻訳した読み方と、精度と説明可能性のトレードオフをどう扱うか
結論:モデルが出すのは「順位と確率」であって、貸すかどうかの答えではない
信用リスクの予測にAIを使う、と言ったときに何をしようとしているのかを最初にはっきりさせます。やろうとしているのは、与信先ごとに「1年以内にデフォルトする確率」と「デフォルトしたときに失う割合」を数値で推定し、ポートフォリオ全体の期待損失を積み上げることです。個別案件を承認するか否決するかを機械に決めさせることではありません。
この区別が曖昧なままモデルを作ると、ほぼ確実に失敗します。承認・否決の判断には、モデルが入力として持っていない情報——経営者の交代方針、取引先との関係、直近の受注状況、担保の実際の処分可能性——が大量に効くからです。モデルは過去の観測データから統計的な関係を取り出す装置であり、観測されていないものは扱えません。モデルは与信先を「危ない順」に並べて確率という共通の物差しで表し、人はその順位を出発点にモデルが見ていない情報を足し引きして判断する。この分業が守られなければ、説明できない否決と承認が積み上がるだけです。
なお、与信稟議書の下書きを生成AIに支援させる話、審査プロセスのどこにAIを入れるかという工程論は、与信審査・融資稟議での生成AI活用で扱っています。本記事はそこには踏み込まず、統計・機械学習モデルによる信用リスクの計量に集中します。PD・LGD・EADという概念そのものの定義や期待損失の考え方はクレジットリスク分析入門(PD・LGD・EADと期待損失)にありますので、本記事では「モデルを作る側から見ると、この3つの量はどう扱いが違うのか」という角度だけを扱います。
全体像:期待損失の分解と、モデルが担当する範囲
まず1社で流れを通します。仮設の与信先「三国運輸倉庫」に対して、証書貸付の残高が240百万円、コミットメントラインの未使用枠が200百万円あるとします。以下はすべて仮設例で、単位は百万円に統一します。
- デフォルト確率(PD)=5.0%:1年以内にデフォルト(ここでは3か月以上の延滞または債務者区分の実質破綻先以下への遷移と定義)する確率。これはモデルが推定します。
- デフォルト時与信残高(EAD)=300百万円:デフォルトした時点で実際にいくら貸しているか。現在の残高240百万円に、未使用枠200百万円のうち引き出されると見込む分(掛目30%=60百万円)を足して算出します。240+60=300百万円。これはモデルというより、契約条件と引出見込みの掛目から算定する量です。
- デフォルト時損失率(LGD)=60%:デフォルトした場合に、担保処分・保証履行・回収活動を経てもなお失う割合。裏返すと回収率は40%です。これは回収実績データからモデルで推定します(ただし後述するとおり、PDより格段にデータが少ない)。
この3つを掛け合わせたものが期待損失です。EL = 5.0% × 60% × 300百万円 = 9.0百万円。デフォルトが起きた場合の損失額は300×60%=180百万円ですが、それが起きる確率が5.0%なので、平均的に見込むべき損失は9.0百万円、という読み方になります。回収120百万円と損失180百万円の合計は300百万円でEADと一致します。
ここで押さえておきたいのは、3つの量はデータの豊富さがまったく違うという点です。PD は「デフォルトしたか否か」という二値なので、正常先も含めた全与信先が学習データになります。一方 LGD はデフォルトした先でしか観測できません。年間のデフォルト件数が数十件規模の金融機関では、LGD を精緻にモデル化するだけのサンプルが物理的に足りないことがよくあります。EAD に至っては、コミットメントラインの引出行動という、さらに事例の少ない現象です。
この非対称性は設計に直結します。PD は機械学習で細かく推定しようとする一方、LGD と EAD は担保種類別・保証有無別の単純な区分平均や、監督上の掛目に近い保守的な固定値を使う——という構成が実務では珍しくありません。「全部をAIで推定する」ことは目的ではなく、データがある部分にだけモデルを当てるのが正しい設計です。
3社ポートフォリオで期待損失を通す(整数設例)
個社の EL が計算できたら、次はポートフォリオです。仮設の与信先3社を置きます。すべて架空の会社で、数値は理解のための仮設例です。単位は百万円、PD と LGD は%で統一します(倍率表記は使いません)。
| 与信先(仮設) | 業種 | PD | LGD | EAD | EL |
|---|---|---|---|---|---|
| 佐倉精工 | 金属加工 | 2.0% | 40% | 500 | 4.0 |
| 三国運輸倉庫 | 運輸・倉庫 | 5.0% | 60% | 300 | 9.0 |
| 白鷺フーズ | 食品卸 | 1.0% | 30% | 800 | 2.4 |
| 合計 | 1,600 | 15.4 | |||
検算します。佐倉精工は 2.0% × 40% × 500 = 0.02 × 0.40 × 500 = 4.0。三国運輸倉庫は 0.05 × 0.60 × 300 = 9.0。白鷺フーズは 0.01 × 0.30 × 800 = 2.4。合計は 4.0 + 9.0 + 2.4 = 15.4百万円。与信合計は 500 + 300 + 800 = 1,600百万円です。ポートフォリオの期待損失率は 15.4 ÷ 1,600 = 0.9625 → 0.96%(小数第3位四捨五入)となります。
ここで読み取れることが2つあります。第一に、与信額が最大の白鷺フーズが、EL では最小だという点です。EAD が800百万円と最も大きいにもかかわらず、PD が1.0%と低く、LGD も30%と低い(不動産担保が厚いという設定)ため、EL は2.4百万円にとどまります。「残高の大きい先が最もリスクが高い」という直感は、期待損失の物差しでは成り立ちません。第二に、EL の6割弱(9.0 ÷ 15.4 = 58.4%)が三国運輸倉庫1社に集中していることです。EL に分解すると、どこを見張るべきかがはっきりします。
1社が悪化したときに何が動くか
次に、三国運輸倉庫の業績が悪化し、債務者区分が下方に遷移して PD が 5.0% から 12.0% へ引き上げられた場合を見ます。LGD と EAD は変えません。
| 与信先(仮設) | 当初 PD | 当初 EL | 悪化後 PD | 悪化後 EL | 増減 |
|---|---|---|---|---|---|
| 佐倉精工 | 2.0% | 4.0 | 2.0% | 4.0 | ±0 |
| 三国運輸倉庫 | 5.0% | 9.0 | 12.0% | 21.6 | +12.6 |
| 白鷺フーズ | 1.0% | 2.4 | 1.0% | 2.4 | ±0 |
| 合計 | — | 15.4 | — | 28.0 | +12.6 |
| EL率(EL ÷ 与信1,600) | — | 0.96% | — | 1.75% | +0.79pt |
検算します。三国運輸倉庫の悪化後 EL は 0.12 × 0.60 × 300 = 21.6。増加分は 21.6 − 9.0 = 12.6。合計は 4.0 + 21.6 + 2.4 = 28.0 で、当初合計 15.4 + 12.6 = 28.0 と一致します。EL率は 28.0 ÷ 1,600 = 0.0175 = 1.75%、変化は 1.75% − 0.96% = 0.79pt です。
1社の PD が2.4倍になっただけで、ポートフォリオ全体の期待損失が1.8倍になりました。この感応度の高さが、PD 推定の精度が信用リスク計量の中核である理由です。逆に言えば、PD モデルが1段階分の格付を系統的に外していると、引当や与信費用の見積りが桁で狂う可能性があります(引当額の算定方法は会計基準・自己査定基準に従うため、EL がそのまま貸倒引当金になるわけではない点に注意してください)。
AIに任せる部分と、人が判断する部分
信用リスクの計量工程を、担当者を明示して分けます。ここでの「AI」は、PD/LGD を推定する統計・機械学習モデルと、設計レビューや文書化を助ける生成AIの両方を含みます。
| 工程 | AI/モデルが担える | 人が決める・確認する |
|---|---|---|
| 目的変数の定義 | 定義候補の列挙、定義ごとの件数集計 | 採用する定義そのもの(自己査定基準・監督上の定義との整合) |
| 説明変数の候補出し | 財務指標の網羅的な生成、相関・欠損の集計 | 申込時点で入手できるかの可否判定、業務上の意味づけ |
| データ品質の点検 | 欠損率・外れ値・重複の機械的検出 | 検出結果の原因特定、名寄せ・グループ与信の集約ルール |
| PD/LGD の推定 | モデルの中核。ここは機械が担う | 推定値の水準が業務常識と乖離していないかの査閲 |
| EAD の算定 | 引出実績の集計、掛目の候補提示 | 掛目の採用値(保守性の水準は経営判断) |
| 格付への割当 | スコアの分布に基づく境界値の候補算出 | 格付区分の粒度と境界、既存格付との接続 |
| 個別案件の承認・否決 | —(モデルは参考情報の一つ) | すべて人が判断し、理由を記録する |
| モデルの承認・実装 | 検証結果の集計、文書ドラフト | 承認の可否、適用範囲と有効期限の設定 |
最下段から2つ目の行が、この記事でいちばん重要な線です。モデルのスコアは判断材料であって判断ではありません。スコアが良いから承認した、悪いから否決した、という記録の残し方をすると、後から「なぜその与信をしたのか」を説明できなくなります。5C・DSCRによる信用分析の基礎にあるような定性・定量の判断枠組みは、モデルを入れても消えません。むしろモデルのスコアが1つの入力として加わるだけです。
モデル設計チェックリスト(実務成果物1)
ここからが本記事の成果物です。信用リスクモデルの設計で壊れる箇所は、経験上ほぼ決まっています。工程順に6つの関門として整理しました。
チェックリスト本体
| 項目 | 確認すること | 合格の目安 |
|---|---|---|
| 1. デフォルトの定義 | 何をもってデフォルトとするか(延滞日数/債務者区分/代位弁済/法的整理)を文書で1つに固定したか。自己査定基準・社内の格付定義と矛盾しないか | 定義文が1文で書けて、該当件数がSQLで再現できる |
| 2. 観測期間(アウトカム期間) | 「いつ時点の情報で、その後いつまでのデフォルトを予測するか」を明示したか。1年か3年かで意味も精度もまったく違う | 「基準日 t の情報で t+12か月以内」のように期間が固定されている |
| 3. 説明変数の入手時点 | 各変数が基準日時点で実際に入手できていたかを1変数ずつ確認したか。決算データは「決算期末」ではなく「入手日」で紐づいているか | 全変数に「入手可能となる時点」の列があり、基準日より後のものがゼロ |
| 4. サンプルの偏り | 学習データが承認先に限られていないか(否決先の結末は観測できない)。特定業種・特定支店に偏っていないか | 母集団と学習サンプルの業種・規模・地域構成を並べた表を作成済み |
| 5. 不均衡データの扱い | デフォルト率が数%以下の場合の評価指標を、正解率以外で定義したか。サンプリングで調整した場合、確率水準の補正をしたか | AR値(またはAUC)・捕捉率・誤警報件数を併記し、実績デフォルト率と予測平均が近い |
| 6. 期間の代表性 | 学習期間に景気の悪い局面が含まれているか。特殊な政策局面(大規模な資金繰り支援等)を含む期間をそのまま使っていないか | 年度別のデフォルト率推移を提示し、平時と非平時を識別している |
| 7. 検証用データの分け方 | 時系列で分割しているか(アウト・オブ・タイム検証)。ランダム分割だけで済ませていないか | 学習期間より後の期間で単独に性能を測った結果がある |
| 8. 変数の業務的な意味 | 採用した変数それぞれについて、符号の向き(大きいほど危ない/安全)が業務常識と整合するか説明できるか | 符号が直感と逆の変数について、理由を書面で説明できる |
| 9. 再学習と有効期限 | 再学習の頻度、トリガー(性能劣化の閾値)、承認者、旧モデルへの切り戻し手順を定めたか | 運用手順書に頻度・閾値・責任者が固有名詞で書かれている |
| 10. 適用範囲の明示 | このモデルを使ってよい対象(規模・業種・与信種類)と、使ってはいけない対象を定めたか | 「適用外」の条件が明記され、システム側で弾ける |
3番目の「説明変数の入手時点」が、実務でいちばん見落とされます。審査プロセスの途中や事後にしか得られない情報(追加担保の差入れ、条件変更の記録、支店のモニタリング記録など)が説明変数に紛れ込むと、検証データでは驚くほど高い精度が出ます。しかし新規の申込先にはその情報が存在しないため、本番では何も予測できません。この現象自体の解説はファイナンスのための機械学習入門(過学習とデータリーク)にありますので、ここでは信用リスク固有の混入経路だけを列挙します。
- 決算データを「決算期末」で紐づけている(実際に金融機関が入手するのは2〜4か月後)
- 格付・債務者区分の更新日が、更新のたびに上書きされ、過去時点の値が復元できない
- 条件変更(リスケジュール)の記録が、実施日ではなく最新状態としてのみ保持されている
- 保証協会の代位弁済記録が、デフォルト判定より前の時点に付与されている
- 支店の要注意先リストへの登録日が空欄で、現在の登録状態だけが分かる
いずれも「現在の状態しか持っていないマスタ」を、過去時点の分析に使ってしまうことで起きます。対策は、時点情報を持つ履歴テーブル(いつからいつまでその値だったか)を先に整備することです。これはモデリングの前段階の話ですが、ここが整っていない状態で作ったモデルは、どれだけ手法を工夫しても信用できません。
データ品質点検表(実務成果物2)
もう一つの成果物がデータ品質の点検表です。信用リスクモデルのデータは、勘定系・財務・属性・外部データが混ざるため、壊れる場所が多岐にわたります。どこで何が壊れるかを先に地図にしておくと、点検が漏れません。
点検表本体
| 点検項目 | 見るもの | 検出方法 | 対処 |
|---|---|---|---|
| 1. 欠損 | 変数別・年度別・支店別の欠損率 | 欠損率のクロス集計。特定年度だけ跳ねていないか | 欠損が「情報がない」のか「該当なし」なのかを区別。欠損フラグを変数化するか、当該期間を除外 |
| 2. 外れ値 | 財務比率の分布の裾 | 上下0.5%点の実データを目視。分母がゼロ近傍で発生していないか | 入力誤りは修正、実在する極端値は上下限で切る(切った件数を記録) |
| 3. 名寄せ | 同一先が複数コードで登録されていないか | 法人番号・所在地・代表者名での突合。表記ゆれ(株式会社の前後・旧字体)の検出 | 法人番号を主キーに寄せ、統合前後の与信額合計が一致することを確認 |
| 4. 決算期の不揃い | 決算月の分布、変則決算の有無 | 決算月別の件数集計。会計期間が12か月でないレコードの抽出 | 年換算のルールを明文化。基準日からの経過月数を変数として持つ |
| 5. 業種コードの粒度 | 分類の階層と、1コードあたりの件数 | 業種別件数の分布。1件しかないコード、過半を占めるコードの確認 | 件数の少ないコードは上位階層に統合。統合ルールを文書化 |
| 6. グループ与信の集約 | 親子会社・実質同一体への与信の合算 | グループコードの付与率。付与漏れの多い支店の特定 | 集約単位(個社/グループ)をモデルの目的に応じて固定し、両方を混在させない |
| 7. 時点の整合 | 各テーブルの基準日が揃っているか | レコードごとに「基準日 − データ日付」を計算し、負の値がないか確認 | 負の値(未来の情報)はリークなので即座に除外 |
| 8. 重複 | 主キーの一意性 | (顧客コード, 基準日)での件数カウント | 重複の発生原因を特定してから除去。件数のずれを記録 |
この点検を通す前に精度を議論しても意味がありません。実務では、モデル手法の選択よりデータ整備のほうが精度への寄与が大きいことがほとんどです。汎用的なデータバリデーションの考え方に、上記の与信データ固有の観点を足したものが、この点検表の位置づけです。
生成AIに設計をレビューさせるプロンプト
ここまでのチェックリストは人が使うものですが、モデル設計書の草案に対して機械的に穴を探させる用途では、生成AIが役に立ちます。ただし、機密データそのものを渡すのではなく、設計の記述(データ辞書と定義文)だけを渡すのが前提です。
あなたは金融機関の信用リスクモデル検証の担当者です。 【目的】 以下に貼り付けた「PDモデル設計書(抜粋)」を読み、モデルの妥当性を損なう 設計上の欠陥を洗い出してください。改善案の提示ではなく、まず欠陥の特定に 集中してください。 【入力資料】 ・PDモデル設計書(抜粋):目的変数の定義、観測期間、説明変数一覧(変数名/ 定義/データソース/入手可能となる時点)、サンプル抽出条件、学習・検証の 分割方法、評価指標、再学習の方針 ※実データ・個社名は含みません。定義文とデータ辞書のみです。 【対象期間】 設計書に記載された観測期間をそのまま使ってください。記載がなければ「未記載」 と書いてください。 【単位】 金額は百万円、確率・比率は%で表記してください。倍率表記は使わないでください。 【必ず確認する観点】(各観点について「問題あり/問題なし/設計書からは判断 不能」の3択で判定し、根拠となる設計書の記述を引用してください) 1. デフォルトの定義が一意に特定できるか 2. 基準日とアウトカム期間の関係が明示されているか 3. 各説明変数の「入手可能となる時点」が基準日以前か(基準日より後のものは データリークとして指摘) 4. サンプルが承認先に限定されていないか(生存バイアス) 5. 学習・検証の分割が時系列で行われているか 6. 不均衡データに対する評価指標が正解率以外に定義されているか 7. 学習期間に景気後退局面が含まれているか 8. 再学習の頻度・トリガー・承認者・切り戻し手順が定められているか 9. モデルの適用対象と適用除外が明示されているか 【出力形式】 表形式。列は「観点番号/観点/判定/設計書の該当記述(原文の引用)/ なぜ問題か(2文以内)」。表の後に、判定が「問題あり」の観点だけを 重大度の高い順に並べ替えた一覧を付けてください。 【禁止事項】 ・設計書に書かれていないことを補って解釈しないでください。 ・一般論としてのモデルリスクの説明は不要です。設計書の記述に紐づく指摘のみ 書いてください。 ・「概ね妥当です」のような総括評価は書かないでください。 【不明情報の処理】 設計書から判断できない事項は、推測せず「設計書からは判断不能」と書き、 確認すべき質問文を1行で添えてください。 【検算・自己レビュー】 出力の最後に、次の3点を自己点検して結果を書いてください。 (a) 9つの観点すべてについて判定を書いたか(書いた観点番号を列挙) (b) 「問題あり」と判定した全てに設計書の原文引用を付けたか (c) 設計書に存在しない用語や数値を出力に含めていないか
出力例(抜粋・仮設)
上記のプロンプトに、目的変数の定義を「延滞が発生した先」とだけ書いた設計書を渡した場合、次のような指摘が返ってくることを想定しています。
| 観点 | 判定 | なぜ問題か |
|---|---|---|
| 1. デフォルト定義 | 問題あり | 「延滞が発生した先」では延滞日数の閾値が特定できず、同じ設計書から異なる母集団が作られる。1日延滞と90日延滞では該当件数が大きく変わる。 |
| 3. 変数の入手時点 | 問題あり | 「直近決算の自己資本比率」の入手可能時点が空欄。決算期末を基準に紐づけている場合、基準日時点では未入手の情報を使うことになる。 |
| 7. 期間の代表性 | 判断不能 | 観測期間の記載はあるが、その期間のデフォルト率推移が設計書に含まれていない。確認質問:学習期間の年度別デフォルト率を提示できますか。 |
ここで返ってくるのは「指摘の候補」であって、指摘そのものではありません。生成AIは設計書に書かれていない現場の事情(そもそも延滞日数のデータが取れない、など)を知らないため、実際には問題にならない指摘も混ざります。検証担当者がひとつずつ潰していく前提で使ってください。
精度と説明可能性のトレードオフ
信用リスクモデルの設計で必ずぶつかるのが、精度と説明可能性の対立です。勾配ブースティングのような手法は、ロジスティック回帰よりも判別力が高く出ることが多い一方で、「なぜこの先のスコアが低いのか」を一文で説明することが難しくなります。審査の場面では、これが決定的な制約になります。取引先から「なぜ否決されたのか」と問われたときに、支店の担当者が答えられないモデルは、そもそも審査の現場に置けません。
実務上の落としどころとしては、用途によってモデルを分けるという選び方があります。ポートフォリオ全体の期待損失を見積もる、モニタリングで劣化の兆候がある先を抽出する、といった順位づけが目的の用途では複雑なモデルを使い、個別先への説明が必要な用途では変数が少なく符号の解釈できるモデルを使う、という分け方です。説明の粒度をどこまで求めるか(顧客向け/社内向け/監督当局向け)という論点は掘り下げる価値がありますが、本記事の範囲を超えるため、ここでは指摘に留めます。
モデルバイアスと差別的取扱いの観点
説明可能性と隣り合わせにあるのが、属性による不当な差別的取扱いの問題です。説明変数に性別・年齢・国籍などを直接入れていなくても、郵便番号や取引チャネルのような変数がそれらと強く相関していれば、結果的に特定の属性に不利な判定が生じ得ます。これは技術的には検出可能です。具体的には、属性別のスコア分布・承認率・実績デフォルト率を並べ、スコアの水準差が実績のデフォルト率差で説明できるかを見ます。説明できない差が残るなら、変数選択を見直す必要があります。
ただし、その差が日本の法令上どのように評価されるかについて、本記事は解釈を示しません。金融機関の与信判断における属性の取扱いは、業法・個人情報保護法制・社内規程が絡む論点であり、実務では法務・コンプライアンス部門に個別に確認するのが正しい進め方です。モデル開発側がやるべきことは、「どの属性でどのような差が出ているか」を数値で示せる状態を作り、その判断材料を法務・コンプライアンスに渡すことです。
なお、米国には ECOA(Equal Credit Opportunity Act:平等信用機会法)や FCRA(Fair Credit Reporting Act:公正信用報告法)といった、与信における差別の禁止や信用情報の取扱い、否決理由の通知に関する連邦法があります。海外の解説記事ではこれらを前提に議論が組み立てられていることが多いのですが、これらは米国の制度であり、日本の与信実務にそのまま当てはまるものではありません。海外の実務書やベンダー資料を読むときは、前提となる法域を確認してください。
金融庁「モデル・リスク管理に関する原則」をどう読むか
日本でモデルのガバナンスを設計するときの出発点になるのが、金融庁が2021年11月12日に公表した「モデル・リスク管理に関する原則」です(PDF、2026年8月3日確認)。適用対象は本邦G-SIBs・本邦D-SIBs等に限定されており、すべての金融機関に一律に適用されるものではありません。また、細則を並べたルールベースではなく、原則ベースのアプローチが採られています。
同原則は8つの原則で構成されています。以下は原文の引用ではなく、モデル開発の実務工程に引き寄せた筆者の言い換えです。
| 原則 | 信用リスクモデルの文脈での意味(筆者の言い換え) |
|---|---|
| ① ガバナンス | 経営陣がモデルリスクを自らのリスクとして認識し、責任の所在と体制を定める。「データサイエンス部門に任せている」は体制ではない |
| ② 特定・インベントリー管理・リスク格付 | そもそも自組織にどんなモデルが何個あるかを一覧化し、重要度に応じた格付を付ける。Excelマクロで動く簡易スコアもモデルに含まれ得る |
| ③ モデル開発 | 開発の過程・前提・限界を文書化する。本記事の設計チェックリストとデータ品質点検表は、この文書化の中身にあたる |
| ④ モデル承認 | 使い始める前に、誰が何を確認して承認するかを定める。適用範囲と有効期限を明示する |
| ⑤ 継続モニタリング | 運用開始後の性能劣化・入力データの分布変化を継続的に測る。作ったら終わりにしない |
| ⑥ モデル検証 | 開発者から独立した立場で、前提・データ・手法・結果を検証する。開発者の自己点検では代替できない |
| ⑦ ベンダー・モデル/外部リソース | 外部から購入したモデルも自組織のモデルリスク。中身が開示されないことを理由に検証を省略しない |
| ⑧ 内部監査 | モデルリスク管理の枠組みそのものが機能しているかを、内部監査が独立して評価する |
この枠組みの含意で最も実務に効くのは、②のインベントリー管理と⑦のベンダーモデルの扱いです。「モデル」を機械学習で作った予測器だけだと考えていると、長年支店で使われてきた表計算ベースの簡易スコアや、外部から購入したスコアリングサービスが管理の外に置かれます。生成AIを組み込んだ仕組みも、出力が業務判断に影響するのであれば、同じ発想で棚卸しの対象として扱うのが自然です。
関連して、金融庁は2024年12月12日に「金融機関のモデル・リスク管理の高度化に向けたプログレスレポート(2024)」を公表しており(案内ページ、2026年8月3日確認)、原則公表後の実装状況が整理されています。また金融機関のAI活用全般については、金融庁「AIディスカッションペーパー(第1.1版)」(2026年3月3日公表)が論点を整理しています。
モデル出力の検証方法
信用リスクモデル固有の検証項目を挙げます。生成AI出力の一般的な検証(出典の実在確認・数値転記・計算再現・論理整合)は生成AI出力の検証手順に譲り、ここではモデルそのものの検証に絞ります。
- 判別力:学習期間より後の期間(アウト・オブ・タイム)で AR値/AUC を測る。学習期間内の値とどれだけ落ちるかを見る。落差が大きければ、期間依存の関係を拾っている疑いがある。
- 較正(キャリブレーション):予測 PD の平均と、実績デフォルト率が近いか。格付段階ごとに「予測 PD」と「実績デフォルト率」を並べる。判別力が高くても水準がずれていれば、期待損失の金額が狂う。
- 単調性:格付が悪い段階ほど実績デフォルト率が高い、という順序が保たれているか。順序が逆転している段階があれば、区分の切り方を見直す。
- 安定性:入力変数の分布が開発時と現在でどれだけ動いたか(母集団安定性の確認)。分布が動いていれば、精度が落ちる前に手を打てる。
- 個別事例での納得性:スコアが極端に良い先・悪い先を各20件程度抽出し、審査担当者に見せて違和感がないか確認する。この工程は自動化できません。数値上は正しくても、現場感覚と大きくずれるモデルは運用に乗りません。
- ベンチマーク比較:既存の格付や、Altman Zスコアのような公知の指標と並べ、順位づけがどこで食い違うかを確認する。食い違いの理由が説明できるかが論点です。
- 再現性:同じデータと同じ手順で、別の担当者が同じ結果を出せるか。乱数シード、前処理の順序、除外条件がすべて記録されているか。
2番目の較正は見落とされがちです。順位づけが正しくても水準がずれていれば、ポートフォリオの期待損失は誤ります。先ほどの設例で言えば、3社の危険度の順序(三国運輸倉庫>佐倉精工>白鷺フーズ)が正しくても、PD の水準が一律に半分に見積もられていれば、合計 EL は15.4百万円ではなく7.7百万円と出てしまいます。判別力と較正は別の性質だと理解しておいてください。
機密情報・個人情報の注意
信用リスクモデルのデータは、法人の財務情報に加え、個人事業主や保証人に関する個人情報を含むことが少なくありません。外部の生成AIサービスに、個社が特定できる形の与信データを入力しないでください。設計レビューに生成AIを使う場合は、本記事のプロンプト例のように「定義文とデータ辞書」だけを渡し、実データは渡さない構成にします。社内規程の作り方や、入れてよい情報・いけない情報の線引きは生成AIの機密情報管理と社内ルールに整理してあります。個人情報保護委員会も生成AIサービスの利用に関する注意喚起を公表しており(2023年6月2日)、利用目的の範囲内であることの確認を求めています。
よくある失敗
- 検証データで異常に高い精度が出て喜ぶ。信用リスクモデルで AR値が極端に高い場合、まずデータリークを疑います。実務で普通に作れる水準を超えていたら、説明変数の入手時点を1つずつ確認してください。
- 正解率を評価指標にする。デフォルト率が2%のデータでは、全件を「正常」と予測するだけで正解率98%です。この数字を成果として報告してしまう事故が実際に起きます。
- 否決先のデータがないことを忘れる。学習データは過去に承認した先だけで構成されています。既存の審査基準で弾かれた層について、モデルは何も知りません。新しい層に適用範囲を広げるときは、その前提が崩れます。
- LGD を PD と同じ密度でモデル化しようとする。デフォルト事例が年間数十件しかないのに、LGD を多変数モデルで推定すると、ほぼ確実に過学習します。データ量に見合った粗さで作るのが正解です。
- 再学習の手順を決めずに運用を始める。誰がいつどの基準で入れ替えるかが決まっていないと、劣化に気づいた時点で「旧モデルに戻せない」状態になります。
実務チェックリスト
- デフォルトの定義を1文で書き、該当件数をSQLで再現できる状態にした
- 基準日と予測対象期間(例:t 時点の情報で t+12か月以内)を文書に明記した
- 全説明変数に「入手可能となる時点」の列を付け、基準日より後のものがないことを確認した
- 学習サンプルと母集団の業種・規模・地域構成を並べた表を作成した
- 学習・検証を時系列で分割し、アウト・オブ・タイムの性能を測定した
- 評価指標に AR値(またはAUC)・捕捉率・誤警報件数を含め、正解率単独では判断していない
- 格付段階別に「予測 PD」と「実績デフォルト率」を並べ、較正と単調性を確認した
- 学習期間に景気後退局面が含まれているかを年度別デフォルト率で確認した
- 欠損・外れ値・名寄せ・決算期・業種コード・グループ集約・時点整合・重複の8点検を実施し、記録を残した
- スコア上位・下位の各20件を審査担当者に見せ、納得性を確認した
- 属性別のスコア分布と実績デフォルト率を集計し、説明のつかない差がないかを確認したうえで、属性の取扱いについて法務・コンプライアンス部門の確認を得た
- モデルの適用範囲・適用除外・有効期限を承認文書に記載した
- 再学習の頻度・トリガー閾値・承認者・切り戻し手順を運用手順書に明記した
- 外部から購入したモデル・スコアも含めてモデルの一覧(インベントリー)に登録した
- 生成AIを設計レビューに使う場合、実データを渡さない構成になっていることを確認した
日本の実務での留意点
日本の金融機関で信用リスクモデルを作る場合、既存の枠組みとの接続が最初の論点になります。多くの金融機関は自己査定に基づく債務者区分と、内部格付制度をすでに持っています。新しいモデルを入れるときに、それらを置き換えるのか、並存させるのかで設計が変わります。並存させる場合は、モデルのスコアと既存格付が食い違ったときの扱い(どちらを優先するか、乖離が大きい先をどう処理するか)を先に決めておかないと、現場が混乱します。
データ面では、中堅・中小企業の財務データの質が論点になります。非上場企業の決算書は上場企業のような監査を経ていないものも多く、金融機関が入手できるのは年1回、しかも決算期末から数か月遅れます。四半期ごとに情報が更新される上場企業向けのモデルと同じ感覚では設計できません。格付とクレジット指標の基礎で扱う外部格付が付いている先はごく一部で、大半の与信先は自前で評価するしかない、というのが日本の中小企業向け与信の実情です。
信用保証協会の保証付き融資が一定割合を占める点も設計に影響します。保証付き部分は実質的な LGD が大きく下がるため、保証の有無を区別せずに LGD を推定すると水準を見誤ります。返済能力の指標としてDSCRを使う場合も、保証や担保の有無とは別の情報である点を意識して変数設計してください。
面接での答え方(30秒回答例)
リスク管理部門やクレジット関連職の面接で「信用リスクモデルにAIを使うことについてどう考えるか」と聞かれた場合の骨格です。
「期待損失は PD × LGD × EAD に分解されますが、この3つはデータ量が大きく違います。PD は全与信先が学習データになる一方、LGD はデフォルトした先でしか観測できず、EAD はさらに事例が少ない。ですので、機械学習を厚く使えるのは PD の推定で、LGD と EAD はデータ量に見合った粗い区分で保守的に置くのが現実的だと考えています。設計上いちばん気をつけるのは説明変数の入手時点で、審査後に判明した情報が混ざると検証では高精度に見えて本番で機能しません。そのうえで、モデルが出すのは順位と確率であって、承認・否決の判断そのものではないという線引きは維持すべきだと思います。」
この回答の要点は、「AIで精度を上げます」ではなく「どこにAIが効いて、どこには効かないか」を分けて話していることです。信用リスクの実務家は後者を聞いています。
よくある質問(FAQ)
Q. ロジスティック回帰から機械学習に切り替えると、どのくらい精度が上がりますか。
A. データと対象によって大きく異なるため、一般的な数字は示せません。ただ実務でよく観察されるのは、手法を変えることによる改善より、データ品質の改善や説明変数の入手時点の整理による改善のほうが大きいという順序です。手法の比較をする前に、本記事のデータ品質点検表を通すことをお勧めします。
Q. デフォルト事例が少なくてモデルが作れません。どうすればよいですか。
A. 無理に複雑なモデルを当てないことが第一です。変数を絞る、複数年度を積み上げる、外部データを併用するといった選択肢はありますが、いずれも限界があります。サンプルが足りない領域では、モデルの出力を参考値に位置づけ、人の判断の比重を上げるのが正しい設計です。「モデルを作らない」という結論も選択肢に含めてください。
Q. 生成AIに PD を推定させることはできますか。
A. 大規模言語モデルに企業情報を渡して「デフォルト確率を推定して」と頼めば、それらしい数字は返ってきます。しかしその数字は、自組織の与信ポートフォリオの実績デフォルト率で較正されたものではないため、期待損失の計算に使える水準の推定値ではありません。生成AIの用途は、設計のレビュー、文書化、定性情報の整理といった周辺工程に置くのが現実的です。
まとめ
信用リスク予測にAIを使う話は、「精度が上がるか」ではなく「何を推定し、何を推定しないか」の設計から始まります。期待損失 EL = PD × LGD × EAD のうち、機械学習を厚く使えるのは PD で、LGD と EAD はデータ量の制約から粗く保守的に置くのが現実的な構成です。設例では3社合計の EL が15.4百万円、1社の PD が5.0%から12.0%へ悪化しただけで28.0百万円へ動きました。この感応度が、PD 推定の設計を丁寧にやる理由です。
設計で壊れる場所は決まっています。目的変数の定義、説明変数の入手時点、サンプルの偏り、不均衡データ、期間の代表性、再学習の運用——この6つを本記事のチェックリストと点検表で潰してください。そして、精度を上げるほど説明が難しくなるという構造的なトレードオフは、用途ごとのモデルの使い分けで扱います。金融庁「モデル・リスク管理に関する原則」が示す8つの原則は、この一連の作業を組織として回すための枠組みです。モデルが出すのは順位と確率であって、貸すかどうかの答えではありません。この線を守れる組織だけが、信用リスクの計量から利益を得られます。
出典・参考(2026-08-03確認)
- 金融庁「モデル・リスク管理に関する原則」(令和3年11月12日)https://www.fsa.go.jp/common/law/ginkou/pdf_02.pdf ※本記事の8原則の記述は原文の引用ではなく、実務工程に引き寄せた筆者の言い換えです。
- 金融庁「『金融機関のモデル・リスク管理の高度化に向けたプログレスレポート(2024)』の公表について」(2024年12月12日)https://www.fsa.go.jp/news/r6/ginkou/20241212/20241212.html
- 金融庁「AIディスカッションペーパー(第1.1版)」(2026年3月3日)https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html
- 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(2026年3月31日)https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日)https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 日本銀行「金融システムレポート別冊:金融機関における生成AIの利用状況とリスク管理」(初版2024年10月21日)https://www.boj.or.jp/research/brp/fsr/fsrb241021.htm
※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。