AnthropicのScion：AnthropicがGitをエージェント規模のバージョン管理システムに置き換えた方法

Anthropicは、社内バージョン管理システムであるScionを構築し、5ヶ月でモノレポをgitから完全に移行したと発表しました。これは、gitの分散型でオフライン優先の設計が、コードを書くAIエージェントにもはや追いつかなくなったためです。同社は、マージされるコード変更が2026年5月の1日あたり約2,500件から、2026年9月には1日あたり30,000件以上に増加し、Scionのインフラストラクチャフットプリントは、CPUとメモリの点で以前のgitミラーリング設定よりも200倍小さいと報告しています。

核心的な問題：コーディングがボトルネックではなくなった

Anthropicでは、システム構築と研究のボトルネックはもはやコードを書くことではありません。それは、人間の規模に合わせて構築された開発者インフラストラクチャ、つまりソース管理、ビルド、CIです。Claudeは研究ループを自律的に反復し、複雑なプログラムをマイクロ最適化し、新しいサービスをゼロから構築できますが、周囲のツールが制約になっています。

Anthropicが引用する成長率は急峻です。2026年5月、Anthropicは1日あたり平均約2,500件のコード変更をマージしていました。2026年9月の時点では、1日あたり30,000件以上をマージしています。Anthropicは、この成長率が鈍化するとは予想しておらず、コードをマージすることへの潜在的な需要は「実質的に無限」であると述べ、ボトルネックを取り除くたびに、生成されるコード量が即座に増加すると指摘しています。

Scionに加えて、AnthropicはコードレビューサーフェスであるAntique、コード検索、ソース管理IAMシステム、そして大量のレビュー済みコードを管理および展開する新しい方法も、同じ5ヶ月間で構築してリリースしました。

gitがAnthropicのモノレポに適合しなくなった理由

Gitは分散型システムであり、すべてのクローンは完全で自己完結型のリポジトリであり、完全にオフラインでも差分の計算、履歴とblameの読み取り、任意のリビジョンのチェックアウトが可能です。Anthropicは、大多数のリポジトリにとってこれは正しい設計であり、gitが標準になった大きな理由であると明確に述べています。しかし、Anthropicのモノレポは、ますますその設計領域から外れています。

Anthropicが示す具体的な規模の数値は次のとおりです。

メインブランチの履歴だけでほぼ100 GBです。
圧縮された 作業コピーは25 GBを超えます。
Anthropicは、開発者環境、エージェントサンドボックス、研究ジョブを数える前に、CIのために1日あたり約2,500万回のコードチェックアウトを実行します。
素朴にフェッチすると、1日あたり600 PBを超えるgitトラフィックになります。

Anthropicは、利用可能なすべての標準的な回避策（シャロークローン、スパースチェックアウト、プロミサーリモート、内部gitミラー、blobストレージに保持されたリポジトリスナップショット（シード））を使用しました。ピーク時には、Anthropicは負荷に対処するために数百の内部gitミラーを運用していました。これらは時間を稼ぎましたが、マージ率が増加するにつれて運用が難しくなりました。シードは更新の間にメインの先端からさらに離れ、部分クローンでdiffやblameなどの履歴依存の操作を機能させ続けるには、ますます注意が必要になりました。

重要な洞察は、Anthropicがほとんどの企業と同様に、gitを1つの権威あるコピーを持つ集中型システムとして使用していた一方で、そのクライアントのほぼすべてが、定義上オンラインであるエージェントとジョブであるということでした。分散型でオフラインの作業に優れたgitの特性が、リポジトリが成長するにつれてAnthropicのスケーリング能力を積極的に損なっていました。

Scionの背後にある6つの原則

Anthropicは、巨大なモノレポにおけるソース管理の先行技術、具体的にはGoogleのPiperとMetaのSaplingに言及し、それらの苦労して得た教訓を念頭に置いてScionを構築したと述べています。この設計は6つの原則に基づいています。

1. クライアントは常にオンライン

Gitは、クライアントがオフラインで動作し、リポジトリの完全なコピーを必要とすることを前提としています。Anthropicのクライアントのほぼすべてがエージェントとジョブであるため、Scionのクライアントとプロトコルは、サーバーが常に到達可能であり、クライアントが必要なときにデータをフェッチすることを中心に設計されています。

2. クライアントとサーバーの非対称性

Gitでは、すべてのクライアントが本格的なサーバーになることができます。Scionでは、サーバーがファイル履歴とblameに関する質問に答え、コミットを作成し、マージとリベースを実行します。クライアントは、境界のあるローカルオブジェクトキャッシュを維持し、作業コピーファイルをディスクにレイアウトし、ファイルシステムの変更を監視し、サーバーと連携するための人間工学的な方法を提供します。クライアントは単独で計算できることはほとんどありませんが、ローカルに必要なデータははるかに少なくなります。

3. 包括的なソース管理サービスは多くの新しいアプリケーションを強化できる

Gitでは、リポジトリについて質問する必要があるCIジョブやツール（最後に誰が行を変更したか、2つのコミットがどのように関連しているかなど）は、ローカルコピーを維持するか、ベンダー固有のAPIに依存する必要があります。Scionでは、クライアントが使用するすべてのソース管理クエリがAPIを介しても公開されているため、多くの場合、ジョブはローカルリポジトリをまったく必要としません。Anthropicは、自動化されたbisectやrevertパイプラインなどの内部ツールは、この安価でプログラムによるソース管理へのアクセスがなければ、大規模には実用的ではないと述べています。

4. すべてが水平方向にスケーラブルでなければならない

ピーク時には、Anthropicは数百のgitミラーを実行していましたが、これは容量を圧迫し、リポジトリがミラーのディスクまたはメモリ制限を超えるとスケーリングを停止しました。Scionでは、リポジトリデータは分散され、すべてのコンポーネントが独立してスケーラブルです。サーバー上であっても、リポジトリの完全にマテリアライズされたコピーはどこにもありません。gitのパックファイルに相当するものがないため、リポジトリのメンテナンスは不要です。

5. コミットは安価で、増分的で、ロックフリーでなければならない

Gitでは、ローカルでコミットしてからプッシュして作業を共有します。Scionでは、すべてのコミット、リベース、またはマージがサーバー上で発生するため、プッシュするものはありませんが、これらの各操作は高速である必要があります。コミットを作成し、その下流のデータ構造を更新するコストは、リポジトリ全体のサイズではなく、変更のサイズに応じてスケーリングする必要があります。Scionの開発ライフサイクルは、メインのrefまたはリリースブランチを除いて、refs（ブランチやタグなどのコミットへのポインタ）を推奨していません。これは、すべてのサーバーが同意する必要があるグローバル状態が、差し迫ったスケーリング問題だからです。

6. 作業コピーはオプションであり、設計上スパース

モノレポが非常に大きく、CIのためにコードが1日に数千万回チェックアウトされるため、Anthropicは可能な限りチェックアウトを避けたいと考えていました。コミットとそのマージベースの間の差分を必要とするCIジョブは、サーバーにそれを要求できます。多くの書き込みワークロードも、チェックアウトをスキップして、完全にAPIを介して機能できます。Scionのプロトコルは、クライアントが要求したディレクトリのみを含むスパースチェックアウトと、オンデマンドでファイルをマテリアライズする仮想化チェックアウトを中心としているため、ジョブは実際に読み取った分だけ支払うことになります。

Scionの仕組み：チェンジセットと派生データ

Scionでは、作業の単位はチェンジセットであり、これは書き込み先行ログのエントリです。チェンジセットはgitコミットが保存するもののほとんどを保存しますが、gitコミットがツリーへのポインタを保存するのに対し、チェンジセットは最初の親に対する相対で変更されたファイルのリストと、blobストレージ内の圧縮されたファイルコンテンツへのコンテンツアドレス指定されたポインタを保存します。チェンジセットはサーバー側で作成され、どこでも即座に利用できます。

この構造により、Scionは非常に高いスループットでチェンジセットを受け入れることができます。受け入れるパックファイルがなく、ロックやサーバー間の調整がなく、移動するrefsもありません。Scionは技術的にはrefsをサポートしていますが、コミットの作成もフェッチもrefsを伴わないため、refの移動は、チェンジセットの作成とは別に発生する単一のSpanner行での比較交換（compare-and-swap）です。

チェンジセットは変更されたものだけを記録するため、それだけでは「最後に誰がこの行を編集したか」や「どのコミットがこのファイルに影響を与えたか」といった質問にすばやく答えることはできません。そのため、Scionはチェンジセットから追加のデータ構造（ファイルのblameとパス履歴用の専用構造、コミットグラフ用のスキップリスト）を構築します。Anthropicは、チェンジセットの直接の一部ではないすべてのものを派生データと呼び、すべてを1つの汎用メカニズムを通じて計算します。各タイプの派生データは再帰的に定義されるため、チェンジセットの値は、そのチェンジセットの親の値から計算されます。

Anthropicは、このメカニズムの3つの利点を挙げています。新しいデータ構造が操作を高速化する場合に、新しいタイプの派生データを簡単に追加できること。各タイプを熱心にまたは遅延して計算できるため、不要なデータがマテリアライズされることはないこと。クライアントがこれらの構造の内部を決して見ないため、クライアントを変更せずに最適化できることです。Anthropicは、システムが成長するにつれて、コピー検出やパスベースのファイル検索用の新しいインデックスを含む、新しいタイプの派生データを何度も追加したと述べています。

サービングアーキテクチャ：デーモン、キャッシュ、サーバーティア

小規模なScionサーバーフリートは、クライアントが必要とする任意の操作（チェンジセットの取得、差分の計算、マージベースの検索、blobのフェッチ）のためのソース管理APIを提供します。すべてのソース管理データはコンテンツアドレス指定されているため、データは一度保存されると変更されることはなく、どのサーバーも他のサーバーに確認することなくキャッシュできます。したがって、サーバーは水平方向にスケーラブルで、ほとんど調整を必要とせず、実質的に大きなキャッシュとして機能し、派生データをその場で計算して結果をSpannerに書き戻すことができます。

Scionのscnクライアントは、いくつかの重要な点でgitのフェッチプロトコルから逸脱しています。Scionのネゴシエーションは、サーバーにクライアントがすでに持っているものを伝えません。代わりに、クライアントが望むツリーとblobのみを操作します。ルートツリーから始めて、クライアントはローカルストアに欠落しているツリーがないか確認し、それらを再帰的に要求し、次にblobについて同じプロセスを繰り返します。すべてのリクエストは決して変更されない特定のオブジェクトに対するものであるため、どのキャッシュもそれに応答でき、アーキテクチャは従来の階層型キャッシュに非常に似ています。このプロセスは、単一の数ギガバイトのパックファイル応答がないため、効率的で再開可能です。スパースおよび仮想化されたチェックアウトでさえ、クライアントが望まないツリーを要求しないだけなので、特別なサポートは必要ありません。

クライアントはソケットを介してデーモンscion-daemonと通信し、デーモンはノード全体のオブジェクトを保存します。ほとんどのノードはモノレポへのアクセスを必要とし、同じノード上のジョブは同じオブジェクトのほとんどを再利用します。各デーモンは定期的に更新されるスナップショットから開始し、その後、自分のリージョン内のツリーおよびblobキャッシュサーバー（scion-cacheと呼ばれる）とのみ通信します。これらのキャッシュサーバーは、デーモンが消費するディスク形式でメモリから直接オブジェクトをストリーミングするため、クライアントの欠落オブジェクトの計算やデルタ圧縮の実行に時間を費やしません。キャッシュにオブジェクトがない場合、権威あるscion-serversに要求し、必要に応じてSpannerまたはクラウドストレージから読み取ります。

scion-daemon、scion-cache、scion-serverはすべて、このプロトコルに対して同一のRPCに応答するため、クライアントはキャッシュトポロジを知る必要はありません。理論的にはどのティアも他のティアと通信できますが、Anthropicは障害ドメインを分離するためにティアリングを厳密に強制しています。具体的には、リージョンのscion-cache障害が上流のscion-serversを圧倒し、システム全体をダウンさせることを避けるためです。

測定された結果

Anthropicは移行から次の結果を報告しています。

システムの各ティアは99%以上のキャッシュヒット率を維持し、長命な状態を必要としないため、簡単にスケールアップできます。
Scionのインフラストラクチャフットプリントは、CPUとメモリの要件の点で、以前のgitミラーリングインフラストラクチャよりも200倍小さいです。
CIおよび研究ジョブは、コードのチェックアウトが2桁速く、数分ではなく数秒で完了し、フリート全体でかなりの容量が解放されます。
CIだけでも25%のCPU容量の向上を実現しました。
クライアントもキャッシュもリポジトリのメンテナンスを実行する必要がなく、ジョブのライフサイクル管理が簡素化されます。

AnthropicがScionの構築から学んだこと

Anthropicは、Claude Mythos PreviewとClaude Tagが社内で利用可能になったのとほぼ同時期にScionの構築を開始しました。両方のリリースが同時にScionの必要性を増幅し、システムを構築できる速度を大幅に加速させたと述べています。

Claudeが取り込みパイプラインを書き換えた

Anthropicは、gitからScionへの取り込みパイプラインの最初のバージョンをプロトタイプとしてほぼ手書きしていました。Claude Mythos Previewの初期の内部スナップショットへのアクセスを得た後、チームはそれに全体を書き換えるよう依頼しました。それ以上の指示なしに、Claudeはメモリ消費が20倍少なく、4倍高速なバージョンを生成し、取り込み順序とデータ構造に関する暗黙の不変条件をすべて保持しました。

小規模チームが数ヶ月で複数年にわたる移行を実行できるようになった

7人のチームがScionとAntique、および関連する半ダースのシステムを構築し、5ヶ月で完全に移行しました。その間、1日あたりにマージされるコードの量は10倍に増加しました。Anthropicは、このようなソース管理システムの開発と展開は、以前は多くのエンジニアを擁する企業で数年にわたる反復的な移行が必要だっただろうと述べ、このような迅速で機敏な移行がより一般的になると予想しています。

エンジニアの価値は低下していないが、その仕事は変化している

Anthropicは、このシステムに携わったすべてのエンジニアが、現在ではClaudeの方が自分よりもコードを書くのが得意だと評価するだろうと述べています。それでも、それらのエンジニアは、システム間の高レベルのコンポーネントと設計レベルのトレードオフの理解を提供し、解決すべき問題と達成すべき規模について情報に基づいた選択を行いました。Anthropicは、エンジニアの役割はしばしばClaudeに「ノー」と言うことであると説明しています。エージェントは、決して許可されるべきではなかったパターンを満たすために、コアシステムの制約に違反することがあります。これは移行中に特に一般的でした。たとえば、複数のシステムが、コードレビューツールに尋ねる代わりに、コミットログを線形に読み取って変更がメインにマージされた時期を力技で調べようとしました。

Anthropicはまた、敵対的レビューを広範囲に使用しており、これは非常に効果的ですが、時には近視眼的であると述べています。熟練したエンジニアは、仮説的な懸念に応えて過剰エンジニアリングしないようにClaudeを導く必要がありました。そのようなレビューの1つは、別の内部サービスを信頼することに対して過度に防御的であり、その結果、Claudeが過剰な検証と複雑さを追加しました。チームメンバーは依然としてシステムのすべての変更要求をレビューしていますが、現在はコードのすべての行を読むのではなく、変更の意図を調べています。

最適化と品質が大幅に向上

Claudeは人間よりもはるかに速く膨大な量のコードを書くことができるため、ScionはAnthropicがこれまでに取り組んだ中で最もテストが行き届き、防御がしっかりしたコードベースの1つです。厳しいタイムラインでも、チームは遭遇したすべての非自明なインフラストラクチャおよびソース管理の相互作用のハーメティックシミュレーションに加えて、ファジングと洗練されたレート制限を構築しました。Anthropicはまた、Claudeが偶然にも重要な最適化を発見したと報告しています。たとえば、チームのインデックスの1つを見逃していた祖先クエリへのアルゴリズム最適化（専門家が数日または数週間の分析と調整を要する作業）を発見し、翌日にはまたそれをやり直しました。

新しい形式のモノレポセキュリティ

Scionは、リポジトリに対する豊富なアクセス制御と、個々のディレクトリに権限を適用する機能をサポートしており、モノレポの利点を失うことなく、最も機密性の高いコードを保護します。Anthropicが構築したコードレビューツールは、承認に関する複雑なセマンティック制約を表現でき、コメントのみの編集などの単純な変更と機密性の高い論理変更を区別できるため、人間のレビュー担当者は最も重要な変更に集中できます。

「スーパーファン」：Claudeをコンポーネントレベルのモニターとして使用

チームはClaude Tagを多用しています。単一のコンポーネントの健全性に執拗に焦点を当てることを任されたClaudeがいるSlackチャンネルを作成しました。scion-daemonスーパーファン、scion-cacheスーパーファン、Antiqueマージキュースーパーファンなどです。これらのClaudeはテレメトリとログにアクセスでき、チャートを更新して何か奇妙なものを探す以外にやることがない経験豊富なエンジニアのように動作します。Anthropicは依然としてすべてのシステムで従来のアラートを実行していますが、スーパーファンは、それらのアラートが比較すると一次元的に見えるような、微妙で新しい問題を検出すると述べています。

マージキューとCIの再考

このプロジェクトは、Anthropicに人間の規模に合わせて設計された他のワークフローを再検討するきっかけを与えました。適切なマージキューはエージェント規模ではあまり意味をなさず、同社は、テストの実行中に数百または数千の変更がマージされる可能性がある場合、CIが何を意味するのかを問いかけています。Anthropicは、マージキューに対する業界標準のグローバルリポジトリロックを効果的に複製できなかったため、代わりにマージ後およびデプロイ前の自動テストに投資しました。これは、同時変更が競合する可能性があることを意味しますが、AnthropicはClaudeが通常、人間がそれらを特定するよりも速くそれらの競合を修正できると述べています。

Scionは一般的な使用のためのgitの代替ではありません

Anthropicは、Scionが決して一般的な使用のためのgitの適切な代替ではないことを明確にしています。それが説明する概念は、数万人のエンジニアまたはコードを大量に書くエージェントの群れを持つ、本当に巨大なモノレポでのみ意味をなします。Anthropicはまた、内部使用のためにトークンを費やす能力が、他のどの企業が現実的に費やしたいと思うであろうものをはるかに超えているという点で独自であると述べています。これは、自社のソフトウェア開発ニーズに対処するためと、Claudeの機能をテストするための両方です。

実際には、Anthropicは、Scionを他の組織に広く役立つ形で提供することは難しいだろうと述べています。それはgitから大幅に逸脱しているため、企業は開発ライフサイクルのすべての部分を移行する必要があり、独自のコードレビュー、コード検索、CIが必要です。Anthropicのこれらのコンポーネントの内部バージョンは非常に特注であり、他の組織が採用するのは難しいでしょう。すべての人を喜ばせようとする公開バージョンは、実際にはあまり役に立たないだろうと懸念しています。

Anthropicがより広いgitエコシステムに提案すること

Anthropicは、この種の問題は今後6〜12ヶ月でより一般的になると予想しており、gitを使用するすべての企業が同様の課題に単独で直面することは、エンジニアリングリソースの非効率的な使用になると主張しています。したがって、その表明された貢献は、他の開発者がScionの最も成功した部分をgitに適用できるように、その考えを共有することであり、全体的なモデルから逸脱することはありません。

Anthropicがgitに対して提案する具体的な方向性は次のとおりです。

gitサーバーはgitクライアントと同じように動作する必要はありません。大幅なスケーリング改善を提供する新しいサーバーアーキテクチャが存在します。
gitプラットフォームは、Scionのような包括的なサーバー側RPCを提供でき、おそらくgitクライアントが通信することを学習できるフォージ全体で標準化された方法で提供できます。
ネゴシエーションプロトコルは、今日とまったく同じように見える必要はありません。
gitのさまざまなスパースおよびシャロー機能をうまく構成できるようにすることができます。

Anthropicは、gitコミュニティが何百万もの開発者のためにプラットフォームをスケーリングするのにほぼ20年を費やしてきたことを認めて締めくくっています。同社は自身の貢献ははるかに狭いもの、つまりエージェンティックソフトウェア開発がこれらのシステムとどのように相互作用するかについての初期の見解を共有することであると説明し、ソフトウェア開発ライフサイクルがAIの指数関数的成長と交差するにつれて、開発者の変化するニーズをサポートするためにGitHub、GitLab、およびOSSコミュニティと提携したいと述べています。