データベースにGitのブランチを持ち込む「Git4Data」、AIエージェントの並行作業を想定

AIエージェントに業務データを触らせるとき、いちばん厄介なのは「試した結果をどう戻すか」です。arXiv（研究者が査読前の論文を公開するサイト）で公開された「Git4Data」は、その問題をデータベース側で解こうとする提案です。

テーブルをバージョン管理の対象にする

論文が想定するのは、大規模言語モデル（LLM）を使ったエージェントが、リレーショナルデータの候補となる状態をいくつも並行して探索する状況です。それぞれの状態は互いに隔離され、再現でき、後から監査できることが望ましく、しかも普段のデータ作業と同じSQLから扱えるのが理想だとします。

既存の道具はこの要件を部分的にしか満たしません。ソースコード向けのバージョン管理は大きなデータセットに対して規模が合わず、逆にリレーショナルデータベースは大量データの扱いは得意でも、ブランチ・比較・マージをネイティブに提供している例はまれです。

Git4Dataはデータベースをリポジトリ、テーブルをバージョン管理される対象として捉えます。スナップショットとタグ付け、ブランチ、差分（diff）、そして競合解決ポリシーを明示したマージといったGit風の操作を、SQLの拡張として露出させる設計です。

コストをデータ量ではなく変更量に比例させる

実装先はクラウドネイティブなリレーショナルデータベース「MatrixOne」。書き換えできないオブジェクトストレージと、複数のバージョンを同時に保持する仕組みであるMVCC（多版型同時実行制御）を利用し、これらの操作のコストをデータ全体の大きさではなく変更の大きさに比例させたとしています。この点が、単にデータをコピーしてブランチを作るやり方との差になります。

評価にはエージェントによるブランチ操作を模したワークロード「BranchBench」を用い、Gitライクなバージョン管理を備えたデータベース「DoltDB」に対して最大で一桁の性能差をつけたと報告しています。

注目したいのは、この論文が「エージェントがデータを壊すかもしれない」という前提から出発している点です。エージェントに安全な砂場を与えるのではなく、本番のデータベースの中に分岐と巻き戻しの語彙を用意する。企業がAIによる自動化を実データに近づけていく段階で、この種の基盤が実装レベルで出てくること自体が一つの兆候だと考えられます。なお性能の主張は論文著者による評価であり、第三者による再現は確認できていません。

出典: arXiv:2609.02106v1「Git4Data: Database-Native Version Control for AI Agents」