Cloudflareが、6月にクローズドベータで始まったプライベートオリジンのサポートを一般提供しました。プロキシ付きのDNSレコードでプライベートIPを指定でき、トラフィックは既存のCloudflare One接続を経由してサーバーに届きます。社内APIやAIエージェントのバックエンド、運用ツールを扱う人にとっては、サーバーをインターネットに公開せずにWAF、キャッシュ、ボット管理を適用できることを意味します。ただし、実際に必要な要件が何かは見極める必要があります。
用語の確認 オリジンとは、Cloudflareの背後でアプリケーションを置くサーバーのことです。WAFは、悪意のあるリクエストを遮断するアプリケーションファイアウォールです。Cloudflare Oneは、トンネルやネットワークを提供する同社のプライベート接続基盤です。RFC 1918は、10.0.0.50のようなプライベートIPv4アドレスを定義しています。CGNATは、事業者が利用する100.64.0.0/10ブロックの共有アドレスを指します。
Cloudflareは何を公開したのか?
Cloudflareの公式ブログによると、クローズドベータ期間中は対象となる顧客だけが、自社のアカウントチームに依頼してアクセスできました。今回からは、そのグループを超えて利用できるようになります。
プロキシ付きのAレコードまたはAAAAレコードをプライベートIPに向けると、アプリケーション向けのツールはパブリックオリジンと同じように動作します。
- WAFとマネージドルール
- ボット管理
- レート制限
- キャッシュ
- 変換および書き換えルール
- Workers
どのような問題を解決するのか?
Cloudflareによれば、同じ問題が繰り返し寄せられていました。社内API、AIエージェントのバックエンド、MCPサーバー、運用ツールは、もともとインターネットに置かれることを想定しておらず、それでもパートナー、顧客、エージェントからのリクエストを受け付ける必要があります。
これまでは、これらのサービスの前にCloudflareを置くには、パブリックIP、ファイアウォールでの開放ポート、またはサーバーの横で動くcloudflaredが必要でした。その結果、プライベートなアプリケーションはパブリックなものと同じ保護を受けられないことが多くありました。
プライベートネットワークに関心のある方は、AWSのプライベートサブネットとセキュリティグループに関する当サイトのガイドもご覧ください。
プライベートルーティングはどう機能するのか?
オリジンに向けてプロキシ付きのレコードを作成します。対応するプライベートレンジについては、プライベートルーティングのオプションが自動的に有効になります。オリジンがプライベートネットワークからのみ到達可能なパブリックIPを持つ場合は、手動で有効にします。
RFC 1918アドレス、RFC 6598のCGNATブロック、RFC 4193のローカルIPv6アドレスでは自動的に設定されます。これらのレンジでは無効化できず、APIで変更しようとするとエラーが返されます。
APIでは、DNSレコードのprivate_routing属性を指定するだけです。プロキシがこれを認識すると、リクエストはプライベートネットワークの層に渡され、IPsec、GRE、Cloudflare Tunnel、CNI、Cloudflare Meshのいずれかの既存の接続が使われます。Cloudflare WANの場合、オリジンにコネクタは不要です。Meshでは、ネットワーク内の1つのコネクタで複数のオリジンを扱えます。
有効化には何が必要か?
Cloudflareが示す要件は次のとおりです。
- アカウントに対するPrivate Originsの許可。アカウントチームに依頼します。
- IPsec、GRE、CNI、Tunnel、Meshのいずれかを使ったCloudflare One接続。
- Unified Routingの有効化。Tunnelを使う場合を除きます。
- WANまたはMeshを使う場合、Cloudflareの送信元レンジに対する戻りルート。IPv4では100.64.0.0/12、IPv6では2606:4700 – cf1:5000 – – /64です。
Cloudflareは、戻りルートの欠落が最も多い設定ミスだと警告しています。リクエストがタイムアウトし、サーバーに何も届いていない場合は、まずこの点を確認してください。
知っておくべき制限
いくつかの制約が残っています。Argo Smart RoutingとCDNの専用送信IPは非対応で、オリジンのヘルスチェックにはロードバランシングが必要です。完全な一覧は開発者向けドキュメントにあります。価格や第三者による検証は公表されておらず、有効化はアカウントチーム経由で行います。プライベートネットワーク間のトラフィックについては、まだ開発中です。
デジタル業務に携わる人への影響
パートナーやAIエージェント向けにAPIを公開している場合、パブリックIPもオープンなポートも持たずにサーバーを運用でき、攻撃対象領域を減らせます。ただし、アクセスルールを明確にした上で、Linuxのネットワーク層で慎重に設定する必要があります。既存のWAFルール、キャッシュ、ボット管理は、追加作業なしでホスト名に適用されます。小規模企業にとっての障壁は商用面で、Cloudflare Oneの基盤を用意し、営業担当に連絡する必要があります。
編集部の見解
これまで利便性のために公開向けの保護を諦めていた場所に、保護を持ち込める点で有用な一歩です。ただし隠れたコストは依存関係です。プライベートなサービスを守るために、ネットワーク、DNS、フィルタリングを単一のベンダーに結びつけることになり、要件もアカウントチームを通して決まります。すでにCloudflare Oneを使っている企業には合理的ですが、それ以外の場合は、導入の前により単純な代替策と比較する価値があります。
よくある質問
Cloudflareのプライベートオリジンとは何ですか?
プライベートIPを持つサーバーで、Cloudflare One接続を通じてCloudflareがアクセスします。インターネットには公開されたままです。WAF、キャッシュ、ボット管理、Workersは、パブリックオリジンと同様に動作します。
ファイアウォールでポートを開ける必要はありますか?
いいえ。Cloudflareによれば、オリジンはプライベートIPのままで、ファイアウォールに受信の例外を設定する必要はありません。Cloudflare WANを使う場合は、サーバーにコネクタを置くことさえ不要です。
どの接続方式が対応していますか?
Cloudflareは、IPsec、GRE、CNI、Cloudflare Tunnel、Cloudflare Meshを挙げています。Unified RoutingはTunnel以外のすべてで利用できます。
リクエストがタイムアウトするのはなぜですか?
ほとんどの場合、戻りのルートが不足しているためです。Cloudflareはこれがベータ期間中に最も多かった誤りだと説明しています。WANまたはMeshでは、100.64.0.0/12および2606:4700 – cf1:5000 – – /64のルートを設定してください。
プライベートネットワーク間でも動作しますか?
まだです。今回の提供はプライベートオリジンへのパブリックトラフィックが対象です。Cloudflareは、プライベートネットワーク間のトラフィックについて、2027年初めにクローズドベータを予定しています。
プライベートネットワーク間トラフィックへの対応は2027年に予定
Cloudflareが次に掲げているのは、WAFとレート制限をプライベートネットワーク間にも広げることです。現時点では目標にとどまり、2027年初めのクローズドベータが予定されています。
- 移行を計画する前に、ドキュメントで最新の制約一覧を確認してください。
- Private Originsと将来のプライベートベータの利用条件について、アカウントチームに問い合わせてください。
- 外部からのリクエストを本当に受ける必要がある社内サービスを洗い出し、この保護が必要な場所を把握してください。




