10月15日、テクノロジー系独立メディアのpbxscience.comが「Anthropic Replaces Git With In-House Scion as AI Coding Pushes Merge Volume Past 30,000 a Day」と題した記事を公開した。AnthropicがAIコーディングによるマージ件数の急増に対応するため、Gitを自社製バージョン管理システム「Scion」に移行したこと、およびその技術的背景について詳しく紹介されている。
1日3万件超のマージ——Gitが限界を迎えた瞬間
2026年5月、Anthropicの内部リポジトリに対するマージ件数は1日あたり約2,500件だった。それが同年9月には1日3万件超へと跳ね上がった。約4ヶ月で10倍以上の増加である。その主な原動力はClaudeによる自動コーディングだ。
Anthropicは「コードをマージしたいという潜在需要は事実上無限」と述べており、この成長が鈍化するとは見ていない。
規模感を示す数字を並べると、その凄まじさがより伝わる。
| 指標 | 数値 |
|---|---|
| マージ件数(2026年5月) | 約2,500件/日 |
| マージ件数(2026年9月) | 3万件超/日 |
| メインブランチの履歴サイズ | 約100GB |
| 圧縮済みワーキングコピー | 25GB超 |
| CI用コードチェックアウト数 | 約2,500万回/日 |
| 単純フェッチ時の推定Git通信量 | 600PB超/日 |
| ピーク時の内部Gitミラー数 | 数百台 |
シャロークローン(--depthオプションで履歴を省略する手法)やスパースクローン(必要なファイルのみを取得する手法)、内部ミラーといった標準的な回避策はすでに試みていたが、マージ速度の上昇とともに運用が困難になったとAnthropicは説明している。
ScionはGitの設計前提を根本から覆す
Gitはもともと分散型として設計されており、各クライアントがリポジトリの完全なコピーを持つ。オフライン作業を前提とした設計だ。しかしAnthropicのクライアントはほぼすべてがAIエージェントや自動化ジョブであり、常時オンラインで動作する。完全なリポジトリコピーを各クライアントが持つことは、コストを生むだけで価値を生まない。
こうした「巨大モノレポ×大量並列処理」という課題は、Anthropicに限った話ではない。Googleは同様の理由から社内専用の集中型バージョン管理システム「Piper」を独自開発しており、全コードを単一リポジトリで管理するアーキテクチャを採用している。ゲーム・メディア業界ではPerforce Helix Coreのような集中型VCSが大規模バイナリ管理の現場で長く使われてきた。Scionはこうした先行事例と同じ文脈に位置づけられるが、AIエージェントによる超高頻度マージという新たな負荷要件に特化している点が異なる。
Scionはこの前提を逆転させた。
- クライアントは常時オンラインであることを前提とする
- 履歴参照、blame、コミット、マージ、リベースはサーバー側で処理する
- クライアントはごく小さなローカルキャッシュを持つだけで、必要なファイルのみを取得する
- 同じクエリをAPIで提供するため、多くの自動化ジョブはローカルコピー自体が不要になる
結果として、以前のGitミラー構成と比較してCPUとメモリの使用量が約200分の1に削減された。CI・研究ジョブのコードチェックアウトは「分単位」から「秒単位」になり、CIだけでCPU容量が25%向上した。キャッシュアーキテクチャの各層ではヒット率99%超を維持しているという。
7人のチームが5ヶ月で完成させた
Scionの構築を担ったのはわずか7人のチームだ。バージョン管理システム本体に加え、コードレビューツール「Antique」、およびいくつかの関連システムを開発し、5ヶ月でフルマイグレーションを完了させた。
この開発自体にもClaudeが大きく貢献している。記事中では「Claude Mythos Preview」(Anthropicが社内研究・開発用途に用いる内部スナップショット版モデルと説明されている)が手書きのデータ取り込みパイプラインを書き直し、メモリ使用量を20分の1、実行速度を4倍に改善したバージョンを生成した一例が紹介されている。
一方でAnthropicはエンジニアの役割についても率直に述べている。「自社エンジニアはもはやClaudeのほうが自分たちよりもコードを書くのが上手いと評価している」としつつも、システムレベルの判断は人間が担うと説明する。エンジニアの仕事の多くは、AIエージェントがシステム上の制約を破ろうとしたり、過剰に複雑な解決策を提案してきたときに「ノー」と言うことだという。レビュー担当者は今もすべての変更リクエストを確認するが、コードを一行ずつ読むのではなく、変更の意図を評価することに集中するようになった。
Scionは公開しない——ただしGitコミュニティへの提言はする
AnthropicはScionを「一般用途においてGitの代替として適切なものでは決してない」と明言しており、公開もしない方針だ。Scionの設計は巨大モノレポ(すべてのプロジェクトを単一リポジトリで管理するアーキテクチャ)と大量のAIエージェントを前提としており、Anthropic社内専用のコードレビュー・コード検索・CIシステムに深く依存している。汎用VCSとして切り出して提供できる性質のものではないという判断だ。
とはいえ、Scionで得た知見をGitエコシステムにフィードバックすることには積極的な姿勢を示している。具体的には、サーバーサイドRPCの充実やスパース・シャロー機能の改善など、Gitのモデル自体を捨てずに取り込める方向性が示唆されている。GitHubやGitLab、オープンソースコミュニティに対して設計思想を共有したいとしており、この点はGitを「廃止すべき過去の遺物」と切り捨てる立場とは明確に異なる。
Anthropicは「この種の問題は今後6〜12ヶ月以内に、AIコーディングツールの普及に伴い他の組織でも一般的になる」と予測している。現時点で1日3万件ものマージには程遠い大多数のチームにとってはGitで十分だが、AIがコードを書く速度を上げるほど、それを保管・レビュー・テスト・マージするインフラへの圧力が高まる——そのシフトを象徴する事例といえる。
詳細はAnthropic Replaces Git With In-House Scion as AI Coding Pushes Merge Volume Past 30,000 a Dayを参照していただきたい。