Claude Code利用額トラッカーを比較

Claude Code の利用額トラッカーが実際に読み取るもの

Claude Code の利用額トラッカーは、3 種類のデータソースのいずれかを読み取ります。どのソースを使うかによって、回答できる質問が決まります。ログパーサーは、ローカルディスク上のセッション記録ファイルを読み取ります。ダッシュボードは、Anthropic がアカウントまたは組織のために保持する利用記録を読み取ります。メトリクスバックエンドは、Claude Code で有効にしたときに出力される OpenTelemetry (OTel) ストリームを読み取ります。3 つすべてが同時に正しくても、結果が一致しないことがあります。数えている対象が異なるためです。

このガイドでは、トークンについて改めて説明しません。Claude Code がトークン使用量を数える方法では、入力、出力、キャッシュへの書き込み、キャッシュからの読み取りを説明しています。この部分を理解しない限り、ダッシュボードの値には大きな意味がありません。ここで扱う質問は、より限定的です。ツールの種類ごとに、何を確認でき、何を決して確認できないのかを説明します。

Claude Code の支出トラッカーが同じ日に3つ登場した理由

同じ日に、Claude Code の支出トラッカーが3つ別々に公開されました。これらは同じツールの3つのバージョンではありません。重要なのはそこです。1つはローカルのセッションファイルを解析します。1つはアカウントの使用量画面をラップします。もう1つは、自分で運用するホスト型のトレースバックエンドです。

3つが同時期に登場したのは、エージェントセッションのコストが分かりにくくなったためです。チャットの費用は、画面上で確認できる内容からおおよそ把握できます。一方、エージェントは20個のファイルを読み、テストスイートを実行し、ターンごとに会話全体を再送します。そのため、請求額は自分が入力していないコンテキストによって決まります。サブスクリプションでは、Claude Code が表示するセッションの金額は推定値です。Anthropic は、この金額は請求には関係しないと説明しています。重要なのは、日によって異なる速さで減少する使用量バーです。この3つのツールは、それぞれこの差の異なる部分を埋めます。

形1: ローカルのログパーサーで当日のコストを確認する

Claude Code は各会話を JSON Lines (JSONL) として ~/.claude/projects/<project>/<session-id>.jsonl に保存します。<project> は作業ディレクトリのパスで、英数字以外の文字は - に置き換えられます。このファイルの各 assistant ターンには、そのリクエストのトークン数が含まれています。ログパーサーはそれらを合計し、料金を計算します。

ccusage は最もよく使われる選択肢です。インストールは不要です。

npx ccusage@latest daily
npx ccusage@latest daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session --json

daily は日付ごとに集計します。--breakdown は各行をモデル別に分けます。これにより、ある週の大半を Opus を使った午後が占めていることなどを確認できます。blocks はサブスクリプションがリセットされる 5 時間単位でまとめます。session は会話ごとに集計し、daily --instances はプロジェクトごとにまとめるため、どのリポジトリのコストが高いかを確認できます。--since と --until を追加すると対象期間を限定できます。使用しているバージョンが想定する日付形式を確認するには npx ccusage@latest daily --help を実行します。2026 年 10 月時点では Codex や OpenCode など、他の agent CLI も読み取れます。これらと比較する場合に役立ちます。

料金はモデルの価格表から取得されます。このツールには 3 つのコストモードがあります。--mode auto は、ファイルに costUSD の値が記録されていればそれを使用し、記録されていなければトークン数から計算します。--mode calculate は常にトークン数から計算し、記録されたコストを無視します。--mode display は記録済みのコストだけを表示し、記録がない行には $0.00 を出力します。合計が正しくないように見える場合は、同じレポートをまず calculate で、次に display で実行します。両者に大きな差がある場合、大半のエントリに記録済みのコストがないことを意味します。そのため、表示されている数値はすべて推定値です。契約料金を利用している場合は、ccusage.json の設定ファイルで defaults の下に pricingOverrides を設定すると、個々のモデルの価格を置き換えられます。

同じデータをプロンプトにも利用できます。ccusage statusline は Claude Code のステータスバー向けに短い行を出力します。通常のステータス行コマンドと同様に、~/.claude/settings.json に組み込めます。設定ブロックと受け取るフィールドについては、Claude Code のステータスラインを構築する を参照してください。

ログパーサーで確認できないのは、このマシン上で発生しなかった処理です。別のノート PC、claude.ai 上のセッション、チームメンバーの作業などのトランスクリプトは、それぞれのディスクに保存されています。古いデータも不足します。cleanupPeriodDays の設定により、トランスクリプトはデフォルトで 30 日後に削除されるためです。アーカイブしていなければ、前四半期のデータは残りません。

もう 1 つのリスクは、構造に関するものです。Anthropic のドキュメントによると、エントリ形式は Claude Code 内部の形式であり、バージョン間で変更されます。そのため、これらのファイルを直接解析するスクリプトは、どのリリースでも壊れる可能性があります。この点は、この形式のすべてのツールに当てはまります。また、JSONL に対する手作りの jq ワンライナーが見た目ほどよい方法ではない理由でもあります。保守されているパーサーは形式の変更に対応しますが、ワンライナーはフィールド名が変更された日に、確信を持って誤った数値を報告します。

最後に、サブスクリプションで表示されるドル金額には注意が必要です。Pro または Max プランの上限内の利用は、トークン単位では請求されません。そのため、この数値はトークンを API の標準料金で利用した場合の金額です。利用量の大きさを測る数値であり、請求額ではありません。例外は usage credits です。これを有効にすると、プラン上限を超えた利用は標準 API 料金で別途請求されます。claude.ai では、その月の利用額を Settings > Usage で確認できます。どのプランを選ぶべきかが本当の疑問であれば、その比較は別の作業になります。API の請求と Claude のサブスクリプションを比較する を参照してください。

形 2: 内蔵の使用量画面で予算を消費したモデルを確認する

Claude Code には独自のレポート機能がありますが、ほとんどの人は開きません。セッション中に /usage を実行します。上部の Session ブロックには、モデル別のトークン数と現在のセッションの金額が表示されます。これは、標準の定価に基づき、トークン数からローカルで計算されます。ただし、管理者が管理対象設定に modelPricing テーブルを設定している場合は、Total cost 行に at your organization's configured rates と表示されます。いずれの場合も、この金額は請求書と異なる可能性がある推定値です。Pro または Max では、使用量がプランに含まれるため、Anthropic は請求上この金額を意味のある指標として扱っていません。/clear で新しい会話を開始すると、合計はリセットされます。

Pro、Max、Team、または seat-based Enterprise プランでは、同じ画面にプラン上限のうちどれだけ使用したかも表示されます。Usage-based Enterprise には使い切る対象の included allowance がありません。すべてのトークンが API 料金で課金されるためです。これらのプランでは、直近の使用量を skills、subagents、plugins、個々の MCP servers 別に、全体に占める割合として表示します。長いコンテキストやキャッシュミスなど、直近の使用量の 10% 以上を占める動作にはフラグが付きます。d または w を押すと、過去 24 時間と過去 7 日間を切り替えられます。これらの数値は概算であり、このマシンのローカルなセッション履歴から計算されるため、2 台目のデバイスの使用量は含まれません。バーが単に少ないのではなく空になっている場合、画面には期間が終了したことだけが表示され、作業を続ける方法は示されません。上限に達した後の対応方法は、モデル、コンテキスト、プランに関する別の判断です。

開発者が 1 人を超えると、数値はアカウント単位になります。API 組織では、Console の使用量ページ、メンバーごとの支出額と accepted lines を表示する Claude Code dashboard、管理者キーで同じ日次のユーザー別指標を返す Claude Code Analytics API を利用できます。Teams および Enterprise プランでは、管理コンソールに支出レポートがあり、CSV export に対応しています。レポートは毎日更新されますが、対象は usage-credit の支出です。seat allowance 内の使用量はドル単位で計測されません。Enterprise には analytics API もあります。どの画面を確認できるかは、各開発者のサインイン方法によって異なります。そのため、混在した組織では 2 つのレポートを確認し、手作業で合算する必要があります。

予算規模を見積もる場合、Anthropic の料金ドキュメントに 2026 年 10 月時点で掲載されている数値は、アクティブな 1 日あたりの開発者 1 人につき平均約 $13、月額で開発者 1 人あたり $150 から $250 です。ユーザーの 90% は、アクティブな 1 日あたり $30 未満です。これはエンタープライズ導入で公表されたベンチマークであり、チームの予測値ではありません。まずパイロットグループで試し、外挿する前に計測します。

ダッシュボードで確認できないのは、日単位および個人単位より細かい情報です。火曜日の大半を Opus が占めていたことは分かります。しかし、どの prompt、どの repository、どの CI job が原因だったかは分かりません。また、組織のレポートは毎日更新されるため、反映にも遅れがあります。そのため、ダッシュボードはレビュー用のツールであり、その日のうちに暴走する agent を検出する手段ではありません。暴走を検出するにはレポートではなく制限が必要です。詳しくは VPS 上で agent のコストを制限する方法を参照してください。

方法 3: 独自の OpenTelemetry スタックで、どのプロンプトが回帰したかを把握する

Claude Code は、1 つの環境変数を設定するだけで OpenTelemetry メトリクスとイベントを出力します。これは、ユーザーごとのトークン数とコストを、ほぼリアルタイムで管理下のシステムへストリーミングできる唯一の方法です。メトリクスには、claude_code.cost.usage（USD 単位）、claude_code.token.usage（トークン単位）、claude_code.session.count、claude_code.active_time.totalが含まれます。

トークンメトリクスが重要なのは、属性を持つためです。各データポイントには type が含まれます。これは input、output、cacheRead、cacheCreation のいずれかです。さらに model と query_source も含まれます。これは main、subagent、auxiliary のいずれかです。また、agent.name、skill.name、mcp_server.name、mcp_tool.nameも含まれます。自分で設定した MCP サーバー名と独自のカスタムサブエージェント名は、OTEL_LOG_TOOL_DETAILS=1を設定しない限り custom として送信されます。OTEL_LOG_TOOL_DETAILS=1を設定すると、ツールイベントに Bash コマンドとツール入力も追加されます。これだけで、どのダッシュボードでも答えられない疑問に対応できます。請求額のうち、自分のターンではなくサブエージェントによる割合はどの程度か、ある MCP サーバーによって入力トークンが 2 倍になったか、誰かが CLAUDE.md を編集した後にキャッシュ読み取りが急減したか、といった疑問です。意外な差が出やすいのは通常キャッシュの動作です。プロンプトキャッシュが元を取る場合では、確認対象を説明しています。

この件については、すべての議論で話題になるため、1 点訂正しておきます。Langfuse はセルフホスト型のトレースバックエンドとして優れており、VPS で実行する方法は エージェントトレース用の Langfuse のセルフホスティングで説明しています。ただし、その OTLP エンドポイントが受け付けるのはトレースだけです。デフォルトでは Claude Code はスパンではなくメトリクスとログイベントをエクスポートするため、OTEL_EXPORTER_OTLP_ENDPOINTを Langfuse に向けてもプロジェクトは空のままで、確認できる有用なエラーも出ません。スパンのエクスポート自体は利用できますが、ベータ版であり、CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1とOTEL_TRACES_EXPORTERを設定するまで無効です。Langfuse 独自の Claude Code 連携は別の方法を取ります。Stop hook、またはそれをインストールするプラグインが、各レスポンス後にセッションのトランスクリプトを読み取り、トレースへ変換します。そのため、ログパーサーと同じくローカルに存在する情報だけが対象です。API を直接使って構築するエージェントでは、独自のコードがプロンプト、モデル、コストを含む各スパンを作成できるため、Langfuse が適しています。Claude Code CLI の支出合計を取得するには、メトリクスストアが適しています。

Claude Code の使用量を自分の VPS で追跡する

2 つのサービスで十分です。メトリクスを受信する collector と、メトリクスを保存する Prometheus です。どちらもパブリックインターネットには公開しないでください。公開された OTLP ポートには、見つけた誰でも書き込めるためです。/opt/ccmetrics/compose.yaml を記述します。

services:
  collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel/config.yaml"]
    volumes:
      - ./collector.yaml:/etc/otel/config.yaml:ro
    ports:
      - "10.8.0.1:4318:4318"
    restart: unless-stopped
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

volumes:
  prom-data:

10.8.0.1 は WireGuard トンネル内でのサーバーのアドレスです。そのため、collector には自分のマシンからだけ接続でき、他からは接続できません。ポートの前に指定するアドレスが重要です。公開された Docker ポートは ufw によってフィルタリングされないためです。詳しくは Docker の公開ポートが ufw を迂回する理由 を参照してください。トンネル自体の設定については、自分の VPS に WireGuard VPN を構築する を参照してください。

/opt/ccmetrics/collector.yaml:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

/opt/ccmetrics/prometheus.yml。Prometheus は Compose ネットワーク上でサービス名を使って collector に接続するため、ポート 8889 はホストに公開されません。

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: claude-code
    static_configs:
      - targets: ["collector:8889"]

cd /opt/ccmetrics
docker compose up -d
docker compose logs collector

collector のログは Everything is ready. Begin running and processing data. で終わるはずです。設定エラーでログが止まる場合、YAML の解析に失敗しています。その場合、コンテナはループして再起動します。

次に、Claude Code から接続します。Claude Code を実行する各マシンで、~/.claude/settings.json に次の内容を追加します。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://10.8.0.1:4318",
    "OTEL_METRIC_EXPORT_INTERVAL": "10000"
  }
}

セッションを開始してプロンプトを 1 つ送信し、エクスポート間隔（ここでは 10 秒、デフォルトは 60 秒）だけ待ちます。その後、Prometheus に取得した内容を問い合わせます。

curl -s http://localhost:9090/api/v1/label/__name__/values | grep -o 'claude_code[a-z_]*'

claude_code_ で始まる名前が複数表示されるはずです。exporter はドットをアンダースコアに置換し、単位を追加します。そのため、正確な文字列は collector のバージョンによって異なります。結果が空の場合、何も到着していません。プロトコルとポートが一致しているか確認してください。http/protobuf は 4318 に接続し、grpc は 4317 に接続するため、不一致があっても静かに失敗します。claude --debug-file /tmp/claude-debug.log を実行し、そのファイルで [3P telemetry] の行を探します。ここに Claude Code の OTel エクスポートエラーが記録されます。

1 台のマシンだけでサーバーを使わない場合は、ここまでの設定をすべて省略できます。OTEL_METRICS_EXPORTER=prometheus を設定すると、Claude Code 自体が http://localhost:9464/metrics に scrape エンドポイントを公開します。prometheus だけが exporter の一覧にある場合、Claude Code はエクスポートするメトリクスから USD、tokens、s の単位を省略します。これにより、scrape の内容は有効な Prometheus テキスト形式になります。メトリクス名は変わりません。otlp,prometheus のように複数の exporter を組み合わせる設定では、単位が保持されます。

この構成には、プライバシーに関する判断が 1 つあります。デフォルトでは、マシン外へ送信されるのはカウントとメタデータだけです。プロンプト本文とツール出力は送信されません。OTEL_LOG_USER_PROMPTS=1 を指定するとエクスポートされるイベントにプロンプト本文が追加され、OTEL_LOG_TOOL_CONTENT=1 を指定すると trace span にツール出力が追加されます。いずれかをエクスポートすると、テレメトリ用のサーバーにソースコードや、コンテキストに含まれていたその他の情報が保存されます。これらは意図的に有効化し、先に エージェントのコンテキストに秘密情報を入れない方法 を読んでください。

スクリプト実行と CI 実行のコストを追跡する

非対話的な実行では画面を監視する人がいないため、想定外のコストが発生しやすくなります。claude -p に --output-format json を指定すると、その実行のコストが結果ペイロードに含まれます。

claude -p "summarise the failing tests" --output-format json | jq '.total_cost_usd'

ペイロードには total_cost_usd とモデル別の内訳が含まれるため、CI ジョブはダッシュボードを使わずに自身のコストを記録できます。ローカルで取得する他の値と同様に、これはクライアント側の推定値です。また、--continue または --resume で会話を継続する実行では、以前の実行分を含む会話全体の合計が報告されます。値をファイルに追記するか、上記のコレクターへメトリクスとして送信します。これは実用的なコスト追跡として最も低コストな方法であり、実行ごとに jq の呼び出しが 1 回必要です。

障害の種類と確認できる内容

レポートが空です。 npx ccusage@latest daily が行を出力しない場合、Claude Code が書き込む場所を読み取れていません。CLAUDE_CONFIG_DIR によって保存先が変更されるため、パーサーにもその場所を指定する必要があります。行は存在するものの約 1 か月前で止まっている場合は、cleanupPeriodDays が設計どおりに動作しています。デフォルトでは、トランスクリプトは 30 日後に削除されます。

2 台のマシンで合計値が異なります。 これは想定される動作であり、バグではありません。/usage の内訳とログパーサーは、どちらもローカルのセッション履歴だけを読み取ります。そのため、別のデバイスや claude.ai での使用量は、どちらにも含まれません。

ローカルの合計値が請求書と一致しません。 ローカルの数値は、契約料金を設定しない限り、標準の定価に基づいてトークン数から計算されます。契約料金は、/usage の管理設定にある modelPricing テーブル、または ccusage の pricingOverrides で設定します。サブスクリプションでは、プランの上限内の使用量にトークン単位の料金は発生せず、使用量クレジットだけが課金対象です。API の請求については、Console の使用量ページが正しい基準です。

同じ作業をしているのにコストが増えました。 まず、キャッシュの列を確認してください。長いセッションでは、ターンごとに履歴全体を再送信します。キャッシュが有効な間はキャッシュ料金が適用され、キャッシュが切れると入力全体の料金が適用されます。そのため、長い中断が 1 回あると、会話全体が再処理されます。これは、出力の数値が小さい一方で入力の数値が大きい状態として現れます。入力と出力のトークン料金では、両者が独立して変動する理由を説明しています。

サブエージェントを使った日の数値が現実とは思えません。 各サブエージェントは独自のコンテキストウィンドウで動作します。そのため、トークン使用量は、実行したサブエージェントの数と、それぞれの実行時間に応じて増えます。プランでは、/usage の帰属情報に、このマシンにおけるサブエージェント分の割合が表示されます。リクエスト単位の詳細は、OTel データで claude_code.token.usage 上の query_source 属性を使って分離できます。ログパーサーでは合計値しか確認できず、内訳は推測することになります。

FAQ

ccusage では Max プランで実際に請求される金額を確認できますか？

いいえ。サブスクリプションのプラン上限内の使用量は、トークン単位では請求されません。そのため、ログパーサーはトークンを API の標準公開料金で換算し、同じ処理を API 経由で実行した場合の費用を表示します。1 日の使用量がどれほど多かったかを相対的に把握する指標として有用です。また、プロジェクトやモデル同士の比較にも利用できます。実際の請求額を確認するには、API の請求については Console の使用量ページを、サブスクリプションについてはプランの請求ページを確認してください。使用量クレジットを有効にしている場合、上限を超えた使用量には API の標準料金が適用され、claude.ai の Settings > Usage にその費用が表示されます。

Claude Code は、これらのツールが読み取るセッションファイルをどこに保存しますか？

~/.claude/projects/<project>/<session-id>.jsonl に保存します。<project> は、英数字以外の文字を - に置き換えた作業ディレクトリのパスです。各行は、1 件のメッセージ、ツール使用、またはメタデータエントリを表す JSON オブジェクトです。CLAUDE_CONFIG_DIR でディレクトリ全体を移動できます。また、settings.json 内の cleanupPeriodDays で 30 日間の保持期間を制御します。Anthropic はエントリ形式を内部仕様として文書化しており、バージョン間で変更される可能性があります。そのため、自作スクリプトではなく、保守されているツールで解析してください。

Claude Code のテレメトリを Langfuse に送信できますか？

デフォルトのテレメトリでは送信できません。Langfuse の OTLP エンドポイントはトレースを受け付けます。一方、Claude Code はデフォルトではスパンではなくメトリクスとログイベントをエクスポートするため、データの送信先がありません。スパンのエクスポートはベータ機能であり、有効化が必要です。Langfuse 自身の Claude Code 連携では、代わりに Stop hook を使用してセッションのトランスクリプトをトレースに変換します。費用の合計を確認するには、Claude Code のメトリクスを OpenTelemetry collector に送信し、Prometheus に保存してください。API 上で自分で構築したエージェントでは、プロンプト、モデル、費用を含むスパンをコードから出力できるため、Langfuse を使用してください。

ローカルの数値が Console の使用量ページと一致しないのはなぜですか？

計算方法が異なるためです。/usage とログパーサーは、現在使用しているマシンのセッションファイルからトークン数を集計します。その後、契約料金が設定されていない限り、標準公開料金で換算します。管理対象設定では modelPricing を介して /usage に、ccusage では pricingOverrides に適用されます。Console には、割引適用後に組織が実際に請求された金額が、すべてのマシンとキーを対象に表示されます。不一致は通常のことです。差が非常に大きい場合は、別のデバイス、CI runner、または同じアカウントに請求している別のチームメンバーが原因であることが多いです。

CI で claude -p の実行コストを追跡するにはどうすればよいですか？

--output-format json を指定して実行し、結果から total_cost_usd を読み取ります。たとえば claude -p "..." --output-format json | jq '.total_cost_usd' を使用します。同じペイロードには、モデル別の内訳とセッション ID も含まれます。ジョブごとにこの値を記録すれば、エージェント、ダッシュボード、追加サービスなしでパイプラインごとの費用を把握できます。