Scion はオープンソースか?自分でも使えるのか?
使えない。Anthropic のブログはオープンソース化を発表しておらず、Scion は一般用途に向かず、内部コンポーネントも非常にカスタマイズされていると述べている。二次報道の一部は見出しでオープンソースと書いているが、原文とは一致しない。
アイデアを取り入れたい場合、ブログが示す方向は、Git プラットフォームがサーバー側 RPC を提供し、ネゴシエーションプロトコルや sparse・shallow 機能を改善することだ。
うちのチームは1日のマージが数十回程度だが、心配する必要はあるか?
今のところ必要はない。Anthropic が直面しているのは1日3万件のマージ、100 GB の履歴、1日2,500万回の CI チェックアウトという規模で、一般的なチームとは何桁も違う。
ただしエージェントでコードを大量に書かせ始めるなら、月に一度はマージ数の推移を確認する価値がある。想定より速く伸びることがあるからだ。
ブログにある200倍や20倍といった数字は信用できるか?
これらは Anthropic が自社のエンジニアリングブログで自己申告した数値で、比較の基準も従来の Git ミラー構成であり、一般的な Git の運用ではない。第三者による独立した検証は見つけられなかった。
彼らの極端な規模と使い方のもとでの結果として受け取るべきで、自分の環境でも同じ結果が得られるという約束ではない。
Claude が取り込みパイプラインを書き直した例は、AI が基盤インフラを単独で作れる証拠になるか?
この例が示すのは、明確で比較できる既存のプロトタイプがあるタスクなら、Claude がより効率的なものを作れるということだけだ。ブログが述べているのはプロトタイプのパイプラインの書き直しであり、システム全体を単独で設計できるという意味ではない。
Scion 自体は7人が5か月で作り、コードの大部分は Claude が書いたが、設計上の取捨選択は引き続きエンジニアの判断だった。
Anthropic はエンジニアリングブログで、自社開発のバージョン管理システム Scion を公開し、5か月でモノレポ全体を Git から移行したと発表した。チームは7人で、付属のコードレビューツール Antique も同時に作り、コードの大部分は Claude が書いた。動機は明快で、ブログ自身の言葉では、1日のマージ数が10倍以上に増えたことで、バージョン管理が開発上の最大のボトルネックになったという。
Anthropic の数字によれば、1日のマージ数は 2026年5月の約 2,500 件から 9月には 3万件を超え、約12倍になった。同社は主に AI エージェントが書くコードのためだとしている。モノレポのメインブランチの履歴は 100 GB 近く、圧縮したワーキングコピーは 25 GB 超、CI だけで1日約 2,500万回のチェックアウトがあり、開発環境、エージェントのサンドボックス、研究ジョブは含まれない。ピーク時には Git ミラーが数百あり、従来の取得方法では1日の Git トラフィックが 600 PB を超える計算になる。Anthropic の結論は、Git を分散型・オフライン作業に優れたものにしている特性が、この規模ではかえって足かせになったというものだ。クライアントの大半は常時オンラインのエージェントやジョブで、完全なローカルコピーを必要としない。
Scion はサーバー中心のクライアント・サーバーモデルで、階層化した地域キャッシュを持ち、各層のキャッシュヒット率は 99% を超えると Anthropic は述べている。同社自身の説明では、Scion の CPU とメモリの規模は従来の Git ミラー構成の 200分の1で、CI や研究用のチェックアウトは数分から数秒に短縮され、CI の CPU 容量は約25%余裕が生まれた。別の例として、Claude は追加の指示なしに Git から Scion への取り込みパイプラインを書き直し、メモリ使用量は20分の1、速度は4倍になった。Antique は承認に意味的な条件を設定でき、コメントだけの変更と機密性の高いロジックを含む変更で経路を分けられる。注意点として、これらの数値はすべて Anthropic の自己申告で、第三者による独立した検証は見つけられなかった。
Anthropic は、Scion は決して一般用途の Git の代替にはならず、内部コンポーネントは非常にカスタマイズされていて他の組織が採用するのは難しいと明言しており、ブログにオープンソース化の発表はない。同社が最も有用な貢献と考えるのは考え方の共有で、Git プラットフォームが Scion のようなサーバー側 RPC を提供し、ネゴシエーションプロトコルや sparse・shallow 機能を設計し直せば、Git コミュニティが Scion の最も成功した部分を Git に生かせるとしている。(二次報道の一部は見出しで Scion のオープンソース化と書いているが、原文とは一致しない。原文を基準にしてほしい。)
ほとんどのチームにとって、この話は Git をやめろという意味ではなく、早期警告のサインだ。エージェントが大量にコードを書き始めると、最初に壊れるのはモデルの利用枠ではなく、マージ、CI、チェックアウトといった下流の工程であることが多い。測るべき数字は3つで、1日のマージ数の伸び、CI での平均チェックアウト時間、ミラーやキャッシュの負荷だ。ボトルネックになる前にシャロークローン、キャッシュ、CI の振り分けで対処するほうが、後からアーキテクチャを作り直すよりずっと安い。