SpaceRole

SpaceRole は Space メンバーに付与する権限のまとまりです。Content Type・Content・Media に対して何を（読み取り・作成・編集・削除・公開）できるか、Script を実行・管理できるか、そして Space 設定にアクセスできるかを 1 つのリソースにまとめます。特定の Content Type のみ、自分が作成したもののみといったかたちで権限の範囲を絞り込むフィルターも SpaceRole の中で定義します。

作成した SpaceRole は、それ自体では誰にも適用されません。Space Membership の roles にこの SpaceRole の Refer を入れてメンバーに付与します。1 人のメンバーが複数の SpaceRole を同時に持つことができます。また DeliveryAccessToken も least-privilege（最小権限）の SpaceRole 1 つに紐づき、そのトークンで配信を受けられる範囲が決まります。

リソース構造

以下は SpaceRole「商品閲覧専用」の単一取得レスポンスです。sys（システムプロパティ）とともに、権限を定義する本体プロパティ contentType・content・media・settings・script を持ちます。

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7ObyNrQQbHbm",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-16T09:53:16.617Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-16T09:53:16.617Z",
    "isLocked": false,
    "version": 1
  },
  "name": "商品 閲覧専用",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "settings": [],
  "script": {}
}

主なキー:

contentType: Content Type 自体（スキーマ）に対する権限マップです。Content Type を読み取り、作成し、編集し、削除し、公開する権限をアクションごとに定義します。
content: Content（コンテンツデータ）に対する権限マップです。上の例は特定の Content Type の Content のみを読み取れるよう限定したものです。
media: Media（ファイル・画像）に対する権限マップです。
script: Script（フロントエンドが呼び出す宣言型バックエンドエンドポイント）に対する権限マップです。実行（Execute）と管理（作成・読み取り・編集・削除）をアクションごとに定義します。
settings: Space 設定へのアクセス権限を定義する文字列の配列です。権限マップではなく、アクション名をそのまま並べます。全アクセスは ["SETTING_ALL"]、設定へのアクセスを一切付与しない場合は [] で、必要な設定だけを選んで入れることもできます（下の settings を参照）。
isLocked: true の場合は Weegloo が標準で提供するロール（例: Administrator）であり、変更・削除できません。

システムプロパティ (sys)

すべての SpaceRole は共通のシステムプロパティを sys オブジェクトに持ちます。space・createdBy・updatedBy は Refer 形式（{ "sys": { "id", "type": "Refer", "targetType" } }）で入ります。

プロパティ	型	説明
`id`	string	リソースの一意な識別子。
`type`	string	リソースの種類。SpaceRole は常に `"SpaceRole"`。
`space`	Refer<Space>	この SpaceRole が属する Space。
`createdBy`	Refer<User>	作成したユーザー。
`createdAt`	string (date-time)	作成日時。
`updatedBy`	Refer<User>	最後に変更したユーザー。
`updatedAt`	string (date-time)	最終変更日時。
`isLocked`	boolean	`true` の場合は標準提供ロールであり、変更・削除できません。自分で作成したロールは `false` です。
`version`	integer (≥1)	リソースのバージョン。変更するたびに 1 ずつ増えます。

SpaceRole は公開の概念を持たない設定リソースです。そのため Content・Media とは異なり、sys に publish・archive・status がなく、version のみを持ちます。version は SpaceRole を変更するたびに増加します。

権限マップ: contentType・content・media

contentType・content・media はそれぞれ アクションをキーに持つマップ です。使えるアクションは Create（作成）・Read（読み取り）・Edit（編集）・Delete（削除）・Publish（公開）・Unpublish（公開停止）・Archive（アーカイブ）・Unarchive（アーカイブ解除）であり、すべてのアクションをまとめて指す All もあります。Save というアクションはありません。 編集の権限は Edit であり、Save は Webhook が購読するイベント名です。各アクションの値は Allow（許可）と Deny（拒否）のルール配列を持つオブジェクトです。

"content": {
  "Read":   { "Allow": [ /* ルール */ ], "Deny": [ /* ルール */ ] },
  "Edit":   { "Allow": [ /* ルール */ ] }
}

各ルール（rule）オブジェクトは権限の範囲を絞り込む任意のフィルターを持ちます。

self: そのルールが適用される対象を リソース自身 1 つに限定します。対象のリソースを指す Refer を入れます。contentType マップでは特定の Content Type 1 つを、script マップでは特定の Script 1 つを意味します。
contentType: その Content が 属する Content Type に限定します。Content Type を指す Refer を入れます。
createdBy: 特定のユーザーが作成したリソースのみに限定します。sys.id に特定のユーザー id を入れるとその人が作成したもののみ、予約値 :self を入れると「現在呼び出したユーザーが作成したもののみ」に限定されます。
tag: 特定の Tag が付いたリソースのみに限定します。

どのフィルターがどの権限マップで意味を持つかは決まっています。 合わないフィルターを入れると、ロールの保存が拒否されます。黙って無視すると、絞り込んだつもりのルールが全体許可になってしまうからです。

権限マップ	使えるフィルター	入れると保存が拒否されるフィルター
`contentType`	`self`（その Content Type 自身）・`createdBy`	`contentType`
`content`	`contentType`（その Content が属する種類）・`createdBy`・`tag`	`self`
`media`	`createdBy`・`tag`	`self`
`script`	`self`（その Script 自身）・`createdBy`	`contentType`・`tag`

contentType マップの対象は contentType ではなく self で指定します。 Content Type 自身を限定することだからです。contentType フィルターは「このリソースが参照する種類」という意味なので、content マップにのみ合います。
そのリソースに存在しない軸で絞り込もうとするフィルター（Content Type に tag、Media に contentType）は、保存が止められることはありませんが、ルールが意図どおりに判定されません。使わないでください。

createdBy フィルター（:self を含む）を CDA（配信）で判定する場合は、対象の Content Type の publishWithAuthor が true である必要があります。 CDA は公開スナップショットの sys.createdBy でこのフィルターを判定しますが、publishWithAuthor がデフォルト値の false だとスナップショットに作成者がないため、Allow ルールは何もマッチせず、Deny ルールは誰も除外できません。CMA（管理）は下書きの sys.createdBy で判定するため、この設定とは無関係です。publishWithAuthor は遡及しないため、コンテンツを公開する前に有効にする必要があり、すでに公開された Content は再度公開する必要があります。Content Type の publishWithAuthor の説明を参照してください。

空の Allow 配列 [] は、その種類全体に対してアクションを許可する という意味です。フィルターが空で絞り込む対象がないため、すべてのリソースに対してそのアクションが開かれます。

空の Deny 配列 [] は逆に動作します。 「何も拒否しない」ではなく その種類全体を拒否 して、そのアクションを完全に塞ぎます。Allow を併せて書いても塞がれます。拒否する対象がないという意味で [] を置くと正反対に動作するため、何も拒否したくない場合は Deny キー自体を入れないでください。

例 1: Administrator (全権限、標準提供)

Administrator ロールは contentType・content・media・script すべての All アクションに空の Allow を与えて全体を許可し、settings に ["SETTING_ALL"] を与えて Space 設定全体にアクセスします。このロールは Weegloo が標準で提供するため sys.isLocked が true であり、変更・削除できません。

{
  "sys": {
    "id": "3trmXRLdJF4GBlAjtcuoWfVubsasp4",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-14T14:56:04.737Z",
    "updatedBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-14T14:56:04.737Z",
    "isLocked": true,
    "version": 1
  },
  "name": "Administrator",
  "description": "Members of this role have full access to everything in this space.",
  "contentType": { "All": { "Allow": [] } },
  "content": { "All": { "Allow": [] } },
  "media": { "All": { "Allow": [] } },
  "settings": ["SETTING_ALL"],
  "script": { "All": { "Allow": [] } }
}

例 2: 読み取り専用 (特定の Content Type のみ)

自分で作成する least-privilege ロールの例です。content の Read アクションにのみルールを置き、そのルールの contentType フィルターで特定の Content Type 1 つに限定します。Content Type 自体と Media は All を空の Allow で開放していますが、コンテンツデータはその 1 種類を読み取ることだけが可能です。settings が [] のため Space 設定にはアクセスできません。このようなロールを DeliveryAccessToken に紐づけると、配信トークンがその範囲だけを読み取るようになります。このロールの JSON は上のリソース構造の「商品閲覧専用」と同じです。

`settings` (Space 設定アクセス)

settings は権限マップではなく文字列の配列です。Space 設定へのアクセス権限を持ち、Allow/Deny もフィルターもありません。配列に入れたアクションは許可され、入れなかったアクションは許可されません。

全アクセスは ["SETTING_ALL"]、アクセスを一切付与しない場合は [] にします。その中間が必要な場合は、以下のアクションから選んで入れます。

アクション	扱えるようになるもの
`SETTING_GENERAL`	Space 自体（名前・説明など）
`SETTING_LOCALE`	Locale
`SETTING_WEBHOOK`	Webhook（呼び出し履歴・ステータスを含む）
`SETTING_APP`	Market App のインストール
`SETTING_TAG`	Tag
`SETTING_DELIVERY_ACCESS_TOKEN`	Delivery Access Token
`SETTING_SPACE_ACCESS_TOKEN`	Space Access Token
`SETTING_USER`	Space Membership（メンバーの割り当て）
`SETTING_ROLE`	SpaceRole
`SETTING_WEB_HOSTING`	Web Hosting とカスタムドメイン
`SETTING_SERVICE_LOGIN`	ServiceLogin・ServiceUser・ServiceUserRole
`SETTING_EMAIL_ACCOUNT`	メール送信アカウント
`SETTING_MONITORING`	使用量・メトリクスの参照
`SETTING_SCHEDULER`	Scheduler とその実行記録
`SETTING_ALL`	上記すべて

トークンの 2 種類はアクションが分かれています。SETTING_DELIVERY_ACCESS_TOKEN だけを与えると、読み取り専用の Delivery Access Token は発行できても、書き込みまでできる Space Access Token は発行できません。

settings のアクションは、コンソールのログインセッションと Personal Access Token からのみ呼び出されます。Space Access Token・Delivery Access Token・ServiceUser のトークンは、ロールにどのアクションを入れておいてもこの一覧の API を呼び出せません。

権限マップ（contentType・content・media・script）のアクション一覧とフィルターキー（self・contentType・createdBy・tag）・:self の意味、そしてどのフィルターがどのマップで有効かは、上の権限マップ: contentType・content・media の節に従います。

script (Script 権限)

script は Script（フロントエンドが呼び出す宣言型バックエンドエンドポイント）に対する権限マップです。構造は content・media と同じで、アクションをキーに置き、Allow/Deny ルール配列を値に持ちます。使用するアクションは次のとおりです。

Create・Read・Edit・Delete: Script リソースを作成し、取得し、変更し、削除します。
Execute: Script を実行します（/execute 呼び出し）。Script 固有のアクションです。
All: 上記すべてを含む上位アクションです。

Script は公開するリソースではないため、Publish・Unpublish のような公開アクションは使いません。ルールフィルターとして使えるのは self と createdBy の 2 つです。

self: 特定の Script 1 つに限定します。その Script を指す Refer（targetType は Script）を入れます。
createdBy: 作成した人で限定します（:self で「自分が作成した Script のみ」）。

contentType・tag は Script に付かない軸なので、入れるとロールの保存が拒否されます。

たとえば、すべての Script を実行できるようにしつつ、取得は自分が作成したものだけに絞るには、次のように書きます。

"script": {
  "Execute": { "Allow": [] },
  "Read": {
    "Allow": [
      { "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } } }
    ]
  }
}

self で絞ると、Script 1 つだけを実行できる最小権限になります。 決済代行会社のように外部のシステムへ実行権限を与えるとき、そのシステムが呼ぶ窓口 1 つだけを開けて残りは閉じておく方法です。

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

このロールを Space Access Token に紐づけると、そのトークンでは指定した Script 1 つだけが実行されます。実行権限を 1 つに絞る理由と、Script の実行が作成者の権限を委任されるという点は Script の実行セマンティクス、制約、セキュリティで扱います。

この script 権限は「Script リソースを実行・管理できるか」を定義します。これとは別に、Script をオーサリング（作成・変更）する際には、保存時点で作成者がその Script の statement が扱う Content・Media の操作権限まで実際に持っている必要があり、持っていない場合は保存が拒否されます（Script のエラーを参照）。詳しくは Script の実行セマンティクス、制約、セキュリティで扱います。

エラー

SpaceRole を扱うときに出会うコードです。すべてのリソースに共通するコードは共通エラーを参照してください。

コード	条件
`WGL400020`	その権限マップでは意味を持たないフィルターをルールに入れて、ロールを保存しようとしました。

API

以下のすべてのエンドポイントの基準 URL は https://cma.weegloo.com/v1 であり、Authorization ヘッダーに CMA を認証する Bearer トークンが必要です。ロールの変更（PUT・PATCH）には楽観的並行性制御のために X-Weegloo-Version ヘッダー（現在のリソースの sys.version）を併せて送る必要があります。作成と削除にはこのヘッダーはありません。sys.isLocked が true の標準提供ロールは変更・削除できません。

Space Membership: メンバーの roles に SpaceRole をバインド。
Delivery Access Token: least-privilege の SpaceRole に紐づける配信トークン。
Content Type: 権限ルールが指す Content Type。

リソース構造

システムプロパティ (sys)

権限マップ: contentType・content・media

例 1: Administrator (全権限、標準提供)

例 2: 読み取り専用 (特定の Content Type のみ)

`settings` (Space 設定アクセス)

script (Script 権限)

エラー

API

SpaceRole 一覧取得

SpaceRole 単一取得

SpaceRole 作成

SpaceRole 変更

SpaceRole 部分変更 (JSON Patch)

SpaceRole 削除

リソース構造

システムプロパティ (sys)

権限マップ: contentType・content・media

例 1: Administrator (全権限、標準提供)

例 2: 読み取り専用 (特定の Content Type のみ)

settings (Space 設定アクセス)

script (Script 権限)

エラー

API

SpaceRole 一覧取得

SpaceRole 単一取得

SpaceRole 作成

SpaceRole 変更

SpaceRole 部分変更 (JSON Patch)

SpaceRole 削除

関連ドキュメント

`settings` (Space 設定アクセス)