Gitの代替・拡張の動きを俯瞰する OpenAI Pandoから見える6つの方向

Posted at 2026-11-04

はじめに

2026 年 11 月 3 日（JST）、OpenAI の開発者向けアカウント @OpenAIDevs が、モノレポ向けの新しい Git バックエンド「Pando」を作ったと投稿しました。

We built Pando, a new Git backend for our monorepo, to handle more pushes and fetches without changing how our engineers and agents use Git.
Pando cut push latency by ~80% and now serves nearly a petabyte of Git data a day. We can grow Git capacity alongside agent usage.

出典: @OpenAIDevs の投稿

その前月の 2026 年 10 月には、Anthropic が社内モノレポを Git から独自のバージョン管理システム Scion に移したと説明しています。どちらも「エージェントが増えて Git が持たなくなった」という文脈ですが、変えている層が違います。サーバーの裏側だけを入れ替える話と、バージョン管理そのものを捨てる話と、手元のクライアントの使い心地を変える話は別物です。自分の悩みに効くのはどの層なのか、というのがこの記事の問いです。

対象読者は、AI コーディングエージェントや CI から同じリポジトリを扱い、Git の遅さ・衝突・履歴の扱いにくさが気になり始めた開発者です。

この記事の確認範囲を先に書いておきます。

実行して確かめたもの: Jujutsu（jj 0.45.1）の Git 互換の動作、Git 本体（2.43.0）の partial clone・sparse-checkout・Scalar・bundle URI・reftable の可否。Linux の実行環境で、すべてローカルの一時ディレクトリで完結しています
公式ドキュメントや論文を読んだだけのもの: Scion、Piper、Sapling、VFS for Git、Spokes、GitFarm、Pijul、Fossil、Entire、GitButler、Lit
報道と投稿だけに基づくもの: Pando。公式記事「Scaling Git at OpenAI」は、この記事の調査では HTTP 403 が返って本文を読めていません。アクセス制限の回避はしていないため、Pando の数値は投稿の逐語に限り、設計の細部は第三者の要約を出典つきで添えます

6 つの方向の一覧

#	方向	取り組み	置き換える層	Git との関係	手に入るか
1	サーバーの裏側を差し替える	OpenAI Pando / GitHub Spokes / Uber GitFarm	サーバー側の保存・配信・実行	クライアントは Git のまま	Pando・GitFarm は社内、Spokes は GitHub 内部
2	Git をやめて社内基盤を作る	Google Piper（CitC）/ Anthropic Scion	バージョン管理システム全体	別系統	どちらも社内専用
3	手元のクライアントを作り替える	Jujutsu / Sapling	クライアントの操作体系	Git リポジトリをそのまま扱える	OSS（Sapling のサーバー側は外部利用未サポート）
4	別の思想で作られた VCS	Pijul / Fossil	データモデルごと	別系統	OSS
5	Git 本体が取り込む	Scalar / partial clone / bundle URI / reftable	Git の内部実装と既定値	Git そのもの	Git に同梱
6	エージェント向けに上へ載せる	Entire / GitButler / Lit	記録・並列作業・操作 IF	Git に載る（Lit は自称で代替）	OSS・製品

1. サーバーの裏側だけを差し替える（Pando・Spokes・GitFarm）

クライアントから見える Git の振る舞いは変えず、サーバー側の保存・配信を作り直す方向です。

OpenAI Pando は冒頭の投稿のとおり、「エンジニアとエージェントの Git の使い方を変えずに」push と fetch を増やすためのバックエンドです。投稿に書かれている数値は、push latency が約 80% 減ったことと、1 日にほぼ 1 ペタバイトの Git データを配信していることの 2 点です。測り方（平均か中央値か）は投稿からは読み取れません。

設計については、第三者の要約ページ ai-tldr.dev が次のように伝えています。公式本文で確認できていない点は、そのまま受け取らないでください。

push ごとに不変の packfile を blob ストアへ置き、ブランチごとの ref の版を別のメタデータストアで持つ。無関係なブランチへの push は互いに待たない
fetch は保存済みの pack を選び、Git の packfile-uri 機能でダウンロードリンクを返す
小さな pack はバックグラウンドで大きな pack にまとめる（要約は LSM ツリーに似た処理と表現）
技術の共有方法は検討中で、Git クライアント側の修正は upstream へ送っている

GitHub Spokes（旧称 DGit）は、GitHub が 2016 年に公開した repository の保存方式です。GitHub のエンジニアリングブログによると、各リポジトリを独立した 3 台のサーバーに置き、書き込みは 3 台へ流して 2 台以上が確認した時点で確定します。レプリケーションはディスクではなくアプリケーション層で、Git 自身のプロトコルを使って 3 つの Git リポジトリを同期します。

Uber GitFarm は、Git 操作そのものを遠隔で実行する方向です。論文 GitFarm: Git as a Service for Large-Scale Monorepos（2026-04-13 投稿）は、gRPC ベースの基盤が、事前に温めたリポジトリを持つ使い捨てのサンドボックスで Git 操作を走らせる構成を示しています。著者らは、すぐ使えるチェックアウトを 1 秒未満で用意でき、以前は最大 15 分あったクライアントのコールドスタートをなくせたと述べています。

この方向の共通点は、利用者の手元のコマンドを変えないことです。代わりに、自前でサーバーを運用していて、規模の壁に当たっている組織だけが恩恵を受けられます。

2. Git をやめて社内基盤を作る（Piper・Scion）

Git の前提そのものが合わなくなった組織は、置き換え先を自作しています。

Google Piper は、2016 年の CACM 記事（Potvin と Levenberg）が報告した当時の数値で、約 10 億ファイル、約 20 億行（約 900 万のソースファイル）、約 3,500 万コミット、86TB のデータを単一のリポジトリで扱っていました。開発者は多くの場合、クラウド上のストレージと Linux 専用の FUSE ファイルシステムからなる CitC（Clients in the Cloud）経由で Piper を使い、変更したファイルだけを手元に持ちます。

Anthropic Scion は、Anthropic が 2026-10-13 に公開した Redesigning source control at Anthropic で説明されています。同記事によると、モノレポの履歴は約 100GB、CI のチェックアウトは 1 日に約 2,500 万回で、Git ミラーを数百台で動かす必要が出ていました。モノレポへのマージは 2026 年 5 月の 1 日約 2,500 件から 9 月には 1 日 30,000 件超になっています。設計原則は、クライアントは常にオンラインと仮定する、履歴・blame・マージ・リベースはサーバーが担う、リポジトリの再パックのような保守を不要にする、ワーキングコピーは任意で疎または仮想、という内容です。移行は 7 人のチームが約 5 か月で完了したとされています。

注意点は、Anthropic 自身が Scion を汎用の Git 代替ではないと明言していることです。記事は、巨大なモノレポか、エージェントが大量にコードを書く環境でしか意味を持たない考え方だと書いています。Scion の設計の読み解きは別の記事にまとめています。

Pando と並べると対照が見えます。Pando は Git クライアントとの互換を保ったままサーバーを入れ替え、Scion は Git の「どこにも完全な複製がある」という前提を捨てています。同じ「エージェントによる負荷」に対して、互換を残す答えと捨てる答えが同時期に出た形です。

3. 手元のクライアントを作り替える（Jujutsu・Sapling）

サーバーは普通の Git のまま、手元の操作体系だけを変える方向です。

Jujutsu（jj） は、リポジトリの READMEで「Git-compatible VCS」を名乗り、Git リポジトリを既定のストレージにしています。作者の Martin von Zweigbergk 氏が 2019 年に趣味で始め、のちに Google でのフルタイムの仕事になりましたが、README は Google の公式サポート対象の製品ではないと明記しています。特徴は、ワーキングコピーが実際のコミットとして扱われること、あらゆる操作が操作ログに残ること、競合がコミットの中に保存されることです。

jj 0.45.1 を cargo install で入れ、既存の Git リポジトリに同居させて確かめました。以下の出力は要点を抜粋し、複数のコマンドを 1 つのブロックにまとめて表記しています。最新の 0.46.0（crates.io で 2026-10-07 更新）は rustc 1.97.1 以上を要求し、この環境の 1.97.0 では入れられなかったため、一つ前の版を使っています。

同居と作業コピー。 jj git init --colocate で既存の Git リポジトリに重ねられます。ファイルを編集するだけで、git add なしに作業コピーのコミットが更新されます。

$ jj git init --colocate
Done importing changes from the underlying Git repo.
@  pysvxwpt (empty) (no description set)
○  wmxllzkq main  git: first commit

$ echo "line2" >> a.txt ; jj status
Working copy changes:
M a.txt
Working copy  (@) : pysvxwpt db332e73 (no description set)
Parent commit (@-): wmxllzkq 8c55e90b main | git: first commit

$ git status --short
 M a.txt
$ git log --oneline --all
8c55e90 git: first commit
553d631
86027e0
db332e7

Git 側から見ると、説明が空のコミットが 3 つ混ざります。jj が作業コピーの状態を記録したコミットで、git log --all を使うスクリプトを併用する場合は、この混入を想定しておく必要があります。

操作ログと undo。 ファイルを oops に書き換えたあと jj undo を実行すると、ファイルの中身が編集前に戻りました。jj op log には、作業コピーのスナップショット・コミット作成・説明の変更が操作として並び、undo も新しい操作として追記されます。ログの書き換えではなく追記です。

$ cat a.txt ; echo oops > a.txt ; cat a.txt
hello
line2
oops
$ jj undo
Added 0 files, modified 1 files, removed 0 files
$ cat a.txt
hello
line2

競合を持ったまま先へ進む。 同じ設定ファイルの行を別々に書き換えた 2 つのコミット（agent A は x=2、agent B は x=3）を作り、B を A の上へ jj rebase しました。処理は止まらず、B のコミットに (conflict) が付いただけです。ファイルには競合マーカーが入っています。複数のエージェントが同じ場所を触ったときに、片方の作業を止めずに競合の解決を後回しにできることが分かります。

$ jj rebase -r <B> -d <A>
@  qynmkomy (conflict)  agent B
○  rynrnkpy             agent A
○  yspvpqvz main        base

$ jj file show -r <B> cfg
<<<<<<< conflict 1 of 1
%%%%%%% diff from: yspvpqvz "base" (parents of rebased revision)
\\\\\\\        to: rynrnkpy "agent A" (rebase destination)
-x=1
+x=2
+++++++ qynmkomy "agent B" (rebased revision)
x=3
>>>>>>> conflict 1 of 1 ends

Git リモートへの push。 jj bookmark set main -r @- でブックマークを進めて jj git push すると、bare リポジトリ側の git log には jj で作ったコミットが並び、新しく git clone した先で git fsck を実行しても指摘は出ませんでした。ただし最初の実行では、jj のユーザー設定を入れていなかったために Won't push commit … since it has no author and/or committer set で push が拒否されました。このとき GIT_AUTHOR_NAME などの環境変数は設定済みでしたが、jj が作る新しいコミットの作者は空のままでした。コンテナや CI で使うときは、jj の設定ファイルに user.name と user.email を入れておく必要があります。jj workspace add も実行でき、git worktree に近い役割を持つことを確認しました。

Sapling は Meta で作られたバージョン管理で、Meta の発表ではクライアントだけが OSS として公開され、サーバーと仮想ファイルシステムは「将来的に公開したい」という位置づけでした。公式ドキュメントは、sl clone --git で Git リポジトリを扱え、GitHub とも使える一方、スケール面の機能はサーバーと仮想ファイルシステムに依存し、それらは公開されていないと説明しています。この記事では Sapling を実行していません。

4. 別の思想で作られたバージョン管理（Pijul・Fossil）

Git とデータモデルが違うため、Git のリポジトリをそのまま扱う前提では使えません。

Pijul は、公式マニュアルで「変更（パッチ）の数学的な理論に基づく最初の分散バージョン管理」を名乗っています。Git がスナップショットを記録するのに対し、Pijul は変更そのものを記録します。2 つの変更は順序を入れ替えて適用でき、後続の変更の識別子を変えずに過去の変更を取り消せます。競合も、Git のように作業ディレクトリへマーカーを書き込んでコミットを止めるのではなく、両方の側を適用したうえで競合の位置を計算します。Pijul は crates.io 上で 1.0.0-beta.26 が 2026-10-30 に更新されています。ビルドを試みましたが、この環境では依存ライブラリ（libsodium）のビルドに失敗したため、動作は確かめていません。

Fossil は、公式の比較文書によると、単一の自己完結した実行ファイルで、リポジトリを 1 つの SQLite データベースに持ち、wiki・チケット・フォーラムを同梱します。各コミットを親リポジトリへ自動同期する設定が既定です。SQLite の開発スタイル、つまり少人数で密に協力するチーム向けに設計されており、巨大で分散したコミュニティを想定した Git とは出発点が違うと説明しています。この記事では Fossil も実行していません。

この記事で読んだ公式の資料は、どちらもエージェントの負荷対策を目的としていません。Git の前提を疑う方向としての参照先です。

5. Git 本体が取り込んでいく（Scalar・partial clone・bundle URI・reftable）

大規模リポジトリ向けの工夫が Git に移ってきている、という流れです。

Microsoft は Windows のリポジトリを Git で扱うために GVFS（現在の VFS for Git）という仮想ファイルシステムを作りました。後継の Scalar は仮想化をやめ、sparse-checkout・fsmonitor・バックグラウンドの保守に寄せた方式で、記事は Windows リポジトリのインデックスが 300 万エントリ超、オブジェクトが圧縮後 100GB 超（約 9,000 万個）と報告しています。VFS for Git の README は、新規には Scalar を検討するよう勧めています。Scalar は Git 2.38 から Git 本体に同梱されています。

手元の Git 2.43.0 で、サーバー側の機能がどこまで再現できるかを確かめました。4 つのディレクトリ（svc-a〜svc-c と docs）に約 40KB のファイルを 5 つずつ置き、30 回コミットしたリポジトリ（pack 内 300 オブジェクト、3.56 MiB）を、ローカルの bare リポジトリから file:// で clone しています。

操作	`.git` のサイズ	pack 内のオブジェクト数
通常の clone	3.8M	300
`--filter=blob:none --no-checkout`（partial clone）	208K	180
さらに `sparse-checkout set svc-a` して checkout	380K	185

blob を取らずに clone すると、オブジェクト数は 300 から 180 に減ります。svc-a だけを checkout すると、その 5 ファイルぶんの 5 個が追加で取得されました。サーバー側では uploadpack.allowFilter を有効にしています。数字は数 MB の実験用リポジトリのもので、巨大モノレポの値に外挿はできません。

scalar clone file://…/up.git sc も動きました。作業ツリーは sc/src に作られ、設定を見ると次の値が入っていました。

core.sparseCheckout=true
core.sparseCheckoutCone=true
remote.origin.partialclonefilter=blob:none
gc.auto=0
fetch.unpackLimit=1
index.version=4
core.untrackedCache=true

core.fsmonitor は設定されていませんでした。バックグラウンド保守も、この実行環境に systemd タイマーも crontab もなかったため warning: could not turn on maintenance で有効になっていません。Scalar のドキュメントは保守の有効化を scalar clone の挙動として説明しているので、一般の開発機とは結果が違う可能性があります。

bundle URI は、Git のドキュメントによると、接続の悪い利用者の clone を速めることと、CI のビルドファームが Git データの大半を手元の資源から取れるようにして origin への負荷を下げることを狙っています。packfile-uri が「サーバーが pack の中身を正確に知っている必要がある」のに対し、bundle の提供元は Git サーバーと無関係でよいという違いがあります。git bundle create で作った bundle を git clone --bundle-uri=file://…/up.bundle に渡すと clone が成功し、refs/bundles/trunk が作られていました。bundle が実際に使われた証拠です。速度差は小さすぎるため測っていません。

reftable は ref の新しい保存形式です。Git 2.45 の解説は、大量の loose ref がディレクトリ検索を遅くすることと、単一の packed_refs を更新のたびに書き直すコストを動機に挙げ、「ref の数ではなく更新の大きさに比例する原子的な更新」を目指すとしています。手元の 2.43.0 で git init --ref-format=reftable を実行すると error: unknown option 'ref-format=reftable' で失敗しました。2.45 より前の Git では使えません。

Git 3.0 では、SHA-256 と reftable が新規リポジトリの既定になり、ビルドに Rust が必須になる計画です（BreakingChanges）。リリース日は未定と書かれています。

6. エージェント向けに上へ載せる（Entire・GitButler・Lit）

Git を置き換えるのではなく、エージェントの作業を扱うための層を重ねる方向です。

Entire CLI は READMEによると MIT ライセンスで、AI エージェントのセッションを記録し、コミットと紐づけて索引します。チェックポイントは専用の Git ref として保存され、コードと一緒に push されます。Claude Code・Codex・Cursor など複数のエージェントに対応しています。使い方は別の記事で実機の手順を書いています。

GitButler は、公式ドキュメントによると、複数のエージェントを git worktree なしで 1 つのワークスペースで動かし、各エージェントのコミットをそれぞれのブランチへ振り分けます。同じページが「並列の GitButler ブランチはランタイムの隔離ではない」と書いており、ファイルシステム・依存関係・アプリの状態は共有されます。互換のない状態の checkout が要る場合や、同じ課題への別々の挑戦には worktree のほうが向くとも書かれています。worktree の使い方はこちらとこちらで扱いました。

Lit は、READMEで「AI エージェントを第一に、人間を第二に設計した Git の完全な代替」を名乗る Rust 製の VCS です。全コマンドが既定で構造化 JSON を出し、エラーは型つきのコードと対処のヒントを返し、競合は構造化オブジェクトで表現されます。Git との双方向の import / export も用意されています。これらはすべて README の自己申告で、Git との互換性を検証した結果や第三者の評価は見つかりませんでした。

共通していたパターン

6 つの方向を並べて見えたことを 3 点書きます。

1. 互換を残す案と捨てる案は、規模で分かれる。 Pando・Spokes・Scalar・Jujutsu・Sapling のクライアントは、Git のデータやプロトコルとの互換を保っています。互換を捨てているのは、10 億ファイル規模の Piper や、1 日のマージが 3 万件を超える Scion のように、Git の前提が構造的に合わなくなった組織です。Pijul と Fossil は規模ではなく思想の違いで別系統になっています。

2. 「必要な分だけ取る」が共通の方向。 Piper の CitC は変更したファイルだけを手元に置き、Scion はワーキングコピーを疎または仮想にし、VFS for Git は仮想ファイルシステムで、Scalar は sparse-checkout と partial clone で同じことをします。手元の実験では、partial clone で .git が 3.8M から 208K になり、svc-a だけを checkout しても 380K でした。自前の運用で最初に試せるのはこの Git 本体の機能で、上の 2 つの社内基盤に近い発想を、追加のインフラなしで取り入れられます。

3. 報告された数値は、測っているものが違う。

取り組み	報告された数値	何の数値か
Pando	push latency が約 80% 減	OpenAI の投稿。測り方は不明
Scion	マージが 1 日約 2,500 件から 30,000 件超	負荷の増加であり、Scion の効果ではない
GitFarm	チェックアウトが 1 秒未満	著者による自社環境の報告
Piper	86TB・約 20 億行	2016 年記事の当時の規模

どれも各社の規模と測定条件でしか意味を持たず、横に並べて優劣は決められません。

自分のリポジトリでどこから試すか

clone や fetch が重い場合: --filter=blob:none と sparse-checkout の組み合わせか、scalar clone が出発点です。CI は bundle URI で origin への負荷を減らせます
複数エージェントが同じブランチで衝突する場合: 作業ブランチを分けるのが基本で、Pando 周辺の push 競合の仕組みは同じブログの別記事で手元の Git で再現しています（Qiita 公開待ち）
履歴の操作が怖い場合: jj は git clone の結果にそのまま jj git init --colocate で重ねられ、操作ログと undo があります。ただし git log --all に作業コピーのコミットが混ざる点は確認してから入れてください
自前のサーバーが詰まっている場合: 公開されている設計は Spokes の 3 レプリカ方式と GitFarm の論文、Scion の原則です。Pando は非公開で、設計は報道ベースなので、公式本文が読めるようになった時点で見直す前提で扱ってください

おわりに

Pando と Scion は、同じ負荷に対する互換を残す答えと捨てる答えでした。多くの開発者の手元で効くのは、Git 本体にすでにある partial clone・sparse-checkout・Scalar と、Git 互換のまま使える Jujutsu のような道具です。

Pando の設計は、公式記事を読めた時点で確かめ直せます。この記事の Pando に関する記述は、読み直したうえで更新する前提で書いています。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up