Anthropicにおけるソース管理の再設計

Anthropicでは、コーディングがシステム構築や研究開発のボトルネックではなくなりました。Claudeは、これまで見たことのない速度と規模で、研究ループを自律的に反復処理し、複雑なプログラムをマイクロ最適化し、新しいサービスをゼロから構築することができます。今やボトルネックとなっているのは、ソース管理、ビルド、CIなど、人間規模で構築された開発者インフラストラクチャ全体です。 2026年5月、Anthropicでは1日あたり平均約2,500件のコード変更がマージされていましたが、9月には1日あたり30,000件を超えました。この成長率は当面鈍化するとは予想しておらず、コードマージの潜在的な需要は事実上無限であり、取り除くボトルネックごとに生産されるコード量がさらに増加しています。 この成長をサポートするため、私たちは社内バージョン管理システムであるScionを構築し、5ヶ月でモノレポ全体をGitから移行しました。また、コードレビューインターフェース（Antiqueと呼ばれる）、コード検索、リッチなソース管理IAMシステム、大量のレビュー済みコードを管理・適用するための新しい方法なども、すべて同じ期間に構築・リリースしました。この記事では、特にScionの構築方法に焦点を当てます。これは興味深いケーススタディとなります。Claudeのコード記述能力は、私たちをこの状況に陥れた原因であると同時に、それに対処するための高品質でスケーラブルなシステムを迅速に構築できた方法でもあります。 モノレポの成長 構築したものについて掘り下げる前に、私たちのワークロードがいかに異常であるかを認識する必要があります。驚くことではありませんが、Anthropicは他のほとんどの企業よりもはるかに多くのソフトウェアをClaudeに書かせており、人間規模で構築されたツールの限界が見え始める最初の企業であることがよくあります。ソース管理はその一例にすぎません。多くの組織が近い将来これらの問題を抱えるとは予想していませんが、AIコーディングツールを使用する他の企業も同様のプレッシャーポイントを経験するようになるのは時間の問題だと考えており、私たちが構築したものと学んだことを共有したいと思いました。 Gitは分散システムです。各クローンは完全で自己完結型のレポジトリであり、差分を計算し、履歴やblameを読み取り、完全にオフラインで任意のバージョンをチェックアウトできます。ほとんどのレポジトリにとって、これは正しい設計であり、Gitが標準になった大きな理由の一部です。 私たちのモノレポが成長するにつれて、この設計空間にはますます適合しなくなってきました。メインブランチの履歴だけでも約100GBあり、圧縮されたワーキングコピーは25GBを超えます。開発者環境、エージェントサンドボックス、研究ジョブを考慮しない場合でも、CIのために1日あたり約2,500万回のコードチェックアウトを実行します。これを単純に取得すると、1日あたり600PBのGitトラフィックが発生することになります。 Gitは、シャロークローン、スパースチェックアウト、プロミサーリモートなど、レポジトリの一部を操作するためのツールを提供します。これら以外にも、内部Gitミラーやブロブストレージに保持されるレポジトリのスナップショット（シード）など、大規模モノレポのための標準的な回避策があります。私たちはこれらすべてを使用してきました。ピーク時には、負荷に対処するために数百の内部Gitミラーを運用していました。これにより時間稼ぎはできましたが、マージレートが増加するにつれて運用が困難になりました。シードはリフレッシュの間隔が長くなり、差分やblameのような履歴に依存する操作を部分的なクローンで機能させるためには、ますます注意が必要になりました。 Gitチェックアウトのスケーリングのための典型的なセットアップ。 一歩引いてみると、ほとんどの企業と同様に、私たちはGitを単一の権威あるコピーを持つ中央集権的なシステムとして使用していましたが、クライアントのほぼすべては定義上オンラインであるエージェントやジョブでした。Gitを分散型オフライン作業に優れさせている特性は、レポジトリが成長するにつれてスケーリング能力を積極的に損なっていました。そこで私たちは自問しました。エージェントが常にオンラインであることを最初から念頭に置いてソース管理を設計したら、それはどのようなものになるだろうか？ エージェントスケールのソース管理のための原則 エージェントコーディングでは、ソフトウェア開発の方法に関する多くの一般的な仮定が進化しています。Scionを構築する際にこれらの変化を受け入れたことで、いくつかのコア原則においてGitとは根本的に異なるアプローチを取ることができました。巨大なモノレポのためのソース管理には、GoogleのPiperやMetaのSaplingなど、先行事例があります。そのため、それらの苦労して得た教訓を念頭に置いてScionを構築することができました。私たちの原則は以下の通りです。 クライアントは常にオンラインであること。Gitはクライアントがオフラインで作業し、レポジトリの完全なコピーを必要とすると仮定しています。私たちのクライアントのほぼすべてがエージェントやジョブであるため、Scionのクライアントとプロトコルは、常に到達可能なサーバーを中心に設計されており、クライアントは必要に応じてデータを取得します。 クライアント・サーバーの非対称性。Gitでは、すべてのクライアントが本格的なサーバーになる能力を持っています。Scionでは、サーバーがファイル履歴やblameに関する質問に答え、コミットを作成し、マージやリベースなどを実行します。クライアントは、限られたローカルオブジェクトキャッシュを維持し、ディスク上にワーキングコピーファイルを配置し、ファイルシステムの変更を監視し、ユーザーがサーバーを操作するための人間工学的な方法を提供します。クライアントは自分で計算できることはほとんどありませんが、その引き換えに、ローカルに必要なデータははるかに少なくなります。 包括的なソース管理サービスは、多くの新しいアプリケーションを強化できます。Gitでは、誰が最後にラインを変更したか、または2つのコミットがどのように関連しているかなど、レポジトリに関する質問をする必要があるCIジョブやツールは、ローカルコピーを維持するか、ベンダー固有のAPIが回答を提供することを期待する必要があります。Scionでは、クライアントが使用するすべてのソース管理クエリはAPI経由でも公開されているため、多くの場合、ジョブはローカルレポジトリをまったく必要としません。自動化されたbisectおよびrevertパイプラインなど、多くの内部ツールは、ソース管理へのこのような安価でプログラム可能なアクセスなしには、スケーラブルに実用的ではありません。 すべてが水平スケーラブルである必要があること。ピーク時には、数百のGitミラーを運用していましたが、これは容量に著しく負荷をかけ、レポジトリがミラーのディスクやメモリ制限を超えるとスケーリングしなくなりました。Scionでは、レポジトリのデータは分散されており、すべてのコンポーネントは独立してスケーラブルです。サーバー上であっても、レポジトリの完全に具現化されたコピーはどこにもありません。packfile（Gitの圧縮されたオブジェクトバンドル）に相当するものはないため、レポジトリのメンテナンスは不要です。 コミットは安価で、増分的で、ロックフリーであること。Gitでは、ローカルでコミットしてからプッシュして作業を共有します。Scionでは、すべてのコミット、リベース、またはマージはサーバー上で行われるため、プッシュするものはありませんが、これらの各操作は高速である必要があります。コミットを作成し、その下流のデータ構造を更新するコストは、レポジトリ全体のサイズではなく、変更のサイズに応じてスケーリングする必要があります。そうしないと、サーバーが追いつけなくなります。Scionの開発ライフサイクルでは、グローバルな状態（すべてのサーバーが合意する必要がある）は、メインリファレンスまたはリリースブランチを除き、スケーリングの問題となるため、リファレンス（ブランチやタグなど、コミットへのポインタ）は推奨されません。 ワーキングコピーはオプションであり、設計上スパースであること。私たちのモノレポは非常に大きいため、またCIのために1日に数千万回もコードをチェックアウトするため、可能な限りチェックアウトを避けたいと考えていました。Scionでは、例えばコミットとそのマージベースとの差分を必要とするCIジョブは、サーバーにそれを要求できます。書き込みも同様です。多くの書き込みワークロードは、チェックアウトをスキップして完全にAPI経由で機能させることもできます。Scionのプロトコルは、クライアントが要求したディレクトリのみを含むスパースチェックアウトと、オンデマンドでファイルを具現化する仮想化チェックアウトを中心に構成されているため、ジョブがディスク上のファイルを実際に必要とする場合、クライアントは実際に読み取ったものに対してのみ料金を支払います。 Scionの仕組み これらの原則がScionの構築においてどのように組み合わされたかを理解することは役立ちます。これらの洞察は、他のソース管理システム、またはより広くはソフトウェア開発ライフサイクルの他の段階に適用できます。 データ構造 Scionでは、作業の単位は「変更セット」であり、ライトアヘッドログのエントリです。変更セットは、Gitのコミットで期待されるほとんどのものを格納します。しかし、Gitのコミットが