コンテンツにスキップ

LLM Gateway による組織ガバナンス — 国内外の実践事例と Claude Code の繋ぎ方

作成日: 2026-09-15 出典 / きっかけ: 「Claude Code の利用を組織でどう可視化・統制するか」の調査。日本語事例（電通総研 Fintan・LayerX 等）に対して海外の実名事例を一次資料で裏取りした回 関連: llm_gateway_製品比較_oss_有償_機能_aws構成_整理（製品選定・OSS/有償・AWS 構成はこちら） / layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理 / 社内mcp共通基盤_認証認可ログ_整理 / ai_ガバナンス_誰がnoと言えるか_整理 / aiコーディングエージェント_sandbox隔離と権限運用_他社比較_整理 / エアークローゼット_46リポジトリ知識グラフとllm_observability_整理 / dmm_ai開発生産性_予算戦略と投資対効果_石垣雅人_整理 / cyberagent_ai活用レベル定義と数値レポート_整理

0. 要点（3行）

  • Gateway が解いているのは「モデル配布」ではなく「鍵の所在」問題。全社共通の型は 開発者は gateway の資格情報しか持たず、provider の本物の鍵はサーバ側に閉じる。Uber・Grab・Zalando・Shopify・Wealthsimple・電通総研、調べた事例が例外なくこの形で、可視化もコスト上限もこの構造の副産物として後から付いてくる。
  • 効いているのは絶対値（モデル単価）ではなく相対: 「鍵を n 人に配る運用」対「1 本の鍵を n 人に貸す運用」の差。前者は退職者の鍵回収・監査・按分が全部人手だが、後者はoffboarding が資格情報 1 本の revoke で済む。AT&T の 56% コスト減は結果であって目的ではない。
  • 2026-06-29 に Anthropic 公式の Claude apps gateway が出て、Claude Code 単体なら自作不要になりつつある。ただし公式仕様として全推論が 1 本の共有アップストリーム鍵を通る＝プロバイダ請求書では個人が見えないため、per-user は gateway 側の spend limit（超過で 429）で持つ設計が明示されている。「請求で見る」のを諦めて「サーキットブレーカで持つ」への発想転換が要る。

1. なぜ gateway なのか — 各社が書いている「建てた理由」

事例の一次資料を並べると、動機は綺麗に 4 つに割れる。コスト削減を第一動機に挙げた社は実はほぼ無い。

動機 具体的に何が辛かったか そう書いている社
① 認証の断片化 provider ごとに認証方式が違う（key 方式 / instance role / cloud credential）。開発者が試すだけで詰まる Grab、Zalando、電通総研
② 重複実装 チームごとに独自に LLM 連携を書き、車輪の再発明が発生 Uber（「disparate integration strategies … inefficiencies and redundant efforts」）
③ データ境界 社外 LLM にプロプライエタリなデータ・PII が出ていくのを止めたい／後から検証したい Wealthsimple、Uber、Grab
④ 属人化した鍵配布 利用者ごとに AWS アクセスキーを払い出す運用を避けたい 電通総研 Fintan、Claude apps gateway 公式

つまり gateway は FinOps の道具として生まれていない。「開発者に鍵を配らずに LLM を使わせる」ための構造で、コスト可視化はその構造上「ついでに取れる」もの。ここを取り違えると、コスト削減の ROI が薄いという理由で導入を見送って、鍵配布地獄だけが残る。

2. 海外の実名事例（一次資料ベース）

2-1. 一覧

社 実装 規模（公開値） 特徴的な設計判断 公開日
Uber 自作（Go・OpenAI 互換 API） 30 チーム / 1,600 万クエリ/月 / ピーク 25 QPS / 60+ ユースケース PII redaction / un-redaction（ANONYMIZED_NAME_0 形式の placeholder に置換→応答で復元）。Python/Java/Go 対応 2024-07-11
Grab 自作（リバースプロキシ群） 300+ ユースケース / 50+ モデル / exploration key 利用者 3,000+ 鍵を 2 種類に分ける（探索用 = 短命・staging 限定 / サービス用 = 本番長期）。Slack bot で申請 2025-02-19
Zalando LiteLLM ベース（2024-01〜）＋ 自作ローカルプロキシ 250+ チーム / 月間 2,000 MAU / 6 pod（2 CPU・4GB） pre-call hook で User-Agent を見て古いクライアントを弾く（強制バージョンアップ）。ローカル側にコスト TUI 2026-08-14
Wealthsimple 自作・OSS 公開（wealthsimple/llm-gateway） 公開時点で 72,000+ リクエスト（2023-04 開始） 自社製 PII 除去モデル＋ヒューリスティクス。社外送信データを全件記録 2024-09-17
Shopify 自作 LLM proxy 非公開 Claude Code / Copilot / Cursor / Codex / Gemini を全部同じ proxy 配下に。日次 $250 超で人単位アラート 2026-04-02（BVP 記事）
AT&T LiteLLM ルーター Ask AT&T で 450 億トークン/日 タスク複雑度で安いモデルへルーティング。コーディング等で最大 56% 減・品質低下 2%、従業員クエリの約 40% をオープンモデルへ 2026-08（報道）

※ Shopify は同社の技術ブログではなく Bessemer(BVP) の取材記事が出典（Farhan Thawar VP & Head of Engineering の発言）。AT&T も The Information のインタビューを各紙が報じたもので、一次の技術ブログではない点は割り引いて読む。

2-2. Uber「GenAI Gateway」— OpenAI 互換に振り切る

出典: Navigating the LLM Landscape: Uber's Innovation with GenAI Gateway（2024-07-11 / Roopansh Bansal・Tse-Chi Wang）

Go 製サービスで、OpenAI の HTTP/JSON インタフェースをそのまま模倣する設計。理由が実利的で、LangChain / LlamaIndex などの既存 OSS エコシステムがそのまま刺さるから。社内モデルも同じ API で出す。

最大の特徴は PII の redaction / un-redaction をゲートウェイの責務にしたこと。外部ベンダに送る前に PII を ANONYMIZED_NAME_0 のような添字付き placeholder に置換し、応答が返ってきたら復元する。アプリ側に PII 対応を書かせない。監査ログはコスト按分・セキュリティ監査・品質評価の 3 用途と明記されている。

2-3. Grab「AI Gateway」— 鍵のライフサイクルを 2 種類に割る

出典: Grab AI Gateway: Connecting Grabbers to multiple GenAI providers（2025-02-19）

設計は「必要なときだけ介入する」薄いリバースプロキシ群。path ベースの認可で、API キーごとに触れる provider / 機能が決まる。認証を通ると内部キーを provider の本物のクレデンシャルに差し替えて代理実行する。

一番真似しやすいのが鍵の 2 分類:

種別 寿命 制限 用途
Exploration key 数日 レート制限きつめ・staging のみ 触ってみる。Slack bot で即発行
Service key 長期 本番レート プロダクション

「試したい人」と「本番で使う人」で承認の重さを変えることで、ガバナンスを緩めずに探索の摩擦だけ下げている。3,000 人以上が exploration key を使っている、という数字がこの設計の答え合わせになっている。

課題として挙げられているのも正直で、(1) モデル/機能のリリース速度に追従しきれない、(2) バッチ負荷がオンラインサービスのクォータを食う、(3) リバースプロキシゆえに SDK 個別のエッジケースや未実装パスが出続ける — 3 番目は自作 gateway の宿命として重要。

2-4. Zalando — LiteLLM ＋「ローカルプロキシ」の二段構え

出典: Agentic Engineering at Zalando: a snapshot（2026-08-14 / Bartosz Ocytko, Executive Principal Engineer）

2024 年 1 月から LiteLLM ベースの API proxy を運用（OpenAI / Bedrock / Vertex）。フックの使い方が上手い:

  • post-call hook → 匿名化したコスト追跡
  • pre-call hook → User-Agent を見て古いクライアントを弾き、強制的にバージョンアップさせる

2 つ目は gateway を持つ組織だけができる統制で、「全社のエージェント CLI のバージョン下限をサーバ側から動かせる」。セキュリティ修正を全社に行き渡らせる手段になる。

さらに開発者マシン側にもローカルプロキシを置き、トークン失効問題を解決している（auth ヘッダを自動注入、社内 MCP サーバへの Bearer 注入も同様）。このローカルプロキシに TUI が付いていて、モデル別コスト・プロンプトキャッシュの取りこぼし・リクエスト単位のメタデータが見える。「キャッシュが効いていない区間を開発者本人に見せる」のは、中央ダッシュボードでは起きない行動変容を狙っていて筋がいい。

規模は 250+ チーム・月間 2,000 MAU を 6 pod（各 2 CPU / 4GB） で捌く。gateway 自体は驚くほど軽い、という現実的な相場観として使える。

2-5. Wealthsimple — 金融規制下での「PII を自前モデルで消す」

出典: Get to know our LLM Gateway（2024-09-17）／OSS: wealthsimple/llm-gateway

カナダの FinTech。2023 年 4 月稼働で、構成は (1) 社内チャット UI、(2) API ラッパ の 2 本立て。直接 API を叩かせないことを明示的な設計目標にしている。

PII はヒューリスティクスで落としたうえ、自社で開発した PII 除去モデルで補強。社外に出たデータは UI 経由・API 経由とも全件追跡。gateway を OSS 公開しているのが特異点で、github.com/wealthsimple/llm-gateway で読める。

⚠ 「社員の 50% 超が月次で利用」という数字は ZenML の LLMOps データベース側のまとめにあるが、一次記事では従業員比率は非開示。一次記事で確認できるのは「72,000+ リクエスト」まで。

2-6. Shopify — コーディングエージェントを全部 proxy 配下に置く

出典: Inside Shopify's AI-first engineering playbook（Bessemer Atlas, 2026-04-02 / Farhan Thawar, VP & Head of Engineering の発言）

Claude Code・GitHub Copilot・Cursor・OpenAI Codex・Gemini を単一の LLM proxy 経由にしている点が、本題（Claude Code のガバナンス）に一番近い事例。Farhan Thawar（VP & Head of Engineering）の発言として:

  • 「チーム別・プロジェクト別・人別に利用を見られる」
  • 「1 日に $250 以上トークンを使った人がいるとアラートが飛ぶ」
  • トークンのバルク購入で単価を下げられる
  • ツールが provider でなく gateway を向いているので、裏でモデルを差し替えられる

「ツールは増え続ける前提で、共通の計測点を 1 つ持つ」という割り切り。ツールごとに管理コンソールを見に行く運用と比べたときの差が大きい。

2-7. ベンダーサイト掲載の採用企業（LiteLLM）

出典: litellm.ai（掲載証言。自社技術ブログではない）

litellm.ai に実名と肩書き付きで載っている証言。自社技術ブログではないので裏取りの強度は一段落ちるが、規模感の参考に:

社 発言者 要旨
NVIDIA Ajay Dogra（Product） 100 以上のモデルエンドポイントに単一の一貫した方法でアクセス
Netflix David Leen（Staff SWE） 新モデルをリリース当日中にユーザーへ提供できる。「数ヶ月分の作業を節約した」
Okta Dennis Henry（Productivity Architect） バックエンドモデルの変更が設定更新だけで済む。コード変更・調達・セキュリティレビューの再実施が不要
Lemonade Mark Koltnuk（Principal Architect） 複数モデル管理の複雑さを吸収
AT&T Mark Austin（VP, Data Office） ルーティングでコーディング等のコストが最大 56% 減

Okta の証言が gateway の本質を一番よく言い当てている。モデル変更のコストは技術ではなく「調達とセキュリティレビューのやり直し」で、gateway はそれを一度きりにする。

3. 国内事例（前回調査分の要約）

社 / 出典 構成 押さえどころ
電通総研 Fintan LiteLLM（セルフホスト）→ Bedrock 要件定義が最も明快。セルフホスト必須（情報資産保護で SaaS 不可）、チーム別集計かつ他チームの利用は見えない分離要件、利用者ごとの AWS アクセスキー払い出し回避
LayerX Bedrock × LiteLLM × Langfuse（layerx_ai_agent基盤_bedrock_litellm_durable_temporal_整理） LiteLLM をゲートキーパーと位置づけ、仮想キー＋ユーザー/プロジェクト別予算上限。締める線をデータ境界にだけ引く
Zenn / emuni Azure Container Apps 上の LiteLLM 開発者は ANTHROPIC_BASE_URL と ANTHROPIC_API_KEY を入れるだけ。管理者はモデル別・キー別・タグ別・チーム別をダッシュボードで見る
クラスメソッド Claude Code → LiteLLM → Bedrock Virtual Key 単位の費用上限。既知バグと回避策まで書いてあり実装時に有用
Google Cloud Japan Cloud Run 上に自作 → 公式 gateway 登場で方針転換 Vertex の global エンドポイント指定のハマり（vertex_location: "global" で 404）

国内外の差: 日本語記事は「LiteLLM をどう立てるか」の手順に寄り、海外は「自作して何を学んだか」に寄る。設計判断（鍵の分類・フックの使い道・PII の置き場所）を盗むなら海外事例、立ち上げ手順を写経するなら国内事例、という住み分けで読むのが効率的。

4. 共通アーキテクチャ（全事例の最大公約数）

   開発者のマシン                    社内インフラ                     プロバイダ
 ┌──────────────┐        ┌─────────────────────────┐        ┌──────────────┐
 │ Claude Code  │        │        LLM Gateway       │        │  Bedrock     │
 │ Copilot      │──[1]──▶│  ┌───────────────────┐  │──[5]──▶│  Vertex AI   │
 │ Cursor / SDK │        │  │ ① 認証（鍵 or SSO）│  │        │  Anthropic   │
 └──────────────┘        │  ├───────────────────┤  │        │  OpenAI      │
   ▲ 持つのは             │  │ ② 認可（モデル許可）│  │        └──────────────┘
   │ gateway の           │  ├───────────────────┤  │           ▲
   │ 資格情報だけ          │  │ ③ 予算 / レート制限 │  │           │ 本物の鍵は
   │ （provider 鍵は      │  ├───────────────────┤  │           └─ ここだけが持つ
   │   一切持たない）      │  │ ④ PII / ガードレール│  │
   │                     │  ├───────────────────┤  │
   └──────[4]────────────│  │ ⑤ 監査ログ / 計測   │──┼──[6]──▶ データレイク
      429 / 警告ヘッダ     │  └───────────────────┘  │         OTel Collector
                         └─────────────────────────┘         （Datadog 等）

各社の差分はレイヤの実装であって、レイヤの並びは同じ:

レイヤ Uber Grab Zalando Claude apps gateway
① 認証 社内認証 API キー（2 種） LiteLLM 仮想キー OIDC / 企業 SSO
② 認可 — path ベースで provider/機能を限定 User-Agent でクライアント版を強制 IdP グループ → モデル allowlist
③ 予算 レート制限＋コスト管理 key 単位 QPS・コスト上限 匿名化コスト追跡 spend limit（日/週/月・429）
④ PII redact / un-redact プロンプトインジェクション検知（ロードマップ） — （なし。別レイヤの責務）
⑤ 計測 メトリクス＋監査ログ データレイクに全文投入 post-call hook＋ローカル TUI OTLP をコレクタへ中継

5. Claude Code を gateway に繋ぐ（公式仕様）

5-1. 環境変数（公式ドキュメント確認済み）

出典: Enterprise deployment overview / Other LLM gateways

# 自社 gateway へ向ける（Anthropic API 形式）
export ANTHROPIC_BASE_URL="https://llm-gateway.internal.example.com"
export ANTHROPIC_AUTH_TOKEN="<gateway が発行した開発者ごとの資格情報>"

# クラウドプロバイダを gateway 経由にする場合は provider 別の変数
#   ANTHROPIC_BEDROCK_BASE_URL / ANTHROPIC_AWS_BASE_URL
#   ANTHROPIC_VERTEX_BASE_URL  / ANTHROPIC_FOUNDRY_BASE_URL

# 企業プロキシ（gateway とは別物。併用可）
export HTTPS_PROXY="http://proxy.example.com:8080"

セッションがどの provider / base URL / proxy を使っているかは /status で確認できる。

5-2. 落とし穴（公式ドキュメントに明記されているもの）

  • ANTHROPIC_BASE_URL だけ設定してもサブスクリプションは置き換わらない。gateway 用の資格情報（ANTHROPIC_AUTH_TOKEN 等）を併せて設定して初めて、claude.ai サブスクではなく組織の鍵でトークン課金になる。BASE_URL だけだと「gateway を通るが課金とレート制限はサブスク側」という中途半端な状態になる。
  • Anthropic はサードパーティ gateway 製品を保証・監査しない（公式）。また gateway 経由で非 Claude モデルへルーティングする使い方はサポート対象外と明記。
  • Claude Code は release ごとに機能が増え、gateway が新しいヘッダ/ボディを転送しないとその機能が壊れる。何を転送すべきかは公式の gateway 互換ガイドにある。自作 gateway の継続コストはここに出る（Grab の「未実装パスが出続ける」と同じ話）。
  • CMEK（顧客管理鍵）を使っていても、gateway / カスタム ANTHROPIC_BASE_URL 経由セッションの運用テレメトリには CMEK が適用されない。止めるなら managed settings で DISABLE_TELEMETRY を全社配布する。
  • Kong の検証記事によると、リクエストボディ上限を 512KB まで上げる必要がある（Claude Code は大きなコードベースを扱うと巨大なプロンプトを送るため）。通常の API トラフィック前提のプロキシ設定だと落ちる。

6. Claude apps gateway（Anthropic 公式・2026-06-29 発表）

出典: 発表ブログ（2026-06-29）/ Claude apps gateway ドキュメント / Spend limits

自作 LiteLLM の役割のうち Claude Code 部分だけを公式が肩代わりする選択肢。仕様を一次資料で確認した要点。

6-1. 何であるか

  • claude バイナリ自身が gateway サーバになる（claude gateway --config gateway.yaml）。開発者が入れるのと同じ実行ファイル。
  • ステートレスな Linux コンテナ 1 つ + PostgreSQL 14+。サーバは Linux のみ（macOS は開発用、Windows 非対応）。
  • OIDC の Relying Party として企業 IdP（Google Workspace / Entra ID / Okta 等）で開発者がサインイン。開発者は API キーもクラウド資格情報も持たない。
  • IdP グループ → モデル allowlist ＋ managed settings ポリシーをサーバ側で強制。許可外モデルのリクエストは 400 で弾かれ、/model ピッカーからも消える。開発者はポリシーをローカル設定で上書きできない。
  • upstream は Bedrock / Claude Platform on AWS / Google Cloud Agent Platform / Microsoft Foundry / Anthropic API をフェイルオーバー付きで切替可能。開発者は再設定不要。
  • テレメトリは OTLP で自社コレクタへ中継。gateway のデータプレーンは（Anthropic API を upstream に指定しない限り）Anthropic に何も送らない。

6-2. spend limit — 「請求書で個人を見る」を諦める設計

公式ドキュメントが率直に書いている前提:

gateway は全推論を 1 本の共有アップストリーム資格情報で転送するため、プロバイダの請求はすべてその資格情報に紐づき、開発者個人には割り当てられない。spend limit はその共有請求の上に載る開発者ごとのビュー兼サーキットブレーカである。

つまり Cost Explorer で個人別を見るのは構造的に無理で、代わりに gateway が持つ。仕様の要点:

項目 仕様
スコープ user（OIDC の sub）/ rbac_group（IdP グループ）/ organization
期間 daily / weekly / monthly。各期間が独立に判定され、どれか 1 つでも超えたらブロック
金額 USD セントの整数文字列。null = 無制限、"0" = 全ブロック
優先順位 ユーザー個別 → 所属グループのうち最も厳しいもの → 組織デフォルト → 無制限（group_limit_mode: max で最も緩い方に反転可）
超過時 429 / error.type: billing_error / x-should-retry: false、retry-after ヘッダ付き。メッセージに期間とリセット時刻（例: spend limit reached (daily; resets 2026-08-08 00:00 UTC)）
リセット UTC カレンダー境界（日=00:00 UTC、週=月曜、月=1 日）。※ JST 運用だと日次リセットが朝 9 時になる点は要注意
開発者への予告 利用率 75% と 95% で Claude Code が警告。/usage に Spend limit バー（v2.1.251+）、ステータスラインにも rate_limits.spend_limit
グループ上限の意味 プールではなく「1 人あたりのデフォルト」。10 人のグループに $100/日 = 合計 $1,000/日

実装上の細かいが効く仕様:

  • 中断したリクエストも課金対象。ストリームが upstream の最終 usage フレーム無しに終わった場合、送信済みテキストから「出力 1 トークン ≒ 4 文字」で下限見積もりして計上する。途中で Esc を押して上限を回避することはできない。
  • 単価は「override → upstream モデル ID の定価 → マップした models[].id の定価 → 不明モデル階層 $5/$25 per M トークン」の順に解決。未知の ID が無料扱いにならない設計。
  • 金額は見積もりであって請求書ではない。「サーキットブレーカであって invoice ではない、請求はプロバイダの利用レポートと突き合わせよ」と明記。
  • Postgres への事前チェックはタイムアウト 2 秒。到達不能時は既定で fail-open（リクエストは通る）。enforcement.fail_closed_on_error: true で fail-close にできる。「DB 障害を推論障害にしない」か「未計測の支出をゼロにする」かの選択を設定に出しているのが誠実。
  • count_tokens は無料なので絶対にブロックしない。
  • upstream のレート制限ヘッダ（＝共有クォータの話）は剥がされ、開発者自身の上限ヘッダに差し替えられる。
  • 保持期間: spend 13ヶ月 / admin_audit 365日 / principal_emails（PII を含む）最終活動から 90日。DSAR 対応は principal_emails の当該行を直接 DELETE と手順まで書かれている。

6-3. 制限事項（gateway 経由だと使えない機能）

機能 gateway 経由 理由
サーバサイド Web 検索 ✗ CLI が upstream を判別できず対応可否を検証できないため無効化
Remote Control ✗ Anthropic API が必要
/design-sync・/design-login ✗ claude.ai への接続が必要
/import 等 feature flag を引く機能 ✗ gateway セッションではフラグ取得をスキップ

また /login 時に gateway のホスト名が private アドレス（RFC1918 等）にしか解決しないことを要求する。パブリックアドレスは拒否される（脅威モデル由来）。企業プロキシ経由だとプロキシ側も private である必要があり、そうでなければ NO_PROXY に gateway を追加する。

7. 可視化の 4 アプローチ — どれを選ぶか

gateway は選択肢の 1 つでしかない。Bedrock 前提での整理（4 分類は Zenn / kiiwami 記事の枠組みに、公式仕様の裏取りを足したもの）:

アプローチ 手間 取れる粒度 利用量の制限ができるか 向く場面
Bedrock Invocation Logging + CloudWatch Logs Insights 小 リクエスト単位（IAM プリンシパル） ✗（見るだけ） まず現状把握したい。アドホック分析
Application Inference Profile 中 プロファイル単位でコスト配分タグ △（Budgets でのアラートまで） Cost Explorer で厳密に追跡したい。既存の AWS コスト管理に載せたい
LLM Gateway（LiteLLM / 自作 / Claude apps） 大 ユーザー・チーム・プロジェクト・モデル ✓（上限超過で 429） 複数 provider・複数ツール。鍵を配りたくない。強制力が要る
クライアント側 OpenTelemetry 小〜中 セッション・プロンプト・ツール実行・PR/コミット数まで ✗ 開発者体験の計測（どう使われているか）。既存 Datadog 等に載せたい

gateway と OTel は競合しない。むしろ組み合わせが本命。役割が違う:

  • gateway = 入口の統制（誰が何を使えるか・いくらまで）… 止められる
  • OTel = 出口の観測（どう使われたか・効果が出ているか）… 止められないが深い

Claude Code の OTelは gateway では取れない粒度を出す（claude_code.pull_request.count、claude_code.commit.count、claude_code.lines_of_code.count、claude_code.active_time.total、ツール毎の accept/reject）。コスト統制は gateway、生産性評価は OTel で分担するのが素直。cf. cyberagent_ai活用レベル定義と数値レポート_整理

# OTel 側（managed settings で全社配布する前提）
CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=grpc
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4317
# 組織の軸を付与（部門・チーム・コストセンター）
OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

managed settings で OTLP の宛先を設定すると、起動時に開発者がローカルで設定した競合変数を削除する（特に OTEL_EXPORTER_OTLP_HEADERS を設定すると、認証情報が未承認コレクタに漏れるのを防ぐため開発者側のエンドポイント変数を全て消す）。また OTEL_* は Bash / hooks / MCP サーバの子プロセスには引き継がれない。

8. まとめ — 状況 → 推奨

状況 推奨 理由
Claude Code だけ・Bedrock/Vertex 必須（データ所在要件） Claude apps gateway 自作しなくても SSO・グループ別モデル制限・spend limit・OTLP 中継が揃う。claude バイナリ同梱で運用が軽い
Claude Code だけ・データ所在要件なし Claude for Enterprise 公式も「所在要件が無いなら Enterprise の方が良い」と明言（SCIM・web/mobile が付く）
複数 provider / 複数ツール（Copilot・Cursor も） LiteLLM 等の汎用 gateway Shopify 型。共通の計測点を 1 つ持つ価値が最大化する
既に LiteLLM がある そのまま。Claude Code を後ろに繋ぐ 公式も「既存 gateway があるならそれを使え」。ただし互換ガイドに沿った転送の追従コストを見込む
まず現状を知りたいだけ Bedrock Invocation Logging or クライアント OTel gateway は構築・運用の固定費が重い。統制が要らないなら過剰
個人・小規模 不要（OTel だけで十分） 鍵配布問題が存在しないので gateway の主目的が消える

一言で: gateway は「コストを下げる装置」ではなく「鍵を配らずに済ませ、後から誰が何をしたか言えるようにする装置」。コスト削減は副産物で、意思決定の軸は 鍵配布と offboarding の運用コスト に置くのが正しい。

参考リンク

海外事例（一次資料）

Anthropic 公式ドキュメント

ツール・ベンダー

国内事例

作成: 2026-09-15 ／ 最終更新: 2026-09-15