Codex・Claude CodeのCloudWatch設定ガイド ― CLIとデスクトップアプリから送信する

はじめに

CodexやClaude Codeの利用状況をAWSのCloudWatchで確認するには、各端末からメトリクスを送信し、ユーザー・チームの属性を付けます。CLIとデスクトップアプリでは、設定ファイルの場所や環境変数の渡し方に違いがあります。

本記事の対象は、CLIがLinux（WSL2・DevContainer）、デスクトップアプリがWindowsのみです。AWS側の準備を共通化し、Codex CLI、Claude Code CLI、ChatGPTデスクトップアプリのCodex、ClaudeデスクトップアプリのCodeの順に設定方法を説明します。利用する環境の節と、最後の表示確認の節を参照してください。
ダッシュボードの画面例、取得項目、チーム運用と数字の読み方は、前の記事にまとめています。

対象環境と設定先を確認する

CLIの設定とコマンド実行は、WSL2またはDevContainerのLinux環境で行います。設定ファイルは、それぞれのLinux環境のホームディレクトリに配置します。デスクトップアプリの設定はWindows側で行います。
AWSのCodex向け手順とClaude Code向け手順に沿って、東京リージョンのCloudWatch OTLP受信先へ、APIキーのBearer tokenでメトリクスを直接送ります。中継するOpenTelemetry Collectorは用意しません。モデルへの接続は普段の認証を利用し、Amazon Bedrockへ変更する必要はありません。

本記事でいうChatGPTデスクトップアプリは、Codexの設定を使用するローカル実行を対象とします。Claude側はCodeのローカルセッションを対象にします。通常のチャット、Cowork、クラウド・SSH上で動くセッションを同じ手順で計測できるとは扱いません。

共通準備：APIキーと集計用属性を用意する

CloudWatchの送信用APIキーを発行する

必要なのは、CloudWatchのAPIキーを発行できるAWS環境と、ダッシュボードの閲覧権限です。
AWSコンソールでCloudWatchを開き、設定 → グローバル → APIキーから発行します。有効期限を指定し、表示されたAPI Key Secretを安全な場所へ保存してください。送信時に使うのはSecretの値です。

AWSの公式手順では、必要な権限を持つIAMユーザーとサービス固有の認証情報が作成されます。発行権限がなければAWS管理者へ依頼します。このキーはメトリクスの取り込み用であり、ダッシュボード閲覧用の認証情報ではありません。

Bearer tokenは長期認証情報です。AWSは、短期認証情報を利用できる環境ではそちらを推奨しています。キーを配布する場合は有効期限と更新担当を決め、完成済みの設定ファイルを共有リポジトリへ置かないでください。
CloudWatch側の料金は、使用する機能とリージョンの条件をCloudWatch料金ページで確認します。

同じ利用者・所属には同じ属性値を使う

以下の設定例は架空の値です。実運用では組織内で決めた値へ置き換えます。属性は、送信元の所属を表すリソース属性として渡します。RDとR&Dのような表記揺れがあると別の値になるため、配布前に表記を揃えます。
必要に応じて、user.name、cost_center、location、role、managerも追加できます。CLIとアプリで同じ利用者のIDを揃えると、所属単位で確認する際の混乱を減らせます。

Codex CLIの設定

config.tomlに送信先を統合する

Codexのユーザー設定 ~/.codex/config.toml へ、次の内容を統合します。CODEX_HOME を変更している場合は、その配下の設定を確認してください（OpenAI：設定・状態の保存先）。

[otel]
environment = "demo"

[otel.metrics_exporter]
otlp-http = { endpoint = "https://monitoring.ap-northeast-1.amazonaws.com/v1/metrics", protocol = "binary", headers = { "Authorization" = "Bearer YOUR_API_KEY" } }

[analytics]
enabled = true

YOUR_API_KEY をAPI Key Secretへ置き換えます。すでに同じTOMLテーブルがある場合は、重複して追加せず、既存の項目を残して統合してください。URLには /v1/metrics まで含めます。
OpenAIの設定リファレンスでは、otel.metrics_exporter はメトリクス用です。ログ用の otel.exporter、トレース用の otel.trace_exporter とは別の項目になります。

末尾の [analytics] はAWSの設定例には含まれていませんでしたが、本チームの環境では、enabled = true を明示的に設定すると送信できました。ただし、すべてのバージョンでこの設定が必要とは限りません。OpenAI公式のMetricsの説明では、収集の有効・無効を切り替える設定として案内されています。

APIキーを環境変数に保存し、Authorizationヘッダーに Bearer ${CLOUDWATCH_API_KEY} のように記載して、実際のキーを読み込ませる方法もあります。ただし、Codexのバージョンによっては、${CLOUDWATCH_API_KEY} が環境変数の値に置き換わらず、文字列のまま送信される場合があります（AWS：Codexのメトリクス送信設定）。そのため、本記事ではAWSの手順に合わせ、YOUR_API_KEY を実際のAPIキーの値に置き換えて設定します。
この方法ではconfig.tomlにAPIキーが保存されるため、ほかのユーザーがファイルを読めないようにします。ターミナルで chmod 600 ~/.codex/config.toml を実行すると、所有者だけが読み書きできるようになります。

起動するシェルに属性を設定する

ターミナルで、Codexを起動する前に次を実行します。

export OTEL_RESOURCE_ATTRIBUTES="user.id=demo-user,user.email=demo-user@example.com,team.id=rd,department=engineering,organization=example"

Bashで設定を永続化したい場合は、上記の export 行をLinux側の ~/.bashrc に追記します。保存後に source ~/.bashrc を実行すると、現在のシェルにも反映されます。次回からは、新しいターミナルを開くたびに属性が設定されます。

すでにCodexが動いている場合は終了し、属性を設定したシェルから codex で新しく起動します。ファイルの読み取りや編集などの作業を数ターン行い、実行時刻を控えてください。
本チームの環境では、属性を変更した後にapp-serverデーモンの再起動が必要でした。起動済みのデーモンが変更前の環境変数を保持していたためと考えられます。作業中のセッションを終了してから、属性を設定したシェルで次を実行しました。

codex app-server daemon restart

デーモンの構成はバージョンや起動経路によって異なります。また、本チームの検証環境では再起動が必要でしたが、すべてのCLI環境で必要とは限りません。

Claude Code CLIの設定

ユーザー設定のenvに送信先と属性をまとめる

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 YOUR_API_KEY",
    "OTEL_RESOURCE_ATTRIBUTES": "user.id=demo-user,user.email=demo-user@example.com,team.id=rd,department=engineering,organization=example"
  }
}

YOUR_API_KEY と属性値を置き換えます。すでにenvやほかの項目がある場合は、それらを残して追記してください。上記はメトリクス用の送信設定です。
Claude Code公式のMonitoringでは、シェルの環境変数、ユーザー設定、管理設定で送信先を指定できます。一方、リポジトリ内の .claude/settings.json や .claude/settings.local.json に記載した送信先などは無視されます。個人で試す場合は、ユーザー設定に記載してください。

本チームのCLI環境では、シェルで環境変数を設定するより、ユーザー設定のenvに記載するほうが安定して送信できたため、この方法を採用しました。APIキーを含むファイルはGitで共有せず、ターミナルで chmod 600 ~/.claude/settings.json を実行して権限を制限します。

新しいセッションで送信を確認する

設定保存後に起動済みのClaude Codeを終了し、claude で起動し直します。ファイルの読み取り・編集などの作業を数ターン行い、実行時刻を記録します。
メトリクスの送信間隔は既定で60秒です（Claude Code：Monitoringの設定手順）。数分待ってから、最後の節の手順に沿ってCloudWatchの表示を確認します。

ChatGPTデスクトップアプリのCodexを設定する

Windows側のconfig.tomlとユーザー環境変数へ、送信先・APIキー・ユーザー・チーム属性を設定します。

アプリが使うCodexの設定ファイルを編集する

Codex CLIの節に掲載したconfig.tomlの送信設定を、アプリが参照するユーザー設定へ統合します。Windowsアプリの設定は %USERPROFILE%\.codex に保存されます。WSLでCLIを動かしていても、Linux側の既定の保存先 ~/.codex にある設定は、Windowsアプリと自動では共有されません。

OpenAIのWindows向けガイドには、この保存先の違いが説明されています。WSLの設定がある場合でも、Windows側の設定を確認してください。設定先を変えるためだけに認証情報や履歴をまとめて移す必要はありません。
CODEX_HOME を変更している場合は、Windowsアプリがその設定先を参照しているか確認します。

Windowsではエクスプローラーのアドレス欄に %USERPROFILE%\.codex と入力し、config.tomlをエディターで開きます。送信先・APIキー・analyticsを確認し、不足している項目をCodex CLIの設定例から追加してください。

Windowsのユーザー環境変数に属性を登録する

Windowsでは、ユーザー環境変数に属性を登録します。通常のPowerShellを開き、次を一度実行してください。Userスコープへの登録なので、管理者として起動する必要はありません。例のID・メールアドレス・所属は自分の環境の値へ置き換えます。

[Environment]::SetEnvironmentVariable(
  'OTEL_RESOURCE_ATTRIBUTES',
  'user.id=demo-user,user.email=demo-user@example.com,team.id=rd,department=engineering,organization=example',
  'User'
)

Microsoftの環境変数の永続化手順に従ってUserスコープを指定すると、環境変数が現在のWindowsユーザーの設定として保存され、次回以降のログインでも使えます。Linux側のCLIに設定した環境変数とは別に登録してください。
登録後は、Windowsの「環境変数を編集」を開き、「ユーザー環境変数」にOTEL_RESOURCE_ATTRIBUTESと設定した値が表示されているか確認します。システム環境変数ではなく、本人のユーザー環境変数を確認してください。

ChatGPTアプリを完全に終了して起動し直す

ユーザー環境変数を登録したら、設定を反映するためにChatGPTアプリを完全に終了して起動し直します。ウィンドウを閉じるだけではプロセスが残ることがあるため、タスクマネージャーで終了させます。

1. 作業中のファイルを保存し、アプリの処理を終了します。
2. タスクマネージャーを開きます。
3. ChatGPTアプリを選び、右クリックした後に「タスクの終了」で完全に終了させます。ChatGPTのプロセスが残っていないことを確認してください。
4. ChatGPTアプリを起動し直します。
5. 新しいローカルセッションで数ターン作業し、CloudWatchへの到着と属性を確認します。

ClaudeデスクトップアプリのCodeを設定する

Windows側のユーザー設定settings.jsonに、送信先とユーザー・チーム属性を設定します。対象はCodeのローカルセッションです。

ユーザー設定のsettings.jsonを開く

Claudeのデスクトップ向け公式ガイドでは、同じ実行環境で動くCLIとデスクトップアプリは、ユーザー設定を共有すると説明されています。本記事ではCLIをLinux、デスクトップアプリをWindowsで動かすため、Windows側の %USERPROFILE%\.claude\settings.json に設定します。
Windowsではエクスプローラーのアドレス欄に %USERPROFILE%\.claude と入力し、settings.jsonをエディターで開きます。WSL2やDevContainerでCLIを設定した場合も、Windows側のファイルに設定があるかを確認してください。ファイルがなければ、ユーザー設定として作成します。

envへ送信先と属性を統合する

Windows側の %USERPROFILE%\.claude\settings.json に、次の内容を設定します。新しくファイルを作る場合は、全体を貼り付けてください。既存のファイルにenvがある場合は、その中へ次の6項目を追加・更新し、ほかの設定は残します。

{
  "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 YOUR_API_KEY",
    "OTEL_RESOURCE_ATTRIBUTES": "user.id=demo-user,user.email=demo-user@example.com,team.id=rd,department=engineering,organization=example"
  }
}

YOUR_API_KEY は、共通準備で発行したCloudWatchのAPI Key Secretに置き換えます。Authorization=Bearer の部分は残してください。送信先は東京リージョンの例です。別のリージョンを使う場合は、URL内の ap-northeast-1 を変更します。
OTEL_RESOURCE_ATTRIBUTES の demo-user と demo-user@example.com は本人のIDとメールアドレスに、rd、engineering、example はチーム・部門・組織の値に置き換えます。属性名と、各属性を区切るカンマはそのまま使い、CLIと同じ利用者・所属には同じ値を設定してください。
CLAUDE_CODE_ENABLE_TELEMETRY、OTEL_METRICS_EXPORTER、OTEL_EXPORTER_OTLP_PROTOCOL は、例の値のまま設定します。編集後はsettings.jsonを保存してください。

Claudeでは、settings.jsonのenvに設定するため、Windowsのユーザー環境変数へ別途登録する必要はありません。保存後にアプリを起動し直し、CloudWatchで送信を確認します。
組織の管理設定がある場合は、それがユーザー設定より優先されます。公式の管理設定によるMonitoringの手順は、チーム全体へ送信先を配布する場合の選択肢です。

ローカルセッションを新しく開始する

1. 設定を保存し、Claudeデスクトップアプリを終了して起動し直します。
2. Codeタブを開き、実行環境でローカルを選びます。
3. 検証用のフォルダでファイルの読み取りや編集などの作業を数ターン行い、時刻を記録します。
4. CloudWatchのClaude Codeタブで、その時間帯のデータとユーザー・チーム属性を確認します。

クラウドやSSHを選ぶと、セッションは別のマシンで動きます。ローカル端末へ配置したファイルだけでは、その環境の送信設定は完了しません。

CloudWatchの表示確認と、表示されない場合の調べ方

送信元を一つずつ確認する

東京リージョンのCloudWatchで、生成AIオブザーバビリティ → コーディングエージェントのインサイトを開きます。CodexかClaude Codeのタブを選び、作業した時間帯が表示範囲に含まれていることを確認します。AWSの表示確認手順では、通常は数分で表示されるとされています。

最初に自分のデータが表示されているか確認し、次にUser・Teamで絞り込めるかを確認します。画面例は前の記事にあります。

CLIとアプリを同時に動かすと、どちらの設定で届いたデータかを判別しにくくなります。検証時は片方を止め、環境ごとに時間帯を分けて作業してください。設定ファイルの場所、OS、バージョン、実行時刻、選んだ実行環境を記録します。
または、CLIとデスクトップアプリを区別したい場合は、例えばCLIに location=cli、デスクトップアプリに location=desktop を追加設定し、CloudWatchのLocationで送信元を絞り込む方法も考えられます。

データの到着と属性の反映を分けて調べる

Codexの既存検証では、config.tomlの [otel] に書いたenvironmentは、画面左のEnvironmentの選択肢には表示されませんでした。設定名とダッシュボードの表示名が似ていても、同じ属性として扱われるとは限りません。
まずフィルターを外し、データが届いていないのか、フィルターの条件に合っていないのかを切り分けます。送信設定を変更した場合は、送信元のアプリやCLIを起動し直し、新しいセッションで再確認してください。

まとめ

CloudWatchの受信先とユーザー・チーム属性を揃えることが、利用状況を集計するための共通準備です。Codex CLIはconfig.tomlと起動時の環境変数、Claude Code CLIはユーザー設定のenvで設定します。
WindowsのChatGPTアプリでは、Windows側のconfig.tomlとユーザー環境変数を設定し、タスクマネージャーでChatGPTアプリを完全に終了して起動し直します。WindowsのClaudeのCodeでは、Windows側のユーザー設定settings.jsonへ送信設定を統合します。
表示された数字の読み方と、チームへの配布・認証管理については、前の記事を参照してください。

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。

1. 無料診断パック：業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
2. 検証（PoC）パック：診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
3. コンサルティングサービス：生成AI導入戦略の策定から運用体制構築までを包括的に支援します。
4. Plain RAG：社内文書をもとに回答し、社内問い合わせを効率化するAIチャットパッケージです。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム

Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。