7月7日、Scott Chaconが「Agentic Version Control Benchmarks」と題した記事を公開した。この記事では、AIコーディングエージェントにGit・Jujutsu・GitButlerのいずれのバージョン管理ツールを使わせるべきかをベンチマーク比較した調査が詳しく紹介されている。
なぜエージェントとバージョン管理ツールの相性が問われるのか
AIエージェントがコードを書くだけでなく、コミット操作まで担うケースが増えている。エージェントはツールをCLI経由で呼び出すため、コマンド数が多いほどトークンを消費し、レイテンシが増える。Gitのrebase -iのような対話型コマンドはエージェントにとって扱いにくく、複数ステップの操作が必要になりがちだ。この文脈で「エージェントフレンドリーなCLI設計」が実際に差を生むかどうかを検証したのが本ベンチマークの動機となっている。
結論から：GitButlerはGitより60%速く、コマンド数は80%少ない
記事のTLDRは明快だ。
- GitButler：Gitと比較して約60%高速、コマンド数は約80%削減
- Jujutsu：Gitより遅い
つまり、Claude CodeやCodexを使ってコミットの選択・分割・スカッシュ・アメンドといった複雑なバージョン管理操作を行うなら、GitButlerがGitやJujutsuよりも速く、消費トークン数も少ないという結論だ。
ベンチマークの設計
著者はGitHubとGitButlerの共同創業者であるScott Chaconで、同じくGitButler共同創業者のKirilが実験を設計・実施した。
計測対象は5つのシナリオ（スカッシュ、アメンドなどの典型的なバージョン管理タスク）で、以下の組み合わせで実行された。
- エージェント：Claude Code と Codex の2種類（元記事記載のモデル名を参照）
- ツールセット：Git / Jujutsu / GitButler の3種類
- 各シナリオ：10回ずつ実行
合計300回分のグレーディング済みランが得られた。
重要な設計方針として、エージェントがコードを書くことは一切ない。各ランは同一の初期状態から始まり、プレーンテキストの指示（「このコミットをスカッシュせよ」など）を受け取り、かかった時間と最終的なGit状態の正確さで評価される。採点は最終的なGit historyだけを見る決定論的スクリプトで行われ、途中のコマンド順序は問わない。
また、フェアネスの担保として、JujutsuとGitButlerのランではgit rebase -iなどの生のGit書き込みコマンドが明示的にブロックされている。各ツールの本来の能力だけを測る設計だ。
なお、比較対象の一つであるJujutsu（jj）は、Googleが開発したGit互換の分散バージョン管理システムで、よりシンプルなコマンド体系を特徴とする比較的新しいツールだ。日本語圏ではまだ普及途上にあるが、Git代替として一部の開発者コミュニティで注目されている。
全300ランの散布図が示すもの
記事中に掲載された全300ランの散布図（1ドット＝1ラン）では、オレンジのドット（GitButler）が左側（＝実行時間が短い）に集中しているのが一目でわかる。GitやJujutsuのドットはそれより右に散らばっており、待ち時間の差が視覚的に明確だ。単発の平均値ではなく全ランの分布を示している点で、外れ値の影響も確認できる構成になっている。
試す方法
GitButlerのエージェント向けセットアップについては、元記事に記載されているインストール手順およびGitHubリポジトリを参照してほしい。
ソースコードと全ランのデータはvcbench.devおよび上記リポジトリで公開されており、自分で再現実行することも可能だ。
なお、本ベンチマークはGitButler自身が公開したものであり、利益相反の観点は念頭に置いておく必要がある。ただし、グレーディングスクリプトや全ランデータが公開されている点は透明性の担保になっている。
詳細はAgentic Version Control Benchmarksを参照していただきたい。
