2026年4月9日、Anthropicの公式アカウント@claudeaiがClaude Managed Agentsのパブリックベータ開始を発表した。投稿は37,000いいね・9,178,000表示・33,000ブックマークを記録。
「Introducing Claude Managed Agents: everything you need to build and deploy agents at scale. It pairs an agent harness tuned for performance with production infrastructure, so you can go from prototype to launch in days.」
AIエージェントの構築からデプロイまでの「本番化のギャップ」を埋めるサービスだ。エージェントハーネス(推論ループ)とインフラ(サンドボックス、セッション管理、セキュリティ)がセットで提供される。
Managed Agentsの設計思想は3つの仮想化されたコンポーネントの分離にある。OSの設計原則——「まだ考えられていないプログラムのために安定したインターフェースを作る」——に倣っている。
| コンポーネント | 役割 | 特徴 |
|---|---|---|
| Brain | Claudeの推論ループ(ハーネス) | コンテナの外で稼働。推論とサンドボックスが独立 |
| Hands | サンドボックスとツール群 | execute(name, input) → string の統一インターフェース。使い捨て(cattle) |
| Session | append-onlyイベントログ | 全アクティビティを永続記録。ハーネス障害時の復旧に使用 |
従来のエージェント実装では、ハーネスがコンテナ内部で動作し、コンテナの障害がハーネスごと巻き込む構造だった。Managed Agentsではハーネスがコンテナの外からexecute()を呼ぶ設計に変更。コンテナは「ペット(大事に管理する)」ではなく「家畜(壊れたら取り替える)」として扱われる。
# 従来: ハーネスがコンテナ内で稼働
container = provision_container()
container.run(harness + tools) # コンテナ死亡 = ハーネスも死亡
# Managed Agents: ハーネスはコンテナの外
harness = HarnessLoop(model="claude-opus-4-6")
result = harness.execute("bash", "npm test") # コンテナ死亡 → 再起動して継続
3層分離がもたらした最大の効果はパフォーマンスだ。
| メトリクス | 改善率 | 理由 |
|---|---|---|
| TTFT p50 | -60% | 推論開始がコンテナ起動を待たない |
| TTFT p95 | -90%超 | コンテナプロビジョニングのテールレイテンシを完全回避 |
| サンドボックス不要セッション | コンテナコストゼロ | 推論のみのセッションはコンテナを起動しない |
従来は推論を開始する前にコンテナのプロビジョニングが完了するのを待つ必要があった。Managed Agentsでは推論が即座に開始し、ツール実行が必要になった時点で初めてコンテナがプロビジョニングされる。サンドボックスを使わないセッション(質問応答、分析、要約等)ではコンテナの起動コストが完全にゼロになる。
Managed Agentsのセッションはappend-onlyのイベントログとして永続化される。これによりハーネスの障害から自動復旧が可能になる。
# ハーネス障害時の復旧フロー
session = wake(session_id) # セッションを再開
events = get_session(session_id) # 全イベントログを取得
last_event = events[-1] # 最後のイベントから再開
emit_event(session_id, next_event) # 新しいイベントを追記
セッションログはClaudeのコンテキストウィンドウの外部に存在する永続的なコンテキストオブジェクトとして機能する。コンテキストウィンドウに何を残すかの不可逆な判断を強いられることなく、過去のイベントを柔軟に参照できる。
Claude Codeの4段階コンテキスト圧縮と同様のアプローチだが、Managed Agentsではセッション自体がファーストクラスのオブジェクトとして管理される点が異なる。
Claudeがコードを生成・実行するサンドボックスに認証情報を渡さない——これがセキュリティの基本方針だ。
2つのパターンが使われる:
# パターン1: リソース初期化時にトークンをバンドル
# Gitトークンは初期化時にサンドボックスに紐付け
sandbox:
git:
token: ${GIT_TOKEN} # 初期化時にのみ注入
# パターン2: 外部Vault + MCPプロキシ経由
# OAuthトークンはVaultに保管、MCPプロキシでアクセス
mcp_proxy:
vault: "aws-secrets-manager"
oauth_tokens:
- provider: "github"
scope: "repo,read:org"
| パターン | 用途 | トークン管理 |
|---|---|---|
| リソースバンドル | Git, SSH等の静的トークン | 初期化時にサンドボックスに注入 |
| Vault + MCPプロキシ | OAuth, API Key等の動的トークン | 外部Vaultに保管、MCP経由でアクセス |
ハーネスも認証情報を直接保持しない。Claude CodeのAuto Modeが7段階のパーミッションパイプラインでツール実行を制御するのと同じ思想だ。
Managed Agentsのアーキテクチャは「多対多」の接続をサポートする。
複数のハーネスが複数の実行環境に接続し、ハーネス間で実行環境を受け渡すことも可能。コード生成エージェントがNode.js環境でコードを書き、テストエージェントに同じ環境を渡してテストを実行する——といったオーケストレーションが実現できる。
OpenHandsやBrowser UseのようなOSSエージェントフレームワークと比較すると、Managed Agentsはインフラ管理を完全にAnthropicに委任できる点が最大の差別化ポイントだ。
Claude Managed Agentsが解決する問題は明確だ。エージェントのプロトタイプは簡単に作れるが、本番運用に持っていくのが難しい。
| 従来の課題 | Managed Agentsの解決策 |
|---|---|
| コンテナ管理・プロビジョニング | 使い捨てサンドボックス、自動復旧 |
| セッション状態の永続化 | append-onlyイベントログ |
| 認証情報の安全な管理 | Vault分離 + MCPプロキシ |
| レイテンシ(コンテナ起動待ち) | TTFT p50で60%削減、推論とコンテナを分離 |
| スケーリング | Claude Platformがフルマネージド |
プロトタイプから本番まで数日。Claude Platformでパブリックベータとして利用可能だ。