［開発者向け］1日3万件のマージを支えるAnthropicの独自ソース管理「Scion」とは

2026-10-162026-10-21

はじめに

　Anthropicは2026年10月13日、社内モノレポのソース管理をgitから独自開発のバージョン管理システム「Scion」へ5か月で全面移行した経緯を公開しました。本稿では、Claudeによるコード変更の急増が招いたスケーリング課題と、Scionの設計原則・仕組み・開発から得た教訓を解説します。

参考記事

タイトル: Redesigning source control at Anthropic
著者: Nick G.、ソースコントロールチーム（S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.）
発行元: Anthropic
発行日: 2026年10月13日
URL: https://www.anthropic.com/research/redesigning-source-control

要点

Anthropicのモノレポでは、1日あたりのマージ件数が2026年5月の平均約2,500件から9月には3万件超へ増加し、ソース管理・ビルド・CIが新たなボトルネックとなっている。
同社は独自のバージョン管理システム「Scion」を構築し、モノレポをgitから5か月で全面移行した。同じ期間にコードレビュー基盤「Antique」なども構築している。
Scionは「クライアントは常にオンライン」を前提に、履歴・blame・コミット・マージなどの処理をサーバー側に集約し、作業コピーを任意かつスパースなものとして設計している。
Anthropicによれば、Scionの基盤はCPU・メモリ要件で旧gitミラー基盤の200分の1に縮小し、CIと研究ジョブのチェックアウトは2桁高速化した。
Anthropicは、Scionが一般用途でgitを置き換えるものではないとしたうえで、サーバー側RPCなどの考え方をgitエコシステムへ還元する方針を示している。

詳細解説

背景：コーディングではなく開発基盤がボトルネックに

　Anthropicによれば、同社ではもはやコーディングがシステム構築や研究のボトルネックではなくなっています。Claudeは研究ループの自律的な反復、複雑なプログラムの細かな最適化、新しいサービスのゼロからの構築を、これまでにない速度と規模でこなしており、代わりに人間の作業規模を前提に作られたソース管理・ビルド・CIといった開発基盤がボトルネックになっているといいます。

　数値で見ると、同社のモノレポ（複数のプロジェクトを1つのリポジトリで管理する方式）にマージされたコード変更は、2026年5月には1日平均約2,500件でしたが、9月時点では1日3万件を超えました。元記事では、2026年1月から9月までの1日あたりのマージ件数の推移がグラフで示されています。Anthropicは、コードをマージしたいという潜在的な需要は事実上無限であり、ボトルネックを1つ取り除くたびにコードの量がさらに増えるため、この伸びがすぐに鈍化するとは考えていないと述べています。

　この成長を支えるため、Anthropicは社内向けのバージョン管理システム「Scion」を構築し、モノレポをgitから5か月で完全に移行しました。同じ期間に、コードレビュー基盤「Antique」、コード検索、ソース管理向けの高機能なIAM（誰が何にアクセスできるかを管理する仕組み）、大量のレビュー済みコードを管理して取り込む新しい手法なども構築・リリースしています。元記事はこのうちScionに焦点を当てており、Claudeのコード生成能力がこの状況を生んだ原因であると同時に、それに対処する高品質でスケーラブルなシステムを短期間で作れた理由でもあった点を、興味深い事例として紹介しています。

　5月と9月の数値を単純に比べると10倍を超える伸びです。本稿としては、AIによるコード生成が速くなるほど、負荷がレビュー・統合・検証といった周辺の工程へ移っていくという構図が、具体的な数値で示された点に意味があると考えています。

モノレポの肥大化とgitの限界

　Anthropicはまず、自社のワークロードが特殊であることを認めています。同社はほぼどの企業よりもClaudeにソフトウェアを書かせているため、人間規模を前提としたツールが限界を迎える場面に最初に直面することが多く、ソース管理はその一例だといいます。ごく近い将来に多くの組織が同じ問題を抱えるとは見ていないものの、AIコーディングツールを使う他の組織も遠からず同じ圧力点に直面すると考えており、それが今回の共有の理由だと説明しています。

　gitは分散型のシステムです。すべてのクローンが完全で自己完結したリポジトリであり、オフラインのままでも差分の計算、履歴やblame（各行を最後に変更したコミットの表示）の参照、任意のリビジョンのチェックアウトができます。Anthropicも、大多数のリポジトリにとってはこれが正しい設計であり、gitが標準になった大きな理由だとしています。

　しかし、同社のモノレポは成長に伴い、この設計の想定範囲に収まらなくなりました。Anthropicによれば、mainブランチの履歴だけで100GB近くあり、圧縮した作業コピーでも25GBを超えます。CIのためのチェックアウトは1日あたり約2,500万回にのぼり、これには開発環境、エージェントのサンドボックス、研究ジョブは含まれていません。素朴に取得すれば、gitの通信量は1日600PBを超える計算になるといいます。

　gitにはリポジトリの一部だけを扱うための機能があり、大規模モノレポ向けの定番の回避策も存在します。元記事で挙げられているのは次のものです。

シャロークローン（shallow clone）：履歴を途中までに限定して取得する方法
スパースチェックアウト（sparse checkout）：作業コピーに展開するディレクトリを限定する機能
プロミサーリモート（promisor remote）：手元にないオブジェクトを必要になった時点で取得できるようにする仕組み
社内gitミラー：リポジトリの複製サーバーを社内に置き、取得の負荷を分散する方法
シード（seed）：Blobストレージに保管しておくリポジトリのスナップショット

　Anthropicはこれらをすべて使い、ピーク時には数百台規模の社内gitミラーを運用していました。元記事では、こうしたgitチェックアウトをスケールさせる典型的な構成も図示されています。これで時間は稼げたものの、マージ件数が増えるにつれて運用は難しくなりました。シードは更新の合間にmainの最新状態から遠ざかり、diffやblameのように履歴に依存する操作を部分クローン上で動かし続けるのにも、ますます手間がかかるようになったといいます。

　改めて振り返ると、同社は多くの企業と同様に、gitを「権威あるコピーが1つだけある集中型システム」として使っていました。しかもクライアントのほぼすべては、定義上常にオンラインであるエージェントやジョブです。gitを分散・オフライン作業に優れたものにしている特性が、リポジトリの成長とともにスケーリングの妨げになっていたことから、同社は「エージェントが常にオンラインであることを最初から前提にソース管理を設計したらどうなるか」と問い直しました。

　なお、1日約2,500万回のチェックアウトに25GB超の圧縮作業コピーを掛け合わせると、およそ600PB強になります。元記事の「600PB超」という数字は、この単純計算と整合するものと読めます。ミラーやシードによる対処が時間稼ぎにとどまったのは、負荷がチェックアウト回数とリポジトリサイズの掛け算で増えていく構造だったためと考えられます。

エージェント規模のソース管理を支える6つの設計原則

　エージェント型のコーディングによって、ソフトウェア開発に関する多くの前提が変わりつつあります。AnthropicはScionの構築にあたってこの変化を受け入れ、いくつかの核となる原則でgitとは根本的に異なるアプローチを採りました。巨大モノレポ向けのソース管理には先行事例があり、GoogleのPiperやMetaのSaplingが知られています。元記事の脚注によれば、特に参考にしたのはSaplingのサーバーコンポーネントであるMononokeで、Scionで使っている手法の多く、とりわけBonsaiと呼ばれるデータモデルを先駆けて実現したものだと説明されています。Scionの原則は次の6つです。

クライアントは常にオンライン：gitはクライアントがオフラインで作業し、リポジトリの完全なコピーを持つことを前提としています。Scionではクライアントのほぼすべてがエージェントやジョブであるため、常に到達可能なサーバーを中心にクライアントとプロトコルを設計し、データは必要になった時点で取得します。
クライアントとサーバーの非対称性：gitではどのクライアントも完全なサーバーになり得ます。Scionでは、ファイル履歴やblameへの回答、コミットの作成、マージやリベースなどをサーバーが担います。クライアントは上限のあるローカルのオブジェクトキャッシュを持ち、作業コピーのファイルをディスクに展開し、ファイルシステムの変更を監視し、サーバーを扱いやすくする役割に徹します。単独でできる計算はごくわずかですが、その代わりにローカルに必要なデータ量は大幅に少なくなります。
包括的なソース管理サービスは多くの新しい用途を支えられる：gitでは、ある行を最後に変更したのは誰か、2つのコミットがどう関係しているかといった問いに答えたいCIジョブやツールは、ローカルにリポジトリのコピーを保持するか、ベンダー固有のAPIに頼るしかありません。Scionではクライアントが使うすべてのクエリがAPIとしても公開されているため、多くの場合ジョブはローカルリポジトリを必要としません。自動bisect（不具合を持ち込んだコミットを二分探索で特定する手法）やrevertのパイプラインなど、多くの社内ツールはこの安価でプログラム的なアクセスなしには大規模に運用できなかったといいます。
すべてを水平スケーラブルにする：ピーク時の数百台のgitミラーは容量を大きく圧迫し、リポジトリがミラーのディスクやメモリの上限を超えるとスケールしなくなりました。Scionではリポジトリのデータが分散配置され、各コンポーネントを独立してスケールできます。サーバー上も含め、リポジトリ全体を完全に実体化したコピーはどこにも存在しません。packfile（gitがオブジェクトを圧縮してまとめたファイル）に相当するものがないため、リポジトリのメンテナンスも不要です。
コミットは安価・インクリメンタル・ロックフリーであること：gitではローカルでコミットしてからpushして共有します。Scionではコミット・リベース・マージがすべてサーバー上で行われるためpushは不要ですが、それぞれの操作は高速である必要があります。コミットの作成と下流のデータ構造の更新にかかるコストは、リポジトリ全体の大きさではなく変更の大きさに応じて決まる必要があり、そうでなければサーバーが追いつけません。また、すべてのサーバーが合意する必要があるグローバルな状態はスケーリング上の大きな問題になるため、Scionの開発ライフサイクルでは、mainやリリースブランチを除いてref（ブランチやタグなどコミットを指すポインタ）の利用を推奨していません。
作業コピーは任意であり、設計上スパースである：モノレポが非常に大きく、CIのために1日数千万回チェックアウトしていることから、できる限りチェックアウトを避けたいと考えたといいます。たとえば、あるコミットとそのマージベースとの差分が必要なCIジョブは、サーバーに問い合わせるだけで済みます。書き込みも同様で、多くの書き込み処理はチェックアウトを省略してAPIだけで完結できます。Scionのプロトコルは、クライアントが要求したディレクトリだけを含むスパースチェックアウトと、ファイルを必要に応じて実体化する仮想化チェックアウトを中心に据えており、ディスク上にファイルが必要な場合でも実際に読んだ分のコストしかかかりません。

　これらの原則を並べると、オフラインでの完結性を手放す代わりに、計算とデータをサーバー側へ集約してスケーラビリティを得るという設計思想が読み取れます。一見するとSubversionやPerforceのような従来の集中型バージョン管理に近い方向に見えますが、後述するコンテンツアドレス方式のデータや水平分散を前提にしている点で、同じものとは言えないと思います。一方で、ネットワークが常に利用できることが前提になるため、オフライン作業が多い人間の開発者にとっては不便な場面もあり得ると考えられます。Anthropicが「クライアントのほぼすべてがエージェントやジョブである」という自社の条件から出発している点は、読む側が押さえておきたいポイントだと思います。

Scionの仕組み①：changesetと派生データ

　Anthropicは、これらの原則が実際のScionでどのように形になったかを紹介し、その知見は他のソース管理システムや、より広くソフトウェア開発ライフサイクルの他の段階にも応用できるとしています。

　Scionにおける作業の単位は「changeset」で、これはWAL（ライトアヘッドログ：変更内容を先にログとして追記していく方式）の1エントリです。changesetは、gitのコミットに期待される情報のほとんどを保持します。ただし、gitのコミットがツリーへのポインタを持つのに対し、changesetは最初の親（first parent）に対して変更されたファイルの一覧と、Blobストレージ上の圧縮済みファイル内容を指すコンテンツアドレス方式のポインタを持ちます。changesetはサーバー側で作成され、即座にどこからでも利用できます。元記事ではchangesetの構造も図示されています。また脚注によれば、マージの最初の親を基準に変更ファイルを記録するのは設計上の選択であり、モノレポでのトランクベース開発では、利用者が関心を持つのはメインライン上のコミットの履歴やblameだけだと実際にわかったためだと説明されています。

　この構造により、Scionは非常に高いスループットでchangesetを受け付けられます。受け取るpackfileがなく、ロックやサーバー間の調整も、動かすべきrefもないためです。Scionも技術的にはrefをサポートしていますが、コミットの作成にも取得にもrefが関与しないため、refの移動はchangesetの作成とは独立して、Spanner（Googleの分散データベースを指すと考えられます）の単一行に対するコンペア・アンド・スワップ（値が想定どおりのときだけ書き換える不可分操作）として行われます。

　一方、changesetは変更点しか記録しないため、それ単体では「この行を最後に編集したのは誰か」「このファイルに影響したコミットはどれか」といった問いにすばやく答えられません。そこでScionは、changesetからファイルのblameやパス履歴専用のデータ構造、コミットグラフ用のスキップリストなどを追加で構築します。changesetそのものに含まれないこれらをAnthropicは「派生データ（derived data）」と呼び、すべてを1つの汎用的な仕組みで計算しています。各種の派生データは再帰的に定義されており、あるchangesetにおける値は、その親changesetにおける値から計算されます。この仕組みには次の3つの利点があるとされています。

ある操作を高速化するデータ構造が新たに必要になったとき、新しい種類の派生データを簡単に追加できる
種類ごとに、事前に計算するか遅延させるかを選べるため、不要なデータを実体化せずに済む
クライアントはこれらのデータ構造の内部を一切見ないため、クライアントを変更せずに最適化できる

　実際、システムの成長に伴って、コピー検出やパスベースのファイル検索のための新しいインデックスなど、新しい種類の派生データが何度も追加されてきたといいます。

　コンテンツアドレス方式とは、データの内容から計算したハッシュ値をそのデータの識別子として使う方式で、gitのオブジェクト管理も同じ考え方に基づいています。スキップリストは、コミットグラフ上で祖先を1つずつたどる代わりに遠くの祖先へ飛べるようにする補助構造と考えられ、マージベースの探索などを高速化する目的があると推測されます。派生データを親の値から再帰的に計算する形にしている点は、前述の「コミットのコストを変更の大きさに応じたものにする」という原則を、データ構造の側から支える工夫と読めます。

Scionの仕組み②：キャッシュ階層によるスケーリング

　Scionでは、少数のサーバー群が、changesetの取得、差分の計算、マージベースの算出、Blobの取得など、クライアントが必要とするあらゆる操作のAPIを提供しています。すべてのソース管理データはコンテンツアドレス方式で保存されるため、一度保存されたデータは変わらず、どのサーバーも他と確認し合うことなくキャッシュできます。その結果、サーバーは水平スケーラブルで、ほとんど調整を必要としません。Anthropicは、これらのサーバーを本質的には大きなキャッシュであり、必要に応じて派生データをその場で計算し、結果をSpannerに書き戻す存在だと説明しています。

　Scionの多くの利用者は、もはや自前のローカルリポジトリを保持する必要がありません。以前は、特にコミットの祖先関係やblameについてソース管理に問い合わせる必要があるCIジョブやツールにとって、リポジトリの取得と維持が大きな負担でした。移行の初期、Scion独自のクライアント・リポジトリ形式・プロトコルがまだなかった段階では、Scionはこうした「メタデータ」クエリにだけ応答していました。ファイル内容の取得や作業コピーの実体化ははるかにデータ量の多い処理であり、独自の設計が必要だったといいます。

　Scionのクライアント「scn」は、いくつかの重要な点でgitの取得プロトコルと異なり、その結果、gitサーバーよりも大幅に少ないCPUで済む、スケーラビリティの高いアーキテクチャに適しているとされています。主な違いは次のとおりです。

ネゴシエーションでは、クライアントがすでに持っているものをサーバーに伝えず、クライアントが欲しいツリーとBlobだけを扱う
ルートツリーから出発し、ローカルストアに欠けているツリーを再帰的に要求し、続いてBlobについて同じ処理を繰り返す
各リクエストは変化しない特定のオブジェクトに対するものなので、どのキャッシュでも応答でき、従来の階層型キャッシュによく似た構成にできる
数GBに及ぶ単一のpackfileを返す応答がないため、効率的で、途中から再開もできる
欲しくないツリーを要求しないだけで済むため、スパースチェックアウトや仮想化チェックアウトに特別な対応が要らない

　実際のフリートでは、次の3つの階層でオブジェクトが配信されています。

scion-daemon：各ノードで動き、クライアントとソケット経由で通信して、ノード全体のオブジェクトを保存するデーモンです。ほとんどのノードがモノレポへのアクセスを必要とし、同じノード上のジョブは大半のオブジェクトを再利用します。定期的に更新されるスナップショットから起動し、同じリージョンのscion-cacheとだけ通信します。
scion-cache：リージョンごとのツリー・Blobキャッシュサーバーです。オブジェクトをデーモンがそのまま使えるディスク形式のまま、メモリから直接ストリーミングするため、クライアントに欠けているオブジェクトの計算やデルタ圧縮に時間を使いません。オブジェクトがない場合は、権威を持つscion-serverに問い合わせます。
scion-server：権威を持つサーバーで、必要に応じてSpannerやクラウドストレージから読み出します。

　3つの階層はいずれも、このプロトコルの同一のRPC（リモート手続き呼び出し）に応答するため、クライアントはキャッシュの構成を知る必要がありません。理論上はどの階層も他のどの階層とも通信できますが、障害の影響範囲（障害ドメイン）を分離するため、階層構造は厳密に守られています。リージョンのscion-cacheの障害が上流のscion-serverに過剰な負荷をかけ、システム全体を停止させる事態を避けるためです。元記事では、このチェックアウトのアーキテクチャも図示されています。

　Anthropicが報告している成果は次のとおりです。

各階層のキャッシュヒット率は99%を超え、長期間保持する状態を持たないため、必要に応じて容易にスケールアップできる
CPUとメモリの要件で比べたScionの基盤規模は、以前のgitミラー基盤の200分の1になった
CIと研究ジョブのチェックアウトは2桁速くなり（数分から数秒へ）、フリート全体で相当な容量が空いた
CIだけで、CPU容量について25%の改善が得られた
クライアントもキャッシュもリポジトリのメンテナンスが不要になり、ジョブのライフサイクル管理が簡単になった

　補足すると、gitの取得プロトコルでは、クライアントが手元にあるコミットを伝え、サーバーが不足分を計算してpackfileにまとめて返すのが一般的な流れです。この方式は転送量を抑えやすい反面、サーバー側でリクエストごとに計算が発生し、応答をそのままキャッシュしにくいと考えられます。Scionは「変わらないオブジェクトを個別に要求する」形に変えることで、CDNのような階層型キャッシュの考え方を適用できるようにしたと読めます。ただし、ここで示された数値はAnthropic自身の環境で得られたものであり、規模や利用パターンが異なる組織で同じ効果が得られるとは限らない点には留意が必要だと思います。

Scion開発から得られた6つの教訓

　AnthropicがScionの構築を始めたのは、Claude Mythos PreviewとClaude Tagが社内で利用可能になったのとほぼ同じ時期でした。同社によれば、この2つのリリースはScionの必要性を高めると同時に、構築のスピードも大きく引き上げました。

　特に象徴的な例として紹介されているのが、gitからScionへのデータ取り込みパイプラインです。同年の早い時期、同社はその初版をプロトタイプとしてほぼ手書きで作っており、出来は良いと考えていました。しかし、Claude Mythos Previewの初期の社内スナップショットに全体の書き直しを依頼したところ、追加の指示なしに、メモリ消費量が20分の1、速度が4倍のバージョンを生成し、取り込み順序やデータ構造に関する暗黙の不変条件もすべて保たれていたといいます。元記事では、2026年1月から9月までのScionとAntiqueのコードベースへの週ごとのマージ件数の推移もグラフで示されています。

　Anthropicは、Scionの構築と運用から得た学びが、エージェント規模のソフトウェア開発のあり方を考えるうえで示唆に富むとして、次の6点を挙げています。

少人数チームによる高速な開発が一般的になる：7人のチームがScionとAntique、さらに関連する6つほどのシステムを構築し、5か月で完全に移行しました。その間に1日あたりのマージ量は10倍に増えています。従来であれば、同様のソース管理システムの開発と展開には、はるかに多くのエンジニアと何年にもわたる段階的な移行が必要だったとし、こうした素早く身軽な移行は今後一般的になると同社は考えています。
エンジニアの価値は下がらないが、仕事の中身は変わる：このシステムに携わったエンジニア全員が、コードを「書く」能力ではClaudeの方が自分より優れていると評価しています。それでも、システム間の構成要素についての高い視点からの理解や設計上のトレードオフ、解くべき問題と達成すべき規模に基づく判断は、エンジニアが担いました。エンジニアの役割は、Claudeに「no」と言うことである場面が非常に多かったといいます。エージェントは、そもそも許容されるはずのなかったパターンに合わせるために、システムの核となる制約を破ることがあり、これは移行中に特に多く見られました。たとえば、変更がmainにマージされた時刻を知るために、コードレビューツールに問い合わせるのではなく、コミットログを線形に読んで力ずくで探そうとするシステムが複数ありました。また、Anthropicは敵対的レビュー（批判的な立場からの検証を意図的に行わせるレビュー手法と考えられます）を多用しており、多くの点で非常に効果的な一方で視野が狭くなりがちで、仮定の懸念に反応してシステムの一部を過剰に作り込まないよう、熟練したエンジニアが舵取りをする必要がありました。別の社内サービスを信頼することに過度に慎重なレビューの結果、Claudeが過剰な検証処理と複雑さを加えてしまった例も紹介されています。チームは今もこのシステムへのすべての変更リクエストをレビューしていますが、1行ずつ読むのではなく、変更の「意図」を確認する形に変わっています。
最適化と品質を大きく高められた：Claudeは人間よりはるかに速く大量のコードを書けるため、Scionは同社がこれまで手がけた中でも最もテストが充実し、防御が固いコードベースの1つになったといいます。厳しいスケジュールの中でも、これまでに遭遇した重要なインフラとソース管理のやり取りすべてについてハーメチックなシミュレーション（外部環境に依存せず再現性を保ったシミュレーション）を構築し、ファジング（ランダムな入力を大量に与えて不具合を探すテスト手法）や高度なレート制限も実装できました。Claudeは、インデックスの1つを使っていなかった祖先クエリのアルゴリズム的な最適化など、専門家でも分析と調整に数日から数週間かかるような大きな最適化を難なく見つけ、翌日にもまた同じように成果を出したと述べられています。元記事には、ネイティブのScionリポジトリで観測された性能改善を示す図も掲載されています。
モノレポの新しいセキュリティの土台を築けた：巨大なモノレポでは、安全性・セキュリティ・コンプライアンスの管理も、サイズや規模の管理と同じくらい重要です。Scionはこれを最初から念頭に置いて構築され、リポジトリへのきめ細かなアクセス制御に加えて、個々のディレクトリに権限を設定し、モノレポの利点を損なわずに最も機密性の高いコードを保護できます。また、構築したコードレビューツールは承認に関する複雑な意味的制約を表現でき、コメントだけの変更と機密性の高いロジック変更を区別することで、人間のレビュアーが最も影響の大きい変更に集中できるようにしています。
新しい水準の運用の質が可能になる：チームはClaude Tagを多用し、システムの各コンポーネントの監視に役立てています。たとえば、Slackチャンネルを作り、Claudeに単一コンポーネントの健全性だけにひたすら注目する役割を与えました。同社はこれを「スーパーファン（superfans）」と呼び、scion-daemonのスーパーファン、scion-cacheのスーパーファン、Antiqueのマージキューのスーパーファンなどがいます。スーパーファンはテレメトリとログにアクセスでき、チャートを更新して異変を探すこと以外にやることのない経験豊富なエンジニアのように振る舞います。従来型のアラートもすべてのシステムに設定されていますが、スーパーファンはそれらが一面的に見えるほど微妙で新しい問題を検知できるといいます。
これまでの前提を根本から見直している：このプロジェクトをきっかけに、同社は人間規模を前提に設計された他のワークフローも厳しく見直しています。たとえば、本来のマージキューはエージェント規模ではあまり意味をなしません。テストの実行中に数百から数千の変更がマージされ得る状況で、CIとは何を意味するのかという問いも提示されています。業界標準であるマージキューでのリポジトリ全体のグローバルロックは効果的に再現できなかったため、代わりにマージ後とデプロイ前の自動テストに投資しました。これにより並行する変更同士が衝突することはありますが、多くの場合、人間が衝突に気づくより早くClaudeが修正できるとしています。

　本稿としては、取り込みパイプラインの書き直しで得られた「メモリ20分の1・速度4倍」という結果は、Anthropicの社内環境における1つの事例として受け止めるのが妥当だと考えています。どの書き直しでも同様の改善が得られることを示すものではないと思います。また、エンジニアの役割が「1行ずつ読む」から「意図を確認し、制約違反や過剰設計を止める」へ移っているという指摘は、規模を問わずAIコーディングツールを導入するチームにとって参考になる視点だと思います。マージ後テストへの転換については、前述の自動bisectやrevertのパイプラインのように、問題のある変更をすばやく特定して戻す仕組みが前提にあると読めるため、そうした仕組みが整っていない環境でそのまま取り入れるかどうかは慎重に判断したいところです。

　なお、元記事はNick G.氏とソースコントロールチームのメンバーによって執筆されており、謝辞では、チームを支援したVilas J.氏とSergiu D.氏、Antiqueの初期開発に貢献したAmir O.氏の名前が挙げられています。

gitエコシステムへの還元と導入の考慮点

　Anthropicは、ScionをAIエージェントの能力向上がもたらすスケーリングの懸念に対する答えの一部にすぎないと位置づけています。今回の共有は、同様の課題に取り組むチームへの一例として示したものであり、自社の解決策や判断基準がすべてのケースに当てはまるとは考えていないとしています。

　同社は、Scionが一般用途でgitを置き換えられるものでは決してないと明言しています。ここで説明した考え方は、数万人のエンジニアを抱える組織や、大量のエージェントが盛んにコードを書いているような、真に巨大なモノレポでしか意味をなさないといいます。さらに、社内利用のためにトークンを費やせる規模が、他の企業が現実的に費やしたいと考える水準をはるかに超えている点でもAnthropicは特殊だとしています。同社がそうしているのは、自社のソフトウェア開発のニーズに応えるためと、Claudeの能力を試すためです。

　実務的にも、Scionを他の組織に広く役立つ形で提供するのは難しいとされています。理由として挙げられているのは次の点です。

gitから大きく乖離しているため、導入する企業は開発ライフサイクルのあらゆる部分を移行する必要がある
独自のコードレビュー、コード検索、CIを必要とする
社内版のこれらのコンポーネントは高度に独自仕様で、他の組織が採用するのは難しい
誰もが満足する公開版を作ろうとしても、実際にはあまり役に立たないものになる懸念がある

　一方で、同社はこの種の問題が今後6〜12か月の間にもっと一般的になると見込んでおり、gitを使うすべての企業が単独で同じ課題に向き合うのはエンジニアリング資源の非効率な使い方だと述べています。そのため、最も影響の大きい貢献は自社の考え方を共有することであり、他の開発者がgitの全体的なモデルから離れずに、Scionで特にうまくいった部分をgitに応用できるようにしたいとしています。具体的には、次のような方向性が示されています。

gitサーバーはgitクライアントと同じ仕組みで動く必要はなく、大幅なスケーリング改善をもたらす新しいサーバーアーキテクチャも存在する
gitプラットフォームは、Scionのような包括的なサーバー側RPCを提供でき、場合によってはフォージ（GitHubやGitLabのようなgitホスティング基盤）間で標準化し、gitクライアントがそれを扱えるようにすることも考えられる
ネゴシエーションプロトコルが現在とまったく同じ形である必要はない
gitのさまざまなスパース機能やシャロー機能を、うまく組み合わせて使えるようにできる

　最後にAnthropicは、gitコミュニティが20年近くにわたり、数百万人の開発者のためにプラットフォームをスケールさせてきたことに敬意を示しています。同社の貢献ははるかに限られたもので、エージェント型のソフトウェア開発がこうしたシステムとどう関わるかについての早い段階の見方を共有し、GitHub、GitLab、OSSコミュニティと協力して開発者の変化するニーズを支えることだとしています。

　本稿としては、多くのチームにとっての現実的な受け止め方は「Scionを目指す」ことではなく、自分たちの環境でチェックアウトやフェッチがどれだけ発生しているかを把握し、既存のスパースチェックアウトや部分クローン、キャッシュの活用で足りるかを見極めることだと考えています。そのうえで、blameや祖先関係の確認のためだけにリポジトリ全体を取得しているジョブがあれば、サーバー側のAPIで代替できないか検討するというScionの発想は、規模を問わず参考になる可能性があります。今後6〜12か月で同種の問題が広がるという見通しはAnthropicの予測であり、実際にどの程度の組織が直面するかは、AIコーディングツールの利用規模によって大きく異なると思います。

まとめ

　Claudeによるマージ件数の急増を受け、Anthropicは常時オンラインを前提に処理をサーバーへ集約した独自ソース管理「Scion」を5か月で構築・移行しました。汎用的なgitの代替ではないとされていますが、サーバー側RPCなどの考え方がgitエコシステムにどう生かされるかに注目したいと思います。