Hugging Face の使い方｜モデルの入手・ゲート付きアクセス・ライセンス

はじめに

セキュリティ特化のオープンウェイトモデルや各種 LLM が Hugging Face 上で配布されるようになり、実務エンジニアが自組織でモデルを試したり導入したりする場面が増えています。一方で、モデルの入手は単純なダウンロードだけで完結するとは限りません。公開モデルの取得手順に加えて、アクセス承認が必要な「ゲート付きモデル」の申請や、商用利用の可否を左右するライセンスの確認など、事前に押さえておくべき手順と判断があります。

この記事では、インフラ・セキュリティエンジニアの視点から、Hugging Face でのモデル入手を運用判断まで含めて整理します。

先に結論をまとめます。公開モデルは、アカウントとアクセストークンがあれば取得できます。承認が必要なゲート付きモデルは、事前のアクセス申請が必要です。ライセンスは商用利用の可否や再配布の条件を左右するため、モデルカードでの確認が欠かせません。なお、Hugging Face の CLI は huggingface-cli から hf へ改称されており、認証コマンドが hf auth 系に再編されている点に注意が必要です。

Hugging Face とは（モデル・データセットの配布基盤）

Hugging Face は、機械学習モデルやデータセット、デモアプリ（Spaces）を配布・共有するためのプラットフォームです。各モデルは Git でバージョン管理されたリポジトリとして公開され、モデルの説明やライセンス情報は、リポジトリ内の README.md（モデルカード）に記載されます。

実務エンジニアにとっては、公開されたモデルの「入手元」として使う場面が中心になります。本記事もその観点に絞って解説します。プラットフォーム全体の成り立ちや、モデル・データセット・Spaces の関係といった概念的な背景は、別途まとめる予定の関連記事で扱います。

モデルの入手フロー（公開モデルの基本）

まず、アクセス制限のない公開モデルの入手フローを整理します。公開モデルは、モデルページから直接、または CLI・Python スクリプトから取得できます。認証の要否は次のとおりです。モデルカードの閲覧と、公開（非ゲート）モデルの重み（weights）のダウンロードは、認証なしでも可能です。アクセストークンによる認証が実質的に必要になるのは、後述のゲート付き・プライベートモデルを扱う場合と、匿名アクセスに適用されるレート制限を避けたい場合です。本記事ではゲート付きモデルの入手までを扱うため、以下ではトークンの準備を前提に進めます。

アカウントとアクセストークンの準備

入手の準備として、アカウントとアクセストークンを用意します。

STEP

アカウント作成

https://huggingface.co でメールアドレス、Google、GitHub のいずれかで登録します。登録後、確認メールでメールアドレスを認証します。認証を済ませないとトークンを発行できません。

STEP

アクセストークンの発行

設定画面の Access Tokens（https://huggingface.co/settings/tokens ）から新規トークンを発行します。ダウンロード用途であれば、権限は read（読み取り専用）で十分です。write 権限は、モデルのアップロードや変更を行う場合にのみ付与します。用途に対して過剰な権限を与えないことが、後述するトークン管理の基本になります。なお、トークンの値が表示されるのは発行直後の 1 回のみです。控え忘れた場合は再発行します。

STEP

トークンの保管

発行したトークンは、HF_TOKEN 環境変数に設定するか、後述の hf auth login でローカルにキャッシュして利用します。

ブラウザと CLI / スクリプトでの取得の違い

取得方法は、大きくブラウザ、CLI、Python スクリプトの 3 通りがあります。認証の扱いがそれぞれ異なります。

ブラウザの場合は、アカウントにログインした状態であれば、モデルページの Files タブから個別ファイルを直接ダウンロードできます。認証はログインセッションによって自動的に行われます。

CLI の場合は、公式の hf CLI を利用します。前述のとおり、従来の huggingface-cli から改称されたものです。

参考: Say hello to hf（Hugging Face Blog）
“the Hugging Face CLI has been officially renamed from huggingface-cli to hf”
（Hugging Face の CLI は、huggingface-cli から hf へ正式に改称された）
https://huggingface.co/blog/hf-cli

基本的なコマンドは次のとおりです（公式リファレンス: https://huggingface.co/docs/huggingface_hub/guides/cli ）

# インストール（huggingface_hub パッケージに同梱）
pip install -U huggingface_hub

# ログイン（トークンを入力、または非対話環境では HF_TOKEN を利用）
hf auth login

# モデルのダウンロード
hf download <repo_id>

従来の huggingface-cli コマンドも当面は動作しますが、実行時に新しい hf コマンドへの移行を促す警告が表示されます。手元のドキュメントや過去のスクリプトが huggingface-cli login などの旧表記のままになっていないか、あわせて確認することをおすすめします。

Python スクリプトの場合は、huggingface_hub の hf_hub_download() 関数や、transformers の from_pretrained() に token 引数を渡す方法があります。非対話環境（CI など）では、HF_TOKEN 環境変数にトークンを設定しておくと、各ライブラリが自動的に読み取ります。

入手した後の流れ（モデルはローカルで動かす）

ここまでで入手の準備は整いますが、トークンの発行やダウンロードだけでは、まだ AI として使える状態にはなりません。入手後の全体像を先に示しておきます。

ダウンロードしたモデルの実体は、重みなどのファイル一式です。CLI や Python スクリプトで取得した場合、既定では端末内のキャッシュ（~/.cache/huggingface/hub）に保存されます。このファイルを実行基盤（Ollama や transformers などのソフトウェア）で読み込むことで、はじめて対話や推論に使えるようになります。インターネット接続が必要なのはダウンロードの時だけで、取得後は外部と通信せず、端末内で完結して動作させられます。これが、機密性の高いデータを外部へ出さずに AI を使えるという、オープンウェイトモデルの実務上の利点の実体です。

はじめてローカルでモデルを動かす場合は、Ollama を使う方法が最も手順が少なく、入門に適しています。Ollama は独自のモデル配布の仕組みを持つため、Hugging Face のトークンも基本的に不要です。Ollama と transformers それぞれの具体的な実行手順は、別途まとめる予定の関連記事で扱います。

ゲート付きアクセスの仕組みと申請

モデルによっては、ダウンロードの前にアクセス申請と承認が必要な「ゲート付き（gated）」の設定がされています。ここでつまずくケースが多いため、仕組みと申請の流れを整理します。前回の Antares 記事で「入手にはゲート付きアクセスが設けられている可能性がある」とした部分の具体的な手順にあたります。

ゲートモデルとは（作者が承認を管理する仕組み）

ゲートモデルは、モデルの作者や公開元の組織が、誰にダウンロードを許可するかを管理する仕組みです。公開はされているものの、重みを取得するにはアクセス申請を経る必要があります。ゲートモデルのファイルを取得するには認証が必須で、ブラウザではログイン状態であれば自動的に認証され、スクリプトから取得する場合はユーザートークンを渡す必要があります。

注意しておきたいのは、承認の主導権が完全に作者側にある点です。

参考: Gated models（Hugging Face Docs）
“they can decide at any time to block your access to the model”
（作者は、いつでもモデルへのアクセスをブロックする判断ができる）
https://huggingface.co/docs/hub/models-gated

つまり、一度承認された場合でも、予告なくアクセスが取り消される可能性があります。業務でゲートモデルに依存する場合は、アクセスがいつでも失われ得ることを前提に、取得済みモデルの保管方針や代替モデルの検討を織り込んでおくことが推奨されます。なお、作者はゲートモデルに対して、EU 圏のユーザーからのアクセスを追加で制限するオプションも設定できます。

前回扱った Cisco Antares のように、セキュリティ関連のモデルではゲート付きで公開される例があります（詳細は関連記事『Cisco Antares とは｜脆弱性特定に特化した軽量 AI モデルの実力』を参照）

アクセス申請の手順と承認の実際

アクセス申請の基本的な流れは次のとおりです。

1. アカウントにログインした状態で、対象モデルのページを開きます。
2. ページ上のアクセス申請セクションで、フォームに必要事項を記入して送信します。求められる項目はモデルによって異なり、所属や利用目的の記載を求められる場合があります。
3. 承認を待ちます。申請後すぐに自動承認されるモデルもあれば、作者による手動審査を要するモデルもあります。
4. 承認されると、read 権限を持つトークンでダウンロードできるようになります。

申請フォームに記入した内容は、承認可否を判断する作者に開示されます。所属組織や利用目的は正確に記載することが求められます。特に、サイバー防御者であることの確認を条件とするモデル（Antares がこれに該当する可能性があります）では、用途の申告が承認の判断材料になります。

認証の要点（トークン・HF_TOKEN・最小権限）

承認後は、認証を通してダウンロードします。方法は公開モデルと同様ですが、ゲートモデルでは認証が必須になります。

# ログイン後にゲートモデルを取得
hf auth login
hf download <repo_id>

Python スクリプトから取得する場合は、hf_hub_download() や from_pretrained() にトークンを渡すか、HF_TOKEN 環境変数を設定します。

from huggingface_hub import hf_hub_download

hf_hub_download(repo_id="<repo_id>", filename="<file>", token="hf_...")

権限は、ダウンロード用途であれば read で十分です。細粒度（fine-grained）トークンを使う場合は、「アクセス可能な公開ゲートリポジトリの内容への読み取り権限」を付与します。ここでも、必要最小限の権限にとどめることが安全側の運用になります。

よくあるつまずきとして、認証や承認が済んでいない状態でゲートモデルを取得しようとすると、You are trying to access a gated repo といった趣旨のエラーが発生します。この場合は、アクセス申請が承認済みか、トークンが正しく設定されているか、トークンに対象リポジトリへの読み取り権限があるかを順に確認します。

ライセンスの見極め（商用利用の可否）

モデルを業務で使う際に見落とせないのが、ライセンスの確認です。Hugging Face 上のモデルは「オープン」と表現されていても、商用利用の可否や再配布の条件はライセンスによって大きく異なります。ライセンス情報は、リポジトリのモデルカード（README.md）のメタデータに記載されています。

前提として押さえておきたいのは、「オープン」という語の扱いです。重みが公開されている（オープンウェイト）ことと、OSI（Open Source Initiative）の定義に沿った「オープンソース」であることは別物です。多くの「オープン」なモデルは、学習データや学習コードが完全には公開されておらず、厳密にはオープンウェイトに分類されます。ライセンスがカスタム条項を含む場合、この違いが商用利用の判断に影響します。

主要ライセンスの分類（Apache-2.0 / MIT / Llama 系 / RAIL / CC-BY-NC）

実務でよく遭遇するライセンスを、商用利用の観点で整理します。

判断の目安として、商用利用で摩擦を避けたい場合は Apache-2.0 または MIT が扱いやすい選択肢になります。カスタムライセンス（Llama 系、Gemma 等）は条件が付くため、自組織の利用規模や用途が条項に抵触しないかの確認が必要です。特に MAU の閾値は、製品単位ではなく企業グループ全体で集計される点に注意します。

参考: TechCrunch（Florian Brand 氏のコメント）
“Most companies have a set of approved licenses, such as Apache 2.0”
（多くの企業は、Apache 2.0 のような承認済みライセンスの一覧を定めている）
https://techcrunch.com/2025/03/14/open-ai-model-licenses-often-carry-concerning-restrictions/

多くの組織では、利用を認めるライセンスをあらかじめ一覧化しています。カスタムライセンスのモデルを導入する際は、自組織の承認済みライセンス方針に照らして、法務・調達部門の確認を得ておくことが推奨されます。

実務での落とし穴（ベースモデルのライセンス継承）

ライセンス確認でつまずきやすいのが、派生モデル（ファインチューニングされたモデル）のライセンス継承です。モデルカードに表示されたライセンスだけを見て判断すると、実態と食い違う場合があります。

派生モデルは、ベースとなったモデルのライセンス条件を引き継ぎます。たとえば、あるモデルのカードに Apache-2.0 と表示されていても、そのモデルが制限的なライセンスのベースモデルをファインチューニングしたものであれば、ベース側の制約（商用利用の条件や再配布の制限）が実質的に適用される可能性があります。過去には、モデルカード上は Apache-2.0 と読めるものの、実際には制限的なライセンスのベースモデルに差分の重みを適用する構成になっており、ベース側の条件が及ぶ例もありました。

モデルを選定する際は、そのモデル単体のライセンス表示だけでなく、ベースモデルまで遡ってライセンスを確認することが安全側の運用になります。Hugging Face 上では派生モデルが大量に存在し、1 つのベースモデルの条件が、その下流のすべての派生モデルに引き継がれます。商用導入を前提とする場合は、系統をたどってライセンスの整合を確認しておくことが、後々のコンプライアンス上のリスクを避けることにつながります。

セキュリティ運用上の注意点

ここまでの入手・アクセス・ライセンスに加えて、インフラ・セキュリティエンジニアとして押さえておきたいのが、トークンの管理とモデルファイル自体のリスクです。モデルの配布基盤は、供給元を信頼しきれないという点で、パッケージレジストリと同様のサプライチェーンリスクを抱えています。

トークンの管理と漏洩対策

アクセストークンは、アカウントの認証情報そのものです。漏洩すると、権限の範囲でリポジトリへアクセスされる可能性があります。運用上の要点は次のとおりです。

最小権限にとどめる

ダウンロード用途であれば read 権限で十分です。write 権限は、アップロードや変更が必要な場合に限定します。

コードに埋め込まない

トークンをソースコードやバージョン管理にコミットしないようにします。HF_TOKEN 環境変数や、hf auth login によるローカルのキャッシュを利用します。

ローテーションと失効

定期的にトークンを更新し、不要になったトークンは失効させます。CI などで共有する場合は、用途ごとにトークンを分けると影響範囲を限定できます。

過去には、公開されたリポジトリなどから商用モデル向けのアクセストークンが漏洩し、モデルやデータセットへ不正にアクセスできる状態になっていた事例も報告されています。トークンの取り扱いは、他の認証情報と同じ厳密さで管理することが推奨されます。

モデルファイルのサプライチェーンリスク

見落とされやすいのが、モデルファイルを読み込むこと自体にリスクがある点です。PyTorch の従来形式などは Pickle をベースにしており、モデルの読み込み時にコードが実行される可能性があります。

参考: JFrog
“not only pickle-based models are susceptible to executing malicious code”
（悪意あるコードを実行し得るのは、Pickle ベースのモデルに限らない）
https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/

Hugging Face はマルウェアスキャン、Pickle スキャン、シークレットスキャンといった対策を実施していますが、Pickle 形式のモデルは「unsafe」と表示するにとどまり、ダウンロード自体をブロックするわけではありません。スキャンも万能ではなく、署名ベースの検出を回避する新しい手法が確認されています。したがって、利用者側でも防御的な運用が求められます。

実務での対策として、次の点が挙げられます。

safetensors を優先する

実行可能コードを含まない safetensors 形式を優先し、Pickle 形式しか提供されないモデルは追加の精査対象とします。

リビジョンを固定する

本番では、モデルを名前だけで参照せず、検証済みのコミットハッシュ（revision）で固定します。

trust_remote_code=True を監査する

このオプションはリモートのコード実行につながるため、利用箇所を棚卸しします。

リポジトリのメタデータを確認する

ダウンロード数が多いのに作成日が極端に新しいなど、不自然なリポジトリは警戒します。

内部レジストリでミラーする

承認済みモデルを自組織のレジストリにミラーし、パイプラインはそこから取得することで、名前空間の乗っ取りリスクを抑えられます。

なお、Cisco は Foundation AI と Hugging Face の連携により、Hugging Face 上へアップロードされる公開ファイルに対するマルウェアスキャン（ClamAV エンジンによる検出）を提供しています（https://blogs.cisco.com/security/ciscos-foundation-ai-advances-ai-supply-chain-security-with-hugging-face ）こうした基盤側の対策と、利用者側の防御的運用を組み合わせる発想が求められます。モデル配布基盤が攻撃面になり得ることは、関連記事『OpenAI モデルが Hugging Face に侵入｜自律型 AI 攻撃の全貌と教訓』でも扱っています。

まとめ

Hugging Face でのモデル入手は、公開モデルのダウンロードだけで完結するとは限りません。ゲート付きアクセスの申請、ライセンスの見極め、そしてトークンとモデルファイルのセキュリティという 3 つの観点を押さえることが、実務での安全な導入につながります。基盤側の対策に任せきりにせず、利用者側でも防御的な運用を組み合わせることが要点になります。

• 公開モデルは認証なし、ゲート付きはトークンと事前申請で入手
• 取得後のモデルはローカルで動作しインターネット接続は不要
• CLI は hf へ改称され、認証は hf auth login
• ゲート付きモデルは事前のアクセス申請と承認が必要
• 承認は作者の裁量によるもので、取り消しの可能性も想定
• ライセンスは商用可否を左右し、ベースモデルまで遡って確認
• Apache-2.0 や MIT は寛容、Llama 系や Gemma は条件付き
• モデルファイルは Pickle 実行リスクがあり safetensors を優先

以上、最後までお読みいただきありがとうございました。