Scionで使用している多くの手法を先駆けて実装したプロジェクトについての詳細を追加するため、10月15日に更新しました。
Anthropicでは、もはやコーディングはシステム構築や研究遂行のボトルネックではありません。Claudeは、研究ループの自律的な反復、複雑なプログラムのマイクロ最適化、まったく新しいサービスのゼロからの構築を、かつてない速度と規模で実行できます。現在のボトルネックは、人間の規模のために構築された開発インフラ、すなわちソース管理、ビルド、CIなのです。
2026年5月時点で、Anthropicでは1日あたり約2,500件のコード変更がマージされていましたが、9月には1日あたり30,000件を超えるマージが行われるようになりました。この成長率はすぐに鈍化するとは考えていません。コードをマージする潜在的な需要は事実上無限であり、ボトルネックを1つ取り除くたびに、生成するコードの量はさらに増加します。
この成長に対応するため、私たちは自社開発のバージョン管理システムであるScionを構築し、5か月でモノレポをgitから完全に移行しました。同時に、コードレビューのサーフェス（Antiqueと呼びます）、コード検索、リッチなソース管理IAMシステム、レビュー済みの大量コードを管理・取り込むための新しい手法なども構築・出荷しました。この記事では、具体的にScionをどのように構築したかに焦点を当てます。これは興味深いケーススタディになります。コードを書くClaudeの能力こそが、そもそも私たちをこの状況に陥れた原因であると同時に また それに対処する高品質でスケーラブルなシステムを迅速に構築することを可能にしたからです。
モノレポの拡大
構築したものを詳しく見る前に、私たちのワークロードがいかに特殊であるかを認めておく必要があります。当然のことながら、Anthropicはほぼ他のどの企業よりも多くClaudeをソフトウェアの作成に使用しているため、人間の規模のために構築されたツールが限界に達し始める場所を最初に目にすることが多いのです。ソース管理はその一例にすぎません。近い将来、多くの組織がこれらの問題を抱えるとは考えていませんが、AIコーディングツールを使用する他の組織も、そう遠くないうちに同じ圧力ポイントを経験すると考えています。だからこそ、私たちが構築したものと学んだことを共有したいのです。
Gitは分散型システムです。すべてのクローンは完全で自己完結したリポジトリであり、完全にオフラインの状態でもdiffの計算、履歴やblameの参照、任意のリビジョンのチェックアウトが可能です。大多数のリポジトリにとって、これは正しい設計であり、gitが標準となった大きな理由の一つです。
モノレポが成長するにつれ、その設計の範囲にますます収まらなくなりました。メインブランチの履歴だけでもほぼ100 GBに達し、 圧縮された ワーキングコピーは25 GBを超えます。私たちはCIのために、開発者環境、エージェントサンドボックス、研究ジョブを除いても、1日あたり2,500万回規模のコードチェックアウトを実行しています。素朴にフェッチした場合、1日あたり600 PBを超えるgitトラフィック would が発生することになります。
Gitには、シャロークローン、スパースチェックアウト、promisorリモートなど、リポジトリの一部を扱うためのツールが用意されています。これらに加えて、内部gitミラー、blobストレージに保持されるリポジトリスナップショット（シード）など、大規模モノレポ向けの標準的な回避策もあります。私たちはそのすべてを使用しました。ピーク時には負荷に対処するために数百の内部gitミラーを運用していました。これは時間を稼ぐことにはなりましたが、マージ率が上がるにつれて運用は難しくなりました。シードは更新の合間にmainの先端からどんどん遅れ、diffやblameのような履歴に依存する操作を部分クローン上で動作させ続けるには、ますます多くの注意が必要になりました。
一歩引いて考えてみると、ほとんどの企業と同様に、私たちはgitを単一の権威あるコピーを持つ中央集権的なシステムとして使用していましたが、クライアントのほとんどは、定義上オンラインであるエージェントやジョブでした。分散型のオフライン作業にgitを優れたものにする特性が、リポジトリの成長に伴うスケーリングの能力を積極的に損なっていました。そこで私たちは自問しました。エージェントが常にオンラインであるという事実を最初から念頭に置いてソース管理を設計したら、それはどのようなものになるだろうか、と。
エージェント規模のソース管理のための原則
エージェントによるコーディングにより、ソフトウェア開発に関する多くの一般的な前提は変化しつつあります。私たちはScionの構築にあたってこれらの変化を受け入れ、いくつかの核心的な原則においてgitとは根本的に異なるアプローチを取ることができました。巨大なモノレポ向けのソース管理には先行例があり、特にGoogleの Piper やMetaの Sapling,2 があるため、私たちはそれらの苦労して得られた教訓を念頭に置いてScionを構築することができました。私たちの原則は以下の通りです。
クライアントは常にオンラインである。 Gitは、クライアントがオフラインで作業し、リポジトリの完全なコピーを必要とするという前提に立っています。私たちのクライアントのほとんどはエージェントやジョブであるため、Scionのクライアントとプロトコルは、常に到達可能なサーバーを中心に設計し、クライアントは必要に応じてデータをフェッチするようにしました。
クライアント・サーバー間の非対称性。 gitでは、すべてのクライアントが本格的なサーバーになれます。Scionでは、サーバーがファイル履歴やblameに関する質問に答え、コミットを作成し、マージやリベースなどを実行します。クライアントは、容量制限のあるローカルオブジェクトキャッシュを維持し、ディスク上にワーキングコピーのファイルを配置し、ファイルシステムの変更を監視し、ユーザーにサーバーと作業するための使いやすい方法を提供します。クライアント単体で計算できることは非常に少ないのですが、その代わりにローカルで必要なデータ量ははるかに少なくて済みます。
包括的なソースコントロールサービスは、数多くの新しいアプリケーションを支えることができます。 gitでは、リポジトリについての質問——たとえばある行を最後に変更したのは誰か、2つのコミットがどう関連しているか——を必要とするCIジョブやツールは、リポジトリのローカルコピーを維持するか、ベンダー固有のAPIが答えを提供してくれることに期待するしかありませんでした。Scionでは、クライアントが使用するすべてのソースコントロールクエリがAPI経由でも公開されているため、多くの場合、ジョブはローカルリポジトリをまったく必要としません。自動化されたbisectやrevertパイプラインなどの多くの社内ツールは、このような安価でプログラマティックなソースコントロールへのアクセスがなければ、大規模には実用的になりませんでした。
すべてが水平方向にスケーラブルでなければなりません。 ピーク時には、私たちは数百のgitミラーを実行していましたが、これは容量に大きな負担をかけ、リポジトリがミラーのディスクやメモリの上限を超えて成長すると、もはやスケールしなくなりました。Scionでは、リポジトリのデータは分散されており、すべてのコンポーネントが独立してスケーラブルです。サーバー上でさえ、リポジトリの完全に実体化されたコピーはどこにも存在しません。packfile（gitのオブジェクトの圧縮バンドル）に相当するものもないため、リポジトリのメンテナンスは不要です。
コミットは安価で、増分的で、ロックフリーでなければなりません。 gitでは、ローカルでコミットし、作業を共有するためにプッシュします。Scionでは、すべてのコミット、リベース、マージはサーバー上で行われるため、プッシュするものはありませんが、それらの各操作は高速である必要があります。コミットの作成とその下流のデータ構造の更新のコストは、リポジトリ全体のサイズではなく変更のサイズに比例してスケールしなければなりません。そうでなければ、サーバーは追いつけません。Scionの開発ライフサイクルでは、mainのrefやリリースブランチを除き、ref（ブランチやタグなどのコミットへのポインタ）の使用が推奨されません。なぜなら、 すべてのサーバーが合意しなければならないグローバルな状態は、 差し迫ったスケーリング問題だからです。
ワーキングコピーはオプションであり、設計上スパースです。 私たちのモノレポは非常に大きく、CIのために1日に数千万回コードをチェックアウトするため、可能な限りチェックアウトを避けたいと考えていました。Scionでは、たとえばコミットとそのマージベースの差分を必要とするCIジョブは、サーバーに問い合わせることができます。書き込みについても同様で、多くの書き込みワークロードもチェックアウトを省略し、完全にAPI経由で機能できます。Scionのプロトコルは、クライアントが要求したディレクトリのみを含むスパースチェックアウトと、必要に応じてファイルを実体化する仮想化チェックアウトを中心に設計されているため、ジョブがディスク上のファイルを必要とする場合でも、クライアントは実際に読み取った分だけのコストを払えば済みます。
Scionの仕組み
Scionを構築する際にこれらの原則が実際にどのように組み合わさったのかを理解することは有益です。これらの知見は、他のソースコントロールシステムや、さらに広くソフトウェア開発ライフサイクルの他の段階にも応用できます。
データ構造
Scionでは、作業の単位は「チェンジセット」、つまりライトアヘッドログのエントリです。チェンジセットには、gitのコミットから期待される内容の大部分が格納されます。しかし、gitのコミットがツリーへのポインタを格納するのに対し、チェンジセットは、最初の親からの変更点であるファイルのリストを格納し、1 blobストレージ内の圧縮されたファイル内容へのコンテンツアドレス方式のポインタとともに保持します。チェンジセットはサーバー側で作成され、瞬時にどこからでも利用可能になります。
この構造により、非常に高いスループットでチェンジセットを受け入れることができます。受け入れるべきpackfileがなく、ロックやサーバー間の調整もなく、動かすべきrefもないからです。Scionは技術的にはrefをサポートしていますが、コミットの作成もフェッチもrefを伴わないため、refの移動は単一のSpanner行に対するコンペア・アンド・スワップであり、チェンジセットの作成とは別に行われます。
チェンジセットは変更された内容のみを記録するため、それ単体では、ある行を最後に編集したのは誰か、どのコミットがあるファイルに影響を与えたかといった質問にすぐに答えることはできません。それらに答えるために、Scionはチェンジセットから追加のデータ構造を構築します。これには、ファイルblameとパス履歴のための専用構造や、コミットグラフのためのスキップリストが含まれます。チェンジセットの直接の一部でないすべてを私たちは「派生データ」と呼び、それらすべてを1つの汎用メカニズムを通じて計算します。各種類の派生データは再帰的に定義されるため、あるチェンジセットに対するその値は、そのチェンジセットの親に対する値から計算されます。
このメカニズムには3つの利点があります。第一に、新しいデータ構造が何らかの操作を高速化する場合に、新しい種類の派生データを簡単に追加できます。第二に、種類ごとに、即時に計算するか作業を先送りするかを選択できるため、必要のないデータを実体化することを避けられます。第三に、クライアントはこれらのデータ構造の内部を決して見ないため、クライアントを変更せずに最適化できます。システムの成長に伴い、コピーチェックの実行やパスベースのファイル検索のための新しいインデックスなど、新しい種類の派生データを何度も追加してきました。
Scionのスケーリング
少数のScionサーバーのフリートが、チェンジセットの取得、diffの計算、マージベースの検索、blobのフェッチなど、クライアントが必要とするあらゆる操作のためのソースコントロールAPIを提供します。すべてのソースコントロールデータはコンテンツアドレス方式であるため、データは一度保存されると決して変更されず、どのサーバーも他のサーバーに確認することなくキャッシュできます。その結果、サーバーは水平方向にスケーラブルで、ほとんど調整を必要としません。それらは本質的に大きなキャッシュであり、派生データをその場で計算し、その結果をSpannerに書き戻すこともできます。
Scionの多数のユーザーは、もはや各自でローカルリポジトリを維持する必要がありません。リポジトリの取得と維持は、CIジョブやソース管理に質問(特にコミットの祖先関係やblameに関する質問)を行う必要のあるツールにとって、大きな保守負担でした。移行の初期段階では、独自のクライアント、リポジトリ形式、プロトコルが存在する前は、Scionはこれらの「メタデータ」クエリにのみ答えていました。ファイル内容の取得やワーキングコピーの実体化は、はるかにデータ集約的な操作であり、独自の設計が必要でした。
Scionのscnクライアントは、いくつかの重要な点でgitのフェッチプロトコルとは異なっており、その結果、gitサーバーよりも大幅に少ないCPUで済む、高度にスケーラブルなアーキテクチャを実現しています。Scionのネゴシエーションは、クライアントが既に持っているものをサーバーに伝えません。代わりに、クライアントが欲しいツリーとブロブのみを扱います。ルートツリーから開始して、クライアントはローカルストアに欠けているツリーを確認し、それらを再帰的に要求します。その後、ブロブについても同じプロセスを繰り返します。すべての要求は決して変化しない特定のオブジェクトに対するものであるため、どのキャッシュでも応答でき、このアーキテクチャは従来型の階層化キャッシュに酷似しています。単一の数ギガバイトのpackfile応答が存在しないため、このプロセスは効率的であり、再開も可能です。スパースチェックアウトや仮想化されたチェックアウトであっても、クライアントは不要なツリーを単に要求しないだけで、特別なサポートを必要としません。
本番環境では、クライアントはソケット経由でデーモンであるscion-daemonと通信し、このデーモンがノード全体のオブジェクトを保存します。当社のノードの大部分はmonorepoへのアクセスを必要とし、同一ノード上のジョブはほとんどの同一オブジェクトを再利用します。各デーモンは定期的に更新されるスナップショットから開始し、その後は自リージョンのツリーおよびブロブキャッシュサーバーであるscion-cacheとのみ通信します。これらのキャッシュサーバーは、デーモンが消費するディスク形式で、メモリから直接オブジェクトをストリーミングするため、クライアントに不足しているオブジェクトの計算や差分圧縮の実行に時間をかける必要がありません。キャッシュにオブジェクトがない場合、必要に応じてSpannerやクラウドストレージから読み取る権威あるscion-serverに問い合わせます。
scion-daemon、scion-cache、scion-serverはすべて、このプロトコルに対して同一のRPCに応答するため、クライアントはキャッシュトポロジーを知る必要がありません。理論上はどの階層も他の階層と通信できますが、障害ドメインを分離するために、私たちは階層化を厳格に強制しています。リージョナルなscion-cacheの障害が上流のscion-serverを圧倒し、システム全体をダウンさせるような状況は避けたいと考えています。
このシステムの各階層は99%を超えるキャッシュヒット率を維持し、長期的な状態を必要としないため、必要に応じて容易にスケールアップできます。当社のScionインフラストラクチャのフットプリントは、CPUおよびメモリ要件の面で、以前のgitミラーリングインフラストラクチャより200分の1になりました。CIおよび研究ジョブは2桁速く(数分ではなく数秒で)コードをチェックアウトするようになり、これによりフリート全体で相当量のキャパシティが解放されました。CIだけでCPUキャパシティが25%改善されました。クライアントもキャッシュもリポジトリのメンテナンスを行う必要がなく、ジョブのライフサイクル管理が簡素化されます。
Scion開発で学んだこと
私たちはScionの開発を、 Claude Mythos Preview および Claude Tag が社内で利用可能になったのとほぼ同時期に開始しました。これら両方のリリースは、Scionへの需要を高めると同時に、 開発速度を大幅に加速させました。
特に印象的な例を紹介します。年初、私たちはgitからScionへの取り込みパイプラインの初版をほぼ手作業でプロトタイプとして書いていました。それを良い出来だと思っていましたが、Claude Mythos Previewの初期の社内スナップショットを手にして考えが変わりました。私たちはこのツールに全体を書き直すよう依頼しましたが、追加の指示は一切与えないまま、取り込み順序やデータ構造に関する暗黙の不変条件をすべて保持しつつ、メモリ消費量が20分の1、速度が4倍のバージョンを生成しました。
Scionの構築と運用を通じて学んだことは、エージェント規模のソフトウェア構築がどのようなものになり得るかについて、興味深い教訓を与えてくれます。
少数チームによる迅速な開発が、より一般的になるでしょう。 7人のチームがScionと 、 Antique(当社のコードレビューツールで、これだけで別のブログ記事が書けるほどです)の両方を構築しただけでなく、関連する6つ以上のシステムも作成し、5か月で完全に移行を完了しました。1日あたりのマージされるコード量が10倍に増加する中で、これをすべて成し遂げました。かつては、このようなソース管理システムの開発と展開には、より多くのエンジニアによる数年間の反復的な移行が必要でした。私たちは、このような迅速で機動力のある移行が今後より一般的になると考えています。
エンジニアの価値が下がるわけではありませんが、彼らの仕事は変化しつつあります。 このシステムに取り組んだエンジニア全員が、今ではClaudeの方が自分たちよりも優れていると評価するでしょう。それは コードを書く 能力においてです。しかし、当社のエンジニアは依然として、システム間の高レベルなコンポーネントや設計レベルのトレードオフに関する貴重な理解を提供し、解決すべき問題や達成すべき規模について情報に基づいた選択を行いました。多くの場合、エンジニアの役割はClaudeに「ノー」と言うことでした。エージェントは、そもそも許されるべきではなかったパターンを満たすために、システムの中核的な制約を破ることがあります。これは移行作業において特に多く見られました。例えば、mainブランチへの変更のマージ時期を、コードレビューツールに問い合わせるのではなく、コミットログを線形に読んで総当たり的に調べようとしたシステムが複数ありました。Anthropicでは敵対的レビューも広く活用していますが、これは多くの点で非常に効果的である一方、近視眼的になることもあります。そのため、熟練したエンジニアは、仮説上の懸念に対応してシステムの一部を過剰に設計しすぎないよう、Claudeを導く必要がありました。例えば、あるレビューでは別の内部サービスを信頼することについて過度に防御的であり、その結果、Claudeが過剰な検証と複雑さを追加してしまいました。チームメンバーは依然としてシステムへのすべての変更リクエストをレビューしますが、現在ではコードの一行一行を読むのではなく、変更の 意図 を確認するようになっています。
最適化と品質を大幅に改善できました。 Claudeが自分たちでは不可能な速度で膨大な量のコードを書けるおかげで、Scionは私たちがこれまで取り組んできた中で最もテストが行き届き、防御が堅牢なコードベースの一つとなっています。厳しいタイムラインの中でも、これまでに遭遇したすべての自明でないインフラおよびソース管理のインタラクションについて完全に閉じたシミュレーションを構築できただけでなく、ファジングや高度なレート制限も実装できました。さらに、Claudeは重要な最適化を偶然にも発見しました。例えば、私たちのインデックスの一つを見逃していた祖先クエリに対するアルゴリズム的な最適化であり、専門家であれば数日から数週間の分析と調整を要したであろうものでした。そして翌日にはまた同じことをやってのけました。
新しい形のモノレポセキュリティの基盤を築きました。 大規模なモノレポにおいて安全性、セキュリティ、コンプライアンスを管理することは、サイズと規模の管理と同じくらい重要です。私たちはScionを最初からこれらを念頭に置いて構築しました。Scionはリポジトリに対する豊富なアクセス制御をサポートし、個々のディレクトリに権限を適用できるため、モノレポの利点を失うことなく最も機密性の高いコードを保護できます。さらに、構築したコードレビューツールは承認に対する複雑なセマンティックな制約を表現できるため、コメントのみの変更といった単純なものと機密性の高い論理的変更を区別でき、人間のレビュアーが最も影響の大きい変更に集中できるようになっています。
新たなレベルの運用の卓越性が可能になりました。 私たちのチームはClaude Tagを多用しており、システムの各コンポーネントの監視に役立っています。例えば、単一のコンポーネントの健全性に執着的に集中するようClaudeに任務を与えたSlackチャンネルを作成しました。私たちはこれらのClaudeを「スーパーファン」と呼んでいます。scion-daemonのスーパーファン、scion-cacheのスーパーファン、Antiqueマージキューのスーパーファンなどがあります。彼らはテレメトリとログにアクセスでき、チャートを更新して異常なものを探すこと以外にやるべきことがない熟練エンジニアのように振る舞います。すべてのシステムには従来型のアラートもありますが、スーパーファンは、従来のアラートが一面的に見えるほど微妙で新しい問題を検出できます。
私たちは自分たちの前提を完全に見直しています。 このプロジェクトにより、人間の規模向けに設計された他のワークフローを厳しく見直すことになりました。例えば、適切なマージキューは、エージェントの規模ではあまり意味をなしません。テストの実行中に何百、何千もの変更がマージされ得る場合、CIとはそもそも何を意味するのでしょうか？私たちはマージキューに対するグローバルなリポジトリロックという業界標準を効果的に再現できなかったため、代わりにマージ後とデプロイ前の自動テストに投資しました。これは並行する変更が競合する可能性があることを意味しますが、Claudeは通常、人間が競合を特定することすらできるより速くそれらを修正できます。
より広いエコシステムへの貢献
私たちは、ますます能力が高まるAIエージェントが提起しているスケーリングの懸念に対する答えの一つとして、Scionを捉えています。これらの詳細は、チームが同様の課題に取り組む方法の一例として共有するものですが、私たちのソリューションや考慮事項がすべてのケースに適合するとは期待していません。
Scionは、一般的な用途においてgitの適切な代替となるものでは決してありません。ここで概説した概念が真に意味を持つのは、数万人のエンジニアまたは活発にコードを書くエージェントの群れを擁する、文字通り巨大なモノレポにおいてのみです。さらに、Anthropicは、内部利用のためにトークンに費やせる額が、他のどの企業が現実的に費やしたいと思う額をもはるかに上回るという点でユニークです。私たちはこれを、自社のソフトウェア開発のニーズに対応するためと、Claudeの能力を試すための両方の目的で行っています。
実際のところ、他の組織にとって広く有用な形でScionを提供することは困難です。Scionはgitから大きく逸脱しているため、企業は開発ライフサイクルのすべての部分を移行する必要があり、独自のコードレビュー、コード検索、CIを必要とします。これらのコンポーネントの内部バージョンは高度に特化して作られているため、他の組織が採用するのは困難でしょうし、全員を満足させようとする公開版を構築しようとしても、実際にはあまり有用ではないと私たちは懸念しています。
しかしながら、この種の問題は今後6〜12か月のうちにさらに一般的になると予想しています。gitを使用するすべての企業が同様の課題に単独で直面するのは、エンジニアリングリソースの非効率な使い方です。そうであるならば、私たちにできる最も影響力の大きい ことは、私たちの考えを共有することだと考えています。そうすることで、他の開発者が全体的なモデルから離れることなく、Scionの最も成功した部分をgitに適用できるようになります。gitサーバーはgitクライアントと同じように動作する必要はありません。大幅なスケーリング改善をもたらす新しいサーバーアーキテクチャが存在します。gitプラットフォームは、Scionのような包括的なサーバー側RPCを提供できます。gitクライアントが対話方法を学べるよう、 forge間で標準化された形にすることすら可能でしょう。ネゴシエーションプロトコルも現在とまったく同じ形である必要はなく、gitの various なスパースおよびシャロー機能はうまく組み合わせられるようにできます。
最後に、gitコミュニティが約20年もの間、数百万の開発者向けにこのプラットフォームをスケールさせてきたことを認めたいと思います。私たちの貢献ははるかに限定的なものです。それは、GitHub、GitLab、OSSコミュニティと協力して開発者の変化するニーズを支えられるよう、エージェントによるソフトウェア開発がこれらのシステムとどう相互作用するかについての初期の見解を共有することです。ソフトウェア開発ライフサイクルがAIの指数的成長と交わる今、私たちは皆、同じ船に乗っています。
脚注
01マージの第一の親を基準に変更されたファイルを保存することはスタイル上の選択です。実際には、モノレポにおけるトランクベース開発では、人々はメインライン上のコミットの履歴やblameのみを気にすることがわかっています。
02具体的には、Saplingのサーバーコンポーネントである Mononokeです。これは、私たちがScionで使用している多くの技法、特に Bonsai データモデルを先駆けて実装しました。
著者および謝辞
謝辞
Nick G.およびソースコントロールチーム(S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.)により執筆されました。この野心的な旅においてソースコントロールチームを支えてくれたVilas J.とSergiu D.、そしてAntiqueへの初期の貢献をしてくれたAmir O.に感謝します。