プロンプトの次、ハーネスの次は「メタハーネス」だ

Anthropic Managed Agents が示した本当の論点

Anthropicが2026年4月8日に公開ベータとして出した Claude Managed Agents は、一見すると「長時間動くAIエージェントをAnthropicがホストしてくれる便利サービス」に見えます。
実際、製品ブログでも、secure sandboxing、認証、権限管理、長時間セッション、トレースなどをまとめて提供し、試作から本番までを速める基盤として紹介されています。
ですが、Engineering Blog を読むと、本題はそこではありません。
Anthropicが本当に解こうとしているのは、将来どんなエージェントハーネスが出てきても壊れない実行基盤をどう設計するかという、かなり古くて、かなり大きい設計問題です。 (Claude)

今回の記事の見出しにある “programs as yet unthought of” という言い回しは、まさにその問題を指しています。
まだ存在しない将来のプログラムに耐えるよう、OS が process や file のような抽象を先に作ったのと同じように、Anthropicはエージェントの世界でも、将来の実装変更に耐える抽象を先に作ろうとしています。
Engineering Blog は、Managed Agents を session / harness / sandbox という3つの部品に仮想化し、実装ではなくインターフェースを安定化したと説明しています。 (Anthropic)

ここがとても重要です。
従来のハーネスは、「モデルがまだ自力でできないこと」を前提に設計されます。ところがモデルが進化すると、その前提は簡単に腐ります。
Anthropicはその実例として、以前は Claude Sonnet 4.5 がコンテキスト上限に近づくと仕事を早く切り上げてしまう “context anxiety” があり、ハーネス側で context reset を入れると効いたが、同じ設計を Claude Opus 4.5 に使うと、その癖はすでに消えていて、reset はただの重りになった、と明かしています。
つまり、ハーネスは賢さを補う一方で、賢さが伸びるほど古い工夫が足かせにもなるわけです。

だからAnthropicは、「最強のハーネスを1つ決める」方向には行きませんでした。
そうではなく、ハーネスそのものが入れ替わっても、その外側の土台は持ちこたえるようにした。
これが Managed Agents の設計思想です。
実際、記事の結論部で Anthropic は Managed Agents を meta-harness と呼び、Claude Code のような汎用ハーネスも、特定タスク向けの task-specific harness も、その上に載せられる一般インターフェース群として位置づけています。

この設計に至った理由は、かなり現実的です。
Anthropicは当初、session・harness・sandbox を同じコンテナに入れていました。
すると、ファイル編集は速いし境界も少ないのですが、コンテナが落ちれば session ごと失われ、固まれば個別に看病が必要になり、しかも user data を抱えたままデバッグしなければならない。
典型的な pets not cattle の問題です。
加えて、ハーネスが「Claude が扱う対象は自分と同じコンテナのそばにある」という前提で書かれていたため、顧客のVPCや別環境に繋ぎたいとき、その前提自体が障害になりました。

そこで Anthropic は、brain と hands を切り離します。
Claude とその orchestrating harness を brain、コード実行環境や各種ツールを hands、そして出来事の履歴を残す durable log を session として分けたのです。
新設計では、harness はコンテナの中に住まず、sandbox を execute(name, input) -> string という道具の1つとして呼びます。
コンテナが死ねば tool-call error として扱い、新しい環境を provision(...) で起こせばいい。
harness が落ちても、session log が外にあるので、wake(sessionId) と getSession(id) で続きを再開できます。

この分離は、単なる美しい設計ではありません。
性能にも効いています。
以前は brain を動かすたびにコンテナを先に用意する必要があり、sandbox を使わない仕事でも、その起動待ちを全員が払っていました。
分離後は、hands が必要になったときだけ呼べばいい。
その結果、Anthropic は p50 TTFT を約60%削減、p95 を90%以上削減したと報告しています。長時間エージェントの議論では「どのモデルが賢いか」に目が向きがちですが、実際の体感を壊すのは、こうしたランタイムの待ち時間であることが多い。
Managed Agents はそこを、かなり正面から潰しに来ています。

もう1つ見逃せないのが、セキュリティ境界を構造で解いた点です。
旧設計では、Claude が生成した untrusted code と credential が同じコンテナに同居していたため、prompt injection が通ると、Claude に自分の環境変数を読ませるだけでトークンへ届く危険がありました。
Anthropic の答えは、権限を少し狭めることではなく、そもそも sandbox から credential を見えなくすることでした。
Git の認証はリソース側に結びつけ、MCP の OAuth credential は vault に置き、Claude は専用 proxy 経由で呼ぶ。Docs でも vault は end-user 単位の credential 集合として説明されており、セッションに紐づけて扱う前提です。

さらに重要なのは、Anthropicが 「session は Claude の context window ではない」 と明言しているところです。
長時間タスクでは、どの情報を残し、どれを圧縮し、どれを捨てるかという context engineering が不可欠です。Anthropic はこれまでも、multi-agent research system、effective context engineering、long-running harness、application development harness などを通じて、その問題と格闘してきました。
ですが今回の Managed Agents では、一歩進めて、状態の保存先そのものをコンテキスト窓の外へ出した。
session log を durable に保持し、getEvents() で必要な区間だけ読み出し、その加工や compaction は harness 側の責務に押し出しています。保存と見せ方を分けたわけです。

この分離が意味するのは、AIエージェントの実装単位が、もはや単なる prompt や tool loop ではなく、状態・制御・接続・証跡を分離して持てる runtime substrate へ移りつつある、ということです。
Session は証跡と状態の基盤になり、harness は制御回路になり、sandbox / MCP / vault / environment は接続回路になる。
Managed Agents は「賢い1体のエージェント」を売っているというより、複数の脳と複数の手を、長時間・安全・再開可能に動かすための実行OSを作り始めた、と読んだ方が本質に近いと思います。
Engineering Blog の “Many brains, many hands” は、その方向をかなり率直に示しています。

実務で見ると、この基盤が向くのは、数分から数時間動き、途中で止まり、再開し、ツールをまたぎ、結果を追跡したい仕事です。
Docs でも Managed Agents は long-running tasks と asynchronous work 向けとされ、Messages API は custom agent loops と fine-grained control 向けと整理されています。
つまり、「1つ1つのループを自前で精密に握りたい」なら Messages API が残る一方、「長く動く実務タスクの土台をまず持ちたい」なら Managed Agents がかなり有力、という住み分けです。
Console には session tracing、timeline、tool execution の観測面も用意されています。

ただし、まだ何でも完成済みという段階ではありません。
Managed Agents 自体は public beta で、全APIリクエストに managed-agents-2026-04-01 ベータヘッダが必要です。
Multi-agent、Memory、Outcomes は Research Preview 扱いで、別途アクセス申請や追加ヘッダが必要です。セッションはデフォルトではエフェメラルで、学習内容を跨いで持ちたいなら memory store を使います。
料金もトークンだけではなく、running 状態の session runtime が $0.08 / session-hour で加算されます。要するに、これは「何でも魔法のようにやってくれる完成形」ではなく、プロダクションに近い長時間エージェント基盤を、Anthropic が先に共通化し始めた段階です。

そして、ここがいちばん面白いところです。
Anthropic は 2025年以降、multi-agent research、context engineering、long-running harness、app-building harness と、ずっと「より良いハーネス」を掘ってきました。
今回の Managed Agents は、その延長でありながら、同時にその一段上にあります。
つまり問いが、「どうすれば賢いハーネスを作れるか」から、「ハーネスが今後どう変わっても載せ替えられる土台をどう作るか」へ上がったのです。
これはAIエージェント設計が、prompt engineering や harness design を超えて、実行基盤設計のフェーズに入ったことを示しています。

Anthropic Managed Agents を「また新しいエージェントサービスが出た」とだけ見ると、たぶん見誤ります。
ここで起きているのは、エージェントを動かす“場”そのものの設計変更です。
プロンプトの次にハーネスが来たのだとしたら、その次に来るのは、ハーネスを安全に差し替え続けられる メタハーネス です。
Managed Agents は、その入口に立った最初の本格実装として見ると、かなり面白い。 

この話を「4回路＋証跡基盤」で読むと

ここで見えてくるのは、Managed Agents が単なるエージェント実行サービスではなく、私が整理している 4回路＋証跡基盤 にかなり近い構造を、実際のプロダクトとして具体化し始めたことです。