Anthropic、gitをScionに置き換え 1日のマージ数は3万件超に

Anthropicは、メインのコードリポジトリをgitから、自社で開発したバージョン管理システムScionに移しました。同社によると、2026年5月には1日あたり約2,500件のコード変更をマージしていました。9月には、それが1日3万件を超えました。The Registerは、この急増を、Claudeが同社のコードをより多く書くようになったことと結びつけています。gitは、すべてのコピーが完全な履歴を持つという考え方に基づいています。ほぼすべての利用者が常時オンラインのAIエージェントになると、この考え方は意味をなさなくなりました。Anthropicは10月13日にこのシステムについて説明しましたが、公開はしません。

gitが機能しなくなった理由

「今のボトルネックは、人間の規模に合わせて作られた開発者インフラのすべてです」と、Anthropicはエンジニアリング記事に書いています。コードを書くことは、もはや遅い部分ではありません。遅いのは、ソース管理、ビルド、そして継続的インテグレーション（CI）です。CIとは、変更のたびに実行される自動テストのことです。

このリポジトリはモノレポです。モノレポとは、会社のコードの大半を1つにまとめたリポジトリのことです。その規模を見ると、負荷の大きさがわかります。

項目	数値
メインブランチの履歴	100GB近く
圧縮した作業コピー	25GB超
CIだけで発生する1日あたりのチェックアウト	約2,500万回
各チェックアウトが通常のクローンだった場合のgitの通信量	1日600PB超
ピーク時の社内gitミラー	数百

Anthropicは、一般的な対策を試しました。シャロークローンとスパースクローンを使いました。どちらも、リポジトリの一部だけをダウンロードする方法です。さらに、社内ミラーと事前に構築したコピーも使いました。マージが増えるにつれて、どの対策も運用が難しくなりました。事前に構築したコピーは、メインブランチからずれていきました。部分的なクローンでは、diffやblameといったツールが動かなくなりました。

Scionの仕組み

Scionは、クライアントが常にオンラインであることを前提にしています。履歴、blame、コミット、マージ、リベースは、サーバーが処理します。各マシンが持つのは、限られたローカルキャッシュと作業コピーだけです。作業コピーとは、実際に編集しているファイルのことです。

すべての変更は、チェンジセットとしてログ先行書き込み（write-ahead log）に保存されます。これは、変更を順に記録し続けるログです。チェンジセットは変更されたファイルを列挙し、blobストレージにあるその中身を指し示します。ファイルは必要になったときに取得されます。そのため、チェックアウトで最初に数GBのバンドルをダウンロードすることはありません。

Scionは3つの層で動きます。各マシン上のデーモン、各リージョンのキャッシュ、そして正本となるサーバーです。Anthropicによると、キャッシュの各層がリクエストの99%超に応答しています。mainブランチとリリースブランチ以外のブランチは、使わないよう推奨されています。

Scionは、そのままgitと差し替えられるものではありません。ScionのエンジニアであるNick G.氏は、Hacker Newsでこのトレードオフを説明しました。Simon Willison氏が、その発言を引用しています。「ClaudeはScionの圧倒的に最大の利用者で、必然的にオンラインなので、これはやる必要がなかった」と同氏は書いています。Willison氏は、この結果をSubversionのような古い集中型のシステムになぞらえています。

Anthropicが得たとする成果

Anthropicは、Scion上でネイティブに動くリポジトリについて、次の成果を報告しています。

• 以前のgitミラーと比べて、CPUとメモリの使用量が約200分の1になりました。
• CIと研究用のチェックアウトが約100倍速くなり、数分かかっていたものが数秒で済むようになりました。
• CIシステムが使うCPUが25%減りました。

Scionと、Antiqueというコードレビューツール、そして関連する6つほどのシステムを作ったのは7人です。移行には5か月かかりました。The Registerによると、Scionの開発は2026年1月に始まりました。

ほかのツールには、コード検索、ディレクトリ単位のアクセス権限、そして全体で1つのマージキューを使わずに変更を取り込む仕組みがあります。チームは、これらをClaudeの助けを借りて作りました。Anthropicによると、gitからScionへの初期のインポートパイプラインをClaudeが書き直したところ、メモリ使用量は20分の1になり、速度は4倍になりました。

それでも、作業の舵取りをしたのは人間です。「エンジニアの役割は、Claudeに『ノー』と言うことだと気づく場面が非常に多かった」と、Anthropicは述べています。The Registerが引用した発言です。

Scionはほかでも使えるようになるのか

いいえ。Anthropicによると、Scionを広く役立つ形で提供するのは難しく、一般的な用途には向いていません。同社は代わりに設計を共有しています。そして、GitHub、GitLab、オープンソースコミュニティと協力したいとしています。

記事では、gitの仕組みを変えずにgitのホスティングサービスが取り入れられるアイデアを提案しています。サーバー側でより多くの処理を行うことや、スパースクローンとシャロークローンを組み合わせやすくすることなどです。git自体も変わりつつあります。Git 3.0のSHA-256既定をめぐる議論については、今月初めにお伝えしました。

開発者にとっての意味

• ほとんどのチームにとって、gitは今も問題ありません。 The Registerは、ほとんどのリポジトリにとってgitが今も正しい選択だと指摘しています。Scionが解決するのは、1日に数万件のマージが発生する規模で現れる問題です。
• エージェントの規模拡大に合わせて、CIのチェックアウトのコストに注意すること。 ここでgitを限界に追い込んだのは、1日約2,500万回のチェックアウトでした。エージェントがタスクごとにリポジトリをクローンしているなら、今のうちにその通信量を測ってください。
• エージェントは常時オンラインのクライアントとして扱うこと。 オフラインのコピーが重要なのは人間であり、クラウドで動くエージェントではありません。必要なときにファイルを取得するツールなら、エージェントの実行1回あたりのコストを下げられます。
• gitのホスティングサービスがこれらのアイデアを取り入れると見込むこと。 Anthropicは、GitHubとGitLabに設計の一部を採用してほしいと考えています。最初の一歩になりそうなのは、サーバー側での操作と、部分的なクローンの改善です。
• レビューには人間を残すこと。 Anthropicのエンジニアは、Claudeの提案を却下することに多くの時間を費やしました。エージェントがコードの大半を書くようになるなら、そのレビューの負担を見込んで計画してください。