Anthropicが、自社の開発基盤の中核にあるsource controlをGitから自前実装へ移した。理由は単純で、コードを書く速さではなく、変更をさばく仕組みのほうが先に詰まったからだ。Claudeが研究ループの反復やサービス開発まで担うようになり、1日にマージされるコード量が短期間で桁違いに増えた。この記事は、その“開発がAIで速くなった結果、古い前提のツールが足を引っ張る”という現象をかなり具体的に示している。
Anthropicによると、2026年5月ごろは1日あたり約2,500件だったコードのマージが、9月には30,000件を超えた。増え方が極端だが、同社ではClaudeが研究ループを自律的に回し、複雑なプログラムを最適化し、新しいサービスをゼロから作ることまでできるため、そもそものコード生産量が止まらないという。問題はコードを書くことではなく、それを受け止めるsource control、build、CIのほうになった。
そこでAnthropicはScionという社内版のversion control systemを作り、monorepoをGitから5か月で完全移行した。あわせて、code review用のAntique、code search、source control向けのIAM、巨大なレビュー済みコードを扱って着地させる仕組みなども同時に整えたという。この記事では主にScionの設計に絞って説明している。
背景にあるのは、Gitが「分散していて、オフラインでも完全に使える」ことを強みとしてきた一方で、Anthropicのように大半のクライアントがagentやjobで、常時オンラインで動く環境には向いていなかった、という認識だ。Anthropicのmain branchの履歴だけで約100GB、圧縮したworking copyでも25GBを超える。CIだけで1日およそ2,500万回のcheckoutが発生し、素朴に考えれば600PB超のGit trafficになる。もちろん現実にはそんな流し方はしないので、同社はshallow clone、sparse checkout、promisor remote、内部mirror、blob storage上のseed snapshotなど、ありとあらゆる回避策を積み重ねてきた。ピーク時には数百台のGit mirrorを運用していたが、merge rateの増加に追いつかなくなった。
そこでAnthropicは発想を逆にした。Gitのように「各端末がローカルで完結する」前提を捨て、serverを常時参照できる世界でsource controlを設計し直す。Scionの原則は、クライアントは常時オンライン、serverとclientの役割を明確に分ける、質問や解析はAPIとして外に出す、水平分散できるようにする、commitやmergeは軽くロックなしで行う、working copyは必須ではなくsparseにする、というものだ。
仕組みもかなり違う。Scionではcommitに相当する単位がchangesetで、write-ahead logに記録される。Gitのcommitがtreeへのポインタを持つのに対し、Scionのchangesetは最初の親からの差分ファイル一覧と、blob storage上の圧縮済み内容へのcontent-addressedな参照を持つ。changesetはserver側で作られ、すぐ全体に見える。さらに、file blameやpath history、commit graphのskip listなどの“derived data”は、changesetから再帰的に計算される。これにより、新しい検索インデックスやcopy detectionの仕組みも追加しやすく、必要になるまで計算を遅らせることもできる。
Scionのserver群は、changesetの取得、diff計算、merge base探索、blob取得などをAPIで返す。データはすべてcontent-addressedなので一度保存されたものは変わらず、どのserverでもキャッシュできる。repo全体を完全に実体化したコピーはどこにもなく、packfileのような維持作業もいらない。client側も、何かを欲しがるたびにtreeとblobをたどって必要なものだけを取りに行くため、checkoutのコストをかなり抑えられる。Anthropicは、こうした設計によって、AI時代の開発量に耐えるsource controlへ移したのだと説明している。
この記事で面白いのは、AnthropicがGitを否定していないことだ。むしろ、Gitは大多数の用途には今も正しい設計だと認めている。そのうえで、自社では「人間が少数の変更を扱う」前提ではなく、「常時オンラインのagentが大量の変更を流し込む」前提が現実になった、と言っている。ここが本質だと思う。ツールの優劣というより、前提条件が変わったので、最適解も変わった。
この変化はAnthropicだけの特殊事情では終わらない可能性がある。AI coding toolsが本格的に広がると、checkoutの数、reviewの回数、diffの生成、blame参照、revertやbisectのような周辺作業まで一気に増える。人間が「1日に何十回も触る」規模ではなく、「機械が何万回も叩く」規模になると、source controlは保存庫ではなくAPI基盤に近づく。つまり、version controlは“開発者の手元の道具”から、“自動化システムが常時問い合わせるバックエンド”へ役割が移っていくのではないか。
Scionの設計は筋が通っているが、これを一般企業がそのまま真似するのはかなり難しいと思う。理由は、source controlの置き換えは単なるソフトウェア開発ではなく、開発現場の作法、CI、review、権限管理、検索、障害対応までまとめて変える仕事だからだ。Anthropicは5か月で移行したと書いているが、それは同社が自前のAI開発能力を持ち、しかも問題の規模が限界まで来ていたからできたのであって、再現可能なテンプレートではない。
むしろ気になるのは、Gitの代わりを作った結果、別の複雑さを抱え込んでいないかという点だ。server中心でAPI化されたsource controlは、確かに拡張しやすい一方で、障害時の影響範囲が大きい。ローカルで完結する分散性が薄れるぶん、ネットワークやserverの健全性への依存は強くなる。Anthropicはそこを水平分散やcontent-addressed storageで緩和しているが、運用の難しさが消えるわけではない。設計の巧さと、日々安定して回す難しさは別物だ。
この事例が示しているのは、AIでコード生成が速くなると、まず開発者の生産性が上がるのではなく、周辺インフラが先に悲鳴を上げるということだと思う。CI、review、search、権限管理、履歴参照。人間が当たり前だと思っていた周辺部品が、実は「人間の作業量に合わせて作られた」ことを、Anthropicは露骨に突きつけている。
ただ、ここには希望もある。AIで作業が増えるほど、その負荷を捌くための新しい基盤もまたAIで作れる、という循環が起きているからだ。Anthropicはまさにその循環を使って、自分たちのボトルネックを自分たちで潰した。これは単なる社内ツール開発ではなく、AI時代の開発基盤そのものが、どの粒度で作り直されていくのかを示す実例だと思う。今後ほかの組織も、Gitをそのまま使い続けるか、自分たちのワークロードに合わせて別の設計を選ぶか、いずれ判断を迫られるのではないか。
