機械学習の開発現場では、モデルの最終成果物とは別に、学習途中のチェックポイントやオプティマイザーの状態、処理済みデータのシャード、ログ、トレースといった膨大な中間ファイルが日々生成されます。これらはしばしば上書き・更新を繰り返し、バージョン管理よりも「素早く書き込めて、同期できて、不要になったら消せる」ことが優先されます。
Hugging Faceは2026年3月、こうした用途に特化したオブジェクトストレージ機能「Storage Buckets」をHugging Face Hub上で提供開始しました。Amazon S3に近い感覚で使えるミュータブルなストレージで、HubのブラウザUI、PythonライブラリのSDK、そしてhf CLIのいずれからでも操作できます。バックエンドには独自の「Xet」エンジンが採用されており、ML特有のファイル群において高い効率を発揮するとされています。
Gitリポジトリという既存の枠組みでは対応しにくかったユースケースへの回答として、コミュニティから注目を集めています。
GitリポジトリとML開発の「摩擦」という背景
Hugging Face Hubは、モデルやデータセットを公開・共有するプラットフォームとして急速に普及しました。その核心にあるのはGitベースのリポジトリ管理であり、ファイルの変更履歴を追い、再現性を担保するという設計思想は、公開成果物の管理において非常に有効です。
しかし、現実のML開発ワークフローには、Gitが想定していないユースケースが多数存在します。大規模な分散学習を行うクラスターは、数時間おきにチェックポイントとオプティマイザーの状態をディスクに書き出します。データパイプラインは、生データを繰り返し加工しながら中間成果物を蓄積します。エージェント型AIシステムは、実行のたびにトレースやメモリ、共有知識グラフを更新します。
こうしたケースに共通するのは、「頻繁に上書きされる」「多数のジョブが同時に書き込む」「バージョン履歴よりもアクセス速度や書き込みの速さが優先される」という特性です。Gitはこれらの状況においてパフォーマンス上の課題が生じやすく、大量の中間ファイルや並列書き込みとは相性がよくないと受け取れます。
ML開発がより本格的な産業応用へと移行するにつれ、こうした運用上の「摩擦」は業界共通の課題として認識されてきました。これまでは、Amazon S3やGoogle Cloud Storage（GCS）を別途組み合わせる構成が一般的でしたが、その場合はHub上での可視性が失われ、権限管理が複雑になるという問題がありました。Storage BucketsはHugging Faceのエコシステム内でこのギャップを埋めることを目指した機能と捉えられます。
Gitリポジトリ・クラウドストレージとの比較ポイント
Storage Bucketsの特徴を整理するうえで、既存の選択肢と比較することが理解の助けになります。
Hugging Face Dataset / Model Repoとの違い
既存のHubリポジトリはGitを基盤としており、ファイルの追加・変更はコミットとして記録されます。大容量バイナリファイルの場合はGit LFSが利用されますが、頻繁な上書きが発生するケースでは履歴が肥大化しやすくなります。Storage Bucketsはバージョン管理を持たないミュータブルなストレージであり、上書き・削除・ディレクトリ同期がそのまま行えます。「公開成果物の共有にはリポジトリ、継続的に変化する中間ファイルにはBuckets」という使い分けが想定されていると見られます。
AWS S3 / Google Cloud Storage / Azure Blob Storageとの違い
パブリッククラウドのオブジェクトストレージはS3互換APIを持ち、並列書き込みや大容量データの扱いに豊富な実績があります。一方、Hugging Face Hub上での可視性や権限管理との統合はなく、別途IAMポリシーや認証基盤の管理が必要になります。Storage BucketsはHubの認証・権限システム（ユーザー/組織のnamespace、公開・非公開設定）をそのまま継承する点が大きな差異です。hf://buckets/username/my-bucket という形式のハンドルでPythonコードから直接参照でき、既存のHugging Faceワークフローへの統合がシームレスに行えます。
Xetエンジンによる効率化の仕組み
Storage Bucketsのバックエンドには、Hugging Faceが独自に開発した「Xet」ストレージエンジンが採用されています。Xetはファイルをモノリシックなblobとして扱わず、コンテンツに基づいてチャンク（断片）に分割して管理します。これにより、複数のチェックポイント間で共通するパラメータブロックは重複して保存されず、差分のみが効率的に管理される仕組みです。チェックポイントのように前のバージョンと大部分が共通するファイルを多く扱うMLワークフローでは、ストレージ使用量と転送効率において顕著なメリットが期待できると考えられます。
比較軸のまとめ
比較軸 | Storage Buckets | HF Repo（Git） | AWS S3等 |
|---|---|---|---|
バージョン管理 | なし（ミュータブル） | あり | なし |
Hub上の可視性 | あり | あり | なし |
権限統合 | Hub標準 | Hub標準 | 別途設定が必要 |
ML差分効率化 | Xetで最適化 | Git LFS | 標準blob |
並列書き込み | 対応 | 苦手 | 対応 |
主な用途 | 中間ファイル管理 | 公開成果物 | 汎用 |
導入・検討時に見るべきポイント
Storage Bucketsの導入を検討するIT担当者・MLエンジニアが評価時に確認すべき点を以下に挙げます。
既存ワークフローとの統合コスト
hf CLIおよびPython SDKを通じて操作できる点は大きな利点ですが、既存の学習スクリプトやデータパイプラインがどのような形でストレージを参照しているかを確認する必要があります。hf:// プロトコル経由でのアクセスに対応したライブラリがどの範囲をカバーしているか、またS3互換APIの有無についても公式ドキュメントで最新情報を確認することをお勧めします。これらは実際の統合コストに直結します。
コストと価格体系
Storage Bucketsの料金モデルについては、ストレージ容量・転送量・APIリクエスト数の各要素ごとに、Hugging Faceの公式料金ページを参照して最新情報を確認してください。MLワークフローでは大容量データの頻繁な読み書きが発生するため、特に転送コストの試算は重要な検討事項になります。
プライベート・パブリックの運用設計
Storage BucketsはHubの標準権限管理を継承しているため、組織（Organization）配下での共有設定は比較的容易です。ただし、誰がどのBucketにアクセスできるかという権限設計は事前に整理しておくことが望ましいと言えます。複数チームが並行して利用する環境では、命名規則やアクセスポリシーを整備することが運用上の混乱を防ぐうえで有効です。
データ保持・削除ポリシー
ミュータブルストレージの性質上、古い中間ファイルが蓄積しやすくなります。定期的なクリーンアップスクリプトを組み込むか、保持期間のルールを運用ポリシーとして定めておくことが推奨されます。
セキュリティとコンプライアンス
機密性の高いデータ（個人情報を含む学習データ等）を扱う場合は、データの保存リージョンやアクセスログの取得可否についても確認が必要です。Hugging Faceのデータ処理に関するポリシーや利用規約を踏まえたうえで、自組織のコンプライアンス要件との整合性を評価することが重要です。
「データ層」の整備がMLプラットフォームの競争軸へ
Storage Bucketsの登場は、Hugging Face HubがモデルやデータセットのRegistry（登録簿）としての役割を超え、ML開発のより広い工程を支えるプラットフォームへと進化する動きの一環と見ることができます。
Gitベースのバージョン管理という強みを維持しながら、それでは対応しきれない「流動的なデータ層」を補完するストレージ機能を追加したことで、Hubは学習の開始から成果物の公開まで、ワークフロー全体をより垂直に統合する方向性を示しています。
クラウドプロバイダーやMLOpsプラットフォーム各社も類似のワークフロー統合を進めており、「どこでデータを管理し、どこからアクセスするか」という「データ層」の設計は、MLプラットフォーム選定における重要な比較軸のひとつになりつつあります。
Xetエンジンのチャンクベース管理が実際にどの程度のストレージ効率をもたらすか、大規模な分散学習環境でのパフォーマンスはどうか、エンタープライズ向けのサポート・SLAはどのように整備されていくか——これらの点は、今後の普及を左右する要素として注目していく価値があります。ML開発のインフラ設計を見直すタイミングにある組織にとって、Storage Bucketsは検討リストに加えておく選択肢のひとつと言えそうです。
