Claude CodeのGoogle Cloudコスト管理 — 予算・追跡・ROIの組み方
Google Cloud上のClaude Codeを、専用プロジェクトと請求予算で囲い、OpenTelemetryで追跡し、PR指標でROIを示す。制御・追跡・証明の3段で組む手順をまとめます。
Google Cloud上のClaude Codeの費用は、制御・追跡・証明の3段で組むと管理しやすくなります。Google Cloud側の請求予算とクォータで外枠を作り、OpenTelemetryで使われ方を見て、PRなどの成果指標と並べて投資対効果を示す流れです。
先に分かれ目を言うと、Google Cloudの予算アラートだけでは使用を止められません。止めるには別の仕組みが要ります。以降は、どの道具がどの段を受け持つかを順に見ていきます。
3段の役割分担
制御(Control)
使いすぎを防ぎつつ、使う人を締め出さない外枠を作る段です。
追跡(Track)
請求書が届く前に、誰がどのモデルでどれだけ使ったかを見る段です。
証明(Prove)
使ったトークンが何の成果になったかを、基準値と比べて示す段です。
なぜGoogle Cloudの請求だけでは足りないのか
Google Cloud上のClaudeは従量課金です。請求額は、開発者がどれだけClaudeを使ったかの読み出しにあたります。Claude Codeは1回の依頼で複数手順をこなし、ファイルの読み込み、ツールの実行、タスク全体にわたる推論でトークンを使います。チャットより1タスクあたりの消費が大きくなる理由です。
請求額を決める要素は2つだけです。タスクが消費するトークン数と、処理するモデルの単価になります。経路ごとの単価差はClaudeの提供経路別の料金比較に譲り、ここでは管理の仕組みに絞ります。
BedrockやGoogle CloudなどのクラウドでClaude Codeを使うと、費用はクラウド側のアカウントに従量で請求され、上限などの管理はクラウドの請求コンソールにあります。クラウドからAnthropicへ利用状況は送られないため、Anthropic側の分析ダッシュボードにはこの利用分が載りません。ユーザー別の帰属には、次の3つが選べます。
- OpenTelemetryで各開発者のマシンから自前の監視基盤へ送る
- 自前でホストするClaude apps gatewayを置く
- すべての通信をプロキシ経由にして、キー単位で支出を追う
この記事は、1つ目と2つ目を軸にGoogle Cloudの道具と組み合わせます。
制御: 外枠はGoogle Cloud、個人別の上限はgateway
Google Cloudには、Claudeの支出に使える標準の道具が6つあります。
| 道具 | 受け持つこと |
|---|---|
| プロジェクト単位の請求 | 受け持つことClaude Code専用のプロジェクトを用意し、費用を切り分ける |
| 請求予算とアラート | 受け持つことしきい値を超えたら通知する |
| 支出上限(Preview) | 受け持つことサービス単位の予算を強制し、手動で解除もできる |
| BigQueryエクスポート | 受け持つことClaudeの費用をほかのクラウド費用と並べて分析する |
| クォータ | 受け持つことモデルファミリーとエンドポイントのロケーションごとに、1分あたりのリクエスト数・入力トークン数・出力トークン数を制限する |
| プロビジョンドスループット | 受け持つこと固定料金で容量を確保し、従量課金の代わりにする |
最初の一手は、専用プロジェクトを切ることです。Claude Codeの費用がほかのワークロードと混ざらないので、予算もエクスポートも単純になります。
予算アラートは「知らせる」だけと理解しておく
請求予算は、実績または予測の費用が、設定した割合のしきい値を超えたときにメールで通知します。新しい予算を作ると、実績に対して50%・90%・100%のしきい値が初期値で入ります。通知先は請求管理者や、単一プロジェクトの予算ならプロジェクトオーナーに設定でき、Pub/Sub経由でSlackなどへ流すことや、プロジェクトの請求を自動で無効化する処理にもつなげられます。
ただし、アラートのみの予算はGoogle Cloudの使用や支出を自動で止めません。アラートは対応を促す合図であり、止める力はないという点が、運用設計の出発点です。止めたいなら、Preview段階の支出上限か、後述のgatewayの上限を併用する形になります。
クォータと予約容量は費用ではなく流量の道具
クォータは1分あたりの流量を絞る仕組みで、月額を直接は縛りません。プロビジョンドスループットは、固定料金で容量を押さえる選択肢です。どちらも「いくらまで」ではなく「どれだけ流すか」の調整にあたるので、予算アラートや上限とは役割が重ならない道具として並べておくと整理しやすくなります。
個人別・グループ別の上限はClaude apps gatewayで置く
Claude apps gatewayは、Claude CodeとGoogle Cloud上のClaudeの間に置く、自前でホストするサービスです。開発者はGoogle WorkspaceなどのIdPでサインインするため、すべてのリクエストに検証済みのIDが付きます。これにより、IdPグループごとのモデル許可リストと、ユーザー・グループ・組織単位の日・週・月の支出上限が置けます。
上限の設定そのものはgatewayの支出上限の設定記事が扱っています。ここでは運用の設計だけ押さえます。
- グループと組織の上限は、共有の枠ではなく、各メンバーが受け継ぐ開発者ごとの初期値になる
- 上限に達するとgatewayは429を返し、期間のリセットか管理者による引き上げまで止める
- 引き上げは、gatewayのAdmin APIでスクリプト化でき、チケットのワークフローに載せられる
- 75%と95%を超えると、Claude Code側が開発者にCLI内で警告する。Google Cloudの請求アラートは管理者向けで、宛先が違う
締め付けるより、道筋を作る
注意点として、費用の高いセッションは悪いセッションとは限りません。新しいワークフローを試す利用者は費用が高くなりやすく、そのぶん成果も大きくなりがちです。無駄が出やすいのは、むしろ「重い利用者の長い中間層」だとされています。毎日の定型作業に上位モデルを使っていたり、忘れた定期タスクが動き続けていたりする状態です。
だから最初に効くのは、上限の金額よりモデルの既定値です。gatewayは許可リストをサーバー側で毎回強制し、既定モデルを決めておくと、ほとんどの利用者はそのまま使います。切り替える人は理由があって切り替えているため、既定値と許可リストを組み合わせる運用が勧められています。
追跡: 請求書が届く前に使われ方を見る
追跡は3本の経路で組みます。Cloud BillingのBigQueryエクスポート、Claude CodeのOpenTelemetry、gatewayのAdmin APIです。
BigQueryエクスポートで請求を分解する
Google CloudのBillingをBigQueryへエクスポートすると、ClaudeのSKUをモデルとトークン種別で絞り込めます。Claudeの費用が、ほかのクラウド費用やAI費用と同じ表に並びます。月次の請求の中身を見る用途に向いています。
OpenTelemetryで使われ方を見る
請求は「いくら」を教えますが、「誰が・何に」は教えません。Claude CodeはOpenTelemetryを有効にすると、セッション数、アクティブ時間、コード行数、コミット、PR、トークンと費用を、ユーザー・チーム・モデル別に出力します。最近のリリースでは、スキル・プラグイン・エージェント・MCPサーバー別の内訳も出ます。
有効化の最小構成は次のとおりです。
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,cost_center=eng-123"OTEL_RESOURCE_ATTRIBUTESに入れたキーは、すべてのメトリクスとイベントに付きます。部署やコストセンターで絞り込めるので、社内の費用配賦に使えます。値に空白は使えません。空白が要るなら、アンダースコアかキャメルケースに置き換えます。キーごとに時系列が増えるため、値の種類が多すぎると監視基盤の保管コストが上がる点にも注意が要ります。
gatewayを使う場合は、端末ごとの設定が要りません。gatewayに送信先を設定すると、サインインした開発者のテレメトリが有効になり、IdPで検証したメールとグループが自動で付きます。端末側の自己申告に頼らないので、帰属の信頼度が上がります。
送信先はCloud Monitoringのほか、GrafanaやSplunkでも使えます。Cloud Monitoring向けには、Claude Codeの利用状況をまとめた既製のダッシュボードテンプレートがあり、コンソールから複製できます。独自に組むなら、Claude CodeのOTelクイックスタートでCloud LoggingとCloud Monitoringへ送れます。ログはイベント種別ごとに分割されたBigQueryテーブルへも流せ、開発者別・モデル別の支出を引くSQLが付属します。
上限に当たった回数を、申請フローにつなぐ
ダッシュボードで見ておきたい指標の1つが、gatewayの上限でブロックされたリクエスト数です。この数字をチケット管理と結び、開発者が引き上げを申請する経路を作っておくと、上限が行き止まりになりません。
OTelのプロンプト本文は、機微な内容を含みうるため既定では記録されません。利用者が何を作ろうとしているかを知りたい場合は、明示的にオプトインします。
証明: 費用を成果と並べる
証明の段は、使った量を成果に結びつける作業です。見る軸は、利用状況・開発者の満足度・影響の3つです。
ROIを測る3つの軸
利用状況
有効化したユーザー数と、週次・日次の利用。使い込みの深さと定着、ヘビーユーザーの特定にOTelのデータを使います。
満足度
導入前後の短いアンケートと、継続的な聞き取り。体感の時間短縮、出力への信頼、摩擦を見ます。
影響
スループット、サイクルタイム、レビュー速度を、導入前の基準値と比べます。具体的な作業の成果は定性で足します。
基準値はすでに手元にあります。ソース管理とチケットに残る、過去の納品履歴です。
影響指標の出発点
時間・労力・量の3グループから始めます。
| グループ | 見るもの |
|---|---|
| 時間 | 見るものPRを開いてからマージするまでの時間、コードレビューの待ち時間 |
| 労力 | 見るものPRあたりのレビュー往復回数、レビューコメントと手戻りの数 |
| 量 | 見るものエンジニア1人あたりのPR数、デプロイ頻度、空いた容量で出荷した名前付きの作業 |
これらは目安であり、規則ではありません。
「作業の単位」を先に決める
指標の多くはPRを数えますが、誤字修正と機能リリースはどちらも1PRです。そこで、定義した種類のマージ済みPRを数えます。Claudeが開き、人が出荷を決めたPRです。hotfixや機能リリースなどのラベル、チケットID、Claudeの関与の有無で、既存のシステムから探せます。
PRにならない作業もあります。サービスの切り替えや、根本原因まで詰めたインシデント対応がそうです。ルールは同じで、完了した1つの成果を、それが着地した場所で数えます。
OTelの数字をそのまま成果と読まない
OTelからは、提案の受け入れ率、変更した行数、作成したコミット数・PR数、成果1単位あたりの費用、ユーザーあたりのPR数が追えます。ただしClaude CodeのPR指標が数えるのは、Claude Codeが作ったPRです。最終的にマージされたPRではありません。出荷の記録はGitHubやGitLabとチケット管理が持っているので、両者を突き合わせて全体像を出します。
インシデント調査や営業デモ用のサンプルデータ作りのように、PRを生まなくても業務を速める使い方もあります。プロンプトを記録するオプトインは、そうした見えない使い方を拾う手段になります。
運用の回し方: 既定値から始めて、データで絞る
3段は一度作って終わりではなく、循環させます。出発点は、組織全体の支出上限、既定モデル、モデル許可リストの3点です。そこからロールとチームごとに、使用データを見て調整します。
- Google Cloudで専用プロジェクトを切り、請求予算とBigQueryエクスポートを入れる
- gatewayで組織の上限と既定モデルを置く
- OTelを有効にし、
OTEL_RESOURCE_ATTRIBUTESで部署とコストセンターを付ける - 導入前の納品履歴から、時間・労力・量の基準値を取る
- 数週間分のデータで、グループ別の上限とモデル許可リストを調整する
gatewayの上限は「見積もり金額による回路遮断」であり、請求書の金額ではありません。請求との突き合わせは、Google Cloud側のBigQueryエクスポートで行います。
まとめ
Google Cloudで安全に使う鍵は、道具ごとの守備範囲を混ぜないことです。予算アラートは通知、クォータは流量、gatewayの上限は個人別の遮断、BigQueryとOTelは追跡という役割になります。ROIは、費用の増減ではなく、基準値と比べた時間・労力・量の変化で語るほうが筋が通ります。
Google Cloud上の2形態の違いはClaude Models on Google Cloudの2形態で、チーム全体の支出の見方はClaude Codeのコスト管理で補えます。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。