なぜ今 Claude Code の利用状況を可視化するのか
Claude Code をはじめとする AI コーディングエージェントが、個人の試用からチーム全体の標準ツールへと広がっています。導入が進むほど技術リーダーや CTO のもとには、いくつかの素朴な問いが集まってきます。誰がどれくらい使っているのか、毎月どれだけのコストがかかっているのか、そして本当に開発生産性の向上につながっているのか、という問いです。
これらは感覚ではなくデータで答えるべき問いです。ところが多くの現場では、AI エージェントの利用実態がブラックボックスのまま全社展開だけが先行しています。コストの内訳が部門単位で見えず、利用が一部のメンバーに偏っていても気づけず、効果測定ができないために次の投資判断の根拠も持てない状態に陥りがちです。
AI 活用支援を手がける Ragate でも、導入そのものよりも導入後のモニタリング不足が共通の課題だと感じています。クラウド移行で当たり前になったオブザーバビリティの考え方を、AI エージェントの利活用にもそのまま持ち込むことが、この問いに答える近道です。本記事では Amazon CloudWatch と OpenTelemetry を組み合わせ、Claude Code の利用状況を可視化する具体的な方法を解説します。
OpenTelemetry の基礎と CloudWatch との連携
OpenTelemetry は、テレメトリデータの生成・収集・エクスポートを標準化するオブザーバビリティのフレームワークです。扱うシグナルは大きく三つに分かれます。時系列の数値を表すメトリクス、出来事を記録するログ、処理の流れを追うトレースです。これらを共通の形式で運ぶ規格が OTLP と呼ばれるプロトコルで、データの送り先を選ばないベンダーニュートラルな設計が最大の特徴です。
従来の構成では、各アプリケーションが出力したテレメトリをいったん Collector と呼ばれる中継プロキシで受け取り、加工してからバックエンドへ転送するのが一般的でした。Collector はデータの集約点として便利な一方、配布と運用の手間が増える要素でもあります。
ここで重要なのが、Amazon CloudWatch が OTLP エンドポイントに対応した点です。CloudWatch はリージョンごとに OTLP の受信口を持ち、PromQL によるクエリにも対応しました。これにより Claude Code が出力するメトリクスを、追加のバックエンドを用意することなく、使い慣れた CloudWatch のダッシュボードとアラームでそのまま扱えます。
さらに見逃せないのが、開発者のラップトップから CloudWatch へ直接送信できる構成です。AI コーディングエージェントは AWS の外側にある開発者のマシン上で動くため、本来であれば各マシンに Collector や IAM 資格情報を配る必要がありました。CloudWatch の OTLP エンドポイントは Bearer トークンによる認証をサポートしており、長期 API キーを Authorization ヘッダーに載せるだけで HTTPS 経由の直送が成立します。Collector もサイドカーも、開発者マシンへの資格情報の配布も不要になる点が、この構成の本質的な価値です。
Claude Code が出力するメトリクスと有効化設定
Claude Code のテレメトリは、環境変数で有効化します。必須となるのが CLAUDE_CODE_ENABLE_TELEMETRY=1 で、続けてエクスポーターと送信先を指定します。CloudWatch へ直送する場合の設定例は次のとおりです。エクスポート間隔は既定でメトリクスが 60 秒、ログが 5 秒で、検証時は短く、本番では既定値に戻すことが推奨されています。
CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/json
OTEL_EXPORTER_OTLP_ENDPOINT="https://monitoring.AWS_REGION.amazonaws.com"
OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer YOUR_TOKEN"認証に使う Bearer トークンは CloudWatch のメトリクス向け API キーで、IAM ユーザーにひも付けたうえでマネージドポリシー CloudWatchAPIKeyAccess を付与します。管理者は管理設定ファイルでこれらの環境変数を一元的に定義し、各ユーザーによる上書きを防ぐ運用も可能です。
Claude Code が出力する主なメトリクスは、利用量と生産性の両面をカバーします。代表的なものを整理します。
メトリクス名 | 意味 |
|---|---|
claude_code.session.count | 開始されたセッション数 |
claude_code.token.usage | 使用トークン数（入力・出力・キャッシュ別） |
claude_code.cost.usage | セッションごとの推定コスト |
claude_code.lines_of_code.count | 変更されたコード行数（追加・削除別） |
claude_code.commit.count | 作成されたコミット数 |
claude_code.pull_request.count | 作成されたプルリクエスト数 |
claude_code.code_edit_tool.decision | 編集ツールの承認・拒否の回数 |
claude_code.active_time.total | 合計アクティブ時間 |
これらのメトリクスには共通の属性が付与されます。匿名識別子の user.id、組織を表す organization.id、利用モデルを示す model のほか、OTEL_RESOURCE_ATTRIBUTES を使えば部門名やチーム ID、コストセンターといった独自の属性を自由に付けられます。この属性設計が、後述する部門単位の分析を支える土台になります。
CloudWatch での可視化とダッシュボード設計
収集したメトリクスは CloudWatch のダッシュボードで可視化します。AWS 公式ブログでは、五つのセクションで構成するダッシュボードが紹介されています。全体像をつかむ概要、トークン消費の内訳を追うトークン使用量、コード行数やコミットを見る開発生産性、部門やチーム単位で切り分ける組織別の内訳、そして Amazon Bedrock 経由で利用する場合のモデル別の API 健全性です。
クエリには PromQL を使えるため、Prometheus で培ったクエリ資産や知識をそのまま活かせます。CloudWatch コンソール上での PromQL クエリは無料で実行できる点も実務では助かります。アラートも柔軟に組めます。たとえば直近 1 時間の支出が直近 24 時間平均の倍を超えたら通知する支出スパイクの検知、1 日あたりのチーム予算の閾値超過、さらにセッション数が 7 日平均の半分を下回ったときに知らせる利用減少の検知などが設定できます。
運用面でもう一つ強調したいのが、プライバシーに配慮した既定設計です。user.id は個人情報を含まない匿名の識別子で、プロンプト本文の記録は既定で無効になっています。本文やツールの詳細をログに残したい場合は、明示的にオプトインする必要があります。監視という言葉が持つ過剰な管理の印象を避け、安全側に倒した初期値になっているため、導入時の社内合意も得やすくなります。
実践活用シナリオとRagateの視点
可視化したデータは、三つのシナリオで価値を発揮します。一つ目はコスト管理です。claude_code.cost.usage をメールアドレスやチーム ID、コストセンターでグルーピングすれば、AI の支出をクラウド費用と同じ FinOps の規律で扱い、部門への配賦まで踏み込めます。公式ブログの試算では、200 名規模の開発者でも月あたり 15 ドル未満で可観測化できるとされており、コスト面のハードルは高くありません。
二つ目は利用状況の追跡です。誰がどのモデルをどれだけ使っているかが見えると、利用が一部に偏っていないか、想定したチームに浸透しているかを把握できます。三つ目は利活用の改善です。ここで効くのが編集ツールの承認と拒否を記録する claude_code.code_edit_tool.decision で、AI の提案がどれだけ受け入れられたかという受容率を測れます。トークンを多く消費したことと価値が生まれたことは同じではありません。コード行数やコミット、プルリクエストといった実アウトプットと組み合わせて初めて、効果を立体的に語れます。
Ragate は AI 活用支援の現場で、測らないものは改善できないという原則を大切にしています。AI エージェントの導入は配ったら終わりではなく、利用データを起点に運用を磨き込んでいくサイクルこそが成果を左右します。OpenTelemetry という標準に乗っているため、送り先を CloudWatch から Prometheus や Grafana へ差し替えても同じ計装が使える点も、長期運用での安心材料になります。
まとめと参考リンク
Amazon CloudWatch の OTLP 対応により、Claude Code の利用状況は Collector を介さずにシンプルな構成で可視化できるようになりました。環境変数を数行設定するだけでメトリクスが流れ込み、コスト管理から利活用改善までを一つのダッシュボードで扱えます。可視化は導入のゴールではなく、改善を回し続けるためのスタート地点です。自社の AI 活用を次の段階へ進める第一歩として、まずは小さく計装を試してみてください。
本記事は以下の一次情報を参考にしています。
- AWS 公式ブログ「Analyzing Claude Code usage with CloudWatch and OpenTelemetry」 https://aws.amazon.com/jp/blogs/news/analyzing-claude-code-usage-with-cloudwatch-and-opentelemetry/
- Claude Code 監視ドキュメント https://code.claude.com/docs/ja/monitoring-usage
- OpenTelemetry 公式 What is OpenTelemetry https://opentelemetry.io/docs/what-is-opentelemetry/
