Vercel 上で AI エージェント向け IDE を構築した Superset の取り組み

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 です。これにより、開発者は複数のコーディングエージェントを並列して実行できます。 続きを読む

Vercel 上で AI エージェント向け IDE を構築した Superset の取り組み

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト