はじめに

こんにちは、これを読んでるみなさんはClaude Codeを当然使っていますよね。

Claude Codeを使う上で個人のサブスクリプションを使ったり、Teamプランだったり、Enterpriseなど様々な利用方法があると思います。

ただ、個人のPro・MaxプランにはClaude Codeの組織向けの利用分析がなく、端末でClaude Codeが動いていても、外からの利用状況が全く確認できなくなります。

じゃあEnterpriseを使えばいい？Teamにすればいい？

とはいえ、Enterpriseプランだと全てが従量課金となり、そこまで大規模に使っていないという話だと流石に採算が合いません。
というわけである程度ちゃんと使おうと思うなら、Teamプランが候補となるわけです。

では、Teamプランにすることで十分なのでしょうか、と言われると「NO」です。

Teamプランの利用状況解析では、アクティブユーザ数や、セッション数、ユーザが実際にどのモデルをどれくらい使っているか？くらいは確認可能ですが、よりリアルタイムな監視であったり、プロンプト本文の収集は不可能です。

じゃあどうするか

現状は個人プランを超少数で使っているという現状ですが、今後もう少し人数を増やして、かつ適切に管理された環境で使うという意味でも、

Claude Codeが出力するOpenTelemetryデータをCloudWatchへ送り、足りない監視部分を補うための構成のお試しをしてみた記事を書いていこうと思います。

※当初はCloudWatchのカスタムダッシュボードで実施する必要があると思ってましたが、2026/07/20付で、AmazonCloudWatch Coding Agent Insightsなるものが公開されて、Claude Code向けの標準ダッシュボードが使えるようになりました！

この記事では個人サブスクリプションのClaude Codeで動作を確認しています。もし企業でTeamプランへ展開する場合は、同じ設定をmanaged-settings.jsonやMDMで各開発端末へ配布することになると思います。
なお、Amazon Bedrock経由でClaudeを呼び出す構成ではありません。

Teamプランで見えるものと見えないもの

Claude Codeの管理機能は、プランごとに同じではありません。
2026年7月26日時点の公式情報をもとに整理すると、次のようになります。

項目	個人Pro／Max	Team	Enterprise
組織のメンバー管理	なし	あり	あり
Claude Code利用分析	なし	ある程度分析可能	詳細に分析可能
アクティブユーザーとセッション	なし	日次分析で確認	分析画面とAnalytics APIで確認
監査ログ	なし	Compliance APIの監査ログなし	Compliance APIで提供
ローカルCLIの会話本文	管理画面には表示されない	標準分析には表示されない	Compliance APIにも含まれない
独自のOTel送信	利用可能	利用可能	利用可能

Teamプランにも利用分析はあります。ただ、あくまで集計機能という理解となります。

プロンプト本文、個々のツール実行、数分前に発生したAPIエラーまで調べたい場合は、別の記録先が必要です。

今回の構成

今回の構成は以下の通り。

また、

Claude Code
AWSマネジメントコンソールへログインできる環境
CloudWatchのメトリクス用APIキーを作成できる権限
ログも保存する場合はCloudWatch Logsを操作できる権限

これらが必要となります。

今回は、まずメトリクスだけでCoding Agent Insightsを動かし、ちゃんとメトリクスが取れていることを確認してからログを追加する流れにします。

料金はどれくらい？

使う上でお金は気になりますよね。GPT-5.6くんに計算させるとこれくらいな様子。

項目	単価の目安	最小構成で発生するか
CloudWatchのメトリクス用APIキー	追加料金なし	発生しない
OpenTelemetryメトリクスの取り込み	`$0.50/GB`	発生
OpenTelemetryメトリクスの保存	取り込み料金に15か月分を含む	追加料金なし
CloudWatchコンソールのPromQL実行	無料	発生しない
CloudWatch Logsへの取り込み	`$0.76/GB`	ログを有効にした場合
CloudWatch Logsの保存	`$0.033/GB-月`	ログを有効にした場合
CloudWatch Logs Insights	`$0.0076/GBスキャン`	検索した場合

とのことで、

メトリクスを月0.1GB取り込む
ログを月0.1GB取り込む
ログを7日間保存する
Logs Insightsで月0.1GBをスキャンする

と仮定すると月、0.1$くらいとのこと。

ここで覚えたほうがいい用語たち

言葉	この記事での意味
OpenTelemetry	アプリの利用状況を、決まった形式で外部へ送るための仕組みのこと。この記事では「Claude Codeから利用データを取り出す仕組み」と認識できればOK
メトリクス	セッション数、トークン量、推定コストなどのデータ
ログ	プロンプト、ツールの実行結果、APIエラーなど、1件ずつ残るログ
OTLP	OpenTelemetryのデータを送るときの通信形式（最後のPはプロトコルのP）
Coding Agent Insights	CloudWatchに最初から用意されている、Coding Agent向けのダッシュボード

用意したもの

必要なものはこちらです。

Claude Code
AWSマネジメントコンソールへログインできる環境
CloudWatchのメトリクス用APIキーを作成できる権限
ログも保存する場合はCloudWatch Logsを操作できる権限

この記事では次の値を使います。

項目	値
AWSリージョン	`ap-northeast-1`
ロググループ	`/claude-code/otel`
ログストリーム	`claude-code`
APIキーの有効期間	`30日`

この記事では、PoC用の管理者権限を持つアカウントで作業しています。

CloudWatch画面からAPIキーを作成すると、専用のIAMユーザーが自動作成され、ポリシーの付与と認証情報の発行が行われます。
そのため、CloudWatchの閲覧・操作権限だけではAPIキーを作成できない場合があります。

権限エラーになった場合は、AWS管理者へ必要な権限の付与を依頼する必要があります。メトリクス用にはCloudWatchAPIKeyAccess、ログ用にはCloudWatchLogsAPIKeyAccessが使用されます。

Step1：メトリクス用APIキーを作る

まず、CloudWatch Metricsへ送信するためのAPIキーを作ります。

AWSマネジメントコンソールでCloudWatchを開きます
左側のメニューを一番下まで確認します
「セットアップ」の中にある「設定」を開きます
CloudWatch設定画面の上部で「アカウント」が選ばれていることを確認します
「グローバル」タブを開きます
グローバル設定のページを下へスクロールします
「テレメトリでリソースタグを有効にする」の下にある「APIキー」欄を探します
APIキー欄の右側にある、オレンジ色の「作成」を押します

9.有効期間に30日を選びます
10. 「生成」を押します
11. 表示されたAPI Key Secretを安全な場所へ一時保存します

※この記事では、この値を<YOUR_CLOUDWATCH_METRICS_API_KEY>と表記します。

API Key Secretは画面を閉じると再表示できませんので注意！

Step2：Claude Codeからメトリクスを送る

自分の端末で試す場合は、~/.claude/settings.jsonへ設定します。

今回は個人サブスクリプションで検証するため、組織管理者向けのmanaged-settings.jsonは使いません。TeamとかEnterpriseだと、管理jsonファイルを編集することになります。

最小構成の設定はこちらです。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_METRICS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_METRICS_ENDPOINT": "https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics",
    "OTEL_EXPORTER_OTLP_METRICS_HEADERS": "Authorization=Bearer <YOUR_CLOUDWATCH_METRICS_API_KEY>",
    "OTEL_METRICS_INCLUDE_SESSION_ID": "false",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_VERSION": "true"
  }
}

それぞれの項目の意味についてもざっくり解説します。

設定	今回の値	何をしているか
`CLAUDE_CODE_ENABLE_TELEMETRY`	`1`	Claude CodeのOpenTelemetry出力を有効にする
`OTEL_METRICS_EXPORTER`	`otlp`	セッション数やトークン量などのメトリクスを、OTLPで外部へ送るようにする
`OTEL_EXPORTER_OTLP_METRICS_PROTOCOL`	`http/protobuf`	メトリクスをCloudWatchが受け付ける方式で送る
`OTEL_EXPORTER_OTLP_METRICS_ENDPOINT`	`https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics`	メトリクスの送信先を、東京リージョンのCloudWatch OTLPエンドポイントに指定する
`OTEL_EXPORTER_OTLP_METRICS_HEADERS`	`Authorization=Bearer ...`	Step1で作ったAPI Key SecretをBearer tokenとして送り、認証する
`OTEL_METRICS_INCLUDE_SESSION_ID`	`false`	セッションごとに変わるIDをメトリクスへ含めず、データが細かく分かれすぎるのを防ぎます。
`OTEL_METRICS_INCLUDE_ACCOUNT_UUID`	`false`	Claudeアカウントの`user.account_uuid`と`user.account_id`をメトリクスへ含めない
`OTEL_METRICS_INCLUDE_VERSION`	`true`	`app.version`を含め、Claude Codeのバージョン別に確認できるようにする

<YOUR_CLOUDWATCH_METRICS_API_KEY>を、Step1で作成した値へ置き換えます。
※<と>も含めて置き換えてください。（こういう時に<`と`>`を残してエラーになっちゃうこと、多いですよね）

なお、OTEL_RESOURCE_ATTRIBUTESという項目も設定できるのですが、これは部署名やチーム名などの独自情報をデータへ追加するための任意設定です。そのため、チーム等関係なく利用状況を確認するだけなら、このままで良いです。

設定を保存したら、起動中のClaude Codeをいったん終了し、もう一度起動します。

各変数の正式な仕様は、Claude Code公式のMonitoringと、AWS公式のSet up Claude Code with a bearer tokenで確認できます。

Step3：Coding Agent Insightsで正しくメトリクスデータが送られたか確認する

設定が正しく読み込まれると、Claude Codeを使ったタイミングでメトリクスが作られます。
テスト用にClaude Codeを起動し、短いプロンプトを1つ実行します。

そして、なんと7/20からCloudWatchにはClaude Code用のダッシュボードが用意されています。
グラフを自分で作成する必要はありません！

CloudWatchを開きます
左側のメニューから「生成 AI オブザーバビリティ」を展開します
「コーディングエージェントのインサイト」を開きます
「Claude Code」タブを選びます

モデルや、Claude Codeが自動的に付けたユーザー情報でも表示を絞り込めます。
部署、組織、コストセンター、チーム、拠点、役割は、今回設定していないため値が表示されないです。
これらの分類が必要になったときだけ、OTEL_RESOURCE_ATTRIBUTESを追加します。

Step4：ログも追加してみる

確認したいこと	メトリクスだけで足りるか	ログが必要か
セッション数やトークン量	足りる	不要
モデル別の推定コスト	足りる	不要
入力したプロンプトの本文	足りない	必要
ツール実行の成功と失敗	足りない	必要
APIエラーの詳しい内容	足りない	必要

細かいプロンプトであったり、bashで何したか、エラーで何が起きたか、等の詳細なログをおいたくなったら、ログを取得するための設定が必要となります。

4-1：ログ用APIキーを作る

ログの送信には、メトリクス用とは別のAPIキーが必要です。

CloudWatchの左側のメニューを一番下まで確認します
「セットアップ」の中にある「設定」を開きます
CloudWatch設定画面の上部で「アカウント」が選ばれていることを確認します
「ログ」タブを開きます
「APIキー」欄の右側にある、オレンジ色の「作成」を押します
有効期間に30日を選び「生成」を押します
表示されたAPI Key Secret（長い文字列）を安全な場所へ一時保存します

4-2：ログの保存先を作る

CloudWatch Logsでは、ロググループがログをまとめるフォルダー、ログストリームがその中の保存先と考えて貰えばOKです。
今回は、Claude Code専用のフォルダーと保存先を1つずつ作ります。

CloudWatchの「ロググループ」を開きます
「ロググループを作成」を押します
ロググループ名へ/claude-code/otelを入力します
ログクラスに「Standard」を選びます
保持期間に7日を選びます
作成したロググループを開きます
「ログストリームを作成」を押します
ログストリーム名へclaude-codeを入力します

参照元：Setting up bearer token authentication - Amazon CloudWatch Logs
AWS公式手順の「Enable bearer token authentication」に掲載されているコマンドを、この記事のロググループ名と東京リージョンに合わせています。

次に、CloudWatch画面上部のCloudShellアイコンを押します。
CloudShellは、ブラウザ上でAWSコマンドを実行できるターミナルです。

CloudShellが開いたら、次のコマンドを貼り付けて実行します。

aws logs put-bearer-token-authentication \
  --log-group-identifier /claude-code/otel \
  --bearer-token-authentication-enabled \
  --region ap-northeast-1

このコマンドを実行することで、作成したロググループがBearer tokenを使った書き込みを受け付けるようになります。

ロググループ一覧の「ベアラートークン認証」が「オン」になれば設定完了です。

4-3：settings.jsonにログ設定を追加する

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_METRICS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_METRICS_ENDPOINT": "https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics",
    "OTEL_EXPORTER_OTLP_METRICS_HEADERS": "Authorization=Bearer <YOUR_CLOUDWATCH_METRICS_API_KEY>",

    "OTEL_METRICS_INCLUDE_SESSION_ID": "false",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_VERSION": "true",

    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_LOGS_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_LOGS_ENDPOINT": "https://logs.ap-northeast-1.amazonaws.com/v1/logs",
    "OTEL_EXPORTER_OTLP_LOGS_HEADERS": "Authorization=Bearer <YOUR_CLOUDWATCH_LOGS_API_KEY>,x-aws-log-group=/claude-code/otel,x-aws-log-stream=claude-code",

    "OTEL_LOG_USER_PROMPTS": "1",
    "OTEL_LOG_ASSISTANT_RESPONSES": "0",
    "OTEL_LOG_TOOL_DETAILS": "0",
    "OTEL_LOG_TOOL_CONTENT": "0",
    "OTEL_LOG_RAW_API_BODIES": "0"
  }
}

<YOUR_CLOUDWATCH_LOGS_API_KEY>には先ほど作成したログ用のAPI Key Secretを入れます。

設定	今回の値	何をしているか
`OTEL_LOG_USER_PROMPTS`	`1`	ユーザーが入力したプロンプトを保存する
`OTEL_LOG_ASSISTANT_RESPONSES`	`0`	Claude Codeの回答本文は保存しない
`OTEL_LOG_TOOL_DETAILS`	`0`	コマンド全文やファイルパスなど、ツールの詳しい引数は保存しない
`OTEL_LOG_TOOL_CONTENT`	`0`	ツールが読み書きした内容は保存しない
`OTEL_LOG_RAW_API_BODIES`	`0`	Claude APIへ送受信した生の本文は保存しない

今回の設定では、プロンプトだけを明示的に保存し、それ以外の本文は保存しないように設定しました。細かい情報が必要であればそれぞれの項目の0を1に変更しますが、含まれる情報には注意が必要です。

4-4：ログが取れているか確認する

短いプロンプトを1つ、Claude Codeに入力します。（お試しなので、こんにちは、とかそれくらいのレベルでOK）
その後、CloudWatchで次の順番に開きます。

「ロググループ」
/claude-code/otel
claude-code
ログイベントでuser_promptと検索

検索結果の行を開き、attributes.promptに先ほど入力した文章があれば成功です。

{
  "body": "claude_code.user_prompt",
  "attributes": {
    "event.name": "user_prompt",
    "event.timestamp": "2026-07-26T04:29:02.093Z",
    "prompt_length": "6",
    "prompt": "こんにちは！"
  }
}

だいぶ省略していますが、こんな感じで、ログが1件1件取得できているはずです。ここまで見えたら、ログの追加設定も完了です。

補足（いい感じのダッシュボードが欲しい場合）

CloudWatchでは、ダッシュボードのレイアウトと検索条件をJSONでまとめて設定できます。
一つずつパネルを作るよりも、完成したJSONを貼り付けるほうが簡単です。

AWS公式ドキュメントでも、ダッシュボードの「アクション」から「ソースを表示/編集」を開き、JSONをテンプレートとして利用する方法が紹介されていますので、参考にしてください。

参照元：Using Amazon CloudWatch dashboards

せっかくClaudeCodeやCodexを使ってる前提ですので、Claude Codeでこういう内容をこのように表示させたい。と対話しながらダッシュボードを作成させることを強くお勧めします。

まとめ

今回行ったことは、次の4つです。

CloudWatchでメトリクス用APIキーを作成
~/.claude/settings.jsonでOpenTelemetryを有効化
Claude CodeのメトリクスをCloudWatchへ直接送信
Coding Agent Insightsでトークン量や推定コストを確認
同様にログもCloudWatchに送信し、ログを確認

まず数値データだけで動作を確認し、保存する情報と閲覧できる人を決めてからログを増やすと、安全性と料金を管理しやすくなります。

ちゃんと管理下で使おうと思うと、TeamプランとOtelの組み合わせがいい感じの塩梅だと思いますので、この方法でサブスク契約＋アカウント管理＋ログ・メトリクス管理ができれば良いと思います。

参考資料