Claude Managed Agentsの使い分け — Agent SDK・Claude Codeとの違い

Claude Managed Agents・Agent SDK・Claude Codeは何が違うか

3つはいずれもClaudeを自律的なエージェントとして動かす手段ですが、インフラを誰が持つかが違います。Agent SDKとClaude Code CLIは自分の端末やプロセスの中で動き、Managed Agentsは実行基盤そのものをAnthropicに任せます。同じエージェントを3基盤で動かす具体例はClaude commerce agentの実装にあります。

Claude Managed Agentsとは、Anthropicが管理するインフラでエージェントを走らせるホスト型の仕組みです。エージェントループ・ツール実行・セッションの保存をAnthropic側が担うので、サンドボックスを自作する必要がありません。呼び出し方は各言語のSDK、ant CLI、REST APIの3通りです。

対してAgent SDKは、Claude Codeと同じツール・エージェントループ・コンテキスト管理をPython/TypeScriptから使うライブラリです。中身はClaude Codeのバイナリを動かす構成で、自分のプロセスの中にエージェントを埋め込みます。Claude Code CLIは同じ機能をターミナルの対話体験として包んだものです。

3つに上下関係はありません。Agent SDKの公式比較表には「Agent SDK」「Claude Code CLI」「Client SDK」「Managed Agents」の4行が並び、Managed Agentsの行は「Anthropicにエージェントをホストさせ、Claude APIで設定する」場合の選択肢として書かれています。資格情報の分離や実行制限を外側から足す構成は、NVIDIA OpenShellとの連携発表で扱っています。他社のOpenAI Agents SDKとの設計差はClaude Agent SDKとOpenAI Agents SDKの比較にあります。

3つの実行環境を並べると

言語の面では、Agent SDKはPythonとTypeScriptの2つです。他の言語から同じループを動かすなら、CLIを -p と --output-format json 付きのサブプロセスとして呼びます。Managed AgentsはHTTPが話せれば言語を問いません。

Messages APIやClient SDKとの違い

Messages APIやClient SDKは、モデルを直接呼び出す層です。ツールを実行するループは自分のコードで書きます。Client SDKはベータのツールランナーにループを任せることもできます。

Managed Agentsは、そのループと実行環境までAnthropicが持つ層です。概要ページは用途を「長時間・非同期のタスク」としています。細かい制御が要るならMessages API、ループごと任せたいならManaged Agentsという分け方になります。

選ぶ前に見る4つの分かれ目

実務では「データの扱い」が最後に効いて、選択が裏返ることがあります。

データを外に出せない要件は、自己ホストでも解けない

ネットワーク境界を越えられないデータがあるとき、Managed Agentsの自己ホストサンドボックスが答えに見えます。ツールの実行を自社インフラに移せるからです。ただし、移るものと残るものを分けて見ると、期待とずれます。

データ保持の面でも同じです。API and data retentionの機能別の表では、Managed Agentsの行がZDRもHIPAAも「No」で、備考に「自己ホストサンドボックスを含むすべてのサブ機能に当てはまる」と書かれています。セッションの記録は、削除するまで残るステートフルな資源だからです。

そのため、ZDRやHIPAAの要件がある場合、Managed Agentsは選択肢から外れます。Agent SDKなど別の構成を取る場合も、使う機能がZDRの対象かどうかは、同じ表で機能ごとに照らす必要があります。

自己ホストの流れと、つまずきやすい制約

自己ホスト環境は仕事のキューとして働きます。自分のインフラで動く「環境ワーカー」が、そのキューを取りに来る形です。

ワーカーの起動は、ant CLIなら1行です。ワーカーを動かすホストは /bin/bash が実在するLinuxで、外向きのHTTPSが通れば足ります。

ant beta:worker poll --workdir /workspace

制約も2つあります。1つ目は、自己ホスト環境のセッションに載せられるリソースが memory_store だけな点です。file や github_repository を含めると、400エラーで拒否されます。

Environment env_... is a self-hosted environment. `resources` are not supported with self-hosted environments.

2つ目は、この制約がスケジュールデプロイにも及ぶ点です。cron実行と自己ホストを組み合わせた構成では、ファイルやGitHubリポジトリを渡せません。それらが要るジョブはクラウド環境側で動かす形になります。cronの定義はスケジュールデプロイに、自己ホストの設定は自己ホストサンドボックスにまとめています。セキュリティ側の責任分担は自己ホストの安全設計が詳しいです。

CLIをサブプロセスにする経路で、手元に何があるか

Python/TypeScript以外から使う逃げ道として、CLIの -p があります。この経路が「ただの呼び出し口」に留まるのか、実際のオプションで見てみます。次はClaude Code v2.1.287の --help から抜いた行です。

claude --version
# 2.1.287 (Claude Code)
 
claude --help
#   -p, --print                 Print response and exit (useful for pipes)
#   --output-format <format>    "text" (default), "json" (single result), or "stream-json"
#   --max-budget-usd <amount>   Maximum dollar amount to spend on API calls (only works with --print)
#   -c, --continue              Continue the most recent conversation in the current directory
#   -r, --resume [value]        Resume a conversation by session ID
#   --no-session-persistence    Disable session persistence - sessions will not be saved to disk

--no-session-persistence が用意されているので、通常はセッションがディスクに保存される作りです。--continue と --resume で会話の続きから動かせます。--max-budget-usd は --print のときだけ効く上限です。

--output-format json の応答には total_cost_usd が入り、モデル別の内訳も付きます。ただしどちらもクライアント側の見積もりで、実際の請求とは差が出ます。スクリプトから呼ぶ運用でも、支出の目安と会話の再開までは手元で足ります。

足りなくなるのは、複数ホストにまたがる運用と、ホスト側のスケジューラです。会話ファイルは実行したマシンに置かれるので、別のマシンで続きを動かすには自分で運ぶ必要があります。その具体策はAgent SDKのセッション機能の側にあります。

セッションの持ち方と、途中介入の違い

Agent SDKのセッションは、エージェントが動く間に積み上がる会話履歴です。SDKが自動でディスクに書き込み、あとから continue・resume・fork で戻れます。ステートレスに動かしたければ、TypeScriptでは persistSession: false を渡します。

セッションファイルは作ったマシンの中に閉じます。CIのワーカーや使い捨てコンテナのように別ホストで再開するなら、次の3つから選びます。

• sessionStore アダプターで、自分のバックエンドに会話の記録を写す
• ~/.claude/projects/ 配下のセッションファイルを、1回目の実行から新しいホストへ運ぶ
• 再開に頼らず、結果と判断をアプリの状態として保存し、新しいセッションのプロンプトに渡す

最後の選択肢は、トランスクリプトのファイルを運ぶより堅いことが多い方法です。会話の完全な復元より、必要な結論だけを持ち越す設計です。Managed Agentsでは、この保存の手間がAnthropic側に移ります。イベント履歴はサーバーに残り、あとから全件を取得できます。

途中介入も、3基盤に共通の仕組みがあります。Managed Agentsは user.message を追加で送って方向を変え、user.interrupt で止めます。ツールの承認が必要な場面では、user.tool_confirmation で許可か拒否を返します。

Agent SDKにも対応物があります。ストリーミング入力モードではメッセージをキューに積め、TypeScriptの interrupt() で中断できます。interrupt() が使えるのはこのモードだけです。v2.1.205以降のClaude Codeでは、中断の時点で保留中だったメッセージの一覧が返ります。

両者の差は、介入の窓口の形です。Managed Agentsはどのクライアントからも同じイベントAPIで操作できます。Agent SDKは、エージェントを動かしているプロセスの中から操作する前提です。外部の画面から複数人が同じセッションに介入する運用なら、窓口がAPIとして用意されている側が組みやすくなります。

Managed Agentsをコードで見る

Managed Agentsのエージェント作成は、モデル・システムプロンプト・ツールをJSONで渡すだけです。managed-agents-2026-04-01 ベータヘッダーが全リクエストで必須になります。

curl -sS https://api.anthropic.com/v1/agents \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -H "content-type: application/json" \
  -d '{
    "name": "Coding Assistant",
    "model": "claude-opus-5-5",
    "system": "You are a helpful coding assistant.",
    "tools": [{"type": "agent_toolset_20260401"}]
  }'

作ったエージェントはIDで参照でき、複数のセッションから使い回せます。Agent SDKでプロセスごとに設定を組み立てるやり方と違い、エージェント定義がサーバー側の資源として残ります。作成系は組織単位で1分あたり300リクエスト、参照系は1,200リクエストのレート制限です。

状況別の選び方

「対話的な開発から始めて、固まったら本番基盤へ移す」のが、自然な順路です。CLIでプロンプトとツール構成を試作し、固まった構成をAgent SDKかManaged Agentsに移植します。

自社プロダクトに載せるときの名前と認証

Agent SDKでもManaged Agentsでも、自社プロダクトにClaudeのエージェントを載せる場合は、呼び名に決まりがあります。使えるのは「Claude Agent」、すでにエージェント名があるときの「 Powered by Claude」などです。「Claude Code」「Claude Code Agent」は使えません。Managed Agentsの側では、「Claude Cowork」「Claude Cowork Agent」も不可です。

認証も1点違います。Agent SDKで作ったエージェントに、第三者の開発者がclaude.aiのログインやレート制限を載せることは、事前の承認がない限り認められていません。APIキーでの認証が前提です。

Managed Agentsへ乗り換えるときの注意

Managed AgentsはAPIアカウントなら既定で使えますが、ベータ機能です。挙動はリリースの間で調整される場合があります。SDKを使えばベータヘッダーは自動で付きますが、curlで直接叩くと付け忘れがそのままエラーになります。MCPトンネルとドリーミングは、ベータの中でもさらに限定的なリサーチプレビューです。

Agent SDKやMessages APIからの具体的な移行手順は、Managed Agentsへの移行ガイドにあります。既存のツール定義やシステムプロンプトの持ち込み方も、そちらで扱っています。

まとめ

優劣ではなく、インフラの持ち主・途中介入の窓口・会話を続けるホストの数で選びます。1台の手元で足りるならCLI、自分のプロセスに組み込むならSDK、複数人の介入や長時間の非同期実行までAnthropicに任せるならManaged Agentsです。Managed Agentsの設計思想を掘り下げるか、Agent SDKクイックスタートで自作のループを試すところから始められます。