Scaling Managed Agents: Decoupling the brain from the hands｜マネージドエージェントのスケーリング：思考と実行の分離 | AIニュース最前線

*Claude Managed Agentsの利用を開始するには、[ドキュメント](https://platform.claude.com/docs/en/managed-agents/overview)に従ってください。* エンジニアリングブログで頻繁に扱われるトピックは、[効果的なエージェント](https://www.anthropic.com/engineering/building-effective-agents)の構築方法、[ハarness](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)の設計、そして[長時間実行される作業](https://www.anthropic.com/engineering/harness-design-long-running-apps)に対するハarnessの設計です。これらの取り組みに共通する点は、ハarnessにはClaude単体では実行できないことに関する前提が組み込まれていることです。しかし、モデルの進化に伴い、これらの前提は[陳腐化](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)する可能性があるため、頻繁に見直す必要があります。 一例として、以前の研究では[Claude Sonnet 4.5](https://www.anthropic.com/engineering/harness-design-long-running-apps)がコンテキスト制限に近づくとタスクを prematurely に終了させる傾向があることがわかりました。この行動は「コンテキスト不安（context anxiety）」と呼ばれることもあります。これに対処するため、ハarnessにコンテキストリセットを追加しました。しかし、同じハarnessを[Claude Opus 4.5](https://www.anthropic.com/engineering/harness-design-long-running-apps)で試したところ、その行動は消滅していました。リセット機能はもはや不要な重荷となっていたのです。 ハarnessは今後も進化し続けるでしょう。そこで、Managed Agentsを開発しました。これはClaudeプラットフォーム上のホスト型サービスであり、特定のモデル実装（現在私たちが運用しているものを含む）よりも長寿命となるよう設計された少数のインターフェースを通じて、あなたの代わりに長時間実行されるエージェントを実行します。 Managed Agents の構築とは、計算機科学における古くからの課題を解決することを意味しました。それは「まだ考えられていないプログラム」のためのシステムをどのように設計するかという問題です。数十年ほど前、オペレーティングシステムはハードウェアを「プロセス」や「ファイル」といった抽象化された概念に仮想化する形でこの課題を解決しました。これらの抽象化は、当時存在しなかったプログラムに対しても十分に一般性を持つものでした。その結果、抽象化された層はハードウェアの実装よりも長く存続しました。read() コマンドは、1970年代のディスクパックにアクセスしているのか、現代の SSD にアクセスしているのかに関わりなく動作します。下層の実装が自由に変わっても、その上にある抽象化のインターフェースは安定したまま保たれました。 Managed Agents も同様のパターンに従っています。私たちはエージェントの構成要素を仮想化しました。具体的には、セッション（発生したすべてのことを記録する追記専用ログ）、ハーンネス（Claude を呼び出し、そのツール呼び出しを関連するインフラストラクチャへルーティングするループ）、そしてサンドボックス（Claude がコードを実行しファイル編集を行える実行環境）です。これにより、各構成要素の実装を他方に影響を与えずに差し替えることが可能になります。私たちはこれらのインターフェースの形状については特定の設計思想を持っていますが、その背後で何を実行するかについては指定していません。 ![image](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F903b624ada206b10753a24c6a1367e74a869165d-1080x1080.png&w=3840&q=75) ## ペットを飼わない エージェントの全コンポーネントを単一のコンテナに配置することから始めました。これにより、セッション、エージェント・ハーネス、サンドボックスがすべて同じ環境を共有することになりました。このアプローチには利点があり、ファイル編集が直接のシステムコールで行え、設計すべきサービス境界が存在しませんでした。 しかし、すべてを1つのコンテナに結合したことで、古くからのインフラストラクチャの問題に直面しました。私たちは[ペット](https://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/)を飼うことを選んだのです。ペット対家畜の例えにおいて、ペットは名前が付けられ手厚く管理される個体であり、失うことが許されない存在です。一方、家畜は交換可能です。私たちの場合、サーバーがそのペットとなりました。コンテナが失敗すればセッションは失われ、コンテナが応答しなくなれば、健康を取り戻すために手当てする必要がありました。 コンテナの手当てとは、応答しなくなったセッションのデバッグを意味しました。私たちがアクセスできる唯一の窓口はWebSocketイベント・ストリームでしたが、これでは障害が発生した*場所*を特定できませんでした。その結果、ハーネス内のバグ、イベント・ストリームでのパケット損失、コンテナのオフライン化など、あらゆる問題が同じように見えてしまいました。何が起きたのかを把握するためには、エンジニアがコンテナ内にシェルを開く必要がありましたが、そのコンテナにはしばしばユーザーデータも含まれていたため、このアプローチは実質的にデバッグ能力の欠如を意味しました。 二つ目の問題は、ハースが Claude が作業する対象はそれ自体と同じコンテナ内に存在すると仮定していたことです。顧客が Claude を自身の仮想プライベートクラウド（VPC）に接続するよう依頼した場合、彼らは当社のネットワークとピアリングを行うか、または当社製ハースを自身の環境内で実行する必要がありました。このハースに組み込まれていた仮定は、異なるインフラストラクチャと接続しようとした際に問題となりました。 私たちが辿り着いた解決策は、「脳」（Claude およびそのハース）を「手」（アクションを実行するサンドボックスやツール）および「セッション」（セッションイベントのログ）から切り離すことでした。それぞれが他者についてほとんど仮定を持たないインターフェースとなり、それぞれが独立して失敗したり置き換えたりできるようになりました。 **ハースはコンテナから離れる。** 脳を手に切り離すということは、ハースがもはやコンテナ内に存在しないことを意味しました。ハースは他のあらゆるツールを呼び出すのと同じ方法でコンテナを呼び出しました：execute(name, input) → string。コンテナは家畜（cattle）となりました。コンテナが死滅した場合、ハースはその失敗をツール呼び出しエラーとして捕捉し、Claude に返します。Claude が再試行することを決定した場合、新しいコンテナを標準レシピで初期化できます：provision({resources})。もはや失敗したコンテナの回復に手間取る必要はありません。 **ハーネスの失敗からの回復。** ハーネスは家畜にもなりました。セッションログはハーネスの外側に位置するため、ハーネス内の何かがクラッシュから生存する必要はありません。1つが失敗した場合、wake(sessionId)で新しいものを再起動し、getSession(id)を使用してイベントログを取得し、最後のイベントから再開できます。エージェントループの間、ハーネスはemitEvent(id, event)を使用してセッションに書き込み、イベントの永続的な記録を維持します。 ![image](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F73e900af5b9d6ed8c64db0a8e74d4465963556b7-1640x1596.png&w=3840&q=75) **セキュリティ境界。** 結合された設計では、Claudeが生成した信頼できないコードは、資格情報と同じコンテナ内で実行されていました。つまり、プロンプトインジェクションはClaudeに自身の環境を読み取るよう説得するだけでよかったのです。攻撃者がこれらのトークンを取得すると、新鮮で制限のないセッションを生成し、それらに作業を委任できます。スコーピングの縮小は明白な緩和策ですが、これはClaudeが制限されたトークンで何ができないかという仮定をエンコードするものであり、Claudeはますます賢くなっています。構造的な修正は、トークンがClaudeの生成コードが実行されるサンドボックスから決して到達できないようにすることでした。 これを実現するために、私たちは2つのパターンを使用しました。認証情報はリソースにバンドルするか、サンドボックス外の Vaults に保持します。Git の場合、各リポジトリのアクセストークンを使用してサンドボックス初期化時にリポジトリをクローンし、ローカルの git リモートに接続します。Git の push および pull はサンドボックス内から実行可能であり、エージェントがトークンを直接扱う必要はありません。カスタムツールについては、MCP（Model Context Protocol）をサポートし、OAuth トークンを安全な Vault に保存します。Claude は専用プロキシを介して MCP ツールを呼び出します。このプロキシはセッションに関連付けられたトークンを受け取り、Vault から対応する認証情報を取得して外部サービスへの呼び出しを行います。ハネス（harness）は、いかなる認証情報についても認識されません。 ## セッションは Claude のコンテキストウィンドウではない 長期のタスクは、しばしば Claude のコンテキストウィンドウの長さを超えます。これを解決する標準的な手法はすべて、何を保持するかという不可逆的な決定を伴います。私たちは、コンテキストエンジニアリングに関する[過去の研究](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)でこれらの手法を探ってきました。例えば、コンパクション（compaction）により Claude は自身のコンテキストウィンドウの要約を保存でき、メモリツール（memory tool）によりファイルへのコンテキスト書き込みが可能になり、セッションを跨いだ学習を実現します。これには、古いツール結果や思考ブロック（thinking blocks）などのトークンを選択的に削除するコンテキストトリミング（context trimming）を組み合わせることができます。 しかし、コンテキストを部分的に保持または破棄するという不可逆的な決定は失敗につながりかねません。将来のターンでどのトークンが必要になるかは、知る由もありません。メッセージが圧縮ステップによって変換される場合、ハネスはコンテキストウィンドウから圧縮されたメッセージを削除しますが、これらは保存されていない限り復元できません。先行研究では、コンテキストをコンテキストウィンドウの「外側」に存在するオブジェクトとして保存することでこの問題を解決する方法が探られてきました[1]。例えば、コンテキストは REPL 内のオブジェクトであり、LLM がそれをフィルタリングまたはスライスするコードを書くことでプログラム的にアクセスできます。 ![image](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2Fcf0719d7832b1f577b7393c84a7c53eecc725ca4-760x200.png&w=1920&q=75) Managed Agents では、セッションが同じ恩恵を提供します。これは Claude のコンテキストウィンドウの「外側」に存在するコンテキストオブジェクトとして機能します。ただし、サンドボックスや REPL 内に保存されるのではなく、コンテキストはセッションログに永続的に保存されます。getEvents() というインターフェースにより、脳（エージェントの意思決定部分）はイベントストリームの位置指定スライスを選択することでコンテキストを照会できます。このインターフェースは柔軟に使用でき、脳が最後に読み込みを停止した場所から再開したり、特定の瞬間の前に数イベントを巻き戻して前歴を確認したり、または特定のアクション前にコンテキストを読み直したりすることが可能です。 取得されたイベントは、Claudeのコンテキストウィンドウに渡される前に、ハース内で変換することもできます。これらの変換は、ハースがエンコードするものであれば何でもよく、プロンプトキャッシュのヒット率を高めるためのコンテキスト整理や、コンテキストエンジニアリングを含みます。将来のモデルでどのような特定のコンテキストエンジニアリングが必要になるか予測できないため、セッション内の回復可能なコンテキストストレージとハース内での任意のコンテキスト管理という関心を分離しました。インターフェースは、そのコンテキスト管理をハース側に押し付け、セッションが永続的であり照会可能であることを保証するだけです。 ## 多くの脳、多くの手足 **多くの脳。** 脳と手足の分離は、私たちの初期顧客からの苦情の一つを解決しました。チームがClaudeに自身のVPC内のリソースに対して作業させたい場合、ハースを保持するコンテナがすべてのリソースがその隣にあると仮定していたため、ネットワークをピアリングする以外に方法がありませんでした。ハースがコンテナから外れたことで、この仮定は不要になりました。同じ変更にはパフォーマンス上の利点もありました。当初、脳をコンテナ内に配置していたため、多くの脳にはそれだけ多くのコンテナが必要でした。各脳について、そのコンテナがプロビジョニングされるまで推論は行われず、すべてのセッションがコンセットのセットアップコストを前払いする必要がありました。サンドボックスに触れることのないセッションでさえ、リポジトリのクローンを作成し、プロセスを起動し、サーバーから保留中のイベントを取得する必要がありました。 この待機時間は、最初のトークンまでの時間（TTFT: Time To First Token）として表されます。これは、セッションが作業を受け取ってから最初の応答トークンを生成するまでに要する時間を計測する指標です。TTFT は、ユーザーが最も強く「体感」するレイテンシ（遅延）です。 「脳」と「手」を分離するとは、コンテナが「脳」によってツール呼び出し（execute(name, input) → string）を通じて、必要とされた場合にのみプロビジョニングされることを意味します。つまり、直ちにコンテナを必要としないセッションは、コンテナの準備を待つ必要がありませんでした。オーケストレーション層がセッションログから保留中のイベントを取得し次第、推論（inference）を開始できました。このアーキテクチャを採用した結果、p50 の TTFT は約 60% 短縮され、p95 では 90% 以上削減されました。複数の「脳」にスケールさせることは、ステートレスなハーンス（harnesses）を多数起動し、必要に応じてそれらを「手」に接続するだけのことでした。 **多数の「手」。 **私たちはまた、各「脳」を複数の「手」に接続する機能も欲しました。実務的には、これは Claude が多くの実行環境について推論し、作業をどこに送信するかを決定する必要があることを意味します。これは単一のシェル内で操作するよりも、はるかに高度な認知タスクです。当初は単一のコンテナ内に「脳」を配置していましたが、これは以前のモデルがこれに対応できなかったためです。知能がスケールするにつれて、単一のコンテナ自体が制限要因となりました：そのコンテナが失敗した場合、「脳」がアクセスしていたすべての「手」に関する状態を失うことになったからです。 脳と手足を分離することで、各「手足」はツールとなります。`execute(name, input) → string`というインターフェースでは、名前と入力が渡され、文字列が返されます。このインターフェースは、カスタムツール、任意のMCPサーバー、そして私たちの独自のツールのいずれもサポートします。ハarness（実行環境）は、サンドボックスがコンテナなのか、スマートフォンなのか、ポケモンのエミュレーターなのかを知りません。さらに、どの「手足」も特定の「脳」に結合されていないため、「脳」同士で「手足」を渡し合うことができます。 ![image](https://www.anthropic.com/_next/image?url=https%3A%2F%2Fwww-cdn.anthropic.com%2Fimages%2F4zrzovbb%2Fwebsite%2F4f67b1c10566552aec514a716ea43544ab330e0b-668x243.png&w=1920&q=75) ## 結論 私たちが直面した課題は古くからのものです：「まだ考えられていないプログラム」のためのシステムをどのように設計するかという問題です。オペレーティングシステムは、存在しなかったプログラムに対しても十分一般的な抽象化へとハードウェアを仮想化することで、数十年にわたって存続してきました。Managed Agentsにおいても、私たちはClaudeの周囲にある将来のハarness、サンドボックス、その他のコンポーネントを受け入れるシステムを設計することを目指しました。 Managed Agentsは、Claudeが将来必要とする*特定の*harnessについて特定の立場を取らない点で、同じ精神に基づくメタハarnessです。むしろそれは、多くの異なるharnessを可能にする一般的なインターフェースを持つシステムです。例えば、Claude Codeは広範なタスクで広く使用されている優れたharnessです。また、私たちはタスク固有のエージェントハarnessが狭いドメインにおいて卓越していることも示しました。Managed Agentsはこれらすべてに対応可能であり、時間とともにClaudeの知能とマッチングしていきます。 メタハーネスの設計とは、Claude 周辺のインターフェースに対して明確な方針を持つことを意味します。つまり、Claude が状態（セッション）を操作し、計算（サンドボックス）を実行する能力を持つ必要があると想定しています。さらに、Claude が多数の「脳」と多数の「手」をスケーリングする能力も必要になると予想しています。これらのインターフェースは、長期にわたって信頼性高くかつ安全に実行できるように設計されています。ただし、Claude が必要とする「脳」や「手」の数や場所については一切仮定していません。 ## 謝辞 Lance Martin、Gabe Cemaj、Michael Cohen によって執筆されました。これらのトピックに関する有益な議論をいただいた Nodir Turakulov と Jeremy Fox に感謝します。Agents API チームと Jake Eaton の貢献に特に謝意を表します。

マネージドエージェントのスケーリング：思考と実行の分離

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト