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

Coworkのセキュリティ設計全体(データの所在・保持期間・学習利用・監査ログ)はCoworkセキュリティ — データはどこに置かれ誰が触れるかで扱っています。本稿はそのうち、クラウド/ローカルの2セッション構成と、Connectorのデータ取得がサンドボックスの内側・外側のどちらで完結するかという実行アーキテクチャの経路に絞って掘り下げます。

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

Coworkのタスクは、既定ではクラウドセッションとして動きます。エージェントのループとコード実行はAnthropicのサーバー上で走り、セッションとファイルは利用者のClaudeアカウントに保存されます。従来からあるローカルデスクトップ展開では、ローカルセッションとして利用者のデバイス上で実行され続けます。

どちらのモードでも、セッションごとに新しいサンドボックスまたはVMが作られ、終了時に破棄されます。組織をまたいで状態が共有されることはありません。

Coworkはクラウドセッションとローカルセッションという2つの経路に分かれており、どちらを使うかで管理者が制御できる項目そのものが変わります。既存のデスクトップ導入を続ける組織はローカルセッションの権限モデルを、新規にCoworkを使い始める組織はクラウドセッションのネットワーク設定を、それぞれ最初に確認する対象になります。

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

ここが本題です。CoworkがSalesforceやGmailといった業務SaaSのデータを取得するとき、その呼び出しはサンドボックスの外側、サーバー側で完結します。ローカルファイルの読み書きとは扱いがはっきり分かれています。

サンドボックス自体が保持するのは、数時間で失効するセッション限定のトークンだけです。Connectorの認証トークンはサンドボックスの中に一切入りません。GmailやSalesforceに接続する際にOAuthで取得した認証情報は、サーバー側で管理され、Connector呼び出しもサーバー側から発行されます。

この設計の効果は明確です。仮にサンドボックス内のコード実行が乗っ取られたとしても、業務SaaSへの認証情報そのものはサンドボックスに存在しないため、そこから抜き取ることができません。Connectorの権限がどう決まるか(接続した本人の権限を継承し、組織のアクション制限で狭められる)はClaude Connectorsの権限設定でよくある失敗と対策で扱っていますが、その権限判定自体もサーバー側で行われる処理の一部です。

クラウドセッションでデータがどう扱われるか

クラウドセッションは、社内ネットワークやクラウドのメタデータアドレスに既定で到達できず、外向きの通信はすべてサンドボックス側で迂回できない必須プロキシーを経由して許可リストの送信先だけに届きます。保持する認証情報は数時間で失効する短命トークンのみで、保存される記録は組織・アカウント単位でスコープされ、Anthropicの企業・研究・モデル訓練用の環境とも切り離された基盤で運用されています。この5項目の詳細と、Enterprise組織の既定値・ネットワークアクセスポリシーの設定手順はCoworkセキュリティ — データはどこに置かれ誰が触れるかにまとめています。

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

既存のデスクトップ展開が使うローカルセッションは、2つの実行環境に分かれます。エージェントのループはデバイス上でネイティブに動き、会話処理・接続済みフォルダーへのファイル読み書き・Web取得・ローカルのプラグインMCPサーバーを担当します。これはアプリケーション層の権限システムで、接続フォルダーのルールと組織のネットワーク送信設定を守りながら動作します。

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

デバイス上のファイルやブラウザにはどう届くか

クラウドセッションが利用者のデバイス上のローカルファイルやブラウザーを必要とする場合、その要求はデバイス側のClaude Desktopアプリを経由し、Anthropicが仲介する接続を通ります。ローカルファイルへのアクセスは、利用者がデスクトップ側で接続済みのフォルダーに限られ、ローカルのツール呼び出し1件ごとに利用者の権限と照合されます。デスクトップアプリがオフラインの場合、クラウドセッションはそのデバイスに到達できません。

クラウドセッションがデスクトップアプリ経由で開いたローカルファイルを含め、エージェントの作業はAnthropicのサーバー上で処理されます。デバイス上に留まり続けるわけではありません。会話データはTeam・Enterpriseの他のデータと同じ商用契約の下で扱われ、Claudeの学習には使われません。

管理者が制御できる範囲

管理対象デバイスでは、MDM(モバイルデバイス管理)経由の2つのキー(isLocalDevMcpEnabled・isDesktopExtensionEnabled)でローカルMCPサーバーとデスクトップ拡張の実行を止められます。どちらもClaude Desktopアプリを管理する設定のため、ローカルセッションだけでなく、クラウドセッションがデスクトップアプリ経由で到達する範囲にも及びます。組織全体のCoworkトグルとの依存関係を含む詳細はCoworkセキュリティ — データはどこに置かれ誰が触れるかにまとめています。

組織設定側には、クラウドセッション専用の制御が別に用意されています。組織全体でクラウドセッションのオン・オフを切り替える、到達可能な送信先を決めるネットワークアクセスポリシーを設定する、権限が絡むツール呼び出しごとに毎回の承認を必須にする、信頼済みデバイスの登録と直近のサインインを要求する、といった項目です。ローカルMCPサーバーを無効化した管理対象デバイスでは、クラウドセッションからもフォルダー限定のデスクトップファイルツールしか使えなくなります。

よくある質問

デバイスがVMを起動できない場合どうなりますか

ローカルセッションの場合、ファイルツールとWebツールは動き続けます。シェルコマンドとコード実行は、VMが復旧するまで「workspace unavailable」と報告されます。

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

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

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

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

Enterpriseではクラウドセッションのネットワークアクセスは既定でどうなっていますか

既定はネットワークアクセスなしです。組織設定でネットワークアクセスポリシーを個別に設定するまでは、外部への到達は許可されません。

組織全体のCoworkトグルをオフにすると、デバイス側の制御はどうなりますか

デバイス側の2つのMDMキーは、組織設定の「Organization settings > Cowork」にある全体トグルがオンのときだけ意味を持ちます。全体トグル自体がオフであればCoworkそのものが使えないため、デバイス側の制御を検討する前提が成立しません。まず全体トグルの状態を確認してから、デバイス単位の絞り込みに進みます。

まとめ

Coworkが業務SaaSのデータを取得する仕組みの核心は、Connectorの呼び出しがサンドボックスの外側、サーバー側で完結するという設計にあります。認証トークンはサンドボックスに入らず、コード実行環境が乗っ取られてもSaaS側の認証情報は流出しません。クラウドセッションが既定になったことで、ネットワークアクセス・データ層のテナント分離といった制御が組織設定側に集約され、ローカルセッションは接続済みフォルダーとVMの隔離という別の枠組みで動きます。Coworkの基本機能や料金はClaude Cowork入門、Connectorsの3層構造や承認モードはClaude CoworkのConnectors一覧、Computer Useやスケジュール機能の内部挙動はClaude CoworkのComputer Use・VMサンドボックスにまとめています。