Claudeによるコード生成が増えたAnthropicは、Gitを使っていたモノレポを社内開発のバージョン管理システム「Scion」へ5カ月で移行しました。2026年9月時点のマージ件数は1日3万件超で、5月の約2,500件から増加しており、同社ではコードを書く速さより、変更を管理してビルドや継続的インテグレーション（CI）へつなぐ基盤が課題になっています。
マージ増加で開発基盤がボトルネックに
Anthropicのモノレポは、メインブランチの履歴だけで約100GBあり、圧縮した作業コピーも25GBを超えます。CI向けのチェックアウトは1日あたり約2,500万回に上り、開発環境やエージェントのサンドボックス、研究用途はこの数に含まれていません。
この回数で毎回Gitのデータを単純に取得すると、通信量は1日600PBを超える計算になります。Anthropicは負荷を抑えるために数百台のGitミラーやストレージ上のスナップショットなどを使っていましたが、マージ件数の増加に伴い、運用が難しくなりました。
GitLabのGitalyでも、大規模なモノレポへのクローンやフェッチが増えると、サーバーのCPU負荷が高まる要因になります。GitLabは対策として、パックオブジェクトのキャッシュ、CIでのfetchまたはcloneなしの戦略、タグ取得の停止、浅いクローンなどを挙げています。 これらはGitの取得量や処理を抑える方法ですが、Anthropicは社内の利用形態に合わせて、クライアントがリポジトリ全体を持たない方式を選びました。
Scionはサーバー側で履歴や変更を処理
Gitは分散型で、各クライアントがリポジトリの完全なコピーを持ち、オフラインでも履歴の参照や差分計算ができます。Scionでは、常時オンラインで動くエージェントやジョブを前提に、クライアントが必要なデータをサーバーから取得し、履歴照会やマージ、リベースなどもサーバー側で処理します。
Scionの作業単位は「changeset（変更セット）」です。これは変更履歴に追記される記録で、親の変更から変わったファイルの一覧と、圧縮されたファイル内容を指すアドレスを保持します。
クライアントは作業ファイルの配置や変更の監視を担い、ローカルには上限を設けたデータキャッシュを持ちます。ソース管理への問い合わせはAPIでも利用できるため、差分を調べるなどの処理では、CIジョブがローカルにリポジトリを用意せずに済む場合があります。
必要な範囲だけ取得し、参照の調整を減らす
Scionのチェックアウトは、指定したディレクトリだけを含む「スパース」な形式を基本とし、仮想化チェックアウトではファイルを必要になった時点で配置します。CIジョブはファイルをディスクに展開せず、サーバーAPIから差分などを取得することもできます。
GitHubが解説するGitの部分クローンでは、blobless方式は履歴とディレクトリ情報を取得し、ファイル内容は必要に応じて取得します。浅いクローンはコミット履歴を指定した深さで切り詰め、取得量を減らしますが、利用できる履歴操作に制約が生じます。
Scionでは変更セットの作成と参照の更新を分け、変更セットを作る際に全サーバーで参照を調整する必要をなくしています。履歴から行単位の変更者やファイルの経路を調べる情報は、変更セットそのものとは別の派生データとして構築し、計算を先送りするか早期に行うかを選べます。
Claudeを使った開発と社内利用の範囲
AnthropicはScionに加えて、コードレビュー画面の「Antique」、コード検索、ソース管理のIAM（アクセス管理）機能も同じ期間に構築しました。Scionの初期段階では、Claude Mythos Previewを社内で利用できるようになった後、GitからScionへのデータ取り込み処理の書き直しにClaudeを使い、生成された版はメモリー使用量が20分の1、実行速度が4倍だったとAnthropicは述べています。
一方、AnthropicはScionを一般向けに適したシステムとは位置づけず、オープンソースとして公開する予定もないとしています。同社は、AIによるコーディングを使う組織でも同様の基盤負荷が広がると予測しています。
GitLabの運用例では、レプリケーションの遅れによって読み取りがプライマリノードへ偏り、負荷が集中する場合があります。モノレポのレプリケーションでは、セカンダリからプライマリへのフェッチに時間がかかることも、遅れが続く要因として挙げられています。 Scionは中央サーバーへの依存を強める設計のため、API処理を支えるサーバー群を水平に拡張できることが設計原則に含まれます。
