Googleが「タブデータのゼロショット基盤モデル」TabFMを公開——XGBoostの時代は終わるのか
タブデータの機械学習といえば、長らく「XGBoostを立てて、ひたすらチューニングする」が現場の正攻法だった。そこにGoogleが、ゼロショットで動く基盤モデル「TabFM」を投じてきた。
タイミングとして興味深いのは、これがTimesFMの延長線上にある点だ。GoogleはTimesFMで時系列予測をゼロショット化した。今回はそのロジックをタブデータに持ち込んだ、という位置づけになる。単なる新モデルの発表ではなく、Googleが「基盤モデルで業務データ予測を一掃する」という方向性を着々と進めているサインとして読んだほうがいい。
XGBoostが支配してきた世界に、ゼロショットモデルが来た
タブデータ——つまり行と列で整理された構造化データ——は、企業の意思決定の根幹を支えている。顧客の離脱予測、与信スコアリング、在庫の需要予測。これらの多くは今もXGBoost、ランダムフォレスト、AdaBoostといったツリー系アルゴリズムで動いている。
問題はその「整備コスト」だ。GoogleのブログはXGBoostを例に挙げて、こう書いている。「.fit()を一回呼べば終わり、というわけではない。ハイパーパラメータの最適化とドメイン固有の特徴エンジニアリングに、データサイエンティストは膨大な時間を費やさなければならない」。
これは誇張ではない。現場にいる人間なら刺さる話のはずだ。データが変わるたびに、同じような試行錯誤を繰り返す。それが「タブデータMLのボトルネック」として長年放置されてきた。
TabFMはこのボトルネックを、インコンテキスト学習（ICL）で攻略しようとする。
TabFMはどう動くのか——3つの仕組みを整理する
LLMがユーザーの指示をプロンプトで受け取り、重みを更新せずにタスクをこなすのと同じ発想だ。TabFMは、訓練データと予測対象データをまとめて一つのプロンプトとして受け取り、推論時にテーブルの構造を文脈から読み解く。モデルの重みは変わらない。
ただ、テーブルをそのままトークン化するのは素朴すぎる。言語は1次元の順序列だが、テーブルは2次元で、かつ行や列の順序に本質的な意味がない。この難しさに対応するために、TabFMは3つの仕組みを組み合わせている。
1. 交互行列Attention
まず生のテーブルを、列方向（特徴量）と行方向（サンプル）に交互にAttentionをかけるモジュールで処理する。TabPFNに近い設計で、特徴量間の複雑な依存関係を自動的に捉える。いわば「手作業の特徴エンジニアリングをモデルが肩代わりする」ステップだ。
2. 行圧縮
この文脈化された各行の情報を、一つの密なベクトルに圧縮する。
3. ICL Transformer
圧縮されたベクトル列に対して、別のTransformerがAttentionを行う。TabICLのアプローチに倣って「生のグリッドではなく圧縮済みベクトル」を処理することで、計算コストを大幅に削減している。大規模なデータセットでも推論を現実的なコストに抑えるための設計だ。
事前学習については、ここが特に面白い。タブデータの高品質な大規模オープンデータセットは「産業データには独自スキーマと機密情報が含まれる」という理由で極端に少ない。そこでTabFMは、構造的因果モデル（SCM）を使って動的に生成した数億件の合成データセットで訓練されている。「合成データしか現実的な選択肢がない」という判断は正直で、同時に正しい。
ベンチマーク結果を素直に読む
評価は「TabArena」という生きたベンチマークシステム上で行われた。頭打ちになりがちな固定データセット評価ではなく、ヘッドトゥヘッドの勝率からELOスコアを計算する仕組みだ。
対象は38の分類データセットと13の回帰データセット、サンプル数は700から150,000と幅広い。
結果として、TabFMは上位に食い込んでいる。ただし構成に注意が必要だ。
- TabFM（標準版）：一切のチューニングなし、単一の順伝播で予測を生成。
- TabFM-Ensemble：交差特徴とSVD特徴を追加し、32モデルのアンサンブルを非負最小二乗法で最適化。分類ではPlattスケーリングによる補正も加える。
Ensemble版がより高いスコアを出しているのは当然だが、見逃してはいけないのは「チューニングなし版（TabFM単体）でも既存の強力な手法に対して競争力を持つ」という点だ。単一フォワードパスで現行の主要モデルに並ぶなら、現場のユースケースは十分ある。
ここからは見方だが——「ゼロショット」という言葉の使われ方に注意
「ゼロショット」という言葉は今、マーケティング文脈でかなり雑に使われている。TabFMの場合はどうか。
正直に言うと、TabFM単体は本当にゼロショットだ。モデルをダウンロードして、テーブルを渡して、予測が出る。チューニング不要。これは従来の基準では素直に評価できる。
一方、TabFM-Ensembleは話が変わる。SVD特徴の計算、アンサンブル重みの最適化、Plattスケーリング——これらは「手作業が減った」とは言えるが「ゼロ」ではない。より高い精度が必要なユースケースでは、依然として追加の処理ステップが要る。
この区別は重要だ。ゼロショット版で十分なのか、Ensemble版が必要なのかは、タスクの精度要件次第だ。「ゼロショット基盤モデル」という看板だけを信じて導入を決めると、実際の用途でギャップが生じる可能性がある。
もうひとつ視点を加えると、BigQueryへの統合はこのモデルの「本丸」かもしれない。数週間以内にAI.PREDICTというSQLコマンドで分類・回帰が実行できるようになると発表されている。SQLを書ける人間なら、ML専門知識がなくても予測モデルが使える状態になる。これは「MLエンジニアが必要か」という議論に直結する話だ。
実務者はどこを見ればいいか
データサイエンティスト・MLエンジニア向け
まず触ってみることに損はない。HuggingFaceとGitHubにすでに公開されている。TabFM単体で自分のデータに対してどのくらいのベースラインが出るかを確認する。XGBoostの初期スコアと比較する。その差がチューニング工数に見合うかどうかが、実際の判断軸になる。
特に「データが小さい・新しいドメイン・チューニング工数をかけたくない」というケースでは、真剣に検討する価値がある。逆に、長期間安定稼働しているXGBoostモデルを今すぐ置き換える理由は薄い。
プロダクト・事業サイド向け
BigQueryユーザーであれば、AI.PREDICTの提供開始タイミングを追っておくべきだ。既存のBigQueryワークフローにML予測を組み込むコストが劇的に下がる可能性がある。PoC（概念実証）のハードルが下がるということは、「とりあえず試してみる」を意思決定に組み込みやすくなるということでもある。
経営・投資判断をする人向け
「タブデータML基盤モデル」という領域で、GoogleがTimesFM（時系列）→TabFM（分類・回帰）と着実に範囲を広げている。BigQueryとの統合は、クラウドロックインの文脈でも読める。Google Cloudのデータ分析インフラに乗っているユーザーに対して、ML機能を追加コストなしで提供し、離脱コストを上げる。これはGoogleとしての合理的な戦略だ。
次に来る論点
精度が出るとして、次に問われるのは3点だ。
1. 推論コストと速度
単一フォワードパスは「学習不要」という意味では速いが、大規模テーブルを毎回文脈として渡すコストは無視できない。バッチ処理や常時稼働のシステムでどのくらいのレイテンシとコストになるかは、現時点で公開情報が少ない。
2. 説明責任
XGBoostのような決定木系は、特徴量の重要度が比較的取り出しやすい。TabFMのようなAttentionベースのモデルは、なぜその予測を出したかを説明する難易度が上がる。金融・医療・保険といった説明責任が求められる業種では、ここが壁になりうる。
3. データドリフトへの耐性
合成データで訓練されたモデルが、時間とともに分布が変化する実データにどう追従するか。ファインチューニング不要という設計は強みだが、ドリフト検出と対応の仕組みをどう整えるかは運用側の課題として残る。
まとめ——軸をひとつ渡しておく
TabFMは「XGBoostが死ぬ」話ではない。ただ、タブデータMLの「最初のベースライン構築コスト」を大幅に下げる可能性は本物だ。
今後、同種の「ゼロショット基盤モデル」を見るときのチェックポイントはシンプルだ。「ゼロショット版と最良版の差はどれだけか」「どのサイズのデータで、どのタスクで評価されているか」「本番運用における説明責任とドリフト対応はどうなっているか」。この3点を見れば、過大評価を避けながら自分の業務に使えるかどうかを判断できる。
TabFMに関しては、まずGitHubとHuggingFaceに公開されている時点で触れる状態にある。手を動かすコストが低いときは、議論より実験を先にするに限る。
参考元: Introducing TabFM: A zero-shot foundation model for tabular data – Google Research Blog
