Claude Managed Agentsは、Anthropicのホストされたエージェントハーネスで、執筆時点ではベータ版です。エージェントループ、サンドボックス、セッションログをAnthropicのサーバーで実行し、トークンに加えてセッション1時間あたり0.08ドルで課金され、アイドル時間は無料です。このレイヤー自体を保守する代わりに、イベントを送信して結果をストリーミングします。このポストは、このサービスがホストするもの、ant applyファイルベースのワークフロー動作、およびAgent SDKがまだ最適な場合の詳細なウォークスルーです。
注記：Managed Agentsは、執筆時点ではベータサービスです。ここでの内容は参考までにご覧ください。
Claude Managed Agentsがあなたのためにホストするもの
短く言えば: Anthropicはエージェントハーネス、コンピュートサンドボックス、セッションログを実行します。あなたはイベントを送信し、HTTPで結果をストリーミングして返すだけです。以上です。コンテナライフサイクル、ツール実行環境、一時的な失敗に対するリトライロジックを管理する必要はありません。
より詳しくは、Anthropic側に配置されるもの以下の通りです:
- エージェントループ。Claudeがツール呼び出しのタイミングを決定し、結果を処理して、オーケストレーションを自分で書くことなく反復します。
- 組み込みツール。Bash、ファイル操作、ウェブ検索はすべて
agent_toolset_20260401ツールタイプでアクセス可能です。自分でセットアップする必要はありません。 - セッション単位のサンドボックス。各セッションは独立した実行環境を持ちます。セッション間の干渉はありません。
- 永続的なセッションログ。アプリケーションがストリームを切った場合、セッションは消えません。再接続して続きから始められます。
- MCP統合。カスタムツールはMCPサーバーとしてアタッチされます。Claudeがツールをトリガーし、あなたのサービスはプロトコル経由で結果を返します。デプロイにバンドルする必要はありません。
- プロンプトキャッシング。プラットフォームレベルで組み込まれており、システムプロンプトが長くなると重要です。
あなた側で保持するもの: エージェント定義、MCP サーバーの実装、セッション開始・停止のタイミングを決定するビジネスロジックです。完全なハーネスを所有するより、はるかに小さい範囲です。
Hatchworksはインフラの分割を明確に説明しています: 推論はコンテナがプロビジョニングされる前に開始できるため、毎回のツール呼び出しがサービス境界を越えてもコールドスタートエージェントでより高速になることがあります。
Managed Agents、Agent SDK、Claude Codeのどれを選ぶか
最も多く見かける混乱は、この3つが相互に置き換え可能だと思う人たちです。そうではありません。
Claude Codeはターミナルツールです。開発者がローカルでタスクを実行する際に便利です。製品に組み込むものではありません。
[Agent SDK](/blog/claude-agent-sdk-guide-2026/)は、お客様自身のプロセス内、お客様自身のインフラストラクチャ上でエージェントループを実行します。ファイルシステムへの直接アクセス、プライベートネットワーク接続性、実行環境への完全な制御が可能です。ローカルファイル書き込みのようなサービス境界なしの操作、既に支払い済みの既存インフラストラクチャ、またはモデルレベルでの複数プロバイダーの柔軟性が必要な場合、SDKを選択します（ただし今のところSDKではClaude以外にロックインされます）。
Managed Agentsはホステッド型の答えです。ダッシュな構築なしで、永続的なセッション、サンドボックス化されたコンピュート、および組み込みの可観測性が得られます。コストモデルはトークンだけでなくセッション時間あたりであり、短くフォーカスされたセッションに報い、長い休止状態のセッションにペナルティを与えます。
決定テーブルは以下の通りです：
| 状況 | 以下を選択してください |
|---|---|
| 新しい製品で、すぐにリリースしたい、既存インフラなし | Managed Agents |
| ローカルファイルシステムまたはプライベートネットワークアクセスが必要 | Agent SDK |
| すでに実行している既存エージェントインフラ | Agent SDK |
| ホストされた環境への移行前にローカルでプロトタイプ化 | Agent SDKで最初にプロトタイプ化、その後Managed Agentsに移行 |
| 自分のマシン上のCI/CDパイプライン | Agent SDK |
| 構築なしで永続的なセッションが必要 | Managed Agents |
注目する価値がある点：hidekazu-konishi.comのSDKガイドで述べられているように、一般的な方法はSDKでローカルプロトタイプ化を行い、ホストされたサンドボックスが必要になったら（自分で運用したくない場合）Managed Agentsに移行することです。
このアround全体の生産製品構築が具体的な課題であれば、我々のエージェント工学業務は何か間違った方向に進むのを防ぐのに役立つかもしれません。
1つのエージェントを作成してセッションをインスペクト
これは検証されたプロダクション実行ではなく、ドキュメント化されたウォークスルーです。公式ドキュメントから手順を説明しています。このコードはお客様自身のキーに対して実行するまで説明的なものと考えてください。
実行中のエージェントに到達するには4つのステップがあります。
- エージェント定義を作成します。ここで、エージェントが何をできるかを記述します：どの組み込みツールにアクセスでき、どのMCPサーバーを呼び出すことができ、システムプロンプトが何かです。
- 実行環境を作成します。プラットフォームはエージェント定義にスコープされたサンドボックスをプロビジョニングします。
- セッションを開始します。ユーザーの入力で開始イベントを送信します。セッションIDはすぐに戻ります。
- イベントをストリーム処理します。ツール呼び出し、中間結果、最終応答のすべてがストリーム上に到達します。アプリケーション内でそれらを処理します。
7つの公式SDK（Python、TypeScript、Go、Java、C#、Ruby、PHP）全体では、構文は異なっていても、その流れの形状は一貫しています。agent_toolset_20260401ツールタイプは、単一宣言での完全な組み込みツールセットをアンロックするものです。bash、ファイルオペレーション、ウェブ検索を個別に列挙する必要はありません。
セッションが実行中の場合、セッションログエンドポイント経由でそれをインスペクトできます。ここが永続性の恩恵が具体的に示されます。ストリームをドロップして再接続すると、ログは終了した場所から再生されます。クライアントが切断される可能性がある長時間実行タスクの場合、これは非常に重要です。
ant applyとclaude-lock.jsonでリソースを管理
ant CLIはSDK自体とは別のツールです。Homebrewを経由してインストールします。エージェント定義（エージェント、環境、MCPサーバー登録）をclaude-lock.jsonconfig ファイルで宣言し、プラットフォームに適用するファイルベースのワークフローを提供します。
ant apply ドキュメントは主要コマンドを説明しています：
ant apply
プロダクション環境に触れる前に、ドライランフラグを実行してください：
ant CLIはSDK自体とは別のツールです。Homebrewを経由してインストールします。エージェント定義（エージェント、環境、MCPサーバー登録）をclaude-lock.jsonconfig ファイルで宣言し、プラットフォームに適用するファイルベースのワークフローを提供します。
これは適用時の動作をプレビューしたものです。公式ドキュメントの重要な注意点：--dry-run は適用時にブロックされるプランでも終了コード 0 で終了することがあります。クリーンな dry-run を完全な適用の成功保証と見なさないでください。ステージング環境で実際の適用を確認してください。
claude-lock.json ファイルはデプロイ済みリソースの現在の状態を記録するロックファイルです。package-lock.json のようなもので、リソースバージョンをピンするとともに、宣言した内容とプラットフォームが実行している内容の間のドリフトを防ぎます。ant apply 後はいつでもロックファイルが新しい状態を反映するよう更新されます。コミットしてください。コードレビューの際、ロックファイルの変更を意味のあるものとして扱ってください。
部分的な適用という 1 つのシリアライゼーションポイントが人々を困らせます。ant apply が途中で失敗すると、一部のリソースは新しい状態になり、その他はそのままになります。ロックファイルは部分的な更新を反映します。ant apply を再度実行する前に、ロックファイルを実際にデプロイされたものと照らし合わせ、必要に応じて手動で調整してから再実行してください。最初に確認せずに壊れた部分的な状態に対して 2 番目の適用を実行すると、リソースが混乱した中間状態のままになる可能性があります。
これは Terraform のような CLI に個別の plan ステップがあるツールとは異なります。ant plan はありません。dry-run がプレビューに使用できるものです。CI を設計する際はこれを念頭に置いてください。
CI の変更をレビューして部分的なエラーに対応する
複数の開発者が同じ Managed Agents 環境に対して作業を実行するチームの場合、ローカルマシンではなく CI から変更を適用することを強くお勧めします。そうしないとロックファイルでレース状態が発生します。
推奨するワークフローは以下の通りです：
- PR がオープンされます。CI は
ant apply --dry-runを実行し、出力を PR コメントとして投稿します。 - レビュアーが差分をチェックします（ロックファイルの変更を含む）。
- main にマージされると、CI は
ant applyをステージング環境に対して実行します。 - ステージングの適用が成功し、セッションが正常に動作した後にのみ本番環境に昇格させてください。
シリアライゼーション要件が主な運用上の制約です。同じ環境に対して 2 つの ant apply 呼び出しを並列実行することはできません。CI システムが複数のマージを急速にキューに入れることができる場合は、パイプラインレベルでロックを実装します（ほとんどの CI プラットフォームにはこの目的のための並行グループ設定があります）。
部分的なエラーの処理チェックリストは以下の通りです：
- 失敗した適用の直後にロックファイルを確認します。どのリソースが更新されたか、どのリソースが更新されなかったかを記録してください。
ant applyを盲目的に再実行しないでください。まずエラーを読んでください。- 部分的な状態を調査している間、安全に放置できる場合は放置してください。リソースが壊れた中間状態にある場合は、再適用する前に手動でロールバックする必要があります。
- 解決したら、完全な適用の前に
ant apply --dry-runを再度実行してプランが正しく見えることを確認してください。
--dry-run は ブロックされたプランでも終了コード 0 で終了する可能性があるため、dry-run がクリーンに見えても レビューステップをスキップしないでください。
ベータ版の制限、コスト、デプロイメントチェックリスト
Managed Agents はベータ版サービスです。この指定は本番環境で重要な物事に関わります。機能は変更される可能性があります。価格設定は変更される可能性があります。ベータ版での可用性保証は GA と同じではありません。
料金。公表されているレートはセッション1時間あたり0.08ドルで、セッション実行中のみ計測され（アイドル時間は課金されない）、標準モデルレートでトークンが上乗せされます。これにより、短期間でタスク指向のセッションには相対的に予測可能です。実質的なツール使用を伴う長時間実行セッションの場合、セッション期間を積極的に監視する必要があります。vibecodingacademyガイドはこれをコンテキストで提供します。コスト競争力は、同等の自己管理インフラ構築に費やされるエンジニアリング時間に依存し、これは実質的でしばしば過小評価されています。
ベータ版の現在の制約：
- カスタムツールは関数内プロセスではなく MCP サーバーを経由してルーティングされます。カスタムツールがアプリケーションのランタイムと密結合している場合は、最初に MCP サーバーに抽出する必要があります。
- セッション可視性はセッションログエンドポイントを通じて行われます。SDK の上に自分で構築するものと同等の組み込みダッシュボードはありません。
ant applyは部分的な失敗のセマンティクスに対応しており、手動で調整が必要です。自動ロールバックはありません。- シリアル化されたapplyはパイプラインのスループットをapply期間によって制限します。
デプロイ前チェックリスト：
- エージェント定義をレビューし、システムプロンプトを確定する
- MCPサーバーを登録し、エージェントへの接続前に独立してテストする
claude-lock.jsonをコミットし、レビュー済みの成果物として扱うant apply --dry-runの出力を本番環境へのapply前に第二者がレビューする- セッション期間の監視を実施する（予期せず長いセッションに注意）
- チーム向けに部分的な失敗の復旧手順を文書化する
- 本番環境への昇格前にステージング環境を検証する
- ベータ版の料金が変わる可能性があるため、アカウントレベルで予算アラートを設定する
ビルド vs 購入の質問について最後にひとつ。Agent SDKはより多くの制御を与えます。しかし制御は所有を意味します。ksredがSDKについて述べるように、実質的な作業を行うエージェントセッションはすぐに高額になる可能性があり、失敗の復旧はSDKの設計に完全に依存します。Managed Agentsはその制御の一部を耐久性のあるセッションと自分たちが運用しないインフラストラクチャと交換します。どちらが間違っているわけではありません。選択はチームが実際に保守できるものによって異なります。
ant apply --dry-runの出力を本番環境へのapply前に第二者がレビューする
Managed Agentsはすべてのクロードモデルで機能しますか、それとも特定のバージョンに限定されていますか？
執筆時点の公式ドキュメンテーションでは、Managed Agents内での特定のモデル制限は記載されていません。ベータ版ステータスを踏まえると、モデルの利用可能性は変わる可能性があります。本番環境のエージェント定義で特定のモデルバージョンにコミットする前に、概要ページを直接確認してください。
デプロイ前にテストするために、SDKでローカルに同じエージェント定義を実行できますか？
直接はできません。SDKはローカル環境に対して自分たちのプロセスでループを実行します。Managed Agentsはそれを人類学者のサンドボックスで実行します。SDKでエージェントの動作をプロトタイプすることはできますが、実行コンテキストが十分に異なるため、本番環境への昇格前に実際のManaged Agentsデプロイをステージング環境でテストする必要があります。
Managed Agentsは認証情報が必要なMCPサーバーの認証をどのように処理しますか？
公式ドキュメンテーションでは、カスタムツールをMCPサーバーを通じた接続として説明しており、Claudeはツールをトリガーし、サービスは結果を返します。これらのMCPサーバーの認証情報処理はサーバーレベルでの責任です。Managed Agentsは現在のドキュメンテーションに基づいて、認証情報をMCPコールに代わって注入しません。
SDKのmax_budget_usdパラメータのようにManaged Agentsでセッションごとの支出を制限する方法はありますか？
SDKのmax_budget_usdパラメータはquery()上のSDK レベルの制御で、Managed Agents REST APIに直接変換されません。Managed Agents内の予算制御は現在のベータ版では同じ粒度で文書化されていません。アカウントレベルの支出アラートが今のところ最も安全なバックストップです。
リージョンまたはサンドボックスに障害が発生した場合、実行中のセッションはどうなりますか？
耐久性のあるセッションログはManaged Agentsの中核設計機能ですが、インフラストラクチャの障害を超えたセッション復旧の詳細は現在のベータ版ドキュメンテーションには記載されていません。ベータ版の指定を考慮すると、Anthropicがサービスの SLAを公開するまで耐久性の保証をベストエフォートとして扱ってください。
率直なまとめ：Managed Agentsは大量のインフラストラクチャ作業を排除する本当に有用なサービスです。ant applyワークフローはdry-runの注意事項とシリアル化の要件を理解すれば簡単です。しかしそれはベータ版で、部分的な失敗のセマンティクスには注意が必要で、ローカルファイルシステムへのアクセスが必要な場合または既に満足しているエージェントインフラストラクチャがある場合は正しい答えではありません。決定表で開始し、チームが実際に所有したいものに基づいて選択し、ロックファイルを他の状態ファイルと同じくらい真摯に扱ってください。