Anthropic、自社製VCS「Scion」でマージ10倍・負荷1/200を両立

社内のコーディングエージェントが増えてから、pushのたびに待たされるようになった、というチームもあるはずだ。原因は手元のマシンの遅さではなく、無数のクライアントが同時にコードを書き換える前提に、使っているバージョン管理の仕組みがついていけていないことにある。Anthropicは2026年10月13日、自社のエンジニアリングブログでこの問題を最も極端な規模で経験した話を公開した(Anthropic公式ブログ)。答えは、gitを自社製のバージョン管理システム「Scion」へ置き換えることだった。

マージ数が10倍超に増えた

Anthropicの説明によると、同社のモノレポへのコード変更のマージ数は、2026年5月の平均で1日あたり約2,500件だった。それが9月には1日30,000件を超えた。4か月で10倍以上という増え方だ。

この増加を支えているのは人間のエンジニアだけではない。Anthropicは、社内のクライアントのほとんどが「オンラインであることが定義上当然のエージェントやジョブ」になったと説明している。四六時中動き続けるエージェントが同時多発的にコードを書き換える前提になった結果、モノレポは重くなり続けた。mainブランチの履歴だけでほぼ100GB、圧縮した作業コピーでも25GB超に膨らんだという。CIだけで1日あたり2,500万回ものチェックアウトが発生するようにもなった。数百台規模の内部ミラーを運用しても、負荷と保守の手間が限界に近づいていたという。

ここまでの数字だけでも相当な重さだが、Anthropicが実際に直面した壁は、単なるデータ量の増加ではなかった。

gitの前提そのものが重荷になった

gitがこの規模で苦しくなる理由は、容量の大きさだけではない。Anthropicは、gitでは「すべてのクライアントが完全なサーバーになれる」設計だと指摘している。手元のPCにクローンした瞬間、そのPCは履歴のすべてを持つサーバーと同じ能力を持つ。これは1人の人間が1台のPCで開発する分には合理的な設計だ。だが、常時オンラインのエージェントが何千と動き、それぞれが同じ重いリポジトリ全体を抱え込もうとすれば、話は変わってくる。

Anthropicはここで設計を反転させた。Scionでは、クライアントとサーバーの役割をあえて非対称にする。「クライアントは自分ではほとんど計算できない代わりに、手元に持つデータはずっと少なくて済む」という原則だ。履歴をたどる、誰がどの行を書いたかを調べる(blame)、新しいコミットを作る、といった重い処理はすべてサーバー側が担う。クライアントは必要なディレクトリや内容だけを、そのときどきで取得する軽量なキャッシュに徹する。

この非対称さを支えているのが、Scionにおける「変更」の最小単位だ。Anthropicの説明では、作業の単位は「changeset」と呼ばれる。

changesetの正体は、サーバー側の書き込みログ(write-ahead log)の1エントリだ。gitのコミットは「親を持つスナップショットへの参照」だが、changesetは違う。持つのは、変更されたファイルと、圧縮済みの実体データそのものではなくその置き場所を指すコンテンツアドレス参照だけだ。blameやパス履歴のような「派生データ」は、この書き込みログから親をたどって必要なときに計算し直す。サーバーが権威を持ち、クライアントはキャッシュしか持たない非対称な関係は、この1点に集約されている。

(Anthropic公式ブログの記述をもとに作成)

チェックアウトが「数分」から「数秒」へ、2桁速くなったのは、クライアントが毎回この重い全体を抱え込まなくてよくなったからだ。クライアントが軽くなった分の計算と保存は、どこかで誰かが引き受けなければならない。その引き受け先であるサーバー側のインフラは、果たしてどうなったのか。

マージ10倍でも負荷は1/200

結果は直感に反する方向に振れた。Anthropicは、Scionのインフラ全体のCPU・メモリ要件が、従来のgitミラー基盤の200分の1になったと説明している。マージ数が10倍以上に増えているのに、それを支える基盤の負荷は逆に小さくなっている。

自分はここで一度立ち止まった。開発量が増えれば、それを支えるインフラのコストも増えるものだと思い込んでいたからだ。だが実際に効いているのは台数や処理能力の勝負ではなく、設計の勝負だった。gitのミラー基盤は、台数を増やすたびに「全体を複製したクライアント」を増やしていた。対してScionは、クライアント1つあたりが持つデータそのものを減らしている。母数が増えても、1つあたりの重さが先に減っていれば、合計は小さくできる。

この移行自体も、決して大人数をかけたものではない。ScionとAntique(コードレビュー基盤)の両方を、7人のチームが5か月で作り上げ、モノレポ全体の移行を完了させた。各層のキャッシュのヒット率は99%を超え、CIだけでもCPU容量が25%改善したという。

移行作業そのものにも、Anthropicらしい回収がある。gitのデータをScionへ取り込むパイプラインは、当初は社内で手書きしたプロトタイプだった。これをClaude Mythos Previewに書き換えさせたところ、メモリ使用量が20分の1、速度は4倍になったという。自社のコードを支える基盤を作る作業そのものに、自社のAIを実務で使わせている格好だ。ここまで効果が出ている仕組みなら、他のチームにもそのまま使えるのではないか、と思えてくる。

どこまで使える仕組みなのか

ここまで読むと、Scionを自分のチームにも導入したくなるかもしれない。だが、公式ブログ自身が次の2点を認めている。

• 提供範囲: Anthropic自身が「Scionは一般用途でgitの代替になるものではない」と明言しており、他社に広く使える形で提供するのは難しいとも述べている。想定しているのは、数万人規模のエンジニアとエージェント群が同じコードベースに書き込む、超大規模モノレポという特殊な状況だ
• 未解決の課題: マージキューにおける業界標準的な「グローバルな排他ロック」を、Scionでは効果的に再現できていないという。複数の変更が同時に進んでいるとき、互いに競合する書き換えが起きうるということだ

自分には、ここまでの仕組みを必要とするチームはごく一部に見える。それでもAnthropicは、Scionそのものの配布よりも、非対称設計という発想をgitエコシステム全体へ還元していく立場を取るとしている。

まとめ

Anthropicは、社内のコーディングエージェントによってコード変更のマージ数が1日2,500件から30,000件超へと10倍以上に増えた。その中で、gitから自社製のバージョン管理システム「Scion」へ5か月で移行した。

核心にあるのは、gitの「クライアントは誰もが完全なサーバーになれる」という対称な設計を捨てたことだ。サーバーが履歴やblameの計算を一手に引き受け、クライアントは必要な分だけの軽量なキャッシュに徹する。この非対称な設計への転換により、マージ数が増える一方でインフラのCPU・メモリ要件はむしろ1/200まで減り、チェックアウトも数分から数秒へ縮まった。

Scionは社内専用で、グローバルロックのような未解決の課題も残る。それでも、常時オンラインのエージェントが大量にコードを書く時代に、バージョン管理の前提そのものを疑うとどうなるかを示す実例になっている。