# プログラムによるユーザーアクセス制御の管理 このガイドでは、Hub API を使用して組織メンバーのロールおよびリソースグループのメンバーシップを管理する方法を説明します。具体的には、メンバーの組織ロールおよびリソースグループの割り当ての変更、リソースグループの一覧表示、グループへのユーザーの追加、およびバッチワークフローについてです。 **目次:** - [APIでメンバーのロールを変更する](#change-member-role-via-api) — メンバーの組織ロールとリソースグループの割り当てを設定します（1リクエストにつき1メンバー）。 - [Resource Groups API](#resource-groups-api) — リソースグループの一覧を取得し、ユーザーを追加します。 - [API による自動参加の設定](#configure-auto-join-via-api) — リソースグループで自動参加を有効化または無効化します。 - [API経由で外部のコラボレーターを招待](#invite-external-collaborators-via-api) — 組織外のユーザーをリソースグループに招待します。 - [API経由でメンバーのアカウントタイプを変更する](#change-member-account-type-via-api) — メンバーを外部コラボレーターに変換するか、元に戻す。 --- ## APIでメンバーのロールを変更する Hub API を使用して、メンバーの**組織ロール**（No Access / Read / Contributor / Write / Admin）を変更し、必要に応じて**リソースグループ**内のロールも変更できます。この API は**リクエストごとに 1 人のメンバー**のみを更新します。複数のメンバーのロールを変更するには、ループ内で API を呼び出します（例は下記を参照）。 **OpenAPI リファレンス:** PUT /api/organizations/{name}/members/{username}/role ### 前提条件 - 組織には**サブスクリプションプラン**（TeamまたはEnterpriseなど）が必要です。それ以外の場合、エンドポイントは402を返します。 - 組織のメンバーとして認証されており、組織に対して**Write**（または Admin）権限を持っている必要があります。 - 対象ユーザーは、すでに組織の**メンバー**である必要があります。 ### ベースURLと認証 - **ベースURL:** `https://huggingface.co` - **認証:** リクエストヘッダーにトークンを送信します: ```http Authorization: Bearer ``` [https://huggingface.co/settings/tokens](https://huggingface.co/settings/tokens) で、組織にスコープを限定した「Write access to organizations settings / member management」権限を持つ、細粒度のトークンを作成してください。 ### メンバーのロールを変更するエンドポイント **リクエスト** ```http PUT /api/organizations/{org_name}/members/{username}/role Authorization: Bearer Content-Type: application/json { "role": "read", "resourceGroups": [] } ``` - **パスパラメータ** - `org_name`: 組織スラッグ（例: `my-org`）。 - `username`: 変更対象のメンバーの Hugging Face **username**。 - **本文** - `role`（必須）：メンバーの**組織レベル**のロール。以下のいずれか：`"no_access"`、`"read"`、`"contributor"`、`"write"`、または`"admin"`。 - `resourceGroups` (任意): このユーザーのリソースグループ割り当ての配列。各項目: - `id`: リソースグループの ID（24 文字の 16 進文字列。[リソースグループ一覧 API](#list-resource-groups)から ID を取得します）。 - `role`: そのリソースグループにおけるロール: `"read"`、`"contributor"`、`"write"`、`"admin"`、または `"inherit"`。 - `resourceGroups`を省略するか`[]`を渡すと、ユーザーはすべてのリソースグループから削除されます。組織ロールのみを変更してリソースグループを変更しない場合は、現在のリソースグループのメンバーシップを渡してください（ボディは常に組織ロールとリソースグループの両方のリストを設定します）。 **例 (curl) – 組織のロールを "read" に設定し、リソースグループを指定しない（ユーザーが以前所属していたリソースグループからすべて削除する）** ```bash curl -s -X PUT \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d '{"role":"read","resourceGroups":[]}' \ "https://huggingface.co/api/organizations/my-org/members/member1/role" ``` **例 (curl) – 組織ロールとリソースグループロールを設定（現在のグループを上書き）** ```bash curl -s -X PUT \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d '{"role":"write","resourceGroups":[{"id":"507f1f77bcf86cd799439011","role":"read"}]}' \ "https://huggingface.co/api/organizations/my-org/members/member2/role" ``` **成功レスポンス:** ステータス `200 OK`、ボディ: `{ "success": true }`。 **典型的なエラー** - `400` — 無効なボディ（例：無効なロールまたはリソースグループの`id`）。 - `402` — 組織にサブスクリプションプランがありません。 - `403` — 許可されていません（例：組織に Write 権限がない、またはリソースグループが組織内にない場合）。 - `404` — 組織またはユーザーが見つかりません。 ### 複数のメンバーを更新する APIは**リクエストごとに1人のメンバー**を変更します。一括処理用のエンドポイントは存在しません。多数のメンバーを更新するには、ユーザー名ごとに1回ずつエンドポイントを呼び出してください（リストやCSVからなど）。 **例: Bash – ユーザー名をループし、全員に同じロールを付与** ```bash ORG_NAME="my-org" ROLE="read" for username in member1 member2 member3 member4; do echo "Setting $username to $ROLE ..." curl -s -w "\n%{http_code}" -X PUT \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"role\":\"$ROLE\",\"resourceGroups\":[]}" \ "https://huggingface.co/api/organizations/$ORG_NAME/members/$username/role" echo "" done ``` **例: Python – ユーザー名をループで処理する** ```python import os import requests BASE_URL = "https://huggingface.co" HF_TOKEN = os.environ.get("HF_TOKEN", "") def change_member_role(org_name: str, username: str, role: str, resource_groups: list | None = None): payload = {"role": role, "resourceGroups": resource_groups or []} r = requests.put( f"{BASE_URL}/api/organizations/{org_name}/members/{username}/role", headers={"Authorization": f"Bearer {HF_TOKEN}", "Content-Type": "application/json"}, json=payload, ) if r.status_code != 200: raise RuntimeError(f"{r.status_code}: {r.text}") return r.json() org_name = "my-org" role = "read" for username in ["member1", "member2", "member3", "member4"]: print(f"Setting {username} to {role} ... ", end="") try: change_member_role(org_name, username, role) print("OK") except Exception as e: print(f"Failed: {e}") ``` ユーザーごとに異なるロールを設定するには、`(username, role)`のペア（CSVなどから取得）をループで処理し、各ペアに対して`change_member_role`を呼び出します。 --- ## リソースグループAPI 以下のエンドポイントを使用すると、リソースグループを**一覧表示**し、ユーザーを**追加**できます。既存のメンバーの組織レベルのロールやリソースグループの割り当てを**変更**するには、上記の[APIによるメンバーロールの変更](#change-member-role-via-api)を参照してください。 **OpenAPI リファレンス:** [リソースグループ](https://huggingface.co/spaces/huggingface/openapi#tag/resource-groups) **目次 — APIアプローチ:** | 目標 | セクション | | -------------------------------------------------- | ----------------------------------------------------------------------- | | リソースグループに**1つ**のユーザーを追加 | [リソースグループにユーザーを追加する](#add-users-to-a-resource-group) | | **同じ**ユーザーを**多数の**リソースグループに追加します | [APIをループして一括追加](#batch-add-by-looping-over-the-api) | | グループごとに**異なる**ユーザーを追加 | [APIをループして一括追加](#batch-add-by-looping-over-the-api) | ### ベースURLと認証 - **ベースURL:** `https://huggingface.co` - **認証:** 以下のいずれかを使用します: - **アクセストークン（スクリプトでの使用を推奨）:** [https://huggingface.co/settings/tokens](https://huggingface.co/settings/tokens) で、対象を自分の組織に限定し、「Write access to organizations settings / member management」権限を持つファイングレイントークンを作成してください。リクエストヘッダーで送信します: ```http Authorization: Bearer ``` - **セッション Cookie:** Hub UI と同じセッションを共有するブラウザやツールから呼び出す場合、Cookie は自動的に送信されます。 ### リソースグループのリスト表示 組織内で管理できるすべてのリソースグループを取得します。この結果を使用して、add-users 呼び出しで各グループの `id` を取得します。 **リクエスト** ```http GET /api/organizations/{org_name}/resource-groups Authorization: Bearer ``` **例 (curl)** ```bash curl -s -H "Authorization: Bearer $HF_TOKEN" \ "https://huggingface.co/api/organizations/my-org/resource-groups" ``` **応答の例（抜粋）** ```json [ { "id": "507f1f77bcf86cd799439011", "name": "Cohort 2024", "description": "Members in this group", "users": [...], "repos": [...] } ] ``` ユーザーを追加する際は、各リソースグループの`id`を使用します。 ### リソースグループにユーザーを追加する 1つのリクエストで、単一のリソースグループに1人以上のユーザーを追加します。同じリクエストで複数のユーザーを送信できます。 **リクエスト** ```http POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/users Authorization: Bearer Content-Type: application/json { "users": [ { "user": "member1", "role": "read" }, { "user": "member2", "role": "read" }, { "user": "member3", "role": "write" } ] } ``` - **パスパラメータ** - `org_name`: 組織スラッグ（例: `my-org`）。 - `resource_group_id`: リソースグループの`id`（リストエンドポイントから取得した24文字の16進数文字列）。 - **本文** - `users`: オブジェクトの配列。各オブジェクトには、以下が必要です: - `user`: Hugging Face の **username**（必須）。 - `role`: `"read"`、`"contributor"`、`"write"`、`"admin"`、`"inherit"` のいずれか。 **例 (curl)** ```bash curl -s -X POST \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d '{"users":[{"user":"member1","role":"read"},{"user":"member2","role":"read"}]}' \ "https://huggingface.co/api/organizations/my-org/resource-groups/507f1f77bcf86cd799439011/users" ``` **成功:** ステータスは`200 OK`。ボディは更新されたリソースグループオブジェクトです（`users`に新しいユーザーが含まれます）。 **典型的なエラー:** - `400` — ユーザーが見つからない、ユーザー名が重複している、またはボディが無効であるなどの場合。 - `403` — 許可されていません（例：組織に属していない、または既にリソースグループに属している）。メッセージには、ユーザーが組織に属していないのか、既にグループに属しているのかが示されます。 ### メールによるメンバー追加（回避策） add-users エンドポイントは、**Hugging Face ユーザー名**のみを受け付け、メールアドレスは受け付けません。**メールアドレス**のリスト（例: メンバーのメールアドレス）がある場合は、まず email → username を解決してから、add-users API を呼び出せます。 メールフィルタリングは、メールのドメインが組織の許可ドメイン（**Organization email domain**（Settings → Account → Organization email domain）および/または組織の**SSO allowed domains**（SSOが設定されている場合））のいずれかと一致する場合に**のみ**機能することに注意してください。 **ステップ 1 – メールアドレスからユーザー名を解決する** ```http GET /api/organizations/{org_name}/members?email={email}&limit=1 Authorization: Bearer ``` Response はメンバーの配列です。各メンバーには `user`（ユーザー名）が含まれます。ユーザー追加の呼び出しには `user` を使用してください。 **ステップ 2 – リソースグループに追加** ステップ1のユーザー名を通常のユーザー追加リクエストで使用します: ```http POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/users Content-Type: application/json Body: { "users": [{ "user": "", "role": "read" }] } ``` **例: 1通のメール (bash)** ```bash ORG_NAME="my-org" RG_ID="507f1f77bcf86cd799439011" EMAIL="member@org.com" # Step 1: look up member by email (domain must match org's Organization email domain or SSO allowed domains) MEMBERS=$(curl -s -H "Authorization: Bearer $HF_TOKEN" \ "https://huggingface.co/api/organizations/$ORG_NAME/members?email=$EMAIL&limit=1") USERNAME=$(echo "$MEMBERS" | jq -r '(.[0] // {} | .user // "")') if [ -z "$USERNAME" ]; then echo "No member found for $EMAIL" exit 1 fi # Step 2: add to resource group curl -s -X POST -H "Authorization: Bearer $HF_TOKEN" -H "Content-Type: application/json" \ -d "{\"users\":[{\"user\":\"$USERNAME\",\"role\":\"read\"}]}" \ "https://huggingface.co/api/organizations/$ORG_NAME/resource-groups/$RG_ID/users" ``` **例: ループ内の複数のメール (Python)** ```python import os import requests BASE = "https://huggingface.co" ORG = "my-org" RG_ID = "507f1f77bcf86cd799439011" ROLE = "read" headers = {"Authorization": f"Bearer {os.environ['HF_TOKEN']}", "Content-Type": "application/json"} emails = ["member1@org.com", "member2@org.com"] for email in emails: # Step 1: resolve email → username (email domain must match org's Organization email domain or SSO allowed domains) r = requests.get(f"{BASE}/api/organizations/{ORG}/members", params={"email": email, "limit": 1}, headers=headers) r.raise_for_status() members = r.json() if not members: print(f"No member found for {email}") continue username = members[0]["user"] # Step 2: add that user to the resource group add_r = requests.post( f"{BASE}/api/organizations/{ORG}/resource-groups/{RG_ID}/users", headers=headers, json={"users": [{"user": username, "role": ROLE}]}, ) if add_r.status_code == 200: print(f"Added {username} ({email})") else: print(f"Failed {email}: {add_r.status_code} {add_r.text}") ``` ユーザーがすでにリソースグループに存在する場合、追加呼び出しは`403`を返します。スクリプトはこれを失敗として報告しますが、必要に応じてそのケースをスキップまたは無視できます。 **制限事項:** メールフィルターは、組織に**組織のメールドメイン**および/または**SSO許可ドメイン**が設定されており、かつメールのドメインがそれらのいずれかと一致する場合にのみ適用されます。それ以外の場合は、メンバーAPIを介してメールで検索することはできません。メールからユーザー名への対応付けには、別の情報源（例: 独自のディレクトリ）が必要です。 ### APIをループして一括追加 1つのリクエスト、または少数のリクエスト（例: ユーザー名の一覧をチャンクに分割する）で、**1つの**リソースグループに多数のユーザーを追加できます。また、グループをループして各グループに対してadd-usersエンドポイントを呼び出すことで、**複数の**リソースグループにユーザーを追加することもできます。 **例: Bash – 1つのリクエストで1つのグループ、複数のユーザー** ```bash #!/bin/bash # Add a list of users to a single resource group. # Usage: ./add-users-to-rg.sh ORG_NAME="${1:-my-org}" RG_ID="${2:-507f1f77bcf86cd799439011}" ROLE="${3:-read}" USERS="member1 member2 member3 member4" USERS_JSON=$(echo "$USERS" | tr ' ' '\n' | while read u; do [ -n "$u" ] && echo "{\"user\":\"$u\",\"role\":\"$ROLE\"}" done | paste -sd ',' -) curl -s -w "\nHTTP_STATUS:%{http_code}" -X POST \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d "{\"users\":[$USERS_JSON]}" \ "https://huggingface.co/api/organizations/$ORG_NAME/resource-groups/$RG_ID/users" ``` **例: Bash – 複数のグループをループ処理する** ```bash # Get group IDs and add users to each curl -s -H "Authorization: Bearer $HF_TOKEN" \ "https://huggingface.co/api/organizations/my-org/resource-groups" \ | jq -r '.[].id' \ | while read -r RG_ID; do [ -z "$RG_ID" ] && continue echo "Adding users to resource group $RG_ID ..." curl -s -X POST -H "Authorization: Bearer $HF_TOKEN" -H "Content-Type: application/json" \ -d "{\"users\":[$USERS_JSON]}" \ "https://huggingface.co/api/organizations/my-org/resource-groups/$RG_ID/users" done ``` **例: Python – 1つまたは複数のグループにまとめて追加する** ```python import os import requests BASE_URL = "https://huggingface.co" HF_TOKEN = os.environ.get("HF_TOKEN", "") def list_resource_groups(org_name: str): r = requests.get( f"{BASE_URL}/api/organizations/{org_name}/resource-groups", headers={"Authorization": f"Bearer {HF_TOKEN}"}, ) r.raise_for_status() return r.json() def add_users_to_resource_group(org_name: str, resource_group_id: str, users_with_roles: list): """users_with_roles: list of {"user": "username", "role": "read"|"write"|"contributor"|"admin"}""" r = requests.post( f"{BASE_URL}/api/organizations/{org_name}/resource-groups/{resource_group_id}/users", headers={"Authorization": f"Bearer {HF_TOKEN}", "Content-Type": "application/json"}, json={"users": users_with_roles}, ) if r.status_code != 200: raise RuntimeError(f"Add users failed {r.status_code}: {r.text}") return r.json() # Example: same users added to every resource group org_name = "my-org" role = "read" usernames = ["member1", "member2", "member3"] users_with_roles = [{"user": u, "role": role} for u in usernames] for rg in list_resource_groups(org_name): add_users_to_resource_group(org_name, rg["id"], users_with_roles) ``` ユーザー名の長いリストがある場合は、チャンク（例: リクエストあたり50件）に分割し、チャンクごとにAPIを1回呼び出すことで、大きなリクエストボディやタイムアウトを回避してください。 ### 重要な注意事項 1. **ユーザー名のみ** — この API は Hugging Face の**ユーザー名**を受け付け、メールアドレスは受け付けません。API を呼び出す前に、メールアドレスからユーザー名へのマッピング（ディレクトリや組織メンバーリストなどから取得）が必要です。 2. **ユーザーは組織に属している必要があります** — リクエスト内のすべてのユーザーは、すでに組織のメンバーである必要があります。そうでない場合、リクエストは一部のユーザーが組織に属していないことを示すメッセージとともに`403`を返します。 3. **冪等性** — ユーザーがすでにリソースグループに存在する場合、バックエンドは当該リクエストに対して`403`を返す可能性があります。スクリプトでエラーをキャッチして処理を続行するか、まずグループの`users`リストを取得して、すでにグループに属しているユーザーをスキップすることもできます。 4. **レート制限** — 大規模なバッチ処理を行う場合は、レート制限に抵触しないよう、リクエスト間に短い遅延（例：0.5〜1秒）を挿入することを検討してください。 5. **トークンスコープ** — アクセストークンは、組織に対して十分な権限（通常は少なくとも「組織設定への書き込みアクセス / メンバー管理」）を持つ必要があります。トークンを安全に作成して保存し、バージョン管理システムにコミットしないでください。 --- ## API を使用して自動参加を設定する [Auto-join](./security-resource-groups#auto-join)は、指定されたロールで組織メンバーをリソースグループに自動的に追加します。APIを介して有効化または無効化でき、組織の全メンバーを対象にするか、Read+メンバーのみを対象にするかを選択することもできます。 **自動参加を有効にする** ```http POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/settings Authorization: Bearer Content-Type: application/json { "autoJoin": { "enabled": true, "role": "read", "scope": "read_plus" } } ``` - **パスパラメータ** - `org_name`: 組織スラッグ（例: `my-org`）。 - `resource_group_id`: Resource Group の ID（24 文字の 16 進文字列。[list resource groups エンドポイント](#list-resource-groups)から ID を取得できます）。 - **本文** - `role`: 自動的に追加されるメンバーに割り当てるロール。`"read"`、`"contributor"`、`"write"`、`"admin"`、または`"inherit"`のいずれかです。 - `scope`（オプション）：自動的に追加する組織メンバーの範囲を指定します。すべての組織メンバーを含めるには `"all"` を使用します。`no_access` 組織ロールを持つメンバーを除外するには `"read_plus"` を使用します。省略した場合、デフォルトで `"all"` が使用されます。 既存の Resource Group で auto-join を有効にすると、選択したスコープに一致する現在の組織メンバーが即座に追加されます（バックフィル）。 **自動参加の無効化** `"enabled": false`を指定して、同じリクエストを送信します。無効化する場合、`role`フィールドは必須ではありません: ```http POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/settings Authorization: Bearer Content-Type: application/json { "autoJoin": { "enabled": false } } ``` > [!NOTE] > 自動参加を無効にしても、以前に自動参加したメンバーは**削除されません**。これにより、今後の組織メンバーが自動的に追加されることが防止されるだけです。既存のメンバーはリソースグループに留まります。 ## API経由で支出上限を設定する [支出上限](./security-resource-groups#spend-limits)は、リソースグループに帰属する月間の計算リソースの支出を制限します。更新エンドポイントで設定します: ```http PATCH /api/organizations/{org_name}/resource-groups/{resource_group_id} Authorization: Bearer Content-Type: application/json { "spendLimits": { "total": 500000, "spaces": 100000, "jobs": 50000 } } ``` - **パスパラメータ** - `org_name`: 組織スラッグ（例: `my-org`）。 - `resource_group_id`: Resource Group の ID（24 文字の 16 進文字列。[list resource groups エンドポイント](#list-resource-groups)から ID を取得できます）。 - **本文** - `spendLimits`: **セント単位**の月間上限。上記の例では、合計上限を5,000ドル、Spacesを1,000ドル、Jobsを500ドルに設定しています。 - `total`: 全製品にわたるグループの合計支出の上限。 - `inferenceProviders`、`spaces`、`jobs`、`endpoints`: 製品ごとの制限。合計制限に上乗せして適用されます。2つの制限のうち、より厳しい方が優先されます。 送信したキーのみが更新され、その他のキーは現在の値を維持します。`null`を送信すると、制限が削除されます: ```http PATCH /api/organizations/{org_name}/resource-groups/{resource_group_id} Authorization: Bearer Content-Type: application/json { "spendLimits": { "jobs": null } } ``` **例 (curl)** ```bash curl -s -X PATCH \ -H "Authorization: Bearer $HF_TOKEN" \ -H "Content-Type: application/json" \ -d '{"spendLimits": {"total": 500000}}' \ "https://huggingface.co/api/organizations/my-org/resource-groups/507f1f77bcf86cd799439011" ``` レスポンスは、`spendLimits`を含む更新されたリソースグループです。 ## API を介して外部の共同作業者を招待する [外部招待](./security-resource-groups#external-invitations)を使用すると、リソースグループの管理者は、組織外のユーザーをリソースグループに招待できます。招待されたユーザーは、`no_access`組織ロールを持つ外部コラボレーターとして参加します。これらのユーザーは、組織の有料シート数にカウントされます。 **外部からの招待を有効にする** Org管理者は、以下の設定を有効にできます: ```http POST /api/organizations/{org_name}/resource-groups/settings Authorization: Bearer Content-Type: application/json { "allowExternalInvites": true } ``` - **本文** - `allowExternalInvites`（オプション）：リソースグループの管理者が、組織外からユーザーを招待できるかどうかを指定します。 - `minRoleToCreate`（オプション）：[Resource Groups を作成](./security-resource-groups#who-can-create-resource-groups)するために必要な組織の最小ロール。 省略されたフィールドは変更されません。現在の設定を読み取るには、`GET /api/organizations/{org_name}/resource-groups/settings` を使用してください。 **ユーザーを招待する** ```http POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/invite Authorization: Bearer Content-Type: application/json { "username": "partner-user", "role": "read" } ``` - **パスパラメータ** - `org_name`: 組織スラッグ（例: `my-org`）。 - `resource_group_id`: Resource Group の ID（24 文字の 16 進文字列。[list resource groups エンドポイント](#list-resource-groups)から ID を取得できます）。 - **本文** - `username`: 組織のメンバーではない既存の Hugging Face ユーザーのユーザー名です。組織のメンバーを追加するには、代わりに[リソースグループにユーザーを追加する](#add-users-to-a-resource-group)を使用してください。 - `role`: 招待対象者がリソースグループで取得するロール。`"read"`または`"write"`。 ユーザーが招待を承認すると、メールによる招待と Resource Group へのアクセス権が与えられます。 **保留中の招待を管理する** - **一覧:** `GET /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitations` - **再送信:** `POST /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitation/{invitation_id}/resend` - **取り消し:** `DELETE /api/organizations/{org_name}/resource-groups/{resource_group_id}/invitation/{invitation_id}` また、[完全なOpenAPI仕様を確認](https://huggingface.co/spaces/huggingface/openapi#tag/resource-groups)することもできます。 **典型的なエラー:** - `403` — 組織では外部からの招待が有効になっていません。 - `409` — ユーザーはすでに組織のメンバーであるか、招待の保留中である。 ## API経由でメンバーアカウントの種類を変更する 組織メンバーを[外部コラボレーター](./security-sso-user-management#external-collaborators)（SSO不要）に変更するか、メンバーに戻すことができます。有料プランと、組織に対する**Write**（または Admin）権限が必要です。SCIM 経由でメンバーがプロビジョニングされる、マネージドユーザーが有効な組織では利用できません。 > [!WARNING] > ユーザーのアカウントタイプを変更しても、そのユーザーのロールは変更されません。ユーザーのロールを変更するには、[APIによるメンバーロールの変更](https://huggingface.co/docs/hub/main/en/programmatic-user-access-control#change-member-role-via-api)を参照してください。 ```http PUT /api/organizations/{org_name}/members/{username}/account-type Authorization: Bearer Content-Type: application/json { "accountType": "external" } ``` - **本文** - `accountType`: メンバーを外部コラボレーターに変換するには`"external"`、元に戻すには`"member"`を指定します。