Claude Platform Docs
Managed Agentsセルフホスト型Managed Agents

セルフホスト型Claude Managed Agentsにおけるデータとアクセス

セルフホスト型Claude Managed Agentsがネットワーク外に送信するもの、ログ、トレース、メトリクスの送信先、データの保持期間、サーバーにアクセスできる主体、テナントを分離する方法について説明します。

セルフホスト型Claude Managed Agentsでは、サーバー、そのデータベース、および「worker」(ワーカー)がエージェントのシェルツールとファイルツールを実行するサンドボックスを、ご自身で運用します。このページでは、セキュリティレビューで寄せられる質問に回答します。サーバーの推論プロバイダーとは、サーバーのモデル呼び出しに応答するサービスです。サーバーがAnthropicに接続するのは、そのプロバイダーがClaude APIである場合のみです。Anthropicはサーバーやそのログへのリモートアクセス権を持ちません。

ネットワーク外に送信されるもの

サーバーが行うすべての接続

サーバーが接続するのは次の宛先のみです。

  • お客様の推論プロバイダー
  • サーバーのデータベース
  • サーバーがモデル呼び出し用の認証情報をサービスから取得する場合は、その認証情報を発行するサービス
  • お客様の推論プロバイダーが、モデルを別のサービスで一覧表示する場合は、クラウドプロバイダーのモデル一覧表示サービス
  • お客様が許可するMCPサーバー
  • セッションが使用するリポジトリのために、お客様が許可するGitホスト
  • OpenTelemetryコレクターを構成する場合は、そのコレクター
  • シングルサインオン用にIDプロバイダーを構成する場合は、お客様が列挙するIDプロバイダー
  • シークレットマネージャーまたは鍵管理サービスを構成する場合は、そのサービス
  • そのシークレットマネージャーまたは鍵管理サービスに対するサーバーの認証情報を発行するサービス
  • お客様がサーバーの呼び出し先として構成するその他のサービス

デフォルトの推論プロバイダーはClaude APIです。別の推論プロバイダーを設定した場合、モデル呼び出しは代わりにそちらに送信されます。サーバーがAnthropicに接続するのは、Claude APIが推論プロバイダーである場合のみです。

推論プロバイダーがウェブ検索ツールとウェブフェッチツールを提供している場合、推論プロバイダーがそれらを実行します。サーバーはそれらのために独自の接続を行いません。これらのツールは、サーバーの設定で有効にするまでオフになっています。

サーバーのトラフィックを確認するには、お客様のエグレスプロキシまたはファイアウォールのログをこのリストと比較してください。サーバーからClaude APIへのリクエストには、User-Agentヘッダーが含まれます。サーバーソフトウェアを示すフィールドを参照してください。

ワーカーがアクセスできる範囲

宛先のリストはサーバーのみを対象としています。エグレスゲートウェイを実行する場合、エグレスゲートウェイはお客様が指定したホストに接続し、それらのホスト用にお客様が保存した認証情報の値を送信します。ワーカーは別です。ワーカーは、それが実行されるコンテナ、VM、またはその他のサンドボックスに対してお客様が許可したネットワークアクセスを持ちます。エージェントがワーカーを通じて実行するすべてのコマンドも、同じネットワークアクセスを持ちます。

サーバーが推論プロバイダーに送信するもの

各モデル呼び出しには、プロンプト、ツール入力、ツール結果を含む、それまでの会話が含まれます。

Claude APIが推論プロバイダーである場合、各モデル呼び出しには最大3つのヘッダーも含まれます。これらのヘッダーには、お客様のサーバーが生成したIDが格納されます。

ヘッダー格納される内容
anthropic-managed-agents-session-id呼び出しが処理するセッションのID
anthropic-managed-agents-agent-idそのセッションのエージェントのID
anthropic-managed-agents-environment-idそのセッションの環境のID

IDには名前もコンテンツも含まれませんが、お客様のサーバーがそのIDを作成した時刻はエンコードされています。これらのヘッダーにより、Anthropicは使用量をセッション、エージェント、または環境に帰属させることができます。これらを無効にする設定はありません。ANTHROPIC_BASE_URLがプロキシまたはゲートウェイを指している場合、ヘッダーはそちらに送信されます。その他の推論プロバイダーでは、サーバーがこれらのヘッダーを送信することはありません。

Claude APIが推論プロバイダーである場合、サーバーはモデル呼び出し用の認証情報が有効であることもClaude APIに確認します。この確認は起動時に行われ、その後はhealth.check_intervalを変更しない限り60秒ごとに行われます。これらの確認では推論は実行されません。また、3つのヘッダーはいずれも含まれません。

サーバーソフトウェアを示すフィールド

Claude APIへのすべてのリクエストには、サーバーソフトウェアとそのバージョンを示すUser-Agentヘッダーが含まれます。このヘッダー自体はお客様のデプロイメントを識別するものではありません。すべてのClaude APIリクエストと同様に、APIキーによってお客様の組織が識別されます。Anthropicはこのヘッダーを使用して、セルフホスト型Managed Agentsの使用量をカウントできます。

モデル呼び出しには、リクエスト本文のmetadata.user_idとしてcma-serverというラベルが含まれる場合もあります。このラベルはすべてのサーバーで同じであるため、ラベル自体はお客様のデプロイメント、ユーザー、セッションを識別するものではありません。呼び出しがAnthropicに到達する場合、プロキシがUser-Agentヘッダーを削除したときでも、Anthropicはこのラベルを使用してセルフホスト型Managed Agentsの使用量をカウントできます。

呼び出しにラベルが含まれるかどうかは、呼び出しの送信先によって異なります。

  • サーバーは次の呼び出しでラベルを送信します: Claude API、Microsoft Foundry、およびClaude APIと同じリクエストを受け付けるモデルゲートウェイへの呼び出し。
  • サーバーは次の呼び出しではmetadata.user_idを送信しません: Amazon Bedrock、Claude Models on Google Cloud (Google managed)、および別のリクエスト形式を受け付けるモデルゲートウェイへの呼び出し。

モデルゲートウェイまたはプロキシが呼び出しを別のプロバイダーに転送する場合、metadata.user_idも一緒に送信される可能性があります。metadata.user_idを含む呼び出しでは、お客様独自のプロキシまたはゲートウェイがリクエスト本文でそれを受け付ける必要があります。このフィールドが拒否されると、すべてのモデル呼び出しが失敗します。

ログ、トレース、メトリクスの送信先

サーバーはログを標準エラー出力に書き込みます。Docker、Kubernetes、またはサービスマネージャーの下でサーバーを実行する場合、そのシステムが標準エラー出力からログを収集します。

サーバーは、標準のOpenTelemetry環境変数で有効にするまで、トレースやメトリクスを記録しません。それらは、これらの変数が指す場所にのみ送信されます。Prometheusエンドポイントでメトリクスを公開することもできます。サーバーがリッスンする場所を参照してください。

データの保持期間

ログ、トレース、メトリクスの保持期間は、お客様のログパイプライン、お客様のコレクター、およびお客様のトレーシングバックエンドによって決まります。サーバーはログファイルを保持せず、トレースやメトリクスも保存しません。

サーバーは、エージェント、セッション、セッション履歴など、それ以外のすべてをお客様のデータベースに保存します。データベースを設定しない場合(これがデフォルトです)、サーバーはそのデータをメモリ内に保持し、再起動するとデータは消去されます。シークレットマネージャーを設定した場合、サーバーは新しい各ボールト認証情報のシークレットを、データベースではなくシークレットマネージャーに保管します。それ以前に保存されたシークレットはデータベースに残ります。

セッションとその履歴は、お客様が削除するまでお客様のデータベースに保持されます。サーバーは、アーカイブ済みかどうかにかかわらず、経過期間を理由にセッションを削除することはありません。APIを通じてセッションを削除すると、そのセッションとその履歴がお客様のデータベースから削除されますが、サーバーはセッションのIDを保持します。セッションの実行中は、サーバーが削除を拒否する場合があります。削除は、データベースのバックアップ、エクスポートされたログやトレース、エージェントがメモリストアに書き込んだものなど、他の場所にあるコピーには及びません。Kubernetesでは、セッションのボリュームを解放するで説明されているとおり、削除後もセッションの/workspaceボリュームはそのまま残ります。

サーバーがモデルに送信するもの、およびモデルが返すものは、モデルを提供するプロバイダーとお客様の組織との間の契約の対象となります。その契約のデータ保持条件が適用されます。Claude APIがモデルを提供する場合、お客様の組織がAnthropicとの間で締結しているデータ保持契約および設定が適用されます。お客様の組織がゼロデータ保持(ZDR)の取り決めを結んでいる場合、その取り決めは、他のMessages API呼び出しと同じ方法でこれらのモデル呼び出しを対象とします。

「APIとデータ保持」ページでは、Claude Managed AgentsをZDRの対象外として記載しています。これは、Anthropicがサービスを実行する場合、Anthropicはセッションのトランスクリプトをお客様が削除するまで保存するためです。トランスクリプトを保存する主体は、サービスを実行する主体によって異なります。

  • Anthropicが実行する場合: Anthropicが保存します。セルフホスト型サンドボックスでは、ご自身でホストするのはサンドボックスのみで、それ以外はAnthropicが実行します。
  • セルフホスト型Managed Agentsを使用してお客様が実行する場合: お客様がご自身で保存します。

サーバーにアクセスできる主体

Anthropicはサーバーやそのログへのリモートアクセス権を持ちません。お客様のアプリケーションとワーカーがサーバーに接続します。サーバーがワーカーに接続することはありません。

サーバーが受け付ける認証情報

Anthropicはサーバーが受け付ける認証情報を一切発行せず、いずれも保持していません。サーバーが受け付ける認証情報は、すべて次のいずれかです。

  • お客様が設定または作成したもの
  • お客様のIDプロバイダーが発行したもの
  • サーバー自身が生成したもの(作業ごとにワーカーに渡すトークンなど)

サーバーがリッスンする場所

サーバーは1つのアドレスとポートでAPIリクエストを受け付けます。サーバーはさらに2つのリスナーを開きますが、それぞれ有効にした場合のみです。

リスナーデフォルトで有効デフォルトのアドレス要求するもの
APIリクエストはい127.0.0.1:8400(同じマシンからのみアクセス可能)。アドレスとポートを変更するには、server.addrを設定します。サーバーが受け付ける認証情報を参照してください。
サーバー上のコンソール(Webページ)はい。提供を停止するには、コンソールを無効にするを参照してください。APIリクエストと同じアドレスとポートページの読み込みには、アクセスできる人であれば何も要求しません。コンソールで何らかの操作を行うには、お客様のIDプロバイダーを通じてサインインする必要があります。
Prometheusメトリクスエンドポイントいいえlocalhost:9464(同じマシンからのみアクセス可能)認証情報なし
エグレスゲートウェイ用のサーバーのリスナーいいえすべてのインターフェースのポート8410ゲートウェイの鍵

最後の2つのリスナーの詳細は次のとおりです。

  • Prometheusメトリクスエンドポイント: 認証情報を要求しないため、誰がアクセスできるかはリッスンする場所によって決まります。OTEL_METRICS_EXPORTERをprometheusに設定し、アドレスを設定しない場合、デフォルトのアドレスでリッスンします。サーバーのHelmチャートで有効にした場合、すべてのサーバーPodのポート9464でリッスンします。その場合、NetworkPolicyがそのトラフィックをブロックしない限り、Podのアドレスへのルートを持つものは何でもアクセスできます。
  • エグレスゲートウェイ用のリスナー: エグレスゲートウェイは、サンドボックスとインターネットの間に置くオプションのプロキシです。サーバーは、ゲートウェイ用に別のポートでリッスンします。このリスナーはプレーンなHTTPで通信し、その応答には保存された認証情報の値が含まれます。ComposeスタックとサーバーのHelmチャートでは、ゲートウェイのみがこのリスナーにアクセスできるようになっています。サーバーを別の方法で実行する場合も、同様にしてください。

Docker Composeスタックは、Dockerホストのループバックアドレス127.0.0.1でポート8400を公開します。Docker Engine 28.3.3以降を実行してください。一部の以前のリリースでは、ホストのローカルネットワーク上のマシンが、ループバックで公開されたポートにアクセスできてしまいます。ポートを別のアドレスで公開するには、.envでCMA_PUBLISH_ADDRESSを設定してください。

マルチテナンシー

各デプロイメントは、1つの信頼レベルで1つの「tenant」(テナント)にサービスを提供します。1つのデプロイメント内の環境では、信頼レベルは分離されません。サーバーAPIキーはすべての環境にアクセスできます。ロールを持つすべての呼び出し元は、その環境のワーカーがアクセスできるネットワークやファイルを使って、すべての環境でセッションを実行できます。

分離する対象実施すること
テナント各テナントに、専用のデータベース、サーバーAPIキー、ワーカーを持つ専用のデプロイメントを用意してください。
信頼レベルの異なるワークロード各信頼レベルに専用のデプロイメントを用意し、テナントの場合と同様に設定してください。例としては、信頼できるコードと信頼できないコード、または一部の呼び出し元のみが使用できるシステムにアクセスするワーカーなどがあります。
デプロイメント内の呼び出し元シングルサインオンを有効にし、グループをdeveloperまたはuserロールにマッピングし、サーバーAPIキーは管理者用に確保してください。各ロールでできることに、それらの呼び出し元に表示される内容が示されています。

シークレットマネージャー、シングルサインオン、モデルゲートウェイ

デプロイメントでこれらのサービスのいずれかを使用する場合は、そこでもデプロイメントを分離してください。

  • シークレットマネージャー: シークレットマネージャーの制限に記載されているとおりに、デプロイメント間でシークレットを分離してください。
  • シングルサインオン: 他のどのデプロイメントにも記載されていないaudiencesエントリを各デプロイメントに設定し、他のデプロイメントのトークンを拒否するようにしてください。各信頼レベルのデプロイメントでは、そのレベルで許可された呼び出し元にのみロールを付与し、default_roleは設定しないでください。
  • モデルゲートウェイ: デプロイメントを区別するには、inference.headersの下でx-tenant-idなどのヘッダーに、デプロイメントごとに異なる値を設定してください。

ロールが制限しないもの

ロールが制限するのは、呼び出し元が自身のトークンで行うリクエストのみです。エージェントが実行するコードは、そのサンドボックスが保持する任意の認証情報を使ってサーバーを呼び出すことができます。環境キーは、その環境内のすべてのセッションでイベントを読み取り、ツール結果を投稿できます。そのため、各セッションは専用のサンドボックスで実行し、環境キーはそのサンドボックスに置かないでください。セルフホスト型Claude Managed Agentsを始めるおよびKubernetesにデプロイするのスタックはこのように構成されています。

このページは役に立ちましたか?