Faire は週間 PR スループットを 2 倍にし、18 か月規模の移行を、エージェント群を管理する 1 人のエンジニアで完遂しました。これを可能にしたのが、大規模な並列化と自律性を備えた Cursor の クラウドエージェント です。クラウドエージェントはローカルマシンのメモリやリソースの制約に縛られずに動作し、それぞれが独自の開発環境を持ちます。つまり、エンジニアと同じように—コードを書き、テストし、作業を検証し、ソフトウェアをリリースできます。

現在 Cursor は、Faire でエージェント型開発を進めるための推奨プラットフォームとなっており、社内のバックグラウンドエージェントシステムを置き換えています。チームはさらに、Cursor Automations を使って、Slack でのバグ報告のトリアージ、CI の失敗修正、コードレビューの振り分けといった反復的なタスクにかかる時間を削減するため、手動でプロンプトを与えることなく、毎週 2,000 件を超える自律的なエージェント実行を起動しています。"

#クラウドがエージェントの大規模な並列実行を可能にする

ローカルマシンで複数のエージェントを並行して実行すると、すぐにローカルリソースの制約に突き当たります。各エージェントが同じ計算資源を取り合ううえ、別々のターミナルで進行中の10個のタスクを管理すること自体がひとつの仕事になってしまいます。「ローカルマシン上でエージェントを並列化する方法はありますが、はるかに複雑です」と、プリンシパルエンジニアのLuke Bjerringは語ります。

当初、Faireはこれを、自社運用のインフラストラクチャ上で稼働するSamuraiという社内製のクラウドエージェントシステムを構築することで解決しようとしました。しかし、優れた開発者体験を実現するには相当な投資が必要です。

「自前でサーバーを立ち上げるのは大きな投資です。人材の採用、マシンのブートストラップ、複雑なインフラストラクチャの維持が必要になります。私たちは、エンジニアにはエンドユーザーへの価値提供に集中してほしいと考えています」とBjerringは語ります。

Faireは、マネージドインフラストラクチャでもセルフホストのマシンでもクラウドエージェントを実行できる柔軟性を備えたプラットフォームを探していました。FaireがCursorを選んだ理由は、このデプロイの柔軟性に加え、GitHubのようなツールとの緊密な統合、エージェントの信頼性、エージェントを並行して管理できるすっきりしたインターフェース、そしてローカルとクラウド間でシームレスにハンドオフできることです。現在、CursorはFaire全体でエージェント型開発を進めるための推奨プラットフォームとなっています。

#開発環境によって、エージェントはより自律的に動けるようになります

並列化が効果を発揮するのは、エージェントがエンジニアのように動ける場合に限られます。つまり、依存関係を取得し、社内サービスにアクセスし、コードを実行し、変更を検証できる必要があります。開発環境が設定されていなければ、エージェントはコードを書くことはできても、自分の作業を最後まで完了させることはできません。

Faire の開発環境では、クラウドエージェントの設定が難しくなっています。バックエンドとフロントエンドはそれぞれ別の repo で管理されており、それぞれ独自の社内パッケージ依存関係を持ち、Gradle と Bazel で管理され、さらに個別の AWS 認証情報で保護されています。

この複雑さをシンプルにするために、Faire は Cursor のエージェント主導のオンボーディングを活用しています。Cursor が各 repo を調べ、必要なツールチェーンと依存関係を特定し、チームが編集してバージョン管理できる環境設定を生成します。より厳密な制御が必要な workflows では、Faire は Dockerfile を使って開発環境を定義し、管理できます。

Faire のデザイナーは、Figma のデザインシステムをコード内の React コンポーネントに変換する Playground という社内ツールを使っています。開発環境が完全に設定されていれば、Cursor は Playground server を実行し、React コンポーネントを生成し、デザイナーがエージェントの作業を確認できるように動画デモを記録できます。

Faire は Slack を多用する company で、多くの engineering 作業はチャネルでの質問やバグ報告から始まります。エンジニアは Slack の thread から直接 @cursor を呼び出し、会話のコンテキストをクラウドエージェントに引き継いで、調査のうえ PR を返してもらうことがよくあります。

#Cursor Automationsによるプログラム可能なエージェント

Faireでは、並列エージェントを実行するだけでなく、反復的なエンジニアリング業務を自律的にこなしてチームの時間を節約できるエージェントも必要としていました。Faireは25件を超えるCursor Automationsを設定しており、現在では手動でプロンプトを与えることなく、週に2,000件を超える自律的なエージェント実行を行っています。主なユースケースは次のとおりです。

• Slackで報告されたバグのトリアージ。 Automationsは指定されたSlackチャネルでバグ報告を監視します。Issueが入ると、クラウドエージェントが起動して調査を行い、修正を含むPRを作成し、作業内容の概要を共有します。
• PRの自動修復。 PRのCIが失敗すると、自動化が起動し、失敗の原因を調査して修正をpushし、PRを更新します。
• PRのルーティング。 エージェントがすべてのPRに対して、作成者、リスク、サイズに基づくラベルを付け、それぞれに合わせたコードレビューのワークフローへ振り分けます。

#並列化されたエージェントでレガシーなマイグレーションを自動化

Faireでは、小売業者向けの大規模アプリケーションをMobXからReactネイティブの状態管理へ移行する必要があり、チームはCursor上にSwarmというエージェント連携システムを構築しました。

まず、スクレーパーがコードベース内で検出されたMobXの使用箇所をすべて洗い出し、その一覧をS3に書き出します。次にSwarmがその一覧を読み取り、マイグレーションタスクをCursorのクラウドエージェントに割り当てます。各エージェントは、Cursorのインフラストラクチャ上でそれぞれ独立したVM内で実行されます。1つのエージェントが作業を完了してPRをマージすると、Swarmが次のエージェントを起動します。

本来ならチーム全体で18か月かかっていたはずの手作業も、今では1人のエンジニアがクラウドエージェント群を管理しながら進められます。

#1日足らずでビルドプレビューを立ち上げる

Faireのウェブアプリは大規模で複雑なため、ちょっとした変更の挙動を確認するだけでも、アプリ全体をローカルで立ち上げる必要があることがよくあります。プラットフォームチームのシニアエンジニアであるBlair McAlpineは、開発者がPRを作成するとサンドボックスが立ち上がり、チームがその変更をリモートで確認・操作できるプレビューツールを構築したいと考えていました。

McAlpineはCursorを使って、ビルドの計画から実行まで進めました。まずプランモードで開始し、各ステップをそれぞれ別のPRとして切り出しながら、段階的な実行計画を練り上げていきました。次に、その計画をクラウドエージェントに渡しました。エージェントは2時間稼働し、計画の各ステップを実装する5つの積み上げPRを作成しました。

McAlpineが数週間かかると見込んでいた作業は、クラウドエージェントによって1日足らずで完了しました。

Faireは今、次のボトルネックに目を向けています。エンジニアリングのアウトプットが2〜3倍に近づく中、Faireは同じようなレバレッジを活かして、より広い製品開発プロセス全体の勢いをどう生み出せるかを見極めようとしています。「チームがコーディングエージェントからより大きなレバレッジを得るようになるにつれて、制約も移りつつあります」とBjerringは言います。「今の機会は、隣接するチームも同じようにインパクトを拡大できるよう支援することです。そうすることで、既存の体制の中でリソースを再配分し、より意欲的な取り組みにも着手できます。」

---

クラウドエージェントでエンジニアリング速度の並列化を進めたい方は、Cursorのトライアルを始めるためにお問い合わせください。