はじめに
Cursorが2026年5月21日、クラウドエージェントを1年間構築してきた経験から得た技術的な知見をブログで公開しました。本稿では、開発環境の設計、実行の耐久性、エージェントとマシンの分離、ハーネス設計の変遷、そして自己修復エージェントへの展望という5つのテーマに沿って、その内容を解説します。
参考記事
- タイトル: クラウドエージェント構築から得た学び
- 著者: Josh Ma
- 発行元: Cursor
- 発行日: 2026年5月21日
- URL: https://cursor.com/ja/blog/cloud-agent-lessons
関連記事
要点
- クラウドエージェントの出力品質を左右する最大の要因は、完全な開発環境が用意できているかどうかである
- ワークスティーリングアーキテクチャから Temporal（耐久性のある実行基盤）への移行により、信頼性が9ふたつ超えの水準に達した
- エージェントループ・マシンの状態・会話状態を独立したコンポーネントとして切り離すことで、複数マシンにまたがる柔軟な実行が可能になる
- ハーネスに書いていた制御ロジックをエージェント制御のツール側へ移すことで、より自律的な動作が実現できている
- 今後の方向性は、環境上の問題を自己検知・自己修復できるエージェント基盤の構築である
詳細解説
開発環境こそがプロダクトの品質を決める
Cursorによれば、クラウドエージェントの出力品質を左右する最大の要因は、完全な開発環境を用意できているかどうかだということです。ローカルエージェントでは、手元のノートPC上の開発環境をそのまま引き継げるため、この問題はほとんど意識する必要がありません。一方でクラウドでは、すべてをゼロから再構築する必要があり、しかも「環境が整っていない」ことに気づきにくいという特徴があります。
同社が強調するのは、環境不備の兆候がクラッシュやエラーではなく、出力品質のわずかな低下として現れる点です。原因をモデルのせいだと誤認してしまうリスクがあり、実際には調べるたびに環境設定の不備に行き着くことが多かったと述べています。モデルの性能が向上するほど、環境設定の良否がその能力を引き出せるかどうかを左右する度合いも大きくなると考えられます。
「完全な環境」を実現するためにCursorが作り直してきたインフラには、エージェントVMの効率的な休止・再開、VMイメージのチェックポイントとフォーク、シークレット管理やネットワークポリシーを含むエージェント向けのエンタープライズITなどが含まれます。
耐久性のある実行基盤への移行
クラウドエージェントはローカルと異なり、分離されたVM上で並行して長時間実行されるため、推論プロバイダの障害やノード停止といった中断リスクにさらされます。Cursorは当初、ワークスティーリングアーキテクチャ（複数のワーカーノードがタスクを奪い合って処理する方式）でクラウドエージェントを構築していましたが、この構成は脆弱で、初期ベータ版の信頼性は9ひとつ程度にとどまることもあったといいます。
その後、耐久性のある実行基盤として Temporal（ワークフローオーケストレーションのOSS）を採用しました。Temporalはリトライ、マシン間の作業スケジューリング、ノード障害をまたいだ耐久性といった機能をすでに備えており、自前で再実装する必要がなくなりました。この移行だけで信頼性は9ふたつ超えの水準に達し、現在ではTemporalが 1日あたり5,000万件を超えるアクション を、700万件を超える一意のワークフロー にわたって処理しているとのことです。また、社内PRの40%超がクラウドエージェントによるもので、その割合は増え続けているとCursorは述べています。
Temporalへの移行後も設計は進化しており、バージョンアップを容易にするために「永続的な」長大ワークフローから、単一タスクで完了する短いワークフローへの移行も行われています。
エージェント・マシン・会話状態の分離
クラウドエージェントは、1台のマシン上で1つのループを回すだけではなくなっています。複数マシンにまたがって非同期のサブエージェントを生成したり、ローカルで開始してからクラウドに作業を委ねたりするケースも増えています。こうした複雑な実行形態に対応するために、Cursorは エージェントループ・マシンの状態・会話状態 をそれぞれ独立したコンポーネントとして設計しています。
エージェントループはTemporal上で動作するため、VM自体のライフサイクルとは独立して管理でき、読み取り専用VMや事前にウォームアップされたVMといった最適化も実施できます。会話まわりでは、ストレージ層とストリーミング層をエージェントのワークフローから分離し、追記専用の効率的なストレージ機構を構築しました。これにより、あるステップが部分的な出力をストリーミングした後に失敗して再試行された場合でも、クライアント側で古いデータを新しいデータに差し替えられる仕組みが実現されています。
ハーネス設計：どこまでエージェントに任せるか
クラウドエージェントの開発は、「どこまでを決定論的な挙動にするか、どこからをエージェントに任せるか」を絶えず見直すプロセスでもあります。Cursorの初期は、ハーネス側でタスクのたびに作業を再確認したり、commitとpushを強制したりする制御が多く組み込まれていました。モデルが賢くなるにつれて、そのロジックはハーネスから エージェントが制御するツール側 へと移っています。
たとえばマルチリポジトリ構成では、以前はハーネスにハードコードされた挙動が必要でしたが、現在ではリポジトリのレイアウトとブランチ・PR用ツールを渡せば、作業の進め方はエージェント自身が判断できます。CI Autofixでも同様の変化が起きており、かつてはジョブの失敗ログをVMに書き込むロジックがハーネスに含まれていましたが、今はGitHub CLIへのアクセスを与えるだけにとどまっています。
ただし、コンピュータ操作のようにモデルが単独では扱いきれない領域では、専用のサブエージェント型ハーネス（独自のモデルルーティング、カスタムプロンプト、画面録画を備える）が引き続き機能しています。ハーネス自体がなくなるわけではなく、その中身が変化しているという表現が実態に近いと考えられます。
クラウドエージェントではプロンプトの設計もローカルとは異なり、より自律的な動作を促すようにしているとのことです。「止まってしまうことのコスト」がクラウドでははるかに大きく、確認しに戻るまで何時間も待ち続けるリスクがあるためです。
自己修復するエージェント環境へ
今後の方向性としてCursorが示すのは、エージェントを手取り足取り支援するか完全に任せるかという二択を超えた設計です。シークレットの不足、ネットワークアクセスの遮断など、環境上の要因で作業を進められない状況をエージェント自身が検知・報告し、自己修復的に対処できるようにすることを目指しています。同社はこのアプローチの一例として「autoinstall」と呼ぶ仕組みを研究ブログで紹介しており、今後もこの方向での進化が続くと考えられます。
まとめ
Cursorの1年間の知見は、クラウドエージェントの構築が「ローカルエージェントをサーバーに移植する作業」ではなく、「その周囲の実行基盤を丸ごと設計し直す作業」であることを示しています。環境設計・耐久性・状態分離・自律性のバランスは、今後のエージェント基盤開発において参考になると思います。エージェントハーネス設計の視点については、Cursorの前回記事でも整理していますので、あわせてご覧いただければと思います。
