【2026年最新】Claude Code支出上限｜gatewayで開発者別に設定

「Claude Codeの請求、先月いくらだった？」——クラウド経由で配布している会社ほど、この質問に即答できないんです。Bedrockの請求書には「Claudeモデルにいくら」は載っても、「誰が・どのチームがいくら」は載らない。共有クレデンシャル1本ですべての推論を通しているのだから当然で、公式ドキュメントもこの構造を率直に書いています。

A Claude apps gateway forwards all inference through one shared upstream credential, so your provider’s bill attributes everything to that credential, not to individual developers. Without per-developer limits, one runaway agent fleet can spend the organization’s entire commitment.
（Claude apps gatewayは全推論を1本の共有アップストリーム資格情報で転送するため、プロバイダーの請求書はすべてをその資格情報に帰属させ、個々の開発者には帰属させない。開発者別の上限がなければ、暴走したエージェント艦隊1つで組織のコミットメント全額を使い切りうる）

この穴を埋めるのが、Claude apps gatewayのspend limits（支出上限）です。8月前半のClaude Codeリリース群では、v2.1.225（8月7日・米国時間）でこの上限到達メッセージがClaude Code側の使用量警告に統合され、v2.1.227（8月10日・米国時間）で契約単価の上書き設定が入り、v2.1.233（8月14日・米国時間）でプロキシへのユーザー帰属転送が加わりました。前回の「Claude Code v2.1.233｜Todoが消える変更」の末尾で予告した「ゲートウェイ運用のアップデート」を、この記事でまとめて整理します。

なお本記事は2026年8月17日時点の公式ドキュメント（Claude apps gateway spend limits）、設定リファレンス、公式チェンジログを一次ソースにしています。ドキュメントは更新頻度が高いので、実装時は必ず現行版を確認してください。

前提整理：Claude Codeの支出管理は「契約形態で3系統」に分かれる

spend limitsの位置づけを理解するには、まずClaude Codeの支出管理が契約形態ごとに別物だと押さえる必要があります。公式のManage costs effectivelyは、組織向けの管理面を次の3系統に整理しています。

契約形態	支出の見える場所	上限のかけ方	ユーザー別レポート
Claude for Teams／Enterprise	組織アナリティクスのSpend report	管理設定のspend limits（シート枠＋usage credits）	Spend report CSV、EnterpriseはAnalytics API
Claude Console（API）	Console usageページ	ワークスペースのspend limits	Consoleダッシュボード、Claude Code Analytics API
Amazon Bedrock／Google Cloud／Microsoft Foundry	各クラウドの課金コンソール	各クラウドの予算機能	OpenTelemetry または LLMゲートウェイ

ポイントは3行目です。クラウド経由の場合、Claude Codeはクラウドからの利用状況をAnthropicに送り返さないため、Claude Code側のアナリティクスダッシュボードもClaude Code Analytics APIも対象外になります。公式ドキュメントはこのケースの「ユーザー別コスト帰属」の手段として、OpenTelemetryエクスポート、Claude apps gateway、既存のLLMゲートウェイの3つを挙げており、そのうちユーザー別の「上限」まで持っているのがClaude apps gatewayです。クラウド側の予算機能は組織やアカウント単位の総額アラートであって、「この開発者は1日100ドルまで」という粒度は持ちません。

Claude apps gatewayとは：claudeバイナリに同梱されたAnthropic純正ゲートウェイ

spend limitsはClaude apps gatewayの一機能なので、gateway自体を30秒で復習しておきます。Claude apps gatewayは、開発者のClaude Codeクライアントとモデルプロバイダーの間に置く自己ホスト型のサービスです。開発者はAPIキーやクラウド資格情報を持たず、会社のIdP（OIDC）でサインインして短命のベアラートークンを受け取ります。アップストリームの資格情報はgatewayだけが持ち、IdPグループごとにモデルの許可リストとmanaged settingsを配り、利用テレメトリをOTLPで自社の監視基盤へ流します。

特徴的なのは、これが別製品ではなくclaudeバイナリに同梱されている点です。開発者のノートPCで動くのと同じ実行ファイルが、claude gateway --config gateway.yamlでサーバーとして起動します。前提条件を公式ドキュメントから抜き出すと次の通りです。

• Claude Code v2.1.195以降（gatewayサーバー側・開発者側の両方）
• OIDC対応のIdP（Okta、Microsoft Entra ID、Google Workspace、Keycloak、Dex等。SAML・LDAPは非対応）
• PostgreSQL 14以降（spend limitsを使う場合は、支出・監査・識別情報の永続テーブルを持つのでバックアップ対象）
• サーバーはLinuxネイティブバイナリのみ（macOSはローカル開発用、Windowsはサーバー非対応）
• gatewayのホスト名はプライベートアドレスにのみ解決すること（Claude Codeは公開アドレスのgatewayへの/loginを拒否する）

Bedrock・Vertex／Agent Platform・Foundryのゲートウェイ設計全般の背景は「Claude LLM Gateway｜3大クラウド連携設計」でも整理していますが、本記事はそのうち「支出上限」に絞ります。既にLiteLLMなど別のゲートウェイを運用中で乗り換える予定がない場合は、公式がOther LLM gatewaysで「そのまま使ってよい」としているので、この記事の内容は「純正gatewayなら上限が何をどこまで担保するか」の比較材料として読んでください。

spend limitsの仕組み：3スコープ×3期間と、上限の適用順

上限（cap）は「scope」「amount」「period」の3要素で1本です。

フィールド	取りうる値	意味
scope.type	user／rbac_group／organization	userはIdPのOIDC subで1人を指定、rbac_groupはIdPグループ名、organizationは組織全体の既定値
amount	USDセント単位の整数文字列、またはnull	nullは無制限、"0"は全リクエスト遮断。"50000"なら500ドル
period	daily／weekly／monthly	1スコープに期間ごと1本ずつ持て、それぞれ独立に強制される（どれか1つでも超えれば遮断）

適用順（各期間ごとに独立）は、個人の上書き→所属グループのうち最も厳しい上限→組織既定→無制限です。admin.group_limit_mode: maxを設定すると、複数グループ所属時のタイブレークが「最も緩い方」に反転します。ここで勘違いしやすいのが、グループや組織の上限は「1人あたりの既定値」であって、グループで分け合うプール予算ではない点です。「開発部に月5,000ドル」ではなく「開発部の各メンバーに月5,000ドルずつ」の意味になります。

リセットはUTCの暦境界です。dailyは00:00 UTC、weeklyは月曜、monthlyは1日にリセットされ、日本時間に直すと「毎朝9時」「月曜朝9時」「1日の朝9時」になります。/v1/messages/count_tokensはトークン数の見積もりで課金対象ではないため、上限に達しても遮断されません。

比較のために書いておくと、Anthropicがclaude.ai Enterprise向けに提供している公開のSpend Limits APIは、2026年8月17日時点でperiodがmonthlyのみ、POSTで作れるのはユーザー単位の上書きのみです。gatewayの管理APIはこの公開APIとワイヤ形式を揃えつつ、スコープと期間の選択肢を広げた「上位互換」として設計されています。公式ドキュメントも「公開Admin APIの契約に対して書いたHTTPクライアントは、ベースURLを変えるだけでgatewayを叩ける」と明記しています。

設定手順：gateway.yamlのadminブロックと、cURLでの上限投入

spend limitsを有効にする実作業は2段階です。①gateway.yamlにadmin:ブロックを書いてgatewayを再起動し、②管理API（/v1/organizations/spend_limits）へ上限をPOSTする。上限そのものはYAMLには書かず、すべてAPI経由で出し入れします。

まずgateway.yaml側。公式の設定リファレンスにある例をベースにすると、次のようになります。

# gateway.yaml（抜粋）— admin: ブロックを足すとspend limits機能が有効になる
admin:
  write_keys:
    - { id: terraform, key: "${GATEWAY_ADMIN_WRITE_KEY_TF}" }
    - { id: ci,        key: "${GATEWAY_ADMIN_WRITE_KEY_CI}" }
  read_keys:
    - { id: reporting, key: "${GATEWAY_ADMIN_READ_KEY}" }
  admin_groups: [platform-finops]
  blocked_message: request an increase at https://go.example.com/claude-limits

• write_keys／read_keys：管理API用の静的キー（32文字以上）。idが監査ログにadmin-key:<id>として残るので、Terraform・CI・自動化ごとに別キーを切るのが公式推奨です
• admin_groups：ここに載せたIdPグループのメンバーは、通常のgateway JWTのままフルアクセスの管理者になり、監査ログにはoidc:<sub>で記録されます。人間の管理者はこちら、機械はAPIキー、という使い分けです
• blocked_message：遮断された開発者に表示される429メッセージへ、そのまま追記される案内文。「上限緩和はこのURLから申請」のような導線をここに書きます

次に上限の投入。組織全体の既定として「1人あたり月500ドル」を置くには、こう打ちます（amountはUSDセント単位の文字列である点に注意）。

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"}'

その上に「contractorsグループの各メンバーは1日100ドルまで」を重ねる場合はこうです。

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": "rbac_group", "rbac_group_id": "contractors"}, "amount": "10000", "period": "daily"}'

管理APIは他に、上限一覧（GET /v1/organizations/spend_limits）、1本取得・削除、そして運用で一番よく見ることになるGET /v1/organizations/spend_limits/effective（各開発者の「解決済み上限」と期間内の消化額の一覧。sort=spend_descでトップスペンダー順に並ぶ）とGET /v1/organizations/spend_limits/audit（誰がどの上限をいつ変えたかの変更履歴）を持ちます。

超過したら何が起きるか：429の中身と、75%／95%の事前警告

強制の実体はシンプルで、gatewayが/v1/messagesリクエストごとに、その開発者の上限と期間内消化額をPostgresに1クエリで照会します。どれかの上限を超えていれば、次のリクエストに429が返ります。

• エラー種別はerror.type: billing_error、ヘッダーにx-should-retry: false
• メッセージはspend limit reached (daily; resets 2026-08-08 00:00 UTC)のように期間とリセット時刻を名指しし、blocked_messageを設定していればその案内文が続く。複数の上限を同時に超えている場合は、リセットが最も遅い上限が名指しされる
• retry-afterヘッダーにリセットまでの残り秒数が入る

この「期間・リセット時刻・管理者メッセージ入り」の表示はv2.1.225からで、それ以前のgatewayでは素っ気ないspend limit reachedだけでした。チェンジログにも「Added gateway spend-limit support to Claude Code’s usage warning; the limit-reached message now names the cap, its reset time, and the operator’s message (requires the gateway on 2.1.225)」とあり、gatewayサーバーと開発者側クライアントの両方がv2.1.225以上であることが警告表示の条件です。

事前警告は2段階です。開発者の消化率が最も逼迫している上限の75%を超えると1回目、95%を超えると2回目の警告がClaude Codeの画面に出ます。仕掛けとしては、上限を持つ開発者への成功レスポンスにanthropic-ratelimit-unified-*ヘッダーで本人の消化率とリセット時刻が載り、クライアントがそれを読んで表示しています。gatewayはアップストリーム（クラウド側）のレート制限ヘッダーを剥がして転送しないため、開発者に見えるのは常に「自分の上限」であって、組織の共有クォータではありません。

なお、この仕組みは組織のgateway運用者が設定するものです。個人のProやMaxプランで「利用上限に当たった」場合の対処は別の話なので、「Claude Code利用上限の対処法｜再開手順と運用」を参照してください。

金額はどう測られるか：メーターの単価解決と「請求書ではない」設計

ここがspend limitsを運用に載せる上で一番誤解しやすいところです。gatewayが数える金額は、レスポンスのトークン数に単価を掛けて積み上げたUSDの推定値であって、クラウドプロバイダーの請求書そのものではありません。公式ドキュメントも「a circuit breaker rather than an invoice（請求書ではなくサーキットブレーカー）」と明言し、請求の照合はプロバイダー側のレポートで行うよう求めています。

メーターが1リクエストの単価を決める順序は次の4段階です。

1. pricing.overridesの一致行（gatewayサーバーがv2.1.227以降）：アップストリーム×モデルごとに、input／output／cache_read／cache_writeの4単価をUSD/MTokで上書きできる
2. アップストリームのモデルIDの定価：Claude Codeのコスト表が認識できるID（Anthropic形式、Bedrock形式、Google Cloud形式、Foundry形式）はそのまま定価で計算
3. マッピング先モデルの定価（v2.1.218以降）：Bedrockのapplication-inference-profile ARNやFoundryのデプロイ名のようにモデル名を含まない文字列は、models[].idで対応づけたモデルの定価で計算
4. 不明モデル料率（$5／$25 per MTok）：どうしても特定できないIDは、input $5／output $25で計算される。「認識できないIDだから無料」にはならない設計で、gatewayは起動時とID初出時に警告を出す

この上にpricing.multiplier（既定1、0より大きく1以下）が掛かります。「うちはコミット割引で定価の85%」なら0.85を置く、という使い方です。参考までに2026年8月17日時点の主要モデル定価（標準・input/output）は、公式PricingでOpus 5とOpus 4.8が$5／$25、Sonnet 5が$2／$10、Haiku 4.5が$1／$5です。Sonnet 5は8月10日の告知で導入価格$2／$10がそのまま標準価格になり、9月1日に予定されていた$3／$15への引き上げは行われないことが確定しました。上限額の設計をこの値上げ前提で組んでいた場合は、少し余裕ができた計算になります。

もう1つ見逃せないのが途中切断の課金です。ストリーミングをクライアント側で切ってアップストリームの最終usageフレームが届かなかった場合、メーターは「送信済みテキスト約4文字=1出力トークン」の下限見積もりで計上します。リクエストを途中で切りまくって上限を回避する、という抜け道は塞がれています。

v2.1.233の新設定：forward_user_identityで「gatewayの向こう側」にもユーザー帰属を渡す

2026年8月14日（米国時間）公開のv2.1.233には、この支出管理の文脈に直結する追加が1つ入りました。チェンジログの記載はこうです。

Added an opt-in forward_user_identity apps gateway setting on Anthropic upstreams that sends the signed-in user’s identity as headers, so a proxy behind the gateway can attribute spend per user
（Anthropicアップストリームに対するopt-inのforward_user_identity設定を追加。サインイン中ユーザーのアイデンティティをヘッダーとして送るため、gatewayの背後に置いたプロキシがユーザー別に支出を帰属できる）

gatewayとアップストリームの間にさらに自社プロキシ（監査・DLP・独自メータリング等）を挟んでいる構成では、これまでプロキシから見えるのは「gatewayからのリクエスト」だけで、誰の分かは分かりませんでした。この設定を有効にすると、Anthropicアップストリーム向けのリクエストにサインインユーザーの識別情報がヘッダーで付き、プロキシ側でもユーザー別の集計ができるようになります。opt-in（既定オフ）なのは、ユーザー識別情報を外へ流す設定だからで、有効化する場合は自社のログ・PII方針との整合を先に確認すべきです。

同じ8月前半には、Claude Code側の上限到達メッセージがgatewayのキャップ名・リセット時刻・運用者メッセージを表示するようになった変更（v2.1.225）、Team／Enterpriseのspend limitメッセージが「組織の月次上限」と「個人の上限」を取り違えて表示するバグの修正（v2.1.221）も入っており、支出まわりの整備が連続していることが分かります。バージョンごとの他の変更は「v2.1.233の解説記事」と「v2.1.232フォーク既定化ガイド」を参照してください。

【要注意】運用の落とし穴4パターン

公式ドキュメントを読み込むと、設計判断を間違えやすいポイントがいくつかあります。実際の導入検討で引っかかりやすい順に挙げます。

❌ 失敗1：Postgres障害時の挙動を決めずに導入する
上限チェックのPostgres照会は2秒タイムアウトで、届かない場合の既定はfail-open（リクエストを通す）です。DB障害が推論の全面停止に波及しないための設計ですが、裏を返せば「DBが落ちている間は誰も止まらない＝計測されない支出が発生しうる」ということです。
⭕ 対策：enforcement.fail_closed_on_error: trueにすれば超過者もそれ以外も全員止まるfail-closedに切り替えられます。「絶対に予算を超えない」ことが最優先ならfail-closed＋Postgresの冗長化、「開発を止めない」ことが最優先なら既定のfail-openのままDB監視を厚くする、と方針を先に決めてから導入します。

❌ 失敗2：グループ上限を「プール予算」だと思って設定する
前述の通り、rbac_groupやorganizationの上限は各メンバーが1人ずつ継承する既定値です。「10人の部署に月1,000ドル」のつもりで"100000"を置くと、実際には最大で月10,000ドルまで通ります。
⭕ 対策：1人あたりの想定額で設定し、部署総額は/effectiveをsort=spend_descで定期取得して監視します。公式のコスト管理ドキュメントにある通り、コーディング席はチャット席より消費が大きく、1回のデバッグセッションがチャット1日分を超えることもあるため、初期値は控えめに置いて実測で緩める方が安全です。

❌ 失敗3：モデルIDのマッピング漏れで「$5／$25の不明モデル料率」で計上される
BedrockのARNやFoundryのデプロイ名をmodels[].idに対応づけていないと、実際はSonnet 5（$2／$10）の利用が不明モデル料率の$5／$25で計上され、上限に想定の2倍以上の速さで到達します。
⭕ 対策：gateway起動時の警告ログを必ず確認し、modelsブロックでアップストリームIDを対応づけます。逆に「認識できないIDが無料にならない」のは安全側の仕様なので、警告を潰し切ることが単価精度の担保になります。

❌ 失敗4：PIIの扱いを確認せずに/effectiveやforward_user_identityを使う
gatewayのDBにはprincipal_emailsテーブル（各開発者の最終確認メール・表示名・グループ。明確にPII）があり、既定90日で消えます。また/effectiveのq=やuser_ids[]=はGETクエリ文字列なので、前段のロードバランサーのアクセスログに残ります。
⭕ 対策：退職者は上限行をDELETEし、即時消去が必要な場合は公式が案内する通りprincipal_emailsから該当行を直接削除します。ログポリシーが厳しい組織はプロキシ側でこれらのクエリパラメータをスクラブし、forward_user_identityの有効化は情報管理部門の確認を通してからにします。

導入判断チェックリスト：自分の組織に必要か

最後に、そもそもgateway＋spend limitsを入れるべきかの判断材料です。

• Teams／Enterpriseプランで使っている → gatewayは不要。シート枠が既定の天井で、超過分はusage creditsと管理画面のspend limits（組織・グループ・個人）で制御できる。EnterpriseならSpend Limits APIで自動化も可能
• Claude Console（API直）で使っている → まずワークスペースのspend limitで足りるか確認。Claude Code認証時に自動作成される「Claude Code」ワークスペースに上限とレート制限をかけるのが公式の第一推奨
• Bedrock・Google Cloud・Foundry経由で、ユーザー別の上限が要る → 本記事の構成が本命。データレジデンシー要件でクラウド経由が必須の組織は特に、資格情報の集中管理・グループ別モデル制御とセットで導入価値が高い
• 既に別のLLMゲートウェイを運用している → 乗り換え必須ではない。ただし「Claude Codeが送るヘッダーを追従済み」「上限警告がクライアントUIに統合」「公開Admin API互換のワイヤ形式」は純正の優位点
• 上限より先にまず現状把握がしたい → OpenTelemetryエクスポートが全構成で使え、ユーザー別トークン・コストをほぼリアルタイムで自社監視基盤に流せる。個人・小規模なら「コスト最適化ガイド」の範囲で足りることも多い

組織展開の周辺整備としては、モデル・スキルの統制を扱った「Claude Code全社ガバナンス」、障害時の切り替えを扱った「fallbackModel設定でAPI障害対策」、導入前の確認事項を網羅した「法人導入セキュリティ完全チェックリスト」もあわせてどうぞ。

FAQ

Q1. spend limitsを使うのに追加料金はかかりますか？

gateway自体はclaudeバイナリに同梱されており、機能としての追加課金は公式ドキュメントに記載がありません。ただし自己ホストなので、gatewayを動かすLinuxサーバーとPostgreSQLの運用コストは自社持ちです。推論費用は従来通り契約中のクラウド／APIに課金されます。

Q2. 上限に達した開発者は何もできなくなりますか？

gateway経由の/v1/messagesが429で止まります。トークン数の見積もり（count_tokens）は課金対象外なので止まりません。リセット（UTC暦境界＝日本時間朝9時）を待つか、管理者が上限を上げれば再開します。blocked_messageに緩和申請の導線を書いておくと、開発者が迷いません。

Q3. 金額の精度はどの程度信頼できますか？

トークン数×単価のUSD推定で、公式が「invoice（請求書）ではない」と明言しています。契約単価はpricing.overridesとmultiplierで近づけられますが、最終的な支払額は必ずクラウドプロバイダー側の課金レポートで照合してください。上限は「暴走を止める遮断器」として設計するのが正しい使い方です。

Q4. 「日次」上限のリセットは日本時間の何時ですか？

リセットはUTCの暦境界で、dailyは00:00 UTC＝日本時間の朝9時です。weeklyは月曜朝9時（JST）、monthlyは毎月1日の朝9時（JST）にリセットされます。タイムゾーンの変更設定は2026年8月17日時点の公式ドキュメントには記載がありません。

Q5. Anthropic API直（Claude Console）でもこのgatewayのspend limitsを使えますか？

使えます。アップストリームにはAnthropic APIも指定できるため、Console組織でも「ユーザー別・日次／週次」の粒度が欲しい場合にgatewayを挟む選択肢はあります。ただしConsoleにはワークスペース単位のspend limitが標準機能としてあるので、まずそちらで足りるかを確認するのが公式ドキュメントの推奨順です。

まとめ：「誰がいくら」を測れない構成に、上限という遮断器を置く

クラウド経由のClaude Code配布は、資格情報とデータ経路の統制には優れる一方、「誰がいくら使ったか」が請求書から消えるという構造的な弱点がありました。Claude apps gatewayのspend limitsは、そこにユーザー別の計測と上限を後付けする仕組みで、8月前半のv2.1.225〜v2.1.233で警告表示・契約単価・プロキシへの帰属転送と、実運用に必要な部品が揃ってきています。fail-open／fail-closedの方針決め、グループ上限の「1人あたり」解釈、モデルIDマッピング、PIIの扱い——この4点を先に設計してから入れれば、暴走エージェント1つで月次予算が溶ける事故を仕組みで防げます。

次回は、8月のリリースで拡充が続くプラグイン・マーケットプレイス管理（archiveソース・GitLab対応・enterprise policyのブロック設定）を組織運用の視点で整理する予定です。

出典

• Claude apps gateway spend limits（公式ドキュメント） — 2026年8月17日時点で確認
• Claude apps gateway（公式ドキュメント・アーキテクチャと前提条件）
• Claude apps gateway configuration（公式ドキュメント・admin／enforcement／pricingブロック）
• Manage costs effectively（公式ドキュメント・契約形態別の支出管理）
• Claude Code changelog（公式・v2.1.221／v2.1.225／v2.1.227／v2.1.233の各記載）
• Anthropic Pricing（公式・Sonnet 5価格据え置きの告知を含む）
• Spend Limits API（公式・Claude Enterprise向け公開API）

---

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載執筆。

関連事例: GitLabの多段承認フローとメモリ上限設定でClaude Codeを金融機関の統制内で運用する実装パターンは金融機関のGitLab承認フロー実装パターンで解説しています。

あわせて読みたい

• ▸ 【2026年9月】Claude Code研修・講師の依頼先6社比較と選び方
• ▸ 【2026年最新】Claude Code /compact｜長時間開発の5手順
• ▸ 【2026年最新】Claude Code /diff活用｜差分レビュー5手順
• ▸ 【2026年最新】Claude Code管理MCP配布｜7手順
• ▸ 【2026年最新】Claude Code外部読取制御｜設定5手順