Claude Code OpenTelemetryの設定｜チームの使用状況を収集先へ届けて確かめる

Claude CodeのOpenTelemetry対応は、利用状況のデータを自社の監視基盤へ送る機能です。セッション数、トークン数、費用の目安、ツールの実行などを、チーム全体で集めて見られます。既定では何も送られず、環境変数で有効にした時だけ、指定した送り先へ届きます。

先に答えをまとめると、手順は4段階です。まず1台でCLAUDE_CODE_ENABLE_TELEMETRY=1と送り先を設定し、claude_code.session.countが届くことを確かめます。次に管理設定で全員へ配り、チームごとの属性を足します。そして、プロンプトなど機密になり得る内容は既定のまま送らないようにして、受け取った指標の読み方を決めます。

この記事は、2026年11月1日に確認したAnthropicの公式資料をもとに、編集部が導入の順序と確認項目をまとめたものです。変数や指標はバージョンで変わることがあります。本文中の設定は説明用の例で、編集部の環境で実際に送信して確かめた実測結果ではありません。

Claude CodeのOpenTelemetryで分かること

OpenTelemetryは、指標やログを共通の形式で送るための標準の仕組みです。公式資料（英語）によると、Claude Codeは次の3種類のデータを送れます。

主な指標は次のとおりです。

使用量の確認画面との違い

使用量を見る方法は他にもあります。目的が違うので、OpenTelemetryが本当に必要かを先に確かめます。自分の上限を見たいだけなら、/usageの記事で足ります。

費用の公式資料（英語）は、OpenTelemetryをすべての構成で使え、利用者ごとのトークンと費用を自社の基盤へほぼリアルタイムで流せる唯一の方法と説明しています。Amazon BedrockなどのクラウドやLLMゲートウェイの構成でも使えます。

OpenTelemetryのデータが届くことを1台で確かめる手順

いきなり全員へ配らず、まず1台で「出力できる」「収集先へ届く」を順に確かめます。問題が起きた時に、設定と収集先のどちらが原因かを切り分けられます。

1. 画面へ出力します。送り先を使わず、Claude Code自身がデータを出すことを確かめます。

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

2. 収集先へ送ります。プロトコルに既定値はないので、必ず指定します。認証が必要な収集先ならヘッダーも設定します。

   export CLAUDE_CODE_ENABLE_TELEMETRY=1
   export OTEL_METRICS_EXPORTER=otlp
   export OTEL_LOGS_EXPORTER=otlp
   export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
   export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
   export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-token"
   export OTEL_METRIC_EXPORT_INTERVAL=10000
   claude

3. 届いたことを確かめます。指標を送るなら、収集先にclaude_code.session.countがあるかを見ます。セッションの開始時に送られる指標です。イベントだけを送る設定なら、プロンプトを1つ送ってからclaude_code.user_promptを探します。
4. 届かない時はログを見ます。claude --debug-file ログのパスで起動し、そのファイルで[3P telemetry]のエラーを探します。[Anthropic telemetry]の行はAnthropic自身の運用データの話で、今回の設定の問題ではありません。

確認の間隔を短くしたのは試験のためです。既定の送信間隔は指標が60秒、イベントが5秒なので、本番では短くした設定を戻します。Prometheusで受ける場合はOTEL_METRICS_EXPORTER=prometheusにして、http://localhost:9464/metricsから読み取ります。

OpenTelemetryの設定を管理設定でチーム全員へ配る

各自に環境変数を頼むと、設定の漏れや送り先の違いが出ます。全員に同じ設定を適用するなら、管理設定のenvに書きます。

{
  "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"
  }
}

配り方を決める時に、見落としやすい点が3つあります。

• リポジトリの設定では有効にできません。OpenTelemetryの送信先の変数は、リポジトリの.claude/settings.jsonと.claude/settings.local.jsonでは無視されます。リポジトリから勝手に送り先を変えられないようにするためです。ただし、OTEL_LOGS_EXPORTERなどをnoneにして送信を止めることはできます。
• 送り先は固定されますが、送信の有無は別です。管理設定でOTEL_EXPORTER_OTLP_ENDPOINTを決めると、開発者が設定した個別の送り先は起動時に取り除かれます。一方でOTEL_METRICS_EXPORTERのような選択の変数は開発者が変更できるので、固定したい時はこれも管理設定に書きます。
• 認証の値を固定で配らない方法もあります。HTTP系のプロトコルでは、短い期間で切れるトークンをotelHeadersHelperに指定したスクリプトから取得できます。既定では29分ごとに実行されます。grpcでは使えません。スクリプトが失敗すると、そのセッションのデータは届かなくなります。

OpenTelemetryの属性でチームごとに集計する

指標には標準で組織のIDやセッションのIDなどの属性が付きます。部署やチームで分けたい時は、OTEL_RESOURCE_ATTRIBUTESで独自の属性を足します。

export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

値に空白は使えません。空白があると、エラーも出ないままイベントや指標に属性が付かなくなります。引用符で囲んでも空白の代わりにはならず、引用符まで値に含まれます。空白を使いたい時は、アンダースコアにするか%20に置き換えます。user.idやsession.idのような標準の属性と同じ名前を指定しても、標準の値は上書きされません。

属性を増やすほど、収集先の保存量と費用が増えます。必要な粒度に合わせて、次の変数で調整します。

OpenTelemetryで送る内容と機密の既定値

データはOpenTelemetryの設定で指定した送り先だけに届き、この経路でAnthropicへ送られることはありません。また、既定では、ファイルの内容やコードの断片は指標とイベントに含まれません。導入前に確かめたいのは、既定で送らない内容を、変数で有効にするかどうかです。

メールアドレスは既定で送られる点に注意が必要です。利用者ごとに見られる便利さと引き換えに、収集先の閲覧権限と保存期間を決めておく必要があります。社内で「誰が何をしたか」を監査する目的で使うなら、ファイルやコマンドの内容まで集めるかどうかを含めて、先に社内の規程と照らし合わせます。情報の扱いを制限する設定は情報漏洩対策の記事にまとめています。

OpenTelemetryをクラウドセッションとClaude Tagで使う

クラウドセッションは利用者のパソコンの外で動くので、パソコンの管理設定やシェルの設定では計測できません。設定する場所は次の2つです。

DesktopのCodeタブのセッションは管理設定を読みます。一方、管理画面の「Monitoring」にあるCoworkのOpenTelemetryの設定はCowork専用で、CLIやCodeタブには効きません。また、Codeタブのセッションはservice.nameがclaude-code-desktopになるので、絞り込みをclaude-codeだけにしていると見落とします。

収集先に認証が必要な場合は、環境の変数やネットワークシークレットには置けません。公式資料は、送信の設定全体をサーバー管理の設定にまとめる方法を示しています。ただし、その設定はClaude Tagのセッションには届きません。

送信はセッションのネットワークを通るため、環境のネットワーク設定で収集先のドメインを許可しておきます。セッションを区別する時はsession.idではなくccr.session.idを使います。また、Claude Tagのチャンネルのセッションは組織で共有する身元で動くので、user.*の属性からは、誰がClaudeを呼んだかを判断できません。

OpenTelemetryの指標を読む時の注意

• 費用は請求額ではありません。claude_code.cost.usageは目安で、正式な請求はClaude Console、Amazon Bedrock、Google CloudのAgent Platformなどの利用先で確かめます。契約の単価で払っている組織では、既定の定価で計算された値と請求が合いません。合わせたい時は管理設定のmodelPricingに契約の単価を書きます（v2.1.242以降）。実際の請求額は変わりません。
• 行数やPRの数だけで成果を判断しません。公式資料は開発の流れへの影響を知る材料として挙げていますが、作業の難しさや品質までは分かりません。編集部としては、個人の評価ではなくチームの傾向を見る指標として使い、記録していることを利用者へ事前に伝えることを勧めます。
• コミットのモデル別は近似です。model属性はトークン、費用、行数の指標だけに付きます。コミットをモデルごとに見るには、session.idでトークンや費用の指標と突き合わせ、query_sourceがmainのものだけに絞ります。

アラートの例として、公式資料は費用の急増、トークン消費の異常、特定の利用者のセッション急増を挙げています。最初は監視する項目を絞り、誰がアラートを受けて何を確かめるかを決めてから増やします。

OpenTelemetryのデータが届かない時の確かめ方

まとめ：OpenTelemetryは1台でデータの到着を確かめてから配る

Claude CodeのOpenTelemetryは、1台でclaude_code.session.countが届くことを確かめ、管理設定で配り、属性でチームに分け、送る内容の既定値を確かめてから本番で使います。費用の値は目安なので、請求の正本とは分けて扱います。Claude Code全体の使い方はClaude Codeとはの記事にまとめています。

導入の効果を社内で説明するには、どの指標を誰が見て、どの数字が変われば次の判断をするのかを先に決めておく必要があります。業務での活用の進め方はビジネス活用の記事で紹介しています。組織に合わせた運用づくりは、PLaiのAI社員導入支援でも相談できます。