For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
Theme

おすすめ

本番稼働の開始

パフォーマンスと品質

評価

コストとスループット

安全性とガバナンス

インフラとアクセス

業務運営

API ダッシュボード
ChatGPT を試す

OpenAI プラットフォームの権限管理

ロールベースのアクセス制御（RBAC) を使用して、組織とプロジェクトの権限を管理します。

ロールベースのアクセス制御（RBAC) を使用すると、組織やプロジェクト内で誰がどの操作を行えるかを設定できます。API とダッシュボードには同じ権限が適用されます。たとえば、あるエンドポイント（/v1/chat/completions など）を呼び出せるユーザーは、ダッシュボードの対応するページも利用できます。必要な権限がない場合は、Playground のアップロードボタンなど、関連する UI が無効になります。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 ✓
アシスタント アシスタントの作成と取得 Read, Write Read, Write Read, Write Read, Write Read ✓
スレッド スレッド、メッセージ、実行（Run）の作成と取得 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
Agent Builder Agent Builder でのエージェントとワークフローの作成と管理 Read, Write Read Read, Write Read, Write Read ✓

バッチ権限に伴うアクセス権

バッチ権限には、バッチ入力ファイルの準備、リクエストの実行、結果の取得に必要なアクセス権が含まれます。バッチに含めるリクエストで指定できるエンドポイントは、このアクセス権とは別に定められています。指定できるエンドポイントの一覧は、Batch API ガイドを参照してください。

バッチ権限 追加で付与されるアクセス権
読み取り（api.batch.read） ファイルの読み取り（api.files.read）。対象は /v1/files
書き込み（api.batch.write） バッチの読み取り
モデルの一覧表示（api.model.read と model.read）。対象は /v1/models
ファイルの読み取りと書き込み（api.files.read と api.files.write）。対象は /v1/files
モデル機能へのリクエスト（api.model.request と model.request）。対象は /v1/audio、/v1/chat/completions、/v1/embeddings、/v1/images、/v1/moderations、/v1/realtime、/v1/responses

RBAC の設定

ロールの変更やグループの同期が反映されるまで、最大 30 分かかります。

  1. グループの作成 チームごとにグループを追加します（例：データサイエンス、サポート）。ID プロバイダー（IdP）を使用している場合は、SCIM 同期を有効にしてメンバー構成を最新の状態に保ちます。

  2. カスタムロールの作成 最小権限の原則に従い、必要な権限だけを付与します。たとえば、次のように設定します。

    • モデルテスト担当者：モデルの読み取り、モデル機能へのリクエスト、評価
    • モデルエンジニア：モデル機能へのリクエスト、ファイルの読み取りと書き込み、ファインチューニング
    • アプリ公開担当者：アプリの読み取り、アプリの書き込み

  3. ロールの割り当て

    • 組織レベルのロールは、組織内のすべてのプロジェクトに適用されます。
    • プロジェクトレベルのロールは、そのプロジェクト内でのみ適用されます。 ロールはユーザーとグループに割り当てられます。ユーザーは複数のロールを持つことができ、有効なアクセス権は各ロールが付与する権限の和集合です。

  4. アクセス権の確認 オーナー以外のアカウントを使い、API とダッシュボードの両方で想定どおりにアクセスできることを確認します。ユーザーが必要な範囲を超えて閲覧できる場合は、ロールを調整します。

最小権限の原則に従ってください。まずタスクに必要な最小限の権限を付与し、必要に応じて権限を追加します。

アクセス設定の例

小規模なチーム

  • 中核チームには、モデル機能へのリクエストとファイルの読み取り・書き込みを許可する組織ロールを付与します。
  • アプリごとにプロジェクトを作成します。外部委託先の担当者は、担当するプロジェクトにのみ追加し、プロジェクトレベルのロールを割り当てます。

大規模な組織

  • IdP からグループを同期します（例：研究、サポート、財務）。
  • 職務ごとにカスタムロールを作成し、組織レベルで割り当てます。より厳格なアクセス制御が必要なプロジェクトでは、そのプロジェクト専用のロールだけを付与します。

外部委託先とベンダー

  • 「外部委託先」グループを作成し、組織レベルのロールは付与しません。
  • グループのメンバーを特定のプロジェクトに追加し、読み取り専用など、アクセス範囲を限定したプロジェクトロールを割り当てます。

ユーザーのアクセス権の判定方法

ダッシュボードでは、次のロールを組み合わせてアクセス権を判定します。

  • 組織のロール（直接割り当てられたものと、グループを通じて割り当てられたもの）
  • プロジェクトのロール（直接割り当てられたものと、グループを通じて割り当てられたもの）

有効な権限は、割り当てられたすべてのロールが付与する権限の和集合です。

プロジェクト内で API キーを使ってリクエストを送信すると、システムは API キーに割り当てられた権限を調べ、ユーザーがその権限を付与するプロジェクトロールを持っているか確認します。たとえば、/v1/models にリクエストを送信するには、API キーに api.model.read が割り当てられており、かつユーザーが api.model.read を含むプロジェクトロールを持っている必要があります。

ベストプラクティス

  • 組織構成をグループに反映：IdP のグループ構成をチームに合わせ、ロールは個人単位ではなくグループ単位で割り当てます。
  • 職務の分離：モデルの読み取り、ファイルのアップロード、キーの管理を別々の職務として扱います。
  • プロジェクトの分離：実験用、ステージング用、本番用にそれぞれ別のプロジェクトを使用します。
  • 定期的な見直し：使っていないロールやキーを削除し、機密性の高いキーは定期的に新しいものに切り替えます。
  • オーナー以外のアカウントでのテスト：広く展開する前に、アクセス範囲が想定どおりであることを確認します。