Y Combinator 解説：AI競争の中心はデータ──Snorkel・Inception Labs・多言語事前学習
2026年8月20日
概要
世界最高峰のスタートアップアクセラレーターであるY Combinatorの公式チャンネルが開催したデータイベントの回では、AI開発においてアーキテクチャやGPU以上にデータがボトルネックになっているという共通認識のもと、3つの研究・企業事例が紹介されました。Snorkel創業メンバーのVincent Chen氏は専門家の監督をどうスケールするか、Inception Labs共同創業者のVolodymyr氏は拡散型言語モデルとRL環境の合成、MIT出身でAnthropicに加わったShane氏は多言語事前学習における言語間の転移と干渉について論じています。
司会のFrancois氏は、過去10年でデータ関連の企業群が約1,000億ドル（約15.9兆円。1ドル=158.55円換算）の時価総額を生み出し、いまやデータこそが最大の制約だと指摘しました。データセットは単なるファイルではなく、専門家の判断や実運用に近い環境を組み込んだ「製品」として設計する必要があるという点が、この回全体の基調になっています。
データが最大のボトルネックになっている理由
Francois氏はまず、2016年当時はデータがコモディティと見なされ、ImageNetをすでに取得済みという認識から「データ企業の終局的価値はゼロ」と語る投資家が多かったと振り返りました。しかし実際には、その後データ関連領域で約1,000億ドル（約15.9兆円。1ドル=158.55円換算）規模の時価総額が生まれています。
同氏は面接で「hot dog/not hot dog」のF1スコアが85%に達したモデルがあるとき次に何をするかと問い、モデルを重ねたり活性化関数を比較したりするのではなく、まず誤検出と見逃しをすべて洗い出し、最大の原因をデータから見つけることが正解だと述べました。学習データの分布と実運用データの分布がずれれば、どんなに表現力の高いモデルでも途端に動かなくなります。
経済活動を自動化するには、検証可能な報酬を持つエキスパート向けRL環境と、医師や裁判官のように専門家の間でも答えが割れる領域の選好データが必要です。データセットを単なるzipファイルと考えるのは誤りで、同じSalesforce業務の大量データを持っていてもUIが変われば取り直しが要ります。S&P500種指数の今後7日間のリターン予測では、現状どのAIモデルもランダムより良い結果を出せず、Goldman Sachsのトレーダーのような専門家の軌跡データがあれば変わると指摘しました。
同氏はデータ企業の数をスマートフォンのアプリ数に重ねました。懐中電灯のような簡単な機能はAppleとAndroidが自前で持つのが合理的です。一方、AppleがInstacartのネットワーク全体を立ち上げて食料品配達で競争するのは、Appleが得意でないため理にかなわないと述べました。AI医師のようにHIPAA（米国の医療情報保護法）対応まで含めて深く特化する領域では、Anthropic、OpenAI、Google、Appleのすべてが自前で作るより、医師ネットワークと選好データを持つ一つの企業へ任せる方が自然です。その企業は、特定の患者に対してある軌道と別の軌道を示し、医師がどちらかを選ぶ形の選好データを提供します。
Snorkel：専門家の監督をデータ化する
Snorkel創業チームで現在はベンチマークと評価研究を率いるVincent Chen氏は、同社のスタンフォードAIラボ時代から約10年にわたる取り組みを紹介しました。Snorkelの中心的テーマは、医師や臨床家、ジャーナリストのように「良い状態」の仕様を頭の中に持つ人々の判断を、いかにデータセットへ変換するかです。Snorkelは事実上すべてのグローバルな研究機関、およびFortune 10企業とデータ問題で提携しており、各案件は専門知識のスケールという同じボトルネックに軸足を置いています。
データ1.0は人手によるラベリングで、Q&Aの正誤やプロンプトと応答ペアのような30秒程度の判断で済むものが中心でした。しかし人手ラベリングは1件ごとに認知コストがかかり、ノイズを減らすには冗長な再ラベリングが必要で、仕様が変わるとゼロからやり直しになり、判断理由の来歴も残りません。ここでいう来歴とは「自分の根拠は何か」「この問題をどう考えたか」という情報です。心臓専門医などの狭い専門領域では、大規模データを用意すること自体が現実的ではないと指摘しました。現在のデータは、タスク・ルーブリック・検証器・細かい採点機構をDocker環境にパッケージした「世界」を構築する方向へ進んでいます。そのような環境は、エージェントが実際に動作する空間の種類を表す必要があり、人間が一から作ると1桁時間から3桁時間かかります。
そこでSnorkelは、専門家の監督をソフトウェアとして符号化するデータプログラミングを提唱しました。このデータプログラミングは、CEOのAlexが大学院生だったときに始まった取り組みです。大学院研究の中核は、専門知識をラベリング関数としてモデル化することにあり、知識を人間の頭から再現可能でスケーラブルな形式へ移すことを狙います。正しく行えばソフトウェアのスケールが得られ、データをプログラム的にラベル付けできます。また、ソフトウェアの適応性が得られ、仕様変更に応じてリファクタリングや調整が可能です。プログラム化されたラベル付けは監査・会話・共同作業の対象にもできます。
品質の異なる弱い信号を統合するラベルモデルの目標は、各投票者の正確度を完全に教師なしでモデル化することです。正解ラベルがないままノイズモデルを学習し、各信号源の品質を理解します。ステップ1は投票者の正確度の学習、ステップ2はベイズに基づき、各投票者の実際の投票を条件とした正解確率を計算することです。これは採点基準がない状態で、能力の異なる生徒たちの投票だけから真の答えを推測するような問題です。さらにノイズを織り込んだエンドモデルを訓練することで、当初のラベリング関数のカバレッジを超えて汎化させます。初期の研究は、ラベルと専門家判断をソフトウェアとして導入して専門知識をスケールすることがテーマで、重要なボトルネックは正解ラベルが欠けた状況での信号源のノイズ除去でした。それらの技術の一部は現在も本番環境で使われています。
データ2.0では、データとフロンティア進歩の表面積が拡大し、複雑性と重要性が増しています。コーディングを例にすると、横軸は入力複雑性・出力複雑性・環境複雑性です。環境複雑性には、単なるQ&A環境か、デスクトップへのYOLOアクセスを渡すかが含まれます。縦軸はエージェントが実際に作業するシーケンス長です。ソフトウェアやコーディングの評価が飽和しているように見えても、フロンティアの進歩とともにデータ課題は増え続けます。HumanEvalのような基本評価は飽和していますが、端末ベースのエージェントはスペクトルが成長し続け、Program Benchは最新モデルがようやく1%を超えた段階です。
同氏は、エージェントの複雑性と責任が増すほど、それらを訓練・評価するために作るデータの重要性も増すと述べました。Senior SWE Benchの報酬設計で捉えたかったのは、正しさやマージ可能性だけでなく、コードにセンスがあるか、スタッフ級・シニア級・プリンシパル級のエンジニアが完全に教師なしで行うと信頼できる行動かを測ることでした。Snorkelにはエンジニアと研究者、非常にシニアなプリンシパル・スタッフ級エンジニアのネットワークがありますが、時間は無限ではありません。
同社はPrincetonのSWE-benchチームとSenior SWE Benchを構築しました。現代の開発現場では、コーディングエージェントをシニアエンジニアのように使い、バイブコーディングでアーキテクチャ判断やコード全体のリファクタリングを任せています。一方で評価はジュニアエンジニア向けのままだったため、シニアエンジニアの実際の仕事を代表するベンチマークとデータセットを構築し、専門知識をスケールし、高品質なベンチマークを作ることが課題でした。タスク設計には専門家の監督や専門家のタッチポイントが多数必要でした。指示は自然言語で与えられ、Slackメッセージやログの断片、ユーザーストーリーのような現実的な抽象度になっています。従来のSWE-benchやコーディングベンチマークのサンプルは過剰に仕様化され、実装手順に近い詳細な指示になっているため、指示への専門知識とリアリズムの注入は非常に重要な作業だったと述べました。同氏はHarborを評価フレームワークとして高く評価しています。
Senior SWE Benchの報酬フェーズは、設計とキャリブレーションに多くの時間をかけた領域です。同氏は報酬設計について、単体テストの検証器は信頼性が高いが柔軟性が低く、LLMジャッジは柔軟だが誤った正解に報酬を与える可能性があるため、その中間としてvalidation agentを設計したと説明しました。専門家がユーザーストーリーと必要最小限の機能要件からなる検証仕様を書き、validation agentが実際のコードパスを実行するテストスクリプトを生成します。新しい指標tasteful passでは正しさだけでなくコードベースの慣習への適合やパッチの無駄のなさも測り、Fable、Opus、Soulが同率首位になったと紹介しました。
実践ではCodexとClaude Codeが指示セットに対してパッチを生成します。採点にはテスト実行とジャッジの両方を使い、ジャッジは実行の健全性や共謀、報酬ハッキング、無効な挙動を確認します。キャリブレーションとして、内部およびネットワークのテストエンジニアと整合させ、LLMジャッジで忠実度・完全性・共謀を測りました。各テストはパラメータ化されており、検証仕様はユースケースやエッジケースの型を捉えるランブルのようなものです。完全な仕様とテストを書こうとすると数日から数週間、数ヶ月かかるため、この形で専門家の時間を節約しています。
このベンチマークは現在ライブで公開されており、同率首位の結果はパレートフロンティアが押し上げられていることを示しています。同氏はこれを更新し続けるライブダッシュボードであり、生きたベンチマークだと述べました。
チームでは共同創業者のHenryがリードを務めました。オリジナルのSWE-benchを主導したPrincetonのCararthikのグループと協力し、チーフサイエンティストのFredはウィスコンシン大学マディソン校に研究室を持ち、その学生も関わっています。
データ2.0に入り、複雑性が増すため、人間をタスクに投げ込むだけでは不十分で、より多くのデータ研究が必要です。複雑性が増す軸として、環境がより複雑かつ動的になること、出力が検証不能でニュアンスに富み主観的になること、エージェントの自律性が拡大することがあります。各軸が複利的に複雑性を増すため、専門家の判断をスケールする方法は研究課題です。
同氏は具体的な依頼として、より多くのベンチマークが必要だと述べました。ベンチマーク整備は新しいデータ研究を駆動する高レバレッジな手段です。SnorkelはBerkeleyのagents/exam、Continual Learning Bench、O-World、Terminal Benchの関係者と協力して多くを学んできました。
同社は実際に資金を投じる方針を示し、コミュニティ向けの研究リソースとなることを目指すopen benchmarks grantsの枠組みを設けています。研究チームとパートナーシップを組み、データ開発を加速したいと述べ、データ2.0に向けたベンチマークとデータの未来への期待を示しました。
Inception Labs：拡散モデルと音声向けRL環境生成
続いてInception Labs共同創業者のVolodymyr氏が、拡散型言語モデルについて説明しました。従来の自己回帰LLMが左から右へ1トークンずつ生成するのに対し、拡散型はノイズを含む初期列から並列に全トークンを生成し、複数ステップの修正で洗練させます。これによりMercury 2は毎秒1,000トークンを超える速度を出せ、リアルタイム音声エージェントに応用されています。
同氏はInceptionで実世界向けの大規模な拡散言語モデルを訓練しており、共同創業者のStefanoとAditya、エンジニア・研究者チームが開発に携わっています。この拡散技術は言語モデルの未来になると位置づけ、超高速推論はリアルタイムAI全般に応用できると述べました。音声エージェントの用途としては、顧客サポートと教育を挙げています。
音声AIでは通常、音声認識・LLM・音声合成が連結され、遅延の中心がLLMです。生成速度が上がれば体験が自然になるか、より大きなモデルを使い推論量を増やして品質を上げられます。Cerebras上で動く1,200億パラメータの自己回帰モデルと比べ、Mercury 2は同等以上の品質と速度を実現し、専用チップでなくGPUでもソフトウェアによって速度を稼げると述べました。
同社のスライドでは、x軸にレイテンシ、y軸に品質が取られています。比較対象のGPT-OSSモデルは、Cerebrasの専用チップ上で動く1,200億パラメータの自己回帰モデルです。Mercury 2はTau-benchで測った品質でこれを上回り、実データでも高品質で、さらに高速だとしました。
現在、リアルタイム音声エージェントの評価で最も広く使われている代表的なベンチマークはTau-benchです。ただし高速化だけで高品質な音声モデルは作れず、学習と評価のデータがもう一つの柱です。既存のTau-benchは実運用より仕様の数が一桁少なく、提供ツールも限られ、さらにベンチマーク最適化が進み過ぎて多くのモデルが90点台を出す一方、実運用ログでは大きく下がります。
そこでInception LabsはTau Forgeというエージェント型システムで、銀行窓口のような業務ドメインと実際の利用履歴を入力にし、ポリシー、ユーザー、口座、ツール、模擬ユーザーのタスクを合成します。実データがない場合もウェブからクロールしたビジネス知識グラフを使います。タスクは易しすぎても難しすぎても学習信号が弱いため、モデルの正答率を見て情報を抜いたり要求を複雑化するhardening trapで難易度を調整します。
ドメイン特化データなしのMercury 2.5は約50%だった精度が、Tau Forge由来の初期タスクで訓練すると別環境で23ポイント以上向上し、最先端のオープン・クローズドモデルに匹敵しました。訓練ビジネスとテストビジネスを分けることで過学習を抑えています。Y Combinator参加スタートアップ向けには50万ドル（約7930万円。1ドル=158.55円換算）分のクレジットを提供しています。
また今回は音声を中心に話しましたが、同社には検索やコードなど他の領域にも顧客がいます。これらはいずれもレイテンシに敏感なタスクでMercury 2の強みが活きる領域です。実際にこれらのモデルを使っている企業もあり、同氏はその導入状況についてフィードバックを得ていると述べました。
多言語事前学習：言語間の転移と干渉
最後に登壇したShane氏は、MITでの博士研究とGoogleインターン時の成果として、多言語事前学習における言語間の相乗効果と干渉を発表しました。着目したのは英語以外の言語で学習データが極端に少ないことです。たとえばMadlad 400ではタイ語のトークン数は英語の0.6%程度しかありません。
タイ語だけで訓練するとデータを繰り返すことになり過学習するため、モデルを小さくせざるを得ません。理想はタイ語を多く使いつつ、タイ語と相性の良い英語・インドネシア語・マレー語・ラオ語・クロアチア語などを混ぜる構成ですが、これは言語系統だけでは決まらず、実際に測る必要があります。
同氏は、タイ語単独の学習曲線と各言語を50:50で混ぜた曲線の差から言語間の転移効率を測り、大規模な転移行列を作りました。スペイン語にはポルトガル語・イタリア語・フランス語が強く、日本語は害になったという結果も示しています。転移は対称ではなく、ある方向で役立つ言語が逆方向でも役立つとは限りません。文字体系と言語族のどちらが重要かでは、どちらも効くが文字体系の方がやや強く、トークン化の影響ではないかと説明しました。
モデルが大きくなると干渉だった言語対が相乗効果に変わる一方、小さなモデルでは競合が増えることも分かりました。同氏はChinchillaのスケーリング則を多言語用に拡張し、単一言語ソース、近接言語、それ以外のバケットに分けて損失を予測する方法を提案しました。大規模な事前学習済みモデルをファインチューニングすべきか、対象言語で一から事前学習すべきかも、利用可能な計算量に応じて判断できます。また対応言語数を4言語から8言語に増やす際、精度を保つためにどれだけデータとモデルサイズを増やす必要があるかという多言語化の呪いも定式化し、実際の言語でよく当てはまると述べました。
▶ 同じシリーズの前回: Michael Kratsios: Inside the White House's AI Strategy https://note.com/yondo/n/nea843d81bc42
▶ このテーマの記事をまとめ読み: マガジン「スタートアップと経営者の話」 https://note.com/yondo/m/mff5d4ed16e57
#スタートアップ #AI開発 #YCombinator #YCPaperClub #YCDataClub #Snorkel #InceptionLabs #Anthropic #OpenAI #Google #GOOGL #Cerebras #Salesforce #CRM #Apple #AAPL #GoldmanSachs #GS #Instacart #AI #生成AI #データセット #弱教師あり学習 #データプログラミング #ラベルモデル #データ来歴 #SeniorSWEBench #ProgramBench #HumanEval #拡散モデル #音声AI #多言語モデル #大規模言語モデル #機械学習 #ベンチマーク #データ2 .0 #validationagent #Tau -bench #GPT -OSS #Mercury2 #OpenBenchmarksGrants
