Claude Managed AgentsとClaude Agent SDK徹底比較

先週、私は3つのタブを開いていた：Managed Agentsのドキュメント、Agent SDKのクイックスタート、そしてMessages APIリファレンス。非同期ドキュメント処理パイプラインにどちらのパスを使うべきか、判断しようとしていた。40分後、私が気づいたのは、混乱の原因は機能の違いではなく、ランタイムを誰が所有するかという問題だということだった。

これが判断の核心だ。どちらが「優れているか」ではない。今構築しているものに対して、どのインフラの境界が理にかなっているかという問題だ。この記事では2つのパスの比較を記録する——そして、ほとんどの比較記事が省略している第3の選択肢についても解説する。

Claudeを活用したエージェントへの2つのパス

Agent SDK：ループはあなたが制御し、ランタイムもあなたが管理する

Claude Agent SDK——今年初めにClaude Code SDKから名称変更——は、Claude Codeを動かすのと同じツール、エージェントループ、コンテキスト管理をPythonまたはTypeScriptライブラリとしてパッケージ化したものだ。インストールして自分のインフラで実行し、スケーリング、サンドボックス化、オーケストレーションを自分で処理する。

SDKはClaude Code CLIを自動的にバンドルする。エージェントはファイル操作、bashコマンド、Webブラウジング、コード実行——Claude Codeのフルツールセット——にすぐにアクセスできる。どのツールを許可するかを定義し、パーミッションモードを設定し、カスタムツールをインプロセスMCPサーバーとして実装する。

得られるもの：実行環境への完全な制御。同時に得られるもの：その環境を稼働させ、安全に保ち、可観測性を維持する責任。

Managed Agents：Anthropicがハーネスを所有し、あなたがタスクを定義する

Claude Managed Agentsは、2026年4月8日にパブリックベータとして公開され、所有モデルを逆転させる。エージェントを指定する——モデル、システムプロンプト、ツール、MCPサーバー、ガードレール——そしてAnthropicが実行する。ハーネスがツール実行、サンドボックス化、セッション永続化、コンテキスト圧縮、プロンプトキャッシング、クラッシュリカバリを処理する。

Anthropicのエンジニアリングチームはこれを「メタハーネス」と表現している——モデルが改善するにつれて将来のハーネスに対応するよう設計されており、Claudeができること・できないことに関する固定的な仮定を組み込まない。コンテナがクラッシュしてもセッションは生き残る。新しいコンテナがセッションログから引き継ぐ。

あなたが設定し、Anthropicが運用する。

どちらが普遍的に優れているわけではない

機能の重複は大きい。どちらもClaudeにコード実行、ファイル操作、bash、Webブラウジング、MCP統合へのアクセスを提供する。違いは運用面にある：誰が環境をプロビジョニングするか、誰が障害を処理するか、誰がコンテナをスケールするか。これは機能の決断ではなく、インフラの決断だ。

コア比較

請求について注目すべき点：Agent SDKにはセッションランタイム料金がない。しかし「より安い」と無条件に言うのは誤解を招く。自己ホスト型ランタイムには実際のコストがかかる——サーバー、コンテナオーケストレーション、モニタリング、インシデント対応、それらすべてを維持するためのエンジニアの工数。コスト構造は異なるのであって、単純に順序づけられるものではない。

Managed Agentsを選ぶべき場合

セッション永続化が重要な長時間または非同期タスク

エージェントが30分から数時間動作する場合——ドキュメント処理、リサーチ、マルチステップワークフローの実行——切断やコンテナ障害を乗り越えるセッション状態が必要だ。Managed Agentsは完全なイベント履歴をサーバー側に保存し、API経由で取得可能にする。同等の耐久性を自前で構築することは可能だ。しかし、それはコアプロダクトではない数週間のエンジニアリング作業でもある。

セキュアなサンドボックスを構築するインフラ帯域幅がないチーム

本番環境グレードのサンドボックス化——分離、認証情報管理、スコープ付きパーミッション、実行トレーシング——は本当に難しい。ほとんどのチームはこれを過小評価する。チームにセキュアなエージェント実行環境を構築・維持するDevOps能力がない場合、Managed Agentsはそのサーフェスエリア全体をロードマップから取り除く。

プロトタイプから本番環境へ：数ヶ月ではなく数日で

Anthropicのキャッチフレーズは「本番環境へ10倍速く到達」だ。十分なシナリオで検証していないので、その数字を保証はしない。しかし方向性は正確だ：「エージェントがローカルテストで動作する」と「エージェントが本番環境で確実に動作する」のギャップは大きく、Managed Agentsはそれを縮小する。楽天は専門エージェントをそれぞれ1週間以内にデプロイしたと報告されている。

組み込みの圧縮とキャッシングがカスタム制御より重要な場合

Managed Agentsはプロンプトキャッシングとコンテキスト圧縮を自動的に処理する。 長時間実行エージェント向けに独自のコンテキスト管理を構築したことがある人なら、これにどれほどの試行錯誤が伴うかを知っている。組み込みのアプローチはすべてのワークロードに最適ではないかもしれない。ほとんどの場合には十分であり——そして初日から出荷できる。

Agent SDKを選ぶべき場合

Managed Agentsが公開していないカスタムオーケストレーションロジック

SDKはフック、インプロセスMCPサーバーとしてのカスタムツール、きめ細かいパーミッションコールバック、エージェントループの完全な制御を提供する。エージェントにカスタムリトライ戦略、条件付きツールルーティング、セッション途中の動的プロンプト変更が必要な場合——Managed Agentsの設定サーフェスが公開していないロジック——SDKが必要だ。

特殊なツール統合またはカスタム実行環境

エージェントを特定の環境内で実行する必要がある場合——GPU、特定のデータベースドライバー、プロプライエタリなライブラリへのアクセス——SDKで実行環境を完全に制御できる。Managed Agentsはプレインストールされたパッケージを備えたクラウドコンテナを提供する。ほとんどのケースでは十分だが、すべてのケースではない。

オンプレミスまたはプライベートクラウドの要件

Managed AgentsはAnthropicのインフラ上でのみ実行される。オンプレミスオプションはなく、独自のクラウドへのデプロイもできない。厳格なデータ主権要件やサードパーティインフラへのデータ送信を禁ずる規制上の制約がある組織にとって、SDKが唯一のパスだ。これは好みの問題ではなく、ハードな制約だ。

スケール時のコスト構造

$0.08/セッション時間は、ほとんどのワークロードにとって無視できる——24時間365日稼働するエージェントは、トークン前のランタイムコストが月額約$58だ。しかし、同時に長時間稼働するエージェントの大規模フリートには、セッション料金が積み重なる。500エージェントが同時に実行される場合、セッションオーバーヘッドだけで毎時$40が発生する。

Agent SDKにはこのセッションごとの追加料金がない。コストはトークンとインフラの運用コストだ。大量処理では、ランタイムを所有する方が限界コストの観点から安くなることがある——ただし、それを構築・維持するための固定費をすでに吸収している場合に限る。

第3の選択肢：Messages API

SDKもManaged Agentsも必要ない場合

ほとんどの比較記事が省略するこの選択肢は、人々が思うよりも頻繁に正解となる。

Messages APIは直接モデルアクセスを提供する。プロンプトを送り、レスポンスを受け取る。ハーネスなし、エージェントループなし、マネージドランタイムなし。必要であればツール実行ループを含め、すべてを自分で構築する。

完全なエージェントフレームワークを必要としないシンプルなツール使用パターン

ユースケースが「Claudeを呼び出し、必要に応じて1〜2つのツールを使用させ、結果を返す」という場合——エージェントフレームワークはまったく必要ない。ツール使用を伴うMessages APIがこれをクリーンに処理する。Agent SDKやManaged Agentsを追加すると、単純なリクエスト・レスポンスパターンではコストに見合わない複雑さが生じる。

AnthropicのPythonおよびTypeScriptクライアントSDKはツール使用をネイティブにサポートする。ツールループ自身で実装する——stop_reasonをチェックし、ツールを実行し、結果を送り返すwhileループ。多くの本番ワークロードでは、それだけで十分だ。

エージェントフレームワークに手を伸ばすチームを見てきたが、20行のツールループで済んでいたケースがほとんどだ。重い抽象化を選択する前に、タスクが実際に自律性やセッション永続化を必要とするかどうかを確認してほしい。

移行時の考慮事項

Managed AgentsからSDKへの移行：何が変わるか

エージェントロジック——システムプロンプト、ツール定義、タスク構造——はそのまま移行できる。移行できないもの：セッション永続化、サンドボックス化、コンテキスト管理、クラッシュリカバリ。これらすべてを構築する必要がある。

Managed AgentsからSDKへの移行は、「Anthropicが運用する」から「あなたが運用する」への移行を意味する。機能は同等だ。運用負担は完全にあなたのチームに移る。

SDKからManaged Agentsへの移行：何が変わるか

ある意味では簡単で、別の意味では難しい。エージェントのコアロジックは移行できる。インプロセスMCPサーバーとして実装されたカスタムツールは、リモートMCPサーバーとして再公開する必要があるかもしれない。カスタムフックとパーミッションコールバックは、Managed Agentsの設定モデルにマッピングする必要がある。

得られるもの：ランタイムのメンテナンスから解放される。失うもの：実行環境へのきめ細かい制御。そのトレードオフが機能するかどうかは、カスタムインフラがどれだけ実際に必要だったか、または初期プロトタイプの決断から引き継がれたものかによる。

2026年4月時点で、両者間の公式移行ガイドは存在しない。コードの移植だけでなく、統合テストを計画すること。

FAQ

同じプロダクトで両方を使えるか？

できる。SDKとManaged Agentsは異なる運用ニーズに対応する。一般的なパターン：ユーザー向けのレイテンシに敏感なインタラクションには完全な制御が必要なAgent SDK；セッション永続化とハンズオフ操作がより重要なバックグラウンドの非同期タスクにはManaged Agents。両者はトークンコストに対して同じ基盤となるClaudeモデルと料金体系を共有している。

Managed AgentsはAnthropicのインフラにロックインされるか？

される。ランタイムはClaudeに特化して構築されている。GPT、Gemini、オープンソースモデルは実行できない。エージェントロジック——プロンプト、ツール定義、タスク構造——は移植可能だ。ランタイムとセッション形式は移植できない。SDKはモデルレイヤーを抽象化する柔軟性を提供するが、それもClaude固有だ。

エラーとリトライはどちらがうまく処理するか？

Managed Agentsには組み込みのクラッシュリカバリがある——セッションログが永続化され、新しいコンテナが以前のものが失敗した場所から引き継ぐ。SDKでは独自のエラーハンドリングを構築する。経験があり良いパターンを持っている場合、SDKのエラーハンドリングはニーズに合わせてより精密に調整できる。経験がない場合、Managed Agentsのデフォルトは強力な出発点だ。

既存のSDKエージェントをManaged Agentsに移行できるか？

コアエージェントロジックは移行できる。システムプロンプト、ツール定義、タスク構造は互換性がある。再作業が必要なもの：カスタムフック、インプロセスMCPサーバー（リモート相当品が必要になる場合がある）、カスタムパーミッションロジック、特定の実行環境に依存するもの。公式の移行ツールはまだ存在しない。

大量処理時にどちらがコスト効率が高いか？

何を計算に含めるかによる。Managed Agentsはトークンに加えて$0.08/セッション時間が加算される。SDKにはセッションごとの追加料金はない——ただし自己ホスト型ランタイムには独自のコストラインがある：サーバー、オーケストレーション、モニタリング、エンジニアリングメンテナンス。低〜中程度の量では、Managed Agentsは総所有コストで通常安い。多数の同時長時間実行セッションで非常に大量の場合、計算が逆転することがある——ただし、すでにインフラに投資している場合に限る。

以上が比較だ。決断ツリー：インフラ制御が必要、またはデータをオフプレミスに送れない→SDK。インフラをスキップしたい→Managed Agents。エージェントループがまったく必要ない→Messages API。

不確かな場合は両方でパイロットを実行してほしい。デプロイアーキテクチャにコミットした後より、プロトタイプ段階での切り替えコストははるかに低い。

来週に続く——Managed Agentsでのマルチエージェントパターンをまだテスト中。

過去の投稿：