ニュース

Claude Managed Agentsとは?AIエージェント基盤の全貌

この記事の結論

Anthropicが発表したClaude Managed Agentsの仕組み・料金・活用法を解説。gVisor隔離コンテナ、セッション永続化、3層アーキテクチャの技術詳細とOpenAI・Google ADKとの比較も網羅。

2026年4月8日、Anthropicが新サービス「Claude Managed Agents」をパブリックベータとして公開した。一言でいえば、AIエージェントの実行基盤をAnthropicがまるごとホスティングするクラウドサービスだ。

これまでAIエージェントを本番運用するには、自前でコンテナを立て、エージェントループを組み、ツール実行のサンドボックスを用意し、障害復旧の仕組みを作る必要があった。Managed Agentsはこれらすべてを引き受ける。開発者はタスク定義とツール接続だけに集中すればいい。

すでにNotion、Rakuten Group、Asana、Sentry、Allianzが本番環境で利用を開始している。

何が新しいのか ― 従来のAPI呼び出しとの違い

Claude APIを直接叩くのと何が違うのか。ここが最も混乱しやすいポイントだ。

項目 従来のClaude API Claude Managed Agents
実行モデル 1リクエスト=1レスポンス 長時間走り続けるエージェントループ
状態管理 開発者が自前で実装 セッションの永続化・障害復旧を自動提供
ツール実行 Function callingの結果を手動で返す サンドボックス内でコード実行・ファイル操作を自動処理
インフラ 自前のサーバー / コンテナ gVisor隔離コンテナをAnthropic側が自動プロビジョニング
セキュリティ 開発者の責任 クレデンシャルがサンドボックスに到達しない設計
障害時 自前でリトライ/復旧ロジック ハーネスがクラッシュしても wake(sessionId) でイベントログから復旧

要するに、これまで「エージェントを動かすための基盤づくり」に費やしていた工数が、ほぼゼロになる。Anthropicの公式発表では「開発ワークフローを数ヶ月から数週間に短縮する」としている。

アーキテクチャの3層分離

Anthropicのエンジニアリングブログによると、Managed Agentsは内部的に3つのコンポーネントを分離している。

  1. Session(セッション) ― エージェントの全イベントを記録する追記専用ログ。コンテナの外に永続化される
  2. Harness(ハーネス) ― Claudeを呼び出し、ツールコールを適切なインフラにルーティングするループ。ステートレス設計
  3. Sandbox(サンドボックス) ― Claudeがコードを実行しファイルを編集する隔離環境

この分離により、ハーネスがクラッシュしても新しいインスタンスがセッションログから状態を復元できる。コンテナは「ペット」ではなく「家畜」として扱われ、障害時は新しいコンテナを即座にプロビジョニングする設計だ。

# Claude Managed Agents のセッション作成(Python SDK)
# 動作環境: Python 3.11+, anthropic>=0.50.0
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

import anthropic

client = anthropic.Anthropic()

# エージェントセッションを作成
session = client.managed_agents.sessions.create(
    agent_id="agent_abc123",
    instructions="ユーザーの質問に対してコードベースを調査し回答してください",
    tools=["file_read", "file_write", "bash", "web_search"],
    sandbox={
        "type": "container",
        "packages": ["python3", "nodejs", "git"],
        "network": {
            "egress": ["api.github.com", "pypi.org"]  # 明示的に許可
        }
    }
)

# タスクを投入
result = client.managed_agents.sessions.send_message(
    session_id=session.id,
    message="src/auth/ ディレクトリのセキュリティ監査を実行してください"
)

print(result.output)

ポイント:

  • ネットワークアクセスはデフォルト拒否。egress で明示的にドメインを許可する
  • ファイルシステムは書き込み可能な /workspace と読み取り専用の /source にスコープされる
  • クレデンシャル(OAuthトークンやリポジトリトークン)はプロキシ経由でのみアクセスされ、サンドボックス内のコードからは直接参照できない

具体的に何ができるようになるのか

正直、一番気になるのは「で、結局何に使えるの?」という点だろう。

ユースケース1: コードベース調査エージェント

大規模リポジトリをクローンし、コードを読み、テストを実行し、レポートを返すエージェントを、インフラ構築なしで動かせる。Sentryはすでにこのパターンで障害調査の自動化に使っている。

ユースケース2: カスタマーサポート自動化

MCP(Model Context Protocol)経由でCRM、ナレッジベース、チケットシステムに接続し、問い合わせに自律的に対応するエージェント。セッション永続化があるので、長時間にわたる対話も状態を失わない。

ユースケース3: データパイプラインの監視・修復

定期的にデータパイプラインの健全性をチェックし、異常検知時にコードを書いて修復するエージェント。24時間稼働のユースケースだ。

サブエージェント生成(リサーチプレビュー)

現在リサーチプレビューとして提供されている機能に「サブエージェント生成」がある。親エージェントが複雑なタスクを分解し、子エージェントを動的に生成して並列処理させる仕組みだ。Anthropicの内部テストでは、自動プロンプト改善機能と組み合わせることでタスク成功率が最大10ポイント改善したと報告されている。

よくある誤解

誤解1: 「Claude Codeと同じもの?」

Claude Codeはターミナルで動くローカルのコーディングエージェント。Managed Agentsはクラウド上で長時間稼働するエージェントの実行基盤だ。用途が全く異なる。ただしClaude CodeのAgent SDKとManaged Agentsは技術的な基盤を共有しており、@agentclientprotocol/claude-agent-acp は4月だけでv0.25.0からv0.29.2まで4回のマイナーバージョンアップを重ねている。

誤解2: 「OpenAI Agents SDKやGoogle ADKの競合?」

半分正しくて半分違う。OpenAI Agents SDKやGoogle ADKはフレームワーク(SDK)であり、実行インフラは開発者が用意する。Managed Agentsはフレームワーク+インフラのフルマネージドサービスだ。比較するならAWS AgentCoreやGoogle Vertex AIのエージェントホスティングの方が近い。

観点 Claude Managed Agents OpenAI Agents SDK Google ADK
提供形態 フルマネージド(インフラ込み) SDK(インフラ別途) SDK(Vertex AIでホスティング可)
セットアップ タスク定義+ツール指定のみ 数行のコードで起動 柔軟だが設定項目多い
セッション永続化 組み込み済み 自前実装 自前実装
サンドボックス gVisor隔離コンテナ なし(自前) なし(Vertex AIで提供)
MCP対応 ネイティブ 対応 対応
オープンソース × × ○(Apache 2.0)
ベンダーロックイン 高い 中程度 低い

誤解3: 「安いから気軽に使える」

ランタイム料金は$0.08/時間。一見安く見えるが、24時間365日稼働させると月額約$58のランタイム料金がかかる。これにトークン消費量(入出力ともにClaude API標準料金)とWeb検索($10/1,000検索)が加算される。本番環境で複数エージェントを常時稼働させる場合、コストの見積もりは慎重に行う必要がある。

# Managed Agents コスト見積もりスクリプト
# 動作環境: Python 3.11+
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

def estimate_monthly_cost(
    agents: int,
    hours_per_day: float,
    avg_input_tokens_per_hour: int,
    avg_output_tokens_per_hour: int,
    web_searches_per_hour: int = 0,
    model: str = "claude-sonnet-4-6"
):
    """Managed Agents の月額コストを概算する"""
    # ランタイム料金
    runtime_per_month = agents * hours_per_day * 30 * 0.08

    # トークン料金(Sonnet 4.6 の場合)
    token_prices = {
        "claude-sonnet-4-6": {"input": 3.0, "output": 15.0},  # per 1M tokens
        "claude-opus-4-6":   {"input": 15.0, "output": 75.0},
    }
    prices = token_prices.get(model, token_prices["claude-sonnet-4-6"])
    total_hours = agents * hours_per_day * 30
    input_cost = (avg_input_tokens_per_hour * total_hours / 1_000_000) * prices["input"]
    output_cost = (avg_output_tokens_per_hour * total_hours / 1_000_000) * prices["output"]

    # Web検索料金
    search_cost = (web_searches_per_hour * total_hours / 1000) * 10

    total = runtime_per_month + input_cost + output_cost + search_cost
    print(f"月額概算: ${total:,.2f}")
    print(f"  ランタイム: ${runtime_per_month:,.2f}")
    print(f"  入力トークン: ${input_cost:,.2f}")
    print(f"  出力トークン: ${output_cost:,.2f}")
    print(f"  Web検索: ${search_cost:,.2f}")
    return total

# 例: Sonnet 4.6 エージェント3台、1日8時間稼働
estimate_monthly_cost(
    agents=3, hours_per_day=8,
    avg_input_tokens_per_hour=50_000,
    avg_output_tokens_per_hour=10_000,
    web_searches_per_hour=5
)
# → 月額概算: $195.60

パフォーマンスの実力

Anthropicのエンジニアリングブログによると、アーキテクチャの3層分離により大幅なパフォーマンス改善を達成している。

  • TTFT(Time to First Token): p50で約60%改善、p95で90%以上改善
  • 推論はコンテナのプロビジョニングを待たずに即座に開始される
  • コンテナは実際に必要になったタイミングで初めて起動する「遅延プロビジョニング」方式

ただし、これはAnthropic自身のベンチマークであり、実環境でのパフォーマンスはワークロードに大きく依存する。筆者としても、このあたりの数字は自前の検証を経るまで鵜呑みにしない方がいいと考えている。

結局どうすればいいのか

Claude Managed Agentsに向いている人、向いていない人を整理しよう。

向いている場合:

  • エージェントのインフラ構築・運用に工数を割きたくない
  • セッション永続化・障害復旧を自前で実装するのが辛い
  • すでにClaude APIを使っていてベンダーロックインを許容できる
  • MCP対応のツールエコシステムを活用したい

向いていない場合:

  • マルチモデル戦略を取りたい(ClaudeだけでなくGPT-4oやGeminiも使いたい)
  • コスト最適化を最優先したい(Google ADKの方がトークン単価は安い)
  • オンプレミス要件がある(Managed Agentsはクラウドオンリー)
  • 細かいインフラ制御が必要(コンテナの設定はAnthropicのポリシーに依存する)

個人的な見解を述べると、Managed Agentsの本当の価値は「エージェント基盤のコモディティ化」にある。これまでエージェントの本番運用は、大手テック企業か専任SREチームを持つスタートアップにしかできなかった。そのハードルが一気に下がったことの意味は大きい。

一方で、VentureBeatが指摘するように「ベンダーロックインのリスク」は無視できない。エージェントの実行基盤をAnthropicに委ねるということは、料金改定やサービス変更の影響をモロに受けるということだ。まだ明らかになっていない部分も多い。

筆者の推奨は、まず小さなユースケース(社内ツールの自動化、定型レポート生成など)でPoCを回し、コスト構造とパフォーマンス特性を把握してから本番展開を判断することだ。

出典


AIエージェントの構築パターンや設計原則については、AIエージェントのメモリとは?記憶の仕組みと実装法で体系的にまとめています。

あわせて読みたい:


ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。

この記事はAIgent Lab編集部がお届けしました。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年4月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事