Cloudflare Accessで開発中のWebアプリとモバイルAPIを自分だけに公開する

この記事はAIで生成した文章をもとに、筆者が内容を修正・確認したうえで公開しています。

開発中のWebアプリやスマートフォンアプリのAPIを実際のサーバーで動かしたいものの、まだ他人には使われたくない場面があります。

Cloudflare Zero Trustの Cloudflare Access を使うと、アプリの手前に認証を追加できます。開発環境に入れる人を制限するために、アプリ側へ新しいログイン画面を実装する必要はありません。

この記事では、Webアプリはメールで届くワンタイムコードで、モバイルアプリのAPIはCloudflare One Clientで認証する構成と、その主要な設定を紹介します。

設定項目は、2026年10月12日に確認した公式ドキュメントと、同日に撮影したCloudflareの管理画面に基づき、項目名は公式資料の英語名を基本とします。

構成の概念図。WorkersはWorker単位の保護、AWS・VPSなどはプロキシやTunnelを組み合わせます。

Accessの仕組みと対象

Accessは、リクエストがアプリに届く前に、アクセスを許可するかどうかを判定します。判定には「このメールアドレスのユーザーだけ許可する」といったルールを使います。許可されていないアクセスは、アプリの手前でログインを求められるか、拒否されます。

アプリの設置先はWorkersに限りません。

アプリの設置先	Accessを通す方法
Cloudflare Workers	WorkerにAccessを設定、または公開ホスト名をAccessで保護
AWS上のWebサーバー	Cloudflareのプロキシ、またはCloudflare Tunnelを利用
VPS・自宅サーバー	Cloudflareのプロキシ、またはCloudflare Tunnelを利用

前提は、保護したいWeb・API通信がCloudflare Accessを通ることです。Cloudflareにドメインを登録しただけでは保護されません。また、AWSのあらゆるサービスを一括で保護する機能でもありません。この記事では、HTTP/HTTPSで通信するWebアプリとAPIを対象にします。

なお、自分だけに公開するといっても、公開ホスト名やAccessのログイン画面がインターネットから見えなくなるわけではありません。今回の目的は、認証していない人にアプリの中身やAPIを使わせないことです。

Webアプリのメール認証

ブラウザで使うWebアプリなら、Accessの One-time PIN（OTP）が手軽です。

利用者は、保護されたURLを開いてメールアドレスを入力します。許可されたアドレスにコードが届くので、そのコードで認証するとアプリを開けます。

1. One-time PINを追加する

CloudflareのダッシュボードでZero Trustの初期設定を済ませ、次の順に開きます。

1. Zero Trust → Integrations（インテグレーション）→ Identity providers（ID プロバイダー）を開く。
2. 一覧に One-time PIN があるか確認する。
3. ない場合は Add new identity provider（ID プロバイダーを追加する）から One-time PIN を追加する。

OTPが初期状態で使えるとは限らないため、設定済みかを一覧で確認してください。あわせて、対象のAccessアプリでも、ログイン方法としてOne-time PINを選びます。

One-time PINが登録済みの画面。

公式：One-time PIN login

2. 自分だけを許可するポリシーを作る

Zero Trust → Access controls（Access コントロール）→ Policies（ポリシー）を開き、Add a policy（ポリシーを追加する）を選びます。複数のアプリで再利用できるポリシーを、例えば次のように設定します。

項目	設定例
名前	Only Me
Action（アクション）	Allow（許可）
Rule type	Include（含める）
Selector（セレクター）	Emails（メール）
Value	you@example.com（自分のメールアドレス）

OTPを認証方法として有効にする設定と、誰を許可するかの設定は別です。Include に「One-time PINでログインした人」という条件だけを設定すると、コードを受け取れるメールアドレスを持つ人なら誰でも認証できてしまい、自分だけには限定できません。

自分専用にするなら、メールアドレスそのものを指定します。そのうえで、広い範囲を許可するAllowポリシーや、認証を省略するBypassポリシーがほかに残っていないか確認します。

保存しただけではアプリは保護されないため、次の手順で対象アプリに関連付けます。

公式：Common Access policies

3. 保護するアプリを指定する

Workersの場合

Workers & Pages で対象Workerを選び、Access タブを開きます。

1. Worker単位の保護を開始するボタンを選択する。撮影した画面では Worker Access の「アクセスを有効化」、公式資料では Protect this Worker behind Access と表記されています。
2. 保護範囲（スコープ）を All traffic（すべての Traffic）にする。
3. Authentication policy（認証ポリシー）の「ポリシーを追加」から、自分だけを許可するポリシーを指定する。
4. Apply Access（Access を適用）で適用する。

ここから自分だけを許可するポリシーを追加して適用します。

Previews only を選ぶと、保護されるのはプレビューだけです。開発中のWorker全体を保護したい場合は All traffic を選びます。All traffic では、対象Workerのカスタムドメイン、ルート、workers.dev、プレビューがまとめて保護されます。

複数の設定が一致する場合は ホスト名ポリシー → Workerポリシー → アカウントポリシー の順で優先されると表示されます。 既存のホスト名ポリシーがある場合は、その許可条件も確認してください。All traffic を選ぶだけで既存のホスト名ポリシーが置き換わるわけではありません。

また、確認時点ではWorker単位のAccessはWebSocketに対応していません。WebSocketを使う場合はホスト名単位でAccessを設定し、保護対象外のURLを無効にするか、別途保護してください。

公式：Cloudflare Access for Workers

AWS・VPSなどの場合

Zero Trust → Access controls → Applications でアプリを作成します。Self-hosted系のアプリを選び、保護する公開ホスト名（例：dev.example.com）と、先ほど作ったポリシーを設定します。

次に、そのホスト名をプロキシまたはTunnel経由でサーバーにつなぎます。Tunnelを使う場合は、Accessアプリを先に作成してから公開ルートを設定すると、作業の途中で認証なしにアプリが公開される状態を避けられます。

DNS、Tunnelの作成、サーバー側の設定は設置先によって異なるため、以下の公式手順を参照してください。接続できたら終わりではなく、後述の「Accessを迂回する入口」の対策まで行います。

公式：Publish a self-hosted application to the Internet

モバイルAPIのOne Client認証

iOS・AndroidアプリがAPIを呼んだときに、Webと同じOTPのログイン画面が返ってきても、アプリはそれをそのままでは処理できません。また、ブラウザでログインしても、ネイティブアプリの通信まで認証済みになるとは限りません。

自分の端末で開発・確認する用途なら、Cloudflare One Clientにログインし、その端末の認証セッションをAccessで使う方法があります。対象のAPI通信をOne Client経由にすれば、アプリにAccess専用のログイン処理を追加せずにAPIを呼べます。

1. 端末を登録できるユーザーを自分に限定する

Zero Trustの Team & Resources（チームとリソース）→ Devices（デバイス）→ Management（管理）を開きます。「デバイス登録権限」の「管理」から、端末登録ポリシーを設定します。

「デバイス登録権限」の「管理」を開き、自分だけを許可するポリシーを関連付けます。

「既存のポリシーを追加」または「新しいポリシーを作成」から、Allow・Include・Emails で自分のメールアドレスだけを許可するポリシーを設定して保存します。ほかのユーザーを許可する端末登録ポリシーが残っていないことも確認してください。

「新しいポリシーを作成」から開いた入力画面。Allow は「許可」、Include は「含める」、Emails は「メール」です。撮影用の未保存の例なので、you@example.com を自分のアドレスに置き換えて保存し、端末登録ポリシーに関連付けます。

続いて、端末登録設定の Login methods タブを開き、認証方法として One-time PIN を有効にして保存します。組織にOne-time PINを追加し、Webアプリで有効にしていても、端末登録で使うログイン方法は別に確認が必要です。

この設定で決まるのは、組織に端末を登録できる人だけです。APIを保護するAccessポリシーでも、別途自分だけを許可する必要があります。

公式：Device enrollment permissions

2. AccessでOne Client認証を有効にする

1. Access controls（Access コントロール）→ Access settings（Access 設定）を開き、Authenticate with Cloudflare One Client を有効にする。撮影した日本語画面では「Cloudflare One Client 認証」内の「Cloudflare One Client セッションを使用した認証を有効にする」です。
2. 認証セッションの有効期間を設定する。
3. 対象のAccessアプリの認証設定でも、同じ機能を有効にする。

この機能は確認時点ではBetaで、AllowまたはBlockポリシーを設定したアプリが対象です。また、Accessの Binding Cookie とは併用できません。

One Client認証の設定画面。「すべてのアプリケーションのクライアント認証をオンにする」は、この例ではオフです。対象アプリごとの認証設定を忘れずに確認します

公式：Client sessions

3. スマートフォンから接続する

iOS・Androidでは、Cloudflare One Clientのモバイル版である Cloudflare One Agent をインストールし、自分のZero Trust組織へ登録してログインします。ダウンロード先は公式インストールガイドから確認できます。個人向けの1.1.1.1アプリと取り違えないようにしてください。

PC上のiOSシミュレーターやAndroidエミュレーターでアプリを動かす場合は、そのPCにCloudflare One Clientをインストールし、同じ組織へ登録してログインすれば使えます。シミュレーターやエミュレーターの通信はPCのネットワークを経由するため、シミュレーターやエミュレーターの中にOne Agentを入れる必要はありません。

iPhoneでの接続画面。「接続済み」はOne Clientの接続状態を示します。保護したAPIへのアクセス成功は、別途確認します。

通信をトンネルするモードで接続したら、開発中のアプリから保護されたAPIを呼び出します。このとき、対象のAPI、認証先、組織の cloudflareaccess.com への通信が、One Clientを経由するようにしてください。Split Tunnelsなどでこれらの通信を除外していると、想定どおりに認証できない場合があります。

接続中であることと、認証セッションが有効であることは別です。セッションの有効期間が過ぎると、One Clientで使った認証方法による再認証が必要になります。接続中なのにAPIを呼べなくなった場合は、One Client側の再認証要求を確認し、認証を済ませてからAPIを再度呼び出してください。

Accessを迂回する入口

保護したURLとは別に、サーバーのIPアドレスや別の公開URLからアクセスできると、Accessを迂回される可能性があります。Accessを設定したら、こうした入口も閉じておきます。

AWS・VPSで、アプリのコードを変更せずに構成したいなら、Tunnelを使って外部からサーバーへの直接接続を閉じる方法が扱いやすいでしょう。加えて、Tunnelの Protect with Access を有効にし、cloudflared にAccessトークンを検証させます。

通常のプロキシを使う場合は、オリジンへの接続元を制限し、Accessトークンも検証します。CloudflareのIPだけを許可しても、自分のAccessで認証された通信とは限らないためです。

公式：Application token

ホスト名単位でWorkersを保護する場合も、別のカスタムドメインや workers.dev、プレビューURLに、保護されていない入口が残っていないか確認します。

動作確認

設定が終わったら、許可した経路でアクセスできることと、それ以外の経路が拒否されることの両方を確認します。

メール認証の確認

ブラウザのメール認証は、One Clientを切断し、AccessのCookieがない状態から確認します。One Clientの有効な認証セッションが使える場合は、シークレットウィンドウでも認証画面を経ずにアプリを開けるためです。

確認する操作	期待する結果
One Clientを切断し、AccessのCookieがないブラウザでWebを開く	アプリ本文ではなく認証画面が表示される
上記の認証画面で、許可したメールアドレスで認証する	Webアプリを利用できる
One Clientを切断し、AccessのCookieがないブラウザで、許可していないメールアドレスを使って試す	アプリを利用できない

One Client認証の確認

One Client認証は、対象アプリでこの機能が有効になっていることと、対象の通信がOne Clientを経由することを確認してから試します。ブラウザではAccessのCookieがない状態を使い、APIの呼び出しにはAccessのCookieやサービストークンを付けません。

確認する操作	期待する結果
許可したユーザーのOne Clientに接続し、認証セッションが有効な状態でブラウザからWebを開く	メールOTPの入力を求められず、Webアプリを利用できる
One Client接続中・認証セッションが有効な状態でモバイルアプリからAPIを呼ぶ	APIが正常応答する
One Clientを切断した状態でAPIを呼ぶ	APIのデータを取得できない
One Clientの認証セッションが期限切れになった状態でAPIを呼ぶ	APIのデータを取得できず、再認証が必要になる
One Client側で再認証を済ませ、APIを再度呼ぶ	APIが正常応答する

別URL・オリジンIPからのアクセスも、One Clientを切断し、AccessのCookieやサービストークンを付けずに試し、未認証でアプリを利用できないことを確認します。

APIがJSONの代わりにHTMLやリダイレクトを返す場合は、Accessの認証画面に誘導されていないか確認すると、原因を切り分けやすくなります。

Access設定には「非ブラウザー トラフィックに 401 レスポンスを返す」という項目もありました。この設定によっては、認証失敗時にリダイレクトではなく401が返ります。アプリ側では、HTTPステータスとレスポンスの内容も確認してください。

Accessを使えば、アプリのログイン機能とは別に、開発中のサービスへアクセスできる人を制限できます。公開前の環境では、許可するユーザーの設定と、アプリに到達するすべての入口をセットで確認しておきましょう。