0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

金融データサイエンス基礎Part 3. ディープラーニングが効かないデータ:スコアリングのための機械学習

0
Last updated at Posted at 2026-06-25

原文: han-co.com ·「金融データサイエンス基礎」連載のPart 3です。(原文には手描きの図も載せています。)

Part 2で統計を固めたので、いよいよ機械学習に入る番です。信用でも、モデルは結局のところ性能を見て選びます。ただ信用には、性能を分ける固有の事情と、性能のほかにもう一つ検討すべき軸があります。

性能を分ける最大の要因はデータの形です。信用データはテーブル形式です。一行に一顧客、各セルに収入や限度額や延滞回数が入る構造化データですね。ところがテーブルデータでは、画像と音声を平定したディープラーニングが意外と力を発揮できません。代わりに決定木ベースのブースティングが勝ちます。

Part 2の最後で二つを予告しました。なぜ今もロジスティック回帰が実務で使われるのか、そして金融ではなぜ交差検証を違うやり方でしなければならないのかです。ここに二つを加えます。実務で実際によく使われるのがなぜ決定木モデルなのか、そしてモデルを選んだ後にも付いてくる信用特有の制約は何か、です。

テーブルデータでは決定木が勝ちます

ディープラーニングはこの10年で画像、音声、自然言語を次々と平定しました。そこから「良いデータにニューラルネットを大きく載せれば勝つ」という印象が生まれました。ところがテーブル形式の構造化データでは、この印象がうまく当てはまりません。

理由はデータの性質にあります。画像は隣のピクセル同士、文章は前後の単語同士に強い構造があります。ディープラーニングはその構造を掘り下げるのが得意です。一方、テーブルデータのセルは単位も意味もばらばらで、そうした空間的な構造がありません。さらに信用データはImageNetのように数百万枚と貯まるわけでもありません。こうした環境では、決定木ベースのブースティング(XGBoost、LightGBM)のほうがよく合います。変数ごとに基準点を取って切り分けていくやり方が、ばらばらなセルを扱うのに自然だからです。

これは経験だけの話ではありません。テーブルデータをめぐってディープラーニングと決定木を正面から比較したベンチマーク研究が、同じ結論を繰り返し出しています。Tabular Data: Deep Learning is Not All You Need(Shwartz-Ziv & Armon, 2021)は複数のデータセットでXGBoostが当時提案されたディープラーニングモデルを上回ったと報告し、Why do tree-based models still outperform deep learning on typical tabular data?(Grinsztajn ほか, 2022)は45のデータセットで、決定木系が中規模のテーブルデータにおける最新の基準線であることを示しました。だから信用で性能を見てモデルを選ぶと、結局決定木ベースのブースティングが最終モデルになることが非常に多いのです。

性能で優位がないことだけが理由ではありません。実務でブラックボックスモデルは、それ自体がリスクです。なぜそう判断したのか説明しにくく、入力が少し変わったときにどう動くか見当をつけにくく、検証とガバナンスの負担も大きいです。一度の大きな失敗が高くつく分野なので、信用はこうした不透明さを本能的に警戒します。決定木も完全に透明なモデルではありません。ただ決定木は性能という対価を払い、SHAPや特徴量重要度で説明を付けて、その不透明さをある程度埋め合わせます。ディープラーニングはテーブルデータでその対価さえなく、より暗い箱を持ち込むことになるので、リスクに見合う見返りが乏しいのです。

ディープラーニングが信用でまったく無用だという話ではありません。ただその居場所は、コアのスコアリングモデルではなく非構造化の補助データの側です。問い合わせテキストや取引のシーケンスといったものから特徴を取り出し、本体のモデルに渡すやり方ですね。テーブルに整理された中心的な変数を前にして、ニューラルネットを前面に立てる理由は、少なくとも今のところ見当たりません。

ロジスティック回帰が生き残った理由

性能だけを見ると決定木に傾きますが、ロジスティック回帰が消えたわけではありません。ただしその理由は性能ではなく説明です。

ある領域では、モデルがそれ自体で解釈可能でなければなりません。否決理由を法的に告知しなければならない審査、監督当局が係数の一つひとつを覗き込む規制資本モデルといった場です。ここでは係数がそのまま説明になるロジスティック回帰と、それを点数に移したスコアカードが今も強く好まれます。単調性を強制でき、出力が安定し、理由の告知が自然だからです。

決定木を最終モデルに使うときは、この説明を事後に作ります。特徴量重要度でどの変数が重要かを見て、SHAPで個々の予測において各変数がどれだけ寄与したかを取り出し、否決理由に移すやり方です。実務で通用するやり方で、だから決定木を使いながらも説明の要求を満たせます。ただし事後の説明はモデルそのものではなく、モデルを覗いて得た解釈なので、理由の安定性と忠実さを別に点検する負担が残ります。

整理すると、モデル選択は二つの軸の取引です。性能では決定木が先んじ、それ自体で解釈されなければならない場ではロジスティック回帰が先んじます。たいていの実務はこの間のどこかで、性能と説明の要求を天秤にかけて選びます。

検証は未来で行うべきです

ここからがPart 2で予告した二つ目の約束です。信用では交差検証を違うやり方でしなければなりません。

一般的なk-fold交差検証は、データをランダムに混ぜていくつかの断片に分け、順に一つの断片を検証に使います。ところが信用でこうしてランダムに混ぜると、未来が過去に漏れ込みます。2024年の顧客と2025年の顧客を混ぜて学習すると、モデルは未来を少し見た状態で評価されることになります。ところが実際のデプロイは常に未来に行います。学習は過去のデータで行い、適用はまだ来ていない新規顧客に対して行います。

だから信用の検証は時間を尊重しなければなりません。

  • Out-of-time検証:過去の一定時点までで学習し、それ以降の期間で検証します。モデルが見たことのない未来でどれだけ持ちこたえるかを見ます。
  • 観察期間を守ります:Part 1で見たように、貸し倒れはずっと後になって確定します。まだ結果が熟していない直近の顧客を正解のように使えば、それがリークです。
  • 同じ顧客は片方だけに:一人の顧客の記録が学習と検証に同時に入ると、モデルは事実上、正解を覚えただけになります。

過学習の話も結局は同じところに集まります。信用で過学習が怖いのは、ランダムなホールドアウトでは表に出にくいからです。本当の試験は、時間が経って母集団が動いた後に来ます。Part 0で「検証指標は良いのに本番で崩れる」と述べた話の最もよくある原因が、まさに時間を無視した検証です。決定木であれロジスティック回帰であれ、正則化でモデルを単純に抑え、変数を欲張らず、検証を未来に回しておく習慣が、性能の一行より長持ちします。

特徴量エンジニアリングが実務の8割です

モデルの種類を決めた後、実際に性能を分けるのはアルゴリズムではなく変数です。実務の価値は特徴量エンジニアリングに8割があるという言葉が、信用では特によく当てはまります。決定木を使おうとロジスティック回帰を使おうと同じです。

良い変数はドメインから生まれます。Part 1で見たカードビジネスの構造が、そのまま変数になります。限度額に対する利用額の比率、直近数か月の延滞の推移、入金の規則性、残高が限度額に届く頻度といったものです。生のデータ一行より、比率と推移と直近性で加工した変数のほうが、貸し倒れとよくつながります。

そしてここでも説明という軸が付いてきます。理由を告知しなければならない場なら、できるだけ単調で意味の明確な変数を好みます。貸し倒れの方向と常識的につながる変数であってこそモデルが安定し、後で理由を説明するのも楽になります。自動で大量に作った変数を数千個並べるより、意味の明確な変数が数十個あるほうが、信用では長持ちすることが多いです。

不均衡、でも下手に手を出さないこと

最後は不均衡です。Part 2で、貸し倒れは通常1〜5%の稀な事象だと述べました。そのため一般的な機械学習の助言は「少数クラスを増やせ」という方へ向かいます。オーバーサンプリングやSMOTEといったものです。ところが信用では、ここで一拍止まる必要があります。

問題はキャリブレーションです。モデルが決定木であれロジスティック回帰であれ、データを人為的に半々に合わせると、順位付けの能力は似ていても、出力する確率が実際の貸し倒れ率から離れます。Part 1でEL = PD × LGD × EADを見ましたが、ここでPDは確率そのものが正確でなければなりません。サンプリングで比率を動かすとその確率が膨らみ、ELを計算して価格を付けた瞬間にずれ始めます。

だから信用では、不均衡を扱うときにデータを下手に取り直すより、クラス重みで扱うか、元の比率を保ったまま学習して最後に確率を補正する方をよく選びます。稀な事象だという事実そのものが情報なのに、それを消してはいけません。

AutoMLが来ても残る仕事

最近は金融でもAutoMLが活発に入ってきています。モデルの候補を自動で回し、ハイパーパラメータをチューニングし、変数加工の一部まで自動化してくれるツールです。モデリングの機械的な部分を大きく減らしてくれるのは確かです。では、ここまで話してきたことはじきに要らなくなるのでしょうか。むしろ逆です。自動化が引き取るのは単純作業で、残るのはこの記事が終始強調してきた判断です。

まず、効果的な変数は今も人が作ります。AutoMLは与えられた変数で最適なモデルを見つけてくれますが、どの変数を与えるかは決めてくれません。「限度額に対する利用額が最近どう変わったか」のような変数は、カードビジネスを知っていてこそ浮かぶ仮説です。ドメインから仮説を立て、それを変数に作り上げる仕事、特徴量エンジニアリングの8割は自動化の外にあります。良い変数を入れなければ、どれほど良い自動探索もその上で空回りするだけです。

次に、制約を知る人がモデルを選ばなければなりません。AutoMLはたいてい精度のような一つの指標を最大にする方向に動きます。ところが信用では、最も高い点数を出したモデルが説明できなかったり、確率がずれていたり、規制に引っかかってそのままでは使えないことが多いのです。単調性を強制するか、どのモデルをどこまで許すか、確率をどう補正するかは、制約を理解する人が決めます。

最後に、結果を解釈し、きちんと検証する仕事が残ります。AutoMLが出したモデルをSHAPで覗いて理由に移すのも、その点数が本物かを疑うのも人の役目です。とくに検証がそうです。多くの自動化ツールは既定でランダムな交差検証を使います。ところが先に見たように、信用でランダムに混ぜると未来が過去に漏れ、本番より良く見える点数が出ます。ドメインに合った検証を知らなければ、AutoMLが差し出したバラ色の数字にそのまま騙されかねません。

だから自動化は床を上げてくれるだけで、判断を肩代わりはしてくれません。仮説を立てて変数を作り、制約の中でモデルを選び、結果を解釈して正直に検証する仕事。この記事が扱ったのが、まさにその場所です。

まとめ

信用の機械学習も、性能を見てモデルを選びます。ただその結論が、一般的な直感と違います。

  • 信用データはテーブル形式で、テーブルではディープラーニングではなく決定木ベースのブースティングが勝ちます。性能で選ぶと決定木が最終モデルになることが多いです。
  • ディープラーニングはテーブルデータで性能の優位がないうえ、ブラックボックスなのでリスクも大きいです。その居場所はコアのスコアリングではなく非構造化の補助データです。
  • ロジスティック回帰は性能ではなく説明のために残ります。それ自体で解釈されなければならない場の基本です。決定木を使うときはSHAPのような事後の説明でその要求を満たします。
  • 検証は未来で行います。ランダムに混ぜず、時間を尊重し、同じ顧客を両側に入れません。
  • 性能を分けるのはアルゴリズムより変数で、良い変数はドメインから生まれます。
  • 不均衡には下手に手を出しません。確率を守らなければなりません。
  • AutoMLが入ってきても、仮説で変数を作り、制約の中でモデルを選び、結果を解釈して検証する仕事は人の役目として残ります。

モデルの種類より、そのモデルを取り巻く検証と制約が、信用の機械学習を分けます。

次のPart 4では、モデルを実際に作る工程に入ります。ロジスティック回帰をスコアカードに移す標準的な工程、つまりWOEとIVで変数を加工し、対数オッズを点数にスケーリングし、確率をキャリブレーションする流れを中心に見ていきます。今回が「何を選ぶか」だったなら、次回は「どう作るか」です。


この記事は han-co.com で最初に公開し、韓国語と日本語で連載しています。原文とメール購読 → https://han-co.com/ja/blog/part3-ml-for-scoring

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?