チームで coding agent を使うための AI Gateway とルーターの理想形を考えてみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
coding agent の token 消費が、ここ半年でさらに肥大化してきていて話題になっていると思います。エージェントは一つの指示から何十ターンもループし、毎ターン文脈を読み直すので、チャット時代の感覚で組んだ予算を軽々と超えていきます。海外では 1 人あたり月 $500〜2,000 に達した費用を理由に、大手企業がツールの切り替えを指示したという報道が出ました。どのエージェントを使っていても、他人事ではない金額感になってきています。
個人なら、まとまった量の利用を定額で包む各社の包括的なサブスクリプションプランでどうにか吸収できます。ところがチームや全社になると話が変わります。Team や Enterprise のシート、Console の API、Amazon Bedrock や Claude Platform on AWS の従量課金を組み合わせて、どうにか切り盛りしているのが実情ではないでしょうか。そこへ Claude Code 以外のエージェントが混ざると、窓口がさらに増えます。Codex CLI は ChatGPT のサブスクで動くので、自分の場合は Claude のサブスク、ChatGPT のサブスク、残りのツール用の従量の窓口、という多重管理です。これをどう縮めるかがずっと気になっていました。
前回は NeMo Relay と NeMo Switchyard を AI Gateway としてどう置くかを、製品の責務分解として整理しました（2026-08-29 時点の記事です）。チーム向けの AI 環境そのものは、オープンウェイトモデルの連載で扱っています（2026-08-08 時点の記事です）。
この記事では、課金経路、窓口、振り分け、実行側、観測という五つの層に AI Gateway を分けて、チーム開発とビジネス利用で coding agent を使うときの理想形を 2026 年 8 月時点で構想します。実測は、共通の Gateway に 3 種類のエージェントを通した確認 1 つだけに絞りました。チームや全社で coding agent を管理する側の方に刺さるといいなと思っています。
AI Gateway を五つの層に分けて考える
前回の記事で、AI Gateway という言葉には認証から監査まで幅広い機能が含まれていて、全部入りを一度に用意すると普段の環境には重い、と書きました。今回はもう一段手前から考えます。そもそも誰の財布で払うのかが決まらないと、窓口をどこに置くかも決まらないからです。
五つの層に分けると次のようになります。
| 層 | 答える問い | 担当する部品の例 |
|---|---|---|
| 1. 課金経路 | 誰の財布で、どの単価で払うか | Team / Enterprise のシート、Console の API、Bedrock、Claude Platform on AWS、Agent Platform、Foundry |
| 2. 窓口 | 誰が、どのモデルを、いくらまで使えるか | claude.ai の admin 設定、Claude apps gateway、LiteLLM や Bifrost の virtual key、Envoy や Kong |
| 3. 振り分け | この依頼をどのモデルへ送るか | NeMo Switchyard、LiteLLM の auto-routing と budget fallback、Bedrock の inference profile |
| 4. 実行側 | agent が何をしたか、外へ出す前に何を消すか | NeMo Relay、opencode の guard、Claude Code の managed settings と sandbox |
| 5. 観測・帰属 | 誰がいくら使ったかを財務と突き合わせる | Claude Code の OpenTelemetry、Gateway の spend log、AWS CUR 2.0、Enterprise Analytics API |
2 層目から 5 層目は前回記事の「足りない機能は専用の部品で補う」表とほぼ重なります。違うのは課金経路を最上位に置いたことです。この後で見ていくように、サブスクを選ぶと 2 層目の窓口は Anthropic 側に既にあって、自前で挟む余地がほとんどありません。逆に従量を選ぶと窓口を自分で持つ必要があり、そこで初めて共通の Gateway が出番になります。層の数は同じでも、課金経路の選択で残りの層の置き場所が動く、というのが今回の骨格です。
課金経路が層の要否を決める
Claude Code の公式ドキュメントは、配備の選択肢を六つ並べています。課金と認証、それから使えなくなるものを一つの表にすると、性格の違いが見えてきます。
| 経路 | 課金 | 認証 | 使えなくなるもの（抜粋） |
|---|---|---|---|
| Claude for Teams / Enterprise | シート + usage credits（API 単価） | claude.ai の SSO またはメール | 他のエージェントの相乗り |
| Anthropic Console | API 従量 | API key | Claude Code on the web、Remote Control、Code Review などサブスク限定の機能 |
| Amazon Bedrock | AWS 従量 | IAM または Bedrock API key | WebSearch、fast mode、analytics dashboard、server-managed settings |
| Claude Platform on AWS | AWS Marketplace（CCU 単位、月末後払い） | IAM SigV4 または workspace key | fast mode、analytics dashboard、GitHub Actions |
| Google Cloud Agent Platform | GCP 従量 | GCP credentials | fast mode、analytics dashboard |
| Microsoft Foundry | Azure 従量 | API key または Entra ID | fast mode、analytics dashboard、GitLab CI |
公式は「ほとんどの組織には Teams か Enterprise が最良」と書いています。実際、サブスクは窓口を Anthropic 側が持っていて、admin 設定で組織や個人ごとの spend limit を切れます。Enterprise ならグループ単位の上限も置けて、75% と 90% で通知が飛びます。Team は Standard シートが月払い $25 で Pro の 1.25 倍、Premium シートが月払い $125 で 6.25 倍、上限を超えたら usage credits を API 単価で買い足す形です。Enterprise は 2026 年 8 月時点の現行プランがシート $20 に加えて Claude、Claude Code、Cowork の全利用を API 単価で請求する形に変わっていて、シートごとの利用上限はありません。
ここで押さえておきたいのが二つあります。一つは、サブスクの上限が token ではなく 5 時間と週の時間枠で決まることです。同じシートでも cache の効き方やモデル構成で使える量が変わります。もう一つは prompt cache の寿命で、サブスクは 1 時間、API key と cloud provider、それから usage credits を消費している間は 5 分です。長いセッションを中断して戻ったときの cache miss が、経路によって起きやすさを変えます。
そして、複数のエージェントを束ねる話に直結するのが認証の縛りです。Anthropic は 2026 年 2 月に Consumer Terms を改訂し、Free、Pro、Max の OAuth 認証を第三者のハーネスから使うことを禁止しました。4 月 4 日から実際にブロックされたと報じられています。公式の法務ページにも、第三者の開発者が Claude.ai ログインを自分のアプリケーションに組み込むことや、Pro / Max の credential でユーザーの代わりにリクエストを流すことは認めない、とはっきり書かれています。つまり OpenCode や Pi、Codex 系のツールで Claude を使うなら API key か cloud provider の credential が要ります。
この構図は Anthropic に限りません。OpenAI 側も Codex CLI は ChatGPT のサブスクで動き、web、CLI、IDE が 5 時間と週の枠を共有し、超過分は credits を買い足す必要があります。チーム向けは Business プラン（旧 Team）で、2026 年 8 月 10 日には Standard の 5 倍の枠を持って 5 時間上限も外れる Premium シートが発表されました。月払い $125、年払い $100 で、Claude の Team Premium と同じ値札です。各社とも、自社の first-party agent は自社サブスクへ載せ、第三者のツールと他社モデルは API の従量で払う、という二段構えに揃いつつあります。窓口の数は、使うエージェントの会社の数に共通の従量を足した分だけ増えていくわけです。
自分が多重管理から抜けられない理由は、結局ここにありました。サブスクは各社が自社の agent 専用に用意した窓口なので、安く回せる代わりに、複数社のサブスクを一つの窓口へまとめる方法がありません。まとめたければ、サブスクをやめて全エージェントを API の従量課金へ載せ替え、自前の窓口で受けることになります。ただしそうすると、これまで定額が吸収していた token 消費が、そのまま請求書に並びます。Claude の場合は prompt cache の寿命も 1 時間から 5 分へ縮むため、同じ使い方でも cache の効きが悪くなり、請求はさらに膨らむ方向です。どちらを取るかは、次章の数字を見てから決めたいところです。
ヘビーユーザーの実データで課金経路を当てはめる
自分の Claude Code の直近 30 日分（2026-07-31〜08-29）を ccusage で集計したもので、チーム内でも重い部類の 1 名の例として読んでください。この表に含まれるのは Claude Code の消費だけです。ほかに Codex CLI を ChatGPT の Business（旧 Team）プランで、プロジェクトによっては Fireworks AI の従量課金でオープンウェイトモデルも使っていますが、それらは別の窓口の話なのでこの数字には入っていません。
| 区分 | 30 日の量 |
|---|---|
| 入力（cache 外）+ cache 書き込み | 132.5M tokens |
| cache 読み出し | 6,621.6M tokens |
| 出力 | 23.7M tokens |
| 合計 | 6,778M tokens |
| Anthropic API 定価に換算した額 | $7,879 |
| 実際の支払い | 月 $200 の定額プラン |
全体の 98% が cache read です。以前の集計では、人間が出した指示 1 本から平均 21 ターンのエージェントループが回っていました。毎ターン全コンテキストを読み直すので、token の総量はこの桁になります。定額プランはこの構造をそのまま吸収してくれていて、API 定価換算の 40 分の 1 で使えている計算です。
公開されている平均値と並べると位置が分かります。Anthropic のコスト管理ページは、企業展開での平均を 1 人あたり稼働日 $13、月 $150〜250 とし、90% のユーザーは稼働日 $30 未満だとしています。冒頭で触れた報道は月 $500〜2,000 でした。自分の 30 日は定価換算で $7,879 なので、平均の 30 倍以上、報道の上限の約 4 倍という位置です。
この数字で課金経路を当てはめると、cache hit 率が結論を決めます。従量経路へ載せ替えても、いまの 98% 近い hit 率を保てるなら、月額は cache read 単価に支配されて比較的穏やかです。ところが cache read の単価が入力の 1 割前後という価格体系では、hit 率が 90% に落ちると自分の試算で従量換算が約 1.8 倍、50% なら約 4.9 倍に跳ねます。サブスクの 1 時間 cache と API の 5 分 cache の差が効いてくるのはこの部分で、同じ作業でも経路が変わるだけで請求の桁が動きかねません。
個人的には、この感度が「サブスクが安い」の正体だと思っています。後の実測章で見るように、Claude Code は「connected」と一語返すだけの呼び出しでも 33,359 token を cache に書き込みます。tools の定義と system prompt がそれだけの長さで、以降のターンはそれを読み直す。エージェントの請求は生成した文章の量ではなく、読み直した文脈の量で決まる、という感覚を持っておくと、次章の構成パターンの見え方が変わります。
窓口をどこに置くか、七つの構成パターン
2 層目の窓口を、課金経路と組み合わせて七つ並べます。列は課金、帰属の単位、予算の効かせ方、使えるエージェント、失うものです。
| # | 構成 | 課金 | 帰属の単位 | 予算の効かせ方 | 使えるエージェント | 失うもの |
|---|---|---|---|---|---|---|
| P1 | Team / Enterprise のサブスクのみ | シート + usage credits | user / group（org analytics） | admin の spend limit、75% と 90% の通知 | Claude Code、Cowork、Desktop | 他のエージェント、モデル振り分け、request 単位の監査 |
| P2 | Console API + 共通 Gateway（LiteLLM / Bifrost） | API 従量 | virtual key（user / team） | key と team の budget、budget fallback | 全部 | サブスク限定の機能、Gateway の運用と供給網リスク |
| P3 | Bedrock + Claude apps gateway | AWS 従量 | OIDC の sub |
gateway の spend limit（日 / 週 / 月）と AWS Budgets | Claude Code、Desktop | WebSearch、1 時間 cache、CI 用の service token、他のエージェント |
| P4 | Bedrock + 共通 Gateway | AWS 従量 | virtual key と IAM principal | gateway の budget と Budget Actions | 全部 | beta 機能の一部、WebSearch、オープンウェイトの鮮度 |
| P5 | Claude Platform on AWS + Gateway | AWS Marketplace（CCU） | workspace と gateway key | workspace limit と gateway の budget | Claude Code と API クライアント | サブスク限定の機能、fast mode、Advisor |
| P6 | 既存の API Gateway を拡張（Envoy AI Gateway / Kong） | 上流に依存 | 既存の consumer / key | 既存の rate limit と AI plugin の token 制限 | 全部 | Claude Code 固有 header への追従、機能劣化の検知 |
| P7 | ハイブリッド（first-party agent は各社サブスク、残りは共通 Gateway） | 各社シート + API 従量 | user（OTel の user.id で突合） |
各社 admin の spend limit と gateway の budget の多重管理 | 全部 | 予算の一元化 |
P3 の Claude apps gateway は、2026 年 6 月 29 日に公開された Anthropic 公式のセルフホスト Gateway です。claude バイナリに同梱されていて claude gateway --config gateway.yaml で起動し、OIDC の IdP でサインインさせ、Bedrock や Claude Platform on AWS、Agent Platform、Foundry、Anthropic API を upstream に failover つきで束ねます。spend limit は Admin API で user、group、organization ごとに日・週・月で切れて、超えると 429 の billing_error を返し、Claude Code 側は 75% と 95% で警告を出します。一方で CI 向けの service token はなく、WebSearch は無効、cache の 1 時間 TTL も使えません。そして載るのは Claude Code と Claude Desktop だけです。公式ドキュメントを読んだ範囲での整理で、今回は実測していません。
P2 と P4 の共通 Gateway は、LiteLLM と Bifrost が代表です。LiteLLM は virtual key に budget と期間、モデル制限を持たせられて、予算が尽きたら安いモデルへ落とす budget fallback もあります。ただし 2026 年 3 月 24 日に PyPI へ不正な 1.82.7 と 1.82.8 が公開される供給網の事故があったので、採用するなら版の固定を前提にしたいところです。Bifrost は Go の単一バイナリで Postgres だけに依存する、依存の少なさが持ち味の実装です。P6 は Envoy AI Gateway や Kong のように、既に API Gateway を運用している組織が AI 用の plugin を足す道で、Envoy は v0.4.0 で Anthropic Messages を Bedrock Converse へ変換する translator を入れています。
自分の現状は P7 です。図にすると、窓口がサブスクの数だけあって、観測だけが合流している形になります。
表を眺めて気づくのは、「全部のエージェントが載る」列と「予算が一か所で効く」列が同時に立つ行がないことです。P2 と P4 は全部載りますが Claude Code のサブスク機能を手放し、P1 と P3 は予算が一か所で効きますが Claude Code しか載りません。P7 は全部載りますが、予算の管理はサブスクの数だけ増えます。理想形を考えるというのは、この諦めた 1 列をどう埋めるかの話になりそうです。
共通 Gateway に三種類のエージェントをつないでみた
ここからが本題です。P2 と P4 の「全部載る」側を、実際に一台で受けてみました。普段利用している端末に LiteLLM v1.98.0 と Postgres を立て、利用者ごとの virtual key を 4 本発行して、3 種類のエージェントをつなぎます。upstream は Claude Code が Bedrock の Sonnet 5、Codex CLI が OpenAI の gpt-5.6-terra、OpenCode が Fireworks AI の DeepSeek V4 Flash です。Anthropic Console の key と claude.ai のログインは使っていません。Codex CLI はふだん ChatGPT のサブスクでも動きますが、ここでは共通の窓口に載せること自体が目的なので API 経路で受けています。
| エージェント | Gateway へ話す形式 | 設定した場所 | upstream |
|---|---|---|---|
| Claude Code | Anthropic Messages | ANTHROPIC_BASE_URL と ANTHROPIC_AUTH_TOKEN、専用の config dir |
Bedrock us.anthropic.claude-sonnet-5 |
| Codex CLI | OpenAI Responses | CODEX_HOME 専用の config.toml、wire_api = "responses" |
OpenAI gpt-5.6-terra |
| OpenCode | OpenAI Chat Completions | OPENCODE_CONFIG 専用の設定、{env:...} で key を注入 |
Fireworks AI deepseek-v4-flash-0731 |
確認した結果は次のとおりです。
| 確認したこと | 結果 |
|---|---|
| 3 系統の疎通 | Claude Code は 1 turn で応答、Codex は ls を 1 回実行して回答、OpenCode は bash tool で ls を実行して回答 |
| prompt cache の維持 | Claude Code でファイル読み取りを挟む 2 turns のうち、2 回目の呼び出しから cache read 66,551 token。Bedrock 経由でも cache が効いた |
| 利用者別の帰属 | key 別に spend が分かれ、alice $0.1272、bob $0.0337、carol $0.0074。/spend/logs の行合計と /key/info の spend が一致 |
| 予算超過 | max_budget を $0.000004 にした key で 3 回目の呼び出しが HTTP 429 の budget_exceeded。Retry-After は付かない |
| モデル制限 | Sonnet 5 だけ許可した key で Opus 5 を要求すると HTTP 403 の key_model_access_denied |
| header の転送（既定） | anthropic-beta は Gateway が body から作り直し、client が付けた未知の値は落ちる。x-claude-code-session-id と traceparent は届かない |
| header の転送（設定後） | forward_client_headers_to_llm_api: true で x-claude-code-session-id と x-app: cli が届く。anthropic-beta の作り直しと traceparent の欠落は変わらない |
| session 単位の集計 | header 転送が既定のままでも、spend log の session_id に Claude Code の session ID が入る。metadata.user_id の JSON から Gateway が取り出していた |
| 1 時間 cache の維持 | ttl: "1h" と beta header が Bedrock まで届き、書き込みが 1 時間バケットへ計上された。Claude Code からも ENABLE_PROMPT_CACHING_1H=1 で同様。書き込み単価が上がるため同じ 1 turn の見積は $0.0887 から $0.1382 になる |
疎通と帰属、予算、モデル制限は期待どおりでした。予算超過が 429 で返るのは Claude apps gateway と同じ番号で、エージェント側の retry から見ると同じ扱いになります。ただ Retry-After が無いので、いつ解除されるかはエージェントには分かりません。
目を引いたのは header の扱いです。Claude Code の gateway protocol は anthropic-beta を open list として verbatim に転送するよう求めていますが、LiteLLM は body の内容から beta header を作り直します。今回の Bedrock 向けには effort-2025-11-24,interleaved-thinking-2025-05-14 が付いていました。Claude Code 側で experimental beta を無効にしていたので実害はありませんでしたが、Claude Code が新しい capability を header で送り始めたとき、Gateway が知らない値は黙って落ちる構造です。cache_control と metadata.user_id は届いていたので、cache と帰属は守られています。
もう一つ、コストの数字が二つ出ました。同じ 1 turn の呼び出しを Claude Code は $0.0887 と見積もり、LiteLLM の spend log は $0.0976 と記録しています。どちらも定価表からの見積で、請求の正は Bedrock 側です。Gateway を入れると「誰がいくら」が取れる代わりに、見積の出所が増える点は覚えておきたいところです。
振り分けと実行側は Gateway の外に置く
3 層目の振り分けと 4 層目の実行側は、前回記事で Switchyard と Relay に割り当てた層です。今回の課金経路の話を重ねると、置ける場所がはっきりします。
Switchyard の仕事はモデルの選択です。ところがサブスク経路では、Claude Code の内側でモデルを差し替える余地がありません。OAuth の credential は Claude Code の外に出せず、ANTHROPIC_BASE_URL だけを Gateway へ向けてもサブスクの課金と利用上限が適用されたままです。だから振り分けが効くのは従量経路と、Claude Code 以外のエージェントの側です。NVIDIA は 2026 年 8 月 11 日のブログで Switchyard を open source の model routing library と位置づけ直していて、GitHub のリリースは 8 月 29 日時点で v0.2.0 が最新のままです。Relay 0.8 は Switchyard server との連携を外し、Switchyard 0.3.0 で dynamic plugin として配布される予定になっています。振り分けの層を Gateway の中に固定せず、差し替え可能な部品として外に置いておく方が、この移行期には都合がよさそうです。
Relay の仕事は agent の実行記録と制御です。各開発者の端末に置いて、tool 実行と LLM 呼び出しを一つの作業として記録し、OTLP で中央の Collector へ送ります。前回の実測で見たとおり、Relay の PII redaction は観測データが対象で、provider へ送る本文は変えません。送信前に消したい情報があるなら、Relay の request middleware に DLP を差し込む形になります。Gateway が窓口で見るのは「誰がどのモデルにいくら使ったか」であって、「どのファイルを読んで何を実行したか」は端末側の Relay にしか見えません。
| 層 | 部品 | 置ける経路 | 置く場所 | 2026-08-29 時点の制約 |
|---|---|---|---|---|
| 3. 振り分け | Switchyard | 従量経路、Claude Code 以外 | 共通 Gateway の後段 | strong / weak の 2 tier、0.3.0 の dynamic plugin は未リリース |
| 4. 実行側 | Relay | すべて（agent の hook で動く） | 各開発者の端末 | PII redaction は観測用、送信前の DLP は middleware で別途用意 |
「Switchyard や Relay の活躍の場もありそうか」と聞かれたら、あると答えられるでしょう。ただし主役は窓口ではなく、その前後です。サブスクで Claude Code を回しつつ、他のエージェントの経路で Switchyard に振り分けさせ、端末側の Relay で全エージェントの実行を揃えて中央へ送る。P7 の二重管理を前提にしても、振り分けと実行側はこの置き方で両方の経路に効きます。
観測と財務帰属を一か所に合流させる
5 層目の観測は、P7 で唯一合流している層です。何を、どの単位で、どこから取れるかを並べます。
| 帰属の元 | 単位 | 取れるもの | 経路 |
|---|---|---|---|
| Claude Code の OpenTelemetry | user.id、user.email、session.id |
claude_code.cost.usage、claude_code.token.usage、tool と API のイベント |
すべての経路 |
| Gateway の spend log | virtual key、team、session | モデル、token、spend、request 単位の記録 | 従量経路 |
| AWS CUR 2.0 | IAM principal、session tag | Bedrock の請求行を呼び出し元の identity で分けたもの | Bedrock |
| Enterprise Analytics API | user | Claude Code を含む利用と cost の日次レポート | Enterprise プラン |
Claude Code の OpenTelemetry は、CLAUDE_CODE_ENABLE_TELEMETRY=1 と OTLP の endpoint を managed settings の env で配れば、開発者側の設定より優先して強制できます。OTEL_RESOURCE_ATTRIBUTES に team.id や cost_center を足しておくと、財務の軸で集計できるようになります。公式ドキュメントも、per-user の token と cost を自分の観測基盤へほぼリアルタイムで流せるのは OpenTelemetry だけだ、と書いています。
Bedrock 側は 2026 年 4 月 9 日から、IAM principal ごとのコスト配賦が Cost Explorer と CUR 2.0 に入りました。application inference profile とコスト配分タグで部門ごとに分ける方法も 8 月 13 日の AWS Architecture ブログで案内されています。AWS Budgets の Budget Actions で上限到達時に Deny のポリシーを自動適用する使い方もありますが、Budget Actions が使えるのは月次以上の予算で、日次では組めません。日単位の止め方は Gateway 側に持たせることになります。
規模別に描く 2026 年 8 月の理想形
ここまでの材料を規模別に置きます。理想形といっても、8 月 29 日時点で組める部品で描いた形です。
| 層 | 個人 | 5〜20 人のチーム | 全社 |
|---|---|---|---|
| 1. 課金経路 | 各社サブスクの定額 | 各社のチームシート（Claude Team Premium、ChatGPT Business Premium）+ 残りの API 従量 | Enterprise または cloud marketplace + 共通の従量経路 |
| 2. 窓口 | なし | claude.ai admin + 共通 Gateway（LiteLLM / Bifrost） | IdP 連携の Gateway（Claude apps gateway または共通 Gateway）+ spend limit |
| 3. 振り分け | なし | 共通 Gateway の budget fallback、必要なら Switchyard | Switchyard を差し替え可能な部品として後段に |
| 4. 実行側 | なし | 端末の Relay は任意 | 端末の Relay + 送信前 DLP + managed settings の permission |
| 5. 観測・帰属 | ccusage と /usage |
Claude Code の OTel + Gateway の spend log を一つの Collector へ | 上記 + CUR 2.0 の IAM principal + Analytics API を財務の集計に接続 |
全社の形を図にすると次のようになります。
理想形を一文にすると、窓口は一か所、振り分けと実行側は差し替え可能、観測は合流、です。全社の行では Claude Code もサブスクではなく従量経路へ載せて窓口を一つにしています。これで P7 の「予算の一元化」の穴は埋まりますが、代わりにサブスク限定の機能と 1 時間の cache を手放します。ヘビーユーザーの章の数字でいえば、cache hit 率を高く保てる運用ができるかどうかが、この選択の損益を決めます。
もう一つ、窓口を一か所へ集めるほど、窓口そのものが単一障害点になります。managed settings で ANTHROPIC_BASE_URL を全員へ配る構成は、Gateway が止まった瞬間に全員の手が止まる構成でもあります。Gateway 本体をステートレスにして LB の後ろへ複数並べ、spend を持つ Postgres を HA にするのが土台ですが、それでも決めておきたい判断が三つあります。一つ目はストリームを壊さないこと。Claude Code は 300 秒無通信でストリームを打ち切るので、LB やプロキシの idle timeout と keep-alive ping の転送を先に確認します。二つ目は予算チェックの fail-open と fail-closed の選択で、Claude apps gateway の既定は fail-open、つまり DB 障害時に推論を止めない代わりに未計測の支出を許します。三つ目は、緊急時に Gateway を迂回して直結へ逃がす脱出路を残すかどうか。これは可用性というより、鍵の統制をどこまで緩めるかという組織の判断です。
単一障害点を避ける手として、Gateway を共有せず、設定を揃えたものを各ユーザーの環境へ配布する形も考えられます。現在は検証中の環境を各自ローカルの Docker へ配布して、置き場所は状態と鍵で決めるという整理に落ち着きました。ローカル配布は振り分けと実行側、それから観測の送出にはうまい具合にはまります。一方で窓口だけは、ローカルに置くと強制になりません。予算もモデル制限も、自分の設定ファイルを書き換えれば外せてしまうからです。ローカル配布で窓口を成立させたいなら、鍵を利用者別に発行して、強制を provider 側へ移すことになります。Console なら workspace の spend limit、Bedrock なら IAM principal と Budgets です。共有の窓口が単一障害点を抱えるのと、窓口の強制を provider へ寄せて Gateway を軽くするのとの取り引き、と捉えるのがよさそうです。
個人的には、5〜20 人の行がいちばん現実的で、しばらくは P7 のままだろうと思っています。各社のサブスクは、Claude なら cache の 1 時間、どちらも時間枠の上限という形で、ヘビーユーザーの分をよく吸収してくれます。そこを崩してまで窓口を一つにする理由は、監査の要件が出てくるまで薄い。一方で、どのサブスクにも載らないエージェントやモデルを全員が使い始めた時点で共通 Gateway は避けられないので、そちらは先に立てておいて、観測だけ先に合流させておくのが順番かなと思っています。
まとめ
チームで coding agent を使うための AI Gateway を、課金経路、窓口、振り分け、実行側、観測の五つの層に分けて構想してみました。
いちばんの結論は、最初に選ぶ課金経路が残りすべてを決める、ということです。サブスクを選べば、窓口と予算管理は各社が持ってくれて、定額でヘビーな利用も吸収してくれます。その代わり、載るのはその会社の agent だけです。従量を選べば、どのエージェントでも一つの窓口に載せられます。その代わり、窓口は自分で運用することになり、cache の寿命も短くなって請求は膨らみやすくなります。安さを取ってサブスクを会社ごとに増やすか、束ねやすさを取って従量へ寄せるか。多重管理の正体は、この二択を各社に対して繰り返している状態でした。
従量側の窓口が実際に機能することは、LiteLLM 一台で確かめました。Claude Code、Codex CLI、OpenCode を利用者別の key で受けて、誰がいくら使ったかの帰属、予算超過での 429、モデル制限の 403、それから 1 時間 cache の維持まで動きます。一方で、Gateway が header を作り直したり、コストの見積が Claude Code と食い違ったりと、間に一枚挟むことの代償も見えました。
その上での理想形は、窓口は一か所、振り分けと実行側は差し替え可能な部品として外へ、観測は一つの合流点へ、という形です。とはいえ自分は当面、first-party agent を各社のサブスクに残したハイブリッドを続けるつもりです。窓口を本当に一つへ寄せるかは、従量でも cache hit 率を保てるかと、request 単位の監査がどこまで要るかで決まると思っています。
Claude apps gateway そのものと、Anthropic API を上流にしたときの挙動はまだ試せていません。Switchyard 0.3.0 の dynamic plugin が出たら、振り分けの層をこの構成の後段に足して試してみたいところです。
参考リンク
- Run Claude Code through a gateway — Claude apps gateway と他社 Gateway の選び方
- Gateway protocol reference — Gateway が転送すべき header と body、壊れる機能の一覧
- Claude apps gateway / spend limits
- Manage costs effectively — 1 人あたりの平均コストと組織別のコスト管理
- Monitoring — OpenTelemetry の metrics と属性
- Enterprise deployment overview — 配備 6 経路の比較表
- Legal and compliance — OAuth と第三者ツールの扱い
- What is the Team plan? / What is the Enterprise plan?
- Manage usage credits for Team and seat-based Enterprise plans
- Codex pricing — ChatGPT プランに含まれる Codex と 5 時間・週次の枠
- Premium seats are coming to ChatGPT Business（2026-08-10 発表）
- Amazon Bedrock now supports cost allocation by IAM user and role（2026-04-09）
- Track generative AI costs with Amazon Bedrock inference profiles（2026-08-13）
- Introducing Claude apps gateway for AWS（2026-07-08）
- Claude Code Quickstart | LiteLLM / Security Update: Suspected Supply Chain Incident
- Microsoft cancels Claude Code licenses, shifting developers to GitHub Copilot CLI（Windows Central）
- NVIDIA Nemotron 3.5 Lightning and NeMo Switchyard Deliver Faster, Smarter, More Efficient Agentic AI（2026-08-11）
- NeMo Relay Release Notes — 0.8 での Switchyard 連携の削除と 0.3.0 の予告
