アーカイブ / AI Agent
AIエージェントによる表の修正案を分岐・比較・統合するGit4Data
Git4Data
概要
- Git4Dataは、表のスナップショット、分岐、行の差分確認、衝突方針付き統合をSQLで扱う。
- 著者らのBranchBench実験では、data_cleaningのウォーム実行の平均がGit4Dataで58.6秒、DoltDBで1084.2秒だった。
- 導入時は主キー、変更の正誤を判定するデータ、衝突時の採用方針を確認する必要がある。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Git4Dataの仕組み
- 01元表の状態を保存
- 02修正用の表を分岐
- 03変更行を比較
- 04分岐の変更を統合
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
Git4Dataは、同じ表から複数の修正案を分岐させ、変更行を比べて統合する仕組みである。AIエージェントが別々の案を試す場合、途中の更新を互いに隔離し、どの行が変わったかを後から確認できることが重要になる。
例えば重複レコードの整理と項目の表記統一では、修正される行が異なりうる。元表を丸ごと複製して案を増やす方法は、表が大きいほど作成時間と保存領域を使う。
手法
Git4Dataは、スナップショットという表の特定時点の状態を記録し、そこから独立して更新できる表を作る。例えば顧客表から二つの表を分岐し、一方で表記を統一し、もう一方で重複候補を整理する。差分操作は、二つの版で内容が一致しない行を報告する。
統合には、元の状態と二つの分岐を比べる「三者間統合」を使う。主キーがある表では双方が同じキーの行を変更したときに衝突を判定し、FAILは統合を中止、SKIPは統合先、ACCEPTは統合元の行を採用する。MatrixOneでの実装は、分岐後に追加された保存データと削除記録を調べ、採用した変更を一つの取引として反映する。
新規性
Git4Dataは、表の時点を保存するスナップショット、分岐、行の差分確認、衝突方針を指定した統合をSQL操作として提供する。データベースを版管理の入れ物、表を版付きの対象として扱う。
MatrixOneでの試作では、分岐時に表の管理情報を複製し、差分と統合では分岐後の変更を主に読む。両方の分岐が同じ行を変えた場合も、共通の分岐元を参照して判定する。
従来手法との違い
DoltDBもSQLデータベースでGit風の分岐や統合を扱う。Git4DataはMatrixOneのスナップショットと変更差分を使い、表単位で分岐した後の行の比較と統合を行う。論文はBranchBenchで両者の処理時間を比較している。
同じMatrixOne内では、表全体を複製するINSERT、表の内容を読み比べるSQL、差分を反映するSQLとも比較した。報告された時間差は、この実装、基準処理、実験条件での結果である。
実験結果
著者らはTPC-Hのlineitem表、Scale Factor 100の100 GB表で操作を測定した。主キーありの分岐作成は0.20秒、追加の管理情報は314 KBで、表全体をINSERTでコピーする基準は114.6秒、追加保存量は34 GBだった。1,000行を更新した条件では、差分確認が0.19秒対SQLの316.16秒、ACCEPTでの統合が0.35秒対SQLの321.52秒だった。
BranchBenchのScale Factor 100、約4,700万行では、四つの作業をそれぞれ5エージェント、20ステップで実行した。著者らの報告では、data_cleaningのウォーム実行の平均はGit4Dataが58.6秒、DoltDBが1084.2秒だった。別のsimulation作業では、1,000エージェントが各自で分岐と分岐内の処理を行い、Git4Dataは400秒で完了、DoltDBは2時間以内に完了しなかった。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：顧客表の表記ゆれを複数の修正規則で試す。入力は主キー付きの元表と各規則で、分岐ごとに修正SQLを実行し、差分に出た行を担当者が確認する。採用する変更だけを分岐に残して統合し、修正済みの表と採否の記録を出力する。
必要な元データは顧客表と修正判断に使う人手確定の照合結果で、Git4Data自体に追加の学習データは要らない。専用センサーも想定しない。導入先の項目名と主キーに合わせてSQLを調整し、衝突時の扱いを業務手順に合わせて決める。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：主キー付きの業務表から検証用データを用意し、元表、二つの修正SQL、変更の正誤を判定する人手確定ラベルをそろえる。版管理自体に学習データや専用センサーは不要で、対象の項目名と主キーに合わせてSQLを調整する。
同じ修正を表コピーと手書きSQLでも実行し、分岐作成時間、追加保存量、差分確認時間、統合時間を測る。ラベルと照合して変更行の正誤や衝突件数を記録し、FAIL・SKIP・ACCEPTごとに想定した行が残るか確認する。
限界と課題
著者が明記する制約は、衝突解決が現在は行単位であり、値の意味を踏まえた細かな解決は今後の課題という点である。また、千エージェントの実験では共有計算資源と入出力が主な負荷となり、表全体を走査・書き換える作業はデータ量に応じて遅くなった。
編集上の検証事項：主キーがない表の重複行を期待どおりに扱えるか、共通の分岐元が失われた場合に統合結果をどう確認するかを試したい。FAIL・SKIP・ACCEPTが承認手順に合うか、必要な期間だけ変更履歴を追えるかも対象環境で確かめる。
出典
元のタイトル・要旨を確認する（英語）
Git4Data: Database-Native Version Control for AI Agents
Large Language Model (LLM) agents increasingly explore many candidate states of relational data in parallel, each of which should remain isolated, reproducible, and auditable, preferably through the same SQL interface used for ordinary data work. Existing tools support this requirement only partially: source-code version control does not scale to large datasets, whereas relational databases manage large data efficiently but rarely expose native branching, comparison, and merging. We present Git4Data, a database-native version-control layer for agentic workflows. Git4Data treats a database as a repository and a table as a versioned object, exposing Git-style operations (snapshot/tag, branch, diff, and merge with explicit conflict-resolution policies) through SQL extensions. Implemented in MatrixOne, a cloud-native relational database, Git4Data leverages immutable object storage and MVCC to make the cost of these operations proportional to the size of the change rather than the size of the data. On the BranchBench agentic branching workloads, Git4Data outperforms DoltDB by up to an order of magnitude. Overall, we believe this work sheds light on how relational databases can better support AI agents through efficient versioning.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01