Anthropicは、Claude Managed Agentsのセルフホスト版を公開しました。企業は、エージェントハーネス、サンドボックス、認証情報、セッション履歴を、自社のクラウドまたはオンプレミス環境で運用できます。このオプションは11月12日にプライベートベータとして始まり、利用を希望する顧客はAnthropicのアカウントチームを通じて申請します。
今回の変更が重要になるのは、すでに社内システムの中で無人稼働しているエージェントです。こうしたエージェントは、壊れたビルドの修正、リリースのテスト、アラートのトリアージ、バグの積み残し対応などをこなしています。これまでも、顧客はサンドボックスを自社でホストできました。サンドボックスとは、エージェントのコードを実行する隔離環境です。しかし、それ以外の部分はAnthropicが運用していました。認証情報の取り扱いや、各エージェントの行動記録も含まれます。サービス全体を自社の境界内に置きたいチームは、プラットフォームを自前で構築する必要がありました。
顧客が運用する範囲
セルフホスト構成では、顧客が次の3つを運用します。Managed Agentsサーバー、そのPostgreSQLデータベース、そしてエージェントがシェルやファイルツールを実行するワーカーです。セッション履歴はこのデータベースに保存されます。開発者は、ホスト版と同じコアAPIを使ってエージェントを構築します。
モデルへのリクエストは、顧客が指定した接続先に送られます。接続先は、Anthropic本体、Amazon Bedrock、GoogleのAgent Platform、Microsoft Foundry、あるいは顧客自身のゲートウェイです。ただしClaude自体は引き続き顧客のネットワークの外で動作するため、プロンプトは外部に送信され、生成結果が返ってきます。Anthropicとゼロデータ保持（ZDR）契約を結んでいる組織もあります。その場合、これらのリクエストは、Anthropicの標準的なモデルリクエスト用インターフェースであるMessages APIへの他の呼び出しと同様に扱われます。
認証情報の置き場所
Anthropicは、Managed Agentsを4つのセキュリティ原則に基づいて構築しました。これらの原則は、Anthropicがすべてをホストする場合でも、顧客がサンドボックスだけをホストする場合でも、顧客がすべてをホストする場合でも適用されます。同社の考え方は、無人で動くエージェントの各ステップを人が確認することは当てにできないため、「制限をシステム自体に組み込む必要がある」というものです。
第1の原則は、Claudeを呼び出すハーネスと、エージェントのコードが動くサンドボックスを分離することです。エージェントループ、セッション履歴、ボールトのシークレットはサンドボックスの外に置かれ、サンドボックスはツールが必要としたときにだけ起動します。認証情報もサンドボックスには置きません。MCPツールと対応するAPI呼び出しについては、サンドボックスの外にあるプロキシがリクエストに認証情報を付与します。セルフホストの顧客は、こうした認証情報を自社のシークレットマネージャーで保管できます。ただしAnthropicは、この保護の対象をMCPツールと「対応するAPI呼び出し」に限定しています。そのため、エージェントがアクセスするそれ以外のサービスについては、エージェントの本番投入前に確認しておくべきでしょう。
許可リストとログ
各環境は、許可するホストのリストに限定でき、それ以外のホストへのリクエストはブロックされます。壊れたビルドを修正するエージェントの場合、Anthropicはリストをgitホストとパッケージレジストリだけにすることを提案しています。サンドボックスをホストする顧客は、こうした制限を自社のファイアウォールで実施します。つまり、許可リストを正しく設定する責任は顧客側にあります。
Managed Agentsは、エージェントが取るすべてのステップのログも記録します。呼び出した各ツールと、その結果として得られた内容です。このログはOpenTelemetry経由でエクスポートできるため、セキュリティチームは、すでに運用している監視ツールに取り込み、他の監視対象と並べてエージェントの動きを確認できます。
サーバー、データベース、ファイアウォールルールは、今後は顧客が運用することになります。それらにパッチを適用し、正しく設定し続ける作業も顧客の役割です。
翻訳元: https://www.helpnetsecurity.com/2026/11/12/anthropic-self-hosted-claude-managed-agents/
