ガイド

著者 Matt Connor 2026-08-05 ・更新日 2026-08-07

Claude Codeの支出トラッカー3種を比較

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

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

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

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

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

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

Claude Codeの支出トラッカーは、ローカルログ、組み込みの使用量画面、OpenTelemetryで見える範囲が異なります。目的別に違いを比較します。

Claude Code の支出トラッカーが実際に読み取るもの

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

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

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

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

これらが同時期に登場したのは、エージェントセッションのコストが分かりにくくなったためです。チャットの費用は、画面上で確認できる内容とおおむね一致します。一方、エージェントは20個のファイルを読み、テストスイートを実行し、ターンごとに会話全体を再送信します。そのため、請求額は自分が入力していないコンテキストによって決まります。サブスクリプションでは、ドル単位の金額は表示されません。日によって速さが異なる使用量バーが減っていくだけです。3つのツールはそれぞれ、この不足を異なる方法で補います。

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

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

ccusage が最も多く使われています。インストールは不要です。

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

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

料金はモデル価格テーブルから取得されます。このツールには 3 つのコストモードがあります。--mode auto は、ファイルに costUSD の値が記録されていればそれを使用し、記録されていなければトークン数から計算します。--mode calculate は常にトークン数から計算し、記録済みのコストを無視します。--mode display は記録済みのコストだけを表示し、記録がない行には $0.00 を出力します。合計値が正しくないように見える場合は、同じレポートをまず calculate で実行し、次に display で実行します。両者に大きな差がある場合、記録済みのコストがない項目が大半を占めています。そのため、表示されている値は推定値です。

同じデータをプロンプトに渡すこともできます。ccusage statusline は Claude Code のステータスバー用の簡潔な行を出力します。~/.claude/settings.json に組み込めば、他のステータス行コマンドと同じように使用できます。設定ブロックと受け取れるフィールドについては、Claude Code の statusline を構築するを参照してください。

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

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

最後に、サブスクリプション利用時に表示される金額には注意が必要です。Pro または Max ではトークン単位の課金はないため、その数値は API の定価で計算した場合のトークン料金です。利用量の大きさを示す値であり、実際の請求額ではありません。本当に知りたいことがどのプランを選ぶべきかであれば、その比較は別途検討する必要があります。API の課金と Claude サブスクリプションの比較を参照してください。

手順 2: 組み込みの使用状況画面で、どのモデルが予算を消費したかを確認する

Claude Code には独自のレポート機能がありますが、ほとんどの人は開きません。セッション中に /usage を実行します。画面上部の Session ブロックには、モデル別のトークン数と現在のセッションの金額が表示されます。この金額は、トークン数と標準の定価を使ってローカルで計算されます。割引やプロモーション価格は反映されないため、請求書の金額と異なる場合があります。/clear で新しい会話を開始すると、合計はリセットされます。

Pro、Max、Team、Enterprise のいずれかのプランでは、同じ画面にプラン上限の使用量も表示されます。さらに、最近の使用量を合計に対する割合として、skills、subagents、plugins、個々の MCP servers に割り当てて表示します。long context や cache misses など、最近の使用量の 10% 以上を占める動作にはフラグが付けられます。d または w を押すと、過去 24 時間と過去 7 日間を切り替えられます。これらの数値は概算であり、このマシンのローカルなセッション履歴から計算されるため、別のデバイスでの使用量は含まれません。

開発者が 1 人を超えると、数値はアカウント単位で確認することになります。API organization では、Console usage ページ、メンバーごとの支出額と accepted lines を表示する Claude Code dashboard、管理者キーで同じ日次のユーザー別メトリクスを返す Claude Code Analytics API を利用できます。Team と Enterprise のプランでは、管理コンソールに CSV エクスポート対応の支出レポートが表示され、毎日更新されます。Enterprise では analytics API も利用できます。表示される内容は、各開発者のサインイン方法によって異なります。そのため、混在した organization では 2 つのレポートを確認し、手作業で合算する必要があります。

予算規模を見積もる場合、2026 年 8 月時点で Anthropic のコスト関連ドキュメントに掲載されている数値は、アクティブな 1 日あたりの開発者 1 人の平均が約 $13、1 か月あたりが $150 から $250 で、ユーザーの 90% はアクティブな 1 日あたり $30 未満です。これは enterprise deployments に基づく公開ベンチマークであり、チームの予測値ではありません。まず pilot group を実施して測定してから、全体に外挿してください。

dashboard で確認できないのは、日単位と個人単位より細かい情報です。火曜日の大部分を Opus が占めていたことは分かります。しかし、どの prompt、どの repository、どの CI job が原因だったかは分かりません。また、organization のレポートは毎日更新されるため、情報にも遅れがあります。したがって、dashboard はレビュー用のツールであり、その日の午後に runaway agent を検出する手段ではありません。runaway agent の検出にはレポートではなく制限が必要です。その方法については VPS 上で agent のコストを制限するで説明します。

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

Claude Code は、1 つの環境変数を設定するだけで OpenTelemetry のメトリクスとイベントを出力します。これは、ユーザーごとのトークン数とコストを、ほぼリアルタイムで管理下のシステムへストリーミングできる唯一の方法です。メトリクスには、USD 単位の claude_code.cost.usage、トークン数の 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 も含まれます。これだけで、ダッシュボードでは答えられない疑問を調べられます。請求額のうち、自分のターンではなくサブエージェントが占める割合はどの程度か。1 つの MCP サーバーによって入力トークンが 2 倍になっていないか。誰かが CLAUDE.md を編集した後、キャッシュ読み取りが急減していないか。意外な差が出やすいのは通常、キャッシュの動作です。プロンプトキャッシュが費用に見合う条件では、確認すべき内容を説明しています。

この点は、関連する議論で毎回出てくるため、訂正しておく価値があります。Langfuse はセルフホスト可能な優れたトレーシングバックエンドであり、VPS での運用方法はエージェントトレーシング向けの Langfuse のセルフホスティングで説明しています。ただし、その OTLP エンドポイントが受け付けるのはトレースだけです。Claude Code がエクスポートするのはメトリクスとログイベントであり、スパンではありません。そのため、OTEL_EXPORTER_OTLP_ENDPOINT を Langfuse に向けてもプロジェクトは空のままで、確認する価値のあるエラーも表示されません。Langfuse は、API を直接使って構築するエージェントに適したツールです。その場合は、プロンプト、モデル、コストを含む各スパンを独自のコードで作成できます。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 を実行すると、デバッグログに OTel のエクスポートエラーが出力されます。

1 台のマシンだけでサーバーを使わない場合は、ここまでの設定をすべて省略できます。OTEL_METRICS_EXPORTER=prometheus を設定すると、Claude Code 自体が http://localhost:9464/metrics に scrape エンドポイントを公開します。prometheus だけを exporter として指定した場合、Claude Code はメトリクス名から USD、tokens、s の単位を省略します。これにより、scrape の結果が有効な Prometheus テキスト形式になります。

この構成には、プライバシーに関する判断が 1 つあります。デフォルトでは、マシンの外部に送信されるのはカウントだけです。プロンプト本文やツール出力は送信されません。OTEL_LOG_USER_PROMPTS=1 と OTEL_LOG_TOOL_CONTENT=1 を設定すると、メトリクスを保存するサーバーにソースコードなど、コンテキストに含まれていた情報が保存されます。これらは意図して有効にし、先にエージェントのコンテキストから秘密情報を除外するを読んでください。

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

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

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

このペイロードには total_cost_usd とモデル別の内訳が含まれるため、CI ジョブはダッシュボードを使わずに自身のコストを記録できます。値をファイルに追記するか、前述のコレクターへメトリクスとして送信します。これは実用的なコスト追跡として最も安価な方法であり、1 回の実行につき jq の呼び出しが 1 回必要です。

障害時の動作と確認できる内容

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

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

ローカルの合計値が請求額と一致しません。 ローカルの値は、標準の定価に基づいてトークン数から計算されます。プロモーション価格や契約上の割引は反映されません。また、サブスクリプションではトークン単位で請求されるわけではありません。API の請求については、Console の使用量ページが正式な情報源です。

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

サブエージェントを使った日の使用量が現実的でないように見えます。 各サブエージェントは独自のコンテキストウィンドウで動作します。そのため、トークン使用量は実行した数と、それぞれの実行時間に応じて増加します。これらを分離できるのは OTel データだけです。claude_code.token.usage の query_source 属性を使用します。ログパーサーでは合計値しか確認できず、内訳は推測するしかありません。

FAQ

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

いいえ。サブスクリプションではトークン単位で請求されません。そのため、ログパーサーはトークンを API の標準公開料金で計算し、同じ処理を API 経由で実行した場合の費用を表示します。これは、その日の処理量を相対的に把握する指標として有用です。プロジェクト間やモデル間の比較にも使えます。実際の請求額を確認する場合は、API の請求については Console の使用量ページ、サブスクリプションの請求についてはプランの請求ページを確認します。

これらのツールが読み取るセッションファイルは 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 はスパンではなくメトリクスとログイベントをエクスポートするため、データの送信先がありません。Claude Code のメトリクスを OpenTelemetry collector に送信し、Prometheus に保存してください。API 上で自分で構築したエージェントには Langfuse を使用します。自分のコードから、プロンプト、モデル、コストを含むスパンを出力できるためです。

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

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

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

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

#claude-code #tokens #cost-control #observability#opentelemetry