2026年11月13日時点で、Claude Managed Agents のセルフホスト版（self-hosted Claude Managed Agents）は、エージェントの土台（harness）・サンドボックス・認証情報・セッションの記録まで、Managed Agents のサービスの全部を自社のクラウドかオンプレミスで動かせる非公開ベータ（private beta）です。Anthropic が2026年11月12日（米国時間）に発表し、使うには Anthropic のアカウント担当に申し込みます（Anthropic の発表）。モデルへの要求は、Anthropic・クラウド（発表の名前で Amazon Bedrock・Google’s Agent Platform・Microsoft Foundry）・自社のゲートウェイから送り先を選べます（同）。
この記事の要点（2026年11月13日時点）
- 動かし方は 3 つです。全部を Anthropic が動かす既定の形、サンドボックス（道具が動く隔離された作業場所）だけ自社に置く形、両方を自社に置くセルフホスト版です。
- 自社が運用するのは、サーバー（cma-server）・ワーカーと、設定した場合のデータベース（PostgreSQL 16 以上）で、リリースの導入も自社で行います。
- 原則は 4 つです。頭と手を分ける、認証情報をサンドボックスに入れない、ネットワークを許可したホストに絞る、全部の手順を記録して OpenTelemetry（多くの監視の基盤が受け付ける標準の形式）で書き出す。
- PostgreSQL を設定した場合、セッションの記録は自社のデータベースに残ります。データベースを設定しない既定の形ではメモリにあり、再起動で消えます。Anthropic と ZDR（ゼロデータ保持）を結んでいれば、送り先が Claude API の時のモデルへの要求に効きます。
- 始め方は、担当への申し込み、アーカイブの受け取り、Docker Compose で試す（開発用）、本番は Helm チャートの順です。
対象読者：社内のコードやシステムの中でエージェントを無人で動かしたい開発者・情報システム・セキュリティの担当。
今日やること：保存を自社に置く必要と、推論の送り先を自社で選ぶ必要があるかを整理してください。
Managed Agents は、自律して長く動くエージェントを作って動かすための API の組です（発表）。この記事は、Anthropic の発表と公式ドキュメント（以下 docs）を2026年11月13日時点で確認し、その範囲で整理したものです。当社は非公開ベータを使っておらず、コマンドと設定は docs の例の写しで、動かしてはいません。
3つの動かし方の違い｜Anthropic・サンドボックスだけ自社・全部を自社
docs は、自社で持てる部分を 2 つに分けています。道具がコマンドを動かしファイルを扱うコンテナや VM（サンドボックス）と、API・エージェントのループ・エージェントとセッションと記録の保存をまとめた「サービス」です。どちらを誰が持つかで、動かし方は 3 つになります（Self-hosted Claude Managed Agents）。
| 動かし方（docs の名前） | サンドボックス | サービス | モデル |
|---|---|---|---|
| Cloud sandboxes（既定） | Anthropic | Anthropic | Anthropic |
| Self-hosted sandboxes | 自社 | Anthropic | Anthropic |
| Self-hosted Managed Agents | 自社 | 自社 | Anthropic か、自社が選んだ提供元 |
- クラウドのサンドボックス（既定）：全部をAnthropicが運用する形です。
- 自社のサンドボックス：サンドボックスだけ自社に置く形で、Anthropic がエージェントを動かし続け、道具の実行が自社に移ります（Self-hosted sandboxes）。
- セルフホスト版：サービスもサンドボックスも自社に置く、今回の非公開ベータです。
docs がセルフホスト版を選ぶ場面に挙げるのは、エージェント・セッション・記録を自社に保存しなければならない時と、モデルへの呼び出しを Amazon Bedrock・Claude Models on Google Cloud（Google managed）・Microsoft Foundry・自社のモデルゲートウェイへ送らなければならない時です。道具を自社で動かすだけなら、自社のサンドボックスで足ります（Self-hosted Claude Managed Agents）。
発表によると、エージェントが壊れたビルドの修正やアラートの仕分けを社内のシステムで無人でこなすようになり、サービスごと自社に置きたいチームが出てきたものの、これまでは基盤を自作するしかありませんでした（発表）。自社サーバーはホスト版と基本の API を共有するので、SDK と ant CLI（Anthropic のコマンドラインの道具）を使えますが、一部の機能は使えないか動作が異なります。例外は後半の「使う前に確かめること」で扱います（Self-hosted Claude Managed Agents）。
セルフホストで自社が運用する物｜サーバー・データベース・ワーカー
docs は、1 台以上のサーバー、そのデータベース、自社のサンドボックスをまとめて 1 つのデプロイ（deployment）と呼びます（Self-hosted Claude Managed Agents）。
- サーバー（cma-server）：API を受け、エージェントのループを回し、エージェント・セッション・記録を保存し、モデルが要る時に推論の送り先を呼びます。シェルとファイルの道具は動かしません。
- データベース：PostgreSQL 16 以上です。無いとデータはメモリにあり、再起動で消えます。
- ワーカー：サーバーから仕事を受け取り、シェルとファイルの道具を自社のサンドボックスで動かすプログラムです（
ant beta:workerか SDK のワーカー）。 - 自社のアプリ：SDK か ant CLI でサーバーにつなぐ自社のコードです。
ほかに、自社の ID 基盤でサインインするサーバーのコンソール（Web の画面）と、環境と環境キーを作る管理用 CLI（cma-server-admin）があります。認証情報は 3 種類です（同）。
| 認証情報 | 持つ側 | 何を認証するか |
|---|---|---|
| サーバー API キー | 自社のアプリ・ant CLI・管理用 CLI | 自社サーバーへの要求（ホスト版の Claude API キーの役） |
| 推論の認証情報 | サーバーだけ | 推論の送り先へのモデル呼び出し |
| 環境キー | 仕事を取りに行くワーカー | 1 つの環境の仕事の列と、その環境のセッション |
モデルを呼ぶ推論の送り先（inference provider）は設定 inference.provider で選び、既定は Claude API です（Inference provider）。
| inference.provider | 呼び出しの送り先 | サーバーの認証 |
|---|---|---|
anthropic（既定） |
Claude API | ANTHROPIC_API_KEY |
bedrock |
Amazon Bedrock | AWS の認証情報 |
vertex |
Claude Models on Google Cloud（Google managed） | Google Application Default Credentials |
foundry |
Microsoft Foundry | Foundry の API キーか Microsoft Entra ID |
gateway |
自社で動かすモデルゲートウェイ | ゲートウェイが受け付けるキーかトークン |
エージェントはモデルを claude-opus-5-5 のような Claude API の ID で指定し、サーバーが送り先の ID に訳します（同）。web_search・web_fetch の道具のように、送り先によって使えない機能もあります（Differences from the hosted service）。
守る範囲も自社に移ります。bash の道具はワーカーと同じ権限とネットワークを持つ本物のシェルで、隔離はワーカーを入れる入れ物で決まるため、Compose の組と cma-sandboxes の Helm チャートはセッションごとに別のコンテナかポッドを使います。自分で立てるなら使い捨てのコンテナか VM にし、ふだんと違う使われ方を見つけるのも自社の責任です（Self-hosted Claude Managed Agents）。
4つの設計の原則｜頭と手・認証情報・ネットワーク・記録
発表は、無人で動くエージェントは人が毎手順を確かめられないので限界を仕組みに組み込むとし、3 つの動かし方のどれにも当てはまる 4 つの原則を挙げています（発表）。
原則 1：頭と手を分ける（harness と sandbox）
Claude を呼ぶ harness（頭）と、エージェントのコードが動く sandbox（手）は分けてあります。ループ・セッションの記録・vault の秘密はサンドボックスの外にあり、サンドボックスは道具が要る時だけ起動します（発表）。Anthropic の技術ブログは、生成したコードが認証情報と同じ場所で動くと、プロンプトインジェクション（読ませた文で AI を操る攻撃）で環境の中のトークンが読まれうるため、トークンをサンドボックスから届かない所に置いたと説明しています（Scaling Managed Agents）。
原則 2：認証情報をサンドボックスに入れない（vault）
vault（認証情報を一度登録し、セッションから ID で参照する仕組み）は、認証情報をサンドボックスの外に置くための物です（Authenticate with vaults）。MCP の道具と対応する API の呼び出しでは外のプロキシが認証情報を足し、セルフホスト版では自社で管理する秘密情報の保管サービス（secrets manager）にも保存できます（発表）。設定に secret_store を書くと、新しく作る認証情報の秘密を AWS Secrets Manager・Google Cloud Secret Manager・HashiCorp Vault・Azure Key Vault に書き、データベースには参照だけを残します。既定はデータベースに保存で、前に保存した秘密はそこに残ります（Agent identity and credentials・Data and access）。
- 環境変数の認証情報は、サンドボックスとインターネットの間のプロキシ egress gateway（
cma-egress・既定オフ）をオンにした時だけ使えます。オンにするとサンドボックスはゲートウェイ経由でしか外に出られず、ゲートウェイはegress.allowed_hostnamesのホストにだけつなぎ、本物の値をヘッダーにだけ入れます。Kubernetes のサンドボックスのチャートは、Azure Kubernetes Service（AKS）ではゲートウェイを出していません（同）。 mcp_oauthの認証情報は作れないので、トークンをstatic_bearerで保存し、期限の前に入れ替えます（Differences）。- Git のトークンはサンドボックスに届かず、Git の通信を通すサーバーが足します（同）。
- 環境キーはその環境の全部のセッションのイベントを読み、道具の結果を送れるので、セッションごとに別のサンドボックスを使い、環境キーをサンドボックスに置きません（Data and access）。
原則 3：許可したホストだけに絞る
発表は、許可したホスト以外への要求を止められるとし、壊れたビルドを直すエージェントなら git のホストとパッケージのレジストリだけ、という例を挙げます。サンドボックスを自社で置く時は、同じ制限を自社のファイアウォールで掛けます（発表）。サーバー側では次の 3 つが、設定を書くまで閉じています（Differences）。
- MCP：
mcp.allowed_hostnamesのホストにだけつなぎます。一覧は既定で空、ワイルドカードもサブドメインも無い完全一致です。 - Git：
git.allowed_hostnamesのホストだけを受け付け、push できるのはallowed_push_refsの枝だけです。 - Web の道具：
web_searchとweb_fetchは、設定でオンにするまで使えません。
docs にある MCP と Git の 2 つの設定の例を並べました（公式の例・当社は未実行）。
mcp:
allowed_hostnames:
- mcp.example.com
git:
allowed_hostnames:
- github.com
allowed_push_refs:
- refs/heads/agent/サンドボックスのネットワーク許可はホスト単位で、操作単位ではありません。ホスト版の安全ガイドは、許可したホストへ git push やパッケージの公開も送れると注意しています。自社サンドボックスでは、同等の制限を自社のファイアウォールで設定します（Secure your Managed Agents deployment）。
原則 4：全部の手順を記録する（OpenTelemetry）
Managed Agents は、道具の呼び出しと返ってきた中身まで、エージェントの手順を記録します。記録は OpenTelemetry で書き出せ、すでに使っている監視の道具で見られます（発表）。自社サーバーでの出し方は次の節で扱います。
データの置き場とZDR｜外に出る物・残る物
docs によると、モデル呼び出しのたびに、サーバーはそれまでの会話を推論の送り先へ送ります。サーバーがつなぐ先は、推論の送り先・データベース・許可した MCP サーバーと Git ホスト、設定した時の OpenTelemetry の収集先・ID 基盤・secrets manager などに限られ（ワーカーは入れ物に許したネットワークをそのまま持ちます）、Anthropic につなぐのは送り先が Claude API の時だけです。Anthropic はサーバーとそのログに遠隔で入れません（Data and access in self-hosted Claude Managed Agents）。
- 自社が保存先を管理する物：PostgreSQL を設定した場合のデータベースのエージェント・セッション・記録、secrets manager を設定した時の vault の秘密、サーバーが標準エラーへ出すログ（保存期間はログ基盤の設定で決まる）。データベースを設定しない既定の形では、エージェント・セッション・記録はメモリにあり、再起動で消えます。
- 推論の送り先へ送るモデル入力：モデル呼び出しごとのこれまでの会話（プロンプト・道具の入力と結果）。Claude API へ送る識別用ヘッダーなどは次の段落で扱います。
PostgreSQL を設定した場合、セッションと記録は消すまで残り、古さでは消えません。API で消してもデータベースのバックアップ、書き出したログとトレース、メモリストアに書かれた物には届きません。送り先が Claude API の時は、セッション・エージェント・環境の ID のヘッダーが最大 3 つ付き、止める設定はありません。ID に名前や中身は入りませんが、作った時刻は入ります（同）。
ZDR の効き方
ZDR（ゼロデータ保持）は、API の応答の後にプロンプトと出力を保存しない Anthropic との取り決めで、組織ごとに営業へ申し込みます（API and data retention）。発表は、ZDR を結んでいれば Claude への要求にほかの Messages API の呼び出しと同じく効くとし、docs は、モデルに送る物と返る物はモデルを出す提供元との契約に従うとしています（発表・Data and access）。ZDR のページは Managed Agents を対象外としますが、ホスト版では Anthropic が記録を保存するためで、記録を自社で持つセルフホスト版は例外です（API and data retention）。
- 自社のサンドボックスの形では、記録を保存するのは Anthropic です（Data and access）。
- Amazon Bedrock と Claude Models on Google Cloud（Google managed）では、データの処理者はクラウド側です（API and data retention）。
- Claude Fable 5.2・Claude Mythos 5.2 など、30 日の保存が要り、Anthropic が明示して認めない限り ZDR で使えないモデルがあります（同）。
- 法令で求められた時と、自動の安全の仕組みでフラグが立った時は ZDR があっても保存されることがあり、フラグが立つと入力と出力が最長 2 年残ることがあります（同）。
記録の書き出し｜OpenTelemetryとサーバーのログ
自社サーバーはログを標準エラーに書き、Docker や Kubernetes がそれを集めます。セッション履歴とは別に、OpenTelemetry のトレースとメトリクスは、標準の環境変数でオンにするまで生成せず、その変数が指す先にだけ送ります。サーバーはログもトレースも保存しないので、保存期間は自社のログの仕組みと収集先が決めます（Data and access）。
メトリクスは Prometheus の口でも出せます。既定はオフで、オンにすると認証なしで localhost:9464 で待ち受け、Helm チャートでオンにすると各ポッドの 9464 番で待ち受けるため、NetworkPolicy で止めない限りポッドに経路のある物から届きます（同）。
docs の OpenTelemetry のページ（ベータ）は Claude API と SDK 側の説明です。スパン（記録の 1 段）はセッションへの要求ごととエージェントのターンごとに付き、中身はメタデータだけ（既定）か、プロンプトと応答まで含めるかを選べます。中身まで送ると見張りの基盤がその基盤の決まりで保存するので、自社の要件に合うか確かめるよう書いています（OpenTelemetry tracing for the Claude API）。自社サーバーが出すスパンの名前と中身がこれと同じかは、この記事で読んだ docs の範囲では確認できませんでした。
申し込み方と始め方｜非公開ベータの手順
発表も docs も、Anthropic のアカウント担当に連絡してアクセスを申し込むよう案内しています。docs の始め方は、Docker Compose で 1 台に立てて最初のセッションを動かす手順です（Get started with self-hosted Claude Managed Agents）。
- アカウント担当に申し込む：アクセス（ダウンロード）を申し込みます（発表・Self-hosted Claude Managed Agents）。
- アーカイブを受け取る：アーカイブには版ごとの運用者ガイド
operator-guide.mdが入り、docs は Claude に読ませて設定・運用・接続のコードを手伝わせるよう勧めています（Self-hosted Claude Managed Agents）。 - 前提をそろえる：Claude API キー、Docker Engine と Compose のプラグイン、CPU 2 つ以上の機械（2 つ未満なら
CMA_SANDBOX_CPUSを CPU 数に設定）、初回の起動時のネット接続、opensslとantCLI です。 - Docker Composeで試す：アーカイブの
composeディレクトリで.envを作り、サーバー・PostgreSQL・ワーカーの組を起動して、準備の確認で"status":"ready"が返るのを見ます。 - 最初のセッションを動かす：
antCLI を自社サーバーに向け（ANTHROPIC_API_KEYには Claude API キーでなくサーバー API キー）、エージェントを作ってセッションを始めます。hostnameの結果がcma-sandbox-で始まれば、道具はサンドボックスで動いています。 - Helmチャートで本番：本番には、リリースに入っている 2 つの Helm チャートを Anthropic は勧めています（Get started）。
docs にある例です（公式の例・当社は未実行。sk-ant-... は自分の Claude API キーに置き換える）。まず .env を作ります。
cat > .env <<EOF
CMA_PG_PASSWORD=$(openssl rand -hex 32)
ANTHROPIC_API_KEY=sk-ant-...
CMA_SERVER__API_KEY=$(openssl rand -hex 32)
CMA_STORE__CREDENTIALS_ENCRYPTION_KEY=$(openssl rand -base64 32)
EOF
chmod 600 .env続けて組を起動し、準備ができたかを確かめます。
docker compose up --build -d
curl -s http://127.0.0.1:8400/cma-server/readyzComposeは開発用で、平文の HTTP で動きます（理由と注意は後の読み違い 1）。
使う前に確かめること｜ホスト版との違いと読み違い
ホスト版からは何も写されず、セッションの記録も移りません。エージェント・スキル・vault の認証情報・メモリストアは自社サーバーで作り直します（Differences from the hosted service）。決める前に、次の点を docs と照らします。
| 確かめること | docs の記載 |
|---|---|
| 信頼レベルの分け方 | 1 つのデプロイは 1 つのテナント・1 つの信頼レベル用。分けたい単位ごとに、データベース・サーバー API キー・ワーカーを別にしたデプロイを立てる（Data and access） |
| 秘密の置き場 | secret_store の種類や接頭辞を後から変えると、前に書いた秘密をサーバーが見つけられない（Agent identity and credentials） |
| 使えない機能 | cloud 環境、サーバー上の Messages API と Models API、Files API、mcp_oauth、既製の docx・pdf・pptx・xlsx のスキル、予約実行（scheduled deployments、自社のスケジューラからセッションを開始すれば代替可）、dreams（docs の機能名・代わりの手段は無い）、webhooks（イベントストリームの追跡かイベント一覧の取得で代替し、ワーカーはポーリングできるよう起動したままにする）（Differences） |
| 動きが違う機能 | platform.claude.com のコンソールに自社サーバーの中身は出ない。マルチエージェントは列挙した 1〜20 体への委任だけ。MCP の結果は既定で 100 KiB を超えると切る（同） |
読み違い 1：Compose の組をそのまま本番に使う
❌ 始め方の Docker Compose の組を、そのまま本番のサーバーにする
⭕ Compose の組は開発用で、平文の HTTP で動き、28.3.3 より前の一部の Docker Engine ではローカルネットワークの機械からもポートに届く。本番は Helm チャートを使う（Get started）
読み違い 2：データベースが無くても記録は残る
❌ サーバーを立てれば、セッションの記録は自社に残る
⭕ データベースを設定しない既定の形では、データはメモリにあり再起動で消える。PostgreSQL 16 以上をつなぐ（Self-hosted Claude Managed Agents）
読み違い 3：環境を分ければ信頼レベルも分かれる
❌ 1 つのデプロイの中で環境を分ければ、部署どうしも分かれる
⭕ サーバー API キーは全部の環境に届き、ロールを持つ呼び出し元は全部の環境でセッションを動かせる。信頼レベルごとに別のデプロイにし、中はシングルサインオンのロールで分ける（Data and access）
読み違い 4：push の枝を絞れば上書きも防げる
❌ allowed_push_refs に書いた枝なら上書きされない
⭕ サーバーは force push を拒まないので、書いた枝は上書きされうる。拒むには Git ホスト側で枝を保護する（Differences）
気づいた後にやること・戻せるか
ホスト版の安全ガイドは、動いているエージェントを止める時、user.interrupt を送る、漏れたかもしれない鍵を発行元で替える、セッションが idle になってから archive する、の順を挙げます。interrupt はすでにしたことや送ったことを取り消さず、vault の認証情報を消しても、その秘密で取得済みのトークンはサンドボックスに残ります（Secure your Managed Agents deployment）。自社サーバーは違いの一覧を除いてホスト版と同じ API ですが、予約実行が無いのでデプロイを止める段は当てはまりません（Differences）。自社サーバーの環境キーを失効させる手順は、この記事で読んだ docs では確認できなかったので、リリースの運用者ガイドで確かめてください。
よくある質問
セルフホスト版は誰でも使えますか？
2026年11月13日時点では非公開ベータで、Anthropic のアカウント担当に連絡してアクセスを申し込みます。対象の条件と一般提供の時期は、発表と docs では確認できませんでした（発表）。
セルフホスト版の料金はいくらですか？
発表と docs に、セルフホスト版の料金の記載は見当たりませんでした。ホスト版は製品ページで「トークンの料金に加え、セッションが動く 1 時間ごとに 0.08 ドル」と案内していますが、セルフホスト版に当てはまるかは書かれていないので、担当に確かめてください（Claude Managed Agents）。ホスト版の課金の経緯は Claude Sonnet 5料金恒久化とManaged Agents新課金 にまとめています。
Claude Agent SDK とは何が違いますか？
製品ページは、Agent SDK は自社の機械でローカルに動き、Managed Agents はセッション・サンドボックス・権限を管理したうえでクラウドでエージェントを動かす基盤を出す、と分けています。セルフホスト版は、その Managed Agents のサーバーを自社の環境で動かす形です。SDK で自分の基盤に組む方法は Claude Agent SDK実践ガイド｜Python自律エージェント構築 にあります。
ZDR を結んでいれば何も残りませんか？
いいえ。ZDR が効くのは、送り先が Claude API の時のモデルへの要求です。PostgreSQL を設定した場合、セッションの記録は自社のデータベースに消すまで残ります。設定しない既定の形ではメモリにあり、再起動で消えます。Bedrock・Google managed・Foundry・自社のゲートウェイへ送るなら、その送り先の契約と保存の決まりに従います。30 日の保存が要り ZDR で使えないモデルがあり、法令やフラグによる保存の例外もあります（Data and access・API and data retention）。
Anthropic は自社サーバーやログを見られますか？
docs は、Anthropic はサーバーとそのログに遠隔で入れず、サーバーが受け付ける認証情報を Anthropic は発行も保有もしないと書いています。ただし送り先が Claude API の時は、会話の中身とセッションなどの ID のヘッダーが Anthropic に届きます（Data and access）。
まとめ｜今日・今週・今月にやること
セルフホスト版は、Managed Agents のサービスとサンドボックスを自社の環境に置く非公開ベータです。ホスト版と基本の API を共有しますが、一部の機能は使えないか動作が異なります。記録の置き場と推論の送り先は自社で決められます。その分、サーバー・ワーカーと、設定した場合のデータベースの運用と守りは自社の仕事になります。
- 今日やること：保存を自社に置く必要と、推論の送り先を選ぶ必要のどちらがあるかを決める。道具だけなら自社のサンドボックスで足りる。
- 今週中：ホスト版との違いで、使えない機能（webhooks・予約実行・
mcp_oauthなど）に当たらないかを確かめ、担当に申し込む。 - 今月中：信頼レベルごとのデプロイの分け方、許可するホスト、secrets manager、OpenTelemetry の送り先を決めてから Compose で試す。
あわせて読みたい：
- Claude Managed Agentsとは｜エージェント基盤新API — Managed Agents そのものの仕組み（2026年4月の記事）
- MCP認可の実装ガイド｜OAuth 2.1対応 — MCP サーバーに認証を付ける時の考え方
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
参照日はすべて 2026-11-13 です。
- Operate Claude Managed Agents inside your security perimeter — Anthropic（2026年11月12日）
- Self-hosted Claude Managed Agents — Claude Platform Docs
- Differences from the hosted service — 同
- Inference provider — 同
- Data and access in self-hosted Claude Managed Agents — 同
- Agent identity and credentials — 同
- Get started with self-hosted Claude Managed Agents — 同
- Self-hosted sandboxes — 同
- Authenticate with vaults — 同
- Secure your Managed Agents deployment — 同
- OpenTelemetry tracing for the Claude API — 同
- API and data retention — 同
- Scaling Managed Agents: Decoupling the brain from the hands — Anthropic Engineering（2026年4月8日）
- Claude Managed Agents — Claude 製品ページ
