Claude Code を使い込んでいる人なら、こんな壁に当たったことがあるはずです。
- 長時間タスクの途中でエージェントが止まる。再開しようにも文脈が飛んでいる
- コンテナが落ちた瞬間、作業ファイルもセッション履歴もまとめて消える
- 「外部 VPC 上のリソースに繋ぎたいのに、エージェントのインフラと同居させないと使えない」
これらはすべて、エージェントのコンポーネントがひとつのコンテナに密結合していることから生まれる構造的な問題です。
2026年4月、Anthropic はこの問題を根本から解決するサービス Claude Managed Agents をベータ公開しました。同時に公開されたエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」では、そのアーキテクチャ設計の全貌が明かされています。
この記事では、ブログの知見を日本語で噛み砕きつつ、実際の API の使い方まで紹介します。
従来のエージェント設計が抱えていた「ペット問題」
Anthropic のエンジニアチームが最初に作ったエージェント基盤は、ひとつのコンテナにすべてを詰め込む設計でした。
- セッション（会話履歴）
- ハーネス（Claude を呼び出してツール実行をルーティングするループ）
- サンドボックス（コードの実行環境）
この3つが同居することで、ファイル操作は直接のシステムコールで済み、サービス境界の設計も不要。最初は快適に動いていました。
しかし、これはインフラの世界で「ペット」と呼ばれるアンチパターンそのものです。
ペット vs キャトル（家畜）
- ペット: 名前をつけて手厚く世話する、失うわけにいかない個体。壊れたら修理する
- キャトル: 交換可能な個体。壊れたら捨てて新しいのを起動する
単一コンテナのエージェントは「ペット」でした。コンテナが落ちればセッション履歴が消え、応答しなくなればエンジニアがコンテナ内にシェルを開いて手作業で復旧する。しかもそのコンテナにはユーザーデータも入っているため、デバッグのためにアクセスすること自体がセキュリティ上のリスクになる。
さらに厄介だったのが、ハーネスが「作業対象のリソースは自分と同じコンテナ内にある」と仮定していたことです。顧客が自社の VPC 内のリソースに Claude を繋ぎたいと言ったとき、ネットワークピアリングを張るか、ハーネスごと顧客環境で動かすしかありませんでした。
「脳」と「手」を分離する
Anthropic が到達した解決策は、エージェントを3つの独立したインターフェースに分解することです。
| コンポーネント | 役割 | インターフェース |
|---|---|---|
| Brain（脳） | Claude + ハーネス。推論とツール呼び出しの判断 | wake(sessionId), getSession(id), emitEvent(id, event) |
| Hands（手） | サンドボックス。コード実行やファイル操作 | execute(name, input) → string |
| Session（記録） | 永続的なイベントログ。脳にも手にも属さない | getEvents() |
それぞれが独立して障害を起こせる（そして独立して復旧できる）のがポイントです。
ハーネスがコンテナから出る
分離後、ハーネスはコンテナの外で動きます。コンテナを呼び出すのは、他のツールを呼ぶのとまったく同じインターフェースです。
execute(name, input) → string
コンテナが死んだら？ ハーネスはそれをツール呼び出しエラーとして受け取り、Claude に返します。Claude がリトライすると判断すれば、provision({resources}) で新しいコンテナを標準レシピから起動する。もう「ペット」の看病は要りません。
ハーネス自体もキャトル化
セッションログがハーネスの外にあるので、ハーネス内に生き残らせるべきデータは何もありません。ハーネスがクラッシュしたら、新しいハーネスを起動して wake(sessionId) → getSession(id) でイベントログを取得 → 最後のイベントから再開。それだけです。
セキュリティ境界の構造的な解決
密結合の設計では、Claude が生成した信頼できないコードが、クレデンシャルと同じコンテナ内で実行されていました。つまり、プロンプトインジェクションで「自分の環境変数を読んで」と一言言わせるだけで、認証情報が漏洩するリスクがあったわけです。
「スコープを狭める」という対処は可能ですが、これは「Claude が限定的なトークンでは何もできない」という前提に依存します。そして Claude はどんどん賢くなっている。
Anthropic が採用した構造的な解決策は、「サンドボックスからクレデンシャルに到達できない」ようにすることです。
パターン1: リソースに認証を同梱する
Git リポジトリの場合、アクセストークンを使ってサンドボックス初期化時にリポジトリをクローンし、ローカルの git remote に紐づけます。サンドボックス内からは git push / git pull がそのまま動きますが、エージェントがトークン自体を扱うことはありません。
パターン2: Vault で外部保管する
MCP ツール用の OAuth トークンは、サンドボックスの外にあるセキュアな Vault に保管されます。Claude が MCP ツールを呼ぶと、専用プロキシがセッションに紐づいたトークンを受け取り、Vault からクレデンシャルを取得して外部サービスを呼び出します。ハーネスもサンドボックスもクレデンシャルに触れません。
セッションはコンテキストウィンドウではない
長時間タスクでは、Claude のコンテキストウィンドウを超えることが頻繁に起きます。従来のアプローチ（コンパクション、トリミング）は「何を残すか」の不可逆な判断を伴い、将来必要になるトークンを誤って捨てるリスクがありました。
Managed Agents では、セッションログがコンテキストウィンドウの外にある永続的なコンテキストオブジェクトとして機能します。
getEvents() → イベントストリームの任意のスライスを取得
このインターフェースにより、ハーネスは以下のような柔軟なアクセスが可能です。
- 前回の読み取り位置から続きを取得
- 特定のアクションの直前まで巻き戻して文脈を確認
- 特定の時点のイベントを再読み込み