Vercel CEO ギレルモ・ラウチがモデルとエージェントの分離を主張

1日600万デプロイメント。そのうち半分はコーディングエージェントによってトリガーされている。1日あたり1兆トークンがVercelのインフラストラクチャを流れている。ギレルモ・ラウチがプロダクション環境でのAIについて語るとき、彼は理論を述べているのではなく、ライブテレメトリーから読み上げている。Vercelの ShipNYC カンファレンス後の最近のTechCrunchインタビューで、ラウチはAIインフラストラクチャがどこに向かっているのかの核心に切り込む鋭い議論を展開した。モデルとエージェントは分離される必要があり、それを最初に理解した開発者がプロダクション環境で実際に生き残るシステムを構築するだろうというものだ。

この会話はVercelのロードマップをはるかに超えた意味を持つ。アジア全域の開発者たち — 素早くシップし、コストを厳密に監視し、シリコンバレーとは異なるペースで動く市場向けのAIネイティブプロダクトを構築している開発者たち — にとって、ラウチのフレーミングは現在のエージェントアーキテクチャについて考える実践的なレンズを提供する。

何が起きたのか

Vercel CEO ギレルモ・ラウチがモデルとエージェントの分離を主張というのは、単なるキャッチーなヘッドラインではない。Vercelがプロトタイピング段階を超えて、組織内でエージェントをスケールで実行し始めたときに明らかになった、実在するアーキテクチャ上の緊張を説明している。

TechCrunchのインタビューによると、昨年はプロトタイピングの時期だった — 「エージェントを解放し、誰もが構築できる」。Vercelは社内全体に数百のエージェントを有機的にデプロイし、素早く学習した。厳しい教訓は、それらのエージェントがプロダクション環境に到達したときに来た。ラウチの中心的な洞察は、プロダクション環境に最適化すると、すぐに価格対性能を見始めるということだ。これはプロトタイピング段階でほとんどのチームがスキップする質問を強制する — モデルとエージェントロジックは本当にバンドルされるべきなのか？

それらを分離する議論は単純明快だ。エージェントはループである。コンテキストを認識し、アクションを決定し、それを実行し、繰り返す。モデルはそのループ内の推論コンポーネントに過ぎない。それらが密結合されているとき — エージェントが本質的に特定の1つのモデルのAPIのラッパーであるとき — ランドスケープが変わるにつれてモデルをスワップする能力、タスクタイプごとにコストを最適化する能力、またはエージェントロジックを書き直さずにより安く、より高速なモデルにシンプルなサブタスクをルーティングする能力を失う。

現在1日あたり1兆以上のトークンを処理するVercelのAIゲートウェイは、この問題への部分的な答えである。それはエージェントとモデルの間に位置し、モデルレイヤーを抽象化して、エージェントロジックをポータブルに保つ。ラウチの立場は、Vercelのようなプラットフォーム企業が今、主要なラボと直接的な緊張関係にあるということだ。まさに、ラボはモデルとエージェントをバンドルされたままにしておくための構造的インセンティブを持っているからだ — ロックインはトークン収益に良い。プラットフォーム企業は反対のインセンティブを持つ。ポータビリティと構成可能性は、次のベンチマークサイクルでどのモデルが勝つかに関わらず、開発者をプラットフォーム上に保つ。

これは本当に重要な構造的な戦いであり、開発者が今まさに行っているインフラストラクチャの決定の中で展開されている。

アジアにとって重要な理由

アジアのAI開発者エコシステムは、このモデル対エージェントの緊張に対する特定の関係を持っており、西洋のコメンタリーはしばしばこれを見落とす。東南アジア、韓国、日本、インドの開発者たちはOpenAIやAnthropicのみで構築していない。ここでのモデルランドスケープは本当に多元的だ — AlibabのQwenシリーズ、DeepSeek、BaiduのERNIE、そして地域言語向けにファインチューニングされた成長中のオープンウェイトモデルのスタックすべてがプロダクションワークロードを競う。これは弱点ではない。実は、エージェントアーキテクチャが最初からモデルポータビリティのために構築されていれば、構造的な利点だ。

コスト感度はもう1つの要因だ。ジャカルタやホーチミンシティでAIネイティブプロダクトを構築しているスタートアップは、サンフランシスコのシリーズB企業と同じマージン仮定で作業していない。ラウチが「価格対性能」をプロダクション環境での支配的な懸念として語るとき、それはアジアで異なる響きを持つ — それは素晴らしい最適化ではなく、実行可能なビジネスと推論コストで燃え尽きるビジネスの違いであることが多い。

レイテンシーの側面もある。エージェント呼び出しをUS ベースのモデルエンドポイント経由でルーティングすると、アジアのエンドユーザーに対して実際のレイテンシーが導入される。エージェントオーケストレーションをモデル選択から明確に分離するアーキテクチャは、地域的にデプロイされたモデルへのルーティングをはるかに容易にする — Alibaba CloudのQwenデプロイメント、ローカルプロバイダーのDeepSeekエンドポイント、または独自のインフラストラクチャで実行されているオープンウェイトモデルであろうと。ラウチのフレームワークをアジアの文脈に適用すると、コストについてだけではなく、実際にあなたが提供しているユーザーに対してうまく機能するシステムを構築することについてだ。

MonstarX上で構築している創業者たちにとって、アジアのAIネイティブ開発プラットフォームは、このアーキテクチャ原則が今日のエージェントスタックについてどのように考えるべきかに直接マップされる。モデル依存性をエージェントロジックにハードコードしているチームは、より良い、より安い、またはより高速なモデルが利用可能になったときに解くのが苦痛になる技術的負債を蓄積している — そしてアジアのモデルランドスケープでは、それはほとんどの人が予想するより短いサイクルで起こる。

開発者にとって意味すること

ラウチの議論の実践的な意味は、エージェントアーキテクチャが他の分散システムと同じ設計規律に値するということだ。これを具体的にどのように考えるかを示す。

モデルをアイデンティティではなくインフラストラクチャとして扱う。エージェントの価値はそのオーケストレーションロジック、メモリ管理、ツール使用、タスク分解能力にある。そのどれもが、どのモデルを呼び出しているかと絡み合うべきではない。エージェントループとモデル呼び出しの間に明確なインターフェースを定義する — 今日は1つのモデルのみを使用していても。

これの最小バージョンは、モデル呼び出しを単一の関数の背後に抽象化することのように見える：

async function callModel(prompt, options = {}) {
  const { model = process.env.DEFAULT_MODEL, temperature = 0.2 } = options;
  return await modelGateway.complete({ prompt, model, temperature });
}

その単一の抽象化レイヤーは、GPT-4oからQwen-MaxからDeepSeek-V3へのスワップが、リファクタリングではなく設定変更であることを意味する。明らかに聞こえるが、今書かれているエージェントコードベースの大多数はこれをしていない — 彼らはOpenAI SDKを直接、どこでも、モデル名がハードコードされた状態で呼び出す。

最初からマルチモデルルーティング用に設計する。エージェント内のすべてのサブタスクが同じモデルを必要とするわけではない。ドキュメント要約ステップは、より小さく、より高速なモデルで安く実行される可能性がある。複雑な推論ステップは、フロンティアモデルが必要な場合がある。エージェントロジックがモデルレイヤーから分離されていれば、何も書き直さずにタスクタイプでルーティングできる。これはVercelのAIゲートウェイプレイが意味する場所だ — スケールでのこの種のルーティングのためのインフラストラクチャだ。

セッションごとではなく、エージェントステップごとのトークンコストを監視する。モデルをエージェントから分離すると、以前は持っていなかった可観測性を得る。エージェントループのどのステップが最もトークンを消費しているか、どのモデル呼び出しがそのコストに対して低品質の出力を返しているか、最終結果を低下させずにより安いモデルを代用できる場所を見ることができる。これはラウチが説明している「価格対性能」最適化だ — アーキテクチャ分離が存在してはじめて可能になる。

障害モードについて異なる方法で考える。密結合されたモデル・エージェント・システムは、モデルAPIがダウンするか、レート制限されるとき完全に失敗する。分離されたシステムは、代替モデルにフォールバックし、優雅に低下し、またはタスクをキューに入れることができる。プロダクション環境でリアル