生成AI関連
コーディングエージェントを従量課金で走らせる前に ― トークンとコストを抑える節約テクニック全体地図…
Claude CodeやCodexをチームで使い始めると、「どのチームで利用が進んでいるか」「トークン使用量はどの程度か」を把握したくなります。各自の画面で使用量を確認するだけでは、チーム全体の傾向を追うのに手間がかかります。
本記事では、利用データを集める仕組みと、Codex・Claude Codeのダッシュボードで確認できる項目を紹介します。チームへ導入する際の設定配布と、数字を読むときの注意点も整理します。
以前の記事では、トークンとコストを抑える前提として「まず測る」ことに触れました。今回は、その計測をチームへ広げるための具体的な方法です。
チームの利用状況を集めるには、OpenTelemetryとCloudWatch Coding Agent Insightsを組み合わせます。OpenTelemetryはエージェントの利用データを外部へ送る仕組みで、CloudWatch Coding Agent InsightsはそのデータをAWS上で集計・表示するダッシュボードです。CodexとClaude Codeの両方に、AWSの公式セットアップ手順が用意されています。
データは次の流れで集まります。
本記事で紹介する構成では、CodexやClaude CodeからCloudWatchの受信先へ直接メトリクスを送ります。この方式では、中継するOpenTelemetry Collectorを別途用意する必要はありません。
また、モデルへの接続と利用データの送信は独立しています。テレメトリをAWSへ送るために、モデルの接続先をAmazon Bedrockへ変更する必要はありません（AWS：Codexのセットアップ方式）。
OpenTelemetry（OTel）は、ソフトウェアの動作を観測するためのデータを生成・収集・出力する、標準仕様やツールの集まりです。データの保存先や可視化画面そのものは、CloudWatchなどのサービスが担います。
扱うデータには、主に次の種類があります（OpenTelemetry公式：What is OpenTelemetry?）。
| 種類 | 表すもの | Coding Agentで考えた例 |
|---|---|---|
| メトリクス | 回数・量・時間などの数値 | トークン使用量、ツール呼び出し回数 |
| ログ | 個々の出来事の記録 | ツール実行やAPIエラーのイベント |
| トレース | 一連の処理の流れや所要時間 | 一つの処理の中で、どの呼び出しに時間がかかったか |
広く「利用ログを集める」と呼ぶこともありますが、本記事で扱うのはメトリクスの送信です。会話本文を保存する設定とは分けて考えます。送信には、OpenTelemetryのデータ転送プロトコルであるOTLPを使います。
CloudWatch Coding Agent Insightsは、Coding Agentの利用状況を確認するために用意されたダッシュボード群です。期待される形式のメトリクスが届くと表示されるため、最初からグラフを一つずつ作る必要はありません。
画面にはCodex、Claude Code、Copilotといったエージェントごとのタブがあり、ユーザーやチーム、部門などの属性で利用状況を確認できます。ただし、表示される指標はエージェントによって異なります（Codexの計測対象、Claude Codeの計測対象、Copilotの計測対象）。
| エージェント | AWSの設定ガイドが挙げる主な計測対象 |
|---|---|
| Codex | トークン使用量、ターンごとの所要時間、APIリクエスト、ツール呼び出し、承認 |
| Claude Code | トークン使用量、セッション、コード編集、ツール呼び出し、コスト |
| Copilot | トークン使用量、リクエスト、ツール呼び出し、所要時間 |
ダッシュボードはメトリクス名と属性の配置にも依存します。モデル名などの属性と、送信元を識別するリソース属性を区別し、ユーザー・チームの情報は公式ガイドに沿ってリソース属性として送ります。独自にメトリクス名を変えると、標準画面に表示されなくなる場合があります。
ここからは、本チームが2026年10月2日に取得したCloudWatchの画面を紹介します。Codex CLI 0.159.3、Claude Code CLI 2.1.287でメトリクス送信を確認しました。
CodexとClaude Codeのダッシュボードは縦に長いため、それぞれ上部と下部に分けて画像を紹介します。
上部には総トークン数、APIリクエスト数、利用者数、会話ターン数、キャッシュヒット率の欄があります。今回の画面では総トークン数が517K、キャッシュヒット率が97.4%と表示されています。トークン種別はInput、Output、Cached Input、Reasoning Outputに分かれています。
左側のFilter byは対象を絞る操作、Group byはグラフを分ける単位の選択です。画面例ではUserでグループ化し、二つのユーザーの凡例が表示されています。
ユーザー・チーム・部門・組織といった属性の値は、利用者側で設定できます。導入前に、どの単位で絞り込み、比較したいかを決め、チーム内で値の付け方を揃えることが重要です。同じチームでも表記が異なると別の値として扱われるため、所属名やIDのルールを決めておくと、意図した単位で利用量の偏りや変化を調べられます。
下部では、apply_patchやexec_commandなどのツール呼び出し、承認判断の内訳、会話ターンの推移を確認できます。ターンの所要時間、最初のトークンまでの時間、ツール呼び出しの所要時間は、p50・p90・p99の時系列で表示されます。APIの成否・所要時間の欄もありますが、今回の期間にはデータがありませんでした。
p50・p90・p99は、所要時間を短い順に並べたときの50・90・99パーセンタイルです。通常の待ち時間と、長くかかった処理の傾向を分けて見る材料になります。画面に欄があっても、対応するデータが届かなければ値は表示されません。
Claude Codeの上部には、総トークン数、コスト、利用者数、セッション数、キャッシュヒット率、稼働時間の欄があります。今回の画面では総トークン数が512K、利用者数とセッション数がそれぞれ1、キャッシュヒット率が99.7%と表示されています。
Group byはDepartmentを選び、部門別グラフの凡例にはR&Dが表示されています。Filter byにはModel、Organization、Department、Cost Center、Location、Team、User、Roleが並びます。所属や役割の属性を付けると、同じ画面で対象を切り替えて確認できます。
下部では、部門別のコストや稼働時間、Input・Output・Cache Read・Cache Creationに分かれたトークン使用量を確認できます。追加・削除行数やコミット・プルリクエスト数に加え、編集対象の言語、コード編集時の判断、Edit・Writeなどの編集ツールの内訳も表示されます。今回の画面では、編集対象はMarkdown、編集時の判断はacceptでした。
Claude Codeは、追加・削除行数や、Claude Code経由で作成したコミット・プルリクエストなどを計測します（Claude Code公式：計測項目と定義）。ただし、担当者が別のツールで行った作業まで、すべて集まるわけではありません。
画面のDeveloper Productivityという見出しは、表示項目の分類です。行数・コミット数・稼働時間の値だけで、開発者の生産性を判定できるわけではありません。コストの表示と契約上の請求額も、後述するように分けて確認します。
今回の画面では、どちらもトークン使用量やキャッシュ利用、ユーザー・チーム別の利用状況を確認できます。Codexは、ターンやツール呼び出しの所要時間、承認判断など、エージェントの処理状況を詳しく見る項目が中心です。Claude Codeは、コストや稼働時間に加え、コードの追加・削除やコミットなど、編集作業の傾向を見る項目が揃っています。同じCloudWatch上でも表示項目や指標の定義が異なるため、両者の数値をそのまま比較せず、それぞれの利用傾向を追う画面として使います。
一人分の表示を確認できたら、同じ送信先へチームのデータを集めます。配布する設定は、全員で共有する部分と、メンバーごとに作る部分に分けます。
| 分類 | 設定例 | 配布時の扱い |
|---|---|---|
| 全員に共通 | 送信先、リージョン、プロトコル、組織名 | 秘密情報を除いたテンプレートで管理 |
| 所属ごと | チームID、部門、コストセンター | 組織で決めた値を設定 |
| 個人ごと | ユーザーID、メールアドレス | 本人の値を反映 |
| 認証情報 | 送信用APIキー | テンプレートと分けて受け渡す |
小規模なチームなら、管理者が共通テンプレートと適用手順を用意し、メンバーが個人の値を反映する方法から始められます。APIキーを埋めた完成済みファイルを共有リポジトリへ置く運用は避けます。
Bearer tokenを配る場合は、キーの発行・配布対象、有効期限、更新担当を決めます。新しいキーを反映してデータの到着を確認してから旧キーを無効化すれば、送信が止まっていないことを確かめながら更新できます。詳細はAWS：APIキーのローテーションを確認してください。
長期認証情報を各端末へ配りたくない組織には、SSOを使う別の構成もあります。AWSのCodex向け組織展開ガイドでは、企業の認証基盤、Amazon Bedrockへのアクセス、各端末のCollectorを組み合わせます。Collectorが利用者の属性を付け、短期認証情報で署名してCloudWatchへ送信します。
推論先や端末の管理まで変わるため、今回の直接送信にSSOを足すだけでは済みません。まず少人数で取得項目と表示を確認し、その結果をもとに配布・認証の方式を選ぶと、必要な範囲を判断しやすくなります。
複数人に設定を配布する際は、次の点に注意が必要です。
全社へ展開すると、自力で設定できない人や、設定の時間を取れない人も出てきます。手順を配るだけでは行き渡らないため、設定の自動化や問い合わせ窓口、完了状況を確認する仕組みも併せて用意します。
ダッシュボードは、利用が増えている場所や、詳しく調べるべき変化を見つける手掛かりになります。ただし、数字の意味は、送信された指標と集計方法に左右されます。
今回の構成で集計できるのは、CodexやClaude Codeが送信する利用データです。ChatGPTやClaudeの通常のChatでの利用は集計対象に含まれません。そのため、このダッシュボードだけではチーム全体の生成AI利用量を把握できません。
さらに、送信設定が済んでいない端末や、送信が止まっている端末の利用も集計から漏れます。データがない人を「使っていない人」と判断する前に、設定の適用状況とデータの到着を確認する必要があります。
Chatも含めて利用状況を確認したい場合は、各サービスの公式Analyticsを併用します。OpenAIには、ChatGPTのワークスペース全体の利用・定着を見るWorkspace analyticsと、Codexの利用を見るCodex analyticsがあります。両者は対象範囲が異なり、利用できる画面や項目は契約プランや権限によって変わります（OpenAI：Workspace analytics）。
ClaudeのTeam・Enterpriseプランでは、権限を持つ管理者がAnalyticsのClaude ChatとClaude Codeの各画面で、チャットの利用状況やコーディング作業の傾向を確認できます。たとえばClaude Chatでは、日別のチャット数や利用したユーザーの割合などが表示されます。利用できる画面や項目は、契約プランや権限によって変わります（Anthropic：Team・Enterpriseの利用分析）。
各サービス内の利用状況は公式Analyticsで確認し、CodexとClaude Codeの利用データを共通のユーザー・チーム属性でAWS上に集めたい場合はCloudWatchを使う、という使い分けが考えられます。併用する際は、対象ユーザー、期間、指標の定義を確認し、各画面の数値をそのまま足し合わせないようにします。
| 見るもの | 調べられること | 追加で必要な情報 |
|---|---|---|
| ユーザー・チーム別の利用 | 利用量の偏りや変化 | 対象者数、設定済み端末、担当業務 |
| モデル・トークン種別の内訳 | どのモデルや種類で消費が増えたか | 作業内容、キャッシュ、長い会話の有無 |
| 所要時間やツール呼び出し | 作業中の待ち時間や呼び出し傾向 | 実行した処理、対象リポジトリ、成功・失敗の記録 |
たとえば、あるチームの利用量が少ない場合、未導入なのか、対象業務が少ないのか、送信が止まっているのかは、その数字だけでは分かりません。設定が行き渡った範囲を確認したうえで、担当者に利用場面を聞く材料として使います。
トークン使用量やツール呼び出し回数が多くても、成果が大きいとは限りません。難しい調査をしていた可能性もあれば、修正のやり直しが続いていた可能性もあります。生成したコードの量から、品質やレビュー負担までは判断できません。
導入効果を確認するなら、対象業務を揃えたうえで、作業時間、レビューの手戻り、完了したタスクなどの記録を併せて見ます。個人のトークン数をそのまま生産性の順位に置き換える使い方には、根拠が不足します。
また、コストが表示される場合も、その算出方法と契約上の請求は分けて確認します。特に定額契約では、トークン数が増えても、その分だけ追加で請求されるとは限りません。CodexとClaude Codeで取得項目も異なるため、エージェント間の単純比較にも注意が必要です。
今回のメトリクス送信だけでは、会話の内容や、個々の変更が適切だったかも分かりません。詳しい原因調査には別の記録が必要です。チームへ配布する際には、集める属性、閲覧できる人、利用目的をメンバーに説明しておくと、数字をどう使うかを共有できます。
OpenTelemetryとCloudWatch Coding Agent Insightsを組み合わせると、各端末のCoding Agentが計測したデータを、AWS上で確認する構成を作れます。CodexでもClaude Codeでも、送信設定とユーザー・チームの属性を揃えることが導入の出発点になります。
チームに広げる際は、共通テンプレートと個人属性・認証情報を分け、設定の適用先と更新方法まで決めます。そして表示された数字は、期間や集計方法を確認し、実際の作業と照合して読み取ります。
まずは一人分の操作とメトリクスの対応を確かめ、次に数人でチーム別の表示を確認します。その順序で進めると、運用で見たい指標と、追加で必要な集計を具体化できます。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
