Managed Agents で「脳と手を分離する」— Anthropic が語るスケーラブルなエージェント設計

Claude Managed Agents — TTFT 短縮と分離設計の勘所

Anthropic の Engineering Blog が「Scaling Managed Agents: Decoupling the Brain from the Hands」を公開しました。Claude の推論(脳)と実行環境(手)を独立したコンポーネントとして仮想化することで、スケーラビリティ・耐障害性・セキュリティを同時に実現する設計思想が詳しく解説されています。本記事ではその要点を、実務エンジニア向けに日本語で整理します。

この記事の要約powered by Claude

Anthropic Engineering Blog が公開した Managed Agents の核心は**「脳(推論担当の Claude + ハーネス)と手(実行環境のサンドボックス)を独立した仮想化レイヤーとして分離する」**設計思想です。

セッション状態をイベントログとして外部化するステートレス設計により、コンテナ障害時でも作業状態を失いません。

この分離によって TTFT(最初のトークンが返るまでの時間)は p50 で約 60%、p95 で 90% 超削減され、Many Hands(実行環境を横にスケール)と Many Brains(推論を横にスケール)の両方向に拡張できます。

モデル改善のたびにハーネスを書き直すコストも大幅に下がります。

目次 (22)

分離設計の勘所 1: なぜ実行環境と推論を分離するのか

ハーネスが「モデルの不足を補う」設計になっていた問題

エージェントを構築する際、開発者は Claude 本体だけでなく、その周囲の ハーネス(実行制御の枠組み全体)を設計する必要があります。 ハーネスにはプロンプト制御、コンテキスト管理、ツール呼び出し、リトライロジックなどが含まれます。

Anthropic はこの設計の根本的な問題を指摘しています。

「ハーネスはモデルができないことに関する前提を埋め込んでいる。しかしモデルが改善されると、その前提は時代遅れになる。」 出典

具体例として、Claude Sonnet 4.5 ではトークン上限近くで「コンテキスト不安(context anxiety)」が発生し、 ハーネス側で回避策を実装していました。ところが Claude Opus 4.5 ではこの問題が解消されており、 ハーネスの回避策が不要になりました出典

モデルに対する前提をハーネスに書き込むほど、モデル改善のたびにハーネス全体を見直す必要が生じます。 これはスケーラビリティ・安全性・コストの三点で持続不可能です。

解決策 — OS 設計の仮想化原則を 3 コンポーネントに適用

Anthropic が採用した解決策は、OS 設計で実績のある 仮想化 の原則です。 OS がプロセスとハードウェアを分離したように、Managed Agents は 3 つのコンポーネントを独立した安定した抽象層 として仮想化しました 出典

分離設計の勘所 2: アーキテクチャは 脳 / 手 / セッション の 3 層

3 コンポーネントの分離 — Brain(推論)/ Hands(実行)/ Session(状態)

本セクションの要点を以下に整理します。

┌─────────────────────────────────────────────────┐
│                 Managed Agents                  │
│                                                 │
│  ┌──────────────┐   ┌──────────────────────┐   │
│  │     脳       │   │         手            │   │
│  │   (Brain)    │   │       (Hands)         │   │
│  │              │   │                       │   │
│  │  Claude      │   │  サンドボックス        │   │
│  │  + ハーネス  │──▶│  (コンテナ)           │   │
│  │              │   │  カスタムツール       │   │
│  │  推論・判断  │   │  MCP サーバー         │   │
│  └──────────────┘   └──────────────────────┘   │
│          │                    │                 │
│          └────────┬───────────┘                 │
│                   │                             │
│          ┌────────▼───────┐                     │
│          │    セッション   │                     │
│          │   (Session)    │                     │
│          │                │                     │
│          │ 永続イベントログ │                     │
│          └────────────────┘                     │
└─────────────────────────────────────────────────┘

出典: Anthropic Engineering: Scaling Managed Agents をもとに構成図を作成

コンポーネント 役割 技術的実体
脳(Brain) 推論・計画・意思決定 Claude + ハーネスロジック
手(Hands) 実行・副作用・I/O コンテナ、ツール、MCP サーバー
セッション(Session) 状態の永続化 耐久性のあるイベントログ

ハーネスの位置が変わった — コンテナ外に分離、execute(name, input) で透過接続

従来の設計では、Claude・ハーネス・サンドボックスがすべて単一コンテナ内に同居していました。 Managed Agents では ハーネスをコンテナ外に移動 し、 execute() インターフェース経由でサンドボックスと通信する構造にしました 出典

手のインターフェースはシンプルに統一されています。

execute(name, input) → string

このインターフェースを実装すれば、コンテナ・カスタムツール・MCP サーバー・Anthropic 提供ツールの どれでも「手」として透過的に扱えます出典

セッションによるコンテキスト外部化 — 圧縮なしの耐久ログで巻き戻し可能

セッションは「コンテキストウィンドウの外に存在するコンテキストオブジェクト」として機能します 出典getEvents() インターフェースにより Claude は以下が可能です。

  • イベントストリームの任意位置スライスを取得する
  • 特定の時点まで巻き戻して再読み込みする
  • アクション実行前に関連イベントを再確認する

従来のコンテキスト圧縮(情報を不可逆に削除する操作)と異なり、 セッションログはすべての情報を耐久的に保持します。 コンテキストウィンドウへの収め方はハーネスが制御するため、将来的な改善も容易です。

分離設計の勘所 3: 障害設計を「ペット」から「家畜」へ転換

単一コンテナ設計の脆弱性 — 障害でセッション全損、手動復旧が必須だった

初期の実装では、すべてのコンポーネントを単一コンテナに同居させていました。 コンテナが落ちるとセッション全体が失われ、応答しないコンテナの手動復旧が必要でした 出典

分離による耐障害性 — wake(sessionId) で再起動、ログから状態復元

コンポーネントを分離することで、各要素が 独立して失敗・交換可能 になりました。

  • ハーネスはステートレス化 → クラッシュしても wake(sessionId) で再起動
  • 再起動後は getSession(id) でイベントログから状態を復元
  • コンテナの再初期化が標準的なツールとして機能

「ペット」的に手動管理が必要だったシステムが、「家畜」的に自動管理できるシステムに変わりました 出典

TTFT 短縮の勘所 — p50 で約 60%・p95 で 90% 超を削減

脳と手の分離がもたらした最も明確な定量的成果は、 最初のトークン生成までの時間(TTFT: Time to First Token)の削減です 出典

パーセンタイル 改善率
p50 TTFT 約 60% 削減
p95 TTFT 90% 超削減

出典: Anthropic Engineering: Scaling Managed Agents

改善の理由はシンプルです。従来の設計ではコンテナの初期化が完了するまで推論を開始できませんでした。 ハーネスをコンテナ外に分離したことで、 コンテナのプロビジョニングを待たずに推論を即座に開始 できるようになりました。

分離設計の勘所 4: プロンプトインジェクション対策はリソース同梱 + ボールトの 2 パターン

コンポーネントの論理的分離はセキュリティ面でも重要な役割を果たしています。 Anthropic は認証情報の漏洩を防ぐ 2 つのパターンを採用しています 出典

パターン 1: リソース同梱型認証 — トークンは初期化時のみ、以降は git リモート経由

Git リポジトリへのアクセスを例にとると、リポジトリアクセストークンはサンドボックス初期化時に リポジトリのクローンに使われ、ローカル git リモートとして配線されます。 以降、サンドボックス内からの git 操作はトークン本体を扱わずに実行できます。

パターン 2: ボールト(Vault)型認証 — 専用プロキシ経由でセキュアに OAuth トークン取得

カスタムツールや OAuth トークンは外部のセキュアボールトに保存します。 専用プロキシがセッション関連のトークンを受け取り、ボールトから認証情報を取得して処理します。

構造的な分離によって、 プロンプトインジェクション攻撃がコンテナ内で成功したとしても、認証情報には到達できない 設計になっています。

スケーリングパターン — Many Brains(共有資源)と Many Hands(複数実行先)

Anthropic が明示している設計思想は 「インターフェース周囲には強い意見を持つが、脳・手の数や場所については前提を置かない」です 出典

Many Brains(多数の脳)— 複数ハーネスが共有のサンドボックス・ツール・セッションを利用

複数のステートレスハーネスが共有のリソースを利用する構成です。コンテナは実際に必要なときだけプロビジョニングされるため、並列実行のコストが最適化されます。

脳 1 ──┐
脳 2 ──┼── 共有サンドボックス / ツール / セッション
脳 N ──┘

Many Hands(多数の手)— 単一脳が異種実行環境(コンテナ / 外部サービス / MCP)を横断

単一の脳が異種の実行環境を横断して作業を割り当てる構成です。Claude が実行先を推論して選択します。

                  ┌── コンテナ A
脳(Claude) ──────┼── コンテナ B
                  ├── 外部サービス
                  └── MCP サーバー

従来のエージェント実装との違い — 6 観点で Managed Agents が優位

本セクションの要点を以下に整理します。

観点 従来の実装 Managed Agents
ハーネスの位置 コンテナ内に同居 コンテナ外に分離
障害時の挙動 セッション全体が失われる セッションログから復旧可
TTFT コンテナ初期化待ちが発生 推論を即座に開始可
スケーリング 手動管理・密結合 独立スケールアウト
認証情報管理 ハーネス内に混在しやすい ボールト / リソース同梱で分離
モデル更新対応 ハーネスの前提見直しが必要 インターフェース安定で影響小

実務への応用 — どのユースケースで Managed Agents を選ぶか

Managed Agents が有効な 4 用途 — 長時間 / 並列 / 高セキュリティ / モデル更新追従

本セクションの要点を以下に整理します。

  • 長時間・マルチステップのエージェントタスク: セッション外部化により、数時間・数日にわたるタスクも状態を失わずに継続できます
  • 大規模な並列エージェント実行: Many Brains パターンにより、多数のジョブを効率よく並列処理できます
  • セキュリティ要件が厳しい環境: 認証情報の構造的分離がプロンプトインジェクション対策になります
  • モデル更新を追跡したい場合: ハーネスとモデルが疎結合のため、モデルを更新してもハーネスの改修が最小限になります

検討が必要な場合 — 短時間タスク / 既存ハーネスへの強い依存があるケース

本セクションの要点を以下に整理します。

  • 短時間・単純タスク: アーキテクチャの複雑性がオーバーヘッドになる可能性があります
  • 既存のカスタムハーネスに強い依存がある場合: execute() インターフェースへの適合作業が必要です

出典(一次情報)

本記事の作成に直接参照した一次情報源は以下の通りです。最新の正確な情報は各リンク先で必ずご確認ください。

参考になったら ♡
Clauder Navi 編集部
@clauder_navi

Anthropic の Claude / Claude Code を中心に、日本のエンジニア向けに最新動向と実務 を毎日発信。 運営方針 は メディアについて をご覧ください。