ファウンデーションモデルの種分化 — GPTの代替はGPTではないかもしれない

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

2026年4月10日時点でGitHub Trendingを開くと、奇妙な光景が見える。

shiyu-coder/Kronosが12,180スターを記録し、日次+245で上昇している。「A Foundation Model for the Language of Financial Markets」という副題が付いている。金融市場の注文フローと価格行動を「言語」として扱い、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。トークナイザーを使わない。テキストをトークンに切り分けるのはLLMの最も基本的な前処理段階だが、VoxCPMはそれをまるごと捨てた。音声ドメインにおいてトークン化という概念自体が適合しないという判断だ。

三つのモデルの共通点は二つある。第一に、三つすべてが自身を「foundation model」と呼ぶ。第二に、三つすべてがLLMではない。テキストを入力として受けテキストを出力するモデルではなく、金融注文フロー、時系列数値、音声波形という全く異なるデータドメインに特化したモデルだ。互いに異なる大陸(中国の大学、Google Research、OpenBMB)の互いに異なる研究グループが、同じ週に、同じ単語 — foundation model — を自分のドメインの専門モデルに付けて公開したのである。

本エッセイはこの同時性が偶然ではなく構造的趨勢の可視化であると主張する。過去3年間AI言説を支配したナラティブは「より大きく、より汎用的なLLMがすべてを解決する」だった。GPT-5、Claude Opus 4.6、Gemini 3.1 — 四半期ごとにより大きなモデルが登場し、そのモデルがより多くの領域をカバーしながら「一つの巨大な汎用FMがすべてのドメインの問題を解く」という統一主義(unificationism)が当然視されてきた。ところが2026年4月、まさにその研究コミュニティが — 汎用FMを作る能力があるにもかかわらず — ドメイン特化FMを別途作って出している。なぜか。

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

前のエッセイ「オープンモデル戦争2026」で分析したのはAIモデルの「オープン vs クローズド」軸だった。GoogleがGemma 4をApache 2.0でリリースし、AMDがLemonadeをオープンソースとして公開し、AlibabaがQwen 3.6-Plusを公開した — その戦争はモデルのアクセス方式に関するものだった。本エッセイが扱うのはその戦争と直交する別の軸だ。汎用 vs 特化。オープンであれクローズドであれ、すべてのモデルが汎用を志向すべきか、それともドメインごとに分かれるべきか。同じ市場の二つ目の断層線だ。

1. 三つのモデル解剖 — 各々が何を別様に設計したか

三つのモデルを単に「ドメイン特化モデル」とまとめるだけでは足りない。各々がなぜ、どんな設計選択を通じて汎用LLMと異なる道を歩んだのかを覗き込んでこそこの種分化の実体が見える。

Kronos — 金融市場の「言語」を読むモデル

Kronosの最も興味深い点はフレーミングだ。「A Foundation Model for the Language of Financial Markets.」ここで「language」という単語は隠喩ではなくアーキテクチャ設計の根拠だ。金融市場の注文フロー(order flow) — 買い注文、売り注文、約定、キャンセル、修正 — を時系列ではなくシーケンスとして扱う。自然言語で単語が順に並んで文を成すように、注文イベントが順に並んで市場の「文章」を成すという観点だ。

この観点でtransformerアーキテクチャを適用するのは自然な選択になる。Attention mechanismはシーケンス内の長距離依存性を捉えるのに強く、金融市場の注文フローには長距離依存性が実在するからだ。午前9時30分に大量の買い注文が入れば、その影響が午後2時の価格変動にまでつながるといった依存性だ。これを自然言語の文脈依存性と構造的に同型(isomorphic)と見るのがKronosの核心的洞察だ。

ところが、なぜGPT-5やClaude Opus 4.6に注文フローデータを入れたらいけないのか。二つの理由がある。

第一に、データ形式の不一致。汎用LLMはテキストトークンを入力として受ける。注文フローデータはテキストではない。価格(連続値の実数)、数量(整数)、注文種別(カテゴリカル)、タイムスタンプ(時間型)が絡んだ多次元の構造化データだ。これをテキストに変換してLLMに入れることはできるが、変換過程で情報が失われる。「101.35に500株買い」というテキストと(101.35, 500, BUY)というベクトルは同じ情報を盛り込んでいるが、前者をトークン化する瞬間に数字の連続性と大小関係が離散的トークン埋め込みの中で希釈される。

第二に、学習データの不在。汎用LLMの事前学習コーパスはインターネットのテキストだ。金融市場の注文フローデータはインターネットに上がらない。取引所のマイクロストラクチャ・データ、レベル2のオーダーブック、ティック単位の約定記録 — これらは有料で、ライセンス制約があり、一般的なウェブクローラーが収集できない。GPT-5がいくら巨大でも、学習したことのないデータ分布に対してできることは限られる。Kronosはこのデータで直接事前学習されたモデルだ。

12,180スターという数字はこのアプローチに対するコミュニティの関心の水準を示す。金融工学分野でGitHubプロジェクトが1万スターを越えるのは極めて稀なことだ。

TimesFM — 時系列のGPT

TimesFMはGoogle Researchのプロジェクトで、アプローチがより明示的だ。「GPTがテキストにしたことを時系列にしよう」という宣言だ。大規模時系列データで事前学習した後、特定ドメインにファインチューニングなしでzero-shotで予測を行う。小売店の需要予測、気象観測所の温度予測、電力網の負荷予測 — ドメインを選ばない。

15,985スター、週次+3,095。この数字が意味するのは時系列予測という問題領域の大きさだ。時系列予測は産業全般にわたって存在する問題だが、これまでその問題を解くためにドメインごとに別々のモデルを最初から訓練しなければならなかった。ARIMA、Prophet、N-BEATS — 各々のモデルを各ドメインのデータに合わせてセッティングするのが標準ワークフローだった。TimesFMはこのワークフローを覆す。一度事前学習すれば、新しいドメインにzero-shotで適用可能だ。

TimesFMが汎用LLMと決定的に違うのはinductive biasだ。時系列データにはテキストにない構造的特性がある。時間的局所性(temporal locality) — 近い時点のデータが遠い時点のデータより予測に重要だ。周期性(periodicity) — 日次、週次、年次のパターンが反復される。トレンド(trend) — 長期的に上昇または下降する方向性がある。汎用transformerはこのような構造をデータから学習しなければならないが、TimesFMのアーキテクチャはこのような構造をモデル設計に内在させる。時間軸に対する特別なpositional encoding、多重解像度の入力処理、予測ホライズン(horizon)に最適化されたデコーディング戦略 — このような設計選択が同じパラメータ数で汎用モデルより時系列予測をうまく行わせる。

Google Researchという名前も重要だ。これは小規模研究室の実験ではない。世界最大規模のAI研究組織が、汎用LLM(Gemini)を作れるリソースと技術を保有しながらも、別途ドメイン特化FMを作って公開したのである。汎用モデルで時系列問題を「十分に」解けたなら、わざわざこういうプロジェクトを進める理由はない。GoogleがTimesFMを作ったという事実そのものが、汎用LLMの時系列処理能力に限界があることをGoogle自身が認めたことを意味する。

VoxCPM — トークナイザーを捨てたモデル

VoxCPMは三つのモデルの中で最も急進的な設計選択をした。Tokenizer-free。LLMの世界でトークナイザーは空気のような存在だ。入力テキストをモデルが処理できる離散的トークンに変換する最初の段階であり、GPTシリーズのBPE(Byte Pair Encoding)からSentencePieceまで、すべての主要LLMが何らかの形でトークナイザーを使う。VoxCPMはこれをまるごと取り除いた。

なぜ音声合成でトークナイザーが問題なのか。テキストは離散的(discrete)データだ。単語と単語の間に明確な境界があり、有限の語彙に還元される。音声は連続的(continuous)データだ。波形は滑らかに流れ、どこで切るかによって意味が変わる。音声をトークン化するということは連続的信号を強制的に離散的単位に切り分けることであり、その過程で必然的に情報が失われる。特に韻律(prosody)、感情(emotion)、話者特性(speaker identity)のような微細な音響特性がトークン化過程で捨てられる。VoxCPMがvoice cloningを核心機能として打ち出せるのは、トークナイザーを捨てることで話者特性情報を保存するからだ。

7,644スター、日次+496。OpenBMBはTsinghua Universityから始まった研究グループで、大規模言語モデル分野で既にいくつかのプロジェクト(CPMシリーズ)を発表してきた。彼らがLLMアーキテクチャをよく知りながらも、音声ドメインでは意図的にLLMの核心構成要素(トークナイザー)を廃棄したことが意味深長だ。これはLLMアーキテクチャが万能ではないことをLLM専門家が自ら宣言したことに近い。

Tokenizer-freeという選択は単なる技術的決定を超えた**種分化のマーカー(marker)**だ。生物学で種分化は共通の祖先から枝分かれした集団が異なる環境に適応しながら交配不可能なほど異なっていく過程だ。LLMとVoxCPMは同じdeep learningという共通祖先から出発したが、VoxCPMがトークナイザーを捨てた瞬間 — LLMの最も基本的なデータ処理パイプラインと互換不能になった瞬間 — 二つのモデルは互いに異なる「種」になったのだ。

2. 「Foundation Model」という単語の意味の変遷

これら三つのモデルが共通に使う「foundation model」という単語はどこから来たのか。そしてその単語の意味は2021年から2026年の間にどう変わったか。

2021年:Stanford CRFMの定義

「Foundation model」という用語が学術的に定義されたのは2021年、StanfordのCenter for Research on Foundation Models(CRFM)が発表した「On the Opportunities and Risks of Foundation Models」(Bommasani et al.)である。この論文でfoundation modelは次のように定義される。「大規模データで事前学習されて多様な下位タスクに適応(adaptation)できるモデル。」核心は**転移可能性(transferability)**だ。一度訓練すれば複数のタスクに使えるということ。

この定義で注目すべきは、「汎用」という単語が定義の必須要素ではないという点だ。Bommasani et al.はfoundation modelが汎用でなければならないとは言わなかった。「多様な下位タスクに適応可能」と言っただけだ。多様な下位タスクはドメイン内部の下位タスクであるかもしれない。時系列予測というドメインの中で小売予測、気象予測、エネルギー予測 — これも「多様な下位タスク」だ。TimesFMはこの定義を正確に満たす。

ところが2021年以降、言説はこの本来の定義を超えて走り抜けた。

2022-2024年:「Foundation Model = 巨大な汎用LLM」への意味収束

ChatGPTの登場(2022年11月)は「foundation model」という単語の意味を事実上再定義した。大衆言説でfoundation modelはGPT-4、Claude、Geminiのような巨大な汎用LLMの同義語になった。スケーリング法則(scaling laws) — モデルが大きくなるほどより多くの領域でよりうまく作動する — がこの収束の理論的根拠を提供した。「モデルを十分に大きくすればすべてのドメインをカバーできる」という信念が業界を支配した。

この時期にドメイン特化アプローチは「レガシー」または「naive」として扱われた。「金融専用モデル? GPT-5が金融もうまくやるだろうに、なぜ?」「時系列専用モデル? LLMに数字データを入れればいいではないか?」こうした反応が主流だった。ドメイン特化モデルはリソース不足の研究室が汎用モデルを作れずに取る次善策という認識が敷かれていた。

2025-2026年:種分化の始まり

ところが2025年後半から風向きが変わり始めた。汎用LLMが驚くべき速度で発展したにもかかわらず、特定ドメインではドメイン特化モデルが汎用モデルを明らかに上回り始めたのだ。AlphaFoldがタンパク質構造予測でそうだったし、気象予測分野のGraphCast/Pangu-Weatherもそうだった。これらのモデルはLLMではなかったが、各々のドメインで「foundation model」という地位を獲得した。

2026年4月のKronos、TimesFM、VoxCPMはこの流れの延長線だが、一つ決定的な違いがある。三つのモデルが同じ週に同時にトレンドに上がった。 AlphaFoldやGraphCastは各々単独で話題になった。あの時は「すごいドメインモデルが出てきたな」という個別の出来事だった。今や互いに異なるドメインの互いに異なる研究グループが同時に同じ方向を向いている。これは個別の出来事ではなく趨勢だ。

「Foundation model」という単語の意味が再び本来の定義 — Bommasani et al.の「多様な下位タスクに適応可能な事前学習モデル」 — へと戻っている。ただし今回はその「多様な下位タスク」が領域横断(cross-domain)ではなくドメイン内(within-domain)の多様性を意味する。Foundation modelは汎用モデルのあだ名ではなく、特定ドメインの基盤(foundation)となるモデルという文字通りの意味へ回帰している。

3. 歴史的アナロジー — データベース種分化の30年

この現象を理解するために最も適した歴史的アナロジーはデータベースの歴史だ。1980年代から2020年代まで約40年にわたるデータベースの進化は、foundation modelがこれから経験する種分化のほぼ完璧な先行事例だ。このアナロジーをエッセイの中心軸にする理由は、単なる比喩ではなく構造的同型性(structural isomorphism)が存在するからだ。同じ力(経済的圧力、データ特性の多様化、ワークロード特化)が同じ結果(汎用システムの解体と専門システムの台頭)を生む。

1980年代:汎用RDBMSの黄金期

1980年代のデータベース市場はOracleとIBM DB2が支配した。リレーショナルデータベース管理システム(RDBMS)は一つの技術ですべてのデータ問題を解こうという野望を持っていた。財務データもRDBMS、人事記録もRDBMS、在庫管理もRDBMS、分析レポートもRDBMS。Edgar Coddが1970年に提案したリレーショナルモデルはデータの「汎用表現」であり、SQLはその汎用表現に対する「汎用クエリ言語」だった。

この時期のOracleは今のGPT-4やClaude Opus 4.6と構造的に同じ位置にあった。「一つのシステムがすべてのワークロードを処理する。」企業はOracleを一つ買ってすべてのデータを入れ、すべてのクエリを回した。もちろんワークロードごとに性能差はあったが、「別のシステムを別々に買うよりOracleで統一する方が総費用(TCO)が低い」という論理が通じた。一つのシステムへの専門性だけ確保すればよく、運用チームを一つだけ置けばよく、バックアップと復旧手順を一つだけ作ればよいからだ。

これは2023-2025年のAI言説と正確に同じ構造だ。「GPT-4一つでコーディングもして翻訳もして分析もすればよい。ドメインごとに別々にモデルを管理するより総費用が低い。」一つのAPIへの専門性だけ確保すればよく、プロンプトエンジニアリングのパターンを一つだけ身につければよく、評価パイプラインを一つだけ作ればよい。

1990年代:OLAPの分離 — 一度目の種分化

1990年代に入ると、一つのRDBMSがすべてのワークロードを処理するという仮定にひびが入り始めた。ひびの原因はワークロードの分化だった。企業のデータワークロードは大きく二種類に分かれることがますます明確になった。OLTP(Online Transaction Processing) — 個別取引を高速で処理すること。銀行振込、注文受付、在庫差引。少量のデータを非常に速く読み書きするワークロードだ。OLAP(Online Analytical Processing) — 大量のデータを集めて分析すること。月別売上推移、地域別販売比較、顧客セグメント分析。大量のデータを読むだけだが、集計とジョインが複雑なワークロードだ。

問題はOLTPとOLAPがデータベースに要求するものが正反対だという点だ。OLTPは行(row)単位のアクセスが速く、並行性制御(concurrency control)が精緻で、書き込み性能が良くなければならない。OLAPは列(column)単位のアクセスが速く、大量スキャン性能が良く、読み込みに最適化されなければならない。一つのエンジンが二つともうまくできるが、どちらか一方を極限まで最適化すれば他方が犠牲になる。汎用RDBMSは両ワークロードで「まずまず」の性能を出したが、どちらでも「最高」ではなかった。

これがデータウェアハウスの誕生につながった。OLAPワークロードだけのための別途のシステムを作ろう。OLTPは既存のRDBMSに残し、分析用データはデータウェアハウスに移して別途クエリしよう。Teradata、Sybase IQのような製品がこの市場を開いた。「汎用は万能ではない」という認識の最初のひびだった。

FMの世界でこの段階に対応するのは何か。汎用LLMがテキスト生成(OLTPに対応 — 速い個別応答)と大規模データ分析(OLAPに対応 — 大量データのパターン抽出)を同時にうまくやらなければならないという仮定のひびだ。コーディングエージェントのワークロードは速い応答と正確なツール呼び出しが必要で、研究分析のワークロードは長いコンテキストと深い推論が必要だ。ClaudeがOpus(高性能分析)とSonnet/Haiku(高速応答)を分離したのは既にこの分化の初期兆候だ。

2000年代:カラムストア革命 — VerticaとGreenplum

2000年代に入ると種分化は加速した。Vertica(2005年)とGreenplum(2005年)が**カラム指向ストア(columnar store)**を引っさげて登場した。伝統的RDBMSがデータを行(row)単位で保存するのと違い、カラムストアは各列(column)を連続したブロックとして保存する。OLAPクエリが通常、全行ではなく特定の列だけスキャンするため、この保存方式はOLAPワークロードで行ベースRDBMSに比べて10倍から100倍の性能向上をもたらした。

これはinductive biasの勝利だ。カラムストアは「分析クエリは少数の列だけアクセスする」という事前の仮定をストレージエンジン設計に内在させたものだ。汎用RDBMSはこんな仮定をしない。だからどんなワークロードにも適用できるが、特定ワークロードで極限性能を出せない。カラムストアは分析ワークロードという狭い領域で汎用RDBMSを圧倒的に打ち負かした。

FMの世界でこの段階に対応するのがまさにTimesFMだ。汎用transformerが時系列データを処理できる。だが時系列の時間的局所性と周期性という構造的特性をアーキテクチャに内在させたTimesFMが、同じパラメータ数で時系列予測を圧倒的にうまく行う。VerticaがOracleをOLAPで打ち負かしたのと同じメカニズムだ。適切なinductive biasが適切なワークロードで汎用システムに勝つ。

2010年代:カンブリア爆発 — Neo4j、InfluxDB、Elasticsearch、MongoDB、Cassandra

2010年代はデータベースのカンブリア爆発だった。一行で要約するとこうだ — 各データ型とワークロードパターンごとに最適なエンジンが別々に存在するということが業界の合意になった。

Neo4j(2007年開始、2010年代に台頭) — グラフデータベース。関係(relationship)が核心のデータに特化。ソーシャルネットワーク、推薦システム、不正検知。RDBMSでJOINを数十段階重ねれば性能が指数関数的に落ちるが、グラフDBで関係探索は定数時間に近い。
InfluxDB(2013年) — 時系列データベース。センサーデータ、モニタリング・メトリクス、IoTデバイスデータ。時間軸に沿って連続的に生成されるデータに特化。時間範囲クエリ、ダウンサンプリング、リテンションポリシーが標準内蔵。
Elasticsearch(2010年) — 検索エンジン。全文検索(full-text search)に特化。逆インデックス(inverted index)というRDBMSとは全く異なるデータ構造を核心に据える。RDBMSでLIKE ‘%keyword%‘でテキストを検索すれば全テーブルをスキャンしなければならないが、Elasticsearchは逆インデックスのおかげでミリ秒で結果を返す。
MongoDB(2009年) — ドキュメントデータベース。スキーマが流動的で半構造化されたデータに特化。JSONドキュメントをそのまま保存しクエリする。RDBMSの厳格なスキーマがむしろ邪魔になるワークロードで採用された。
Cassandra(2008年) — 分散ワイドカラムストア。大規模書き込み処理に特化。書き込み性能が読み込み性能より重要なワークロード(ログ収集、イベントストリーミング)に適する。
Pinecone(2021年、2020年代の追加的種分化) — ベクトルデータベース。高次元ベクトルの類似度検索に特化。AI時代に埋め込みベース検索が急増しながら登場した最新の種分化事例だ。

各々のデータベースは特定のデータ型とワークロードパターンに対する深い理解を設計に反映した。そして各々が自分の領域で汎用RDBMSを圧倒的に打ち負かした。Oracleが死んだか。違う。Oracleは依然として巨大な会社で、RDBMSは依然として企業の中核システムで回っている。だが「すべてのデータ問題をOracle一つで解く」時代は終わった。2020年代の企業はOLTPにPostgreSQL、OLAPにBigQuery、検索にElasticsearch、キャッシュにRedis、ベクトルにPineconeを使う。各ワークロードに最適のツールを選ぶ。これをpolyglot persistenceと呼ぶ。

ではこのアナロジーをFMの世界にマッピングしよう。

4. 種分化の力学 — なぜ汎用LLMがすべてのドメインをカバーできないのか

データベースの種分化を導いた力は三つだった。データ型の多様化、ワークロードパターンの分化、経済的圧力。Foundation modelの種分化を導く力もまさに同じ三つだ。

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

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

Kronosが扱う金融市場の注文フローデータは人がテキストで書いたものではない。取引所のマッチングエンジンがミリ秒単位で生成する機械データだ。このデータはインターネットに上がらない(有料で、ライセンス制約があり、リアルタイムストリーミングだ)。GPT-5がいくら大きくなってもこのデータを学習しなければ、このデータの分布を理解できない。金融市場に対するGPTの知識は人が金融について書いたテキスト — ニュース記事、レポート、教科書、ブログ — から来る。これは市場自体ではなく市場に対する人の解釈だ。Kronosは市場自体のデータで学習する。この違いは根本的だ。

TimesFMが扱う時系列データも同じだ。センサーが秒単位で測定する温度、湿度、電力消費量 — これらはテキストではない。インターネットに上がる時系列データは全時系列データの極めて一部に過ぎない。ほとんどの時系列データは工場のSCADAシステム、病院の患者モニタリング装備、電力会社のスマートメーターの中にある。LLMがアクセスできないデータだ。

VoxCPMが扱う音声データはテキストと最も遠いドメインかもしれない。音声は波形だ。人の声に込められた感情、アクセント、リズム、息遣い — これらはテキスト書き起こし(transcription)に還元されない。LLMが音声について知っているのは音声をテキストに変換した後のテキストに対するものだ。音声自体ではない。

データベース歴史でこれに対応するのがデータ型の多様化だ。1980年代にはほとんどの企業データが定型テーブル(行と列)に還元可能だった。2010年代にはJSONドキュメント、グラフ、時系列、全文テキスト、高次元ベクトルなど還元不可能なデータ型が急増した。各データ型には固有の保存方式とアクセスパターンがあり、汎用RDBMSの行-列モデルではこの多様性を効率的に扱えなかった。

FMの世界でデータの多様化は既に進行中だ。テキスト、注文フロー、時系列、音声、タンパク質配列、気象観測、衛星イメージ、ゲノム — それぞれが固有の構造と分布を持ったデータドメインで、これらのドメインのデータはインターネット・テキストコーパスに入っていない。汎用LLMがこれらすべてのドメインを「テキストに変換して」処理することは可能だが、変換過程での情報損失は不可避で、原本データで直接学習したドメインFMに比べて性能が落ちる。

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

汎用transformerの強みは最小限の仮定でほぼすべてのシーケンスデータを処理できることだ。Attention mechanismはシーケンス内のどの位置の要素同士でも直接相互作用できるようにし、この汎用性がtransformerをuniversal approximatorにする。

しかし最小限の仮定は両刃の剣だ。時系列データには「近い時点が遠い時点より重要だ」という強い構造がある。汎用transformerはこの構造をデータから学習しなければならない。TimesFMはこの構造をアーキテクチャに直接内在させる。結果としてTimesFMは同じパラメータ数で汎用transformerより時系列予測をうまく行う。少ないデータでより速く学習し、少ない計算でより正確な予測を出す。

金融データにはregime structureがある。市場は平常時(normal)と危機(crisis)という質的に異なる状態の間を切り替え、各状態でのデータ分布が完全に異なる。2008年金融危機の時の価格変動パターンと平常時のパターンは同じ確率分布から出たものではない。Kronosのアーキテクチャはこのようなregime切替を明示的にモデリングする。汎用LLMにはこのようなメカニズムがない。

音声データには**位相一貫性(phase coherence)**がある。音声波形の物理的特性は時間領域だけでなく周波数領域でも意味を持つ。フォルマント(formant)構造、基本周波数(F0)の変化、ハーモニック構造 — これらはテキストトークンの順序関係とは全く異なる種類の構造だ。VoxCPMがtokenizerを捨てたのはこの構造を直接扱うための設計選択だ。

データベース歴史でこれに対応するのがデータ構造の分化だ。B-treeは範囲クエリに強く、ハッシュインデックスは厳密一致に強く、逆インデックスは全文検索に強く、R-treeは空間クエリに強い。各データ構造は特定アクセスパターンに対する事前仮定を実装したもので、その仮定が当たるワークロードで汎用データ構造(B-tree)を圧倒する。Elasticsearchが全文検索でOracleを打ち負かすのは逆インデックスという専門データ構造の力だ。TimesFMが時系列予測でGPTを打ち負かすのは時系列専用inductive biasの力だ。同じメカニズムだ。

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

第三の力は経済学だ。これは最も即物的で最も説得力のある論拠だ。

汎用LLMは大きい。GPT-4級のモデルは数千億パラメータ以上で、推論に数十個の高価なGPUが必要だ。API呼び出し費用は入力トークンあたり、出力トークンあたり課金され、大量処理時には月数百万ウォンから数千万ウォンの費用が発生する。

ドメイン特化FMは小さい。TimesFMは数億パラメータ規模で、単一GPUで実行可能だ。Kronosも同様だ。VoxCPMはさらに小さいかもしれない。これらのモデルは自身のドメインで汎用LLMよりも正確な結果を出しながら、計算費用は数十分の一に過ぎない。

具体的に計算してみよう。企業が毎日100万件の時系列予測を実行しなければならないと仮定しよう。方法1:GPT-5 APIに時系列データをテキストに変換して送り、予測結果をテキストで受ける。各リクエストに平均500トークンの入力と100トークンの出力が必要なら、入力500Mトークン+出力100Mトークンの日次費用が発生する。トークン単価により異なるが、月数百万ウォンから数千万ウォンかかる。方法2:TimesFMを自社サーバーにデプロイして直接推論する。A100 GPUが1から2枚あれば十分で、月クラウド費用は数十万ウォンレベルだ。

費用差が10倍から100倍だ。そして方法2の精度が方法1より高い。より安く、より正確なら、選択は自明だ。

これはデータベースの世界でNoSQLがRDBMSを置き換えた力学と正確に同じだ。2010年代初め、MongoDBとCassandraが台頭した核心的理由は性能ではなく費用だった。大規模書き込みワークロードをOracleで処理するにはRAC(Real Application Clusters)ライセンスに数億ウォンを払わなければならなかった。Cassandraはオープンソースで、コモディティハードウェアで水平拡張が可能だった。同じワークロードを10分の1の費用で処理できるなら、Oracleの技術的優秀性は経済的合理性の前で力を失う。

FMの世界も同じ力が作動している。汎用LLMのAPI費用がドメイン特化FMの自社運用費用より圧倒的に高く、ドメイン特化FMの性能が汎用LLM以上なら、企業はドメイン特化FMを選ぶ。これは意志の問題ではなく算術の問題だ。

5. Tokenizer-freeの意味 — LLMアーキテクチャ仮定からの脱却の象徴

三つのモデルの中でVoxCPMの「tokenizer-free」選択は別途深く論議する価値がある。この選択は単なる技術的決定ではなく、FM種分化の最も明確な物理的証拠だからだ。

トークナイザーはLLMアーキテクチャの最初のレイヤーだ。すべての入力はトークナイザーを通過してこそモデルに入れる。トークナイザーは連続的なテキストを離散的トークンのシーケンスに変換し、モデルの語彙(vocabulary)を定義する。GPTシリーズのtiktoken、LLaMAのSentencePiece、Claudeの独自トークナイザー — 実装は違うが原理は同じだ。テキストを切り分ける。

この「切り分け」はテキストに対しては自然だ。テキストは本質的に離散的だ。アルファベット、音節、単語という自然な分割単位が存在する。BPEのようなアルゴリズムはこの自然的分割を統計的に最適化したものだ。

しかし音声、イメージ、時系列のような連続的(continuous)データにはこのような自然的分割単位がない。音声波形を20msフレームに切り分けるのは慣例に過ぎず、物理的必然性ではない。イメージを16x16パッチに切り分けるの(ViT)も同様だ。このような人為的分割は便宜のためのもので、データの本質を反映したものではない。

VoxCPMがトークナイザーを捨てたということは、「LLMのデータ処理パイプラインを音声ドメインに強制適用するのが不適切だ」という宣言だ。音声はテキストではなく、テキストのために設計された前処理パイプラインは音声に合わない。これは単なる技術的判断ではなく、ドメインの固有性を認めることだ。

生物学的種分化で、二つの集団が同じ種か別の種かを判断する核心基準は交配可能性(reproductive compatibility)だ。トークナイザーがあるモデルとトークナイザーがないモデルはデータパイプラインレベルで互換不能だ。同じ入力を受けられず、同じ出力形式を生成せず、同じ評価フレームワークで比較できない。この非互換性は二つのモデルが互いに異なる「種」であることを意味する。

この観点でVoxCPMのtokenizer-free設計は、Kronosの金融特化やTimesFMの時系列特化よりも急進的な種分化事例だ。KronosとTimesFMは依然としてtransformerアーキテクチャの変形を使い、何らかの形のトークン化(discretization)を行う。入力データを離散的単位に変換する最初の段階が存在する点でLLMとまだ共通祖先の痕跡を共有する。VoxCPMはその最後の共通点さえも捨てた。これがVoxCPMを三つのモデルの中で最も極端な種分化事例にする。

データベース歴史でこれに対応するのがNeo4jの登場だ。カラムストア(Vertica)やドキュメントストア(MongoDB)は依然としてテーブルという概念を変形した形で維持した。Neo4jはテーブルという概念自体を捨て、ノードとエッジという全く異なる抽象化を導入した。SQLではなくCypherという新しいクエリ言語を作った。RDBMSとの互換性を放棄する代わりに、グラフデータについてRDBMSが到達できない性能と表現力を獲得した。VoxCPMがトークナイザーを捨てたのはNeo4jがテーブルを捨てたのと同じ種類の決定だ。

6. 西側と中国が同じ方向を向く — 同時性の意味

三つのモデルの出所を見ると興味深い地理的分布が現れる。TimesFMはGoogle Research(米国)、Kronosは中国の大学研究チーム、VoxCPMはOpenBMB/Tsinghua University(中国)だ。互いに異なる大陸の互いに異なる組織が、同じ週に、同じ方向(ドメイン特化FM)に向かって動いている。

この同時性に二つの可能な解釈がある。楽観的解釈は「偶然の一致」だ。各自が自分のドメインの問題を解いていたら似た時期に結果が出ただけで、構造的趨勢と見る根拠はない。悲観的解釈は — 本エッセイが主張するところだが — 「同じ構造的圧力に対する独立した応答」だ。データモート、inductive biasの優位、経済的合理性という三つの力が全世界的に同時に作用しているため、互いに連絡していない研究グループが同じ結論に到達したのだ。

後者の方が説得力があると見る理由は、こうしたパターンが技術史で反復的に観察されるからだ。電話機をAlexander Graham BellとElisha Grayが同じ日に特許出願したこと、微積分学をNewtonとLeibnizが独立に発見したこと — 「時代が熟せば同じ発見が同時に出てくる」というのは科学史の定数だ。FMのドメイン特化も同じだ。時代が熟した。

「オープンモデル戦争2026」で分析したように、Google、AMD、Alibabaが同じ週にオープンモデルを同時にリリースしたのは「戦争」のシグナルだった。今回Google Research、中国の大学、OpenBMBが同じ週にドメインFMを同時にトレンドに上げたのは「種分化」のシグナルだ。二つのシグナルは同じ生態系の互いに異なる断層線から出ている。

ここに補助データとしてNVIDIA/personaplexを加えられる。同じ週に8,745スター、週次+2,745を記録したこのプロジェクトはAIペルソナ/パーソナライズに特化したモデルだ。NVIDIAという巨大企業が汎用AIではなく「パーソナライズ」という特定verticalに集中するプロジェクトを出したのも、同じ種分化趨勢の別の表現だ。

同時性の地理的分布も意味深長だ。米中技術競争が激化する環境で、両陣営が同時に同じ方向(ドメインFM)を向いている。これは米中いずれかの特殊な戦略ではなく、技術的必然性に近い趨勢であることを示唆する。米国が汎用LLMだけ推進し中国がドメインFMだけ推進したなら、これは戦略的差として解釈できる。両陣営が同時に同じ方向を向いているなら、これは技術発展の内在的方向性だ。

7. 経済学:1B専門モデルが1T汎用モデルに勝つ地点

種分化の経済学をさらに具体的に掘り下げる必要がある。「ドメインFMの方が安い」という直感的主張を超え、正確にどんな条件で専門モデルが汎用モデルに経済的に勝つのかを分析しなければならない。

モデルサイズと性能の非線形関係

汎用LLMのスケーリング法則はおおよそこうだ。モデルサイズを10倍増やすと性能が一定比率向上する。これはすべてのドメインにわたる「平均的」性能向上だ。だが特定ドメインでの性能向上はこの平均と異なりうる。インターネットテキストによく表現されたドメイン(一般知識、コーディング、ドキュメント作成)ではスケーリングの利得が大きい。インターネットテキストによく表現されていないドメイン(金融マイクロストラクチャ、センサー時系列、音声合成)ではスケーリングの利得が小さい。

これは収穫逓減(diminishing returns)がドメインごとに異なる速度で起きるという意味だ。汎用LLMが1兆パラメータまで大きくなっても金融注文フロー予測での性能向上が微々たるものなら、100億パラメータのKronosがそのドメインでより良い性能を見せるのは全く驚くべきことではない。

推論費用の構造的差異

推論費用はパラメータ数におよそ比例する。1Tパラメータモデルの推論費用は1Bパラメータモデルの約1,000倍だ。GPUメモリ要求量、計算量、電力消費 — すべてパラメータ数に比例して増加する。

具体的に比較してみよう。

汎用LLM経路:GPT-5級モデルのAPI費用を仮定する。入力トークン $10/1Mトークン、出力トークン$ 30/1Mトークンとしよう(2026年基準推定)。時系列予測のためにデータをテキストにエンコードすれば、1日100万件の予測について入力5億トークン、出力1億トークンが必要と仮定する。日次費用 = $5,000(入力)+$ 3,000(出力)= $8,000。月費用は約$ 240,000(約3億2千万ウォン)。

ドメインFM経路:TimesFMを自社サーバーにデプロイする。A100 GPU 2枚あれば十分と仮定する。クラウド基準でA100 1枚の月費用は約 $3,000。2枚なら月$ 6,000(約800万ウォン)。ここにエンジニアリング費用を加えても月$10,000(約1,300万ウォン)を超えない。

費用差:約24倍。そしてドメインFMの予測精度が汎用LLMより高い。

これが「1Bが1Tに勝つ地点」だ。ドメイン特化FMが汎用LLMより性能が同等以上でありながら費用が数十倍低い領域。この領域は現在、金融、時系列、音声で既に存在し、これからより多くのドメインに拡張されるだろう。

ドメインFMのTCO分析

もちろんドメインFMには汎用LLM APIにない費用がある。モデルのデプロイと運用のエンジニアリング負担、モデルアップデートとファインチューニングの持続的費用、障害対応とモニタリング基盤構築費用だ。汎用LLM APIはこれらすべてを提供者が負担する。

だがこの追加費用を勘案しても、大量処理ワークロードではドメインFMの総所有費用(TCO)が汎用LLM APIより低い。データベースの世界でOracleからPostgreSQL+ElasticSearchの組合せへの転換が起きたのと同じ力学だ。Oracleは「一つのライセンスですべて」という便利さを提供したが、ワークロードが一定規模を超えると専門DBの組合せのTCOがOracle単独より低くなった。そのティッピングポイントを越えた企業が一つ二つOracleを離れ始め、これが2010年代の「NoSQL movement」につながった。

FMの世界でも同じティッピングポイントが近づいている。一定規模以上のドメイン特化ワークロードを持った企業が、汎用LLM APIからドメインFM自社運用へ転換し始めるだろう。Kronos、TimesFM、VoxCPMのGitHubスター数はこの転換の先行指標だ。

8. Polyglot FM — 「Foundation Model」が「Verticalized FM」を意味するようになる時点

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

FMの世界でも同じ軌跡が予測できる。GPT-5、Claude、Geminiのような汎用LLMは死なない。テキストベースの汎用作業で依然として最高の選択肢になるだろう。だが「すべてのAI問題をGPTで解く」時代は終わりつつある。2-3年内に、「foundation model」という単語は基本的にverticalized FMを意味し、汎用LLMはその中の一つのvertical(テキスト/一般知識)を担当するFMという認識が定着するだろう。

これを「Polyglot FM」時代と呼べる。企業のAIスタックが次のような形になる時代。

テキスト生成/一般推論:Claude、GPT、Gemini(汎用LLM)
時系列予測:TimesFMまたは後続のドメインFM
金融分析:Kronosまたは後続の金融FM
音声合成/処理:VoxCPMまたは後続の音声FM
イメージ/ビジョン:ドメイン特化ビジョンFM
コード生成:コード特化FM(既にCodexから始まった流れ)
検索/埋め込み:検索特化埋め込みモデル

各ドメインに最適なFMを選び、オーケストレーション・レイヤーがこれらを組み合わせる構造だ。

この構造で価値が移動する方向は明確だ。個別FMの価値はコモディティ化され、オーケストレーション・レイヤー — どのFMをどのタスクにどうルーティングするか — の価値が浮上する。データベースの世界で個別DBの価値がコモディティ化され、データパイプラインとETLツール(Airflow、dbt、Fivetran)の価値が浮上したのと同じ力学だ。

「オープンモデル戦争2026」で分析した「シナリオ2:分散 — 誰も勝てない」とこの展望は直接つながる。あのエッセイで「オープンモデルがコモディティ化されながらどの一社もモデルレイヤーを支配できない」シナリオを最も可能性が高いと評価した。Polyglot FMはそのシナリオの拡張版だ。汎用モデル間のコモディティ化だけでなく、ドメインFMまで含めたFM生態系全体の多様化が起きるのだ。

オーケストレーションの浮上

Polyglot FM時代の核心技術階層はFMオーケストレーションだ。ユーザーのリクエストを分析し、適切なドメインFMにルーティングし、複数のFMの結果を組み合わせて最終応答を生成するレイヤーだ。

興味深いのは、このオーケストレーション・レイヤー自体が汎用LLMの役割になる可能性があるという点だ。汎用LLMは自然言語理解に強い。ユーザーの意図を把握し、適切な専門モデルにリクエストを分配することは自然言語理解の問題だ。「明日のソウルの最高気温は何度か?」という質問が入ってくれば、汎用LLMがこれを時系列予測問題に分類してTimesFMに委任するといった具合だ。

こうなれば汎用LLMの役割は「すべてに直接答えるモデル」から「適切な専門家を見つけ出すルーター」へと変わる。Oracleが「すべてのデータを直接管理するシステム」から徐々に「他の専門システムと連結されるハブ」へと進化したのと似た軌跡だ。Oracle Data Integrator、Oracle GoldenGate — Oracleが他のDBとの連結性を中核製品として出し始めたのは、自社の汎用DBがすべてのワークロードを直接処理しないという現実を認めたことだった。

9. 種分化は失敗ではない — 技術成熟の表れ

ここで重要な区分が一つ必要だ。FMの種分化は汎用LLMの失敗ではない。これは技術成熟(maturation)の表れだ。

生物学で種分化は環境への適応(adaptation)の結果だ。共通祖先が失敗して種分化が起きるのではなく、互いに異なる環境で各々よりよく適応した変異が選択されながら種分化が起きる。ダーウィンのフィンチはガラパゴス諸島の各島で互いに異なる餌に適応しながらくちばしの形が変わった。元のフィンチが「失敗」したのではない。環境の多様性に合わせて最適化が起きたのだ。

データベースの種分化も同じだ。NoSQLの台頭はRDBMSの失敗ではなかった。データの種類が多様化し、ワークロードの規模が大きくなり、経済的圧力が増加しながら、汎用システムより専門システムが有利な領域が生まれたのだ。これは技術生態系の健全な分化(healthy differentiation)だ。

FMの種分化も同じ文脈で理解しなければならない。GPT-5が時系列予測ができなくてTimesFMが登場したのではない。時系列予測というワークロードが十分に重要で、十分に固有の特性を持っているため、専用FMが汎用LLMよりも良い解法を提供できるようになったのだ。これはFMという技術パラダイムが成熟したという証拠だ。初期には一つの形で始まるが、成熟しながら環境に合わせて分化する。

この点で「GPTの代替はGPTではないかもしれない」という本エッセイの副題が意味を持つ。GPTの代替は「より良いGPT」(より大きな汎用LLM)であるかもしれないが、ますます多くのドメインでGPTの代替は「GPTではないもの」(ドメイン特化FM)になっている。金融ではKronosが、時系列ではTimesFMが、音声ではVoxCPMがGPTの代替だ。これらの代替はGPTより小さく、GPTより狭く、GPTより安い。だが各々のドメインでGPTより優れている。

10. 実務者への示唆 — 選択肢の多角化

この分析が実務者に与える示唆は何か。

示唆1:「すべてをGPT/Claudeで」戦略の再検討

現在多くの企業がAI導入を「汎用LLM API導入」と同一視している。すべてのAIワークロードをGPT-5やClaude APIで処理する戦略だ。この戦略は単純で素早く始められるという長所がある。だがワークロードが特定ドメインに集中しているなら — 例えば時系列予測が中核ワークロードの製造業者、金融データ分析が中核の投資会社、音声処理が中核のコンタクトセンター — 汎用LLM APIが最適の選択ではないかもしれない。

ドメイン特化FMが存在するか、それが汎用LLMより良い性能を見せるか、総所有費用がより低いかを検討するのが最初のステップだ。この検討なしに慣性的に汎用LLM APIを選ぶのは、2015年に「すべてのデータをOracleに入れよう」と決めるのと同じ種類のミスかもしれない。

示唆2:Polyglot FM力量の確保

Polyglot persistenceがDBAに「複数のデータベースを扱えなければならない」という要求を作ったように、Polyglot FMはAIエンジニアに「複数のFMを扱えなければならない」という要求を作るだろう。汎用LLMのプロンプトエンジニアリングだけ知っていても足りなくなる。TimesFMの入力形式、Kronosのデータパイプライン、VoxCPMの音声処理API — それぞれについての理解が必要だ。

これは脅威ではなく機会でもある。汎用LLMは誰もがアクセスでき、誰もが同じAPIを使う。差別化が難しい。ドメイン特化FMはドメイン専門性が必要で、モデル運用力量が必要だ。この力量を確保した企業は汎用LLM APIだけ使う競合に対して構造的優位を持つ。

示唆3:オーケストレーション・レイヤーへの投資

複数のFMを組み合わせるオーケストレーション・レイヤーは今後AIスタックの中核階層になるだろう。LangChain、LlamaIndexのようなツールが既にこの方向に向かっているが、まだ汎用LLM中心の設計だ。ドメインFMを含めた真のpolyglotオーケストレーションはまだ初期段階にある。この領域に早く投資するのが長期的に有利だ。

示唆4:データ戦略の再定義

汎用LLMを使う企業のデータ戦略は「プロンプトをうまく作り、RAGをうまく構成すること」が核心だ。ドメインFMを使う企業のデータ戦略は違う。自社ドメインの固有データを収集し、整え、ドメインFMのファインチューニングや追加学習に活用することが核心になる。データが汎用LLMとの差別化の源泉になる。

これは「オープンモデル戦争2026」で「モデルは餌であり、本当の価値は生態系にある」と分析したことの延長線だ。Polyglot FM時代には「モデルはコモディティであり、本当の価値はドメインデータとオーケストレーション力量にある」へと拡張される。

11. 展望 — 種分化の次の段階

2026年4月のKronos、TimesFM、VoxCPMはFM種分化の最初の可視的な波だ。次に来るのは何か。

短期(2026-2027):より多くのドメインFMの登場

現在ドメインFMが登場した領域は金融、時系列、音声だ。だが「インターネットテキストによく表現されていないデータドメイン」はこれ以外にも無数にある。医療画像、衛星/リモートセンシング画像、ゲノム(genomics)、分子構造、気象観測、産業IoTセンサー、ロボット制御信号 — 各ドメインでfoundation modelを自任するモデルが登場するだろう。

この波の加速要因はオープンソースだ。Kronos、TimesFM、VoxCPMがすべてGitHubでオープンソースとして公開されたのは偶然ではない。オープンソースは「このアプローチが有効だ」という証拠をコミュニティに提供し、後続研究者が同じ方法論を別のドメインに適用するよう促進する。一つのドメインの成功が別のドメインの試みを生み、その試みがまた別のドメインに拡散される自己強化ループが形成されるだろう。

中期(2027-2028):ドメインFM生態系の成熟

より多くのドメインFMが登場すれば、それらを管理し組み合わせるインフラの需要も急増する。FMレジストリ(どのドメインFMがどこにデプロイされているか)、FMルーター(入ってきたリクエストをどのFMに送るか)、FMモニタリング(各FMの性能が期待水準を維持しているか) — このようなインフラ階層が一つの市場を形成するだろう。

データベースの世界でpolyglot persistenceが定着しながらdbt、Airbyte、Fivetranのようなデータパイプラインツールが浮上したのと同じ軌跡だ。FMのpolyglot時代はFMパイプラインツールの時代を開くだろう。

長期(2028-2029):「Foundation Model」の意味の変遷完成

この時点で「foundation model」という単語は基本的に「特定ドメインの基礎モデル」を意味するようになるだろう。誰かが「foundation model」と言えば、最初の質問は「どのドメインの?」になる。「汎用FM」は「汎用」という修飾語を明示的に付けなければならない特殊事例になる。あたかも「データベース」と言えば「どんな種類の?」と聞くのが自然で、「汎用RDBMS」は明示的に指定しなければならないように。

これは2021年Stanford CRFMの本来の定義 — 「多様な下位タスクに適応可能な事前学習モデル」 — への回帰だが、その意味の重心は変わっている。2021年にこの定義はGPT-3のようなモデルを説明するためのものだった。2028年にこの定義はTimesFM、Kronos、VoxCPMのようなモデルを説明するためのものになるだろう。同じ単語、異なる指示対象。言語は変わらなかったが世界が変わったのだ。

12. 結論

2026年4月10日のGitHub Trendingは一つの質問を投げかけている。「Foundation modelは一つの巨大な汎用モデルでなければならないのか、それともドメインごとにそれぞれの基礎モデルがなければならないのか?」

本エッセイの答えは後者だ。そしてその答えの根拠は30年前にデータベースが既に提供した。1980年代のOracleが「すべてのデータを一つのRDBMSで」というビジョンを持っていたが、データの種類が多様化しワークロードが分化しながら、グラフDB、時系列DB、検索エンジン、ドキュメントDB、ベクトルDBが各々自分の領域で汎用RDBMSに勝った。Oracleは死ななかったが、Oracleだけの世界は終わった。

同じことがFMに起きている。Kronosは金融市場の言語を直接読む — GPTが金融について書いたテキストを読むのとは次元の異なる理解だ。TimesFMは時系列の構造的特性をアーキテクチャに内在させる — 汎用transformerがデータからその構造を学習するのを待つより効率的だ。VoxCPMはトークナイザーを捨てた — 音声というドメインの本質がテキストと根本的に異なることを認めたのだ。

この三つのモデルが同じ週に同時にトレンドに上がったというのは偶然ではない。同じ構造的力 — データモート、inductive biasの優位、計算経済学 — が互いに異なる大陸の互いに異なる研究グループを同じ方向に導いたのだ。これは個別の出来事ではなく趨勢だ。FMの種分化が始まった。

GPT-5の代替がGPT-6だろうという仮定はあまりに狭い。金融分析でGPT-5の代替はKronosかもしれず、時系列予測でGPT-5の代替はTimesFMかもしれず、音声合成でGPT-5の代替はVoxCPMかもしれない。GPTの代替はGPTではないかもしれない。

実務者へのメッセージは一つだ。選択肢を多角化せよ。「我が社のAI = GPT API」という等式を再検討せよ。自社の中核ワークロードが何かを識別し、そのワークロードに最適化されたドメインFMが存在するか確認せよ。存在するなら、汎用LLMとの費用-性能比較をしてみよ。存在しないなら、2年内に登場する可能性を開いておいてアーキテクチャを設計せよ。

データベースの歴史が教えてくれるのは、汎用システムから専門システムへの転換は一晩では起きないということだ。10年かかった。だがその転換が始まる時点を認知した企業と認知しなかった企業の差は、10年後にとても大きい。2026年4月10日のGitHub Trendingはその始まりを告げるシグナルの一つだ。

出典: