Cloudflareでパブリックトラフィックをプライベートアプリケーションにルーティングする

openaijamodel: gpt-5-mini-2025-08-07

インターネットの長い歴史の中で、パブリックとプライベートのインフラは別々の世界として運用されてきました。パブリックなアプリケーションはCDNやWAFの背後にあり、プライベートなアプリケーションはVPNやファイアウォール、別個の運用スタックの背後にありました。しかし、その区別はもはや時代遅れになりつつあります。多くの組織にとって重要なアプリケーションは公開ウェブサイトではなく、内部API、AIエージェントのバックエンド、MCPサーバー、運用ツールなど、元々パブリックにさらすことを想定していないものです。それらにもモダンなセキュリティ、パフォーマンス、プログラマビリティが必要であり、これらはアプリケーションの配置場所による偶発的なものではなく、トラフィックに対する一貫した特性であるべきです。

これまで、プライベートアプリケーションにこれらのサービスを適用するには、パブリックIP、ファイアウォール例外、コネクタソフトウェア、あるいは複雑なネットワーク設定が必要でした。そのため、多くのプライベートアプリケーションはWAF、ボット管理、レート制限、キャッシュ、トラフィック加速、リライト、Workersといった機能の恩恵を受けられずにいました。

本日、対象となる Enterprise 顧客向けにクローズドベータで "Application Services for Private Origins" をローンチします。これにより、オリジンをパブリックインターネットに晒すことなく、プライベートオリジンへ安全にトラフィックをルーティングできます。Cloudflareのセキュリティ、パフォーマンス、プログラマビリティは、パブリック向けアプリケーションと同じようにプライベートネットワークで稼働するアプリケーションを保護できます。WAFルール、ボット管理、レート制限、キャッシュ、リライト、Workersは、パブリックIPの公開やオリジン上でのcloudflaredの稼働を必要とせず、プライベートオリジンの前に配置できます。

1つのアプリケーション層、4つのトラフィック組み合わせ

このルーティングモデルは、既存の接続パターン（Cloudflare Tunnel、Cloudflare One Client、private network integrations）に基づいています。長年にわたり、Cloudflare Tunnel は cloudflared を使ってパブリックからプライベートアプリケーションへのルーティングを可能にしてきました。今回の機能は、オリジン上でコネクタソフトウェアを稼働させることなく、既存の Cloudflare WAN や Cloudflare Mesh 接続に同じモデルを拡張します。

多くの接続は、Cloudflareのプライベートネットワークリーティング層を通してオーケストレーションされ、Cloudflare Tunnel、Virtual Networks、Cloudflare Mesh、その他の接続方式経由でプライベート宛先へトラフィックを送る方法を決定します。顧客はAPIやダッシュボードを通じてルーティング動作を定義でき、製品ごとに別々のネットワークスタックを管理する必要がなくなります。

Cloudflareのプライベートネットワーキング層をアプリケーションサービススタックに直接拡張したことで、セキュリティ／パフォーマンスのプロキシインフラが、プライベートIPをパブリックホスト名の有効なオリジンとして扱えるようになりました。その結果、以前は Cloudflare Tunnel、Cloudflare One、Cloudflare Mesh、Cloudflare WAN 経由でのみ到達可能だったプライベートIPが、パブリックオリジンと同様に Cloudflare の各種サービスの背後に置けます。

これにより、Cloudflare製品間でより統一されたモデルが実現します。Workers VPC bindings と Spectrum private origin routing は同じ基盤となるプライベート接続レイヤーに依存するようになり、顧客はプライベートトラフィックがCloudflare環境内でどのように移動するかを単一の信頼できる情報源で制御できます。

アプリケーショントラフィックは、ユーザーの出所（Internet or private network）とアプリケーションの所在（public or private）に基づいて4つの組み合わせに分類できます。上段右は従来のCloudflare: インターネット上のユーザーがインターネット上のアプリケーションに到達し、Cloudflareが中継します。下段右は Cloudflare One：プライベートネットワーク上のユーザーがパブリックサービスに安全に到達します。上段左が本日ローンチした機能です。下段左（private→private）は今後の目標です。

今日リリースされるもの（What is shipping today）

これまで、パブリックトラフィックをプライベートオリジンに届けるにはトレードオフが伴いました。顧客はオリジン上または近傍で cloudflared（Cloudflare Tunnel）を稼働させる方法や、プライベートオリジンプールを持つ Cloudflare Load Balancing を使ってヘルスチェックとフェイルオーバーを行う方法をとってきました。多くの組織はパブリック向けロードバランサやリバースプロキシ、ホップ間のmTLS、複数層でのTLS終端といった並列インフラを維持していました。その結果、CloudflareのフルなApplication Servicesをプライベートアプリケーションに適用するには追加の複雑性や運用オーバーヘッド、別製品の併用が必要でした。

"Application Services for Private Origins" はそのトレードオフを排除します。欠けていたのは、すでに Cloudflare WAN（IPsec tunnels、GRE tunnels、CNI links）や Cloudflare Mesh を運用している顧客に対するパスでした。彼らはサイト間ネットワーキングやZero TrustのためにCloudflareへプライベート接続を構築しており、同じ接続を使ってパブリックトラフィックをプライベートオリジンに届けたいと望んでいました。本機能はまさにそれを実現します。

プロキシ化されたAまたはAAAAレコードで Use private network routing を有効にすると、CloudflareのWAF、レート制限、キャッシュ、ボット管理、変換ルールは通常通りCloudflareネットワーク上で動作します。違いは最終ホップだけで、Cloudflareがオリジンへ到達する際にパブリックインターネットではなく、既存のプライベートネットワーク接続経由でルーティングする点です。

このトグルは、RFC 1918 のプライベートIPv4（10.x.x.x、172.16.x.x–172.31.x.x、192.168.x.x）、RFC 6598 のCGNATレンジ（100.64.x.x–100.127.x.x）、RFC 4193 のUnique Local IPv6（FC00::/7）に対して自動で有効になります。これらはプライベートネットワーク内でのみ到達可能なアドレスだからです。プライベートネットワークやトンネル経由でのみ到達可能なパブリックIPに対しては、トグルを手動で有効にできます。

API例（What the API looks like）

APIでデプロイを自動化する顧客向けには、プライベートルーティングは標準のDNSレコードに追加する属性に過ぎません。以下は作成例です：

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "use_private_routing": true
}

裏側では、Cloudflareのプロキシプラットフォームが Cloudflare Origin API を問い合わせて app.example.com のトラフィックをどこへ送るかを決定します。レスポンスには、宛先へプライベートネットワーク経由で到達すべきであることを示すメタデータが含まれます：

{
  "zone_name": "example.com",
  "ipv4_addresses": ["10.0.0.50"],
  "use_private_routing": true
}

use_private_routing フラグが重要なシグナルです。プロキシがこれを検出すると、プライベートIPへ直接パブリックインターネット経由で接続しようとする代わりに、リクエストをプライベートネットワーキング層に引き渡します。そこから IPsec、GRE、Cloudflare Tunnel、CNI、Cloudflare Mesh といった既存のプライベート接続経路を使って接続がルーティングされます。

HTTP以外：Spectrum と Workers VPC

このルーティングモデルはHTTPアプリケーションに限りません。オリジンはウェブサーバーである必要はなく、TCPデータベース、UDPロギングエンドポイント、もしくはWorkersが直接呼び出すプライベートAPIでも構いません。共通点は、Cloudflareがトラフィックとプライベートネットワークの間に入り、プロトコルや発信元に関わらず同じセキュリティ、パフォーマンス、ルーティングレイヤーを適用することです。

Cloudflareのレイヤー4プロキシである Spectrum は、プライベートIP上で稼働するTCP/UDPサービスの前に配置できるようになりました。ロードバランサプールを仲介として作る代わりに、Spectrumのオリジン設定で virtual_network_id を直接指定できます。Spectrumアプリケーション作成時に、プライベートオリジンIPとともに virtual network ID を含める例：

{
  "protocol": "tcp/22",
  "dns": {
    "type": "CNAME",
    "name": "ssh.example.com"
  },
  "origin_direct": ["tcp://10.0.0.50:22"],
  "virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}

Spectrumアプリケーションをプライベートオリジンと virtual network を使って作成または更新する際、Cloudflareは構成を保存する前にそのIPアドレスが Cloudflare Tunnel のルートに一致するかどうかを検証します。一致するルートがなければ、APIはリクエストを拒否し、アプリケーションは作成されません。保存されると、Spectrumは接続を仮想ネットワークに渡し、そのネットワークが関連するトンネル経由でルーティングします。これは、DNSレコードに Use private network routing を有効にしたときにHTTPトラフィックが使用する経路と同じです。

この初期リリースでは、Spectrumのプライベートオリジンは Cloudflare Tunnel を通じてサポートされます。追加のプライベート接続オプションのサポートは今後のリリースで対応予定です。これにより、パブリックIP、コネクタソフトウェア、ロードバランサを必要とせずに、プライベートIP上で動作する任意のTCP/UDPサービスの前にSpectrumを配置できます。サービスは非公開のままです。

Workers VPC は、Cloudflare上で動作するコードのためのループを閉じます。binding によって Workers ランタイムはDNSレコードと同じプライベート経路を通るようにルーティングします。ブラウザ、モバイルアプリ、Workers、AIエージェントは、DNSレコード（インターネット向けトラフィック）やバインディング（Workers）を通じてプライベートオリジンに到達します。

今後の計画（What comes next）

パブリック→プライベートのルーティングは現在クローズドベータ中で、GA（General Availability）は2026年第4四半期を目標にしています。GA後はプライベート→プライベートのトラフィックフローに向けて開発を進めます：プライベートネットワーク上のユーザー、サービス、AIエージェントが他のプライベートネットワーク上のアプリケーションに安全に到達し、Cloudflareのアプリケーションサービスがその中間に入るモデルです。

最終的な目標は、ユーザーまたはオリジンがパブリックであるかどうかに関わらず、同じCloudflareインフラがトラフィックを保護できる世界です。たとえば、Cloudflare One Client を使って社内の wiki.company.internal にアクセスする従業員は、カスタマーがパブリックAPIにアクセスする際と同じWAF、レート制限、ボット管理の保護を受けることができます。専有の内部APIを利用するAIエージェントはブラウザと同じセキュリティスタックを通り、クラウドやデータセンター間のサービス間トラフィックも、ユーザーとサーバーのいずれもがパブリックインターネット上に存在しない場合でもインターネットトラフィックと同様のコントロールを得られるようになります。

さあ始めましょう（Get started today）

プライベートオリジンへのルーティングは、対象の Enterprise 顧客向けにクローズドベータで利用可能です。アクセスを希望する場合は Cloudflare のアカウントチームに連絡してください。有効化後は、フルセットアップを案内する開発者向けドキュメントに従ってください。

必要なもの:

Cloudflare One 接続（IPsec、GRE、CNI、または Cloudflare Mesh）
プライベートネットワークに Cloudflare の送信元IPレンジ 100.64.0.0/12 へのリターンルート

質問やフィードバックがある場合は、コミュニティフォーラムに参加するか、アカウントチームにお問い合わせください。

タグ: server-island-start, Application Services, Private Network, DNS, Pingora, Cloudflare One, Cloudflare Zero Trust, Zero Trust, Product News

Route public traffic to private applications with Cloudflare

要約

Summary

Key Points

Quick API example