Skip to main content

Command Palette

Search for a command to run...

チームとEnterprise

組織グループ

組織グループ は、Engineering、Contractors、Pilot Users など、Cherri Code Enterprise における組織レベルのコホートです。メンバーは組織内のどのチームからでも追加でき、1 人のユーザーが同時に複数のグループに所属できます。

グループには 2 つの役割があります。

  1. コホートに設定を適用する。 支出上限、モデルアクセス、エージェント制御が、チームをまたいでグループメンバーに適用されます。
  2. チームを連携させる。 グループをチームにマッピングすると、Cherri Code がそのチームのメンバーシップとロールをコホートに合わせて維持します。

メンバーシップは手動で管理することも、SCIM を介してアイデンティティプロバイダーから同期することもできます。このページではまず SCIM 同期のセットアップについて説明し、次にグループを使用してチームのメンバーシップとロールを管理する方法を紹介します。

前提条件

  • 組織 を含む Cherri Code Enterprise プラン
  • Org admin の権限。Org admins はグループを作成・管理できます。Team admins はできませんが、marketplace access など、チームの設定でサポートされている場合はグループを選択できます
  • SCIM で同期されたグループの場合: 組織に接続された SCIM プロビジョニング

SCIM 同期グループを設定する

SCIM 同期グループは、アイデンティティプロバイダーのディレクトリグループを反映したものです。誰を所属させるかはアイデンティティプロバイダーが決定します。グループに何を許可するかは Cherri Code が決定します。

SCIMを接続する

SCIM プロビジョニングに従ってアイデンティティプロバイダーを接続し、プッシュグループプロビジョニングを有効にして、ディレクトリグループがCherri Codeに同期されるようにします。組織レベルでは、各アイデンティティプロバイダー接続に組織の設定内のSCIM Directoryセクションがあり、Sync Directoryを選択すると、その接続のディレクトリをCherri Codeに登録できます。

組織レベルでの補足事項は次の2点です。

  • 1つのアイデンティティプロバイダー接続でサポートされるSCIMディレクトリは1つのみです。そのため、組織は自身のアイデンティティプロバイダーを通じて1つのディレクトリを持ちます。一方で、リンクされたチームがそれぞれ独自のアイデンティティプロバイダーを運用している場合は、各接続に対応するSCIMディレクトリがあるため、組織として複数のディレクトリを利用できます。接続された各ディレクトリのディレクトリグループは、同期されたグループを作成する際に利用できます。
  • チームが組織に参加する前にそれぞれ独自のアイデンティティプロバイダーを設定していた場合は、組織管理者がまずそれらを1つの共有組織アイデンティティプロバイダーに統合できます。チームのアイデンティティプロバイダーを統合するを参照してください。

グループを作成

1

Groupsを開く

ダッシュボードで、プロフィールメニューから Organization -> Groups を開き、 Add を選択します。

2

グループを作成する

グループ名を入力し、Type を Synced に設定してから、同期元の Directory group を選択します。複数のディレクトリが接続されている場合は、 各ディレクトリのグループが選択欄に表示されます。

3

設定を行う

グループの設定ページで、支出上限、モデルアクセス、エージェント制御を 設定します。グループ設定を行う を参照してください。

手動グループを作成する場合は、Type を Manual に設定します。その後、管理者はダッシュボード、CSV のインポート、または Organization API を通じてメンバーシップを管理できます。既存のグループを後から SCIM に接続するには、そのグループの Settings を開き、SCIM directory group の横にある Connect を選択します。

同期されるものと、引き続き管理できるもの

SCIM 同期グループでは:

  • メンバーシップはアイデンティティプロバイダーが管理します。 Cherri Code では、同期済みメンバーは参照専用として表示され、次回の同期で上書きされる手動変更は無効になります。誰を所属させるかを変更するには、アイデンティティプロバイダー内のディレクトリグループを更新してください。
  • 設定はお客様が管理します。 Spend limits、モデルアクセス、エージェント制御、チームのマッピングは Cherri Code 内で管理され、ディレクトリから同期されることはありません。
  • ロールはお客様が管理します。 チームのロールは、アイデンティティプロバイダー内のロール属性からではなく、Cherri Code でグループとチームのマッピングに設定したロールから決まります。詳しくは マッピングからチームのロールを設定する を参照してください。

アイデンティティプロバイダーでのメンバーシップの変更は自動的に同期されます。よくある同期の問題については、SCIM FAQを参照してください。

メンバーを管理

グループを開き、Membersを選択すると、メンバー構成を確認できます。

手動グループでは、管理者は次の操作を行えます。

  • 既存の組織メンバーを追加する
  • CSV でメンバーをインポートする
  • メンバーを別のグループに移動する
  • メンバーを削除する
  • メンバー一覧を検索して並べ替える

SCIM 同期グループでは、メンバー一覧は参照専用です。メンバー構成はアイデンティティプロバイダーで管理してください。

グループを編集または削除する

グループを開くと、名前を変更したり、設定を変更したりできます。手動グループの場合は、ここでメンバーも変更できます。

グループを削除すると、支出上限やモデルアクセスなど、そのグループと設定が削除されます。メンバーのアカウントは削除されず、メンバーは他のグループや自身のチーム、またはユーザーごとの設定で付与されたアクセスを維持します。

グループ設定を行う

グループを開いて 設定 を選択します。グループ設定はグループ内の全員に適用され、そのうえで各ユーザーのチーム設定と組み合わされます。重複する設定がある場合、最も許可範囲が広くなる結果が採用されるため、チームレベルでは厳格なデフォルトを設定し、選択したコホートへのアクセスを広げるためにグループを使用してください。グループ設定とチーム設定の組み合わせ方を参照してください。

支出上限

グループにユーザーごとの月間支出上限を設定します。ユーザーが複数のグループに所属している場合やチームの支出上限もある場合、適用可能な上限のうち最も高いものが適用されます。たとえば、チームのデフォルトがより厳しく、グループにより高い上限が設定されている場合は、そのユーザーにはグループの上限が適用されます。グループの上限が、より緩いチーム設定より低い場合でも、そのユーザーに対する制限がより厳しくなることはありません。

モデルアクセス

Models タブを使用して、グループメンバーが使用できるモデルを管理します。これは、段階的なロールアウト、承認、または全員に対して有効になっていないモデルが必要なコホートに適しています。

モデルアクセスは、チーム設定との和集合です。チームまたはユーザーが属するいずれかのグループで許可されている場合、アクセスが付与されます。チームもグループも、もう一方を完全に上書きすることはなく、最も許容範囲の広い設定が適用されます。まずチームのデフォルトを厳しめに設定し、その後グループごとにアクセスを広げます。チーム (またはユーザーが属する別のグループ) がすでに許可しているモデルを、グループで取り上げることはできません。

個人用 API キー (BYOK) の設定は、チームの Team Settings → Models ページで行います。グループの Models 設定では BYOK を設定しません。

チーム側から見た同じ優先順位ルールについては、モデルとインテグレーションの管理を参照してください。

Auto-run と Smart Auto

Groups では、利用可能な場合、Auto-run や Smart Auto の設定を含むグループレベルのエージェント制御を設定できます。

チームとグループの両方で同じ Auto-run 設定が定義されている場合、Cherri Code は各フィールドを個別にマージします。非アクティブなポリシーはこのマージに含まれません。チームのポリシーが無効で、グループのポリシーがアクティブな場合は、グループのポリシーが適用されます。

設定チームとグループの値の組み合わせ方
実行モード和集合。どちらかのレベルで有効になっていれば、そのモードを利用できます: Allowlist、Auto-review、または Run Everything。
ターミナルコマンドの許可リスト重複を除いた和集合。どちらかのレベルで許可されているコマンドは許可されます。
ファイル削除保護どちらかのレベルで有効になっていれば有効になります。
ブラウザ保護どちらかのレベルで有効になっていれば有効になります。
サンドボックス化モードより緩い設定が優先されます。disabled は enabled より優先されるため、サンドボックス化が有効になるのは両方のレベルで有効になっている場合のみです。
サンドボックスのネットワークより緩い設定が優先されます。user_controlled は always_disabled より優先されるため、ネットワークが常に無効になるのは両方のレベルで always_disabled が設定されている場合のみです。
サンドボックスの Git アクセスサンドボックスのネットワークと同じです: user_controlled は always_disabled より優先されます。

複数のグループが同じユーザーに適用される場合、Cherri Code はそれらのグループ間でも同じフィールド単位のマージルールを適用します。例外は Auto-review の指示で、グループで指示が定義されている場合、そのユーザーについてはチームの指示を置き換えます。

チーム マーケットプレイスへのアクセス

チーム管理者は、チーム マーケットプレイスのアクセスを選択したグループに制限できます。Dashboard -> Plugins & MCPs を開き、マーケットプレイスを選択してから、Marketplace Settings -> Marketplace Access でグループを選択します。

マーケットプレイスの対象範囲は、その所有元のチーム内に限定されます。グループを選択すると、そのチームにも所属しているグループメンバーにのみアクセスが付与されます。チーム管理者は引き続きアクセスでき、グループが選択されていないマーケットプレイスはチーム内の全員に公開されます。

既存のマーケットプレイスでチームのディレクトリグループを使用している場合、それらの割り当ては維持されます。Cherri Code がそれらを移行することはありません。

グループを使ってチームを運用する

グループは、設定だけでなく、チームメンバーシップも制御できます。グループをメンバーシップ ソースとしてチームにマッピングすると、Cherri Code はそのチームのメンバー構成をグループと同期した状態に保ちます。誰かがそのグループに参加または離脱すると、マッピングされたチームでのメンバーシップにも自動的に反映されます。

SCIM と組み合わせることで、ディレクトリから Cherri Code のチームまでの一連の流れを構築できます。つまり、アイデンティティプロバイダーがディレクトリグループを更新し、同期が Organization Group を更新し、マッピングがチームを更新します。

グループをチームにマッピングする

手動または SCIM 同期グループである Organization Group をチームにマッピングします。アイデンティティプロバイダー内のディレクトリグループでチームを管理するには、まずそのディレクトリグループを Organization Group に同期してから、そのグループをチームにマッピングします。1 つのチームには複数のグループを同時にマッピングでき、チームの名簿にはそれらすべてのメンバーが含まれます。

チームを作成するときは、Membership Type を Synced に設定し、Membership sources の下に 1 つ以上のグループを追加します。チームのメンバーは、一覧にあるグループの和集合になります。グループを削除すると、そのグループとの同期は停止します。

メンバーシップの反映方法

チームに少なくとも 1 つのマッピング済みグループがあると、同期 がそのチームのメンバー全体を管理します。

  • 追加: マッピング済みグループに誰かが参加すると、その人がチームに追加されます。
  • 削除: 誰かがグループから外れると、その人はチームから削除されます。ただし、同じチームにマッピングされている別のグループに引き続き含まれている場合は除きます。
  • 手動編集は無効です。 同期 されたチームでは、Admins はダッシュボードからメンバーを追加または削除できません。代わりに、マッピング済みグループを通じてメンバーシップを変更してください。

同期 によって誰かが Organization 内の最後のチームから削除されると、その人は Organization からも外れます。org-level の ロール を直接持つメンバー (org admins など) は、Organization への access を維持します。

マッピングを削除すると、残っているマッピング済みグループに基づいてチームのメンバー構成が再計算されます。削除されたグループのみに含まれていたメンバーはチームから削除され、別のマッピング済みグループに引き続き含まれている人は残ります。最後のマッピングを削除しても、誰も削除されません。現在のメンバーはチームに残り、チームは手動管理に戻ります。

マッピングからチームのロールを設定する

マッピングでは、チームのロールとして member、admin、またはロールなしを割り当てることもできます。たとえば、Engineering Leads グループを admin ロールでマッピングすると、そのグループの全員がそのチームの admin になります。ロールは Cherri Code でマッピングごとに設定します。アイデンティティプロバイダーのロール属性は同期されません。各ロールで実行できることについては、メンバー、ロール、シートタイプを参照してください。

ロールの設定は、メンバーシップの同期とは独立して機能します。

  • マッピングにロールがある: 同期によってそのロールが強制され、チーム上のロールはダッシュボードから変更できなくなります。
  • どのマッピングにもロールがない: メンバーは Member ロールで追加され、admin は引き続きダッシュボードでロールを変更できます。

ユーザーが同じチームにマッピングされた複数のグループに所属している場合は、それらのマッピングの中で最も高いロールが適用されます。たとえば、あるグループでは admin、別のグループでは member としてマッピングされているユーザーは admin になります。また、ロールが割り当てられている場合は、ロールなしのマッピングより優先されます。

チームフォームで Use groups to set role を有効にしてから、各グループごとに Member または Admin を選択します。ロールを管理せずにメンバーを同期するには、トグルをオフのままにします。

グループ設定とチーム設定の組み合わせ方

ユーザーの有効な設定は、そのユーザーのチームと、所属するすべてのグループから決まります。基本ルールは、最も許可範囲の広いものが優先されるということです。

設定タイプグループとチーム間での適用方法
支出上限該当する中で最も高いユーザーごとの上限が適用されます。
モデルアクセス和集合。チームまたはいずれかのグループが許可していれば、アクセスが付与されます。
Auto-run と Smart Autoフィールド単位でマージされ、各フィールドでは最も制約の緩い値が優先されます。上の表を参照してください。
Auto-review の指示そのユーザーについては、グループの指示がチームの指示に置き換わります。
チームのロール上記のマージルールではなく、グループからチームへのマッピングによって設定されます。

モデルアクセスについては、チームとグループのどちらか一方がもう一方を完全に上書きすることはありません。どちらかがモデルを許可していれば、ユーザーはそのモデルを使用できます。最も厳格なベースラインをチームに設定し、グループで範囲を広げます。ユーザーごとの上書きやチームのディレクトリグループも含めた階層的な見方については、制限と権限の組み合わせ方を参照してください。

API を使用してグループを管理する

Organization API を通じて、グループの作成、一覧取得、更新、削除を行います。API では、グループのメンバー一覧の取得や、手動グループへのメンバーの追加・削除も可能です。グループのルートでは Organization API キーを使用し、g_ プレフィックスを持つグループの id を指定します。グループのレスポンスでは grp_ プレフィックスを持つ publicId も返されます。名前でグループを見つけるには、name クエリパラメータを指定して List Organization Groups を呼び出します。

チームの ディレクトリグループ は別のリソースです。これらのグループは、/teams/directory-groups の Team Admin API ルートで管理し、team_group_… の id を使用します。これらのルートは、組織グループの id (g_) や publicId (grp_) の値を受け入れません。

関連ドキュメント

Organization Groups はエンタープライズで利用できます

組織レベルの管理について詳しくは、お問い合わせください。

Contact Sales