はじめに
小売向けECプラットフォームを提供するFaireが、Cursorのクラウドエージェントを導入し、週間PR（プルリクエスト）スループットを2倍に向上させた事例を、Cursorが2026年5月26日に公開しました。本稿では、この事例をもとに、クラウドエージェントの並列実行と自動化が開発現場にどのような変化をもたらしているかを解説します。
参考記事
- タイトル: Faire、Cursorクラウドエージェントで週間PRスループットを2倍に
- 著者: Cursor Team
- 発行元: Cursor Blog
- 発行日: 2026年5月26日
- URL: https://cursor.com/ja/blog/faire
関連記事
要点
- FaireはCursorのクラウドエージェントを採用し、週間PRスループットを2倍に改善した
- 本来チーム全体で18か月かかるMobXからReactネイティブ状態管理への移行を、1人のエンジニアがエージェント群を管理して完遂した
- 25件超のCursor Automationsを設定し、週2,000件超の自律的なエージェント実行を手動プロンプトなしに起動している
- Slackでのバグ報告トリアージ・CI自動修復・PRルーティングなど反復的な業務を自動化し、エンジニアの手作業を大幅に削減している
- 当初は社内製クラウドエージェントシステム「Samurai」を自社構築しようとしたが、運用コストの高さからCursorへ移行した
詳細解説
社内ツールからCursorへ——乗り換えを決めた理由
FaireはもともとSamuraiという社内製のクラウドエージェントシステムを自社インフラ上で構築していました。しかし、プリンシパルエンジニアのLuke Bjerring氏は「自前でサーバーを立ち上げるのは大きな投資です。人材の採用、マシンのブートストラップ、複雑なインフラストラクチャの維持が必要になります」と振り返っています。優れた開発者体験を維持しながら社内ツールを運用し続けるコストが課題でした。
Faireが求めていたのは、マネージドインフラとセルフホスト環境の両方に対応したデプロイの柔軟性、GitHubとの緊密な統合、複数エージェントを並行して管理できるインターフェース、そしてローカルとクラウド間のシームレスな引き継ぎです。これらの要件を満たすプラットフォームとしてCursorが選ばれ、現在では社内エージェント型開発の推奨ツールとなっています。
ローカルマシンでの並列実行には限界があります。複数のエージェントが同じ計算資源を取り合い、進行中のタスクを管理すること自体が新たな負担になります。クラウドエージェントはローカルリソースの制約を受けずに動作し、それぞれが独立した開発環境を持てる点で、根本的に異なるアーキテクチャだと言えます。
開発環境との統合がエージェントの自律性を決める
クラウドエージェントが効果を発揮するには、コードを生成するだけでなく、依存関係の取得、社内サービスへのアクセス、コードの実行と変更の検証まで自律して行える環境が必要です。Faireの開発環境は、バックエンドとフロントエンドが別リポジトリで管理され、GradleとBazelが混在し、個別のAWS認証情報も必要な複雑な構成でした。
この複雑さに対応するため、FaireはCursorのエージェント主導オンボーディングを活用しています。Cursorが各リポジトリを調べて必要なツールチェーンと依存関係を特定し、チームが編集・バージョン管理できる環境設定を自動生成します。より厳密な制御が必要なワークフローではDockerfileで環境を定義します。シニアエンジニアのBlair McAlpine氏は「コードベース内のすべてのリポジトリでCursor自身にオンボーディングさせています。これにより新しいセッションを開始するたびのオーバーヘッドが大幅に減り、エージェントがエンジニアと同じようにタスクに取り組めるようになります」と説明しています。
また、FaireのデザイナーはFigmaのデザインシステムをReactコンポーネントに変換する社内ツール「Playground」と連携させており、開発環境が設定された状態でCursorがサーバーを起動してコンポーネントを生成し、動画デモまで記録できる体制が整っています。
Cursor Automationsで反復業務を週2,000件自動処理
Faireでは25件超のCursor Automationsを設定しており、週に2,000件超の自律的なエージェント実行を手動プロンプトなしに行っています。主なユースケースは3つです。
まず、 Slackで報告されたバグのトリアージ です。指定チャネルでバグ報告を監視し、issueが入るとクラウドエージェントが起動して調査・修正PRの作成・概要共有を自動で行います。
次に、 PRの自動修復 です。CIが失敗すると自動化が起動し、失敗原因を調査して修正をpushし、PRを更新します。
3つ目は PRのルーティング で、作成者・リスク・サイズに基づくラベルを付けて適切なレビューワークフローへ振り分けます。
McAlpine氏は「Automationsという考え方自体は以前からありましたが、設定が面倒で複雑でした。Cursor Automationsによって、常時稼働するエージェントを誰でも簡単に立ち上げられるようになりました」と評価しています。Slackのスレッドから直接エージェントを呼び出して数分後にPRが返ってくる体験は、Faireのような Slackを多用する組織 では特に大きな効率改善につながると思います。
18か月の移行作業を1人で完遂した「Swarm」の仕組み
Faireは小売業者向けアプリケーションで使われていたMobXをReactネイティブの状態管理へ移行する必要がありましたが、チーム全体で18か月かかる規模の作業でした。そこでFaireはCursor上に「Swarm」というエージェント連携システムを構築しました。
まずスクレーパーがコードベース内のMobX使用箇所を洗い出してS3（Amazonのクラウドストレージサービス）に書き出します。SwarmがそのリストをもとにCursorのクラウドエージェントへタスクを割り当て、各エージェントは独立したVM（仮想マシン）上で実行されます。1つのエージェントが作業を完了してPRをマージすると次が起動する仕組みです。結果として、大規模な移行作業を1人のエンジニアが管理しながら完遂できました。
Bjerring氏は「Cursorの価値は、優れたコンテキスト管理と、会社全体やコードベースにまたがる有用な独自情報を活用できることにあります。これまで人が何時間もかけていた作業も、今ではエージェントに任せられます」と語っています。
1日足らずでビルドプレビューを構築
FaireのウェブアプリはPRの変更確認にアプリ全体をローカルで起動する必要があるほど大規模でした。McAlpine氏は、PR作成時にサンドボックスが立ち上がりリモートで変更を確認できるビルドプレビューツールを構築したいと考えていました。
Cursorのプランモードで各ステップを別々のPRとして切り出す段階的な実行計画を練り、その計画をクラウドエージェントに渡したところ、エージェントが2時間稼働して5つの積み上げPRを作成しました。McAlpine氏が数週間かかると見込んでいた作業が1日足らずで完了した、とのことです。
まとめ
FaireのCursor活用事例は、クラウドエージェントの並列実行と自動化が開発生産性に与えるインパクトを具体的な数値で示しています。週間PRスループット2倍、18か月分の移行を1人で完遂といった結果は、AIコーディングツールが実用段階に達していることを示す一つの指標と言えます。Cursorのエージェント設計思想についてより詳しく知りたい方は、エージェントハーネスの進化を論じた過去記事もあわせてご覧いただければと思います。
