チームにAIエージェントが加わった時代の権限設計
Cloudflare Developer Platform上では、チームメンバーだけでなくAIエージェントがアプリケーションをデプロイするケースが増えています。ここで最も避けたいのは、エージェントが必要以上の権限を持ち、本番環境を書き換えてしまう事故です。
従来はアカウント単位の権限しかなく、「このWorkerだけ触らせたい」という要件に応えられませんでした。今回のアップデートで特定のWorker単位でスコープできるようになり、ロールも4種類に細分化されました。
本記事では、新ロール4種と実務での組み合わせ方を整理します。
追加された4つのロール
| ロール | できること | 利用シーン |
|---|---|---|
| Metadata Read-Only | リソース一覧・設定・メトリクス/ログ/トレースの閲覧（コンテンツは不可） | デバッグ用の可観測性データのみ付与したい場合 |
| Content Read-Only | WorkerコードやD1データの読み取り（変更不可） | コードレビュー用エージェントやメンバーにソースを公開する場合 |
| Editor | コンテンツの読み書き・設定変更（作成・削除は不可） | CI/CDやデプロイ自動化への権限付与 |
| Admin | リソースの作成・改名・削除・権限付与まで完全制御 | 該当Workerの完全な管理が必要な場合 |
スコープは3階層
ロールは次のいずれかのスコープに適用されます。
- Developer Platformレベル: 全リソースのメタデータ
- プロダクトレベル: 特定プロダクト（例: 全Worker）のメタデータ
- リソースレベル: 特定のWorker 1つのメタデータ
APIトークンでWorker単位の権限を付与する例
# 特定のWorkerにのみスコープされたAPIトークンを作成
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/tokens" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{
"name": "deploy-my-worker-only",
"policies": [{
"effect": "allow",
"resources": {
"com.cloudflare.api.account.worker": {
"<WORKER_ID>": "*" # このWorkerにのみスコープ
}
},
"permission_groups": [
{ "name": "Workers Scripts Edit" } # Editorロール相当
]
}]
}'
このトークンであれば、仮にエージェントが侵害されても被害範囲は該当Worker 1つに限定されます。まさに最小権限の原則（Principle of Least Privilege）の実践です。
実務でよく使う3つのシナリオ
1. ソースを露出せずデバッグのみ
障害対応エージェントに Metadata Read-Only を付与すれば、メトリクス・ログ・トレースは閲覧可能ですがWorkerコードは見えません。GraphQL Analytics API経由でも、権限範囲内のWorkerデータのみ返却されます。
2. コードレビューは可、デプロイは不可
レビューボットに Content Read-Only を付与すれば、コードは読めてもデプロイや設定変更はできません。D1・R2・KVにも同様の分離が順次適用される予定です。
3. CI/CDにデプロイ権限だけを
ワークフローごとに Editor ロールのトークンをWorker単位で発行すれば、トークン漏洩時も他のWorkerを変更・削除できません。
⚠️ 注意点: Routes & Custom Domainsは別権限
ここが落とし穴です。Workerに Editor 権限があっても、ルートやカスタムドメインの変更にはzoneレベルの Workers Routes 権限が別途必要です。本番トラフィックをリダイレクトしうる機微な操作だからです。
// wrangler.jsonc - ルート設定例
{
"route": {
"pattern": "example.com/*",
"zone_name": "example.com"
}
}
逆に、ルートが既に設定済みであれば、その接続を変更しないデプロイはzone権限なしで可能です。つまりCI/CDにドメイン権限を渡す必要はありません。
Durable ObjectsはWorker権限に従う
DOには専用ロールがなく、実装したWorkerの権限をそのまま継承します。メトリクス・ログは Metadata Read-Only で十分ですが、Data Studioで保存データを照会・変更するには Editor が必要です。
403エラーが親切になりました
権限不足時には、必要な権限とドキュメントリンクを返すようになりました。エージェント自身が必要な権限を把握できるため、過剰な権限を事前付与する必要がなくなります。
日本開発コミュニティにおける適用文脈
日本の受託開発やSIer案件では、まだ「アカウントに1つのAdminトークン」を共有する運用が残っているケースがあります。特に外部パートナーが混在するプロジェクトでは、リソース単位のスコープがセキュリティ監査対応にも有効です。ただしTerraform管理の場合は、providerバージョンとスキーマ互換性を先に確認してください。
この技術の限界
- レガシーロール（Workers Platform Admin等）はdeprecation日程が未定。既存割り当ては継続動作するため、移行を急ぐ必要はありません。
- D1・R2・KVへの拡張はロードマップであり、現時点ではWorkers中心です。
- User Groupを活用すれば個別割り当てより管理負荷を軽減できます。
次の学習ステップ
- 公式ドキュメントでレガシー→新ロールのマッピング表を確認し、既存トークンを置換
- エージェントごとに最小権限トークンを発行するテンプレートを整備
- Terraformでリソースレベルポリシーをコード化