Cloudflareは非公開IPの配信元を中継する構成を一般提供にした。使うにはCloudflare Oneの接続などの条件がある ── 多くのサイトに効く「配信元に直接つながる道」が残っていないかを確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 非公開IPの配信元を、公開せずにCloudflareの守りの後ろに置けるようになった
   1. 先に結論 — 当てはまるかの判定は3問で終わる
2. 02 なぜ・背景 — 配信元に直接つながると、前に置いた守りは素通りされる
   1. CDNやWAFは、通った通信にしか効かない
   2. 配信元のアドレスは、思わぬ所から分かる
   3. 直接つなげる道は、3つの形で残る
   4. 「隠す」と「閉じる」は別の作業になる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 戻りの経路
   2. プロキシ付きのDNSレコード
4. 04 型別 — 対象の条件、告知が書いていないこと、確かめる手順
   1. 🅰 適用範囲 — 告知が書く要件と、対象外のもの
   2. 🅱 この告知が書いていないこと
   3. 🅲 手順1 — 3問で、自分に当てはまるかを判定する
   4. 🅲 手順2 — プロキシなしのレコードを、上から全部開く
   5. 🅲 手順3 — 配信元のアドレスに直接つないで、何が返るかを書き留める
   6. 🅲 手順4 — 配信元側で「どこからの通信を受けるか」を読む
   7. 🅲 手順5 — 戻りの経路は、移す前に担当者を決める
5. 05 明日、担当サイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 配信元を守る方法は、新機能のほかにもある
   1. 公式文書が並べる方法を、層ごとに読む
   2. 今回の新機能は、この表のどこに入るか
   3. 配信元のアドレスを変える
   4. 通信の量を減らす側の工夫
7. 07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない
   1. 当サイトで同じ点検をするなら
8. 08 このテーマは、ここまで — Cloudflareの告知と、配信元の守りを追った記事の流れ
   1. これまでの記事
   2. 今回の記事の位置
9. 09 この記事のまとめ

01 何が書いてあるか — 非公開IPの配信元を、公開せずにCloudflareの守りの後ろに置けるようになった

Cloudflareは2026年10月30日、公開アドレス宛ての通信を、非公開IPアドレスの配信元へ中継する機能「Services for private origins」を一般提供にしたと公式ブログで告知した。配信元（オリジン）とは、ページやAPIの中身を実際に持っているサーバーのことである。告知によると、2026年6月に限定の試験（クローズドベータ）が始まり、今回、試験に参加していない利用者にも広がった。

仕組みの要旨は次のとおりである。利用者は、Cloudflareのプロキシを通すDNSのレコード（AレコードまたはAAAAレコード）を、非公開のIPアドレスに向ける。すると、Cloudflareは、利用者がすでに持っているCloudflare Oneの接続を通して、その配信元に届く。配信元のサーバーは、インターネットから直接見えるアドレスを持たなくてよい。告知は、使い道の例として、社内のAPI、AIエージェントの裏側のサーバー、MCPサーバー、社内向けのツールを挙げている。

非公開にしても、Cloudflare側の守りの機能はそのまま効く、と告知は書く。挙げられている機能は、WAFとマネージドルール、bot管理、レート制限、キャッシュ、変換やリライトのルール、Workersである。公開の配信元と同じように動く、という書き方である。

ただ、この記事の読者の多くは、この機能を今すぐ使う立場ではないと筆者は考える（筆者の読み）。使うには、後で述べるとおり、Cloudflare Oneの接続（5種類のどれか）が要る。それでも、この告知は、多くのサイトに関係する問いを1つ置いていく。「自分の担当サイトの配信元に、CDNを通さずに直接つながる道は、残っていないか」という問いである。この記事は、前半で「この新機能が自分に当てはまるか」を先に判定し、後半で、当てはまらない場合にも役に立つこの問いの確かめ方を13項目にまとめる。

先に結論 — 当てはまるかの判定は3問で終わる

次の3つの問いに、順に答える。1つでも「いいえ」なら、この新機能は、いまの契約と構成では使えない。

1. Cloudflareを、担当サイトの前に置いているか（DNSをCloudflareのプロキシ経由にしているか）。
2. Cloudflare Oneの接続（IPsec、GRE、CNI、Tunnel、Meshの5種類のどれか）を、配信元のある場所とつないでいるか。
3. 配信元は、非公開のIPアドレスのネットワークの中（クラウドの非公開ネットワーク、社内など）に置いているか、置く予定があるか。

02 なぜ・背景 — 配信元に直接つながると、前に置いた守りは素通りされる

CDNやWAFは、通った通信にしか効かない

CDN（コンテンツ配信ネットワーク）やWAF（ウェブアプリケーションファイアウォール）は、訪問者とサーバーの間に立って、通信を見て、必要なら止める仕組みである。逆に言えば、その仕組みを通らない通信には、何も効かない。配信元のIPアドレスを知っている相手が、CDNを通さずにそのアドレスへ直接つなげば、WAFのルールも、bot管理も、レート制限も、キャッシュも使われない。

当サイトは以前、同じ考え方で、WAFの保護とPHPの更新の関係を整理した。PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）という記事で、CDNを通らない経路が1つの確認項目になっている。今回の機能は、その経路を、構成の側から無くす手段の1つと読める（筆者の読み）。

配信元のアドレスは、思わぬ所から分かる

Cloudflareの公式文書「Protect your origin server」は、配信元のIPアドレスが分かってしまう道として、次のような点を挙げている。

• プロキシを通さない（DNSだけの）レコードに、配信元のアドレスが書かれている。メール用のSPFやTXTのレコードの中にアドレスが入っていることがある。
• 保護するWebサイトと同じサーバーで、メールの送信も動かしている。存在しない宛先のメールが返ってきたときの情報から、メールサーバーのアドレスが分かるおそれがある。
• Cloudflareを入れる前のDNSの記録は公開の情報で、履歴に古いアドレスが残る。そのため、導入後に配信元のアドレスを変えることを勧めている。

この3つは、専門の機材がなくても確かめられる。後半のチェックリストでは、1つ目（プロキシなしのレコードとSPF・TXTの中のアドレス）が4番目と5番目、2つ目（メールの送信）が9番目の項目になっている。3つ目の導入前のDNSの履歴は、公開された情報として残るため、チェックリストには項目を設けず、第06章の「配信元のアドレスを変える」で扱う。6〜8番目は、見つかった道が実際に開いているか、配信元側の対策は何かを確かめる別の項目である。

直接つなげる道は、3つの形で残る

CDNを通らずに配信元へつながる道は、大きく3つの形で残りうる、と筆者は整理している（筆者の整理）。1つ目は、配信元のアドレスが漏れていて、そこへ直接つなげる形。2つ目は、アドレスは知られていなくても、配信元側が誰からの通信でも受け付けている形。3つ目は、CDNを通る通信の中に、別の利用者のCDN経由の通信が混ざる形である。3つ目は、Cloudflareのアドレスは多くの利用者で共有されるため、アドレスの許可だけでは区別できないことがある、という筆者の読みである。公式文書がこの点をはっきり書いているかは、確かめていない。この点が、後の章で述べるクライアント証明書や秘密のヘッダーなどが並ぶ理由の1つだと筆者は読む。

「隠す」と「閉じる」は別の作業になる

アドレスが知られないようにする（隠す）ことと、知られても直接つなげないようにする（閉じる）ことは、別の作業である。隠すだけだと、何かの拍子にアドレスが分かった時点で、守りが無くなる。公式文書が、配信元側での対策を何段にも分けて並べているのは、隠すだけでは足りないからだと筆者は読んでいる（筆者の読み）。今回の新機能は、「閉じる」の最も強い形、つまり配信元がそもそも公開のアドレスを持たない形に近い。

03 用語 — 出てくる言葉を、先にそろえる

戻りの経路

通信は、Cloudflareから配信元へ向かう道（行き）と、配信元からCloudflareへ戻る道（帰り）の2方向でできている。告知が戻りのルートの設定を求めているのは、Cloudflare WANまたはCloudflare Meshで接続する場合である。告知は、帰りの道、つまりCloudflareの送信元の範囲への戻りの経路が設定されていないと、要求が時間切れになり、配信元には何も届かない、という症状になると書く。ベータで最も多かった設定の失敗だったという。Tunnelなど、ほかの方式で接続する場合に同じ設定が要るかは、告知の要件の文には書かれていない。後の章で詳しく述べる。

プロキシ付きのDNSレコード

DNSの管理画面で、レコードの横に「オレンジの雲」の印が付いているものを、プロキシ付きと呼ぶ。この印があると、訪問者のつなぎ先はCloudflareになり、配信元のアドレスは見えなくなる。印が無い（灰色の雲の）レコードは、書かれたアドレスがそのまま公開される。公式文書は、可能なら印を付けるよう勧めている。

04 型別 — 対象の条件、告知が書いていないこと、確かめる手順

🅰 適用範囲 — 告知が書く要件と、対象外のもの

告知が書く要件を、表にした。

告知の説明文は、Cloudflare One接続を持つ顧客すべてを対象に挙げる一方、本文は、権限をアカウントの担当者に有効にしてもらう必要があると書く。プランの名前や料金の区分は、告知に書かれていない。契約によって使えるかどうかは、この記事では分からない。

🅱 この告知が書いていないこと

• 料金がいくらかは書かれていない。
• 配信元に直接つなげる道を、どう見つけるかは書かれていない。この告知は、新しい機能の紹介であって、点検の手引きではない。
• この構成にしたあと、配信元の応答が遅くなるか、速くなるかの数字は書かれていない。
• 告知の末尾は、次の取り組みとして、非公開のネットワーク同士の通信を挙げ、その限定の試験を2027年の初めごろに目指すと書く。今回の機能の対象は、公開インターネットから非公開の配信元へ向かう通信である。

🅲 手順1 — 3問で、自分に当てはまるかを判定する

最初の作業は、第01章の3つの問いに答えることである。答える相手は、Cloudflareの契約を管理している人と、配信元を管理している人の2人であることが多い。1通のメッセージで、次の3つを聞くと返事が早い。

1. 担当サイトのDNSは、Cloudflareのプロキシ（オレンジの雲）を通っているか。
2. Cloudflare Oneの接続が、IPsec、GRE、CNI、Tunnel、Meshのどの方式であるか。
3. 配信元は、非公開のアドレスのネットワークの中にあるか。

3つとも「はい」なら、第06章の表と、アカウントの担当者への問い合わせへ進む。1つでも「いいえ」なら、この新機能の導入は今は考えず、次の手順2以降の点検へ進む。

🅲 手順2 — プロキシなしのレコードを、上から全部開く

DNSの管理画面を開き、灰色の雲のレコードを上から順に見る。見るのは、書かれているアドレスが、配信元のサーバーのアドレスと同じに見えないかである。メール用のSPFやTXTのレコードの中身にも、アドレスが書かれていることがある。見つかったら、そのアドレスが配信元のものかを、運用者に聞く。

🅲 手順3 — 配信元のアドレスに直接つないで、何が返るかを書き留める

配信元のアドレスが分かっているなら、自分が管理するサイトに限って、そのアドレスをブラウザに直接入れて開く。見るのは3つの結果のどれかである。サイトの中身がそのまま出る、拒否や接続できない表示が出る、別のページ（初期のページなど）が出る。サイトの中身が出るなら、CDNを通らずに配信元へつながる道が開いていることになる。証明書の警告が出るのは、アドレスで直接つなぐと名前が合わないためで、ここでは想定内である。

結果は、日付と一緒に台帳に書く。「閉じている」と書く前に、一度は実際に開いてみる。設定の画面で閉じているように見えることと、実際につながらないことは別の話である。

🅲 手順4 — 配信元側で「どこからの通信を受けるか」を読む

配信元のファイアウォールや、サーバーの前に置いたネットワークの許可の設定を開き、許可している送信元を読む。公式文書が挙げる、配信元側での対策は、次の5つである。

• Cloudflareの範囲のアドレスだけを許可する。
• Cloudflareが付ける秘密のHTTPヘッダーを持つ通信だけを通す。
• クライアント証明書で、通信がCloudflareから来たことを確かめる（Authenticated Origin Pulls）。
• Cloudflare Tunnelで、配信元から外向きにだけつなぐ。
• 専用の送信元アドレスを使い、それだけを許可する。

どれを使っているかを、運用者に聞いて、台帳に1行書く。何も使っていなければ、それが今回の点検の最大の発見になる。

🅲 手順5 — 戻りの経路は、移す前に担当者を決める

WANまたはMeshで接続して新機能を使う場合、告知が特に強調している失敗は、戻りの経路である。告知は、ベータの期間に最も多かった設定の失敗として、Cloudflareの送信元の範囲への戻りのルートが無いことを挙げ、そのとき、要求が時間切れになり、配信元には何も届かないという症状になる、と書く。配信元のログに何も残らないので、「届いていない」ことは分かっても、原因は配信元のログからは分からない。戻りのルートを設定する担当者の名前を、移す前に決めておく。

05 明日、担当サイトで確認できることチェックリスト

以下は、配信元に直接つながる道が残っていないかを確かめ、新機能が当てはまりそうな場合は準備を始める13項目である。1〜3番目は接続と構成の把握、4〜9番目は配信元の隠れ方と閉じ方の確認、10番目は故障の通知、11〜12番目は新機能の準備、13番目は記録である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。

• Cloudflareの管理画面か請求書を開き、Cloudflare Oneの接続（IPsec、GRE、CNI、Tunnel、Meshのどれか）があるかを「ある・ない・分からない」の3択で台帳に書く
• 担当サイトの一覧を上から見て、配信元が非公開のネットワークか社内にあるサイトの数を数え、台帳に件数を書く
• 担当サイトのうち、DNSをCloudflareのプロキシ（オレンジの雲）経由にしているサイトを、一覧に印を付けて数える
• DNSの管理画面で、プロキシなしの灰色の雲のレコードを上から全部開き、配信元のアドレスに見えるものがないかを見る
• メール用のSPFとTXTのレコードを開き、書かれたアドレスが配信元のものと同じでないかを見る
• 自分が管理するサイトだけで、配信元のアドレスをブラウザに直接入れて開き、中身が出たか、拒否されたか、別のページが出たかを書き留める
• 配信元のファイアウォールの許可の一覧を開き、Cloudflareの範囲以外から許可している行の数を数える
• 配信元側の対策が、アドレスの許可、秘密のヘッダー、クライアント証明書、Tunnelのどれかを運用者に1通で聞き、答えを台帳の1列に書く
• 保護するサイトと同じサーバーからメールを送っていないかを、運用者に聞いて、「送っている・送っていない」を書く
• 配信元の故障（5xxの増加、到達できない）の通知が登録されているかを、通知の設定画面で数える
• 3問すべてに「はい」の場合だけ、アカウントの担当者に、Private Originsの権限と接続方式を聞く下書きを1通保存する
• WANまたはMeshで接続して新機能に移す場合は、戻りのルートを設定する担当者の名前を、台帳の1行に書く
• 点検した日付と、次に見直す日（3か月後）を、台帳の見出しに書く

06 代替・他の選択肢 — 配信元を守る方法は、新機能のほかにもある

公式文書が並べる方法を、層ごとに読む

新機能が使えない構成でも、配信元を守る方法はある。Cloudflareの公式文書は、配信元への接続を守る方法を、DNSの項目のあと、アプリケーション層、トランスポート層、ネットワーク層の3つの見出しに分けて並べ、各方法の強さと使える顧客の範囲を書いている。その要旨を表にした。強さの評価は、文書の書き方に沿った（筆者がページの文言をそのまま写したものではない）。

この表で、筆者が最も大事だと読むのは、アドレスの許可だけでは、評価が中程度で、偽装に弱いと書かれている点である。「Cloudflareの範囲だけ許可しているから大丈夫」という説明は、1つの層にすぎない。ほかの層（秘密のヘッダーやクライアント証明書）と組み合わせるかを、運用者に確かめる。

今回の新機能は、この表のどこに入るか

今回の新機能は、上の表にはない。配信元が公開のアドレスを持たないので、「直接つなぐ」ための入口そのものが無い構成になる。筆者の読みでは、Tunnelと近い位置にあるが、告知はTunnelとの違いや優劣を書いていない。どちらが自分の構成に向くかは、告知だけでは決められず、契約とネットワークの事情で変わる。

配信元のアドレスを変える

公式文書は、Cloudflareに導入したあと、配信元のIPアドレスを変えることを勧めている。DNSの記録は公開の情報で、導入前の履歴に古いアドレスが残るためである。アドレスを変えるのは、サーバーの引っ越しに近い作業になることがあるので、他の方法と組み合わせて、計画的に行う。

新機能も、アドレスの変更も、どちらもすぐには決められない場合は、先に「直接つないだら何が返るか」だけを確かめて、台帳に書く。結果が「拒否される」なら、緊急度は下がる。「中身が出る」なら、どの方法でも、閉じる計画を立てる理由になる。

通信の量を減らす側の工夫

公式文書は、配信元への通信そのものを減らす工夫も書いている。キャッシュで配信元への要求を減らす、複数のDNSレコードで分散する、急な増加にはWaiting Roomで受け入れを調整する、といったものである。守りではなく、負荷の面の対策だが、配信元が弱い構成では、この面も一緒に見ておく。

07 当サイトで確かめたこと — 当サイトはCloudflareを使っていない

当サイトは、Cloudflareを使っていない。そのため、この記事で取り上げた新機能は、当サイトには当てはまらない。第01章の3問のうち、1つ目で「いいえ」になる。当サイトの画面で、この機能の設定を見たり、試したりはしていない。

一方で、配信元の側の点検という考え方は、当サイトでも同じ形で取り組んでいる。公開の場所に残ったファイルを外から確かめる作業を、当サイトのブログにまとめた。控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順は、外から見えるものを自分で数えた記録である。配信元に直接つながる道を探す点検と、同じ向きの作業である。

当サイトで同じ点検をするなら

当サイトがCloudflareを使い始めた場合は、この記事のチェックリストの4〜10番目を、そのまま当サイトに当てる。使っていない間は、配信元の側の点検として、外から見えるものを数える作業を続ける。

08 このテーマは、ここまで — Cloudflareの告知と、配信元の守りを追った記事の流れ

これまでの記事

当サイトでは、2026年10月に入って、Cloudflareの告知と、配信元や守りの層の話を何度か取り上げた。時系列で並べる。

• 通信の半分以上は人間ではないという話は、Cloudflareが通信の半分以上は人間ではないと書いた週、当サイトのログで自動と分かるものは36.2%だった ── 他人の大きな数字を、自社のログ1週間分で数え直すで書いた。
• AI学習だけを止める設定は、Cloudflareが9月15日に加えた「AI学習だけを止める」設定 ── 検索に載せたまま止められる範囲と、今週確かめる6つで書いた。
• WAFと配信元の関係は、PHPの脆弱性にWAFの保護が入っても、PHPの更新は要る。Cloudflareは「追加の層」と書いた ── CDNを通らない経路・ルールの対象外・WAFを切ったときを確かめる13項目（2026年10月時点）で書いた。
• WAFの検知と応答の新しいルールは、CloudflareのWAFは、リクエストと応答を対にして見る検知と応答のルールを全プランに入れた ── 自社の画面とルールを確かめる13項目（2026年10月時点）で書いた。
• WAFの守りが届かない所の確かめ方は、CloudflareはWAFを突破できるか試す公開の催しを始め、同じ記事に「更新の代わりにならない」と書いた ── 事業者が自分で試す理由から、自社のWAFの守りが届かない所を確かめる13項目（2026年10月時点）で書いた。
• 配信元が範囲指定の要求に答えられるかは、CloudflareのOrigin Range Requestsは全プランで使えるが、配信元が範囲指定に答えられることが前提になる ── 大きなファイルの配り方を確かめる13項目（2026年10月時点）で書いた。

今回の記事の位置

これまでの記事は、CDNやWAFの手前の機能を確かめる話が中心だった。今回は、配信元を、そもそも手前の機能を通る形に限る話である。新機能は、その最も強い形の1つだが、使えるのは接続などの条件を満たす場合に限る。使えない場合でも、配信元に直接つながる道を無くす点検は、どの担当サイトにも当てはまる。

点検の結果を、一覧で管理するための形は、PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る ── 台帳の8列を埋めて確かめる13項目（2026年10月時点）にある。この一覧に、「配信元に直接つないだ結果」と「配信元側の対策の方式」の2列を足すと、今回の点検が一覧の中で管理できる。外から見える設定の状態をまとめて確かめるときは、🔧 WEBサイト総合分析・レポートツール — 公開ページの状態をまとめて確認するが入口になる。配信元そのものの設定は、このツールでは分からない。