クラウドエージェント構築から得た教訓（12 分読了）

1 年前にクラウドエージェントを初めて立ち上げた際、それらはローカルエージェントの単純な拡張のように思えました。それから以来、クラウドエージェントの機能は大幅に拡大しました。

クラウドエージェントは今や独自の専用仮想マシン上で実行され、独自の環境、依存関係、ネットワークアクセスを持っています。並列処理が可能で、無人でも動作でき、ラップトップ上のローカルエージェントよりも長いタスクを任せることができます。

これらの機能は、エージェントがあなたのラップトップ上で動作している場合よりも、環境設定、信頼性、オーケストレーションに関する課題をより顕在化させます。

本稿では、クラウドエージェント構築において得た最大の教訓と、なぜこの作業がローカルエージェントをサーバーに移植するものから、その周りにオペレーティングレイヤーを構築するものへと変化しているのかについて共有します。

開発環境こそが製品である

過去 1 年間を通じて、クラウドエージェントの出力品質における最大の要因は、開発者が持つような完全な 開発環境 を確保することであると学びました。

これはローカルではそれほど意識する必要がないことです。なぜなら、ローカルエージェントはラップトップから無料であなたの作業用開発環境を継承するからです。クラウドでは、すべてを一から再構築する必要があり、完璧にできていない場合にそれがどれほど深刻かを判断するのは、意外にも難しいものです。

クラッシュやエラーメッセージの代わりに、出力品質の微妙な低下だけが唯一の兆候となることもよくあります。最初はそれに気づかないか、あるいは気づいてもモデルのせいだと片付けてしまうかもしれません。

しかし、私たちは何度も同じ診断にたどり着きました：クラウドエージェントが作業を実行または検証するために必要な環境を持っていないという問題です。1 年前は、モデル自体が環境をあまり活用できなかったため、この問題はそれほど重要ではありませんでした。しかし、モデルが賢くなるにつれて、環境のセットアップがその潜在能力を最大限に発揮できるかどうかを決定づける要因となっています。

imageimage

今日、"完全な環境"を実現するには、驚くほど多くのインフラストラクチャを再構築する必要があります：

• エージェント環境を構築するためのより優れたユーザーツール
• メッセージ間でエージェント仮想マシン（VM）を効率的に休止および再開する方法
• VM イメージを迅速かつ永続的にチェックポイントし、復元およびフォークするためのパイプライン
• エージェントと人間が両方とも環境を理解して対話できるようにするための、きめ細やかなハーンとクライアントの統合

そして、クラウドエージェントがより多くの作業を引き受けるにつれ、PR の作成、依存関係の取得、調査などのために制御されたネットワークアクセスが必要となります。時間の経過とともに、私たちは本質的にエージェント向けのエンタープライズ IT を構築することになり、機密情報の削除、ネットワークポリシー、認証情報管理まで備えたものとなりました。

長時間実行されるエージェントには永続的な実行環境が必要

クラウドエージェントは、ローカルエージェントとは異なる種類の信頼性の課題を提示します。あなたのラップトップ上でローカルリソースを競合するのではなく、クラウドエージェントは独自の隔離された VM で実行されます。これにより、開発者は多数のエージェントを並列で実行し、しばしば数分ではなく数時間を要する長時間実行タスクを委任することが容易になります。

しかし、VM での実行は、推論プロバイダの障害、ポッドの置き換えが必要になること、EC2 ノードのダウンなど、様々な中断への曝露を生み出します。

私たちは当初、ワーカーノードがエージェントを引き受けて完了までループさせる「ワーク・スチーリング」アーキテクチャでクラウドエージェントの構築を始めました。これはローカルで機能するものをサーバーに移植したものでしたが、脆いセットアップでした——私たちの初期ベータ版のクラウドエージェントは、信頼性が 9 のうち 1 という状態で運用されることがよくありました。

imageimage

クラウドエージェントの成熟に伴い、Temporal がすでに解決している多くの永続的な実行プリミティブ（例：リトライメカニズム、マシン間でのタスクスケジューリング、ノード障害に対する耐久性）を再構築しようとしていることに気づきました。そこで、私たちはそれらを再構築するのではなく、Temporal への移行を選択しました。

imageimage

Temporal 上の現在のエージェントループは、推論の信頼性の瞬間的な低下やポッドの休止・再開、さらには数日甚至いは数週間にわたる実行にも耐えることができます。この移行だけで、私たちは信頼性レベルを「9」が2桁からさらに向上させました。現在、Temporal は700 万を超えるユニークなワークフロー全体で、1 日に5,000 万件以上のアクションを処理しています。社内のプルリクエスト（PR）の40%以上がクラウドエージェントによって作成されており、その割合はさらに増加しています。

imageimage

長年にわたり、Temporal ワークフローのアーキテクチャをより良く構築する方法を学んできました。一度きりのタスク完了後に終了する複数の短いワークフローへと移行し、「永遠に続く」エージェントワークフローから脱却しました。これによりバージョンアップが容易になりました。また、タイムアウトやリトライを非同期ツール呼び出しとしてより正確に捉えるためにアクティビティを分割しました。サブエージェントや推論プロバイダの障害が発生したことで、私たちの基礎的な前提条件も変化しています。

imageimage

会話状態からエージェントとマシンを分離する

クラウドエージェントはもはや単一のマシンで動作する一つのループではありません。代わりに、エージェントは一台のマシン上で実行されたり、複数のマシンに非同期のサブエージェントを生成したり、ローカルで開始して作業をクラウドへ委譲したりします。また、サブエージェントが親プロセスよりも長く存続したり、全く異なる種類のポッド（注：コンテナ実行環境）上で動作することさえあります。

imageimage

その仕組みを機能させるために、エージェントループ、マシン状態、会話状態を独立したコンポーネントとして維持することが有効であると私たちは見出しました。エージェントループは VM 自体ではなく Temporal 内に存在するため、ポッドのライフサイクルを独立して管理し、読み取り専用 VM やプリウォームされた VM といった最適化を含むさまざまな種類のポッド間でエージェントを実行することができます。

会話側においては、ストレージとストリーミング層をコアなエージェントワークフローから分離しました。ウェブおよびデスクトップクライアントへ会話更新情報をストリーミングする効率的なアペンドオンのみストレージメカニズムを構築しました。この層はリトライ処理を担当しており、エージェントループのステップが部分的な出力をストリーミングした後に失敗し、再試行された場合でも、クライアントはそのことを検知してストリームを巻き戻し、古いデータではなく新しいデータを表示することができます。

邪魔にならない方法を学ぶ

imageimage

クラウドエージェントのハネスを構築するということは、どの程度の振る舞いが決定論的であり、どの程度がエージェントに委譲されるかを絶えず再評価することを意味します。

当初、私たちはエージェントをあまり信頼していなかったため、ハルネスは各タスクの後に作業を再確認し、強制的にコミットしてプッシュしていました。モデルが賢くなるにつれて、ロジックをハルネスからエージェントが制御するツールへと移行させ始めました。1 年前は、マルチリポジトリ設定にはハードコードされたハルネス動作が必要でしたが、現在はエージェントにリポジトリのレイアウトを与え、ブランチやプルリクエスト用のツールを公開して、作業方法を自分で判断させることができます。

CI オートフィックスにおいても同様のことが起こりました。以前のバージョンのクラウドエージェントハルネスには、ジョブ失敗ログを取得して VM に書き込むロジックが含まれていましたが、現在はエージェントに GitHub CLI のアクセス権を与え、検索可能なファイルに大規模な出力を自動的に書き込むようにしています。エージェントへの通知は大幅に簡素化され、この傾向は今後も続くものと予想されます。

ハルネスがなくなるというよりは、その中身が変化しているのです。コンピューター操作（Computer use）は現在の良い例です。私たちのクラウドエージェントハルネスには、コンピューター操作専用のサブエージェントタイプがあり、独自のモデルルーティング、カスタムプロンプト、画面録画を備えています。VNC と Chrome は環境に属しており、親エージェントとサブエージェントの間で共有されています。これにより、親エージェントは Playwright スクリプトを実行するなどして、これらのリソースを直接利用できます。この足場（スキャフォールディング）を使用しているのは、モデルがまだ単独でコンピューター操作を処理する準備が整っていないためですが、それでも呼び出しのタイミングはエージェントが制御します。

クラウドエージェントは、ローカルエージェントとは異なる種類のプロンプトをハネスでも必要とします。ブロックされるコストがはるかに高いため、より自律的な行動を促すよう推奨しています。ローカル環境では、エージェントが停止して許可を待っている状態を把握できますが、クラウド上では数時間放置された後に初めて確認に行くという状況も起こり得ます。

自己修復型エージェント環境

将来を見据え、私たちはエージェントの手を握り続けるか、完全に手を引くかの二択を超えたアプローチに注力しています。より良いパターンは、エージェントが周囲のシステムを理解するためのツールを提供することです。

クラウドエージェントには、機密情報が不足している場合やネットワークアクセスがブロックされている場合、あるいは環境自体が進捗を妨げている場合に報告し、その後自己修復的な方法で行動できる能力を持たせたいと考えています。最近の研究ブログ では、これを達成するための一つの道筋として「autoinstall」と呼ぶアプローチについて言及しました。

クラウドエージェントはここ数ヶ月で劇的に改善され、今後その変化の速度がさらに加速すると予想しています。Cursor のクラウドエージェントを利用すれば、チームは裏側のインフラを構築・維持することなく、この広大な機能面を活用できます。