Cloudflare Tunnel は、ローカルサーバーや社内向けツールを外部から確認できるようにしたいときに便利な選択肢です。私の会社でも、まだルーター側でポートフォワーディングして使うケースがありますし、最近 Microsoft Teams 開発では Microsoft が提供する Dev Tunnels でローカルの Bot サーバーを公開したこともあります。どちらも目の前の問題は解決できますが、繰り返し使うと役割の違いが見えてきます。
私が Cloudflare Tunnel を良いと思った理由はシンプルです。サーバーがインターネットから直接 inbound 接続を受けるのではなく、cloudflared が Cloudflare 側に outbound 接続を作り、その経路でリクエストが入ってきます。origin IP を直接見せず、ルーター設定も毎回変えなくて済みます。
関連記事
要約
Cloudflare Tunnel は cloudflared クライアントを通じて、自分のサーバーと Cloudflare ネットワークの間にトンネルを作る仕組みです。ポートフォワーディングなしで使え、独自ドメインと組み合わせると開発サーバーや内部ツールを固定 URL で共有できます。Microsoft Teams 開発で使う Dev Tunnels は Teams/Bot のローカルデバッグには便利ですが、社内共通ドメインやアクセス制御まで考えると Cloudflare Tunnel の方が運用寄りに感じます。
この記事の内容
この記事で扱うこと
Cloudflare Tunnel とは何か
Cloudflare の説明を短くまとめると、Cloudflare Tunnel は公開 IP なしで自分のリソースを Cloudflare に安全に接続する方法です。中心になるのは cloudflared で、ローカルマシンやサーバー上で動き、Cloudflare のグローバルネットワークに outbound 接続を作ります。
ユーザー → Cloudflare → Tunnel → ローカル/サーバー上のサービスorigin サーバー側から見ると、公開ポートに直接アクセスが来るわけではありません。すでに作られたトンネルを通してリクエストを受けます。HTTP サービス、SSH、RDP、Zero Trust の private access にも使えますが、ここでは開発者がよく使う「ローカル Web サービスや内部ツールをドメインで見せる」観点で整理します。
既存方式との比較
| 方式 | 良い点 | 気になる点 | 向いている場面 |
|---|---|---|---|
| ポートフォワーディング | 直接つなげられて分かりやすい | ルーター/Firewall 設定、origin IP 露出の可能性 | 個人サーバーの単純運用 |
| VPN | 内部ネットワーク全体へのアクセスに強い | 外部共有やデモには重い | 社内ネットワーク、運用者アクセス |
| ngrok 系トンネル | 短時間の共有が速い | 料金/制限、固定 URL、長期運用性 | 短いデモ、Webhook テスト |
| Microsoft Dev Tunnels | Teams/Bot のローカルデバッグに合う | 汎用的な社内ドメインや共通アクセス制御には弱い | Teams アプリ、Bot Framework、ローカルデバッグ |
| Cloudflare Tunnel | ポート開放なし、独自ドメイン、Cloudflare のセキュリティ連携 | Cloudflare、DNS、Zero Trust の理解が必要 | 開発サーバー共有、内部ツール、アクセス制御 |
Microsoft Dev Tunnels との比較
Microsoft Teams 開発では Microsoft Dev Tunnels が自然でした。Teams アプリや Bot をローカルでデバッグするときは外部 HTTPS endpoint が必要で、Microsoft の文書でも devtunnel host -p 3978 --protocol http --allow-anonymous のような流れが案内されています。
ただ、私の感覚では Dev Tunnels は Microsoft 開発フローの中でローカルデバッグを楽にする道具です。Teams、Bot Framework、Visual Studio、Agents Toolkit の流れでは強い。一方で、社内の複数ツール、独自ドメイン、アクセス制御、長期運用まで考えると Cloudflare Tunnel の方が汎用的です。
| 項目 | Microsoft Dev Tunnels | Cloudflare Tunnel |
|---|---|---|
| 主な用途 | Microsoft 系のローカル開発/デバッグ | ローカル/サーバーサービスを Cloudflare に接続 |
| Teams 開発 | かなり合う | 可能だが Teams 専用ではない |
| ドメイン運用 | devtunnels.ms の開発 URL 中心 |
独自ドメインと DNS route が自然 |
| アクセス制御 | トンネル設定と Microsoft アカウント中心 | Cloudflare Access、SSO、メール、ポリシー |
| 長期運用 | 開発用の性格が強い | サービス化、複数 connector、Zero Trust 構成 |
実務では何がよく使われるか
実務では一つの方式だけに統一されていることは少ないです。古い環境ではポートフォワーディングが残っています。単純で慣れているからです。開発段階では ngrok や Microsoft Dev Tunnels のような一時的なトンネルが、Webhook テスト、Teams Bot デバッグ、モバイルアプリの callback テストによく合います。
ただし運用に近づくほど基準は変わります。URL が毎回変わると困りますし、誰がアクセスできるかをポリシーで管理したくなります。ここでは Cloudflare Tunnel、VPN、クラウドロードバランサー、Zero Trust アクセス制御を並べて検討する方が自然です。
基本的な利用の流れ
ローカル管理型トンネルの流れは、Cloudflare にドメインを追加し、cloudflared をインストールし、ログイン、トンネル作成、設定ファイル作成、DNS route、実行という順番です。
brew install cloudflared
cloudflared tunnel login
cloudflared tunnel create my-dev-tunnel
cloudflared tunnel listtunnel: <Tunnel-UUID>
credentials-file: /Users/me/.cloudflared/<Tunnel-UUID>.json
ingress:
- hostname: dev.example.com
service: http://localhost:8000
- service: http_status:404cloudflared tunnel route dns my-dev-tunnel dev.example.com
cloudflared tunnel run my-dev-tunnel継続的に使うなら、ターミナルで動かしっぱなしにするより service や launch agent として登録する方が安全です。
使ってみて良かった点
一番良いのは、ルーターや Firewall を毎回触らなくてよいことです。小さな Web ツール、管理画面、テスト API を外部から確認したいとき、ネットワーク設定に時間を取られにくくなります。
また、固定ドメインを使いやすい点も大きいです。URL が毎回変わると文書や Webhook 設定を直す必要がありますが、dev.example.com のような URL なら説明もしやすいです。
セキュリティとベストプラクティス
Cloudflare Tunnel を使えば自動的に安全、というわけではありません。大事なのは、どのサービスを誰に開けているかです。
| 項目 | 推奨 | 理由 |
|---|---|---|
| 公開範囲 | 開発サーバーでも基本は認証の後ろに置く | URL を知っているだけで入れる状態を避ける |
| アクセス制御 | Cloudflare Access でメール/SSO/OTP を使う | 社内ツールはユーザー単位の制御が必要 |
| 認証情報 | credentials file と tunnel token を secret として扱う | 流出すると意図しない connector が接続できる |
| 実行方式 | 長期利用は service/launch agent 化する | 再起動後の抜け漏れを減らす |
| ingress | 最後に http_status:404 を置く |
想定外の公開を減らす |
「開発サーバーだから大丈夫」と考えるのが一番危ないです。開発サーバーにもテストアカウント、内部 API の応答、サンプルデータ、管理画面が混ざることがあります。
最初に迷った点
トンネルを作ることと、サービスを外部に公開することは同じではありません。トンネル作成は UUID と credentials を作る段階で、実際にどの hostname をどの service に向けるかは DNS route と ingress で決まります。
cloudflared tunnel list
cloudflared tunnel info my-dev-tunnel
cloudflared tunnel run my-dev-tunnel向いている場面
- ローカル開発サーバーを外部の人に見せたいとき
- Webhook テスト用の固定 URL が必要なとき
- ルーターのポートフォワーディングを避けたいとき
- 社内管理ツールを Cloudflare Access の後ろに置きたいとき
- origin IP の直接露出を減らしたいとき
まとめ
Cloudflare Tunnel は、ポートフォワーディングなしで開発サーバーや内部サービスを外部から確認したいときに現実的な選択肢です。私の会社のようにポートフォワーディングが残っていて、特定の開発では Microsoft Dev Tunnels も使う環境なら、役割を分けて考える価値があります。
万能ではありません。Cloudflare 依存はありますし、DNS と Zero Trust の理解も必要です。それでも、一度構造を理解しておくと、開発中の外部共有や内部ツール公開の面倒をかなり減らせます。
参考文献
- Cloudflare Tunnel documentation
- Create a locally-managed tunnel
- Microsoft Dev Tunnels overview
- Debug Teams apps locally