ClaudeのIPアドレス制限に使う固定IP一覧と許可登録の手順

ClaudeのIPアドレス制限(ファイアウォールの許可リスト)で使う固定IPは、Claude APIとConsole向けに公開されています。

Claude APIへの許可ルールで使うレンジは3つです。inboundはIPv4の 160.79.104.0/23 とIPv6の 2607:6bc0::/48、outboundはIPv4の 160.79.104.0/21 です。過去に使われていた 34.162.x.x/32 の5件は現在使われておらず、登録済みなら削除の対象になります。

公式ドキュメントは、これらの固定IPを「Claude APIとConsole双方への安全なアクセス」のファイアウォール設定に使うものと説明し、予告なしには変更しないとしています。API通信はドメインで許可し、Consoleだけ別のプロキシルールで縛っている組織も、Console側の許可に同じレンジが関わります。

許可するのは「自社からAnthropic」か「Anthropicから自社」か

最初に決めるのは通信の向きです。inboundとoutboundを混同して片方だけ登録し、「許可したのに繋がらない」となるのが典型的な失敗です。

outboundの /21 はinboundの /23 を包含する広いブロックです。outboundにはIPv6のレンジが公開されていないため、MCPサーバー側の許可はIPv4だけで組みます。許可を入れても繋がらないときの切り分けはClaude API connection errorの切り分けと疎通確認にもあります。

手順: レンジを登録して、実際の接続先で検証する

ルールの追加画面はクラウドのセキュリティグループやオンプレのUTMなど製品ごとに違うので、操作そのものは各製品のドキュメントに従います。共通するのは次の順序です。

確認用のスクリプトです。getaddrinfo でアドレスファミリを指定して引くので、IPv6の解決結果も見られます。

python3 - <<'EOF'
import socket, ipaddress
 
nets = {
    socket.AF_INET: ipaddress.ip_network("160.79.104.0/23"),
    socket.AF_INET6: ipaddress.ip_network("2607:6bc0::/48"),
}
for host in ["api.anthropic.com", "platform.claude.com"]:
    for family, net in nets.items():
        try:
            infos = socket.getaddrinfo(host, 443, family, socket.SOCK_STREAM)
        except socket.gaierror as e:
            print(host, family.name, "解決できず:", e)
            continue
        for ip in sorted({i[4][0] for i in infos}):
            print(host, family.name, ip, "範囲内:", ipaddress.ip_address(ip) in net)
EOF

手元のmacOS(既定のDNSリゾルバー)で実行したところ、結果は次のとおりでした。

api.anthropic.com AF_INET 160.79.104.10 範囲内: True
api.anthropic.com AF_INET6 2607:6bc0::10 範囲内: True
platform.claude.com AF_INET 160.79.104.10 範囲内: True
platform.claude.com AF_INET6 2607:6bc0::10 範囲内: True

APIのホストとConsoleのホストが同じIPv4・IPv6アドレスに解決され、どちらもinboundのレンジに収まっています。公式が「APIとConsole双方」と書いている点と合う結果です。ただしこれは筆者の環境での1回の観測で、リゾルバーや時間帯が変わっても同じ値が返る保証はありません。自社の出口から同じスクリプトを実行し、結果がレンジ内かどうかを自分の環境で見てください。

自社のDNSが api.anthropic.com を許可レンジ外のアドレスに解決するなら、社内のプロキシやDNSフィルタが介在している可能性があります。その場合、IP許可リストを足しても解決しません。

outbound側: MCPサーバーのログで着信元を確かめる

outboundの許可は、呼ばれる側(MCPサーバーや社内API)で組むため、DNSでは検証できません。代わりに、サーバーのアクセスログに残った着信元IPが 160.79.104.0/21 に入っているかを見ます。

outboundの許可が要るのは、インターネットに公開したHTTPのMCPサーバーです。Streamable HTTPとSSEのどちらにも対応します。ローカルのSTDIOサーバーには直接接続できないので、許可の対象になりません。

レンジの広さは計算で押さえておけます。/21 は 160.79.104.0 から 160.79.111.255 までの2,048アドレスです。inboundの /23 は 160.79.104.0 から 160.79.105.255 までの512アドレスなので、その4倍にあたります。ログに 160.79.106.x のような、inboundのレンジには入らないアドレスが現れても、outboundのレンジ内であれば不自然ではありません。

実在するブロックの例が、Inference hooksの送信元です。AIセキュリティサーバーへのリクエストは 160.79.106.0/24 から届き、これはoutboundのレンジの一部です。同じページのinboundレンジには含まれないため、inboundの /23 だけを許可しても通りません。IP許可で入口を絞っても、署名検証の代わりにはなりません。このブロックはInference hooks以外のAnthropicの送信トラフィックも運ぶためです。

python3 -c "
import ipaddress
net = ipaddress.ip_network('160.79.104.0/21')
for ip in ['160.79.104.10', '160.79.106.5', '203.0.113.7']:
    print(ip, ipaddress.ip_address(ip) in net)
"

実行結果は 160.79.104.10 True、160.79.106.5 True、203.0.113.7 False です。203.0.113.7 はドキュメント用に予約されたアドレスで、範囲外の例として入れています。ログの着信元をこの関数に流せば、許可ルールがAnthropic由来の通信だけを通しているかを後から検証できます。

繋がらないときの切り分け

許可を入れた後に失敗する場合、まず「ネットワークで落ちているのか、HTTPの応答は返っているのか」を分けると原因の層が絞れます。

• HTTPのエラー応答(JSON)が返ってくる: 経路は通っています。たとえば403の permission_error は、APIキーが対象リソースを使う権限を持たない場合のエラーです。確認先はConsoleの組織とワークスペースの設定で、許可レンジの話ではありません。すべてのAPI応答には一意の request-id ヘッダーが付き、エラーはJSONの error オブジェクトで返ります。これらが揃っていれば、Anthropicまで届いて返った応答と見てよいでしょう。403なのに揃っていないときは、途中のプロキシが返した応答かもしれません
• 504の timeout_error: 公式の定義は「処理中にリクエストがタイムアウトした」で、長いリクエストにはストリーミングの利用を検討するよう案内されています。ファイアウォールのIP許可漏れとは別の層です
• 応答が一切なく、接続の確立段階で待たされる: ファイアウォールが宛先を落としている可能性があります。登録したレンジの向き(inbound/outbound)と、IPv6の許可漏れを見直す段階です
• リクエストを送った後に応答が来ない: 接続は確立できているので、許可漏れとは別の原因です。ネットワークによってはアイドル状態の接続を一定時間で切るため、Anthropicから応答を受け取れないまま失敗やタイムアウトになることがあります。TCPのソケットkeep-aliveを設定すると、影響を抑えられる場合があります。公式SDKは、非ストリーミングのリクエストが10分のタイムアウトを超えない見込みかを検証し、keep-aliveのソケットオプションも設定します

IPv6は見落としやすい箇所です。上の実行結果のとおり、APIのホストにはIPv6アドレスも返ります。IPv4だけを許可した出口でIPv6を優先して接続を試みるクライアントがあれば、環境によっては接続が遅くなったり失敗したりします。使っているクライアントの挙動と合わせて確認してください。

待ち時間の長さには、SDKの再試行も関わります。公式SDKは接続エラー、レート制限、5xxエラーのような一時的な失敗を、指数バックオフで既定2回再試行します。許可漏れで接続が失敗する環境では、この再試行が重なり、最終的に失敗が返るまでの時間が延びます。

層の違いを示す例が413の request_too_large です。直のClaude APIでは、APIサーバーに届く前にCloudflareがこのエラーを返します。応答が返っていても、返したのがAPIサーバーとは限りません。

旧IPアドレスの扱い

使われなくなった次の5件は、公式ドキュメントで「以前許可登録したなら削除する」よう案内されています。公式ページでは、この5件はoutboundの節に並んでいます。MCPサーバー側で着信を許可しているルールも、見直しの対象に入れてください。

34.162.46.92/32
34.162.102.82/32
34.162.136.91/32
34.162.142.92/32
34.162.183.95/32

残っていても、現在のAnthropicの通信には使われていません。ただし使われない宛先を許可し続けるルールは、棚卸しのたびに根拠の説明を求められます。定期的な見直しの際にまとめて消すのが手間の少ない進め方です。

AWS上のClaude Platformでは参照するレンジが変わる

一方で、MCPコネクタ・Web検索・Web取得といったoutboundのツール呼び出しは、AWS版でも本記事のAnthropicのレンジから送信されます。つまりAWS版の利用者は、inboundはAWS側、outboundは本記事のレンジという2系統を持つことになります。

claude.aiの「外部ネットワークへの通信を許可」はIPではなくドメインで決める

「Claude外部ネットワークへの通信を許可」で探している場合、対象はこのページのIPレンジではありません。claude.aiのコード実行・ファイル作成機能で、Claudeのサンドボックスが外へ出る通信を制御する設定です。

設定項目は「Allow network egress」です。TeamとEnterpriseでは、組織オーナーがOrganization settings > Capabilitiesから変更します。選択肢は次の4つです。

• 通信を許可しない: 事前にインストールされたパッケージだけで動き、インターネットには出ません
• パッケージマネージャーのみ許可: npmやPyPIなど承認済みの取得元だけに出ます
• パッケージマネージャーと指定ドメインを許可: 追加で許可するドメインを1件ずつ登録します
• すべてのドメインを許可: Anthropicの法的ブロックリストにあるドメインを除き、どこにでも出られます。4つの中でもっともリスクが高い選択肢です

新規のEnterprise組織では、この設定は既定でオフです。Teamについて、設定の説明ではパッケージマネージャーのみの許可が既定とされています。同じページの提供状況の節には「既定では無効」ともあるので、現在の値は管理画面で確認してください。

Free・Pro・Maxの個人プランでは、既定でパッケージ取得元への通信が有効です。変更するときは、利用者が自分の設定から行います。

MCP連携を有効にしている場合、MCP経由の通信はこの設定に関係なく行えます。MCPの構成は別に評価する必要があります。指定するのはIPではなくドメインなので、本記事のレンジを入れる場所ではありません。

IP許可かドメイン許可か、Claude Codeのサンドボックスとの違い

ファイアウォールやプロキシの多くは、IP単位の許可とドメイン名(FQDN)単位の許可を両方扱えます。選ぶ材料は主に次の2つです。

• TLSインスペクションの有無: 通信を復号して検査するプロキシならドメイン名ベースのルールが扱いやすく、L3/L4のパケットフィルタではIPベースが基本になります
• ルールの棚卸しのしやすさ: IPレンジは変更頻度が低く、ルールの根拠を追いやすい利点があります

名前が似ていて混同しやすいのが、Claude Codeのサンドボックスのネットワーク制御です。こちらは接続先をドメイン名で許可・拒否する別の仕組みで、IPv6環境での書き方はClaude CodeサンドボックスのIPv6ドメイン許可リストにあります。本記事は社内ネットワークの出入口でAPI・Consoleの通信を許可する話です。Claude Codeのサンドボックスはツールが発する通信を制御する話なので、設計の際はどちらの通信を扱っているかを先に分けます。

IaCで管理するときの持ち方

固定IPは「予告なしに変更しない」とされていますが、永久に不変という意味ではありません。実際に5件が使われなくなっています。将来レンジが更新されたときに備え、更新の起点を1か所にしておくと直し漏れを防げます。

Terraformなどでルールを管理しているなら、レンジを変数や設定ファイルの1か所にまとめ、ルール本体はそこから参照する形にします。レンジがコード内に個別に散らばっていると、更新したときの直し漏れが残ります。次のようなリストを1つ持つ形です。

anthropic_inbound_ipv4  = ["160.79.104.0/23"]
anthropic_inbound_ipv6  = ["2607:6bc0::/48"]
anthropic_outbound_ipv4 = ["160.79.104.0/21"]

まとめ

登録の可否を決めるのは通信の向きで、自社からAPIを呼ぶならinbound、MCPなどで呼ばれる側ならoutboundです。登録後はスクリプトで解決先がレンジ内にあることを確かめ、それでも失敗するなら、HTTPの応答が返っているかどうかで「ネットワークの問題」か「認証・権限の問題」かを切り分けてください。周辺の設定はClaude API認証方式まとめとClaude APIが使える国・地域にあります。