AnthropicがモノレポをScionへ移行 — 1日3万件のマージとCIチェックアウト最大2桁台高速化を実現したサーバーサイド設計

10月27日、Eran Stillerが「How Anthropic Redesigned Source Control for AI-Driven Development」と題した記事を公開した。この記事では、AnthropicがモノレポをGitから独自開発のソース管理システム「Scion」へ移行した経緯と技術的な設計について詳しく紹介されている。

1日3万件のマージ——AIエージェントがもたらした規模の急変

Anthropicの規模の変化は数字を見れば一目瞭然だ。2026年5月時点で1日あたり約2,500件だったマージ数が、9月には3万件超に急増した。CIシステムは1日あたり約2,500万回のチェックアウトを実行し、対象のモノレポはメインブランチの履歴だけで約100GB、圧縮後のワーキングコピーも25GB超に達している。

この急増の背景にあるのが、AIエージェントの台頭だ。コード生成・レビュー・テストを自律的にこなすエージェントが大量のプルリクエストを自動生成するようになると、人間のエンジニアだけが開発していた時代には想定していなかった頻度でマージが発生する。Gitはもともとこうした「エージェント駆動の並列開発」を想定した設計ではなく、運用の限界が急速に顕在化した。

2026年1月〜9月のAnthropicモノレポにおける1日あたりのマージ数（出典: Anthropic）

これに対応するため、Anthropicはshallow clone（浅いクローン）、sparse checkout（スパースチェックアウト）、promisor remote（必要なオブジェクトだけを遅延取得する仕組み）、リポジトリスナップショット、数百台のGitミラーなど、考えられる最適化を軒並み試みた。しかしマージレートが上がるにつれて、これらの運用コストが限界を超えた。

その結論として生まれたのが、独自ソース管理システムScionだ。

GitとScionの根本的な違い：どこで処理するか

Gitはもともとローカルファーストのシステムだ。クローン、ログ、blameといった操作はすべてローカルマシン上で完結する設計になっている。Scionはここを根本から変えた。

コミット、マージ、リベース、履歴参照、blameクエリをすべてサーバー側で処理する。 クライアントは有界なオブジェクトキャッシュを保持するだけで、ファイルはオンデマンドで実体化される仮想チェックアウト方式を採用する。ツールがdiffを照会したり、一部の書き込み操作を行う際も、コードをチェックアウトせずAPIを通じて実行できる。

データモデルも異なる。Scionのチェンジセット（変更単位）は、第一親からの変更ファイルと、Blob Storageへのコンテンツアドレスドなポインタのみを記録する。ツリー構造はサーバーが「派生データ（derived data）」として別途計算し、eagerly（先行計算）またはon-demand（要求時）で提供される。この設計により、クライアントを変更せずにサーバー側のデータ構造を進化させられる。

Scionのチェンジセット構造。ツリーはサーバーが派生データとして別途生成する（出典: Anthropic）

3層キャッシュで99%以上のキャッシュヒット率を実現

チェックアウト時、クライアントは不足している不変ツリーとBlobをサーバーへ要求する。ここで重要なのが「不変オブジェクト」という性質だ——一度書かれたBlobやツリーは変更されないため、キャッシュの無効化を考慮せずに積極的に共有できる。この特性を最大限に活かすのが、以下の3層キャッシュ構造だ。

ノードローカルデーモン — ジョブ間でオブジェクトを共有するローカルキャッシュ。同一ホスト上の複数CIジョブが共通ファイルを何度も取得する無駄を省く
リージョナルキャッシュ — ローカルデーモンのミスをカバーする地域単位のキャッシュ。データセンター内のトラフィックに閉じることでレイテンシを抑える
正規サーバー（SpannerとクラウドストレージでバックアップされたAuthoritativeサーバー）— 上位2層を抜けたリクエストの最終的な供給源

リージョナルキャッシュはデーモンのストレージフォーマットでオブジェクトをストリーミングするため、リクエストごとのデルタ圧縮が不要になる。また層間の呼び出し順序を強制することで、リージョナルキャッシュ障害が正規サーバーに波及しないよう設計されている。

結果として、各層でキャッシュヒット率99%以上を達成。旧来のGitミラー構成と比べてCPUとメモリのインフラフットプリントは200分の1に削減され、CIおよびリサーチジョブのチェックアウト速度は2桁台の高速化を実現したとAnthropicは報告している。これらはあくまで同社の内部ワークロードにおける計測値であり、Gitとの一般的なベンチマーク比較ではない点は注意が必要だ。

先行研究との関係と、Gitの代替ではないという立場

Anthropicは10月15日の追記で、MetaのMononokeとそのBonsaiデータモデルが本設計の多くの技術を先駆けたと明示的にクレジットしている。BonsaiはMeta社内のモノレポ基盤Saplingで採用されたデータモデルで、ファイルツリーを不変オブジェクトのDAG（有向非巡回グラフ）として表現し、コンテンツアドレス方式で管理する設計が特徴だ。Scionはこのアプローチを参照しつつ、Anthropicの要件に合わせて独自実装したものであり、無から生まれたわけではない。

なお、2026年8月にInfoQが取り上げたUberのGitFarmは、Git自体を置き換えずに標準的なGit操作を集中管理するアプローチだった。Scionはデータモデル自体を変えており、踏み込みの深さが異なる。

重要な点として、Anthropic自身はScionをGitの汎用代替として推奨していない。Scionの運用には専用のコードレビュー、コード検索、CIシステムが必要であり、同社の実装は高度にカスタマイズされたものだ。つまり「Gitをやめてすぐ使える代替品」ではなく、特定のワークロードに対して徹底的に最適化した専用システムという位置付けになる。

同社が外部に提案するのは、Scionそのものの採用ではなく、包括的なサーバーサイドAPIの整備と改善されたフェッチプロトコルという考え方を既存のGitプラットフォームに取り込むことだ。

アーキテクチャ上の示唆として記事が提示しているのは、「ワークロードが変化したとき、処理をどこで行うかを再考せよ」という点だ。リポジトリへのクエリは必ずしもローカルチェックアウトを必要とせず、不変オブジェクトはキャッシュ経由で共有できる。一方でScionはサーバーの可用性に依存し、必要な統合作業も相当なものになる。

詳細はHow Anthropic Redesigned Source Control for AI-Driven Developmentを参照していただきたい。