Cloudflare Workers、制作会社にはWorker単位で権限を渡す

自社サイトやWebアプリをCloudflare Workersで動かしていて、制作会社に改修と公開を頼みたい。ところが招待画面で役割を選ぼうとすると、アカウント全体に効く権限しか思い浮かばず、DNSや請求、ほかのWorkerまで見えてしまうのではと手が止まる。障害時にログだけ見てほしい社内の担当者にも、同じ迷いがあります。

Cloudflareは2026年9月21日の変更履歴で、Workersのダッシュボードから特定のWorkerだけに権限を付けてメンバーを招待できるようにしました。この記事では、4つのアクセスレベルがそれぞれ「何をできないか」を公式ドキュメントで確認し、発注側のアカウントに外部の人を入れるときの渡し方と、契約終了時の外し方を編集部の提案としてまとめます。

Workerの画面の「Invite」から、1つのWorkerだけに招待する

操作は、対象のWorkerの画面で Invite を押し、相手のメールアドレスとアクセスレベルを選んで Invite を押すだけです。相手がすでにアカウントのメンバーなら、そのWorkerへのアクセスはすぐに付きます。メンバーでない場合はCloudflareからアカウントへの招待が送られ、相手が承諾した時点でWorkerへのアクセスが付きます。

注意したいのは、招待できる人が限られている点です。変更履歴には、Workerの画面から招待できるのは Super Administrator の役割を持つメンバーだけと書かれています。メンバー管理の文書でも、メンバーを管理するにはSuper Administratorの役割と確認済みのメールアドレスが必要とされています。

Super Administratorは、あらゆる設定の変更、購入、請求情報の更新、メンバーの管理、アカウント所有のAPIトークンの作成と管理ができる役割です。招待を制作会社に任せるためにこの役割を渡すと、請求やほかのメンバーの権限まで触れる状態になります。招待は発注側のSuper Administratorが行う、と最初に決めておくのが安全です。

4つのアクセスレベルと、それぞれ「できないこと」

選べるのは次の4つです。上のレベルは下のレベルの内容を含みます。

図で見てほしいのは、「デプロイはできるが削除はできない」Editorと、「削除までできる」Adminの境目です。改修と公開を頼むだけなら、削除の権限は要りません。もう1つの境目は、Metadata Read-OnlyとContent Read-Onlyの間にあります。ログは見せたいがコードは見せたくない、という相手にはMetadata Read-Onlyが合います。

公式ドキュメントには、渡す前に知っておきたい制約もいくつかあります。

• Worker単位の権限は、すでにあるWorkerにしか付けられません。新しいWorkerを作るには、Workers全体（プロダクト単位）のAdminが必要です。
• RoutesやCustom Domainsを追加・変更・削除するには、そのWorkerのEditorに加えて、影響するゾーンごとの Workers Routes Write が必要です。一度設定したあとは、つなぎ方を変えないデプロイならEditorだけでできます。
• Custom Domainsは、現時点でWorker単位の権限に対応していません（対応予定と記載）。
• KV、R2、D1などのバインディングがあるWorkerでも、デプロイにはWorkerのEditorがあれば足ります。バインド先のデータを直接読むには、その資源への権限が別に必要です。
• Cloudflare Pagesの権限には、Worker単位の権限を使いません。

制作会社がCLIでデプロイする場合

制作会社は、ダッシュボードではなく手元からWranglerでデプロイすることもあります。ここにも1つ条件があります。公式ドキュメントによると、wrangler login のOAuthによるログインは、現時点でこの細かい権限（granular authorization）に対応していません。Worker単位の権限でWranglerを使うには、アカウント所有のAPIトークンで認証します。

トークンもメンバーと同じ役割と範囲で作れますが、メンバーとは別に自分の権限を持ちます。特定のWorkerに絞ったトークンなら、WranglerはそのWorkerに許された操作しかできません。CI/CDから自動でデプロイする場合も、Worker単位のEditorのトークンが公式の例に挙がっています。ブランチごとの確認URLを制作会社に立ててもらう流れは、Worker Previewsの記事で整理しています。

協業相手ごとに、何を渡すか

ここからは、上の仕様を踏まえた編集部の提案です。発注側のアカウントに人を入れる前に、相手ごとに次のように決めておきます。

新しいWorkerが必要になったら、発注側で先に作成し、その上で制作会社にEditorを付けます。Worker単位の権限は未作成のWorkerに付けられないためです。独自ドメインのつなぎ替えも、Custom DomainsがWorker単位に対応していない現時点では、発注側で行う作業として契約の分担に書いておくと混乱しません。

複数のWorkerを同じ制作会社のメンバー数人に任せる場合は、User Groupを作ってグループにポリシーを付け、メンバーを追加する方法が公式に案内されています。人の入れ替わりがあっても、グループへの出し入れで済みます。

契約が終わったら、どこを外すか

外す作業も、発注側のSuper Administratorが行います。アカウントから完全に外すなら、Membersの画面で対象のメンバーを開き、Revoke を押して Yes, revoke access で確定します。アカウントには残し、特定のWorkerの権限だけを外すなら、同じ画面の Edit で範囲と役割を更新します。

見落としやすいのは、権限の出どころが複数ある場合です。メンバーの実際の権限は、本人に直接付けたポリシーと、所属するUser Groupのポリシーの和になります。Membersの画面には直接付けた権限しか表示されず、グループから受け継いだ権限はGroupsのタブで確認する必要がある、と公式ドキュメントに注意書きがあります。

編集部としては、契約終了時に次の順で確認することを提案します。

1. Membersの画面で、その会社のメンバーを洗い出す（承諾前の「Invite Pending」も含めて）
2. Groupsのタブで、その会社のメンバーが入っているUser Groupを確認する
3. その会社のCI/CDやWrangler用に発行したアカウント所有のAPIトークンを確認する。トークンはメンバーとは別に権限を持つため、メンバーを外しても別に見直す
4. 不要になったメンバーをRevokeし、トークンも止める

誰に何を渡しているかを表にしておくと、この確認が早く終わります。サイトの引き継ぎで発注側と保守側の分界点を決める考え方は、ネームサーバを移したらJSが増えていた話でも扱いました。

2026年9月30日に、Cloudflareの変更履歴（2026年9月21日の項）、Workersの権限のドキュメント（Workers roles and permissions、Roles and permissions）、アカウントメンバーの管理・役割・ポリシー・User Groupsの文書を、公式ドキュメントのソースリポジトリで直接開いて照合しました。検証用のCloudflareアカウントで招待・承諾・剥奪を試してはおらず、実際の画面、招待メールの文面、招待の有効期限、対象プランの条件は確認していません。メニュー名は英語表記のまま記載しています。

Cloudflare上のサイト運用や、制作会社との分担を含めたサイトのリニューアルは、グリームハブへご相談ください。

Sources

• Give teammates access to specific Workers directly from the dashboard — Cloudflare Changelog
• Workers roles and permissions — Cloudflare Workers docs
• Roles and permissions — Cloudflare Workers docs
• Manage account members — Cloudflare Fundamentals docs
• Roles — Cloudflare Fundamentals docs
• Policies — Cloudflare Fundamentals docs
• User Groups — Cloudflare Fundamentals docs