プライベート IP アドレス範囲（Private IP Ranges）とは何ですか？

インターネットにルーティングされない内部ネットワーク用の IP アドレス帯。RFC 1918 と RFC 4193 で定義されている。

ネットワーク

プライベート IP アドレス範囲（Private IP Ranges）

Q: プライベート IP アドレス範囲（Private IP Ranges）の概要について教えてください

プライベート IP アドレス範囲（Private IP Ranges） は、インターネット上でルーティングされない内部ネットワーク専用のアドレス帯です。IPv4 では RFC 1918（1996 年）、IPv6 では RFC 4193（2005 年）で定義されています。組織内の LAN やデータセンター内の通信に使用し、インターネットとの通信には NAT（Network Address Translation）やプロキシを介します。

2025年12月9日更新

概要

プライベート IP アドレス範囲（Private IP Ranges） は、インターネット上でルーティングされない内部ネットワーク専用のアドレス帯です。IPv4 では RFC 1918（1996 年）、IPv6 では RFC 4193（2005 年）で定義されています。組織内の LAN やデータセンター内の通信に使用し、インターネットとの通信には NAT（Network Address Translation）やプロキシを介します。

IPv4 のプライベートアドレスは次の 3 つのブロック で構成されます。

CIDR 表記	アドレス範囲	アドレス数	用途の目安
10.0.0.0/8	10.0.0.0 〜 10.255.255.255	16,777,216	大規模企業・クラウド VPC
172.16.0.0/12	172.16.0.0 〜 172.31.255.255	1,048,576	中規模ネットワーク
192.168.0.0/16	192.168.0.0 〜 192.168.255.255	65,536	家庭・小規模オフィス

これらのアドレスは世界中の組織が自由に使え、IANA への申請は不要です。ただし、インターネットのルーターはこれらのアドレスを宛先とするパケットを転送しないため、外部との通信には必ずグローバル IP アドレスへの変換が必要になります。

仕組み

IPv4 では RFC 1918 の 3 ブロック、IPv6 では RFC 4193 の ULA がプライベートアドレスとして定義され、NAT を介してインターネットと通信します。

RFC 1918 — IPv4 プライベートアドレス

RFC 1918「Address Allocation for Private Internets」（1996 年 2 月）は、IPv4 アドレス空間の枯渇を緩和する目的で策定されました。すべての組織がグローバル IP アドレスを使うと 32 ビット空間（約 43 億個）では足りないため、外部と直接通信しないホストにはプライベートアドレスを割り当てるという方針です。

プライベートアドレスの根本的な特徴は、インターネットのルーティングテーブルに載らないことです。ISP やバックボーンのルーターは RFC 1918 アドレスを宛先とするパケットを受け取っても破棄します。この性質により、異なる組織が同じプライベートアドレスを使っても衝突が起きません。東京のオフィスと大阪のオフィスの両方が 192.168.1.0/24 を使っていても、それぞれのネットワークは独立しています。

RFC 4193 — IPv6 ユニークローカルアドレス（ULA）

IPv6 には RFC 4193 で定義された ULA（Unique Local Address）があります。プレフィックスは fc00::/7 で、実運用では fd00::/8 の範囲を使います。fc00::/8 は現時点で未割り当てです。

fdXX:XXXX:XXXX::/48

XX:XXXX:XXXX の 40 ビットはランダムに生成します。ランダム値を使うことで、異なる組織が同じプレフィックスを使う確率を実用上無視できるレベルまで下げています。RFC 1918 の IPv4 プライベートアドレスとは異なり、VPN で複数拠点を接続してもアドレス衝突が起きにくい設計です。

ULA はインターネットにルーティングされないという点で RFC 1918 と同じ役割を果たしますが、IPv6 ではアドレス空間が 128 ビットと広大なためアドレス枯渇の問題はありません。ULA の主な用途は、インターネット接続の有無にかかわらず安定したアドレスを内部通信に使うことです。ISP から割り当てられたグローバルユニキャストアドレス（GUA）はプロバイダー変更時に変わりますが、ULA はローカルに固定できます。

特殊用途のアドレス帯

RFC 1918 と RFC 4193 以外にも、インターネットでルーティングされない特殊用途のアドレス帯があります。

アドレス帯	用途	RFC
127.0.0.0/8	ループバック（自ホスト宛て）	RFC 1122
169.254.0.0/16	リンクローカル（DHCP 未取得時の自動設定）	RFC 3927
::1/128	IPv6 ループバック	RFC 4291
fe80::/10	IPv6 リンクローカル	RFC 4291
2001:db8::/32	ドキュメント用（例示専用）	RFC 3849

これらはプライベートアドレスとは目的が異なりますが、「インターネット上でルーティングされない」という性質は共通しています。IP アドレスの判定ツールではこれらもまとめて「プライベート」と分類することがあります。

NAT によるグローバルアドレスへの変換

プライベート IP アドレスを持つホストがインターネットと通信するには、NAT（Network Address Translation）を使ってグローバル IP アドレスに変換します。家庭のルーターが行っている処理がこれにあたります。

NAT の基本的な流れは次の通りです。

内部ホスト（192.168.1.10）がパケットを送信する
ルーターが送信元アドレスを自身のグローバル IP（例: 203.0.113.5）に書き換える
応答パケットのルーターが宛先アドレスを元の内部アドレスに書き戻す

この仕組みにより、1 つのグローバル IP アドレスで複数の内部ホストがインターネットに接続 できます。NAT なしでは IPv4 アドレスの枯渇により現在のインターネット規模を維持できませんが、エンドツーエンドの通信モデルを崩すという側面もあります。

具体例

ネットワーク規模に応じた IPv4 プライベートアドレスの使い分けと、IPv6 ULA の生成例を示します。

IPv4 プライベートアドレスの使い分け

ネットワーク設計では、規模に応じてプライベートアドレスの範囲を選択します。

# 小規模オフィス（〜254 ホスト）
192.168.1.0/24    → 192.168.1.1 〜 192.168.1.254

# 中規模拠点（サブネット分割）
172.16.0.0/16     → 172.16.0.0 〜 172.16.255.255
  172.16.1.0/24   → 開発環境
  172.16.2.0/24   → ステージング環境
  172.16.3.0/24   → 本番内部通信

# クラウド VPC（AWS、GCP 等）
10.0.0.0/8        → 10.0.0.0 〜 10.255.255.255
  10.0.0.0/16     → VPC 全体
  10.0.1.0/24     → パブリックサブネット
  10.0.2.0/24     → プライベートサブネット

IPv6 ULA の生成例

# ランダムな 40 ビット値を生成してプレフィックスを構成する
fdab:1234:5678::/48

# サブネット分割
fdab:1234:5678:0001::/64   → サーバーセグメント
fdab:1234:5678:0002::/64   → クライアントセグメント

OS ごとの確認方法

自分のマシンに割り当てられた IP アドレスを確認するコマンドは OS によって異なります。

# macOS / Linux
ip addr show
# または
ifconfig

# Windows
ipconfig

出力に 192.168.x.x、10.x.x.x、172.16.x.x 〜 172.31.x.x のいずれかが表示されていれば、そのインターフェースにはプライベート IP アドレスが割り当てられています。

確認方法

特定の IP アドレスがプライベートかどうかは、アドレスの先頭部分を上記の範囲と照合することで判定できます。

プログラム的に判定する場合は、CIDR のプレフィックスマッチで確認します。

python3 -c "import ipaddress; print(ipaddress.ip_address('192.168.1.1').is_private)"

True

python3 -c "import ipaddress; print(ipaddress.ip_address('8.8.8.8').is_private)"

False

外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ip?ip=192.168.1.1"

レスポンスは次の形式で返ります。

{
  "success": true,
  "data": {
    "ip": "192.168.1.1",
    "type": "IPv4",
    "isPrivate": true,
    "ptr": null
  },
  "error": null,
  "meta": { "responseTime": 0 }
}

data.isPrivate が true であれば、そのアドレスはプライベート IP アドレス範囲に含まれます。プライベート IP アドレスではインターネット上に PTR レコードが存在しないため、ptr は null になります。

ip パラメーターを省略すると、リクエスト元（自分自身）の IP アドレスに対する結果が返ります。自分のグローバル IP を確認する用途にも使えます。

curl "https://labee.dev/api/ip"

Labee の IP API が判定するプライベートアドレスの範囲には、RFC 1918 の 3 ブロックに加えて、ループバック（127.0.0.0/8）、リンクローカル（169.254.0.0/16）、IPv6 ループバック（::1）、IPv6 ULA（fc00::）、IPv6 リンクローカル（fe80::）、ドキュメント用（2001:db8::）が含まれています。

よくある問題

プライベートアドレスの利用では、VPN 時のアドレス衝突やコンテナ環境との競合が代表的な問題です。

VPN 接続時にプライベートアドレスが衝突する

リモートワーク環境で VPN を使用する際、自宅の LAN とオフィスの LAN が同じプライベートアドレス範囲（例: 両方 192.168.1.0/24）を使っているとアドレスが衝突します。ルーティングが混乱し、オフィスのサーバーにアクセスできなくなる場合があります。

対策としては、VPN 接続先のネットワークに一般的でない範囲（例: 10.200.0.0/16 や 172.24.0.0/16）を割り当てることが有効です。IPv6 ULA を使う場合は 40 ビットのランダム値によりこの問題が起きにくくなります。

Docker / コンテナのアドレス範囲と既存ネットワークの競合

Docker はデフォルトでブリッジネットワークに 172.17.0.0/16 を使用します。この範囲が既存の社内ネットワーク（172.16.0.0/12 の一部）と重なると、コンテナからの通信が社内サーバーに到達しなくなります。

Docker の場合は /etc/docker/daemon.json でデフォルトのアドレスプールを変更できます。

{
  "default-address-pools": [
    { "base": "10.200.0.0/16", "size": 24 }
  ]
}

Kubernetes でも Pod CIDR やサービス CIDR がオンプレミスのネットワークと重複しないように設計段階で確認が必要です。

クラウド VPC のアドレス設計で範囲が足りなくなる

AWS VPC や GCP VPC を最初に小さな CIDR（例: 10.0.0.0/24）で作成すると、サブネットの追加やピアリング接続の拡大時にアドレスが不足します。VPC の CIDR は後から拡張できますが、既存の CIDR と重複する範囲は追加できない という制約があります。

この問題を避けるには、初期設計の段階で将来の拡張を見越した CIDR 計画を立てます。AWS では /16 の VPC を作成し、/24 のサブネットに分割する構成が一般的です。複数の VPC をピアリングする場合は、VPC 間で CIDR が重複しないように全体のアドレス計画を管理します。

プライベート IP アドレスからのメール送信

メールサーバーの送信元がプライベート IP アドレスの場合、インターネット上の受信サーバーから見ると送信元が NAT 後のグローバル IP アドレスになります。PTR レコードはグローバル IP アドレスに対して設定するため、NAT の背後にあるメールサーバーでは PTR の設定先を正しく把握する必要があります。curl "https://labee.dev/api/ip" で自分のグローバル IP を確認し、そのアドレスに対して PTR を設定します。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す