クラウドエージェント環境を構築した方法
クラウドエージェントが変更をテストできるよう、コンピュータを与えることを決めたとき、まず自社のコードベースで変更を適切にテストできるようにする必要がありました。
モノレポをクラウドエージェントで動作させるなかで、開発環境もそれ自体がプロダクトであり、そのユーザーはエージェントであることを学びました。クラウド環境をローカル開発に合わせ、エージェントが暗黙知に頼らずコードを実行・テストできるようリポジトリを十分に理解しやすくし、コードベースの変化に合わせて環境を健全に維持する必要があります。
この環境を構築したことで、私たちの働き方は変わりました。12月には、CursorのモノレポにマージされたPRのおよそ10件に1件をクラウドエージェントが作成していました。現在では、その半数以上を作成しています。
7-day rolling share of merged PRs from cloud agents
クラウド環境をローカル開発に合わせる
リポジトリでクラウドエージェントを十分に機能させるための最初のステップは、クラウド VM 上でリポジトリが適切に動作するようにすることでした。この段階は、初めてリモート開発環境を設定したエンジニアなら誰もが経験したことがあるはずです。
Cursor の開発者の大半は Mac でローカル開発を行っていますが、クラウド VM は Linux 上で動作します。そのため、さまざまな開発ユーティリティや設定スクリプトを、Ubuntu VM でも動作するように汎用化する必要がありました。クラウドエージェントのベースイメージとなる Cursor 定義の Dockerfile に、重要な開発依存関係を追加しました。
また、ユーザーが必要なシークレットを安心してエージェントの環境に注入できるよう、セキュリティチームと協力してクラウドエージェント製品にセキュリティ機能を追加しました。これらの機能には、ネットワーク送信の制限、スコープを限定しプロキシを介した git リモートアクセス、コミットとコミットメッセージのシークレットスキャン、ツール結果でのシークレットのマスキングが含まれます。これにより、エージェントが試みてもシークレットの値を読み取ることはできません。
エージェント向けのよりシンプルなインターフェース
Ubuntu VMs 上で開発環境を動かせるようになった後も、エージェントは依然としてコードの実行が苦手でした。これは驚くことではありません。開発者体験が煩雑で、多数のビルドコマンド、ビルドフラグ、ユーティリティスクリプトを学び、覚える必要があったからです。
システムのさまざまな部分をビルド・実行する方法についてスキルを作成しましたが、改善はわずかでした。スキルで適切なコマンドを文書化することはできますが、コマンド自体が複雑で、落とし穴だらけだったからです。
この複雑度を下げるため、エージェントがすべてのサービスを起動するために使える anydev という CLI を構築しました。一般的なユーティリティスクリプトも anydev 経由で実行できるようにし、各サブコマンドの使い方を説明する複数の --help メニューを anydev に用意しました。anydev には、長時間実行されるビルドコマンドを監視・再起動するスーパーバイザープロセスもあり、その責任をモデルから完全に取り除いています。
anydev により開発体験が十分にシンプルになり、エージェントはコードを確実に実行できるようになりました。スキルは使い方の文書化には役立ちましたが、より大きな変化は、エージェントがニッチで複数ステップにわたるビルドコマンドを扱ったり、見えにくい落とし穴を避けたり、長時間実行プロセスを見守ったりする必要がなくなったことでした。
この時点で、それぞれが専用のコンピュータを持つクラウドエージェントは、ローカルエージェントに比べて明確な価値を発揮し始めました。コンピュータ使用、recordScreen ツール、そして動作する開発環境により、エージェントは変更をエンドツーエンドでテストし、その作業の正しさをユーザーに証明できるようになりました。
また、誰かがバグ報告を修正した際には Slack で、変更を含む PR を作成した際には PR 上で、エージェントが記録したデモを共有できるようにもなりました。多くのタスクで、エンジニアはブランチをローカルにチェックアウトすることなく、クラウドエージェントが生成したコードを安心してマージ・デプロイできるようになりました。
自己修復する環境
エージェントを取り巻く環境は常に変化するため、稼働状態を維持するには、実行方法やアクセスできる対象を継続的に更新する必要があります。
障害が発生する不健全な環境を診断・復旧できるよう、Cursor Cloud MCP を構築しました。エージェントループを再構築せずにインターフェースを変更でき、動的に検出可能なツールを利用できるため、MCP を選択しました。クラウドエージェントはこれを使って、自身の環境における設定エラー、ネットワーク送信 ポリシー、変更されたシークレットなどを検査します。これにより、Issueの発生時に診断・修正し、不健全な環境をより早く復旧できます。
Cursor Cloud MCP を導入した上で、定期的に障害を確認し、一時的なエラーと重要なエラーを識別・記憶し、根本原因を分析して、高い確信度で Issue を修正する PR を作成できる Cloud Doctor という自動化を設定しました。
エージェント体験の改善
環境が健全でも、エージェントが変更を検証するために遠回りで不自然な手順を取ることがあります。誤ったスキルを使ったり、VM で回避可能な Issue に遭遇したり、必要以上に時間のかかるワークフローを実行したりする場合があります。
ここでも Cursor Cloud MCP を活用しています。Cloud Doctor エージェントはトレースを検査し、別のエージェントがどこでつまずいたか、どのスキルやコマンドが誤解を招いたか、どのワークフローが恒常的に遅いかを特定します。得られた指摘を基に、Cloud Doctor はスキルを修正したり、パスを簡素化したり、次のエージェントがよりスムーズに作業できるよう環境を変更したりします。
このループにより、エージェント自体の開発者体験も継続的に改善されます。環境が健全で自己修復機能を備えていれば、エージェントは安定して実行され、開発者はより重要な作業をクラウドエージェントに任せられるようになります。
これにより、社内でのクラウドエージェントの導入を拡大でき、現在ではリリースするコードの大半をクラウドエージェントが作成しています。
クラウドエージェントを活用できる環境を整える
クラウドエージェントの生産性は、環境に大きく左右されます。コードベースの準備が整っているかを確認するには、まず次の3つの質問に答えてください。
- エージェントは、開発者と同じツールやデータにアクセスできますか？
- エージェントは、開発者の実際の作業方法を文書化したスキルを見つけられますか？
- エージェントはコアワークフローをテストして検証できますか？
環境の準備についてサポートが必要な場合は、お問い合わせください。
また、詳しくは、Faireがクラウドエージェントによって週次PR処理量を2倍にした事例をご覧ください。
