ローカルで動かしている Web サービスを、すぐ外部に見せたい場面は意外と多い。社内レビューでも、Webhook の受け口を試すときでも、AI エージェントに実際の URL を渡したいときでも、いちいち本番環境を用意するのは重い。Cloudflare が公開した Quick Tunnels は、その面倒をかなり雑に、しかも短時間で片づけるための仕組みだ。この記事では、ローカルの localhost をどうやって公開 URL に変えるのかを整理したうえで、これが開発の現場に何を持ち込むのかを見ていきたい。
Cloudflare の Quick Tunnels は、ローカルで動くサーバーを、Cloudflare の edge 上にある公開 URL に変換するサービスだ。ページの説明では「Localhost, meet the Internet.」という言い方で、手元のサーバーをそのままインターネットに接続する道具だと位置づけている。使い方はかなり単純で、cloudflared tunnel --url http://localhost:8000 を実行するだけで、手元の Web サーバーが外からアクセスできる URL に紐づく。
Cloudflare はこれを「No account. No DNS. No open ports.」と強調している。つまり、アカウント登録も DNS 設定も不要で、ルーター側でポート開放する必要もない。公開に見えて、実際には outbound-only、つまりマシンから Cloudflare へ外向きの接続だけを張る形になっている。外から来た通信は Cloudflare のネットワークを通って自分のマシンへ戻ってくるため、TLS で暗号化され、DDoS フィルタもかかる。
サイト上では「335+ CITIES」「~3S TO URL」「0 PORTS OPENED」「FREE」といった数字も出していて、URL が素早く発行されること、公開に伴うポート解放が発生しないこと、そして無料で使えることを押し出している。
もう一つの特徴は、これがエージェント時代向けだと明言している点だ。Cloudflare は、Quick Tunnel が coding agents のループに向くと説明していて、スクリーンショットサービス、Webhook、eval harness、あるいは人間がクリックして確かめるための公開先として使えるとしている。さらに、stdout に hostname、edge、health を JSON で出力できるので、ログを正規表現でこじ開けなくてよいとも書いている。
導入手順は macOS、Windows、Linux に分かれているが、流れ自体は共通だ。まず cloudflared をパッケージマネージャーか GitHub releases から入れる。ログインは不要。次に手元のアプリを起動し、最後に tunnel コマンドを実行する。すると証明書、routing、DDoS protection は Cloudflare 側で処理され、生成された URL をチームメイトや Webhook、agent にそのまま渡せる。トンネルはプロセスと一緒に消えるので、後始末もいらない、という設計になっている。
Quick Tunnels の面白さは、派手な新機能ではなく、地味な摩擦を片っ端から削っているところにあると思う。ローカル開発で本当に面倒なのは、サーバーを立てることそのものではない。外に見せる瞬間に、DNS、証明書、ポート開放、プロキシ、期限切れ、片づけ、そうした雑務が一気に乗ってくる。Cloudflare はそこを「1 コマンド」「数秒」「無料」で飛び越えようとしている。これは開発者の気分を良くするためというより、試す回数を増やすための設計だろう。
特に効いているのは、エージェント向けの使い方を前面に出している点だ。AI エージェントや自動化ツールは、説明文だけでは動かない。実際の URL が必要で、Webhook の戻り先も必要で、スクリーンショットを撮る対象も必要だ。Quick Tunnels は、その「とりあえず触れる公開先」を即席で作る。人間がレビューするにも都合がいいし、機械同士をつなぐ中継点としても扱いやすい。ここは単なる tunnel サービスではなく、開発フローの接着剤を狙っているように見える。
一方で、こういう仕組みは便利であるほど雑に使われやすい。トンネルはプロセスが終われば消える、というのは安全側の設計ではある。でも実際の現場では、「消えるから大丈夫」と思って、認証のないテスト画面やデバッグ用のエンドポイントを安易に外へ出してしまうことがある。Quick Tunnels 自体が危ないというより、公開のハードルを下げると、公開してよいものと駄目なものの境目も薄くなる。ここは使う側のルール作りが必要だと思う。
さらに、Cloudflare の edge を経由する以上、通信の入口と出口を Cloudflare に預ける構図になる。説明上は encrypted で、DDoS filtered で、inbound port も開かないので安心感はある。ただ、企業の内部ツールや機微なデータを扱う検証環境では、「便利だから使う」で終わらせるには少し軽い。誰がその URL を知っているのか、どのくらいの時間だけ有効なのか、ログはどこに残るのか。こうした運用の話を詰めないと、開発スピードは上がっても、後から確認に追われる可能性がある。
Quick Tunnels がいちばん刺さりそうなのは、Webhook を受ける開発や CI の検証だと思う。Stripe や GitHub のような外部サービスは、ローカルの localhost には飛んでこない。そこで毎回ダミーの環境を用意するより、cloudflared tunnel --url ... でその場に実在する URL を出したほうが早い。しかも Cloudflare は「Any framework, any port」と言っているので、特定のフレームワークに寄らない。Node でも Python でも Go でも、ローカルで動いていればつなげる。
この「実在する URL」があるだけで、テストの質は少し変わる。フィクスチャだけでは見えない、実際の callback の流れや、ブラウザからのアクセス、外部サービスからの再送、失敗時の挙動をそのまま確認しやすくなるからだ。とくに agent や自動化の文脈では、URL がないと始まらない。Quick Tunnels はそこを埋めるので、開発者の手作業を減らすだけでなく、機械が機械を呼ぶ流れを作りやすくする。
ただ、これはあくまで「今動いているものをすぐ見せる」道具であって、長期運用の公開基盤ではない。説明でも ephemeral by design とされていて、トンネルはプロセスと一緒に死ぬ。つまり、恒久的な公開 URL を管理したいなら別の仕組みが必要になる。そこを取り違えると、短期の便利さに引きずられて、本来は staging や正式な tunnel 設定が要る場面まで Quick Tunnels で済ませてしまいかねない。
それでも、この割り切りはかなり筋がいいと思う。長期運用の仕組みは重くて当然だし、短期の共有は軽くてよい。Cloudflare はその境界をはっきり分け、前者ではなく後者に徹している。だからこそ、ローカル開発の「ちょっと見せたい」「今だけつなぎたい」を、ためらいなく外へ出せる。試作、CI、Webhook、エージェント実行。このあたりの作業が多い人ほど、Quick Tunnels の価値は分かりやすいはずだ。
