Anthropic 将内部单体仓库从 Git 迁至自研基座 Scion

Anthropicは2026年10月13日、社内のソース管理基盤Scionへの移行を扱う技術記事を公開した。一般提供の発表ではなく、社内での設計と移行の事例を紹介している。

同社はAIによる開発量の増加を受け、複数のプロジェクトをまとめたモノレポをGitからScionへ移した。常時接続を前提に処理をサーバーへ集め、クライアントが保持・取得するデータを減らしている。

Redesigning source control at Anthropic - Engineering at Anthropic

同社で1日にマージされる変更は、2026年5月の約2500件から9月には3万件超へ増加した。Claudeがコードを書く速度が上がり、ソース管理やビルド、継続的インテグレーション（CI）など、変更を取り込んで検証する基盤がボトルネックになったという。

CIや研究用の処理へコードを配る負担

Anthropicのモノレポは、メインブランチの履歴が約100GB、圧縮した作業用コピーが25GB超に達し、CIだけで1日約2500万回のチェックアウトが発生していた。

Gitは通常、履歴をローカルに持ち、接続がなくても履歴の参照やコミットができる。ただし、Anthropicのように巨大なリポジトリを大量の自動処理で使う場合、処理を実行する各環境に必要なデータを用意する負担が大きくなる。

同社は、取得する履歴を絞るshallow clone、作業用ファイルを必要な範囲に限定するsparse checkout、足りないデータを後から取得するpromisor remoteなどのGitの機能や、社内ミラーで負荷を抑えていた。それでも、取得範囲を絞りつつ差分や変更履歴を調べられる状態を維持するには、次第に手間がかかるようになったという。

ソース管理へアクセスするのは、主に常時オンラインのエージェントや、CI・研究などの自動処理を実行するジョブだった。そこでAnthropicは、各クライアントが手元で処理を完結させる前提を変え、サーバーへ必要な処理を依頼するScionを設計した。多数の技術者やエージェントが使う巨大なモノレポに用途を絞っている。

処理をサーバーへ集め⁠、クライアントの作業を減らす

Scionでは履歴の照会、コミットの作成、マージやリベースをサーバーが処理する。たとえばCIでコードの変更内容を確認したい場合は、ScionのAPIを呼び出し、変更前後の差分を取得できる。その確認のために、CIの実行環境へリポジトリを取得して維持する必要がなくなる。テストなどでファイル自体が必要な場合も、対象のディレクトリだけを取得したり、実際に読み出すファイルだけを展開したりできる。

Scionのサーバーは、Gitのコミットに相当するchangesetという単位で変更を記録する。changesetには、基準となる状態と比べて変わったファイルの一覧と、その内容の保存先を示す参照が含まれる。コミットの作成ではこの変更分を扱うため、リポジトリ全体の大きさに左右されない設計になっているという。

データの再利用で配布の負荷を減らす

Scionでは、リポジトリのデータを分散ストレージに保存し、サーバー側にも全体を展開したコピーを置かない。クライアントは、必要なファイルのうち手元にないデータを個別に要求し、サーバーはそのデータを返す。このため、クライアントごとに大きな転送データを組み立てる必要がない。

CIや研究用ジョブを動かす計算ノードには、取得したデータを保存する常駐プロセスを置く。これにより、同じノードのジョブ間でデータを再利用できる。さらに、各ノードは同じ地域（リージョン）内で共有するキャッシュサーバーに接続する。このキャッシュにデータがあれば、取得元となるScionのサーバーへ要求を送らずに済む。

Anthropicは、Scion基盤のCPU・メモリ要件が従来のGitミラー基盤の200分の1になったと報告している。CIや研究用ジョブのチェックアウトは分単位から秒単位になり、CIではCPU容量を25%節約できたという。

新基盤の開発にもClaudeを活用

Claudeは、ソース管理の負荷を増やしただけでなく、新基盤の開発を速める手段にもなった。Anthropicによると、7人のチームがScionやコードレビュー用システムなどを構築し、5カ月でモノレポの移行を完了した。

この開発では、技術者がシステム同士の関係を理解し、設計で何を優先するかを判断した。Claudeがシステムの制約に反する処理や過剰に複雑な実装を加えることもあり、技術者がそれを抑える必要があったと述べている。

コラム⁠：GitHubでも月間コミット数が前年の5倍超に

GitHubでも、開発量の増加に対応する基盤の見直しが進んでいる。同社が10月6日に公開した技術記事によると、2026年9月に開発者とエージェントがGitHub上で行ったコミットは73億8000万件に達し、前年同月の5倍を超えた。

GitHubは、エージェントが短い間隔で変更を記録するようになると、1回のプッシュを待つ時間も作業速度を左右すると説明する。さらに、変更のたびにCIなどがコードを取得するため、書き込みと読み出しの両方を効率よく処理する必要がある。

GitHubの既存基盤では、障害に備えてリポジトリ全体のコピーを複数のサーバーに保存し、それらのサーバーで読み出し要求も分担している。ただし、変更を書き込む際はすべてのコピーを更新する必要があり、コピーを増やすとプッシュが遅くなるという。

このためGitHubは、データの保存と読み出し要求の処理を分離する構成への移行を進めている。リポジトリのデータはストレージに保存し、読み出し要求には、必要なデータをキャッシュするワーカーが応える。読み出しの負荷が増えた場合はワーカーを増やして対応できるため、変更のたびに更新する保存用のコピーを増やす必要がなくなる。こうした内部基盤の変更後も、ブランチの作成やレビュー、マージといった既存の開発フローは維持する方針を示している。