Cloudflare Workers、Worker単位の権限と4つの新ロールを導入 チームやAIエージェントに必要なアクセス権だけを付与

Cloudflareは何を発表したのか

Cloudflareは2026年9月15日、公式ブログに記事（執筆者はDina Kozlov、Anthony Oreglia、Visal In）を公開した。記事によると、Workersでより細かなアクセス制御ができるようになった。Workersは、Cloudflareの開発者プラットフォーム（Developer Platform）上でアプリケーションを動かす仕組みで、個々のアプリケーションを「Worker」と呼ぶ。Cloudflareによると、チームメンバーやAIエージェントに特定のWorker1つだけへのアクセスを与えられるようになった。相手はそのアプリケーションだけを変更でき、アカウント内の他のリソースは変更できない。

Cloudflareは記事の中でこの機能の動機を次のように説明している。「the last thing you want is for an agent to make a change in production, just because it was granted more access than it needs.」つまり、最も避けたいのは、エージェントが必要以上の権限を与えられていたというだけの理由で本番環境に変更を加えてしまうことだ、という意味である。

詳しい説明を読む

情報源を収集し、独立検証を行ってから Jev が判断します。

Cloudflareによると、新しいロールは発表当日からすべての顧客に提供されている。ロールは特定のユーザーに割り当てることができ、そのユーザーがダッシュボードにログインすると許可されたWorkerだけが表示される。また、範囲を限定したAPIトークンを作成してエージェントに渡すこともできる。APIトークンは、プログラムからCloudflareを操作するための認証用の鍵である。

4つの新ロールの比較

下の表の「オブザーバビリティデータ」とは、メトリクス（数値指標）、ログ、トレースなど、アプリケーションの動作状況を把握するためのデータを指す。「CI/CD」は、コードの変更を自動でテスト・デプロイ（本番環境への反映）する仕組みである。

権限の範囲：3つのレベル

Cloudflareによると、各ロールは3種類の範囲のいずれかに適用できる。Developer Platformレベル（すべてのDeveloper Platformリソース）、製品レベル（例：すべてのWorker）、そしてリソースレベル（例：単一のWorker）である。ロールは何ができるかを決め、範囲はどのリソースに対してできるかを決める。

Cloudflareは、設計にあたってバランスを重視したと述べている。範囲が広すぎるロールは、利用者に想定以上の権限付与を強いて最小権限の原則（必要な権限だけを与えるという考え方）に反する。一方、個別の権限が多すぎると何を付与すべきか判断しにくくなるという。

一般ユーザーとチームへの実際の影響

Cloudflare Workersを利用する開発チームにとって、この変更の核心的な意味は「ミスや漏えいが起きた際の影響範囲を小さくすること」にある。これまでは、自動化ツールやAIエージェントにデプロイを手伝わせるには比較的広い権限を与える必要があった可能性がある。Cloudflareによると、今後は単一のWorkerに対する特定のロールだけを与えられるようになった。

• デバッグ：Cloudflareによると、Metadata Read-Onlyでは人やエージェントがメトリクス、ログ、トレースを確認できるが、ソースコードは見られない。
• コードレビュー：Cloudflareによると、Content Read-Onlyではレビュー担当者やレビュー用エージェントがコードを読めるが、変更やデプロイはできない。
• 自動デプロイ：Cloudflareによると、CI/CDが単一のWorkerに限定したEditorトークンを使えば、設定ミスやトークン漏えいが起きても影響は限られる。そのWorkerへの変更をデプロイできるだけで、削除したり他のアプリケーションに触れたりはできない。
• 完全な管理：Adminは最上位の権限で、アプリケーションを削除できるが、Cloudflareによると、それでも単一のWorkerに限定することが可能だという。

ルート、カスタムドメイン、Durable Objectsのルール

ルート（route）やカスタムドメイン（Custom Domain）は、どのホスト名への通信をそのWorkerに届けるかを指定する設定である。Cloudflareによると、これらの変更は本番トラフィックに影響する可能性があるため、Workerの権限だけでは不十分だという。ルートやカスタムドメインの追加・変更・削除には、そのWorkerのEditor権限と、該当ゾーン（zone、Cloudflare上のドメインの単位）のWorkers Routes権限の両方が必要となる。

ただしCloudflareによると、ルートを設定した後は、デプロイでその紐付けを変更しない限り、紐付けられたゾーンやリソースへのアクセス権がなくても新しいバージョンを継続的にデプロイできる。これにより、CI/CDシステムがドメイン、データベース、ストレージへのアクセス権を同時に持つ必要がなくなる。

Durable Objectsについて、Cloudflareは独自のロールや権限はなく、アクセス権はそれを実装するWorkerによって決まると説明している。Metadata Read-OnlyではDurable Objectのメトリクス、ログ、トレースを確認できるが、内部に保存されたデータは見られない。また、Durable Objects Data Studioの利用にはEditorロールが必要となる。

今後の展開

Cloudflareは、同じロールをD1（データベース）、R2（ファイルを保存するストレージ）、KVを含む他のDeveloper Platform製品にも拡大する計画である。「設定やオブザーバビリティデータは見られるが、コンテンツは見られない」という区別も維持するとしている。具体的な提供時期について、Cloudflareはこの記事で明らかにしていない。

このトピックの最新ニュースを見る

• テックニュース