Anthropicが公開したManaged Agents設計に見る、エージェントの長時間タスク・状態消失・context超過の解決策

Anthropicが最近エンジニアリングブログで、Agentの基盤アーキテクチャをどのように再設計したかを公開した。一見するとインフラストラクチャの記事だが、その背景にある設計思想は注目に値する。

モデルへのパッチは、進化とともに無意味なコードになる

Agent開発に携わったことがあるなら、こんな経験があるはずだ。モデルがある特定の問題を起こすので、フレームワークレベルでロジックを追加して回避する。問題は解決したが、そのロジックはずっとコードベースに残り続ける。

Anthropic自身も同じ問題に直面した。Claude Sonnet 4.5がcontextの上限に近づくと、タスクを途中で諦めてしまう現象を発見した。まるで「もう時間がないから急いでまとめよう」という挙動だ。彼らはこれを**context anxiety（コンテキスト不安）**と呼んだ。解決策として、harnessにcontext resetのロジックを組み込み、一定間隔でリセットする仕組みを入れた。

ところが、同じharnessをClaude Opus 4.5で動かしたところ、この振る舞いは消えていた。モデルの能力が向上したことでcontext anxietyが発生しなくなり、あのresetロジックは意味のないデッドコードと化したのだ。

この例が示すのは、より一般的な問題である。アーキテクチャ内のあらゆる設計判断は、本質的に「モデルに何ができないか」という仮説に過ぎない。モデルは進化し、仮説は陳腐化するが、コードは自動的には無効化されない。

Anthropicの対応方針はこうだ。パッチを貼り続けるのではなく、アーキテクチャを再設計し、どの世代のモデルの変更にも耐えられるほど安定したインターフェースを提供する。それが今回公開されたManaged Agentsである。

すべてを1つのコンテナに詰め込むのは、いずれ返済すべき負債

Anthropicの初期実装は素朴なものだった。Agentの実行に必要なものすべて──スケジューリングロジック、実行環境、会話記録──を1つのコンテナに詰め込んだ。利点はシンプルさで、ファイルの読み書きはシステムコールで完結し、サービス間通信は不要だった。

問題は、このコンテナに責務が集中しすぎて「動かせない個体」になってしまったことだ。コンテナがクラッシュすると、セッション全体が失われ、復元する方法がない。コンテナがハングした場合、エンジニアは中に入って手動で調査するしかないが、コンテナ内にはユーザーデータも同時に存在しているため、デバッグは煩雑かつセキュリティリスクを伴う作業になる。

さらに根本的な問題として、この設計では「Claudeの実行環境はharnessと同じ場所になければならない」という仮説がアーキテクチャにハードコードされていた。企業顧客が自社のプライベートクラウドにあるリソースにClaudeを接続したい場合、選択肢は自社ネットワークとAnthropicのネットワークを直接接続するか、harness全体を自社でデプロイするかの二択になる。暗黙の仮説が、スケーラビリティの障害となっていたのだ。

脳と手を分離する

解決策は、3つのパートに分離することだ。

• Brain（脳）：Claude本体と、それをスケジューリングするharness
• Hands（手）：具体的な操作を実行するサンドボックス環境（コード実行、ファイル操作など）
• Session（セッション）：このAgentセッションで発生したすべてのイベントログ

3者の間はシンプルなインターフェースで通信する。Handsが外部に公開するインターフェースはexecute(name, input) → stringのみ。BrainはHandsがコンテナなのか、スマートフォンなのか、それとも別の何かなのかを知る必要がない。指示とパラメータを渡し、結果を受け取るだけだ。

この分離には2つの直接的なメリットがある。

1. 信頼性の向上

サンドボックスコンテナが落ちても、harnessはツール呼び出しのエラーを受け取るだけだ。リトライするかどうか判断し、新しいコンテナを起続行できる。Sessionログは外部に保存されているため、harness自体がクラッシュしても問題ない──新しいharnessを起動し、sessionログを読み込めば、前回の中断地点から状態を一切失わずに再開できる。各コンポーネントが独立して失敗し、独立して再起動できる。

2. パフォーマンスの向上

従来の設計では、各Agentセッション開始時にまずコンテナを立ち上げてから推理を開始する必要があった。しかし、コンテナがオンデマンドで起動するようになると、セッションが一時的にコード実行を必要としない場合はコンテナを待つ必要がなくなる。harnessがsessionログを取得した時点で、推理をすぐに開始できる。この変更により、初トークン遅延のp50が約60%、p95は90%以上短縮された。

認証情報とコードを同じ場所に置いてはいけない

この部分は少し詳しく説明する。涉及するセキュリティロジックは、一見では分かりにくいからだ。

従来の結合された設計では、Claudeが生成したコードと各種APIトークン、アクセス認証情報はすべて同じコンテナ内に存在していた。つまり、Claudeがプロンプトインジェクション攻撃を受けた場合──たとえば悪意のあるコンテンツに誘導されて環境変数を読み取るコードを実行した場合──攻撃者はコンテナ内のすべてのトークンを入手し、それを使って制御不能なリクエストを発行できる。

新しいアーキテクチャの構造的な解決策は、サンドボックスで実行されるコードが物理的にいかなる認証情報にもアクセスできないようにすることだ。

Gitを例に説明しよう。Claudeはコードのpushとpullができる必要があるが、そのためのトークン自体を「知る」必要はない。Anthropicの方法はこうだ：サンドボックスの初期化段階で、リポジトリのアクセストークンを使ってcloneを実行し、トークンをローカルgitのremote設定に組み込む。その後、Claudeがサンドボックス内でgit pushやgit pullを実行すると、gitツールが自分で認証処理を行い、Claudeが生成したコードはトークンそのものに一切触れない。これが「トークンをワイヤリングする」という意味だ。トークンは初期化の段階でツール設定に埋め込まれ、実行環境の変数として露出することはない。

他の外部サービスについては、AnthropicはMCPプロキシ方式を採用している。OAuthトークンはharness外部のセキュアなvaultに保存され、Claudeが外部ツールを呼び出す際はリクエストがまずプロキシに届く。プロキシはセッション識別子に対応する認証情報をvaultから取得し、外部サービスに転送する。Claudeのサンドボックス環境にもharnessにも、これらの認証情報は保持されない。

結果として、たとえサンドボックス内のコードが乗っ取られても、攻撃者は何も持ち出せない。セキュリティ保証は「モデルが騙されないことを信じる」のではなく、構造的な分離によって実現されている。

Sessionはイベントログであり、context windowのコピーではない

Agentが長時間タスクを処理する際、contextの長さ上限にすぐぶつかる。一般的な対処法はcompaction──モデルに現在のcontextを要約させ、摘要で元の内容を置き換えてスペースを確保する。問題は、これが不可逆な操作だということだ。元の情報は一度圧縮されると取り戻せず、後続のステップでどの詳細が必要になるかも事前に判断しにくい。

Managed Agentsのsession設計は、この問題を根本から解決する。sessionは外部に完全に保存されたイベントの連なりであり、context windowはそのイベント連なりに対する1つのビューに過ぎない。

具体的には、harnessはgetEvents()を呼び出してsessionの任意の位置からイベントのスライスを取得し、どの内容をClaudeのcontext windowに入れるかを判断できる。直近のN件のイベントだけ取得することも、ある重要な決定の前のコンテキストを再読み込みすることも、特定のアクションの前に数件多く参照することもできる。

従来のcompactionとの本質的な違いは、context window内のコンテンツに対する操作が可逆であるということだ。圧縮、切り取り、再構成はすべてharnessが「ビュー」レベルで行う選択であり、元データは常にsessionに完全に保存されている。問題があれば遡及でき、将来context管理戦略を変えてもデータの移行は不要だ。

インターフェースは安定し、実装はいつでも交換可能に

Anthropicは、この設計の目標を説明するためにオペレーティングシステムのアナロジーを用いている。Unixのread()システムコールは、1970年代のディスク時代から今日のNVMeに至るまで、インターフェースは一度も変わっていない。変わったのは下位の実装だけだ。アプリケーションはストレージメディアが何であるかを気にする必要がない。

Managed Agentsが目指すのも同じことだ。Session、harness、sandboxの3つの抽象化についてインターフェースを定義してしまえば、裏側で動く実装はいつでも置き換え可能になる。Claude Codeも1つのharnessに過ぎず、タスク特化型のharnessも接続できるし、まだ存在していない将来のharnessも同様だ。アーキテクチャは特定の実装に賭けず、インターフェースの形にのみ賭ける。

Agentアプリケーション開発者への示唆

Agentアプリケーションの開発者にとって、この設計思想から得られる示唆は非常に明確だ。現在のモデル能力へのworkaroundをアーキテクチャに書き込まないこと。その代わり、定期的に自問するのだ。自分の設計判断のうち、どれが本質的にモデルの限界に対する仮説なのか、そしてその仮説は現在もまだ成立しているのか、と。