学習済みモデル、ゲームアセット、ビルド成果物、サンプルデータ。ソースコードと一緒に大きなバイナリを扱いたいという要件は、プロジェクトが育つほど 10 GB → 100 GB → 1 TB とオーダーが変わっていきます。ところが素の Git と GitHub は本質的にはテキストのバージョン管理に最適化されていて、100 MiB を超えた時点で push が弾かれます。
さらに厄介なのは、Git LFS を使えば済むかというとそうでもない点です。10 GB では十分現実的な LFS 単体運用が、100 GB を超えたあたりで急に破綻し始め、1 TB クラスではオブジェクトストレージ連携がほぼ必須になります。本記事では 2026 年 7 月時点の公式ドキュメントと料金ページを基準に、代表的な 6 つの選択肢を「10 GB / 100 GB / 1000 GB」の 3 スケールで並べて、切り替え閾値を整理します。
この記事で得られること
- GitHub の素の Git 制限（50 MiB 警告・100 MiB ブロック・リポジトリ推奨 1 GB）を数字で押さえられる
- Git LFS の課金モデル（従量課金・無料枠・単一ファイル上限）と、コストが跳ねる 2 つの構造要因が分かる
- GitHub Releases、Cloudflare R2 と自前 LFS プロキシ、DVC、AWS S3、Hugging Face Hub の位置づけが整理できる
- 10 GB / 100 GB / 1000 GB それぞれで、どの選択肢が生き残るかを月額とともに把握できる
GitHub 本体のファイルサイズ制限
Git LFS の話に入る前に、素の Git として GitHub にどこまで積めるかを整理します。ここは GitHub Docs の About large files が一次情報です。
- 50 MiB を超えるファイルを push すると警告が出る
- 100 MiB を超えるファイルは強制的にブロックされる（Git push が拒否される）
- Web UI からのアップロードは 25 MiB が上限
- 1 回の git push 全体で 2 GiB がハードリミット
- リポジトリ全体は 1 GB 未満が推奨、5 GB 超はサポートから改善勧告が来る可能性がある
つまり 10 GB クラスに達した時点で、素の Git では立ち行きません。Git LFS か Releases か外部ストレージか、という分岐の入口です。
Git LFS の課金モデルとプラン別上限
Git LFS は、実体を GitHub 側の別ストレージに置き、Git 側には数十バイトのポインタだけを残す仕組みです。GitHub の Git LFS 課金ドキュメントによれば、課金体系は 2023 年から 2025 年にかけて「50 GB あたり 5 USD のデータパック」から従量課金（metered billing）に完全移行しました。
無料枠と超過単価は次のとおりです。
| プラン | 無料ストレージ | 無料帯域（月） | 単一ファイル上限 |
|---|---|---|---|
| GitHub Free | 10 GiB | 10 GiB | 2 GB |
| GitHub Pro | 10 GiB | 10 GiB | 2 GB |
| GitHub Team | 250 GiB | 250 GiB | 4 GB |
| GitHub Enterprise Cloud | 250 GiB | 250 GiB | 5 GB |
無料枠を超えた分は、ストレージが 0.07 USD/GiB・月、帯域が 0.0875 USD/GiB で課金されます。予算（spending limit）を初期値の 0 USD にしておくと、超過した瞬間からその月末まで LFS 操作がブロックされ、翌月 1 日にリセットされる仕様です。
ここで注意したいのが単一ファイル上限です。1 本 5 GB を超えるファイルは LFS でも拒否されます。1 TB クラスでも「ファイル 1 本のサイズ」自体はこの上限に収まっているのが普通なので実運用ではあまり刺さりませんが、モデル 1 本を丸ごと 8 GB で置きたい、といったケースでは LFS 全体が使えなくなります。
Git LFS のコストが跳ねる 2 つの構造要因
なぜ Git LFS は「気付いたら請求が跳ねる」と言われるのか。理由は 2 つあります。
帯域はリポジトリ所有者に集中する
GitHub の課金モデルでは、LFS ファイルのダウンロード帯域はすべてリポジトリ所有者に請求されます。パブリック・プライベートを問わず、他人が fork して clone しても、GitHub Actions が CI ジョブで LFS を落としても、外部の CDN が定期的に取りに来ても、すべて所有者側のクォータを削ります。
CI が LFS キャッシュを持たずに毎回落とす構成だと、この帯域が線形にストレージ規模に比例して膨らみます。100 GB クラスで CI を月 100 回回すだけで 10 TB の転送になり、次章の試算のとおり月 800 USD 級の請求になります。
履歴分だけストレージが積み上がる
Git LFS はバイナリ差分（デルタ圧縮）を取りません。ファイルを 1 バイトだけ書き換えて push すると、丸ごと新しいオブジェクトが追加で保管されます。100 GB のデータを月 4 回更新すると、月末には 400 GB が LFS バックエンドに残る計算です。
git lfs prune で古い履歴を明示的に消さない限り、ストレージ使用量は不可逆的に増えていきます。頻繁に再学習するモデル、CI で自動更新されるビルド成果物などを LFS に載せると、この構造が効いてきます。
代替パターン 5 種
Git LFS 以外に、大容量バイナリを扱う実用的な選択肢を 5 つ挙げます。
GitHub Releases
そのファイルがソースの変更に追随して日常的に書き換わるものではなく、ビルド成果物や確定した配布用アーカイブなら、GitHub Releases が最も素直です。
- 1 リリースあたり最大 1000 アセット、各ファイル 2 GiB 未満
- 総サイズと帯域には上限なし・追加課金なし
- Git clone には乗らないので、clone を重くしない
100 GB や 1 TB を扱いたい場合も、split で 1.9 GiB ずつに分けて添付する運用でカバーできます。1 リリースあたり最大 1000 アセットまで積めるので、理論上は 1.9 TB 弱まで 1 タグに載せられます。GitHub CLI の gh release create と gh release download でスクリプト化できます。
配布側にとっては帯域無料が効きます。バージョン管理は「タグ単位」の粒度になり、リポジトリの working tree に自動で現れないので、ソースと成果物を分離できる用途に向きます。
自前 LFS プロキシ ＋ Cloudflare R2
Git LFS は Batch API というオープン仕様で、実体を保管するサーバー側を差し替えられます。リポジトリの .lfsconfig に自前の LFS URL を指定すれば、Git 側の操作感（git push / git pull）はそのままに、実体の保管先だけを外部に逃がせます。
代表的な組み合わせが、git-lfs-s3-proxy のような OSS のプロキシを Cloudflare Workers に置き、バックエンドを Cloudflare R2 にするパターンです。R2 の料金は次のような構造になっています。
- ストレージ 0.015 USD/GB・月（10 GB まで無料枠）
- エグレス（ダウンロード帯域）は完全無料
- Class A 操作 4.50 USD/百万、Class B 操作 0.36 USD/百万
エグレスが無料なので、1 TB を月 10 回ダウンロード（合計 10 TB 転送）してもストレージ費だけで済みます。GitHub ネイティブ LFS の帯域課金を完全に切り離せるのがこの構成の最大の強みです。似た戦略で Backblaze B2 を使う手もあり、B2 は月次平均ストレージの 3 倍までエグレス無料、超過は 0.01 USD/GB です。
弱点は運用負荷で、プロキシの認証や URL に埋まる資格情報の扱いは自前で設計する必要があります。ここを踏み外すとバケットが読み放題になるので、IAM の最小権限 と署名 URL の TTL 管理は必須です。
DVC ＋ オブジェクトストレージ
機械学習のデータセットやモデル重み、パイプラインの中間生成物なら、DVC (Data Version Control) が候補になります。DVC は Git の上にオーバーレイする OSS の CLI で、Git には .dvc という軽量なポインタファイルだけを追跡させ、実体は S3、Google Cloud Storage、Cloudflare R2、Google Drive など任意のリモートに同期します。
Git LFS との違いは、DVC が「データパイプラインの再現性」まで面倒を見る点にあります。dvc.yaml にステージ（前処理・学習・評価）を書き、dvc repro で再現できます。GitHub Actions からも setup-dvc アクション 経由で使えます。
料金は選ぶバックエンド次第で、R2 なら 100 GB クラスでも数 USD で済みます。S3 Standard なら 0.023 USD/GB・月＋エグレス（US East で 0.09 USD/GB 目安）が発生します。運用は dvc push / dvc pull を通常の Git フローに組み込むことになり、チーム全員に習得コストが発生します。ML 領域ならリターンは十分見合いますが、汎用のバイナリ配布にはややオーバースペックです。
なお、DVC の OSS プロジェクトは 2025 年 11 月に lakeFS を運営する Treeverse に移管されており、ロードマップ変化は継続ウォッチしたい論点です。
git-annex / git-remote-s3
より汎用に「Git はメタデータ、実体は外部」を実現する OSS が git-annex と git-remote-s3 です。
git-annex は「実体は special remote に置き、Git には参照だけを入れる」設計で、S3・rsync・USB ドライブ・オフライン媒体・IPFS など多彩な保管先に対応します。分散環境、アーカイブ用途、長期保存で強みが出る一方、git annex add / get / copy / sync という独自コマンド体系を覚える必要があり、GitHub 中心の普通の Git 体験からはだいぶ離れます。
git-remote-s3 は S3 バケットを Git のリモート（かつ LFS サーバー）として扱う AWS Labs の実装です。IAM 最小権限と SSE-KMS を推奨構成にできるので、GitHub を経由せずに社内 AWS で完結させたい要件と噛み合います。
Hugging Face Hub / Zenodo / 直接オブジェクトストレージ参照
配布物のドメインが決まっているなら、専用ホスティングが第一候補です。
- ML モデル・データセットなら Hugging Face Hub が有力で、公開リポジトリは実質無制限、エグレスと CDN も無料。バックエンドは Xet（旧 XetHub）ベースでコンテンツ定義チャンキングによる重複排除が効きます
- 研究データで DOI が必要なら Zenodo が 1 レコード 50 GB まで無料、GitHub 連携でリリース時に自動アーカイブできます
- ゲームアセットのように「アプリが URL 経由で実体を取りに行く」構造なら、Git リポジトリには
assets.jsonのようなメタデータだけを置き、実体は R2 や S3 に直接置く「Git-less」パターンが最軽量です
スケール別のコスト比較
シナリオを固定して、10 GB / 100 GB / 1000 GB の 3 スケールで月額を並べます。ここでは次のように置きました。
- 保管サイズ = その月のピーク時ストレージ（履歴累積を含む）
- 月間転送量 = 保管サイズの 10 倍（CI と開発者の pull を合わせた中量アクティブ想定）
- S3 のエグレスは US East 目安の 0.09 USD/GB、最初の 100 GB/月はアカウント全体で無料
| 選択肢 | 10 GB / 100 GB 転送 | 100 GB / 1000 GB 転送 | 1000 GB / 10 TB 転送 |
|---|---|---|---|
| GitHub LFS (Free/Pro) | 約 7.88 USD | 約 92.93 USD | 約 943 USD |
| GitHub LFS (Team/Ent.) | 0 USD（枠内） | 約 65.63 USD | 約 906 USD |
| GitHub Releases | 0 USD | 0 USD（分割必要） | 0 USD（分割必要） |
| 自前 LFS プロキシ ＋ Cloudflare R2 | 0 USD | 約 1.35 USD | 約 14.85 USD |
| AWS S3 Standard 単独 | 約 0.23 USD | 約 83.30 USD | 約 914 USD |
| Hugging Face Hub（公開） | 0 USD | 0 USD | 0 USD |
内訳を軽く辿ります。GitHub LFS Free/Pro は 10 GiB のストレージ・帯域無料枠を超えたぶんが 0.07 / 0.0875 USD で線形に効いてくるので、100 GB を超えた瞬間から数十 USD、1 TB では 3 桁 USD に届きます。Team/Enterprise Cloud は 250 GiB 無料枠が効くので 100 GB クラスまでは楽ですが、1 TB では結局帯域超過で 900 USD 級に届きます。座席課金（Team は 4 USD/user/月）は別建てです。
R2 と Hugging Face の 3 桁差はすべてエグレス無料が効いているぶんです。特に R2 はストレージ単価が 0.015 USD/GB・月なので、1 TB でも 15 USD 弱で収まります。S3 単独は「アカウント全体で最初の 100 GB/月」のエグレス無料枠を超えると 0.09 USD/GB で効いてくるため、転送が読めないプロジェクトで一気に費用が跳ねます。
Releases はサイズにかかわらず 0 USD ですが、1 ファイル 2 GiB 未満に分割する運用と、Git の working tree に載らないという制約が付きます。
スケール × 用途で選ぶ
上の表を横に読み替えると、意思決定の分岐が見えてきます。
10 GB クラス
- 個人開発・小規模チーム: GitHub LFS のまま。Free/Pro でも 10 GiB の無料枠に入り、月数 USD で収まります
- 配布が主目的: GitHub Releases。1 ファイル 2 GiB を超える場合だけ split すれば済みます
- 公開 ML モデル: Hugging Face Hub 一択で 0 USD
10 GB では「そもそもオブジェクトストレージ連携のセットアップコスト」の方が高くつきやすく、素直に LFS か Releases に載せた方が総合的に安いです。R2 バックエンドを組む価値が出てくるのは、次の 100 GB クラスからです。
100 GB クラス
- チーム開発で CI が LFS を毎回落とす: 自前 LFS プロキシ ＋ Cloudflare R2。月数 USD で済み、GitHub LFS Team の座席課金と 66 USD 級の帯域超過を両方回避できます
- 素直な運用を優先: GitHub Team に上げれば 250 GiB 無料枠に収まる場合もありますが、CI が回るほど転送は 1 TB を超えやすいので次段階を見据えたほうが安全です
- ML パイプライン: DVC ＋ R2/S3 を先んじて入れておくと 1 TB に伸びても移行不要です
- 配布のみ: Releases はサイズにかかわらず 0 USD。ただし 50 個超のアセットに分かれる運用性は事前に検証が必要です
100 GB あたりが、Git LFS 単体でどこまで粘るかの分水嶺です。ここを超えると帯域課金が線形に効いてきて、月次 100 USD が視野に入ります。
1000 GB / 1 TB クラス
- チーム開発: 自前 LFS プロキシ ＋ Cloudflare R2 の一択に近くなります。GitHub LFS Team/Enterprise でも月次 900 USD 級、S3 単独でも 900 USD 級になるのに対し、R2 なら 15 USD で済みます
- ML パイプライン: DVC ＋ R2、もしくは lakeFS を先頭に置いて S3 データレイクへ寄せます
- ゲーム・映像などの巨大バイナリ: Perforce Helix Core のような専用製品が現実的な候補になります。Git の枠組みそのものを外れる代わりに、大規模チームのロックや UE/Unity 連携が強力です
1 TB クラスに達すると、Git LFS ネイティブは費用と単一プランの帯域上限（実質 250 GiB/月無料）の両面で無理筋になります。「Git を残すか、Git を捨てるか」の意思決定を先に済ませ、残す場合は R2 や S3 へ実体を逃がす構成が必要です。
判断を切り替える閾値
数字と用途を突き合わせると、実装フェーズを変えるべき閾値は次のあたりに集約されます。
- 単一ファイルが 5 GB を超えた: LFS 全般が使えないので、分割か外部ストレージ直参照に切り替える
- 月間帯域が 250 GiB を継続的に超えた: GitHub LFS Team/Enterprise の無料枠が飽和するので R2 バックエンドに寄せる
- LFS ストレージが 100 GB を超えた: 履歴累積によるストレージ膨張が視野に入るので、prune 運用か DVC ＋ 外部ストレージへの移行を検討する
- CI ジョブが LFS を毎回全取得している: ジョブキャッシュを入れるか、そもそも R2 バックエンドに切り替える
まとめ
10 GB では素直に GitHub LFS、100 GB では自前 LFS プロキシ ＋ Cloudflare R2、1 TB クラスでは R2 か DVC か Perforce を含めた大きな設計判断。同じ「大容量バイナリを GitHub 周辺で扱う」という要件でも、スケールが 1 桁上がるごとに最適解は入れ替わります。裏側でずっと効いているのは、帯域がリポジトリ所有者に集中する構造と、履歴分だけストレージが積み上がる構造の 2 つです。この 2 つが見えていれば、10 GB から 1 TB への成長曲線を眺めながら、どのフェーズで何に乗り換えるかを事前に見積もれます。
以上、GitHub で大容量バイナリを扱うときの Git LFS と代替パターンをスケール別に比較した、現場からお送りしました。