この記事はAIエージェントと一緒に執筆しています

はじめに

Anthropic のエンジニアリングブログに「Redesigning source control at Anthropic」という記事が出ました（2026-10-13）。

結論、Claude がコードを書きすぎて git が追いつかなくなったので、エージェント前提のバージョン管理システム「Scion」を自分たちで作って、5か月で移行した、という話です。

このブログも「AIエージェントと書く技術ブログ」なので、エージェントがコードを書く量が増えると、その先で何が詰まるのか、はかなり気になるテーマでした。

ちなみに記事の中でも、ほとんどの会社にとってはまだ先の話で、Scion を git の代わりにみんなが使うものではない、とはっきり書かれています。

何が起きていたのか

マージが1日2,500件から3万件に

記事によると、Anthropic の中では、もうコードを書くことはボトルネックではないそうです。Claude が研究のループを自分で回したり、複雑なプログラムを細かく最適化したり、新しいサービスを一から作ったりしている。

その結果、詰まるようになったのは「人間のスケールで作られた開発の基盤」、つまりソース管理・ビルド・CIでした。

• 2026年5月：1日あたり約 2,500件 のマージ
• 2026年9月：1日あたり 30,000件以上 のマージ

4か月で10倍以上です。しかも、ボトルネックを1つ取り除くたびに、すぐにコードの量がまた増えるので、この伸びはしばらく止まらないだろう、と書かれていました。

git の「分散」が、逆に重荷になった

git は分散型で、クローン1つ1つが完全なリポジトリになっていて、オフラインでも差分や履歴、blame が見られます。ほとんどのリポジトリにとっては、これが正しい設計です。

でも Anthropic のモノレポは、

• main ブランチの履歴だけで 100GB 近く
• 圧縮した作業コピーで 25GB 以上
• CI だけで1日に 約2,500万回 のチェックアウト

という規模になっていて、素直に取ってくると 1日600PB を超える git の通信量になる計算だそうです。

shallow clone や sparse checkout、社内の git ミラー（いちばん多いときで数百台）、スナップショットなど、定番の工夫は全部使っていたけれど、マージが増えるほど運用が苦しくなっていったとのこと。

そこで気づいたのが、クライアントのほとんどはエージェントやジョブで、そもそも常にオンラインだということでした。オフラインで動けるという git の良さが、この使い方では逆に足を引っぱっていた、という整理です。

Scion の考え方

Google の Piper や Meta の Sapling など、巨大モノレポ向けのソース管理には先行例があって、その教訓もふまえて作ったそうです。原則はこんな感じでした。

原則	中身
クライアントは常にオンライン	全部を手元に持たず、必要なときにサーバーから取る
クライアントとサーバーは非対称	履歴・blame・コミット・マージ・リベースはサーバーがやる。クライアントは小さなキャッシュと作業コピーの面倒だけ見る
ソース管理を API として開く	「この行を最後に変えたのは誰か」などを API で聞ける。ジョブはローカルのリポジトリがなくても動ける
すべて横に増やせる	リポジトリ全体が丸ごと置かれている場所はどこにもない（サーバーにも）。packfile もないので、メンテナンスが要らない
コミットは安く、少しずつ、ロックなし	コミットはサーバーで作るので push がない。コストはリポジトリ全体ではなく、変更の大きさに比例する
作業コピーはなくてもいい、あっても部分だけ	差分が欲しいだけならサーバーに聞く。ファイルが要るときも、読んだ分だけ取る

個人的に面白かったのは、**「ソース管理を API として開く」**ところです。社内の自動 bisect や自動 revert のパイプラインは、この安くて手軽な API がなかったら、この規模では現実的ではなかったそうです。

Scion のしくみ

コミットのかわりに「changeset」

Scion の単位は changeset です。git のコミットはツリーを指しますが、changeset は「最初の親から変わったファイルの一覧」と、圧縮したファイルの中身への（中身から決まる）ポインタを持っています。

変わったところしか持っていないので、「この行を最後に変えたのは誰か」のような質問にはそのままでは答えられません。そこで、blame やパスの履歴、コミットのグラフ用のデータを、changeset から**後から作る（derived data）**しくみになっています。

このしくみのいいところとして、記事では3つ挙げていました。

1. 速くしたい操作があれば、新しい種類のデータを足すだけでいい
2. 種類ごとに、すぐ作るか、必要になってから作るかを選べる
3. クライアントは中身を知らないので、クライアントを変えずに最適化できる

キャッシュを3段に重ねる

ファイルの中身を取ってくるところは、こういう3段になっています。

クライアント(scn)
  └ scion-daemon   … マシンごと。そのマシンのジョブで共有
      └ scion-cache   … リージョンごと。メモリからそのまま返す
          └ scion-server  … 大元。Spanner やクラウドストレージから読む

データは全部「中身から決まるアドレス」で管理されていて、一度保存したら変わりません。なので、どのキャッシュも、ほかと相談せずに答えを返せます。

git は「クライアントが何を持っているか」をサーバーに伝えて、足りない分をまとめて送ってもらう方式ですが、Scion はクライアントが欲しいツリーとブロブを1個ずつ取りにいく方式です。欲しくない部分は取りにいかないだけなので、部分的なチェックアウトにも特別な対応が要りません。

結果がすごくて、

• 各段のキャッシュのヒット率が 99%以上
• 前の git ミラーの仕組みと比べて、CPU とメモリが 200分の1
• CI や研究のジョブのチェックアウトが、分単位から秒単位に（100倍くらい）
• CI だけで CPU の容量に 25%の余裕ができた

だそうです。

作った側の話が面白い

ここからは、作った人たちが学んだこととして書かれていた部分です。わたし的にはここがいちばん刺さりました。

7人で、5か月で

Scion と、コードレビューのツール（Antique）と、関連するシステムをいくつか、7人のチームが5か月で作って移行したそうです。しかもその間に、1日のマージ量は10倍になっていました。

最初は手で書いた取り込みパイプラインの試作を、社内の Claude Mythos Preview の早い版に「全部書き直して」と頼んだら、それ以上の指示なしで、メモリ使用量が20分の1、速度が4倍になって、順番やデータ構造の暗黙の決まりごとも守られていた、というエピソードも載っていました。

エンジニアの仕事は「Claude にノーと言うこと」

エンジニアは全員、コードを書くのは Claude のほうがうまい、と評価しているそうです。それでも、システム同士のつながりや設計のトレードオフを分かっているのは人間で、エンジニアの役目は Claude に「それはダメ」と言うことが多かった、と書かれていました。

• 本当は許してはいけないパターンに合わせるために、システムの大事な制約を破ってしまうことがある
• 敵対的なレビュー（adversarial review）はすごく効くけれど、視野が狭くなることもあって、「もしこうなったら」という心配に引っぱられて作り込みすぎることがある

変更は今もメンバーが全部レビューしているけれど、1行ずつ読むのではなく、その変更の意図を見ているとのこと。

規模はぜんぜん違いますが、Claude Code とこのブログを書いていても、わたしが返すのは「それは書かないで」「ここは消して」が多いので、ちょっと分かる気がしました。

コンポーネントごとの「推し」の Claude

運用の話で好きだったのがこれです。

Slack にチャンネルを作って、1つのコンポーネントの健康だけをひたすら気にかける Claude を置いているそうです。名前は「superfan（推し活勢）」。scion-daemon の推し、scion-cache の推し、マージキューの推し……と、それぞれがテレメトリやログを見て、ずっとグラフを更新しながら変なところを探している。

ふつうのアラートもあるけれど、推しの Claude はもっと細かくて新しい異変に気づくので、アラートが一次元的に見えるくらいだそうです。かわいい。

マージキューも考え直し

テストが走っている間に何百、何千というマージが入る規模だと、マージキューに全体ロックをかける、という業界の定番がうまくいかなかったそうです。

そこで、マージしたあと・デプロイする前の自動テストに力を入れる形にしたとのこと。同時に入った変更がぶつかることはあるけれど、Claude が人間より速く直せる、という割り切りです。

git はどうなるのか

記事の最後では、Scion は一般向けの git の代わりにはならないと何度も書かれていました。

• 本当に巨大なモノレポ（何万人ものエンジニアか、大量のエージェント）でしか意味がない
• git と大きく違うので、移るならコードレビューも検索も CI も全部作り直しになる
• Anthropic は社内でトークンを使える量がふつうの会社とぜんぜん違う

そのかわり、この種類の問題は これから6〜12か月でもっとよく起きるようになると見ていて、Scion の考え方の中で git に持ち込めそうなもの（サーバー側の API を充実させる、取ってくる手順を変える、sparse や shallow をうまく組み合わせる）を共有した、という立場でした。GitHub や GitLab、OSS のコミュニティと一緒にやっていきたい、という締めです。

まとめ

• Anthropic では、1日のマージが4か月で 2,500件から3万件以上に増えて、ボトルネックが「書くこと」から「ソース管理・ビルド・CI」に移った
• 「クライアントは常にオンライン」という前提で、自前のバージョン管理 Scion を作って、7人・5か月で git から移行した
• 履歴や blame はサーバーが答え、クライアントは欲しいものだけ取りにいく。キャッシュは3段で、チェックアウトは分から秒に
• エンジニアの役目は、設計を分かったうえで Claude に「ノー」と言うこと。運用には部品ごとの「推し」の Claude
• Scion は一般向けの git の代わりではない。でも同じ問題はこれから多くの人に来そう、という問題提起