10月2日、Cloudflareが「Protected Quick Tunnels: simple accountless authentication for your next dev project」と題した記事を公開した。アカウント不要のまま認証付きトンネルを1コマンドで立ち上げられる新機能「Protected Quick Tunnels」について詳しく紹介されている。
「誰でも見られる」問題をフラグ1つで解決
Quick Tunnelsは2021年にリリースされたCloudflareのツールで、cloudflared tunnel --url http://localhost:5173 の1コマンドだけでローカルの開発サーバーをランダムな trycloudflare.com のURLで外部公開できる。アカウント不要、ドメイン不要、無料というシンプルさが受け、近年はAIコーディングエージェントによる利用も急増している。
しかし従来の欠点は明快だった。そのURLを知っていれば誰でもアクセスできてしまう。cloudflared 2026.9.3から導入された --allowed-mail フラグを追加するだけで、この問題を解消できる。
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com
このコマンドを実行すると、URLを開いた訪問者はCloudflare Access（CloudflareのZero Trustアクセス管理サービス）のサインインページに誘導され、メールアドレスを入力してワンタイムPINで本人確認を行う。許可リストに一致すれば通過、それ以外はアクセスできない。開発者側もアクセス者側もCloudflareアカウントは不要だ。
複数人を許可したり、ドメイン全体を許可したりする場合はフラグを繰り返す：
cloudflared tunnel --url http://localhost:8080 \
--allowed-mail alice@example.com \
--allowed-mail bob@example.com \
--allowed-mail '*@example.com'
--allowed-mail を省略した場合は従来通りの公開トンネルとして動作し、既存の挙動は一切変わらない。
エージェント時代の「意図せず全公開」問題
この機能が登場した背景には、AIコーディングエージェントの普及がある。エージェントはビルドしたアプリをレビューしてもらうためにQuick Tunnelsを自律的に使うようになっており、その利用が急増している。
2026年9月18日にHacker NewsのQuick TunnelsページがトップにランクインしてHN上で800ポイント以上・300コメント以上を集めたとのことで、スレッドはエージェント活用の実例で溢れた。あるユーザーはAIが自分でQuick Tunnelsを見つけてサイトを公開したと報告し、別のユーザーは「エージェントを使った作業で本当に助かる」と述べた。
そしてあるコメントがこの機能の必要性を端的に表現した：
「エージェントが知らぬ間に、個人の機密情報や未完成の危険なアプリをトンネルで世界に公開するまで、あとどれくらいかかるんだろう？」
— Hacker Newsコメント
Protected Quick Tunnelsはこの懸念への直接の回答となっている。
エージェントに常時認証付きトンネルを使わせるには、AGENTS.md などのエージェント用指示ファイルに1行追加するだけでよい：
When you start a Quick Tunnel, always add --allowed-mail me@example.com.
ただしエージェントが常に指示に従うとは限らないため、cloudflared が出力するログで認証モードと適用ルール数を確認することが推奨されている（メールアドレス自体はログに出力されない）。
設計の核心：ゲストリストはあなたのマシンから出ない
アカウントなしで認証を実現するにあたって、設計上の課題は「ゲストリスト（許可メールアドレス）をどこに置くか」だった。
最初に検討されたのは、Quick Tunnelホスト名ごとにCloudflare Accessアプリケーションを立てる案。しかし同時に数十万本のトンネルが稼働し得る状況で、それぞれにアプリケーションとポリシーを動的に作成する仕組みは現実的でなかった。次に検討されたのは、cloudflared がルールを保持し、Tunnelサービスがコード送信と検証を行う案。認可ロジックは良かったが、メール配信やアビューズ対策、セッション管理、多言語対応のサインインページといった認証基盤を一から構築・運用するコストが問題だった。
最終的な設計は両者のいいとこ取りだ。
- 認証（このメールは本人のものか）: Cloudflare Accessが担当
- 認可（このメールは許可リストにあるか）:
cloudflaredがローカルでチェック
間をつなぐ仲介役として、Cloudflare Workers上にステートレスな認証ブローカーが動作する。このブローカーはトンネルのポリシーも訪問者のセッションも保存しない。結果として、Cloudflare側には「このトンネルはメール認証を使っている」という事実しか伝わらず、誰を招待したかは一切わからない。
なお、この設計はCloudflareのインターンシップ生2名——プロダクト担当のHugo VicenteとエンジニアリングのAlessandro Frigerio——が要件定義から認証ブローカー実装、cloudflared リリースまでを担当したとのことだ。
リクエストの流れ
初回アクセス時の流れは以下の通りだ：
cloudflaredがセッションのないリクエストを検知し、ブラウザをlogin.trycloudflare.comにリダイレクト（ランダムな使い捨てstate付き、有効期間10分）- Cloudflare Accessが訪問者のメールにワンタイムPINを送信・検証
- 認証ブローカーがトンネルホスト名とstateに紐づいた短期署名アサーションを発行（form POSTで渡されるためURLやブラウザ履歴に残らない）
cloudflaredがアサーションを検証し、stateを使い切り、メールを許可リストと照合。一致すればローカルセッションを作成、不一致なら汎用レスポンスを返す- 以降は最大4時間（またはCloudflare Accessのサインイン期限が先に来る場合はそれ以下）そのセッションを使用
セッションCookieにはランダム値と有効期限のみが含まれ、訪問者の身元情報は入らない。cloudflared は認証情報をアプリに転送する前に取り除くため、ローカルのアプリ側でログイン処理を実装する必要はない。
Wranglerからも使える
Workers開発者向けに、最新版の wrangler からも同じトンネルを起動できる：
npx wrangler tunnel quick-start http://localhost:8080 \
--allowed-mail alice@example.com
フラグの繰り返し指定、カンマ区切りの値、ワイルドカードドメインに対応しており、デバッグログから --allowed-mail の値は除外される。
Protected Quick TunnelsはQuick Tunnels自体と同様に無料で利用できる。cloudflared 2026.9.3以降をインストールまたはアップデートしてローカルサーバーを起動し、--allowed-mail フラグを追加するだけで使い始められる。設定の詳細や照合ルール、制限事項についてはQuick Tunnelsドキュメントを参照のこと。
詳細はProtected Quick Tunnels: simple accountless authentication for your next dev projectを参照していただきたい。
