AnthropicのScion — 1日3万マージ超でgitから移行した経緯

Anthropicは、モノレポに入るコード変更の数が2026年5月の1日約2,500件から9月には3万件超へ増えたため、gitを離れて自社製のバージョン管理システム「Scion」へ5か月で移行しました。2026年10月13日付のエンジニアリングブログが、その設計と得られた数字を説明しています。

Scionは社内ツールで、Anthropicは他社が広く使える形で提供するのは難しいとしています。それでも、gitの前提のどこが先に壊れ、何に置き換えたのかは、エージェントにコードを書かせる開発が広がる組織にとって参考になる情報です。

1日2,500件が3万件超に — 詰まったのは書く工程ではなかった

出発点は、コードを書くことがもうボトルネックではない、という認識です。Claudeが研究のループを自律的に回し、複雑なプログラムを微調整し、新しいサービスを一から作る速度に対して、人のスケールで作られた周辺の基盤が追いつかなくなりました。名指しされているのはソース管理、ビルド、CIの3つです。

数字

Scionの規模と効果

• 1日のマージ数

  約2,500→3万超

  2026年5月の平均から9月へ

• インフラの大きさ

  1/200

  従来のgitミラー構成と比べたCPU・メモリ

• CIのCPU容量

  25%改善

  チェックアウトの高速化で生まれた余力

• 各層のキャッシュヒット率

  99%超

  Scionのチェックアウト構成

マージ数の増加は10倍超です。Anthropicは伸びがすぐに鈍るとは見ていません。マージしたいコードの潜在的な需要は実質的に無限で、ボトルネックを1つ取り除くたびに生成されるコードがさらに増えると見ています。

CI側で同じ時期に起きた詰まりは、テスト影響分析がCI負荷25倍で限界に — Anthropicの作り直しに詳しくあります。ソース管理の話は、同じ時期にその手前の工程で起きた圧力にあたります。

gitの設計は、このモノレポのどこで合わなくなったか

gitは分散型で、すべてのクローンが完結したリポジトリです。差分も履歴もblameも、オフラインで任意のリビジョンのチェックアウトまで手元でこなせます。多くのリポジトリにとっては正しい設計で、gitが標準になった大きな理由でもあります。

Anthropicのモノレポは、その設計の想定から外れていきました。

• mainブランチの履歴だけで約100GB
• 圧縮した作業コピーは25GB超
• CI向けのコードのチェックアウトが1日に約2,500万回(開発環境、エージェントのサンドボックス、研究ジョブは別枠)
• すべてを素直に取得すると、1日のgit通信量は600PB超

既存の対処はすべて試されています。シャロークローン、スパースチェックアウト、promisor remoteといったgit標準の部分取得に加え、社内gitミラーと、blobストレージに置いたリポジトリのスナップショット(seed)です。ピーク時には数百台のgitミラーを運用していました。

時間は稼げたものの、マージ速度が上がるほど運用が重くなりました。seedは更新の合間にmainの先頭から遠ざかり、部分クローン上でdiffやblameのような履歴依存の操作を動かし続けるには、手間が増える一方でした。

ここで前提が見直されました。gitを「正本が1つの集中型」として使っているのに、クライアントの大半はエージェントやジョブで、定義上つねにオンラインです。オフラインでも使える分散設計の性質が、規模を伸ばす妨げに回っていました。そこから、エージェントは常時オンラインだと最初から決めて設計したら、ソース管理はどうなるか、という問いに進みます。

Scionの5原則 — gitと何が違うのか

大規模モノレポ向けのソース管理には先行例があります。GoogleのPiperとMetaのSaplingがそれで、Scionはその教訓を踏まえて設計されました。原則は次の5つです。

クライアントを薄くすると、サーバーのAPIが使える

サーバー側がすべての問い合わせに答えるので、クライアントが使うソース管理の問い合わせはAPIとしても公開されています。誰がこの行を最後に変更したか、2つのコミットの関係はどうか、といった質問のために、CIジョブがリポジトリのコピーを持つ必要は、多くの場合なくなります。

自動bisectや自動revertのパイプラインのような社内ツールは、このAPIの安さがなければ大規模には成り立ちませんでした。

コミットのコストを変更の大きさに比例させる

Scionでは、コミット、リベース、マージがすべてサーバーで起きます。そのため各操作の速さが要ります。コミットを作って下流のデータ構造を更新するコストは、リポジトリ全体ではなく変更の大きさに比例させる必要があります。

ブランチやタグのようなref(コミットへのポインタ)は、mainとリリースブランチを除いて開発ライフサイクルで推奨されません。全サーバーが合意しなければならないグローバルな状態は、いずれスケールの問題になるからです。

changesetと派生データ — 履歴を「差分のログ」にする

Scionの作業単位は「changeset」で、先行書き込みログ(write-ahead log)の1エントリです。gitのコミットがツリーへのポインタを持つのに対し、changesetは最初の親に対して変更されたファイルの一覧と、blobストレージ内の圧縮済みファイル内容へのコンテンツアドレス方式のポインタを持ちます。サーバー側で作られ、作成の直後にあらゆる場所で使えます。

最初の親に対する差分だけを持つのは設計上の選択です。トランクベースで運用するモノレポでは、実際に履歴やblameが必要になるのはメインライン上のコミットだけだと分かったから、と説明されています。

この構造でスループットが稼げるのは、受け付ける対象にpackfileがなく、ロックもサーバー間の調整もなく、動かすrefもないからです。refはScionにも技術的にはありますが、コミットの作成にも取得にも関わりません。refを動かすのは、Spannerの1行に対するcompare-and-swapで、changesetの作成とは別に行われます。

changesetは変更点しか持たないため、誰がこの行を最後に編集したか、どのコミットがこのファイルに触れたかには単独ではすぐには答えられません。そこで、changesetから追加のデータ構造を作ります。blame用、パス履歴用、コミットグラフのスキップリストなどです。changesetそのもの以外をまとめて「派生データ」と呼び、1つの汎用的な仕組みで計算します。

派生データの種類ごとに、changesetの値はその親の値から再帰的に求められます。この仕組みには3つの利点があります。

1. 操作を速くするデータ構造が見つかれば、新しい種類をすぐ足せる
2. 種類ごとに、先に計算するか後回しにするかを選べるので、不要なデータは作らずに済む
3. クライアントは内部構造を見ないので、クライアントを変えずに最適化できる

コピー検出用や、パスによるファイル検索用の索引も、システムが育つなかで後から足されています。

チェックアウトを3層のキャッシュで配る

Scionのサーバー群は、changesetの取得、diffの計算、マージベースの探索、blobの取得といった操作をAPIで提供します。ソース管理のデータはすべてコンテンツアドレス方式で、一度保存されたデータは変わりません。どのサーバーも他のサーバーに確認せずキャッシュできるため、サーバーは大きなキャッシュとして動き、必要なら派生データをその場で計算してSpannerに書き戻します。

移行の初期、自前のクライアントもリポジトリ形式もプロトコルもなかった段階では、Scionが答えるのはメタデータの問い合わせだけでした。ファイルの内容の取得と作業コピーの実体化はデータ量が桁違いなので、別の設計が必要になりました。

Scionのクライアント(scn)は、gitのfetchプロトコルから意図的に離れています。交渉でクライアントが持っているものをサーバーに伝えることはせず、欲しいツリーとblobだけを扱います。

手順

Scionのチェックアウトでデータが流れる順番

1. 1

   scnがルートツリーから欠けた分を要求する

   クライアントはローカルのストアを調べ、足りないツリーを再帰的に要求します。続けてblobでも同じ処理を行います。要求は変化しない特定のオブジェクトに対するものなので、どのキャッシュでも応答できます。

2. 2

   ノード単位のscion-daemonが受ける

   クライアントはソケット経由で、ノード全体のオブジェクトを保管するscion-daemonに話しかけます。同じノードのジョブは、ほとんど同じオブジェクトを再利用します。daemonは定期的に更新されるスナップショットから始まります。

3. 3

   地域のscion-cacheが返す

   daemonが話すのは、同じ地域のツリー用・blob用キャッシュサーバー(scion-cache)だけです。キャッシュはdaemonがそのまま使えるディスク形式のオブジェクトを、メモリから直接流します。足りないオブジェクトを計算したり、差分圧縮をかけたりはしません。

4. 4

   なければ権威のscion-serverへ

   キャッシュに無いオブジェクトは、権威を持つscion-serverに問い合わせます。サーバーは必要に応じてSpannerやクラウドストレージから読みます。

この構成の特徴は、巨大なpackfileの応答がないことです。処理は効率的で、途中から再開できます。スパースチェックアウトや仮想化チェックアウトにも特別な対応は要らず、クライアントが要らないツリーを要求しないだけで済みます。

scion-daemon、scion-cache、scion-serverは、このプロトコルで同一のRPCに答えます。クライアントはキャッシュの階層を知る必要がありません。理論上はどの層も他のどの層と話せますが、障害の影響範囲を分けるため、階層の順守を強制しています。地域のキャッシュの障害が上流のサーバーを圧迫し、システム全体を止める事態を避けるためです。

各層は長期保持の状態を持たないため、必要なら容易に拡張できます。

数字をどう読むか — 200分の1と25%の中身

成果は次のとおりです。

• 200分の1は、Scionのインフラを従来のgitミラー構成と比べたときの、CPUとメモリの要件の比
• CIや研究ジョブのコードのチェックアウトは2桁速くなり、分単位だった時間が秒単位になった
• 25%は、その高速化によってCIだけでCPU容量が改善した幅(フリート全体でも容量が空いた)
• クライアントにもキャッシュにもリポジトリのメンテナンスが要らなくなり、ジョブのライフサイクル管理が簡単になった

読むときの注意が2点あります。1つ目は、比較対象が同社自身の数百台規模のgitミラー構成だという点です。ミラーを大量に抱えるほど膨らむ構成との比較なので、一般的なgitサーバーに対する200分の1ではありません。2つ目は、計測条件の内訳が載っていない点です。数字は、このモノレポの規模と使い方のもとでの報告です。

もう1つ、数字として出ているのがgit-to-Scionの取り込みパイプラインです。最初の実装は、ほぼ手書きのプロトタイプでした。社内で早期のClaude Mythos Previewのスナップショットが使えるようになってから書き直しを頼むと、追加の指示なしで、メモリ消費が20分の1、速度が4倍の実装が返ってきました。取り込み順序とデータ構造に関する暗黙の不変条件も保たれていました。

7人で5か月 — Claudeが書き、人が「だめだ」と言う

Scionと、コードレビューの画面(Antique)と、関連する6つほどのシステムを作り、移行まで終えたのは7人のチームです。その間にマージ量は10倍に増えました。これまでなら数年と多数のエンジニアが要った作業です。開発の開始時期は、社内でClaude Mythos PreviewとClaude Tagが使えるようになった頃と重なり、両者はScionの必要性を高めると同時に、作る速度も上げました。

エンジニアの役目は設計判断と「却下」に寄った

関わったエンジニア全員が、コードを書く力ではClaudeのほうが上だと評価しています。それでもシステム間の高次の構造と、設計上のトレードオフを決めるのは人でした。役割の多くは、Claudeに「いいえ」と言うことです。具体例が2つあります。

• 複数のシステムが、mainにいつマージされたかを、コードレビューツールに尋ねず、コミットログを順に読んで調べようとした。エージェントは、そもそも許してはならないパターンに合わせるため、システムの中核の制約を破ることがある
• 敵対的レビューは効果が高い一方で近視眼的にもなる。あるレビューは別の社内サービスを信用することに過度に慎重で、Claudeが過剰な検証と複雑さを足した

チームは今もScionへのすべての変更要求をレビューします。ただし見る対象はコードの全行ではなく、変更の意図に変わりました。

品質を上げたのも、書く量の多さだった

Scionは、チームが扱ってきたなかで最もよくテストされ、よく守られたコードベースの1つだと評価されています。非自明なインフラとソース管理のやり取りの密閉シミュレーションに加え、ファジングと高度なレート制限まで、短い期間で整いました。インデックスを外していた祖先クエリのアルゴリズム改善のように、専門家が数日から数週間かけて分析・調整する最適化も見つけています。

セキュリティの面では、リポジトリ全体のアクセス制御に加え、ディレクトリ単位の権限も設定でき、機微なコードだけを守ってモノレポの利点を保てます。レビューツールは承認に複雑な意味的制約を課せるため、コメントのみの変更と、ロジックに関わる機微な変更を区別して、人間のレビュアーが重要な変更に集中できるようにしています。

運用はClaude Tagの「superfan」が見張る

Claude Tagは、チームのSlackチャンネルの中で動くClaudeです(公開ベータ)。導入の経緯はClaude Tagが登場 — Slackで@Claudeを呼び出しチームの一員として並行作業を任せる新機能にあります。

このチームは、Slackのチャンネルごとに1つのコンポーネントの健全性だけを執拗に見るClaudeを置き、「superfan」と呼んでいます。scion-daemonのsuperfan、scion-cacheのsuperfan、Antiqueのマージキューのsuperfanなどです。テレメトリとログにアクセスし、グラフを更新し続けて異常を探す、時間のあるベテランエンジニアのように動きます。従来型のアラートも併用していますが、細かく新しい異常はsuperfanのほうが拾えます。

マージキューはエージェント規模で成り立つのか

この投稿でいちばん重い判断は、Scionそのものより、CIの置き方を変えた点にあります。

人の規模で作られた他のワークフローにも、疑いの目が向けられました。たとえばマージキューは、エージェント規模ではあまり意味をなさないと判断されました。テストの実行中に数百から数千の変更がマージされうる状況で、CIは何を意味するのか、という問いです。業界標準のマージキューにおけるグローバルなリポジトリロックは、効果的に再現できませんでした。代わりに、マージ後とデプロイ前の自動テストに投資しています。

その結果、並行する変更同士が衝突することはあります。Claudeは、そうした衝突を人が気づくより速く直せるのが普通だといいます。

この賭けが成り立つ条件は2つあります。衝突を直す速さと、マージ後のテストが壊れた変更をデプロイ前に捕まえる精度です。前者はClaudeの能力に、後者はテスト基盤の厚みにかかっています。Scionのサーバー設計はgitに持ち込めても、マージ前に全部通すというCIの前提を手放す判断は、同じ条件がそろわない組織には移せません。

Scionは汎用のgit代替ではない — 持ち帰れる材料

Scionはgitの汎用的な代替ではありません。意味を持つのは、数万人規模のエンジニアか、コードを大量に書くエージェントの群れが使う、本当に巨大なモノレポに限られます。Anthropicは、内部利用だから成り立つトークン消費量も前提に挙げています。

広く提供するのが難しい理由も具体的です。

• gitと大きく異なるため、導入する会社は開発ライフサイクルの全部品を移行しなければならない
• 専用のコードレビュー、コード検索、CIが必要になる
• 社内版の部品は特注の度合いが強く、万人向けの公開版は役に立たなくなると同社は考えている

代わりに同社が提案するのは、Scionの成功した部分をgitの枠を出ずに生かす道です。

• gitサーバーの構造が、gitクライアントと同じである必要はない。スケールを大きく改善するサーバーアーキテクチャーはある
• gitのプラットフォームが、Scionのようなサーバー側の包括的なRPCを、フォージ(ホスティングサービス)をまたいで標準化した形で提供し、gitクライアントが話せるようになる可能性もある
• 交渉プロトコルは今の形のままである必要はなく、スパースやシャロー機能を組み合わせても動くようにできる

gitのコミュニティは20年近くかけて、数百万人の開発者に向けてgitを育ててきました。Anthropicはそこに敬意を示し、自らの貢献は、エージェントによるソフトウェア開発がこれらのシステムとどう作用するかの初期の見立ての共有に限られるとしています。GitHub、GitLab、OSSコミュニティと協力する意向もあり、この種の問題は今後6〜12か月でより一般的になると見ています。

読者の側で見積もれる目安は、ここまでに出てきた規模です。履歴が約100GB、チェックアウトが1日に数千万回という水準は、多くのチームの現実からは遠い数字です。置き換えの検討が始まったのも、部分取得やミラーといった手前の対処で運用が重くなってからでした。

手元のモノレポでClaude Codeを使う設定は、Claude Codeのモノレポ運用ガイドが扱っています。

まとめ

Scionの教訓は、ツールの名前ではなく前提の入れ替えにあります。クライアントが常時オンラインのエージェントなら、完全なコピーを持たせる理由は薄れ、サーバーが答えを持つ設計に倒せます。Anthropicはその前提で、5か月、7人でモノレポを移し、従来のgitミラー構成と比べてインフラのCPU・メモリ要件を200分の1にしました。

一方、マージ後のテストで衝突を拾う運用は、全体のロックを再現できなかった末の選択です。数字は同社の環境での報告で、他の組織に持ち出せるのは設計の方向までです。