Richard SocherがYou.comを検索エンジンからAIのWebデータ層へ変えた転換

Richard Socherは「Math and languages don't intersect often, right?」と語り、数学と言語をコンピュータで交差させる道を選んだ。出典

研究を現実へ持ち出す

SocherはStanfordで自然言語処理を研究し、MetaMindを創業した。

2016年にSalesforceがMetaMindを買収し、彼はChief Scientistとして研究を実際のプロダクトへ近づけた。出典

検索は死んだ、という前提から始める

2018年、SocherとBryan McCannはNatural Language Decathlonを発表した。

複数の言語タスクを一つのモデルで扱う考え方は、後のprompt engineeringにもつながった。出典

二人がYou.comを始めたのは2020年だ。

当時の業界には「search is dead」という見方もあったが、二人は検索を単なるリンク一覧ではなく、言語モデルを情報へ接続する層として作り直そうとした。出典

消費者向け検索からenterprise infrastructureへ

転機はenterpriseへのpivotだった。

Socherは「the biggest thing for us was the pivot into enterprise」と説明し、LLMのhallucinationを減らすには良いsearch infrastructureが要ると語っている。出典

そこでYou.comは、Search APIだけでなくContents、Answer、Researchを揃えた。

検索、ページ抽出、引用付き合成を別々の部品として提供し、AI agentを作る企業の実装負担を減らした。出典

APIを情報の実行基盤へ広げる

2026年にはAnswer APIが加わり、検索結果と検証済みcitationを一つの応答で返す構成になった。

さらにKnowledge parameterは株価、暗号資産、天候など、Webページになっていないlive dataへ検索の境界を広げた。出典

You.comの道のりは、検索エンジンを作った物語というより、AIが信頼できる情報へ到達するまでの欠けた工程を一つずつAPIにした物語だ。

今後も評価可能性とデータ権利を保ちながら、検索をAIの基盤として定着させられるかが問われる。

You.comのPMFは、LLMの回答をリアルタイム情報と引用で検証可能にしたいAI開発チームにある。

公式docsはSearch、Contents、Answer、Researchを用途別に分け、検索結果だけでなく抽出・合成までAPIに切り出す。出典

価格はusage-basedで、無料枠から始められるため試作の入口が低い。

一方、SOC 2、ZDR、DPA対応やcustom QPSを掲げ、企業導入の要件も先回りしている。出典

これは検索UIではなく、AI applicationの情報取得レイヤーとしての適合である。

最大のmoatは、検索index、Contents抽出、reranking、citation verification、agentic researchを一つの運用面に積み重ねることだ。出典

ただし検索結果の基本機能は模倣されやすい。

評価harnessやMCP、開発者向けdocsを外部へ開くことで、品質改善の速度と採用データを蓄積するエコシステム型の障壁へ移行している。出典

ネットワーク効果は強いソーシャル型ではなく弱いデータ・開発者型である。

API利用が増えるほどquery、評価、導入事例の学習は増えるが、検索結果を利用者間で直接共有する構造ではない。出典

むしろswitching costは、検索・抽出・引用・研究を一つのAPI群へ統合した後に生まれる。

複数endpointとSDK、MCPの組み合わせがworkflowの置換を難しくする。

主な対象は、AI agent、RAG、research workflow、検索UIを作る開発チームと、社内データとWebを接続したいenterpriseである。

公式docsはPython SDK、REST、MCPを用意し、APIを組み込む前提を明確にしている。出典

逆に、単純なサイト内検索だけを必要とするチームや、検索結果の品質を自社で厳密に制御したい大規模企業には、導入前のevalが必要だ。

第一はSearchからResearchまでを同じWeb indexの上に積み、開発者が自前で検索・抽出・citation trackingを組む負担を減らしたことだ。出典

第二はaccuracy、freshness、latency、costをAPIの評価軸として明示したこと。

公式benchmarkではSimpleQA 77.84%、p50 445msを公表し、性能を売り文句だけでなく検証文脈に置いた。出典

第三は、Answer APIやKnowledge parameterのように既存Search APIの境界を拡張し、回答合成とlive dataを同じ呼び出しモデルに寄せたことだ。出典

検索品質はモデルだけでなく、Webの鮮度、情報の欠落、引用の正しさに依存する。

You.com自身も検索だけではWebに存在しないlive dataを答えられない問題を説明している。出典

また、公式benchmarkは自社測定であり、provider比較やデータセット更新で結果が変わる。

評価用のOSS harnessを公開したこと自体、単一の数字だけでは導入判断できないという不確実性を示す。出典

AI検索市場では大手モデル提供者が検索機能を内製するリスクもある。

You.comは独立した検索インフラとAPIの深さで差別化を続ける必要がある。

成長はconsumer searchからenterprise APIへ軸足を移し、developer docs、free credits、MCP、GitHubで試用を広げ、SOC 2・ZDR・DPA・custom QPSで企業の本番要件へ接続する順番だ。出典

従量課金は小さく始めやすい一方、検索コストが増えるほど粗利と品質維持のトレードオフが出る。

SearchだけでなくContents、Answer、Research、Finance Researchを追加し、同じ顧客の利用深度を上げる拡張が重要になる。出典

主要チャネル: content, developer_docs, github, product_led, enterprise_sales, community

You.comから学べるのは、AI機能を一枚の万能endpointにせず、Search、Contents、Answer、Researchへ分解する考え方だ。

利用者が必要な速度・深さ・制御を選べる。出典

もう一つは、性能を主張するだけでなく、評価harnessを公開して比較可能性を作ること。

数字の見栄えより、顧客が自分のqueryとcostで再検証できる状態のほうが、インフラ製品の信頼を積み上げる。

日本で展開するなら、企業内の日本語文書・官公庁情報・商用データベースを、citation付きで扱える検索基盤として位置づけるとよい。

日本語の表記揺れやPDF、長寿企業の一次資料は、一般Web検索だけでは取りこぼしやすい。出典

ただし国内データの権利処理、保存場所、個人情報、回答の説明責任を先に設計する必要がある。

ZDRやDPAの選択肢を日本の法務・情シス要件へ翻訳できるかが導入の分岐になる。