Claude Managed Agentsとは？機能・料金を解説

Claude Managed Agentsは、Anthropicが2026年4月8日にパブリックベータを開始した、Claudeエージェントをそのままホスト運用できるマネージド型の実行基盤です。

これまで自前で組む必要があった「エージェントループ」「ツール実行サンドボックス」「セッション永続化」「ストリーミング配信」といった運用レイヤを、/v1/agents・/v1/environments・/v1/sessionsを中心とする主要リソースにまとめて任せられるようになりました。


本記事では、Claude Managed Agentsのアーキテクチャと4つのコア概念、クイックスタート、Notion・楽天・Asanaといった先行事例、そして料金体系までを、公式ドキュメントとAnthropicのエンジニアリングブログをもとに整理します。

Claude Agent SDK・Messages APIとの使い分け、他社マネージドエージェント基盤との比較まで網羅しているので、自社でエージェント運用に踏み切るかどうかの判断材料にしてください。

Claude Managed Agentsとは？

Claude Managed Agents（クロード・マネージド・エージェンツ）は、Anthropicが2026年4月8日にパブリックベータを公開した、Claudeエージェントをそのままホスト運用できるマネージド型の実行基盤です。

これまでClaudeでエージェントを作る場合、開発者は「Claudeを呼び出すループ」「ツール実行用の隔離サンドボックス」「セッション履歴の永続化」「ストリーミング配信のインフラ」をすべて自前で用意する必要がありました。

Claude Managed Agentsは、この一連の"エージェントハーネス"とクラウドコンテナをAnthropic側に委ねる選択肢を提供するもので、開発者は「エージェントの設計」と「アプリケーション側の統合」にリソースを集中できます。

APIの中心になるのは/v1/agents・/v1/environments・/v1/sessionsの3つのリソースで、それぞれの役割と使い方は後述の「4つのコア概念」と「クイックスタート」で順に解説します。

Claude Agent SDK・Messages APIとの位置づけ

Claudeでエージェントを組む方法は大きく3つに分かれ、それぞれレイヤーが異なります。

この違いを最初に整理しておかないと、「Messages APIで十分な用途にManaged Agentsを使ってオーバースペックになる」「SDKで組むべき要件をManaged Agentsに押し付ける」といった設計ミスが起きやすいポイントです。

以下の表で、3つのアプローチの役割分担を並べて整理しました。

この比較から読み取れるのは、Messages APIが「Claudeとの会話」レイヤ、Agent SDKが「エージェントの組み立て方」レイヤ、Managed Agentsが「エージェントを動かすプラットフォーム」レイヤという役割分担になっている点です。

Managed Agentsは上位ラッパーではなく、同じClaudeプラットフォーム上の別オファリングとして位置づけられています。

【関連記事】
Claude Codeとは？主な特徴や使い方、料金体系・拡張機能まで徹底解説

なぜClaude Managed Agentsが必要なのか？

エージェントを本番運用しようとすると、モデル呼び出しそのものよりも「周辺の運用レイヤ」で時間を溶かしがちです。Claude Managed Agentsは、この運用レイヤをまとめて引き受けるために設計されています。

自前運用で時間を溶かす3つのポイント

AIエージェントを自社インフラで動かす場合、開発者は典型的に以下の3つの問題に直面します。

• インフラ構築の重さ
  ツール実行用にセキュアなコンテナを用意し、ネットワーク制御やファイルシステムの隔離を設定する必要があります。単純なDockerでは不十分で、エージェントの暴走を防ぐサンドボックス設計が欠かせません。
  
  
• 状態管理の複雑さ
  エージェントが途中でクラッシュしたときに、どこまで進んだかを取り戻す仕組みが必要です。会話履歴・ツール呼び出し履歴・ファイル状態をすべて整合的に復元するのは簡単ではありません。
  
  
• エラーリカバリーと監視
  ハーネスのプロセス落ち、タイムアウト、モデルAPIの断続的な失敗、ツール側の障害など、復旧すべき障害点が多く、本番運用ではモニタリングと再実行ロジックをセットで設計しなければなりません。
  
  

Anthropicのエンジニアリングブログ「Scaling Managed Agents: Decoupling the brain from the hands」では、これらの課題を「プログラムとして汎化しにくい領域」と表現しており、OSがかつてハードウェアを仮想化したのと同じ構図でエージェントランタイムを抽象化すべきだと述べています。

Brainとhandsを分離する設計思想

Anthropicが今回採用したのは、エージェントの"脳"（Claude本体）と"手"（コンテナ内で動くツール実行）を疎結合に分離する設計です。
ハーネスはコンテナの内側ではなく外側に置かれ、「execute(name, input) → string」という標準インタフェース経由で各コンテナを呼び出します。

この分離により、ハーネス側がクラッシュしても「wake(sessionId)」で新しいハーネスをブートストラップし、永続化されたgetEvents相当のAPIからイベントログを取得してそのまま再開できます。コンテナも「手塩にかけて育てるペット」ではなく「いつでも差し替え可能な家畜」として扱えるようになり、必要なときだけ必要な数だけプロビジョンできます。

Anthropic自身の計測によれば、この設計の導入でエージェントのTTFT（Time-To-First-Token）がp50で約60%、p95で90%以上短縮されたと報告されています。

これは単なる設計美学ではなく、長時間エージェントをコスト効率よく運用するための実装上の必然でもあります。

Claude Managed Agentsの4つのコア概念

Claude Managed Agentsを理解するうえで押さえておくべき概念は、公式ドキュメントで明示されている以下の4つです。どれもシンプルですが、APIの設計そのものがこの4概念に沿って分かれているので、最初に頭に入れておくと学習コストが大幅に下がります。

以下の表で、4つのコア概念と役割を整理しました。

この4分類のポイントは、Agentを「再利用可能な型」、Sessionを「使い捨てのインスタンス」として分離していることです。考え方としては、OpenAIのAssistants APIで言うAssistant/Threadの関係に近い構図ですが、Assistants APIは2026年8月26日にシャットダウン予定でResponses APIへの移行が公式に推奨されているため、現時点で類比として使う際は参考程度に留めておくのが安全です。

Environmentという実行コンテナの概念が別レイヤで分離されている点は、Managed Agents独自の設計です。

Agent：再利用可能なエージェント定義

Agentは、モデルID・システムプロンプト・利用可能ツール・MCPサーバー・Skillsを束ねた「設定オブジェクト」です。一度/v1/agentsで作成したAgentはIDとバージョンを持ち、その後のすべてのセッションから同じIDで呼び出せます。

バージョン管理されているので、プロンプトを更新したいときは新しいバージョンを作ってアプリ側の参照を切り替えるだけで、過去セッションへの影響を出さずに運用できます。

Environment：実行コンテナのテンプレート

Environmentは、Claudeが実際にコードを走らせるクラウドコンテナの仕様書です。ネットワークアクセスの許可範囲（unrestricted／許可リスト方式）や、事前インストールするパッケージ、マウントするファイルを指定します。

クイックスタートの最小構成では、名前と「type: cloud」「networking.type: unrestricted」だけでテンプレートを作れます。本番運用では、外部APIへのアクセスをホワイトリスト方式で絞ったり、必要なファイルをマウントしたり、追加のランタイムやツールを仕込んだりといった設定を加えていく流れです。

Session：実行中のエージェントインスタンス

Sessionは、「このAgentをこのEnvironmentで動かす」という指定で起動される実行中のインスタンスです。
永続的なファイルシステムと会話履歴を持ち、複数のユーザー発話にまたがって状態を保ちます。

セッションの特徴は、履歴がサーバー側で全量永続化される点です。Claudeのコンテキストウィンドウに収まらなくなった古いイベントも、セッションイベント取得APIで取り出して参照できるため、長時間タスクや「数日前の作業の続き」といったユースケースにも対応できます。

Events：アプリとエージェントの対話チャネル

EventsはWebSocket的なチャネルというより、**追記専用のログ（append-only log）**として設計されています。アプリからの「user.message」、モデルからの「agent.message」「agent.tool_use」、そしてエージェントが処理を終えたことを示す「session.status_idle」といったイベントが時系列に並びます。

この「イベントをそのまま時系列ログとして保存する」設計は、前述のハーネスクラッシュ時の復旧や、後からセッションの挙動を監査する用途にも直結しています。

Claude Managed Agentsのアーキテクチャ

Claude Managed Agentsの設計思想は、Anthropicのエンジニアリングブログ「Scaling Managed Agents」に詳しく書かれています。ここでは、開発者が知っておくべきアーキテクチャ上の要点を3つのコンポーネントと1つの境界に整理して紹介します。

セッション・ハーネス・サンドボックスの3層構造

Claude Managed Agentsのランタイムは、以下の3つのコンポーネントがそれぞれ独立したインタフェースでつながる構造になっています。

• Session（セッション層）
  起きたイベントをすべて追記する「append-onlyログ」。ハーネスの外側に永続化されており、ハーネスが落ちても失われません。
  
  
• Harness（ハーネス層）
  Claudeを呼び出し、返ってきたツール呼び出しを適切なインフラにルーティングするループ。サンドボックスの外側に配置されており、「execute(name, input) → string」というシンプルなインタフェースでコンテナを操作します。
  
  
• Sandbox（サンドボックス層）
  Claudeが実際にコードを実行し、ファイルを編集する隔離環境。コンテナとして必要なときに立ち上がり、役割を終えたら破棄されます。
  
  

この3層分離が重要なのは、各層を個別に差し替えられるからです。新しい実行環境（たとえばGPU付きコンテナ）を追加したいとき、ハーネスやセッションの実装を変えずにSandbox層だけ拡張できます。

逆にモデルを差し替えたいときはHarness層の設定だけ変えれば済みます。

認証情報をサンドボックスの外に置く

セキュリティ上、もっとも重要な設計判断が**「認証情報はClaudeが動くサンドボックスの内側に渡さない」**という原則です。エージェントのコードが暴走した場合でも、クレデンシャルが盗まれるリスクを最小化する構えです。

公式ブログでは、認証を扱うパターンとして以下が紹介されています。

• サンドボックス初期化時にリソースごとバンドルして埋め込む（セッション限定のトークン）
• OAuthトークンをサンドボックス外のセキュアなVaultに保管し、Proxy経由で取得
• MCPツール呼び出しの際にだけ、Proxyサービスが必要な認証情報をフェッチして付与

どのパターンを選ぶにせよ、Claudeが動くコンテナの環境変数やファイルシステムに直接APIキーを置かない、という原則は共通です。

外部コンテキストとしてのセッション

従来のClaudeエージェントでは、長時間動かすうちにコンテキストウィンドウが枯渇し、要約や切り詰めでしのぐ必要がありました。Managed AgentsのセッションはClaude自身が問い合わせられる外部コンテキストとして設計されており、イベント取得APIを介して過去のイベントを任意の位置から取り直せます。

この違いが効いてくるのは、たとえば「数百回のツール呼び出しをした後に、数時間前の決定の根拠を確認したい」といったケースです。従来ならコンテキストから消えていた情報を、セッション経由で取り戻してから次の意思決定に使えるようになります。

スケーリング特性

Brain／Hands分離の直接的な成果として、Anthropicは以下の数値を公表しています。

• TTFT（最初のトークンが返るまでの時間）: p50で約60%短縮、p95で90%以上短縮
• コンテナは必要になったときだけプロビジョンされるため、常駐分のコストが不要
• 1つのBrainから複数のHandsを呼び分けたり、複数Sessionsに同じHandを渡したりといった柔軟な配置が可能

これらの数値はAnthropic公式エンジニアリングブログで公開されているもので、実運用時のレイテンシ削減効果を根拠づけるデータとして参照できます。

Claude Managed Agentsで使えるツールと拡張性

Claude Managed Agentsは、Agent定義に「toolset」を指定することで、Claudeがその場で使える操作一式を有効化します。

公式ドキュメントのToolsページに、2026年4月時点で利用可能な組み込みツールと設定方法がまとまっています。

組み込みツールセット

ツールタイプに「agent_toolset_20260401」を指定すると、以下の組み込みツールが一括で有効化されます。いずれもClaude Codeで見慣れた操作と同じ粒度で設計されており、コンテナ内のファイルシステムとシェル、そして外部Web情報にアクセスできます。

以下の表で、組み込みツールの一覧と役割を整理しました。

この一覧で押さえておきたいのは、コード実行系（bash）とファイル操作系（read/write/edit/glob/grep）が最初から揃っている点です。

これらはすべてコンテナ内で完結するため、ファイル編集や依存ライブラリのインストール、スクリプト実行といった操作をClaude自身が完遂できます。Web系の2ツールは外部情報の取り込みに使え、たとえば「最新のライブラリドキュメントを調べて実装に反映する」といった自律タスクが現実的になります。

特定ツールだけを有効化する

全ツール有効化ではリスクが大きい場合、「default_config.enabled」をfalseにしてから必要なツールだけを個別に有効化できます。たとえば「コード実行はさせるがWebは一切触らせない」といった厳しい権限設計も可能です。

{
  "type": "agent_toolset_20260401",
  "default_config": { "enabled": false },
  "configs": [
    { "name": "bash", "enabled": true },
    { "name": "read", "enabled": true },
    { "name": "write", "enabled": true }
  ]
}

このような設定にしておくと、シェル・読み取り・書き込みの3つだけが有効化され、その他の組み込みツールはすべて封じられます。本番運用では、タスクに必要な最小権限の組み合わせを見極めて絞り込む運用が推奨されます。

カスタムツールとMCPサーバー連携

組み込みツールに加えて、カスタムツールとMCPサーバーの2つの拡張ポイントが用意されています。カスタムツールはMessages APIのユーザー定義ツールと同じ考え方で、アプリケーション側で処理を実装し、Claudeからは入力スキーマと説明だけで呼び出せます。

MCP（Model Context Protocol）サーバーを接続すれば、Notion・Slack・GitHub・社内DBなど既存のMCPエコシステムをそのままエージェントの"手"として流用できます。公式ドキュメントでは、カスタムツール設計のベストプラクティスとして「詳細な説明文を最低3〜4文書く」「関連操作は1つのツールに統合する」「ツール名にリソース名のプレフィックスを付ける」といった指針も示されています。

レート制限と組織設定

Managed Agents全エンドポイントには、組織単位でレート制限がかかっています。本番設計では、この上限を踏まえたリクエスト設計とリトライ戦略が必要になります。

以下の表で、2026年4月時点の公式レート制限を整理しました。

この制限はあくまでManaged Agents APIの話で、組織単位のスペンド上限やClaude APIのティア別レート制限は別途かかります。大量のセッションを並列で起動する設計にするなら、作成系エンドポイントの60req/minをボトルネックとして意識しておく必要があります。

Claude Managed Agentsのクイックスタート

実際にClaude Managed Agentsを動かしてみる流れを、公式クイックスタートに沿って整理します。Python SDKを例にしますが、TypeScript・Go・Javaなどでも同じ4ステップで動作します。

事前準備：SDKとCLIのインストール

まず環境を整えます。Python SDKはpipで1行で入ります。CLIツール「ant」も入れておくと動作確認が楽になり、公式クイックスタートではmacOS向けのHomebrew、Linux／WSL向けのcurl、Goユーザー向けのgo installの3系統が案内されています。

# Python SDKのインストール
pip install anthropic

# CLIツール（macOS / Homebrew）
brew install anthropics/tap/ant
xattr -d com.apple.quarantine "$(brew --prefix)/bin/ant"

# CLIツール（Linux / WSL / curl）
curl -fsSL https://platform.claude.com/install/ant.sh | sh

# CLIツール（Go環境がある場合）
go install github.com/anthropics/ant@latest

# APIキーを環境変数にセット
export ANTHROPIC_API_KEY="your-api-key-here"

APIキーはClaude Consoleから発行しておきましょう。SDKを使う限り、ベータヘッダの付与は自動で行われるため、自分でヘッダ名を書く必要はありません。

ステップ1：Agentの作成

最初に/v1/agentsでエージェント定義を作成します。Python SDKだと以下のようになります。

from anthropic import Anthropic

client = Anthropic()

agent = client.beta.agents.create(
    name="Coding Assistant",
    model="claude-sonnet-4-6",
    system="You are a helpful coding assistant. Write clean, well-documented code.",
    tools=[
        {"type": "agent_toolset_20260401"},
    ],
)

print(f"Agent ID: {agent.id}, version: {agent.version}")

このアプローチの利点は複数あります。1つ目は、戻り値のagent.idが得られた時点で再利用可能なエージェント定義として保存される点です。2つ目は、toolsに「agent_toolset_20260401」と書くだけで、前述のbash/read/write/edit/glob/grep/web_fetch/web_searchがすべて有効化される点で、個別にツールを書き起こす必要がありません。

ステップ2：Environmentの作成

次に、Agentが実行される環境を/v1/environmentsで作成します。最小構成ではネットワーク無制限のクラウドコンテナを指定するだけでOKです。

environment = client.beta.environments.create(
    name="quickstart-env",
    config={
        "type": "cloud",
        "networking": {"type": "unrestricted"},
    },
)

print(f"Environment ID: {environment.id}")

本番運用では、networking設定を許可ドメインリスト方式に切り替えたり、特定パッケージを事前インストールするよう指定したりします。クイックスタートではまず「動かすこと」を優先するためunrestrictedで問題ありません。

ステップ3：Sessionの起動

AgentとEnvironmentが揃ったら、それらを組み合わせたSessionを作成します。

session = client.beta.sessions.create(
    agent=agent.id,
    environment_id=environment.id,
    title="Quickstart session",
)

print(f"Session ID: {session.id}")

セッションIDが返ってきた時点では、まだセッションの「箱」が用意されただけの状態です。コンテナの厳密な起動タイミングは公式ドキュメントとcookbookの間で表現に揺れがあるため断定はしませんが、料金面では明確で、セッション稼働時間課金は「running」状態の間だけ発生し、アイドル時間は課金対象外です。実運用上は「session.create直後のidle状態では課金されず、実際に処理が走っている間だけ加算される」と理解しておけば見積もりに困りません。

ステップ4：メッセージ送信とストリーミング

最後に、セッションにユーザーメッセージを送り、SSEストリームで応答を処理します。

client.beta.sessions.events.send(
    session.id,
    events=[
        {
            "type": "user.message",
            "content": [
                {
                    "type": "text",
                    "text": "Create a Python script that generates the first 20 Fibonacci numbers and saves them to fibonacci.txt",
                },
            ],
        },
    ],
)

with client.beta.sessions.events.stream(session.id) as stream:
    for event in stream:
        match event.type:
            case "agent.message":
                for block in event.content:
                    print(block.text, end="")
            case "agent.tool_use":
                print(f"\n[Using tool: {event.name}]")
            case "session.status_idle":
                print("\n\nAgent finished.")
                break

このコードを実行すると、Claudeがコンテナ内でPythonスクリプトを書き、bashで実行し、生成されたfibonacci.txtを確認するところまでを自律的に行い、最後に「session.status_idle」イベントで処理完了を通知します。

詰まりポイント：ストリームと送信の順序

クイックスタートで最初に押さえておきたいのが、ユーザーメッセージの送信とストリーム接続の順序です。公式情報源ごとに推奨が分かれているので、両方を理解しておくと迷いません。

公式のQuickstartでは、HTTPベースのクライアントを前提に「user eventを先にsendしてから、その後にstreamで接続しても、Claude Managed Agents APIは接続が確立されるまでイベントをバッファするため取りこぼさない」と説明されています。上記のPythonサンプルもこの順序で記述しています。

一方、公式のCookbook（Iterate to fix failing tests）では、より安全なパターンとして「先にstreamを開いてから内側でsendする」実装が推奨されています。先にsendしてからstreamを開く順序にはレースウィンドウが生じる可能性があり、初手のイベントを取りこぼすリスクをゼロにしたいなら、cookbookのstream-firstパターンに寄せておくのが堅実です。

実装方針としては、HTTPで素直に書きたいときはsend-first、Python/TypeScript SDKのコンテキストマネージャを使うときはstream-first、と書き分けるのがおすすめです。

もうひとつよくハマるのが、「agent_toolset_20260401」の中の特定ツールだけを絞りたい場合に、default_configをfalseにし忘れてconfigsだけで無効化しようとするパターンです。

configsは既定の有効化状態を上書きする仕組みなので、「全部オフから必要なものだけオン」にしたい場合はdefault_configを先に切る必要があります。

Claude Managed Agentsの導入事例

Claude Managed Agentsは、パブリックベータ公開時点ですでに複数のエンタープライズ企業で採用が進んでいます。

公式ブログと各社のコミュニケーションから、代表的な導入パターンを整理します。

Notion：ワークスペース内エージェント

Notionは、Claude Managed Agentsを自社のNotion Custom Agents（プライベートアルファ）に統合し、ユーザーがワークスペース内から直接Claudeにタスクを委譲できるようにしました。エンジニアはコードの出荷に、ナレッジワーカーはWebサイトやプレゼン資料の生成に、それぞれ同じエージェント基盤を活用しています。

Anthropic公式発表では、Managed Agentsを利用することでプロトタイピング速度が大幅に短縮されたことが示唆されています。これは単なる時間短縮ではなく、「プロトタイプの試行回数を増やせる」という意味で、プロダクト開発サイクル全体の密度を上げる効果につながります。

楽天：全社横断のエンタープライズエージェント

楽天は、Claude Managed Agentsを使ってプロダクト・セールス・マーケティング・ファイナンスにまたがるエンタープライズエージェントを構築し、各specialist agentを1週間以内のスピードで展開しています。社員はSlackやTeamsからタスクを割り当てるだけで、エージェント側がスプレッドシートやスライドなどの成果物を返す運用です。

通常であれば各部門ごとに個別のAIツール導入プロジェクトを走らせる必要があるところを、共通のManaged Agents基盤に統合することで部門横断のデプロイ速度を上げているのがポイントです。

Asana：プロジェクト管理にAI Teammatesを組み込む

Asanaは、Claude Managed Agents上にAI Teammatesと呼ばれるエージェント群を構築し、既存のプロジェクト管理ワークフローに組み込んでいます。人間と並んでタスクをピックアップし、ドラフト作成や成果物作成を担当する設計で、チームの報告によれば「高度な機能を追加するスピードが従来より劇的に速くなった」と評価されています。

Vibecode・Sentry：スタートアップ／開発者ツールでの採用

公式ブログでは上記3社以外にも、AIネイティブアプリ構築プラットフォームのVibecodeがManaged Agentsをデフォルト統合として採用し、エラートラッキングのSentryが自社のデバッグエージェントとClaude製のパッチ書き込みエージェントを組み合わせる事例が紹介されています。

事例から読み取れる傾向

これらの事例には、「エージェント基盤を共通化することで横展開速度を上げる」という共通点があります。自社プロダクトに組み込む場合（Notion・Vibecode）でも、社内の業務自動化に使う場合（楽天・Asana）でも、インフラ層をManaged Agentsに寄せることで本来注力したい"エージェントの設計"や"業務プロセスへの統合"に時間を割けるようになっている構図です。

もしあなたのチームが「社内の1部門のAI活用から始めてみたいが、インフラ構築で止まっている」状態なら、まず1つの業務に絞ってManaged Agentsで動かしてみるのが合理的な第一歩です。楽天がspecialist agentを1週間以内で展開している事実は、少人数のチームでも十分現実的なタイムラインで導入できることを示しています。

Claude Managed Agentsと他サービスの比較

Claude Managed Agentsと似た位置づけのサービスは複数あります。ここではAnthropic社内の別オファリングと、他社のマネージドエージェント基盤の両方を並べて比較し、選定の判断材料にできる情報を整理します。

Anthropic社内の3選択肢

まず、同じClaudeを使う3つのアプローチを改めて並べて整理しておきましょう。

この比較で押さえたいのは、Messages APIとManaged Agentsは競合ではなく棲み分けだという点です。

同じアプリケーション内で、ユーザー向けのチャットはMessages APIで、バックエンドの長時間自動化タスクはManaged Agentsで、というハイブリッド構成が自然な着地点になります。

他社のマネージドエージェント基盤との比較

2026年4月時点で、主要クラウドベンダーもそれぞれマネージドエージェント基盤を提供しています。Claude Managed Agentsと並べて見ると、位置づけの違いが明確になります。

以下の表で、主要な4つのマネージドエージェント基盤を整理しました。

この比較から読み取れる特徴は、Managed Agentsが「モデル提供元が直接ハーネスとサンドボックスも提供する」アプローチである点です。

Bedrock AgentsやFoundry Agent Serviceはクラウドベンダーがまとめ役になる構造で、OpenAI AgentKitはUI層まで含むパッケージの色が強いのに対し、Managed Agentsは**APIとSDKを軸とした"開発者向けの素材感"**が強めに出ています。

どれを選ぶべきか

選定で迷ったときは、以下のような判断軸を置くのが実務的です。

• すでにClaudeをメインで使っている／Claude Codeを開発に入れているなら、エージェント側もManaged Agentsに寄せる方が統合コストが低い
• 組織のクラウドがAWS／Azureに固定されており、IAMやデータソース統合を重視するならBedrock Agents／Foundry Agent Serviceを選ぶ
• GUI中心でエージェントを組み立てたい非エンジニアが主要ユーザーならOpenAI AgentKitのAgent Builderが有利

いずれの選択をするにしても、Managed Agentsは**「APIとSDKだけで本番運用まで持っていける軽さ」**が他と比べた相対的な強みです。既存のClaude利用があるなら、まず1タスク分の自動化をManaged Agentsで組んでみて、運用負荷を肌で確かめるのが遠回りしない道筋になります。

【関連記事】
AIエージェント(AI agent)とは？その仕組みや作り方、活用事例を解説

Claude Managed Agentsの制限と導入判断で詰まる論点

本番運用を前提に検討するなら、現時点での制限事項とリスクも正直に押さえておく必要があります。Claude Managed Agentsはパブリックベータというステータスであり、仕様変更や追加制約が発生する前提で設計した方が安全です。

パブリックベータの前提

2026年4月時点で、Managed Agentsはすべてのエンドポイントがベータヘッダ「managed-agents-2026-04-01」で保護されています。

Anthropicの公式ドキュメントでも「リリース間で出力を改善する目的で動作が調整される可能性がある」と明記されており、プロンプトや応答のわずかな挙動差は許容する設計にしておくのが前提です。

加えて、以下の3機能はさらに一段階制限の強いリサーチプレビューとして提供されており、利用には別途アクセス申請が必要です。

• Outcomes: エージェントの結果品質をAnthropic側の自己評価ループで改善する機能
• Multiagent: 複数のエージェントを連携させて1つのタスクを解かせる機能
• Memory: セッションをまたいで長期記憶を保持する機能

本番で頼りきるには早い機能群ですが、今後のロードマップを占う材料としてウォッチしておく価値があります。

ベンダーロックインの現実

マネージド型基盤を選ぶ上で避けて通れないのが、ベンダーロックインのリスクです。

Session・Environment・Agentという独自データモデルでエージェントを組み上げると、他プラットフォームへ移行する際には相当量の書き直しが発生します。

一方で、Anthropicはエンジニアリングブログで**「ハーネスのインタフェースは将来のモデルに対しても安定させる」**と明言しており、最低限Claude側の進化には透過的に追従する設計になっています。

社内のエージェント資産のうち、どの層をポータブルに保つべきか（アプリケーション層とエージェント定義は分離しておく等）を最初に決めておくと、ロックインの痛みを和らげられます。

導入判断で詰まる論点

概念や料金を読み終えた後、多くのチームが迷うのは「結局、自前で組むのとManaged Agentsに寄せるのと、どちらを選ぶか」という論点です。AI総合研究所の支援経験から、以下の判断軸を推奨しています。

• エージェントを1〜2個しか動かさない／処理時間が数十秒以内
  Messages APIで自前ループを書く方が圧倒的に軽い。Managed Agentsはオーバースペックになりやすく、料金面でもメリットが薄いです。
  
  
• 長時間タスク・複数エージェント・並行セッションを運用したい
  Managed Agentsへの移行を真剣に検討すべきフェーズ。自前で同等のハーネスを組むと、運用コストとバグ率が跳ね上がります。
  
  
• 社内にエージェント運用の専門チームがない
  Managed Agentsに寄せて、チームのリソースはビジネスロジックとエージェント設計に集中させるのが合理的です。
  
  
• クラウドベンダーとの密結合（AWS／Azure）が前提
  Bedrock AgentsやFoundry Agent Serviceの方が、IAM・データソース統合の面で有利なことがあります。
  
  

迷ったときの現実的な進め方は、**「自前運用中のエージェントのうち、もっとも運用負荷が高い1つをManaged Agentsに移植してみる」**ことです。1週間〜2週間の検証で、ハーネス運用からの解放と料金の実態が見えるので、そこから全体移行の判断ができます。

Claude Managed Agentsの料金体系

Claude Managed Agentsの料金は、標準のClaudeトークン料金に加えて、セッションのアクティブ実行時間に対する時間課金という2軸の構成です。

公式ドキュメントと複数の一次情報をもとに、2026年4月時点の料金ルールを整理します。

料金体系の構成要素

料金の構成は以下の2つに分かれます。

• トークン従量課金
  Claude Platformの標準モデル料金がそのまま適用されます。

Sonnet 4.6なら入力100万トークンあたり3ドル・出力100万トークンあたり15ドル、Opus 4.6なら入力100万トークンあたり5ドル・出力100万トークンあたり25ドル、といった具合に、Messages APIで使う場合とまったく同じ単価です。

• セッション稼働時間課金
  セッションがアクティブに実行している時間に対して、1時間あたり0.08ドルが課金されます。
  この課金はミリ秒単位で計測され、アイドル時間（次のユーザーメッセージやツール確認を待っている時間、キューに並んでいる時間）は課金対象外です。
  
  

加えて、セッション内から組み込みのweb_searchツールを使った場合は、Claude Platform標準のWeb検索料金（1,000回あたり10ドル）が別途かかります。プラットフォーム利用料や別途のアクセス料金はありません。

価格例

2026年4月時点の料金を前提に、いくつかの実例で費用感を掴んでおきましょう。

• 1時間の単発セッション（Opus 4.6、入力5万トークン・出力1.5万トークン）
  トークン料金（5万×5/100万＋1.5万×25/100万＝約0.625ドル）＋稼働時間料金（0.08ドル）で、合計約0.70ドル/セッション。
  
  
• カスタマーサポート用エージェント（1チケットあたり約20分のアクティブ時間）
  稼働時間料金は20分÷60分×0.08ドル＝約0.027ドル/チケット。トークン料金は複雑度により0.10〜0.50ドル程度が目安です。
  
  
• 24時間常駐エージェント（稼働時間のみ）
  0.08ドル×24時間×30日＝月間約58ドル（トークン料金別）。ただし、実運用ではアイドル時間が課金外なので、タスク処理中のみカウントすれば実支払いはさらに下がります。
  
  

この価格例から読み取れるのは、アイドル時間が課金されない設計がバースト型ワークロードに有利に働く点です。

常駐させるのではなく、リクエストが来たときだけ処理する設計にすれば、実質的な時間課金はアクティブ実行時間だけで済みます。

料金最適化のヒント

以下の設計を取り入れると、Managed Agentsの料金をさらに最適化できます。

• モデル選定: 精度要件を満たすならSonnet 4.6を優先し、Opus 4.6は難易度の高いタスクだけに限定する
• アイドル時間の活用: セッションを常駐させず、ユーザー入力待ちの時間はセッションを閉じずに待機させる
• ツール絞り込み: 使わないツールを無効化し、不要なツール呼び出しによるトークン消費を抑える
• Web検索の制御: 1,000回10ドルの単価を踏まえ、キャッシュ可能なクエリはアプリケーション側で再利用する

料金体系が透明で「アクティブ時間×0.08ドル＋トークン従量」というシンプルな構造なので、実運用コストの見積もり自体は非常に立てやすい設計になっています。

Claudeエージェントを自社テナント内で業務に組み込むなら

Claude Managed Agentsはエージェント実行基盤の運用負荷を一気に下げてくれる一方で、Anthropic側のクラウドにエージェントが置かれる構成です。

エンタープライズで本番展開する段では「データは自社のAzureテナント内に閉じ込めたい」「業務システム連携・権限・実行ログを自分たちのガバナンス下に置きたい」というもう一段のハードルが出てくるケースも少なくありません。

AI Agent Hubは、ClaudeをはじめとするLLMを活用した業務エージェントを、Azure Managed Applicationsとして自社テナント内に構築するエンタープライズAI基盤です。
Managed Agentsで検証したエージェント設計を、自社環境に閉じ込めた形で本番運用へ移植する選択肢として位置づけられます。

• 設計はManaged Agentsで検証、本番は自社テナント内へ
  プロトタイプはManaged Agentsで素早く回し、本番運用フェーズで自社のAzureテナント内に再構築するハイブリッドな進め方を支援します。
  Anthropic側に置けないデータや、社内ポリシーで外部実行が許されない業務でも、同じエージェント設計を持ち込めます。
  
  
• SAP・Salesforce・Microsoft 365などの基幹システム接続をセットで構築
  SAP Concur／freee会計／Dynamics 365／Salesforce／Oracle NetSuiteといった標準連携に加え、要件に応じたAPI接続の設計と構築まで伴走します。
  Managed Agents単体では別途作り込みが必要な業務システム接続を、基盤としてまとめて提供します。
  
  
• Teamsから呼び出し、実行ログと権限を1画面で集約
  社員はTeamsチャットからエージェントにタスクを依頼するだけ。実行ログ・アクセス権限・セキュリティチェックを1つのダッシュボードに集約できるため、複数のエージェントが乱立しても、ガバナンス観点では1つの基盤として統制できます。

AI総合研究所は、Microsoft MVP／Solution Partner認定のチームが、Managed Agentsで検証したClaudeエージェントを自社テナント内の本番運用までつなぐ設計を伴走支援しています。

「自前運用は重い、でもAnthropic側に全部預けるのは難しい」というハイブリッドな悩みをお持ちの方は、まずは無料の資料でAI Agent Hubの全体像をご確認ください。

Claudeエージェントを自社テナント内で動かす

Managed Agentsで検証したエージェントを自社環境の本番運用へ

Claude Managed AgentsはAnthropic側のクラウドで動くため、データを自社に閉じ込めたい業務では別の選択肢が必要になります。AI Agent Hubは、Managed Agentsで検証したエージェント設計を自社のAzureテナント内に再構築し、SAPやSalesforceとの接続・実行ログ・権限管理まで一元化するエンタープライズAI基盤です。

▶ 無料で資料をダウンロード

まとめ

本記事では、Claude Managed Agentsのアーキテクチャ・コア概念・使い方・導入事例・料金体系・制限事項を一通り整理しました。2026年4月8日にパブリックベータが公開されたこのサービスは、Claudeでエージェントを本番運用するうえでの運用レイヤを一気に引き受けてくれる選択肢として、既存のMessages APIやClaude Agent SDKと補完関係を持つ位置づけです。

重要なポイントを改めて押さえておくと、以下の3点に集約されます。

• アーキテクチャ: Session／Harness／Sandboxを分離する設計により、ハーネスクラッシュ時の復旧、コンテナのプロビジョン最適化、認証情報の安全な隔離を同時に実現している
• 料金: トークン従量＋セッション稼働時間1時間あたり0.08ドルという透明な2軸構成。アイドル時間が課金外なので、バースト型ワークロードほどコスト効率が高い
• 選定基準: Messages APIで自前ループを書くのが重くなってきたタイミング、もしくは長時間・複数並行のエージェントを運用したいタイミングが、Managed Agentsへ移行する判断点

次の一歩としておすすめなのは、自社で動かしているもっとも運用負荷の高いClaudeエージェントを1つ選び、クイックスタートに沿ってManaged Agentsに移植してみることです。1〜2週間の検証で、ハーネス運用から解放される感覚と、実運用時の料金が肌感覚で掴めます。そこから全体移行の判断をしても遅くありません。

まだAIエージェントの全体像から押さえたい方は、AIエージェント(AI agent)とは？その仕組みや作り方、活用事例を解説や自律型AIエージェントとは？その仕組みや自動化との違い、活用事例を解説もあわせて読むと、Managed Agentsの立ち位置がより明確になります。

Anthropic全体の戦略や最新動向を押さえたい方は、Anthropicとは？Claudeの特徴・最新動向・料金を解説も参考にしてください。