ツール / 開発環境

AnthropicがGitをやめた理由 — 1日3万マージを捌く独自版管理「Scion」の設計を読む

AnthropicGitバージョン管理モノレポAIエージェント

はじめに

2026年10月13日、Anthropic がエンジニアリングブログで「Redesigning source control at Anthropic」を公開しました。社内のモノレポを Git から独自の版管理システム「Scion」へ移行した、という報告です。Hacker News では180ポイント超・150件を超えるコメントを集め、「Git の利点を捨てるのか」という批判も含めて議論になりました。

きっかけは、AI エージェントがコードを書くようになってマージの数が桁違いに増えたことです。本記事では、Git のどこが限界になったのか、Scion がどんな設計でそれを解いたのか、そして普通の開発チームにとって何が参考になるのかを整理します。

1日2,500件が3万件に — 何が起きたのか

記事によると、Anthropic のメインリポジトリへのマージは2026年5月に1日約2,500件でしたが、9月には約30,000件に達しました。4か月で12倍です。記事は、この状況を生んだのも、それを素早く解決できたのも Claude がコードを書けるからだ、と述べています。版管理を使う側も、ほぼすべてがエージェントと自動ジョブになっていました。

この規模で Git が苦しくなった理由は、記事の数字を並べるとよく分かります。

  • メインブランチの履歴だけで約100GB、圧縮した作業コピーでも25GB以上
  • CI のためのチェックアウトが1日およそ2,500万回
  • 素直に fetch した場合のトラフィックは「1日600PB超」に相当する
  • これを支えるため、ピーク時には社内に数百台の Git ミラーを立てていた

Git は分散型なので、クローンするたびに履歴をまるごと持ちます。人間が1日数百回クローンする規模なら問題になりませんが、エージェントと CI が数千万回チェックアウトする規模では、この「全員が全部持つ」前提がそのままインフラ費用になります。

チームは7人。5か月で Scion 本体、コードレビューツール「Antique」、周辺の6システムを作り、モノレポを Git から移しきったとしています。マージ数が10倍に増えている最中の移行だった点も強調されています。

Scion の設計 — 「常にオンライン」を前提にする

Scion の出発点は、Git が大事にしてきた前提を逆にすることです。記事が挙げる設計原則のうち、主なものは次のとおりです。

  1. クライアントは常にオンライン: 主な利用者はエージェントと自動ジョブなので、オフライン作業は考えない
  2. クライアントとサーバーの非対称: 履歴の管理、コミット、リベース、マージ、blame はサーバーが行う。クライアントはキャッシュと作業コピーの展開、ファイル変更の監視を受け持つ
  3. API で直接問い合わせる: CI やツールは手元にリポジトリを作らず、RPC で版管理に質問する
  4. 水平にスケールする: 履歴の完全コピーをどこにも置かず、各部品を独立に増やせる
  5. コミットが軽くロック不要: コミットのコストはリポジトリ全体ではなく変更の大きさに比例する
  6. 作業コピーは任意で、最初から疎（sparse）: 手元にファイルを展開しない使い方が基本

データの持ち方も Git と違います。Git のコミットはディレクトリツリー全体のスナップショットを指しますが、Scion の「チェンジセット」は「どのファイルがどう変わったか」の一覧と、圧縮した中身への参照だけを持ちます。チェンジセットはサーバー側で作られ、作られた瞬間にどこからでも見えます。blame やファイル履歴、コミットグラフのスキップリストのような重い情報は「導出データ」として扱い、種類ごとに先に計算しておくか後回しにするかを選べます。サーバーがその場で計算した結果は Spanner に書き戻されます。

配信は3段のキャッシュです。

scn クライアント
  └ scion-daemon   … ノード（マシン）ごとのキャッシュ
     └ scion-cache … 地域ごとのキャッシュ（メモリからストリーミング）
        └ scion-server … Spanner / Cloud Storage を参照

中身はハッシュで指す（内容アドレス）ので、どのサーバーでも安心してキャッシュでき、各段で99%を超えるヒット率が出ているそうです。作業コピーが必要な場合も、仮想化されたチェックアウトが必要なファイルだけをその場で取り出します。

結果として、CPU とメモリの必要量は以前の Git ミラー基盤の約200分の1、CI や研究ジョブのチェックアウトは「分」から「秒」へ2桁速くなり、CI 全体でも CPU 容量が25%浮いたと報告されています。

既存の巨大モノレポとの比較

「常時オンライン＋サーバー中心＋仮想ファイルシステム」という組み合わせ自体は新しくありません。Google の Piper は巨大モノレポをサーバー側に置き、CitC というクラウド上の作業領域で必要なファイルだけを見せる方式です。Meta の Sapling も、サーバー（Mononoke）と仮想ファイルシステム（EdenFS）で必要な部分だけを取り出します。Microsoft は Windows のリポジトリのために VFS for Git を作り、後継として Scalar を出しました。HN でも「Perforce に近い」「SVN の再発明では」という反応が出ています。

それでも Scion が注目される理由は2つあります。1つは、規模を押し上げた原因が人数ではなくエージェントだという点です。Google や Meta は数万人の開発者を抱えて十数年かけてこの形に至りましたが、Anthropic は数か月でそこに到達しました。もう1つは、7人で5か月という作り方です。記事では Git から取り込むパイプラインを Claude に改善させたところ、メモリが20分の1、速度が4倍になった例が紹介されています。部品ごとに専任の監視エージェント（記事では「superfan」と呼んでいます）を置き、通常のアラートより細かく異常を拾う運用もしているそうです。エンジニアの仕事は「Claude にノーと言うこと」、つまり制約を破る変更を止めることに移った、という表現が印象的です。

一方でトレードオフもはっきりしています。Scion は Git から大きく離れた設計で、使うには専用のコードレビュー、コード検索、CI が必要になります。そのため Anthropic は Scion 自体を公開せず、考え方の共有を優先するとしています。HN の批判の一つは、オフラインで履歴を扱えるという Git の長所が消えることでした。

エンジニアへの影響

ほとんどのチームは1日3万マージに届かないので、明日 Git をやめる必要はありません。ただ、エージェントを CI やコード生成に深く組み込み始めると、同じ方向の負荷は小さな規模でも現れます。今からできることを挙げます。

  • CI のチェックアウトを見直す: --depth=1 の shallow clone や --filter=blob:none の partial clone、sparse-checkout を使えば、履歴まるごとの取得を避けられます。Scion の数字は「CI が毎回全部取ってくる」ことの費用の大きさを示しています。
  • マージキューの前提を疑う: Anthropic はマージキューにリポジトリ全体のロックをかける業界標準のやり方を再現できず、代わりにマージ後・デプロイ前の自動テストに投資し、衝突は Claude に直させています。記事は「Claude は人間が衝突に気づくより速く直せる」と書いています。エージェントの PR が増えて順番待ちが詰まり始めたら、テストをどこに置くかを再設計するきっかけになります。
  • 版管理を「API で聞くもの」として扱う: 記事には、エージェントが作ったシステムが「この変更がいつ main にマージされたか」をレビューツールに聞かず、コミットログを先頭から読んで力ずくで調べていた例が出てきます。エンジニアが止めるべき「制約違反」の典型です。GitHub や GitLab の API で取れる情報は、ローカルクローンを作らずに API で取るよう、エージェントへの指示やレビューで決めておくとよいでしょう。

Anthropic は今後6〜12か月で同じ問題が他社にも広がると見ていて、GitHub、GitLab、OSS コミュニティと、サーバー側の新しい設計や、sparse/shallow クローンがうまく組み合わさる仕組みづくりで協力したいとしています。Git ホスティング側の改善としてこちらに届く可能性もあります。

まとめ

  • Anthropic ではエージェントの普及で1日のマージが4か月で12倍の3万件になり、Git の「全員が全履歴を持つ」設計が費用の壁になった
  • Scion は常時オンラインを前提に、コミットとマージをサーバーに寄せ、差分単位のチェンジセットと3層キャッシュで配る
  • 以前の Git ミラー基盤と比べて CPU・メモリは200分の1、チェックアウトは分から秒へ。一方で Git 互換性とオフライン作業は捨てている
  • 設計思想は Piper や Sapling と同じ系統だが、エージェントが原因で、7人・5か月で到達した点が新しい

エージェントがコードを書く量が増えるほど、版管理や CI は「人間の操作に合わせた道具」から「機械が大量に叩くサービス」へ変わっていきます。Git がこの変化にどう追いつくのかは、今後しばらく注目しておきたいテーマです。

ソース

Back to articles