Claude Managed Agents実践ガイド — Agent SDKとの違い・コスト設計・3つのデプロイ経路を徹底解説

Managed Agentsとは何か — 4つのコアコンセプト

2026年4月8日、AnthropicがManaged Agentsをパブリックベータとしてリリースした。これまでAgent SDKでエージェントを動かすには、サンドボックス構築・状態管理・プロセス監視を自前で用意する必要があった。Managed Agentsはこれらをクラウド側で丸ごと引き受ける。本記事では、ローカルで動いているAgent SDKエージェントをManaged Agentsに移行する具体的な手順を、Before/Afterのコード付きで解説する。

Agent・Environment・Session・Eventsの関係

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

設計上のポイントはBrain/Hands分離アーキテクチャだ。モデル推論（Brain）はステートレスに動作し、ツール実行（Hands）はサンドボックス内で行われる。ツール実行の待ち時間中にモデルリソースを占有しないため、p50 TTFTで約60%の削減を実現している。

Agent SDKとManaged Agentsの使い分け判断フロー

判断基準はシンプルだ。

• Agent SDKを選ぶケース：ローカル完結で十分、自前のインフラがある、カスタムサンドボックスが必要
• Managed Agentsを選ぶケース：インフラ管理を委任したい、複数セッションを並行実行したい、MCPツールをクラウド側で統合したい

なお、ベータ期間中は全APIリクエストにヘッダ anthropic-beta: managed-agents-2026-04-01 が必須となる。SDKを使う場合は自動付与されるが、REST APIを直接叩く場合は付け忘れに注意してほしい。

コスト設計 — $0.08/session-hourの実際

料金構造の内訳

Managed Agentsの料金はセッション料金 + トークン料金の二本立てだ。

• セッション料金: $0.08/session-hour（ミリ秒単位計測。running状態のみ課金で、アイドル時間は対象外）
• トークン料金: 通常のAPI料金と同一
  • Sonnet 4.6: 入力 $3 / 出力 $15 per MTok
  • Opus 4.6: 入力 $5 / 出力 $25 per MTok

ユースケース別コスト試算

自前でEC2やCloud Runを立てる場合、コンテナ維持だけで月$50〜$100はかかる。セッション数が少ない段階ではManaged Agentsの方がコスト効率がよく、常時稼働エージェントが増えてくると自前運用の損益分岐点に近づく。

3つのデプロイ経路を比較する

Console（GUI）でノーコードデプロイ

Anthropicのコンソール画面からブラウザ上でエージェントを作成できる。Instructions入力、MCPサーバー接続、テスト実行まで画面上で完結する。プロトタイピングには最適だが、設定の再現性が低いため本番運用には向かない。

ant CLIでCI/CDパイプラインに組み込む

正直、この ant CLIが一番実用的だと感じている。Homebrewでインストールでき、YAML設定ファイルでバージョン管理できる。

brew install anthropics/tap/ant

# agent.yaml
name: code-reviewer
model: claude-sonnet-4-6
system: |
  You are a code review assistant.
  Point out bugs, security issues, and style problems.
tools:
  - type: agent_toolset_20260401
environment:
  type: cloud
  networking:
    type: unrestricted

ant beta:agents deploy --config agent.yaml

SDK / REST APIで直接制御する

Python・TypeScript等のSDKからプログラマティックにデプロイする方法。既存のデプロイスクリプトやCI/CDに組み込む場合はこちら。次のセクションで詳しく解説する。

実践：Agent SDKエージェントをManaged Agentsに移行する

Before — Agent SDKでローカル実行しているコード

ローカルでClaude CLIをサブプロセスとして実行する典型的なパターン。slaveのようなシステムではおなじみの構成だ。

import subprocess

def run_agent(prompt: str) -> str:
    result = subprocess.run(
        ["claude", "-p", "--dangerously-skip-permissions"],
        input=prompt,
        capture_output=True,
        text=True,
    )
    return result.stdout

この方式では、プロセス管理・タイムアウト・状態の永続化をすべて自前で実装する必要がある。

After — Managed Agents APIに置き換えたコード

Managed Agentsでは、エージェント作成・セッション開始・イベント受信をAPIで行う。ベータ期間中はすべて client.beta.* 名前空間を使う。

from anthropic import Anthropic

client = Anthropic()

# 1. エージェント定義を作成
agent = client.beta.agents.create(
    name="code-reviewer",
    model="claude-sonnet-4-6",
    system="You are a helpful coding assistant.",
    tools=[{"type": "agent_toolset_20260401"}],
)

# 2. 実行環境を作成
environment = client.beta.environments.create(
    name="review-env",
    config={"type": "cloud", "networking": {"type": "unrestricted"}},
)

# 3. セッションを開始
session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    title="Code review session",
)

# 4. SSEストリーミングでイベントを受信
with client.beta.sessions.events.stream(session.id) as stream:
    client.beta.sessions.events.send(session.id, events=[{
        "type": "user.message",
        "content": [{"type": "text", "text": "Review this Python file for bugs."}],
    }])
    for event in stream:
        match event.type:
            case "agent.message":
                print(event.content)
            case "agent.tool_use":
                print(f"[Tool] {event.name}")
            case "session.status_idle":
                break

セッション永続化とイベントストリーミングの実装

セッションIDを保存しておけば、後から再接続して会話を続けられる。これはローカルCLI実行では実現しにくかった機能だ。

# セッションIDを保存
session_id = session.id  # "session_abc123..." をDBやファイルに永続化

# 後から再接続
with client.beta.sessions.events.stream(session_id) as stream:
    client.beta.sessions.events.send(session_id, events=[{
        "type": "user.message",
        "content": [{"type": "text", "text": "Continue from where we left off."}],
    }])
    for event in stream:
        # 同じイベント処理ロジック
        ...

レート制限はエンドポイントごとに設定されているため、大量のセッションを同時に立ち上げる場合はリトライ処理を入れておくこと。

MCPツール統合とCredential Vault

mcp_serversフィールドでツールを接続する

Managed Agentsは既存のMCPエコシステムをそのまま活用できる。エージェント定義時に mcp_servers を指定するだけでよい。

agent = client.beta.agents.create(
    name="github-assistant",
    model="claude-sonnet-4-6",
    system="You help manage GitHub repositories.",
    mcp_servers=[{
        "url": "https://mcp.github.com/sse",
        "name": "github",
    }],
)

Credential VaultによるOAuth認証管理

外部サービスの認証情報はCredential Vaultで管理する。2つのパターンがある。

• サンドボックス初期化時のクレデンシャル利用: サンドボックス初期化時にクレデンシャルを使ってリソースをセットアップ（例: git cloneトークン）。エージェント自体はトークンに直接アクセスしない
• Vault Proxy: OAuthトークンをVaultに保存し、MCPツール呼び出し時にプロキシ経由で認証。クレデンシャルがサンドボックス内に入らないため、プロンプトインジェクション攻撃によるトークン漏洩を構造的に防げる

この設計思想は地味に重要で、エージェントに強い権限を持たせつつもセキュリティを担保できる仕組みになっている。

ハマりポイントと制限事項

ベータ版の現時点での制約

ベータヘッダの付け忘れが最もよくある初見ミスだ。anthropic-beta: managed-agents-2026-04-01 を全リクエストに付与しないと403が返る。SDKを使えば自動付与されるので、REST APIを直接叩く場合だけ注意すればよい。

その他の制約:

• セッションのアイドル判定は running 状態のみ課金。だがセッションを明示的に終了しないとリソースが残り続ける可能性がある
• Environment起動のオーバーヘッドがあるため、数秒の短いタスクではローカル実行の方が速い
• Outcomes（成果評価）、マルチエージェント連携、Memory機能はまだResearch Previewで一般提供されていない

ベンダーロックインへの対処

Managed Agentsのロジック部分はAnthropicのAPIに依存するが、以下の設計を意識すれば移行リスクを軽減できる。

• エージェント定義をYAMLで管理し、ant CLIでデプロイする（Console上の手動設定に依存しない）
• MCPツールは標準プロトコルなので、他のフレームワーク（CrewAI, LangGraph等）でも再利用可能
• フォールバック層を用意して、API障害時にはAgent SDK（ローカルCLI実行）に切り替えられるようにしておく

まとめ

Managed Agentsは「エージェントのHeroku」とも言える存在で、サンドボックス・状態管理・ツール実行のインフラ層を丸ごと委任できる。Agent SDKで自作エージェントを動かしている開発者にとって、移行は数十行のコード変更で済む。

まずはant CLIかConsoleで小さなエージェントをデプロイし、コスト感とレイテンシを体感するところから始めてほしい。ベータ期間中に本番ワークロードを載せるかは、ベンダーロックインの許容度とコスト試算次第で判断すればよい。