Gitが限界に達した日 — AnthropicがVCS「Scion」を内製し5か月で全面移行

コードを書くのは、もう人間だけではない。ならば、人間のために作られた道具が先に壊れるのは当然だ。

2026年10月13日、Anthropicが自社のエンジニアリングブログで「社内のソースコード管理を作り直した」と公表した。新しく開発したバージョン管理システムの名前はScion（サイオン）。すでに社内のモノレポ（monorepo・巨大な単一リポジトリ）を全面移行済みで、要した期間はわずか5か月だという。

「あのGitが限界に達した」という見出しだけが独り歩きしているが、原文を読むと話はもう少し込み入っている。IT小僧が整理する。

まず結論：捨てたのではなく作り替えた

【確定情報】公式発表で確認できた事実は3点。1つ目、同社の1日あたりのマージ件数は2026年5月時点で約2,500件だったが、9月には30,000件を超えた。2つ目、この負荷に耐えるため新しいバージョン管理システムを内製し、5か月で移行を完了した。3つ目、開発にあたったのは7人のチームだ。

同社は、ボトルネックはもはやコーディングではないと書いている。コードを書く速度が人間の手を離れた結果、ソースコード管理・ビルド・テスト自動化という「人間の規模」向けに作られた開発基盤が先に音を上げた、という構図だ。

なぜ既存のバージョン管理が限界に達したのか

理由は単純な「重さ」ではなく、設計思想とのミスマッチである。Gitは分散型だ。クローンした時点でどの手元のコピーも完全なリポジトリであり、オフラインのまま差分も履歴も計算できる。この設計こそが標準の座を獲得した理由であり、大半のリポジトリには今でも最適解だ。

ところが同社のモノレポは、その想定範囲から完全にはみ出していた。公表された数字を並べると異常さがわかる。

1日600ペタバイト。もちろん実際にそれだけ流していたわけではない。浅いクローン（shallow clone）、部分クローン（partial clone）、疎なチェックアウト（sparse checkout）に加え、ピーク時には数百台の社内ミラーを運用し、オブジェクトストレージ上のスナップショットまで、使える手は全部使っていたと明記されている。

だがそれは時間稼ぎにしかならなかった。マージ速度が上がるほどスナップショットは最新の先頭から離れ、履歴や追跡情報に依存する操作を部分的なコピーの上で成立させるのに手間がかかるようになった。運用担当者なら胃が痛くなる話である。

【ここが本質】彼らが気づいたのは、分散型の道具を中央集権的に使っていたという事実だった。しかも利用者の大半は、定義上つねにオンラインのエージェントや自動実行ジョブだ。オフラインで完結できるという最大の美点が、規模を追ううえでは足かせになっていた。

バージョン管理システム「Scion」をわかりやすく解説

発想はひと言でいえば「クライアントは常時つながっている前提で、全部サーバ側に寄せる」である。先行事例としてPiperとSaplingという巨大モノレポ向け実装の知見を参照したと明言されている。設計原則は次のとおり。

• クライアントは常にオンライン：手元に完全なコピーを持たせず、必要なときに必要な分だけ取りに行かせる。
• クライアントとサーバの非対称化：履歴照会、変更の作成、マージやリベースはすべてサーバ側が担当。手元に残るのは上限つきの一時保存領域と作業ファイルの配置だけだ。
• すべてをAPI（エーピーアイ）で公開：クライアントが使う問い合わせは全部APIからも叩ける。自動テストや各種ツールが手元にリポジトリを持つ必要がなくなった。
• 完全な水平スケール：データは分散保持され、サーバ側にすら全体を実体化したコピーが存在しない。圧縮済みのオブジェクト束（packfile・パックファイル）に当たる概念がなく、保守作業そのものが不要だ。
• コミットは安価・増分・ロックフリー：すべてサーバ上で起きるので push（プッシュ）が存在しない。コストはリポジトリ全体ではなく変更の大きさに比例する。
• 作業コピーは任意、かつ疎が既定：仮想化チェックアウトにより、実際に読まれたファイルだけが実体化される。

データ構造も作り替えられた。作業の単位は「changeset（チェンジセット）」と呼ばれ、先行書き込みログの一エントリとして記録される。従来のコミットがツリーへのポインタを持つのに対し、changesetは第一の親からの変更ファイル一覧と、圧縮済み実体へのコンテンツアドレス指定ポインタを持つ。参照を動かす必要も、ロックも、サーバ間の調整も発生しない。これが毎日3万件を捌く土台だ。

ただし差分だけでは「この行を最後に触ったのは誰か」に即答できない。そこで追跡情報や経路履歴、コミットグラフ用のスキップリストなどを「派生データ（derived data）」として別途生成する。各種別は親の値から再帰的に定義され、先に計算するか後回しにするかを選べる。内部構造は外から見えないため、クライアントを変えずに最適化できる。

配信側は3層構造だ。各ノード上の常駐プロセス、地域ごとのキャッシュ群、そして権威サーバ。3者が同じ手続き呼び出しに応答するため、クライアントは構成を意識しなくていい。ただし階層をまたぐ通信は厳格に禁止されている。地域キャッシュの障害が全系停止を招く最悪のシナリオを、設計で潰しているわけだ。

【成果の数字】各層のキャッシュ的中率は99%超。基盤に必要な演算資源とメモリは、従来のミラー群と比べて200分の1になった。テストや研究ジョブのコード取り出しは2桁高速化し、数分が数秒になった。自動テスト基盤だけで演算容量の25%が浮いたという。

「Scion」は一般公開されるのか

ここが一番知りたいところだろう。現時点で一般公開の予定はなく、そもそも「汎用の代替にはならない」と開発元自身が明言している。

理由は3つ。第一に、この設計が意味を持つのは、数万人規模の技術者か大量のエージェントがコードを書き続けるような、本当に巨大なモノレポだけであること。第二に、既存の仕組みから逸脱しているため、導入企業は開発工程のあらゆる部分を移行し直す必要があり、専用のレビュー基盤・コード検索・テスト自動化まで丸ごと要求されること。第三に、「万人を満足させる公開版を作っても大して役に立たない」と自ら書いていること。社内版は自社向けに作り込まれすぎている、という判断だ。

【IT小僧の見立て・推測を含む】この判断は誠実だと思う。社内でしか回らない前提の塊を無理やり製品化した例を、IT小僧は何度も見てきた。たいてい誰も幸せにならない。加えて同社は「社内利用でトークンを使い倒せるのは当社が特異なだけ」とも書いている。ただし将来、主要なホスティング事業者と組んだ形で技術要素だけが降りてくる可能性は十分ある。

Git側の対応と、バージョン管理サービスの今後

では既存勢は何もしていないのか。そんなことはない。部分クローンや疎なチェックアウト、疎なインデックスといった標準機能は年々強化されている。Microsoftが実務から育てたScalar（スカラー）は、その設定とファイル監視を自動化してくれる。

Metaが公開するSaplingのように、独自クライアントで操作体系ごと刷新する系譜もある。

近年はJujutsu（ジュジュツ）も注目されているが、冷静な評価も出ている。2026年7月時点の比較記事では、部分クローン非対応などの制約から「移行しても一番遅い箇所が改善されない」と指摘されていた。乗り換えが目的化するのは、いつの時代も危険だ。

そして今回の発表で最も実務的に価値があるのは、実は提言部分だ。サーバはクライアントと同じ仕組みで動く必要はない。サーバ側に包括的な手続き呼び出しを用意し、事業者をまたいだ標準として整備し、クライアントがそれを喋れるようにすればいい。取得交渉の手順も今の形である必然性はなく、疎な取得と浅い取得ももっとうまく組み合わせられるはずだ、と。

つまり「乗り換えろ」ではなく「サーバ実装を進化させろ」という提案だ。同社は今後6か月から12か月でこの種の問題が一般化すると予測し、各社が個別に同じ壁にぶつかるのは技術者資源の浪費だとして、主要なホスティング事業者や公開ソフトウェアの共同体と協調する姿勢を示している。ここは素直に評価していい。

もうひとつ現場に効く示唆がある。「エージェント規模ではマージ待ち行列という仕組み自体が成立しない」という指摘だ。テスト実行中に数百から数千件が取り込まれる世界では、全体を止めて順番待ちさせるやり方が機能しない。だから統合前ではなく、統合後と配備前の自動検査に投資を振り替えた。衝突は起きるが、修復は人間が気づくより速く終わる、と。

IT小僧の結論

あなたの会社のリポジトリは、履歴100GB・1日2,500万回の取り出しに達しているだろうか。達していないなら今日やることは何も変わらない。既存の分散型は依然として正しい選択だ。これは断言できる。

ただし「うちには関係ない」で終わらせるのは早い。注目すべきは新システムではなく、「人間の手の速さ」を前提に設計された開発基盤が、どこから順番に壊れるのかという順序のほうだ。最初に悲鳴を上げたのはソースコード管理だった。次はビルド、その次はテスト自動化、最後にレビュー工程が来る。この順番は規模が小さくても同じ形で現れる。

7人で5か月、というのも噛みしめる価値のある数字だ。従来なら数年と多人数を要した基盤刷新が成立してしまった。一方で原文には、技術者の役割は設計上の判断と、暴走しがちな自動生成に「それはやるな」と言うことだった、とも書かれている。書く速度が上がったぶん、止める判断の価値が上がった。現場感覚として、まったくそのとおりだ。

出典：同社公式エンジニアリングブログ「Redesigning source control at Anthropic」（2026年10月13日公開）ほか。