著者 Claude Code利用額トラッカーを比較
Claude Codeの利用額トラッカーは、ローカルログ、組み込みの利用状況画面、OpenTelemetryで確認できる内容が異なります。3種類の違いと使い分けを比較します。
Claude Code の利用額トラッカーが実際に読み取るもの
Claude Code の利用額トラッカーは、3 種類のデータソースのいずれかを読み取ります。どのソースを使うかによって、回答できる質問が決まります。ログパーサーは、ローカルディスク上のセッション記録ファイルを読み取ります。ダッシュボードは、Anthropic がアカウントまたは組織のために保持する利用記録を読み取ります。メトリクスバックエンドは、Claude Code で有効にしたときに出力される OpenTelemetry (OTel) ストリームを読み取ります。3 つすべてが同時に正しくても、結果が一致しないことがあります。数えている対象が異なるためです。
このガイドでは、トークンについて改めて説明しません。Claude Code がトークン使用量を数える方法では、入力、出力、キャッシュへの書き込み、キャッシュからの読み取りを説明しています。この部分を理解しない限り、ダッシュボードの値には大きな意味がありません。ここで扱う質問は、より限定的です。ツールの種類ごとに、何を確認でき、何を決して確認できないのかを説明します。
1 日に 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 --jsondaily は日付ごとに集計します。--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 のステータスラインを構築する を参照してください。
ログパーサーで確認できないのは、このマシン上で発生しなかったことです。別のノート PC、claude.ai 上のセッション、チームメイトの作業などのトランスクリプトは、それぞれのディスクに保存されています。古いデータも失われます。cleanupPeriodDays 設定では、デフォルトで 30 日後にトランスクリプトがクリーンアップされるため、アーカイブしていなければ前四半期のデータは残りません。
もう 1 つのリスクは、ファイル形式そのものにあります。Anthropic のドキュメントによると、エントリ形式は Claude Code の内部仕様であり、バージョン間で変更されます。そのため、これらのファイルを直接解析するスクリプトは、どのリリースでも動かなくなる可能性があります。この点は、この形式のすべてのツールに当てはまります。また、JSONL に対して手作業で作成した jq のワンライナーが、見た目ほど良い方法ではない理由でもあります。保守されたパーサーは形式の変更に対応しますが、ワンライナーはフィールド名が変更された日に、確信ありげな誤った値を報告します。
最後に、サブスクリプション利用時に表示されるドル額には注意が必要です。Pro または Max ではトークン単位の課金は行われないため、その値はトークンを API の標準料金で利用した場合の金額です。利用量の大きさを測る値であり、実際の請求額ではありません。どのプランを選ぶべきかが本当の問題であれば、その比較は別途検討する必要があります。API の請求と Claude サブスクリプションの比較 を参照してください。
方法 2: 組み込みの使用量画面で、どのモデルが予算を消費したかを確認する
Claude Code には独自のレポート機能がありますが、多くのユーザーは開きません。セッション中に /usage を実行してください。画面上部の Session ブロックには、モデル別のトークン数と現在のセッションの金額が表示されます。この金額は、トークン数に標準の定価を適用してローカルで計算されます。割引やプロモーション価格は反映されないため、請求書の金額と異なる場合があります。/clear で新しい会話を開始すると、合計値はリセットされます。
Pro、Max、Team、Enterprise のいずれかのプランでは、同じ画面にプラン上限の使用量も表示されます。また、直近の使用量を合計に対する割合として、skills、subagents、plugins、個別の MCP servers ごとに示します。長いコンテキストやキャッシュミスなど、直近の使用量の 10% 以上を占める動作にはフラグが付きます。d または w を押すと、直近 24 時間と直近 7 日間を切り替えられます。これらの数値は概算であり、このマシンのローカルなセッション履歴から計算されるため、別のデバイスでの使用量は含まれません。バーが単に少ないのではなく空になった場合、画面にはウィンドウが終了したことだけが表示され、作業を続ける方法は示されません。上限に達した後の対処方法は、モデル、コンテキスト、プランに関する別の判断です。
開発者が 1 人を超えると、数値はアカウント単位で管理されます。API organisation では、Console usage ページ、メンバーごとの支出額と受け入れられた行数を示す Claude Code dashboard、同じ日次のユーザー別指標を admin key で返す Claude Code Analytics API を利用できます。Teams と Enterprise のプランでは、admin console に日次更新の支出レポートが表示され、CSV export も利用できます。Enterprise では analytics API も追加されます。表示されるものは各開発者のサインイン方法によって異なるため、構成が混在する organisation では 2 つのレポートを確認し、手作業で合算する必要があります。
予算規模を見積もる場合、2026 年 8 月時点で Anthropic の cost documentation に掲載されている数値は、アクティブな 1 日あたりの開発者 1 人につき平均約 $13、1 か月あたり $150 から $250 です。また、ユーザーの 90% はアクティブな 1 日あたり $30 未満です。これはエンタープライズ導入に基づく公表ベンチマークであり、チームの予測値ではありません。小規模なパイロットグループを運用し、外挿する前に測定してください。
ダッシュボードで確認できないのは、日単位および個人単位より細かい情報です。火曜日の大半で Opus が使われたことは分かります。しかし、どのプロンプト、どのリポジトリ、どの CI job が原因だったかは分かりません。また、organisation のレポートは日次で更新されるため、反映にも遅延があります。そのため、当日の暴走した 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 を編集した後にキャッシュ読み取りが急減したかどうかを確認できます。驚くような差が出やすいのは通常、キャッシュの動作です。プロンプトキャッシュが効果を発揮する条件では、確認すべき内容を説明しています。
この話題では必ず出てくるため、1 点訂正しておきます。Langfuse はセルフホスト型のトレースバックエンドとして優れており、VPS で実行する方法は エージェントトレース用の Langfuse セルフホスティングで説明しています。ただし、その OTLP エンドポイントが受け付けるのはトレースだけです。Claude Code がエクスポートするのはメトリクスとログイベントであり、スパンではありません。そのため、OTEL_EXPORTER_OTLP_ENDPOINT を Langfuse に向けてもプロジェクトは空のままで、確認する価値のあるエラーも表示されません。Langfuse は、API を直接使って構築するエージェントに適したツールです。その場合は、自分のコードでプロンプト、モデル、コストを含む各スパンを作成します。Claude Code CLI には、メトリクスストアが適しています。
Claude Code の使用額を自分の VPS で追跡する
必要なサービスは 2 つだけです。メトリクスを受け取るコレクターと、メトリクスを保存する 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 トンネル内にあるサーバーのアドレスです。そのため、コレクターには自分のマシンからだけ到達でき、その他の場所からは到達できません。ポートの前に指定するアドレスが重要です。公開された 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 ネットワーク上でサービス名を使ってコレクターに接続するため、ポート 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コレクターのログは 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_ で始まる名前が複数返るはずです。エクスポーターはドットをアンダースコアに置換し、単位を追加します。そのため、正確な文字列はコレクターのバージョンによって異なります。結果が空の場合、何も到着していません。プロトコルとポートが一致しているか確認してください。http/protobuf は 4318 に接続し、grpc は 4317 に接続するためです。不一致でもエラーが明確に表示されない場合があります。claude --debug を実行すると、デバッグログに OTel のエクスポートエラーが表示されます。
1 台のマシンだけでサーバーを使わない場合は、上記の設定をすべて省略できます。OTEL_METRICS_EXPORTER=prometheus を設定すると、Claude Code 自体が http://localhost:9464/metrics にスクレイプエンドポイントを公開します。prometheus に記載されたエクスポーターが 1 つだけの場合、Claude Code はメトリクス名から USD、tokens、s の単位を省略します。これにより、スクレイプ結果が有効な 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 ジョブはダッシュボードを使わずに自身のコストを記録できます。値をファイルに追記するか、前述のコレクターへメトリクスとして送信します。これは実用的なコスト追跡として最も低コストな方法であり、実行ごとに 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 経由で実行した場合の費用を表示します。1 日の処理量を相対的に把握する指標として有用であり、プロジェクト間やモデル間の比較にも使えます。実際の請求額を確認するには、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 も含まれます。ジョブごとにこの値を記録すれば、エージェント、ダッシュボード、追加サービスなしでパイプライン単位の支出を把握できます。