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

分離設計の勘所 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 をもとに構成図を作成

ハーネスの位置が変わった — コンテナ外に分離、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)の削減です 出典。

出典: 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 を選ぶか

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

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

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

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

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

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

出典(一次情報)

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

• Anthropic Engineering: Scaling Managed Agents — Decoupling the Brain from the Hands — 著者: Lance Martin, Gabe Cemaj, Michael Cohen -出典— 公式ドキュメント(Managed Agents 関連ページは随時公開)