Cloudflare、WorkerへのAccessポリシー直接適用に対応 全Workerをデフォルト非公開化する新機能を発表

概要

Cloudflareは2026年8月14日、Workerに対して直接Zero Trust Accessポリシーを設定できる新機能を発表した。これまで開発者はカスタムドメインやworkers.dev、プレビューURLなど、Workerに紐づく複数のエンドポイントごとに個別のアクセス制御を用意する必要があったが、新機能ではポリシーをWorker自体に紐づけることで、そのWorkerに関連するすべてのドメインが自動的に保護対象となる。設定単位はWorker単位とアカウント全体の2種類から選択でき、アカウント全体を選べば既存・新規を問わずすべてのWorkerをデフォルトで非公開にした上で、必要なものだけを例外的に公開する運用が可能になる。

背景と狙い

Cloudflareが公式ブログで強調しているのは、AIによる「vibe-coding」で内製アプリケーションが急増している現状への対応だ。開発者が素早く社内ツールをデプロイできるようになった一方で、認証設定を忘れたまま公開状態のWorkerが放置されるケースが課題となっていた。今回の機能は、CISOなど組織のセキュリティ管理者がアカウント全体に対して「デフォルト非公開」のガードレールを一括適用できるようにすることで、開発者個人の設定漏れに依存しない防御を実現する狙いがある。認証対象としてはCloudflareアカウントのメンバーに加え、特定のメールアドレスやメールドメインを指定でき、本番環境のみ、あるいはプレビュー環境も含めて保護するかを選べる。

技術的な詳細

実装面では、Cloudflareの新しいRustベースのプロキシ基盤「FL2」により、リクエストのルーティング処理をWorkerの実行前に行えるようになったことがこの機能を支えている。従来のNGINX/Lua製プロキシ「FL1」ではWorker単位での認証適用が技術的に複雑だったが、FL2への移行によってポリシーの適用点をWorkerの手前に置けるようになった。開発者向けには、Workersランタイム上でctx.access.getIdentity()を呼び出すだけで認証済みユーザーのメールアドレス、名前、所属グループを取得できるAPIが用意され、JWTの手動検証は不要になる。ローカル開発時にはwrangler.jsoncのdevブロックに擬似的な認証ユーザー情報を設定することで、Access連携込みの認証フローをローカル環境でテストできる。詳細なポリシーの調整はZero Trustコンソールから行うほか、Workers APIを用いたプログラマティックな設定にも対応する。またWorkers for Platformsを利用する場合、プラットフォーム上にデプロイされる全Workerをデフォルトで非公開化することも可能で、マルチテナント環境での内部アプリケーション保護にも応用できる。

今後の展望

この機能により、Cloudflare上でWorkerを運用する組織は、個別のドメインやルートごとに認証設定を管理する手間から解放され、Worker単位・アカウント単位でセキュリティポリシーを一元管理できるようになる。特にAI支援によるアプリケーション開発が広がる中で、意図しない情報公開のリスクを組織レベルで抑止できる点は、開発速度とセキュリティ統制の両立を目指す企業にとって実用的な選択肢となりそうだ。