---
title: "Google Cloud経由のClaude Code、組織での費用の上限と効果の測り方"
description: "Google CloudのAgent Platform経由でClaude Codeを使う組織向けに、予算と上限のかけ方、利用状況の集め方、効果の指標を、Anthropicが10月27日に公開した解説記事と公式ドキュメントで確かめます。"
url: https://udon-dev.com/notes/claude-code-google-cloud-cost-roi/
lang: ja
published: 2026-10-28
topic: [ai]
tags: ["claude", "claude-code", "google-cloud", "cost-management", "opentelemetry"]
---

# Google Cloud経由のClaude Code、組織での費用の上限と効果の測り方

- Google Cloud経由の利用は、Anthropicの分析画面とClaude Code Analytics APIの対象外で、費用は自社で集める
- Google Cloudの支出の上限はプロジェクトとサービスの単位で、上限に達するとそのプロジェクトのAgent Platformの利用全体が止まる
- 開発者ごとの上限は、自社で動かすClaude apps gatewayで、日・週・月の単位で設定できる
- Anthropicが挙げる効果の指標の例はPRの所要時間・手戻り・件数で、Claude Codeが数えるPRの数は作成した数でありMergeされた数ではない

9月に書いた[Claude Codeのコスト管理の記事](/notes/claude-code-usage-effort/)は、開発者が自分の`/usage`を見て、エフォートで使う量を調整する話でした。組織でClaude Codeを配ると、管理者には別の疑問が出ます。誰がいくら使っているか、使いすぎをどこで止めるか、払った分の効果をどう説明するか、です。

Anthropicは10月27日、この3つを「Control（上限）」「Track（追跡）」「Prove（効果の証明）」に分けた[解説記事](https://claude.com/resources/articles/how-to-manage-costs-and-demonstrate-roi-for-claude-code-on-google-cloud)を公開しました。対象はGoogle Cloud経由で使う組織です。Google Cloudと共同で開いたウェビナーをもとにした記事です。この記事では、そこに出てくる機能を公式ドキュメントで確かめ、設定の単位や止まり方まで整理します。

## Google Cloud経由ではAnthropic側の集計を使えない

費用を見る場所は、どの経路で契約しているかで変わります。[公式ドキュメント](https://code.claude.com/docs/en/costs)は、経路ごとに次のように分けています。

| 経路 | 費用を見る場所 | 上限をかける場所 | 利用者ごとの集計 |
| --- | --- | --- | --- |
| Claude for Teams・Enterprise | 組織の分析画面の費用のレポート | 管理画面の支出の上限 | 費用のレポートのCSV（EnterpriseはAnalytics APIも） |
| Claude Console（API） | Consoleの利用状況のページ | ワークスペースの支出の上限 | Consoleのダッシュボード、Claude Code Analytics API |
| Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry | 各クラウドの請求の画面 | 各クラウドの予算の機能 | OpenTelemetryか、LLMのゲートウェイ |

Google CloudのAgent Platform（旧Vertex AI）経由では、トークンごとの料金がGoogle Cloudの請求に載ります。Claude Codeはクラウド側の利用の数字をAnthropicに送りません。そのため、Anthropicの分析画面とClaude Code Analytics APIには、この利用が出てきません。利用者ごとの数字は、自社で集める必要があります。

## 支出の上限はGoogle Cloudの予算と開発者ごとの上限で分ける

上限をかける機能は、Google Cloudの側とClaude Codeの側の両方にあります。単位が違うので、役割を分けて使うことになります。

### Google Cloudの側は、プロジェクトとサービスの単位

解説記事は、Google Cloudの次の機能を挙げています。

- プロジェクトの分離：Claude Code専用のプロジェクトを作り、費用を切り分ける
- 予算とアラート：実際の支出がしきい値を超えたら通知する
- 支出の上限（Preview）：サービス単位で予算を強制する
- BigQueryへのエクスポート：Claudeの費用を、ほかのクラウドの費用と並べて分析する
- 割り当て（Quotas）：モデルとエンドポイントの場所ごとに、1分あたりのリクエスト数・入力トークン数・出力トークン数の上限がある
- プロビジョンド スループット：従量課金の代わりに、固定の料金で容量を確保する

このうち支出の上限は、上限に達するとそのプロジェクトのAgent Platformの利用がまとめて止まります。[Google Cloudのドキュメント](https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps)によると、上限をかける単位は、1つのプロジェクトの中の1つのサービスで、期間は毎月1日から始まる月単位だけです。対象のサービスには、Agent Platform（`aiplatform.googleapis.com`）が入っています。

支出が予算の50%・80%・100%を超えるとメールが届き、100%を超えると、そのプロジェクトのそのサービスの新しい利用が、期間の終わりまで止まります。止まるのは、そのプロジェクトでAgent Platformを使う全員です。上限は手動でも外せますが、外したあと元に戻るまで最大1時間かかることがあります。

金額の判定には、割引やクレジットを含まない、定価で見積もった費用を使います。判定は請求のレポートより早いものの、即時ではありません。超えた分は通常どおり請求されます。このため支出の上限は組織全体の使いすぎを止めるためのもので、開発者ごとの管理には向かないとみられます。

### 開発者ごとの上限は、Claude apps gatewayで

開発者の単位で上限をかけるのが、[Claude apps gateway](https://code.claude.com/docs/en/claude-apps-gateway-spend-limits)です。開発者が使っている`claude`と同じバイナリに入っていて、自社のGoogle Cloudのプロジェクトで動かし、Claude CodeとAgent Platformのあいだに置きます。開発者はGoogle Workspaceなどの自社のIDプロバイダーでサインインするので、リクエストごとに誰の利用かが分かります。

ゲートウェイは既定で、推論を全て1つの共有の上流の認証情報で送るので、Google Cloudの請求は開発者ごとではなく、その認証情報の分としてまとめて出ます。ドキュメントは暴走したエージェントの群れが組織の予算を使い切る例を挙げ、ゲートウェイの上限を、共有の請求の上に置く「開発者ごとのブレーカー」と位置づけています。

上限は利用者・IDプロバイダーのグループ・組織の3つの範囲に、日・週・月の期間でかけられます。設定には管理APIを使い、`gateway.yaml`には書きません。組織全体で開発者1人あたり月500ドルにする例は次のとおりです（金額はセント単位の文字列）。

```bash
curl -sS https://claude-gateway.internal.example.com/v1/organizations/spend_limits \
  -H "x-api-key: $GATEWAY_ADMIN_WRITE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"scope": {"type": "organization"}, "amount": "50000", "period": "monthly"}'
```

出典：[Claude apps gateway spend limits（Claude Code公式ドキュメント）](https://code.claude.com/docs/en/claude-apps-gateway-spend-limits)

設定の前に知っておきたい動きは、次の4つです。

- グループや組織の上限は、メンバーで分け合う共有の枠ではなく、1人ずつに適用される既定値です。1人の上限は本人の個別の設定、所属グループの中で一番厳しい上限、組織の既定値の順に決まります
- 上限を超えると、次のリクエストに`429`が返り、期間が切り替わるか管理者が上限を上げるまで止まります。期間はUTCの0時で切り替わるので、日単位の上限は日本時間の毎日9時に戻ります
- Claude Codeは、使った割合が75%と95%を超えたときに開発者へ警告を出します。Google Cloudの予算のアラートが管理者向けなのに対して、こちらは開発者の画面に出ます
- ゲートウェイが数える金額は定価による見積もりです。請求額としてはGoogle Cloudの利用のレポートと突き合わせます

ゲートウェイではIDプロバイダーのグループごとに使えるモデルを制限し、既定のモデルを決めることもできます。Anthropicは、既定のモデルを決めるやり方がとてもうまくいったとしています。ほとんどの人は既定のモデルのまま使い、切り替える人には理由があるからです。なお、Google Workspaceのトークンにはグループの情報が入っていません。グループで分けるには、ゲートウェイの`oidc.google_groups`の設定が必要です（[Google Cloudへの配置の手順](https://code.claude.com/docs/en/claude-apps-gateway-on-gcp)）。

### 費用の高いセッションを止めすぎない

解説記事が上限について強調しているのは、制限するより誘導する、という考え方です。費用の高いセッションは、新しい使い方を試している人のもので、価値も高いことが多いと書いています。解説記事によると、無駄が出やすいのはその下の「よく使う人」の層です。例として、Sonnetで足りる毎日の定型作業に上位のモデルを使っている、もう要らない定期実行を止め忘れている、の2つが挙がっています。

上限に達した人が引き上げを申請できるように、ゲートウェイの管理APIをチケットの仕組みにつなぐ例も紹介されています。

## 利用状況はOpenTelemetryで人・部署・モデルごとに集める

Google Cloud経由の利用を利用者ごとに見る主な方法は、Claude CodeのOpenTelemetryの出力です。[監視のドキュメント](https://code.claude.com/docs/en/monitoring-usage)によると、`CLAUDE_CODE_ENABLE_TELEMETRY=1`で有効になり、OTLPで自社の監視の仕組みに送れます。

数えられる主な指標は、セッション数、変更した行数、作成したPRの数、コミット数、費用、トークン数、アクティブな時間です。費用の指標にはモデルやエフォートのほか、どのサブエージェント・スキル・プラグイン・MCPサーバーの利用かという属性も付くので、社内で作ったスキルがどれだけ使われているかも分かります。ただし、自分で作ったエージェントやMCPサーバー、公式以外のマーケットプレイスのプラグインの名前は、既定では`custom`や`third-party`に置き換わり、実際の名前を出すには`OTEL_LOG_TOOL_DETAILS=1`が要ります。

部署や原価の単位で集計するには、`OTEL_RESOURCE_ATTRIBUTES`に属性を書きます。

```bash
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"
```

出典：[Monitoring（Claude Code公式ドキュメント）](https://code.claude.com/docs/en/monitoring-usage)

ゲートウェイを使う場合は、開発者のパソコンごとに設定する必要がありません。ゲートウェイに送り先を設定すると、サインインした開発者の出力が有効になり、サインインしたメールアドレスとグループが付いて届きます。

（図: Cloud MonitoringのClaude Codeのダッシュボードの例。上段に24時間の費用、組織の1日の上限の使用率、止められたリクエスト数、トークン数、セッション数、アクティブな開発者数が並び、下にトークンの種類別の推移、利用者ごとのトークン数、モデルごとの費用、変更した行数、利用者ごとのセッション数のグラフがある）
Claude CodeのOpenTelemetryの指標から作ったCloud Monitoringのダッシュボード。見本のデータで再現した画面。出典：[Manage costs and demonstrate ROI for Claude Code on Google Cloud（Claude公式）](https://claude.com/resources/articles/how-to-manage-costs-and-demonstrate-roi-for-claude-code-on-google-cloud)

画面の「Blocked requests」は、ゲートウェイの上限で止められたリクエストの数です。

Cloud Monitoringには、Google Cloudが公開している[Claude Code Monitoringのダッシュボード](https://github.com/GoogleCloudPlatform/monitoring-dashboard-samples/tree/master/dashboards/claude-code)をそのまま読み込めます。セッション数、利用者数、コミットとPRの数、編集の承認率、利用者・モデルごとのトークンと費用の見積もりが1画面にまとまります。READMEにはつまずきやすい点が2つ書かれています。

- 利用者ごとの集計は`user.email`の属性でまとめます。ゲートウェイやClaudeのアカウントでサインインしていれば自動で付きますが、Agent Platformを直接呼ぶ場合は付かないので、`OTEL_RESOURCE_ATTRIBUTES`に1人ずつ書きます
- 指標を送る間隔（`OTEL_METRIC_EXPORT_INTERVAL`）は既定の60000ミリ秒のままにし、15000ミリ秒より短くしません。Cloud Monitoringは、同じ系列に約15秒以内に続けて届いた点を受け付けず、エラーは`Bad Request`としか出ないので、データが欠けても気づきにくくなります

プロンプトの本文は機密を含むことがあるため、既定では記録されません。何に使われているかまで知りたい場合は、`OTEL_LOG_USER_PROMPTS=1`で明示的に有効にします。有効にするかどうかは、社内で情報を扱う決まりと合わせて判断する必要がありそうです。

## 効果の指標は何を数えて何と比べるか

Anthropicは効果を測る指標を「利用」「満足度」「成果」の3つに分け、利用はOpenTelemetryのデータから、満足度は導入の前後に行う短いアンケートとその後の聞き取りから取るとしています。成果の指標は導入前の実績と比べます。

成果の指標の出発点として挙がっているのは、次の3つの観点です。

| 観点 | 指標の例 |
| --- | --- |
| 時間 | PRを開いてからMergeするまでの時間、コードレビューにかかる時間 |
| 手間 | PRあたりのレビューの往復の回数、レビューのコメントと手戻りの量 |
| 量 | エンジニア1人あたりのPRの数、デプロイの頻度、空いた時間で終えた具体的な作業 |

解説記事によると、比べる相手の数字はソース管理とチケットの履歴に既にあります。これらの指標は決まりではなく目安だ、とも書かれています。

数えるときの注意も2つ書かれています。1つは誤字の修正も新機能もPR 1件と数えてしまうことです。そこで、種類を決めたPR（Claudeが開き、人がMergeを判断したもの）だけを数えるよう勧めています。ラベルやチケット番号で、あとから絞り込めるようにしておきます。

もう1つは、Claude CodeのPRの指標がClaude Codeが作成したPRの数で、最終的にMergeされた数ではない点です。何が出荷されたかの記録は、GitHubやGitLab、チケット管理のほうにあります。障害の調査やデモ用のデータ作りのように、PRにならない仕事もあるので、Claude Codeの数字とソース管理・チケットの記録を突き合わせて見ることになります。

## 最初に決める3つ

解説記事が勧める始め方は、組織全体の上限、既定のモデル、使えるモデルの一覧の3つを、無理のない値で決めることです。利用のデータが貯まったら、役割やチームごとに調整します。

Google Cloudで使う場合は、Claude Code専用のプロジェクトを分けるかどうかも先に決めておくとよさそうです。分ければ、支出の上限と予算のアラートをClaude Codeだけにかけられます。ほかのAI利用と同じプロジェクトのままだと、上限に達したときに、Agent Platformを使うほかの仕組みまで止まります。