CoworkのOpenTelemetry監視設定 — SIEMに何が流れるか
Team/EnterpriseのCoworkが送るOTelイベントの種類と、プロンプト本文が既定で流れるかどうかを設定の仕組みから確認します。
Team・EnterpriseプランのCoworkは、セッション内の操作をOpenTelemetry(OTel)経由で自社のSIEMや監視基盤にリアルタイムでストリーミングできます。ユーザーIDやツール呼び出し、承認判定、APIコストまで記録できますが、プロンプト本文や応答本文は既定では流れず、otlpContentCaptureという設定で明示的に有効化して初めて含まれます。設定はAdmin settings(組織設定)> Coworkの1画面で完結します。
CoworkのOpenTelemetry監視で何が分かるか
OTel監視をオンにすると、Coworkはセッション中に発生する6種類のイベントを自社のOTelコレクターへストリーミングします。ユーザーが送ったプロンプト、モデルの応答、ツール・MCP呼び出しの成否と所要時間、ファイルアクセス、人間による承認・却下の判定、APIリクエストごとのモデル・トークン数・推定コストです。すべてのイベントにはprompt.idという共通の属性が付き、1回のプロンプト送信から発生した一連の処理を後から串刺しで追跡できます。
用途は大きく3つです。セキュリティ監視とインシデント調査(誰がどのファイルに触れたか、どのツールが失敗したか)、組織横断でのツール・ファイルアクセスパターンの把握、そしてコスト・パフォーマンス分析です。既存のダッシュボードやアラートの仕組みにそのまま組み込める点が、後述するCompliance APIとの一番の違いになります。
設定手順
設定はAdmin settings > Coworkから行います。
- Admin settings > Coworkを開く
- OTLPエンドポイント(自社OTelコレクターのURL)を入力する
- OTLPプロトコルをHTTP/JSONまたはHTTP/protobufから選ぶ
- 認証が必要な場合はOTLPヘッダー(Bearerトークン等)を追加する
- 設定を保存する
設定はセッション開始時に読み込まれるため、既存の実行中セッションには反映されません。新しいセッションから有効になります。認証ヘッダーはAnthropicのサーバー上で保存時に暗号化されます。
バージョン要件には注意が必要です。クラウド上で動くCoworkセッション(デスクトップ・Web・モバイル)の監視にはClaude Desktop 1.22209.3以降、ローカルのデスクトップセッションの監視には1.1.4173以降が必要です。組織内のメンバーが古いバージョンのままだと、そのメンバーのセッションだけイベントが送られない状態になります。
イベントの種類と含まれる情報
すべてのイベントにはsession.id・organization.id・user.account_uuid・user.emailなどの標準属性が共通で付きます。イベント固有の主な属性は次の通りです。
| イベント名 | 発生タイミング | 主な属性 |
|---|---|---|
user_prompt | 発生タイミングプロンプト送信時 | 主な属性prompt_length、prompt(本文) |
assistant_response | 発生タイミングモデルが応答を生成した時 | 主な属性model、response_length、response(本文) |
tool_result | 発生タイミングツール実行完了時 | 主な属性tool_name、success、duration_ms、tool_parameters、tool_input |
tool_decision | 発生タイミングツールの許可判定時 | 主な属性decision(accept/reject)、source(config/hook/user_permanent等) |
api_request | 発生タイミングClaudeへのリクエスト時 | 主な属性model、cost_usd、input_tokens、output_tokens |
api_error | 発生タイミングリクエスト失敗時 | 主な属性status_code、error、attempt |
tool_resultイベントのtool_parametersにはMCPサーバー名・ツール名も含まれるため、どのMCP連携がどれだけ使われているかもここから追える設計です。tool_decisionのsourceには、設定ファイルによる自動許可(config)、フックによる判定(hook)、そしてユーザーが都度・恒久的に許可・却下した場合(user_temporary・user_permanent・user_reject等)まで区別が残るので、承認フローの運用実態をログから検証できます。組織の自動承認設計そのものはAIエージェントの自動承認で扱っています。
プロンプトの本文は既定で流れるのか
ここが誤解しやすいポイントです。OTel監視を有効にしただけでは、イベントに含まれるのはメタデータのみで、プロンプト本文・応答本文・ツールの詳細な引数は含まれません。これらの内容を含めるには、otlpContentCaptureという設定に対象カテゴリを配列で指定する必要があります。
| カテゴリ | 含まれる内容 |
|---|---|
userPrompts | 含まれる内容ユーザーが送ったプロンプトの本文 |
assistantResponses | 含まれる内容モデル応答の本文 |
toolDetails | 含まれる内容ツールの入力引数(検索クエリの文字列等) |
Claude Desktopのバージョンによっては、userPromptsだけを有効にしても応答本文まで自動的に含まれる挙動になっている点も覚えておく価値があります。1.17377以降では、プロンプト本文だけを応答なしで取得する設定は存在しません。取得した内容はいずれも設定した自社のOTLPエンドポイントにのみ送られ、Anthropicには送信されません。
つまり「OTel監視=プロンプトが全部SIEMに流れる」と考えて設定すると、実際には空のメタデータしか届かず原因調査で戸惑うことになります。プロンプト内容を含めた本格的な監査ログが目的なら、エンドポイント設定とotlpContentCaptureの両方をセットで確認する必要があります。逆に、社内ポリシー上プロンプト内容をSIEMに残せない組織であれば、エンドポイントだけ設定しotlpContentCaptureには触れないことで、既定のメタデータ監視に留められます。
コストと利用状況の分析にどう使うか
api_requestイベントのcost_usdをuser.account_uuidやorganization.idで集計すれば、ユーザー単位・チーム単位のコスト傾向を可視化できます。ただしイベントから算出できるコストは近似値で、正式な請求データは請求ダッシュボード側を参照する必要があります。tool_resultのduration_msとapi_requestの応答時間を追えば、どのツール・どのモデルがボトルネックになっているかのパフォーマンス分析にも使えます。
送信先はOTel準拠のコレクターであれば何でもよく、Splunk・CriblのようなSIEM、Elasticsearch・Lokiのようなログ集約基盤、ClickHouseのような列指向ストア、Honeycomb・Datadogのようなオブザーバビリティ基盤のいずれとも組み合わせられます。コレクターの設定次第で、複数の宛先へ同時に振り分けることも可能です。
Compliance APIとの使い分け
なお、Claude Code(CLI)側のOpenTelemetry設定は本記事とは別の仕組みなので、Claude CodeのOpenTelemetry監視設定を参照してください。
似た目的の仕組みにCompliance APIがあります。Compliance APIはCowork(Claude・Claude Desktop・Claude Mobile経由)とClaude Code(CLI・Claude Desktop経由)のセッションを横断し、個々のユーザーに紐づく監査証跡をAPI経由で取得する仕組みです。すでにOTelを使っている組織はCompliance APIと並行運用でき、OTelのカバー範囲にはWeb・モバイル版のCoworkも含まれます。
役割の違いは明確です。OTelは自社のパイプラインへリアルタイムでイベントを流し込み、既存のアラート・ダッシュボードに載せるための仕組みです。Compliance APIは事後に監査証跡をAPIで引き出す仕組みで、セッション単位の網羅性を重視します。両方を使う組織では、日常的な異常検知はOTel側のアラートで拾い、インシデント発生後の正式な証跡確認はCompliance API側で行う、という役割分担が現実的です。
設定時に見落としやすい注意点
user.emailは既定で全イベントに付く: 自社アカウントで使う通常のCoworkでは、ユーザーのメールアドレスが標準属性として常に含まれます。SIEM側でのアクセス制御やマスキングが必要なら、コレクター側でフィルタ・削除する設計にしておきますtool_parameters・tool_inputに機微な値が混じりうる: ファイルパスやコマンド引数がそのままJSON文字列として記録されるため、保持期間とアクセス権限は事前に決めておきます- イベントが送られるのは管理者がエンドポイントを設定した場合のみ: 既定では何も送信されないので、監視を始めたつもりで未設定のままになっていないか確認します
- 既存セッションには即時反映されない: 設定変更後、対象のメンバーに新しいセッションを開始してもらう必要があります
- サードパーティデプロイでは属性名が変わる: Amazon Bedrock・Google Cloud's Agent Platform・Microsoft FoundryのようなサードパーティのデプロイメントでCoworkを使っている組織では、
user.emailのようなAnthropicアカウント由来の属性がそもそも存在せず、代わりにenduser.idというリソース属性でユーザーを識別します。自社のSIEMクエリを組む前に、どちらのデプロイ形態で動いているかを確認しておくと属性名の不一致で悩まずに済みます
トレース出力とプラグイン利用状況の追跡
より細かい相関分析が必要なら、ベータ機能のotlpTracesEnabledでトレース出力も有効にできます。有効化するとイベントにtrace_id・span_idが付与され、オブザーバビリティ基盤側のスパンと突き合わせてプロンプト単位の処理全体を時系列で追跡できます。
配布したプラグイン・スキルがどれだけ呼ばれているかもtool_resultイベントから追跡できます。組織のプラグイン配布方針(Coworkプラグイン管理)や、独自マーケットプレイスの運用(Coworkプライベートマーケットプレイス)と合わせて監視設計を組むと、配布後の利用実態まで一貫して追えます。
まとめ
CoworkのOpenTelemetry監視は、Admin settings > Coworkでエンドポイント・プロトコル・ヘッダーを設定するだけで始められますが、既定で流れるのはメタデータだけで、プロンプトや応答の本文はotlpContentCaptureを明示的に設定して初めて含まれます。この2段構えを理解しておけば、監視の設計段階で「何を記録し、何を記録しないか」を意図通りにコントロールできます。Coworkのデータ取り扱い全体の設計思想はCoworkセキュリティで扱っています。