Claude Managed Agentsのセルフホスト対応 — サービス本体を自社で運用

2026年11月12日、Claude Managed Agentsにセルフホスト構成が加わりました。これまでセルフホストできたのはツールを動かすサンドボックスだけでした。今回はサービス全体を自社のクラウドやオンプレミスで動かせます。エージェント、セッション、セッション履歴の保存先も自社のデータベースになります。

要点

• サービス本体(API、エージェントループ、保存)を自社で動かせる。サンドボックスだけのセルフホストとは別の選択肢
• モデルへのリクエストは、自分で選んだ推論プロバイダーに送られる。既定はAnthropic
• APIはホスト型と同じなので、SDKとant CLIがそのまま使える
• 提供形態はプライベートベータの限定提供。利用にはAnthropicのアカウント担当チームへの問い合わせが必要
• サーバーとデータベースの運用、リリースごとの更新、セキュリティ確保は利用者側の仕事になる

ホスト型の利便性を手放す代わりに、データの置き場所とモデルの経路を自分で決められる更新です。

何が自社に移るのか

Managed Agentsは、動かす場所の違いで3つの選択肢に分かれました。

ここでいうサービスとは、APIとエージェントループ、そしてエージェント・セッション・セッション履歴の保存を指します。サンドボックスは、エージェントのツールがコマンドを実行し、ファイルを扱うコンテナやVMです。後者だけを自社に置く構成は、すでにManaged Agentsのセルフホストサンドボックスで扱っています。

構成要素

1つのデプロイは、次の部品で成り立ちます。

• サーバー(cma-server): APIの提供、エージェントループの実行、セッション履歴の保存を担う。エージェントのシェルやファイル操作は実行しない
• データベース: PostgreSQL 16以降。データベースを設定しないと、サーバーはデータをメモリに持ち、再起動で消える
• ワーカー: サーバーから仕事を受け取り、自社のサンドボックスでシェルとファイルのツールを動かす。ant beta:workerコマンドか、SDKのワーカーで用意する
• コンソール: サーバーのアドレスで開くWebページ。自社のIDプロバイダー経由でサインインして、エージェントの作成やセッションの実行をする
• 管理用CLI(cma-server-admin): 環境と環境キーを作る。Linux(x86-64とArm)と、Apple siliconのmacOSで動く

サーバーのソフトウェアは、専用のライセンス契約(Software License Agreement: Claude Managed Agents Server)の下で提供されます。リリースごとのアーカイブにはoperator-guide.mdという運用ガイドが付き、ドキュメントはこれをClaudeに読ませて、設定やサーバーに接続するコードの作成を手伝わせるよう案内しています。

推論プロバイダーの選択肢

モデル呼び出しの行き先は、Amazon Bedrock、Claude Models on Google Cloud(Google管理)、Microsoft Foundry、自社のモデルゲートウェイから選べます。既定はClaude APIです。発表記事ではGoogle側が「Google's Agent Platform」と書かれており、ドキュメントの呼び名と食い違います。設定を調べるときは、ドキュメント側の名称で探すほうが確実です。

選ぶ判断はどう変わるか

セルフホストManaged Agentsが向くのは、次の2つの条件に当てはまる場合です。

1. エージェント、セッション、セッション履歴を自社のインフラに保存しなければならない
2. モデル呼び出しをBedrock、Foundry、自社ゲートウェイなど、Claude API以外に向ける必要がある

「ツールの実行だけ自社に置ければよい」なら、サンドボックスだけのセルフホストで足ります。その場合のサービスはAnthropicが運用し続けます。逆にサービス本体を持つと、サーバーとデータベースの運用に加えて、リリースの導入も自分で行う前提になります。ホスト型にだけある機能もあるため、採用前に「ホスト型との違い」の確認が必要です。

3つの選択肢の使い分けは、Managed Agents・Agent SDK・Claude Codeの使い分けとあわせて読むと整理しやすくなります。

判断材料

セルフホストを検討する人の確認先

• データの保存先

  セッション履歴は自社のデータベースに置かれます。削除するまで残り、年数による自動削除はされません。

• 推論の経路

  Claude API、各クラウド、自社ゲートウェイから選びます。会話の全文が選んだ先に送られます。

ネットワークの外へ出るもの

セキュリティレビューで最初に聞かれるのは、何が外に出るかです。データとアクセスのページは、サーバーの接続先を限定して列挙しています。

サーバーが接続するのは、推論プロバイダー、データベース、許可したMCPサーバーとGitホストです。設定した場合は、モデル呼び出し用の認証情報を発行するサービス、OpenTelemetryコレクター、シングルサインオン用のIDプロバイダー、シークレットマネージャーなどにも接続します。web検索とWebページ取得のツールは、推論プロバイダーが提供している場合にそのプロバイダー側で実行され、サーバー自身はその宛先に接続しません。web検索はClaude API、Claude Models on Google Cloud、Microsoft Foundryで、Webページ取得はClaude APIとMicrosoft Foundryで使えます。Amazon Bedrockと自社のモデルゲートウェイでは、どちらもモデルから呼べません。どちらも既定では無効です。Claude APIを推論プロバイダーにしたときだけ、サーバーはAnthropicに接続します。Anthropicにはサーバーとそのログへのリモートアクセスがありません。

モデル呼び出しごとに、会話の履歴、ツールの入力、ツールの結果が推論プロバイダーに送られます。Claude APIが行き先の場合は、これに最大3つのヘッダーが付きます。

IDに名前や内容は含まれません。ただしサーバーがIDを作った時刻はIDにエンコードされており、設定でヘッダーを止めることはできません。Anthropicはこれでセッション、エージェント、環境ごとの利用量を割り当てられます。ほかに、Claude APIへのリクエストにはUser-Agentでサーバーのソフトウェア名とバージョンが入り、呼び出しによってはmetadata.user_idにcma-serverというラベルも載ります。どちらも利用量の集計に使えるものです。

自社のプロキシやゲートウェイを挟むときは注意が要ります。metadata.user_idが付く呼び出しでは、自社のプロキシがこのフィールドを受け付ける必要があり、拒否すると全てのモデル呼び出しが失敗します。ラベルを送るのはClaude API、Microsoft Foundry、Claude APIと同じリクエストを受けるゲートウェイへの呼び出しです。Amazon Bedrock、Claude Models on Google Cloud(Google管理)、別形式のゲートウェイには送りません。

ZDRとの関係

ZDR(ゼロデータ保持)を契約している組織では、モデルへの呼び出しは通常のMessages APIと同じようにその対象になります。一方、APIとデータ保持のページはManaged AgentsをZDRの対象外としています。Anthropicがサービスを動かす場合、セッションのトランスクリプトは削除されるまでAnthropic側に保存されるためです。セルフホストManaged Agentsなら保存するのは利用者自身です。サンドボックスだけのセルフホストでは、Anthropicがトランスクリプトを保存し続けます。

動かす前に知っておく運用の勘所

待ち受けポート

• APIとコンソール: 既定は127.0.0.1:8400で、同じマシンからしか届かない。変更はserver.addr
• Prometheusのメトリクス: 既定では無効。有効にするとlocalhost:9464で待ち受け、認証情報は求めない
• 送信制御ゲートウェイ(egress gateway)用: 既定では無効。有効にすると全インターフェースのポート8410で待ち受け、応答に保存済みの認証情報の値が含まれる。Composeのスタックとサーバー用Helmチャートは、このポートにゲートウェイだけが届くよう制限している。ほかの方法で動かす場合も同じ制限が要る

Docker Composeのスタックはポート8400をDockerホストのループバックに公開するため、Docker Engine 28.3.3以降が前提です。それより古いリリースでは、ホストのローカルネットワーク上のマシンから、ループバックに公開したポートへ届くことがあります。

Helmチャートでメトリクスを有効にすると、各サーバーポッドのポート9464で待ち受けます。NetworkPolicyで止めない限り、ポッドのアドレスに経路のあるものから読めます。認証のない待ち受け口なので、ここは設計時に決めておく項目です。

1つのデプロイは1つの信頼レベル

1つのデプロイが受け持つのは、1つのテナントの1つの信頼レベルです。環境を分けても信頼レベルは分離されません。サーバーのAPIキーはすべての環境に届き、ロールを持つ呼び出し元は、どの環境でもセッションを動かせます。テナントや信頼レベルを分けるなら、データベース、APIキー、ワーカーを含めてデプロイごと分けます。

エージェントが実行するコードは、サンドボックスが持つ認証情報で自由にサーバーを呼べます。環境キーはその環境のすべてのセッションのイベントを読め、ツール結果を投稿できます。そのためセッションごとに専用のサンドボックスで動かし、環境キーはその外に置く構成になります。

3つの認証情報

ホスト型でClaude APIキーが担っていた役割を、サーバーのAPIキーが引き継ぎます。アプリやワーカーに推論の認証情報は不要です。

サービスごと持つと、会話内容がAnthropicに届くかは推論先しだいになる

発表記事は、エージェントが「壊れたビルドの修正、リリースのテスト、アラートの仕分け」のような仕事を人の監視なしに担うようになったと述べています。そうなると、ツールの実行場所だけでなく、ループの制御、認証情報、履歴まで自社の境界内に置きたい組織が出てきます。それを自前の基盤づくりなしに実現する手段が、今回のセルフホストです。

記事は、Managed Agentsの設計原則が「Anthropicが全部運用する」「サンドボックスだけ自社」「サービス全体を自社」のどの形でも同じだと説明しています。

設計原則

どの構成でも共通する4つの設計

• 頭脳と手の分離

  ハーネスがClaudeを呼び、サンドボックスでコードが動く。ループ、履歴、vaultの秘密はサンドボックスの外にある。

• 認証情報はサンドボックスの外

  MCPツールなど対応する呼び出しでは、外側のプロキシがリクエストに認証情報を足す。セルフホストでは自社のシークレットマネージャーも使える。

• ネットワークの制限

  環境ごとに許可ホストを絞れる。自社でサンドボックスを持つなら、同じ制限を自社のファイアウォールで掛ける。

• 完全な記録

  ツール呼び出しと結果を含む全ステップの記録を、OpenTelemetryで既存の監視ツールに流せる。

セルフホストサンドボックスでは、サービスもモデルもAnthropic側なので、会話内容とツールの出力はAnthropicに届きます。サービスごとのセルフホストではその前提が変わり、届くかどうかは推論プロバイダーの選択次第になります。サンドボックスだけを移す場合の責任分担は、セルフホストサンドボックスのセキュリティ責任分界で整理しています。

ただし、自前運用は軽い選択ではありません。サーバー、データベース、リリース更新、防御がすべて利用者側に来るので、導入の前にManaged Agentsを本番に出す前のセキュリティ点検の項目を自社の構成に当てはめておくと、抜けを見つけやすくなります。ホスト型の環境設定の考え方は、クラウド環境の構築の記事が参考になります。

まとめ

保存先か推論の経路に社内規程の縛りがあるかどうかが分かれ目です。縛りがなく、ツール実行の場所だけが論点なら、セルフホストサンドボックスで足ります。導入を考えるなら、ホスト型との機能差、ネットワークの待ち受け、認証情報の持ち方を先に確かめてください。