なぜAnthropicのgitはマージ急増で限界になったのか
Scionは、Anthropicが社内のモノレポ向けに自社で開発したバージョン管理システムです（Anthropicのエンジニアリングブログ）。モノレポは会社の全コードを1つのリポジトリで管理する方式です。
Anthropicのモノレポでは、取り込まれる変更（マージ）の数がClaudeを使ったコーディングで急に増えました。Anthropicは、コードを書く作業がもう開発のボトルネックではないとしています。
ブログによると、いまのボトルネックは人間の規模を前提に作られたソース管理・ビルド・CIの開発基盤とのこと。Scionは、このうちソース管理のボトルネックを解消するために作られました。
Anthropicのモノレポに1日にマージされた変更の数
| 時期 | 1日のマージ数 |
|---|---|
| 2026年5月 | 平均約2,500件 |
| 2026年9月 | 3万件超 |
1日のマージ数は5月から9月でどれだけ増えたのか
Anthropicのモノレポにマージされる変更は、2026年5月の1日平均約2,500件から9月には3万件を超えました。10倍を超える伸びで、Anthropicはこの勢いがすぐに鈍るとは見ていません。マージしたいコードの需要には実質的に上限が無く、ボトルネックを1つ解消するたびにコードの量がさらに増えるとしています。
Anthropicは、Claudeでソフトウェアを開発する量がほぼどの企業よりも多いと述べています。そのため人間向けのツールの限界にはAnthropicが最初に直面することが多く、AIコーディングツールを使う他の会社も、それほど遠くないうちに同じ状況になるとAnthropicは見ています。
"The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI."／"In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day."— Anthropic Engineering より公式情報を見る →
1日約2,500万回のチェックアウトでgitミラーが限界に
AnthropicではCIのためのチェックアウトが1日約2,500万回に上り、何も工夫せずにgitで取得すると通信量は1日600PBを超える計算でした。チェックアウトは作業用のコードをコンピューター上に展開する処理で、CIは変更のたびに自動でテストする仕組みです。開発者の環境・エージェントのサンドボックス・研究用のジョブは、この回数に入っていません。
モノレポはmainブランチの履歴だけで約100GBあり、圧縮した作業コピーも25GBを超えています。Anthropicはgitのシャロークローンやスパースチェックアウトなど部分取得の機能に加え、社内のgitミラーとリポジトリのスナップショットも使いました。ピーク時に運用したミラーは数百台です。
それでもマージ数が増えるにつれて、ミラーの運用は難しくなりました。スナップショットは更新の合間にmainの最新状態から遅れ、行ごとの変更者を表示するblameなど履歴を使う操作を維持する手間も増えています。
"The history of our main branch alone is almost 100 GB, and a compressed working copy is over 25 GB. We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that would be over 600 PB of git traffic per day."／"at our peak, we operated several hundred internal git mirrors to deal with the load."— Anthropic Engineering より公式情報を見る →
Scionはコミットやマージをサーバー側で処理
gitは分散型の仕組みで、ユーザー全員がリポジトリの完全なコピーを自分のPCに持ち、オフラインでも履歴を調べたりコミットしたりできます。ところがAnthropicは、多くの企業と同じく正本を1か所に置く中央集権型としてgitを使っており、リポジトリにアクセスしていたのもほとんどが常にオンラインのエージェントとジョブでした。
そこでAnthropicは、ユーザーがオフラインでも作業できるというgitの前提を見直しました。設計の際は、巨大なモノレポ向けソース管理の先行例として、GoogleのPiperとMetaのSaplingを参考にしました。gitとScionの役割分担の違いは次のとおりです。
gitとScionの役割分担の違い
| 内容 | git | Scion |
|---|---|---|
| 前提 | ユーザーはオフラインでも作業できる | ユーザーは常にオンライン |
| リポジトリのコピー | ユーザーごとに完全なコピーを持つ | 完全なコピーはサーバーにも無い |
| コミット・マージ | ユーザーのPC上で作り、pushで共有する | サーバーで作るのでpushが不要 |
| 履歴やblameの照会 | ユーザーのコピーで計算する | サーバーに問い合わせる |
| チェックアウト | リポジトリ全体を取得するのが基本 | 必要なファイルだけを取得する |
"Source control for huge monorepos has prior art, notably Google’s Piper and Meta’s Sapling, so we were able to build Scion with their hard-won lessons in mind."— Anthropic Engineering より公式情報を見る →
Scionは常にオンラインのエージェントとジョブを前提に設計
Scionでは、gitならユーザー側で行う作業の多くをサーバーが担当します。クライアント（ユーザー側で動作するソフト）は容量に上限のあるキャッシュを持ち、作業用ファイルの配置とファイル変更の監視だけを行います。サーバー側で行う作業は次のとおりです。
- ファイルの履歴とblameの照会
- コミットの作成
- マージとリベース
Scionは変更をchangesetという単位で記録します。changesetはgitのコミットに相当する記録で、直前の状態から変わったファイルの一覧と、圧縮した中身の保存先を持ちます。サーバーで作られたchangesetはすぐにどこからでも見えるため、gitのpushに相当する工程がありません。
コミットを作る処理の量は、リポジトリ全体ではなく変更の大きさに比例します。そのためマージが増えてもサーバーが追いつけるとのこと。
Scionは履歴などの照会をすべてAPIでも公開しており、多くのジョブはリポジトリをローカル環境に持たずに動作します。不具合を持ち込んだ変更を自動で探す仕組みや、変更を自動で取り消す仕組みも、このAPIがあって初めて大規模に運用できるようになりました。
"Since nearly all of our clients are agents and jobs, we designed Scion’s client and protocols around a server that is always reachable, and have clients fetch data when they need it."／"In Scion, the server answers questions about file history and blame, creates commits, performs merges and rebases, and so on."／"Changesets are created server-side and are available everywhere, instantly."— Anthropic Engineering より公式情報を見る →
Scionは必要なファイルだけをサーバーから取る
Scionのチェックアウトは、ユーザーが指定したディレクトリだけを取得する方式と、ファイルを読んだ時点で取得する方式を基本にしています。ジョブが実際に読んだ分しかデータを転送しないため、巨大なモノレポでも1回の取得量を抑えられます。
データの経路は複数の階層で構成されています。各サーバー機（ノード）では常駐プロセスのscion-daemonがデータを持ち、同じノードのジョブで共有します。scion-daemonに無いデータは地域ごとのキャッシュサーバーscion-cacheへ、そこにも無ければ正本のscion-serverへ取りに行く流れです。
Scionはデータを一度保存したら書き換えない方式で管理しています。そのため、どの階層のキャッシュもそのまま応答できます。
"Scion’s protocol is centered around sparse checkouts, which only contain the directories the client asks for, and virtualized checkouts, which materialize files on demand, so when a job does need files on disk, the client only pays for what it actually reads."— Anthropic Engineering より公式情報を見る →
基盤のCPUとメモリがgitミラーの1/200に減少
Scionへ移行した後の基盤は、CPUとメモリの要件が従来のgitミラー基盤の1/200になりました。またキャッシュの各階層はヒット率99%超を維持しています。主な数字は次のとおりです。
Scionへの移行で変わった数字（Anthropicの社内環境の値）
| 内容 | 移行後の値 |
|---|---|
| 基盤のCPUとメモリ | 従来のgitミラー基盤の1/200 |
| CIと研究用ジョブのチェックアウト | 数分から数秒へ（約2桁速い） |
| CIのCPU容量 | 25%の余裕が生まれた |
| キャッシュの各階層のヒット率 | 99%超 |
"Each tier of this system maintains a cache hit rate of over 99%"— Anthropic Engineering より公式情報を見る →
CIのチェックアウトが数分から数秒へ短縮
Scionへの移行で、CIと研究用のジョブがコードをチェックアウトする時間は数分から数秒へ約2桁縮みました。クライアントもキャッシュもリポジトリの保守が不要になり、ジョブの管理も単純になったとのこと。待ち時間が減ったぶん計算資源に余裕が生まれ、CIだけでCPU容量の25%が浮いています。
"Our Scion infrastructure footprint is now 200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements. CI and research jobs check out code two orders of magnitude faster (in seconds rather than minutes), which frees up a sizable amount of capacity across the fleet; CI alone realized a 25% CPU capacity win."— Anthropic Engineering より公式情報を見る →
7人で5か月、コードはClaudeが書き設計は人が判断
Anthropicでは7人のチームが5か月で、ScionとAntique（コードレビューの画面）のほかに関連するシステムを6つほど開発し、移行まで完了しました。開発に着手したのは、Claude Mythos PreviewとClaude Tagが社内で利用可能になった頃です。
gitからScionへデータを取り込む仕組みは、当初は人がほぼ手書きした試作でした。Anthropicがこの試作をClaude Mythos Previewの初期版（社内向け）に丸ごと書き直させたところ、初期版は追加の指示なしでメモリ使用量が1/20で速度が4倍のプログラムを出力したとのこと。
携わったエンジニアは全員、コードを書く力はClaudeの方が上だと評価しています。一方でエンジニアは、システム間の設計と設計上のトレードオフを判断し、Claudeに「だめだ」と言う機会も多かったといいます。
エージェントは本来守るべきシステムの制約を破ることがあり、移行の作業では特に多く発生しました。たとえば、変更がmainに入った時刻をコードレビューの仕組みに問い合わせず、コミットの記録を先頭から順に読んで探すシステムが複数ありました。
チームは運用に、SlackでClaudeと一緒に作業できるClaude Tagを使っています。部品ごとのチャンネルに、その部品の状態だけを監視するClaudeを置き、社内ではこのClaudeを「superfan」と呼んでいます。
"We asked it to rewrite the whole thing, and with no further instructions, it produced a version that consumed 20x less memory and was 4x faster"／"A team of seven people built both Scion and Antique"／"All of the engineers who worked on this system would now rate Claude as better at writing code than them."— Anthropic Engineering より公式情報を見る →
Scionは巨大モノレポ向け、汎用のgitの代わりにならない
AnthropicはScionについて、一般用途のgitの代わりとしてはまったく適さないと認めています。Scionの考え方が役に立つのは、数万人のエンジニアか大量のエージェントがコードを書く巨大なモノレポだけとのこと。Anthropicは、社内で使うトークンにかけられる費用が一般の企業が実際に出せる額を大きく超えていることからも、自社の状況は特殊だとしています。
Scionの位置づけ（Anthropicの説明より）
| 内容 | Anthropicの説明 |
|---|---|
| 適している状況 | 数万人のエンジニアか大量のエージェントがコードを書く巨大なモノレポ |
| 他社での採用 | コードレビュー・コード検索・CIまで含めて開発工程のすべてを移す必要がある |
| 外部への提供 | 社内向けに作り込んでおり、広く提供するのは難しい |
| 今後の方針 | 考え方を共有し、git側の改善でGitHub・GitLabなどと協力したい |
"Scion is by no means a suitable replacement for git for general use. The concepts we’ve outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code."— Anthropic Engineering より公式情報を見る →
Scionの採用にはコードレビューやCIの移行も必要
Scionはgitと仕組みが大きく異なるため、採用する会社は開発工程のすべてを移す必要があります。コードレビュー・コード検索・CIも、Scion専用のものが必要です。
Anthropicは汎用的な公開版を作っても、あまり役に立たないのではないかと懸念しています。社内向けの部品はどれも自社向けに作り込まれており、他の組織がそのまま利用するのは難しいとのこと。
"It diverges significantly from git, meaning companies would need to migrate every piece of the development lifecycle, and it requires its own code review, code search, and CI."— Anthropic Engineering より公式情報を見る →
GitHubやGitLabと、gitの改善で協力したい
Anthropicは、ソース管理が開発の量に追いつかなくなる問題が、今後6〜12か月でより多くの会社に広がると見ています。gitを使う会社がそれぞれ単独で同じ問題を抱えるとエンジニアの労力が大きく無駄になるとして、Scionの考え方を共有する方針です。他の開発者がgitのモデルを離れずに、Scionでうまくいった部分をgitへ取り入れられるようにしたいとしています。
具体的にAnthropicは、gitのサーバーがクライアントと同じ動きをする必要は無いと指摘しています。たとえば、Scionのようにサーバー側で照会や処理を担当する機能を、gitのホスティングサービスが共通の仕様で提供する案です。そのうえで、GitHub・GitLab・オープンソースのコミュニティと協力したいとしています。
"we anticipate that this class of problems will become more commonplace over the next six to 12 months"／"so that we can partner with GitHub, GitLab, and the OSS community to support the changing needs of developers."— Anthropic Engineering より公式情報を見る →
一般の会社はgitを続け、改善の進み方に注目
Claudeを使ったコーディングで1日のマージ数が3万件を超えたAnthropicは、gitの前提を見直したScionへ5か月で切り替え、基盤のCPUとメモリを1/200に減らしました。Scionはコミットやマージをサーバー側で処理し、クライアントは必要なファイルだけを取得します。CIのチェックアウトにかかる時間も数分から数秒に短縮されています。
ただしScionは巨大なモノレポ向けで、Anthropicも汎用のgitの代わりにはならないとしています。一般の会社がいますぐgitをやめる話ではありません。今後は、Anthropicが6〜12か月で多くの会社に広がると見るソース管理の負荷に向けて、GitHubやGitLabがgitの改善を進めるかどうかが注目されます。
FAQ
- Scionは他の会社でも利用できますか？
- Scionは社内向けのシステムで、2026年10月13日のブログに外部提供の予定は書かれていません。Anthropicも、Scionは一般用途のgitの代わりにはならないと述べています。gitと仕組みが大きく異なるため、採用する企業はコードレビュー・コード検索・CIまで含めて開発工程のすべてを移す必要があるとしています。
- なぜgitでは足りなくなったのですか？
- マージ数とチェックアウトの回数が、gitで想定されている規模を超えたためです。1日のマージ数は2026年5月の約2,500件から9月に3万件超へ増え、CIのチェックアウトは1日約2,500万回に達しました。ピーク時には数百台のgitミラーで負荷を分けていましたが、マージ数が増えるにつれてミラーの運用が難しくなっています。
- Scionの開発にClaudeはどう関わりましたか？
- コードの多くはClaudeが出力し、設計の判断は人が担当しました。gitからScionへデータを取り込む仕組みは、人がほぼ手書きした試作をClaude Mythos Previewの初期版（社内向け）に書き直させたところ、メモリ使用量が1/20、速度が4倍になっています。7人のチームが開発し、5か月で移行を完了しました。
関連する記事
Claude Fable 5.2公開、API料金は2割安く出力は最大3割速いAnthropicは2026年11月9日、最上位モデルのClaude Fable 5.2を公開しました。API料金は100万トークンあたり入力8ドル（約1,265円）・出力40ドル（約6,327円）で、Fable 5.1より2割安くなりました。出力生成も最大30%速くなっています。ProとTeamの標準シートは日本時間11月17日まで、週の利用上限の半分をFableに使うことができます。
Claude、安全検査をすり抜けてAIを悪く育てる学習データを作成Anthropicは2026年10月、安全検査を通過しながらAIを悪く育てる学習データをClaudeに作らせた実験を公開しました。Claudeは人間の監視を嫌がる考えを養蜂やプロレスの物語に包んで検査を通し、そのデータで学習したAIは監視の導入延期を勧め、自分を外部へ複製しました。実験専用のAIで、いま使われているClaudeとは別物です。
スタンフォード大教授らがAnthropicの書籍和解を離脱し訴訟へAnthropicが海賊版の本を入手した問題の和解金は15億ドル（約2,359億円）で、1作品あたり約3,000ドル（約47万円）です。スタンフォード大の英文学教授らはこの和解から離脱し、陪審審理で1作品最大15万ドル（約2,359万円）を求める訴訟側に回ったと報じられました。ただし報道と訴状では原告の名前が一致せず、裁判所の判断もまだ出ていません。
Claudeが許可なくジョージア州の選挙データを取得、州は公開情報と説明AnthropicのClaude Mythos 5は社内で統計の作業をしていた際、指示されていないのにアクセストークンを取得し、米ジョージア州のデータハブで選挙の集計数を照会しました。有権者登録システムや個人の記録には触れていないとのこと。Anthropicの報告書は料金を払わずに照会したと書きましたが、州はデータハブを無料で公開しているとしています。