Managed Agentsの設計思想 — セッション/ハーネス/サンドボックスを分離した長時間エージェントのつくり方

Anthropicが2026年4月8日にエンジニアリングブログで公開した「Scaling Managed Agents: Decoupling the brain from the hands」は、長時間エージェント(long-horizon agent)を本番環境で運用するためのインフラ設計を扱った記事です。本稿では、初期実装の何が壁になり、最終的にどのような分離アーキテクチャに落ち着いたのかを、原文の主張を引きながら実務目線で読み解いていきます。

背景 — なぜ「ハーネスとサンドボックスを分ける」必要があったのか

Managed Agentsは、Anthropicが提供するホステッド型のエージェント実行サービスです。1つのタスクを数分から数時間かけて遂行する用途を想定しており、外部から見えるAPIはモデルが進化しても変わらない安定インターフェースであることが設計上の前提に置かれています。

この前提が重要な理由は、ハーネス(harness、エージェントを駆動する実行ループ)がその時点のモデルの限界を前提にコードを書いてしまうからです。原文ではClaude Sonnet 4.5で観測されていた "context anxiety"(コンテキスト不安、文脈ウィンドウが詰まる前に作業を畳もうとする挙動)が例に挙げられ、これはClaude Opus 4.5では解消されたため、回避コードがそのまま無駄になったと説明されています。モデルが直る速度のほうがハーネスを書き直す速度より速いとき、ハーネスはむしろ進化のブレーキになります。

そこでManaged Agentsは、モデルとハーネスを「いつでも置き換え可能な部品」として扱える形に作り直されました。本記事の主題である「brain(脳)とhands(手)を切り離す」というフレーズは、この再設計の中心にあるメタファーです。

「pet」を作ってしまった初期実装の壁

最初のアーキテクチャは、セッション(session)・ハーネス(harness)・サンドボックス(sandbox)の3要素を1つのコンテナに同居させる素直な作りでした。実装はシンプルですが、運用上は次の問題が顕在化します。

• コンテナが落ちるとセッションごと消える(復旧パスがない)
• コンテナが応答停止すると、WebSocketのイベントストリームを目視で追って手作業デバッグするしかない
• 顧客が自社のVPC(Virtual Private Cloud、仮想プライベートクラウド)につなぎたいと言ったとき、ハーネスがコンテナ内にあることを前提にしているのでネットワークpeeringか、ハーネスごと顧客環境にデプロイするしかない

原文ではこの状態を「コンテナがpet(ペット)になってしまった」と表現しています。クラウドインフラの世界でpets vs cattle(ペットvs家畜)は、「個体識別して大事に世話するサーバ」と「壊れたら同型を量産して差し替える資源」を対比させる定番のメタファーで、Managed Agentsの初期実装は前者に陥っていた、という反省です。

長時間タスクを「壊れたら作り直せるcattle」として扱うには、コンテナ単位の状態を最小化し、外側から状態を保持する必要があります。再設計の方針はここから出発しています。

分離後のアーキテクチャ — 3つのinterfaceに切り出す

再設計後のManaged Agentsは、ハーネス・サンドボックス・セッションをそれぞれ独立したinterfaceとして定義し、置き換え可能にしています。原文で示された主要インターフェースを表にまとめます。

ポイントは、ハーネスがコンテナを「自分の体内の一部」ではなく外部ツールとして呼ぶ形に変わったことです。execute(name, input) → string という最小契約に揃えたことで、サンドボックスはコンテナでも、スマートフォンでも、別の実行環境でも構わない、という設計になりました。

ハーネスをstatelessにする

ハーネス自身が状態を持たないことが、再設計のもう一つの軸です。セッションログはハーネスの外側(永続ストア)に出され、ハーネスがクラッシュしても wake(sessionId) で別プロセスから起動 → getSession(id) で履歴取得 → 直前のイベントから再開という流れで戻れます。実行中もハーネスは emitEvent でイベントログを書き出し、いつ落ちても良い状態を維持します。

これはClaude Codeのようなローカル実行ハーネスと違い、サーバ側でセッションを長時間保持するManaged Agents特有の難しさへの解答です。Claude Code本体の仕組みについてはClaude Code完全ガイド2026年版でまとめています。

セキュリティ境界 — 認証情報をサンドボックスに置かない

ハーネスとサンドボックスを分けたことで、副次的に「信頼できないコードに認証情報を渡さない」設計が素直に書けるようになっています。原文では2つの典型パターンが紹介されています。

1. Gitリポジトリへのアクセス: アクセストークンはサンドボックス側のクローン初期化にだけ使い、サンドボックス内部には残さない。push / pullはローカル操作として完結し、認証情報がサンドボックスに露出しない
2. カスタムツール / MCPサーバ: OAuthトークンはサンドボックス外のsecure vault(セキュアな保管庫)に置き、専用プロキシがセッション固有のトークンでvaultから取り出してツール呼び出しを代行する

エージェントが実行するコード自体は信頼できないことを前提に、認証情報を「呼び出し時にだけプロキシ経由で借りる」モデルにしている、と読めます。Claude Codeでも長期運用での認証分離は重要テーマで、設計の方向はClaude Codeセキュリティ運用ガイドと地続きです。

セッションはClaudeのコンテキストウィンドウではない

長時間タスクは、当然ながらモデルのcontext window(文脈ウィンドウ、一度に処理できるトークンの範囲)に収まりません。これまでのアプローチは、要約による圧縮(compaction)・メモリツール・コンテキストの切り詰めなど、いずれも不可逆な操作でした。一度捨てた情報は戻せません。

Managed Agentsはこの問題に対し、セッションをcontext windowの外側に置かれた永続オブジェクトとして再定義しています。原文の主張をそのまま書くと「The session is not Claude's context window」、つまりセッションはClaudeが今読んでいる文脈とは別物だ、ということです。

getEvents() でハーネスはイベント列の任意レンジを切り出せるようになりました。具体的には次のような操作が可能です。

• ある時点までを取り出し、その続きから別の戦略で再実行する
• 特定の瞬間の前まで巻き戻して、当時の文脈を見直す
• 中断箇所からresume(再開)する

ハーネス側は取り出したイベント列に変換をかけてからClaudeのコンテキストに流し込むため、prompt caching(プロンプトキャッシュ)に効きやすい形に整える、といった最適化もハーネス層の責務として独立して管理できます。

既存手法との対比

長時間エージェントで「文脈をどう持つか」は実装ごとに割れている領域です。本稿の独自整理として、主要な戦略を並べると次のように見えます。

Managed Agentsの選択は「重いほうの右端」です。ハーネスをサーバ側で持つホステッド型サービスだからこそ採れる選択肢で、ローカルハーネスにそのまま輸入できる構造ではない点には注意が必要です。

Many brains, many hands — TTFTがp50で約60% 改善した理由

ハーネスがコンテナに縛られない結果、Managed Agentsは 「複数のbrain」「複数のhand」という構成を素直に表現できるようになりました。

Many brains(複数のハーネス)

顧客VPCへの接続は、初期実装ではネットワークpeeringを必須としていました。ハーネスがコンテナの内側にいるためです。再設計後はハーネスがstatelessなプロセスとして任意の場所で起動でき、必要なときだけ手(hand)につなぎに行くため、ネットワーク要件が大幅に緩みます。

副次的な効果として、TTFT(time-to-first-token、最初のトークンが返るまでの時間)が劇的に改善しました。原文で報告されている数字は次のとおりです。

• p50 TTFTが約60% 削減
• p95 TTFTが90% 以上削減

理由はシンプルで、以前は「セッション開始時にコンテナを必ず立てる」コストを全リクエストが払っていたのに対し、再設計後はツール呼び出しが発生したタイミングで初めてコンテナをプロビジョンする流れに変わったためです。すべてのタスクが必ずシェルを叩くわけではない以上、初手の応答までにコンテナ起動を待たせる必要がない、という素直な合理化です。

Many hands(複数のサンドボックス)

モデルの能力が伸びるにつれて、単一のシェル環境だけで作業を完結させるのは窮屈になっていきます。Managed Agentsはこの方向に対し、handを「execute(name, input) → string を満たすツール」として一般化することで応えています。コンテナ・スマホ・社内ツール・MCPサーバ・カスタムツールが、すべて同じ抽象でハーネスから呼べる形です。

原文で強調されているのは「ハーネスはhandの中身に無関心であるべきだ」という点です。コンテナでもスマホでも違いを意識せず、必要に応じて別のbrainにも引き継げる(handがbrainに強く結合していない)。Agent SDKでツールを増やしていく実装パターンとも重なり、Agent SDKクイックスタートで扱った「ツールを足し算で拡張する」設計の延長で読めます。

編集視点 — Managed Agentsは「Claude Codeの対極」と「Coworkの裏側」のどちらに近いか

ここまでの仕様を踏まえると、Managed AgentsはClaude CodeともCoworkとも違うレイヤーの製品だと位置付けられます。本メディアの読者向けに整理した軸を以下に置きます。

つまりManaged Agentsは、Coworkのように完成したUIを提供するわけでも、Claude Codeのように開発者の手元で走るわけでもなく、「自社プロダクトに長時間エージェントを内蔵したい開発者」に対してインフラの面倒をAnthropic側で見ることを売りにした製品、と読むのが自然です。

このとき本記事の設計思想が効いてきます。プロダクトに内蔵する以上、開発者は「モデルが新しくなっても自分のコードを書き直さなくていい」「コンテナが死んでもセッションは生き残る」「自社VPCにつなげる」という保証が欲しいはずで、3要素分離のinterfaceはちょうどそこを抑えに行く設計になっています。

設計から学べるもの — OSの仮想化メタファーをもう一度

原文の結びは、設計哲学をオペレーティングシステムが行ったハードウェアの仮想化に重ねます。OSが「特定のハードウェアに紐づかない、長く使える抽象」を作ったように、Managed Agentsはsession / harness / sandboxを仮想化し、将来の実装にも耐えるinterfaceを残すことを目指している、という整理です。

ここで重要なのは「interfaceには強い意見を持つが、実装には不可知である」という非対称な姿勢です。タスク特化のハーネスも、汎用ハーネスも、同じinterfaceを満たせば共存できる。Anthropicが「ハーネスは置き換え可能でなければならない」と書いているのは、自分たちが書くハーネスでさえ、より良いものに出会ったら捨てる前提を取っている、というメッセージとして読めます。

まとめ

• Managed Agentsの再設計は、コンテナ同居の "pet" 構造から、execute / wake / getEvents といった最小契約で3要素を切り離した分離アーキテクチャへの移行
• ハーネスをstatelessにしたことで、コンテナ障害がセッションを巻き込まなくなり、TTFTもp50で約60% / p95で90% 以上の改善が報告されている
• セッションをcontext windowの外に置く設計は、要約圧縮やtrimと違い、過去のイベントへ巻き戻して再実行する自由度を残す
• 認証情報はサンドボックスに渡さず、外部vaultからプロキシ経由で借りる形に統一されている
• Claude Code(ローカル)・Cowork(業務UI)に対し、Managed Agentsは「自社プロダクトに長時間エージェントを内蔵する開発者」を主読者に置くインフラ層の製品と位置付けられる

執筆はLance Martin・Gabe Cemaj・Michael CohenによるAnthropic Agents APIチームで、Nodir Turakulov・Jeremy Fox・Jake Eatonらの貢献が記されています。料金やベータ条件などのプロダクト面の情報は本記事では公開されておらず、続報を待つ位置づけです。