一日3万件のマージ — Anthropicがgitを捨てた理由と、その設計の系譜
一日3万件のマージ — Anthropicがgitを捨てた理由と、その設計の系譜
エージェントがコミットする時代のソース管理は新しい発明なのか、それとも巨大モノレポが既に歩んだ道をもう一度歩いているだけなのか?
導入
2026年10月13日、Anthropicのエンジニアリングブログに「Redesigning source control at Anthropic」という記事が公開された。Hacker Newsでは892ポイント、コメント1,010件を集めた。記事の冒頭は問題をこう要約する。一日あたりのマージ件数が10倍以上に増え、ソース管理が開発最大のボトルネックになった。そこで5か月で社内製のバージョン管理システムへ移行した、と。
まず数字を書き写しておく。記事によれば、Anthropicのモノレポには2026年5月時点で一日平均約2,500件の変更がマージされていたが、9月には一日3万件を超えた。mainブランチの履歴だけで100GB近く、圧縮されたワーキングコピーは25GBを超える。CIだけで一日2,500万回程度のチェックアウトが発生し、これを素朴にgitで取得すれば一日600PBを超えるトラフィックになるという。この状況への答えとして作られたのがScionという自社製バージョン管理システムであり、7人のチームがScionとコードレビューツールAntiqueを作り、移行まで完了させた、というのが記事の骨子である。
この記事が興味深い理由は二重になっている。一つは「コードを書く主体が人からエージェントに変わったとき、開発インフラのどの前提が崩れるのか」という問いに対する具体的な事例であること。もう一つは、翌日にMetaでMononokeの開発に関わったエンジニアが「ScionはMononokeから強く影響を受けている」という記事を出し、設計の系譜とクレジット表記の問題が一緒に噴き出したことだ。本稿はこの二つを順に扱う。
gitのどの前提が崩れたのか
Anthropicの診断は、gitの欠陥を指摘するものではなく、gitの設計前提が自分たちのワークロードに合わないというものである。記事はgitが分散システムであることから出発する。すべてのクローンはそれ自体で完結したリポジトリであり、オフラインでもdiffを計算し、履歴やblameを読み、任意のリビジョンをチェックアウトできる。記事は、大多数のリポジトリにとってはこれが正しい設計であり、gitが標準になった大きな理由だと認めている。
問題はその先にある。多くの企業と同じく、Anthropicもgitを事実上「権威あるコピーを一つ持つ中央集権型」として使っていた。そしてクライアントのほとんどは、定義上常にオンラインであるエージェントとジョブだった。オフラインの分散作業のためのgitの長所が、リポジトリが大きくなるほどスケールを妨げる方向に働いた、というのが記事の表現だ。そこで立てた問いが「エージェントは常にオンラインだという事実を最初から前提にしてソース管理を設計したら、どんな形になるか」だった。
それ以前に試したことも記事に書かれている。shallow clone、sparse checkout、promisor remoteといったgitの部分リポジトリ機能、そして社内gitミラーやblobストレージに置いたリポジトリスナップショット(seed)といった大規模モノレポの定番の回避策をすべて使った。ピーク時には社内gitミラーを数百台運用していた。時間は稼げたが、マージ速度が上がるにつれ運用は難しくなった。seedは更新の合間にmainの先端からどんどん離れ、diffやblameのように履歴に依存する操作をpartial clone上で維持するのに、ますます手間がかかるようになった。
ここでエージェントが変えたものを整理すると、三つに見える。以下は記事の事実に基づく筆者の解釈である。
第一に、クライアントの性格だ。人間の開発者はノートPCを持って飛行機に乗るが、CIジョブやエージェントのサンドボックスはネットワークなしには存在しない。オフライン作業というgitの中核的価値を享受するクライアントが全体の少数派になれば、すべてのクライアントに完全なコピーを要求するコストだけが残る。
第二に、チェックアウトの頻度だ。人のチェックアウトは一日数回だが、エージェントとCIは短命な環境で毎回コードを取得する。記事が示した一日2,500万回は、開発環境、エージェントのサンドボックス、研究ジョブを数える前の、CIだけの数字である。チェックアウト一回のコストがリポジトリサイズに比例する限り、この掛け算は耐えられない。
第三に、マージの並行性だ。記事は、マージキューにおけるグローバルなリポジトリロックという業界標準を効果的に再現できなかったと書く。テストが走っている間に数百、数千件の変更がマージされうる状況で、CIとはそもそも何を意味するのかと問い直す。結局、マージ後・デプロイ前の自動テストに投資した。並行する変更が衝突することはありうるが、Claudeはたいてい人間が衝突に気づくより早くそれを直す、と説明している。この部分は「マージ前に検証する」という古い原則を「マージ後、デプロイ前に検証する」へ移したものであり、ソース管理そのものより大きな変化かもしれない。
Scionの設計選択と、その先達
記事が挙げるScionの原則は六つある。クライアントは常にオンラインである。クライアントとサーバーは非対称である。包括的なソース管理サービスは新しい応用を可能にする。すべては水平スケール可能でなければならない。コミットは安価で、インクリメンタルで、ロックフリーでなければならない。ワーキングコピーはオプションであり、設計上スパースである。
具体的にはこうだ。Scionにおける作業単位は「changeset」と呼ばれるwrite-ahead logのエントリである。gitのコミットがツリーへのポインタを保存するのに対し、changesetは第一親に対して変更されたファイルの一覧と、blobストレージ上の圧縮済みファイル内容へのcontent-addressedなポインタを保存する。コミット、リベース、マージはすべてサーバー上で起きるので、pushするものがない。コミットのコストはリポジトリ全体のサイズではなく変更のサイズに比例しなければならず、ブランチやタグのようなrefはmainとリリースブランチ以外では推奨されない。すべてのサーバーが合意すべきグローバル状態は、迫りくるスケーリング問題だからだという。refの移動は、changesetの作成とは切り離された、Spannerの1行に対するcompare-and-swapである。
changesetは変わったものだけを記録するので、「この行を最後に変更したのは誰か」といった問いにはすぐには答えられない。そこでScionはchangesetから、blame、パス履歴、コミットグラフ用のskip listといった構造を別途構築する。記事はこれを「derived data」と呼び、各タイプが親の値から再帰的に計算される一つの汎用メカニズムで扱うと説明する。新しいタイプの追加が容易であること、即時に計算するか遅延させるかを選べること、クライアントが内部構造を見ないためクライアントを変えずに最適化できることが利点として挙げられている。
転送プロトコルもgitとは異なる。gitのネゴシエーションは、クライアントが既に持っているものをサーバーに伝え、サーバーが不足分を計算してpackfileにまとめて送る方式だ。Scionではクライアントがルートツリーから出発し、ローカルストアにないツリーを再帰的に要求し、続いてblobを要求する。すべての要求は決して変わらない特定のオブジェクトに対するものなので、どのキャッシュでも応答できる。ノードごとにscion-daemonがオブジェクトを保持し、リージョンごとのscion-cacheを経由し、キャッシュにない場合にだけ権威あるscion-serverがSpannerやクラウドストレージから読み出す。三つの階層は同じRPCに応答するが、障害ドメインを隔離するために階層構造を厳格に強制しているという。記事が示す結果は、各階層のキャッシュヒット率99%以上、以前のgitミラー基盤と比べてCPUとメモリ基準で200分の1の規模、CIと研究ジョブのチェックアウトが分単位から秒単位へと二桁高速化したこと、CIだけでCPUキャパシティを25%節約したことである。
この設計は初めて見るものなのか。記事自身が「違う」と答えている。巨大モノレポ向けのソース管理には先行事例があり、代表的なものとしてGoogleのPiperとMetaのSaplingがあって、彼らが苦労して得た教訓を念頭にScionを作ることができた、と書く。筆者が読んだ版には脚注が付いており、具体的にはSaplingのサーバーコンポーネントであるMononokeが、Scionが使う多くの手法、特にBonsaiデータモデルを切り開いたという内容だ。ただし記事冒頭には、10月15日にScionの手法を切り開いたプロジェクトについての詳細を追加したという更新表記がある。この脚注がいつ入ったのかは、後述の追記で扱う。
Hacker Newsの反応は、この系譜をさまざまな角度から突いた。あるユーザーは短く「AnthropicはSVNを再発明したのか」と問うた(@mijoharas)（直接の引用ではなく、コメントの要旨の要約）。中央サーバーでコミットが起きるという点だけを見れば、的外れではない。別のユーザーは基本的な発想は妥当だと見ながらも、すべてのコミットとリベースがサーバー上で起きるというくだりで背を向けた。gitと、とりわけjujutsuの核心は、ローカルで小さなコミットを積み重ね、手直ししたり捨てたりできることにあり、このモデルはAIが遍在する世界でも良くない、という主張だった(@amluto)（直接の引用ではなく、コメントの要旨の要約）。East River Source Controlで働いているというユーザーは、大規模チームとエージェントがモノレポで作業すればgitのスケーリング限界にぶつかるという自社の主張を裏付けるものだと歓迎し、git互換レイヤーによる橋渡しを提供していると紹介した(@steveklabnik)（直接の引用ではなく、コメントの要旨の要約）。
これはフロンティアラボだけの話なのか
記事は自ら一般化に線を引いている。Scionは汎用的なgitの代替ではなく、ここで説明した概念は、数万人のエンジニアか、コードを旺盛に書くエージェントの群れを抱えた本当に巨大なモノレポにしか合わない、と書く。さらに、社内用途にトークンを使える能力が、他のどの企業も現実的に使いたいと思う水準をはるかに超えているという点で、Anthropicは特殊だと認めている。Scionを外部に提供するのも難しい。gitから大きく外れているため開発ライフサイクルのあらゆる部分を移行する必要があり、独自のコードレビュー、コード検索、CIが必要になるからだ。
ところが同じ記事は、この種の問題は今後6〜12か月でよりありふれたものになると予想している、とも書く。だからScionそのものではなく考え方を共有する、というわけだ。gitサーバーがgitクライアントと同じように動く必要はなく、gitプラットフォームはScionのように包括的なサーバーサイドRPCを提供でき、場合によってはフォージ間で標準化してgitクライアントがそれと話せるようにもなりうる、という提案である。ネゴシエーションプロトコルも今の形である必要はなく、gitのさまざまなsparse・shallow機能をうまく組み合わさるようにできる、とも付け加える。最後に、GitHub、GitLab、OSSコミュニティと協力していくという言葉で締めくくっている。
筆者は、この二つの主張の間の緊張こそがこの記事の本当の中身だと考える。「自分たちだけの問題」と「もうすぐ皆の問題」が同時に真であるためには、問題を引き起こす変数が会社の規模ではなく、エージェントが生み出す変更量でなければならない。Hacker Newsでもこの点で意見が割れた。あるユーザーは、皆が自分はAnthropicやGoogleではないと気づく前に、同じことをしなければと焦る醜い時期が来るだろうと述べた(@preommr)（直接の引用ではなく、コメントの要旨の要約）。別のユーザーは、AIがコードを書くことを安くするにつれ、小さなスタートアップでも車輪の再発明が増えるだろうが、自作ソフトウェアを維持することまで同じように安いかは別の問題だと指摘した(@kburman)（直接の引用ではなく、コメントの要旨の要約）。
レビューの問題も提起された。記事は、チームメンバーが今もすべての変更リクエストをレビューしているが、今ではコードを一行ずつ読むのではなく変更の意図を検討していると書く。エンジニアの役割はしばしばClaudeに「ノー」と言うことであり、エージェントがそもそも許されるべきでなかったパターンを満たすために中核的な制約を破ることが、移行の過程で特に多かったという。例として挙がっているのは、変更がいつmainにマージされたかを調べるのに、コードレビューツールに問い合わせず、コミットログを線形に読む複数のシステムだ。敵対的レビューは近視眼的になりうるため、仮定上の懸念に応じた過剰設計を止める必要があった、というくだりもある。あるユーザーは、この部分は自分のエージェントコーディングの経験と一致するとしつつも、一日3万件を意図だけでもレビューするのがどれほど容易なのか、コードを読まずにモデルが意図の実装で近道をしていないかをどう見抜けるのか、と疑問を呈した(@tetraodonpuffer)（直接の引用ではなく、コメントの要旨の要約）。
筆者の判断では、この事例を一般化するときに持ち帰るべきものはScionの実装ではなく、一つの問いである。「自分たちの開発インフラのうち、何が人間の速度を前提に設計されているか」。一日のマージが数十件のチームがソース管理を作り直す理由はない。しかし、チェックアウトのコストがリポジトリサイズに比例するCI、グローバルロックに頼ったマージキュー、一行ずつ読むことを前提にしたレビュー手順は、エージェントの利用量が増えたとき、規模に関係なく真っ先にきしむ候補である。記事がgit陣営に提案したサーバーサイドRPCやオブジェクト単位の要求プロトコルが実際に標準化されるかどうかは、まだわからない。
（10月15日追記: 10月14日、MetaでMononokeの開発に関わったRainは、ブログに「Anthropic’s Scion is heavily inspired by Mononoke」を公開した。AnthropicがScionの「derived data」を説明した箇所と、自身が2022年にMononokeのderived dataを説明した文章を並べ、模倣の程度は似た洞察を持つというレベルを超えていると書いた。Saplingが「苦労して得た教訓」としてしか言及されず、Mononokeがまったく言及されていないのは剽窃に近い、というのである。同時に、AnthropicがMononokeの設計をなぞったこと自体には問題はなく、オープンソースとして公開した理由の一つは良いアイデアの普及にあると述べ、LLMが新しいシステムの設計を助けるほど既存の設計に大きく依存するようになるのだから、先人をクレジットすることはかつてなく容易で、かつ重要になっていると強調した。この記事はHacker Newsで426ポイントを得た。反論もあった。あるユーザーは、MononokeはSaplingのコンポーネントであり、Rainの記事が張るリポジトリへのリンクもSaplingリポジトリのサブディレクトリなので、不満の要点がよくわからないと述べ(@BryantD)、別のユーザーは、インデックスという発想は新しいものではなく、問題を第一原理から考えた人なら思いつく内容だと反論した(@Mawr)（いずれも直接の引用ではなく、コメントの要旨の要約）。Anthropicの原文には、前述のとおり10月15日の更新表記とともに、MononokeとBonsaiデータモデルを明記した脚注が入っている。更新前の原文の正確な文言を筆者は直接確認できておらず、もともとSaplingだけが言及されていたという点はRainの記事に基づく記述である。）
結論
Anthropicの記事が示す事実は明確だ。一日のマージが2,500件から3万件に増えると、gitミラー数百台で持ちこたえていた体制が限界に達し、常にオンラインのクライアントを前提に、サーバー中心、content-addressed、オブジェクト単位の要求、derived dataを軸としたシステムへ移行した。その結果、インフラ規模は200分の1になり、チェックアウトは秒単位になったという。
しかし、これらの設計要素の多くは新しいものではない。中央サーバー、仮想化されたワーキングコピー、変更だけを記録するデータモデルとその上の派生インデックスは、GoogleとMetaが巨大モノレポを運用しながら磨いてきた方向と重なる。新しいのは、その圧力を受ける主体である。かつては数万人のエンジニアを抱える企業だけがこの地点に到達したが、今ではエージェントの変更量が同じ圧力を生む。そしてRainの指摘は、もう一つの新しさを浮かび上がらせる。モデルが既存のオープンソース設計を学習し、そのまま組み立て直せるようになったとき、その系譜を明らかにする責任はモデルではなく、それを使う人間の側に残る。
あなたの組織で、エージェントが生み出す変更が今の10倍になったら、最初に崩れるのは何だろうか。ソース管理かもしれないし、CIかもしれないし、レビューかもしれない。その答えを前もって知っておくことは、Scionを真似て作るよりはるかに安い。
出典: