Claude Code のコストを社内で可視化し、監査・統制する方法

社内で「Claude Code のコストを管理したい」と言うとき、実際には性質の違う 3 つの作業が混ざっています。最初にこれを分けておかないと、ツール選定を間違えます。

1. 請求額の確認 — 実際にいくら請求されるか。契約先（Anthropic / AWS / Google Cloud など）の請求画面だけが正本です。
2. 利用状況と概算コストの可視化 — 誰が・どのモデルを・どれくらい使っているか。改善や部門配賦、投資判断の材料になります。
3. 統制 — 支出上限、設定の強制、危険な操作の禁止。「使いすぎを止める」「やらせない」ための仕組みです。

この記事は 2 を中心に、1 と 3 との役割分担をはっきりさせながら進めます。「可視化ツールを入れれば使いすぎが止まる」という誤解が、導入時にいちばん高くつくためです。

Claude Code は、どの方式で認証しているかによって、課金の仕組みも、コストが見える場所も変わります。全社導入では複数の方式が混在することも珍しくありません。まず自社がどこにいるかを確認します。

1 行目でつまずきやすいのは、シート課金では利用枠内の消費が金額として計測されない点です。「誰がいくら使ったか」を金額で見たい場合は、usage credits を有効にして超過分を計測するか、テレメトリの概算値を使うことになります。採用状況（DAU・セッション・コード貢献）の分析は、金額とは別のダッシュボードで確認できます。

Anthropic の公式ドキュメントは、この表について「OpenTelemetry のエクスポートはすべての構成で動作し、ユーザー単位のトークン数とコストを自前の可観測性スタックへニアリアルタイムに流せる唯一の選択肢」と説明しています。裏を返すと、クラウドプロバイダー経由の利用は Anthropic 側の分析ダッシュボードの対象外です。

相場観を持っておく

予算を組むときは、公式が公開している実績値が目安になります（2026 年 8 月時点）。エンタープライズ導入全体で 1 開発者あたり 1 アクティブ日 約 13 ドル、月あたり 150〜250 ドルが平均で、90% のユーザーは 1 アクティブ日 30 ドル未満に収まるとされています。まず小さなパイロットで自社のベースラインを測り、そこから全社の見積もりを組み立てるのが安全です。

認証方式は /status で確認する

手元の Claude Code がどの方式で認証しているかは /status で確認できます。環境変数に API キーが設定されているとサブスクリプションより優先されることがあり、本人が気づかないまま従量課金が発生する場合があります。全社展開の前に、代表的な端末でこの確認をしておくと事故を防げます。

「誰がどれくらい使っているか」を知る手段は複数あり、それぞれ守備範囲が違います。自前で作る前に、まず既にあるものを確認します。

Anthropic 公式の利用分析

Claude for Teams / Enterprise には、管理コンソールの利用分析ダッシュボード（DAU・セッション数・コード貢献の指標、CSV エクスポート可）があります。金額のスペンドレポートは usage credits を有効にすると現れ、対象はシート利用枠を超えた分の支出です。Enterprise では Analytics API でユーザー別の利用・コストを取得できます。Console（API キー）で使っている場合は、Console ダッシュボードと Claude Code Analytics API が利用できます。まずここを見るのが出発点で、これで足りるならほかは要りません。なお Team と Enterprise のどちらを契約するか自体を検討中なら、Claude Team と Enterprise、どちらを選ぶべきか にまとめています。

ccusage でローカルの履歴を集計する

ccusage は、端末に残る Claude Code の利用履歴から日次・月次・セッション別のトークン数と概算コストを表示する OSS の CLI です。個人が自分の使い方を把握するには最短の手段です。集計対象はその端末のローカルデータなので、全社への配布・中央での監査・権限管理といった用途とは目的が異なります。

OpenTelemetry を自前の基盤へ送る

Claude Code は OpenTelemetry のメトリクス・ログ・トレースをエクスポートできます。OTLP の送信先を自社の OpenTelemetry Collector に向け、Prometheus / Grafana / ログ基盤へ流せば、可視化の自由度は最も高くなります。反面、Collector の運用、時系列データベース、ダッシュボード、ログ検索、保持と削除、権限管理を、すべて自前で設計して維持することになります。

OTLP をマネージドで受け取る

送信側の設定は自前基盤と同じまま、受信・保存・可視化・検索をサービスに任せる方法です。Aimeterly はこの位置づけで、テレメトリを有効にした Claude Code が送る OTLP をそのまま受け取り、利用状況・概算コスト・生産性のダッシュボードと、組織が設定画面で有効にした種別についての監査ログ検索を提供します。

注目すべきは「正式な請求額」と「支出を止められるか」の 2 列です。テレメトリを可視化する手段は、どれも請求の正本にはならず、支出を止めもしません。 この 2 つは契約先側で設定します。逆に、公式コンソールだけでは埋まりにくいのは、外部の基盤へニアリアルタイムに流すこと、部門やチームなど自社の軸を付けた集計、そしてイベント単位の詳細な監査です。テレメトリはそこを埋めるために使います。

4 つの手段それぞれの更新頻度・遡及できる期間・閲覧権限の違いは、Claude Code のコストを把握する 4 つの方法を比較する で詳しく扱っています。手段の選定で迷っている段階なら、先にそちらを読んでください。実際の画面イメージは デモ（デモデータ） で確認できます。

設定を配る前に、何が送られるのかを把握しておきます。そもそも Claude Code の OpenTelemetry は、CLAUDE_CODE_ENABLE_TELEMETRY=1 とエクスポータを設定しない限り何も送りません。有効にしたうえで、送られるのは「メトリクス」「イベント（ログ）」「トレース」の 3 系統です。本文を記録するフラグはすべて既定で無効なので、有効化した直後に送られるのは本文を含まないメタデータだけです（項目の一覧は 公式のテレメトリ仕様 にあります）。

8 種類のメトリクス

これらには user.email・user.id・session.id・model・terminal.type・organization.id などの属性が付きます。OTEL_RESOURCE_ATTRIBUTES=department=platform のように独自の属性を足せば、部門やチームの軸を自分で持たせることもできます。

イベントと本文の記録は別物

メトリクスとは別に、claude_code.user_prompt・claude_code.assistant_response・claude_code.tool_result・claude_code.api_request・claude_code.api_error・claude_code.tool_decision といったイベントがログとして送られます（user_prompt のような短い名前は、各レコードの event.name 属性に入ります）。ここで重要なのは、既定ではプロンプトや応答の本文が送られないことです。本文まで記録するには、次の環境変数を明示的に有効にする必要があります。

属性の量を絞る

メトリクスに付く属性はカーディナリティ（値の種類数）に直結し、保存先によってはコストと性能に影響します。OTEL_METRICS_INCLUDE_SESSION_ID=false でセッション ID を外す、OTEL_METRICS_INCLUDE_ACCOUNT_UUID=false でアカウント UUID を外すといった調整ができます。自前基盤に送る場合はとくに、最初に決めておくべき項目です。

テレメトリの設定は環境変数です。各自に手で設定させるのは現実的ではないので、管理設定として配布します。配布する JSON の中身は、どの方式でも同じです。

最小構成

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://<送信先のエンドポイント>",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer <トークン>"
  }
}

この JSON は settings.json と同じスキーマなので、以下のどちらの配布方式でもそのまま使えます。OTEL_EXPORTER_OTLP_HEADERS に入るトークンは秘密情報です。リポジトリにコミットせず、配布経路を触れる人の範囲も確認してください。

方法 A: サーバー管理設定（Teams / Enterprise）

Claude for Teams / Enterprise なら、claude.ai の Admin Settings → Claude Code → Managed settings に JSON を貼るだけで全ユーザーへ配布できます（サーバー管理設定のドキュメント）。クライアントは起動時に取得し、セッション中は 1 時間ごとに更新を確認します。MDM を持っていない組織や、管理外の端末を含む場合に向いています。編集できるのは Owner / Primary Owner だけです。

方法 B: エンドポイント管理設定（MDM）

MDM を運用しているなら、macOS の管理プロファイル、Windows のレジストリポリシー、または各 OS の管理設定パスに置く managed-settings.json で配布します。OS レベルでファイルを保護できるぶん、こちらの方が強い保証が得られます。

反映されないときに見るところ

• OpenTelemetry の設定は、ほかの設定と違って完全に再起動しないと反映されません。
• 送信されているか怪しいときは claude --debug でエクスポータのエラーを確認します。
• 開発者が個人設定で送信先を上書きしている場合、管理設定側で OTEL_EXPORTER_OTLP_ENDPOINT を設定していれば、起動時に競合する開発者設定のシグナル別エンドポイントが取り除かれます（v2.1.217 以降）。
• CLAUDE_CODE_USE_BEDROCK などのプロバイダー変数や独自の ANTHROPIC_BASE_URL をシェルでエクスポートしていると、サーバー管理設定の取得自体がスキップされます。
• 受信側で claude_code.session.count が増えているかを最初に見ます。届いていれば経路は通っており、あとは属性の問題に切り分けられます。

Bedrock / Google Cloud / Foundry の場合

サードパーティのモデルプロバイダー経由（Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、カスタムエンドポイント）では、サーバー管理設定は利用できません。この構成では MDM によるエンドポイント管理設定を使うか、自己ホスト型のゲートウェイを立てることになります。公式の分析ダッシュボードも対象外になるため、ユーザー単位のコスト把握は OpenTelemetry か LLM ゲートウェイが実質的な選択肢です。

OTLP の受け皿を自前で構築せずに始めたい場合は、Aimeterly のセットアップ手順 が使えます。組織を作るとエンドポイントと取り込みトークンが即時発行されるので、上のスニペットの <...> を置き換えて配布すれば受信経路は通ります。ユーザー別に集計したい場合は、これとは別に、直前で触れた識別属性の手当てが必要です。

プロンプトや応答の本文を記録すれば、「何が入力され、何が起きたか」を後から追えるようになります。同時に、記録の対象にはソースコード、顧客情報、認証情報、個人情報が含まれ得ます。技術的に有効化できることと、有効化してよいことは別です。

既定は「本文を送らない」

本文の記録は主に 4 種類（プロンプト / 応答 / ツール詳細 / ツール内容）に分かれ、いずれも既定で無効です（前述の OTEL_LOG_RAW_API_BODIES も既定で無効で、この記事では有効にしません）。一括で有効にするのではなく、達成したい目的から逆算して必要な種類だけを選びます。たとえば「どんな指示が出されたか」を追いたいだけならプロンプトのみで足ります（その場合は前述のとおり OTEL_LOG_ASSISTANT_RESPONSES=0 を明示します）。

先に決めておく項目

1. 目的 — 何のために記録するのか（インシデント調査、情報持ち出しの確認、規約遵守の説明など）を文書化する。
2. 範囲 — 4 種類のうちどれを有効にするか。全社か、特定のチームか。
3. 閲覧者 — 誰が見られるか。管理者だけか、上長も含むか。権限を分けられる仕組みか。
4. 保持期間と削除 — いつまで残すか。削除の手順と、実行できる人は誰か。
5. 従業員への通知 — 記録の目的・範囲・閲覧者を事前に周知する。就業規則や労使協定の確認が必要かを法務・人事と詰める。

生産性指標を評価に直結させない

コード行数、コミット数、PR 数、提案の受け入れ率といった指標は、導入の浸透度を見たり、支援が必要なメンバーを見つけたりするには有用です。一方、個人の成果指標としては簡単に歪みます（行数を増やす、細かくコミットする、といった行動を誘発します）。組織の傾向を見る用途に留め、人事評価の直接の根拠にはしない——これを導入時に明示しておくと、運用が安定し、現場の抵抗も小さくなります。

可視化と統制は別のレイヤーです。ダッシュボードは何が起きたかを教えてくれますが、それ自体は何も止めません。やりたいことごとに、実際に効く場所を整理します。

つまり、テレメトリの可視化ツールに求めるべきは「止めること」ではなく、方針どおりに運用されているかを後から確認できることです。止める仕組みは契約先と管理設定に置き、確認の仕組みをテレメトリに置く——この分担が、いちばん壊れにくい構成です。

ここまでの内容を、着手順に並べておきます。上から順に潰していけば、大きな手戻りは避けられます。

1. 認証方式と請求元を確認した（/status、契約プラン、クラウド経由の有無）
2. 支出の上限を契約先側で設定し、それが「止まる上限」か「通知だけ」かを把握した
3. テレメトリの送信先を決め、トークンの配布経路と権限を確認した
4. 管理設定の配布方式（サーバー管理 / MDM）を、クライアント群ごとに 1 つへ決めた
5. サーバー管理設定で空でないエンドポイントを配る場合、承認ダイアログが出ることを利用者へ事前に案内した
6. 配布後、対象の端末で Claude Code を完全に再起動した（OpenTelemetry の設定は再起動しないと反映されない）
7. 受信側で claude_code.session.count が増えることを確認した
8. パイロットで user.email などのユーザー識別属性が期待どおり届くか確認した（外部プロバイダー経由では別途手当てが必要）
9. 届かないときの診断手順（claude --debug、適用されている管理設定の確認）を決めた
10. 本文の記録について、目的・範囲・閲覧者・保持期間・削除手順を決めた
11. プロンプトだけを記録する場合、OTEL_LOG_ASSISTANT_RESPONSES=0 を明示して配布した
12. 配布物に OTEL_LOG_RAW_API_BODIES が紛れ込んでいないことを確認した
13. 従業員への通知と、必要な社内手続きを済ませた
14. 概算コストと正式な請求額を、社内の説明資料で区別した