[レビュー] Googleが6/30に公開したテーブルデータ用の基盤モデルTabFMは、信用でGBMに勝てるか。公開データで直接テストしました
Googleが公開したゼロショットのテーブル基盤モデルTabFMは、学習もチューニングもなしで「よくチューニングしたGBMにも勝つ」と言います。信用の貸し倒れに実際に使えるでしょうか。公開クレジットカードデータで、よく作ったGBMと競わせた実務者レビューです。
この記事は連載「レビュー」の第1回です。新しく出たツールが信用の実務に本当に役立つのかを、実務者の目線で試す場です。
Googleが最近TabFMを公開しました。テーブルデータをそのまま入れれば、学習もチューニングもなしで予測し、「ゼロショットでよくチューニングしたGBMにも勝つ」と主張するモデルです。GBMが長く支配してきた信用リスクでこれが本当に通用するなら、大きな話です。そこで公開の貸し倒れデータで、よく作ったGBMと直接競わせてみました。先に結論を言うと、私が回したこの条件では、よくチューニングしたGBMがわずかに上でした。ただしこれは論文が勝ったと述べたのと同じ条件での正面対決ではなく、優劣を断定できるものではありません。何よりTabFMが特徴量エンジニアリングもチューニングもなしに、その最善へぴたりと迫ったことが肝心です。
TabFMとは
TabFMはGoogleが2026年6月末に公開したテーブルデータ用の基盤モデルです。核心はゼロショットです。データセットごとに学習し直したり、ハイパーパラメータを合わせたり、特徴量を作ったりしません。代わりに学習データを一つのコンテキストとして読み込み、予測は一度のforward passで終えます。これをin-context learningと呼びます。GPTが例をいくつかプロンプトで受け取って答えるのに似て、TabFMはテーブル全体をプロンプトのように受け取り、その場で答えます。
これができるのは、あらかじめ途方もなく学習してあるからです。ところが画像やテキストと違って公開のテーブルデータはそれほど多くないので、Googleは構造的因果モデル(SCM)でテーブルデータを数億個合成し、それで事前学習しました。学習した構造は三つの部分です。行と列に交互にアテンションを与えて特徴量どうしの関係をとらえ、各行を密なベクトルに圧縮し、その上でin-context学習によって予測します。テーブルデータ基盤モデルの先行した試みであるTabPFN系の発展形と見ればよいでしょう。
セリングポイントは明確です。特徴量エンジニアリングも、ハイパーパラメータのチューニングも要らない、ということ。つまり実務でGBMに注ぐ労力を0にできるという主張です。そしてGoogleはTabArenaベンチマークで、このゼロショットモデルが手間をかけてチューニングした教師あり学習モデル、とりわけGBM系をELO順位で上回ったと報告しています。分類38個と回帰13個、標本700個から15万個の間のデータセットを集めたベンチマークです。モデルは今Hugging FaceとGitHubに公開されており、BigQueryには数週間のうちにSQL一行(AI.PREDICT)で呼べる形で入ってくるとのことです。
実験の目的: 信用の貸し倒れに使えるか
気になったのは一つでした。一般のベンチマークでGBMに勝つというこのモデルが、信用の貸し倒れでもそうなのか。
Part 3で私は、テーブル形式の信用データではディープラーニングではなく決定木ベースのブースティングが勝つと整理しました。TabFMはまさにその結論を覆すという主張なので、再検証する価値がありました。しかも信用は一般のベンチマークと違います。貸し倒れは稀な事象で、順位だけでなく確率が正確でなければならず(Part 5)、否決理由を説明できなければなりません(Part 4)。一般のデータで勝っても信用では違いうる、ということです。そこでゼロショットのTabFMがよくチューニングしたGBMに信用でも勝つのかを、公開データで直接確かめてみました。
データとモデル
データはUCIの台湾クレジットカード貸し倒れデータです。3万人、23個の特徴量、貸し倒れ率22%。直近6か月の延滞状態と請求・支払額が主な特徴量で、文献上は標準的なモデルがおおよそAUC 0.77から0.78あたりで頭打ちになる、信号の限られたデータとして知られています。
公平な比較の核心は、モデルと特徴量を分けることです。「特徴量エンジニアリングしたGBM」と「素のTabFM」をそのまま比べると、差が出てもそれがモデルのおかげか特徴量のおかげか分かりません。そこで複数のベースラインを並べました。
| 名前 | 正体 |
|---|---|
| GBM 素 | LightGBM、特徴量・チューニングなし (労力の下限) |
| GBM チューニング | LightGBM + エンジニアリング特徴量 + Optuna チューニング |
| CatBoost / XGBoost | 特徴量 + チューニングした強いベースライン |
| TabFM ゼロショット | 素のまま、単一の forward pass (本命) |
| TabFM アンサンブル | 論文プリセット (派生特徴量 + キャリブレーション) |
GBM系は延滞の動態のような特徴量を足してOptunaでチューニングしました。TabFMは素のまま、チューニングは0です。確率が実際の貸し倒れ率と合うよう、すべてのモデルを自然な比率で学習しました。指標は信用に合わせて判別(ROC-AUC、PR-AUC、KS)とキャリブレーション(Brier、ECE)を一緒に見ました。Part 5で見たあの二つの軸です。貸し倒れが22%なのでごく激しい不均衡ではありませんが、稀な貸し倒れをどれだけ捉えるかはPR-AUCでも確認しました。層化5-foldで検証しました。
検証結果
| Arm | ROC-AUC | PR-AUC | KS | ECE ↓ | 所要時間 |
|---|---|---|---|---|---|
| GBM チューニング (LightGBM) | 0.789 | 0.566 | 0.443 | 0.010 | 548秒 |
| XGBoost | 0.789 | 0.565 | 0.439 | 0.009 | 102秒 |
| CatBoost | 0.788 | 0.566 | 0.444 | 0.011 | 1179秒 |
| TabFM ゼロショット | 0.785 | 0.558 | 0.441 | 0.022 | 503秒 |
| GBM 素 | 0.779 | 0.554 | 0.429 | 0.013 | 0.5秒 |
| TabFM アンサンブル | 0.774 | 0.540 | 0.418 | 0.018 | 268秒 |
読み取れるのは三つです。
一つ目、よくチューニングしたGBM(0.789)がTabFMゼロショット(0.785)をわずかに上回ります。木3種がすべてTabFMの上にあり、PR-AUCで見ても順序は同じです(TabFM 0.558、チューニングGBM 0.566)。差は0.4%pでfoldの標準偏差(0.006)の中なので統計的には引き分けに近いですが、方向は一貫してGBMが上です。「ゼロショットがチューニングGBMに勝つ」はこのデータでは成り立ちませんでした。
二つ目、労力なし同士で比べると話が違います。TabFMゼロショット(0.785)は素のGBM(0.779)を超えます。特徴量もチューニングもなしで、です。速いベースラインとしては確かに魅力的です。
三つ目、キャリブレーションも互角です。自然な比率で学習すれば木も確率がよく合い(ECE 0.010)、TabFMは0.022でわずかに劣ります。どちらも確率が大きく外れてはいません。
そして三つのブースティングが0.7885から0.7891の間に収束します。モデルを変えて特徴量とチューニングを足しても上がらない、このデータの天井が0.79ほどだということです。どちらもその上には行けませんでした。
まとめると、少なくともこの実験ではTabFMがよく作ったGBMを退けたのではなく、労力なしでそこへ迫りました。同じ条件ではなかった点を踏まえる必要があります。
この実験の限界
この検証結果は、いくつかの条件の中でのみ有効です。
- データが一つです。台湾クレジットカードの一データセットなので一般化は保証できません。他の貸し倒れデータでは順位が変わりうります。
- 信号が限られています。23個の特徴量に天井が0.79なので、そもそもモデルが広げられる幅が狭かったです。特徴量が多く信号の豊かなデータでは違って出るかもしれません。
- シード一つで、out-of-time検証はできませんでした。信頼できる時間列がなくランダム層化で分けましたが、Part 3で強調したように実際の信用モデルは時間で分けて検証するほうが厳格です。
- TabFMは8GB GPUで回しました。そのため下の「モデル自体の限界」に挙げたアンサンブル構成をきちんと踏めておらず、上の表のTabFMの数値は下限として読むべきです。
モデル自体の限界
実験を離れて、TabFMを実務に入れるときに引っかかることです。
- ブラックボックスです。基盤モデルなので係数も、明確なルールもありません。否決理由を告知し監督当局に説明しなければならない信用審査(Part 4)には、そのまま使いにくいです。SHAPのような事後の説明を付けることはできますが、スコアカードのようにモデル自体が説明になるわけではありません。
- 高性能なGPUが要ります。モデルの重みだけで6.5GBあり、GPUなしでは推論が十倍以上遅く、論文プリセット(アンサンブル・大きなコンテキスト)は16GB以上のGPUがないときちんと回りません。CPU一台でもよく回るGBMと対照的な点です。
- データと特徴量の規模に上限があります。in-context学習は学習データをまるごとプロンプトのように読みますが、アテンションがコンテキストの二乗で膨らみます。そのため数百万行の大規模な信用データや特徴量が非常に多いデータは、そのまま載せにくいです。この系列のモデルがそもそも中小規模のテーブルを狙って作られた理由です。
- 推論が重いです。保存しておいたGBMは一行でスコアを出しますが、TabFMは予測のたびに学習データを読み直します。大量のリアルタイムスコアリングでは、このコストが負担になります。
- まだ新しいです。出たばかりのモデルなので、実務の検証実績も、規制の受容事例もありません。
これから、そしてあなたも
TabFMは今Hugging Faceで受け取って使え、数週間のうちにはBigQueryでSQL一行でも呼べるようになるとのことです。参入障壁がそれだけ下がるので、大きなGPUがあるか、BigQueryの統合が開いたら、アンサンブルのプリセットまできちんと回して、より大きなデータで再び試してみるのもよいでしょう。とりわけ小標本のデータ、特徴量の豊かなデータ、そして時間で分けた検証でどう出るかが気になります。この記事の結論は台湾カード一勝負の話にすぎないのですから。
私の結論はこうです。この一度の実験ではGBMがわずかに上でしたが、論文が勝ったと述べた条件(大規模で多様なデータ・アンサンブルプリセット・十分なGPU)で競ったわけではないので、「勝てない」と断定はできません。確かなのはこうです。特徴量もチューニングもなしにその最善へ0.4%p以内で迫る、たいへん速いベースラインだということ。プロトタイピングや最初のベースラインとしては今すぐ魅力的で、最終的な性能と正確な確率、説明まで要るプロダクションの信用モデルなら、まだよくチューニングしたGBMが無難な選択です。Part 3の結論が崩れたと見るのは早いですが、いまや労力なしで肉薄する候補が一つできました。
付録: コードとデータ
- データ: UCI Default of Credit Card Clients (台湾), 公開データ
- TabFM 原文: Google Research ブログ · Hugging Face · GitHub (モデルの構造図とベンチマークは原文で見られます)
- コード: github.com/HangilKim11/blog-research/tree/main/tabfm-credit (韓国語・日本語ノートブック)
- 再現: 層化5-fold