Anthropicにおけるソース管理の再設計：ClaudeはGitの限界を超えた
Anthropicは、Claudeの支援によりモノレポの1日当たりのマージ数が2026年5月の約2,500件から9月には3万件超へ増加したことを受け、Gitを置き換えた。この急増により、Anthropicにおけるソース管理の再設計は単なるインフラ移行の物語ではなくなった。AIが、開発システムが安全に受け止められる速度を上回ってコードを生成したときに何が起こるかを示している。
同社は、オンラインのエージェント、サーバーサイドの操作、巨大なリポジトリへのスパースアクセスを前提に設計された社内ソース管理システム、Scionを構築した。7人のエンジニアは、新たなコードレビューシステムであるAntiqueと、複数の関連サービスも開発した。Anthropicによると、チームは5か月で移行を完了したという。
重要な対立軸は、単にScion対Gitではない。人間の注意力を前提に設計された開発プラクティスと、エージェント規模のコード生産との対立である。GoogleとMetaはすでに、巨大なモノレポのための専用システムを構築してきた。Anthropicは、オフラインで作業する必要がまったくないソフトウェアエージェントの群れという、異なる圧力源によって同様の到達点に至った。
Anthropicにおけるソース管理の再設計は、1日3万件のマージから始まった
AnthropicがGitを捨てたのは、エンジニアがGitを嫌っていたからではない。Claudeがリポジトリトラフィックの形と量を変えたからだ。
Anthropicのエンジニアリング解説によると、1日当たりのマージ数は2026年5月から9月にかけて10倍以上に増加した。同社はこの成長を、一時的な移行時の急増ではなく、継続する需要として位置付けている。
その結果生じた負荷は、コミット作成をはるかに超えていた。Anthropicのmainブランチの履歴は100 GBに迫り、圧縮された作業コピーは25 GBを超えた。継続的インテグレーション、すなわちCIは、開発者環境、エージェントサンドボックス、研究ジョブを含める前の時点で、毎日およそ2,500万回のコードチェックアウトを実行していた。
Anthropicの試算では、これらのチェックアウトを単純にフェッチすると、Gitトラフィックは1日当たり600ペタバイトを超える。同社は、シャロークローン、スパースチェックアウト、リポジトリスナップショット、数百台の社内Gitミラーを用いて、このコストを抑えていた。
こうした対策で時間は稼げたものの、リポジトリの変化速度はさらに速まり続けた。スナップショットは更新の合間に古くなった。部分クローンは、履歴検索、diff、最終的に各行を変更した人物を特定するblameなどの操作も複雑にした。
同社の問題は、Gitの強みとAnthropicの主要クライアントとの間にあるミスマッチに起因していた。Gitは、各クローンに自己完結型リポジトリとして動作するための十分な情報を与える。この設計は、オフライン開発、ローカル履歴、分散型コラボレーションを支える。
Anthropicのエージェントと自動化ジョブはすでにオンラインだった。完全なローカル履歴も、独立したサーバーとして機能する能力も必要としていなかった。それでもインフラは、すべてのクライアントがノートPCを使う人間の開発者であるかのように、リポジトリデータを繰り返し配布・維持していた。
Scionはこの前提を覆す。サーバーが履歴クエリの実行、コミット作成、diffの計算、マージやリベースの処理を担う。軽量クライアントは、上限のあるキャッシュを維持し、現在のタスクに必要なファイルだけを実体化する。
研究ジョブがモノレポ全体ではなく1つのディレクトリだけを必要とする場合、この違いは重要になる。CIサービスがdiffまたはマージベースの計算だけを必要とする場合も同様だ。Scionは、従来型の作業コピーを作成せずに、APIを通じてこれらの要求に応えられる。
Anthropicによると、新アーキテクチャは社内で大きな改善を生んでいる。各キャッシュ階層のヒット率は99パーセントを超えているという。インフラのCPUとメモリ使用量は、従来のGitミラー群の200分の1だ。
Anthropicはまた、CIと研究用チェックアウトが数分から数秒へ短縮されたとしている。この変更により、CIのCPU容量の25パーセントがより広範なコンピューティングフリートへ戻された。
これらは社内システムについて同社が報告した測定値である。外部の研究者は、Anthropicのワークロード、リポジトリ、インフラにアクセスできないため、再現できない。それでも、この数値はGitのさらなるチューニングがもはや十分に見えなくなった理由を説明している。
必要だったのは単に大規模なリポジトリを支えるシステムではない。主要な書き手、読み手、自動化された利用者が機械速度で動作するリポジトリを支えるシステムだった。
Claudeはソフトウェアインフラをボトルネックに変えた
Scionの真の意義は、コード生成がAnthropicにとって希少資源ではなくなったことにある。制約となったのは、レビュー能力、インフラ、そして判断だった。
AIコーディングアシスタントは当初、なじみ深い開発プロセスに収まっていた。人間が関数を依頼し、出力を確認し、テストを実行して、プルリクエストを提出する。アシスタントは、周辺システムを変えることなく、個々の開発者の入力速度を高めた。
Anthropicが説明するのは、より高度な運用モデルだ。Claudeは、研究ループを反復し、複雑なプログラムを最適化し、サービスを作成し、本番コンポーネントを監視し、大規模な移行を支援しているとされる。各活動は新たな変更を生み出したり、新しいリポジトリアクセスを要求したりする可能性がある。
このパターンは、圧力を乗算的に高める。1つのエージェントは、先行する変更がテストを通過する間に別のタスクを開始できる。自動レビューアーは修正を要求でき、それが追加の変更を生む。CIシステムはその後、候補ごとにチェックアウトを作成し、さらなるリポジトリクエリを実行する。
Simon Willisonが取り上げたグラフは、2026年中の急激な増加を示している。Willisonはこの加速をAnthropicの新しい社内モデル世代と結び付けつつ、社内での利用可能時期と一般公開日を慎重に区別した。
Anthropicはより具体的なつながりを示している。Scionの開発は、Claude Mythos PreviewとClaude Tagが社内で利用可能になった頃に始まったという。これらのモデルはScionの必要性を高める一方で、チームによる構築も支援したとされる。
一例は、GitからScionへデータを移すパイプラインに関するものだ。Anthropicのエンジニアは、最初のプロトタイプを手作業で書いていた。その後、Claude Mythos Previewの初期社内バージョンが、わずかな追加指示でパイプラインを書き換えた。
置き換え後のパイプラインは、メモリ使用量を20分の1に抑え、4倍高速に動作したとされる。Anthropicによると、取り込み順序やデータ構造に関する暗黙の要件も維持されたという。この主張は印象的だが、独立ベンチマークではなく、同社が説明した結果にとどまる。
より広いフィードバックループは、より容易に確認できる。コード生成の高速化がリポジトリ活動を増加させた。その活動が新しいインフラを正当化した。そしてClaudeがそのインフラの構築を支援し、コード生成に対する別の制約を取り除いた。
このループは、開発ライフサイクルのあらゆる部分に圧力をかける。人間のペースによる変更を処理するビルドサービスは、エージェントが数千の並行タスクを作成すると高コスト化しうる。テストスイートの実行中にリポジトリが数百の変更を通過するなら、レビューキューの有用性は低下する。
ナレッジへのアクセスも制約の一部になる。エージェントに必要なのはソースファイルだけではなく、仕様、アーキテクチャ上の意思決定、インシデント履歴、オーナーシップの文脈だ。類似のワークフローを構築するチームには、より高速なコードインフラと並んで、検索可能なエンジニアリングナレッジベースが必要になる。
Anthropicは現在、個別のScionコンポーネントに対して「superfans」と呼ばれる永続的なClaudeモニターを利用しているという。これらのエージェントは専用のSlackチャンネルを通じてテレメトリーとログを監視する。従来のアラートも維持される一方、エージェントは固定しきい値では見逃されうるパターンを探す。
この運用モデルは、エンジニアリング作業をより上位の層へ移す。人間は不変条件を定義し、アーキテクチャ境界を選択し、障害を解釈し、何を本番環境に到達させるかを決める。エージェントは、その境界内で実装を生成し、テレメトリーを調査する。
この変化はエンジニアを不要にするものではない。希少なスキルを、コードを書くことから、どのコードが存在する価値を持つかを決めることへと変える。
ScionはGitのオフラインモデルをエージェント規模のサービスに置き換える
Scionは、Gitを特徴付ける対称性、すなわちクライアントがリポジトリの完全な知能を持つという性質を手放すことでスループットを得ている。
Gitのコミットには、完全なディレクトリツリーへのポインタが含まれる。クライアントはpackfileと呼ばれる圧縮オブジェクト集合をやり取りし、ローカルリポジトリが履歴を保持して独立して動作できるようにする。このモデルは、大半のソフトウェアプロジェクトにとって今なお適切である。
Scionは、親に対する変更済みファイルを記録する先行書き込みログのエントリであるchangesetを使用する。ファイル内容は圧縮され、コンテンツアドレス指定され、個別に保存される。コンテンツアドレス指定とは、ストレージキーがデータから導出されることを意味し、不変オブジェクトを安全にキャッシュできる。
changesetはサーバー上で作成され、システム全体で利用可能になる。クライアントが大きなpackfileを構築・アップロードする必要はない。また、コミット操作のたびにグローバルなブランチポインタを移動することも避けられる。
Scionは、ブランチやタグなどのポインタを意味する参照も引き続きサポートする。しかしAnthropicは、mainラインとリリースブランチ以外の参照の大半を推奨していない。コミットレートが上昇するにつれ、グローバルに調整された状態はますます高コストになる。
このシステムは、履歴情報を派生データとして別個に計算する。ファイル履歴、blame、コピー、コミットグラフ内の関係について専用インデックスを構築する。これらのインデックスは即時に生成することも、利用者が要求するまで遅延させることもできる。
この分離により、Anthropicはすべてのクライアントを変更せずにインデックスを変更できる。また、どのタスクにも必要とされないデータの計算をサービスが回避できる。
Scionのチェックアウトプロトコルも同じ原則に従う。クライアントは、自分がすでに保有するものの完全な状況をネゴシエートするのではなく、特定のツリーとファイルオブジェクトを要求する。保存されたオブジェクトは決して変化しないため、リージョナルキャッシュサーバーは大半の要求を満たせる。
各コンピュートノード上のデーモンは、ローカルジョブ間でキャッシュ済みオブジェクトを共有する。リージョナルキャッシュサービスは、そのデーモン群と権威あるScionサーバーの間に配置される。Anthropicは、リージョナルキャッシュの障害が中央サービスを圧倒しないよう、この階層を強制している。
スパースチェックアウトは、選択したディレクトリのみを要求する。仮想化チェックアウトは、プロセスが読み取る時点でファイルを作成する。一部のジョブはファイルシステムを完全に省略し、APIにdiff、履歴結果、またはマージベースを要求する。
この設計は、モノレポ規模に対する以前の対応策に似ている。Googleは、巨大で中央集約型のコードベースを支えるインフラの一部としてPiperを説明してきた。同社が公開したモノレポ分析は、共有コード、統一された依存関係、組織横断的な変更の利点を記録している。
MetaはSaplingという別の道を選んだ。これは、使い慣れた分散ソース管理の概念を維持しつつ、社内リポジトリの規模へ拡張するシステムだ。Metaによると、そのサーバーは数千万のファイル、コミット、ブランチを処理できる。公開されているSaplingの設計は、Gitリポジトリとローカル開発者ワークフローもサポートしている。
Scionは両方の歴史から教訓を借りているが、その主要な前提はより限定的だ。主なクライアントは常時オンラインで、多くの場合自動化されており、リポジトリ全体を必要とする可能性は低い。これにより、サーバーは同期パートナーではなく、ソース管理データベース兼コンピューティングサービスとなる。
その代償は依存性だ。Scionクライアントは意図的に保持するデータを減らし、ローカルで実行する操作も少なくしているため、Gitの完全なオフライン動作を再現できない。したがって、ネットワークや中央サービスの障害は異なる形で影響する。
移行コストはコマンドラインクライアントにとどまらない。Anthropicはコード検索、アイデンティティおよびアクセス制御、CI統合、そしてAntiqueを構築する必要があった。同じ設計を採用する企業は、開発プラットフォームの大部分を置き換える必要がある。
これが、Scionが一般的なチーム向けのAnthropic版Git代替ではない理由だ。これは、一つの例外的なワークロードのための垂直統合システムである。
より高速なマージがコードレビューをより難しい問題にする
未解決の問いは、Scionが3万件の変更を受け入れられるかどうかではない。その速度でAnthropicが説明責任を維持できるかどうかだ。
Anthropicによれば、Scionでの変更はすべて依然として人間のレビューを受ける。レビュアーは現在、すべての行を読むのではなく、変更の意図に注目している。この選択は変更量に起因するが、同時にテスト、エージェントの説明、自動分析へと信頼の重心を移すものでもある。
意図のレビューでは、提案された変更がシステムの目標やアーキテクチャ上の規則に合致しているかを問う。行単位のレビューでは、その実装が正しく動作するかを問う。強力な自動チェックは両者を結びつけられるが、どのテストスイートもすべての暗黙の要件を捉えることはできない。
Anthropicは、エンジニアがしばしばClaudeに「ノー」と言わなければならなかったと認めている。エージェントが局所的にはもっともらしいパターンを選択しても、システム全体の制約に違反する場合があった。一部の生成コンポーネントは、権威あるマージ時刻をAntiqueに問い合わせる代わりに、コミットログを線形に走査しようとした。
敵対的なレビューは別の失敗モードも生んだ。Claudeは仮説上のリスクに対し、過剰な検証や複雑さで応じることがあった。防御的プログラミングがシステム改善に寄与しなくなる時点を判断する必要があったのは、人間のエンジニアだった。
これらの例は、より優れたモデルが直接的により優れたソフトウェアを生むという単純な主張を複雑にする。エージェントは価値ある最適化を見つける一方で、不必要な仕組みも生み出し得る。高い出力量は、両方の振る舞いを増幅する。
Anthropicによれば、同社チームはScion向けにシミュレーション、ファズテスト、レート制限を構築した。ファジングは予期しない入力を与えて欠陥を露出させ、密閉型シミュレーションは隔離された環境でインフラの挙動を再現する。これらの制御は、マージ件数だけよりも強い証拠を提供する。
それでも、マージ量は品質指標ではない。変更は小規模、実験的、生成済み、取り消し済み、あるいは顧客向けの進捗と無関係である可能性がある。1日3万件の変更は並外れた活動量を示すが、信頼性や事業価値を独立して示すものではない。
公開された開発者の反応は、この区別に集中している。Hacker Newsの議論では、一部の読者がAnthropicはモノレポを再考すべきではないかと疑問を呈した。一方で、従来のコミットの仕組みよりも、意図、来歴、継続的な検証の方が重要だと主張する人もいた。
そのスレッドで応答したAnthropicのエンジニアは、モノレポの一貫したツール群とアトミックな変更を擁護した。同じエンジニアは、Scionがテキスト上の競合を阻止する一方、並行変更間の意味的競合を排除することはできないと明確にした。
意味的競合は、個別には有効な二つの編集が組み合わさることで誤った動作を生む場合に発生する。一方の変更が関数を変更して呼び出し元を更新する一方、別の変更が同時に新たな呼び出し元を追加するかもしれない。ファイルはきれいにマージできても、統合後のプログラムは誤っている可能性がある。
従来のマージキューは、次のバッチを受け入れる前に提案されたリポジトリ状態をテストすることで、このリスクを低減する。Anthropicによれば、テスト実行中に数百、数千の変更が取り込まれる状況では、グローバルなリポジトリロックは現実的ではない。
同社は投資の重点を、マージ後およびデプロイ前のテストへ移している。このアプローチにより、チェックが安全に本番へ到達できるものを判断する間も、リポジトリのスループットを継続できる。
これが、Anthropicにおけるソース管理再設計の中核的なトレードオフだ。Scionはソース管理から直列化を取り除くが、何らかの直列化は依然としてデプロイ、データ移行、人間による意思決定の局面に存在する。リスクは消えるのではなく、移動する。
Anthropicは、人が競合を特定するよりも速くClaudeが並行競合を解決できると述べている。この回答は修復速度には応えるが、検知されない相互作用のコストには答えていない。安全性は、監視が問題をどれだけ迅速に検出できるか、またシステムがどれだけ効果的に問題を隔離または元に戻せるかに依存する。
ディレクトリ単位のアクセス制御と意味論的な承認ルールは役立つ。Anthropicによれば、Antiqueはコメントのみの変更と、センシティブなロジック変更を区別できる。そのため、人間の注意をより大きな結果を伴う変更に集中させられる。
残る検証上の隔たりは大きい。Anthropicは、独立した欠陥率、ロールバック頻度、インシデント傾向、あるいはエージェントが作成・レビューした変更の割合を公表していない。これらの指標がなければ、外部の人々はスループットの向上と下流リスクを比較できない。
したがって、他チームにとって最も有用な教訓は、Anthropicのマージ件数を追うことではない。仕様からデプロイまでの経路全体を測定することだ。有用な指標には、流出した欠陥、レビュー遅延、失敗した変更、ロールバック、重複作業、コンテキスト復元に費やした時間などが含まれる。
個人向けのAIワークフローは、エージェントがより多くの成果物を生成するなかで、エンジニアが意思決定と来歴を保持する助けになる。しかし、保存されたコンテキストが役立つのは、チームがそれを強制可能なテスト、責任の所在、レビュー方針に結びつける場合に限られる。
Anthropicのソース管理実験が次に変えるもの
次の段階では、エージェント規模の開発が移転可能なエンジニアリングモデルになるのか、それとも高コストなAnthropic固有の例外にとどまるのかが試される。
最初に注目すべき兆候は、Anthropicが約束しているAntiqueに関する説明だ。ソース管理は変更の保存・取得方法を説明するが、極端な変更量の下で意図、責任範囲、承認を維持する方法を決めるのはコードレビューである。
Antiqueのレビューモデルに関する詳細が、明確な来歴とリスクに基づく人間の介入を示すなら、Anthropicの主張は強まるだろう。測定可能な検証なしに、レビューが主としてモデルによる要約に依存しているなら、その主張は弱まる。
二つ目の兆候は、時間の経過に伴うソフトウェア品質だ。Anthropicがマージスループットと併せてロールバック率、流出した欠陥、サービスインシデント、その他の成果指標を公表すれば、同社のインフラに関する主張はより説得力を持つ。
信頼性が安定または改善すれば、エージェントがリスクを比例して増加させずに変更量を増やせるという考えを支持することになる。リグレッションや緊急修正が増加すれば、Scionがガバナンスよりも速く本番投入を加速したことを示唆するだろう。
三つ目の兆候は、Gitプラットフォームや大規模エンジニアリング組織がどう反応するかだ。ほとんどの企業はGitを置き換えないだろうが、サーバー側メタデータAPI、仮想化ワークスペース、リスクを考慮したレビュー、並行エージェントへのより良い対応を採用することはできる。
MetaのSaplingは、馴染みあるワークフローとの互換性を維持する一つの道筋をすでに示している。MicrosoftのScalarおよび関連するGit改善は別の道筋を示しており、データモデルを置き換えるのではなく、大規模リポジトリ向けにGitを拡張している。
Anthropic自身は、こうした圧力が6〜12カ月以内に広がると予想している。この予測は企業としての判断であり、測定された市場トレンドではない。その妥当性は、他組織がAnthropic社内のトークン利用やClaude使用の異例な集中なしに、同様の限界へ到達するかどうかにかかっている。
Scionはまた、競合他社が避けるかもしれない戦略的な依存関係を導入する。Anthropicはモデル、リポジトリサービス、レビュー画面、オブザーバビリティエージェント、デプロイワークフローを管理している。この統合は反復を速めるが、開発環境の再現や置き換えを困難にする。
大半の組織にとって、Gitは依然として賢明なデフォルトであり続ける。幅広い相互運用性、成熟したツール、持ち運び可能な履歴、オフラインでの耐障害性を備えている。Scionのアーキテクチャが魅力的になるのは、リポジトリのトラフィックがすでにそれらの利点を圧倒した場合に限られる。
より差し迫った変化は、マネジメントに関するものだ。エンジニアリングリーダーは、生成されたコード量を目標として扱うことをやめなければならない。より多くの出力が価値を生むのは、チームがそれを安全にレビュー、テスト、デプロイ、監視、撤回できる場合に限られる。
開発者も、自分たちの仕事が変化することを想定すべきだ。Anthropicの説明では、システム設計、アーキテクチャ上の制約、評価、拒否により大きな比重が置かれている。エンジニアはますます、エージェントが迅速に動ける境界を定義する存在になる。
したがって、Anthropicにおけるソース管理の再設計は、そのパフォーマンスの物語とともに警告も示している。コードが安価になると、弱い仕様、欠けたテスト、不明確な責任境界のすべてが、機械の速度で再生産され得る。
有用な問いは、あなたのチームがScionを必要としているかどうかではない。エージェントが来四半期に10倍の変更を生み出した場合、既存のレビュー、CI、ナレッジシステムが信頼に値する状態を維持できるかどうかだ。その能力を今測定し、最初に破綻する統制を特定し、マージ量の増加が到来する前に強化すべきである。
