CoworkのOpenTelemetry監視設定 — SIEMに何が流れるか
Team/EnterpriseのCoworkが送るOTelイベントと、プロンプト本文が既定で流れるかを、公式ページ同士の食い違いも含めて確認します。
Team・EnterpriseプランのCoworkは、セッション内の操作をOpenTelemetry(OTel)経由で自社のSIEMや監視基盤へ送れます。ユーザーID、ツール呼び出し、承認判定、APIコストまでが対象です。悩ましいのはプロンプト本文の扱いで、公式の2ページが逆のことを書いています。「既定はメタデータのみ」という記述と「既定で含まれる」という記述が並存しているため、本記事はその食い違いの読み方を軸に、設定とイベントの中身を確認します。
「プロンプトは既定で流れる」のか「流れない」のか
結論から言うと、どちらの記述も存在し、どちらが実際の挙動かを示す記述は、確認した公式のページにはありません。判断材料は次のとおりです。
2ページの書き分け
Coworkの監視リファレンス
イベントは既定でメタデータだけを含み、プロンプト本文・応答本文・ツールの詳細はotlpContentCaptureで有効にしたときだけ含まれる、と書かれています。assistant_responseのresponse属性は、キャプチャが無効のとき<REDACTED>という文字列になります。
サポート記事
「User prompt content is included in events by default」と明記しています。SIEMに本文を残せない方針の組織には、コレクター側でフィルタや削除を設定してから下流へ回すよう案内しています。
otlpContentCaptureについて、サードパーティ向けの設定リファレンスには、Claude Desktop 1.15962.0で追加されたキーで既定値は空(内容をすべて伏せる)と記載されています。
もう1つ材料があります。サードパーティ向けのテレメトリーのページは、既定でメタデータだけを含み、メッセージ本文は含まないと書いています。ただしこれは第三者デプロイの話として書かれており、第一者で既定が同じかどうかは、このページからは分かりません。
読者側の切り分けは次のとおりです。
- プロンプト内容をSIEMに残せない組織: 本文が流れる前提でコレクターにフィルタを入れておけば、どちらの記述が正しくても本文はSIEMに残りません
- 本文を含む監査ログが目的の組織: 監視リファレンスの記述どおり、イベントに
promptが入っているかを最初のセッションで実際に確かめます - 確かめる手段: 検証用のセッションを1つ流し、コレクター側のログで
user_promptイベントのprompt属性を見ます
Anthropicへの送信については、サードパーティ版の設定リファレンスに、取得した内容は設定したOTLPエンドポイントにだけ送られ、Anthropicには届かないと記載されています。第一者のページには同じ記述が見当たりません。
設定手順とエンドポイントの仕組み
第一者(Anthropic直接)のデプロイでは、管理者が組織の設定画面でエンドポイントを登録します。画面名は監視リファレンスが「Admin settings > Cowork」、サポート記事が「Organization settings > Cowork」で、表記が食い違っています。
OTel監視を始める5ステップ
- 1
Coworkの管理設定を開く
Team・Enterpriseの管理者として、Coworkの管理設定へ進みます。
- 2
エンドポイントを入れる
OTLP endpointに自社コレクターのURLを入れます。例は
http://collector.example.com:4318です。 - 3
プロトコルを選ぶ
OTLP protocolは
http/jsonかhttp/protobufから選びます。 - 4
認証ヘッダーを足す
OTLP headersに
Authorization=Bearer your-tokenの形式で入れます。ヘッダーはAnthropicのサーバー上で保存時に暗号化されます。 - 5
保存して新しいセッションを始める
設定はセッション開始時に読み込まれるため、実行中のセッションには反映されません。
サポート記事には「イベントはすぐに流れ始める」とありますが、監視リファレンスは既存セッションが新設定を拾わないと明記しています。新しいセッションを始めたメンバーから流れる、と読むのが両方と矛盾しません。
バージョン要件はサポート記事のほうが細かく、クラウド上のCoworkセッション(デスクトップ・Web・モバイル)にはClaude Desktop 1.22209.3以降、ローカルのデスクトップセッションには1.1.4173以降が必要です。監視リファレンスは1.1.4173以降とだけ書いています。要件を下回るバージョンでの挙動は、どちらのページにも記載がありません。
6種類のイベントと持ち出される属性
すべてのイベントにはsession.id・organization.id・user.account_uuid・user.emailなどの標準属性が付き、UUID v4のprompt.idが1回のプロンプト送信から生じた処理を束ねます。特定のprompt.idで絞れば、そのプロンプトが呼んだAPIとツールをまとめて追えます。
| イベント名 | 発生タイミング | 主な属性 |
|---|---|---|
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、source |
api_request | 発生タイミングClaudeへのリクエスト時 | 主な属性model、cost_usd、input_tokens、output_tokens |
api_error | 発生タイミングリクエスト失敗時 | 主な属性status_code、error、attempt |
表に載せなかった属性にも使い道があります。tool_resultにはdecision_typeとdecision_sourceが付くため、tool_decisionを別に結合しなくても、ツールごとの成否と承認経路を1行で見られます。tool_inputは個々の文字列が512文字を超えると切り詰められ、全体でも約4K文字が上限です。assistant_responseは1.17377以降のClaude Desktopで出力され、responseは60KBで切られ、思考内容(thinking)は含まれません。
tool_decisionのsourceは、設定による自動許可(config)、フック(hook)、ユーザーの恒久許可(user_permanent)、一時許可(user_temporary)、中断(user_abort)、却下(user_reject)の6値です。人が承認した操作と自動で通った操作をログから分けられるので、承認フローの運用実態を検証できます。組織の自動承認設計そのものはAIエージェントの自動承認で扱っています。
MCPの利用状況はtool_parametersのmcp_server_nameとmcp_tool_nameから追えます。標準属性のworkspace.host_pathsにはデスクトップアプリで選ばれた作業フォルダーが入るので、どのフォルダーを開いたセッションかも分かります。
本文・引数はどこまで出せるか(otlpContentCapture)
本文系の情報はotlpContentCaptureにカテゴリを並べて有効にします。監視リファレンスが挙げるのは3カテゴリですが、設定リファレンスにはさらに2つあります。
otlpContentCaptureのカテゴリ
userPrompts
ユーザーのプロンプト本文と、会話のタイトル。
assistantResponses
モデルの応答本文。
toolDetails
ツールの入力引数(Web検索のクエリ文字列など)。
toolContent
ツールの出力内容(取得したページのテキストやコマンドの標準出力など)。
rawApiBodies
推論APIのリクエストとレスポンスの本文全体。1つの本文は既定で60KBで切られ、拡張思考の内容は常に伏せられます。
挙動には落とし穴があります。1.17377以降のClaude Desktopでは、userPromptsを有効にするとassistantResponsesを並べなくても応答本文が付いてきます。プロンプトだけを応答なしで取る設定は存在しません。会話タイトルは、デスクトップアプリ自身のストリーム(claude-desktop)にdesktop_session_title_setイベントとして流れ、otlpDesktopLogLevelがinfoかdebugのときだけ出ます(1.44121.1以降)。
この設定の置き場所には注意が要ります。otlpContentCaptureはサードパーティ版Claude Desktopの設定リファレンスに載るキーで、MDM(端末管理)とブートストラップのサーバーから配る形式です。1.15962.0で追加され、既定は空です。第一者のCoworkの管理画面で説明されている項目は、エンドポイント・プロトコル・ヘッダーの3つで、このキーは含まれていません。
サードパーティ環境で変わること
Amazon Bedrock・Google Cloud's Agent Platform・Microsoft Foundryなどで動かすClaude Desktopは、同じcoworkストリームを出しつつ属性の構成が変わります。
organization.id・user.account_uuid・user.emailはAnthropicアカウント由来のため出ません- 代わりに
enduser.idというリソース属性でユーザーを識別します。対話型のサインインなら通常はメールアドレスで、静的キーなどIDのクレームを持たない認証ではOSのログイン名です enduser.idはendUserAttributionをfalseにすると、アプリの表示とエクスポートの両方から消えます- OSのログイン名を表す
process.ownerは、標準のプロセス属性なので全デプロイで常に付き、endUserAttributionでは消せません
エクスポートはログとメトリクスで、service.nameはcowork・claude-code-desktop・claude-desktopの3系統に分かれます。プロトコルはこの環境でgrpcも選べますが、CoworkとChatはWindowsではgrpcを指定してもhttp/protobufで送ります。他のプラットフォームでも、Claude CodeエンジンにHTTPプロキシが設定されていれば同じです。デスクトップアプリ自身のストリーム(claude-desktop)は、常にhttp/jsonで出ます。エンドポイントは変わらないため、4317番のgRPC受信口を指していると届きません。1つのコレクターで3系統とも受けるなら、http/protobufを選んで4318番のHTTP受信口を指す構成になります。
到達できない場合の挙動も見落としやすい点です。コレクターが拒否したり届かなかったりしても、アプリは動き続け、エラーも出さず、該当バッチを捨てます。データが来ないときは、コレクター側のリクエストログで受信を確かめます。
コスト分析と送信先
api_requestのcost_usdをuser.account_uuidやorganization.idで集計すれば、ユーザーやチーム単位の傾向が出せます。イベント由来のコストは近似値で、正式な請求は請求ダッシュボードで見る前提です。tool_resultのduration_msとapi_requestのduration_msを並べると、遅延の主因がツールかモデルかを切り分けられます。api_requestにはキャッシュ読み取り(cache_read_tokens)と作成(cache_creation_tokens)のトークン数、speed(fastかnormal)も付きます。
送信先はOTel準拠のコレクターなら何でもよく、SplunkやCriblのようなSIEM、ElasticsearchやLokiのような集約基盤、ClickHouse、HoneycombやDatadogに対応します。コレクターの設定次第で複数の宛先への同時送信もできます。SIEMが独自の取り込み形式しか受けない場合は、OTLPを受けて転送するコレクターを間に置くのが公式の案内です。
設定時に見落としやすい注意点
user.emailは第一者のデプロイでは常に付く: 標準属性なので、隠したいならコレクター側でフィルタか削除をしますtool_parameters・tool_inputに機微な値が混じる: ファイルパスやコマンド引数が記録されます。tool_inputはファイルパス・URL・検索パターンなどの引数で、toolDetailsを有効にしたときだけ含まれます。保持期間とアクセス権限を先に決めておきます- 何も設定しなければ何も送られない: イベントが出るのは管理者がエンドポイントを設定した場合だけです
cost_usdは近似値: 請求額との突き合わせに使わないようにします
Compliance APIとの使い分け
似た目的の仕組みにCompliance APIがあります。Cowork(Claude・Claude Desktop・Claude Mobile経由)とClaude Code(CLI・Claude Desktop経由)のセッションを横断し、個々のユーザーに紐づく監査証跡をAPIで取れます。OTelと並行運用でき、OTelのカバー範囲にはWeb・モバイル版のCoworkも含まれます。
OTelは自社のパイプラインへリアルタイムでイベントを流し、既存のアラートやダッシュボードに載せる用途です。日常の異常検知はOTel側、事後の証跡確認はCompliance API側と分けて使う組織が想定できますが、この分担は本記事の整理で、推奨された運用ではありません。Claude Code(CLI)側の設定は別の仕組みなので、Claude CodeのOpenTelemetry監視設定を参照してください。
トレース出力とプラグイン利用状況の追跡
より細かく追うなら、ベータ機能のotlpTracesEnabledでトレースも出せます。有効にするとイベントにtrace_idとspan_idが付き、バックエンド側のスパンと突き合わせてプロンプト単位の処理を時系列で追えます。要件はClaude Desktop 1.22209.0以降で、監視リファレンスはこの機能をサードパーティのデプロイ向けとして紹介しています。エンドポイントを設定した状態では、このキーだけがトレースの有無を決め、端末上のClaude Codeの設定(managed settingsを含む)でトレースが有効でも、未設定かfalseなら出ません(1.52386.0以降)。メトリクスにはトレースの文脈が付かないので、session.idで突き合わせます。
トレースの内容もotlpContentCaptureの対象で、カテゴリを何も有効にしなければタイミング・ツール名・所要時間・トークン数といったメタデータだけが載ります。ExcelやWordのOffice agentsのスパンはOffice agentsのOpenTelemetry設定にまとめています。
配布したスキルやプラグインの利用状況は、サポート記事が監視対象として挙げています。どのイベントの属性に出るかは、そのサポート記事に記載がありません。組織のプラグイン配布方針(Coworkプラグイン管理)や、独自マーケットプレイスの運用(Coworkプライベートマーケットプレイス)と組み合わせるなら、検証用のセッションでイベントを見て属性を確かめてからダッシュボードを作ります。
まとめ
プロンプト本文が既定で流れるかは、2通りの記述があるので、本文を残せない組織はコレクターでの削除を前提に、残したい組織は初回のセッションでprompt属性の有無を確かめる、という判断になります。Coworkのデータ取り扱い全体の設計思想はCoworkセキュリティで扱っています。