Fundamental、表計算をNEXUSで予測のfoundation modelへ変えた日

Jeremy Fraenkelは、企業の最重要データがdocumentsやpixelsではなくrowsとcolumnsに蓄積されていることを起点にFundamentalを立ち上げた。

公式ローンチ記事の冒頭で、Fundamentalは「the world’s biggest enterprises were leaving trillions of dollars on the table」と説明している。出典

見過ごされたデータから始める

生成AIがtextやimageを扱う一方で、企業の意思決定を支えるstructured dataには、用途ごとに別々の予測モデルを作る手作業が残っていた。

Fundamentalはこのギャップを、tableそのものを理解するfoundation modelの問題として定義した。出典

転機：NEXUSを一行のcodeへ

NEXUSはbillions of tabular datasetsでpre-trainされ、rowsとcolumnsの非線形な関係を学習する。

公式説明では、既存のデータに接続し、複雑なfeature engineeringなしで予測を始められる。出典

ローンチと資金調達

Fundamentalは2026年2月にstealthから公開へ移行し、$30MのSeedと$225MのSeries A、合計$255Mのfundingを発表した。

Oak HC/FTの発表では、Fortune 100企業とのseven-figure contractsとAWSとのpartnershipも公表されている。出典

企業の重要な予測はtableに埋まっているが、用途ごとのfeature engineeringとmodel maintenanceが導入の壁になる。

FundamentalはNEXUSをtable向けfoundation modelとして提供し、demand・fraud・priceなどの予測を一つのmodel familyから始める。出典

ただし実データのschema差を越えるかは、顧客環境での検証が必要だ。

billions of tablesでのpre-training、tabular向けのmodel architecture、enterprise dataとの接続ノウハウがmoatになり得る。

単なるdashboardではなく、予測modelそのものを置き換えるため、精度と導入事例が積み上がれば差別化が強まる。

直接のnetwork effectは弱い。

顧客同士が同じデータを共有するmarketplaceではないためだ。

一方、異なる業界のtabular patternを扱うほどmodelとevaluationの知見が増える、data learning効果は期待できる。

ただし学習データの扱いは要確認。

金融、製造、小売、エネルギーなど、structured dataから予測と意思決定を行うenterprise data science・operations・risk team。

小規模な分析や予測頻度の低い組織には過剰になり得る。

第一に、LLMでは扱いにくいstructured dataへ明確に集中した。

第二に、one line of codeとAWS distributionで、研究成果を導入可能な形へ翻訳した。

第三に、$255M fundingとFortune 100のseven-figure contractsをローンチ時点で示し、enterprise trustを先に作った。出典

tabular dataは業界・企業ごとの差が大きく、pre-trained modelの汎用性がそのままproduction accuracyを意味しない。

公開情報はローンチ時点に偏り、ARR、顧客数、第三者benchmark、長期の運用実績は要確認だ。

enterprise salesとAWS経由に依存する導入も、販売サイクルを長くする可能性がある。出典

research記事でtabular AIの必要性を定義し、enterpriseとの直接契約とAWS marketplace的な導線を組み合わせる。

NEXUSを一つのモデルで複数ユースケースへ展開すれば、demand forecastingからfraud、pricingへland-and-expandできる。出典

主要チャネル: research, content, enterpriseSales, cloudPartnerships

新しいAI基盤の価値は、モデルの新しさだけでなく、既存データから顧客の意思決定までの距離を縮められるかで決まる。

Fundamentalはtableを中心単位に選び、classic MLの設定負債を減らす物語を作った。

一方、性能主張は第三者検証と実ワークロードで読むべきだ。

日本では設備保全、需要予測、不正検知など、tableの更新が業務KPIに直結する領域から検証する。

data residency、監査、private deployment、学習への利用条件を先に定義し、SIerやcloud partnerと導入責任を分担するのが現実的だ。

これは提案であり要検証。