Cloudflare、非公開サーバーもWAFで保護【2026年10月】

2026年10月30日（米国時間）、Cloudflare は公開 IP を持たないプライベートなサーバー（オリジン）にも、WAF・キャッシュ・ボット対策・Workers を使える機能「Cloudflare services for private origins」を一般提供（GA）にしたと発表しました。6月に始まったクローズドベータからの正式提供です。

Cloudflare services for private origins is now generally available

これまで Cloudflare の保護を使うには、基本的にサーバーをインターネットに公開しておく必要がありました。今回の機能は、サーバーを社内ネットワークなどに隠したまま、入り口だけを Cloudflare で守るためのものです。ただし使うには条件があり、現時点では企業（Enterprise）向けの機能という位置づけです。

private originsとは？一言でまとめると

一言でいうと、DNS レコードにプライベート IP を書くだけで、Cloudflare が自社の専用回線経由でそのサーバーに通信を届けてくれる機能です。

オリジンは、Cloudflare の後ろで実際にサイトやアプリを動かしているサーバーのことです。プライベート IP は「10.0.0.50」のような、社内ネットワークの中でしか届かないアドレスを指します。

これまでとの違い：公開IP・ポート開放が不要に

公式ブログによると、社内向けの API、AI エージェントのバックエンド、MCP サーバー、運用ツールなどは、インターネットに公開する前提で作られていません。それでも、取引先や顧客、AI エージェントからのリクエストは受け付ける必要があります。

これまで、そうしたサービスの前に Cloudflare を置くには、次のどれかが必要でした。

• サーバーに公開 IP を付ける
• ファイアウォールのポートを開ける
• サーバーの隣で cloudflared（Cloudflare Tunnel 用のソフト）を動かす

その結果、プライベートなアプリは WAF やレート制限などの保護を受けられないことが多かった、とブログは説明しています。

今回の機能では、オリジンはプライベート IP のままで、受信側のファイアウォールに例外を作る必要もありません。企業ネットワーク向けの Cloudflare WAN でつないでいれば、オリジン側に専用ソフトを入れる必要もないとしています。

何ができる？使える機能と制限

① 公開サイトと同じように使える機能

プロキシした（オレンジの雲の）A / AAAA レコードをプライベート IP に向けると、次の機能が公開オリジンのときと同じように動きます。

• WAF とマネージドルール
• ボット管理
• レート制限
• キャッシュ
• Transform ルール・書き換えルール
• Workers

TLS の終端や WAF・キャッシュの処理は、これまでどおり Cloudflare のネットワーク上で行われます。違うのは最後の区間だけで、公開インターネットではなく、利用者の専用の接続を通ってオリジンに届きます。

② まだ使えないもの

公式ブログは、次の制限を挙げています。

• Argo Smart Routing（経路の高速化）は非対応
• Dedicated CDN Egress IPs（専用の送信元 IP）は非対応
• オリジンのヘルスチェックには Load Balancing が必要

③ 自動でオンになるIPアドレスの範囲

DNS レコードに次の範囲の IP を書くと、「Use private network routing」の設定が自動でオンになり、オフにはできません。

専用の接続からしか届かない公開 IP の場合は、手動でオンにできます。なお、同じ名前に複数の A / AAAA レコードがあり、1つでもオンになっていると、その名前のレコードはすべてプライベート経由になります。

誰が使える？料金・提供状況

結論からいうと、個人や小規模のサイトがすぐに使える機能ではありません。

ブログの説明文には「Cloudflare One の接続を持つすべての顧客に提供」とあり、ベータの参加者以外にも開放されたのは確かです。一方で、開発者向けドキュメントは「Enterprise-only」「Closed beta」の表記のままです（最終更新は2026年5月7日）。

権利がないままプライベート IP をプロキシしようとすると、「Error 1002: DNS points to prohibited IP」が出るとドキュメントに書かれています。料金も公開されていないため、使いたい場合は Cloudflare の営業・アカウントチームに問い合わせることになります。

始め方：公式ドキュメントの手順

ここでは、公式ブログの「Get started」と、ドキュメントの「Set up a private origin via Cloudflare WAN」に書かれている流れを紹介します。権利の有効化と Cloudflare One の接続が済んでいることが前提です。

① 戻りの経路を確認する

Cloudflare WAN や Cloudflare Mesh でつなぐ場合は、Cloudflare の送信元の範囲（IPv4 は 100.64.0.0/12、IPv6 は 2606:4700:cf1:5000::/64）への戻りの経路をネットワークに設定します。

Cloudflare WAN のドキュメントでは、次の準備も求めています。

• 冗長化のため、IPsec トンネルを2本用意する
• トンネルごとに静的ルートを設定し、優先度を変える（例: 100 と 101）
• Cloudflare Source IP をプライベートな範囲（既定は 100.64.0.0/12）にする

② DNSレコードを作る

ダッシュボードでは次の手順です。

1. DNS の Records を開き、Add record（または既存レコードの Edit）を選ぶ
2. A または AAAA レコードに、オリジンのプライベート IP を入力する
3. Proxy status（オレンジの雲）がオンになっていることを確認する
4. Use private network routing をオンにする（プライベート IP なら自動でオン）
5. Save を選ぶ

API で作る場合は、DNS レコードに private_routing を加えます（必要なトークン権限は DNS Write）。

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"type": "A", "name": "app.example.com", "content": "10.0.0.50", "proxied": true, "private_routing": true}'

既存の WAF・キャッシュ・ボット管理の設定は、そのホスト名にそのまま適用されます。

③ つながるか確認する

ドキュメントでは、トンネルが正常かをダッシュボードで確認し、ネットワークの外から curl -v https://<ドメイン>/ でアクセスし、オリジン側で Cloudflare の送信元範囲から通信が届いているかを tcpdump で見る、という流れを紹介しています。

公式ブログによると、ベータでいちばん多かった失敗は戻りの経路の設定漏れです。リクエストがタイムアウトし、オリジンに何も届かないときは、まず戻りの経路を確認するよう勧めています。

個人・小規模のVPSならCloudflare Tunnelが現実的

VPS で WordPress やアプリを動かしている人が「サーバーの IP を公開せずに Cloudflare で守りたい」場合、今回の機能を待つ必要はありません。公式ドキュメントで 「Available on all plans」（全プランで利用可能） とされている Cloudflare Tunnel が、その用途の機能です。

Cloudflare Tunnel の仕組みは、ドキュメントによると次のとおりです。

1. サーバーに cloudflared をインストールする
2. cloudflared が外向きだけの暗号化された接続で Cloudflare につながる（受信ポートの開放は不要）
3. 公開ホスト名をサーバー内のサービスに割り当てる（例: app.example.com → http://localhost:8080）
4. 通信は Cloudflare を通り、キャッシュ・WAF・ボット管理・DDoS 保護が適用される

今回の新機能との違いは、オリジン側で cloudflared を動かすかどうかです。サーバーが1台で、ソフトを入れられる VPS なら、Tunnel で十分に「オリジンを隠す」ことができます。新機能は、すでに企業ネットワークを Cloudflare WAN や Mesh でつないでいる会社が、その回線をそのまま使えるようにしたもの、と考えると分かりやすいでしょう。

オリジンの IP を隠すことは、Cloudflare が DDoS 対策としてすべてのユーザーに勧めている設定でもあります。最近の DDoS 攻撃の傾向は、こちらの記事でまとめています。

あわせて読みたい

Cloudflare DDoS報告：小さく短い攻撃が急増【2026年10月】

Cloudflare の前で使える無料の WAF については、次の記事で解説しています。

あわせて読みたい

Cloudflare無料WAFでできること：PHP脆弱性対策【2026年版】

VPS 側のファイアウォールなどの初期設定は、さくらのVPSのセキュリティ初期設定やXServer VPSのセキュリティ対策を参考にしてください。

次は「プライベート同士」：2027年初めにベータ予定

今回の機能は、インターネットからプライベートなオリジンへの通信が対象です。Cloudflare は次の段階として、プライベートネットワーク同士の通信にも同じ保護を広げる計画を明らかにしています。

• 対象：プライベートネットワーク上の利用者・サービス・AI エージェントが、別のプライベートネットワークのアプリにアクセスする通信
• 時期：2027年初めにクローズドベータを目指す
• 参加：アカウントチームに相談

ブログでは例として、社員が社内 Wiki（wiki.company.internal）を開くときにも WAF・レート制限・ボット管理を使えるようになる、と説明しています。

IT Picks的な所感

今回の発表は、「インターネットに出すアプリ」と「社内のアプリ」の守り方を1つにまとめるという、Cloudflare の方向性がはっきり見えるものだと思います。特に、AI エージェントや MCP サーバーのように、社内に置いたまま外部から呼ばれるサービスが増えていることを強く意識した機能です。

一方で、2026年10月30日時点では、ドキュメントは Enterprise-only・クローズドベータの表記のまま、料金も非公開です。「一般提供」といっても、個人や小規模のサイトが管理画面からすぐに使える機能ではない、と受け止めておくのがよいでしょう。

個人の VPS でオリジンを隠したいなら、全プランで使える Cloudflare Tunnel が現実的な選択肢です。新機能は、Cloudflare WAN などをすでに導入している企業が、ドキュメントの更新や料金の公表を待って検討する段階だと考えています。

Cloudflare は10月、AI モデルの Clairic など開発者向けの発表も続けています。

あわせて読みたい

Cloudflare「Clairic」とは？値をJSONで抽出【2026年10月】

まとめ

Cloudflare services for private origins の一般提供のポイントをまとめます。

• 発表：2026年10月30日（米国時間、Cloudflare 公式ブログ）
• できること：プライベート IP のオリジンに、WAF・ボット管理・レート制限・キャッシュ・Workers を適用
• 仕組み：プロキシした A / AAAA レコードをプライベート IP に向け、既存の Cloudflare One の接続で届ける
• 不要になるもの：オリジンの公開 IP・受信ポートの開放（Cloudflare WAN ならコネクターのソフトも不要）
• 制限：Argo Smart Routing・Dedicated CDN Egress IPs は非対応、ヘルスチェックは Load Balancing が必要
• 使える人：アカウントチームに権利の有効化を依頼。ドキュメントは Enterprise-only の表記
• 料金：公式に記載なし
• 今後：プライベート同士の通信を2027年初めにクローズドベータ予定
• 個人・小規模の代わり：全プランで使える Cloudflare Tunnel

VPS を Cloudflare の後ろに置いている人は、まずサーバーの IP が直接見えていないかを確認し、必要なら Cloudflare Tunnel でオリジンを隠すところから始めるのがおすすめです。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。