エージェントに並列でコードを書かせるようになってから、リポジトリが重くなりました。
git status が一拍置いてから返ってきます。.git の大きさは、半年前の記憶より桁が増えています。worktree の一覧も、画面に収まらなくなりました。
朝にまとめて出した PR が、昼を過ぎても CI を抜けません。
書く速さだけが変わって、周りがついてきていません。
数字
2026年10月13日に、Anthropic が自社のモノレポを Git から Scion という独自の仕組みに移したことを公開しました。
きっかけは量です。
| 1日のマージ | 2,500件(2026年5月)→ 30,000件超(9月) |
| main の履歴 | 約100GB |
| 圧縮した作業コピー | 25GB超 |
| 1日の checkout | 約2,500万回 |
| 作った人数と期間 | 7人・約5か月 |
4か月で12倍です。そして checkout の2,500万回は、人が打ったものではありません。CI と、エージェントのサンドボックスと、研究用の処理が動いた数です。
何が詰まったか
Git は、作業コピーを手元に全部持つ作りです。履歴も手元に落とします。
これは1人の開発者には都合がよい設計です。ネットワークが無くても履歴を追えますし、ブランチを切るのも手元で終わります。
手元に全部持つ以上、全部が大きくなると全部が遅くなります。100GBの履歴を持つリポジトリを、1日に2,500万回 checkout するのは、設計が想定していない使い方です。
Scion がやったこと
サーバーに寄せました。履歴の問い合わせやマージはサーバーが担当して、クライアントは必要なぶんだけ取りに行きます。
必要なファイルだけを取る形にも対応しています。CI の1つの仕事が、リポジトリ全体ではなく触るファイルだけを取れます。
結果として、以前の Git を鏡像する仕組みと比べ、CPU とメモリの使用量が200分の1になったと説明されています。CI の checkout は分単位から秒単位になり、各段のキャッシュの命中率は99%を超えています。
公開されません
ここを飛ばすと話が変わってしまうので、はっきり書きます。
Scion は公開されませんし、汎用の Git の代替として作られたものでもありません。 Anthropic 自身がそう言っています。
代わりに提案されているのは、Git の本体に、サーバー側の処理とプロトコルの変更を取り込んでもらうことです。つまり「Git をやめよう」ではなく、「Git にこの形を入れてほしい」という話です。
「Git の終わり」と読むのは誤りです。1つの会社が、1つの極端な使い方で、既存の設計の端にぶつかったという話として読むのが正確です。
自分たちに関係があるか
ほとんどの場合、ありません。1日3万マージも、100GBの履歴も、普通の規模では起きません。
ただし、向きは同じです。エージェントに並列で書かせると、人が書いていたころの数倍から数十倍のコミットが出ます。倍率が上がれば、どこかが先に詰まります。
詰まる場所は規模によって変わります。Anthropic ではバージョン管理でしたが、手前の規模なら CI の待ち時間や、レビューの順番待ちや、worktree を切る手間のほうが先に来ます。
手前でできること
並列にする前と後で、何が増えるかを見ておくと早めに気づけます。
git log --since="1 week ago" --oneline | wc -l # 1週間のコミット数
du -sh .git # 履歴の大きさ
git worktree list | wc -l # 切ってある作業場所の数
倍率が上がっていく途中で、先に音を上げるのはたいてい CI です。1つのコミットに10分かかる検査が、1日100コミットになると回らなくなります。
MulmoTerminal で並列に動かすと、枠ごとに worktree が切られます。同時に走らせてもファイルを取り合わない代わりに、手元の作業場所の数と履歴の大きさは増えます。
npx mulmoterminal@latest
まとめ
Anthropic が Git から移ったのは、エージェントが書く量に既存の設計が追いつかなくなったからです。数字は極端ですが、向きは並列でエージェントを動かしているところすべてに共通します。
ただし Scion は公開されませんし、Git の代替として作られたものでもありません。読むべきは結論ではなく、どこが先に詰まったかのほうだと思います。
- Anthropic の公開記事
- MulmoTerminal —
npx mulmoterminal@latest
