Foundation Modelの種分化 — GPTの代替はGPTではないかもしれない

「同じ週に、金融市場の言語を読むモデルと、時系列を予測するモデルと、tokenizerなしに語るモデルが、同時にGitHubトレンドに上がった。三つとも自分を『foundation model』と呼んだ。三つともLLMではなかった。」

2026年4月第2週現在のGitHub Trendingを開くと、奇妙な風景が広がっている。

shiyu-coder/Kronosが12,180スターを記録し、日次+245で上昇中だ。「A Foundation Model for the Language of Financial Markets」というサブタイトルが付いている。金融市場の注文フロー（order flow）と価格行動を「言語」として扱い、transformerアーキテクチャを適用してそのパターンを学習するモデルだ。中国の大学研究チームのプロジェクトである。

同じ週間トレンドにgoogle-research/timesfmが15,985スター、週次+3,095で上がっている。Google Researchのpretrained time-series foundation modelだ。小売、天気、エネルギー — ドメインを問わずzero-shotで時系列予測を行う。「時系列のGPT」というポジショニングである。

そしてOpenBMB/VoxCPMが7,644スター、日次+496で上がっている。多言語音声合成とvoice cloningを行うモデルだが、核心的な技術的選択が一つある — tokenizer-free。tokenizerを使わない。テキストをトークンに分割することはLLMの最も基本的な前処理ステップだが、VoxCPMはそれを丸ごと捨てた。音声ドメインではトークン化という概念そのものが適切でないという判断だ。

三つのモデルの共通点は二つある。第一に、三つとも自分を「foundation model」と呼んでいる。第二に、三つともLLMではない。テキストを入力として受け取りテキストを出力するモデルではなく、金融注文フロー、時系列数値、音声波形というまったく異なるデータドメインに特化したモデルだ。異なる大陸の異なる研究グループが、同じ週に、同じ言葉を自分のドメインの専門モデルに付けて公開した。

このエッセイは、この同時性が偶然ではなく構造的トレンドの可視化であると主張する。過去3年間AIの言説を支配してきた物語は「より大きく、より汎用的なLLMがすべてを解決する」というものだった。GPT-5、Claude Opus 4.6、Gemini 3.1 — 毎四半期より大きなモデルが登場し、統合主義（unificationism）が当然視された。ところが2026年4月、まさにその研究コミュニティが — 汎用FMを作る能力を持ちながら — ドメイン特化FMを別途作って発表している。なぜか？

この「なぜ」を三つの層位から解剖する。データ、アーキテクチャ、経済学。そしてこの現象を30年前にすでに一度起きた歴史的先例 — データベースの種分化 — と対比しながら、「foundation model」という言葉の意味がどのように変わりつつあるかを論じる。

1. 三つのモデルが汎用LLMと異なる道を歩んだ理由

Kronos — 金融市場の「言語」を読むモデル。 Kronosの最も興味深い点はフレーミングだ。「Language」という言葉が比喩ではなく、アーキテクチャ設計の根拠になっている。金融市場の注文フロー（order flow）— 買い、売り、約定、取消 — を時系列ではなくシーケンスとして扱う。自然言語において単語が並んで文をなすように、注文イベントが並んで市場の「文」をなすという視点だ。

汎用LLMにこのデータを入れられない理由は二つある。第一に、データ形式の不一致。価格（連続型実数）、数量（整数）、注文種別（カテゴリ型）、タイムスタンプ（時刻型）が絡み合った多次元構造化データをテキストに変換すると、「101.35で500株買い」というテキストは（101.35, 500, BUY）というベクトルの数値連続性とスケール関係を離散的トークン埋め込みの中で希薄化させてしまう。第二に、学習データの不在。取引所のマイクロストラクチャデータ、レベル2オーダーブック、ティック単位の約定記録は有償でライセンス制約があり、汎用LLMの事前学習コーパスには含まれない。GPT-5がどれだけ大きくなっても、学習していないデータ分布に対してできることは限られる。12,180スターという数字は、このアプローチへのコミュニティの関心の高さを示している。金融工学の分野でGitHubプロジェクトが一万スターを超えることは極めて稀だ。

TimesFM — 時系列のGPT。 TimesFMのアプローチはより明示的だ。「GPTがテキストに行ったことを時系列に行う」という宣言である。大規模な時系列データでpretrainした後、特定ドメインへのfine-tuningなしにzero-shotで予測を行う。小売店の需要予測、気象観測所の気温予測、電力網の負荷予測 — ドメインを問わない。これまで時系列予測はARIMA、Prophet、N-BEATSなど各モデルを各ドメインに合わせてセットアップするのが標準的なワークフローだった。TimesFMはこのワークフローをひっくり返す。

汎用LLMと決定的に異なるのはinductive biasだ。時間的局所性（temporal locality）、周期性（periodicity）、トレンド（trend）— 時系列固有の構造をアーキテクチャに内在させる。時間軸に対する特別なpositional encoding、多重解像度入力処理、予測地平線（horizon）に最適化されたデコーディング戦略が、同じパラメータ数で汎用モデルより正確な予測を可能にする。Google ResearchがGeminiを作れるリソースを持ちながら、別途ドメインFMを作ったという事実自体が、汎用LLMの時系列処理能力に限界があることを自ら認めたも同然だ。

VoxCPM — tokenizerを捨てたモデル。 VoxCPMは三つのモデルの中で最も急進的な設計選択をした。Tokenizer-free。LLMの世界でtokenizerは空気のような存在だ。GPTシリーズのBPEからSentencePieceまで、すべての主要LLMが何らかの形でtokenizerを使う。VoxCPMはそれを丸ごと取り除いた。

なぜ音声においてtokenizerが問題なのか。テキストは本質的に離散的（discrete）なデータだ。単語の間に明確な境界があり、有限の語彙に還元される。音声は連続的（continuous）なデータだ。波形はなめらかに流れ、トークン化するとプロソディ（prosody）、感情（emotion）、話者特性（speaker identity）といった微細な音響情報が失われる。VoxCPMがvoice cloningを核心機能として掲げられるのは、tokenizerを捨てることで話者特性の情報を保持できるからだ。OpenBMBはTsinghua Universityから始まった研究グループで、大規模言語モデル（CPMシリーズ）を作り続けてきたチームだ。LLMアーキテクチャを熟知しながらも音声ドメインで意図的にtokenizerを廃棄したということは、LLMアーキテクチャが万能ではないことをLLMの専門家自身が宣言したに等しい。

2. 「Foundation Model」という言葉の意味の変遷

「Foundation model」という用語が学術的に定義されたのは2021年、Stanford CRFMが発表した「On the Opportunities and Risks of Foundation Models」（Bommasani et al.）においてだ。「大規模データで事前学習され、多様な下流タスクに適応（adaptation）できるモデル。」注目すべきは、この定義に「汎用」という言葉が必須要素として含まれていない点だ。「多様な下流タスク」はドメイン内の下流タスクであってもよい。時系列予測というドメインの中で、小売予測、気象予測、エネルギー予測 — これも「多様な下流タスク」だ。TimesFMはこの定義を正確に満たしている。

しかしChatGPTの登場（2022年11月）以降、言説においてfoundation modelはGPT-4、Claude、Geminiのような巨大汎用LLMの同義語になった。スケーリング則 — モデルが大きくなるほどより多くの領域でより良く機能する — が理論的根拠であり、ドメイン特化アプローチは「リソースが不足する研究室の次善策」として扱われてきた。

2025年後半から風向きが変わり始めた。汎用LLMが驚くべき速度で発展したにもかかわらず、特定のドメインではドメイン特化モデルが汎用モデルを明確に上回り始めたのだ。AlphaFoldがタンパク質構造予測で、GraphCast/Pangu-Weatherが気象予測でそうだった。これらのモデルはLLMではなかったが、それぞれのドメインで「foundation model」という地位を獲得した。2026年4月のKronos、TimesFM、VoxCPMはこの流れの延長線上にあるが、決定的な違いがある。三つのモデルが同じ週に同時にトレンドに上がった。 AlphaFoldやGraphCastがそれぞれ単独で話題になったときは「すごいドメインモデルが出た」という個別の事件だった。今は異なるドメインの異なる研究グループが同時に同じ方向を向いている。これは個別の事件ではなくトレンドだ。

「Foundation model」という言葉が再び元の定義に戻りつつある。ただし今回は「多様な下流タスク」がクロスドメイン（cross-domain）ではなくドメイン内（within-domain）の多様性を意味する。汎用モデルの別名ではなく、特定ドメインの基礎（foundation）となるモデルという文字通りの意味へ回帰している。

3. 歴史的な比喩 — データベース種分化の30年

この現象を理解するのに最も適した歴史的比喩はデータベースの歴史だ。同じ力（経済的圧力、データ特性の多様化、ワークロードの専門化）が同じ結果（汎用システムの解体と専門システムの台頭）を生み出した構造的同型性（structural isomorphism）が存在する。

1980年代：汎用RDBMSの全盛期。 OracleとIBM DB2が支配した時代。リレーショナルデータベースは一つの技術であらゆるデータの問題を解くという野心を持っていた。財務データも、人事記録も、在庫管理も、分析レポートもすべてRDBMS。これは2023〜2025年の「GPT-4一つでコーディングも翻訳も分析もすればよい」と正確に同じ構造だ。「一つのシステムへの専門性だけ確保すればよく、運用チームを一つだけ置けばよい」という論理が通用していた。

1990〜2000年代：最初の亀裂と加速。 企業のデータワークロードが大きく二種類に分かれることが次第に明確になった。OLTP（Online Transaction Processing）— 銀行振込、注文受付、在庫引落。少量のデータを非常に速く読み書きするワークロード。OLAP（Online Analytical Processing）— 月別売上推移、地域別販売比較、顧客セグメント分析。大量のデータを読むだけだが、集計とジョインが複雑なワークロード。問題はOLTPが行（row）単位のアクセスと書き込み性能を、OLAPが列（column）単位のアクセスと読み込み性能を要求するという点だった。一つのエンジンが両方をうまくこなすことはできるが、どちらか一方を極限まで最適化するともう一方が犠牲になる。OLAP専用データウェアハウスの誕生だ。

2000年代にはVertica、Greenplumなどカラム指向ストア（columnar store）がOLAPにおいて行ベースのRDBMSと比べて10〜100倍の性能向上をもたらした。「分析クエリは少数の列しかアクセスしない」という事前仮定をストレージ設計に内在させたinductive biasの勝利だった。

2010年代：カンブリア爆発。 各データ型とワークロードに最適のエンジンが別々に存在するというのが業界の合意となった。Neo4j（グラフ — 関係探索が定数時間）、InfluxDB（時系列 — 時間範囲クエリとダウンサンプリングを内蔵）、Elasticsearch（全文検索 — 転置インデックスベースのミリ秒検索）、MongoDB（ドキュメント — 柔軟なスキーマ）、Cassandra（分散書き込み — 大規模イベントストリーミング）、そして2020年代のPinecone（ベクトル — 高次元類似度検索）。Oracleは死ななかった。今もなお企業のコアシステムで稼働している。しかし「あらゆるデータの問題をOracleだけで解く」という時代は終わった。各ワークロードに最適のツールを選ぶ — polyglot persistence — が新たな標準となった。

FMの世界へのマッピング。 VerticaがOracleをOLAPで打ち負かしたのは、適切なinductive biasが適切なワークロードで汎用システムを打ち負かしたということだ。TimesFMが時系列予測でGPTを打ち負かすのも同じメカニズムだ。Neo4jがテーブルという概念そのものを捨て、ノードとエッジというまったく異なる抽象化を導入したことは、VoxCPMがtokenizerを捨てたことと同種の決断だ。互換性を放棄する代わりに、自分のドメインで汎用システムが到達できない性能を手にした。

4. 種分化の三つの力

データモート（data moat）— LLMが見ていない世界

汎用LLMの事前学習コーパスは一文で要約できる — 人間がテキストとして書いてインターネットに上げたもの。Common Crawl、Wikipedia、コードリポジトリ、学術論文、ソーシャルメディアが数兆トークン規模で合わさって学習データとなる。

Kronosが扱う金融注文フローはこのコーパスには含まれていない。取引所のマッチングエンジンがミリ秒単位で生成する機械データであり、有償でライセンス制約があり、リアルタイムストリーミングだ。GPT-5がどれだけ大きくなっても、このデータを学習していなければ、このデータの分布を理解できない。GPTの金融知識は市場に対する人間の解釈 — ニュース記事、レポート、ブログ — から来る。これは市場そのものではなく、市場についての二次情報だ。Kronosは市場そのもののデータで学習する。この差は根本的だ。

TimesFMが扱う時系列データも同様だ。センサーが秒単位で計測する温度、湿度、電力消費量はテキストではない。ほとんどの時系列データは工場のSCADAシステム、病院の患者モニタリング機器、電力会社のスマートメーターの中にある。VoxCPMが扱う音声はさらにテキストから遠い。人の声に込められた感情、アクセント、リズム、呼吸はテキスト書き起こし（transcription）には還元されない。LLMが音声について知っているのは、音声をテキストに変換した後のテキストについてのことだ。音声そのものではない。

データベースの歴史においてこれに対応するのはデータ型の多様化だ。1980年代にはほぼすべての企業データが整形テーブルに還元可能だった。2010年代にはJSONドキュメント、グラフ、時系列、全文テキスト、高次元ベクトルなど還元不可能なデータ型が急増し、汎用RDBMSの行列モデルではこの多様性を効率的に扱えなくなった。

Inductive bias — 構造的な事前知識の価値

汎用transformerの強みは最小限の仮定でほぼあらゆるシーケンスデータを処理できることだ。しかし最小限の仮定は両刃の剣だ。時系列には「近い時点が遠い時点より重要だ」という強い構造があり、金融データには平常時と危機という質的に異なるregime structureがあり、音声にはフォルマント（formant）構造と基本周波数（F0）という周波数領域の構造がある。汎用transformerはこうした構造をデータから学習しなければならないが、ドメインFMはこの構造をアーキテクチャに直接内在させる。結果として同じパラメータ数で、より少ないデータで、より少ない計算で、より正確な結果を出せる。データベースにおいて転置インデックスが全文検索でB-treeを圧倒し、R-treeが空間クエリで汎用インデックスを打ち負かすのと同じメカニズムだ。各データ構造は特定のアクセスパターンに対する事前仮定を実装したものであり、その仮定が合うワークロードで汎用データ構造を凌駕する。

計算経済学 — 1Bが1Tを打ち負かす地点

汎用LLMは数千億パラメータ以上であり、ドメインFMは数億パラメータ規模だ。推論コストはパラメータ数におおよそ比例する。具体的に比較してみよう：企業が毎日100万件の時系列予測を行わなければならないとする。GPT-5 APIにデータをテキストに変換して送ると（入力$10/1Mトークン、出力$30/1Mトークン基準）日次約$8,000、月次約$240,000（約3,200万円）。TimesFMをA100 GPU 2枚で自社配備すれば月約$6,000（約800万円）。コスト差約40倍、そしてドメインFMの精度の方が高い。より安くより正確であれば、選択は意思の問題ではなく算術の問題だ。

これは2010年代にOracle RACライセンスに数億円を払っていた企業がオープンソースのCassandraで同じワークロードを10分の1のコストで処理できるようになると離脱が始まったのと同じダイナミクスだ。Oracleの技術的優秀性は経済的合理性の前で力を失った。もちろんドメインFMには汎用LLM APIにはないコストがある。モデルの配備と運用のエンジニアリング負担、モデルのアップデートとfine-tuningの継続的コスト、障害対応とモニタリングインフラ構築のコストだ。しかしこの追加コストを考慮しても、大量処理ワークロードでは総所有コスト（TCO）が汎用LLM APIより低い。データベースの世界でOracleだけよりPostgreSQL+Elasticsearchの組み合わせのTCOが低くなるティッピングポイントを超えた企業がひとつひとつOracleを離れ始めたように、FMの世界でも同じ転換が近づいている。

5. Tokenizer-freeの意味 — 種分化の物理的証拠

VoxCPMのtokenizer-free設計は別途論じる価値がある。この選択は単なる技術的決断ではなく、FM種分化の最も明確な物理的証拠だからだ。

TokenizerはLLMアーキテクチャの第一層であり、すべての入力はこれを通過しなければならない。テキストは本質的に離散的であるため — アルファベット、音節、単語という自然な分割単位が存在するため — BPEのようなアルゴリズムが自然に機能する。しかし音声、画像、時系列のような連続的なデータにはこうした自然な分割単位がない。音声波形を20msフレームに区切るのは慣例に過ぎず、物理的必然性ではない。VoxCPMがtokenizerを捨てたということは、「LLMのデータ処理パイプラインを音声ドメインに強制的に適用することが不適切だ」という宣言だ。

生物学的種分化において二つの集団が同じ種かどうかを判断する核心的な基準は交配可能性（reproductive compatibility）だ。tokenizerがあるモデルとないモデルはデータパイプラインのレベルで互換性がない。同じ入力を受け取れず、同じ出力形式を生成せず、同じ評価フレームワークで比較できない。KronosとTimesFMはまだ何らかの形のトークン化（discretization）を行っており、LLMと共通の祖先の痕跡を共有している。VoxCPMはその最後の共通点まで捨てた。データベースの歴史においてNeo4jがテーブルという概念そのものを廃棄し、ノードとエッジというまったく異なる抽象化を導入したこと、SQLではなくCypherという新しいクエリ言語を作ったこととと同種の決断だ。RDBMSとの互換性を放棄する代わりに、グラフデータで到達不可能な性能を手にした。

6. Polyglot FM時代と結論

データベースの世界でpolyglot persistenceが定着するのに約10年かかった。2005年頃に最初の専門DBが登場し、2015年頃に「ワークロードごとに最適のDBを選ぶ」ということが業界の常識となった。Oracleは死ななかった。しかしOracleの地位は「唯一の選択」から「複数の選択肢の一つ」へと変わった。

FMの世界でも同じ軌跡が見えている。GPT-5、Claude、Geminiのような汎用LLMはテキストベースの汎用タスクにおいて依然として最良の選択であり続けるだろう。しかし「あらゆるAIの問題をGPTで解く」という時代は終わりを迎えつつある。企業のAIスタックは次のような形になっていく。

  • テキスト生成/一般推論: Claude、GPT、Gemini（汎用LLM）
  • 時系列予測: TimesFMまたは後続のドメインFM
  • 金融分析: Kronosまたは後続の金融FM
  • 音声合成/処理: VoxCPMまたは後続の音声FM
  • 検索/埋め込み: 検索特化の埋め込みモデル

この構造において価値が移動する方向は明確だ。個別のFMはcommodity化され、オーケストレーションレイヤー — どのFMをどのタスクにどのようにルーティングするか — の価値が浮上する。データベースの世界で個別のDBがcommodity化され、データパイプラインツール（Airflow、dbt、Fivetran）の価値が浮上したのと同じだ。興味深いことに、このオーケストレーション自体が汎用LLMの新たな役割になる可能性がある。「すべてを直接答えるモデル」から「適切な専門家を探してくれるルーター」への転換。OracleがほかのDBとの接続性（Oracle Data Integrator、GoldenGate）をコアプロダクトとして打ち出し始めたのと似た軌跡だ。

FMの種分化は汎用LLMの失敗ではない。技術的成熟（maturation）の証だ。生物学において種分化は共通の祖先が失敗して起きるのではなく、異なる環境でそれぞれより良く適応した変異が選択されることで起きる。ダーウィンのフィンチがガラパゴス諸島の各島で異なる食料に適応してくちばしが変わったように、FMが各ドメインのデータ特性に適応してアーキテクチャが変わっていく。GPT-5が時系列予測を苦手とするからTimesFMが登場したのではない。時系列予測というワークロードが十分に重要であり、十分に固有の特性を持っているため、専用FMが汎用LLMより優れた解法を提供できるようになったのだ。

この点で「GPTの代替はGPTではないかもしれない」というこのエッセイのサブタイトルが意味を持つ。GPTの代替は「より良いGPT」（より大きな汎用LLM）かもしれないが、ますます多くのドメインでGPTの代替は「GPTではないもの」（ドメイン特化FM）になりつつある。これらの代替はGPTより小さく、GPTより狭く、GPTより安い。しかしそれぞれのドメインでGPTより優れている。

2026年4月10日のGitHub Trendingは一つの問いを投げかけている。「Foundation modelは一つの巨大な汎用モデルであるべきか、それともドメインごとにそれぞれの基礎モデルがあるべきか？」このエッセイの答えは後者だ。Kronosは金融市場の言語を直接読み、TimesFMは時系列の構造をアーキテクチャに内在させ、VoxCPMはtokenizerを捨てた。三つのモデルが同じ週に同時にトレンドに上がったのは偶然ではない。同じ構造的な力 — データモート、inductive biasの優位、計算経済学 — が異なる大陸の研究グループを同じ方向へ導いた。個別の事件ではなくトレンドだ。FMの種分化が始まった。

実務者へのメッセージは一つだ。選択肢を多角化せよ。「我が社のAI = GPT API」という等式を見直せ。自社のコアワークロードが何かを特定し、そのワークロードに最適化されたドメインFMが存在するかを確認せよ。存在するなら、汎用LLMとのコストパフォーマンス比較を行え。存在しないなら、2年以内に登場する可能性を念頭に置いてアーキテクチャを設計せよ。この検討なしに慣性で汎用LLM APIを選び続けることは、2015年に「すべてのデータをOracleに入れよう」と決定するのと同種の過ちかもしれない。データベースの歴史が教えてくれるのは、汎用から専門への転換は一夜にして起きないが、その転換が始まる時点を認識した企業と認識しなかった企業の差は10年後に非常に大きいということだ。2026年4月10日のGitHub Trendingは、その始まりを告げるシグナルの一つだ。GPTの代替はGPTではないかもしれない。

出典: