Vercel 上で AI エージェント向け IDE を構築した Superset の取り組み
Superset は Vercel のインフラを活用し、並列実行される AI エージェント群を管理するための専用 IDE を構築し、従来の開発ワークフローのボトルネックを解消した。
キーポイント
マルチエージェント用 IDE の登場
Superset は単一のエンジニアとエージェントの対話から、クラウド上で複数のエージェントを並列に指揮する新しい開発形態に対応するために構築された。
インフラの並列化が不可欠
各エージェントスレッドに孤立した環境を提供し、ブランチごとのライブ URL を即時生成することで、従来の CI/CD のキュー待ちによるボトルネックを排除している。
Vercel によるプラットフォーム不要化
チームはプラットフォームエンジニアリングを省略し、Next.js プロジェクトと Vercel の機能(Blob, Cron Jobs, AI Gateway など)のみで開発・運用を完結させている。
劇的なスケーラビリティの実現
週に最大 1,400 デプロイ、日次 600 のプレビュー環境を処理し、平均ビルド時間を約 30 秒に抑えることで、エージェントの並列実行を阻害しない基盤を提供している。
Vercel 環境での完全統合とスケーラビリティ
AI SDK、AI Gateway、Fluid compute を活用し、追加のクラウドやプラットフォームエンジニアリングチームを必要とせず、並列タスクを自動的に処理する。
Superset による自己利用と開発速度の向上
チームが Superset を自身の IDE として最大 12 インスタンスで並行運用し、シリアルな決定待ちを排除してコミットグラフを指数関数的に拡大させた。
即座のデプロイと自動修復によるリスク低減
平均 30 秒のビルド時間と 1 週間に 1,400 回のデプロイにより、エージェントが 30 分以内に不具合を修正・マージし、失敗時のロールバックも即時に行える。
影響分析・編集コメントを表示
影響分析
この記事は、AI エージェントが単なるチャットボットから自律的な開発チームとして振る舞うようになりつつある現状を示しており、従来の IDE や CI/CD ツールでは対応できない新たなインフラ要件を浮き彫りにしています。Superset の事例は、Vercel などのモダンなクラウドプラットフォームを活用することで、大規模なエージェント運用を小規模チームで実現可能であることを示す重要な実証例であり、今後の AI エージェント開発の標準的なアーキテクチャに影響を与える可能性があります。
編集コメント
AI エージェント開発における「並列処理のインフラ的制約」を明確に指摘しており、単なるツールの紹介ではなく、開発パラダイムシフトの本質的な課題解決策として注目すべき事例です。
Superset on Vercel
週あたり 1,000〜1,400 のデプロイメント
1 日あたり約 600 のプレビューデプロイメント
平均ビルド時間約 30 秒
週次 DAU(日次アクティブユーザー)成長率 57–64%
AI を用いたソフトウェア開発は、かつては単一のエンジニアが単一のエージェントとローカルリポジトリについてチャットするところから始まりました。今日では、開発者はクラウド上で多数のエージェントを指揮していますが、従来のツールは「1 人の開発者が 1 つのチケットを順次処理する」という旧来の仕事の形のために設計されました:IDE(統合開発環境)、ターミナル、レビューシステムです。
Superset の共同創設者である Kiet Ho 氏、Satya Patel 氏、Avi Peltz 氏は、YC ベンチャーキャピタル支援企業での元 CTO 経験を持つ彼らによって、マルチエージェント開発のための IDE として Superset が構築されました。これは最大 10 個のコーディングエージェントを並列で実行し、それぞれが独自の隔離されたワークスペースで動作します。開発者はこれを使用して、複数のブランチにまたがってコードを生成するエージェントチームを指揮します。
エージェントチームを並列で実行することは、基盤となるプラットフォームが担わなければならない業務の内容を変えます。Superset がユーザーに提供する製品が並列的に見えるのは、プラットフォーム上の何かが作業の待機を強制しないからです。もしどのレイヤーでもわずかな時間でも遅延が生じれば、その上に構築された並列処理はそれとともに崩壊してしまいます。
並列エージェントには並列インフラストラクチャが必要
このワークフローには、製品表面からは見えない依存関係が存在します。各エージェントスレッドには独自の隔離環境が必要であり、各ブランチにはライブ URL が必要であり、各変更には安全に実行できる場所が必要です。
即時プロビジョニングがない場合、並列エージェントは並列ではなくなります。CI パイプラインはブランチごとに設定する必要があり、プレビュー環境を手動で管理しなければならず、デプロイが互いにバックアップしてしまいます。一度に dozen のエージェントを運用しているチームにとって、この直列化こそが製品を破綻させる原因です。12 のワークフローが 1 つのキューに圧縮され、数分で完了するはずのタスクが数時間かかるようになります。開発者が再び待たされることになり、これは Superset が解決するために存在するまさにその問題です。
6 つの Next.js プロジェクト、プラットフォームチームなし
Vercel は最初からデフォルトの選択肢でした。3 人の創業者全員が以前の会社で Vercel を活用して開発していたからです。初日から、Superset は Vercel 上で 6 つの Next.js プロジェクトを稼働させています:Web アプリ、マーケティングサイト、ドキュメント、そして 3 つのサポートサービスです。チームはプラットフォームエンジニアリングを完全にスキップし、製品への集中を維持しました。
Superset の開発者やエージェントが作成するすべてのブランチは自動的にプレビューデプロイとなり、しばしば複数のサービスが起動します。ピーク時には、Superset は内部で 1 日あたり約 600 のプレビューデプロイを生成しています。すべてのブランチにライブ URL が付与され、チームがデプロイクューを待つことは決してありません。
あらゆるワークロードのための単一プラットフォーム
スタックは製品とともに成長し、機能追加に伴い各コンポーネントが特定の課題解決のために導入されました:
Vercel Blob はエージェントやユーザーからのアーティファクトを保存し、管理すべきオブジェクトストレージは不要です。
Cron Jobs(定期タスク)により、並列環境の蓄積を防ぎます。
BotID は高トラフィック期間中にボットをフィルタリングし、カスタムミドルウェアは不要です。
エージェントのオーケストレーション自体は AI SDK と AI Elements で実行され、AI Gateway がモデルのルーティングを処理します。Fluid compute が背後でスケーリング負荷を引き受け、エージェントが分散しても並列タスクを吸収し、チームに再アーキテクチャを強いることはありません。
Superset が新しい製品領域へと拡大するにつれて、スタック全体は Vercel のまま維持されています。追加のクラウドを接続する必要も、維持すべきオーケストレーション層も、それを繋ぎ止めるためのプラットフォームエンジニアリングチームも存在しません。新しい表面領域は、従来の表面領域を処理したのと同じプリミティブの上に構築されるため、チームがインフラ整備に時間を割くのではなく、製品開発に集中し続けることが可能になります。
Superset はその自身に対するスーパーユーザーである
Superset チームが実際に Superset をどのように使用しているかを示す最も信頼性の高い証拠です。GitHub のイシューは Superset に流れ込み、並列ワークスペース間で分割されます。Satya はチームのセットアップを調整し、一度に最大 12 インスタンスまで実行できるようにしています。誰かがシリアルの決定を待たずに、複数の取り組みが同時に進行します。以前の開発ワークフローと比較して、Superset のコミットグラフは指数関数的な成長を示しています。
Hacker News のスパイクによるスケーリング
Hacker News の「Show HN」でのローンチ中、ユーザー数は一晩で 3 倍に増加しました。Superset は誰かが飛行中にインフラをプロビジョニングすることなく、このスパイクを吸収しました。
これはインシデントにも適用されます。Superset に顧客から問題が報告されると、エージェントが起動して修正コードを記述し、プレビューを生成し、30 分以内にコードをマージします。もし修正によって状況が悪化した場合でも、ロールバックは瞬時に行われるため、失敗したデプロイのコストはほぼゼロにまで低下します。
「デプロイにかかる時間はほとんどない」が基準です
Superset にとって即時デプロイが重要なのは、コードの記述からプレビュー、そしてリリースまでのループを十分に短く保つことであり、これにより数十もの並列する作業ストリームにわたっても速度が停滞しないようにするためです。ビルド時間は平均して約 30 秒で、週あたりのデプロイ量は 1,000 から 1,400 の間にあります。
今後の展望
成功のパターンはすでに明確です:並列処理のために設計された製品を、並列して作業するチームが、エージェントインフラストラクチャ(agentic infrastructure)上で構築しています。これは、彼らをキューに待機させることを強制しないものです。顧客へ提供される新しいエージェント機能は、まずエンジニアが一度に数十個を実行して負荷テストにかけられます。その数はさらに増え、その下にあるインフラストラクチャはそれを前提として設計されています。
Superset について:Superset は元 YC(Y Combinator)の CTO を務めた 3 名のチームによって構築されており、AI エージェント時代の IDE です。これにより、開発者は複数のコーディングエージェントを並列して実行できます。
続きを読む
原文を表示
Superset on Vercel
1,000–1,400 deployments per week
~600 preview deployments per day
~30 second average build time
57–64% week-over-week DAU growth
Software development with AI started as a single engineer chatting with a single agent about a local repo. Today, developers direct fleets of agents in the cloud, but traditional tools were built for the old shape of the job: IDEs, terminals, and review systems designed for one developer moving one ticket at a time.
Co-founders Kiet Ho, Satya Patel, and Avi Peltz, all former CTOs at YC-backed companies, built Superset as the IDE for multi-agent development. It runs up to 10 coding agents in parallel, each in its own isolated workspace. Developers use it to direct teams of agents generating code across multiple branches simultaneously.
Running a team of agents in parallel changes what the platform underneath has to do. The product Superset offers its users only feels parallel because nothing on the platform forces the work to wait. If any layer slows down, even briefly, the parallelism on top collapses with it.
Parallel agents need parallel infrastructure
This workflow has a dependency that's invisible from the product surface. Every agent thread needs its own isolated environment, every branch needs a live URL, and every change needs a safe place to run.
Without instant provisioning, parallel agents stop being parallel. CI pipelines have to be configured per branch, preview environments have to be managed by hand, and deploys back up behind one another. For a team running a dozen agents at once, that serialization is what breaks the product. Twelve workflows collapse into one queue, and a task that should take minutes takes hours. The developer is back to waiting, which is the exact problem Superset exists to solve.
Six Next.js projects, no platform team
Vercel was the default choice from the start, as all three founders had built on it at previous companies. From day one, Superset ran six Next.js projects on Vercel: the web app, marketing site, docs, and three supporting services. The team skipped platform engineering entirely and stayed focused on the product.
Every branch a Superset developer or agent creates becomes a preview deployment automatically, often spinning up multiple services. At its peak, Superset generates roughly 600 preview deployments a day internally. Every branch gets a live URL, and the team never waits on a deploy queue.
One platform for every workload
The stack grew with the product, and each piece was pulled in to solve a specific problem as functionality was added:
Vercel Blob stores artifacts from agents and users, no object storage to manage.
Cron Jobs prevent parallel environments from piling up.
BotID filters bots during high traffic periods, no custom middleware needed.
The agent orchestration itself runs on the AI SDK and AI Elements, with AI Gateway handling model routing. Fluid compute carries the scaling load underneath, absorbing parallel tasks as agents fan out without forcing the team to rearchitect.
As Superset has expanded into new product areas, the entire stack has stayed on Vercel. There's no second cloud to glue in, no orchestration layer to maintain, and no platform engineering team to keep it glued together. New surface areas gets built on the same primitives that handled the old surface area, which is what frees the team to keep moving on product instead of plumbing.
Superset is its own super user
The most credible proof how the Superset team uses Superset themselves. GitHub issues flow into Superset and get split across parallel workspaces, and Satya has tuned the team's setup to run up to a dozen instances at once. Multiple efforts move forward without anyone waiting on serial decisions. Compared to their previous dev workflows, Superset's commit graph looks exponential.
Scaling through a Hacker News spike
During a Hacker News "Show HN" launch, user counts tripled overnight. Superset absorbed the spike without anyone provisioning infrastructure mid-flight.
That extends to incidents. If a customer reports an issue to Superset, their agents can spin up, write the fix, generate a preview, and merge the code in under thirty minutes. If the fix makes things worse, rollbacks are instant, so the cost of a bad deploy drops to near zero.
"Almost no time to deploy" as the bar
For Superset, immediate deployment matters because it keeps the loop between writing code, previewing it, and shipping it short enough that velocity never stalls, even across dozens of parallel workstreams. Build time averages around 30 seconds, and deployment volume runs between 1,000 and 1,400 a week.
What's next
The pattern for success is already clear: a product built for parallelism, by a team that works in parallel, on agentic infrastructure that doesn't force them back into a queue. Every new agent capability they ship to customers gets stress-tested first by their own engineers running a dozen at once. The dozen will become two dozen, and the infrastructure underneath was built to expect it.
About Superset: Superset is built by a team of three ex-YC CTOs and its the IDE for the AI agents era, letting developers run multiple coding agents in parallel.
Read more
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み