ワークスペースのロールと権限：5段階のアクセス階層

ワークスペースは最初、1人のメンバーと1つのウォレットから始まります。この段階では、権限はまったく問題になりません。ところが、キャンペーンのためにフリーランスの編集者が加わり、バックエンドのサービスにキーが必要になり、経理の誰かが「全部でいくらかかっているのか」を確認したくなる。そうなると「全員が管理者」という運用は近道ではなく、リスクに変わります。eroqでは、すべてのメンバーが同じ共有クレジット残高から消費するからです。

そのため、eroqのロールはまず「はしご」であり、チェックボックスの表はその次です。5つの段、名前の付いた15の権限、誰が誰に対して操作できるかを決める1つのルール。そして、どの段も誰かにぴったり合わないときのために、権限ごとに個人単位で切り替えられるスイッチがあります。ここではモデルの全体像と、初めての人が必ず驚く1つの挙動、つまりAPIキーを作成した人を降格したときにそのキーがどうなるかを説明します。

5つの段

各段は、1つ下の段のすべての権限に加えて、その段独自の権限を持ちます。考え方はこれだけで、残りは細部です。

オーナー（Owner）。 すべての権限を持ち、ほかの誰も持たない2つの権限、つまりワークスペースを他人に譲渡する権限と、ワークスペースを完全に削除する権限も含みます。オーナーとは、そのワークスペースを作成したアカウントです。

管理者（Admin）。 ワークスペースを運営します。メンバー、請求、ワークスペース設定、APIキー、Webhook、生成、公開、ライブラリ、使用量。譲渡と削除以外のすべてです。

開発者（Developer）。 APIの上に構築します。APIキーの作成と取り消し、Webhookエンドポイントの管理、フルレートでの生成、公開、ライブラリと使用ログの閲覧ができます。請求、招待、設定の権限はありません。APIを組み込むものの、プランを変更できてはならないエンジニアのための段です。

クリエイター（Creator）。 スタジオで制作します。生成、コミュニティの棚への公開、ライブラリと使用量の閲覧ができます。キー、Webhook、設定、請求の権限はありません。デフォルトでは、クリエイターにはワークスペースの1分あたりのレート制限枠の半分が割り当てられます。動画ツールで一日中作業するには十分ですが、同じプランで動いている本番パイプラインを枯渇させるほどではありません。

閲覧者（Viewer）。 作品ライブラリと使用ログを閲覧できます。クレジットは1つも使えません。クライアントや関係者、あるいは何が作られ、いくらかかったかを確認するだけの人のための段です。

権限そのものも暗黙のものではなく、すべて名前が付いています。生成、公開、ライブラリの閲覧、使用量の閲覧、4つのストレージ権限（閲覧、アップロード、削除、設定）、APIキー、Webhook、ワークスペースの設定、メンバーの管理、請求とプラン、オーナー権限の譲渡、ワークスペースの削除です。/dashboard/workspaceの「メンバー」タブにある権限表は、サーバーが実際に適用するのと同じデータから描画されます。つまり、そこに表示されている内容が、そのままリクエスト時の挙動になります。

どの段も合わないとき：権限を1つだけチェックする

はしごはデフォルトとしては正解ですが、最終的な答えとしては不十分です。公開はしてほしいがクレジットは使わせたくない編集者、1か月だけAPIキーが必要だが請求は絶対に見せたくない外部委託者、ウォレットへのチャージだけをしてほしい経理担当者。どれも1つの段には当てはまりません。

そこで、すべての権限はチェックボックスにもなっています。「メンバー」タブでメンバーのアクセスを開くと、ロールが出発点になります。すべてのボックスがロールに基づいてあらかじめ埋められていて、その上で任意の1つをチェックしたり外したりできます。生成にチェックを入れた閲覧者はクレジットを使えるようになり、APIキーのチェックを外した開発者はキーを作成できなくなります。アクセスがロールと異なるメンバーには一覧で小さなカスタムタグが付き、カーソルを合わせると、何が追加・削除されたかが正確に表示されます。

これが混乱を招かないよう、3つのルールがあります。

1. 付与できるのは自分が持っている権限だけです。 開発者はWebhookの権限を持っているので、クリエイターにWebhookをチェックできます。しかし請求とプランは自分が持っていないので、誰に対してもチェックできません。チェックを外すことは、自分より下の相手なら誰に対しても常に可能です。
2. ボックスでランクは変わりません。 メンバーの管理にチェックが入ったクリエイターは、クリエイターより下のメンバーを招待・編集できますが、あくまでクリエイターより下だけです。誰が誰より上かを決めるのは、引き続きはしごです。
3. 譲渡と削除にはボックスがありません。 この2つはオーナーだけのものです。例外はありません。

これらはすべて、その人が参加する前に設定しておくこともできます。招待フォームには、ロール選択の下に同じ表が折りたたまれています。生成にチェックを入れた閲覧者として招待すれば、その人は最初のログインの瞬間からまさにその権限を持ちます。新しいメンバーが意図より多い、あるいは少ない権限を持ってしまう空白期間はありません。

ロールを変更しても、まだ意味のあるボックスは残ります。カスタマイズされた閲覧者をクリエイターに昇格させると、生成のチェックは新しいロールに含まれるため単に消えますが、持っていた請求とプランのチェックは残ります。そしてAPIキーも、ほかのすべてと同じルールに従います。ボックスをチェックしたり外したりすると、ロール変更とまったく同じように、30秒以内にキーへ反映されます。

オーナーが割り当て可能なロールではない理由

オーナーはメンバーシップの行には保存されていません。ワークスペースそのものの属性、つまりワークスペースを作成したアカウントであり、ワークスペースが読み込まれるときに最上段へ引き上げられます。

実装上の細かい話に聞こえるかもしれません。しかし、ここから頼りにできる3つの帰結が生まれます。

1. オーナーは常にちょうど1人です。 「たいてい1人」ではありません。スキーマ上、2人を表現できないのです。
2. うっかりオーナーを作ってしまうことはありません。 ロールを割り当てる管理者の選択欄に、オーナーは表示されません。割り当て可能なロールではないからです。
3. ワークスペースの譲渡は意図的な操作であり、 誰かを昇格させることとは別物です。会社のアカウントを引き渡すことと、同僚に請求へのアクセス権を渡すことは意味が違い、このモデルは両者を決して混同しません。

実務的に言えば、会社のためにワークスペースを用意するなら、18か月後に削除したくなるような個人のログインではなく、会社が管理するアカウントから作成してください。

管理できるのは自分より下のメンバーだけ

2つ目のルールです。メンバーに対して操作できるのは、自分のランクが相手より厳密に上の場合だけです。また、自分と同じかそれより上のロールを付与することは決してできません。

前半も後半も重要なので、2回読んでください。

• 2人の管理者が互いを降格・削除・締め出すことは決してできません。同じランク同士は手を出せないのです。管理者を外す必要があるなら、それはオーナーが行います。
• 開発者は、自分自身もほかの誰かも管理者に昇格させることはできません。管理者は開発者より下ではないからです。
• 招待フォームのロール選択には、自分が付与できる段だけが表示されます。管理者には管理者・開発者・クリエイター・閲覧者が表示されます。開発者には招待に使える段が何も表示されません。招待はメンバー管理の権限だからです。

管理者が横並びのフラットな構成では、揉めごとが起きたときに、マウス操作が一番速い人がワークスペースを乗っ取れてしまいます。はしご構造なら、それは「起こりにくい」ではなく「起こり得ない」ことになります。

APIキーは保有者のロールを引き継ぐ

ここはしっかり押さえておきたい部分です。キーは、独自の権限を持つ別個のIDではありません。 キーは保有しているメンバーのランクを持ち、それが呼び出しのたびに評価されます。

開発者を閲覧者に降格すると、その人のキーは生成できなくなります。キーに一切触れなくても、即座にです。

curl -X POST https://eroq.ai/v1/videos/generations \
  -H "Authorization: Bearer $EROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "eroq-motion-one",
    "prompt": "A courier crosses a wet avenue under a broken streetlight, headlights smearing behind her. Tracking shot, 35mm film, neon noir palette, tense tempo.",
    "seconds": 5,
    "aspect": "9:16"
  }'

{
  "error": {
    "message": "This workspace role cannot spend credits. Ask an admin for Creator access or above.",
    "type": "permission_error",
    "code": "role_forbidden"
  }
}

何が起きなかったかに注目してください。何も課金されておらず、キーは引き続き読み取りができます。降格されたメンバーのキーでも、作品の一覧取得や使用量の閲覧はまだ可能です。これらは閲覧者の権限だからです。止まるのは、取り上げた権限だけです。

オフボーディング（メンバーの離任処理）の手順は、これで全部です。ロールを1回変更するだけで、その人がこれまでに作成したすべてのキーから生成の権限が外れます。どのキーが存在し、どのサービスがそれを使っているかを洗い出す必要はありません。まずロールを変更し、キーの取り消しは後で落ち着いて行えば大丈夫です。ロールの変更は、数秒以内に新しいリクエストへ反映されます。

このチェックはサーバー上の1か所、つまりクレジットが動こうとするまさにその瞬間に置かれています。そのため、新しい生成エンドポイントがチェックを忘れることはありません。

ロールに上乗せする2つのダイヤル

ロールが決めるのは何をできるかです。どれだけできるかは、メンバーごとの2つのダイヤルが決めます。どちらも管理者が「メンバー」タブで設定します。

1分あたりのレート制限の割り当て（パーセンテージ）。 ロール自体の割り当てが上限で（クリエイターは半分からスタート）、メンバーごとの上書きはそれをさらに狭めることしかできません。ロールが許す範囲を超えて広げることは決してできません。

月間クレジット上限。 そのメンバーが暦月のあいだに共有ウォレットから使える量の厳格な上限で、毎月1日にリセットされます。返金分は差し引かれるので、失敗して自動的に返金されたレンダリングが、知らないうちに誰かの枠を食いつぶすことはありません。上限に達すると、謎めいた請求エラーではなく、その数値を明示したはっきりした拒否が返ります。

どちらのダイヤルも必須ではありません。両方を空欄のままにすれば、メンバーはロールが与える権限をそのまま得ます。適切な値の決め方はそれだけで1つのテーマですが、フラットなクレジット制の背景にある考え方はAI APIのクレジット料金設計で解説しています。

無難なデフォルトの割り当て

• バックエンドサービスや外部連携 → 開発者。パイプラインごとにキーを1つ。
• フリーランスの編集者や外部委託者 → クリエイター。契約の規模に合わせた月間上限を設定。
• 支出を承認するプロデューサーやアカウントマネージャー → 管理者。
• クライアント、関係者、監査担当者 → 閲覧者。
• 成果物を法的に所有するアカウント → オーナー。ほかの誰でもありません。

誰かを招待する前に、もう1つ計画に入れておくべき制約があります。プランで使えるシート数です。無料のワークスペースは1シート、個人向けプランはどれもちょうど2シートで、本格的なチームはビジネス向けのプランで運用します。シート数の一覧は/pricingにあり、/faqでも改めて回答しています。

よくある質問

eroqでは管理者同士が互いを削除できますか？

いいえ。メンバーが操作できるのは自分より厳密に下のランクの相手だけなので、同じランク同士は互いに手出しできません。管理者の削除や降格はオーナーの役割です。

チームメンバーを降格するとAPIキーはどうなりますか？

新しいロールでも許可されている操作には引き続き使え、それ以外はできなくなります。閲覧者に降格した場合、キーでライブラリと使用量は読み取れますが、生成の呼び出しはクレジットを消費せずに403 role_forbiddenを返します。

オーナーはほかの人に与えられるロールですか？

ロールとしては与えられません。オーナーはワークスペースを作成したアカウントなので、ロール選択には表示されません。オーナーを移すことはワークスペースそのものの譲渡であり、オーナーだけが行える別の操作です。

2人目が参加する前に、はしごを整えておきましょう。/dashboard/workspaceの「メンバー」タブを開いてください。