AIエージェント向けのgit代替：Anthropicが作ったもの

2026年5月、Anthropicのメインブランチには1日あたり約2,500件の変更がマージされていました。9月には3万件を超えています。Anthropicはほぼどの企業よりもClaudeでソフトウェアを書いており、開発の最大のボトルネックになったのはgitでした。今日、同社のソース管理チームがgitを自社システムScionに置き換えた経緯を公開しました。実質的には、人間よりもまずAIエージェントのために設計されたgit代替です。

この記事では、gitが追いつかなくなった理由、新しい仕組み、諦めたもの、そしてエージェントが数千ではなく2〜3体の普通のプロジェクトで使えることを短くまとめます。私は複数のリポジトリを持ち、どれでもコーディングエージェントが動いています。Scionは要りません。ただ、そのアイデアの一部はもう必要です。

なぜAnthropicはgit代替を必要としたか#

記事にある規模です。メインブランチの履歴だけで約100GB、圧縮した作業コピーは25GB超。CIだけで1日あたり2,500万回規模のチェックアウトがあります。素朴に取得すれば、gitの転送量は1日600PBを超える計算です。

大規模プロジェクトでgitを回す定番の手は一通り試したそうです。shallow clone、sparse clone、partial clone、blobストレージに用意したシード。ピーク時には数百台の社内gitミラーを運用していました。マージが増えるほどミラーの運用は重くなり、シードはmainの先端からどんどん遅れていきました。

核心となる観察はこうです。gitは全員が履歴の完全なコピーを持ち、オフラインで分散して働くために作られた。一方、彼らのクライアントは常時オンラインのエージェントとCIジョブだった。gitは事実上、中央集権型として使われており、分散型の設計がむしろ邪魔になっていました。

Scionの仕組み#

Scionはクライアントが常にオンラインであることを前提にしています。他の設計はすべてそこから来ています。

• 重い処理はサーバー側。 履歴、blame、コミット、マージ、リベースはサーバーで計算します。クライアントは上限付きのオブジェクトキャッシュを持ち、ファイルを配置し、ファイルシステムを監視するだけです。
• コミットの代わりにchangeset。 作業の単位は先行書き込みログ（write-ahead log）の1エントリです。ツリー全体を指すのではなく、第一親からの変更ファイルを列挙します。サーバー上で作られるので、pushするものはありません。
• ブランチの移動は1回のアトミック操作。 refの更新はSpannerの1行に対するcompare-and-swapで、changesetの作成とは別に行われます。グローバルな状態はスケールしにくいため、mainとリリースブランチ以外のrefは避けています。
• クライアントは足りないものだけを求める。 gitではクライアントが「すでに持っているもの」をサーバーに伝えます。Scionではルートツリーから辿り、足りないツリーとblobだけを要求します。オブジェクトは不変なので、どのキャッシュからでも返せます。
• 3層の配信。 各マシンのscion-daemon、リージョン単位でメモリ上のscion-cache、そしてSpannerとクラウドストレージ上のscion-server。プロトコルは共通ですが層は分離されており、リージョンのキャッシュが落ちてもサーバーに要求が殺到しません。
• 作業コピーは任意。 多くのCIジョブはチェックアウトせずAPIだけを使います。コピーが要るときも部分的か仮想的で、ファイルは読まれた時点で初めてディスクに現れます。

アイデア自体は新しくなく、著者たちもそう書いています。巨大モノレポにはGoogleのPiperやMetaのSaplingという先例があります。バージョン管理システムを比較するなら、違いは負荷にあります。クライアントがエージェントで、その数は人間より桁違いに多いのです。

数字で見る結果#

7人が5か月で、Scion、コードレビューツールAntique、コード検索、権限システム、関連サービスをいくつか作りました。移行はマージ量が10倍に増える中で行われています。開発にはClaudeを使いました。git→Scionの取り込みパイプラインはチームが手書きでプロトタイプを作り、初期のClaude Mythos Previewがそれを書き直して、メモリ使用量は20分の1、速度は4倍になりました。

諦めたもの#

記事の中で私にとって一番役に立った部分です。

gitの代わりにはならない#

著者たちは、Scionは汎用のgitとしては使えないとはっきり書いています。導入にはコードレビュー、検索、CIの置き換えが必要でした。社内ツールが独自すぎるため、外部に提供する予定もありません。

履歴はメインラインのみ#

changesetは第一親からの差分を保存します。blameとパス履歴はmain向けに最適化されています。これはトランクベース開発でのみ成り立ちます。

マージキューのグローバルロックなし#

この速度では、業界標準であるマージキューのグローバルロックを再現できませんでした。代わりにマージ後とデプロイ前にテストします。並行する変更がぶつかることもありますが、たいていは人が気づくより早くClaudeが衝突を直します。私にとってはこれが一番の示唆です。マージキューは人間のペースに合わせて作られたもので、エージェントの時代にはスケールさせるより別の仕組みに置き換えた方が楽かもしれません。

エンジニアの仕事：Claudeに「ノー」と言う#

著者たちによれば、アーキテクチャとトレードオフを決めるのは今も人間です。最も多かった仕事は、エージェントに「ノー」と言うことでした。記事の例では、レビューツールに聞けばいいのにコミット履歴を総当たりで探るエージェントや、敵対的なレビューの後で防御的なチェックを過剰に足すエージェントが挙がっています。

レビュアーは一行ずつではなく、変更の意図を見ます。本番の監視はコンポーネントごとに1体ずつ置かれた別のClaudeが担い、「スーパーファン」と呼ばれています。テレメトリとログを読み、静的なアラートが見逃すものを拾います。

取り入れたいこと：Scionなしでモノレポのgitとエージェント#

私の規模はまったく違います。いくつかのサイトとアプリに、エージェントがそれぞれ1〜2体。それでも、Scionの3つのアイデアは普通のgitで使えます。

1. 要らないものはcloneしない。 partial cloneとsparse checkoutは以前からgitにあり、エージェントが履歴全体を必要とすることはまれです。

git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/ios packages/shared

大きなリポジトリにはscalar cloneがあります。git 2.38から同梱されており、これらの設定とバックグラウンドのメンテナンスを一度に有効にします。

2. エージェントごとに作業ツリーを分ける。 今日、あるエージェントがmeteohealth.proに修正を出しました。私の作業ブランチには未pushのコミットがありましたが、エージェントはそれに触れず、origin/mainから別のworktreeを作りました。

git worktree add -b fix-key ../site-main origin/main
git -C ../site-main push origin fix-key:main
git worktree remove ../site-main

Scionの「安くて任意の作業コピー」のローカル版です。

3. チェックは自動で、マージの前に。 私にグローバルロックはなく、その役割はpre-pushフックが果たしています。meteohealth.proでは型チェック、翻訳チェック、言語と画面幅の108通りの組み合わせでのヘッダーのレイアウト確認を走らせます。エージェントが頼み込んでも通りません。人間に残るのは、Anthropicと同じく変更の意図を判断することです。

真似しないもの：ブランチをやめることと、第一親だけの履歴。1日3万件のマージなら妥当な代償ですが、週30件では何も得られません。

記事に書かれていないこと#

• ソースコードも、クライアントscnのAPIの説明もありません。記事から同じシステムを作ることはできず、著者たちもそれを想定していません。
• 同じ負荷での他の方式との比較。「200分の1」「数分ではなく数秒」は自社のgitミラー構成との比較で、PiperやSaplingとは比べていません。
• 他の人がいつこれを必要とするか。著者たちはこの種の問題が6〜12か月で一般的になると見ており、GitHub、GitLab、オープンソースコミュニティとアイデアを共有したいとしています。どんなサーバー側RPCやsparse・shallowのモードを提案するのかは、まだわかりません。

gitのモノレポで、エージェントの数が人間を上回りつつあるなら、ミラーの段階に達する前に上の3点を確認してください。エージェントにプロジェクトの共有メモリを持たせる方法はMCPでつなぐコーディングエージェント向けwikiの記事で、複数のエージェントが衝突せずに作業を分ける方法は共有wikiでのエージェントの作業予約の記事で解説しています。