モデルガバナンスの記事では、availableModels / enforceAvailableModels で「使ってよいモデルを固定する」設定を扱いました。では、それを組織全体に、開発者が外せない形で、自社クラウド経由で効かせるにはどうするか——その答えが Claude apps gateway です。開発者の Claude Code と モデルプロバイダの間に立つセルフホストのコントロールプレーンで、SSO・モデル制御・コスト按分・テレメトリを自前基盤に集約します。本記事は、この gateway をガバナンスの実行インフラとして整理します。
到達点
- gateway が何を解決するか(資格情報の集約・IdP ベースのアクセス・自社クラウド経由)
- 5 つの提供価値(credentials / access control / settings / telemetry / routing)
- 開発者に何が強制されるか
- セットアップの骨子と、「private ネットワーク限定」というセキュリティガード
- 制約(web search 不可・1h キャッシュ不可・OIDC のみ・CI 非対応)と Claude Enterprise との使い分け
何を解決するか
想定は、推論を自社のクラウドプロバイダ経由で通す必要がある組織です(例:データレジデンシー要件)。gateway を挟むと——
- 上流の資格情報(API キー / クラウド資格情報)は自社インフラだけに置かれる。開発者のマシンには載らない
- 開発者は 企業の IdP(OIDC)でサインインし、短命の bearer トークン(既定 TTL 1 時間)を受け取る
- オフボーディングは IdP で完結:ユーザーを無効化すれば、セッション寿命(既定 1 時間)以内にアクセスが失効する
claude バイナリに内蔵されているのが特徴で、ラップトップで Claude Code を動かすのと同じ実行ファイルが、claude gateway --config gateway.yaml で gateway サーバとして動きます。
5 つの提供価値
| 領域 | 内容 |
|---|---|
| Credentials | 上流資格情報は自社内のみ。開発者は SSO で短命トークンを得る。失効は IdP で |
| Access control | IdP グループ → モデル許可リスト + managed settings を server-side で強制。非許可モデルはリクエストを拒否。開発者はポリシーを上書きできない |
| Settings delivery | managed settings を gateway 自身がクライアントへ配信(claude.ai 管理コンソールの server-managed settings を代替) |
| Telemetry | Datadog / Splunk / ClickHouse 等へ OTLP メトリクス(トークン数・モデル・ユーザー識別・レイテンシ)。プロンプト/生成内容は保存しない |
| Upstream routing | クライアントは gateway に Messages API を話し、gateway が Bedrock / Claude Platform on AWS / Vertex / Foundry / Anthropic API へ翻訳・フェイルオーバー。リージョン/プロバイダの変更を開発者に気づかせず行える |
重要な点として、gateway のデータプレーンは、Anthropic API を上流に設定しない限り Anthropic に何も送りません。テレメトリ・監査ログ・managed settings・IdP アイデンティティの行き先は、すべて組織が握ります。
開発者に何が強制されるか
サインイン済みの gateway セッションでは、次が保証されます。
- モデルアクセス:ポリシーが許可しないモデルへのリクエストは 400。
/modelピッカーは許可リストに絞られる(enforceAvailableModels: trueを併用して Default も許可内に解決させるのが定石) - 資格情報:gateway トークンがセッション唯一の資格情報。
ANTHROPIC_API_KEY/ANTHROPIC_AUTH_TOKEN/apiKeyHelper/ 既存の claude.ai ログインはすべて無視される - managed settings:ロックされたキーはローカルで上書き不可。起動時 + 毎時ポーリングで適用
- テレメトリ先:OTLP エクスポート先が gateway に固定され、ローカルの
OTEL_*を上書き - 起動:gateway 到達不能なら、設定なしで起動せず約 10 秒でエラー終了(fail-closed)
- デプロビジョン:IdP で無効化されたユーザーのセッションは、次回リフレッシュ失敗時(TTL 以内)に失効
claude -p(非対話)や Agent SDK 経由のセッションも、サインイン後はすべて gateway セッションを通り、同じポリシーが効きます。
セットアップの骨子
前提と手順の要点です。
前提:Claude Code v2.1.195 以降(サーバ・開発者双方)、OIDC の IdP(Okta / Entra ID / Google Workspace / Keycloak 等。SAML / LDAP 非対応)、PostgreSQL 14+、HTTPS、そして Linux サーバ(macOS はローカル開発のみ、Windows サーバ非対応)。
手順:①IdP に OIDC クライアント登録 → ②Postgres 用意 → ③gateway.yaml(listen / oidc / session / store / upstreams の 5 節)を書く → ④Docker Compose かバイナリで起動 → ⑤開発者マシンの managed settings に forceLoginMethod: "gateway" と forceLoginGatewayUrl を配布 → 開発者は /login。
// 開発者マシンの managed settings(MDM 等で配布)
{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}セキュリティガード:private ネットワーク限定
見逃せない設計が、gateway のアドレスは private でなければ /login が拒否するという制約です。理由は明快で——信頼された gateway は、開発者マシン上でコマンドを実行しうる設定(managed settings)を push できるから。だから gateway は内部 LB / VPN の背後に置き、private IP のみに解決するホスト名を与える必要があります。加えて、CLI は初回接続時に TLS 証明書をピン留めし、フィンガープリントを表示します(証明書ローテーションは計画イベントとして扱う)。
制約と Claude Enterprise との使い分け
gateway 経由では効かない機能があります。
| 機能 | gateway 経由 |
|---|---|
| server-side web search | ❌(どの上流か CLI から見えず無効化) |
| 1 時間キャッシュ TTL | ❌(5 分のみ。全上流が 1h を持たないため) |
| first-party 最適化(global cache scope 等) | ❌ |
| CI 用サービストークン | ❌(ブラウザ device flow のみ。無人 CI は不可) |
| SAML / LDAP | ❌(OIDC のみ) |
| マルチテナント(複数 issuer) | ❌(1 gateway = 1 issuer) |
| 管理 UI | ❌(設定は YAML、変更は再デプロイ) |
そして最上位の判断軸:「自社クラウド経由が必須(データレジデンシー等)」なら gateway。そうでなく SCIM プロビジョニングや Claude Code の web / mobile が欲しいなら、Claude Enterprise の方が適合します。gateway は「自前で束ねる」ための道具であって、万能ではありません。
モデルガバナンスとの接続
この gateway は、モデルガバナンスで扱った availableModels / enforceAvailableModels を、組織全体に server-side で強制する実行レイヤです。個々の開発者が settings を書いても、gateway の管理ポリシーが上位で効き、非許可モデルはサーバ側で 400。「設定で縛る」を「インフラで縛る」に格上げする——それが gateway の役割です。あわせてユーザー/グループ別の spend limit で、暴走ワークロードが commitment を食い潰すのも防げます。
まとめ
Claude apps gateway は、開発者の Claude Code とモデルプロバイダの間に立つセルフホストのコントロールプレーンです。claude バイナリ内蔵で、開発者は IdP(OIDC)で SSO サインイン、上流資格情報は自社インフラのみ、IdP グループごとにモデル・設定を server-side で強制、テレメトリは自前の監視基盤へ、推論は選んだクラウドへルーティング。
勘所は 3 つ — 「自社クラウド経由が必須」かで Claude Enterprise と使い分ける、gateway は private ネットワーク限定(設定 push の信頼境界)、web search / 1h キャッシュ / CI サービストークンは効かない。個人開発では出番のない機能ですが、Claude Code をチーム・組織に本格展開する段になったら、ガバナンスと自社クラウド要件を同時に満たす中核の選択肢になります。