Cloudflare Quick Tunnelsに、アカウント不要のメール認証が追加された

コーディングエージェントに作らせたアプリを、スマートフォンでも確認したい。そんなときの最短ルートがcloudflared tunnel --url http://localhost:5173の1行だった。数秒で返ってくるtrycloudflare.comのURLは、アカウント登録もドメインの用意もいらない。

Cloudflareが2021年に始めた無料ツール「Quick Tunnels」は、この手軽さをそのまま売りにしてきた。ただし同じ手軽さは、「そのURLを知っている人なら誰でも開ける」という弱点の裏返しでもある。2026年10月2日、Cloudflareはこの弱点に、アカウントを一切増やさずに応える機能を公式ブログで発表した。何がどこまで変わったのか。

誰でも開ける弱点は消えたか

Quick Tunnelsを一度でも使ったことがある人なら、この弱点にはもう気づいているかもしれない。URLさえ知っていれば、送った相手以外の誰でもローカルの画面を開ける。公式ブログもこの弱点をそのまま認めている。

The catch has always been the same. Anyone with the link can open it. (昔からある落とし穴は変わっていない。リンクを持っている人なら誰でも開けてしまう) — Cloudflare公式ブログ

AIエージェントが自分でコードを書き、自分でcloudflaredを起動する時代になって、この弱点はむしろ目立つようになった。2026年9月18日、Quick Tunnelsを紹介するページがHacker Newsのトップに立ち、800以上のポイントと300件超のコメントを集めている。そのスレッドであるコメントが投げた疑問を、公式ブログはそのまま引用した。

how long until someone’s agent sets up a tunnel for the world to see one’s most sensitive, private and embarrassing information or insecure work-in-progress app? (誰かのエージェントが、世界中に向けて最も触られたくない個人情報や、対策前の作業中のアプリを晒すトンネルを立ててしまうまで、あとどれくらいだろうか) — Hacker Newsのコメント（Cloudflare公式ブログが引用）

この懸念に、Cloudflareは10月2日の発表で直接答えた。

メール認証で何が変わるか

新しく加わったのは、コマンドに1つオプションを足すだけの変更だ。cloudflaredを2026年9月24日公開の2026.9.3以降に更新する（GitHub公式リリース）。すると--allowed-mailで指定したメールアドレスの持ち主だけがURLへ入れるようになる。訪問者はメールアドレスを入力し、届いたワンタイムPINを入力するだけでよい。どちらの側もCloudflareのアカウントを必要としない。

cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected]

--allowed-mailを書かなければ、これまでどおり誰でも開ける公開URLのままになる(公式ブログ)。では、Cloudflareのアカウントを一切作らせずに、どうやって「この人だけ通す」を実現しているのか。

なぜアカウントなしで絞れるのか

アクセスを絞る仕組みを作るとき、Cloudflareにはすでに「Cloudflare Access」という製品がある。公式ブログによれば、開発チームは次の2案を検討し、どちらも採らなかった(公式ブログ)。

• 既存のCloudflare Accessをそのまま前に置く案。同時に動く膨大な数の一時的なトンネルに、専用のアプリとポリシーをいちいち用意するのは現実的ではなかった
• メールでの本人確認まで含めて全部を自前で新しく作る案。「誰を通すか」を決める部分はうまくいきそうだったが、本人確認の部分でつまずいた。メールを確実に届け、不正利用を防ぎ、安全な認証の仕組みを何年も運用し続けるのは、片手間でできることではなかった

公式ブログは1つ目の案を諦めた理由を、具体的な規模感とともにこう振り返っている。

hundreds of thousands of Quick Tunnels can be running at once, many for only a few minutes, and each would need its own application and policy. With no account to own them, we would have had to invent a new namespace and route applications dynamically, just to store a list that lives for an afternoon. (同時に何十万本ものQuick Tunnelsが動いていて、多くは数分しか続かない。それぞれに専用のアプリとポリシーが要り、所有者となるアカウントもないので、午後の数時間しか生きないリストを保存するためだけに、新しい名前空間を作ってアプリを動的に割り当てる必要が出てしまう) — Cloudflare公式ブログ

自分は最初、「メール認証を追加した」と聞いて、てっきりCloudflare側のサーバーが「誰を通すか」のリストを預かるようになったのだと思っていた。実際に読むと、その予想は外れていた。Cloudflareが確認するのは「このメールアドレスの持ち主である」ことだけで、「この人を通すかどうか」を決めるのは、手元のパソコンで動くcloudflared自身だ。公式ブログはこの役割分担を次のように説明している。

Authentication proves who a visitor is. Authorization decides whether that visitor gets in… your guest list never leaves your machine. Cloudflare learns that a tunnel requires email authentication. It doesn’t learn who you invited. (認証は訪問者が誰であるかを証明する。認可はその訪問者を通すかどうかを決める。招待リストは一度もパソコンの外に出ない。Cloudflareが知るのは、あるトンネルがメール認証を必要としているという事実だけで、誰を招待したかまでは知らない) — Cloudflare公式ブログ

確認するのはCloudflare、通すかどうかを決めるのは自分のパソコン。この役割分担が分かれば、許可リストが一度もクラウドへ渡らない理由にも納得がいく。では、訪問者が実際にURLを開いてから中へ入るまで、画面の裏で何が起きているのか。

認証はどう進むか

保護されたURLを初めて開いてから、画面が表示されるまでに、裏側では次の手順が進む(公式ブログ)。

1. 訪問者が保護されたURLを開くと、cloudflaredがlogin.trycloudflare.comへ転送し、10分間だけ有効な使い捨ての合言葉(state)を発行する
2. Cloudflare Accessが、その人のメールアドレスへワンタイムPINを送って確認する
3. Workers上で動く「認証ブローカー」が、トンネルのホスト名とその合言葉に紐づく署名付きの通行証を発行する。ブラウザはこの通行証をフォームの送信で渡すので、URLや閲覧履歴、ログには残らない
4. cloudflaredが通行証の署名を検証し、記載されたメールアドレスを自分が持つ許可リストと照合する。一致すればその場でセッションを作り、訪問者を本来のページへ送る。一致しなければ、リストの中身を一切明かさない定型の応答を返す

もし裏側のサービスがメール認証モードを確認できなかった場合、cloudflaredは誤って公開URLを渡すのではなく起動自体を拒否する。保護されたトンネルが、途中で無防備な公開トンネルへ戻ることもない(公式ブログ)。ちなみにこの機能を作ったのは、プロダクト担当のHugo Vicente氏とエンジニアリング担当のAlessandro Frigerio氏という、2人のインターンだったという(公式ブログ)。ここまでは1人を許可する場合の流れだ。チーム全員や、取引先のドメイン全体に見せたいときはどうすればいいのか。

複数人やドメインを許可するには

複数人に見せたいときは、--allowed-mailを繰り返すか、カンマ区切りで並べる。会社のドメイン全体を許可したいときはワイルドカードを使う(公式ブログ、公式ドキュメント)。

cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected] \
  --allowed-mail [email protected] \
  --allowed-mail '*@example.com'

コーディングエージェントが自分でトンネルを立てる運用なら、指示書ファイル(AGENTS.mdなど)に1行書いておく方法もある。「Quick Tunnelsを始めるときは必ず--allowed-mailを付ける」と書いておけば、エージェントが作るプレビューも自分専用になる。Cloudflare Workers上で開発している場合は、npx wrangler tunnel quick-startからも同じ仕組みを呼び出せる(公式ブログ)。手軽に許可を広げられる一方で、使う前に知っておきたい制限もある。

使うときに気をつけること

メール認証に伴う制限は次のとおり(公式ブログ、公式ドキュメント)。

• セッションは最長4時間で切れる。Cloudflare Access側のサインインがそれより早く切れる場合は、そちらが優先される
• cloudflaredを止めた瞬間、全員のアクセス権が同時に失効する
• 認証はブラウザでの対話操作が前提で、プログラムが自動で叩くような非対話のクライアントには対応しない

これに加えて、Quick Tunnels自体がもとから持つ制限も残っている(公式ドキュメント)。

• 1本のトンネルが同時にさばけるリクエストは200件までで、超えると429が返る
• Server-Sent Events(SSE)には対応しない
• 稼働時間の保証はなく、ホスト名もトンネルを作り直すたびに変わる

安定したホスト名や、IDプロバイダーのグループ指定のような複雑な許可ルールが要る場面では、公式ブログも通常のCloudflare Tunnel + Accessを勧めている。自宅のMac miniで動くエージェントに、公開URLを出さずに自分のデバイスだけから双方向でつなぎたい場合は、Cloudflare Meshという選択肢もある(公式ブログ)。

まとめ

Quick Tunnelsの「リンクを知っていれば誰でも入れる」という弱点は、cloudflaredを2026.9.3以降に更新するだけで直せるようになった。コマンドへ--allowed-mailを1行加えればよい。Cloudflareのアカウントを新しく作る必要はなく、料金もこれまでのQuick Tunnelsと同じく無料だ(公式ブログ)。

できることの中心は、確認と判断を分けた設計にある。メールアドレスの持ち主であることを確認するのはCloudflareで、その人を実際に通すかどうかを決めるのは、コマンドを打った自分のパソコンだ。だから許可リストは一度もクラウドへ送られない。セッションは最長4時間、cloudflaredを止めれば全員のアクセスがすぐに切れるという制限はあるが、その場限りの共有には十分な範囲だ。次にローカルの作業を誰かに見せるときは、コマンドの最後に--allowed-mailを足すところから試せる。