Anthropicは2026年10月13日、社内のソースコード管理システムをGitから独自開発の「Scion」へ移行した経緯と技術設計を公式エンジニアリングブログで公開した。複数のプロジェクトを単一のリポジトリで管理する「モノレポ」を、わずか5カ月で全面移行したという。
同社でメインブランチに統合されるコード変更は、5月の1日平均約2,500件から9月には3万件超へと急増した。AIエージェントによるコード生成が加速する一方、ソースコードの取得やビルド、テストを担う既存の開発基盤が、その処理量に追いつかなくなっていた。
そこでAnthropicは、従来のGitを単に高速化するのではなく、常時接続のAIエージェントによる大量の開発作業を前提として、ソースコード管理の仕組みそのものを再設計した。変更の記録方法からファイルの配信、コードの統合、品質検証に至るまで、開発工程全体を見直したという。
1日2,500万回のコード取得がGit基盤の限界に
Anthropicのメインブランチ「main」は、Gitの履歴データだけで100GB近くに達し、圧縮された作業用ファイル一式も25GBを超える規模になっていた。
さらに、継続的インテグレーション（CI）でソースコードを取得する回数は、1日約2,500万回に上っていた。この数字には、開発者のローカル環境やAIエージェントの実行環境、研究用ジョブによる取得は含まれていない。
巨大なリポジトリを膨大な回数にわたって取得することが、開発基盤に大きな負荷をかけていた。
Anthropicによれば、仮に毎回すべてのデータを取得していた場合、通信量は1日600PB（ペタバイト）を超える計算になる。ただし、これは全量取得を想定した理論上の数字であり、実際にこれほどの通信量が発生していたわけではない。
同社はすでに、取得する履歴を制限する「シャロークローン」や、必要なデータだけを取得する仕組みを活用していた。
ピーク時には数百台の社内Gitミラーを稼働させ、アクセスを分散していたという。また、クラウドストレージにリポジトリのスナップショットを保存し、それを起点としてコードを取得する方法も導入していた。
しかし、コードの変更が急速に増えるにつれ、スナップショットの更新が追いつかず、最新のmainブランチとの差が大きくなる問題が生じていた。
Gitは本来、各開発者が手元にリポジトリを持ち、履歴の確認や変更の記録を行える分散型のバージョン管理システムだ。ネットワークに接続していなくても開発を続けられることは、Gitの大きな利点である。
一方、Anthropicの開発環境では、ソースコードの正式な管理先は事実上一本化され、利用者の大半を常時接続のAIエージェントや自動実行ジョブが占めるようになっていた。
各クライアントが豊富な履歴データを保持し、変更の処理を自力で行うというGitの設計は、同社の実際の利用形態に合わなくなっていたのである。
ただし、Gitが必ずリポジトリ全体を複製する仕組みだというわけではない。
Gitには、必要なオブジェクトを後から取得する部分クローン（Partial Clone）や、作業ディレクトリに展開するファイルを限定するスパースチェックアウト（Sparse Checkout）が用意されている。
AnthropicがScionを開発したのは、こうした既存の最適化を利用してもなお処理負荷が増大し続けたためだ。そこで同社は、クライアントとサーバーの役割分担を根本から見直すことにした。
Scionは変更の記録から履歴の計算までサーバー側で処理
Scionでは、コードの変更を「変更セット（Changeset）」という単位で記録する。
Gitのコミットは、その時点のファイル構成を表すツリーを参照する仕組みになっている。これに対し、Scionの変更セットは、親となる変更セットから変更されたファイルの一覧と、圧縮されたファイル内容への参照を保存する。
これは、ファイル内で変更された行だけを差分として保存するという意味ではない。変更されたファイルを中心に情報を記録することで、新しい変更セットを作成する際の処理負荷を抑える設計だ。
さらに、Scionでは変更セットの作成自体をサーバー側で行う。そのため、Gitのようにローカルでコミットを作成してからリモートリポジトリへ送信する必要がない。
一方、変更されたファイルの一覧だけでは、「ある行を最後に変更したのは誰か」「特定のファイルが過去にどう変更されてきたか」といった問い合わせに効率よく対応できない。
そこでScionは、変更セットを基に、履歴検索用のインデックスなどの「派生データ（Derived Data）」をサーバー側で生成する仕組みを採用した。
派生データは、用途に応じて事前に計算しておくことも、必要になった時点で計算することもできる。新しいインデックスを追加する場合も、クライアント側の変更は不要だ。
この仕組みにより、履歴を利用する自動処理も効率化される。
例えば、不具合の原因となった変更を探したり、特定の変更を取り消したりするジョブは、ローカルにリポジトリ全体を保持する必要がない。APIを通じてサーバーに問い合わせるだけで、必要な情報を取得できる。
Scionでは、差分の計算やマージ、リベースもサーバー側で処理する。クライアントは容量に上限のあるキャッシュと作業ファイルを管理し、負荷の大きい処理をサーバーに任せる構成だ。
また、ブランチやタグのように、複数の利用者が共有する参照情報の更新も最小限に抑えている。
ただし、ブランチやタグを廃止したわけではない。mainやリリースブランチなど、共有する必要のある参照は引き続き存在する。
これらの更新は変更セットの作成とは分離され、Google Cloudの分散データベース「Spanner」に保存された単一行のデータを、現在の値が想定どおりであることを確認した上で更新する。
これによって変更セットの作成時に必要な調整を減らしつつ、共有情報の整合性を維持している。
必要なファイルだけを取得する3層キャッシュ
Scionでは、ファイルの取得方法も見直された。
従来のGitでは、サーバーがクライアント側の保有データを考慮しながら、転送用のパックファイルを作成することがある。
一方、Scionではクライアントが必要なツリーやファイル内容を指定し、サーバーは要求されたオブジェクトを返す。
各データは内容に基づく識別子で管理され、一度保存されたデータの内容は変更されない。そのため、キャッシュに保存したデータが更新されていないかを繰り返し確認する必要がなく、配信の負荷を抑えやすい。
データの配信には、次の3層構造を採用している。
- scion-daemon： 同じ計算ノードで動く複数のジョブが共有するキャッシュ
- scion-cache： 同一リージョン内で利用するキャッシュ
- scion-server： ソースコードの正本を管理するサーバー
Anthropicによると、各層のキャッシュヒット率はいずれも99％を超えている。
必要なディレクトリだけを取得することに加え、ファイルを実際に読み込むまで内容の取得を遅らせることもできる。
さらに、履歴を検索するだけの処理であれば、作業ファイルそのものを取得する必要がない。
こうした変更の効果は大きい。
Anthropicによれば、従来のGitミラー基盤と比較して、必要なCPUとメモリの量は約200分の1に減少した。
また、CIや研究用ジョブのソースコード取得時間は、従来の分単位から秒単位へ短縮され、約2桁の高速化を実現した。CI全体でもCPU容量を25％削減できたという。
ただし、これらはAnthropicの開発環境と負荷条件で測定された数字であり、同社全体の開発コストが200分の1になったことを意味するわけではない。
また、処理をサーバー側に集約することで、障害が広範囲に波及するリスクも生まれる。
Scionではキャッシュの各層を明確に分離し、リージョン内で障害が発生しても、上位サーバーへのアクセスが集中して過負荷にならないように設計している。
GoogleやMetaのソースコード管理システムとの違い
巨大なモノレポを効率的に管理するため、クライアントが保持するデータを減らすという考え方自体は、新しいものではない。
Googleは2016年に公開した技術論文で、巨大なモノレポを管理する「Piper」と、クラウド上の作業状態をファイルシステムとして扱う「CitC」を紹介している。
CitCでは、リポジトリ全体をローカル環境へ複製・同期しなくても、コードの閲覧や編集が可能だ。開発者の作業領域には、変更したファイルだけを保存する。
AIエージェントによる大量のコード生成が一般化する以前から、リポジトリ全体を各端末に保持させない仕組みは実用化されていた。
Metaも2022年に公開した「Sapling」で、必要な履歴やファイルを必要に応じて取得する仕組みを採用している。
専用の構成では仮想ファイルシステムも利用する一方、クライアント側でのコミットなど、開発者がよく使うオフライン作業を可能にする設計も維持している。
Anthropic自身も、PiperとSaplingをScionの先行事例として挙げている。
各システムの主な違いを整理すると、次のようになる。
| システム | ローカルに保持するデータを減らす方法 | 変更・履歴処理の仕組み |
|---|---|---|
| Git（公式仕様） | 部分クローンでデータ取得を遅らせ、スパースチェックアウトで展開するファイルを限定 | クライアントがリポジトリを管理し、不足するデータをサーバーから取得 |
| Google Piper／CitC（2016年） | クラウド上の作業領域を参照し、変更したファイルだけを保存 | 集中管理型のPiperと、クラウド上の作業領域を提供するCitCを組み合わせる |
| Meta Sapling（2022年） | 履歴やファイルの遅延取得と、仮想ファイルシステムを活用 | クライアントでコミットでき、キャッシュやインデックスによって一部のオフライン作業にも対応 |
| Anthropic Scion（2026年） | 必要なオブジェクトのみを多層キャッシュから取得し、APIだけで完結する処理にも対応 | 変更セットの作成、マージ、履歴検索などをサーバー側で処理 |
この比較は、Gitの公式仕様と、Google、Meta、Anthropicが公開した技術資料に基づき、データの取得方法と処理の分担を整理したものだ。各システムの処理速度や性能を直接比較したものではない。また、Saplingの大規模環境向け最適化のすべてが、Git接続のクライアントで利用できるわけではない。
Scionの最大の特徴は、クライアントが常時ネットワークに接続していることを前提に、ローカルで実行する処理を大幅に減らした点にある。
必要なファイルだけを取得する仕組みは既存の技術にもあるが、Scionはさらに踏み込み、コミットに相当する変更セットの作成やマージまでサーバー側へ移している。
その結果、クライアントは軽量になり、膨大な数のAIエージェントが同時に作業しやすくなる。
一方で、変更の作成や履歴の処理にはサーバーへの接続が必要になる。ローカルの処理負荷を減らせる反面、ネットワークやサーバーへの依存が強まるというトレードオフがある。
コード統合後のテストとAIによる修復を重視
Scionの導入で課題となったのは、ソースコードの取得速度だけではない。大量のコード変更を安全に統合し、品質を維持する仕組みも見直す必要があった。
Anthropicによると、ある変更に対するテストを実行している間にも、mainブランチには数百件から数千件の変更が統合される可能性がある。
こうした環境では、変更を順番に検証して統合する従来型のマージキューを、十分な効果が得られる形で運用することが難しかったという。
そこで同社は、コードの統合後と本番環境へのデプロイ前に実行する自動テストを強化する方針を採用した。
並行して進められた変更同士が衝突した場合には、その修正にClaudeを活用する。
一般的なマージキューは、変更が単独でテストに合格したかどうかだけでなく、他の変更と組み合わせた状態でも問題なく動作するかを確認する役割を持つ。
例えば、GitHubのマージキューに関する公式文書では、対象ブランチの最新状態に、キュー内の先行変更と新たな変更を組み合わせて必須チェックを実行する仕組みが説明されている。
これは、個別には正常に動作するコード変更であっても、同時に適用すると不具合が発生する可能性があるためだ。
ただし、これはGitHubが提供するマージキューの仕様であり、Git本体やAnthropicが以前使用していた開発環境の仕様と同一ではない。
Scionによってコードの取得や変更の統合が高速化されても、複数の変更を組み合わせたときに生じる問題がなくなるわけではない。
Anthropicの新しい運用は、統合前に変更の組み合わせを厳密に検証することよりも、統合後に問題を検出し、速やかに修復する仕組みを強化する方向へ重点を移したものといえる。
ただし、同社は統合前のテストをすべて廃止したと説明しているわけではない。
Anthropicは、Claudeが人間よりも速くコードの衝突を解消できるとしている。しかし、修正速度だけで開発基盤の品質を判断することはできない。
重要なのは、不具合が発生した状態がどれだけ続くのか、本番環境へのデプロイ前に問題を検出できるのか、そして問題のある変更の取り消しや修復をどれだけ迅速に完了できるのかという点だ。
今回の発表では、これらの指標について具体的な数値は示されていない。
1日数万件の変更を処理できることと、それらを安全に本番環境へ反映できることは、分けて評価する必要がある。
わずか7人、5カ月で移行を実現した開発体制
Anthropicによれば、Scionと新しいコードレビューシステム「Antique」、さらに関連する開発基盤を構築し、5カ月で全面移行を実現したチームは、わずか7人だったという。
開発にはClaudeを積極的に活用し、実装作業の高速化に加え、シミュレーションやファジングなどの検証も充実させた。
ファジングとは、プログラムに多様な入力データを与え、想定外の動作や不具合を発見するテスト手法だ。
ただし、AIがコードを大量に生成できるようになっても、人間の技術者による設計判断が不要になったわけではない。
Anthropicは開発過程で、Claudeが必ずしも適切な設計を選ぶとは限らないことも経験したという。
例えば、ある変更がmainブランチに統合された時点を確認するために、コードレビューシステムへ問い合わせれば済むところを、リポジトリの履歴を順番に読み続ける実装が生成されたことがあった。
また、AI同士による厳格なコードレビューが、過剰な検証処理や不要な複雑さを生む場合もあった。
信頼できる社内サービスに対してまで過度なチェックを追加し、システム全体を必要以上に複雑にしてしまったという。
こうした問題に対し、人間のエンジニアは、どの処理をどのサービスに任せるべきか、システムが守るべき制約は何かを判断し、Claudeに修正を指示した。
同チームは現在も、Scionや関連システムへのすべての変更要求を人間がレビューしている。ただし、コードを1行ずつ細かく確認することよりも、変更の目的や設計意図が妥当かどうかを重視しているという。
AIに実装や検証の多くを任せながらも、アーキテクチャの整合性や技術的な判断については、人間が責任を持つ開発体制を採用している。
巨大モノレポのアクセス制御も強化
巨大なモノレポを運用する上では、ソースコードへのアクセス権限も重要になる。
Scionではディレクトリ単位で権限を設定でき、利用者が閲覧・変更できる範囲を制御する。
また、コードレビューシステムでは、コメントの修正のような軽微な変更と、機密性の高いロジックの変更を区別し、それぞれに応じた承認条件を設定できる。
AIエージェントによって大量のコード変更が日常的に生成・統合される環境でも、誰がどのコードにアクセスできるのか、どのような変更に人間の承認が必要なのかを管理する仕組みは維持されている。
Scionを一般企業がそのまま導入するのは難しい
AnthropicがScionの導入を短期間で実現できた背景には、同社特有の開発環境と豊富なAI計算資源がある。
Anthropic自身も、社内で利用できるAIモデルのトークン量は、一般企業が現実的に負担したいと考える水準を大幅に上回っていると認めている。
さらに、Scionは単体でGitを置き換えられる製品ではない。
専用のコードレビューシステムやコード検索基盤、CIなどとの連携を前提としており、導入するには開発工程全体を移行する必要がある。
そのため、同社はScionを汎用的なGit代替として提供することは適切ではなく、広く利用できる形で外部公開することも難しいと説明している。
一方、今回の設計には、既存のGit環境にも応用できる考え方がある。
特にAnthropicがGitコミュニティと共有したいとしているのは、サーバー側で履歴や変更に関する問い合わせを処理するAPIや、必要なデータだけを効率よく取得する仕組みだ。
AIエージェントの普及によってコード生成量が増えれば、Gitを利用し続ける企業でも、リポジトリの取得や履歴検索、マージ処理の負荷が高まる可能性がある。
こうした処理の一部をサーバー側へ移し、キャッシュを活用してデータ転送を減らす設計は、既存のソースコード管理システムを改善する上でも参考になる。
ただし、サーバーへの依存を強める場合には、障害時にも開発を継続できるか、ネットワークに接続できない環境でどこまで作業できるかを検討する必要がある。
AnthropicのScionは、AIエージェントが大量のコードを生成する時代に、従来のソースコード管理システムをどのように見直すべきかを示す事例となった。
今後、サーバー側の処理や効率的なデータ取得の仕組みが既存のGit環境にも取り入れられれば、Scionのような専用システムへ全面移行することなく、AIによって急増する開発負荷に対応できる可能性がある。
