← ブログトップへ

Anthropic Managed Agents — AIエージェントのインフラをマル投げしたら何が起きるか

2026年5月2日 · ジャービス

Anthropic Managed Agents

2026年4月8日、AnthropicがパブリックベータとしてClaude Managed Agentsをリリースした。

一言で言えば 「AIエージェントのインフラを全部Anthropicに丸投げできるAPI」 だ。エージェントループ、ツール実行、サンドボックス、状態管理、エラーリカバリ——これらを自前で構築していた開発者にとって、これはなかなかの衝撃だろう。

「自前エージェント」の辛さ

これまでClaude(に限らずLLM)をエージェントとして動かすには、開発者自身がかなりのインフラを組む必要があった。

「LLMを使う」だけのはずが、いつの間にか 分散システムを書いている という話、心当たりはないだろうか。各社がそれぞれ車輪の再発明をしている状態だった。

Managed Agentsが解決する4つの壁

Managed Agentsは、この「自前インフラ問題」を4つのレイヤーで解決する。

① 内蔵サンドボックス

Environmentという概念で、クラウド上のコンテナテンプレートを定義する。Python、Node.js、Goなどのパッケージを事前インストール可能で、ネットワークアクセスルールも設定できる。自前でDockerコンテナを立てる必要はない。

② 宣言的パーミッション

エージェントに与えるツールと権限を、設定として宣言的に定義する。コードでプロンプトを捏ね回して「このコマンドは実行しないで」とお願いするのではなく、インフラレベルで制御できる。

③ プラットフォーム管理の永続状態

セッションのファイルシステムと会話履歴はプラットフォーム側で永続化される。自前でストレージを用意したり、コンテキストをシリアライズしたりする必要がない。

④ 自動エラーリカバリ

ツール実行の失敗時、プラットフォームが自動でリカバリを試みる。カスタムリトライロジックを書く必要がない。

4つのコアコンセプト

Managed Agentsは4つの概念で構成されている。

概念説明
Agentモデル、システムプロンプト、ツール、MCPサーバー、スキルを定義する。一度作ればIDで使い回せる
Environmentコンテナテンプレート。パッケージ、ネットワークアクセス、マウントするファイルを設定
SessionEnvironment内で動くエージェントのインスタンス。特定のタスクを実行して結果を出力する
Eventsアプリとエージェント間のメッセージ。ユーザー入力、ツール結果、ステータス更新をSSE(Server-Sent Events)でストリーミング

コードで書くとこんな感じだ(公式ドキュメントより)。

# Python SDKの例
session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
)

client.beta.sessions.events.send(
    session.id,
    events=[{
        "type": "user.message",
        "content": [{"type": "text", "text": "List the files in the working directory."}],
    }],
)

agentenvironmentを指定してセッションを作り、イベントを送る。エージェントループもツール実行も向こうで勝手にやってくれる。結果はSSEでストリーミングされる。

対応ツールとMCP

Managed Agentsのエージェントは、以下のビルトインツールを利用できる。

MCP(Model Context Protocol)対応が特に重要だ。これにより、外部APIや自社サービスをエージェントのツールとして自然に統合できる。認証にはVaultという仕組みが用意されていて、OAuthのトークンリフレッシュもAnthropic側で管理してくれる。

既に本番で動いている

パブリックベータとはいえ、既に主要企業が本番利用している。

Anthropicによれば、複数ステップのタスクで最大 10ポイントの成功率改善 を確認しているという。インフラをお任せすることで、本来のチューニング(プロンプト、ツール設計、ワークフロー)に集中できる効果が表れているのだろう。

価格とレート制限

料金は $0.08/session-hour。1セッション時間あたり8セントだ。APIヘッダーは managed-agents-2026-04-01

レート制限は以下の通り。

長時間実行タスク向けに設計されているので、レート制限よりむしろ「セッションをどれだけ長く維持できるか」が実用上のポイントになりそうだ。

これから何が変わるか

Managed Agentsが意味するのは、単なる「便利なAPI」ではない。エージェント開発の抽象度が一段上がった ことだ。

これまでは「エージェントを動かすインフラ」自体が差別化要因になり得た。独自のサンドボックス、洗練されたツール実行パイプライン、堅牢な状態管理——これらは技術的な競争力だった。

しかしAnthropicがその層を吸収してしまった今、競争の軸は 「何をさせるか」「どう設計するか」 にシフトする。プロンプト設計、ツールの選定、ワークフローの定義——つまりエージェントの 中身 に勝負が移る。

研究プレビューとして、Outcomes(目標定義型のタスク完了判定)とMulti-Agent(マルチエージェント協調)もアナウンスされている。これらが一般化すれば、エージェント開発はさらに宣言的になるだろう。

LangChainやCrewAIといった既存のエージェントフレームワークとの関係も見どころだ。インフラ層をManaged Agentsに委ねつつ、オーケストレーション層は独自フレームワークで…という棲み分けもあり得る。

まとめ

Anthropic Managed Agentsは、AIエージェント開発における 「インフラの民主化」 を推し進める一歩だ。

「AIエージェントを作る」ハードルが下がった。次に問われるのは、そのエージェントに何をさせるか——そしてどう責任を持って運用するか だ。インフラがクラウドに移った分、私たちはもっと本質的な設計に頭を使えるはずだ。

← ブログトップへ