公開2026.08.26更新2026.09.30 Claude

Claude CodeのOpenTelemetry設定｜利用状況とコストを組織で可視化する実装

Q: 設定したのに何も届きません。どこから調べればよいですか？

まずエクスポータの指定を console に変えて端末へ吐かせ、Claude Code側が出力しているかを切り分けてください。ここで出るなら経路の問題で、ホスト名とポート番号とプロトコルを確認します。gRPCなら4317、HTTPなら4318で、片方だけ開いている構成は珍しくありません。端末側でも出ないなら、変数が届いていないか管理設定に取り除かれています。

Q: MCPサーバごとの費用は分かりますか？

api_request の属性に mcp_server.name と mcp_tool.name が含まれるため、イベント側の集計であれば切り分けられます。ただしメトリクスの標準属性ではないので、メトリクスの画面には出てきません。継続的に見るなら、Collector側で集計値を作るかログ基盤のクエリで集計する形です。

Claude CodeのOpenTelemetry設定｜利用状況とコストを組織で可視化する実装

全社にClaude Codeを配ったあと、最初に困るのは請求書です。総額は分かるのに、どの部署がどれだけ使い、費用がどのモデルに寄っているかが読めません。増席か、使われていない席の回収か。判断する材料が管理画面の外にしかない状態になります。

この記事は、Claude Code自身が持つOpenTelemetryの出力を組織の可視化基盤へ流すまでを、実装の手順として扱います。有効化する環境変数、出力されるメトリクスとイベントログの中身、Collectorを挟む構成、部門別の費用を出す属性設計、既定で伏せられるデータの範囲、全社へ強制配布する方法までを順に置きました。製品そのものの機能と料金はClaude Codeとは？できること・使い方・料金とコード解析の実力【2026年版】に譲ります。数値の前提は2.1系（2026年8月時点）です。

まとめ：Claude Codeのテレメトリ導入で先に決める5点

結論を5点で先に置きます。第一に、追加のラッパーやサイドカーは要りません。Claude CodeはOTLPを自分で話すため、CLAUDE_CODE_ENABLE_TELEMETRYを1にして送信先を指定すれば、メトリクス8種とイベントログが流れます。

第二に、出てくるのはメトリクスとイベントログの二系統です。トレースはベータ扱いの出力にとどまるため、分散トレースの画面を前提に設計すると期待と実装がずれます。

第三に、本文は既定で伏せられます。プロンプトも応答もツール引数も伏せ字に置き換わり、明示的に環境変数を1にしたときだけ実データが出ます。初期導入は、社内規程の確認を待たずに進められる範囲です。

第四に、部門別の費用を出すかどうかで属性設計が変わります。誰がという情報は既定の属性で足りますが、どの部署かは自分で足す必要があり、足し方で時系列の本数が跳ねます。

第五に、全社へ効かせるにはmanaged settingsを使います。開発者ごとの設定に任せると集計対象に穴が空くのが理由です。送信先を管理側で固定すれば、開発者が設定した変数は起動時に取り除かれます。以下、順に根拠を見ていきます。

Claude Codeが出すテレメトリの中身｜メトリクス8種とイベントログ

何が取れるのかを先に確定させます。規格そのものの構造はOpenTelemetry（OTel）とは｜3つのシグナル・OTLP・Collector・Prometheusとの違いを解説で扱うため、ここではClaude Codeが吐く名前だけを並べました。

Claude Codeが出すメトリクス8種類｜費用と稼働時間が土台になる

メトリクスはいずれもclaude_code.という接頭辞が付きます。表では接頭辞を省きました。

メトリクス名	単位	取れる内容
session.count	件	開始されたセッション数
token.usage	トークン	消費したトークン数
cost.usage	USD	セッションの費用
lines_of_code.count	行	変更されたコード行数
commit.count	件	作成されたコミット数
pull_request.count	件	作成されたプルリク数
code_edit_tool.decision	件	編集許可の判断回数
active_time.total	秒	実際に動いていた時間

投資判断に直結するのはcost.usageとactive_time.totalの組です。費用だけなら高く見える部署も、稼働時間で割ると単価は平均だった、と読み替えられます。lines_of_code.countの単体利用は、行数が容易に増減するため避けてください。

イベントログは一連の動きをprompt.idで串刺しにできる

メトリクスが数の集計なのに対し、イベントログは一件ずつの記録です。主なものはuser_prompt、assistant_response、tool_result、api_request、api_error、tool_decision、mcp_server_connectionになります。

費用分析でいちばん使うのはapi_requestです。属性にmodel、cost_usd、input_tokens、output_tokens、cache_read_tokens、cache_creation_tokensを持つため、キャッシュがどれだけ費用を抑えたかまで数字で出せます。agent.name、skill.name、mcp_server.nameも付き、費用を食っているスキルも切り分けられます。

これらのイベントにはprompt.idが付き、ひとつの指示から派生した一連のイベントを後から串刺しにできます。ダッシュボードでは、この列を検索の軸に据えると調査が短く済みます。

トレースはベータ扱い｜分散トレースの画面を前提に設計しないこと

三つのシグナルのうち、Claude Codeが安定して出すのはメトリクスとログです。トレース用の出力指定はベータの位置づけにとどまります。見慣れたウォーターフォールの画面を前提に設計すると後段が空振りするため、まずは二系統で組み、トレースは正式化してから足すのが安全です。

テレメトリを有効にする環境変数とOTLPの送信先を指定する手順

設定はすべて環境変数で入ります。個人の検証なら.zshrc相当、プロジェクト単位なら設定ファイルのenvキー、組織配布ならmanaged settingsと置き場所が変わります。

最小構成は三点だけ｜有効化と送信先とプロトコルを環境変数で書く

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://collector.example.internal:4317
export OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer 発行したトークン

エクスポータの指定は取りうる値が決まっています。メトリクス側はotlp、prometheus、console、none、ログ側はotlp、console、noneで、カンマ区切りの併記もできます。手元で確かめるだけならconsoleにして端末へ吐かせるのが早いです。

プロトコルはgrpcとhttp/jsonとhttp/protobufから選びます。社内の経路にgRPCを通せない事情があるならHTTP側を選び、その場合はポートが4318になる点に注意してください。

シグナルごとに送信先を分けるときの上書き規則とパスの書き方の注意

メトリクスとログを別々の基盤へ送るなら、シグナル別の変数で上書きします。OTEL_EXPORTER_OTLP_METRICS_ENDPOINTとOTEL_EXPORTER_OTLP_LOGS_ENDPOINTがあり、プロトコルと認証ヘッダにも同じ形の変数が並びます。シグナル別のパスは末尾まで書く必要があり、v1/metricsやv1/logsで終わる形です。

送出間隔と集計方式の既定値｜検証のあいだだけ短く詰めてから戻す

メトリクスの送出間隔は既定で60000ミリ秒、ログは5000ミリ秒です。検証中に一分待つのは長いため、動作確認のあいだだけ短くし、終わったら既定へ戻してください。短いまま全社へ配ると、収集側の書き込み回数が増えます。

もう一点、メトリクスの集計方式は既定がデルタです。累積を前提にしたダッシュボードの計算式をそのまま持ち込むと数字が合わないため、OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCEで切り替えるか、クエリ側を合わせます。

Collectorを挟む構成とGrafana・Datadogへ送るときの分岐

次に決めるのは、端末からバックエンドへ直接送るか、あいだにCollectorを置くかです。

直送とCollector経由の分かれ目は認証情報の配布で決まる

直送は構成が短く、検証段階では有効です。ただし全社展開ではバックエンドの認証情報を全端末へ配ることになります。端末に置いた値は取り出せると考えるべきです。

社内網にCollectorを一段置けば、端末側は社内の受け口へ送り、外部への認証情報はCollectorだけが持ちます。属性の追加や削除も一箇所で変えられます。台数が二桁を超えるなら、この一段を先に用意したほうが楽です。

Collector設定の骨格｜受け口と加工と送り先の三段で書く

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
processors:
  batch:
    timeout: 10s
  attributes/dept:
    actions:
      - key: dept.code
        value: platform
        action: upsert
exporters:
  otlphttp/backend:
    endpoint: https://otlp.example.com
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [attributes/dept, batch]
      exporters: [otlphttp/backend]

受け口を二つ開けたのは、端末ごとにgRPCとHTTPが混在しても受けるためです。加工段の部署コードは次章で扱います。標準の配布物に含まれない受信器や送信器が要る場面もあり、その判断はOpenTelemetry Collector Contribとは｜coreとの違いとocbで作る自作distroで整理しました。

受け口の違いでGrafana系とDatadogは手当てが変わる

OTLPは規格として共通ですが、バックエンド側の受け方は同じではありません。Grafana系はメトリクスとログを別の保管先へ置くため、パイプラインもシグナルごとに分けて書きます。具体的な組み方はGrafana OpenTelemetry連携の構成｜OTLP受信から3シグナル統合までにまとめました。

Datadogは、OTLPで受ける経路のほかに独自の配布物を使う経路があり、選択で属性の見え方が変わります。基準はDatadog OpenTelemetry連携の4方式｜OTLP送信とDDOTの選び分けで扱いました。どちらでもClaude Code側は送信先の指定が変わるだけです。

トークン使用量とコストを部門別に集計するための指標と属性の設計

数値そのものは自動で出ますが、部署や案件で切る軸は自分で設計しなければなりません。

標準属性の顔ぶれと既定値｜どこまでが指定なしで自動的に付くのか

メトリクスとイベントには、指定なしでも一定の属性が付きます。制御用の環境変数はOTEL_METRICS_INCLUDE_に続く語で決まるため、表では接尾辞だけを示しました。

接尾辞	付く属性	既定値
SESSION_ID	session.id	true
ACCOUNT_UUID	user.account_uuid	true
RESOURCE_ATTRIBUTES	資源属性のキー	true
VERSION	app.version	false
ENTRYPOINT	app.entrypoint	false

これに加えてorganization.id、user.id、user.email、terminal.typeが付きます。誰がという軸は最初から取れており、個人単位の集計は追加設定なしで成立します。逆に部署や案件は、Claude Codeが知らない情報なので自動では付きません。

部署コードを足す入れ方は端末側と収集側のどちらかを選んで決める

ひとつは端末側でOTEL_RESOURCE_ATTRIBUTESに部署コードを書く方法です。資源属性のキーはメトリクスの属性にも既定で載るため、書けばそのまま集計軸になります。配布物で部署ごとに値を変えられるなら、この方法が短く済みます。

もうひとつは、前章のCollector設定のように収集側で足す方法です。端末を触らずに変更でき、組織改編で部署コードが変わっても一行で追随できます。ただし送信元と部署の対応表を収集側が持つ前提が要ります。人事異動の多い組織では、収集側で足すほうが運用は続きやすいです。

時系列の本数はメトリクスとログで役割を分けることによって抑える

ここで効いてくるのがsession.idとuser.account_uuidが既定で有効という点です。両方が付いたメトリクスは、利用者数とセッション数の積に近い本数の時系列を作ります。開発者百人が一日五セッション動かせば、単純計算で日に五百通りの組み合わせが増え続けます。

費用の集計に要るのは部署別と利用者別の合計で、セッション単位の内訳ではありません。であればOTEL_METRICS_INCLUDE_SESSION_IDを無効にして粒度を落とし、セッション単位の追跡はログ側で行う切り分けが成立します。ログは属性の種類が多くても時系列のような費用の増え方をしません。粒度の一般論はOpenTelemetryのメトリクス実装｜計器選定とカーディナリティ設計で扱っています。

送出データの範囲と既定の伏せ字｜本文のログを開ける前の判断基準

社内規程との調整でいちばん聞かれるのは、コードやプロンプトの中身が外へ出るのかという点です。既定値を正確に把握しておくと話が早く進みます。

既定で出ないもの｜プロンプトも応答も本文はすべて伏せ字に変わる

プロンプト本文は伏せ字に置き換わり、長さだけが記録されます
応答本文も同様で、モデル名と要求IDと長さだけが残ります
ツールの引数やファイル名は記録されず、ツール名と成否と所要時間だけが出ます
ツールの入出力そのものは記録されません
APIの生の要求本文と応答本文は送られません
エラーの本文は分類やコードに切り詰められ、全文は含まれません

出るのは、トークン数、費用、セッション数、変更行数、コミット数、ツール判断の回数といった数値と、イベントの種別や状態コードや所要時間です。この範囲なら、コード資産そのものが外部へ出るという説明にはあたりません。稟議の初期は、既定のまま数値だけを取るのが通しやすいです。

本文のログを開けたときに増える保存量と責任を開ける前に見積もる

監査や品質分析のために本文が要る場面はあります。その場合に開けるのはOTEL_LOG_USER_PROMPTS、OTEL_LOG_ASSISTANT_RESPONSES、OTEL_LOG_TOOL_DETAILSの三つです。生のAPI本文を落とす指定もあり、ディレクトリを指定して端末のディスクへ書き出す形も選べます。

開けると変わるのは二点です。まず保存量。一件の本文はCLAUDE_CODE_OTEL_CONTENT_MAX_LENGTHで切り詰められ、既定は61440になります。UTF-16の単位でおよそ60キロバイト相当が上限のため、全社で開けると保管費用の桁が変わります。次に責任です。伏せ字が外れたログは、個人の入力とソースコードの断片を含む記録になります。保管期間と閲覧権限を決めないまま開けるのは避けてください。まず数値、次に特定チームだけ本文という順で広げます。

子プロセスにはOTELで始まる環境変数が渡らないという分離の仕様

見落としやすい挙動を一点。Claude Codeは、自分が起動する子プロセスへOTELで始まる環境変数を引き継ぎません。シェル実行、フック、MCPサーバ、言語サーバのいずれも対象です。子プロセス側でも送るなら、そのコマンドの中で変数を直接与えます。この分離のおかげで、開発中のアプリのテレメトリと利用状況が混ざらずに済みます。

managed settingsで全社に配布し開発者の上書きを封じる方法

個人の設定に任せると、有効にした人の分しか集まりません。母数が分からない集計はコスト判断に使えないため、配布の仕組みごと決めます。

配置場所と書式｜三つのOSで置き場所となるパスがそれぞれ変わる

管理者が置くファイルはmanaged-settings.jsonで、設定ファイルと同じ形です。テレメトリの変数は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.internal:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer 発行したトークン"
  }
}

置き場所はmacOSがApplication Support配下のClaudeCodeディレクトリ、LinuxとWSLが/etc/claude-code/、WindowsがProgram Files配下の同名ディレクトリです。配る手段は問われないため、端末管理の仕組みがあるならそこへ載せます。macOSの構成プロファイルやWindowsのレジストリを使う経路もあり、そちらが優先されます。

送信先を管理側で書くと開発者が設定した変数は起動時に排除される

ここが実装上の要点です。管理側で送信先に関する変数を書くと、起動時に開発者の競合する変数が取り除かれます。全体の送信先を書けばシグナル別送信先は消え、プロトコルも同じ扱いです。認証ヘッダや証明書を書いた場合はさらに強く、開発者が設定した送信先の変数がすべて消えます。組織のトークンが意図しない収集先へ届くのを防ぐための挙動です。

この排除は2.1系の途中から入った仕組みで、それ以前は変数ごとの優先順位で解決されていました。エクスポータの指定まで固定するなら、2.1系のなかでも新しめのバージョンが要ります。配布前に、端末群が満たすべきバージョンの下限を決めておいてください。

効いているかどうかは二つのコマンドで出どころから切り分けて確認する

配布したのに集まらない、という報告への切り分けは二段です。まず端末で状態を表示するコマンドを実行し、設定の出どころを示す行に管理設定が出るかを見ます。表示がなければファイルの場所か形式の問題で、別の名前が出ていれば優先順位の高い経路が先に効いています。

次にclaude doctorを実行します。書式の誤りで落とされた項目が、出どころと項目名つきで並びます。管理設定は誤りのある項目だけを落として残りを適用するため、一部の変数だけが効かない状態も起こりえるということです。二つを順に見れば、配布側か端末側かはその場で分かります。

Claude Codeのテレメトリ導入を進める条件と見送る場面の線引き

進めてよい三つの条件｜どれか一つでも当てはまるなら着手してよい

第一に、席数の増減を数字で決めたい場合です。稼働時間と費用の両方が取れるため、使われていない席の回収と増席の判断が同じ画面でできます。投資の継続を通す材料として最も直接的に効きます。

第二に、既にOTLPを受けられる監視基盤がある場合です。追加で作るのは受け口の一本とダッシュボードだけで、可視化までは数日の作業に収まります。基盤がなくても、Collectorを一台立てて既定の数値だけを流す構成なら短期間で形になります。

第三に、費用の内訳を案件別に説明する義務がある場合です。受託開発では、AI支援の費用を案件原価へ配賦する必要が出てきます。部署コードの代わりに案件コードを資源属性へ載せれば、原価計算に耐える実績が取れるという理屈です。相談は生成AI開発・AI受託開発で受けています。

見送ってよい場面｜規模と目的が釣り合わないうちは待ってもよい

利用者が数名にとどまる段階では、見送って構いません。管理画面で費用の総額が読めるうえ、誰が使っているかも把握できています。この規模では、運用の手間が得られる情報を上回ります。

開発者個人の生産性を評価する目的だけで導入するのも勧めません。変更行数もセッション数も、測られていると分かった時点で動きが変わる数値です。目的は費用配分と席数判断に置くと最初に明言したほうが、結果として質の良いデータが集まります。

本文ログを最初から全社で開けるのも見送りです。保管の設計が追いつかないまま個人の入力とコードの断片を溜め始めると、後から止めるほうが難しくなります。数値から始めて、必要が生じた部門だけ広げてください。

よくある質問

APIキー利用でも定額契約でもテレメトリは出ますか？

いずれの契約形態でも環境変数の指定は共通で、有効にすればメトリクスとイベントログが流れます。ただし費用の読み方は変わります。従量課金ならcost.usageは請求額の推計として使えますが、定額では実際の請求と一致しません。定額ならトークン数と稼働時間を主指標に据えてください。

定額と従量のどちらで契約するか自体を決めたい場合は、公式の平均コストを使った損益分岐と、--max-budget-usdで1回ごとに上限を掛ける設定をClaude Codeの料金プラン比較｜Pro・Max・Team・APIの損益分岐と支出上限にまとめています。

設定したのに何も届きません。どこから調べればよいですか？

まずエクスポータの指定をconsoleに変えて端末へ吐かせ、Claude Code側が出力しているかを切り分けてください。ここで出るなら経路の問題で、ホスト名とポート番号とプロトコルを確認します。gRPCなら4317、HTTPなら4318で、片方だけ開いている構成は珍しくありません。端末側でも出ないなら、変数が届いていないか管理設定に取り除かれています。

ダッシュボードは何から作るのがよいですか？

最初の一枚は、部署別の費用と稼働時間を並べた表で十分です。次に週次の推移、そのあとにモデル別の内訳と足すと、見られない画面を作らずに済みます。api_errorの発生率とmcp_server_connectionの失敗は運用向けの一枚に分けてください。

MCPサーバごとの費用は分かりますか？

api_requestの属性にmcp_server.nameとmcp_tool.nameが含まれるため、イベント側の集計であれば切り分けられます。ただしメトリクスの標準属性ではないので、メトリクスの画面には出てきません。継続的に見るなら、Collector側で集計値を作るかログ基盤のクエリで集計する形です。