Worker 単位で4つのロールを割り当てられるようになった。Metadata Read-Only から Admin までで何が見えて何ができないか、Durable Objects の継承、適用範囲の3段階を整理する。
4ロール Worker 単位で選べる権限の段数 Metadata Read-Only、Content Read-Only、Editor、Admin の4つ（2026年9月15日の Cloudflare changelog）
Worker ごとにロールを割り当てられるようになった。選べるのは Metadata Read-Only、Content Read-Only、Editor、Admin の4つ。changelog の日付は2026年9月15日で、そこには全顧客が今日から使えるとある。CI/CD 用のトークンに Editor を渡せば、デプロイはできるが Worker の削除はできない。
4つのロールの差は、3つの境界で整理できる。コードが読めるか、変更とデプロイができるか、Worker を削除できるかである。
| ロール | できること | できないこと |
|---|---|---|
| Metadata Read-Only | 設定、メトリクス、ログ、トレースの閲覧 | Worker のコードの閲覧、変更 |
| Content Read-Only | コード、設定、observability データの閲覧 | 変更、デプロイ |
| Editor | Worker の更新とデプロイ | 削除 |
| Admin | Editor の全部と、Worker の削除 | （changelog に記載なし） |
出典：Cloudflare Docs Changelog「Grant teammates and agents access to specific Workers」（2026年9月15日）
上の2つの差はコードの可視性だけで、どちらも変更とデプロイには届かない。下の2つの差は削除の可否だけだ。読む側と書く側を分ける境界は Content Read-Only と Editor の間にあり、破壊的な操作を許すかどうかの境界は Editor と Admin の間にある。
Metadata Read-Only で見えるものの並びは、障害対応のときに最初に開くものとほぼ同じだ。設定、メトリクス、ログ、トレース。この4つを読むのにコードを読む必要はない、という前提でロールが切られている。
changelog は4つのロールに、それぞれ想定する相手を添えている。デバッグ用のエージェントには Metadata Read-Only を渡し、設定と observability データだけを読ませてコードは見せない。コードレビュー用のエージェントには Content Read-Only を渡し、読めるが変えられない状態で置く。CI/CD ワークフローには Editor を渡す。
このうち CI/CD の説明にだけ条件が一つ多い。原文は「deploy without deleting the Worker or accessing other Workers」で、削除できないことと、ほかの Worker に触れないことを並べている。後者はロールではなく適用範囲が決める部分だ。Admin については、人にもエージェントにも同じ説明が当てられている。削除を含む全権、という説明だけである。
Durable Objects には自前のロールも scope もない。実装している Worker に割り当てられた権限をそのまま継承する、と changelog は書いている。
つまり、ある Worker に Admin を渡した相手は、その Worker が実装する Durable Objects に対しても同じ段階まで届く。Durable Objects だけを別の段階に切り出す手段は、この changelog の範囲では示されていない。権限を設計するときの単位は Worker であって、その内側のストレージではない。
ロールを効かせる範囲は、Developer Platform 製品全体、すべての Workers、個別の Worker の3段階から選ぶ。同じ Editor でも、全 Workers に効くのか1つの Worker にだけ効くのかは、この scope の指定で変わる。
人に渡すときは、dashboard の Manage Account > Members で対象の member を選び、permission policy を作る。scope を Individual Workers にして対象の Workers を選び、ロールを選ぶ。同じチームや同じプロジェクトで複数人に同じ権限が要るなら、policy を個人ではなく User Group 側に割り当てる。グループに追加された人は、その policy を自動で継承する。
エージェントや CI/CD ワークフローには、Manage Account > Account API Tokens から account-owned API token を作る。scope は Specified Workers を選び、そのトークンが触れる Workers とロールを指定する。設定の経路は dashboard のほかに API と Terraform があり、changelog はこの3つを並べている。
今日見直せるのは、範囲が account 全体のままになっているトークンと、権限を個人ごとに配ってきた member の側だ。順に見るなら次の3つになる。
一方、既存の permission policy や API token がこの4ロールにどう対応づくのか、移行が必要なのかは changelog に書かれていない。Worker が使う KV や R2 のようなバインディング先の扱いも、Durable Objects 以外は触れられていない。Content Read-Only がコードを読めるとき、secrets の値まで見えるのかどうかも、この文面からは確定できない。いずれも Workers roles and permissions のドキュメント側で決まっている可能性があるが、changelog の記述だけでは判断できない。
