Scionが選んだ取捨選択：常時オンラインのエージェントに合わせたソース管理

Scionは、一般の開発者が今日Gitの代わりに導入できる製品として発表されたものではありません。Anthropicが10月13日に公開したのは、巨大な社内モノレポ、つまり複数のプロジェクトを一つにまとめたリポジトリを5か月で移行した開発の記録です。注目すべきは「Gitの後継」という名前より、常時オンラインのエージェントに合わせて、ローカルの自律性とサーバーへの依存をどう交換したかです。

Scionは一般の開発者向けのGit代替ではない

Redesigning source control at Anthropicによると、同社のコード変更のマージ数は、2026年5月の平均約2,500件／日から、9月には30,000件超／日へ増えました。公開されたのはこの負荷への対応であり、記事は一般向けのダウンロード、オープンソース公開、利用申し込みを案内していません。

主ブランチの履歴だけで約100 GB。圧縮した作業コピーは25 GB超。変更ごとの自動テストなどを走らせるCIだけで毎日およそ2,500万回チェックアウトし、開発者環境やエージェントのサンドボックス、研究ジョブは別です。

記事の600 PB／日超という数字は、単純に全量を取得した場合の想定です。実際にその通信量が発生していた、という測定値ではありません。同社はすでに部分的な取得やスナップショットを使い、ピーク時には数百台の社内Gitミラーを運用していました。それでも変更頻度が上がると、スナップショットが最新状態から離れ、履歴を使う処理の維持が難しくなったと説明しています。

問題は、リポジトリが大きいことだけではありません。大量の短命なジョブに、同じデータと履歴を繰り返し渡すことでした。

常時オンラインなら、履歴の計算までサーバーに任せられる

通常のGitリポジトリは、手元のデータで差分や履歴を調べ、blameで各行を最後に変更した履歴を確認できます。ネットワークが切れても作業を続けられる。この自律性は、人間が別々の環境で開発する際の強みです。

Scionはその前提を外しました。履歴の問い合わせ、コミット作成、マージ、リベースはサーバーが担当します。クライアントは容量を制限したオブジェクトキャッシュ、作業ファイルの配置、変更監視、操作画面を持ちますが、単独で計算できることは少なくなります。

ここを「Gitは必ず全部を複製する」と読むのは誤りです。Gitのpartial clone設計文書には、完全なコピーを持たずに動作し、不足するオブジェクトを必要時に取得できると明記されています。履歴の範囲を狭めるshallow cloneとも別の仕組みです。欠けたデータが必要になれば、Gitでも取得先への接続が要ります。

違いは、取得量を減らすだけでなく、計算と問い合わせの責任まで移したことです。例えばCIが「この変更と共通祖先との差分」だけを知りたいなら、ScionのAPIに尋ねればよい。作業コピーを作る必要はありません。ファイルを使う場合も、指定したディレクトリだけ、あるいは実際に読むファイルだけを実体化します。

その代わり、サーバーに届かなければ履歴照会やコミットなどが止まります。これは仕様の穴ではなく、オンラインで動くジョブ群のために選んだ依存関係です。開発者のノートPCに同じ前提を置けるかは、別に判断する必要があります。

changesetは差分を記録し、履歴の索引は別に作る

Scionの基本単位は、変更の記録であるchangesetです。Gitのコミットがファイル全体の構成を示すツリーへの参照を持つのに対し、changesetは基準となる親（第1親）から変わったファイルの一覧と、圧縮した内容への参照を記録します。ファイル内容は、その内容から決まる識別子でblob storageに保存します。

変更の受け付けは、リポジトリ全体ではなく変更の大きさに応じた処理にしたい。そこで、changeset作成と同時にブランチの指す先まで更新する処理を避けています。ただしブランチやタグに相当するrefsが消えたわけではありません。参照を動かす処理はSpanner上で分離され、現在の値が想定どおりのときだけ更新するcompare-and-swapを使います。

変更一覧だけでは、ある行の最終編集者やファイルの履歴を素早く答えられません。そのため行やファイルの履歴、コミット間の関係を検索する索引を派生データとして作ります。親の派生データから計算し、種類ごとに先に作るか、問い合わせ時まで待つかを選びます。

履歴を安くしたというより、書き込みと読み取りに必要な構造を分けた設計です。索引の実装をクライアントから隠せる利点はありますが、その計算と運用はサーバー側に残ります。第1親を基準にする選択も、同社のモノレポで主系統の履歴を重視する開発方式に沿ったものです。

キャッシュを重ねるだけでなく、障害の波及を止める

取得プロトコルも役割を絞っています。クライアントが「何を持っているか」をサーバーに調べてもらうのではなく、「欲しいツリーとblob」を要求する。保存後に変わらないオブジェクトなので、途中のキャッシュでも同じ要求に答えられます。

CIやクラスタ上のジョブでは、ノード全体でオブジェクトを共有するscion-daemonを経由します。その先がリージョン内のscion-cache、さらにデータの正本を管理するscion-serverです。開発者のマシンは、オブジェクト取得時にリージョンキャッシュへ直接接続します。同じノードのジョブが同じ内容を再利用し、キャッシュはメモリから、daemonが保存する形式のまま送り出します。要求ごとの不足オブジェクト計算や差分圧縮を避ける構造です。

重要なのは、どの層でも同じRPCに答えられる一方、実際の接続先は厳密に階層化している点です。リージョンキャッシュの障害でリクエストが一斉に上流へ流れ、全体を落とす事態を防ぐためです。キャッシュは高速化だけでなく、障害の波及を制限する境界でもあります。

公式の内部観測では各層のヒット率は99%超。Scion基盤のCPU・メモリ要求は、以前のGitミラー基盤の200分の1になったとしています。またCIについて、CPU容量面で25%の改善を報告しています。

200倍は全操作の高速化率ではなく、25%も全社の計算費用やテスト時間の削減率ではありません。本文は比較条件を再現できる測定手順までは示しておらず、この記事でも独立測定はしていません。同じ値を別のチームの予算に当てはめることはできません。blob storage、Spanner、通信、運用人員まで含めた総費用も、この数字からは分かりません。

Gitを外すと、レビューとCIの責任も移る

移行したのは保存形式とCLIだけではありません。同社はレビュー用のAntique、コード検索、権限管理、CIを含む周辺システムも作りました。ディレクトリ単位のアクセス制御や、コメントだけの変更と重要なロジック変更を区別する承認条件も、この開発基盤の一部です。

テストの位置も変わります。記事は、テスト中に数百、数千の変更がマージされる規模では、マージキューにリポジトリ全体のロックを置く方式をうまく再現できず、マージ後とデプロイ前の自動テストへ投資したと説明します。並行した変更が衝突する可能性も認めています。

これは普通のチームにもマージキューを捨てよ、という提案ではありません。衝突の検出、修復、デプロイ阻止を引き受ける仕組みが必要です。ソース管理を速くしても、壊れた変更を速く届けるだけなら意味がありません。

7人が関連システムを含め5か月で構築・移行したという結果は印象的です。ただし、それは同社の投入資源と内製環境での結果。公式記事は、内部用途に投入できるトークン量が、他社が現実的に負担したい水準を大きく上回るとも認めています。読者の移行工期や予算を見積もる数字ではありません。

普通のチームは、Scionの何を持ち帰ればよいか

常時オンラインの巨大モノレポという発想自体には先例があります。Sapling SCMの紹介も、企業内のオンライン環境や単一の主系統を意識した設計を説明しています。一方、SaplingのCLIはGitリポジトリを扱え、個人開発者にも使えると明記されています。内部基盤の設計と、一般向けに使えるクライアントは、分けて読むべき情報です。

Scionの記事は、自ら一般用途のGit代替には適さないと述べています。専用のレビュー、検索、CIが必要で、導入は開発ライフサイクル全体に及ぶからです。むしろ提案しているのは、サーバー側RPCや取得方式の工夫を、Gitの枠組みに持ち帰ることです。

通常のチームなら、まずCIがどれだけ取得を繰り返すか、どのデータを再利用できるか、履歴の問い合わせだけで作業コピーを作っていないかを測る。partial cloneなど既存の手段を検討し、ボトルネックが転送、履歴計算、テスト待ちのどこにあるかを分けるのが先です。

Scionから学ぶべきなのは、Gitを捨てる決断の速さではありません。失ってもよい自律性を特定し、その代わりに必要なサービスの可用性と運用を引き受けることです。その条件がそろわないチームにとって、Gitを使い続けるのは遅れではなく、妥当な設計判断です。