はじめに
AI コーディングエージェントを企業で使えるようにしたものの、次に困るのが「実際どれくらい使われているの?」という点かと思います。
トークンをどれだけ食っているのか、どのチームが伸びているのか、モデルを変えたらコストはどう動くのか？
もう色々な企業では、既に自作でダッシュボード化もしているかと思います。
2026年7月20日、CloudWatch に Coding Agent Insights が追加されました。Claude Code や Copilot、Codex が吐く OpenTelemetry メトリクスを CloudWatch に流すと、組織・部門・チーム・ユーザー単位で切ったダッシュボードが自動で出てくるというものです。
今回は東京リージョンで、Claude Code から実際にメトリクスを飛ばして中身を確認してみました。なお、Copilot や Codex でも簡単に同じような要領でできそうなのでドキュメントを参考に是非試してみてください。
忙しい人のための要約
- CloudWatch コンソールの GenAI Observability > Coding Agent Insights に、AI コーディングエージェント用のダッシュボードが自動で現れます（自分で作る必要はありません）
- 対応エージェントは Claude Code / Copilot / Codex。エージェント側は OTel の環境変数を設定するだけです
- 認証方式は 2 通り（ベアラートークン / Claude apps gateway）。まず試すならベアラートークンが最短で、IAM ユーザー 1 つと
CloudWatchAPIKeyAccessポリシーがあれば数分で使えます - チームや部門といった属性は OTel の resource 属性として渡すのが決まりです
- 料金は CloudWatch の OTel メトリクス取り込み（GB 単位）のみのようです
Coding Agent Insights とは
ざっくり言うと「エージェントが元々出している OTel メトリクスを CloudWatch に集めると、専用ダッシュボードが勝手に生えてくる」機能です。公式ドキュメントによると、自分達でダッシュボードを作ったりインポートしたりする作業はなく、期待される形のメトリクスが届いた時点で自動的に表示してくれるとのことです。
組織・部門・チーム・コストセンター・ユーザーといった軸で切り替えられ、CSV でのエクスポートもできるとのことです。AWS のブログでは、概況（総トークン数・総コスト・アクティブユーザー・セッション数・キャッシュヒット率）、利用量とコスト、開発者の生産性、コード編集の内訳といったセクションが紹介されています。
メトリクス
Claude Code のドキュメントによると、Claude Code が出すメトリクスは次の 8 つです。ダッシュボードの各セクションはこれらを集計したものになります。
| メトリクス | 内容 |
|---|---|
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 |
アクティブ時間の合計 |
属性
属性には置き場所の違う 2 系統があります。
| 属性 | 置き場所 | 誰が付けるか |
|---|---|---|
model type など |
データポイント側 | エージェントが自動で付ける |
user.email team.id department cost_center organization など |
resource 側 |
OTEL_RESOURCE_ATTRIBUTES で自分で渡す |
では、それぞれ何を入れるか。まずエージェントが自動で付けるほうです。変数名はいずれも頭に OTEL_METRICS_ が付きます。
| 属性 | 制御変数と既定値 | 判断 | 理由 |
|---|---|---|---|
app.version |
INCLUDE_VERSION（false） |
入れる | バージョン間の比較に使える |
app.entrypoint |
INCLUDE_ENTRYPOINT（false） |
入れる | CLI / VS Code / SDK の別が分かる |
session.id |
INCLUDE_SESSION_ID（true） |
外してよい | 系列が増えるだけ |
user.account_uuid / user.account_id
|
INCLUDE_ACCOUNT_UUID（true） |
どちらでも |
user.email で足りる |
| resource 属性のコピー |
INCLUDE_RESOURCE_ATTRIBUTES（true） |
外してよい | resource 側と二重になる |
model / type
|
制御不可 | — | ダッシュボードが使う |
user.id（匿名ハッシュ） |
制御不可 | — | 人の識別には使えない |
user.email |
制御不可 | — | OAuth 認証時に付く |
terminal.type |
制御不可 | — | 検出できたときに付く |
organization.id |
制御不可 | — | 認証時に付く |
次に、自分で OTEL_RESOURCE_ATTRIBUTES に書くほうです。ダッシュボードのどの軸に効くかが判断基準になります。
| 属性 | 判断 | 理由 |
|---|---|---|
team.id department organization
|
必須 | 主要な集計軸 |
user.email |
必須 | ユーザー軸 |
cost_center |
配賦するなら必須 | コスト按分の軸 |
user.id |
推奨 | 人を識別できる |
user.name |
任意 | ドキュメントの例にはある |
location role manager
|
不要 | 標準の集計軸ではない |
料金
料金は CloudWatch の OTel メトリクス取り込み（GB 単位）のみのようです。2026 年 7 月時点の東京リージョンの料金は次のとおりです。
| 項目 | 単価（東京） |
|---|---|
| メトリクスの取り込み | $0.50 / GB |
| 保存（15 か月） | 取り込み料金に込み。追加費用なし |
バイト数がそのまま効くので、長い属性値を大量に付けるのは避けたほうが良さそうです。ちなみに、AWS のブログでは、開発者 200 人規模の組織で月 $15 未満と見積もられています。
認証方式
送り方が分かったところで、次は認証です。手を動かす前に、どの方式で送るかを決める必要があります。Claude Code のセットアップページには 2 つの方式が書かれています。
| 方式 | 必要なもの | 向く場面 |
|---|---|---|
| A. ベアラートークン | IAM ユーザー 1 つとトークン | 開発者の PC、まず試すならこれ |
| B. Claude apps gateway | 自社ホストのゲートウェイ + OIDC IdP + PostgreSQL | SSO で統制したい組織 |
この記事では方式 A を手順 1〜3 で通しでやります。方式 B は後半で概要を扱います。
やってみた（方式A: ベアラートークン）
手順1: CloudWatch メトリクス API キーを作る
公式のセットアップ手順に沿って、方式 A で進めます。使うのは CloudWatch OTLP エンドポイント専用のベアラートークン（API キー）です。これは IAM ユーザーに紐づく「サービス固有の認証情報」で、専用ドキュメントによるとメトリクス取り込みエンドポイント以外には使えない、つまり GetMetricData などのクエリ系 API は叩けない仕様になっています。
# 取り込み専用の IAM ユーザーを作って、マネージドポリシーを付ける
aws iam create-user --user-name cw-coding-agent-otlp
aws iam attach-user-policy --user-name cw-coding-agent-otlp \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAPIKeyAccess
# API キー（ベアラートークン）を発行。有効期限は 1〜36600 日で指定可能
# レスポンスの ServiceCredentialSecret がトークン本体なので、そのまま変数に取る
TOKEN=$(aws iam create-service-specific-credential \
--user-name cw-coding-agent-otlp \
--service-name cloudwatch.amazonaws.com \
--credential-age-days 1 \
--query 'ServiceSpecificCredential.ServiceCredentialSecret' \
--output text)
このトークンは発行時にしか取得できないので、失くしたら作り直しになります。--credential-age-days を省略すると無期限になるため、検証用途では短めに切っておくのが良さそうです。
なお $TOKEN はシェル変数なので、当たり前ですがターミナルを閉じると消えます。次の手順 2 ではターミナルに依存しない置き場所へ移すので、ここでは一旦同じシェルのまま進めてください。
一応疎通確認は空ペイロードで叩くとできます。成功すると空の JSON が返ります。
curl -X POST "https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{"resourceMetrics":[]}'
# -> {}
手順2: Claude Code に OTel の設定を入れる
Claude Code は環境変数で OTel エクスポータを設定します。テレメトリの設定はモデルの推論経路とは独立しているので、推論に Bedrock を使っていても Anthropic API を使っていても、この設定だけで送信できます。
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT="https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics"
export OTEL_EXPORTER_OTLP_METRICS_HEADERS="Authorization=Bearer $TOKEN"
# 組織属性は resource 属性として渡す
export OTEL_RESOURCE_ATTRIBUTES="\
user.id=leomarokun,\
user.email=leomarokun@example.com,\
department=engineering,\
team.id=platform,\
cost_center=cc-qiita,\
organization=leomarokun-lab"
この状態で Claude Code のセッションを回すと、デフォルトでは 60 秒間隔でメトリクスがエクスポートされます。
ただし環境変数はそのターミナルを閉じたら消えますので、これだけだと開き直すたびに設定し直すこととなります。Claude Code は ~/.claude/settings.json の env からも同じ変数を読むので、恒久的にはこちらに書きます。
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
"OTEL_EXPORTER_OTLP_METRICS_ENDPOINT": "https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics",
"OTEL_EXPORTER_OTLP_METRICS_HEADERS": "Authorization=Bearer 【トークン】",
"OTEL_METRICS_INCLUDE_VERSION": "true",
"OTEL_METRICS_INCLUDE_ENTRYPOINT": "true",
"OTEL_RESOURCE_ATTRIBUTES": "user.id=leomarokun,user.email=leomarokun@example.com,department=engineering,team.id=platform,cost_center=cc-qiita,organization=leomarokun-lab"
}
}
なお、この settings.json の env はシェルの環境変数より優先されます。すでに別の OTel 送信先を設定している場合、export で上書きしようとしても効かないので注意が必要です。
手順3: ダッシュボードを見る
メトリクスが届いていれば、あとは何も作らなくてもダッシュボードが出てきます。CloudWatch コンソールの左ペインから 生成 AI オブザーバビリティ > コーディングエージェントのインサイト を開き、エージェントのタブ（Claude Code）を選びます。
Usage & Cost(利用状況と費用)
ここではトークンの使用量と費用が確認できますね。
ユーザー毎に見てみましょう。画面左側の Group by を User にします。
Developer Productivity(開発者の生産性)
ここでは、コードの行数、コミット、プルリクエストなどを見ることができるようです。開発者がどれだけ効率よく AI を使いこなせているかのデータとして使えそうですね。
Code Editing(コード編集)
ここでは、言語、コードの編集をどれだけ採用したか、どれだけツールが使われたかを見ることができるようです。モデルごとに見てあげれば、どのモデルで十分かなどの判断をしてコスト効率の改善へと繋げることができそうですね。
しばらく待ってもグラフが空のままなら、送信できていないのか、届いているのに表示されていないのかを切り分けます。ここで注意したいのが、OTLP 経由で入ったメトリクスは aws cloudwatch list-metrics には出てこないことです。従来のメトリクスとは別の場所に入るためで、確認するにはコンソールの Query Studio を開き、クエリモードを PromQL に切り替えて次を実行します。
{"claude_code.token.usage"}
ここに値が出るならデータは届いています。空なら送信側の問題なので送信側の設定などを見直します。
トラブルシュート
| 症状 | 原因と対処 |
|---|---|
| メトリクスがまったく届かない |
settings.json の env がシェルの環境変数より優先されます。既存の OTel 設定があると、export しても効きません |
| 設定を上書きしても届かない | 汎用の OTEL_EXPORTER_OTLP_HEADERS が残っていると、シグナル別の OTEL_EXPORTER_OTLP_METRICS_HEADERS より優先されました。両方に同じ値を入れると通ります |
ベアラートークンの扱い
ここまでで動くようにはなりましたが、ベアラートークンが長期認証情報である点は意識しておきたいところです。ドキュメントでも、短期認証情報が使える環境では SigV4 を優先し、ベアラートークンは開発者の PC のような AWS 外の環境に限定することが推奨されています。加えて前述のとおり、トークンを持っていれば誰でも他人の team.id を名乗れます。
手軽さと引き換えに何を許容しているか、という話です。ここが許容できない場合の選択肢が、もうひとつの方式になります。
方式B: Claude apps gateway
もうひとつの方式は、トークンも AWS の認証情報も開発者に渡しません。自社ホストのゲートウェイが Claude Code とモデルプロバイダの間に入り、開発者は社内 IdP でサインインします。実体は claude バイナリ自身で、gateway サブコマンドを渡すとゲートウェイとして動きます。
テレメトリの観点で効いてくるのは、ID の出どころが変わることです。方式 A では開発者のマシンが OTEL_RESOURCE_ATTRIBUTES に書いた値をそのまま名乗っていましたが、こちらはゲートウェイが IdP から取った ID を各エクスポートに刻んで送ります。届くメトリクスにユーザー・チーム・組織の属性が付くのは同じなので、ダッシュボードは方式 A と同じように埋まります。
| 方式 A | 方式 B | |
|---|---|---|
| ID を名乗るのは | 開発者のマシン（自己申告） | ゲートウェイ（IdP 由来） |
| 開発者が持つもの | ベアラートークン | なし（SSO でサインイン） |
| 必要なインフラ | なし | 常時稼働のサーバー + PostgreSQL + OIDC の IdP |
ただしゲートウェイは認証・モデルのアクセス制御・設定配布・上流ルーティングもまとめて引き受ける基盤で、テレメトリはそのうちの 1 機能にすぎません。本番で動かせるのは Linux だけ、ホスト名はプライベートアドレスに解決する必要あり、と要求も多めです。推論の経路にも入るので、ダッシュボードを見たいだけなら重すぎる選択肢かと思います（ここは試していないので、ドキュメントの構成から読み取った印象です）。
「SSO で統制したい」「開発者にクレデンシャルを持たせたくない」という要件が先にあり、テレメトリはその副産物、という順序で採用するものだと理解しています。手順はセットアップガイドに揃っているので、そちらに譲ります。
既にこんな記事を書いてくれている人もいるので、参考にすると良いかと思います。
まとめ
- エージェント側は環境変数を数個入れるだけで、CloudWatch にメトリクスを送れ、ダッシュボードが自動で出てきます
- 組織属性を
OTEL_RESOURCE_ATTRIBUTESに載せておけば、チーム別・部門別の集計もできます - 認証方式は 2 通りで、まず試すならベアラートークン、組織として統制するならゲートウェイ、という住み分けかと思います
まずは自分1人分を流してみて、claude_code.cost.usage の数字を眺めるところから始めるのが良さそうです。
そこから、開発者の生産性、コード編集などの他の情報も見てどう改善へと繋げていくのが今後求められるフェーズかと思います。
参考リンク
本文中でも都度リンクしているので、ここでは特に読む価値のあるものだけ挙げておきます。
- Coding Agent Insights — 機能そのものの説明
- Claude Code の監視設定 — メトリクスと属性の一覧
- Analyzing Claude Code usage with CloudWatch and OpenTelemetry — ダッシュボードの中身や、コスト急増を検知する PromQL の例