技術・研究 · · Team LATENT
AnthropicがGitからScionへ移した理由
1日3万件超のマージを支えるには、コードを書く速さだけでは足りない。Scionが変更の記録、履歴の照会、ファイルの取得をどう作り替え、開発基盤の負荷を減らしたかを解説する。
AnthropicがScionで変えたのは、各端末に大きなリポジトリを持たせて処理する前提だ。変更の記録や履歴の調査をサーバーへ移し、端末は作業に必要なデータだけを求める。AIが書くコードの増加に、コードを取得して検査する基盤を対応させた。
2026年10月13日の発表によると、同社の1日あたりのマージ数は5月の約2,500件から9月の3万件超へ増えた。マージは、別々に進めた変更を共有のコードへ取り込むことだ。変更を記録するコミットの件数とも、本番環境への配備回数とも異なる。
この記事の要点
- Anthropicでは、巨大なコードと履歴を大量の検査環境へ配る処理が負担になった。Scionは端末が行っていた変更管理をサーバーへ移している。
- 変更したファイルの記録と、履歴を素早く調べるためのデータを分けた。ファイルも必要なものだけを取得し、近くのキャッシュから再利用する。
- 軽い履歴APIは自動の原因調査や変更の取り消しにも使われる。ただし、設計上の制約を判断する人のレビューは残り、一般向けのGit代替製品としては提供されていない。
1日2,500万回のコード取得
同社は、多数の開発対象のコードを一つにまとめるモノレポを使っている。共有する開発の本流mainは、履歴だけで約100GBに達した。作業用のファイル一式も、圧縮して25GBを超える。
コードを変更するたび、ビルドやテストを自動実行するCIが動く。検査を始めるには、対象のバージョンのファイルを作業場所へ用意する必要がある。この取得・展開をチェックアウトと呼ぶ。AnthropicではCIだけで1日に約2,500万回行っていた。
Gitはコードと履歴を管理する道具で、通常の完全な複製なら端末内で過去の変更も調べられる。ネットワークがなくても調査できる利点がある一方、短時間で入れ替わる検査環境が同じ巨大なリポジトリを繰り返し準備すると、取得と維持の費用が積み重なる。
同社は部分的な取得や、社内の複製サーバー、あらかじめ保存したリポジトリの複製を使っていた。それでも更新が速くなると、保存済みの複製が最新状態から離れやすい。履歴を一部だけ取得した環境で、変更前後の比較や行ごとの変更者を正しく調べるための管理も複雑になった。
端末の処理をサーバーへ移す
Scionでは、常時接続しているAIや検査処理を主な利用者とした。端末は完全なリポジトリを管理する役割を減らし、サーバーへ問い合わせる。コミットの作成、マージ、履歴の照会もサーバー側で行うため、手元で作ったコミットを後からpushして共有する段階はない。
APIは、プログラムから機能を呼び出すための窓口だ。たとえば「この変更でどのファイルが変わったか」を知りたいだけなら、その答えをAPIから受け取ればよい。ファイルを実行する検査と、変更履歴だけを読む処理を分けることで、後者は作業用ファイル一式を用意せずに済む。
ここで変わるのは、どこで計算し、どれだけのデータを手元へ運ぶかだ。Gitを使うサービスでも履歴APIは提供できる。Scionは、その分担を端末の基本動作にまで広げた設計と読める。
変更の記録と履歴の検索を分ける
サーバーへ仕事を集めるだけでは、今度はサーバーの処理が追いつかなくなる。そこでScionは、変更を受け付ける記録と、履歴を素早く調べるためのデータを分けている。
Gitのコミットは、その時点のファイル構成を表すツリーを参照する。ツリーはファイル名と内容の対応をたどるためのデータだ。変更していない内容は再利用するので、コミットのたびに全ファイルを丸ごと保存し直すわけではない。
Scionの記録単位はchangesetだ。直前の基準となる変更に対して、どのファイルが変わったかと、その内容の保存先を記録する。複数の変更を合流した場合は、最初の親を比較の基準にする。
Gitの状態参照とScionの変更記録
Bだけを変更した場合の概念図
Gitのコミット
ツリー → A・更新後のB・C。変更していないAとCの内容は再利用する。
Scionのchangeset
最初の親との差 → Bの変更と新しい内容の参照を記録する。
照会に使う派生データ
変更記録から、ファイルの履歴や行ごとの変更者を調べるデータを作る。
変更記録だけを順に読んで調べると、履歴が長いほど調査に時間がかかる。そのため、ファイル単位の履歴などは別のデータとして計算する。必要なものは先に用意し、ほかは問い合わせ時に計算できる。変更を受け付ける処理に、すべての照会準備を抱え込ませない構成だ。
changesetの作成と、mainが指す変更の更新も別の操作だ。したがって、変更を記録できたこととmainへ取り込まれたことは同じではない。公式が説明するロックやサーバー間調整の少ない書き込みは、まず変更記録を大量に受け付けるための設計である。
必要なファイルを近くから取得する
ファイルが必要な処理でも、リポジトリ全体を毎回取得する必要はない。Scionの端末は必要なディレクトリとファイルを選び、手元にないものを要求する。要求しないディレクトリは取得せず、実際に読むときにファイルを用意する使い方もできる。
Gitは通信や保存の効率を上げるため、複数のデータをpackfileという圧縮したまとまりにできる。Scionは取得したいデータを個別に指定する方式を採る。同じ識別子の内容は変わらないため、別の処理が使ったコピーを再利用しやすい。内容による識別自体はGitにもあるが、Scionでは個々のデータの要求に対してキャッシュが応答する。
必要なデータをキャッシュから探す
要求したデータがないときだけ次の段へ進む
1 同じ計算機で共有
端末 → scion-daemon。同じ計算機のジョブが取得済みのデータを再利用する。
2 同じ地域で共有
scion-cacheへ要求。同じ地域のジョブが使うデータを返す。
3 保存先から取得
scion-serverが必要なデータを保存先から読む。結果は要求元へ返る。
たとえば、同じバージョンの同じファイルを二つの検査が読むなら、二つ目の検査は既にあるデータを使える。ファイルを変更した後の内容には別の識別子が付くので、以前の内容と区別できる。この再利用と取得対象の絞り込みが、大量のチェックアウトで繰り返す仕事を減らす。
バグの原因調査と設計の制約
このAPI化は、バグが入り込んだ変更を探す処理にもつながる。bisectは正常な状態と失敗する状態の間を検査し、原因候補を絞る方法だ。revertは変更の効果を打ち消す新しい変更を作る。どちらも履歴の参照を繰り返すため、調査用にリポジトリを維持する負担が小さいほど大量に実行しやすい。
Anthropicは、自動bisectとrevertの社内処理が、この低コストのAPIアクセスに支えられていると説明する。Scionがバグを判断するのではなく、原因を調べて変更を戻す道具が履歴を扱いやすくなった、という関係だ。修正の成功率を示す発表ではない。
検査の時点も変わった。テスト中に数百、数千の変更が入る環境では、順番待ちの変更をリポジトリ全体のロックで制御する方式を十分に再現できなかった。そのため同社は、マージ後と本番配備前の自動テストへ投資した。並行する変更の衝突は残り、Claudeがその修正を担うと報告している。
一方、設計の制約には人が介入している。実例は「この変更がmainに入ったのはいつか」を調べる処理だ。AIが履歴を先頭から順に読む実装を作ろうとしたところ、レビュー用のシステムへ問い合わせる方式へ人が誘導した。履歴が増えるほど重くなる調査を、せっかく作った基盤の上に再導入しないための判断である。
担当チームは、このシステムへの変更要求を今もすべてレビューし、各行より変更の意図を見ているという。自動の検査を増やすことと、システム全体の設計判断を人が行うことを組み合わせた開発だ。
出典：What we learned building Scion
コードレビューで何を検出できるかは、LATENTのReviewBench解説でも扱った。Scionの話で増えたのは、レビューの対象となるコードだけでなく、その検査と調査を繰り返すための基盤の仕事だった。
減った負荷と移行の代償
Anthropicが報告した効果は次のとおりだ。比較対象と測定対象が異なるため、一つの「開発が何倍速い」という数字にはまとめられない。
| 対象 | 公表された変化 |
|---|---|
| ソース管理基盤のCPU・メモリ | 従来のGitミラー基盤の約200分の1。 |
| CI・研究ジョブのチェックアウト | 約2桁の高速化。分単位から秒単位へ。 |
| CIのCPU処理能力 | 25%の余力を得たと報告。 |
減ったのは、主にコードを配り、作業環境を準備し、履歴を調べるための負担だ。テストそのものがすべて100倍速くなったという意味ではない。AIが大量に変更を書くほど、変更を確かめる前に待つ時間も無視できなくなる。Scionはその待ち時間を生む処理を作り替えた。
代償は、サーバーへの接続と専用基盤への依存だ。Gitのように手元だけで多くの作業を完結する性質を弱め、レビュー、検索、CIも合わせて移行した。Scionは一般向けのGit代替製品として提供されていない。小規模な開発でも同じ移行が有利だとは、今回の結果からは言えない。
この事例から読み取れるのは、AI時代にはコードの生成量だけでなく、取得・統合・検査の単位も見直す必要が生じることだ。Anthropicは端末ごとに持っていた仕事をサーバーへ移し、変更した部分と実際に必要なファイルを中心に処理することで、増え続ける開発を支えた。
出典
2026年10月14日に公式発表とGit公式資料を確認した。図は資料に基づくLATENTの概念図で、社内構成を完全に再現したものではない。性能値はAnthropicの報告であり、独自の実測は行っていない。