Claude APIのIPアドレスをファイアウォールに許可登録する手順
Claude APIの通信はinbound 160.79.104.0/23・outbound 160.79.104.0/21の固定IPを使う。ファイアウォール許可設定の手順と、削除すべき旧IPを整理する。
この記事で扱うIPアドレス
企業のネットワーク環境からClaude APIやConsoleにアクセスする際、社内ファイアウォールが外部への通信を制限していると、Anthropic側の固定IPアドレスを個別に許可登録する必要があります。Anthropicは受信(inbound)・送信(outbound)それぞれに固定IPアドレスを使っており、予告なしに変更しないと明言しています。
公式ドキュメントは、ここに挙がる固定IPアドレス群を「Claude APIとConsole双方への安全なアクセスのため」のファイアウォール設定に使うものと説明しています。Console経由のアクセスも同じ設定の対象に含まれます。API通信をドメインベースで許可し、Console(Webブラウザ経由)へのアクセスは別のプロキシルールで制御している組織は、どちらの経路にも本記事のIPレンジ設定が関わりうる点を踏まえてファイアウォールルールを見直す必要があります。
前提: inboundとoutboundの違いを区別する
許可登録の前に、2種類のIPレンジを混同しないことが重要です。
- inbound: Anthropicのサービスが外部からの接続を受け取るIPアドレス。自社サーバーからClaude APIへリクエストを送る場合、送信先としてこのレンジを許可する
- outbound: Anthropicが外部へリクエストを送信する際に使うIPアドレス。MCPコネクタ・Web検索・Web取得ツールなど、Claudeが外部サービスを呼び出す際の送信元になる。自社側でAnthropicからの着信を許可する場合はこちらを使う
この2つは値も用途も異なるため、片方だけ登録して「繋がらない」と混乱するケースが起きやすい構成です。
手順: ファイアウォールに登録するレンジ
inbound(APIへリクエストを送る側が許可する)
| プロトコル | レンジ |
|---|---|
| IPv4 | レンジ160.79.104.0/23 |
| IPv6 | レンジ2607:6bc0::/48 |
outbound(Anthropicからの着信を許可する側が使う)
| プロトコル | レンジ |
|---|---|
| IPv4 | レンジ160.79.104.0/21 |
outboundのレンジ(/21)はinboundのレンジ(/23)を包含する広いブロックです。MCPコネクタ経由で外部サーバーを呼び出す構成を組んでいる場合、その外部サーバー側のファイアウォールにはこのoutboundレンジからの着信を許可する設定が必要になります。
具体的な許可ルールの追加方法はファイアウォール製品(クラウドのセキュリティグループ、オンプレのUTM等)ごとに異なるため、各製品のドキュメントに従って上記レンジを追加してください。設定後は、api.anthropic.com が実際に許可レンジ内のIPへ解決されているかを確認しておくと安全です。
python3 - <<'EOF'
import socket, ipaddress
inbound_v4 = ipaddress.ip_network("160.79.104.0/23")
host_ip = socket.gethostbyname("api.anthropic.com")
addr = ipaddress.ip_address(host_ip)
print(f"api.anthropic.com -> {host_ip}")
print("inboundレンジ内:", addr in inbound_v4)
EOFgethostbyname はA(IPv4)レコードを1件しか返さないため、環境によって別のIPが返ることがあります。CDN経由でDNSラウンドロビンされている可能性を考慮し、複数回実行して結果が許可レンジ内に収まるかを確認してください。
削除すべき旧IPアドレス
過去にAnthropicが使用していたものの、現在は使われていないIPアドレスが5つ公式に告知されています。
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以前これらのアドレスを許可リストに登録したことがある場合は、ファイアウォールルールから削除するよう案内されています。使われていないルールを残しておくこと自体が直接のセキュリティリスクになるわけではありませんが、不要な許可設定はレビュー対象を増やし、監査の手間を増やします。定期的なファイアウォールルールの棚卸しのタイミングで、この5件が残っていないか確認しておくとよいでしょう。
Claude Codeのネットワーク設定とは別物
本記事のIPアドレス許可リストは、Claude API・Consoleへのアクセス経路を対象にしたものです。Claude Codeをサンドボックス環境で動かす際のネットワーク制御は、これとは別の仕組みです。Claude Codeのサンドボックスは接続先をドメイン名で許可・拒否する方式を取っており、IPv6環境でのドメイン許可リストの書き方はClaude CodeサンドボックスのIPv6ドメイン許可リストにあります。「IPで許可する」本記事の話と「ドメインで許可する」Claude Codeサンドボックスの話は、どちらも英語ではallowlistと呼ばれるため名前だけでは区別が付きません。自社のネットワーク設計で両方を扱う場合は、対象がAPI/Consoleへの通信なのか、Claude Codeのサンドボックスが発する通信なのかを、まず切り分けてください。
なぜ固定IPでの許可登録が必要になるのか
多くの企業ネットワークでは、外部への通信をデフォルト拒否し、必要な宛先だけを個別に許可する「ホワイトリスト方式」のファイアウォールを運用しています。ドメイン名(api.anthropic.com)ベースで許可設定できるファイアウォール製品もありますが、DNSクエリの可視化やSSL/TLSインスペクションを厳格に運用している環境では、IPアドレス単位での許可のほうが監査ログとして扱いやすいという実務上の理由があります。Anthropicが固定のIPレンジを公開し「予告なしには変更しない」と明言しているのは、こうした企業側のネットワーク運用に配慮した設計だと言えます。
IPベースの許可とドメインベースの許可、どちらを使うか
ファイアウォールやプロキシの多くは、IPアドレス単位の許可とドメイン名(FQDN)単位の許可の両方をサポートしています。どちらを選ぶかは組織のネットワーク構成次第ですが、判断材料は次の2点です。
- TLSインスペクションを行っているか: 通信内容を復号して検査するプロキシを使っている場合、SNI(ドメイン名)ベースのルールが扱いやすい傾向があります。一方、L3/L4のパケットフィルタ(ステートフルファイアウォール)ではIPアドレスベースのルールが基本になります
- 監査ログの粒度: セキュリティ監査でファイアウォールルールを棚卸しする際、IPレンジは変更頻度が低く固定的なため、ルールの根拠を追跡しやすいという利点があります。Anthropicが「予告なしに変更しない」固定IPを公開しているのは、こうした監査要件に応えるためだと考えられます
どちらの方式でも、許可する通信は標準的なHTTPS(TCP 443番ポート)です。プロトコル・ポートまで含めてファイアウォールルールに明記しておくと、レビュー時に「何のための許可設定か」が一目で分かります。
よくあるつまずき
- inboundとoutboundを逆に設定してしまう: 「APIへの送信を許可したい」のか「Anthropicからの着信を許可したい」のかで参照するレンジが違います。構成図を書いてどちらの通信方向かを先に確認してから設定すると迷いません
- 旧IPアドレスを消し忘れる: フェーズアウトした5件のIPは、ドキュメントを確認しない限り気づかずに残り続けます
- IPv6を見落とす: inboundにはIPv6レンジ(
2607:6bc0::/48)も存在します。IPv4のみを想定したファイアウォール設定だと、IPv6経由の通信で意図しない挙動になる可能性があります - outboundにIPv6レンジが無いことを見落とす: 公式ドキュメントが明示しているoutboundのレンジはIPv4(
160.79.104.0/21)のみです。MCPコネクタの着信元をIPv6でも許可しようとして値を探しても、公開されているのはIPv4レンジだけという点を押さえておいてください
変更頻度と運用上の位置づけ
固定IPは「予告なしに変更しない」とされていますが、これは「絶対に変更されない」という意味ではありません。実際に過去5件のIPアドレスがフェーズアウトしています。IaC(Infrastructure as Code)でファイアウォールルールを管理している場合は、許可レンジをコード上の1か所(変数や設定ファイル)にまとめておくと、将来レンジが更新された際の反映作業を1か所の変更で済ませられます。ハードコードされた個別のルールがコードベース内に散らばっていると、更新漏れのリスクが上がります。
まとめ
Claude APIのファイアウォール許可設定は、inbound(IPv4: 160.79.104.0/23 / IPv6: 2607:6bc0::/48)とoutbound(IPv4: 160.79.104.0/21)を区別して登録します。過去に使われていた 34.162.x.x/32 の5アドレスは現在使用されていないため、許可リストに残っていれば削除してください。AWS版のClaude Platformを使っている場合はinboundのIPレンジがAWS側の範囲に置き換わる点にも注意が必要です。認証方式やAPIの対応地域など、ネットワーク設定と合わせて確認しておきたい項目はClaude API認証方式まとめとClaude APIが使える国・地域にまとめています。