Anthropicが社内のソース管理を「Scion」に作り直した理由　1日3万件のマージ

米Anthropicは10月13日、自社のエンジニアリングの技術記事で、社内のモノレポをgitから自前のバージョン管理システム「Scion」へ5か月で移したと公表した（15日に追記）。理由は、エージェントがコードを書く速さに、人の規模で作った開発基盤が追いつかなくなったことにある。1日にマージされる変更が5月の約2500件から9月には3万件を超え、各所に全体を複製するgitの前提ではミラーとCIの負荷を支えられなくなった。数字はいずれも同社の自己申告だ。

gitをやめて自前の仕組みに移した

Anthropicの技術記事「Redesigning source control at Anthropic」によると、ボトルネックはもうコードを書くことではなく、ソース管理やビルドやCIのように人の規模を前提に作った開発基盤にある。そこで同社はScionを作り、モノレポをgitから移し終えた。ほかに、承認の条件を細かく書けるコードレビューの画面「Antique」とコード検索、ディレクトリ単位の権限を扱うIAMも作った。ScionとAntiqueを作ったのは7人のチームだという。

着手の時期は、社内でClaude Mythos Previewと「Claude Tag」が使えるようになった頃と重なる。Claude Tagは、Slackのチャンネルでタグを付けてClaudeに作業を頼むチーム向けの機能で、同社は6月23日の発表でベータとして公開した。技術記事は、この2つが同時にScionの必要性を一段と高めたと書く。

設計の手本として、記事はGoogleのPiperとMetaのSaplingを挙げる。特にSaplingのサーバー部分「Mononoke」のデータモデルから多くを借りたという。MononokeはGitHubのREADMEで、数百万のファイルに毎時数千のコミットが入る規模を想定したサーバーと説明されている。

CIの取得が数分から数秒になった

技術記事によるとmainの履歴だけで約100GB、圧縮した作業コピーでも25GBを超える。CIだけで1日に約2500万回のチェックアウトがあり、素直にgitで取れば1日600PBを超える通信になる計算だった。同社は最盛期に数百の社内gitミラーで負荷をさばいたが、マージの数が増えるほど運用は難しくなった。リポジトリがミラーのディスクやメモリの上限を超えると、この構成は規模に追いつかなくなり、配る種のコピーも更新の合間にmainの先端から遅れていった。gitはオフラインで作業する人を前提にしているが、Anthropicのクライアントはほぼすべてが常時つながったエージェントとジョブだった。

Scionは、この前提を逆にした。履歴とblameとコミットの作成、マージやリベースはサーバーが受け持ち、クライアントは上限のあるキャッシュと作業コピーだけを持つ。クライアントが使う問い合わせはAPIでも開いているので、CIのジョブはコミットとマージベースの差分をサーバーに尋ねればよく、多くの場合ローカルのリポジトリが要らない。作業コピーも頼んだディレクトリだけを置く方式と、ファイルを開いた時に取り出す仮想の方式を選べる。全サーバーが合意するグローバルな状態は今後の規模の問題になり得るとして、mainとリリースのブランチ以外のrefは勧めない設計にした。ref自体は技術的には使える。

データの単位は「changeset」で、最初の親からの変更ファイルの一覧を持つ。blameやパスの履歴は、親の値から順に求める派生データとして計算する。配信はノードごとのscion-daemon、地域ごとのscion-cache、Spannerとブロブストレージを読むscion-serverの3段で、各段のキャッシュのヒット率は99%を超えるという。

成果として記事が挙げるのは、gitミラーの構成に比べてCPUとメモリで約200分の1のインフラの規模、数分から数秒になったCIと研究用のチェックアウト、CIのCPUの容量の25%の余裕だ。どれも同社の自己申告の値で、測り方の詳細は書かれていない。

汎用のgitの代わりではない

技術記事は、Scionは一般の用途でgitの代わりになるものでは全くないと明言している。合うのは非常に大きなモノレポだけで、導入には開発の流れ全体を移す必要がある。社内の構成要素も独自性が強く、他の組織が採り入れるのは難しいという。同社は代わりに考え方を共有したいと書く。

うまく再現できなかった仕組みもある。業界で標準のマージキューは、リポジトリ全体のロックで変更を1つずつ入れるが、同社はこれをうまく再現できていないと書く。代わりにマージ後とデプロイ前の自動テストに投資した。同時に入った変更がぶつかることはあるものの、人が衝突に気づくより速くClaudeがたいてい直せるという。

書く速さの外に詰まりがある

人の仕事の中身も変わったと技術記事は書く。レビューはすべての行を読むより変更の意図を見る形に移り、Antiqueではコメントだけの変更と重要なロジックの変更で承認の条件を分けられる。エンジニアは、Claudeの方がコードを書くのはうまいと評価しつつ、仕組みの制約を破る提案に「いいえ」と言う役が多かったという。運用ではSlackのチャンネルごとに1つの部品の健全さだけを見張るClaudeを置き、「superfan」と呼んでいる。通常のアラートでは捉えにくい細かな異常に気づけるという。Mythosが書き直した取り込みのパイプラインは、メモリが20分の1、速さが4倍になった。

社外に向けては、gitのホスティングがScionのようなサーバー側のRPCを広く用意し、できればフォージの間で標準にできると書く。gitの全体の形を変えずに、Scionのうまくいった部分をgitに当てはめる道もあるという。エージェントが1日3万件を超える変更を入れる規模では、詰まりはコードを書く速さではなく、手元に全体を複製する前提のソース管理とCIにあった。

編集部の見方

編集部は、この記事で読むべきなのはScionという製品ではなく、全体を手元に複製しないCIの組み方だと見る。AnthropicはScionを一般の用途には向かないと自ら書き、gitのホスティングがサーバー側のRPCを揃えることに期待を寄せている。差分をサーバーに尋ねて必要なディレクトリだけを置くCIは、そうしたRPCがホスティング側に揃えばgitのままでも近づけると編集部は読む。エージェントの並列作業を増やすチームは、1日のチェックアウトの回数と1回の取得時間をまず測るとよい。200分の1や25%は社内の自己申告で、規模の小さいリポジトリで同じ差が出るかは分からない。