はじめに
こんにちは、これを読んでるみなさんは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/otelclaude-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をテンプレートとして利用する方法が紹介されていますので、参考にしてください。
せっかくClaudeCodeやCodexを使ってる前提ですので、Claude Codeでこういう内容をこのように表示させたい。と対話しながらダッシュボードを作成させることを強くお勧めします。
まとめ
今回行ったことは、次の4つです。
- CloudWatchでメトリクス用APIキーを作成
-
~/.claude/settings.jsonでOpenTelemetryを有効化 - Claude CodeのメトリクスをCloudWatchへ直接送信
- Coding Agent Insightsでトークン量や推定コストを確認
- 同様にログもCloudWatchに送信し、ログを確認
まず数値データだけで動作を確認し、保存する情報と閲覧できる人を決めてからログを増やすと、安全性と料金を管理しやすくなります。
ちゃんと管理下で使おうと思うと、TeamプランとOtelの組み合わせがいい感じの塩梅だと思いますので、この方法でサブスク契約+アカウント管理+ログ・メトリクス管理ができれば良いと思います。
参考資料
- Claude Code usage analytics
- Teamプランについて
- Enterpriseプランの請求方法
- Claude Code Monitoring
- CloudWatch Coding Agent Insights
- Claude CodeをBearer tokenでCoding Agent Insightsへ接続する
- CloudWatch OTLPエンドポイント
- CloudWatch MetricsのBearer token認証
- CloudWatch LogsのBearer token認証
- CloudWatchでPromQLを使用する
- OpenTelemetryメトリクスの料金と保存期間
- Amazon CloudWatchの料金




