Anthropic の Scion に学ぶソース管理設計、Git の前提はどこで崩れるか

Posted at 2026-10-27

はじめに

コーディングエージェントを CI やバッチジョブに組み込むと、リポジトリを取得するクライアントの数が人間の開発者数とは別の桁で増えていきます。そのとき最初に音を上げるのはどこなのでしょうか。

対象読者は、リードエンジニア・プラットフォーム担当、そして AI エージェントを開発基盤に組み込もうとしている方です。

Anthropic は 2026-10-13 に Engineering ブログで「Redesigning source control at Anthropic」を公開し、社内向けのバージョン管理システム Scion について説明しました（2026-10-15 に、Scion の技術の源流となったプロジェクトに関する説明が追記されています。巨大モノレポのソース管理には Google の Piper や Meta の Sapling という先行例があり、脚注では Sapling のサーバー側コンポーネントである Mononoke が Scion で使う技術の多くを先に開拓した、と述べられています）。記事の冒頭には次の一文があります。

The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.

コードを書く速さはもはや律速ではなく、人間の規模を前提に作られたソース管理・ビルド・CI が律速になった、という主張です。

この記事で立てる問い

人間規模で設計された開発基盤は、エージェントが主なクライアントになったとき、どこで詰まるのか
Scion の設計原則のうち、Git を使い続ける組織にとって参考になる論点はどれか

先に前提を確認しておきます。公式記事によると Scion は社内向け（in-house）のバージョン管理システムで、他組織がそのまま使える形では提供されていません。記事自身も次のように明言しています。

Scion is by no means a suitable replacement for git for general use.

Git を置き換えるべきかという話ではなく、「どの前提が、どの規模で効かなくなるか」を読み解く材料として扱います。

Anthropic が公表した事実

公式記事が示す規模の数字を整理します。いずれも Anthropic の社内モノレポに関するものです。

項目	公式記事の記述
main にマージされる変更数	2026 年 5 月は 1 日平均約 2,500 件、9 月には 1 日 30,000 件超
main の履歴サイズ	約 100 GB
圧縮したワーキングコピー	25 GB 超
CI 向けチェックアウト	1 日約 2,500 万回
Git で素朴に取得した場合の転送量	1 日 600 PB 超
旧インフラのミラー数	ピーク時に数百の Git ミラー

5 月から 9 月の 4 か月ほどで、1 日あたりのマージ数は 10 倍を超えています。25 GB 超のワーキングコピーを 1 日 2,500 万回取得するという前提を置けば、600 PB 超という試算の桁になることも読み取れます。

公式記事は、Git の特性そのものが "were actively undermining our ability to scale as the repo grew" と述べています。Git は分散型で、クローンがリポジトリの完全な複製を持ち、オフラインでも作業できます。多くのリポジトリにはこの設計が適していますが、巨大なモノレポでクライアントの大半がエージェントやジョブである場合には合わなかった、という整理です。公式記事は、Git にはシャロークローン、スパースチェックアウト、promisor remote といった一部だけを扱う仕組みや、内部ミラーやリポジトリスナップショットといった定番の回避策があると述べたうえで、ミラーはマージ速度の上昇に伴って運用が難しくなったとしています。

Git の前提と Scion の設計原則

公式記事が挙げる Scion の設計原則を、Git の前提と並べると次のようになります。

観点	Git の前提	Scion の設計原則（公式記事より）
接続	オフラインで作業できる	クライアントは常にオンラインで、必要なデータだけを取得する
役割分担	各クローンが同等の能力を持つ（対称）	非対称。履歴・blame・コミット作成・マージはサーバー側、クライアントはローカルキャッシュと作業ツリーを管理する
ツール連携	ローカルのリポジトリを読む	包括的な API を持ち、CI やツールはローカルにリポジトリを持たずに問い合わせられる
スケール	完全な複製を増やす	水平スケール。サーバー上にすら完全に展開された複製は存在しない
コミット	ツリーへのポインタ、refs は自由に増やせる	安価・増分的・ロックフリー。コミットとマージはすべてサーバー側で、refs は最小限
作業ツリー	全体を展開するのが基本	任意で、スパースが基本

スケールの行について、公式記事は "there is no fully materialized copy of the repo anywhere, even on the server." と書いています。Git が「どこにでも完全な複製がある」ことを強みにしているのに対し、Scion は「どこにも完全な複製を置かない」ことを前提にしている点で、設計の出発点が反対向きです。

変更セットという書き込みの単位

Scion の書き込みログの単位は変更セット（changeset）です。Git のコミットがツリー全体へのポインタであるのに対し、公式記事によると変更セットは、最初の親に対して変更されたファイルの一覧と、コンテンツアドレス指定された Blob へのポインタを保持します。blame や履歴は、変更セットから再帰的に計算される派生データという位置付けです。

書き込みを差分のログとして持ち、読み出し用の構造は後から計算する、という分け方になっています。マージ数が 1 日数万件の規模では、書き込みのたびに全体構造を作り直さない設計が効いてくる、と読めます。

3 層の階層キャッシュ

読み出し側は 3 層のキャッシュで構成されています。

公式記事によると、この分割の狙いは障害の影響範囲を層ごとに切り分けることです。取得プロトコルはルートツリーから必要なツリーと Blob を再帰的に要求する形で、途中で切れても再開でき、効率よく取得できるとされています。各層のキャッシュヒット率は 99% を超えると報告されています。

数値の読み方

公式記事が示す効果の数字は次のとおりです。

Scion のインフラは、旧 Git ミラー基盤と比べて CPU とメモリの要件が約 200 分の 1
CI・リサーチジョブのチェックアウトは分単位から秒単位へ（2 桁速い）
CI 単独で CPU 容量が 25% 改善
移行は約 5 か月で、7 人のチームが Scion とコードレビューツール Antique を構築し完全移行
取り込みパイプラインの手作りのプロトタイプを、Claude Mythos Preview の社内の初期スナップショット（early internal snapshot）を使って書き直したところ、メモリ使用量 20 分の 1・速度 4 倍

これらの数字を自分の組織に当てはめる前に、何との比較なのかを確認しておく必要があります。

数字	何を示しているか	何を示していないか
200 分の 1	ピーク時に数百の Git ミラーを抱えていた旧基盤との、CPU とメモリの要件の比較	ストレージや運用工数を含む総コスト、一般的な Git ホスティングやミラーを持たない構成との比較
分単位から秒単位	巨大モノレポを CI・リサーチジョブがチェックアウトする場面	人間の開発者が手元で作業する場面の体感
CPU 容量 25% 改善	CI 単独での改善幅	開発基盤全体のコスト削減率
7 人・約 5 か月	Claude を日常的に使う体制での構築と移行	同じ体制を持たない組織での所要期間
メモリ 20 分の 1・速度 4 倍	取り込みパイプラインという一部コンポーネントの再実装	Scion 全体の性能

一般化には限界があります。前提となる規模（1 日 30,000 件超のマージ、1 日約 2,500 万回のチェックアウト）を持つ組織は多くありません。また Scion は公開されていないため、外部の第三者が同じ条件で再現する手段もありません。数字は「この規模ではこれだけ差が出た」という報告として受け取り、自分のリポジトリにそのまま移すものではないと考えるのが妥当です。

運用面で公式記事が挙げた変化

ソース管理の外側の変化として、公式記事は次の点を挙げています。

エンジニアの役割が、コードを書くことから、意図の確認と設計上のトレードオフの判断へ移った。Claude に "no" と伝える場面が多かったとされています
専門家が数日から数週間かけるような最適化を Claude が見つけた事例もあったとされています
運用では Claude Tag を使い、各コンポーネントを監視する "superfan" と呼ぶ Claude を配置している
人間規模を前提にしたマージキューはエージェント規模では機能しにくく、マージ後・デプロイ前のテストに重点を移している

最後の点は、ソース管理だけを差し替えても終わらないことを示しています。マージ数が 10 倍を超えれば、人間規模を前提にしたマージ前の検証の仕組みそのものを見直す必要が出てくる、という論点です。

公式記事は今後について、設計の考え方を共有し、GitHub・GitLab・OSS コミュニティと協力する（partner with GitHub, GitLab, and the OSS community）ことで、Scion の成功した部分を Git に適用していける形を目指す、としています。

同時期の動き: Entire の正式公開

同じ時期に、エージェント前提でフォージ（Git ホスティングの基盤）を作り直す動きが別の場所からも出ています。GitHub の元 CEO である Thomas Dohmke 氏が構築した Entire が、米国時間 2026-10-26 に正式公開されました（出典: ZDNET Japan（2026-10-27）、Entire 公式 CLI リポジトリ）。Anthropic や Scion とは無関係の別プロジェクトです。

報道と公式 README によると、Entire は次の点を打ち出しています。いずれも提供元の主張であり、本記事では検証していません。

エージェントのセッション記録をコミットに紐づけてリポジトリに残す CLI を提供する（CLI は MIT ライセンスのオープンソース）
プルリクエストを「Trails」に置き換え、カスタマイズした評価項目をエージェントが push ごとに採点する。評価項目がすべて満たされれば、コードそのものを見ずにマージできるとされる
過去のセッションを活用する「Continuous Memory」でトークン使用量を最大 71% 削減できるとしている

エージェント前提でフォージを作り直す動きは、Cursor の Origin（2026 年 8 月に早期ベータとして提供開始と報じられています）など、並行して出ています。Scion が社内専用であるのに対し、Entire は外部の開発者が使えるサービスとして提供される点が対比になります。Scion が「エージェント規模で Git の前提が崩れる場所」を読み解く材料だとすれば、Entire はその前提を外部向けのサービスでどう作り替えるかの一例です。

自分のリポジトリで確認できる観点

Scion を導入する選択肢は現実にはありません。それでも、公式記事が挙げた詰まりどころは、Git を使い続ける組織でも観察できます。以下は自分のリポジトリで確認するための観点です。

クローンの所要時間とサイズ: 新規クローン 1 回にかかる時間と転送量はどれくらいか。半年前と比べてどう変わったか
クライアントの内訳: リポジトリを取得するクライアントのうち、人間・CI・エージェントの比率はどうなっているか。エージェント経由の取得が伸びていないか
1 日の取得総量: 1 日あたりのチェックアウト回数とワーキングコピーのサイズを掛けると、どの桁になるか
回避策の積み重ね: シャロークローン、スパースチェックアウト、ミラー、リポジトリスナップショットなど、回避策が何種類あり、誰が保守しているか
ミラーの運用負荷: ミラーの台数、同期遅延、障害時の切り分けにかかる手間はどれくらいか
ツールのローカル依存: CI やコード解析ツールが、リポジトリ全体をローカルに持たないと動かない作りになっていないか。API で問い合わせる形に置き換えられる処理はないか
マージキューの処理能力: エージェントが作る変更の流量に対して、マージキューの処理が追いついているか。待ち時間は伸びていないか

いずれも「Scion が解いた問題が、自分の環境ではまだ小さいのか、すでに表れ始めているのか」を判断する材料になります。

結論

冒頭の問いに戻ります。

人間規模の開発基盤がエージェント規模で詰まる場所として、公式記事から読み取れるのは「クライアントが完全な複製を持つ」という Git の前提です。クライアントの大半が常時オンラインのエージェントやジョブであれば、オフライン作業の価値は小さくなり、全員に完全な複製を配るコストだけが残ります。Scion はこの前提を反転させ、クライアントは常時オンラインで必要な分だけ取得し、履歴やマージはサーバーに集約し、サーバーにすら完全な複製を置かない設計を選んでいます。

一方で、この選択にはトレードオフがあります。オフライン作業を前提にしない、サーバー側に計算と責任を集める、独自のシステムを社内で保守し続ける、といった代償です。公式記事が「一般用途で Git の代替にはならない」とするのは、Git から大きく乖離しているため、導入側がコードレビュー・検索・CI を含む開発ライフサイクル全体を移行する必要があり、社内向けの構成要素も個別化されているためです（公式記事の説明）。加えて、前述の代償も採用側の負担になると考えられます（本記事の解釈）。

Git を使い続ける組織にとって参考になる論点は、次の 3 つに整理できます。

全量取得を前提にしない: 作業ツリーはスパースを基本にし、取得は必要な分だけにする方向で、既存の回避策を整理できないか
ツールを API 越しにつなぐ: CI やツールがローカルの完全な複製に依存しない構成にできるか
検証の位置を見直す: マージ前の検証にすべてを載せず、マージ後・デプロイ前に重点を移す余地があるか

どれも「こうすべき」と言い切れる話ではなく、規模と体制によって答えが変わります。公開情報から言えるのは、エージェントが主なクライアントになった時点で、ソース管理・ビルド・CI の前提を一度棚卸しする価値がある、という点までです。Anthropic が GitHub・GitLab・OSS コミュニティと進めるとしている取り組みが、Git の枠組みの中でどの論点から形になるのかは、今後の発表を待つ必要があります。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up