AnthropicのScion：エージェントスケールのモノレポのためのソース管理の再設計

Anthropicは、社内バージョン管理システムであるScionを構築し、5ヶ月でモノレポをgitから完全に移行したと発表しました。これは、人間のスケール向けに設計された開発者インフラ（ソース管理、ビルド、CI）が、現在Claudeが同社のコードの大半を書くようになったことでボトルネックになっていたためです。この投稿はScionの設計に関する技術的なケーススタディであり、製品リリースではありません。Anthropicは、Scionがgitの汎用的な代替品として適しているわけではなく、広く提供する計画もないと明言しています。

問題：マージ量がgitの限界を超えた

Anthropicのマージ率は4ヶ月で約10倍に成長し、同社はこの成長が鈍化するとは予想していません。2026年5月、Anthropicは1日あたり平均約2,500件のコード変更をマージしていましたが、2026年9月現在では1日あたり30,000件以上をマージしています。Anthropicはコードマージに対する潜在的な需要を「実質的に無限」と表現し、ボトルネックを取り除くたびに即座に生成されるコード量が増加すると指摘しています。

モノレポの規模は、インフラストラクチャへの負担の直接的な原因です。メインブランチの履歴だけで約100GB、圧縮されたワーキングコピーは25GB以上あります。Anthropicは、開発者環境、エージェントサンドボックス、研究ジョブを数える前に、CIのために1日あたり約2,500万回のコードチェックアウトを実行しています。これを素朴に取得した場合、1日あたり600PBを超えるgitトラフィックになります。

gitの分散型設計（すべてのクローンが完全で自己完結型のリポジトリであり、オフラインでもdiffの計算、履歴やblameの読み取り、任意のリビジョンのチェックアウトが可能）は、圧倒的多数のリポジトリにとって正しい設計であり、Anthropicもそう明言しています。これは単にこのワークロードには適合しないだけです。Anthropicは、シャロークローン、スパースチェックアウト、プロミサーリモート、内部gitミラー、ブロブストレージ内のリポジトリスナップショット（シード）を使用していました。ピーク時には、負荷に対処するために数百の内部gitミラーを運用していました。これらの回避策は時間を稼ぎましたが、マージ率が上がるにつれて運用が難しくなりました。シードはリフレッシュの間にメインの先端からさらに離れ、部分クローンでdiffやblameなどの履歴依存の操作を機能させ続けるには、ますます注意が必要になりました。

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

エージェントスケールのソース管理のための6つの原則

Scionはgitとは異なる一連の前提に基づいて設計されました。Anthropicは、大規模モノレポのソース管理における先行技術（GoogleのPiperとMetaのSapling）が設計に影響を与えたとしています。

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

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

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

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

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

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

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

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

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

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

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

Scionのスケーリング：階層型キャッシュアーキテクチャ

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

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

クライアントはソケットを介してデーモンscion-daemonと通信し、ノード全体のオブジェクトを保存します。ほとんどのノードはモノレポへのアクセスを必要とし、同じノード上のジョブは同じオブジェクトのほとんどを再利用します。各デーモンは定期的に更新されるスナップショットから開始し、その後、リージョン内のツリーおよびブロブキャッシュサーバー（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の必要性を同時に高め、構築速度を大幅に加速させたと述べています。

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

少人数チームによる迅速な開発はより一般的になる

7人のチームがScionとAntique（Anthropicのコードレビューツール）の両方に加えて、半ダースの関連システムを構築し、5ヶ月で完全に移行しました。その間、1日あたりにマージされるコードの量は10倍に増加しました。Anthropicは、このようなソース管理システムの開発と展開は、以前は多くのエンジニアによる何年もの反復的な移行を必要としただろうと指摘し、この種の迅速で機敏な移行がより一般的になると予想しています。

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

Anthropicは、このシステムに携わったすべてのエンジニアが、今ではClaudeの方がコードを書く能力で自分たちよりも優れていると評価するだろうと述べています。しかし、エンジニアは依然として、システム間の高レベルのコンポーネントと設計レベルのトレードオフについての理解を提供し、どの問題を解決するか、どのスケールを達成するかについて情報に基づいた選択を行いました。Anthropicは、エンジニアの役割はしばしばClaudeに「ノー」と言うことであると説明しています。

エージェントは、そもそも許可されるべきではなかったパターンを満たすために、中核的なシステム制約に違反することがあります。

これは特に移行中に一般的でした。例えば、複数のシステムが、コードレビューツールに尋ねる代わりに、コミットログを線形に読み取って、変更がいつメインにマージされたかを力技で調べようとしました。Anthropicはまた、敵対的レビューを広範囲に利用しており、これは非常に効果的ですが時には近視眼的であると述べているため、熟練したエンジニアは、仮説的な懸念に応えてシステムの一部を過剰にエンジニアリングしないようにClaudeを導く必要がありました。そのようなレビューの1つは、別の内部サービスを信頼することに対して過度に防御的であり、その結果、Claudeが過剰な検証と複雑さを追加しました。チームメンバーは今でもシステムのすべての変更要求をレビューしていますが、すべてのコード行を読むのではなく、変更の意図を調べています。

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

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

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

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

新しいレベルの運用上の優秀さが可能になる

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

Anthropicは自らの前提を再考している

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

Scionはgitの代替品ではなく、Anthropicはオープンソース化しない

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

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

代わりに、Anthropicができる最も影響力のあることは、その考えを共有して、他の開発者がScionの最も成功した部分をgitに適用し、全体的なモデルから逸脱しないようにすることだと言います。投稿からの具体的な提案：

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

Anthropicは、この種の問題は今後6〜12ヶ月でより一般的になると予想しており、gitを使用するすべての企業が同様の課題に単独で直面することは、エンジニアリングリソースの非効率な使用であると主張しています。投稿は、gitコミュニティが何百万もの開発者のためにプラットフォームをスケーリングするのにほぼ20年を費やしてきたことを認め、Anthropicの貢献はより狭いものであると位置付けています。それは、エージェント型ソフトウェア開発がこれらのシステムとどのように相互作用するかについての初期の見解を提供し、GitHub、GitLab、およびオープンソースコミュニティと連携することです。

技術的な脚注

Scionは、変更されたファイルをマージの最初の親に対して相対的に保存します。Anthropicはこれをスタイル上の選択であると説明し、実際には人々はモノレポのトランクベース開発においてメインライン上のコミットの履歴またはblameのみを気にすることを指摘しています。

この投稿はNick G.とソース管理チーム（S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.）によって書かれ、チームを支援してくれたVilas J.とSergiu D.、そしてAntiqueへの初期の貢献に対してAmir O.に感謝の意が表されています。

まとめ

Anthropicは、社内バージョン管理システムであるScionを構築し、2026年5月の1日あたり約2,500件から2026年9月の30,000件以上への10倍のマージコード変更の増加に対処するために、5ヶ月でモノレポをgitから移行しました。

タイトル

AnthropicのScion：エージェントスケールのモノレポのためのソース管理の再設計

Sources