ゲート付きモデル

モデルの使用方法に対する制御を強化するため、Hub ではモデル作成者がモデルに対してアクセスリクエストを有効にできます。有効にすると、ユーザーはモデルファイルにアクセスするためにアクセスリクエストを提出する必要があり、モデル作成者がその収集をオプトアウトしていない限り、Hugging Face の情報（ユーザー名とメールアドレス）がモデル作成者と共有されます。モデル作成者はカスタムフィールドを追加することもできます。アクセスリクエストが有効なモデルはゲート付きモデルと呼ばれます。アクセスリクエストは、組織全体ではなく、常に個人ユーザーに対して承認されます。ゲート付きモデルの一般的なユースケースは、より広範なリリース前に、初期の研究モデルへのアクセスを提供することです。

モデル作成者としてゲート付きモデルを管理する

アクセスリクエストを有効にするには、モデルの設定ページに移動します。デフォルトでは、モデルはゲートされていません。右上隅のEnable Access requestをクリックしてください。

デフォルトでは、モデルのアクセス要求時に、自動的にユーザーへのアクセス権限が付与されます。これは自動承認と呼ばれます。このモードでは、ユーザーが個人情報を共有した時点で、誰でもあなたのモデルにアクセスできます。

モデルへのアクセスを許可するユーザーを手動で承認したい場合は、manual approvalに設定する必要があります。この場合、より多くのオプションが表示されます。

• アクセスの追加を使用すると、ユーザーを検索して、リクエストがなくてもアクセス権を付与できます。
• 通知頻度では、新しいユーザーがアクセスをリクエストした際に通知を受け取るタイミングを設定できます。1日1回またはリアルタイムに設定できます。デフォルトでは、プライマリーメールアドレスにメールが送信されます。組織がホストするモデルの場合、デフォルトでは組織の最初の5人の管理者にメールが送信されます。どちらの場合（ユーザーまたは組織）でも、通知用メールアドレスフィールドで別のメールアドレスを設定できます。

アクセス要求のレビュー

アクセス要求が有効になると、承認モードが手動であっても自動であっても、モデルへのアクセスを許可するかどうかを完全に管理できます。要求のレビューと管理は、UI または API を通じて行うことができます。

UIから

アクセス要求の確認ボタンをクリックすることで、ゲート付きモデルの設定ページから、誰がそのモデルにアクセスできるかを確認できます。これにより、3つのユーザーリストが表示されるモーダルが開きます。

• pending: モデルへのアクセスを承認待ちで待機しているユーザーのリストです。このリストは、manual approvalを選択していない限り空です。AcceptまたはRejectでリクエストを処理できます。リクエストが拒否された場合、そのユーザーはモデルにアクセスできず、再度アクセスをリクエストすることもできません。
• accepted: モデルへのアクセス権を持つユーザーの完全なリストです。承認モードが手動であっても自動であっても、いつでも任意のユーザーに対してアクセスをReject（拒否）できます。また、承認をCancel（キャンセル）すると、そのユーザーはpendingリストに移動します。
• rejected: 手動で拒否したユーザーのリストです。これらのユーザーはあなたのモデルにアクセスできません。モデルのリポジトリにアクセスすると、このリポジトリへのアクセスリクエストは、リポジトリの作成者によって拒否されました というメッセージが表示されます。

API経由

API を使用して、アクセスリクエストの承認を自動化できます。ゲート付きリポジトリへの write アクセス権限を持つ token を渡す必要があります。トークンを生成するには、ユーザー設定に移動します。

上記のHTTPエンドポイントのベースURLはhttps://huggingface.coです。

リクエストをresetに設定すると、以前の決定が取り消され、ユーザーに最初からやり直すよう求められます。ユーザーはモデルへのアクセス権を失い、リクエストがリセットされたことを通知するメール（任意のresetReasonを含む）を受け取り、次にモデルページを訪れた際にゲーティングの条件に同意して新しいリクエストを送信するよう促されます。これは、既存のリクエストをそのまま保持して単にレビューキューに戻すpendingや、ユーザーが再度アクセスをリクエストすることをブロックするrejectedとは異なります。

新機能! これらのエンドポイントは、Python クライアント huggingface_hub で正式にサポートされました。モデルへのアクセスリクエストを、list_pending_access_requests、list_accepted_access_requests、list_rejected_access_requests で一覧表示できます。また、accept_access_request、cancel_access_request、reject_access_request を使用して、アクセスリクエストの承認、キャンセル、拒否も可能です。最後に、grant_access を使用して、ユーザーにアクセス権を付与できます。

ダウンロードアクセスレポート

ゲート付きモデルのすべてのアクセスリクエストのレポートは、ユーザーアクセスレポートのダウンロードボタンからダウンロードできます。このボタンをクリックすると、ユーザーのリストを含むjsonファイルがダウンロードされます。各エントリには、以下が含まれます。

• requestId: リクエストのID。
• user: ユーザーID。例: julien-c。
• fullname: Hub 上のユーザー名。例: Julien Chaumond。
• status: リクエストのステータス。"pending"、"accepted"、"rejected"、または"reset"のいずれかです。
• email: ユーザーのメールアドレス。
• time: ユーザーが最初にリクエストを行った日時。
• reviewedAt: リクエストが承認または拒否された日時。保留中のリクエストには設定されません。

user、fullname、email は、リクエスト時にそれらを収集することを選択した場合にのみ存在します。リクエストは常にrequestIdによって識別できます。

Hugging Faceがあなたと共有するプロファイルデータを選択

デフォルトでは、Hugging Face はリクエスト者のユーザー名とメインのメールアドレスをあなたと共有します。個人識別情報（PII）の処理と、適用される法律に従ったその処理方法の開示（例えば、独自のプライバシーポリシーへのリンクを貼ることなど）は、あなたの責任となります。これは、モデル設定ページのゲーティングオプションで変更できます。

• ユーザー名の収集: 未チェックの場合、リクエスト送信者の Hugging Face ユーザー名、氏名、アバターを受け取れません。リクエストはリクエスト ID で一覧表示され、他のリクエストと同様に承認または拒否できます。
• メールアドレスの収集: リクエスト元の Hugging Face プロファイルのメールアドレスを収集します。ユーザー名の収集が必要です。

カスタムフォームフィールドへの回答は引き続き受信できるため、必要な連絡先情報をそこで指定できます。これらの設定は新しいリクエストにのみ適用されます。既存のリクエストには、作成時に設定されていた設定が維持されます。

Gating Group Collection内のモデルでは、これらのオプションはコレクション側で設定されます。

要求される情報のカスタマイズ

By default, users landing on your gated model will be asked to share their Hugging Face information (email and username, unless you disabled their collection) by clicking the Agree and send request to access repo button.

より多くのユーザー情報を収集したい場合は、追加のフィールドを設定できます。この情報は、Settingsタブからアクセスできます。そのためには、モデルカードのメタデータに、キー/値のペアのリストを含むextra_gated_fieldsプロパティを追加します。keyはフィールドの名前、valueはその型、またはtypeフィールドを持つオブジェクトです。フィールドの型のリストは以下の通りです:

• text: 1行のテキストフィールド。
• checkbox: チェックボックスフィールド。
• date_picker: 日付ピッカーフィールド。
• country: 国名ドロップダウン。国名のリストはISO 3166-1 alpha-2標準に基づいています。
• select: オプションのリストを持つドロップダウン。オプションのリストはoptionsフィールドで定義されます。例: options: ["option 1", "option 2", {label: "option3", value: "opt3"}]。

最後に、extra_gated_prompt という追加フィールドを使用して、ユーザーに表示されるメッセージをカスタマイズすることもできます。

カスタマイズされたリクエストフォームの例を以下に示します。このフォームでは、ユーザーに会社名と国を記入し、モデルが非商用利用のみであることを確認するよう求められます。

---
extra_gated_prompt: "You agree to not use the model to conduct experiments that cause harm to human subjects."
extra_gated_fields:
  Company: text
  Country: country
  Specific date: date_picker
  I want to use this model for:
    type: select
    options: 
      - Research
      - Education
      - label: Other
        value: other
  I agree to use this model for non-commercial use ONLY: checkbox
---

一部のケースでは、ゲートの見出し、説明、ボタンのデフォルトテキストを変更したい場合もあります。そのような用途では、extra_gated_heading、extra_gated_description、extra_gated_button_contentを次のように変更できます。

---
extra_gated_heading: "Acknowledge license to accept the repository"
extra_gated_description: "Our team may take 2-3 days to process your request"
extra_gated_button_content: "Acknowledge license"
---

アクセスリクエストをプログラムで管理する使用例

コミュニティ内で自然に生まれた、ゲート付きリポジトリへのアクセスリクエストをプログラムで管理するいくつかの興味深いユースケースをご紹介します。 なお、モデルリポジトリは手動承認に設定する必要があります。そうしないと、ユーザーが自動的にアクセスできるようになります。

プログラマティックな管理の可能なユースケースには、以下が含まれます。

• 高度なユーザーリクエストのスクリーニング要件（高度なコンプライアンス要件など）がある場合、または Hub 外でユーザーリクエストを処理したい場合。
  • この一例として、MetaのLlama 2の初期リリースでは、ユーザーがMetaのウェブサイト上でアクセスを申請する必要がありました。
  • アクセスフローでユーザーにHFユーザー名を尋ね、その後、スクリプトを使用して、設定した条件に基づいてHub上のユーザーのリクエストをプログラム的に承認できます。
• 支払いフローの完了に基づいてモデルへのアクセスを条件付きで制御する場合（実際の支払いフローは Hub の外で実行されることに注意してください）。
  • TrelisResearchによる、このユースケースを使用したサンプルリポジトリの例を以下に示します。
  • @RonanMcGovern が、フローに関する動画と、その実装に関するヒントを投稿しました。

組織メンバーのゲートアクセス

組織がホストするゲート付きモデルでは、組織のメンバー自身にもアクセスリクエストの提出を要求できます。モデル設定ページで、ゲーティングオプションの下にある、{org}のメンバーにもアクセスをゲートするを有効にしてください。

このオプションが有効な場合、組織のメンバーは他のユーザーと同様に、モデルへのアクセスをリクエストする必要があります。以下のロールはリクエストをスキップし、直接アクセスを維持します。

• 組織管理者
• リポジトリを作成したユーザー
• モデルがリソースグループに属している場合、リソースグループの管理者

その他のすべてのメンバーは、アクセスリクエストフローを経由する必要があります。これには、read、contributor、またはwriteの組織ロールを持つメンバー、およびadminロールを持たないリソースグループのメンバーが含まれます。

組織としてゲート付きモデルを管理する（Team & Enterprise）

Team & Enterpriseのサブスクライバーは、Gating Group Collectionを作成することで、コレクション内のすべてのモデルとデータセットへのアクセスを一括で許可（または拒否）できます。

Gating Group Collectionsに関する詳細は、専用ドキュメントを参照してください。

ユーザーとしてゲート付きモデルにアクセスする

ユーザーとしてゲート付きモデルを使用するには、そのモデルへのアクセスをリクエストする必要があります。つまり、Hugging Faceのユーザーアカウントにログインしている必要があります。

アクセスのリクエストは、ブラウザからのみ行えます。Hub上の対象モデルに移動すると、情報の共有を求められるプロンプトが表示されます。

同意するをクリックすると、リクエストフォームに入力した情報（該当する場合）と、著者が収集を希望している場合のHugging Faceユーザー名およびメールアドレスを、モデルの著者と共有することに同意したことになります。モデルの著者がアクセスを許可するかどうかを判断するために、フォームの各項目をできるだけ完全に記入してください。

アクセスリクエストが送信されると、2つの可能性があります。承認メカニズムが自動の場合、すぐにモデルファイルへのアクセスが許可されます。それ以外の場合は、著者による手動の承認が必要であり、時間がかかる場合があります。

モデルの作成者は、モデルへのアクセスに対して完全な管理権限を有しています。具体的には、承認メカニズムの有無や、リクエストがすでに承認されているかどうかに関わらず、事前の通知なしにいつでもモデルへのアクセスをブロックすることができます。

ファイルのダウンロード

ゲート付きモデルからファイルをダウンロードするには、認証が必要です。ブラウザでは、アカウントにログインしている限り自動的に認証されます。スクリプトを使用する場合は、ユーザートークンを指定する必要があります。Hugging FaceのPythonエコシステム（transformers、diffusers、datasetsなど）では、huggingface_hubライブラリを使用してマシンにログインし、ターミナルで以下を実行できます。

hf auth login

代わりに、ノートブックやスクリプト内でlogin()をプログラム的に使用してログインすることもできます。

>>> from huggingface_hub import login
>>> login()

ライブラリのほとんどの読み込みメソッド（from_pretrained、hf_hub_download、load_dataset など）には、スクリプトから直接tokenパラメータを指定することもできます。

ログイン方法の詳細については、ログインガイドを参照してください。

EUユーザーへのアクセス制限

ゲート付きモデルでは、EU（欧州連合）の国々からのユーザーを特に制限するために、追加のアクセス制御レイヤーを追加できます。これは、モデルのライセンスまたは利用規約がEUでの配布を禁止している場合に有用です。

これを有効にするには、モデルカードのメタデータにextra_gated_eu_disallowed: trueプロパティを追加してください。

重要: この機能は、モデルがすでにゲート付きである場合にのみ有効になります。gated: false の場合、またはプロパティが設定されていない場合、この制限は適用されません。

---
license: mit
gated: true
extra_gated_eu_disallowed: true
---

システムは、IPアドレスに基づいてユーザーの位置情報を特定します。