エージェントの働きぶりが、経営の画面に載る──CloudWatchがClaude Code/Codex/Copilotを横並びで測り始めた
AWSが7月20日に発表したCloudWatch Coding Agent Insightsは、Claude Code・Codex・Copilotの消費・コスト・成果を一枚の画面に並べる。導入効果を数字で測れる利点と、個人の行数を監視に転用する危うさの両面を整理する。
コーディングエージェントは「入れたら終わり」の道具ではなくなりました。導入が進むほど、次に問われるのは「誰が、どれだけ使い、何を生んでいるのか」という運用の可視化です。2026年7月20日、AWSはこの問いに正面から答える機能として、Amazon CloudWatch Coding Agent Insights を発表しました。Claude Code・OpenAI Codex・GitHub Copilot の利用状況を、既存のCloudWatch運用データと同じ画面に並べて見せるダッシュボードです。
「体感」で語られていた導入効果に、数字がつく
これまで、コーディングエージェントの効果は「開発が速くなった気がする」という体感で語られがちでした。Coding Agent Insights は、その効果を OpenTelemetry（オープンな計測規格）で送られるメトリクス として集め、消費・コスト・成果の3つの軸で示します。エンジニアリング責任者が「どのチームに枠を広げるべきか」「どこで開発が加速しているか」「部門ごとのトークン予算をどう適正化するか」を、推測ではなくデータで判断できるようにする、という位置づけです。
ダッシュボードは4つのタブに分かれている
画面はコーディングエージェント専用に用意され、見る目的ごとに切り替えられます。
| タブ | 見えるもの |
|---|---|
| Executive Summary（全体像） | 総トークン数、総コスト、アクティブ利用者、セッション数、キャッシュヒット率、稼働時間 |
| Usage & Cost（利用とコスト） | トークン消費の推移、部門・チーム別のコスト、入力／出力／キャッシュ読み書きといったトークン種別の内訳 |
| Developer Productivity（開発の成果） | 追加・削除された行数、コミット数、実作業時間、プルリクエスト数 |
| Code Editing（編集の中身） | 言語の分布、提案された編集の採用／却下の比率、使われた編集ツール |
利用可能なのはイスラエル（テルアビブ）と中東（UAE・バーレーン）を除くすべてのAWS商用リージョンで、費用はCloudWatchの標準的なメトリクス取り込み料金に従います。
データはどこから来るのか──鍵は「Claude apps gateway」
数字の出どころは、各エージェントが吐き出すOpenTelemetryのメトリクスです。Claude Code については、AWSが7月15日に発表した Claude apps gateway（自社で持つ制御盤）を通せば、追加の計測コードなしにテレメトリを集められます。このゲートウェイはClaude CodeのCLIバイナリに同梱されるステートレスなコンテナで、ECS・EKS・EC2上で動かせます。単に数字を集めるだけでなく、次のような統制も担います。
- OpenID Connect による社内シングルサインオン（IDプロバイダのグループ単位で設定を適用）
- 利用できるモデルやツール権限を、手元では上書きできない既定として配布
- 組織・グループ・個人ごとに、日次／週次／月次の上限で支出に蓋をする
- Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry、Anthropic API といった複数の実行先への振り分け
Claude Code 側の設定は環境変数から
手元のClaude Codeからメトリクスを送るだけなら、ゲートウェイを使わずとも環境変数で完結します。テレメトリを有効化し、送り先をCloudWatchのエンドポイントに向ける形です。
CLAUDE_CODE_ENABLE_TELEMETRY=1でテレメトリを有効化OTEL_METRICS_EXPORTER=otlpとOTEL_EXPORTER_OTLP_ENDPOINT（https://monitoring.<リージョン>.amazonaws.com）で送信先を指定OTEL_RESOURCE_ATTRIBUTESにuser.id/team.id/cost_centerなどを付け、誰の・どのチームの消費かを紐づける
設定後に短いセッションを回し、CloudWatchで claude_code.token.usage のようなメトリクスが届いていれば疎通確認は完了です。
「使いっぱなし」から「配分の判断」へ
ビジネス面での意味は、コストの可視化にとどまりません。トークン予算を部門ごとに適正化し、成果の出ているチームに枠を寄せ、支出の上限で暴走を防ぐ——エージェントの利用を、勘ではなく配分の意思決定に載せられるようになります。生成AIの利用が「見えない経費」として膨らみやすいなか、消費と成果を同じ画面で突き合わせられることには実利があります。
数字が「監視」に転ぶ危うさ
一方で、Developer Productivity タブが個人単位で「追加行数」「コミット数」「プルリクエスト数」を映せる点には、注意が必要だという指摘もあります。行数やコミット数を生産性の指標として個人評価に持ち込めば、指標そのものが目的化し、水増しや不要な変更を誘発しかねません（測る対象が目標になると指標が壊れる、という古くからの問題です）。集計は本来チームや部門の傾向を掴むためのものであり、個人を採点する物差しに使えば、利便性の裏で開発者の監視や萎縮というコストを生む懸念があります。何を測り、誰に見せ、何には使わないかを先に決めておくことが、導入の質を分けそうです。
参照: Amazon CloudWatch announces coding agent insights（AWS） ／ Analyzing Claude Code usage with CloudWatch and OpenTelemetry（AWS Cloud Operations Blog） ／ AWS Ships Claude Apps Gateway as Self-Hosted Control Plane（InfoQ） ／ Set up OpenTelemetry for Claude Code（Amazon CloudWatch Docs）
