CursorがVercelマイクロフロントエンドとフラグで構築した成長イテレーションループ
Cursor は Vercel のマイクロフロントエンドと機能フラグを活用し、複数のドメインを統合してブランド認知を高めつつ、PLG サインアップを 5% 増加させる成長イテレーションループを構築した。
キーポイント
単一ドメインへの統合戦略
マーケティングサイト、サインインダッシュボード、ドキュメント、ヘルプセンターの 4 つのウェブプロパティを「cursor.com」に統一し、ブランド認知とユーザー体験の一貫性を確保した。
マイクロフロントエンドによる実装
異なるリポジトリで管理される各機能を Vercel のマイクロフロントエンド技術で統合し、既存の認証フローを中断させることなく新サイトの迅速なローンチを実現した。
データ駆動型の成長イテレーション
機能フラグを活用して A/B テストやローカライゼーション（4 カ国から 11 カ国へ）を安全に展開し、製品主導型から営業支援型への移行と PLG サインアップの向上を両立させた。
エッジ構成を活用した高速な A/B テストの実装
Statsig と Vercel Flags SDK を組み合わせ、Edge Config で低遅延に評価を行うことで、SEO や PLG フネルを損なうことなくシームレスな実験環境を構築しました。
ビルド時の事前計算によるユーザー体験の最適化
レイアウトのズレやフラッシャー現象を防ぐため、バージョン生成をビルド時に事前計算（pre-compute）するアプローチを採用し、高速なページ読み込みと滑らかな表示を実現しています。
CMS 廃止によるエージェント主導のコンテンツ更新ワークフロー
人間の作業に依存しない迅速な変更のため CMS を放棄し、AI エージェントが下書きを作成し人間がレビュー・マージする新しいワークフローを導入しました。
コードベースでのコンテンツ公開と自動化ワークフロー
CMS の手動操作によるボトルネックを解消し、Slack からエージェントが GitHub PR を作成して Vercel プレビューや動画生成を行うエンジニアリングに近いプロセスへ移行した。
影響分析・編集コメントを表示
影響分析
この記事は、SaaS プロダクトが急成長期において、複雑化するウェブ体験を統合し、かつ実験的な改善を安全に行うための具体的なアーキテクチャパターンを示しています。特に Vercel のエコシステムを活用したマイクロフロントエンドの導入事例は、類似規模のテック企業が DX（デジタルトランスフォーメーション）や PLG 戦略を推進する際の参考モデルとして高い価値を持ちます。
編集コメント
AI エディタツール市場で急成長する Cursor の、技術的基盤をどう成長戦略に組み込んだかの事例は、開発者向け SaaS 企業の DX において非常に示唆に富んでいます。単なる機能追加ではなく、アーキテクチャの再設計を通じて「学習速度」を向上させた点は、多くのテック企業が直面する課題に対する実用的な解と言えます。
Cursor on Vercel
cursor.com の下にウェブプロパティを統一し、約 100 以上のルートを統合しました。
実験を通じて PLG（Product-Led Growth）によるサインアップを 5% 増加させました。
ローカライゼーションの対応言語を 4 か国から 11 か国に拡大しました。
Cursor の成長チームは、製品の最前線に近い場所で活動しています。
9 月に Cursor が新ブランドを立ち上げ、マーケティングサイトをリデザインした頃には、すでにチームが迅速に行動できることを証明していました。次のステップはより微妙なものでした：単に速く動くのではなく、より速く学ぶことでした。彼らは、どの変更が機能し、どの変更が機能していないのかを理解したいと考えており、さらに広がり、よりグローバル化するウェブ体験全体で確信を持って改善を行う方法を模索していました。
つまり、同時に 2 つの問題を解決する必要がありました。
まず、Cursor は単一のドメインの下で一貫したウェブ体験を実現したかったのです。次に、特にローカライゼーションの拡大や、純粋な製品主導の動きから販売も組み合わせた動きへと進化し始めた際に、結果を測定するためのフレームワークが必要でした。
より広大な対象領域と、シンプルな目標：1 つの cursor.com を目指す
Emily Gavrilenko は Cursor の成長チームに所属するエンジニアです。彼女は 9 月の立ち上げ当初から参加し、ロゴの収集や顧客の実績事例の確保を行い、ビジネスを牽引するコアとなるサインアップフローが破綻しないように努めました。立ち上げチームは小規模で、Emily、ブランドデザイナーの Justin、そして開発者教育担当バイスプレジデントの Lee Robinson の 3 名でした。
Cursor のウェブプレゼンスは範囲を広げていました。単なるマーケティングサイトではなく、サインインダッシュボード、ドキュメント、ヘルプセンターも含まれていました。各サイトはそれぞれ独自のリポジトリに存在していましたが、訪問者にとってはすべてが一つの体験として感じられる必要がありました。
Cursor の目標は明確でした：すべてのものを cursor.com の下で統一することです。
「ドメインとブランド認知度を高めるために、すべてのものを cursor.com に置きたかったのです」と Emily は述べ、プロパティ間でドメインの体験を標準化しようとする動きについて説明しました。
マイクロフロントエンドによる 4 つのプロパティの統合
Cursor はすでにマーケティングサイトとサインイン済み体験を別々のリポジトリに分離していました。これによりチームは各領域内で迅速に移動できるようになりましたが、同時に新たな課題も生じました：複数のコードベースとプロパティが同じドメインの下で存在する場合、ユーザーに対してどのように統一された体験を提供するかという問題です。
答えはマイクロフロントエンドでした。
Cursor の即時的な制約は実務的なものでした。新しいマーケティングサイトを迅速に立ち上げたいと考えていましたが、認証やサインアップの主要ルートはまだ旧来の体験上に残っていました。マイクロフロントエンドを使えば、既存の流れの継続性を維持しながら、新しいマーケティングページをリリースすることが可能になります。
Emily はこれをシンプルに説明しました：チームが求めたのは「人々が見るマーケティングページとサインアップ体験との統合」であり、マイクロフロントエンドは「ダウンタイムなしでそれを迅速に実現するための最良の方法」であると述べました。
この最初の立ち上げは始まりに過ぎませんでした。Cursor の移行パスは意図的に漸進的であり、3 つのフェーズに分けて実行されました：
新しいマーケティングサイトはまず立ち上げられ、約 20 の主要ルートに対応しました。
ドキュメントはその後に移行し、docs.cursor.com から cursor.com/docs へ移動しました。
ヘルプセンターは最後に統合され、同じマイクロフロントエンド設定に組み込まれました。
時が経つにつれ、これは大きなルーティング領域へと成長しました。現在、Cursor は 4 つの異なるサイト間で 100 を超えるルートをリダイレクトしています。
Flags、Edge Config、Statsig を用いた学習ループの構築
ドメインの統一は最初のステップでした。2 つ目のステップは測定ループの構築です。
この作業以前、Cursor はサインアウト状態のマーケティング体験において A/B テスト（A/B test）を実行していませんでした。「当初は、可能な限り最良のプロダクトを構築することに集中していました」と Emily は語ります。「チームとユーザーベースが成長するにつれ、オンボーディングファネルの最適化に時間を割き始めました。」
Cursor は、実験データに基づいてオンボーディングやコンテンツの選択を確信を持って行いたいと考えていました。健全な SEO/AEO（検索エンジン最適化/生成型検索最適化）および PLG（製品主導成長）ファネルの維持が最優先事項であり、レイアウトシフトや実験によるフリッカーなしで高速にページを読み込み、シームレスにコンテンツをレンダリングすることも重要でした。
彼らが採用した実装は、Cursor がすでに使用していたツールと、体験を高速かつ一貫性のあるものにする Vercel のプリミティブを組み合わせたものです：
実験は Statsig に配置されており、これは Cursor がサインイン状態のプロダクトでも既に使用しているものです。
マーケティングサイトについては、Vercel Flags SDK を実装し、Edge Config（エッジ設定）を使用して低遅延で実験を評価できるようにしました。
シームレスな体験を維持するために、彼らは事前計算アプローチを用いてビルド時にバージョンを生成し、より長いビルド時間と引き換えに、ページ内の滑らかな体験を実現しています。
システムが整ったことで、カーソルが最も必要としていたことが可能になりました。つまり、最も重要なコンテンツやフローに対して自信を持って反復改善を行えるようになったのです。
実験自体は、高レベルのメッセージングからナビゲーションに関する意思決定まで多岐にわたりました。例えば、ヒーローコピーやコール・トゥ・アクション（CTA）をテストし、「アプリをダウンロード」するか「始めよう」という呼びかけがどちらが優れているかを検証しました。また、営業活動の拡大に伴い、ナビゲーションに「お問い合わせ」を追加する実験も行いました。エミリーは注目すべき成果の一つとして次のように語っています。「営業成約数は増加しましたが、PLG（Product-Led Growth）によるサインアップ数も 5% 増えました。」
大規模な国際的な顧客層を相手にしているため、実験はローカライゼーションやセグメンテーションにも及びました。カーソルは国ごとのローカライゼーション手法、ティア推奨、さらに訪問者の地理情報に基づいて表示するロゴやケーススタディの選定までテストしました。
追いつくための公開：CMS からエージェントファーストワークフローへ移行
カーソルのウェブ上のプレゼンスが拡大するにつれ、変更を迅速にリリースする必要性も高まりました。しかし、カーソルにとって「迅速」とは、慌ただしい人間による作業を意味するものではありません。それは、まずエージェントが下書きを行い、その後人間がレビューしてマージするというプロセスを指します。
このワークフローが、重要な意思決定へと導きました。カーソルはマーケティングコンテンツの更新のために CMS（コンテンツ管理システム）を使用することをやめたのです。
その理由は単純でした。彼らのチームの働き方に合っていなかったからです。
Emily は、開発の多くが Slack のクラウドエージェントを通じて行われていると説明しました。誰かが「@Cursor、この修正をお願いします」といったリクエストでエージェントにタグ付けできます。CMS によって人間は手動ループに戻らされました：ログインしてコンテンツを直接編集し、別のインターフェースで変更を管理することです。「CMS への移行により、その速度が大幅に低下しました」と Emily は述べています。「実際にサインインして自分自身で変更を加える必要があったからです。」
そこで Cursor は、人間が関与する必要がある場合のために Markdown を使用し、コンテンツをコード内で直接公開することにシフトしました。
実際には、これは変更リクエストがエンジニアリングよりもむしろコンテンツ運用に近いワークフロートリガーすることを意味します：
エージェントが GitHub の PR（プルリクエスト）を開く
PR が Vercel のプレビューデプロイメント（本番環境への展開前のテスト用環境）を生成し、レビュー担当者がクリックして変更を検証できる
クラウドエージェントがコンピューター操作を使用してプレビュー動画を生成し、関連するルート全体での前後の動作を示す
Cursor にとってこれは単にステップを削除しただけではありません。誰が参加できるかを変えたのです。CMS の専門知識を必要とする代わりに、チームのメンバーは Slack で更新をリクエストし、プレビューや成果物を通じて結果を検証できるようになりました。
CMS の移行自体は、このアプローチの概念実証（PoC）でした。Cursor は 1 週間にわたって 200 以上のエージェントを並列で実行し、コンテンツの移行、テスト、および問題の特定を行いました。これは、問題が発生した際にプロンプトが必要となるものの、作業の大部分を自律的に処理する自己反復・自己検証型のループです。総コストはトークン利用料約 260 ドルと経過時間 3 日でした。
Cursor がプロセスを再利用可能なスキルとしてコード化すると、さらに容易になりました。Emily は複合効果について説明しました。初期の作業には調査と反復が必要でしたが、一度完了してスキルとしてコード化されれば、変更を加えることが非常にシームレスになります。
次への統一基盤
Cursor の物語は単なる 1 つの移行に関するものではありません。それは野心に合わせてスケールする Web システムを構築することです。複数のプロパティに展開可能な unified cursor.com エクスペリエンス（統合された体験）であり、測定可能で反復可能、そして次第に自動化される迅速なイテレーションをサポートします。
マイクロフロントエンドは、ダウンタイムなしでドメイン経験を統合する道筋を Cursor に与えました。フラグ機能、Edge Config、およびプリコンピュートにより、レイアウトシフトのない高速な実験が可能になりました。また、エージェントファーストの公開ワークフローにより、表面積が拡大しても摩擦を加えることなく改善を継続してリリースすることが可能になりました。
Cursor について：Cursor は、AI とエージェントを活用してチームがソフトウェアをより速く作成・リリースするためのツールを開発しています。
続きを読む
原文を表示
Cursor on Vercel
Unified four web properties and ~100+ routes under cursor.com
Increased PLG signups 5% through experimentation
Expanded localization from 4 languages to 11
Cursor’s growth team sits close to the sharp edge of the product.
By the time Cursor launched a new brand and redesigned marketing site in September, the team had already proven they could move quickly. The next step was more subtle: not moving faster, but learning faster. They wanted to understand which changes were working, which were not, and how to make confident improvements across a web experience that was getting broader and more global.
That meant solving two problems at once.
First, Cursor wanted a single, consistent web experience under one domain. Second, they needed a framework for measuring results, especially as they expanded localization and started evolving from a purely product-led motion to one that also included sales.
A bigger surface area, and a simple goal: one cursor.com
Emily Gavrilenko is an engineer on Cursor's growth team. She was part of the September launch from the start, collecting logos, sourcing customer proof points, and making sure the transition did not break the core signup flows that drive the business. The launch team was small: Emily, brand designer Justin, and VP, Developer Education Lee Robinson.
Cursor's web presence had expanded in scope. It was not just a marketing site. It also included the sign-in dashboard, documentation, and a help center. Each site lived in its own repo, but all needed to feel like a single experience to visitors.
Cursor's goal was straightforward: unify everything under cursor.com.
“We wanted everything to be on cursor.com for domain and brand recognition,” Emily said, describing the push to standardize the domain experience across properties.
Unifying four properties with Microfrontends
Cursor had already separated their marketing site and signed-in experience into different repositories. That helped the team move quickly within each surface area, but it also created a new challenge: how do you present a unified experience for users when multiple codebases and properties need to live under the same domain?
Microfrontends was the answer.
Cursor’s immediate constraint was practical. They wanted to launch the new marketing site quickly, but key routes for authentication and signup still lived on the old experience. Microfrontends let them ship the new marketing pages while maintaining continuity for the existing flows.
Emily described it simply: the team wanted “integration between the marketing pages people see and the signup experience,” and Microfrontends were “the best way to get it out fast without any downtime.”
That initial launch was only the start. Cursor’s migration path was intentionally progressive, executed in three phases:
The new marketing site launched first, supporting around 20 core routes.
Docs moved later, migrating from docs.cursor.com to cursor.com/docs.
The help center came last, also folded into the same Microfrontends setup.
Over time, this grew into a significant routing surface area. Cursor is now redirecting over 100 routes across four different sites.
Building a learning loop with Flags, Edge Config, and Statsig
Unifying the domain was step one. Step two was building the measurement loop.
Before this work, Cursor was not running A/B tests on the signed-out marketing experience. “We initially hyper-focused on building the best possible product.” Emily said. “As our team and user base grew, we began dedicating time to optimizing the onboarding funnel.”
Cursor wanted to confidently make onboarding and content choices backed by experimentation data. Maintaining a healthy SEO/AEO and PLG funnel was a top priority, paired with fast loading pages and seamless content rendering without layout shifts and experimentation flicker.
The implementation they landed on combined tools Cursor already used with Vercel primitives that made the experience fast and consistent:
Experiments live in Statsig, which Cursor already used for the signed-in product.
For the marketing site, they implemented the Vercel Flags SDK so experiments could be evaluated with low latency using Edge Config.
To keep the experience seamless, they generate versions at build time using a pre-compute approach, trading longer builds for a smoother on-page experience.
Once the system was in place, it enabled exactly what Cursor wanted: confident iteration on the content and flows that matter most.
The experiments themselves ranged from high-level messaging to navigation decisions. They tested hero copy and calls-to-action, for example whether it was better to ask visitors to “download” the app versus “get started.” They also tested adding “Contact sales” in the navigation as Cursor expanded their sales motion, and Emily shared one notable outcome: “Sales conversions increased, but so did PLG signups, by 5%."
With a large international audience, experimentation also extended into localization and segmentation. Cursor tested country-level localization approaches, tier recommendations, and even which logos and case studies were shown based on the visitor's geography.
Publishing that keeps up: dropping the CMS for an agent-first workflow
As Cursor’s web surface area grew, so did the need to ship changes quickly. But for Cursor, “quickly” did not mean frantic human work. It meant letting agents do the first pass, then letting humans review and merge.
That workflow drove a key decision: Cursor moved away from a CMS for updating marketing content.
The reason was simple: it did not fit how the team worked.
Emily explained that much of their development happened through cloud agents in Slack. Someone can tag an agent with a request, like “@Cursor, make this fix.” A CMS forced humans back into a manual loop: logging in, editing content directly, and managing changes in a separate interface. “Migrating to CMS slowed that down significantly,” Emily said, “because we had to actually go sign in and make the changes to ourselves.”
So Cursor shifted to publishing content directly in code, using Markdown where edits might need a human in the loop.
In practice, that means a change request can trigger a workflow that looks much more like engineering than content operations:
Agents open a GitHub PR
The PR produces a Vercel Preview Deployment so reviewers can click around and test changes
Cloud agents can generate a preview video using computer use, showing before-and-after behavior across relevant routes
For Cursor, this did more than remove steps. It changed who could participate. Instead of requiring specialized knowledge of the CMS, people across the team could request updates in Slack and review the result through previews and artifacts.
The CMS migration itself was a proof of concept for the approach. Cursor ran over 200 agents in parallel over the course of a week to migrate content, test it, and surface issues: a self-iterating, self-testing loop that required prompting when problems came up but handled the bulk of the work autonomously. Total cost: about $260 in tokens and three days of elapsed time.
Once Cursor codified a process as a reusable skill, it became even easier. Emily described the compounding effect: the upfront work took research and iteration, but once it was done and codified in a skill, making changes became super seamless.
A unified foundation for what comes next
Cursor’s story is not about a single migration. It is about building a web system that scales with ambition: a unified cursor.com experience that can expand across multiple properties, while supporting rapid iteration that is measured, repeatable, and increasingly automated.
Microfrontends gave Cursor a path to consolidate their domain experience without downtime. Flags, Edge Config, and pre-compute made experimentation fast and without layout shifts. And an agent-first publishing workflow made it possible to keep shipping improvements without adding friction as the surface area grew.
About Cursor: Cursor builds tools that help teams write and ship software faster with AI and agents.
Read more
関連記事
Amplitude社、Cursorにより本番コードの出荷量を3倍に増加
Amplitude社がAI駆動のコードエディタ「Cursor」を導入し、開発チームが本番環境へのコード出荷量を従来の3倍に増加させた。
より優れたAIモデルがより野心的な仕事を可能にする
AI企業が、より高性能なAIモデルを開発し、これにより研究者や開発者がより複雑で野心的なプロジェクトに取り組めるようになった。
より優れたAIモデルがより野心的な仕事を可能にする
AI企業がより高性能なAIモデルを開発し、これにより従来よりも複雑で創造的な作業を自動化できるようになった。