Cloudflare Access for Workers — アカウント単位で全 Worker を既定で社内ログインの背後へ

要約

2026-08-14、Cloudflare が Cloudflare Access for Workers を提供開始しました。Worker に対して Cloudflare Access を直接適用できるようにする機能です。

公式が想定している課題がはっきりしています。AI に書かせて素早く公開した内部アプリ（vibe-coded application）が、認証を付けないまま公開状態になること。エージェントに指示すれば数分で動くものが出来上がり、そのままデプロイできてしまう現在、認証の設定は「後でやる」に回されがちです。そして後でやられないまま残ります。この問題に対して、個々の開発者の規律ではなく、アカウントの既定値で解くというのが今回のアプローチです。

ポリシーは2つの粒度で設定できます。アカウント単位では、アカウント内の全 Worker に適用され、既存分だけでなく以後に作られる Worker も対象になります。プレビューと本番の両方のデプロイが、既定で会社ログインの背後に入ります。アプリケーション単位では、特定のアプリに紐づく全ドメインで、デプロイ方法を問わず認証を強制します。

保護対象は routes、カスタムドメイン、workers.dev、プレビュー URL に及びます。適用範囲はプレビュー URL のみ、または全ホスト名から選べます。プレビューだけを守る選択肢があるのは実務的で、「本番は公開 API だがプレビューは社内限定にしたい」というよくある要件に合います。

複数のポリシーが重なる場合は具体的なものが優先され、ホスト名単位 > Worker 単位 > アカウント単位の順です。どのポリシーが効いているかはダッシュボードで確認できます。

ローカル開発では wrangler.jsonc に access ブロックを追加すると、認証済みユーザーをシミュレートして動作確認できます。認証を入れた途端にローカルで動かなくなるという、この種の機能にありがちな摩擦への対処が入っています。

公式は「available to everyone」と記載しており、具体的なプラン要件の明示はありません。

何が変わったか

• Worker に対して Cloudflare Access を直接適用できるようになった
• アカウント単位のポリシーで、既存および以後に作られる全 Worker を既定で認証の背後に置ける
• アプリケーション単位のポリシーで、そのアプリに紐づく全ドメインに認証を強制できる
• 保護対象は routes、カスタムドメイン、workers.dev、プレビュー URL
• 適用範囲をプレビュー URL のみ／全ホスト名から選べる
• ポリシー競合時はホスト名単位 > Worker 単位 > アカウント単位の順で具体的なものが優先される
• ダッシュボードで、そのアプリケーションに効いているポリシーを確認できる
• wrangler.jsonc の access ブロックで、ローカル開発中に認証済みユーザーをシミュレートできる
• 公式表記は「available to everyone」。具体的なプラン要件の明示はない

業務インパクト（一般企業向け）

設定漏れという事故の型を、構造的に減らせる更新です。

社内ツールの認証漏れは、担当者の不注意というより仕組みの問題として起きます。デプロイの手順に認証設定が含まれていなければ、忙しいときに飛ばされる。飛ばされたことに誰も気づかない。既定を「認証あり」にして、外す方を明示的な操作にするのが正しい設計で、今回の機能はそれを提供します。

特に効くのがプレビュー URL です。本番の認証は意識されますが、プレビューは「一時的なもの」として扱われ、認証なしで共有されがちです。実際には検証用の実データが入っていることも多く、URL さえ知っていれば誰でも見られる状態が長く残ります。適用範囲をプレビューのみに絞れる選択肢があるので、本番の構成に手を入れずにプレビューだけ先に守るという段階的な導入ができます。ここから始めるのが摩擦の少ない進め方でしょう。

AI コーディングの普及との関係も無視できません。エージェントに社内ツールを作らせる組織が増えており、生成から公開までのリードタイムが劇的に短くなっています。レビューが追いつかない速度でアプリが増えていく状況では、一つずつ確認する運用は成立しません。アカウント単位の既定値で押さえる方が現実的です。

一方で、アカウント単位ポリシーの副作用には注意が要ります。以後に作られる Worker にも自動適用されるということは、公開 API や Webhook 受け口を新規に作ったときにも認証がかかるということです。認証必須の社内アプリと、認証してはいけない公開エンドポイントが同じアカウントに同居している構成では、事故の向きが逆転します。導入前に、そのアカウントで作られる Worker の種類を棚卸ししておくべきです。公開用と社内用でアカウントを分けるのが構成として素直で、それが難しい場合はホスト名単位の除外ポリシーで対処することになります。優先順位が「具体的なものが勝つ」設計なので、除外は書けます。

プラン要件が明示されていない点は、導入計画を立てる上での不確定要素です。「available to everyone」という表現だけでは、Access のシート数課金がどう効くかが読めません。利用者数が多い社内アプリで先に確認しておくのが安全です。

副業・個人活用視点

個人開発でも使いどころがあります。自分専用の管理画面やダッシュボードを Workers に置いているケースは多く、そこに認証を入れるのは面倒だからと URL の推測困難性に頼っている、という状態は珍しくありません。ダッシュボードの設定だけで会社ログイン（個人なら自分の ID プロバイダー）の背後に置けるなら、自前で認証を実装する理由がなくなります。

クライアントワークでは、プレビュー共有のやり方が変わります。制作物を確認してもらうためにプレビュー URL を渡す場面で、これまでは「URL を知っている人なら誰でも見られる」状態を許容していました。Access を通せば、クライアントのメールアドレスを許可リストに入れる運用に切り替えられます。納品前の成果物が第三者に流れるリスクを説明できると、それ自体が提案材料になります。

wrangler.jsonc でローカル開発時に認証済み状態を再現できる点は、実装する側にとって重要です。認証を入れると開発中に毎回ログインが必要になる、という摩擦があると結局外されます。開発体験を落とさずに既定を安全にできることが、定着するかどうかを分けます。

案件として拾うなら、社内ツールの認証棚卸しが切り口になります。Workers で作られた社内ツールが何個あり、どれが認証なしで公開されているかを一覧にする作業は、作った本人ですら把握していないことがあります。アカウント単位ポリシーの適用にあたっては、公開してよいエンドポイントの切り分けが必要になるので、その仕分けごと引き受ける形にすると仕事として成立します。

発信のネタとしては、「vibe coding の後始末」という切り口が実態に合っています。AI で素早く作ることの記事は多い一方、作った後に残る運用課題を扱ったものは少ない。認証、ログ、権限、削除。この4つが典型的に抜けます。今回の機能は認証の部分に対する一つの解なので、残り3つがまだ手つかずであることも含めて書くと、読者の現実に届きます。