前回の記事では Claude Managed Agents の概要と業界インパクトを紹介した。本記事では、Anthropic のエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」に基づき、内部アーキテクチャを掘り下げる。
全体アーキテクチャ
Claude Managed Agents は4つのコアコンセプトで構成される。
| コンセプト | 説明 |
|---|---|
| Agent | モデル、システムプロンプト、ツール、MCP サーバー、スキルの定義 |
| Environment | コンテナテンプレート（パッケージ、ネットワークアクセス、マウントファイル） |
| Session | Agent と Environment を参照して起動される実行インスタンス |
| Events | アプリケーションとエージェント間でやり取りされるメッセージ（SSE） |
これらの背後には、Brain / Session / Hands という3層の分離設計がある。
設計思想: OS の抽象化パターン
Anthropic はこのアーキテクチャの設計思想を、OS がハードウェアを抽象化した歴史に重ねている。
1970年代のディスクパックでも現代の SSD でも、read() コマンドは同じように動く。ハードウェアの実装が変わっても、その上の抽象化層（プロセス、ファイル）は安定し続けた。
Managed Agents も同じパターンを採用している。Session、Harness、Sandbox というエージェントのコンポーネントを仮想化し、インターフェースは安定させたまま、内部実装を自由に交換できる構造にした。Anthropic はこれを「メタハーネス」と呼んでいる。
なぜこの設計が必要なのか。ハーネスには「モデルが自力でできないこと」に関する前提が埋め込まれるが、モデルの能力が向上するとその前提が陳腐化する。例えば Claude Sonnet 4.5 では、コンテキスト制限が近づくとタスクを早期終了する「コンテキスト不安（context anxiety）」が見られた。そこでハーネスにコンテキストリセットを追加した。しかし Claude Opus 4.5 ではこの振る舞いが消え、リセット機能は無駄な荷物になった。
Brain: ステートレスなハーネス + Claude
Brain は Agent Harness と Claude（LLM 推論）で構成される。
初期の問題: Pet になったコンテナ
インフラ運用には Pets vs Cattle（ペットと家畜）という有名な比喩がある。Pet は名前を付けて大切に管理するサーバーで、壊れたら修理・看護する。一方 Cattle は番号で管理する使い捨てのサーバーで、壊れたら新しいものに差し替えるだけだ。クラウドネイティブな設計では、個々のインスタンスに依存しない Cattle 型が望ましいとされる。
当初はすべてのコンポーネント（ハーネス、セッション、サンドボックス）を単一のコンテナに入れていた。ファイル操作が直接のシステムコールで済むなどの利点はあったが、コンテナが Pet 化した。
- コンテナが落ちるとセッションが失われる
- 応答しなくなったコンテナの看護が必要
- デバッグのためにコンテナ内でシェルを開く必要があるが、ユーザーデータが同居しているため実質的にデバッグ不可能
- 顧客の VPC に接続するにはネットワークピアリングが必要
解決: Brain を Cattle にする
Brain をコンテナから分離し、ステートレスにした。
- クラッシュからの復旧: Brain がクラッシュしても、新しい Brain が
wake(sessionId)で起動し、getSession(id)でイベントログを取得して最後のイベントから再開できる - スケーリング: 多数の Brain を起動するには、ステートレスなハーネスを多数起動するだけでよい
- TTFT の改善: コンテナの起動を待たずに推論を開始できるようになり、TTFT（Time to First Token: 最初のトークンが返るまでの時間）が p50 で約60%、p95 で90%以上改善した
Brain は実行中、emitEvent(id, event) でセッションログにイベントを書き込み、耐久性のある記録を維持する。
ハーネスの役割
Agent Harness はエージェントループの実行を担い、以下の最適化を組み込んでいる:
- プロンプトキャッシュ: 高いキャッシュヒット率を実現するコンテキスト配置
- コンパクション: コンテキストウィンドウの要約・圧縮
- コンテキストエンジニアリング: 不要なトークン（古いツール結果、思考ブロック）の選択的削除
Session: コンテキストウィンドウの外に存在する永続コンテキスト
Session は append-only のイベントログで、Claude のコンテキストウィンドウの外に永続的に存在する。
なぜ Session が必要か
長時間タスクはコンテキストウィンドウを超えることが多い。従来の対処法（コンパクション、メモリツール、トリミング）はすべて不可逆な判断を含む。将来のターンでどのトークンが必要になるかを事前に予測するのは困難だ。
getEvents() インターフェース
Session の getEvents() インターフェースにより、Brain はイベントストリームの任意の位置スライスを照会できる:
- 最後に読んだ位置から続きを取得
- 特定のアクション前の数イベントを巻き戻して経緯を確認
- 特定の時点のコンテキストを再読み込み
取得したイベントはハーネス内で変換してから Claude のコンテキストウィンドウに渡すことも可能だ。回復可能なコンテキスト保存は Session が担い、任意のコンテキスト管理はハーネスが担うという関心の分離がなされている。
Hands: 使い捨て可能なサンドボックス + ツール
Hands はサンドボックス（コンテナ）と各種ツールで構成される。Brain から execute(name, input) → string という統一インターフェースで呼び出される。
Cattle としてのコンテナ
Brain から分離されたことで、コンテナは Cattle（使い捨て可能な家畜）になった:
- コンテナが落ちても、ハーネスはツール呼び出しエラーとして Claude に報告
- Claude がリトライを判断すれば、
provision({resources})で新しいコンテナを初期化 - コンテナの障害が Brain やセッションに波及しない
セキュリティ境界
結合設計では、Claude が生成したコードと認証情報が同じコンテナ内に存在していた。悪意あるプロンプトで LLM を操作し、環境変数を読み取らせるプロンプトインジェクションのリスクがあった。
分離設計では、認証情報がサンドボックスの中から到達不可能になっている:
| リソース | 認証情報の扱い |
|---|---|
| Git リポジトリ | アクセストークンでクローン時に認証。サンドボックス内では git push/pull が透過的に動作するが、トークン自体には触れられない |
| MCP ツール | OAuth トークンを Vault に格納。専用プロキシ経由でアクセスし、ハーネスもトークンを知らない |
Many Brains, Many Hands
分離設計により、1つの Brain が複数の Hands を操作でき、逆に複数の Brain がそれぞれ独立した Hands を持つこともできる。
- Many Brains: ステートレスなハーネスを多数起動するだけ。Hands が不要なセッションはコンテナを起動しない
- Many Hands: 各 Hand は
execute(name, input) → stringというツール。コンテナでも MCP サーバーでも、Hands のインターフェースを満たすものなら何でも接続できる - Hands の受け渡し: Brain 間で Hands を受け渡すことも可能（マルチエージェント連携の基盤）
OpenClaw との設計思想の比較
OpenClaw のアーキテクチャと比較すると、同じ「AIエージェント基盤」でも設計思想が大きく異なる。
共通点
両者とも「チャットボットを超えたエージェント基盤」を目指しており、以下の点は共通している:
- LLM が判断と実行を担う
- ツール実行を抽象化している
- 外部サービス連携の仕組みを持つ
- 長時間タスクへの対応
根本的な違い
| 観点 | OpenClaw | Claude Managed Agents |
|---|---|---|
| 実行場所 | ユーザーのデバイス（ローカル） | Anthropic のクラウド |
| 常駐性 | Gateway デーモンが常駐。Heartbeat で自律判断 | セッション単位のオンデマンド起動 |
| 入力ソース | 22+ チャネル / Heartbeat / Cron / Webhook | API 経由のイベント送信 |
| 障害分離 | 単一デーモン（Gateway + Runtime が結合） | Brain / Session / Hands が独立して障害・交換可能 |
| スケーリング | 単一デバイス | Many Brains, Many Hands でクラウドスケール |
| 人格・記憶 | SOUL.md / MEMORY.md でローカル管理 | Agent 定義 + Session ログ |
| ワークフロー | Lobster YAML（決定論的パイプライン） | ハーネス内でのタスク実行（LLM 自律） |
| エコシステム | ClawHub（13,000+ スキル） | MCP サーバー + 組み込みツール |
使い分け
- OpenClaw が向いているケース: プライバシー重視（データをクラウドに出したくない）、マルチチャネル統合が必要、常駐型の自律エージェントが欲しい、決定論的ワークフロー（Lobster）が必要
- Managed Agents が向いているケース: インフラ管理を避けたい、長時間の非同期タスク、スケーラブルなマルチエージェント連携、セキュリティ境界の分離が重要
両者は競合というより補完的な関係にある。OpenClaw がエッジ側の自律エージェント、Managed Agents がクラウド側のスケーラブルなタスク実行基盤という棲み分けだ。
API の基本フロー
Managed Agents の利用フローは5ステップで構成される:
# 1. Agent を作成（モデル、プロンプト、ツールを定義）
POST /v1/agents
# 2. Environment を作成（コンテナテンプレート）
POST /v1/environments
# 3. Session を開始（Agent + Environment を参照）
POST /v1/sessions
# 4. イベントを送信
POST /v1/sessions/{id}/events
# 5. SSE でレスポンスをストリーム
GET /v1/sessions/{id}/streamすべてのエンドポイントにベータヘッダー managed-agents-2026-04-01 が必要だ。SDK を使えばヘッダーは自動設定される。
SSE（Server-Sent Events）とは
ステップ5で使われている SSE（Server-Sent Events）は、HTTP 上でサーバーからクライアントへ一方向にリアルタイムデータを配信する W3C 標準の仕組みだ。Content-Type: text/event-stream で接続を維持し、イベントを逐次送信する。
WebSocket との違いは以下の通り:
| 項目 | SSE | WebSocket |
|---|---|---|
| 通信方向 | サーバー → クライアント（単方向） | 双方向 |
| プロトコル | 標準 HTTP | 独自プロトコル (ws://) |
| 再接続 | 自動 | 手動実装が必要 |
| インフラ互換性 | プロキシ / LB と相性良好 | 対応が必要な場合あり |
Managed Agents ではエージェントへの指示は REST API（POST /v1/sessions/{id}/events）で送り、結果の受信は SSE（GET /v1/sessions/{id}/stream）で行う。エージェント実行の監視は本質的にサーバーからの単方向配信であり、双方向通信は不要なため、インフラの複雑さを増さない SSE が合理的な選択となっている。
実際の利用フロー: チャットボットとの連携例
CMA 自体にはチャット UI やチャネル監視の機能はない。開発者が自前のアプリケーション（チャットボット、Web UI など）を構築し、そのアプリが CMA の API を仲介する形になる。
- ユーザーがチャットでメッセージを送信 — チャットボットや Web UI がメッセージを受け取る
- アプリが API でイベントを送信 —
POST /v1/sessions/{id}/eventsで Session にイベントを書き込む - Brain がイベントを取得 —
getEvents()で Session のイベントログを読み取る - Brain がオーケストレーション実行 — Agent Harness が Claude に推論させ、必要に応じて Hands（Sandbox / Tools）を
execute()で呼び出す - Brain が結果を記録 —
emitEvent()で Session にイベントを書き込む - SSE でアプリに結果をストリーム —
GET /v1/sessions/{id}/streamでアプリがリアルタイムに結果を受信 - アプリがユーザーに応答を表示
つまり、OpenClaw のように Gateway が直接チャットチャネルを監視するのとは異なり、CMA では開発者のアプリケーションがイベントの入出力を仲介する設計になっている。これにより、どのようなフロントエンド（Slack ボット、Web アプリ、モバイルアプリなど）とも柔軟に統合できる。
まとめ
Claude Managed Agents のアーキテクチャは「ハーネスに埋め込まれた前提は陳腐化する」という課題に対する構造的な解答だ。Brain / Session / Hands を分離し、それぞれを Cattle として扱えるようにすることで、障害分離、スケーラビリティ、セキュリティを同時に達成している。
OS が「まだ考えられていないプログラム」のためにハードウェアを抽象化したように、Managed Agents は「まだ考えられていないハーネス」のためにエージェントのコンポーネントを抽象化する。モデルの能力が向上するたびにハーネスの前提が変わっても、インターフェースは安定し続ける。この設計判断が、今後のエージェント基盤の進化にどれだけ寄与するかが注目される。
参考
- OpenClaw 入門: チャットボットを超える AI エージェントランタイムの全体像 — OpenClaw のアーキテクチャ（Gateway / Runtime / Heartbeat）を解説。CMA との設計思想の違いを理解する上で参考になる