Cloudflare Workers に個別単位の権限ロールが追加 — エージェントに「読めるが変えられない」を渡せるようになった

要約

Cloudflare は 2026-09-15、個々の Worker 単位でアクセス権を絞れるロールを公開しました。全顧客向けに即日提供されています。

これまでの制約は明快でした。権限の粒度が「開発者プラットフォーム全体」か「Workers 全体」しかなく、特定の Worker だけを読ませる・更新させるという指定ができませんでした。 結果として、1つの Worker を触らせたいだけでも、アカウント内の全 Worker への権限を渡すことになっていました。

新しいロールは4種類です。

Metadata Read-Only — 設定・メトリクス・ログ・トレースを閲覧できますが、Worker のコードへはアクセスできず、変更もできません。Content Read-Only — コード・設定・可観測性データを読めますが、変更もデプロイもできません。Editor — 更新とデプロイができますが、削除はできません。Admin — Editor に加えて削除ができます。

この4段階の切り方が、実務をよく踏まえています。

「可観測性データは見せたいが、コードは見せたくない」（Metadata Read-Only）と、「更新はさせたいが、消させたくない」（Editor）。この2つは、従来の Read / Write の二分法では表現できませんでした。特に Editor と Admin の間に削除の線を引いたことが効きます。

適用範囲は3段階で指定できます。開発者プラットフォーム製品全体 / すべての Worker / 個別の Worker。 設定はダッシュボード（Members または Account API Tokens）、API、Terraform の3経路です。特定ユーザーへの割り当てと、スコープ付き API トークンの発行の両方に対応します。

公式が挙げるユースケースが、そのままエージェント運用を前提にしています。

デバッグ用エージェントには Metadata Read-Only を渡して可観測性データだけを見せる。コードレビュー用エージェントには Content Read-Only を渡して読ませるが変更はさせない。CI/CD ワークフローには Editor を渡して自動デプロイを許しつつ、誤削除を防ぐ。 人間のチームメンバーには Admin を渡します。

何が変わったか

• 個別の Worker 単位でアクセス権を付与できるようになった
• 4つのロール:
  • Metadata Read-Only: 設定・メトリクス・ログ・トレースを閲覧。コードへはアクセス不可、変更不可
  • Content Read-Only: コード・設定・可観測性データを読める。変更・デプロイ不可
  • Editor: 更新とデプロイが可能。削除は不可
  • Admin: Editor に加えて削除が可能
• 適用範囲は3段階: 開発者プラットフォーム製品全体 / すべての Worker / 個別の Worker
• 設定経路: ダッシュボード（Members / Account API Tokens）、API、Terraform
• 特定ユーザーへの割り当てとスコープ付き API トークンの発行の両方に対応
• 想定用途: デバッグ用エージェント（Metadata Read-Only）、コードレビュー用エージェント（Content Read-Only）、CI/CD（Editor）、人間のメンバー（Admin）
• 全顧客向けに即日提供（プラン制限の明記なし）

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

Cloudflare Workers を複数人・複数チームで運用している組織にとって、これは棚卸しの機会です。

確認すべきは、既存の API トークンです。

これまで粒度が粗かったため、必要以上に広い権限を持つトークンが発行されている可能性が高いです。 CI/CD 用に作ったトークンが、実際には全 Worker の削除権限まで持っている、という状態はよくあります。今回のロール追加で、これを実態に合わせて絞り直せるようになりました。

優先度が高いのは、自動化に渡しているトークンです。 人間が持つトークンは、少なくとも本人が何をしたか認識できます。CI/CD やエージェントに渡したトークンは、誤った動作をしたときに気づくのが遅れます。 ここから絞るのが効率的です。

Editor と Admin の間に引かれた「削除」の線は、実務的に大きな意味を持ちます。

デプロイの誤操作は、たいてい復旧できます。 前のバージョンを再デプロイすればよいからです。削除は違います。 Worker を削除すると、ルーティング設定やバインディングを含めて失われます。CI/CD に削除権限を渡す理由は、通常ありません。 Editor で十分です。この1点を変えるだけで、自動化による事故の最悪ケースが「ロールバック可能な障害」に収まります。

エージェント運用という観点では、この発表はより本質的です。

AI エージェントに本番環境の操作を任せる流れは、もう止まりません。 問題は、渡せる権限の粒度が粗すぎたことでした。「ログを見て原因を調べてほしい」だけのエージェントに、全 Worker のデプロイ権限を渡さざるを得ない。これでは、エージェントが想定外の動作をしたときの被害範囲を限定できません。

Metadata Read-Only の存在は、この問題への直接的な答えです。 可観測性データは見せるが、コードは見せず、変更もさせない。「調査はさせるが、手は出させない」という状態が、権限として表現できるようになりました。 エージェントを本番に入れる際の審査で、これは通しやすい構成です。

運用としての推奨は、次の順序です。 (1) 既存の API トークンを一覧し、用途を確認する、(2) 自動化に渡しているトークンから、必要な最小ロールへ置き換える、(3) 新規のエージェント・CI 導入時は、最初から個別 Worker スコープで発行する。Terraform 対応があるため、(3) は構成管理へ組み込めます。

副業・個人活用視点

個人開発で Workers を使っている場合、直接の必要性は低めです。1人で全て触るなら、権限を分ける相手がいません。

ただし、2つの場面で効いてきます。

1つ目は、AI エージェントに作業を任せる場面です。

個人開発でも、Claude Code や Codex のようなエージェントに Cloudflare の操作をさせる構成は珍しくなくなりました。ここで渡す API トークンの権限が、そのまま事故の最大被害になります。

「ログを見て不具合を調べて」という依頼のために、削除権限まで持ったトークンを渡していないか。 今回の変更で、調査用には Metadata Read-Only、実装確認用には Content Read-Only という選択肢ができました。 個人だからこそ、事故が起きたときに誰も助けてくれないという前提で、渡す権限を絞る意味があります。

2つ目は、受託案件で顧客環境を触る場面です。

顧客の Cloudflare アカウントへのアクセスを求めるとき、「全 Worker への Admin 権限をください」は、通らないか、通っても信頼を削ります。 今回の変更で、「この Worker だけ、Editor 権限で」と依頼できるようになりました。 これは受注の場面で効きます。

さらに、提案としての価値もあります。 顧客が既に発行している API トークンの棚卸しは、それ自体が独立した小さな案件になります。 「CI に渡しているトークンが全削除権限を持っています」という指摘は、具体的で、対処も明確で、リスクの説明が容易です。セキュリティ関連の提案は抽象的になりがちですが、これは違います。

支援時の注意点を1つ。権限を絞る作業は、絞りすぎると既存の自動化が止まります。 顧客環境で行う場合、必ず現行の CI/CD が何をしているかを確認してから変更してください。 特に、デプロイ以外の操作（削除と再作成でデプロイを実現している構成など）が混ざっていると、Editor では動かなくなります。変更前に、既存パイプラインの1回分のログを読むことです。 権限を絞って本番のデプロイを止めた、という事故は、善意でやっただけに説明が難しくなります。