Claude apps gatewayの費用を利用者別に追う8手順

結論：請求credentialではなく、SSOの主体を費用の軸にする

読者の具体的な困りごとは、全員が一つのupstream credentialを使うため、費用が増えても利用者、部署、model、再試行のどこに原因があるか説明できないことです。この記事を読むと、個人、group、組織の三層で費用を分類し、追跡継続、上限設定、設定修正、利用停止を判断できます。

次の行動：一人のcanary利用者について、OIDC sub、email、group、gateway、upstream、model、日次上限、照合責任者を一行へ記録してください。

正式な提供条件・料金・制限を確認する

Claude apps gatewayは、Amazon Bedrock、Claude Platform on AWS、Google Cloud、Microsoft Foundry、Anthropic APIなどへ推論を中継するself-hosted serviceです。企業のIdPでsign-inし、gatewayがupstream credential、model access、managed settings、telemetryを管理します。自社cloud経由やdata residencyが必要な組織向けで、SCIMやWeb・mobileまで必要ならClaude Enterpriseとの比較が必要です。

公式quickstartの前提は、gateway serverとclientのClaude Code 2.1.195以降、OIDC、PostgreSQL 14以降、HTTPS、private-network address、model upstreamです。serverはnative Linux binaryで動かし、macOSはlocal開発向け、Windowsはserver platform非対応です。機能単体の追加料金は公式ページに示されていませんが、model provider利用料、Postgres、load balancer、監視、運用人員の費用は発生します。

gatewayのtelemetryは、token数、model、user identity、latencyを含むOTLP metricsを既定で送れます。logsとtracesは送信先ごとのopt-inです。telemetryだけで請求額を確定せず、providerのusage reportingと期間・model ID・価格表を照合します。価格overrideやmultiplierを使う場合は、契約単価と設定変更日を残してください。

2.1.233のforward_user_identityはopt-inです。signed-in user identityをheaderとして後段proxyへ送るため、proxyが自社管理下にあり、headerを外部へ再転送しないこと、logの閲覧範囲と保持期間が決まっていることが前提です。具体的なheader名やschemaを推測せず、稼働versionのconfiguration referenceと検証環境で確認します。

費用追跡の7軸を一つの台帳へそろえる

1. 主体：email表示名ではなくIdPのOIDC subを安定IDにし、groupは組織変更に追従させます。
2. 経路：client、gateway、後段proxy、upstreamを記録し、どこでidentityやmodel IDが失われるか確認します。
3. 利用量：input、output、cache、latency、request countを同じtime zoneと締め期間で集計します。
4. 単価：gatewayの見積単価、契約discount、provider請求単価を分け、変更日を持たせます。
5. 上限：user、RBAC group、organizationへdaily・weekly・monthly capを重ねます。
6. 例外：共有service account、CI、退職者、IdP group変更、unknown modelを別queueで確認します。
7. 証跡：設定変更、上限変更、429、fail-open、請求差分をrequest IDと担当者へ結び付けます。

spend limitは、共有upstream credentialの上に利用者別circuit breakerを置く機能です。gatewayは各requestでcapとperiod-to-date spendを確認し、超過時は次のrequestへ429を返します。user override、group、organizationの順で実効capを解決します。ただし金額はinvoiceではなくUSD見積もりです。provider請求との差はcache、失敗request、価格override、期間境界から調べます。

ユーザー別追跡をcanary導入する8手順

1. 対象を一部署・一gateway・一upstream・一model familyへ絞り、追跡目的と保存期間を決めます。
2. IdPのsub、email claim、groups claimを確認し、退職・異動時の扱いをidentity管理者と固定します。
3. gatewayのOTLP metricsを自社collectorへ送り、user identity、model、token、latencyが一requestで結び付くか確認します。
4. 後段proxyで帰属が必要な場合だけforward_user_identityをcanary upstreamへ有効化し、受信headerとlogをreadbackします。
5. 個人・group・組織のcapを少額から設定し、75%、95%、超過時の表示と429をテストします。
6. Postgres停止時のfail_closed_on_errorを選び、可用性優先か未計測費用の禁止かを承認します。
7. gateway見積もり、OTLP集計、provider請求を同じUTC/JST期間で照合し、差分理由を分類します。
8. canary結果からgroup展開、単価修正、上限調整、HOLDを決め、変更前後のconfigと担当者を残します。

人名やemailを可観測性platformへ広く複製する必要はありません。分析用にはOIDC subや管理IDを使い、人名対応表は権限を分けます。退職者を削除して過去費用が追えなくならないよう、identityの失効と監査recordの保持を別policyにします。

導入前チェックリストとHOLD条件

• 2.1.195以降を確認した
• private networkとHTTPSを確認した
• OIDC subを正本にした
• group claimを確認した
• telemetry送信先を限定した
• log保持期間を決めた
• forward設定をopt-inにした
• proxyの再転送を確認した
• provider単価と期間を合わせた
• unknown modelの扱いを決めた
• 個人・group・組織capを試した
• 429をreadbackした
• Postgres障害時動作を決めた
• 請求照合責任者を置いた

HOLDするのは、IdPの主体が安定しない、proxyが受け取るidentity headerを外部へ転送する、telemetryの閲覧者と保持期間が未定、契約単価を確認できない、Postgres障害時に未計測で続けるか止めるか決まらない、service accountを人間利用へ混ぜる場合です。dashboardに人別数字が出たことだけを会計証跡にしません。

よくある質問と次の行動

正式な構成と前提はClaude apps gateway公式guide、全設定と価格meterは公式configuration reference、capと見積額の制限は公式spend limits guide、新しいidentity forwardingは公式changelogで公開直前にも確認してください。

上限の詳細はgateway費用上限、全体費用はClaude Codeコスト管理、判断証跡は監査ログへつなげます。Miraigentの無料診断では、identity、利用量、単価、上限、障害、請求照合を一枚の運用表へ整理します。