Anthropic、常時オンラインのエージェント向けにソース管理を再構築

Anthropicによると、社内モノレポで1日にマージされる変更は、5月の約2,500件から2026年9月には3万件超に増えた。同社の10月13日のエンジニアリング記事は、この増加の多くを支えるエージェントや自動ジョブ向けに構築したソース管理システムScionを紹介している。注目すべき技術的な問いは、履歴、コミット、マージを中央サービスに任せられるとき、クライアント側にどの作業が残るのかだ。

大きな変化

• 何が変わったか： Anthropicは5か月でモノレポをGitからScionへ移行した。Scionのクライアントは必要なオブジェクトだけを取得し、コミット、マージ、リベース、履歴検索をサーバーに任せる。Anthropicは、オンラインのエージェントやジョブが大半を占める負荷向けに構築した。
• なぜ重要か： CIジョブはローカルリポジトリを維持せずに、API経由で差分やマージベースを要求できる。ファイルが必要な場合、スパースまたは仮想化チェックアウトによってディスクに置く内容を制限できる。これによりコストと運用責任が中央サービス側へ移る。
• 注目点： Anthropicは自社フリートでチェックアウトの高速化とインフラ利用の削減を報告しているが、ここでは独立検証されていない。同社によればScionは特注の社内システムで、移行にはコードレビュー、検索、CIの変更も必要だった。

このモノレポでGitのコストが高くなった理由

Gitの分散設計では、各完全クローンがオフライン作業に必要な履歴とオブジェクトを保持する。Anthropicによると、モノレポのメインブランチ履歴は約100 GB、圧縮した作業コピーも25 GBを超える。同社のCIフリートは、開発環境、エージェントのサンドボックス、研究ジョブを除いても、1日に約2,500万回コードをチェックアウトする。これはAnthropicの負荷の数値であり、Gitが機能しなくなる一般的な境界ではない。

同社は以前からシャロークローン、スパースチェックアウト、社内ミラー、リポジトリのスナップショットを使っていた。リポジトリとマージ頻度の増加に伴い、数百個のミラーの運用が難しくなったという。Anthropicの診断は固有のものだ。クライアントの大半はもともとオンラインのエージェントやジョブだったのに、ツールはローカルリポジトリを維持するコストの多くを負っていた。

Scionはオンライン接続を設計上の前提にしている。そのエンジニアリング記事によると、サーバーが履歴とblameの問い合わせに応じ、コミットを作成し、マージやリベースを実行する。クライアントは上限のあるオブジェクトキャッシュを持ち、要求された作業ファイルをディスクに置き、ローカルのファイル変更を監視する。これらの操作を単独で実行できなくなることは、各クライアントへ送るデータを減らすための意図的なトレードオフだ。

チェックアウトは小さくでき、不要になることもある

Scionはクライアントが使うソース管理クエリをAPIとして提供する。Anthropicによると、マージベースとの差分を必要とするCIジョブはサーバーに直接問い合わせられる。自動化された二分探索やリバートのパイプラインも同じプログラム経路を使う。こうした作業では、ジョブが作業コピーを実体化する必要さえない場合がある。

ジョブがファイルを必要とする場合、Scionは指定ディレクトリだけを含むスパースチェックアウトと、読み取り時にファイルを実体化する仮想化チェックアウトをサポートする。クライアントは大きなpackfileを交渉する代わりに、不足している特定のtreeとblobを再帰的に要求する。要求する各オブジェクトには不変のコンテンツアドレス識別子があるため、キャッシュは内容が変わったかを確認せずに返せる。Anthropicは、クライアントと権威サーバーの間にノード単位のデーモンとリージョナルキャッシュを置く構成を説明しており、全レイヤーが同じオブジェクト要求プロトコルを使う。

この設計では、完全なローカルクローンとは障害と保守の境界が異なる。クライアントはGitがオフラインで行える操作をサービスに依存し、サービスはフリートの速度に合わせてオブジェクトや履歴の問い合わせを提供しなければならない。Anthropicによると、リージョナルキャッシュが故障した際に上流サーバーが過負荷になるのを防ぐことも、キャッシュ階層を設けた理由の一つだ。この記事には、この構成の可用性を示す測定値はない。

サーバーが保存・計算するもの

Scionの作業単位は、write-ahead log内のchangesetだ。Anthropicによると、最初の親に対する変更ファイルを記録し、blobストレージ内の圧縮ファイル内容へのポインターを持つ。サーバーは書き込みごとに共有ブランチのポインターを動かすことなくchangesetを作る。別の派生構造がファイルのblame、パス履歴、コミットの祖先関係などの問い合わせを支える。Anthropicは一部を先に計算し、ほかは後回しにできる。

この分離はAPI設計に関わる。ジョブは、答えをローカルで計算するためのすべての構造を持たずに、マージベースやファイル履歴を要求できる。それらの構造を維持するコストもAnthropicのサービス側へ移る。同社によると、リポジトリデータを分散し、コンポーネントを個別にスケールさせており、サーバー上でも完全に実体化したリポジトリのコピーはない。

Anthropicは、Scionのインフラが以前のGitミラー構成と比べてCPUとメモリを200分の1に抑え、CIや研究のチェックアウトが数分ではなく数秒で済むと報告している。また、この変更によってCIのCPU容量が25%増えたとしている。これらはAnthropicの従来の社内システムと自社の負荷を比較したものだ。BIG CHANGEは測定を再現しておらず、基礎となるテレメトリーも確認していない。

移行コストも成果の一部

Anthropicによると、7人のエンジニアがScion、コードレビュー用の連携ツールAntique、関連システムを構築し、5か月でモノレポを移行した。その説明には、新しいコード検索、アクセス制御、コードのレビューや取り込み方法の変更も含まれる。この設計を評価する組織は、ソース管理サービスだけでなく、隣接するワークフローも考慮する必要がある。

Anthropicは、Scionが汎用的なGitの代替には適さないと明言している。社内のレビュー、検索、CIの各コンポーネントは特注で、Gitから離れるには開発ライフサイクル全体の変更が必要になる。同社の説明から得られる、より限定的な教訓はアーキテクチャにある。オンラインサービスは自動化クライアントのソース管理に関する質問へ多く回答でき、クライアントは使うファイルだけを保持できる。Anthropicは、より豊富なサーバーAPIやGitのsparseとshallow機能のより良い組み合わせなど、Scionを採用せずに応用できる考えも挙げている。

出典と参考資料

• Anthropic Engineering, “Redesigning source control at Anthropic”（2026年10月13日）。Scionのアーキテクチャ、移行、社内の負荷と性能の数値に関するAnthropicの一次資料。報告された測定値や運用上の成果はBIG CHANGEが独立検証しておらず、この記事ではScionのシステムをテストしていない。