Cowork監査ログと権限管理 — 法人導入前に見える範囲

Coworkの導入を情シス・セキュリティ部門が検討するとき、最初に聞かれるのは「誰が何をしたか、あとから追えるか」です。答えは1つではありません。組織の管理操作を記録する監査ログと、Claudeがタスク中に何をしたかを流すOpenTelemetry、そしてセッション内容を取得できるCompliance API。この3つは別の仕組みで、Team / Enterpriseプランでどこまで使えるかも違います。

背景 — なぜCoworkの可視性は1つの仕組みで済まないか

一般的な監査ログは「誰がいつログインしたか」「誰をメンバーに追加したか」のような組織管理イベントを記録します。監査ログは認証・組織管理・プロジェクト・データの4カテゴリのイベントを記録します。ロール設計とあわせた実装手順はClaude CoworkのRBAC運用にまとめてあります。

しかしCoworkはエージェントです。Claudeがどのファイルを開いたか、どのツールを呼んだか、どの操作をユーザーが承認したかは、組織管理イベントとは別の軸の記録です。OpenTelemetryはこの軸を埋めるための仕組みであり、監査ログの代替にはなりません。両方が要る、というのが実態です。

Coworkを可視化する2つの仕組み

OpenTelemetry(OTel)は、Coworkのイベントを自社のSIEMや可観測性ツールへリアルタイムでストリーミングする仕組みです。Team / Enterpriseプランで使え、クラウド上で動くセッション(デスクトップ・Web・モバイル)とローカルのデスクトップセッションの両方が対象です。管理者がOrganization settingsでOTLPエンドポイントを設定しない限り、データは一切流れません。

Compliance APIは、Cowork(Claude・Claude Desktop・Claude Mobile経由)とClaude Code(CLIとClaude Desktop経由)、それに通常のチャットをまとめて1つの監査証跡として扱うAPIです。すべてのセッションが個々のユーザーに帰属づけられる形で記録されます。ただしCompliance APIはEnterpriseプランの機能で、Teamプランには含まれません。

この非対称が実務上重要です。Teamプランの組織は、Cowork向けの可視化手段としてOpenTelemetryしか持ちません。Compliance APIも、組織管理イベントを記録する監査ログも、Enterpriseへ移行しない限り使えません。

OpenTelemetryで見える6種類のイベント

OTelコレクタに接続すると、Coworkは次の6カテゴリのイベントを流します。

1件のユーザープロンプトに紐づく全イベントには共通のprompt.idが付き、1つの入力に対してClaudeが何をしたかを後から再構成できます。送信先はSplunkやCribl、Elasticsearch、ClickHouse、Honeycomb、Datadogなど標準的なOTelコレクタに対応するものであれば任意です。

見える範囲には注意が要る

OTelを有効にする前に押さえておく点が4つあります。ユーザープロンプトの本文は既定で含まれるため、プロンプトの内容をSIEMに残したくない組織はコレクタ側でフィルタや削除を設定します。ツールパラメータにはファイルパスやコマンド引数など機密性のある値が含まれることがあり、tool_parametersフィールドとして出力されます。ユーザーのメールアドレスもイベント属性に含まれます。そして最も基本的な点として、イベントは管理者がOTLPエンドポイントを設定したときだけ流れ、既定では何も送信されません。

権限管理は1段ではなく、レイヤーが重なる

Coworkの権限設定はOrganization settingsに集約されていますが、実際には複数の層が重なっています。組織全体の有効・無効を切り替える「Enable for your organization」、クラウドでのセッション実行を切り替える「Run Cowork in the cloud」、自動承認モードを許可する設定、コネクタツールの「常に許可」を許可する設定は、それぞれ独立したトグルです。

Enterpriseプランでは、これに加えてカスタムロールとグループによる粒度の細かい制御が使えます。コネクタツールの「常に許可」設定がオフの組織では、カスタムロールで権限を付与していてもこの設定が優先されます。最も制限の強い層が勝つという設計です。

クラウドセッション固有の管理設定としては、権限が必要なツール呼び出しのたびに承認を求めさせる(永続的な「常に許可」を無効化する)設定、信頼済みデバイスの登録と直近のサインインを必須にする設定があります。デバイス側ではMDM経由で、ローカルMCPサーバーを止めるisLocalDevMcpEnabledと、デスクトップ拡張を止めるisDesktopExtensionEnabledの2つのキーが使えます。

TeamとEnterpriseの可視性・権限の違い

OpenTelemetryが監査ログの代替にならない理由

OTelが監査ログの代替にならないのは、両者が違う対象を記録しているからです。監査ログは組織そのものの変化(誰が招待され、誰がSSOでログインし、プロジェクトの公開範囲がいつ変わったか)を記録します。OTelはエージェントの振る舞い(何を読み、何を呼び、何を承認したか)を記録します。前者が欠けている組織は、Coworkの実行を見ていても、誰がその組織にアクセスできる状態だったかを追跡できません。後者が欠けている組織は、メンバーの入退を把握していても、Claudeが実際に何をしたかを再現できません。

Teamプランの組織がOTelだけで運用する場合、この片方の軸が丸ごと空白になります。監査ログとCompliance APIが要る業務(規制対応、インシデント後の説明責任)を見込むなら、この空白はEnterpriseへの移行を検討する材料になります。導入前にどちらの軸が自社に必要かを整理しておくと、あとから慌てずに済みます。

OpenTelemetryを設定する手順

Organization settingsのCowork項目からOTLPエンドポイント(自社のOpenTelemetryコレクタのURL)を入力し、コレクタが使うプロトコル(HTTP/JSONまたはHTTP/protobuf)を選び、認証に必要なOTLPヘッダー(ベアラートークンなど)を追加して保存します。設定を保存した時点からイベントが流れ始めます。認証用のヘッダーはAnthropicのサーバー上で暗号化して保存されます。

クラウド上のセッションを監視するにはClaude Desktopバージョン1.22209.3以降、ローカルのデスクトップセッションを監視するにはバージョン1.1.4173以降が必要です。組織のデスクトップアプリが古いままだと、設定自体は完了していてもイベントが流れてきません。

よくある質問

ローカルセッションの会話履歴は監査ログやCompliance APIに含まれるか

ローカルセッションの会話履歴はユーザーの端末に保存され、Anthropicの標準的なデータ保持ポリシーの対象外です。管理者が一元的に管理・エクスポートすることはできません。Enterprise管理者はCompliance API経由でこのセッション内容を取得できますが、ローカルセッションを削除するためのエンドポイントはまだ提供されていません。

ネットワークアクセスの設定を変えたら、進行中のタスクにも反映されるか

反映されません。ネットワークアクセスの設定は新しいCoworkセッションが作られた時点で適用される仕組みで、会話が進行中の間にアクセスモードや許可リストを変えても、その会話には反映されません。設定を変えたあとは新しい会話を始める必要があります。

Coworkを組織全体で一時的に止めることはできるか

TeamでもEnterpriseでも、Organization settingsの「Enable for your organization」トグルをオフにすれば、Cowork自体を組織全体で無効化できます。Enterpriseではこれとは別に、グループ単位でCoworkやクラウド実行を個別に有効化することもできます。

Compliance APIとOpenTelemetryは同時に使えるか

使えます。Compliance APIを使っている組織がOpenTelemetryを並行して動かすことも想定されており、OTelの対象範囲はWeb・モバイル経由のCoworkも含みます。片方だけで運用を組む必要はありません。

まとめ

Coworkの可視性は、組織管理イベントを記録する監査ログ(Enterprise限定)、エージェントの振る舞いをリアルタイムで流すOpenTelemetry(Team / Enterprise)、セッション内容を横断的に取得できるCompliance API(Enterprise限定)の3層に分かれます。Teamプランのまま法人導入を進めると、この3層のうちOTelしか使えない点は、事前に把握しておきたい制約です。Coworkの全体像はClaude Cowork(クロードコワーク)とは、デスクトップ・Web・モバイルでの使い分けはCoworkのウェブとモバイル対応を参照してください。