チーム管理の概要
チーム管理では、プロジェクトで業務を分離し、メンバーのロールで管理権限を制御し、チーム API キーで実際の呼び出し元を識別します。まずリソースの境界を定義し、その後にメンバーを招待してキーを発行してください。すべてのアプリが同一の認証情報と予算を共有するのは避けてください。
リソースの関係
ワークスペース
├─ メンバーとロール
├─ プロジェクト A（本番）
│ ├─ チームキー
│ ├─ モデルとルーティング方針
│ ├─ 予算
│ └─ 利用履歴
└─ プロジェクト B（テスト）
├─ チームキー
├─ モデルとルーティング方針
├─ 予算
└─ 利用履歴ここで「ワークスペース」はチーム組織を表す概念であり、別途作成必須のリソースを意味しません。プロジェクトが現在の権限・予算・統計の境界で、チームキーはアプリ、環境、Agent、自動化タスクを識別します。メンバーは複数のプロジェクトに参加できますが、プロジェクトごとの所属は個別に権限を付与してください。
推奨する導入順序
- アプリと環境ごとにプロジェクトを作成します（例
customer-service-productionとcustomer-service-staging）。 - プロジェクトに予算を設定し、チームキーにルーティングモードと許可するモデルを設定します。
- メンバーを招待し、必要最小限のロールを割り当てます。
- サービス、Agent、CI のそれぞれにチームキーを作成します。
- 利用履歴ページで、プロジェクトとキー別に費用・レイテンシ・エラー・再試行を確認します。
- 予算、エラー率、異常トラフィックのアラートを設定します。
よくある分割方法
| 場面 | 推奨する境界 |
|---|---|
| 同一アプリの開発と本番 | プロジェクト 2 個、キー 2 組、予算は個別 |
| 複数の業務チーム | 業務ごとに最低 1 つのプロジェクト、メンバーはプロジェクト単位で権限付与 |
| 複数の Agent | Agent ごとにチームキー 1 本。限度額と追跡が容易になります |
| 外注または臨時メンバー | プロジェクトとロールを限定し、終了後にすぐ削除 |
| CI/CD | 専用キーとし、デプロイに必要なモデルと予算だけを許可 |
セキュリティと監査の原則
- 本番サービスで個人キーを使用しません。
- アプリ・環境・Agent でチームキーを共有しません。
- 管理者権限は、プロジェクト・予算・メンバーの担当者にのみ付与します。
- メンバーの離脱時は、まずアクセス可能なキーを取り消し、その後で所属を削除します。
- Trace と利用履歴は請求・診断用のリクエストメタデータを保持しますが、プラットフォームはプロンプトや応答内容をデータベースに書き込みません。
- 未使用のキー、異常な費用、429、再試行回数、見覚えのないモデル呼び出しを定期的に点検します。