CoworkとEDR(エンドポイント検知)ツールの相性問題
CoworkのVM分離設計により、EDR(エンドポイント検知)ツールはローカルVM内もクラウドセッションも観測できません。導入前に押さえておきたい代替の可視化手段をまとめます。
CoworkのVM分離設計は、EDR(エンドポイント検知・Endpoint Detection and Response)ツールに対しても分離として働きます。ローカルのコード実行VMも、クラウド上のセッションも、EDRからは中身が見えません。これはバグではなく設計上の帰結で、コンプライアンス上の可視性を求める組織は、Coworkを展開する前にこの前提を織り込む必要があります。
EDRツールはCowork内の活動を検知できるか
できません。EDRツールはVM内部の活動を確認できないことが公式のFAQで明確に否定されています。VMはホスト側のセキュリティツールから設計上分離されており、クラウドセッションはエンドポイントの外で完全に動くため、EDRツールはそちらも観測できません。
ここで言う「VM」は、Coworkのコード実行専用のLinux VMを指します。画面操作を行うComputer Useには同じ意味でのサンドボックスは無く、両者は別物として扱う必要があります。EDRの盲点として問題になるのは、あくまでコード実行VMとクラウドセッションの側です。
なぜローカルのコード実行VMがEDRから見えないのか
ローカルセッションは2つの実行環境に分かれます。エージェントループ(会話処理・接続済みフォルダーへの読み書き・Web取得・ローカルプラグインMCPサーバー)はデバイス上でネイティブに動き、権限システムがアプリケーション層で制御します。一方、シェルコマンドとClaudeが書いたコードの実行は、専用のLinux VM内で行われます。このVMはホストOSから、プラットフォームのハイパーバイザー(macOSではApple Virtualization.framework、WindowsではHyper-V)によって隔離されています。
EDR製品の多くは、ホストOSのカーネルやプロセス階層にフックして活動を監視する仕組みです。VMはホストとは別のカーネル・別のプロセス空間を持つゲスト環境なので、ホスト側にフックしたEDRエージェントからはVM内部のプロセス・ファイルアクセス・ネットワーク通信が見えません。VM自身が独自のネットワーク送信フィルタリング・システムコール制限・セッションごとのユーザー分離を持っている点は、Coworkの実行を安全にする仕組みであると同時に、ホスト側の監視ツールから見えなくする仕組みでもあります。
クラウドセッションが同様にEDRの対象外になる理由
ローカルVMとは別の理由で、クラウドセッションもEDRの死角になります。クラウドセッションは、エージェントループもコード実行も丸ごとAnthropic管理のインフラ上で動く、独立した一時サンドボックスの中で実行されます。セッションはユーザーの組織のネットワークの外、つまりエンドポイント自体の外側で完結します。EDRエージェントはユーザーのデバイスにインストールされるものなので、そもそも観測対象になる活動がデバイス上に存在しません。
クラウドセッションがローカルのファイルやブラウザに触れる必要があるときだけ、Claude Desktopアプリ経由の接続を通します。この経路はデスクトップアプリの権限システムを通りますが、それでもEDRから見た「エンドポイント上の活動」としては現れません。Coworkがどうデータを取得しているかの全体像は、Coworkのデータ取得の仕組みで扱っている構造と地続きです。
EDRが見えなくても残っている制御は何か
EDRが効かないからといって、Coworkのクラウドセッションが無防備なわけではありません。エンドポイント監視の代わりに、ネットワーク層とデータ層で別の制御がかかっています。
- 既定でネットワークにアクセスできない。クラウドセッションのサンドボックスは、プライベートアドレス・内部アドレス・リンクローカルアドレス・クラウドメタデータアドレスに到達できず、Anthropic内部システムにも届きません。ユーザーのネットワークへの踏み台には使えない設計です。
- 既存のネットワークアクセスポリシーに従う。クラウドセッションは、ローカルのCoworkやチャットを管理しているのと同じネットワークアクセス設定を使います。Enterprise組織では既定で「ネットワークアクセス無し」になります。
- 送信経路はサンドボックスの外で強制される。サンドボックスから出るすべての通信は、サンドボックス自身が再設定もバイパスもできない必須プロキシを通過し、許可リストに載った宛先にしか届きません。
- 短命な認証情報しか持たない。サンドボックスが保持するのはセッション単位のトークンだけで、数時間で失効します。Connectorの認可トークンはサンドボックスに入らず、Connector呼び出しはサーバー側で行われます。
- データ層でテナントが分離されている。保存される全レコードは組織・アカウントに紐づけて分離されます。
つまり、EDRが担ってきた「ホスト上で何が起きたか」の可視性は失われる一方、「どこと通信できるか」「どんな権限を持ち続けるか」は別の仕組みで絞られています。エンドポイント監視を前提にした統制モデルを、ネットワーク境界とトークン寿命を前提にした統制モデルに置き換える必要がある、というのが実務上の含意です。
セキュリティチームが導入前に確認しておきたいこと
コンプライアンス体制がエンドポイントの可視性を前提にしているなら、Coworkを展開する前に次の点を確認しておきましょう。
- 自社のコンプライアンス要件が「エンドポイント上でのログ取得」を証跡として明示的に求めているか
- 求めている場合、EDR以外の手段でCoworkの活動を同等以上の粒度で記録できるか
- 記録した証跡を既存のSIEM・監査プロセスに組み込めるか
EDRが埋めていた可視性の穴は、EDRの延長では埋まりません。Cowork側が提供する別の経路に切り替える必要があります。
EDRの代わりに使える可視化手段
Coworkの活動を可視化する経路は、EDRとは別に2つあります。OpenTelemetry(OTel)とCompliance APIです。OTelはTeam・Enterpriseプランで使え、クラウドセッションの監視にはClaude Desktopバージョン1.22209.3以降、ローカルセッションの監視には1.1.4173以降が必要になります。
| 手段 | 対象プラン | カバー範囲 | 主な用途 |
|---|---|---|---|
| OpenTelemetry | 対象プランTeam・Enterprise | カバー範囲クラウドセッション(デスクトップ・Web・モバイル)とローカルセッション | 主な用途SIEMへのリアルタイムストリーミング、インシデント調査、コスト・パフォーマンス分析 |
| Compliance API | 対象プランTeam・Enterprise | カバー範囲Claude・Claude Desktop・Claude Mobile経由のCoworkとClaude Code | 主な用途個人に紐づく監査証跡としての事後照会 |
OpenTelemetryを設定すると、次の活動が監視対象になります。
- ユーザープロンプトの全文
- MCPを含むツール呼び出し(サーバー名・ツール名・パラメーター・成否・実行時間)
- ファイルアクセス経路
- 呼び出したスキルとプラグイン
- 人間による承認可否
- API単位のモデル・トークン数・コスト・エラー
これらは指定したOTelコレクター(Splunk、Cribl、Elasticsearch、Datadogなど)にストリーミングされます。すべてのイベントにはprompt.idが付き、1つのプロンプトに対してClaudeが行ったことを後から再構成できます。設定はOrganization settings > Coworkの画面でOTLPエンドポイント・プロトコル(HTTP/JSONまたはHTTP/protobuf)・認証ヘッダーを入力するだけで、保存直後からイベントが流れ始めます。認証ヘッダーはAnthropicのサーバー上で暗号化保存されます。
Compliance APIは、Claude・Claude Desktop・Claude Mobile経由のCowork活動と、CLI・Claude Desktop経由のClaude Codeを、通常のClaudeチャットと同じ監査証跡にまとめます。OTelとCompliance APIは併用でき、既にOTelを使っている組織がCompliance APIも並行運用するのは一般的な構成です。Coworkの監査ログと権限管理も、この2つと合わせて確認しておきたいところです。
OTelを有効にする前に、プロンプト本文がデフォルトで含まれる点、ファイルパスやコマンド引数などのツールパラメーターに機微な値が入り得る点、ユーザーのメールアドレスがイベント属性に含まれる点は把握しておきましょう。ログ内容の取り扱いにポリシーがあるなら、コレクター側でのフィルタリングやマスキングを組み込んでから接続します。
見落としやすいのは、OTelは管理者がOTLPエンドポイントを設定するまでデータを一切送信しないという点です。EDRの穴を埋めるつもりで契約や導入計画にOTelを組み込んでいても、実際に設定を保存するまで可視性はゼロのままになります。イベントの型と属性の全リストは、Coworkの活動をOpenTelemetryで監視するで扱っています。フィルタリングルールをコレクター側で組む前に、どのイベントが実際に流れてくるかをそちらで確認しておくと手戻りが少なくなります。
まとめ
CoworkのVM分離とクラウドサンドボックス化は、実行環境を安全に隔離する設計であると同時に、既存のEDRからは中身が見えなくなる設計でもあります。ホスト側のセキュリティツールに依存してきたセキュリティチームほど、この前提を先に確認しておく必要があります。代替として使えるのはOpenTelemetryとCompliance APIで、どちらもTeam・Enterpriseプランで利用できます。コンプライアンス要件がエンドポイントの可視性を前提にしているなら、Cowork展開前にどちらかを有効化しておくのが現実的な選択肢です。