結論：Gatewayの接続元制御と/login許可を分けて決める
Claude Code 2.1.268では、access_control.allow_cidrsが空のGatewayに起動時警告が出て、公開アドレスから最初のrequestが来た時にも一度警告されます。また、gatewayInternalNetworks managed settingで、組織のpublic IPv4 blockからGatewayの/loginを許可できます。
二つは同じ許可リストではありません。前者はGatewayへ到達する経路の安全確認、後者は組織のネットワークからログイン画面へ到達させる条件です。まず公開範囲、ログイン範囲、IdP認証、TLSを別々に台帳化し、警告を消すことだけを目的にCIDRを広げないでください。
根拠はClaude Code公式changelogの2.1.268、公式Gateway configuration、公式Gateway overviewです。Gatewayは自社で運用する中継点で、IdP、モデルアクセス、managed settings、telemetryを企業側で管理します。公式資料にない「社内だけなら安全」という単純化はしません。
二つの設定とネットワーク境界を比較する
| 項目 | 決める対象 | 確認する責任 |
|---|---|---|
allow_cidrs | Gatewayへ到達できる接続元の範囲 | ネットワーク・security担当 |
gatewayInternalNetworks | 指定public IPv4 blockから/loginを許可する条件 | IdP・Gateway管理者 |
| TLS / IdP | 通信の保護と利用者の本人性 | 認証・証明書管理者 |
| rate limit / 監視 | 異常な到達とログイン試行の検知 | 運用・SOC |
CIDRが正しくても、TLS証明書、IdPのredirect URI、セッションの有効期間、rate limitが誤っていれば安全なログイン経路にはなりません。逆に/loginだけを閉じても、既に発行したsessionの扱いや推論requestの到達範囲が整理されていなければ説明が不足します。アクセス制御を「ネットワーク」「認証」「session」「推論」の四層へ分けます。
設定確認の手順：公開範囲を8ステップで診断する
claude --versionで2.1.268以降か確認し、Gatewayのversion、configのhash、確認時刻を記録します。- Gatewayのpublic URL、listen address、TLS termination、reverse proxyの有無を図にし、インターネットから直接到達する箇所を洗い出します。
access_control.allow_cidrsの値を確認し、空の場合は警告を「無視する」のではなく、空である理由と公開要件をOwnerに確認します。- 実際に使うoffice、VPN、private network、管理用踏み台の送信元CIDRを固定し、広すぎる集約範囲を分割できるか検討します。
- 組織のpublic IPv4 blockから/loginを許可する必要がある場合だけ、
gatewayInternalNetworksをmanaged settingsへ段階適用します。 - 許可された経路、許可されない経路、IPv4以外の経路、proxy経由をそれぞれテストし、request時刻と結果だけを証跡にします。
- IdPのredirect、session lifetime、rate limit、証明書更新、監視通知を確認し、認証情報やtokenはログへ保存しません。
- 公開範囲の変更承認、緊急停止、rollback、次回のCIDR棚卸し日を決め、検証ユーザーから展開します。
公開アドレスからの警告は、ただちに侵害を意味しません。意図したreverse proxyやNATなら、経路の説明、送信元の確定、TLS、認証、監視の証拠を一つにまとめます。説明できない公開requestなら、ログを保存しつつ接続を止め、経路と設定を再確認します。警告文を消すための0.0.0.0/0のような広い許可は、診断の失敗を設定に固定するだけです。
導入前に分けるべき料金・制限・運用責任
Gatewayの公開範囲設定は、Claude Codeの専用料金を決めるものではありません。利用モデル、provider、Gatewayの自社インフラ、IdP、監視、TLS、ネットワーク費用を分けて見積もります。Gatewayは自社インフラに置くself-hosted serviceであり、アクセス範囲を狭めたから運用費やprovider料金がなくなるわけではありません。
制限も分けます。CIDRは接続元の集合、managed settingsは利用者への設定配布、IdP groupは本人・所属、モデルallowlistは推論先、rate limitは試行量です。これらを一つの「社内利用フラグ」で代用しないでください。誰がどの設定を変更できるか、公開IPの更新を誰が検知するか、退職・異動時のsessionをどう失効させるかまで担当者を置きます。
既存のGateway認証エラーの記事はAPIキー、SSO、managed settingsの切り分け、HTTP hook許可リストの記事は外部送信先のfail-closedを扱います。今回の検索意図は、Gatewayの入口と/loginの到達範囲です。MCP、hook、telemetryの許可設定をCIDRの代用品にしないことが重要です。
チェックリスト：CIDRを変更する前に
□versionとconfig hashを記録したか □public URLとreverse proxyを図にしたか □allow_cidrsの空・広すぎる状態を説明できるか □office・VPN・管理経路のCIDRを棚卸ししたか □gatewayInternalNetworksの対象を限定したか □/loginと推論requestを別にテストしたか □TLS・IdP・redirectを確認したか □session失効を決めたか □監視とrate limitを設定したか □変更承認・緊急停止・rollback責任者を残したか。
よくある質問
allow_cidrsが空だと必ず接続を拒否しますか？
2.1.268の公式更新は起動時と公開アドレスからの最初のrequestに警告を追加したものです。実際の拒否結果はGateway、proxy、firewallの構成を確認し、警告だけで仕様を推測しません。
gatewayInternalNetworksは社内ネットワーク専用ですか？
公式説明は組織のpublic IPv4 blockからGatewayの/loginを許可するmanaged settingです。社内扱いかどうかではなく、指定範囲、IdP、TLS、sessionを組み合わせて判断します。
公開IPが変わった時は？
変更前に新旧経路を並べ、許可範囲、ログイン、監視、rollbackを検証します。CIDRを一時的に全開放しての切り分けは避け、秘密情報を含まない結果だけ記録します。
公式情報と無料診断
更新内容は公式changelog、設定名と制限は公式configuration、構成の前提は公式Gateway overviewを公開直前に確認しています。Miraigentの無料診断では、ネットワーク、認証、権限、停止条件を一つの導入判断表にまとめます。