ロールベースのアクセス制御（RBAC）を使用すると、組織とプロジェクト全体で、誰にどの操作を許可するかを API とダッシュボードの両方について決められます。どちらにも同じ権限が適用されます。たとえば、あるエンドポイント（/v1/chat/completions など）を呼び出せるユーザーは、対応するダッシュボードのページも使用できます。必要な権限がなければ、関連する UI（Playground の アップロード ボタンなど）は無効になります。RBAC では、次のことができます。
- ユーザーをグループ化し、大規模に権限を割り当て
- 必要な権限だけを持つカスタムロールを作成
- 組織またはプロジェクト単位でアクセス範囲を設定
- ダッシュボードと API の両方に一貫した権限を適用
主要なコンセプト
- 組織：最上位のアカウントです。組織ロールでは、すべてのプロジェクトにわたるアクセスを付与できます。
- プロジェクト：キー、ファイル、リソースのためのワークスペースです。プロジェクトロールは、そのプロジェクト内に限ってアクセスを付与します。
- グループ：ロールを割り当てられるユーザーの集まりです。ID プロバイダーから SCIM 経由でグループを同期すると、メンバー構成を自動的に最新の状態に保てます。
- ロール：モデルへのリクエストやファイルへの書き込みなどの権限をまとめたものです。組織用のロールは 組織設定で、特定のプロジェクト用のロールはそのプロジェクトの設定で作成できます。作成した組織ロールやプロジェクトロールは、ユーザーまたはグループに割り当てられます。ユーザーは複数のロールを持つことができ、各ロールで許可されるアクセス範囲の和集合が、そのユーザーのアクセス範囲になります。
- 権限：ロールが許可する具体的な操作です。たとえば、モデルへのリクエスト、ファイルの読み取りや書き込み、キーの管理などがあります。
権限
次の表に、利用可能な権限、それらを含むプリセットロール、カスタムロールで設定できるかどうかを示します。
| 対象 | 許可される操作 | 組織オーナーの権限 | 組織リーダーの権限 | プロジェクトオーナーの権限 | プロジェクトメンバーの権限 | プロジェクト閲覧者の権限 | カスタムロールで設定可能 |
|---|---|---|---|---|---|---|---|
| モデルの一覧取得 | この組織がアクセスできるモデルの一覧取得 | Read | Read | Read | Read | Read | ✓ |
| グループ | グループの表示と管理 | Read、Write | Read | Read、Write | Read、Write | Read | |
| ロール | ロールの表示と管理 | Read、Write | Read | Read、Write | Read、Write | Read | |
| 組織管理 | 組織のユーザー、プロジェクト、招待、管理 API キー、レート制限の管理 | Read、Write | |||||
| 使用状況 | 使用状況ダッシュボードの表示とエクスポート | Read | ✓ | ||||
| 外部キー | Enterprise Key Management 用のキーの表示と管理 | Read、Write | |||||
| IP 許可リスト | IP 許可リストの表示と管理 | Read、Write | |||||
| mTLS | 相互 TLS 設定の表示と管理 | Read、Write | |||||
| OIDC | OIDC 構成の表示と管理 | Read、Write | |||||
| モデルの機能 | チャット補完、音声、埋め込み、画像へのリクエスト送信 | Request | Request | Request | Request | ✓ | |
| Assistants | Assistants の作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| スレッド | スレッド、メッセージ、実行の作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| 評価 | 評価の作成、取得、削除 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| ファインチューニング | ファインチューニングジョブの作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| ファイル | ファイルの作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| ベクトルストア | ベクトルストアの作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | ✓ | |
| Responses API | レスポンスの作成 | Read、Write | Read、Write | Read、Write | Read、Write | ✓ | |
| プロンプト | Responses API と Realtime API のコンテキストとして使用するプロンプトの作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| Webhook | プロジェクト内の Webhook の作成と表示 | Read、Write | Read | Read、Write | Read、Write | Read | ✓ |
| データセット | データセットの作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| アプリ | ダッシュボードでアプリを作成、管理し、レビューに提出 | Read、Write | ✓ | ||||
| トンネル | 組織をスコープとするトンネルの確認、使用、管理 | Read、Use、Manage | ✓ | ||||
| プロジェクト API キー | ユーザーが自分の API キーを管理するための権限 | Read、Write | Read、Write | Read、Write | Read、Write | Read | ✓ |
| プロジェクト管理 | 管理 API を通じたプロジェクトのユーザー、サービスアカウント、API キー、レート制限の管理 | Read、Write | Read、Write | ||||
| バッチ | バッチジョブの作成と管理 | Read、Write | Read、Write | Read、Write | Read、Write | Read | |
| サービスアカウント | プロジェクトのサービスアカウントの表示と管理 | Read、Write | Read、Write | ||||
| 動画 | 動画の作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | ||
| 音声 | 音声の作成と取得 | Read、Write | Read、Write | Read、Write | Read、Write | Read | |
| Agent Builder | Agent Builder でのエージェントとワークフローの作成と管理 | Read、Write | Read | Read、Write | Read、Write | Read | ✓ |
バッチ権限に含まれるアクセス権
バッチ権限には、バッチ入力ファイルの準備、リクエストの実行、結果の取得に必要なアクセス権が含まれます。この実効的なアクセス権と、バッチ内で送信できるリクエストの対象エンドポイントは別です。対象エンドポイントは、Batch API ガイドに記載されています。
| バッチ権限 | 追加で付与されるアクセス権 |
|---|---|
読み取り（api.batch.read） | /v1/files に対するファイルの読み取り（api.files.read） |
書き込み（api.batch.write） | バッチの読み取り/v1/models に対するモデル一覧の取得（api.model.read と model.read）/v1/files に対するファイルの読み取りと書き込み（api.files.read と api.files.write）/v1/audio、/v1/chat/completions、/v1/embeddings、/v1/images、/v1/moderations、/v1/realtime、/v1/responses に対するモデル機能へのリクエスト（api.model.request と model.request）/v1/videos に対する動画の読み取りと書き込み（api.videos.read と api.videos.write） |
RBAC の設定
ロールの変更とグループの同期が反映されるまで、最大 30 分 かかります。
-
グループの作成 チームごとにグループ（「データサイエンス」「サポート」など）を追加します。IdP を使用している場合は、グループのメンバー構成を最新に保つために SCIM 同期を有効にします。
-
カスタムロールの作成 最小限の権限から始めます。以下に例を示します。
- モデルテスト担当者：モデルの読み取り、モデル機能へのリクエスト、評価
- モデルエンジニア：モデル機能へのリクエスト、ファイルの読み取り／書き込み、ファインチューニング
- アプリ公開担当者：アプリの読み取り、アプリの書き込み
-
ロールの割り当て
- 組織レベル のロールは、組織全体（組織内のすべてのプロジェクト）に適用されます。
- プロジェクトレベル のロールは、そのプロジェクトにのみ適用されます。 ロールは ユーザー と グループに割り当てられます。ユーザーは複数のロールを持つことができ、アクセス権は各ロールの権限の 和集合となります。
-
確認 オーナー以外のアカウントを使い、API とダッシュボードで想定どおりにアクセスできることを確認します。ユーザーが必要以上の情報を閲覧できる場合は、ロールを調整します。
最小権限の原則に従います。タスクに必要な最小限の権限から始め、必要に応じて権限を追加します。
アクセス設定の例
小規模なチーム
- 中核となるチームに、モデル機能へのリクエストとファイルの読み取り/書き込みの権限を含む組織レベルのロールを付与します。
- アプリごとにプロジェクトを作成します。外部委託者は該当するプロジェクトにのみ追加し、プロジェクトレベルのロールを付与します。
大規模な組織
- IdP からグループ（例：「リサーチ」「サポート」「財務」）を同期します。
- 業務ごとにカスタムロールを作成し、組織レベルで割り当てます。より厳密な管理が必要なプロジェクトでは、プロジェクト固有のロールのみを付与します。
外部委託者とベンダー
- 組織レベルのロールを持たない「外部委託者」グループを作成します。
- そのグループを特定のプロジェクトに追加し、読み取り専用アクセスなど、権限の範囲を絞ったプロジェクトロールを付与します。
ユーザーのアクセス権の評価方法
ダッシュボードでは、以下を組み合わせます。
- 組織 で割り当てられたロール（直接の割り当てとグループ経由の割り当て）
- プロジェクト で割り当てられたロール（直接の割り当てとグループ経由の割り当て）
実際に適用される権限は、割り当てられたすべてのロールの権限の 和集合 です。
プロジェクト内の API キーを使ってリクエストする場合は、その API キーに割り当てられた権限を確認し、ユーザーがそれらの権限を付与するプロジェクトロールを持っていることを確認します。たとえば、/v1/models にリクエストする場合は、API キーに api.model.read が割り当てられている必要があり、ユーザーも api.model.read を含むプロジェクトロールを持っている必要があります。
ベストプラクティス
- 組織構成をグループに反映：IdP にチーム構成を反映し、個人ではなくグループにロールを割り当てます。
- 職務の分離：モデルの読み取り、ファイルのアップロード、キーの管理をそれぞれ分離
- プロジェクトの分離：実験、ステージング、本番環境を別々のプロジェクトに分けます。
- 定期的なレビュー：使用していないロールやキーを削除し、機密性の高いキーをローテーションします。
- オーナー以外のアカウントでテスト：広く展開する前に、アクセス権が想定どおりであることを確認します。