Cloudflare Tunnelの始め方｜社内Webアプリへの接続とAccess認証

Cloudflare Tunnelで社内Webを使う場合は、Tunnelによる接続と、Accessによる利用者認証を組み合わせます。 Tunnelだけで公開ホスト名を作ると、社内の画面をインターネットへ公開してしまうことがあります。

この記事では、ブラウザーでアクセスする一つの社内Webアプリを、公開ホスト名とAccessで保護する構成を扱います。社内ネットワーク全体へのVPN接続や、SSH・RDPのクライアント設定は対象に含めません。公式：Accessで公開ホスト名のアプリを保護する

TunnelとAccessの役割を分ける

Tunnelでは、社内側のサーバーで動く cloudflared がCloudflareへ外向きの接続を作ります。この経路を通して、Cloudflareから社内のWebアプリへ通信を届けます。公式：Tunnelの仕組み

構成要素	役割	導入時の確認
利用者のブラウザー	公開ホスト名へアクセスする	正しい会社のアカウントでログインする
Cloudflare Access	利用者を認証し、ポリシーで判定する	許可対象とセッション期間を決める
Cloudflare Tunnel	社内側との通信経路を作る	コネクターの状態と接続先を確認する
社内Webアプリ	業務画面・APIを提供する	アプリ内部の権限や操作履歴を確認する

Accessへ入れた人全員に、アプリ内の管理操作まで許可してよいとは限りません。アプリ独自のログインや部門別権限がある場合は、それも維持します。

最初に、一つのアプリと検証用ホスト名を決める

用意するものは、Cloudflareアカウント、Cloudflareで有効なドメイン、cloudflared を動かすサーバー、接続するWebアプリ、利用者を認証する方法です。契約プランと利用人数の条件も確認します。

構成例では、公開ホスト名を internal.example.com、社内アプリを http://localhost:8080 とします。これは説明用です。実際のドメインやポートは、対象アプリに合わせて変更します。

localhost はcloudflaredが動く環境自身を指します。別サーバーや別コンテナにアプリがある場合は、その環境から到達できるサービス名・IP・ポートを指定しなければなりません。ブラウザーから見えたという理由だけで、コネクターからも届くとは判断しないでください。

先にAccessアプリと許可ルールを作る

公式は、Tunnelの公開経路を設定する前にAccessアプリを作ることを勧めています。認証がない時間を作らないため、社内アプリではこの順序を守ります。

1. CloudflareのZero Trustから、AccessのApplicationsへ進む。
2. 自社で管理するアプリの設定を作り、保護する公開ホスト名を登録する。
3. 認証元を選び、最初は検証担当者など少数の利用者へAllowポリシーを限定する。
4. セッション期間と必要な認証条件を決める。
5. 設定対象が想定のホスト名・パスを覆っているか確認する。

画面上の分類名は更新されるため、現行のAccess作成手順を併用してください。検証を通すために広いBypassルールを残す、全メールアドレスを許可するといった設定は、当初の利用者範囲を壊してしまいます。

Tunnelを作成し、コネクターを起動する

CloudflareダッシュボードのNetworking→Tunnelsで名前を付け、配置先のOS・構成に合う手順を選びます。画面に表示されたインストール・起動手順を、検証用サーバーで実行します。公式：Tunnelの開始手順

トンネルのトークンは、コネクターが接続するための秘密情報です。記事、共有メモ、リポジトリ、スクリーンショットへ値を残さないようにします。トークンを指定したコマンドを使う場合は、端末履歴やログの扱いも管理してください。

起動後はダッシュボードでHealthyなどの状態を確認します。ただし、HealthyはCloudflareとの接続状態を示すもので、社内アプリの正常動作まで保証しません。

続いて公開ホスト名を、アプリの接続先へ対応させます。接続先がHTTPSなら証明書とホスト名を確認します。証明書エラーを理由に検証を恒久的に無効化するのではなく、正しい証明書・名前・信頼設定を整えます。

Accessの検証と、別経路からのアクセスを確認する

公式のAccess手順では、発行されたアプリケーショントークンの検証も必要とされています。Tunnel側の「Protect with Access」で検証する方法、またはアプリ側で検証する方法を、現行の構成に合わせて選びます。公式：Accessトークンの検証

認証付きURLから開けることに加え、認証を通らない別URL・IP・ポートから入れないことを確かめます。

元アプリをすでに外部公開している場合、その公開経路が残っていないか調べます。Cloudflare側だけを保護しても、元サーバーへ直接アクセスできれば迂回になります。既存利用者への影響を確認しながら、公開範囲やネットワーク設定を整理します。

許可・拒否・障害の三つを試す

試す条件	期待する結果
未ログインでURLを開く	認証なしでアプリ本文が見えない
許可された利用者	ログイン後に対象アプリを使える
許可していない利用者	アプリへ到達できない
アプリ内で権限の違う利用者	管理機能などの範囲が適切に制限される
cloudflaredを停止	接続できなくなり、担当者が状態を識別できる
アプリだけを停止	トンネルとアプリの障害を区別できる
利用者の権限を外す	セッション失効を含む運用後にアクセスできない

「403が出た」という結果も、どの段階で拒否されたかを記録します。Accessのポリシーなのか、アプリ側の認可なのかで修正箇所が変わります。ログへ個人情報やトークンをそのまま残さず、日時・対象・処理IDなど、調査に必要な情報を選びます。

運用開始後は、停止と失効の担当を決める

サーバー再起動時の自動起動、コネクター更新、接続状態の確認、アプリの障害連絡を担当者へ引き継ぎます。業務上の可用性が必要なら、コネクターやアプリの冗長化を別途検討します。

退職や委託終了では、認証元のアカウントだけでなく、Accessのルールと既存セッションを確認します。トンネルトークンが漏れた場合は、利用者の退職処理とは別にトークンの失効・更新とコネクターの再設定が必要です。

試行を終了する場合は、利用者への案内、経路の停止、専用DNSレコードとトンネル、残すログの扱いを整理します。ほかのアプリで使う共有経路を誤って止めないよう、最初の台帳に対象を記録しておきます。

よくある質問

Tunnelを作ればVPNが完全に不要になりますか？

用途によります。この記事は一つのHTTPアプリをAccessで保護する方法です。社内ネットワーク全体、非HTTP通信、端末条件が必要な場合は別の設計を確認します。

Quick Tunnelを社内の恒久運用に使えますか？

開発用の一時的な公開と、会社が管理する固定ホスト名・認証・運用を分けて考えます。継続利用では管理対象と復旧手順が明確な構成を選びます。

Healthyなのにアプリが開かないときは？

cloudflaredから見た接続先、ポート、HTTP／HTTPS、証明書、アプリ自体の状態を確認します。認証で止まる場合はAccessのログとポリシーも照合してください。

次に読む記事

• Cloudflare DNSの設定と切り替え確認
• Cloudflare OSの導入方法と利用者・接続先の設計
• AI Searchを社内文書検索に使う

公式情報の確認日：2026年10月22日。実アカウントでのTunnel作成・疎通試験を実施した報告ではなく、公式手順と運用上の確認点を整理した解説です。