連載の現在地:Phase 1「公開」(3 / 4本目) — まずは小さく安全に世に出す
1. 公開 → 2. 費用と安定 → 3. 安全 → 4. 品質 → 5. 自動化
こんな悩みの人へ
作りかけのAIアプリを社内で試してもらいたいけれど、URLが外に漏れるのが心配。お客様にだけデモを見せたいが、ログイン機能を作るほどの時間はない。かといって、パスワードをチャットで共有するのはさすがにやめたい。ひとつでも思い当たるなら、この記事が役に立つはずです。
結論
Cloudflare Accessを使えば、アプリのコードを変えずに、決めた人だけが開ける状態にできます。 開こうとすると、先にログイン画面が出ます。許可したメールアドレスにだけ、使い捨てのコードが届く仕組みです。会社のGoogleアカウントなどでのログインにも対応しています。
Zero Trustの無料プランで、50人まで無料で使えます。
なぜ「限定公開」は難しいのか
限定公開が意外と難しいのには、理由があります。
URLは、知っていれば誰でも開けます。推測されにくいURLにしても、転送されたり、履歴から見られたりすれば終わりです。
共有パスワードにすると、今度は誰が使っているのか分からなくなります。辞めた人や取引の終わった相手を外すには、全員のパスワードを変えるしかありません。かといって、デモのためにログイン機能を作るのは重すぎます。パスワードの保存や再設定、セッション管理まで作ると、本来作りたい機能より大きくなってしまいます。
Accessは、アプリの手前でログインを済ませてから通す「門番」です。Accessで保護するホスト名と、ほかの公開経路を確認します。独自サーバーへ直接アクセスできる構成では、TunnelやAccessトークンの検証など、迂回を防ぐ設定も必要です。
[利用者] --> [Cloudflare Access] --ログインした許可済みの人だけ--> [あなたのアプリ]
|
+-- 未ログイン → ログイン画面(One-time PIN・Googleなど)
※ *.workers.dev など、Accessを通らない別の入口は、閉じるか同じように守る解決策の比較
方法 | 費用 | 手間 | 向いている状況 |
|---|---|---|---|
Cloudflare Access | Freeは50ユーザーまで。Pay-as-you-goは1ユーザー月7ドル | 少ない | 見せる相手を、人単位で管理したい |
Basic認証 | 無料 | 少ない | ごく短期間、ごく少人数で試すだけ |
ホスティングのパスワード保護機能 | プランによる | 少ない | そのサービスで公開していて、機能が使える |
アプリにログイン機能を作る | 開発の工数 | 多い | 本番でも会員機能が必要になる |
どれを選ぶか
見せる相手を1人ずつ追加・削除したい場合や、社内の人だけに限りたい場合は、Accessが向いています。数日だけ2〜3人に見せる程度なら、Basic認証でも足ります。ただし、パスワードの共有方法には注意してください。本番でも会員ごとに表示を変えるのであれば、アプリにログイン機能を作る必要があります。
手順
前提:Cloudflareのアカウントと、Cloudflareで管理しているドメイン(またはWorkersで公開したアプリ)。
- ダッシュボードから「Zero Trust」を開きます。初めての場合は、チーム名を決めて無料プランを選びます。
- 「Access controls」→「Applications」で「Create new application」を選び、種類は「Self-hosted and private」を選びます。
- 「Add public hostname」から守りたいホスト名やパスを指定します。例:
demo.example.comや、example.com/demoのようなパスです。 - 「誰を通すか」のポリシーを作ります。特定の人だけに見せるならメールアドレスを1件ずつ登録し、社内の人だけに見せるならメールアドレスのドメイン(例:
@example.co.jp)で許可します。 - ログイン方法を選びます。最初は「One-time PIN」(メールに届くコード)が手軽です。会社でGoogle WorkspaceやMicrosoft 365を使っていれば、それと連携することもできます。
- 保存したら、ブラウザのシークレットウィンドウでURLを開きます。許可したメールアドレスでログインしてアプリを開けることと、許可していないアドレスでは開けないことの両方を確認します。
更新日:2026-11-03
つまずきやすい点
よくあるのが、*.workers.dev のURLが開いたままになっているケースです。独自ドメインだけを守っても、Workersに最初から付いているURLから入れてしまうことがあります。使わないなら無効にするか、同じように守ってください。
ログインを挟むと、APIを別のプログラムから呼べなくなる点にも注意します。ログインのない自動処理からアクセスする場合は、「サービストークン」を発行して、リクエストに付けます。
人数と認可は、別々に管理します。無料枠はアカウントの席数として数えますが、ユーザーを席の一覧から削除するだけでは、Accessの利用を禁止できません。退職者などは、ポリシーやIdPの権限からも外します。デモを見せ終わった取引先や退職者を、ポリシーから外し忘れないようにしましょう。
次に出やすい悩み
見せる相手を絞れたら、次は本番として出す準備と、誰でも使える形で公開したときの悪用が気になってきます。まだ公開そのものができていない場合は、「AIアプリをサーバー管理なしで公開したい」から始めてください。AIで作ったコードをこのまま本番に出してよいか不安なら「Claude Codeなどで作ったものを本番に載せたい」を、ログインなしで一般の人に公開する機能を作るなら、Phase 3の「ボットにAPIを食いつぶされる」もあわせて読んでおくと安心です。
「社内の人には全体を、取引先には一部だけ見せたい」のように、見せる相手が混ざる場合の設計もご相談いただけます。社内ツールの公開範囲やアクセス管理はCloudflareインフラ構築をご覧ください。
よくある質問
Q. 推測されにくいURLにすれば、限定公開として十分ですか？
URLは転送や共有ができるため、知っていることだけを利用の許可にしない設計が必要です。Cloudflare Accessなどで本人を確認し、許可したメールアドレスや組織のルールと照合します。URLの公開範囲と、誰がアクセスできるかを分けて管理します。
Q. Accessで保護したAPIを、自動処理から呼べますか？
自動処理向けには、サービストークンを使う方法があります。Accessのポリシーも用途に合わせて設定し、Client IDとClient Secretをサーバー側で管理します。発行方法や失効の手順はサービストークンの公式資料で確認してください。
Q. 独自ドメインを保護すれば、workers.devのURLも自動で保護されますか？
別の入口として確認してください。独自ドメインだけに保護を設定しても、別URLから同じアプリへアクセスできる場合があります。使わない入口は無効にするか、その入口にも保護を設定し、未許可の利用者で拒否されることを確認します。
Q. 短期間、少人数に見せるだけでもAccessが必要ですか？
本文では、数日だけ少人数へ共有する場合の候補としてBasic認証も挙げています。その場合もパスワードの共有先と変更の方法を決めます。相手を個別に追加・削除したい場合はAccess、本番で会員ごとに表示を変えたい場合はアプリ内の認証・認可を検討します。
執筆者情報
IT顧問、AI・業務アプリ開発、SESを通じて、企業のIT活用を支援しています。代表の藤澤 昌隆は、2007年からシステム開発・運用に携わり、アクセンチュアでの業務ITコンサルティングを経て、2019年にパブロフ株式会社を設立しました。
AI活用の支援事例として、営業工程を支える7つの業務別AIアプリの構築を公開しています。アプリの開発に加え、入力・出力の形式、評価基準、テストケースの整備にも取り組んでいます。
記事の内容に関するご質問や誤りのご指摘は、お問い合わせ窓口へお寄せください。