<style>
.qt-hero{padding:clamp(25px,5vw,48px);border-radius:24px;background:linear-gradient(125deg,#10263b,#225b68 62%,#387f72);color:#fff}.qt-hero h2{color:#fff;margin:.25em 0}.qt-eyebrow{color:#b9f3de;font-size:.8rem;font-weight:800;letter-spacing:.12em}.qt-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:22px 0}.qt-card{padding:17px;border:1px solid #bedbd4;border-radius:15px;background:#f1faf7}.qt-card strong{display:block;color:#176b59;font-size:1.1rem}.qt-flow{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:9px;margin:22px 0}.qt-step{padding:16px;border-radius:14px;background:#eaf4f4;border:1px solid #b8d6d4}.qt-step b{display:block;color:#17645e}.qt-table{overflow-x:auto;margin:20px 0}.qt-table table{border-collapse:collapse;min-width:650px;width:100%}.qt-table th,.qt-table td{padding:11px;border:1px solid #c4d7d5;text-align:left;vertical-align:top}.qt-table th{background:#e5f3ee}.qt-note{padding:16px 19px;border-left:5px solid #d6903b;border-radius:10px;background:#fff7e9;margin:20px 0}@media(max-width:760px){.qt-grid,.qt-flow{grid-template-columns:1fr 1fr}}@media(max-width:520px){.qt-grid,.qt-flow{grid-template-columns:1fr}}
</style>
SECURITY / DEVELOPER WORKFLOW
ローカルのデモを、招待した人だけに
開発中の画面を一時URLで共有するQuick Tunnel。従来はURLを知る人ならアクセスできたが、新しいメール認証はブラウザーでの本人確認を入り口に置ける。
3行で要約
- Cloudflareは2026年10月2日、Quick Tunnelにメール認証を追加したと発表した。
cloudflared 2026.9.3以降で --allowed-mail を指定する。[1][2]
- 訪問者はワンタイムPINでメール所有を証明し、ローカルの
cloudflared が許可リストと照合する。Cloudflareアカウントは公開側・閲覧側とも不要だ。[1]
- 開発・テスト用の機能であり、本番運用や非対話API向けの認証基盤には置き換えられない。[3]
背景：共有しやすさと公開範囲が同じだった
Quick TunnelはローカルのHTTPサービスに一時的な trycloudflare.com のURLを発行する。従来の cloudflared tunnel --url http://localhost:8080 は導入が簡単な反面、URLを入手した人ならアクセスできる。プレビューURLがチャットやログに残る開発フローでは、URLを秘密として扱うだけでは十分とは限らない。[1][3]
何が新しいのか
10月2日の発表で、許可メールアドレスをコマンド引数に渡せるようになった。Cloudflareの説明では、未指定時のQuick Tunnelは従来どおり公開動作を維持する。保護を使う場合はトンネル作成時に認証モードが確認できなければ起動せず、意図せず公開モードへフォールバックしない設計だ。[1]
設定は1フラグ許可するメールアドレスまたはドメインを指定
認証はPINCloudflare Accessがメール所有を検証
判定は手元許可リストはローカルのcloudflaredで照合
技術的なポイント：認証と認可を分ける
Cloudflareの実装説明では、Accessが「そのメールを使える人か」を確認し、署名付きの短寿命アサーションをブラウザー経由で返す。一方、「招待された人か」という認可は手元の cloudflared がメモリー上の許可リストで決める。Cloudflareによると、招待リストはトンネルのサービス側へ送信しない。これは提供元が説明する設計上の性質であり、独立監査の結果ではない。[1]
1 訪問一時URLをブラウザーで開く
2 本人確認AccessがメールへPINを送る
3 許可判定cloudflaredが許可リストと照合
4 ローカルへ許可された通信だけを転送
同社の説明では、認証後のローカルセッションは最大4時間で、cloudflared を停止すればアクセスも終了する。認証情報はローカルアプリへそのまま転送しない。[1]
開発者・企業への影響
デザイナーやレビュー担当者への一時的な画面共有では、URLの拡散だけで誰もが閲覧できる状態を避けやすくなる。編集上の判断として、AIエージェントが開発サーバーを自動公開するワークフローでも、起動コマンドに許可先を明示し、実際のコマンドとログを人が確認する運用が有効だ。ただし、メールを受け取れることは組織の権限管理やアプリ内部の認可を代替しない。
用途別の選び方| 用途 | 選択肢 | 理由 |
|---|
| 短時間の公開デモ | 通常のQuick Tunnel | 誰でも見てよい内容に限定 |
| 招待者だけのブラウザー確認 | 保護付きQuick Tunnel | メールPINと許可リストを追加 |
| 安定URL・本番・細かな権限 | 正式なCloudflare TunnelとAccess | Quick Tunnelは開発用で稼働保証なし |
導入手順：まず1人だけ許可する
cloudflared を2026.9.3以降へ更新し、ローカルのHTTPサーバーを起動する。[1][3]- 次のコマンドを実行し、表示されたURLを許可した相手へ共有する。
cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]
- 別ブラウザーでアクセスし、PIN入力後に許可先だけが開けることを確かめる。複数人は
--allowed-mail を繰り返し、ドメイン全体なら --allowed-mail '*@example.com' と指定できる。ワイルドカードはシェル展開を避けるため引用符で囲む。[3]
- 許可先を変える場合はプロセスを停止して起動し直す。作業終了時も停止し、一時URLを失効させる。[3]
リスクと限界
「メール認証付き」でも本番サービスではない。公式ドキュメントはQuick Tunnelをテスト・開発用途とし、稼働保証なし、同時処理中リクエストは最大200件、超過時は429、SSE非対応と記載している。メール認証は対話的なブラウザーセッションが必要で、機械間通信には使えない。[3]
- 許可ドメインの指定はそのドメイン内の全メール利用者に範囲を広げる。個別アドレスで足りるなら、広いワイルドカードを避ける。
- アプリ内部の脆弱性や公開してはいけないデータの混入は、入り口の認証だけでは解決しない。共有前にダミーデータとローカル環境変数を点検する。
- ホスト名はトンネルを作り直すたび変わる。固定URLやIdPグループなどの高度なルールが必要なら正式なTunnelとAccessを使う。[1][3]
今後注目すべき点
実務では、エージェントや開発スクリプトが --allowed-mail を確実に付けているか、プレビューの終了時にプロセスを停止しているかを確認したい。現時点で確認できるのはCloudflareの発表とドキュメント上の仕様であり、組織への導入前には対象の cloudflared バージョンで認証成功・拒否の両方を試すのが妥当だ。
最終確認日：2026年10月4日（日本時間）
参照元
- Cloudflare Blog：Protected Quick Tunnels（2026年10月2日）
- Cloudflare Changelog：メール認証の追加（2026年10月2日）
- Cloudflare Docs：Quick Tunnelsの手順と制約