利用状況の計測

Claude Code は、メトリクスを時系列データとして、イベントをログ／イベントのプロトコルで、さらに分散トレースを（ベータで）OpenTelemetry（OTel）経由で出力できます。組織全体の使用量・コスト・ツール活動を自前の可観測性基盤で追うための仕組みです。Team・Enterprise の管理画面にある分析ダッシュボードは、このページの最後で説明します。

• 環境変数 CLAUDE_CODE_ENABLE_TELEMETRY=1 で有効にし、エクスポーターを選ぶ
• 管理者は管理設定で全ユーザーの送り先を固定できる
• メトリクス・イベント・トレース（ベータ）の 3 種類を出せる
• プロンプトやツール内容は既定で伏せられ、環境変数で個別に出す
• コストの扱いはコストを抑える、管理設定の配り方は組織への導入と管理設定を参照

クイックスタート#

環境変数で設定します。

# 1. Enable telemetry
export CLAUDE_CODE_ENABLE_TELEMETRY=1

# 2. Choose exporters (both are optional - configure only what you need)
export OTEL_METRICS_EXPORTER=otlp       # Options: otlp, prometheus, console, none
export OTEL_LOGS_EXPORTER=otlp          # Options: otlp, console, none

# 3. Configure OTLP endpoint (for OTLP exporter)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

# 4. Set authentication (if required)
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-token"

# 5. For debugging: reduce export intervals, and reset them for production use
export OTEL_METRIC_EXPORT_INTERVAL=10000  # 10 seconds (default: 60000ms)
export OTEL_LOGS_EXPORT_INTERVAL=5000     # 5 seconds (default: 5000ms)

# 6. Run Claude Code
claude

• メトリクスの確認は、バックエンドに claude_code.session.count（セッション開始時に出る）が届いたかを見る。ログだけの構成は、プロンプトを送って claude_code.user_prompt イベントを探す
• 何も届かなければ claude --debug-file <path> で起動してログを見る。設定したエクスポーターの失敗は [3P telemetry] のエラー（3P は第三者の意味）として出る。[Anthropic telemetry] で始まる行は Anthropic 自身の運用テレメトリで、設定の問題ではない（セキュリティとデータの扱いを参照）

管理者による設定#

管理設定のファイルで、全ユーザーの OpenTelemetry 設定を配れます（配布方法は組織への導入と管理設定、優先順位は設定ファイルの仕組み）。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer example-token"
  }
}

• デスクトップアプリの Code タブのセッションは、種類ごとに届く管理設定の取得元から読みます（デスクトップアプリ）。管理コンソールの「Data and privacy settings」にある「Monitoring」の OpenTelemetry フォームは Cowork のセッション専用で、ターミナルの CLI も Code タブもそこで指定したコレクターへは出力しません
• リポジトリの .claude/settings.json と .claude/settings.local.json にある OpenTelemetry のエクスポーター変数は無視されます。リポジトリ側から、テレメトリを有効にする・送り先を決める・内容を取り出す、はできません。管理設定か、開発者のシェル・~/.claude/settings.json に置きます。ただしリポジトリは OTEL_LOGS_EXPORTER のようなエクスポーター選択を none にして信号を止めることはできます（管理設定・--settings ファイル・起動環境が同じ変数を設定していない場合）
• Claude Code は、起動するサブプロセス（Bash ツール・フック・MCP サーバー・言語サーバー）に OTEL_* 環境変数を渡しません。Bash ツールで動かす OpenTelemetry 計装済みアプリが自分でテレメトリを出すなら、そのコマンドで変数を直接指定します

管理設定が OTLP の送り先を固定する仕組み#

管理設定に OTEL_EXPORTER_OTLP_* 変数を置くと、起動時に、衝突する開発者設定の変数を Claude Code が取り除き、デバッグログに警告を書きます。

詳細ベータトレースでは、ログとトレースをログ／トレースのエクスポーターではなく BETA_TRACING_ENDPOINT に出します。次のいずれかが管理設定にあると、開発者の BETA_TRACING_ENDPOINT は取り除かれます。

• 汎用またはログ・トレース用のエンドポイントや資格情報
• otelHeadersHelper
• ログまたはトレースのエクスポーター選択が none・console・空（信号をコレクターから外す値）
• CLAUDE_CODE_ENABLE_TELEMETRY をオフにしたもの

メトリクス用だけのエンドポイントや資格情報では取り除かれません。v2.1.251 より前は、管理設定がコレクターを固定していても、開発者の BETA_TRACING_ENDPOINT が詳細ベータトレースのログとトレースを別の送り先へ振っていました。

• 管理設定の中に自分で置いた信号別の変数は取り除かれないので、信号ごとに別のコレクターへ振れます（SIEM の例は後の節）。信号別の資格情報を管理設定に置くと、その信号の開発者設定のエンドポイントは取り除かれます
• 取り除くのは配信先の話で、Claude Code が何を収集するかは変わりません
• v2.1.217 より前は、全変数がキー別の優先順位に独立に従い、ユーザー設定やシェルで信号別のエンドポイントを置くと、その信号が管理設定のコレクターから外れていました
• デスクトップアプリやセルフホスト環境のランナーが OTLP のエンドポイントを環境に入れて起動した場合も、同じ形で送り先が固定され、起動側が自分で置いた変数は取り除かれません（v2.1.251 以降）

設定の詳細#

共通の設定変数#

全構成で、エクスポーター・エンドポイント・エクスポートの動作を設定する変数です。信号別のエンドポイントやプロトコル（OTEL_EXPORTER_OTLP_METRICS_ENDPOINT など）を置くと、その信号では汎用変数より優先されます。信号別のヘッダー変数は、汎用の OTEL_EXPORTER_OTLP_HEADERS と統合されます。管理設定のあるマシンで何が取り除かれるかは前の節を見てください。

http/protobuf と http/json では、各エクスポート要求に Content-Length ヘッダーを付けて送ります。v2.1.212 より前の v2.1.191 以降は chunked 転送で送っていたため、長さの宣言が必要な Azure Monitor などのエンドポイントは 411 Length Required か 400 で拒否していました。

mTLS 認証#

OTLP エクスポーターのクライアント証明書の設定は、その信号で使うプロトコル（OTEL_EXPORTER_OTLP_PROTOCOL か信号別の上書き）で決まります。メトリクス・ログ・トレースで同じ設定です。

grpc では OpenTelemetry SDK が標準の OTLP 変数を直接読むので、信号別のメトリクス変数を使う既存の設定もそのまま動きます。管理設定のあるマシンでは、起動時に開発者設定の信号別の資格情報とエンドポイントが取り除かれることがあります。

メトリクスのカーディナリティ制御#

メトリクスに含める属性を決める環境変数です。

カーディナリティが低いほど性能が良く保管費用も安いが、分析の粒度は粗くなります。

トレース（ベータ）#

分散トレースは、ユーザーのプロンプトと、それが引き起こす API リクエストやツール実行をつなぐスパンを出力します。1 つの要求を、トレースのバックエンドで 1 本のトレースとして見られます。

トレースは既定でオフです。CLAUDE_CODE_ENABLE_TELEMETRY=1 と CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 の両方を設定し、OTEL_TRACES_EXPORTER で送り先を選びます。エンドポイント・プロトコル・ヘッダー・mTLS は共通の OTLP 設定を使い回します。

スパンは、プロンプトのテキスト・ツール入力の詳細・ツール内容を既定で伏せます。含めるには OTEL_LOG_USER_PROMPTS=1・OTEL_LOG_TOOL_DETAILS=1・OTEL_LOG_TOOL_CONTENT=1 を設定します。

• トレースが有効なとき、Bash と PowerShell のサブプロセスは、実行中のツールスパンの W3C トレースコンテキストを入れた環境変数 TRACEPARENT を引き継ぎます。サブプロセスがこれを読めば、自分のスパンを同じトレースの下に置けます
• Anthropic API に直接つないでいるときは、各モデル要求に claude_code.llm_request スパンのコンテキストを入れた W3C の traceparent ヘッダーが付き、API の traceresponse ヘッダーはスパンリンクに記録されます。互換のある中継を通してもクライアント側とサーバー側のトレースがつながります。HTTP の MCP 要求にも同様に traceparent が付きます。サードパーティのプロバイダには送りません
• モデルと HTTP MCP 要求の traceparent ヘッダーは、ANTHROPIC_BASE_URL が未設定か Anthropic API を指すときだけ送ります（未知のヘッダーを拒否するプロキシがあるため）。サブプロセスの TRACEPARENT も同じ切り替えに従います。独自の ANTHROPIC_BASE_URL のプロキシ越しでもトレースコンテキストを伝えたいときは CLAUDE_CODE_PROPAGATE_TRACEPARENT=1 を設定します
• Agent SDK と -p の非対話セッションは、各インタラクションのスパンを始めるとき、自分の環境から TRACEPARENT と TRACESTATE も読みます。埋め込み元のプロセスのトレースコンテキストを渡せば、Claude Code のスパンが呼び出し元の分散トレースの子として現れます。対話セッションは、CI やコンテナ環境の環境値を誤って引き継がないよう、受け取った TRACEPARENT を無視します
• この受け取ったトレースコンテキストはイベントにも適用されます。TRACEPARENT を設定した Agent SDK と -p のセッションでは、トレースのエクスポーターを設定していなくても、各 OTLP イベントのログレコードに trace_id と span_id が付き、アプリケーションのトレースと結べます
• インタラクションが有効なあいだに出たレコードは、権限確認のコールバックや起動中にバッファして後で出すものなど、スパンの非同期コンテキストの外で出す場合でも、インタラクションのスパンの ID を持ちます。有効なインタラクションのスパンが無いときは、受け取った TRACEPARENT の ID を直接持ちます。v2.1.214 より前は、スパンの非同期コンテキストの外のレコードはスパンの ID ではなく受け取った TRACEPARENT の ID を持ち、v2.1.212 より前は、有効なスパンの外のイベントに trace_id／span_id が付きませんでした

スパンの階層#

ユーザーのプロンプトごとに、ルートスパン claude_code.interaction が始まり、API 呼び出し・ツール呼び出し・フック実行がその子として記録されます。ツールのスパンには、権限判断の待ち時間と実行の 2 つの子スパンがあります。Agent ツール（旧 Task ツール）がサブエージェントを起動すると、そのサブエージェントの API・ツールのスパンは親の claude_code.tool スパンの下に入れ子になります。

claude_code.interaction
├── claude_code.llm_request
├── claude_code.hook                    (requires detailed beta tracing)
└── claude_code.tool
    ├── claude_code.tool.blocked_on_user
    ├── claude_code.tool.execution
    └── (Agent tool) subagent claude_code.llm_request / claude_code.tool spans

• Agent SDK と claude -p のセッションでは、環境に TRACEPARENT があると claude_code.interaction 自体が呼び出し元のスパンの子になります
• PreToolUse フックがツール呼び出しを保留すると、Claude Code は保留したターンのトレースコンテキストを保存します。セッションを再開してツールが再実行されると、そのツールのスパンは、以前のターンの claude_code.interaction スパンの子として、そのトレースに加わります

スパン属性#

どのスパンも標準属性と、スパン名と一致する span.type 属性を持ちます。以下は各スパンの追加属性です。llm_request・tool.execution・hook のスパンは失敗を記録するとステータスが ERROR になり、ほかのスパンは常に UNSET で終わります。「ゲート」の列は、その属性に必要な変数です。

claude_code.interaction

claude_code.llm_request

各リトライの試行は、attempt と client_request_id を持つ gen_ai.request.attempt スパンイベントとしても記録されます。

claude_code.tool

claude_code.tool 上の tool.output スパンイベント

OTEL_LOG_TOOL_CONTENT=1 を設定すると、Read と Bash の呼び出しは claude_code.tool スパンに tool.output スパンイベントを記録できます。Edit と Write は、OTEL_LOG_TOOL_DETAILS=1 も設定したときだけ記録します。この変数はその 2 つのツールに限らず他へ引数を足すので、共通設定の表の行を確認してください。MCP ツール・WebFetch・WebSearch も、v2.1.283 以降はこのイベントを記録します。

イベントはツール呼び出しが成功して戻ったときに書くので、エラーを出した呼び出しは何のツールでも記録しません。戻った呼び出しでも、次は tool.output イベントを記録しません。

• Read・Edit・Write・Bash・WebFetch・WebSearch・MCP ツール以外のツールの呼び出し
• ファイルのテキスト以外（画像・PDF・内容が変わっていないファイルの再読込）を返した Read
• OTEL_LOG_TOOL_DETAILS=1 を設定していない Edit・Write
• 待っているメッセージを Claude に届けるため、Claude Code が実行中にバックグラウンドへ移した WebFetch・WebSearch の呼び出し（あとで届く結果も記録されない）。いつ移すかは、ターミナルでは対話モードの「キューに入れたものをいつ送るか」の項、Agent SDK のセッションでは SDKUserMessage の priority フィールドを見る

イベントの属性は、それぞれコンテンツ上限（既定 60 KB）で切られます。「ゲート」は OTEL_LOG_TOOL_CONTENT=1 に加えて必要な変数で、Edit と Write では、その変数が属性ではなくイベント自体のゲートです。

どのツールから来たイベントかは、親スパンの tool_name 属性で分かります。コンテンツ上限で切られた属性には、<属性名>_truncated と <属性名>_original_length が付きます。

claude_code.tool.blocked_on_user

claude_code.tool.execution

claude_code.hook

このスパンは、詳細ベータトレースが有効なときだけ出ます。ENABLE_BETA_TRACING_DETAILED=1 と BETA_TRACING_ENDPOINT の組が必要で、この組はログとトレースの送り先も変えます（環境変数一覧）。シェル・ユーザー設定・管理設定のどれかに置きます。両方ともプロジェクトとローカル設定では無視されます。CLAUDE_CODE_ENHANCED_TELEMETRY_BETA だけでは出ません。対話の CLI セッションでは、詳細ベータトレースに、組織がこの機能の許可リストに載っていることも必要です。Agent SDK と非対話の -p セッションでは許可リストは不要です。

これらの属性は次のスパンに載り、「ゲート」は詳細ベータトレースに加えて要る変数です。コンテンツ上限（既定 60 KB）より長い値は切り詰められます。

詳細ベータトレースで OTEL_LOG_USER_PROMPTS=1 のときは、完全なシステムプロンプトを持つ claude_code.system_prompt イベントも出ます。コンテンツ上限で切られ、セッションが異なるシステムプロンプトを初めて送るたびと、コンパクションの後にもう一度届きます。

動的ヘッダー#

動的な認証が要る企業環境向けに、スクリプトでヘッダーを動的に生成できます。動的ヘッダーは http/protobuf と http/json のプロトコルにだけ適用されます。grpc では、静的ヘッダーの変数（OTEL_EXPORTER_OTLP_HEADERS とその信号別の変数）だけを使います。

設定#

.claude/settings.json に、自分のスクリプトのパスで追加します。

{
  "otelHeadersHelper": "/path/to/generate-otel-headers.sh"
}

値は、実行可能ファイルのパス（空白を含んでもよい）か、引数付きのシェルのコマンドラインです。Windows では常にシェル経由で動くので、空白を含むパスは JSON の値の中で引用符で囲みます。

スクリプトの要件#

スクリプトは、HTTP ヘッダーを表す文字列の key-value を、有効な JSON として出力する必要があります。

#!/bin/bash
# Example: Multiple headers
echo "{\"Authorization\": \"Bearer $(get-token.sh)\", \"X-API-Key\": \"$(get-api-key.sh)\"}"

ヘルパーが失敗するか、要件を満たさない出力をすると、エクスポートは失敗し、ヘルパーが直るまでテレメトリのバックエンドにそのセッションの分は何も届きません。失敗は次で報告されます。

• 対話セッションの警告通知 otelHeadersHelper failed; telemetry is not being exported（最初に失敗したときにセッションごとに 1 回）
• /status の出力
• --debug で起動したとき、またはセッション中に /debug を実行した後のデバッグログ
• -p の非対話セッションでは stderr

更新の動作#

ヘッダーのヘルパースクリプトは、起動時とその後定期的に実行され、トークンの更新に対応します。既定では 29 分ごとです。間隔は環境変数 CLAUDE_CODE_OTEL_HEADERS_HELPER_DEBOUNCE_MS で変えられます。

複数チームの組織向け#

複数のチームや部門を持つ組織は、環境変数 OTEL_RESOURCE_ATTRIBUTES でグループを区別するカスタム属性を足せます。

# Add custom attributes for team identification
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

カスタム属性は全メトリクスとイベントに入るので、次ができます。

• チームや部門でメトリクスを絞り込む
• コストセンターごとにコストを追う
• チーム別のダッシュボードを作る
• 特定のチーム向けのアラートを設定する

Claude Code は、これらの値を OTLP のリソースブロックに送るのに加えて、全メトリクスのデータポイントとイベントのレコードの属性としても付けます。多くのメトリクスのバックエンドはデータポイントの属性を検索できるラベルとして扱うので、カスタムキーで直接グループ化や絞り込みができます。vcs.* のリポジトリ属性を除き、カスタムキーは user.id や session.id などの標準属性を上書きしません。衝突したときは組み込みの値を保ちます。

カスタムキーは全メトリクス系列のラベルになるので、カーディナリティの高い値は保管費用を増やします。カスタム属性をリソースブロックだけに送りデータポイントのラベルから外すには、OTEL_METRICS_INCLUDE_RESOURCE_ATTRIBUTES=false を設定します。

export OTEL_RESOURCE_ATTRIBUTES="org.name=Johns_Organization"
export OTEL_RESOURCE_ATTRIBUTES="org.name=JohnsOrganization"

export OTEL_RESOURCE_ATTRIBUTES="org.name=John%27s%20Organization"

設定例#

claude を実行する前に環境変数を設定します。どの例も完全な設定で、各変数は共通の設定変数の表にあります。反映の確認は、セッション開始後にバックエンドで claude_code.session.count を見ます（ログだけの構成と、何も届かないときの確認はクイックスタートを参照）。

コンソールでデバッグする（エクスポート間隔 1 秒）：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
export OTEL_METRIC_EXPORT_INTERVAL=1000

OTLP を gRPC で送る：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

Prometheus で http://localhost:9464/metrics を取得する：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=prometheus

セルフホスト環境では、ランナーの既定の容量（1）のときだけ、セッションがポート 9464 を使います。容量がそれより大きいと、ランナーが自分の /metrics エンドポイントでセッションのカウンターとゲージを再公開します。

複数のエクスポーターに送る：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console,otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/json

メトリクスとログを別のエンドポイント・バックエンドへ送る：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_METRICS_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://metrics.example.com:4318
export OTEL_EXPORTER_OTLP_LOGS_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=http://logs.example.com:4317

メトリクスだけを送る（イベント・ログなし）：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

イベントとログだけを送る（メトリクスなし）：

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

クラウドセッションと Claude Tag のテレメトリ#

クラウドセッション（Slack と Claude Tag のチャネルのセッションを含む）は、ユーザーの端末ではなくクラウド環境で動くため、端末の管理設定ファイルやシェルプロファイルではテレメトリを設定できません。Anthropic がホストする環境のセッション向けに、変数を置く場所・コレクターへ届かせる方法・クラウドと Claude Tag のセッションをデータ上で見分ける方法を説明します。

CLAUDE_CODE_ENABLE_TELEMETRY と OTEL_* 変数（管理者による設定の例と同じキー）は、次の 2 か所のどちらかに置きます。

• サーバー管理設定：組織のサーバー管理設定の env ブロックに足す。サーバー管理設定が適用される場所では、Claude Code が起動時に取得する。ユーザーの端末と、Claude Tag のチャネルセッション以外のクラウドセッションを含む。Claude Tag のセッションはサーバー管理設定を受け取らないので、この経路では設定できない
• 環境の変数：クラウド環境の環境変数に足すと、その環境で動くセッションだけを設定できる。Claude Tag のセッションに届くのはこちらの経路

環境を使う人は誰でも変数を読めるので、OTEL_EXPORTER_OTLP_HEADERS のコレクターのトークンのような資格情報を置いてはいけません。環境の API 資格情報も役に立ちません。Claude Code 自身のテレメトリのエクスポートは、資格情報が付かない要求の 1 つだからです。コレクターが資格情報を要求するなら、エクスポート全体をサーバー管理設定で設定します。そこに資格情報を置くと、管理設定の外で置かれたエンドポイント変数が取り除かれるからです。

クラウドセッションのテレメトリを設定するときの制約です。

• セッションからコレクターへ届かせる：エクスポートはセッションのネットワーク経由で送られるので、OTEL_EXPORTER_OTLP_ENDPOINT のホストに届くかは、環境のネットワークアクセスレベルで決まります。選んだレベルでコレクターのドメインに届かないなら、環境の許可リストにそのドメインを足します（サーバー管理設定では環境のネットワーク許可リストにドメインを足せない）
• Claude Tag のチャネルは組織レベルの環境を使う：チャネルのセッションは、メンバー個人の環境ではなく組織レベルの環境で動くので、許可リストや環境変数の変更は、組織の既定にしたか、そのチャネルに固定した共有環境で行う
• Cowork は別に設定する：Cowork のセッションはサーバー管理設定を受け取らないので、サーバー管理の env ブロックではテレメトリを設定できない

クラウドセッションにテレメトリを紐づける#

既定では、クラウドセッションのメトリクスとイベントは session.id・ccr.session.id・organization.id を含む標準属性を持つので、追加設定なしでセッションや組織で絞れます。ccr.session.id の値はセッションの CLAUDE_CODE_REMOTE_SESSION_ID です。

さらに詳しく紐づけるには、次を使います。

• Claude Tag のセッションを見分ける：OTEL_METRICS_INCLUDE_ENTRYPOINT=true を設定する。メトリクスに app.entrypoint が付き、Claude Tag のセッションでは値が claude-in-slack になる
• カスタム属性を足す：そのセッション向けの他の OTEL_* 変数と同じ場所に OTEL_RESOURCE_ATTRIBUTES を置く。環境のセットアップスクリプトで export しても Claude Code には届かない（セットアップスクリプトは Claude Code の起動前に動く別の Bash スクリプトで、export した変数はそこで終わる）

Claude Tag のチャネルセッションでは、Claude は特定のメンバーではなく組織の共有 ID として動くので、誰がタグ付けしたかを user.* 属性で特定しようとしないでください。

メトリクスとイベントの一覧#

標準属性#

すべてのメトリクスとイベントが共通で持つ属性です。

Claude apps gateway に /login でサインインしたセッションでは、CLI が認証済みの ID をエクスポートに付けます。user.id は IdP のサブジェクト、user.email はサインインしたメール、user.groups は IdP のグループ所属（カンマ区切りの文字列）です。エクスポートには identity.source: gateway-oidc も付きます。ゲートウェイの ID は最後に適用されるので、そのセッションでは OTEL_RESOURCE_ATTRIBUTES で設定した user.* と identity.* のキーは無視されます。ゲートウェイ経由の Claude Desktop と Cowork のセッションの ID 属性は、ゲートウェイの telemetry の設定リファレンスを見ます。

イベントは、さらに次の属性を持ちます。無制限のカーディナリティになるため、メトリクスには付きません。

リポジトリ属性#

OTEL_METRICS_INCLUDE_REPOSITORY=true で、メトリクスとイベントにセッションのリポジトリの識別を付けられ、共有のコレクターでリポジトリ別の使用量を割り当てられます（v2.1.269 以降）。

Claude Code は、リポジトリの origin リモートからセッションごとに 1 回、これらの属性を導出します。GitHub・GitLab・Bitbucket Cloud のように、HTTPS と SSH のリモートが同じホストと同じパスを指すときは、どちらも同じ値になります。

• 値は小文字になり、リモート URL の資格情報・クエリ文字列・フラグメントは入りません。origin リモートが無い・リモートが URL の形でない・囲むリポジトリがホームディレクトリだけ、のときは属性が省略されます
• クラウドセッションでこの属性を得るには、OTEL_METRICS_INCLUDE_REPOSITORY を含むテレメトリ変数をそのクラウド環境の環境変数に置き、コレクターのドメインを環境のネットワークアクセスで許可します
• OTEL_RESOURCE_ATTRIBUTES に宣言した vcs.* キーは、そのキーの導出値を置き換えます。vcs.repository.url.full を宣言すると、Claude Code はリモートを読まず、宣言したキーだけを報告します
• 1 つのリポジトリで HTTPS と SSH のクローンが違う値になる場合（HTTPS のクローン URL にだけパスの接頭辞があるセルフホスト環境など）は、OTEL_RESOURCE_ATTRIBUTES に vcs.repository.url.full と、報告したい他の vcs.* キーをすべて宣言すると、どのクローンも宣言した ID を報告します
• 属性は自分のエクスポーターにだけ流れます。Anthropic のテレメトリは vcs.* キーをすべて捨てます

メトリクス#

Claude Code は次のメトリクスを出力します。単位の列は各メトリクスに付く OpenTelemetry の単位文字列で、カウント系は単位なしです。

OTEL_METRICS_EXPORTER に prometheus だけを挙げたときは、スクレイプが正しい Prometheus のテキスト形式を保つよう、出力から USD・tokens・s の単位を省きます。メトリクス名は変わらず、otlp,prometheus のように組み合わせると単位は残ります。v2.1.216 より前は、一部のスクレイパーが拒否する OpenMetrics 専用の # UNIT 行が含まれていました。

メトリクスの詳細#

各メトリクスは上の標準属性を持ちます。追加の属性があるものを以下に挙げます。

セッションカウンター#

各セッションの開始時に加算されます。

コード行数カウンター#

コードが追加・削除されたときに加算されます。

プルリクエストカウンター#

Claude Code が、シェルコマンドか MCP ツールでプルリクエスト（マージリクエスト）を作ったときに加算されます。標準属性のみ。

コミットカウンター#

Claude Code で git コミットを作ったときに加算されます。標準属性のみ。

コストカウンター#

API リクエストごとに加算されます。

agent.name・skill.name・plugin.name・mcp_server.name・mcp_tool.name は、既定では一部の名前を "custom" か "third-party" の代替値に置き換えます。OTEL_LOG_TOOL_DETAILS=1 を設定すると実際の名前が入ります。v2.1.273 より前は、コスト・トークンのカウンターと api_request・api_error・api_refusal のイベントが、OTEL_LOG_TOOL_DETAILS=1 でも伏せた値のままでした。

トークンカウンター#

API リクエストごとに加算されます。

コード編集ツール判断カウンター#

ユーザーが Edit・Write・NotebookEdit の使用を承認または拒否したときに加算されます。

アクティブ時間カウンター#

Claude Code を実際に使っている時間を、アイドル時間を除いて追います。入力や応答を読むなどのユーザー操作中と、ツール実行や AI の応答生成などの CLI の処理中に加算されます。

イベント#

OTEL_LOGS_EXPORTER を設定すると、Claude Code は次のイベントを OpenTelemetry のログ／イベントで出力します。

どのイベントも、標準属性に加えて次の 3 つを持ちます。以降の各イベントの表には、イベント固有の属性だけを載せます。

イベントの相関属性#

ユーザーがプロンプトを送ると、Claude Code は複数の API 呼び出しと複数のツール実行を行うことがあります。prompt.id 属性で、それらのイベントを元の 1 つのプロンプトに結びつけます。

• 1 つのプロンプトが起こした活動をすべて追うには、特定の prompt.id の値でイベントを絞ります。そのプロンプトの処理中に出た user_prompt・api_request・tool_result のイベントが得られます
• event.sequence は Claude Code のプロセスが始まるたびに 0 から始まり、そのプロセスの存続中は数え続けます。新しい session.id を割り当てる /clear をまたいでも続きます。分岐せずにセッションを再開すると、session.id はそのままで event.sequence は再開したプロセスの値になるので、1 つのセッションの中で後のイベントが前より小さい値になったり重複したりします。順序は event.timestamp で並べ、同じ時刻のものだけを event.sequence で並べます
• メッセージ単位で再構成するため、各イベントの種類は、セッション記録の項目と一致するキーを持ちます。記録のエントリの形式は Claude Code の内部のもので、バージョンで変わるので、これらのキーで結合するパイプラインはどのリリースでも壊れうるものとして、バージョン固有に扱ってください

user_prompt イベント#

プロンプトが送られたときに記録されます。Claude Code が自分で始めたターンも含みます。イベント名：claude_code.user_prompt

assistant_response イベント#

モデルのテキストを返した API リクエストのあとに記録されます。応答のテキストブロックだけを含み、thinking ブロックと tool-use ブロックは含みません。v2.1.193 以降。イベント名：claude_code.assistant_response

tool_result イベント#

ツールの実行が完了したときに記録されます。ツール呼び出しが拒否された場合は出ません（拒否は tool_decision イベント）。イベント名：claude_code.tool_result

tool_parameters の中身はツールで変わります。

api_request イベント#

Claude への API リクエストごとに記録されます。イベント名：claude_code.api_request

api_error イベント#

Claude への API リクエストが失敗したときに記録されます。イベント名：claude_code.api_error

api_refusal イベント#

API リクエストが stop_reason: "refusal" を返したときに記録されます。拒否は HTTP エラーではなく成功した応答ストリームで届くので、api_error イベントは出ません。このイベントで拒否の頻度を追え、api_request・api_error と同じ属性でグループ化できます。イベント名：claude_code.api_refusal

api_request_body イベント#

OTEL_LOG_RAW_API_BODIES を設定したとき、API リクエストの試行ごとに記録されます。試行ごとに 1 イベントなので、パラメータを調整したリトライもそれぞれイベントを出します。イベント名：claude_code.api_request_body

api_response_body イベント#

OTEL_LOG_RAW_API_BODIES を設定したとき、API 応答が成功するごとに記録されます。

ファイルモード（OTEL_LOG_RAW_API_BODIES=file:<dir>）では、成功した応答ごとに <dir>/index.jsonl へ JSON を 1 行追記します。項目は timestamp・session_id・query_source・model・request_id・message_id・message_uuid・request_file・response_file です。テレメトリのバックエンドに問い合わせずに、ある記録メッセージの元になった要求と応答のファイルを探すのに使えます。インデックスファイルは v2.1.274 以降です。イベント名：claude_code.api_response_body

tool_decision イベント#

ツールの権限判断（承認・拒否）が行われたときに記録されます。イベント名：claude_code.tool_decision

tool_source の値です。

source の値です。

tool_parameters の補足です。

• "sdk_host_builtin_mcp" のツールでは、ホストアプリがこれらの名前を決めるので、OTEL_LOG_TOOL_DETAILS がオフでも mcp_server_name と mcp_tool_name が入ります。これが無いと、これらの組み込みサーバーへの拒否された呼び出しが、既定のストリームで誰のものか分からなくなるためです。ユーザーが設定した MCP サーバーでは、イベントの tool_name は常に文字どおり "mcp_tool" で、サーバー名とツール名は、フラグがあるときの tool_parameters にだけ出ます。引数の内容はどこでもフラグが必要です。v2.1.214 以降
• Bash ツール：bash_command・full_command・timeout・description・dangerouslyDisableSandbox。デスクトップアプリのワークスペースの Bash ツールも tool_name は Bash だが、含まれるのは bash_command・full_command・timeout のみ
• MCP ツール：mcp_server_name・mcp_tool_name
• Skill ツール：skill_name
• Agent ツール・旧 Task ツール：subagent_type

permission_mode_changed イベント#

権限モードが変わったときに記録されます。Shift+Tab の切り替え・plan mode の終了・auto mode のゲート確認などが原因です（権限モード）。イベント名：claude_code.permission_mode_changed

auth イベント#

/login か /logout が完了したときに記録されます。イベント名：claude_code.auth

mcp_server_connection イベント#

MCP サーバーが接続・切断・接続失敗したときに記録されます。イベント名：claude_code.mcp_server_connection

internal_error イベント#

Claude Code が想定外の内部エラーを捕捉したときに記録されます。記録するのはエラーのクラス名と errno 形式のコードだけで、エラーメッセージとスタックトレースは含みません。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry で動かしているとき、または DISABLE_ERROR_REPORTING を設定しているときは出ません。イベント名：claude_code.internal_error

plugin_installed イベント#

プラグインのインストールが完了したとき、claude plugin install CLI コマンドと対話の /plugin UI の両方から記録されます（プラグインを使う）。イベント名：claude_code.plugin_installed

plugin_loaded イベント#

セッション開始時に、有効なプラグインごとに 1 回記録されます。インストール操作自体を記録する plugin_installed を補い、全社でどのプラグインが有効かの棚卸しに使います。イベント名：claude_code.plugin_loaded

skill_activated イベント#

スキルが呼び出されたとき、Claude が Skill ツールで呼んだ場合も、/ コマンドで実行した場合も記録されます（スキル）。イベント名：claude_code.skill_activated

at_mention イベント#

Claude Code がプロンプトの @ メンションを解決したときに記録されます。すべてのメンションが出すわけではなく、権限の拒否・大きすぎるファイル・PDF の参照の添付・ディレクトリ一覧の失敗などの早期終了の経路は、記録せずに戻ります。イベント名：claude_code.at_mention

api_retries_exhausted イベント#

2 回以上の試行のあとに API リクエストが失敗したときに 1 回記録されます。最終の api_error イベントと一緒に出ます。イベント名：claude_code.api_retries_exhausted

hook_registered イベント#

セッション開始時に、設定されたフックごとに 1 回記録されます。実行ごとの hook_execution_start・hook_execution_complete を補い、全社でどのフックが有効かの棚卸しに使います（フックのリファレンス）。イベント名：claude_code.hook_registered

hook_execution_start イベント#

フックのイベントに対して 1 つ以上のフックが実行を始めたときに記録されます。イベント名：claude_code.hook_execution_start

hook_execution_complete イベント#

フックのイベントのすべてのフックが終わったときに記録されます。イベント名：claude_code.hook_execution_complete

hook_plugin_metrics イベント#

公式マーケットプレイスのプラグインのフックが、呼び出しごとの指標を出したときに記録されます。出せるのは、Anthropic の公式マーケットプレイスからインストールしたプラグインだけで、サードパーティのマーケットプレイスのプラグインとユーザーが設定したフックはこのイベントを出しません。プラグインの挙動（検出率・コスト・所要時間など）を自前の可観測性基盤で監視するのに使います。イベント名：claude_code.hook_plugin_metrics

compaction イベント#

会話の圧縮が完了したときに記録されます（コンテキストとプロンプトキャッシュ）。イベント名：claude_code.compaction

subagent_completed イベント#

サブエージェントが終わり、起動元の会話へ結果を返したときに記録されます。サブエージェントの種類ごとにツール使用と実行時間を集計するのに使います。トークンやコストの集計には、query_source を "subagent" に絞ったトークンカウンターとコストカウンターを使います（このイベントの total_tokens は最後のリクエストだけだからです）。"subagent" の分類は、エージェント型フックのリクエストも数えますが、それはサブエージェントのイベントを出しません。イベント名：claude_code.subagent_completed

feedback_survey イベント#

セッションの品質アンケートが表示された、または回答されたときに記録されます。アンケートが集める内容と制御の方法はセキュリティとデータの扱いを参照してください。イベント名：claude_code.feedback_survey

retention_sweep イベント#

保持期間の掃除（cleanupPeriodDays 設定より古いセッション記録などのアプリケーションデータを削除する）の実行ごとに 1 回記録されます。掃除は、1 セッションにつき最大 1 回、バックグラウンドで動きます。何も削除しなかった実行もイベントを出します。同じマシンのどこかのセッションで過去 24 時間以内に掃除が走っていれば、このセッションの掃除は少なくとも 10 分遅れるので、それより早く終わるセッションはイベントを出しません。claude -p を --bare で動かすと、掃除は走らず、イベントも出ません。

このページのほかの OTel イベントと同じく、設定したテレメトリのバックエンドにだけ送られます（v2.1.227 以降）。

Claude Code が保持期間を安全に決められないときは、掃除を止め、result を "skipped" にして skip_reason を付けたイベントを出します。管理設定が cleanupPeriodDays を設定していると、管理値が保持期間を固定し、優先度の低いスコープの設定ファイルが壊れていても掃除は動きます。managed-settings.json 自体が読めないときは、管理層が別の取得元（サーバー管理設定や、壊れたファイルの隣の managed-settings.d/ のドロップイン）から cleanupPeriodDays を供給しない限り、掃除は止まります。削除数のカウンターの属性は result が "complete" のときだけ付きます。イベント名：claude_code.retention_sweep

skip_reason の値です。

managed_settings_resolved イベント#

セッションが解決した管理設定とともに記録されます。セッション開始時に 1 回、セッション中に管理設定かポリシーヘルパーの状態が変わったとき、および error.type が挙げる理由のどれかで Claude Code が起動を拒否またはセッションを終了したときです。想定外の管理の取得元で動いているマシン・ポリシーヘルパーが失敗しているマシン・マシンが起動を拒否した理由を見つけるのに使います（v2.1.274 以降。設定の詳細は組織への導入と管理設定）。

既定では、イベントは管理の取得元とポリシーヘルパーの状態を持ち、設定そのものは持ちません。秘匿した managed_settings.settings 属性と managed_settings.resolved_sha256 ダイジェストを足すには OTEL_LOG_MANAGED_SETTINGS=1 を設定します。

• 管理設定の env ブロック・ユーザー設定・--settings、または Claude Code を起動する環境に置く。プロジェクトとローカル設定の値では有効にならない（クローンしたリポジトリが書けるため）
• サーバー管理設定からは、セキュリティ承認ダイアログを出さずに設定できる。この変数は、組織がすでに受け取るイベントに、組織自身の秘匿済みポリシーを足すだけだから
• 信頼していないフォルダでの対話セッションでは、Claude Code は拒否イベントをエクスポートしない

イベント名：claude_code.managed_settings_resolved

error.type の値です。

managed_settings.helper.state の値です。

managed_settings.settings の作り方です。

• スキーマが宣言する設定名は出力し、宣言していないキーは出さない
• 真偽値・数値と、スキーマが固定の選択肢に限る文字列値（permissions.defaultMode など）はそのまま出力する。sandbox.network.httpProxyPort と sandbox.network.socksProxyPort は "[REDACTED]" で出力する
• ほかの文字列（model・apiKeyHelper・env のすべての値・すべての URL・すべてのコマンドなど）は "[REDACTED]" で出力する
• マップのエントリ名（env の変数名やプラグイン ID など）はそのまま出力する。スキーマがエントリの型を決めていない設定（vimInsertModeRemaps など）は 1 つの "[REDACTED]" で出力し、sandbox.ignoreViolations はコマンドパターンを除いたパスのリストの一覧で出力する
• リストは長さを保ち、各エントリを同じ規則で秘匿する
• permissions.allow・permissions.deny・permissions.ask のルールは、ツールがこのバージョンの組み込みか mcp__jira__create_issue のような mcp__ の参照なら、内容を秘匿したツール名（Read([REDACTED]) など）で出力する。それ以外のルールは "[REDACTED]"
• フックも同じ規則に従うので、type や timeout のような固定の選択肢や数値の項目は出て、各コマンド・URL・matcher・if 条件は "[REDACTED]" になる

apiKeyHelper・2 つの env 変数・deny ルールを持つ管理設定の出力例です。

{"apiKeyHelper":"[REDACTED]","env":{"HTTPS_PROXY":"[REDACTED]","CLAUDE_CODE_ENABLE_TELEMETRY":"[REDACTED]"},"permissions":{"deny":["Read([REDACTED])"]}}

値は UTF-8 で 8 KB で切られ、切られた値は有効な JSON ではありません。

メトリクスとイベントを読み解く#

出力したメトリクスとイベントは、さまざまな分析に使えます。

使用量の監視#

コストの監視#

claude_code.cost.usage メトリクスは次に役立ちます。

• チームや個人ごとの使用量の傾向を追う
• 最適化の対象になる使用量の多いセッションを見つける
• skill.name・plugin.name・agent.name 属性で、支出を特定のスキル・プラグイン・サブエージェントの種類に割り当てる

Claude Code は、ANTHROPIC_BASE_URL の先のゲートウェイやプロキシが複数フレームにまたがって使用量を段階的にストリームする場合でも、各ストリーム応答をコストとトークンのメトリクスにちょうど 1 回だけ数えます。v2.1.214 より前は、使用量を複数フレームで運ぶストリームは、増えたフレームごとにおよそ 1 リクエスト分、claude_code.cost.usage と claude_code.token.usage を水増ししていました。

アラートとセグメント分け#

検討したい一般的なアラートです。

• コストの急増
• 異常なトークン消費
• 特定のユーザーからのセッション数の多さ

すべてのメトリクスは標準属性で分けられます。model 属性は claude_code.token.usage・claude_code.cost.usage、および v2.1.172 以降の claude_code.lines_of_code.count にあります。コミットのモデル別の内訳は、1 つのセッションが複数のモデルにまたがりうるので、session.id でトークンかコストのメトリクスと結合して近似するしかありません。補助とサブエージェントの要求が、コミットを作っていないモデルに割り当てられないよう、トークンかコスト側を query_source が "main" の行に絞ります。

リトライ切れの検出#

Claude Code は失敗した API リクエストを内部でリトライし、あきらめたあとにだけ claude_code.api_error を 1 回出すので、そのイベント自体がそのリクエストの終端の信号です。途中のリトライの試行は別のイベントとして記録されません。

• イベントの attempt 属性が総試行回数。CLAUDE_CODE_MAX_RETRIES の既定は 10 で、上限は 15
• v2.1.199 以降は、CLAUDE_CODE_RETRY_WATCHDOG を設定すると既定を引き上げ、上限を外せる
• 一時的なエラーですべてのリトライを使い切ると、attempt は有効な上限に 1 を足した値になる：既定では 11、watchdog を設定しなければ 16 を超えない。これより小さい値は、400 応答のようなリトライ不能なエラーか、より小さな独自のリトライ枠を持つ原因を示す（たとえば AWS や Google Cloud の資格情報の読み込み失敗は、最大 2 回までリトライ）
• 回復したセッションと止まったセッションを分けるには、session.id でイベントをグループ化し、エラーの後に api_request イベントがあるかを確認する

イベントの分析#

イベントデータは、Claude Code の各やり取りを詳しく記述します。

• ツールの使用パターン：tool_result イベントから、よく使われるツール・ツールの成功率・ツールの平均実行時間・ツール種別ごとのエラーの傾向を分析する
• 性能の監視：API リクエストの所要時間とツールの実行時間を追って、性能のボトルネックを見つける

入力トークンを OpenTelemetry の GenAI の規約へ対応づける#

Claude Code は、入力トークン数を API 応答の usage ブロックのとおりに出すので、次の値にはプロンプトキャッシュから読んだ分と書いた分が含まれません。

• claude_code.llm_request スパンと api_request イベントの input_tokens
• claude_code.token.usage メトリクスの "input" の type

Claude Code は gen_ai.usage.* の属性を設定しません。OpenTelemetry の GenAI の規約は、gen_ai.usage.input_tokens にキャッシュから読んだ分と書いた分を含めるべきだとしています。合計は次のように出します。

• スパンかイベントから：input_tokens・cache_read_tokens・cache_creation_tokens を足す
• claude_code.token.usage メトリクスから："input"・"cacheRead"・"cacheCreation" の type を足す

規約には、キャッシュの読み取りと書き込みの別々の属性もあります。

• cache_read_tokens は gen_ai.usage.cache_read.input_tokens に対応する
• cache_creation_tokens は gen_ai.usage.cache_write.input_tokens に対応する。規約の古い版は書き込みの属性を gen_ai.usage.cache_creation.input_tokens と呼ぶので、バックエンドが求める名前を使う

セキュリティイベントの監査#

OpenTelemetry のイベントは、Claude Code の活動の監査データの出どころです。どのイベントも、ツール呼び出し・MCP の活動・権限判断を、それを起こしたユーザーに結ぶ ID 属性を持ちます。OTLP のログエクスポーターは、これらのイベントを、OTLP レシーバーを持つ SIEM（Security Information and Event Management）基盤か、SIEM へ転送する OpenTelemetry Collector へ届けられます。

操作をユーザーに結びつける#

各イベントの標準属性には、認証済みユーザーの ID があります。Claude アカウントでサインインしているとき（クラウドセッションではセッション自身の資格情報が持つとき）の user.email・user.account_uuid・user.account_id・organization.id と、user.id とセッションごとの session.id です。user.id はインストール単位の識別子ですが、Claude apps gateway に /login でサインインしたセッションでは、ゲートウェイが発行したトークンの IdP のサブジェクトになります。

• 開発者が始めたセッションでは、MCP ツール呼び出し・Bash コマンド・ファイル編集はその開発者に結びつきます。別のサービスアカウントで動くことはなく、各イベントの ID は、開発者自身の Claude アカウント（Claude apps gateway のセッションでは開発者の IdP の ID）です。Claude Tag のチャネルセッションでは、Claude は組織の共有 ID として動きます
• 直接の API キーや Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry で認証しているときは、セッションに Claude アカウントが無く、user.id と session.id だけが入ります。この構成では、OTEL_RESOURCE_ATTRIBUTES でユーザーの ID を自分で付けます。管理設定のファイルかランチャーのラッパーで、ユーザーごとに設定します。Claude apps gateway のセッションには不要です

export OTEL_RESOURCE_ATTRIBUTES="enduser.id=jdoe@example.com,enduser.directory_id=S-1-5-21-..."

MCP の活動を監査する#

MCP サーバーの活動を呼び出しの詳細つきで取るには、ログのエクスポーターを有効にして OTEL_LOG_TOOL_DETAILS=1 を設定します。各 MCP 操作が、標準の ID 属性とともにサーバー名・ツール名・呼び出し引数を持つ構造化イベントを出します。

OTEL_LOG_TOOL_DETAILS が無いと、これらのイベントは識別の詳細を落とします。

• tool_result：mcp_server_scope は残り、ユーザーが設定したサーバーでは tool_name が文字どおり "mcp_tool" に伏せられ、引数の内容は出ない。Claude Desktop 組み込みのサーバー（Desktop が管理するセッション）では、tool_parameters の中の mcp_server_name／mcp_tool_name の組も残る（v2.1.214 以降）
• tool_decision：tool_source は残り、ユーザーが設定したサーバーでは tool_name が文字どおり "mcp_tool" に伏せられ、引数の内容は出ない。Claude Desktop 組み込みのサーバー（Desktop が管理するセッション）では mcp_server_name／mcp_tool_name の組も残る。tool_source と名前の組はどちらも v2.1.214 以降
• mcp_server_connection：server_name とエラーメッセージは出ないが、is_plugin・plugin_id_hash・plugin.name は残り、Anthropic 以外のプラグイン名は文字どおり "third-party" に伏せられるので、詳細ログが無くてもプラグイン提供のサーバーを見分けられる

セキュリティの問いをイベントに対応づける#

検知ルールを作るときは、監視したい信号を探し、対応するイベントと属性をバックエンドに問い合わせます。

Claude Code が出すのは生のイベントストリームだけです。異常検知・ベースライン・セッションをまたぐ相関・アラートは、SIEM か可観測性バックエンドの役目です。

イベントを SIEM に送る#

OTEL_EXPORTER_OTLP_LOGS_ENDPOINT を、SIEM の OTLP レシーバーか、SIEM のネイティブの取り込み API へ転送する OpenTelemetry Collector に向けます。次の管理設定の例は、MCP と Bash の監査のためにツールの詳細を有効にして、イベントだけを出力します。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_LOG_TOOL_DETAILS": "1",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://siem.example.com:4318/v1/logs",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your-siem-token"
  }
}

イベントが届くかは、この設定で動くセッションでプロンプトを送り、SIEM で claude_code.user_prompt イベントを探して確かめます。何も届かなければ、claude --debug-file <path> で起動し、そのログで [3P telemetry] のエクスポートエラーを確認します。

バックエンドの選び方#

メトリクス・ログ・トレースのバックエンドの選択が、できる分析の種類を決めます。

日次・週次・月次のアクティブユーザー（DAU/WAU/MAU）の指標が要る組織は、ユニークな値の効率的なクエリに対応するバックエンドを検討してください。

サービス情報#

すべてのメトリクスとイベントは、次のリソース属性つきで出力されます。

コレクターのパイプラインやダッシュボードが service.name = claude-code で絞っているなら、Code タブのセッションのテレメトリも拾うため、絞り込みに claude-code-desktop を足します。

投資対効果の測定#

Claude Code の投資対効果を測る包括的なガイドとして、Anthropic が公開している「Claude Code ROI Measurement Guide」のリポジトリ（anthropics/claude-code-monitoring-guide）があります。テレメトリの設定・コスト分析・生産性指標・自動レポートを扱い、すぐ使える Docker Compose の構成、Prometheus と OpenTelemetry の設定、Linear などのツールと連携する生産性レポートのテンプレートが入っています。Amazon Bedrock での使用量の監視は、AWS が公開している「Claude Code Monitoring Implementation (Amazon Bedrock)」を参照してください。

セキュリティとプライバシー#

• あなたのバックエンドへの OpenTelemetry のエクスポートはオプトインで、明示的な設定が要ります。Anthropic 自身の運用テレメトリとその無効化はセキュリティとデータの扱いを参照
• ファイルの生の内容とコードの断片は、メトリクスとイベントに含まれません。トレースのスパンは別のデータ経路で、OTEL_LOG_TOOL_CONTENT の項目を参照
• OAuth で認証していると user.email がテレメトリの属性に入ります。送られるのは設定した OTel エンドポイントだけで、Anthropic には送られません。懸念がある組織は、テレメトリのバックエンド側でこの項目を絞り込むか秘匿します
• ユーザープロンプトの内容は既定で収集されず、プロンプトの長さだけが記録されます。含めるには OTEL_LOG_USER_PROMPTS=1。有効にすると次が起きます

  • user_prompt イベントは、プロンプトのテキストを prompt と prompt_text の 2 つの属性に持つ。コレクターで属性名を指定してイベントのプロンプトのテキストを落とす・伏せるときは、ルールに両方の名前を書く

    次の OpenTelemetry Collector の attributes プロセッサは、これを列挙したパイプラインで両方の属性を削除します。

    yamlコピー

    processors:
      attributes/drop-prompt-text:
        actions:
          - key: prompt
            action: delete
          - key: prompt_text
            action: delete
    

  • トレースを有効にすると、claude_code.interaction スパンが user_prompt 属性にプロンプトのテキストを持つ

  • 詳細ベータトレースでは、スパンが要求ごとの新しいユーザーメッセージ・ツール結果・システムリマインダー、システムプロンプトのテキスト、モデルの出力も持つ。各属性は「詳細ベータトレースの内容属性」の表を見る。claude_code.system_prompt イベントは完全なシステムプロンプトを持つ

• アシスタントの応答テキストは既定で収集されず、応答の長さだけが記録されます。含めるには OTEL_LOG_ASSISTANT_RESPONSES=1。Claude Code の他の OpenTelemetry データと同じく、応答テキストは設定した OTel エンドポイントにだけ送られ、Anthropic には送られません。この変数が未設定なら OTEL_LOG_USER_PROMPTS が代わりに使われるので、プロンプトの内容は取り、イベントの応答の内容は取りたくないなら OTEL_LOG_ASSISTANT_RESPONSES=0 を設定します。詳細ベータトレースでは、claude_code.llm_request スパンの response.model_output が引き続きモデルの出力を持ち、これはこの変数ではなく OTEL_LOG_USER_PROMPTS に従います
• ツールの入力引数とパラメータは既定で記録されません。含めるには OTEL_LOG_TOOL_DETAILS=1。このデータも設定した OTEL エンドポイントにだけ送られ、Anthropic には送られません。引数に機密の値が入りうるので、必要に応じてバックエンドでこれらの属性を絞り込むか秘匿します。有効にすると次が起きます
  • tool_result と tool_decision のイベントに、Bash コマンド・MCP のサーバー名とツール名・スキル名を含む tool_parameters 属性が入る。full_command などは切り詰めずに出る
  • tool_result イベントには、ファイルパス・URL・検索パターンなどの引数を含む tool_input 属性も入る。512 文字を超える個々の値は切り詰められ、全体はおよそ 4K 文字までに収まる
  • user_prompt イベントに、カスタム・プラグイン・MCP のコマンドの command_name がそのまま入る
  • コスト・トークンのカウンターと api_request・api_error・api_refusal のイベントの割り当て属性に、実際のエージェント・スキル・プラグイン・MCP のサーバー名とツール名が入る
  • claude_code.tool スパンに、file_path などの入力由来の属性が入る。詳細ベータトレースでは tool_input 属性も入る
• ツールの内容は、トレースのスパンに既定では記録されません。含めるには OTEL_LOG_TOOL_CONTENT=1。claude_code.tool スパンに、ファイルの生の内容・Bash コマンドの出力・MCP ツールや WebFetch や WebSearch が返したものを持つ tool.output スパンイベントが付き、属性ごとにコンテンツ上限（既定 60 KB）で切られます。MCP ツール・WebFetch・WebSearch の結果は v2.1.283 以降です。ツールの内容は new_context（ゲートはスパンごとに違う）経由でもスパンに届きます。必要に応じてバックエンドでこれらの属性を絞り込むか秘匿します
• Anthropic Messages API の生のリクエスト・応答本文は既定で記録されません。含めるには、シェル・ユーザー設定・管理設定に OTEL_LOG_RAW_API_BODIES を設定します（プロジェクトとローカル設定では無視される）。本文は、システムプロンプト・過去のユーザーとアシスタントのすべてのターン・ツール結果を含む会話履歴全体を含むので、有効にすると、他の OTEL_LOG_* の内容フラグが明らかにするすべてに同意したことになります。Claude の extended thinking の内容は、他の設定にかかわらず常に伏せられます。設定した値が、本文の届け方を決めます
  • =1：API 呼び出しごとに api_request_body と api_response_body のログイベントを出す。イベントの body 属性に JSON 化したペイロードが入り、コンテンツ上限（既定 60 KB）で切られる
  • =file:<dir>：切り詰めない本文を、そのディレクトリの下の .request.json と .response.json に書き、イベントにはインラインの本文の代わりに body_ref のパスが入る。ディレクトリはテレメトリのストリームではなく、ログコレクターかサイドカーで送る。成功した応答ごとに、そのディレクトリの index.jsonl へ 1 行が追記され、応答ファイルを、それを生んだ要求ファイルと、それになった記録メッセージに結ぶ。各行はメッセージの内容を持たない。項目は api_response_body イベントの節にある。インデックスファイルは v2.1.274 以降

チームの分析ダッシュボード#

OpenTelemetry とは別に、プランごとの分析ダッシュボードがあります。開発者の利用状況・貢献の指標・導入状況を見るためのものです。

ユーザー別のトークン数とコストの推定は、OpenTelemetry のエクスポートを設定するか、組織の分析設定から Spend report をエクスポートします（ユーザー別・モデル別のトークン使用量と、推定の使用クレジットの支出が出ます）。支出の管理はコストを抑えるを参照してください。

Team・Enterprise の分析#

ダッシュボードを見られるのは、管理者（Admin）とオーナー（Owner）です。内容は次のとおりです。

• 使用量の指標：受け入れたコードの行数・提案の受け入れ率・日次のアクティブユーザーとセッション
• 貢献の指標：Claude Code の支援で出した PR とコード行数（GitHub 連携）
• リーダーボード：Claude Code の使用量で並べた上位の貢献者
• データのエクスポート：貢献データを CSV でダウンロードしてカスタムレポートに使う

貢献指標を有効にする#

使用量と導入のデータは、すべての Claude for Teams と Claude for Enterprise のアカウントで使えます。貢献指標には、GitHub の組織をつなぐ追加の設定が要り、分析設定の変更にはオーナーのロールが、GitHub アプリのインストールには GitHub の管理者が必要です。

1. GitHub の管理者が、組織の GitHub アカウントに Claude の GitHub アプリ（github.com/apps/claude）をインストールする
2. Claude のオーナーが、claude.ai/admin-settings/claude-code で Claude Code の分析機能を有効にする
3. 同じページで「GitHub analytics」のトグルを有効にする
4. GitHub の認証フローを完了し、分析に含める GitHub の組織を選ぶ

データは通常、有効にしてから 24 時間以内に現れ、毎日更新されます。データが出ないときは次のメッセージが出ることがあります。

• 「GitHub app required」：貢献指標を見るには GitHub アプリをインストールする
• 「Data processing in progress」：数日後にもう一度見る。それでも出なければ GitHub アプリがインストールされているか確認する

貢献指標は、GitHub Cloud と GitHub Enterprise Server に対応しています。

要約指標を読む#

ダッシュボードの上部に次の要約指標が出ます。

グラフ#

PR の帰属#

貢献指標を有効にすると、Claude Code はマージ済みのプルリクエストを分析し、Claude Code の支援で書かれたコードを判定します。Claude Code のセッション活動を、各 PR のコードと照合する方法です。

PR がマージされたときの流れです。

1. PR の diff から追加された行を取り出す
2. 時間枠の中で、一致するファイルを編集した Claude Code のセッションを特定する
3. 複数の方式で、PR の行を Claude Code の出力と照合する
4. AI の支援を受けた行と全体の行について指標を計算する

比較の前に、行は正規化されます（空白を削る・連続する空白をまとめる・引用符を統一する・小文字に変換する）。Claude Code の支援を受けた行を含むマージ済みの PR には、GitHub で claude-code-assisted のラベルが付きます。

• 時間枠：PR のマージ日の 21 日前から 2 日後までのセッションを、帰属の照合の対象にする
• 除外されるファイル：自動生成されるため、次のファイルは分析から自動で除外される
  • ロックファイル：package-lock.json・yarn.lock・Cargo.lock など
  • 生成コード：Protobuf の出力・ビルド成果物・最小化したファイル
  • ビルドのディレクトリ：dist/・build/・node_modules/・target/
  • テストのフィクスチャ：スナップショット・カセット・モックデータ
  • 1,000 文字を超える行（最小化か生成されたものとみられる）
• 帰属の注意点：
  • 開発者が大幅に書き直したコード（20% を超える差）は、Claude Code に帰属されない
  • 21 日の枠の外のセッションは考慮されない
  • アルゴリズムは、帰属を行うときに PR のソースブランチもマージ先ブランチも考慮しない

分析を活かす#

貢献指標は、ROI の説明・導入パターンの把握・始めたい人を手伝える人の発見に使えます。

• 導入を監視する：Adoption のグラフとユーザー数で、他の人にベストプラクティスを共有できるアクティブユーザー、組織全体の導入の傾向、摩擦や問題を示しうる利用の落ち込みを見つける
• ROI を測る：「このツールは投資に見合うか」に、自分のコードベースのデータで答える。導入が進むにつれた PR per user の変化を追う。Claude Code ありとなしで出した PR とコード行数を比べる。DORA 指標・スプリントのベロシティなどのエンジニアリング KPI と併用して、Claude Code の導入による変化を理解する
• パワーユーザーを見つける：リーダーボードで、Claude Code の導入が進んでいて、プロンプトの工夫とワークフローをチームに共有し、うまくいっている点のフィードバックをくれ、新しいユーザーの立ち上げを助けてくれる人を探す
• データをプログラムから取る：Enterprise プランでは、Claude Enterprise Analytics API が、Claude Code を含む各サーフェスの組織のユーザー別のエンゲージメント・使用量・コストのレポートを返す。キーは Primary Owner が claude.ai/analytics/api-keys で read:analytics スコープ付きで作る。この API は Teams プランでは使えない。貢献データを GitHub 側で調べたいなら、claude-code-assisted ラベルが付いた PR を検索する

API 利用者（Claude Console）の分析#

Claude Console の API 利用者は、platform.claude.com の claude-code で分析を見られます。ダッシュボードには UsageView の権限が必要で、Developer・Billing・Admin・Owner・Primary Owner のロールに付与されています。同じ日次のユーザー別の指標をプログラムから取るには、Admin API キーで Claude Code Analytics API を使います。

Console のダッシュボードに出るもの：

• Lines of code accepted：ユーザーがセッションで受け入れた、Claude Code が書いたコードの行数の合計。拒否した提案を除き、その後の削除は追跡しない
• Suggestion accept rate：コード編集ツール（Edit・Write・NotebookEdit）の使用をユーザーが受け入れた割合
• Activity：日次のアクティブユーザーとセッションのグラフ
• Spend：日次の API コスト（ドル）とユーザー数

チームの洞察の表は、ユーザー別の指標を出します。