ナレッジベース
ロールと権限レベル
ロールはその人が何をしてよいかを定め、アドレスの付与は何に対してそれをしてよいかを定める。
詳細
- 1人につき2種類の付与があり、両方が一致しなければ何も起こらない。ロールは Settings → Members で設定し、ワークスペース内で何をしてよいかを定める。メールを読む、送る、テンプレートを編集する、ドメインを追加する、API キーを発行する、といったことである。アドレスの付与はアドレス行の Share コントロールで設定し、どのアドレスに対してそれを行ってよいかを、読み取り専用または読み取りと送信のいずれかで定める。送信を含むロールを持っていてもアドレスが1つもなければ、どこからも送信できない。ワークスペース内のすべてのアドレスを読み取り専用で付与されている人も、そのいずれからも送信できない。
- 6つのロールは誰かが作らなくても最初から存在し、どのワークスペースにも同じ6つがある。そのため「Admin」はここでも、ドキュメントでも、API でも同じ意味を持つ。Owner、Admin、Member、Viewer は階段状になっており、上位は下位が持つものをすべて含む。したがって降格はできることを狭めるだけで、別の範囲に入れ替えるわけではない。Developer と Billing はこの階段の段ではない。Developer は連携を構築する役割で、API キー、Webhook、テンプレート、送信を扱えるが、ワークスペースのメールは一切読めない。Billing はプランと請求書を見ることができ、プランと支払い情報を変更でき、メールボックスの設定を読めるが書き込みはできない。これらの権限は編集できる。メンバーにテンプレートを書かせたくないワークスペースはそのチェックを外せばよく、変更はそのロールを明示的に持つ人の次のリクエストから反映される。ロールが明示的に与えられておらず、ロール導入前のアドレス付与によって暗黙的に決まっている人は、明示的に与えられるまで初期状態の既定値のままになる。名前も編集できる。Ops と On-call で回しているワークスペースは、それらを改名することで自らの実態を記述することになり、それこそがこの仕組みの狙いである。
- Owner はあらゆる面で例外である。編集も削除も割り当てもできない。これはワークスペースが紐づくアカウントを表し、後のリリースで追加されるものも含めてすべての権限を持つ。そのため権限の一覧は保存されず、その都度計算される。ワークスペースを他の人に渡すのはロールの変更ではなく譲渡であり、それを行う機能はここには存在しない。
- それ以外に、ワークスペースは同じグループ分けされた表から権限にチェックを入れて、合計24個までの独自ロールを作成できる。チェックには含意がある。「テンプレートを編集」を選ぶと「テンプレートを読む」も一緒に保存される。開けないテンプレートを編集できるロールは、誰かの意図した方針ではなく、チェックの入れ忘れだからである。人や API キーが使っているロールを削除しようとすると、移行先を尋ね、推測はせずに拒否する。ロールが消えた API キーは上限がまったくない状態に戻ってしまい、いま削除されたロールよりも広い権限になってしまうからである。
- API キーはロールに紐づけて発行でき、ロールは2つ目の付与ではなく上限として働く。キーができることは、キー自身のスコープとロールの権限の積であり、リクエストごとに解決される。送信を有効にして作成されたキーでも、Viewer で上限を設けていれば送信できない。ロールを狭めれば、キーをローテーションしなくてもその場で権限が取り消される。アシスタントも同じ一覧に従う。MCP サーバーは呼び出し元の権限からクライアントのツールを組み立てるため、Viewer のクライアントには送信ツールがそもそも含まれない。また、一覧を組み立てた後にセッションがメールボックスを切り替えることがあるため、制限付きのツールはすべて呼び出し時に再確認する。