Claude Media
Claude Coworkのデータ取得の仕組み — サンドボックスとConnectorsの役割分担

Claude Coworkのデータ取得の仕組み — サンドボックスとConnectorsの役割分担

CoworkがGmailやSalesforceのデータを取得するとき、クラウドセッションではConnectorの呼び出しが隔離サンドボックスの外側、サーバー側から出ます。クラウドとローカルでデータの通り道がどう変わるかをまとめます。

CoworkがGmailやSalesforceのデータを取りに行くとき、クラウドセッションでは認証トークンがサンドボックスの中に入りません。Connectorの呼び出しは、コードを実行する隔離環境の外側にあるサーバー側で行われます。一方、利用者のPC上のファイルやブラウザーは別の経路を通ります。

この記事は、データの種類ごとにどの経路を通るかを切り分けるための整理です。データの所在・保持期間・学習利用・監査ログといったセキュリティ全体はCoworkセキュリティ — データはどこに置かれ誰が触れるかで扱っています。

Coworkはどこでタスクを実行しているか

Coworkのタスクは、既定ではクラウドで動きます。エージェントのループとコード実行はAnthropic管理のインフラ上にある隔離された一時的なサンドボックスで走り、セッションとファイルは利用者のClaudeアカウントに保存されます。既存のデスクトップ導入向けには、エージェントのループもコード実行も利用者のデバイス上で動くローカルセッションが引き続き使えます。

くらべる

クラウドセッションとローカルセッション

既定

クラウドセッション

エージェントのループもコード実行も、Anthropicのサーバー上の隔離サンドボックスで動きます。セッションごとにサンドボックスが作られ、終わると破棄されます。組織をまたいで状態は共有されません。

既存のデスクトップ導入

ローカルセッション

エージェントのループはデバイス上でネイティブに動きます。シェルコマンドやClaudeが書いたコードは、デバイス内の専用VM(隔離仮想マシン)で実行されます。

どちらを使うかで、管理者が触れる設定が変わります。クラウドセッションには組織設定側の専用の制御があり、ローカルセッションはデバイス側の設定と接続済みフォルダーのルールで枠が決まります。

業務SaaSのデータはどこで取得されるか

Salesforceの取引先やGmailの本文のような業務SaaSのデータは、サーバー側で取得されます。クラウドセッションの説明では、サンドボックスが持つのは数時間で失効するセッション限定のトークンだけで、Connectorの認可トークンはサンドボックスに入りません。Connectorの呼び出しはサーバー側から出ます。

この設計が効くのは、サンドボックス内のコード実行が悪用された場合です。SaaSへの認証情報がそもそも手元に無いので、そこから取り出すことができません。ローカルファイルの読み書きとは扱いがはっきり分かれる点です。

Connectorが何に触れられるかは別の層の話です。接続した本人が持つ権限を引き継ぎ、組織のアクション制限でさらに狭められます。ソース側で見えない記録やチャンネルは、Claudeからも見えません。共有の資格情報を使うカスタムConnectorだけは、その資格情報が触れる範囲に届きます。この権限の決まり方と失敗例はClaude Connectorsの権限設定でよくある失敗と対策で扱っています。

データの種類で経路が変わる

同じCoworkでも、取りに行く先によって通り道が違います。次の3つで考えると切り分けやすくなります。

経路

データの取得先と経路

  • 業務SaaS(Gmail・Salesforceなど)

    クラウドセッションでは、Connectorの呼び出しがサーバー側から出ます。認可トークンはサンドボックスに入りません。

  • PC上のファイル・ブラウザー

    クラウドセッションの場合、Claude Desktopアプリを経由し、Anthropicが仲介する接続で届きます。範囲は利用者がデスクトップ側で接続したフォルダーに限られます。

  • 自社のMCPサーバー(カスタムConnector)

    リモートMCPを使うカスタムConnectorには、利用者のPCではなくAnthropicのクラウドから接続します。サーバーはインターネット越しに到達できる必要があります。

3つ目は見落としやすい点です。サポート記事は、カスタムConnectorがAnthropicのクラウドから呼ばれることを、CoworkやClaude Desktopのようにローカルで動くアプリでも同じだと明記しています。社内ネットワーク上やVPNの内側にあるMCPサーバーは、自分のPCから届いていても接続に失敗します。ファイアウォールの内側にある場合も同じです。対処として、AnthropicのIPアドレス範囲を自社のファイアウォールで許可し、Claudeからの接続がサーバーに届くようにする方法が案内されています。

ディレクトリから入れるConnectorにも、仲介の仕組みの話があります。リモートConnectorはClaudeアカウントを通じて設定・仲介され、接続は利用者のPCのネットワークではなくAnthropicのサーバーから出ます。この点は、CoworkやClaude DesktopをPC上で動かしていても変わりません。

ただし、認可トークンがサンドボックスに入らないという説明は、クラウドセッションの隔離についてのものです。ローカルセッションのVMについて、同じ形の説明はありません。

クラウドセッションでデータはどう守られるか

クラウドセッションの基盤は、Anthropicの企業・研究・モデル訓練の環境とは切り離されています。そのうえで、隔離は次の5つの性質で説明されています。

  • 利用者のネットワークには既定で届かない。プライベート・内部・リンクローカル・クラウドのメタデータの各アドレスにも、Anthropic内部のシステムにも到達できません
  • ネットワークアクセスは、既存のポリシーに従う
  • 外向きの通信は、サンドボックスの側で設定を変えたり迂回したりできない必須のプロキシーを通り、許可リストにある宛先だけに届く
  • 保持するのは数時間で失効するトークンだけ
  • 保存される記録は、組織とアカウント単位でスコープされている

ネットワークアクセスの設定は、ローカルのCoworkやチャットと同じ設定が使われます。Enterpriseでは「ネットワークアクセスなし」が既定で、組織が許可する宛先を設定するまでは外部に出られません。設定手順やEnterprise組織の既定値は、前述のセキュリティ記事にまとめています。

ローカルセッションでは何が変わるか

ローカルセッションは、デバイス上の2つの実行環境に分かれます。

エージェントのループはネイティブに動き、会話処理、接続済みフォルダーへのファイル読み書き、Web取得、ローカルのプラグインMCPサーバーを担当します。ここを守るのはアプリケーション層の権限システムで、接続フォルダーのルールと、組織のネットワーク送信設定が効きます。

シェルコマンドやClaudeが書いたコードは、専用のLinux VMで動きます。ホストOSからハイパーバイザーで隔離されており、macOSではApple Virtualization.framework、WindowsではHyper-Vが使われます。VMはネットワーク送信のフィルタリング、システムコールの制限、セッションごとのユーザー分離を独自に持ちます。

デスクトップアプリ越しに届くとき、データはどこで処理されるか

クラウドセッションがPC上のファイルやブラウザーを必要とするとき、要求は利用者のデスクトップアプリを通ります。アクセスは接続済みフォルダーに限られ、ローカルのツール呼び出しは1件ごとに利用者の権限と照合されてから実行されます。アプリがオフラインなら、クラウドセッションはそのデバイスに届きません。

見落とされやすいのは処理の場所です。デスクトップアプリ経由で開いたファイルも、クラウドセッションの作業としてAnthropicのサーバー上で処理されます。デバイスの外に出ないわけではありません。会話データはTeam・Enterpriseの他のデータと同じ商用上の取り決めで扱われ、Claudeの学習には使われないと説明されています。

届かないときの切り分け

Coworkからデータに届かないときは、原因が経路ごとに違います。サポート記事の記述から導ける順に並べると、次のようになります。

切り分け

データに届かないときの確認順

  1. 1

    組織全体のCoworkトグルを見る

    Organization settings > Coworkの有効化がオフなら、Coworkそのものが使えません。デバイス側のMDM設定は、このトグルがオンのときにだけ意味を持ちます。

  2. 2

    接続先の種類を見る

    ディレクトリのConnectorか、自社のMCPサーバーかで、確認先が変わります。自社のMCPサーバーなら、公開インターネットから到達できるか、IPレンジの許可が済んでいるかを見ます。

  3. 3

    PC上のファイルなら、デスクトップアプリの状態を見る

    クラウドセッションがローカルに届くのはアプリがオンラインのときだけです。届く範囲も、接続したフォルダーまでです。

  4. 4

    ローカルセッションのシェルが動かないなら、VMを疑う

    VMが起動できないと、ファイルツールとWebツールは動き続けますが、シェルとコード実行は「workspace unavailable」と報告されます。確認順序はCoworkで「workspace unavailable」と出たときの対処法にあります。

管理者が制御できる範囲

管理対象デバイスでは、MDM(モバイルデバイス管理)の2つのキーで範囲を絞れます。isLocalDevMcpEnabledをfalseにするとプラグイン同梱のMCPサーバーとローカル設定のMCPサーバーが止まり、isDesktopExtensionEnabledをfalseにするとMCPBとDXTの拡張サーバーの実行が止まります。どちらも組織設定ではなく、デバイス側でMDM経由で適用します。

この2つはClaude Desktopアプリを対象にしているので、ローカルセッションだけでなく、クラウドセッションがデスクトップアプリ経由で届く範囲にも及びます。ローカルMCPサーバーはクラウドセッションでは動きません。ローカルMCPを無効化した管理対象デバイスでは、クラウドセッションから使えるのはフォルダーに限定されたデスクトップのファイルツールだけになります。

クラウドセッション専用の制御は、組織設定にあります。

  • クラウドセッションの有効・無効を組織単位で切り替える(ローカルのデスクトップCoworkは残せる)
  • 到達できる宛先を決めるネットワークアクセスポリシーを設定する
  • 「常に許可」を無効にして、権限が絡むツール呼び出しごとの承認を必須にする。メンバーが承認なしで実行できるかどうかも制御する
  • 信頼済みデバイスの登録と直近のサインインを要求する。有効にすると、組織内のすべてのクラウドセッションに適用される

MDMキーと組織トグルの依存関係など、管理画面まわりの詳細はCoworkセキュリティ — データはどこに置かれ誰が触れるかにあります。

よくある質問

EDR(エンドポイント検知)ツールでVMの中身を監視できますか

できません。VMはホスト側のセキュリティツールから設計上隔離されており、クラウドセッションはエンドポイントの外側で動くため、EDRはどちらも観測できません。エンドポイントの可視性に依存するコンプライアンス要件がある組織は、導入前にこの点を織り込む必要があります。

Coworkの活動はCompliance APIやOpenTelemetryで捕捉されますか

されます。Claude・Claude Desktop・Claude Mobile経由のCowork活動はCompliance APIで捕捉されます。Team・Enterpriseプランの管理者は、OpenTelemetryでも組織内のCowork活動を監視できます。

まとめ

SaaSのデータ、PC上のファイル、自社のMCPサーバーは、それぞれ別の経路を通ります。届かないときは「どの種類のデータか」から確認するのが近道です。クラウドセッションの隔離とConnectorの分離は、サンドボックス内のコードが悪用されても、SaaSの認証情報を持ち出せないようにするための設計です。

Coworkの基本機能や料金はClaude Cowork入門、Connectorsの3層構造や承認モードはClaude CoworkのConnectors一覧、Computer Useやスケジュール機能の内部挙動はClaude CoworkのComputer Use・VMサンドボックスにあります。

この記事を共有:XはてブLinkedIn