アクセス制御リファレンス

Capgo は ロールベースアクセス制御（RBAC） 各チームメンバーの権限を管理します。ロールは次の範囲で整理されます。 スコープ — 組織全体から個別の bundle まで。

ダッシュボードでのメンバー管理のウォークスルーは、以下をご覧ください。 組織.

---

ロールのスコープ

各ロールはスコープに属し、スコープによってアクセスを許可するリソースが決まります。

適用範囲	適用対象	ユースケースの例
組織	組織全体とそのすべてのアプリ	共同創業者にはSuper Admin、経理担当者にはBilling Managerを付与
アプリ	単一のアプリとそのチャンネル	1つのアプリを担当する外部パートナーには App Developer ロールを付与
チャンネル	アプリ内の単一のチャンネル	QAエンジニアが管理するのは staging チャンネル
Bundle	単一の bundle バージョン	レビュアーには特定のリリースへの閲覧権限が必要

メンバーは スコープごとに1つのロールを 保持できます — 例: 1つの組織ロール、App A でのロール、App B での別のロール。

---

組織のロール

これらのロールはメンバーを招待する際に割り当てられます。組織全体へのアクセス権限を付与します。

ロール	内部名	説明
スーパー管理者	org_super_admin	オーナー相当。組織の削除、請求管理、アプリの譲渡を含む全権限を持ちます。組織の作成者に自動的に付与されます。
管理者	org_admin	フル管理者 — メンバー、アプリ、チャンネルを管理できます。組織の削除、請求情報の更新、アプリの譲渡、ユーザーのSuper Adminへの昇格はできません。
請求マネージャー	org_billing_admin	請求専用アクセス: 請求情報、請求書、請求監査ログの閲覧と更新が可能です。アプリやメンバーへのアクセス権はありません。
メンバー	org_member	組織とそのすべてのアプリへの読み取り専用アクセス。

組織の権限マトリックス

権限	説明	スーパー管理者	管理者	請求マネージャー	メンバー
org.read	組織を表示	✅	✅	✅	✅
org.update_settings	組織名、ロゴ、管理用メールアドレスの編集	✅	✅	❌	❌
org.delete	組織を完全に削除する	✅	❌	❌	❌
org.read_members	メンバー一覧を表示	✅	✅	❌	✅
org.invite_user	新しいメンバーを招待	✅	✅	❌	❌
org.update_user_roles	メンバーのロールを変更（AdminはSuper Adminへ昇格できません — ロール階層により制限されています）	✅	✅	❌	❌
org.read_billing	請求情報と現在のプランを表示	✅	✅	✅	❌
org.update_billing	支払い方法とプランを更新	✅	❌	✅	❌
org.read_invoices	請求書を表示	✅	✅	✅	❌
org.read_audit	組織のアクティビティログを表示	✅	✅	❌	❌
org.read_billing_audit	請求専用の監査ログを表示	✅	✅	✅	❌

注意

組織のロールは、階層下位にあるapp、channel、およびbundleのロールのすべての権限を継承します。 スーパー管理者 が実行できるすべての操作を アプリ管理者 または Channel管理者 すべてのアプリとチャンネルで実行できます。

---

アプリのロール

単一のアプリに限定されます。チームメンバーに組織全体ではなく1つのアプリだけを担当させたい場合に使用します。

ロール	内部名	説明
アプリ管理者	app_admin	1つのアプリを完全にコントロールできます — チャンネル、デバイス、アプリのユーザーロール。アプリの削除や譲渡はできません（これらは組織レベルの操作です）。
アプリ開発者	app_developer	bundleのアップロード、デバイス管理、Native Buildの実行、チャンネル設定の更新が可能です。削除、アプリ設定の変更、チャンネル作成はできません。
アプリアップロード担当	app_uploader	読み取りアクセス + 新しいbundleバージョンのアップロード。
アプリ閲覧者	app_reader	読み取り専用 — 統計、bundle、チャンネル、ログ、デバイス。
アプリプレビュー	app_preview	組織とアプリに紐づくプレビューCIライフサイクル：bundleをアップロードし、プレビューチャンネルを作成します。そのチャンネルを作成すると、そのチャンネルに限りライフサイクル権限が自動的に付与されます。

アプリ権限マトリックス

権限	説明	アプリ管理者	アプリ開発者	アプリアップロード担当	アプリ閲覧者
app.read	アプリの詳細、統計、メタデータの表示	✅	✅	✅	✅
app.update_settings	アプリ設定の編集	✅	❌	❌	❌
app.read_bundles	アップロード済みbundleの一覧表示	✅	✅	✅	✅
app.upload_bundle	新しいbundleバージョンのアップロード	✅	✅	✅	❌
app.create_channel	新しいchannelの作成	✅	❌	❌	❌
app.read_channels	channelを表示	✅	✅	✅	✅
app.read_logs	アップデート配信ログの表示	✅	✅	✅	✅
app.manage_devices	デバイスの割り当て、上書き、解除	✅	✅	❌	❌
app.read_devices	デバイス一覧の表示	✅	✅	✅	✅
app.build_native	Native Buildの実行	✅	✅	❌	❌
app.read_audit	アプリレベルのアクティビティログ表示	✅	✅	✅	✅
app.update_user_roles	アプリスコープのロール割り当て管理	✅	❌	❌	❌
bundle.delete	bundleの削除	✅	❌	❌	❌

注意

app.delete と app.transfer は 組織レベルの操作 — のみ org_super_admin アプリレベルのロールに関係なく、これらを実行できます。

App Preview 権限セット

使用する アプリプレビュー (app_preview) は、アプリ全体や組織全体への広範なアクセス権を持たずに PR プレビューのライフサイクルを管理する、組織とアプリに紐付けられた CI キー向けです。

この app_preview このバインディングでは、以下のアプリレベルの権限のみが付与されます：

権限	可能にする
app.read	選択したアプリの読み取り
app.read_bundles	アップロード済みbundleの読み取り
app.upload_bundle	bundleのアップロード
app.create_channel	channelの作成

App Preview keyがchannelを作成すると、Capgoはそのkeyに新しいchannel専用の channel_preview 子バインディングを自動的に付与します：

権限	可能にする
channel.read	keyが作成したchannelの読み取り
channel.promote_bundle	そのchannelにkey自身のアップロード済みbundleを設定
channel.delete	そのchannelの削除

理由は、 app_preview を保持するためです app.read、そのキーは選択されたアプリ内のチャンネルメタデータを列挙できる場合があります。自動の子バインディングは 管理 境界となります。つまり、そのキーが作成していないチャンネルのライフサイクル変更は許可されません。

Capgo は、各チャンネルを作成し、各bundleをアップロードしたプレビューキーを記録します。そのため、App Previewキーは、必要な非公開プレビューチャンネルをそれぞれ作成し、自身のbundleをプロモートし、さらにそのチャンネルとbundleを Capgo でアトミックに削除できます。 channel delete --delete-bundle既存のデフォルト/メインチャンネルや、他のプレビューキーのチャンネル、あるいは他のキーのbundleに対して、これらの操作を行うことはできません。

以下は含まれません： app.update_settings、デバイスまたはロールの管理、 channel.update_settings, channel.rollback_bundle、デバイスの強制管理、または一般的な bundle.delete.

注意

すべてのApp Previewバインディングは、選択されたアプリを所有する組織に紐付けられたままです。このロールには組織全体のロールは含まれず、組織との関連付けは解除されません。アプリのバインディングを失効または期限切れにすると、そのキーの実効的なライフサイクルアクセスは失われます。

---

チャンネルロール

単一のチャンネルにスコープされます。特定のリリースチャンネルへのアクセスを絞って付与したい場合に便利です。

注意

Channel roles は現在、以下でのみ利用できます： API および CLI 経由 — ダッシュボードでこれらを割り当てる UI はありません。 channel_preview は例外です：Capgo は、App Preview キーがチャンネルを作成したときに、そのキー用に自動で作成します。ダッシュボードでは、 チャンネル権限のオーバーライド を代わりに使用して、ユーザーごとにチャンネルへのアクセスを微調整してください。

ロール	内部名	説明
Channel管理者	channel_admin	1つのチャンネルをフルコントロール：設定、bundleの昇格/ロールバック、強制デバイスの管理。
Channel Viewer	channel_reader	読み取り専用 — 現在のbundle、履歴、強制デバイス、監査ログ。
チャンネルプレビュー	channel_preview	チャンネルを作成したApp Previewキーに自動割り当て：読み取り、自身のbundleの昇格、およびチャンネルの削除。

Channel権限マトリックス

権限	説明	Channel管理者	Channel Viewer	チャンネルプレビュー
channel.read	チャンネルと現在のbundleを表示	✅	✅	✅
channel.update_settings	チャンネル設定の編集 (プラットフォームの切り替え、updateポリシーなど)	✅	❌	❌
channel.delete	チャンネルの削除	✅	❌	✅
channel.read_history	bundle割り当て履歴の表示	✅	✅	❌
channel.promote_bundle	チャンネルの有効なbundleを設定	✅	❌	✅
channel.rollback_bundle	以前のbundleにロールバック	✅	❌	❌
channel.manage_forced_devices	特定のデバイスをこのチャンネルに強制割り当て	✅	❌	❌
channel.read_forced_devices	強制割り当てされたデバイス一覧を表示	✅	✅	❌
channel.read_audit	チャンネルのアクティビティログを表示	✅	✅	❌

---

Bundleロール

単一のbundleバージョンに限定されます。ほとんどのチームはアプリレベルのロールを使用するため、必要になることは稀です。

注意

Bundle roles は現在利用可能です API および CLI 経由 — ダッシュボードでこれらを割り当てる UI はありません。

ロール	内部名	説明
Bundle管理者	bundle_admin	特定のbundleの読み取り、メタデータの更新、および削除が可能です。
Bundle Viewer	bundle_reader	特定のbundleに対する読み取り専用アクセス権限。

---

Channel権限の上書き (Dashboard)

ダッシュボードでは、デフォルトでユーザーのapp roleに基づいてchannelへのアクセス権が決まります。より詳細な制御を行うには、 特定のchannel権限を上書き（override）できます。 app roleを変更せずに、ユーザーまたはグループごとに設定可能です。

上書き設定は、アプリの アクセス権 タブから、ユーザーの横にあるchannel permissionsボタン（シールドアイコン）をクリックして行います。詳細は 組織 — チャンネル権限の上書き のビジュアルガイドを参照してください。

上書き可能な権限

権限	説明	デフォルトの動作
読む	チャンネルと現在のbundleを表示	アプリロールから継承
履歴	bundleの割り当て履歴を表示	アプリロールから継承
bundleを関連付ける	チャンネルの有効なbundleを設定または変更します	アプリロールから継承

各権限は以下のように設定できます：

• デフォルト — app roleから継承（デフォルト）
• Allow（許可） — app roleに関わらず明示的に許可
• Deny（拒否） — app roleに関わらず明示的に拒否

これにより、例えばApp Readerに対して、App Developerに昇格させることなく staging チャンネルへのbundle紐付け権限を付与できます。

---

ロール階層

ロールは階層を形成します。親ロールは すべての権限を継承します。 子ロールの権限も含めて。つまり、 org_admin が実行できるすべての操作を app_admin ができ、さらに下位のロールができるすべてのことも channel_admin でき、といった具合です。

Super Admin (org_super_admin)
  └── Admin (org_admin)
        └── App Admin (app_admin)
              ├── App Developer (app_developer)
              │     └── App Uploader (app_uploader)
              │           └── App Reader (app_reader)
              ├── Bundle Admin (bundle_admin)
              │     └── Bundle Viewer (bundle_reader)
              └── Channel Admin (channel_admin)
                    └── Channel Viewer (channel_reader)

実際の仕組み：

• 一つの 管理者 組織レベルのロールは、下位のロールができるすべてのことを実行できます アプリ管理者 組織内のすべてのアプリで可能です。
• 一つの アプリ管理者 特定のアプリにおいて、以下の権限を持つことができます： Channel管理者 そのアプリ内のすべてのチャンネルで可能です。
• 一つの アプリ開発者 が実行できるすべての操作を アプリアップロード担当 さらに、それ以上の操作も可能です。

権限の階層は 下方向にのみ 適用されます。 channel_admin アプリレベルのロールを持っていても、組織レベルの権限が自動的に付与されることはありません。

---

グループ

ユーザーごとに個別にロールを割り当てる代わりに、 グループ を作成して、そのグループにロールを割り当てることができます。グループの全メンバーに、それらのロールが自動的に継承されます。

グループの仕組み

• グループの所属先 1つの組織 — 複数の組織にまたがることはできません。
• グループは以下のスコープで 任意のスコープにロールの紐付けが可能です: org、app、channel、またはbundle。例えば、あるグループに アプリ開発者 App Aでのroleと、 Channel管理者 App Bの staging channelでのroleを割り当てることができます。
• ユーザーの権限が評価される際、所属するすべてのグループが透過的に解決されます。所属するグループのいずれかが必要な権限を付与していれば、アクセスが許可されます。
• ユーザーは以下のいずれかに所属できます 複数のグループ、すべてのグループの権限は加算されます。
• グループベースの権限は以下にのみ適用されます： ユーザープリンシパル — API キーはグループロールを継承しません。

グループを使う場面

シナリオ	グループなし	グループあり
5名のQAエンジニアが3つのアプリへのDeveloperアクセスを必要とする場合	15件の個別ロールバインディング	1つのグループ + 3つのロールバインディング
QAチームにメンバーが加入	3つのロールバインディングを手動で追加	グループにメンバーを追加
QAチームからメンバーが離脱	3つのロールバインディングを手動で削除	グループからメンバーを削除

APIによるグループ管理

すべてのグループエンドポイントは認証が必要で、以下で提供されます /private/groups.

グループ一覧

curl -X GET "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>"

要件: org.read_members 権限。

グループを作成

curl -X POST "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Quality assurance engineers"
  }'

要件: org.update_user_roles 権限 (スーパー管理者 または 管理者).

グループを更新

curl -X PUT "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Updated description"
  }'

グループを削除

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>"

グループを削除すると、そのグループのロールバインディングもすべて削除されます。メンバーは組織から削除されません。

グループメンバー一覧

curl -X GET "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>"

グループにメンバーを追加する

curl -X POST "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "user_id": "<USER_UUID>" }'

ユーザーは既に組織のメンバーである必要があります。既存のメンバーを追加しても何も起こりません。

グループからメンバーを削除する

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>/members/<USER_UUID>" \
  -H "authorization: <API_KEY>"

注意

グループにロールを割り当てるには、role bindings の API を principal_type: "group" と principal_id group UUID に設定して使用します。

---

APIによるロールの割り当て

メンバー一覧

curl -X GET "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "orgId": "<ORG_ID>" }'

回答例:

[
  {
    "uid": "user-uuid",
    "email": "alice@example.com",
    "image_url": "https://...",
    "role": "org_admin",
    "is_tmp": false
  }
]

メンバーを招待

curl -X POST "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com",
    "invite_type": "org_admin"
  }'

有効な値 invite_type:

値	割り当てられたロール
org_super_admin	スーパー管理者
org_admin	管理者
org_billing_admin	請求マネージャー
org_member	メンバー

メンバーを削除

curl -X DELETE "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com"
  }'

---

CLIによるロールの割り当て

組織一覧

npx @capgo/cli organization list --apikey <API_KEY>

メンバー一覧

npx @capgo/cli organization members <ORG_ID> --apikey <API_KEY>

注意

CLI は現在、メンバー一覧の表示のみをサポートしています。メンバーの招待やロールの変更をプログラムから行う場合は、上記の API エンドポイントを使用してください。

---

カスタムロール

組み込みのロールでほとんどのチーム構成に対応可能です。カスタムロールの作成はロードマップに含まれています。もしチームで必要であれば、 お問い合わせください。具体的なユースケースをお知らせいただくことで、この機能の開発優先度を判断する際の直接的な助けとなります。

アクセス制御リファレンスから続ける

使用している場合 アクセス制御リファレンス ダッシュボードと API の運用を計画するには、これを次と連携させます API の概要 「API の概要」の実装の詳細については、 はじめに 「はじめに」における実装の詳細については、 API キー API Keys の実装の詳細については、 デバイス Devices の実装詳細については、および Bundle Bundlesの実装詳細については