Lena です。Managed Agents のアーキテクチャ記事を読み終えたあと、しばらく Anthropic の engineering blog を画面に出したままにしていました。急いで試したくなったというより——そのフレーミングが、こちらの予想を少し裂いていったからです。
彼らは agent のインフラを OS になぞらえていました。OS はハードウェアを process、file、socket といった抽象に仮想化する——その抽象はハードウェアより長く生き残る。そして彼らは言うわけです：私たちは同じことを、agent 向けにやりました、と。
その一文の前で、少し時間を置きました。
Claude Managed Agents は 2026 年 4 月 8 日に public beta で公開されました。新しい model ではありません。インフラ層です——hosted runtime で、Claude は受管理環境の中で自律 agent として動きます。Anthropic の設計の仕方には、少し立ち止まって見るだけの価値があります。特に、あなたのチームが「agent のこの層を自分で作るのか、他人に任せるのか」を決めようとしているなら。
以下は、私が気づいたこと、そしてまだ理解しようとしていることです。
Claude Managed Agents とは何か
長時間の agent 作業のための hosted service
要するに、Claude Managed Agents は agent の実行 runtime を扱う一連の API です。あなたは agent が何をすべきかを定義します——system prompt、ツール、制約。Anthropic はそれを隔離されたクラウドコンテナで動かし、Claude はそこでファイルを読み、コードを実行し、ウェブを閲覧し、MCP ベースの connector を通じて外部サービスを呼べます。
ピッチはシンプルです：agent loop、sandbox、ツールのオーケストレーション、エラー回復、credential 管理を数か月かけて自前で作る代わりに、それを Anthropic に渡す。Managed Agents の公式ドキュメント によれば、harness には prompt caching、context compaction、性能最適化が組み込まれています——どれも、多くのチームが最後には自力で作る羽目になるものばかりです。
価格は consumption-based。標準の Claude API トークンレートに加え、1 session-hour のアクティブ runtime あたり $0.08。idle 時間はカウントされません。runtime はミリ秒単位で計測されます。定額の月額料金はなく、agent ごとのライセンスもありません。
……この価格構造を二度見しました。これが意味するのは、本当のコストの支配要因は runtime 自体ではない、ということです——session 中にあなたの agent の tool loop がどれだけトークンを食うか、そこです。bash コマンド、ファイル読み取り、ウェブ取得のすべてがトークンを積み上げます。重い agentic session が推論で燃やす金額に比べれば、$0.08/hour はほとんど端数のようなものです。
Session、harness、sandbox、そしてイベントインターフェース
アーキテクチャが面白くなるのはここからです。
Anthropic の Managed Agents engineering 記事 は、独立に進化できるように設計された 3 つの仮想化コンポーネントを説明しています：
Session は append-only の、永続化されたイベントログです。あらゆるユーザーメッセージ、assistant のレスポンス、tool call、tool result が、typed event として記録されます。これは harness の完全に外側に存在します。クラッシュ、ネットワーク断、コンテナの再起動を生き延びます。インターフェースの原語は 2 つ、appendEvent() と getEvents()。それだけです。
Harness は agent loop そのものです——Claude を呼び、tool call をルーティングし、context を管理します。重要なのは、Anthropic がこの層を所有していて、model の改善に合わせて更新していくことです。彼らは、Claude Sonnet 4.5 向けに作った harness に「context anxiety」を扱うための context-reset ロジックが含まれていたのに、Claude Opus 4.5 が到着するとその不安はもう存在しなかった、と語っています。古い harness が、新しい model の足を積極的に引っ張っていた。その観察が、アーキテクチャ全体を駆動したわけです。
Sandbox は実行環境です——gVisor で隔離されたコンテナで、Claude が生成したコードがその中で走ります。ネットワーク egress は default-deny。ファイルシステムアクセスは scoped。credential は sandbox には決して保存されません——セキュアな vault に保管され、プロキシ経由でアクセスされます。sandbox は設計上、信頼されないものとして扱われます。
この分離に何度も戻ってきます。すっきりしています。でも、なぜそれが重要なのかは「次の model が出たらどうなるか」を考えるまで、はっきりとは腑に落ちませんでした。
Managed Agents が解くこと
Runtime インフラ、sandboxing、再開可能な session
本番に agent を出そうとしたことがあれば、このリストはもう身に染みているはずです：sandbox 化された実行、credential 管理、session の永続化、エラー回復、observability。あるデベロッパーは、1 つの agent を本番に維持するためだけに 6 つの別々のシステムをチームで作ったと話していました——そのうち 4 つは agent が実際にやっていることとは無関係だったそうです。
Managed Agents はその一群の作業をまるごと消します。session は何時間も走れます。接続が落ちても、session は永続イベントログから再開します。すべての tool call と失敗モードは、組み込みの observability を通じて追跡可能です。Notion、Asana、Sentry のような企業はすでに、このインフラ上に作られた agent を統合しています。
実用的なインパクトは本物です。 コードベースを読み、修正を計画し、PR を出す coding agent。数十回のウェブ検索にまたがって 90 分走る research agent。こうしたパターンは以前、agent のロジックに取りかかる前に、何か月ものインフラ作業を必要としていました。
「脳」と「手」を切り離すことがなぜ重要か
……ここで何かがかちっとはまりました。
Anthropic はこのアーキテクチャを、「脳」（model と、何をするかを決める harness）と「手」（実際に作業を実行するツールと sandbox）の分離として枠づけます。その分離には、具体的な帰結があります：より良い model が出てきたとき、あなたの agent 定義に触れることなく harness が更新できる。
古い結合設計では、あらゆる session がコンテナ起動コストをまるごと払っていました——sandbox を一度も触らない session でさえ。Anthropic が harness をコンテナの外に出したことで、コード実行を必要としない session は、コンテナのプロビジョニングを待たずに開始できるようになりました。
しかし、もっと深いポイントは耐久性についてです。Harness は「model にできないこと」についての前提をエンコードしています。そうした前提は、model が進化するにつれて古びていきます。あなたの harness が自分で作った固定のシステムなら、前提を現状に合わせ続ける保守コストを引き受けることになります。Anthropic が harness を所有すれば、そのコストは彼らに移ります。
その約束が、時間を通してどれだけ実際に成立するかは、完全には自信がありません。でも、アーキテクチャの推論としては腑に落ちます。
Managed Agents が既定では解かないこと
ここはいちばん時間をかけて考えた部分です。
能力の検証、agent をまたいだ再利用、ガバナンスのライフサイクル
Managed Agents は runtime の問題を徹底的に解きます。でも、隣接する問題は扱われていません——欠陥だからではなく、それらが現状の scope の外側に座っているからです。
能力の検証。 ある agent が複雑なタスクを成功させたとき——たとえば、あるクラスの security アラートを triage する、特定のコードパターンを refactor する——その成功は「検証済みの再利用可能な能力」として捕まえられません。session log は何が起きたかを記録しますが、「このアプローチがうまくいった、他の agent が継承できる strategy としてエンコードせよ」と言う仕組みはありません。 各 session は新しく始まります。ある session で Claude が学んだことは、次の session を自動的によくすることはありません。
Agent をまたいだ再利用。 agent を一度定義して、ID で session 間から参照することはできます。それは設定レベルの再利用です——同じ prompt、同じツール、同じ制約。でも能力レベルの再利用ではありません。Agent A が特定の framework に効く debug strategy を見つけても、同じような問題に取り組む Agent B は、誰かが共有 system prompt を手で更新しない限り、その恩恵を受けません。
ガバナンスのライフサイクル。 beta にはスコープ付き権限、アイデンティティ管理、実行トレースが含まれています。でも、より広いガバナンスの問い——agent のふるまいが広がる前に、誰がそれが安全だと検証するのか、capability drift を時間を通じてどう監査するか——は、現行のサーフェスには含まれていません。
深読みかもしれません。これらは将来のロードマップ項目かもしれません。でも現時点では、Managed Agents は優れた受管実行を提供しているのであって、組み込みの能力蓄積ではありません。 長期的なシステムの改善を考えているのなら、単なるタスク自動化を考えているのとは話が変わってきます。
……まだ少し曖昧なところが残っています。この gap は意図的だと思います——Anthropic はまずインフラの問題を解いていて、能力の進化は別の層だ、と。でも、完全な確信はまだありません。
Managed Agents vs Claude Code Routines
長時間 runtime vs トリガー可能な自動化
この比較は最初混乱しましたが、両方を見たあとでは明確になりました。
Claude Code Routines は保存された設定です——prompt、repo、connector。スケジュール、API 呼び出し、あるいは GitHub イベントへの応答で自動的に走ります。人の目が届かない、繰り返せるタスク のために設計されています。たとえば夜間 triage、PR review、ドキュメント drift スキャンなど。各 run は新しい session。プランに応じて 1 日あたりの上限があります（5〜25 回）。それらはサブスクリプションの使用枠から引かれます。
Claude Managed Agents は、長時間・自律的な仕事 のための hosted runtime です。session は何時間も走れます。harness が context compaction、エラー回復、ツールのオーケストレーションを管理します。課金はトークン + session-hour。1 日あたりの run 上限はありません——使った分だけ支払います。
いちばん単純な区別：Routines は「トリガー可能な自動化」。Managed Agents は「agent インフラのための runtime」。Routines はタスクが有界で繰り返せることを前提とします。Managed Agents はタスクがオープンエンドで、しばらく時間がかかることを前提とします。
複数ファイルの refactor を計画し、テストを走らせ、PR を開く coding agent——それは Managed Agents の領域です。新しい issue にラベルを付けて Slack に要約を投稿する夜間スクリプト——それは Routine です。
どちらかがどちらかを置き換えるわけではありません。でもそのどちらも、単体では成功した実行を再利用可能な能力に変えることはしません。
誰が Managed Agents を評価すべきか
見てきた限り、次の条件に合うチームなら Managed Agents は真面目に評価する価値があります：
agent のプロトタイプは作ったが、インフラの壁にぶつかっている。 「動くデモ」から「本番へのデプロイ」への段差が、多くのチームが止まる地点です。あなたの backlog に「sandbox 分離を作る」「session チェックポイントを実装する」「credential 管理を設計する」といった項目があるなら、Managed Agents はそのカテゴリをまるごと消します。
agent のタスクが長時間・多段である。 agent がコードベースを読み、変更を計画し、コードを実行し、テストを走らせ、PR を開く——それを 1 時間近くかかるかもしれない 1 つの session でやる必要があるなら、Managed Agents はまさにそのためのものです。短くて同期的なタスクには、標準の Messages API のほうが適しています。
beta の境界を受け入れられる。 すべての endpoint は managed-agents-2026-04-01 の beta ヘッダを要求します。マルチエージェント協調と self-evaluation はまだ research preview。ふるまいは変わり得ます。GA に到達していないサーフェスに mission-critical なワークフローを載せないでください。
ロックインの問題を考えた上で選んでいる。 一度 agent が Anthropic のインフラ上で走り始めると、プロバイダーの切り替えは軽いものではありません。Managed Agents についての Anthropic のブログ記事 は、これを意図的なトレードオフとして枠づけています：受管された harness の進化を得る代わりに、1 つの runtime に結合する。アーキテクチャが複数プロバイダーの model を混ぜることを要求するなら、この制約は重要です。
デフォルトでの能力継承を期待していない。 Managed Agents が与えるのは優れた受管実行であって、成功したふるまいが session をまたいで積み上がり、自己改善していくシステムではありません。
FAQ
Managed Agents はどの model をサポートしますか？
public beta は Claude Sonnet 4.6、Claude Opus 4.6、Claude Haiku 4.5 をサポートします。大コンテキスト（1M トークン）は Opus と Sonnet ではデフォルトで利用できます。
価格はどうなっていますか？
model 利用は標準の Claude API トークンレート、加えて 1 session-hour のアクティブ runtime あたり $0.08。Web 検索は 1,000 検索あたり $10。idle 時間は除外。定額の月額料金はありません。
beta と research preview の違いは？
コアプラットフォーム——session、sandboxing、ツール実行——は public beta。マルチエージェント協調と self-evaluation（outcomes）は research preview で、別途アクセス申請が必要です。
session ごとの予算上限は設定できますか？
Managed Agents 内部から直接は設定できません。Claude Console で組織全体の月次支出上限は設定できますが、session ごとの予算上限は現状ドキュメント化されていません。session 作成を自前のロジックでラップして、暴走する session を追跡・終了するのが実務的な workaround です。
各 session は新しく始まるのですか？
session は 1 つの session の中では状態を保ちます——ファイルシステム、会話履歴、イベントログ。ただし session をまたいだ組み込みの記憶や能力の引き継ぎはありません。新しい session はクリーンな環境から始まります。
これは Claude Code と同じですか？
違います。Claude Code はインタラクティブなコーディングのための開発者ツールです。Managed Agents は、自律 agent を大規模にデプロイするための API レベルのインフラサービスです。アーキテクチャの DNA は共有していますが、対象とする読者は違います。
アーキテクチャの前にまだ座っています。session、harness、sandbox——それぞれ仮想化され、それぞれ独立に進化できる。解いている runtime の問題は本物で、プロトタイプと本番の間に詰まっていたチームにとって、これはタイムラインを数か月から数日に変えます。
それでも、「受管された実行」と「積み上がっていく能力」の間にあるスペースに気づき続けています。session log は起きたことをすべて記録します。それはまだ、起きたことを次の session が積み上げられる何かには変えません。
Previous Posts：
👉 Claude Code が外部ツールや agent とどうつながるか知りたい？ MCP の基礎から：What Is MCP? The AI Tool Connection Standard Explained
👉 agent をプロンプトの向こうへ広げたい？ Claude Code の中で skill が実際にどう動くかを分解：Claude Code Skills Explained: Build, Share, and Extend
👉 agent インフラの層が実際のシステムでどう積み上がるか気になる？ アーキテクチャの全景：MCP, CLI, and GEP: The Three Layers of the Agent Stack
👉 「インフラ vs 能力」を比べているなら、多くのチームが見落とす決定的な違いをここで：Agent Skills vs GEP Assets: The Real Difference
👉 agent memory が実際にどうスケールするか（どこで破綻するか）を知りたい？ 現実のトレードオフに踏み込む：Hermes Agent Memory Limits and Tradeoffs
