ClaudeのIP許可リストをEnterpriseで設定する — 申請の流れと締め出し対策
ClaudeのIP許可リストはEnterprise限定で、設定は申請ベースです。CIDRの洗い出し方、締め出しを避ける確認点、Claude in Chromeのブリッジ接続への影響を解説します。
ClaudeのIP許可リストとは何をする機能か
IP許可リスト(IP allowlisting)は、Claudeに届くリクエストの送信元IPアドレスを、組織が登録した範囲だけに絞る機能です。Enterpriseプランの管理者向けで、他のプランでは使えません。
有効にすると、Anthropicは認証済みのリクエストすべてについて、送信元IPを組織の許可リストと照合します。リストにないIPからのリクエストは拒否されます。指定はCIDR形式で、IPv4の 10.0.0.0/8 もIPv6の 2001:db8::/32 も書けます。
対象は「どこから来た通信か」です。ここがテナント制限(どの組織のアカウントか)との違いで、両者は役割が別です。違いは後半の比較表にまとめています。
有効化は申請から始まる
有効化は、管理者が設定画面で切り替える形ではありません。CIDR範囲の一覧をAnthropicに渡し、アカウント側で追加してもらう申請ベースです。
有効化までの流れ
- 1
CIDR範囲を洗い出す
オフィス、VPNの出口、そのほか承認済みのアクセス元をすべて列挙します。
- 2
Anthropicの窓口かサポートへ送る
自社のAnthropic担当者か、サポートチームに一覧を共有します。
- 3
アカウント側で許可リストが有効になる
Anthropic側が一覧を許可リストに追加し、機能が有効になります。
洗い出しが最も重要な工程です。必要な範囲が一覧から漏れると、利用者がClaudeから締め出される可能性があると明記されています。有効化後に範囲を足したり外したりする手続きは、同ページに記載がありません。変更のたびに窓口とのやり取りが発生する前提で、最初の一覧を厚めに点検してください。
締め出しを避けるための洗い出しチェック
サポート記事が例に挙げるのは、オフィス拠点、VPNの出口、その他の承認済みアクセス元の3種類です。実際の組織では、次のような箇所で漏れが起こりやすくなります。
| 確認する場所 | 見るポイント |
|---|---|
| 拠点の回線 | 見るポイント本社だけでなく支店・工場・サテライトオフィスの出口 |
| VPNの出口 | 見るポイント出口が複数あるか。リージョンごとに別IPか |
| スプリットトンネル | 見るポイントClaude宛ての通信がVPNを通らず、利用者の自宅回線から直接出ていないか |
| IPv6 | 見るポイント出口にIPv6を使う経路があるなら、IPv6のCIDRも必要か |
| ブラウザー以外のクライアント | 見るポイントclaude.aiにログインして使うデスクトップアプリやClaude Codeの出口が、ブラウザーと同じか |
| ホストごとの出口 | 見るポイントプロキシが宛先ホストごとに出口を振り分けていないか(後述のホスト表) |
スプリットトンネルの行は、「認証済みのリクエストすべて」の送信元を検証するという記述から導いた確認点です。なお、このサポート記事はClaudeの組織へのアクセスを対象にしています。APIキーで呼ぶ社内ツールやCI/CDに同じ検証がかかるかは、記事に書かれていません。該当する場合は、Anthropicの窓口に申請時に確かめておくと安全です。
申請前に自分でCIDRを検算する
社内の出口IPが、申請予定の一覧のどれかに入っているかは手元で検算できます。次のPythonは標準ライブラリだけで動きます。範囲は説明用のドキュメント用アドレスで、実際の値に差し替えてください。
import ipaddress, sys
allow = ["203.0.113.0/24", "198.51.100.0/25", "10.0.0.0/8", "2001:db8::/32"]
nets = [ipaddress.ip_network(c) for c in allow]
for ip in sys.argv[1:]:
a = ipaddress.ip_address(ip)
hit = [str(n) for n in nets if a.version == n.version and a in n]
print(ip, "->", hit[0] if hit else "許可リスト外")Python 3.12.2で、4つのアドレスを渡した実行結果は次のとおりです。
203.0.113.45 -> 203.0.113.0/24
198.51.100.200 -> 許可リスト外
2001:db8:1::7 -> 2001:db8::/32
192.0.2.10 -> 許可リスト外198.51.100.200 は /25 の範囲(.0〜.127)から外れるため、リスト外になります。/25 と /24 の書き間違いは、一覧を手で作る場面で起こりがちです。ここで漏れを見つけておけば、申請後の再依頼を避けられます。
なお、スクリプトに渡す出口IPは、利用者が実際に使っている回線から調べた値を使います。管理者のPCのIPだけを調べても、他の経路の漏れは見つかりません。
範囲外から接続すると何が起こるか
許可リストにないIPからのリクエストは、アクセスが拒否されます。誤ってブロックされたと思う利用者は、IT管理者に連絡する運用です。
拒否時のエラー文面やHTTPステータスは、同ページに記載がありません。テナント制限は403の tenant_restriction_violation のようにエラーコードが決まっていますが、IP許可リストについては同種の記載がない以上、画面のメッセージだけで原因を断定せず、次の順で切り分けると安全です。
- 同じ利用者が、社内ネットワーク(またはVPN接続中)で試して成功するか
- 失敗する端末の出口IPが、申請した一覧に入っているか
- 失敗するのが特定のクライアント(ブラウザー、デスクトップアプリ、Claude Code)だけか
1と2の差が見えれば、原因は範囲の漏れかVPN経路の外れかに絞れます。3は次の節の話につながります。
Claude in Chromeのブリッジ接続は別ホストを通る
IP許可リストを有効にした組織で、特に引っかかりやすいのがブリッジ用のホストです。Claude in Chromeの拡張機能と、Claude CodeやClaude Desktopをつなぐ接続は bridge.claudeusercontent.com を使います。
組織がIP許可リストを有効にしている場合、このホストは claude.ai や api.anthropic.com と同じプロキシの出口に通します。ZscalerならアプリセグメントをClaude本体と同じにする、Netskopeなら同じステアリングポリシーに入れる、といった設定です。
プロキシがこのホストだけ別の出口から送ると、Anthropicは到着した送信元アドレスで許可リストと照合するため、拒否されます。Claude Codeの場合は、ほかの機能が正常でもClaude in Chromeの拡張機能とだけつながらなくなります。Claude Desktopでも、ブリッジを使うClaude in Chromeなどの機能だけが止まり、アプリのほかの部分は動き続けます。
Claude Codeでは、/chrome の接続エラー「Browser extension is not connected」の原因のひとつに、組織のIP許可リストがこのホストへの接続を拒否しているケースが挙がっています。拡張機能が別の組織のアカウントでサインインしている場合と症状が同じなので、アカウントを確認してから、出口を疑う順が効率的です。
出口を揃えられないときの代替策
もうひとつの選択肢は、プロキシがそのホストに使う出口アドレスを、組織の許可リストへ追加する方法です。ただし条件が付いています。
- 追加してよいのは、その出口アドレスが自社専用のときだけ
- 共有のプロキシ出口レンジを許可すると、プロキシ事業者のほかの顧客の通信も通ってしまう
許可リストの目的は接続元の絞り込みなので、共有レンジを入れると意図が崩れます。出口を揃えるほうが安全で、アドレス追加は次善策です。
NO_PROXYの書き方にも制約がある
Claude Codeでアーティファクトのホストに直接つなぐために NO_PROXY を設定する場面があります。.frame.claudeusercontent.com のように範囲を狭く書くのが前提です。広く .claudeusercontent.com と書くと、bridge.claudeusercontent.com までプロキシを迂回し、IP許可リストが必要な組織では出口がずれるためです。
# 狭く書く(ブリッジはプロキシ経由のまま)
NO_PROXY=.frame.claudeusercontent.comプロキシで出口を揃えるホストを洗い出す
ブリッジ用ホスト以外にも、Claude Codeが接続するホストはいくつかあります。ネットワーク要件の表に載っている、Anthropic関連のホストは次のとおりです。
| ホスト | 用途 |
|---|---|
claude.ai | 用途claude.aiアカウントの認証 |
api.anthropic.com | 用途Claude APIリクエスト、機能フラグの取得 |
platform.claude.com | 用途Anthropic Consoleの認証、claude.aiアカウントのOAuthトークン交換 |
mcp-proxy.anthropic.com | 用途claude.aiのMCPコネクタ(管理者が設定したものを含む) |
bridge.claudeusercontent.com | 用途Claude in ChromeのWebSocketブリッジ |
*.frame.claudeusercontent.com | 用途アーティファクトの内容の読み取り |
このうち、IP許可リストの出口を揃えるよう明記されているのは bridge.claudeusercontent.com です。残りのホストが許可リストの照合を受けるかどうかは、サポート記事に記載がありません。そのため、プロキシのポリシーを見直すときは、表のホストをまとめて同じアプリセグメントやステアリングポリシーに入れておく方法があります。ホストごとに出口がずれる余地をなくせば、接続エラーの原因を「出口のずれ」から外して調べられます。
アーティファクトを使わない組織は、"enableArtifact": false で *.frame.claudeusercontent.com への接続自体を止めることもできます。
似た名前の仕組みとの違い
「IPを許可する」という言葉は、方向の違う設定にも使われます。今どれを扱っているかを先に決めると、設定ミスが減ります。
| 仕組み | 誰が誰を絞るか | 設定する側 |
|---|---|---|
| ClaudeのIP許可リスト(本記事) | 誰が誰を絞るかAnthropicが、自社組織への接続元IPを絞る | 設定する側Anthropicに申請 |
| テナント制限 | 誰が誰を絞るかAnthropicが、プロキシのヘッダーで許可した組織以外を遮断する | 設定する側自社のプロキシ |
| Claude APIの固定IP | 誰が誰を絞るか自社のファイアウォールが、Anthropicの通信を通す | 設定する側自社のファイアウォール |
| GitHub組織のIP許可リスト | 誰が誰を絞るかGitHubが、Claudeのクラウド処理からの接続を絞る | 設定する側GitHub組織のオーナー |
最後の行は、Claude Codeのクラウドセッションを始める操作で出るエラー「Your GitHub organization has an IP allowlist that is blocking Claude」の原因です。この場合に追加するのはAnthropicの送信IPで、本記事の許可リストとは向きが逆です。
テナント制限は、ネットワーク側で「どの組織のアカウントを使わせるか」を決めます。IP許可リストは「どこから使わせるか」を決めます。個人アカウントの持ち込みを止めたいならテナント制限、社外ネットワークからの利用を止めたいならIP許可リストが対応します。両方を入れる組織では、プロキシの出口がIP許可リストの範囲に入っていることが前提になります。
社内VPN運用での確認点
最後に、社内VPNを前提にしている組織の確認点をまとめます。
- VPNに接続していない自宅回線やカフェのWi-Fiからは、許可リスト外のため拒否されます。リモートワークを認める組織は、全員がVPN接続中にClaudeを使う運用か、VPN出口以外の経路を許可に含めるかを決めておきます
- VPN出口を増減するときは、許可リストの更新も同時に必要です。ネットワーク担当とClaudeの管理者が別の部署なら、変更手順に「Anthropic窓口への連絡」を入れておきます
- Claude in Chromeを使う部署には、ブリッジ用ホストを同じ出口に通す設定をネットワーク担当へ依頼します
- 管理者が自分の環境だけで動作確認を済ませないことが大切です。部署・拠点・クライアントの組み合わせごとに、1人ずつ接続を試します
Claude in Chromeを使う部署の出口設計は、Claude in Chromeの管理者設定にも関連します。接続が通らないときの一般的な切り分けは、Claude CodeのConnection refusedの原因にまとめています。
まとめ
IP許可リストは、申請ベースで有効にするEnterprise専用の機能です。準備の中心は、実際に使われる回線の出口を網羅したCIDR一覧を作ることです。漏れは締め出しに直結し、変更手続きは窓口経由になるため、最初の一覧づくりに時間をかけた分だけ運用が楽になります。Claude in Chromeを使う組織では、ブリッジ用ホストの出口を揃える作業も忘れずに。