Claudeがコードを書く量が急増し、gitがその勢いについていけなくなった。Anthropicは5カ月かけて自社製のソース管理システム「Scion」を作り、社内の巨大リポジトリをgitから完全に移した。1日のマージ数は2500件から3万件超へ膨らんでいる。
AnthropicはなぜScionを作ったのか？
AI企業Anthropicは10月13日、エンジニアリングブログでソース管理基盤の再設計を公表した。発端は、同社のAI「Claude」が書くコードの量が爆発的に増えたことにある。2026年5月時点で1日あたり約2500件だったコードのマージは、9月には3万件を超えた。4カ月で12倍になる勢いだ。
同社が使っていたgitは、もともとオフラインで動く分散型の設計を前提にしている。各クローンが完全なリポジトリを持ち、履歴や差分を自分で計算できる仕組みだ。ほとんどの用途では正しい設計で、gitが標準になった理由でもある。
ところがAnthropicの巨大リポジトリ（モノレポ）は、その設計の枠に収まらなくなった。メインブランチの履歴だけで100ギガバイト近く、圧縮した作業コピーは25ギガバイトを超える。CIのために1日およそ2500万回のチェックアウトが走り、開発環境やエージェントのサンドボックス、研究ジョブを数えると、素直に取得すれば1日600ペタバイトを超える通信になる計算だ。
同社は内部ミラーやスナップショットの複製でしのいできた。ピーク時には数百個の内部gitミラーを動かしていたという。それでもマージ量が増えるほど運用は難しくなり、履歴に依存する差分やblame（各行を最後に変更したコミットを追う機能）を部分クローンで保つには手間がかかるようになった。
Scionとgitの設計は何が違うか
Anthropicは、自社のクライアントはほぼすべてエージェントとジョブであり、常にオンラインで動く点に着目した。gitの強みであるオフライン前提の性質が、リポジトリの成長に伴って足を引っ張っていたわけだ。
そこでScionはいくつかの原則をgitと変えている。第一に、クライアントは常にオンラインとみなす。必要なデータはその都度サーバーから取り、完全なコピーは持たない。第二に、クライアントとサーバーに非対称な役割を持たせる。gitではどのクライアントも完全なサーバーになれるが、Scionでは履歴やblameの照会、コミットの作成、マージやリベースはサーバーが担う。クライアントは限られたデータのキャッシュを持ち、作業コピーをディスクに展開して変更を監視する役割に絞る。
大規模モノレポ向けの先行例はある。GoogleのPiperやMetaのSaplingがそうで、Anthropicはその知見を踏まえてScionを設計したと説明している。
Scionが解いた課題と生んだもの
Scionの本体に加え、同社は5カ月の間に周辺の道具も作り込んだ。コードレビューの画面「Antique」、コード検索、きめ細かな権限管理（IAM）の仕組み、レビュー済みコードを大量に着地させる独自の方法などだ。
注意したいのは、Scionはあくまで社内ツールだという点だ。Anthropicは一般提供を発表しておらず、他社がそのまま導入できる形で配るのは難しいとしている。Claudeをエージェントとして使う組織が、いつか同じ圧力に直面するときの参考事例として公開した位置づけに近い。
gitが前提としていること
- クライアントはオフラインで動く
- 各クローンが完全なリポジトリを持つ
- どのクライアントもサーバーになれる
Scionが前提とすること
- クライアントは常にオンライン
- クライアントは完全なコピーを持たない
- 履歴やマージはサーバーが担う
Scionが開発者とAI業界に示すもの
この事例が読み取らせるのは、AIがコードを書く時代に、ソフトウェア開発の土台そのものが作り替えを迫られるという現実だ。コードを書くことがボトルネックでなくなると、次に詰まるのはgit、ビルド、CIといった人間の規模を前提に組まれた開発インフラになる。Anthropicは、この詰まりを真っ先に体験する立場にある。
gitやその系譜のツールを使って開発する一般のチームにとって、Scionを今すぐ導入する話ではない。だが、AIエージェントにコードを書かせる運用が広がれば、同じ圧力は時間差で他の組織にも及ぶ。同社は、人間の規模を前提とした道具がどこから壊れるのか、何に置き換えたのかという記録として、この設計を公開した。
注目点は二つある。Scionが扱う規模の数字が今後どこまで伸びるか、そして同じ課題に直面した他の組織が、自前で作るか既存ツールを拡張するか、どちらを選ぶかだ。ブログは一般提供の予定に触れておらず、Scionが汎用のgit代替製品になるかは未定のままだ。
