ルーターを触れない環境でも公開できる：Cloudflare Tunnelの始め方と、Free / Pro / Business に引かれた規約の線
画面名・仕様は2026年8月時点の確認です。Cloudflareは管理画面の構成と製品名が変わることがあるため、最新は各公式ドキュメントでご確認ください。
「自宅サーバーを外から見られるようにする方法」を調べると、手順はたいていこの1行から始まります。
ルーターの管理画面を開き、ポート開放（ポートフォワーディング）の設定へ進みます
ここで止まったまま、次の一手が分からなくなっていないでしょうか。手順が難解だったからではなく、その管理画面に自分が入れないから、という理由で。
集合住宅の共有回線を使っていて、回線側の設定を住人が変えられない。会社なら、境界のルーターやファイアウォールは外部のIT業者や本社の管理下にあり、管理画面のパスワードは渡されていない。誰に聞けばいいのかもはっきりしない。そういう位置に立たされている人は珍しくありません。
この状態で詰まっているのは、技術ではなく権限です。「ポート開放は危険だからやめましょう」という一般論は、開放する権限を最初から持っていない人にとっては助けになりません。必要なのは、開けないものを開けずに済ませる経路です。
Cloudflare Tunnel はそのための道具です。ただし使える範囲には、公式の利用規約ではっきり線が引かれた境界があります。しかもその線は、無料プランの外周ではなく、Enterprise とそれ以外（Free / Pro / Business）の間を通っています。手順と一緒に、そこがどこなのかまで見ていきます。
TL;DR
- Cloudflare Tunnel は、サーバー側からCloudflareへ「外向きの接続」だけを張る仕組みです。ルーターの受け口（ポート）を1つも開ける必要がなく、グローバルIPも要りません。だからルーター設定を触れない環境でも成立します。
- 現在の推奨手順はダッシュボード経由です。管理画面でトンネルを作成し、画面に表示されたインストールコマンドをサーバーにコピペします。
- ⚠️ 動画配信の公開は規約で止められています。 Enterprise以外のプランでCDN経由の動画・大容量ファイルを配信するには、Stream等の有償サービスの利用が必要と公式に明記されています。JellyfinやPlexをTunnelで公開する構成は、ここに該当します。
- ただし実際にどう扱われるかは、報告が割れています。規約が存在することは確定していますが、運用でどう当たるかは分かりません。この2つは分けて考える必要があります。
- 自分と社内の人だけが使うものなら、そもそも公開せずVPNの内側に置く方が適しています。用途が違うので、外から安全につなぐ方法（Tailscale / WireGuard）と読み分けてください。
「ポート開放できない」の正体は、たいてい権限の話
自宅サーバーの記事は、ポート開放を「危険だから避けるべき選択肢」として扱います。それ自体は正しく、理由は外から安全につなぐ方法にまとめてあります。ただ、実際に読者が止まる地点はもう一段手前にあります。
日本語の技術記事でも、この事情は繰り返し書かれています。たとえばQiitaの解説記事には、Cloudflare Tunnelを選ぶ理由として「集合住宅の共有回線を利用している場合など、自由にグローバルIPアドレスを使えなかったり、ルータの設定を変更できない環境もある」と書かれています（Qiita / zypr）。技術的にやってはいけないのではなく、やる権限が手元にないという話です。
会社で「若手でIT詳しそうだから」という理由でサーバーを任された人は、同じ壁に別の形で当たります。社内の境界ルーターは自分の管轄ではなく、そこに手を入れるには外部業者への依頼と、その前に上長の承認が要る。承認を取ろうにも、何を頼めばいいのかを説明する言葉が自分の中にまだない。
さらに日本の家庭・小規模オフィス回線には、構造的な事情がもう1つあります。IPoE接続で広く使われている MAP-E や DS-Lite といった方式では、グローバルIPv4アドレスを他の利用者と共有するため、自分専用のアドレスが手元にありません（IPoE 自体はIPv6の届け方の話で、その上でIPv4をどう通すかがこれらの方式です）。この場合、通常のポート開放は選択肢として成立しません。
「グローバルIP」って何？ インターネット上で自分の回線を指し示す住所です。従来のポート開放は「この住所の、この番号宛の通信をうちのサーバーに通す」という設定なので、住所が自分専用でなければ成り立ちません。
なお、自宅回線でのサーバー運用そのものをプロバイダの契約が制限しているかどうかは、事業者ごとに規定が異なります。一律に禁止されているとも、一律に自由とも言えません。長期運用を考えるなら、契約中のプロバイダの利用規約を自分で1度確認しておくのが確実です。
いずれにせよ、ここまでの障害は全部「自分では動かせないもの」の側にあります。Cloudflare Tunnel が効くのは、これらを1つも動かさずに済ませるからです。
Cloudflare Tunnel は何をしているのか
「Cloudflare Tunnel」って何？ サーバーの中で
cloudflaredという小さなプログラムを動かし、そこからCloudflareのネットワークへサーバー側から接続を張り続ける仕組みです。外から来る通信はいったんCloudflareが受け取り、その張られっぱなしの通信路を通ってサーバーに届きます。
普通の公開との違いは、通信を始める向きだけです。ポート開放は「外からの着信を受け入れる」設計で、Tunnel は「内から出ていく」設計です。公式ドキュメントでも、cloudflared が張るのは外向き（アウトバウンド）の接続だと明記されています。
この向きの違いが、そのまま次の3つの利点になります。
- 受け口を1つも開けません。 ルーターの設定を変更する必要がないため、管理画面に入れなくても構いません。ファイアウォールの着信許可も追加しません。
- グローバルIPが要りません。 サーバー側から出ていく接続だけで成立するので、IPoE環境や共有回線でも動きます。固定IPの契約も不要です。
- サーバーの実IPアドレスが表に出ません。 外から見えるのはCloudflare側だけです。この「間に挟まる」構造は、Cloudflare DNSプロキシ（オレンジ雲）で扱った仕組みと同じ考え方の上に乗っています。
VPNとどちらを選ぶか
先に線を引いておきます。Tunnel と VPN は、どちらが優れているかではなく公開範囲が違う道具です。
| Cloudflare Tunnel（本記事） | VPN / メッシュVPN | |
|---|---|---|
| 誰が使うか | 不特定多数、または社外の相手 | 自分と社内の人だけ |
| アクセス方法 | ブラウザでURLを開くだけ | 事前に各端末へ導入とログインが必要 |
| 向く対象 | 公開Webサービス、Webhookの受け口 | SSH、NAS、社内管理画面 |
| 代表例 | cloudflared | Tailscale / WireGuard |
判断はここだけで決まります。「URLを渡す相手が、事前準備なしでアクセスできる必要があるか」。必要ならTunnel、不要ならVPNです。
社内の管理画面やNASのように「自分たちしか使わない」ものは、公開せずVPNの内側に置くのが原則です。その手順は外から安全につなぐ方法（Tailscale / WireGuard）にあります。Tunnel にも社内向けのプライベート接続機能はありますが、それはVPN側の領分なので本記事では扱いません。
手順：ダッシュボードからトンネルを1本作る
⚠️ 先にお断りしておきます。Cloudflareは管理画面の構成と製品名がよく変わります。 以下は2026年8月時点で公式ドキュメントが示している流れですが、メニューの位置が違っていたら、それは記事が古いのではなく画面が動いた可能性が高いと考えて、公式ドキュメントで現在地を確認してください。
実際、2026年2月20日の公式changelogで、トンネルの管理画面がコアダッシュボード側にも追加されました。それ以前はZero Trustダッシュボードからしか触れなかったため、古い日本語記事の画面と、今あなたが見ている画面は一致しません。どちらからでも同じトンネルを管理できます。公開Webサービスが目的なら、コアダッシュボード側が素直です。
大まかな流れは4段階です。
- ダッシュボードでトンネルを作る。 ネットワーク関連のメニューからTunnelsを開き、新規作成に進みます。
- 表示されたコマンドをサーバーにコピペする。 OSごとのインストールコマンドが画面に出ます。公式のダウンロード解説にも、ダッシュボードでトンネルを作成した場合は表示されたインストールコマンドをそのままコピー＆ペーストすればよい、という趣旨の記述があります。これは略式の手順ではなく、公式が示している主経路です。
- 接続を確認する。 コマンドが通ると、ダッシュボード側でトンネルが接続済みとして見えます。
- 公開するサービスを1つ割り当てる。 公式の手順書では「Published application」として、公開したいホスト名（自分のCloudflareアカウントに登録済みのドメインのサブドメイン）と、サーバー内部のサービスのURL（
http://localhost:8000など）を指定します。
この4段階を終えると、指定したホスト名でサービスが外から見えるようになります。ルーターには一切触れていません。
用語のねじれに注意
古い記事と読み比べるときに混乱しやすい点が1つあります。Cloudflareは用語集で、この2つを区別しています。
- remotely-managed tunnel — ダッシュボードで作ったトンネル。設定はCloudflare側にあります（上記の手順はこちら）
- locally-managed tunnel — コマンドラインで作ったトンネル。設定ファイルは自分のサーバー上にあります
検索で出てくる手順書がコマンド中心で画面と噛み合わないときは、後者を前提にしている可能性があります。
動くかどうかだけ先に試したい場合
恒久的なホスト名を用意する前に、cloudflared tunnel --url で起動する Quick Tunnel という機能があります。アカウント設定なしで trycloudflare.com のランダムなURLが1つ払い出され、そこから手元のサービスに届くかを確認できます。URLは使い捨てで恒久運用には向きませんが、「そもそもこの経路が成立するのか」を数十秒で確かめる用途には向きます。
本当の境界線は「無料か有料か」ではない
「無料で使える」と聞いたとき、どこかに罠があるのではないかと身構えたなら、その警戒は正しい方向を向いています。無料のサービスに会社のインフラを寄せる判断の重さは、実際にそれを決めた本人にしか見えていないことが多いからです。
ただし、これから見る線は無料プランの外周には引かれていません。Pro や Business を払っていても、越える側は同じです。
そして一番きついのは、半年後にこう気づく展開ではないでしょうか。「自分がやっていたことは、最初から規約で止められていた」。悪意はなく、単に読んでいなかっただけで。先に境界線を見ておけば、これは避けられます。
規約に書かれていること（ここは確定です）
CloudflareのService-Specific Terms（Application Services・2026年6月2日更新）の「Content Delivery Network (Free, Pro, or Business)」の項に、次の記述があります。
“Unless you are an Enterprise customer, Cloudflare offers specific Paid Services (e.g., the Developer Platform, Images, and Stream) that you must use in order to serve video and other large files via the CDN. Cloudflare reserves the right to disable or limit your access to or use of the CDN, or to limit your End Users’ access to certain of your resources through the CDN, if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files.”
要点は2つです。
- Enterprise以外の顧客が、CDN経由で動画やその他の大容量ファイルを配信するには、Stream等の有償サービスを使う必要があるとされています。
- 有償サービスを使わずにそれをしている、あるいはしていると疑われた場合、CloudflareはCDNの利用を無効化または制限する権利を留保しています。
ここで1つ補っておきます。この条文が書いているのは “via the CDN” までで、Tunnel という語は文書中に一度も出てきません。 ただ、Tunnel で公開したサービスへの通信は構造上Cloudflareのネットワークを経由するため、この条項の射程はTunnel経由のトラフィックにも及ぶ、と読むのが自然です。少なくとも「Tunnelなら対象外」と明記した記述は見当たりません。
具体的に言えば、自宅サーバーの用途として最も人気のある構成の1つ、JellyfinやPlexを Cloudflare Tunnel で公開して家族に見せる、というやり方は、Free / Pro / Business では規約に反する構成、という読みになります。 言い方を変えれば、Cloudflareがこの条項を根拠に止められる位置に、この構成は入っています。 日本語の解説記事ではほとんど触れられていない一方、後から知って構成を作り直す羽目になる種類の情報です。
実際にどう扱われるかは、割れています（ここは不確実です）
ここは切り分けて書く必要があります。規約が存在することは公式文書で確認できますが、実際に何が起きるかは予測できません。
英語圏のフォーラム——Reddit の r/CloudFlare、r/selfhosted、それに r/JellyfinCommunity や r/PleX といったコミュニティ——を見ると、報告は両極に割れています。「何年も動画を流しているが一度も警告を受けていない」という書き込みと、「Cloudflareのサポートから警告を受けた」「アカウントを止められた」という書き込みが、どちらも見つかります。件数を数え上げたわけではないので「よくある」「めったにない」とまでは言えませんが、運用実態としての取り締まりの強さにばらつきがあること自体は、読み取れます。
ここから引き出せる結論は1つだけです。
- 「即座に止められる」とは言えません。 実際に何年も無事な人がいます。
- 「みんなやっているから大丈夫」とも言えません。 止められた人もいます。
- したがって、止められない前提で設計してはいけません。 家族が毎晩使う動画配信の経路が、ある日の判断1つで消える可能性を残したまま運用するかどうか、という選択になります。
家族に動画を見せたいだけなら、そもそも不特定多数への公開ではありません。公開せずVPNの内側に置く構成の方が、規約の境界に近づかずに済みます（Tailscale / WireGuard）。
境界を踏まない使い方
では、この条項を気にせず使える範囲はどこか。公開する中身が動画や大容量ファイルの配信でないことが条件です。この持ち込み方なら、目的にも合っています。
- 社内向けに自作した小さなWebツールや管理ダッシュボード。 外出先や別拠点から見たいが、そのためだけに社内ネットワークへ穴を開けたくない場合に向きます。
- Webhookの受け口。 外部SaaSからの通知を、自前のサーバーで受け取る用途です。外部サービス側に渡すURLが必要なので、VPNでは代替できません。
- ステータスページや、見せるためのダッシュボード。 社内の稼働状況を、URLを1本渡すだけで見せられます。作業の重さを言葉で説明するより、画面を1つ共有する方が早い場面があります。
逆に、外すべきものもはっきりしています。動画・音声・大容量ファイルの配信サービスは前述の通りです。そしてSSH・NAS・サーバーの管理画面は、そもそも公開する対象ではありません。これらはVPNの内側に置いてください。
もう1つ、後から効いてくる注意点があります。公開するホスト名は「1つのサービス専用」に保つことです。 手を広げて1本のトンネルに複数の内部サービスを紐づけていくと、どれが外に見えていてどれが見えていないのかが、時間の経過とともに自分でも分からなくなります。半年後に「公開したつもりのない管理画面が世界中から見える状態だった」と気づく事故は、この曖昧さから生まれます。
公開するものを増やすたびに、判断は1回で終わらせず記録に残してください。どこまでやれば十分かの線の引き方はセキュリティの合格ラインに、サーバー本体側の締め方はVPS初期セキュリティ設定チェックリストにまとめています。
まとめ
| 項目 | ポート開放 | Cloudflare Tunnel | VPN（Tailscale等） |
|---|---|---|---|
| ルーター設定の変更 | 必要 | 不要 | 不要 |
| グローバルIP | 必要 | 不要 | 不要 |
| 使う相手 | 不特定多数 | 不特定多数 | 自分・社内のみ |
| 相手側の事前準備 | 不要 | 不要 | 必要（導入とログイン） |
| 動画・大容量配信 | 制約なし | ⚠️ 有償サービスが必要（規約） | 制約なし |
| 向く対象 | 推奨しない | 公開Webサービス、Webhook受け口 | SSH、NAS、社内管理画面 |
ルーターの管理画面に入れないことは、能力の問題ではありません。権限の問題です。そして権限が手元にない前提で組める経路は、実際に用意されています。
利用規約を最後まで読んだことがない人がほとんどですし、それを責める話でもありません。押さえるべき線は2本だけです。公開していいのは動画・大容量ファイル以外のサービスであること。自分と社内だけが使うものは、そもそも公開しないこと。 この2つを持っていれば、今日から1本目のトンネルを作って構いません。
サーバー側のハードウェアをこれから選ぶ段階なら、用途とVM台数から決める判断軸をN100 vs N305 vs Ryzen省電力：自宅サーバー向けCPUの選び方に、機材を揃える順番を自宅サーバー（ホームラボ）の始め方にまとめています。
構成を決めきる前に「これは公開していい範囲か」を第三者の目で確かめておきたい場合は、公開範囲の切り分けについて相談するところから始められます。