データバージョニングとは？方式別の設計とDVC・lakeFS採用判断を実装目線で解説【2026年版】

データバージョニングは、学習や分析に使ったデータの実体そのものに版を付け、数か月後でも同じ状態を取り出せるようにする仕組みです。この記事では、版を付ける対象を4層に分けたうえで、Git LFS・DVC・lakeFS・テーブル形式という4方式の構造差を示します。総容量・更新頻度・参照チーム数で方式を切り分ける基準、学習パイプラインへの組み込み順序、ストレージ費用と個人情報の削除要求という運用の壊れどころまで扱います。コードやAPIの版番号の付け方には踏み込みません。

まとめ：データバージョニングの方式選定と導入判断の要点

結論を先に置きます。データバージョニングで最初に決めるのはツールではなく、版を付ける対象と粒度です。生データ全部に版を付けようとすると容量も運用も破綻します。版が要るのは、学習ジョブが直接読む「学習用データセット」と「ラベル」の2層。ここに絞れば、残りは抽出条件の記録で足ります。

方式は総容量・更新頻度・参照チーム数で決まります。数十GBまでで1チーム完結ならDVC、数TB規模でオブジェクトストレージが既にあり複数チームが同じデータを触るならlakeFS、日次で行が追記される表形式のデータならDelta LakeやIcebergのスナップショット機能。この3分岐でほぼ収まります。

導入の判断は再学習の頻度と監査要件で切ります。月1回以上の再学習、または「この予測はどのデータで学習したか」を第三者に説明する義務があるなら導入する。単発のPoCで再学習の予定がないなら、抽出条件をrunに記録するだけで十分です。記録の設計そのものは実験管理の記録項目とrun設計で整理しています。

データバージョニングの定義と、gitだけでは版を追いきれない構造的な理由

用語の輪郭を先に固めます。データバージョニングは、データセットの各状態に一意の識別子を与え、その識別子から中身を完全に復元できる状態を保つことを指します。復元できなければ版管理ではなく、単なる履歴メモです。

版を付ける対象｜生データ・学習用データセット・ラベル・特徴量の4層

機械学習の現場で「データ」と呼ばれるものは1種類ではありません。層ごとに変更の頻度も再現の必要性も違うため、まず対象を分解します。

• 生データ：業務システムやログから取り込んだままの状態。取り込み日時とソース側の主キーで追える場合が多い
• 学習用データセット：抽出・結合・分割を経て学習ジョブが直接読む形。ここが再現の起点になる
• ラベル：アノテーション結果。人の判断が入るため、修正が入ると過去の学習結果と食い違う
• 特徴量：学習用データセットから計算した入力値。複数モデルで共有されると影響範囲が広がる

実務で版管理の投資に見合うのは、学習用データセットとラベルの2層です。生データはソース側の履歴で追えることが多く、二重に版を持つと容量が単純に倍増します。特徴量が複数チームで共有される段階まで来ているなら、版管理より特徴量ストアの二層構成と導入判断が扱う仕組みのほうが運用は軽くなる設計です。優先順位を付けずに4層すべてへ手を広げた現場は、たいてい半年で更新が止まります。

gitに直接入れると壊れる理由｜差分圧縮の前提とファイルサイズ上限

gitはテキストの行単位の差分を前提に設計されています。ParquetやTFRecord、画像のような形式は、中身が1レコード変わっただけでもバイト列としては別物になり、差分圧縮が効きません。コミットのたびにファイル全体が丸ごとリポジトリへ積まれ、履歴の総容量が線形に膨らんでいきます。

上限も現実的な制約になります。GitHubの1ファイルあたりのLFS上限は、FreeとProが2GB、Teamが4GB、Enterprise Cloudが5GB（2026年8月時点）。加えて、リポジトリをクローンした全員が過去の全世代を引き当てる構造のため、世代を重ねるほど新規参加者の初回クローンが重くなります。データを別の場所へ逃がし、gitには識別子だけを残す。4方式に共通するのはこの発想です。なお、ソースコードやAPI、DBスキーマの版番号の付け方は別の主題で、セマンティックバージョニングとAPIバージョニングの設計で扱っています。

データ版管理の4方式｜ポインタ方式とテーブル方式で分かれる管理の粒度

方式は大きく2系統に割れます。ファイル単位で識別子を持たせるポインタ系（Git LFS・DVC・lakeFS）と、テーブル全体のスナップショットを積むテーブル形式系（Delta Lake・Iceberg）です。選択で巻き戻しの粒度が変わります。

Git LFS方式｜ポインタ置換の仕組みと機械学習の現場で足りなくなる境界

Git LFSは、対象ファイルをコミット時に小さなテキストへ置き換える拡張です。リポジトリに入るのはSHA-256のオブジェクトIDとサイズを書いた数行のポインタで、実体は専用のLFSサーバへ送られます。git lfs track で拡張子を登録すれば以降は自動で振り分けられ、既存のgit操作はそのまま使えます。最新リリースはv3.7.1（2025年10月公開）。

足りなくなるのは、データセットが大きく世代が多い場合です。チェックアウト時に必要な世代の実体を取得する仕組みのため、ブランチを切り替えるたびに数GBの転送が走ります。ストレージ課金がホスティング事業者の従量制に乗る点も、自前のS3互換ストレージへ逃がしにくさとして効きます。数百MB規模のデータを少数世代だけ管理するなら手軽ですが、学習データの本命に据えるには制約が多い方式です。

DVC方式｜メタファイルをgitに残しデータ実体をリモートへ逃がす構造

DVCは、データファイルのハッシュ・サイズ・パスを書いた小さなメタファイルをgit管理下に置き、実体は指定したリモートストレージへ送る設計です。dvc add でメタファイルが生成され、これをgitにコミットする。実体の送受信は dvc push と dvc pull が担います。PyPI表示の最新は3.67.1、対応PythonはApache License 2.0のもとで3.9以上（2026年8月時点）。

この構造の利点は、データの版がgitのコミットと自然に対応する点にあります。あるコミットをチェックアウトし、続けてDVC側の取得を走らせれば、そのコミット時点のコード・パラメータ・データが同時に揃う。リモートの実体置き場はS3やAzure Blob Storageなどから選べ、ストレージ費用は自社の契約内に収まります。難点は、大量の小さなファイルを含むデータセットで取得が遅くなることと、gitの操作にDVC側の操作を必ず1手足す運用規律が要る点です。

lakeFS方式｜オブジェクトストレージにブランチとコミットを載せる層

lakeFSは、S3互換のオブジェクトストレージそのものにブランチ・コミット・マージの概念をかぶせるデータレイク向けの層です。最新リリースはv1.86.0（2026年8月5日公開）。アプリケーション側はS3互換のAPIでlakeFS越しにアクセスするため、既存のSparkジョブやデータ処理コードを大きく書き換えずに導入できます。

特徴はブランチ作成がメタデータ操作だけで完結する点です。数TBのデータセットからブランチを切ってもオブジェクトの複製は発生せず、変更したオブジェクトだけが新たに書かれます。取り込んだデータの検証をブランチ上で済ませてから本流へマージする運用が、この構造で成立する仕組みです。反面、サーバコンポーネントの運用が必要で、1人のデータサイエンティストが手元で始める用途には重すぎます。

テーブル形式｜Delta LakeとIcebergが持つスナップショットと時点参照

表形式のデータなら、ファイルの版を意識せずテーブル自体の時点参照で済ませる選択肢があります。Delta Lakeは _delta_log にトランザクションログを積み、任意のバージョン番号やタイムスタンプを指定した読み出し（タイムトラベル）を提供します。最新リリースは4.3.1（2026年7月8日公開）。Apache Icebergも同様にスナップショット単位の参照を持ち、最新リリースは1.11.0（2026年5月20日公開）です。

注意すべきは保持期間の既定値です。Delta Lakeの VACUUM は既定で7日より古い不要ファイルを削除対象とし、実行後はその期間を超えた時点への巻き戻しができなくなります。ログファイルの既定保持期間は30日で、delta.logRetentionDuration で変更できます。半年前の学習データを再現する要件があるなら、既定のまま運用してはいけません。保持期間を要件に合わせて延ばすか、学習に使った時点のスナップショットを別テーブルとして固定する設計が要ります。

方式の選定基準｜総容量・更新頻度・参照チーム数で切り分ける判断の軸

方式の優劣は絶対的なものではなく、案件の3つの数値でほぼ決まります。迷ったときはこの順で当てはめてください。

選定の3軸｜総容量・更新頻度・同時に参照するチーム数で決まる分岐

1つ目の軸が総容量です。全世代を合計して数十GBに収まるなら、DVCで十分に回ります。数TBを超えるとメタファイルとgit操作の組み合わせが重くなり、lakeFSのようにストレージ側で版を持つ構成へ移る判断が現実的になります。

2つ目が更新頻度。週1回のバッチ更新ならファイル単位の版で追えますが、日次で行が追記され続けるテーブルにファイル版を付けるのは筋が悪い。この場合はDelta LakeやIcebergのスナップショットに寄せます。3つ目が参照チーム数で、同じデータを2チーム以上が同時に触るなら、ブランチとマージの仕組みを持つ方式でないと衝突を裁けません。1人が手元で回す実験用データに、サーバ運用が要る方式を持ち込むのは投資として過剰です。

方式別の比較｜導入の重さ・扱えるデータ量・巻き戻しの粒度の対応表

3軸を方式に対応させると次のようになります。表の数値は2026年8月時点の各公式情報と一般的な運用規模の目安です。

混在させても構いません。実務では、テーブルはDelta Lakeの時点参照で追い、そこから切り出した学習用データセットのスナップショットだけをDVCで固定する、という組み合わせが扱いやすい形になります。1方式で全層を覆おうとすると、どこかに無理が出ます。

実装設計｜リモートストレージの構成と学習パイプラインへの組み込み手順

方式が決まったら、実体の置き場とパイプラインへの組み込み順序を設計します。ここを詰めないと、データは版管理されているのに学習ジョブがそれを読んでいない状態が起こります。

リモート設定とキャッシュ｜オブジェクトストレージを実体置き場にする構成

DVCを例にとると、実体の置き場はプロジェクト単位でリモートとして登録し、開発者の手元にはキャッシュディレクトリが作られます。同じハッシュのファイルは手元のキャッシュから復元されるため、複数のブランチを行き来しても再ダウンロードは発生しません。キャッシュが既定のままリポジトリ内に置かれると、複数プロジェクトで同じデータセットを扱う環境では実体が重複します。キャッシュ置き場を共有ディレクトリへ移す設定を先に入れておくとディスク消費を抑えられます。

バケット設計も先に決めます。実体はハッシュ名で並び、人が見て中身を判別できません。バケットやプレフィクスをプロジェクト単位で分け、ライフサイクルルールと権限をその単位で当てられる形にしておくこと。参照が張られたあとの分割は手間がかかります。

学習パイプラインへの組み込み｜取得・学習・記録を並べる実行順序

学習ジョブの実行順序は固定します。順序が崩れると、記録された版と実際に読んだデータがずれます。

1. コードのコミットをチェックアウトし、データ側の取得コマンドで実体を復元する
2. 復元したデータのハッシュまたはスナップショットIDを、実行時のパラメータとして取得する
3. 学習を実行し、そのIDを実験管理の記録へパラメータとして残す
4. 生成したモデルの成果物に、学習に使ったデータ版のIDをタグとして付与する

2の工程を省き、データ版のIDを人が手で書き写す運用は必ずずれます。取得コマンドの出力から機械的に読み取り、そのまま記録へ渡す実装にしてください。

実験管理とモデルレジストリとの対応付け｜データ版IDを紐づける単位

データバージョニングは単体では効きません。データ版のIDが、学習の実行記録と、本番へ出したモデルの両方から辿れて初めて再現性が成立します。学習の実行単位に何をどう記録するかは実験管理のrun設計と記録項目の領分で、データ版のIDはそこでパラメータとして残す項目のひとつになります。

本番に出したモデルの側からも同じIDを辿れる状態が必要です。障害時に問われるのは「今動いているモデルはどのデータで学習したか」であり、これに答えるにはモデルの版とデータの版が1対1で結ばれている必要があります。モデル側の版管理と本番昇格の設計はモデルレジストリの版管理と昇格フローにまとめています。紐づけの単位は、学習の実行1回に対してデータ版1つ。1回の学習で複数のデータセットを結合しているなら、結合後の成果物に版を付け直すほうが追跡は簡単になります。

運用で壊れる箇所｜ストレージ費用の膨張と個人情報の削除要求への対処

導入直後は問題が出ません。壊れるのは半年後、ストレージの請求書と、個人情報の削除要求が届いたときです。設計段階で手を打てる論点を2つ挙げます。

ストレージ費用の増え方｜世代を残す範囲と削除ポリシーの決め方の基準

版管理の費用は、データ量そのものではなく世代数との掛け算で増えます。100GBのデータセットを週次で更新し全世代を残せば、1年で5TB規模。変更されたファイルだけが新たに保存される方式であっても、画像やParquetのように全体が置き換わる形式では削減効果は小さく見積もるべきです。

削除ポリシーは、世代の性質で分けます。本番モデルの学習に使った版は削除しない。それ以外の試行錯誤の版は、保持期間を決めて自動で消す。この2分類だけで、費用の伸びは大きく変わります。判断の材料は、その版から学習されたモデルが今も稼働しているかという1点です。稼働中のモデルに対応する版を消すと、監査で説明できない状態になります。

個人情報を含むデータの版管理｜削除要求と履歴保持が衝突する場面

個人データを含む学習データで削除要求を受けると、全世代から該当レコードを消す必要が生じます。版管理は「過去の状態を変えない」ことを前提に作られているため、この要求と正面から衝突します。

現実的な対処は2つ。ひとつは、個人を直接識別する項目を版管理の対象へ入れない設計です。学習に使うのは仮名化・匿名化された派生データに限り、対応表は版管理の外で別途管理する。もうひとつは、版の保持期間を法令や契約で求められる期間に合わせて短く区切り、期限が来たら世代ごと物理削除する運用です。全世代を無期限に保持する設計は、個人データを含む案件では採用しないこと。

導入してよい3条件と、データバージョニングを見送るべき案件の見極め

ここは条件を付けて言い切ります。データバージョニングは、すべての機械学習案件に必要な仕組みではありません。

導入を決める3条件｜再学習の頻度・監査要件・データ量の実務的な閾値

次の3条件のうち1つでも当てはまるなら、導入する判断が合理的です。

• 再学習が月1回以上ある：データが更新されるたびに精度が動き、原因の切り分けにデータ版の比較が要る
• 監査・説明責任の要件がある：金融や医療の与信・診断支援では、学習データの特定が求められる
• 学習用データセットが数GBを超え、2名以上が触る：手元のファイル名運用が破綻する規模

優先度が高いのは2つ目です。監査要件は後から満たそうとしても、過去のデータが復元できなければ手の打ちようがありません。1つ目と3つ目は、破綻してから導入しても間に合います。

見送ってよい場面｜単発PoCと抽出条件の記録だけで足りる案件の条件

逆に、見送るべき場面も明確です。3か月で終わる単発のPoCで、再学習の予定がなく、担当が1名。この条件が揃うなら、データバージョニングの導入は過剰投資になります。抽出日時・抽出条件・行数・主要カラムの統計量を実験管理のパラメータとして記録しておけば、必要な再現性は確保できます。

もうひとつ見送ってよいのが、ソース側のデータ基盤が既に時点参照を持っている案件です。データウェアハウスがスナップショットを保持していて、日付指定で当時の状態を取り出せるなら、その上にもう1層の版管理を重ねる必要はありません。二重管理はどちらが正なのか分からなくなる分だけ、状況を悪化させます。

ツール選定の現況｜DVCのlakeFS移管が採用判断に与える影響と見通し

ツール選定の前提が2025年に動きました。DVCはIterativeからlakeFSを開発するTreeverseへ移管され、2025年11月18日公開の告知で、ライセンス変更・機能の有料化・アクセス制限のいずれも予定はなく、コマンドや既存ワークフローに破壊的変更はないと明記されています。位置づけは、DVCが小〜中規模のデータサイエンス案件向けの軽量ツール、lakeFSがエンタープライズのデータ基盤向けという住み分けです。

採用判断への影響は限定的と見ています。小規模から始めて大規模へ移る経路は描きやすくなり、一方で単一ベンダーへの依存度は上がりました。判断材料になるのは、DVCがApache License 2.0のオープンソースで、メタファイルの中身がハッシュとパスという単純な構造である点。開発が滞っても、実体を復元する処理は自前で書けます。この移行可能性をツール選定の基準に入れてください。製品横断の選び方はMLOpsツールの比較と選定基準で整理しています。既存のデータ基盤へ版管理を後付けする設計や、監査に耐える再現性を備えた学習基盤の構築は、機械学習モデル開発として外部の実装知見を入れながら進めると、運用用に入ってからの手戻りを抑えられます。

データバージョニングの導入と運用の現場でよくある質問への実務的な回答

導入検討でつまずきやすい点を、実務で寄せられる疑問の形で整理します。

データバージョニングとバージョン管理（Git）の違いは何ですか？

対象と保存の仕組みが違います。Gitはテキストの行差分を前提にソースコードの履歴を管理する仕組みで、バイナリの大容量ファイルには差分圧縮が効きません。データバージョニングは、データの実体を別のストレージへ置き、gitには識別子だけを残すことでこの制約を回避します。両者は排他ではなく、コードをgit、データをDVCやlakeFSで管理し、コミット単位で対応させる使い方が基本形です。

DVCとlakeFSはどちらを選べばよいですか？

総容量とチーム数で切り分けます。全世代の合計が数十GBまでで、1チームが手元で回すならDVC。サーバ運用が不要で、gitの操作にコマンドを1つ足すだけで始められます。数TB規模のデータレイクがあり、複数チームが同じデータを同時に触るならlakeFS。ブランチ作成がメタデータ操作で完結するため、大規模でも検証用の分岐を現実的な速度で切れます。

数百GBの画像データでもデータバージョニングは現実的ですか？

現実的ですが、全ファイルに版を付ける設計は避けてください。画像は1枚ずつが独立したバイナリのため、ファイル数が多いほど取得処理が遅くなります。実務では、画像そのものは追記のみのストレージへ置いて削除しない運用とし、版を付けるのは「どの画像IDを学習に使ったか」を書いたマニフェストファイルに絞る方式が扱いやすい形になります。

データを更新するたびに全件をコピーして保存するのですか？

方式によります。DVCはファイル単位のハッシュで管理するため、変更のなかったファイルは再保存されません。lakeFSも変更されたオブジェクトだけを新たに書き、ブランチ作成では複製が発生しない構造です。ただし、1つの大きなParquetファイルを毎回書き換える形なら、ファイル単位では全体が別物になり毎回丸ごと保存されます。

個人情報を含む学習データで削除要求が来た場合はどうしますか？

過去の全世代から該当レコードを消す作業が必要になり、版管理の前提と衝突します。設計段階で回避するのが唯一の現実解です。個人を直接識別する項目は版管理の対象へ入れず、仮名化した派生データだけを管理対象にする。あわせて、版の保持期間を契約や法令で求められる期間に合わせて区切り、期限到来で世代ごと削除する運用を組んでおきます。

関連記事

• 実験管理とは？記録項目とrun設計：データ版IDを学習の実行記録へ残す方法を扱います。
• モデルレジストリとは？版管理と本番昇格：モデル側の版とデータ版の紐づけ先です。
• 特徴量ストアとは？二層構成と導入判断：特徴量を組織横断で共有する段階の選択肢です。
• バージョニングとは？SemVerとAPI版の設計：コードと成果物側の版番号の付け方を解説します。
• MLOpsツール比較｜選定基準と最小構成：製品横断でスタックを選ぶ際の基準です。