原典: The evolution of agentic surfaces: building with Claude Managed Agents
一行要約
harness を自前で持つことの重荷を、API → Agent SDK → Managed Agents という変遷で説明する。中心にある設計判断は 「脳（harness）と手（サンドボックス）を分離する」 ことで、その1つの選択が認証情報の安全・遅延・再開性の3つに同時に効いている。
要点
何が prototype と production を分けるか
infrastructure is what separates a prototype from a production agent. All too often, teams burn development cycles on security, state management, permissioning, and harness tuning.
prototype と production のエージェントを分けるのはインフラである。往々にして、チームはセキュリティ・状態管理・権限付与・harness チューニングに開発工数を燃やす。
production で詰まる6点が列挙される。ホスティングとスケール（数時間のタスクでプロセスをどれだけ生かせるか）、セッション管理（中断を跨いで再開できるか、過去を検査できるか）、ファイルシステム（成果物を作る作業場はどこか、実行間でそれはどうなるか）、実行の隔離（間違ったときの爆心地の範囲）、認証情報（生成したコードに社外秘を晒さずにどうアクセスを与えるか）、可観測性（1時間自律で動いて驚くことをしたとき、全手順を再構成できるか）。
問題の根にある1つのアーキテクチャ選択
Several of these hurdles stem from a common architectural choice: agent harnesses often run inside the same container as the filesystem it works on. A container has to spin up (paying a startup cost) before Claude can think, the agent along with code execution lives right next to your credentials, and when the container dies, the run dies with it.
これらの障害のいくつかは共通のアーキテクチャ選択に由来する。agent harness は、それが作業するファイルシステムと同じコンテナの中で動くことが多い。Claude が考え始める前にコンテナが起動しなければならず（起動コストを払う）、エージェントとコード実行はあなたの認証情報のすぐ隣に置かれ、コンテナが死ねば実行も一緒に死ぬ。
Managed Agents solves these problems by decoupling the brain from the hands. The harness that calls Claude runs separately from the sandbox where code executes, and the session–an append-only log of every model call, tool call, and result–connects the two.
Managed Agents は脳と手を分離することでこれらを解く。Claude を呼ぶ harness は、コードが実行されるサンドボックスとは別に動き、セッション —— すべてのモデル呼び出し・ツール呼び出し・結果の追記専用ログ —— が両者を繋ぐ。
この1つの分離から3つの帰結が出る。Claude はコンテナが存在する前に推論を始められる、サンドボックスは認証情報から遠く離れている、実行全体をセッションからいつでも再構成できる。
3つの資源
| 資源 | 何か |
|---|---|
| agent | 設定。モデル・プロンプト・ツール群・その周りのガードレール |
| environment | 実行文脈。サンドボックスコンテナ、ネットワーク規則、事前導入パッケージ。Anthropic のクラウドか自前のインフラ上 |
| session | 1回の実行。agent と environment を組み、専用の隔離サンドボックスを得る。イベント履歴・サンドボックス状態・出力をサーバ側に永続化 |
agent と environment を一度定義すれば、同じ設定に対して多数の session を走らせられる。
なぜ harness を自前で持たないのか
harnessing-claudes-intelligence と同じ context anxiety の逸話が、こちらでは「だから harness を持つな」の論拠として使われている。
When the harness doesn’t evolve alongside model intelligence, the agent breaks down. On Claude Sonnet 4.5, an agent would rush to finish as it neared the end of its context, cutting work short rather than using the room it had left—a pattern called “context anxiety.” Our fix was to add context resets to the harness, baking in an assumption that Claude needed help staying coherent near the limit. That assumption didn’t survive the next model. On Claude Opus 4.5, the behavior was gone, and the resets we’d added were just overhead.
harness がモデルの知能と並んで進化しないと、エージェントは壊れる。 Claude Sonnet 4.5 では、エージェントは context の終わりが近づくと残った余地を使わずに切り上げようと急いだ ——「context 不安」と呼ばれるパターンだ。我々の対処は harness に context リセットを足すことで、上限付近で Claude が一貫性を保つのに助けが要るという前提を焼き込んだ。その前提は次のモデルを生き延びなかった。 Claude Opus 4.5 ではその挙動は消えており、足したリセットは単なるオーバーヘッドだった。
For most organizations, maintaining a harness is overhead that doesn’t differentiate their product.
ほとんどの組織にとって、harness の保守は製品を差別化しないオーバーヘッドである。
差別化すべき場所も名指しされている ——「context 管理とドメインの専門性」。
分離が生む4つの利点（実測値つき）
1. 認証情報がサンドボックスの外に出る。
When everything runs in one container, the code Claude generates sits right next to your credentials, so prompt injections could lead the model to leak a token by convincing the model to read its own environment.
すべてが1つのコンテナで動くと、Claude が生成したコードはあなたの認証情報のすぐ隣に置かれる。だから prompt injection は、自分の環境を読むようモデルを説得することでトークンを漏らさせうる。
対処として、MCP / CLI / GitHub リポジトリ向けのトークンは別の vault に置き、プロキシが必要時にだけ取得・復号する。保存前に envelope encryption で保護し、取り出しには署名付きリクエストトークンの検証を要する。
2. サンドボックス起動を待たない分の遅延削減。 ツールを一度も使わないセッションはコンテナを完全に飛ばす。
In our testing, that cut the time-to-first-token by roughly 60% in the median case (p50) and by over 90% in the slowest cases (p95).
我々のテストでは、それが time-to-first-token を中央値（p50）で約 60%、最も遅い場合（p95）で 90% 超削減した。
3. セッションが永続する。 要求/応答ではなくイベントで考える。エージェントを動かしているプロセスの外側にあるログへ、すべてが追記される。だから保存点や DB を管理せずに任意のセッションを再開でき、アイドルになればコンテナがチェックポイントされる。可観測性とメモリはこの構造の副産物として付いてくる。Dreaming はセッションとメモリを定期的に見直してパターンを抽出し、繰り返す誤りやユーザーの好みから改善する。
4. 手はどこにでも置ける。 脳と手が分離されているので、サンドボックスを自社の VPC 内に置ける（self-hosted sandbox）。加えて MCP tunnel でプライベートネットワーク内の MCP サーバへ繋げる。原典はこの2つの役割分担を明示している —— self-hosted sandbox は「エージェントのコードがどこで実行されるか」を制御し、MCP tunnel は「Anthropic があなたのネットワーク内の MCP サーバへどう到達するか」を制御する。
変遷の整理
| 何を自分で持つか | |
|---|---|
| API | ループ・ツール実行・インフラの全部。「tokens in, tokens out」 |
| Claude Agent SDK | Claude Code と同じ harness 機構を借りる。ファイルシステム・セッション永続・OpenTelemetry での可観測性が付く |
| Managed Agents | harness とインフラを Anthropic が運用。利用者はタスク・ツール・ガードレールを定義する |
全面的なカスタマイズが要るエージェントには API 直の方が理に適うと原典自身が書いている。Managed Agents が向くのは「予測可能で複雑度の低いエージェント的ワークロード」。
そのまま使える具体例
境界の引き方（何がどこに残るかを決める2つのつまみ）:
| つまみ | 決めるもの |
|---|---|
| self-hosted sandbox | エージェントのコードが「どこで実行されるか」 |
| MCP tunnel | Anthropic がプライベートネットワーク内の MCP へ「どう到達するか」 |
原典で言及されている関連文書
- managed-agents — Engineering 側の設計解説（brain / hands / session の分離）
- harnessing-claudes-intelligence — 同じ context anxiety の逸話を「何をやめられるか」の側から使っている
- mcp — MCP サーバ
- new-in-claude-managed-agents — dreaming / outcomes / multiagent orchestration