Claude Code のコストを把握する 4 つの方法を比較する

手段を比べる前に、答えたい問いをはっきりさせます。ここが曖昧なまま比較表を眺めると、必要のない基盤を作ることになります。

1. いくら請求されるか — 経理に渡す数字。契約先の請求画面が唯一の正本です。どの可視化ツールもこれを代替しません。
2. 誰がどれくらい使っているか — 定着度の把握、シートの増減判断、部門への配賦、投資対効果の説明に使います。
3. 何をしていたか — インシデント調査や、情報の持ち出しがなかったことの確認。プロンプトやツール操作の記録が必要になります。

1 だけなら請求画面で足ります。2 が要るなら以下の 4 手段の比較に意味が出てきます。3 まで必要なら、選択肢は実質的に絞られます。

Claude for Teams / Enterprise の管理コンソールには、利用分析のダッシュボードがあります。まずここを見るのが出発点で、これで足りるなら追加の仕組みは要りません。

何が見えるか

スペンドレポートは CSV で書き出せます。列はメールアドレス・アカウント UUID・プロダクト・モデル・リクエスト数・入力トークン・出力トークン・純支出・総支出です。ユーザー別の内訳としては十分な粒度があります。

実務で効いてくる 4 つの制約

1. 1 日の遅延 — 支出データは日次更新で、1 日遅れて反映されます。「今まさに何が起きているか」は分かりません。
2. 90 日の遡及 — カスタム期間で遡れるのは最大 90 日、しかも前日までです。
3. シート枠内は金額が出ない — シート制のプランでは、支出レポートは usage credits を有効にした場合のみ現れ、内容も枠を超えた分だけです。枠内に収まっている利用は金額として計測されません。
4. 閲覧できる人が限られる — Team プランは Owner と Primary Owner のみ。Enterprise は Owner / Primary Owner / Admin ですが、Admin は支出を見られません。

なお Console（API キー）で使っている場合は、Console のダッシュボードと Claude Code Analytics API が使えます。クラウドプロバイダー経由（Bedrock / Google Cloud / Microsoft Foundry）の利用は、公式の分析ダッシュボードの対象外です。

ccusage は、端末に残るコーディングエージェントの利用履歴を読んで、トークン数と概算コストを集計する OSS の CLI です。インストール不要で試せます。

npx ccusage@latest daily
npx ccusage@latest monthly
npx ccusage@latest session
npx ccusage@latest blocks

キャッシュ作成・キャッシュ読み取りのトークンを分けて追跡し、価格は内蔵のスナップショットを使うためオフラインでも動きます。ccusage.json で単価を上書きすることもできます。Claude Code 以外のエージェント（Codex など）にも対応しています。

向くところと、向かないところ

個人が自分の使い方を把握するには最短の手段です。5 時間ウィンドウの消費を見ながら作業を調整する、といった使い方は他の手段では代替できません。一方、読むのはその端末のローカルデータなので、組織全体の集約、設定の一括配布、閲覧権限の分離、保持期間の管理といった用途は設計思想の外にあります。全社の数字を出すために各自の出力を集めて回るのは、現実的ではありません。

Claude Code は OpenTelemetry でメトリクス・ログ・トレースをエクスポートできます。送信先を自社の OpenTelemetry Collector に向ければ、あとは煮るなり焼くなり自由です。既に可観測性の基盤を持っている組織なら、そこへ相乗りするのが最も筋がいい選択になります。

実際に用意することになるもの

• OpenTelemetry Collector — 受信・整形・振り分け。冗長化と監視の対象が 1 つ増えます。
• 時系列データベース — メトリクスの保存（Prometheus、Mimir など）。カーディナリティ設計を誤ると容量とクエリ速度に効きます。
• ログ基盤 — イベント（プロンプト・ツール実行の記録）の保存と全文検索（Loki、OpenSearch など）。
• ダッシュボード — Grafana 等での可視化。指標の定義と保守は自分たちの仕事になります。
• 保持と削除 — プラン別・組織別の保持期間、削除要求への対応。監査ログを扱うなら特に重くなります。
• アクセス制御 — 誰が本文まで見られるのかの分離。可観測性基盤は通常「全社のエンジニアが見る」前提で作られているため、監査ログを同居させるなら設計を分ける必要があります。

ニアリアルタイムに数字が出ること、自社の軸（部門・チーム・プロジェクト）で自由に集計できること、既存の監視やアラートと統合できることが利点です。裏を返すと、これらが要らないなら重すぎる選択です。

送信側の設定は 3 と同じまま、受信・保存・可視化・検索を外部のサービスに任せる方法です。Claude Code 側は標準の OTLP を送るだけなので、送信先を切り替えるだけで移行できます（ベンダーロックインが薄い、という意味でもあります）。

Aimeterly はこの位置づけです。テレメトリを有効にした Claude Code が送る OTLP をそのまま受け取り、利用状況・概算コスト・生産性のダッシュボードと、組織が設定画面で有効にした種別についての監査ログ検索を提供します。Collector も時系列データベースも用意せず、管理設定にスニペットを配るだけで始められます。

権限は管理者・マネージャー・閲覧者で分かれているため、「マネージャーにダッシュボードだけ見せる」「監査ログは管理者だけ」といった分け方ができます。公式の利用分析で詰まりやすい閲覧権限の問題は、ここで解けます。

表の下 2 行が、最初に決めた 3 つの問いに戻ってきます。請求額は契約先でしか分からず、監査は取得を有効にした手段でしか追えません。 残りの列は「誰がどれくらい使っているか」をどの解像度で見たいか、の違いです。

10 人以下・Teams プラン・まず把握したい

公式の利用分析で始めてください。追加のコストも手間もかかりません。1 日遅延と 90 日遡及が問題にならない規模です。個々の開発者には ccusage を勧めておくと、自分の消費を自分で調整できるようになります。なお Team と Enterprise のどちらを契約すべきか自体は Claude Team と Enterprise、どちらを選ぶべきか で整理しています。

数十人規模・マネージャーに数字を配りたい

公式の閲覧権限（Team は Owner のみ、Enterprise でも Admin は支出を見られない）が最初の壁になります。OpenTelemetry を出して、権限を分けられる場所に集めるのが素直です。既存の可観測性基盤があるならそこへ、無ければマネージドを検討してください。基盤をゼロから作るのは、この規模では割に合わないことが多いです。

既に Grafana / Prometheus を運用している

自前基盤への相乗りが有力です。Collector にエンドポイントを 1 つ足すだけで、既存のダッシュボードとアラートに統合できます。ただし監査ログ（プロンプト本文）まで載せるなら、保存先と閲覧権限を分ける設計を先に決めてください。

Bedrock / Google Cloud / Foundry 経由で使っている

公式の分析ダッシュボードが対象外なので、OpenTelemetry か LLM ゲートウェイが実質的な選択肢です。サーバー管理設定も使えないため、配布は MDM 等になります。加えて user.email が付かないことがあり、ユーザー別に集計するには識別子を配る手当てが要ります。詳しくは Bedrock / Google Cloud / Foundry の場合 を参照してください。

監査要件がある（何が入力されたかを追う必要がある）

公式の利用分析にも ccusage にも、プロンプトやツール操作の記録はありません。OpenTelemetry のコンテンツログを有効にしたうえで、自前基盤かマネージドで受けることになります。ただし有効化の前に、目的・範囲・閲覧者・保持期間・従業員への通知を決めるのが先です。技術的に可能なことと、実施してよいことは別です。