Anthropicがコード管理ツールGitから脱却、AI開発の需要に適応する独自バージョン管理システム「Scion」を開発

Anthropicは業界標準のコード管理ツールであるGitを手放し、自社で「Scion」と呼ばれる新システムを独自開発した。

AIが人間に代わってコードを書き、コミット量が急増するにつれて、Anthropicが従来運用していたGitインフラは限界に達した。Scionの開発着手からリポジトリの移行完了まで、チームが要した期間は5か月だった。

この新システムの中心的な設計思想は、主に以下の3点にある：

• オンデマンド取得：稼働しているクライアントの多くは常時接続されたAIエージェントであり、毎回全履歴をダウンロードする必要はない。システムは特定のファイルが必要になった時点で初めて、サーバーから対応するコンテンツを取得する。
• サーバー主導の負荷処理：バージョン管理における複雑で負荷の高い計算処理の大部分をクラウドサーバー側で完結させ、クライアントはファイルをディスクに展開し、変更を検知し、軽量なキャッシュを維持する役割に特化させることで、ローカルマシンのリソース消費を大幅に削減している。
• より軽量な記録方式：変更を保存する際、システムは変更されたファイル一覧とコンテンツのポインタのみを記録し、変更セット（changeset）を作成する際にリポジトリ全体をロックする必要がない。ブランチの参照（refs）更新は別途行われ、多数のタスクが同時にコミットする際の調整コストや混雑を低減している。

なぜGitは限界を迎えたのか？（背景と課題）

Anthropicの社内では、コードを書くこと自体はもはやボトルネックではなくなった。Claudeが研究ループを自律的に回し、低レイヤーのプログラムを微調整し、さらにはゼロから新しいサービスを立ち上げることすら可能になったため、コードの生成速度は驚異的なレベルに達している：

• マージ数が12倍以上に急増：2026年5月時点では1日あたり約2,500件だったコードのマージ数が、9月には1日あたり30,000件超へと跳ね上がった。
• 巨大なリポジトリと膨大なトラフィック：メインブランチの履歴は100 GB近くに達し、圧縮後のローカルコピーでも25 GBを超える。CI（継続的インテグレーション）の実行に伴い、1日あたり約2,500万回のチェックアウトが発生していた。もし毎回圧縮コピーを完全に取得していれば、1日あたり600 PB以上のネットワークトラフィックが生じる計算になる。
• Gitの設計前提と負荷の乖離：Gitの本質は「分散型でオフライン作業を可能にする」ことにあり、デフォルトのフルクローンは全履歴を保持する。しかし、Anthropicにおけるコードクライアントの圧倒的多数は、常時オンラインのAIエージェントとクラウド上のCIタスクである。Gitを耐えさせるため、かつては数百台のミラーノードを運用していたが、マージ頻度が加速しメインブランチの更新があまりに早くなったことで、ミラーのスケールアウトやスナップショット（seeds）の更新、さらには一部のコピー上でのDiffやBlameの計算の維持管理がますます困難になっていった。

Gitのオフラインでの強みは、なぜここでは負担となったのか？

Gitの決定的な強みは、ローカルリポジトリが自己完結して動作できる点にある。ネットワークが切断されても、開発者はコードをコミットし、差分を比較し、既存の履歴を閲覧することができる。

この設計により、クライアント側には強力な機能が備わっている：

1. 分散型（Decentralized）：各開発者のローカルクローンは、それ単体で機能が完結した完全なリポジトリである。ネットワークが繋がらない新幹線や飛行機の中でも、オフラインで過去のコミットを確認し、差分（Diff）を比較し、各行のコードを誰が変更したか（Blame）を追跡できる。
2. P2Pアーキテクチャ（Peer-to-Peer）：クライアントとサーバーの機能は完全に対等である。開発者のノートPCは本質的に、いつでも外部にサービスを提供できるGitサーバーそのものである。
3. スナップショットの完全性（Full Snapshot）：各コミット（Commit）は論理上、プロジェクトのファイルツリー（Tree）全体に対する完全な記録であり、パックファイル（Packfile）と差分圧縮によってディスク容量を節約している。

中小規模のプロジェクトや一般的なオープンソースコミュニティにとって、この設計は極めてエレガントで堅牢である。しかし、履歴が優に100 GBを超える超大規模モノレポ（単一リポジトリ）において、大量のオンラインエージェントやライフサイクルの短いタスクが同一のコードを繰り返し取得する環境では、それぞれがローカルリポジトリを保持・管理すること自体が極めて大きなオーバーヘッドとなる。

Git自体も取得範囲を絞り込むツールを提供しており、Anthropicも一般的なスケール手法を採用していた：

• 多段ミラーアレイの構築：クラスタ内にGitミラー（Mirrors）を配置し、ピーク時には数百台を運用してプライマリリポジトリへのプル負荷を分散させた。

• コールドデータスナップショット（Seeds）：リポジトリのスナップショットをシードとしてオブジェクトストレージに保存し、新規ノードの起動時にはまずスナップショットをダウンロードしてから、少量の新規コミットのみを増分取得するようにした。

• 部分チェックアウトと浅いクローン：Gitの shallow clone（浅いクローン、直近のコミットのみを取得）や sparse-checkout（スパースチェックアウト、特定ディレクトリのみを保持）を活用した。

これらの対策によって負担はある程度緩和されたものの、同社の規模においては維持管理が急速に困難になっていった：

• スナップショットの陳腐化：マージのペースが加速するにつれ、定期更新されるシードスナップショットとトランク最新版との乖離が広がり、新規タスクはより多くの差分を追加取得しなければならなくなった。

• ミラーの容量と運用保守コストの増大：モノレポのトランク履歴は100 GB近くに達し、圧縮後のワーキングコピーでも25 GBを超えていた。リポジトリが肥大化し続ける中、ミラーのディスクやメモリ容量、メンテナンスコストがスケール上の制約要因となった。

• 部分コピーにおける履歴クエリの複雑化：部分クローンでは、クエリの実行に必要な履歴やオブジェクトが欠落している場合がある。これらのコピー上でDiffやBlameを正常に動作させるため、ツールチェーン側でデータの追加フェッチといった付加的なステップを処理する必要が生じた。

Anthropicは、自社のクライアントの大部分がオンラインのエージェントや自動化タスクであり、実際の開発コラボレーションは単一の信頼できるリポジトリ（オーソリティ）を中心に行われていることに着目した。そこで設計の出発点を根本から転換した。すなわち、クライアントは必要なデータのみを取得し、履歴クエリやコミット処理はオンラインサービス側に委ねるというアプローチである。

Scionはどの処理をサーバー側に委ねたのか？

「クライアントは常時オンラインである」という前提に立ち、AnthropicはGoogleのPiperやMetaのSaplingといった超大規模モノレポシステムの進化の知見を取り入れ、エージェント規模のワークロードに特化して自社開発したバージョン管理システムScionの「6つの柱」を確立した：

1. クライアント常時接続（Always Online）：オフラインで自律的に演算を行う負担を放棄する。クライアントは必要な時にのみサーバーへ特定データを要求し、デフォルトで完全な履歴コピーを保持することはしない。
2. 徹底した非対称性（Client-Server Asymmetry）：サーバーが唯一の計算ハブとなり、ブランチのマージ、リベース（Rebase）、コード帰属（Blame）の計算、履歴インデックスの作成などを担う。クライアントは軽量な役割に徹し、管理されたローカルキャッシュの維持やファイルをディスクへ投影する処理のみを担当することで、ローカルで必要とされるデータと計算リソースを最小化する。
3. サービス化されたAPIとしてのバージョン管理（API-First）：CIツールが「これら2つのコミット間にどのような変更があるか」や「この行は誰が書いたのか」を知りたい場合、ディスク上にリポジトリをクローンする必要はなく、サーバーのメタデータAPIを直接呼び出してクエリ結果を取得できる。
4. エンドツーエンドの水平スケールと全量実体化コピーの排除：システム内のどこにも、リポジトリ全体を完全に展開した実体は存在しない。Gitのような巨大で複雑なパックファイル（Packfile）を持たないため、リポジトリの定期的なアンパックや再圧縮といったメンテナンスも完全に不要となる。
5. 極限まで軽量な差分とロックフリーコミット（Lock-Free Changesets）：コミットは低コストかつ高速でなければならない。各コミットでは変更された差分ファイル一覧のみを記録し、リポジトリ全体のスキャンは絶対に行わない。変更セット（changeset）の作成とブランチ参照（refs）の移動を分離して処理することで、作成フェーズにおける調整のオーバーヘッドを削減する。
6. ワーキングディレクトリの完全任意化、デフォルトでのスパース化と仮想化：ディスクへの書き込みは極力避ける。コードのチェックアウトは指定ディレクトリのみの取得（スパースチェックアウト）をサポートするほか、仮想ディレクトリツリーのみを構築し、プログラムが実際にファイルを読み取る段階で初めてデータをストリーミングロードする（仮想化チェックアウト）方式を採る。

変更はどのように保存され、ファイルはどうやって取得されるのか？

これら6つの原則を具現化するため、Scionはデータ構造およびネットワークトポロジーにおいて独自のアプローチを採用している。

1. まず変更セットを記録し、ディレクトリツリーは後から導出する（Changeset）

Gitの低レイヤー構造では、1回のコミットはプロジェクトのルートディレクトリを表すRoot Treeオブジェクトを指している。たとえ1文字しか変更していなくても、Gitは最下層のリーフノードから上方へ向けてディレクトリツリーのハッシュの連鎖を再構築する。

Scionの中核的な記録方式はこれとは異なる。その論理的な最小単位は、先行書き込みログ（WAL: Write-Ahead Log）内の1件の変更セット（Changeset）である：

• 何を保存するのか：Changesetはメタデータ（作成者、コミットメッセージ、親ノードポインタ）と、第1親に対する変更ファイル一覧（例：変更された guide.md のハッシュ、削除された legacy.rs など）を記録する。ファイルの具体的内容は圧縮後、コンテンツハッシュに基づいてクラウドオブジェクトストレージ（Cloud Storage）へ直接書き込まれる。

• 何を排除したのか：Changesetにはリポジトリ全体のディレクトリツリー構造は保存されない。コミット時に複数サーバー間でパッケージ化を調整する必要はなく、グローバルなブランチ参照を更新する必要もない。

• ブランチの移動はデータベースの単一行操作：メインブランチ（Main Branch）参照の更新は、低レイヤーでは分散データベースGoogle Cloud Spannerの単一行データに対するCAS（Compare-And-Swap：比較交換）アトミック更新として抽象化されている。これによりコミット処理は完全に疎結合化され、スループットが劇的に向上している。

2. 派生データ機構（Derived Data）

変更リストの記録に絞ることで書き込みの大幅な高速化は達成できるが、「このコードは5年前に誰が書いたのか」あるいは「特定のファイルがどのようなコミットを経てきたのか」といった問い合わせにはどう迅速に答えるのか？

Scionは派生データ（Derived Data）と呼ばれる汎用計算フレームワークを採用している：

• ファイルのBlameチェーン、パスの変更履歴、コミットグラフのスキップリスト（Skip Lists）などの補助構造は、すべて派生データとして定義される。

• 派生データは再帰的に定義される。ある変更セットにおける派生値は、その親変更セットの派生値に現在の変更セットの差分を加えることで算出できる。

• サーバー側は、頻繁に利用されるインデックスを即時事前計算（Eager）するか、アクセス頻度の低いインデックスをクエリ実行時まで計算を遅延（Lazy）させるかを自律的に決定できる。クライアントからは低レイヤーのインデックス詳細が完全に隠蔽されているため、サーバー側でインデックスの最適化を進めてもクライアント側に一切の変更を要求しない。

3. 3層ストリーミングキャッシュ構造：scnクライアントの動作原理

1日あたり数千万回に及ぶ高頻度な読み取りを支えるため、Scionは階層的に隔離された物理キャッシュネットワークを構築した：

従来のGitのネゴシエーションプロトコルでは、どのオブジェクトが既に存在し、どのオブジェクトの転送が必要かをクライアントとサーバー間でやり取りし、サーバーが双方の差分集合を算出する。超大規模リポジトリにおいて、このハンドシェイクは莫大なCPUリソースを消費する。

Scionはこのネゴシエーションフローを根本的に改めた。クライアントは自らが保持しているものを上流へ報告することはなく、欠落している対象ツリーとオブジェクトハッシュのみをサーバーへ要求する。

具体的な動作レイヤーは以下の通りである：

1. ローカルデーモン（scion-daemon）：各物理コンピュートノードのバックグラウンドで動作する。同一ノード上で稼働する複数のタスクはこのデーモンを共有する。同一ノード上のタスクが実行するコードは重複度が高いため、大半のファイルはローカルデーモンのキャッシュに直接ヒットする。
2. リージョンメモリキャッシュ（scion-cache）：ノードデーモンでキャッシュミスが発生した場合、リクエストはそのデータセンターのリージョンキャッシュクラスタへ転送される。このサーバー群は、ディスクネイティブのフォーマットのままメモリ上からオブジェクトをストリーミング配信するため、リクエストごとに欠落オブジェクト集合を算出したり再圧縮を行ったりする必要がない。
3. オーソリティサービスクラスタ（scion-server）：前述の2層キャッシュを両方とも通過（キャッシュスルー）した場合にのみ、リクエストは最上位のオーソリティノードへ到達し、分散データベースSpannerおよびオブジェクトストレージからマスターデータを読み出す。

Anthropicの報告によると、各キャッシュ層のヒット率はいずれも99%を超えている。これら3つのレイヤーは外部に対して完全に同一のRPCインターフェースを公開しているが、厳格な階層化ルールによって障害ドメインが隔離されており、リージョンキャッシュの障害時に大量のリクエストが直接オーソリティサービスを直撃することを防いでいる。

どれほど高速化したのか？操作ごとに個別に見る必要がある

このアーキテクチャが実際に本番稼働したことで、どのような定量的改善がもたらされたのか？

全面移行が完了した後、各プロセスのパフォーマンスには顕著な高速化の差が現れた。その効果は環境やコマンドによって一様ではない。以下に、GitとScionにおける同種操作の比較を示す。

エージェント環境では、変更リクエスト1件あたりに消費されるバージョン管理の総所要時間が34分から3.7分へと短縮され、約9.2倍高速化した。これは複数の操作による累積待ち時間であり、コードの準備を繰り返すことがタスク全体に与える影響の大きさを示している。

主要な側面における実績は以下の通りである：

• エージェントワークツリー（Worktree）の初期化：従来の7.1分から5.1秒へと激減し、84倍の高速化を達成した。エージェントがアイドリング状態で長時間待たされることはなくなった。

• ステータス照会（Status）：開発マシン上での scn status の所要時間は3.9秒から19ミリ秒へと短縮され（207倍）、対話的な待ち時間が劇的に削減された。

• CIチェックアウト所要時間：CIタスク内でのチェックアウトは中央値31秒から3.5秒へと短縮（8.8倍）、計算クラスタタスク起動時のチェックアウトは175秒から22秒へと短縮された（8倍）。

• エージェントの待ち時間およびマシン時間の削減：

  • エージェント環境全体で1日あたり約11,000時間のバージョン管理待ち時間を削減；
  • CIおよび計算クラスタ全体で1日あたり合計約280,000マシン時間を解放；
  • CI単体の高速化だけでも、CIインフラ自体のCPUキャパシティが25%向上。

• バージョン管理インフラのフットプリント削減：かつて数百台のGitミラーを保守していたのと比較して、ScionサーバーのCPUおよびメモリ消費におけるインフラ要件は従来の約200分の1に抑えられた。

なお、これらのマシン時間やエージェント稼働時間の節約はAnthropic社内のワークロードに基づく推計値であり、人間のエンジニアが削減できた工数にそのまま換算できるものではない。ベンチマークグラフに示されている数値はコマンドの中央値所要時間であり、ハードウェア構成、サンプル数、キャッシュ条件などは明示されていないため、各数値はそれぞれの前提環境に即して理解する必要がある。現に、開発者によるCommitの高速化は約1.3倍（1.4秒から1.1秒へ短縮）にとどまっている。

わずか7名のチームがどのようにこの移行を成し遂げたのか？

7名からなるチームが5か月間でScion、Antique、および関連システムの構築を完了させ、リポジトリ全体の移行を成し遂げた。Anthropicは、従来のエンジニアリングであれば遥かに多くのエンジニアと数年間にわたる段階的移行が必要とされていた規模のプロジェクトであるとしており、これほど小規模なチームで実現できた背景には社内Claudeをフル活用できる環境があった。

Claudeは従来のツールチェーンに対する負荷を激増させた要因であると同時に、エンジニアが新しいツールチェーンを実装・最適化するのを支援する推進力でもあった。

この移行劇は、チームの働き方そのものも変革させた：

1. モデルがコードを書き、エンジニアは「モデルにノーと言う」

プロジェクトに参加したエンジニアたちは、コードを書くことに関してはClaudeの方がすでに自分たちよりも優れていると考えている。システムの全体目標、コンポーネント間の連携関係、設計上のトレードオフを決定する役割は引き続き人間のエンジニアが担っている。

当初、人間のエンジニアが手作業で書き上げたGitからScionへの履歴データ取り込み（インジェスト）のプロトタイプは、チーム内でも十分に完成度が高いと評価されていた。しかし、エンジニアがそのコードをそのままClaudeに投入したところ、何ら追加のチューニング指示を与えていないにもかかわらず、モデルは自律的なリファクタリングによってメモリ消費量を20分の1に削減し、処理速度を4倍に向上させた高性能な実装を出力し、しかも暗黙的な時系列不変条件（invariants）の制約を完全に維持していた。

しかし、この開発体制は新たな課題も生み出した。エージェントは局所的な要件を満たすためにシステム全体の制約に反するコードを書くことがあり、過度な防御的プログラミングによって実装を無駄に複雑化させてしまう場合もあった。

• モデルが作成した複数の周辺スクリプトでは、特定の変更がいつトランクにマージされたかを調べるために、実績のあるレビューツールのAPIを呼び出すのではなく、コミットログを線形探索しようとする挙動が見られた。

• 社内で実施された敵対的レビュー（Adversarial Review）において、モデルは別のマイクロサービスの信頼性を過度に懸念した結果、肥大化したバリデーション層や防御的コードを勝手に追加し、システム全体の複雑性を不必要に増大させていた。

• レビューの重点のシフト：チームは依然としてすべての変更に対してレビューを実施しているが、その主眼は根本的な意図（Intent）の確認やシステム間コントラクトの策定へと移行し、モデルがアーキテクチャ上の制約を逸脱しようとした際には断固として却下するようになった。

2. テスト実行中にもトランクは動き続ける：検証プロセスの再設計

従来の開発体制では、トランクを常にビルド可能な状態に保つため、グローバルロックを伴うマージキュー（Merge Queue）が広く用いられてきた。コミットAがすべてのテストをパスしてマージされた後でなければ、コミットBは最新の状態に基づいてキューに並ぶことができない。

しかし、1日のマージ数が数万回に達し、毎分のように複数のコードがコミットされる環境では、テストを実行しているわずかな合間にも数百〜数千件の変更がマージされてしまうため、リポジトリ全体をロックする従来のマージキュー方式を踏襲することは不可能だった。

そのため、同社は検証リソースをマージ後テスト（Post-Merge Testing）およびデプロイ前検証へとシフトさせた。並行マージは論理的なコード競合を引き起こすリスクを孕むが、Anthropicによれば、Claudeはそうした競合を通常迅速に修正できるという。ここでのトレードオフは、マージ段階で問題が発生し得ることを受容した上で、マージ後およびデプロイ前のテストによってそれを検知・解消することである。これには相応の包括的検証能力が不可欠であり、コードレビューを撤廃したわけではない。

3. 運用・監視の熱狂的守護者「Superfans」

監視の分野において、チームは社内ツールとClaude Tagを活用し、Slackチャンネル上でClaudeに各中核コンポーネントを常時監視させている。

• scion-daemon デーモンを専任で見守るClaude、scion-cache のメモリプールを専門に監視するClaude、コードレビューのマージキューを注視し続けるClaudeなどが配備されている。

• これらは関連するテレメトリやログにアクセスして継続的に異常を検知しており、チームによれば、従来の静的アラートでは検知しにくかった微細な兆候や新しいパターンの問題を浮き彫りにできるという。なお、従来型のアラート機構も引き続き併用されている。

4. 隔離シミュレーションとセマンティック権限：高スループット下で品質と機密コードをどう守るか

エージェントによる書き込みスループットが劇的に増加する中、テストカバレッジを維持し、機密コードへのアクセスや承認フローを厳格に管理することが重要な課題となった。チームはClaudeとScionの仕組みを組み合わせて2つの防衛線を構築した：

• 隔離シミュレーションによるテストカバレッジの確保：過密な移行スケジュールの下で、Claudeは複雑なインフラとソース管理との相互作用を再現する隔離シミュレーション（Hermetic simulations）の迅速な構築を支援し、ファジング（Fuzzing）やきめ細かなレートリミットを組み合わせた。この仕組みは、制御・隔離された環境で極端なインタラクションや異常入力をシミュレートし、コードスループットの急増時に潜む欠陥や並行処理の落とし穴を洗い出すとともに、レートリミットによって高頻度なリクエストが基盤サービスを圧迫することを防ぎ、テストカバレッジを底上げする役割を果たしている。

• ディレクトリ権限とセマンティックレビューによる機密コードの統制：Scionはリポジトリおよびディレクトリ単位でのきめ細かなアクセス制御をネイティブでサポートしており、モノレポ特有のコラボレーションの利便性を維持しながら機密コードを保護する。また、連携するコードレビューツールは複雑な承認セマンティクスを表現でき、単なるコメントの修正と機密性の高いロジックの変更を識別することが可能である。この仕組みにより、人間のレビュアーの労力を真に重要なロジックの変更に集中させ、本質的でない修正によるフローの停滞を防ぎつつ、権限と承認要件に厳格に則って機密コードを管理している。

一般的な開発チームは何を参考にできるのか？

今回の移行事例を目にして、開発者が真っ先に抱く疑問は「Gitは本当に時代遅れになるのか？ 自分たちもGitをやめるべきなのだろうか？」という点だろう。

一般的なチームは、引き続きGitを利用できる。Scionがもたらす優位性は、超巨大なコードベースと高頻度で実行されるオンラインタスクという極端な負荷環境があって初めて顕在化するものである。

Scionが対象としているのは、極めて特殊なワークロードである：

• 独自開発・内製化のエコシステム維持コストが極めて高い：Scionは単体ですぐに使える汎用CLIツールではない。社内開発のコードレビュープラットフォームAntique、独自開発のコード検索、社内IAM権限管理などと密接に結合している。もしGitから移行しようとすれば、コードレビュー、検索、CIなどの開発フロー全体をまるごと刷新・移行しなければならない。

• 再現困難なコンピュートリソースの投入：Anthropic社内における大規模言語モデルのトークン消費量は、一般的な民間企業が社内開発環境ツールに投じられる予算規模を遥かに超越している。

• ユースケースの根本的な違い：一般的なチームにとっては、Gitのオフライン作業能力や成熟したツールエコシステムは依然として計り知れない価値を持っている。Scionは主として巨大モノレポと大量のエージェント群のために特化された設計である。

Anthropicは、今回の試行錯誤で得られた知見の一部をGitエコシステムへ還元したいと考えている：

1. Gitサーバーはクライアントの振る舞いを機械的に模倣すべきではない：GitHubやGitLabなどのコードホスティングプラットフォームは、Scionのような非対称アーキテクチャを取り入れ、重い計算をサーバー側に集約してきめ細かなRPCクエリインターフェースを提供することで、クライアントに巨大なパックファイルをダウンロードさせる運用から脱却できる余地がある。
2. ネゴシエーションおよびチェックアウトプロトコルの再設計：Gitエコシステムには長年、スパースチェックアウト（Sparse checkout）やプロミサーリモート（Promisor remotes）といった機能が存在してきたが、これらを協調して最適化する余地はまだ残されている。「オンデマンドでオブジェクトをストリーミング取得する」軽量なネゴシエーションプロトコルが標準化されれば、大規模タスクがリポジトリの転送や維持管理に費やす重複コストを大幅に削減できる可能性がある。

今回の移行事例が示しているのは、AIによってコード生成が劇的に加速された結果、開発全体のボトルネックがストレージ、配信、レビュー、検証の各プロセスへと次々に波及していくという現実である。一般的なチームにとってより有益な教訓は、「実際にはクエリの結果だけを必要としているタスクはないか」「重複して無駄に転送されているファイルはないか」「共通の負荷の高い計算をサーバー側に委ねられないか」を見直すことにある。なお、ScionはAnthropicの社内システムであり、現時点で一般的なチームがインストールして利用できる汎用バージョンは提供されていない。