CoworkとEDR(エンドポイント検知)ツールの相性問題
CoworkのVM分離設計により、EDR(エンドポイント検知)ツールはローカルVM内もクラウドセッションも観測できません。導入前に押さえておきたい代替の可視化手段をまとめます。
CoworkのVM分離設計は、EDR(エンドポイント検知・Endpoint Detection and Response)ツールに対しても分離として働きます。ローカルのコード実行VMも、クラウド上のセッションも、EDRからは中身が見えません。これはバグではなく設計上の帰結です。コンプライアンス上の可視性を求める組織は、展開前にこの前提を織り込む必要があります。
EDRが見えない範囲と、見えるかもしれない範囲
アーキテクチャ概要のFAQには「EDRツールはVMの内側を検査できるか」という問いがあり、答えは「できない」です。VMはホスト側のセキュリティツールから設計上分離されており、クラウドセッションはエンドポイントの外で完結するため、そちらもEDRの観測外とされています。
ただし、Coworkの実行環境は3つに分かれます。FAQが否定しているのは、そのうち2つです。
Coworkの3つの実行環境とEDR
ローカルのエージェントループ
会話処理、接続済みフォルダーの読み書き、Web取得、ローカルプラグインのMCPサーバーが動きます。制御するのはアプリケーション層の権限システムです。FAQはこの部分のEDR可否に触れていません。
ローカルのコード実行VM
シェルコマンドとClaudeが書いたコードの実行場所です。FAQはEDRから見えないと明記しています。
クラウドセッション
エージェントループもコード実行も、Anthropic管理の一時サンドボックスで動きます。FAQはEDRから見えないと明記しています。
デバイス上で動くエージェントループをEDRがどこまで拾うかは、導入しているEDR製品ごとの検証事項です。「Coworkは丸ごと見えない」と決めつけると、ホスト側に残る痕跡を見落とします。逆に「VMの外は見える」前提で証跡設計を組むのも、検証前には置けない仮定です。
「VM」はコード実行専用のLinux VMを指します。画面操作を行うComputer Useとは別物で、サンドボックスの有無を同じ尺度で語れません。クラウドかローカルかを見分ける方法はクラウド実行かローカル実行かの見分け方にまとめています。
ローカルのコード実行VMがホストから見えない仕組み
VMは、ホストOSからプラットフォームのハイパーバイザー(macOSではApple Virtualization.framework、WindowsではHyper-V)によって隔離されています。VMの中で起きるプロセス生成・ファイルアクセス・通信は、ゲストの内側の出来事になります。
VM自身も、独自のネットワーク送信フィルタリング、システムコール制限、セッションごとのユーザー分離を持ちます。Coworkの実行を安全にする仕組みが、そのままホスト側の監視ツールから見えにくくする仕組みでもあります。VMが起動できない端末では、ファイル操作とWeb取得は動き続け、シェルコマンドとコード実行だけが「workspace unavailable」を返します。
クラウドセッションがEDRの対象外になる理由
クラウドセッションは、Anthropic管理のインフラ上の一時サンドボックスで動きます。セッションごとにサンドボックスが作られ、終了時に破棄されます。ユーザーの組織のネットワークの外で完結するので、EDRエージェントを入れたデバイス上に観測対象の活動がありません。
例外はデバイスに触れる場面です。ローカルファイルやブラウザが必要になると、リクエストはAnthropicが仲介する接続を通じてClaude Desktopアプリに渡ります。触れるのは、メンバーが接続したフォルダーだけです。ローカルのツール呼び出しは、実行前にメンバーの権限と照合されます。デスクトップアプリがオフラインなら、クラウドセッションはデバイスに届きません。ローカルのMCPサーバーも、クラウドセッションでは動きません。
デバイス上でファイルを開く操作は発生しますが、エージェントの処理自体はAnthropicのサーバーで行われ、端末内に留まりません。Coworkがデータをどう取りに行くかは、Coworkのデータ取得の仕組みで扱っている構造と地続きです。
EDRの代わりにかかっている制御
エンドポイント監視が効かない代わりに、ネットワーク層とデータ層で別の制御がかかっています。
クラウドセッションの5つの制御
既定でネットワークに届かない
プライベート・内部・リンクローカル・クラウドメタデータの各アドレスと、Anthropic内部システムには到達できません。ユーザーのネットワークへの踏み台にはなりません。
既存のネットワークポリシーに従う
ローカルのCoworkやチャットと同じ設定を使います。Enterprise組織の既定は「ネットワークアクセス無し」です。
送信経路はサンドボックスの外で強制
出ていく通信はすべて必須プロキシを通り、許可リストの宛先にしか届きません。サンドボックスからは再設定もバイパスもできません。
認証情報は短命
保持するのは数時間で失効するセッション単位のトークンだけです。Connectorの認可トークンはサンドボックスに入らず、呼び出しはサーバー側で行われます。
データ層でテナントを分離
保存される全レコードは組織・アカウントに紐づけて分離されます。
「ホスト上で何が起きたか」の可視性が失われる一方、「どこと通信できるか」「どんな権限を持ち続けるか」は別の仕組みで絞られています。エンドポイント監視を前提にした統制を、ネットワーク境界とトークン寿命を前提にした統制へ置き換える、というのが実務上の含意です。
組織設定には、クラウドセッションごとの調整項目もあります。クラウドセッションだけを組織単位でオフにし、ローカルのデスクトップ版Coworkは残せます。永続的な「常に許可」をオフにして、権限制御されたツール呼び出しごとに承認を求める設定もあります。承認プロンプトなしでセッションを走らせてよいかどうかも、管理側で決められます。信頼済みデバイスの登録と直近のサインインを要求する設定は、組織内のすべてのクラウドセッションに適用されます。
端末側に残る調整手段はMDMキーの2つ
エンドポイント管理を軸にしてきたチームにとって、端末側の操作点は次の2つです。どちらもMDMで配るデバイス単位の設定で、組織設定画面からは変えられません。
isLocalDevMcpEnabledをfalseにすると、プラグイン同梱とローカル設定のMCPサーバーが無効になりますisDesktopExtensionEnabledをfalseにすると、MCPBとDXTの拡張サーバーが動かなくなります
これらはClaude Desktopアプリを対象にするため、ローカルセッションにも、クラウドセッションがアプリ経由で触れる範囲にも効きます。ローカルMCPを無効にした端末では、クラウドセッションが使えるのはフォルダー限定のデスクトップのファイルツールだけになります。Cowork自体を使えるかどうかは、組織設定の「Enable for your organization」が決め、MDMキーはCoworkが有効なときだけ意味を持ちます。
導入前の判断: 要件の読み方で打ち手が変わる
エンドポイント上のログが要件に入っているかで、取るべき道は変わります。
要件が「端末でプロセスとファイル操作を記録する」という手段の指定なら、VMの内側とクラウドセッションはその手段では満たせません。要件の文言を「誰が・いつ・何を指示し・どのツールが動いたか」という行為の記録として読み替えられるかが分かれ目です。読み替えられるなら、後述のOpenTelemetryとCompliance APIが受け皿になります。
手段の指定が動かせない場合は、端末側で残る調整手段(MDMキーと、ローカルセッションの利用可否)でCoworkの使える範囲を絞り、範囲外の業務には使わせない運用になります。
記録した証跡を既存のSIEMや監査プロセスへ流せるかは、コレクター側の設計の問題です。EDRが埋めていた穴はEDRの延長では埋まらず、Cowork側が提供する別の経路へ切り替える作業になります。
OpenTelemetryとCompliance APIの使い分け
Coworkの活動を外から見る経路は、EDRとは別に2つあります。対象プランと用途が違うので、先に並べます。
2つの可視化経路
OpenTelemetry
クラウドセッション(デスクトップ・Web・モバイル)とローカルセッションが対象です。SIEMへのリアルタイムのストリーミング、インシデント調査、コストとパフォーマンスの分析に向きます。
Compliance API
Claude・Claude Desktop・Claude Mobile経由のCoworkと、CLI・Claude Desktop経由のClaude Codeが対象です。個人に紐づく1本の監査証跡として使います。
Compliance APIの対象プランはEnterpriseで、Public Sector組織は除かれます。Claude Platformの顧客はClaudeのチャットが対象です。Team組織はCompliance APIを使えず、可視化の手段はOTelだけになります。対象範囲にも線があり、Claude Codeのクラウドセッション、Claude Platform経由のClaude Code、BedrockやVertex AI上のセッションは含まれません。有効化できるのはPrimary Ownerだけで、設定場所はOrganization settings > APIです。
両者は併用できます。OTelを使っている組織は、Compliance APIも並行して運用できます。前者はリアルタイムの運用監視、後者は個人に紐づく監査証跡を担います。監査ログ側の権限設計はCoworkの監査ログと権限管理で扱っています。CLIとデスクトップ経由のClaude Codeも、同じ監査証跡に入ります。
OpenTelemetryを有効にするときの手順と注意点
設定は管理画面で完結しますが、保存してからのふるまいに癖があります。
OTel設定の流れ
- 1
管理画面を開く
Organization settings > Coworkを開きます。OTelのヘルプ記事はこの表記で、Cowork監視のドキュメントページはAdmin settings > Coworkと書いています。
- 2
エンドポイントとプロトコルを入れる
OTLPエンドポイント(コレクターのURL)と、HTTP/JSONかHTTP/protobufのどちらかを選びます。
- 3
認証ヘッダーを入れる
ベアラートークンなど、コレクターが要求するOTLPヘッダーを追加します。ヘッダーはAnthropicのサーバー上で暗号化して保存されます。
- 4
保存して新しいセッションを始める
保存直後からイベントが流れ始めますが、設定はセッション開始時に読み込まれます。すでに動いているセッションには反映されません。
送信側はCowork VMの中で動き、セッションのegress規則に従います。組織がネットワーク送信を制限している場合は、コレクターのホスト名がセッションの許可リストへ自動で追加されます。Capabilitiesのネットワーク設定に自分で書き足す必要はありません。
プロンプトの中身は既定で出るのか
ここは公式ページ同士で書き方が食い違います。OTelのヘルプ記事は、プロンプトの全文が既定でイベントに含まれると書き、ポリシーによってはコレクター側でフィルタリングやマスキングをかけるよう案内しています。Cowork監視のドキュメントページは、既定ではメタデータのみで、プロンプト本文・モデル応答・ツール詳細は otlpContentCapture で有効にしたときだけ含まれると書いています。
有効にするキーも分かれています。userPrompts はプロンプト本文、assistantResponses はモデル応答、toolDetails はツール入力です。モデル応答のキャプチャにはClaude Desktop 1.17377以降が必要で、プロンプト本文を取る設定ならモデル応答も一緒に取れます。接続した直後のイベントで、assistant_response の response が <REDACTED> か、prompt や tool_input が含まれるかを見れば、自組織の実際の設定が分かります。どちらの前提で設計するにせよ、コレクター側のマスキングは入れておく価値があります。
ユーザーのメールアドレスは、第一者のデプロイでは常にイベント属性に入ります。また、データは管理者がOTLPエンドポイントを設定するまで一切送信されません。EDRの穴を埋めるつもりで導入計画にOTelを書いていても、設定を保存するまで可視性はゼロのままです。
どんなイベントが流れてくるか
ドキュメントページが挙げるイベントは6種類です。
| イベント名 | 記録されるタイミング | 主な属性 |
|---|---|---|
user_prompt | 記録されるタイミングプロンプト送信時 | 主な属性prompt_length、prompt |
assistant_response | 記録されるタイミングテキスト出力を含む応答の完了時 | 主な属性model、response_length、response |
tool_result | 記録されるタイミングツールの実行完了時 | 主な属性tool_name、success、duration_ms、decision_source |
tool_decision | 記録されるタイミングツールの権限判断時 | 主な属性tool_name、decision、source |
api_request | 記録されるタイミングClaudeへのリクエスト時 | 主な属性model、cost_usd、各種トークン数 |
api_error | 記録されるタイミングリクエスト失敗時 | 主な属性status_code、attempt |
すべてのイベントに prompt.id が付き、1つのプロンプトに対してClaudeが行ったことを後から再構成できます。共通属性には session.id と user.email が入ります。ホスト側で選んだ作業ディレクトリは workspace.host_paths で分かります。リソース属性には process.owner(OSのログイン名)と os.type があります。端末単位の絞り込みや、どのユーザーがどのフォルダーを選んだかの追跡は、この辺りが手がかりになります。
承認の経緯は decision_source で読めます。config、hook、user_permanent、user_temporary、user_abort、user_reject の6値です。「永続的に許可されたから実行された」のか「その場でユーザーが承認した」のかを区別でき、監査では承認の質を見る材料になります。
読むときの限界もあります。tool_input は512文字を超える個々の文字列が切り詰められ、全体も約4,000文字までです。長いコマンドや大きな引数は、全文が残るとは限りません。assistant_response は思考内容を含まず、60KBで切り詰められ、キャプチャを切っているときの値は <REDACTED> という文字列になります。api_request の cost_usd は概算値で、正式な請求額は請求ダッシュボードで見ます。
送り先の選び方
標準のOTelコレクターなら受けられます。ヘルプ記事が挙げる例は、SplunkやCribl(SIEM)、ElasticsearchやLoki(ログ集約)、ClickHouse(カラム型ストア)、HoneycombやDatadog(可観測性基盤)です。全文検索中心ならログ集約系、構造化したイベントの複雑なクエリならカラム型ストア、アラートや可視化まで一体で欲しいなら可観測性基盤が合います。コレクターの設定で、複数の宛先へ同時に流すこともできます。
バージョンの条件は、ページごとに数字が違います。ヘルプ記事はクラウドセッションの監視にClaude Desktop 1.22209.3以降、ローカルセッションの監視に1.1.4173以降を挙げています。ドキュメントページの要件は1.1.4173以降の1本です。クラウドセッションまで監視するなら、端末に配るデスクトップのバージョンは1.22209.3以降で揃えるのが安全です。
OTelの設定をここまで押さえておくと、EDRの代替としてどこまで足りるかを具体的に見積もれます。属性ごとの意味は、Coworkの活動をOpenTelemetryで監視すると並べて読むと追いやすくなります。
まとめ
EDRで見えない範囲は、VMの内側とクラウドセッションです。デバイス上のエージェントループは別扱いで、自社のEDRで実測してから証跡設計に入れるかどうかを決める必要があります。
代替の可視化は、Team以上ならOTel、Enterpriseならこれに加えてCompliance APIです。どちらを採るにしても、プロンプト本文を取るかどうかとコレクター側のマスキングを、有効化の前に決めておいてください。